特許 6184516 輸送手段の実時間遅延の決定

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6184516

(24)【登録日】2017年8月4日

(45)【発行日】2017年8月23日

(54)【発明の名称】輸送手段の実時間遅延の決定

(51)【国際特許分類】

   G06Q 50/30 20120101AFI20170814BHJP

   G06Q 10/08 20120101ALI20170814BHJP

   G08G 1/00 20060101ALI20170814BHJP

   G08G 1/123 20060101ALI20170814BHJP

【ＦＩ】

   G06Q50/30

   G06Q10/08 306

   G08G1/00 D

   G08G1/123

【請求項の数】16

【全頁数】24

(21)【出願番号】特願2015-548276(P2015-548276)

(86)(22)【出願日】2013年12月16日

(65)【公表番号】特表2016-505962(P2016-505962A)

(43)【公表日】2016年2月25日

(86)【国際出願番号】EP2013003800

(87)【国際公開番号】WO2014095029

(87)【国際公開日】20140626

【審査請求日】2016年9月20日

(31)【優先権主張番号】12290452.7

(32)【優先日】2012年12月20日

(33)【優先権主張国】EP

(31)【優先権主張番号】13/722,441

(32)【優先日】2012年12月20日

(33)【優先権主張国】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】509228994

【氏名又は名称】アマデウス エス．アー．エス．

【氏名又は名称原語表記】ＡＭＡＤＥＵＳ Ｓ．Ａ．Ｓ．

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】マハフィオティ， ヴァンセンゾ

(72)【発明者】

【氏名】コッデス， ジュエル

(72)【発明者】

【氏名】サボルニン， リチャード

【審査官】 谷川 智秀

(56)【参考文献】

【文献】 特開２００２−０１５４００（ＪＰ，Ａ）

【文献】 特開２００２−３５８５９７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００−９９／００

Ｇ０８Ｇ １／００

Ｇ０８Ｇ １／１２３

(57)【特許請求の範囲】

【請求項1】

スケジュールされる輸送手段の実時間遅延を決定する方法であって、
前記方法は、
サーバが、前記スケジュールされる輸送上でまたは前記スケジュールされる輸送において第1のユーザデバイスから前記スケジュールされる輸送についての第1の進行更新のための第1の要求を受信するステップであって、前記第1の要求は、前記スケジュールされる輸送の現在位置を示すデータを含む、ステップと、
前記第1の要求を受信することに応答して、前記サーバが、前記第1の要求内の前記スケジュールされる輸送の前記現在位置を示す前記データに基づいて前記スケジュールされる輸送の前記現在位置を決定するステップと、
前記サーバが、前記スケジュールされる輸送が前記現在位置にあるであろう予定時間について詳細参照スケジュールデータベースを問い合わせるステップと、
前記サーバが、かつ前記スケジュールされる輸送の前記現在位置に基づいて、前記スケジュールされる輸送が前記現在位置にある実時間と、前記スケジュールされる輸送が前記現在位置にあるであろう前記予定時間との間の第1の時間差を決定するステップと、
前記サーバが、前記第1の進行更新を前記第1のユーザデバイスに返送するステップであって、前記第1の進行更新は、前記サーバによって決定された前記第1の時間差を含む、ステップと、
前記サーバが、ログブックデータベース内にタイムスタンプ付き入力として、前記第1の時間差と、前記スケジュールされる輸送の前記現在位置とを保存するステップと、
前記サーバが、第2のユーザデバイスから第2の進行更新のための第2の要求を受信するステップと、
前記第2の要求を受信することに応答して、前記サーバが、前記第1の時間差ついて前記ログブックデータベースに問い合わせるステップと、
前記サーバが、前記ログブックデータベースから得られた前記第1の時間差に基づいて、前記スケジュールされる輸送が前記現在位置にある前記実時間と、前記スケジュールされる輸送が前記現在位置にあるであろう前記予定時間との間の第2の時間差を決定するステップと、
前記サーバが、前記第2の進行更新を前記第2のユーザデバイスに返送するステップであって、前記第2の進行更新は、前記第2の時間差を含む、ステップと
を含み
前記詳細参照スケジュールデータベースは、前記スケジュールされる輸送の予定される進行に対応する複数のタイムスタンプ付き参照位置を含み
前記第1の要求は、前記スケジュールされる輸送の前記現在位置を示すデータをそれぞれが含む複数の第1の要求の1つであり、かつ
前記サーバが、複数の第1の要求のうち、前記スケジュールされる輸送が定刻通りであることを示す進行更新と関連しない第1の要求を破棄するステップと、
前記サーバが、タイムスタンプを、複数の第1の要求のうち、前記スケジュールされる輸送が定刻通りであることを示す進行更新と関連する第1の要求のそれぞれの第1の要求内の前記現在位置と関連付けるステップと、
前記サーバが、前記複数のタイムスタンプ付き参照位置を定義するために、前記詳細参照スケジュールデータベース内に、前記スケジュールされる輸送が定刻通りであることを示す進行更新と関連する前記第1の要求の前記タイムスタンプ付き現在位置データを保存するステップと
をさらに含む方法。

【請求項2】

前記サーバが、前記複数のタイムスタンプ付き参照位置に基づいて、前記スケジュールされる輸送の参照運動曲線を決定するステップをさらに含む、請求項1に記載の方法。

【請求項3】

前記サーバが、前記第1のユーザデバイスにおいて前記詳細参照スケジュールデータベースをキャッシュ化するステップであって、前記スケジュールされる輸送が前記現在位置にあるであろう前記予定時間について問い合わせられる前記詳細参照スケジュールデータベースは、前記キャッシュ化されたデータベースである、ステップをさらに含む、請求項1に記載の方法。

【請求項4】

前記第1の時間差を決定するステップは、
タイムスタンプを前記第1の要求と関連付けるステップと、
前記第1の時間差を決定するために、前記タイムスタンプを前記予定時間と比較するステップと
をさらに含む、請求項1に記載の方法。

【請求項5】

前記タイムスタンプを前記第1の要求と関連付けるステップは、前記第1の要求が受信された時間を決定するステップを含む、請求項4に記載の方法。

【請求項6】

前記タイムスタンプを前記第1の要求と関連付けるステップは、前記第1の要求内に含まれるタイムスタンプデータを読み取るステップを含む、請求項4に記載の方法。

【請求項7】

前記ログブックデータベースは、前記スケジュールされる輸送の前記現在位置を示す前記データを含まない前記第2の要求に応答して、前記第1の時間差について問い合わせられる、請求項1に記載の方法。

【請求項8】

前記ログブックデータベースから得られる前記第1の時間差に基づいて、前記スケジュールされる輸送が前記現在位置にあるであろう前記実時間と、前記スケジュールされる輸送が前記現在位置にあるであろう前記予定時間との間の前記第2の時間差を決定するステップは、
前記保存された第1の時間差における傾向を評価するために、前記ログブックデータベース内の複数の保存された第1の時間差を補外するステップと、
前記傾向に基づいて前記第2の時間差を決定するステップと
を含む、請求項1に記載の方法。

【請求項9】

前記スケジュールされる輸送が前記現在位置にあるであろう前記実時間と、前記スケジュールされる輸送が前記現在位置にあるであろう前記予定時間との間の前記第2の時間差を決定するステップは、前記ログブックデータベース内の直近に保存された第1の時間差を受信するステップと含む、請求項1に記載の方法。

【請求項10】

前記サーバが、前記第2のユーザデバイスにおいて前記ログブックデータベースをキャッシュ化するステップであって、前記スケジュールされる輸送が前記現在位置にある前記実時間と、前記スケジュールされる輸送が前記現在位置にあるであろう前記予定時間との間の前記第1の時間差について問い合わせられる前記ログブックデータベースは、前記キャッシュ化されたデータベースである、ステップをさらに含む、請求項1に記載の方法。

【請求項11】

前記第1の要求は、識別符号を含み、前記識別符号は、少なくとも輸送手段に関連付けられており、
前記サーバが、前記識別符号に基づいて前記スケジュールされる輸送の予定される進行を決定するステップをさらに含む、請求項1に記載の方法。

【請求項12】

前記第1の要求は、識別符号を含み、かつ
前記サーバが、前記識別符号に関する旅程情報についてパッセンジャー・ネーム・レコード・データベースに問い合わせるステップと、
前記サーバが、前記旅程情報に基づいて前記スケジュールされる輸送の現在の区間を決定するステップと
をさらに含む、請求項1に記載の方法。

【請求項13】

前記データによって示される前記現在位置が、前記スケジュールされる輸送の経路内の位置に対応するか検証することによって、前記サーバが、前記第1の要求が前記スケジュールされる輸送の前記現在位置を示すデータを含むことを決定するステップをさらに含む、請求項1に記載の方法。

【請求項14】

前記第1の要求が、前記第1のユーザデバイスのエンドユーザによって入力された前記スケジュールされる輸送を識別する情報を含み、
前記サーバが、前記スケジュールされる輸送を識別する前記情報に基づいて、前記スケジュールされる輸送の現在の区間を決定するステップと
をさらに含む、請求項1に記載の方法。

【請求項15】

スケジュールされる輸送手段の実時間遅延を決定するコンピュータシステムであって、前記コンピュータシステムは、
プロセッサと、
ログブックデータベースと、
詳細参照スケジュールデータベースと、
前記プロセッサによって実行されたときに、前記コンピュータシステムに、
前記スケジュールされる輸送上でまたは前記スケジュールされる輸送において第1のユーザデバイスから前記スケジュールされる輸送についての第1の進行更新のための第1の要求を受信することであって、前記第1の要求は、前記スケジュールされる輸送の現在位置を示すデータを含む、ことと、
前記第1の要求を受信することに応答して、前記第1の要求内の前記スケジュールされる輸送の前記現在位置を示す前記データに基づいて前記スケジュールされる輸送の前記現在位置を決定することと、
前記スケジュールされる輸送が前記現在位置にあるであろう予定時間について前記詳細参照スケジュールデータベースを問い合わせることと、
前記スケジュールされる輸送の前記現在位置に基づいて、前記スケジュールされる輸送が前記現在位置にある実時間と、前記スケジュールされる輸送が前記現在位置にあるであろう前記予定時間との間の第1の時間差を決定することと、
前記第1の進行更新を前記第1のユーザデバイスに返送することであって、前記第1の進行更新は、前記コンピュータシステムによって決定された前記第1の時間差を含む、ことと、
前記ログブックデータベース内にタイムスタンプ付き入力として、前記第1の時間差と、前記スケジュールされる輸送の前記現在位置とを保存することと、
第2のユーザデバイスから第2の進行更新のための第2の要求を受信することと、
前記第2の要求を受信することに応答して、前記第1の時間差ついて前記ログブックデータベースに問い合わせることと、
前記ログブックデータベースから得られた前記第1の時間差に基づいて、前記スケジュールされる輸送が前記現在位置にある前記実時間と、前記スケジュールされる輸送が前記現在位置にあるであろう前記予定時間との間の第2の時間差を決定することと、
前記第2の進行更新を前記第2のユーザデバイスに返送することであって、前記第2の進行更新は、前記第2の時間差を含む、ことと
をさせる命令のセットを含むメモリと
を備え、
前記詳細参照スケジュールデータベースは、前記スケジュールされる輸送の予定される進行に対応する複数のタイムスタンプ付き参照位置を含み、
前記第1の要求は、前記スケジュールされる輸送の前記現在位置を示すデータをそれぞれが含む複数の第1の要求の1つであり、かつ
前記メモリは、前記プロセッサによって実行されたときに、前記コンピュータシステムに、
複数の第1の要求のうち、前記スケジュールされる輸送が定刻通りであることを示す進行更新と関連しない第1の要求を破棄することと、
タイムスタンプを、複数の第1の要求のうち、前記スケジュールされる輸送が定刻通りであることを示す進行更新と関連する第1の要求のそれぞれの第1の要求内の前記現在位置と関連付けることと、
前記複数のタイムスタンプ付き参照位置を定義するために、前記詳細参照スケジュールデータベース内に、前記スケジュールされる輸送が定刻通りであることを示す進行更新と関連する前記第1の要求の前記タイムスタンプ付き現在位置データを保存することと
をさせる命令のセットをさらに含む、コンピュータシステム。

【請求項16】

スケジュールされる輸送手段の実時間遅延を決定するコンピュータプログラムであって、前記コンピュータプログラムは、
非一時的コンピュータ可読記憶媒体と、
プロセッサによって実行されたときに、前記プロセッサに、
前記スケジュールされる輸送上でまたは前記スケジュールされる輸送において第1のユーザデバイスから前記スケジュールされる輸送についての第1の進行更新のための第1の要求を受信することであって、前記第1の要求は、前記スケジュールされる輸送の現在位置を示すデータを含む、ことと、
前記第1の要求を受信することに応答して、前記第1の要求内の前記スケジュールされる輸送の前記現在位置を示す前記データに基づいて前記スケジュールされる輸送の前記現在位置を決定することと、
前記スケジュールされる輸送が前記現在位置にあるであろう予定時間について詳細参照スケジュールデータベースを問い合わせることと、
前記スケジュールされる輸送の前記現在位置に基づいて、前記スケジュールされる輸送が前記現在位置にある実時間と、前記スケジュールされる輸送が前記現在位置にあるであろう予定時間との間の第1の時間差を決定することと、
前記第1の進行更新を前記第1のユーザデバイスに返送することであって、前記第1の進行更新は、前記プロセッサによって決定された前記第1の時間差を含む、ことと、
ログブックデータベース内にタイムスタンプ付き入力として、前記第1の時間差と、前記スケジュールされる輸送の前記現在位置とを保存することと、
第2のユーザデバイスから第2の進行更新のための第2の要求を受信することと、
前記第2の要求を受信することに応答して、前記第1の時間差ついて前記ログブックデータベースに問い合わせることと、
前記ログブックデータベースから得られた前記第1の時間差に基づいて、前記スケジュールされる輸送が前記現在位置にある前記実時間と、前記スケジュールされる輸送が前記現在位置にあるであろう前記予定時間との間の第2の時間差を決定することと、
前記第2の進行更新を前記第2のユーザデバイスに返送することであって、前記第2の進行更新は、前記第2の時間差を含む、ことと
をさせる前記コンピュータ可読記憶媒体上に記憶された命令のセットと
を含み、
前記詳細参照スケジュールデータベースは、前記スケジュールされる輸送の予定される進行に対応する複数のタイムスタンプ付き参照位置を含み、
前記第1の要求は、前記スケジュールされる輸送の前記現在位置を示すデータをそれぞれが含む複数の第1の要求の1つであり、かつ
前記コンピュータプログラムは、前記プロセッサによって実行されたときに、前記プロセッサに、
複数の第1の要求のうち、前記スケジュールされる輸送が定刻通りであることを示す進行更新と関連しない第1の要求を破棄することと、
タイムスタンプを、複数の第1の要求のうち、前記スケジュールされる輸送が定刻通りであることを示す進行更新と関連する第1の要求のそれぞれの第1の要求内の前記現在位置と関連付けることと、
前記複数のタイムスタンプ付き参照位置を定義するために、前記詳細参照スケジュールデータベース内に、前記スケジュールされる輸送が定刻通りであることを示す進行更新と関連する前記第1の要求の前記タイムスタンプ付き現在位置データを保存することと
をさせる命令のセットをさらに含むコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般に、定期(スケジュールされた)輸送手段（scheduled transportation means）の遅延決定に関する。より詳細には、本発明は、モバイル・ユーザ・デバイスを有する乗客に輸送手段についての実時間遅延情報を提供することを対象とする。

【背景技術】

【0002】

所定経路に沿って運行される輸送手段の移動時間は、大部分の乗客にとって重要な情報の１つである。電車、バス、船、飛行機又はトラム等の公共輸送手段で移動する際、乗客は、通常、輸送手段の正確な移動時間、出発時刻及び到着時刻を知りたがる。そのために、各公共輸送手段のための公式な時刻表が運営会社によって例えばウェブ上で乗客に提供される。一般に、こうした公式な時刻表には、特定経路内の全ての駅に対する計画出発時刻及び計画到着時刻を含む。しかし、輸送手段は、予期せぬ要因（例えば悪天候、交通状況等）のために遅延することがある。その結果、時刻表は、輸送手段の実際の進行を反映しない場合がある。

【0003】

特許文献１は、普通列車又は路線バスの乗客に遅延情報を提供する方法を開示している。該公報は、ＧＰＳデバイス等の位置測定デバイスを有する到着時刻表示デバイスを記載している。電車又はバスの到着遅延時刻及び早期到着時刻は、到着時刻表示デバイス内に含まれる時間差計算部により、特定位置における予定到着時刻と現在の時刻との間の時間差を計算することによって計算される。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開平０６−０４４４９５号公報

【発明の概要】

【課題を解決するための手段】

【0005】

本発明によれば、時刻表に従い、経路に沿って運行される定期輸送手段の実時間遅延を決定する方法が提供される。経路は、少なくとも１つの区間を含む。実時間遅延の決定は、定刻通りである輸送手段の任意のタイムスタンプ付き参照位置を示す詳細参照スケジュールに基づく。本方法は、位置基準（ｐｏｓｉｔｉｏｎ−ｂａｓｅｄ）決定及び時間基準（ｔｉｍｅ−ｂａｓｅｄ）決定を含む。位置基準決定は、
（ｉ）輸送手段上に位置するユーザ・デバイスによる輸送手段の実時間遅延に関する要求を受信することであって、要求は少なくとも輸送手段の現在位置を示す、受信すること；
（ｉｉ）要求内に示された現在位置、タイムスタンプ、及び詳細参照スケジュールの対応するタイムスタンプ参照位置に基づいて輸送手段の実時間遅延を計算すること；
（ｉｉｉ）計算した実時間遅延を要求中のユーザ・デバイスに返送すること；並びに
（ｉｖ）計算した実時間遅延をログブック内に保存すること；
を含む。時間基準決定は、輸送手段の現在位置を示さない異なる又は同じユーザ・デバイスによる要求への応答時、輸送手段に対する実時間遅延入力を含むログブックに基づいて実時間遅延を返送することを含む。

【0006】

別の態様によれば、上記した定期輸送手段の実時間遅延を決定するコンピュータ・システムが提供される。

【0007】

別の態様によれば、コンピュータ・プログラム命令を中に保存した非一時的コンピュータ可読記憶媒体であって、コンピュータ・プログラム命令をコンピュータ・システム上で実行すると上記した方法が実施される。

【0008】

更に別の態様によれば、コンピュータ・プログラムであって、コンピュータ・システム上で実行すると上記した方法が実施される、コンピュータ・プログラムが提供される。

【0009】

更なる態様は、従属請求項に示される。

【0010】

本発明を添付の図面を参照しながら説明する。同様の参照番号は、一般に同一又は機能的に同様の要素を示す。

【図面の簡単な説明】

【0011】

【図1】本発明の遅延決定の原理を示す流れ図である。

【図2】本発明の遅延決定の一例によるより具体的な流れ図である。

【図3】本発明の遅延決定の一例に利用されるパッセンジャー・ネーム・レコード（ＰＮＲ）データベースの図である。

【図4】定期輸送手段の例示的時刻表の図である。

【図5】本発明の遅延決定に利用できる例示的詳細参照スケジュールの図である。

【図6】直線補間を使用して参照時間計算を示す計算例の図である。

【図7】輸送手段の例示的運動曲線の図である。

【図8】本発明の遅延決定に利用できる例示的ログブックの図である。

【図9a】本発明の遅延決定の実装例によるユーザ・デバイスにおける手順を示す詳細流れ図である。

【図9b】本発明の遅延決定の実装例によるサーバ側における手順を示す詳細流れ図である。

【図9c】本発明の遅延決定の実装例によるユーザ・デバイスにおける手順を示す詳細流れ図である。

【図10】本発明の遅延決定を実施するように構成した例示的システムの構成図である。

【図11】本発明の遅延決定を実施するアプリケーションを稼動するユーザ・デバイスのグラフィカル・ユーザ・インターフェースの図である。

【図12】本発明の遅延決定を実施するアプリケーションを稼動するユーザ・デバイスのグラフィカル・ユーザ・インターフェースの図である。

【図13】ユーザ・デバイスの内部構成の例示的概略図である。

【発明を実施するための形態】

【0012】

図２から図１３を参照して詳細な説明に目を向ける前に、最初に、一部の一般的態様を図１に基づいて示す。

【0013】

本発明は、一般に、特定の時刻表に従って定期的に移動する定期輸送手段に関する。そのような定期輸送手段は、例えば、電車（国際、高速、国内又は地域又は近郊の電車）、バス、シャトル・カー、飛行機、船又はフェリー、トラム或いは任意の他の公共輸送手段とすることができる。

【0014】

時刻表は、通常、輸送手段の運営者によって作成、発行される。例えば、ＳＣＮＦは、フランスで運行する全てのＴＧＶに関する時刻表を作成、発行している一方で、ドイツ鉄道は、ドイツで運行するＩＣＥの時刻表を作成、発行している。運営者は、一般の人々、特には駅にいる乗客に対して、インターネットを介して又は輸送手段自体において／輸送手段自体内で入手可能な時刻表を作成している。輸送手段の時刻表は、通常、輸送手段の起点及び最終目的地並びに中間駅を示す。更に、時刻表は、通常、起点駅の出発時刻及び最終目的地の到着時刻、並びに中間駅の出発時刻及び任意選択で到着時刻を示す。

【0015】

このことにより、運営者の時刻表は、定期輸送手段をそれらの経路及び移動時間に関して論理的にグループ化する。同一時刻に同一経路を進む輸送手段を以下、特定の「関係」（ｃｏｎｎｅｃｔｉｏｎ）に属する輸送手段と呼ぶ。例えば、ニース発パリ行きの毎日１０時に運行する全ての電車は、そのような関係を形成する。一方、用語「経路」は、時刻表に従った、起点駅から最終目的地までの定期輸送手段の進路を指す。例えば、上述の関係に属する電車（即ちニース発パリ行きの毎日１０時のＴＧＶ）の場合、経路は、ニース・パリ間の線路によって示される。更に、一般に、定期輸送手段の経路は、区間から構成される。以下では、用語「区間」は、時刻表に掲載された２つの続く駅の間の経路部分を指す。例外的に、経路は、時刻表が起点駅と最終目的地との間に中間停止駅を何も規定しない場合、ただ１つの区間からなる。しかし、経路は、通常複数の区間に分割される。例えば、時刻表が起点と最終目的地との間に６つの中間駅を示す場合、経路は７つの区間に細分される。

【0016】

通常、乗客は、運営者の時刻表によって設定された、輸送手段の計画到着時刻及び計画出発時刻のみならず、乗客が使用するつもりの又は現在使用している特定の輸送手段の実際の進行にも興味をもっている。例えば、待ち時間を最小にする又は適切な接続輸送手段を選択するために、乗客は自分の輸送手段が現在完全に定刻通りか、予定より遅れているか、又は更にはスケジュールより前であるかどうかの知識を有することが有益である。この点において、用語「遅延」は、本明細書ではこうした可能性の３つの全てを含むために使用される。したがって、遅延は、輸送手段がスケジュールより遅れており、おそらくは次の駅には時刻表が示すよりも遅く到着する場合、プラスである。遅延は、輸送手段が定刻通りでありおそらく次の駅に時刻表が示す時刻に到着する場合、ゼロである。輸送手段がスケジュールより早い、したがっておそらく次の駅に時刻表が示すよりも早く到着する場合、遅延はマイナスである。

【0017】

このニーズに対処するために、輸送手段の現在の遅延を計算するように構成したユーザ・デバイスが従来技術において公知である。一例は、既に上述した特許文献1である。しかし、該公報で開示された遅延計算は、目的地情報を手入力し、ユーザの現在位置を例えば全地球測位システム（ＧＰＳ）の利用によって提供する必要がある。したがって、ＧＰＳ有効範囲が不十分又は存在しない状況では、このシステムは適切に動作しない。更に、特許文献1で記載した手法は、予定到着時刻を現在の時刻と、目的地位置を現在位置と単に比較することに基づいている。明らかに、ユーザの直線進行が想定されている。このことは、通常は非直線である現実世界の進行と相関しない。したがって、特許文献1で提案される手法は、本質的に不正確である。

【0018】

従来技術のこうした問題に対処することが本発明の目的である。本明細書で提示する遅延情報方法／システムにより、位置決定機能を備えない又は位置決定が可能ではない状況にあるユーザ・デバイスに実時間遅延情報を提供することが可能になる。更に、遅延情報方法／システムは、遅延情報の正確さを改善することを目的とする。

【0019】

一方では、本発明の遅延決定は、輸送手段の運営者が発行した時刻表よりも詳細な参照スケジュール４に基づく。上記で概説したように、こうした運営者の時刻表は、輸送手段の停車駅又は駅に関する目標時刻を単に含むだけである。しかし、この情報は、本発明では中間駅の間の位置、即ち区間内の位置に関する参照情報を何も提供しないため不十分であるとみなされている。運営者の時刻表を補う１つの可能性は、中間駅の間の輸送手段の直線進行を仮定し、それに応じて直線補間により時刻表を「埋める」ことである。しかし、本発明では詳細参照スケジュール４を導入し、この詳細参照スケジュール４は、中間駅の間のスケジュール通りの輸送手段の実際の現実世界進行をより正確に反映することを目的とする。この目的で、詳細参照スケジュール４は、それぞれの運営者の時刻表から取得できる中間駅における目標時刻情報に加えて、経路に沿ったあらゆる任意の場所に対する目標時刻情報を含む。言い換えれば、詳細参照スケジュール４は、運営者が規定した駅の到着時刻及び出発時刻のみを示すだけでなく、具体的には、定刻通りである輸送手段の更なるタイムスタンプ付き参照位置も含み、この位置は、任意、即ち停車駅又は駅とは無関係である。本明細書で提示する遅延決定に従って動作する発展システムでは、詳細参照スケジュール・データは、本発明の遅延決定により含まれる各関係のために存在することになる。例えば、既に述べたＴＧＶの例を再度参照すると、毎日１０時ニース発のニース発パリ行きＴＧＶのための詳細参照スケジュール・データ、及び毎日正午ニース発のニース発パリ行きＴＧＶのための更なる詳細参照スケジュール・データがあることになる。そのような詳細参照スケジュール４を確立するいくつかの可能性があり、以下で更に説明する。１つの可能性は、定刻通りであった輸送手段に関連する位置基準要求からのデータを収集することによる、いわゆる「社会的手法」である。この詳細参照スケジュール４は、予定停車駅のみを参照データとして使用する時刻表基準（ｔｉｍｅｔａｂｌｅ−ｂａｓｅｄ）手法と比較して参照データの細分性を増大させることにより、輸送手段の遅延のより厳密な決定を可能にする。

【0020】

一方、本発明の遅延決定方法は、当該輸送手段についての実時間遅延情報を収集するログブック５を利用する。ログブック５は、以下のように実施される位置基準遅延決定により生成した実時間遅延情報で記入される（図１の左手の分岐により可視化される）。

【0021】

輸送手段上に位置する又は輸送手段にいる乗客は、携帯電話、スマートフォン、ラップトップ、タブレット・コンピュータ等のモバイル・ユーザ・デバイス１を備える。ユーザ・デバイス１は、輸送手段の実時間遅延に関する要求を生成する。要求には、輸送手段の現在位置と同一である、ユーザ・デバイス１の少なくとも現在位置を含む。現在位置は、サーバに発行されるか、或いはキャッシュ機構を使用してユーザ・デバイス１でローカルに処理できる（これは、以下でより詳細に説明する）。次に、要求は、サーバによって受信されるか、又はユーザ・デバイス１の内部で受信される。次に、要求は、輸送手段の遅延を計算するために処理される。要求内に示された現在位置、及び更には要求に関連するタイムスタンプに基づいて、詳細参照スケジュール４が調べられ、定刻通りの輸送手段に関するそれぞれのタイムスタンプ付き参照位置を使用して輸送手段の実時間遅延を計算する（図１の囲み１２）。遅延計算の詳細は、以下で更に説明する。得られた遅延情報は、図１の囲み８で、（再度、サーバによって又はユーザ・デバイス１内部で）ユーザ・デバイス１に返送される。しかし更に、計算した遅延情報は、ログブック５内に記録、保存される。

【0022】

位置基準決定により入手した遅延情報を記入したログブック５は、純粋な時間基準決定を促進し（図１の右手の分岐に示す）、この純粋な時間基準決定は、ユーザ・デバイス１による位置決定を何も伴わずに機能する。位置基準要求を以前に発行したユーザ・デバイスと同じであっても、別であってもよいユーザ・デバイス１は、時間基準要求を生成し、この時間基準要求は、上記した位置基準要求とは対照的に、ユーザ・デバイス１の現在位置の表示を含まない。その理由は、デバイス１が以下の理由によりその現在位置を決定できないという可能性がある：デバイス１が位置決定手段を全く備えていないため、デバイス１が本発明の遅延決定の目的では不十分である不正確な位置決定手段しか備えていないため、或いは例えば有効範囲がない、人工衛星へのフリー・ライン・オブ・サイトがない、輸送手段から離れている（例えば関心をもっているユーザが家にいる）等が原因で要求の時点で位置決定が不可能であるため、のいずれかである。ユーザの輸送手段に関連するログブック・データをこの時間基準要求に基づいて決定できるという条件で、輸送手段の遅延を決定し（図１の囲み７）、ログブック５内で利用可能な実時間遅延入力に基づき、輸送手段に関する遅延情報を返送する（再度、図１の囲み８）ことが可能である。

【0023】

このようにして、輸送手段に関する実時間遅延情報は、乗客のユーザ・デバイス１上に表示される。実時間遅延情報には、例えば運営者の時刻表による駅、具体的には次の駅（現在の区間の終了点）への輸送手段の予定到着時刻、輸送手段の現在の時間遅延、並びに次の目的地及び／又は最終目的地におけるそれぞれの起こり得る実到着を含むことができる。

【0024】

上記で概説したように、位置関連要求及び時間関連要求の両方は、タイムスタンプに関連する。このタイムスタンプを使用して、輸送手段が要求の時間に位置すると思われる区間を決定し、実時間遅延を計算する。基本的には、タイムスタンプを生成するには２つの方法がある。１つの可能性は、ユーザ・デバイス１による要求内にタイムスタンプを直接含めることである。したがって、このオプションにより、要求はタイムスタンプを実際に含む。もう１つの可能性は、要求の受信時にのみタイムスタンプを生成することである。このオプションは、（以下で更に説明するキャッシュ機構を使用してユーザ・デバイス１で要求をローカルに処理するのとは反対に）サーバが要求を中央で処理する場合、特に有用である。タイムスタンプをサーバで生成すると、全ての要求が１つの同じサーバ側クロックによりタイムスタンプ付けされるので、一貫した時間管理が保証される。また、（要求内にタイムスタンプを含める）最初のオプションを使用する場合、即ちユーザ・デバイス１が信頼できるクロックと同期する場合も同様の一貫した時間管理が可能である。

【0025】

既に上記で示したように、詳細参照スケジュール４を確立し、移動手段の必要な任意のタイムスタンプ参照位置を作成する仕方のいくつかのオプションがある。上記の始めで既に説明したように、こうしたタイムスタンプ付き参照位置は、輸送手段の駅又は停車駅とは無関係な経路上のあらゆる場所を指すので「任意」である。詳細参照スケジュール４を確立する１つの可能性は、輸送手段運営者の協働とは無関係な、いわゆる「社会的手法」である。したがって、参照スケジュールは、運営者の輸送手段のネットワーク及び時期条件について詳細データを配信する運営者の善意を当てにする必要がなく利用できる。社会的手法は、輸送手段上に位置するユーザ・デバイス１が発行した実位置基準要求を利用する。こうした要求のそれぞれが輸送手段の位置及び関連するタイムスタンプ（即ちタイムスタンプ＋位置ペア）をもたらすので、これらは、一般に有益なデータベースを提供する。詳細参照スケジュール４の入力が参照タイムスタンプ付き位置として働くと同時に、収集したデータの検証が実施される。全部の数の収集したタイムスタンプ＋位置ペアのうち、定刻通りであった輸送手段（即ち運営者の時刻表に従って進行した輸送手段）に属するペアをシークし、定刻通りではなかった輸送手段による残りのデータ・セットを破棄する。この分類は、運営者が参照時刻を設定した駅付近の位置を有するタイムスタンプ＋位置ペアを見ることによって実施できる。駅付近の位置を有するペアが運営者の時刻表が規定した時刻に対応する場合、それぞれの輸送手段は定刻通りであったとみなされ、この輸送手段から収集した全てのタイムスタンプ＋位置ペアは有効であるとみなされ、詳細参照スケジュール４内に含められる。

【0026】

詳細参照スケジュール４を確立するための更なる任意選択の代替形態は、輸送手段上の専門職員によって生成されることができる人為的な要求、輸送手段の運営者によるそれぞれのデータのシミュレーション又はプロビジョンである。

【0027】

ログブック５は、輸送手段の現在位置を示さない要求への応答時、基本的に２つの方法で利用される（図１の囲み７）。１つの方法は、要求中のユーザ・デバイス１にログブック５内の輸送手段に関する直近の実時間遅延入力を単に返送することである。このオプションは、ログブック５内のこの直近の入力が最新であり、したがって輸送手段の現在の実時間遅延を正確に反映する場合、特に適している。ログブック５内の最終入力の最新さは、例えばログブック入力のタイムスタンプと要求に関連するタイムスタンプとの比較により決定される。これら２つのタイムスタンプ間の差異が所与の閾値を下回る、例えば５分若しくは１０分未満である場合、又は依然として輸送手段の現在の区間内にある場合、最終ログブック入力の正確さが想定され、この直近のログブック入力の遅延情報が返送される。輸送手段の現在位置を表示しない要求に対してログブック５を利用するもう１つの方法は、遅延の傾向を評価するためにログブック入力を補外することである。補外は、直近のログブック入力がかなり古く（例えば最終入力のタイムスタンプと要求のタイムスタンプとの差異が前述の所与の閾値を上回る）、したがってタイムスタンプが古くなっているようであり、輸送手段の実際の実時間遅延を正確に反映しないおそれがある場合に適切であると考えることができる。適切に適用できる補外技法は、指数平滑法である。補外の結果は、ユーザ・デバイス１に返送される。

【0028】

同様に、輸送手段の現在位置を示す要求への応答時の実時間遅延計算（図１の囲み１２）に関して様々なオプションがある。例えば、詳細参照スケジュール４が、要求内に示された輸送手段の現在位置に対応するタイムスタンプ付き参照位置を含む場合、詳細参照スケジュール４内のその位置に関連する参照タイムスタンプと、要求に関連するタイムスタンプとの差異を計算すれば十分である。２つのタイムスタンプ間の差異は、輸送手段の正確な実時間遅延であり、ユーザ・デバイス１に返送される（図１の囲み８）。一方で、詳細参照スケジュール４が要求内に示される位置と対応する参照位置を含まない場合、２つの更なるオプションがある。要求内に示される位置に最も近い参照位置を求めて詳細参照スケジュール４を探索すること、及び直前で説明したように（即ち詳細参照スケジュール４内のその位置に関連する参照タイムスタンプと要求に関連するタイムスタンプとの間の差異を計算することによって）実時間遅延を計算することのいずれかである。しかし、このことは、一定の不正確さをもたらし、この不正確さは、２つの位置（即ち詳細参照スケジュール４内の位置及び要求内の位置）が互いにずれるほどたくさんになる。この不正確さを最小にするために、代替的に、要求内に示される位置付近の詳細参照スケジュール４内のタイムスタンプ付き位置に対して直線補間技法を利用できる。

【0029】

詳細参照スケジュール・データが、適用される各関係及び輸送手段に対して存在することは上記で既に簡単に概説した。したがって、正確な輸送手段又はそれぞれの関係及び対応する詳細参照スケジュール・データをユーザ・デバイスの要求から演繹する必要がある。要求と輸送手段／関係／詳細参照スケジュール・データとの間を関連付ける１つのオプションは、要求内に含まれる識別符号であり、この識別符号が輸送手段の識別を可能にする。そうすると、この識別符号は、正確な時刻表データ、（要求内に含まれる地理的位置の使用による）現在の区間、及び詳細参照スケジュール４内の関連データに対して結論付けることが可能である。１つの実装例では、この識別符号は、乗客の旅程情報に関するＰＮＲデータベースに問い合わせることを可能にするパッセンジャー・ネーム・レコード（ＰＮＲ）識別子である。この旅程情報は、乗客が現在使用している輸送手段の関係に関する情報を含むことができる。代替的に、ＰＮＲ識別子以外の識別符号は、要求内に含まれる。例えば、ユーザ・デバイス１は、現在使用している輸送手段及び関係それぞれの入力をユーザに促すことができ、乗客がこの情報を手入力すると、次にこの情報は要求内に含まれる。

【0030】

任意選択の実装形態では、位置基準決定は、要求中のユーザ・デバイス１における詳細参照スケジュール４のキャッシュ化を含む。例えば、ユーザ・デバイス１は、特定の輸送手段に関する最初の位置基準要求を遅延決定サーバに誘導する。サーバは、乗客が現在使用している輸送手段の関係に関連するデータを含む詳細参照スケジュール４を維持する。ユーザ・デバイス１の位置基準要求は、上記のように遅延決定サーバによって処理され、計算した実時間遅延は、ユーザ・デバイス１に返送される。しかし、キャッシュ化を使用する任意選択の実装形態では、乗客の現在の輸送手段に属する詳細参照スケジュール・データも、実時間遅延情報と共に、又は実時間遅延情報がサーバにより返送される前若しくは返送された後個別のメッセージでユーザ・デバイス１に転送される。次に、詳細参照スケジュール・データをユーザ・デバイス１のキャッシュ・メモリ内にバッファリングする。したがって、同じユーザ・デバイス１によるその後の位置基準要求は、位置基準要求を遅延決定サーバに送信する必要性を何も伴わずにユーザ・デバイス１でローカルに処理できる。このようにして、ユーザ・デバイス１が外部通信リンクを何も起動する必要なしに位置基準遅延計算が可能になり、したがって例えば、無線有効範囲外の領域で実施できる。

【0031】

この結果、ユーザ・デバイス１に無線リンクがないためにキャッシュ化詳細参照スケジュール４を使用して位置基準遅延決定がユーザ・デバイス１でローカルに実施された場合は、ローカルで計算した実時間遅延情報を遅延決定サーバ内に維持できるログブック５内に保存できない。このことが生じた場合、ローカルで計算した実時間遅延情報も、ユーザ・デバイス１のローカル・ログブック内でローカルにバッファリングすることになる。より後の時点で再度無線リンクが利用可能である場合、ユーザ・デバイス１は、バッファリングした実時間遅延情報を遅延決定サーバに送信し直し、すると情報が（中央のサーバ側）ログブック５内に導入される。

【0032】

ユーザ・デバイス１におけるキャッシュ化は、乗客が現在使用している輸送手段の詳細参照スケジュール・データに限定されなく、他の情報にも有用に拡大できる。例えば、更なる詳細参照スケジュール・データは、乗客が使用しそうな将来の輸送手段に関係する可能性があり、そのような接続輸送手段も、同様にユーザ・デバイス１でキャッシュ化できる。ユーザ・デバイス１で利用可能なバッファ・スペース及びユーザ・デバイス１が利用可能な通信リンク帯域幅に鑑みて実行可能である場合、将来の乗客に関連し得る、より多くの又は全ての詳細参照スケジュール・データがユーザ・デバイス１に転送され、そこでローカルの位置基準遅延決定用に保存される。更に、ユーザ・デバイス１による最初の位置基準要求への応答時、サーバ側ログブック５もユーザ・デバイス１に転送され、そこでキャッシュ化できる。このキャッシュ化したログブックは、時代遅れになるので、より長い時間期間で更新しない場合は重要性を失うが、遅延決定サーバを調べる必要性を何も伴わずにユーザ・デバイス１で時間基準決定をローカルに実施することを可能にする。データがユーザ・デバイスでキャッシュ化される程度は、ユーザ・デバイスの利用可能なリソース（例えば空いているバッファ・スペース、通信リンクの質）とキャッシュ化データにより達成可能な起こり得る改良事項との兼ね合いである。

【0033】

上記で概説した基本的手法、即ち位置基準遅延要求及びそれらの計算結果の収集によってログブック５に実時間遅延情報を記入することは、更なる適用例に活用できる。例えば、ログブック５が維持する情報は、駅のディスプレイ、インターネットを介してアクセス可能なウェブサイト又はウェブ・サービス、ＲＳＳ又はＳＭＳのようなプッシュ・サービス、或いはあらゆる他のブロードキャスト型情報配信チャンネルに転送できる。したがって、それぞれの輸送手段上で移動していない他の人々は、自分の現在位置とは無関係に本発明の実時間遅延決定機構から恩恵を受けることができる。

【0034】

更に、輸送手段の実時間遅延についての情報を得ることを必ずしも対象としないメッセージによる実時間遅延システム及びログブック５を供給することは、本明細書で提示する手法の範囲内である。むしろ、そのようなメッセージは、遅延を実際に要求することなく輸送手段の現在の遅延をシステムに通知する目的を純粋に務める可能性がある。例えば、駅職員、実際の若しくは潜在的な旅行者のような人々又は関心がある他の人々は、例えばＧＳＭ、ＳＭＳを使用してメッセージを遅延決定サーバに送信でき、それにより特定の輸送手段の場所及び現在の遅延を示す。そのようなメッセージに応答して、遅延決定サーバは、情報の検証を実施し、情報が有効である可能性が高いことがわかった場合、ログブック５に遅延の表示を追加する。

【0035】

次に、より詳細な説明に目を向けると、図２は、本発明の実時間遅延決定のより具体的な例を示す。図１と同様に、図２の左手分岐は、位置基準遅延決定を示す一方で、右手側の分岐は、時間基準遅延決定を指す。

【0036】

図２の例では、ユーザ・デバイス１は、ローカルにインストールされた遅延決定アプリケーションを備えるスマートフォンであり、この遅延決定アプリケーションは、遅延決定要求を生成するように構成される。スマートフォンは、情報をユーザに表示するようにし、またユーザが本発明の遅延決定を始動させたい場合にユーザ入力を可能にするように構成したグラフィカル・ユーザ・インターフェースを有する。スマートフォンは、２Ｇ、３Ｇ及び／又は４Ｇ送受信器、並びに／或いはＷｉＦｉ ＩＥＥＥ８０２．１１等の他の移動通信規格に対し動作する送受信器による移動通信インターフェースも備える。こうした通信インターフェースは、移動通信、具体的には遅延決定要求の送信及び実時間遅延情報の受信を促進する。

【0037】

更に、スマートフォンは、ＧＰＳ送受信器を備え、したがってＧＰＳ衛星への通信リンクが確立できるという条件でその場所を決定できる。ＧＰＳが何らかの理由で利用可能ではない場合、スマートフォン１は、三角測量又は観測時間差技法等他の位置決定方法を利用できる。位置決定が可能である場合、スマートフォン１は、ユーザからのそれぞれの入力コマンドの後、位置基準遅延決定を開始する。スマートフォン１は、その位置を決定し、得られた地理的位置を要求内に含める。更に、現在時刻を示すタイムスタンプをスマートフォン１が生成した要求内に含める。代替的に、上記で説明したように、タイムスタンプは、要求内に含まれないが、全体的な時間整合性の理由でサーバ側でのみ取得される。最後に、ＰＮＲ識別を要求内に含める。ユーザにＰＮＲ識別の入力を促すか、それぞれの情報がスマートフォン１でローカルに入手可能な場合はＰＮＲ識別が自動的に生成されるかのいずれかである。スマートフォン１が位置基準要求を作成し終わると、位置基準要求を適切な移動通信リンクにより遅延決定サーバ４７に送信する（サーバは図２に示されておらず、全体的なシステムの高レベル構造は、図１０を参照して以下で更に説明する）。

【0038】

要求がサーバにより受信された後、要求内に含まれる地理的位置及びＰＮＲ識別を利用して、ユーザが現在位置する輸送手段（より正確には輸送手段の関係）、より具体的には輸送手段が現在位置する経路の現在の区間を決定する。この目的で、遅延決定サーバ４７は、ＰＮＲデータベース２等の旅行情報システムに適切に接続される。ＰＮＲデータベース２の概略図を図３により示す。ＰＮＲデータベース２は、ユーザの移動の旅程情報を含む。移動は、Ａ発Ｂ行きのフライト及びＢ発Ｃ行きの接続電車の移動等、いくつかの区分から構成できる。区分のうち１つは、ユーザが位置し遅延決定要求が関連する現在の輸送手段により形成される。以下において、例示的な理由でＢ発Ｃ行きの電車移動の例に言及するが、この例は輸送手段の種類に関していかなる限定ももたらさないものとする。要求が関連する輸送手段を発見する本発明の目的で、ＰＮＲデータベース２に保持されるそれぞれの識別情報は、最も関心があるもの、即ちユーザが旅程に従ってＢ発Ｃ行きの移動のために乗るはずである電車のＩＤである（図３を参照）。

【0039】

電車ＩＤ（例えば「Ｔｒ１」）を入手した後、サーバ４７も利用可能である電車運営者の正確な時刻表３を参照することが可能である。時刻表３の一例を図４により示す。時刻表は、いくつかのパラメータ、中でも電車ＩＤ、駅ＩＤ（「ｓｔＩＤ」）、駅の地理的位置（「ｌａｔ」は緯度、「ｌｎｇ」は経度の略であり、度で示す）並びに出発時刻（「ＡｒｒＴＤ」）及び到着時刻（「ＤｅｐＴＤ」）を含むことができる。したがって、図４の非常に単純な例によれば、電車Ｔｒ１の起点駅はｌａｔ４３．５５度、ｌｎｇ７．０２度に位置するＳｔ１である。電車は、Ｓｔ１から７：３０に出発すると想定される。次の停車駅は、ｌａｔ４３．５９度、ｌｎｇ７．１２度に位置する中間駅Ｓｔ２である。この電車は、中間駅Ｓｔ２に８分後の７：３８に到着し、２分間の滞在後７：４０に出発する。最終目的地は、ｌａｔ４３．７０度、ｌｎｇ７．２８度に位置する駅Ｓｔ３であり、８：０１に到着すると想定される。更に、時刻表３は、駅の地理的位置情報及び駅間の距離情報、即ち区間の長さを含むことができる（図４には示さない）。時刻表３に問い合わせる目的は、輸送手段が現在位置する区間（言い換えれば運営者の時刻表３による次の計画停車駅）を決定することである。したがって、要求内に含まれる地理的位置は、時刻表３への問合せの引数として渡され、現在の区間を抽出する。したがって、工程は、（要求内に当初から含まれる）地理的位置、（要求内に含まれるか又はサーバによる要求の受信時に設定した）タイムスタンプ及び（直前に説明したＰＮＲデータベース２及び時刻表３の調査により決定される）区間に更に進む。

【0040】

次のステップは、詳細参照スケジュール４の更新である（図２の囲み１０）。上記で既に詳細に説明したように、詳細参照スケジュールは、任意のタイムスタンプ付き参照位置、即ち運営者の時刻表３に従って定刻通りである輸送手段のタイムスタンプ＋位置ペアを含む。詳細参照スケジュール４の一例を図５により示す。詳細参照スケジュール４は、電車ＩＤ（例えばＴｒ１、Ｔｒ２）、区間ＩＤ、タイムスタンプ及び位置（ｌａｔ、ｌｎｇ）を含む。図５の例によれば、電車Ｔｒ１は、７：３５に座標ｌａｔ４３．５６度、ｌｎｇ７．１１度にあり、７：３６に座標ｌａｔ４３．５７度、ｌｎｇ７．１１度にあることが想定され、以下同様である。任意のタイムスタンプ付き参照位置をこのように収集すると、移動手段の運動曲線を形成し（図７を参照）、この運動曲線は、検証したタイムスタンプ付き参照位置データを含めば含むほどより正確になる。

【0041】

上記のように、詳細参照スケジュール表４を確立し、充実させるための１つの手法は、実際に発生した位置基準ユーザ要求を収集し詳細参照スケジュール表内に保存する、いわゆる「社会的手法」である。詳細参照スケジュール表４の更新ステップ１０は、まさにこの目的の役割を果たす。更新ステップ１０は、既に十分な有効データが詳細参照スケジュール表４内に存在する場合には必要ではないので、概して任意選択なステップである。更新１０とは、地理的位置とタイムスタンプとのペアが詳細参照スケジュール表に参照データとして追加されることを意味する。しかし、この任意選択の追加が実施された場合、続いて、更なる処理、即ち検証１１が実行される。追加されたタイムスタンプ付き参照位置は、実際に参照位置の役割を果たすのに適切であることを保証するために検証する必要がある。追加されたタイムスタンプ付き参照位置は、輸送手段（即ち本例では電車Ｔｒ１）が実際に定刻通りである場合にのみ、適切である。上記で既に説明したように、特定のＴｒ１が定刻通りであるか否かの決定は、詳細参照スケジュール表に追加された任意のタイムスタンプ付き位置を時刻表３の参照データと一致させることにより行うことができる。検証を実施していない限り、フラグ「有効」内の対応する評価は、「Ｎｏ」に設定される（図５を参照）。まだ検証されていない入力が有効であることがわかると、「有効」フラグの評価は、「Ｙｅｓ」に変更される。入力が無効である（即ち電車が定刻通りではなかった）ことがわかると、その入力は、詳細参照スケジュール表４から削除される。

【0042】

次に、位置基準遅延決定は、詳細参照スケジュール表４内のタイムスタンプ付き参照位置の検証済み入力に基づく遅延の実際の計算に進む（図２の囲み１２）。スマートフォン１による要求から発生した地理的位置を詳細参照スケジュール表４に対して試験する。詳細参照スケジュール表４が、要求の地理的位置と完全一致する参照位置を含む場合、参照時刻は詳細参照スケジュール表４から単純に取得できる。別様には、この地理的位置に関する参照時刻は、要求の地理的位置の直前及び直後の、詳細参照スケジュール表４内の参照位置に関連する時間を直線補間することにより計算される。また、詳細参照スケジュール４が、現在の区間に対して非常に少数のタイムスタンプ付き参照位置しか含まない又は停車駅／駅を除き全く入力を含まないことを考慮に入れる。このことは、特に、本発明の遅延決定の展開の初期段階、又は（電車の時刻表に例えば１年に２回生じる）基礎をなす時刻表を変更した後のケースであり得る。この場合、詳細参照スケジュール４は、運営者の時刻表から取得できるデータを少なくとも含み、遅延は、時刻及び地理的位置表示の直線補間を使用することにより計算される。

【0043】

詳細参照スケジュール４が出発駅Ｓｔ１（７：３０に出発）及び終着駅Ｓｔ３（０８：０１に到着）に関する参照時刻のみを含むことを仮定する一例を図６により示す。２つの駅の間の距離は、時刻表に存在するか（図４を参照）、又は以下の式：
距離（Ｓｔｌ，Ｓｔ３）＝円弧（ｃｏｓ（ｌａｔ＿Ｓｔｌ−ｌａｔ＿Ｓｔ３）ｃｏｓ（ｌｎｇ＿Ｓｔｌ）ｃｏｓ（ｌｎｇ＿Ｓｔ３）＋ｓｉｎ（ｌｎｇ＿Ｓｔｌ）ｓｉｎ（ｌｎｇ＿Ｓｔ３））
［注意：正弦・余弦式の引数はラジアンで示される。］
ｋｍ単位の距離＝距離（Ｓｔｌ，Ｓｔ３）×６３７２．７９５４７７５９８
の使用による駅の地理的位置から推定される。

【0044】

ユーザ・デバイス１から受信した位置基準要求内に示される現在の地理的位置と、次の駅又は詳細参照スケジュール４内の参照位置との間の距離も同様に計算される。次に、直線補間を以下の三の法則を使用して実施する：
Ｔｐ＝ＴＩ×Ｄｐ／ＤＩ
式中、Ｔｐは、輸送手段の直線進行を仮定する次の参照位置に到達するのに必要な時間であり、ＴＩは、輸送が以前の参照位置から次の参照位置まで移動を完了するのに必要な参照時刻であり、Ｄｐは、現在の場所と次の参照位置との間の距離であり、ＤＩは、２つの参照位置間の距離である（図６に示す特定の例示的な数字を参照）。したがって、図６の例では、要求内に示された地理的位置及び詳細参照スケジュール４に含まれるデータによる計算から得られた参照時刻である７：４２、２５秒（８：０１−１７分３５秒）において、電車Ｔｒ１は、要求内に示されるｌａｔ４３．６５度；ｌｎｇ７．１５度の参照位置に位置すべきである。

【0045】

得られたこの参照時刻と要求に関連するタイムスタンプとの差異が計算され、これが電車Ｔｒ１の要求された実時間遅延である。

【0046】

位置基準要求による遅延計算１２の一例を図７を参照して示す。図７は、詳細参照スケジュール表４によって規定される電車Ｔｒ１の参照運動曲線を示す。位置は図のＸ軸上に描かれ、時間はＹ軸上に描かれる。前述のように、この運動曲線は、例えばタイムスタンプ＋位置ペアの収集によって確立され、このタイムスタンプ＋位置ペアは、定刻通りであったまさにその関係に属する輸送手段に関連する位置基準要求内に含まれる。より多くの入力が生成され、詳細参照スケジュール４内に収集されるほど、より正確で完全な運動曲線になる。この運動曲線を使用すると、電車Ｔｒ１の参照時刻が、入力パラメータとして要求内に含まれる地理的位置により決定される。例えば、運動曲線によれば、ｌａｔ４３．６５度、ｌｎｇ７．２５度の地理的位置は、７：５２の参照時刻に対応する。次に、この参照時刻を要求に関連するタイムスタンプの実際の時刻と比較する。このタイムスタンプが８：１２を示す場合、実時間遅延は、２０分である。

【0047】

図２に戻って参照すると、位置基準遅延決定工程は、ログブック表５の更新に進む（囲み１３）。既に上記で説明したように、ログブック表５の目的は、要求と共に位置情報を提供できない乗客に実時間遅延情報を入手可能にすることである。詳細なログブック表５の一例を図８により示す。ログブック表５は、電車ＩＤ（例えばＴｒ１、Ｔｒ２）、詳細参照スケジュール表４（例えば「計画時刻」）からの参照情報、及び時刻表３（出発駅［「ｓｔＤｅｐ」］、次の到着駅［「ｓｔＡｒｒ」］、計画出発時刻［「ｐｌａｎＤｅｐ」］、及び計画到着時刻［「ｐｌａｎＡｒｒ」］）を含む。具体的には、ログブック表５は、要求及び遅延計算からの実時間情報を含み、即ち要求内に示された地理的位置（「ｌａｔ、ｌｎｇ」）、要求に関連するタイムスタンプ（「実時間」）、遅延（「遅延」）及び推定される次の駅への到着（「ｒｅａｌＡｒｒ」）を含む。

【0048】

最後に、次の到着駅等の要求された実時間遅延情報、及び実時間遅延値は、移動通信インターフェースを介してスマートフォン１に返送される（図２のステップ８）。次に、スマートフォン１にインストールされたクライアント・ソフトウェアは、情報を乗客に表示する。

【0049】

次に、図２の右側に示す時間基準遅延決定を参照すると、スマートフォン１は、ＧＰＳ信号が微弱すぎる又はＧＰＳリンクが全く利用可能ではない状況では、その現在位置を示さずに時間基準要求を生成する。したがって、時間基準要求は、タイムスタンプ（代替的にはサーバ側にだけ追加した可能性がある）及びＰＮＲ識別のみを含む。要求は、サーバ４７に送信される。ＰＮＲデータベース２及び時刻表３は、位置基準決定に関して前に述べたように電車ＩＤを判断するために調べられる。このように電車ＩＤを判断した後、ログブック表５に電車ＩＤを使用して問い合わせて、以前の位置基準遅延決定により生成した、存在する可能性のある実時間遅延情報をシークするようにする。例えば、ログブック表５が乗客の電車の現在の区間に対する入力を含むことが判断された場合、その入力に関連する遅延が選ばれる。

【0050】

図８の例では、電車Ｔｒ１は、駅Ｓｔ２とＳｔ３との間の第２の区間上にあると仮定される。時刻表によれば、電車Ｔｒ１は、駅Ｓｔ２を７：４０に出発し、Ｓｔ３に８：０１に到着したはずである（図４及び図５も参照）。その移動の途中で、２つの位置基準要求が生じ、処理され、計算した実時間遅延は、ログブック表５内に保存されている。Ｔｒ１がＳｔ１とＳｔとの間のその第１の区間に依然としてある間に第１の位置基準要求が７：４６で生じた。１０分の遅延が検出された。後に、Ｔｒ１がＳｔ２とＳｔ３との間の第２の区間に進行したとき、８：１２で別の位置基準要求を受信し、２０分の更に増大した遅延が決定された。ここで、８：１５で時間基準要求をサーバ４７が受信したと仮定すると、ログブック５が調べられ、わずか３分前の電車Ｔｒ１の現在の区間に関する８：１２の入力が発見される。この入力の遅延値、即ち２０分の遅延が決定される（図２の囲み７）。次に、遅延及び例えば次の到着駅Ｓｔ３は、乗客に情報を表示するスマートフォン１に返送される。

【0051】

以下では、上記で既に概説したキャッシュ化機能を含む位置基準決定及び時間基準遅延決定の実装例を図９ａ、図９ｂ及び図９ｃの流れ図を参照してより詳細に説明する。図９ａは、遅延決定に関する要求が発行されるまでのユーザ・デバイス１で進行する工程を示す。図９ｂは、サーバ４７における要求の処理を示す。最後に、図９ｃは、遅延決定結果がサーバ４７により返送された後のユーザ・デバイス１側での動作を再度可視化する。

【0052】

一般に、関連するデータ・フローは、以下の条件に従って分類できる：
（ｉ）位置決定機能及び移動通信リンクの両方がユーザ・デバイス１で利用可能である。
（ｉｉ）位置決定機能が利用可能である。しかし、移動通信リンクは利用可能ではない。
（ｉｉｉ）位置決定機能を実装しないか又は一時的に利用不可能である。しかし、移動通信リンクは、利用可能である。
（ｉｖ）位置決定機能も、移動通信リンクも利用可能ではない。

【0053】

（ｉ）（位置決定機能及び移動通信リンクが利用可能である）の場合のデータ・フローは、以下の通りである。

【0054】

１９で開始した後、工程は、ユーザ・デバイス１内に存在するか又はユーザが手入力したＰＮＲ識別の検証チェック２０を始める。次に、２１で移動通信リンクの利用可能性をＹｅｓと確認した後、２９でユーザ・デバイス１はキャッシュを検証する。キャッシュが空である場合、移動通信リンクを利用し、ＰＮＲ識別により参照した輸送手段に関する詳細参照スケジュール・データ及び現在の遅延情報をダウンロードするようにする。この目的で、３０でキャッシュ更新メッセージがサーバ４７に送信される。キャッシュ更新メッセージに応答して、サーバ４７は、そのデータベース（即ちＰＮＲデータベース２、時刻表３、詳細参照スケジュール４及びログブック５）に問い合わせ、対応するデータをユーザ・デバイス１に返送する。ユーザ・デバイス１は、これらのデータをそのキャッシュに保存する。すると、キャッシュは、例えば現在の輸送手段に関する時刻表データ、具体的には、次の到着駅、現在の輸送手段の詳細参照スケジュール・データ、及びログブック５内で入手可能な現在の輸送手段の最近の電車遅延情報を含む。これらの情報は、位置決定機能及び／又は移動通信リンクがない場合の現在の輸送手段の実時間遅延の計算又は推定には十分である。

【0055】

更に、２７でユーザ・デバイス１はＧＰＳ信号が利用可能かどうかを確認しＹｅｓの結果がもたらされる。次に、２８でユーザ・デバイス１は位置基準要求を生成し、これをサーバ４７に送信する。サーバ側（図９ｂ）では、３１でサーバ４７は乗客が現在使用している輸送手段に関連する時刻表３が既に利用可能かどうかを確認する。そうでない場合には、３２で輸送手段の運営者によるそれぞれの時刻表情報を抽出できる。これらのデータをできるだけ迅速に含めることができるように、サーバ４７は、適切には運営者及び運営者の時刻表データベースへの通信リンクを有する。

【0056】

３３でユーザ・デバイス１が受信した要求が地理的位置を含むことをＹｅｓと決定した後、サーバ４７は、要求内に含まれる地理的位置の検証を任意選択で実施する（図９ｂには示さない）。この検証機能は、要求内に含まれた地理的位置がＰＮＲにより示される電車の経路と一致することを保証することである。この検証を実施するために、電車経路のその地理的位置に関する記述は、サーバ４７が利用可能である。次に、要求内に示された地理的位置は、経路の地理的位置参照情報と比較される。要求の地理的位置が「経路範囲内」であると判断された場合、即ち要求の地理的位置が経路上の場所に一致する、又はその場所に少なくともほぼ一致する場合、要求の地理的位置は有効であるとみなされる。経路の地理的位置参照情報は、輸送手段の運営者、外部の地図サービスから入手でき、サーバ４７のオペレータにより推定でき、及び／又は受信した相当数の位置基準要求によって収集しこれらから演繹できる。更に、経路上又は経路に近いが電車の実位置から実質的に離れている地理的位置を示す要求（例えば次の駅で既に待機している将来の乗客又は前の駅で既に電車を離れた以前の乗客によって生成された要求）は、要求の地理的位置やタイムスタンプ・ペアと詳細参照スケジュール４及び／又はログブック５内に既に含まれている情報とを適合させることによって除外できる。例えば、電車が既に通り過ぎた地理的位置を示す要求は、ログブック５が経路を既に遠くに離れている地理的位置に関する入力を含む場合除外できる（そのような古くなった要求は、ログブック５に基づいて依然として処理でき、例えばログブック５内に含まれる最新の実時間遅延を返送できる）。別の例として、ログブック５の入力を考慮することにより電車がまだ到着するはずがない将来の地理的位置を示す要求も除外できる（同様に、そのような要求への応答時、最新の実時間遅延情報をやはり返送できる）。概して、要求により示された地理的位置を電車の現在位置に関連しないように判断する場合、そのような要求は、時間基準要求と同様に処理される。即ち、地理的位置は存在ないとみなされ、実時間情報はログブック５を利用して返送できる。

【0057】

この任意選択の検証ステップに続いて、サーバ４７は、位置基準遅延決定を実行する（図９ｂの右手側に示す）。図２を参照して既に上記で詳細に説明したように、この方法は：
−４１で、ユーザ・デバイスの要求内に含まれる地理的位置を使用して時刻表３に問い合わせることによって現在の区間を決定すること；
−４２で、区間及び地理的位置を有する詳細参照スケジュール４に問い合わせ、適用可能な場合は、詳細参照スケジュール４内に保持されるタイムスタンプ付き参照位置を補間すること；
−４３で実時間遅延を計算し、４４で次の駅への対応する推定到着時刻を計算すること；並びに
−４５で、少なくともタイムスタンプ（「実時間」）、計算した実時間遅延（「遅延」）及び次の駅（「ｓｔＡｒｒ」）への推定実到着時刻（「ｒｅａｌＡｒｒ」）を有するログブック５を更新すること
を含む。

【0058】

次に、４０でサーバ４７は次の到着駅、推定実到着時刻及び計算した実時間遅延等、得られた実時間遅延情報をユーザ・デバイス１に返送する。移動通信リンクを介してそれぞれのメッセージを受信した後（図９ｃ）、４６でユーザ・デバイス１はこうした情報で、ユーザ・デバイス１自体のキャッシュを更新し、その情報をグラフィカル・ユーザ・インターフェースを介してユーザに提示する。４８で工程は終了する。

【0059】

（ｉｉ）（位置決定機能は利用可能−移動通信リンクは利用不可能）の場合のデータ・フローは、以下の通りである。

【0060】

移動通信リンクが利用できないことが既に２１の初めで決定された場合、２２でユーザ・デバイス１はユーザにより示された輸送手段に関連するキャッシュ化情報が利用可能かどうかを確認する。これがＹｅｓである場合、２３で遅延決定はユーザ・デバイス１でローカルに可能である。キャッシュ化データがユーザの輸送手段に関する詳細参照スケジュール・データを含むという条件で、位置基準要求を生成し、ユーザ・デバイス１によって内部で、移動通信リンクが利用可能であった場合にサーバ４７によって処理したのと同様に処理する。基本的な唯一の差異は、４５でサーバが実施したであろうログブック５の更新が移動通信リンクなしではユーザ・デバイス１には不可能であることである。したがって、ユーザ・デバイス１は、関連データをローカル・ログブック内にバッファリングし、後で再度移動通信リンクが利用可能になったときにサーバ側ログブック５を更新する（この動作は図９ａには示さない）。ユーザ・デバイス１がローカルに計算した遅延情報をユーザに提示し、２４で工程は終了する。

【0061】

（ｉｉｉ）（移動通信リンクは利用可能、位置決定機能は利用不可能）の場合のデータ・フローは、以下の通りである。

【0062】

この場合、時間基準遅延決定が実施される。この工程は、データ・フロー・ケース（ｉ）を参照して上記で説明したように、ステップ１９から２１、２９及び３０を伴ってユーザ・デバイス１で再度開始される。２７でユーザ・デバイス１はＧＰＳ信号が利用可能ではないことを決定する。次に、２５で移動通信リンクの存在を再検証する。

【0063】

例え移動通信リンクがその間はなかったとしても、一般に、この場合遅延決定はステップ２２及び２３でローカルに可能である。というのは、キャッシュがステップ２９及び３０で以前に更新されており、必要な参照データ及びログブック・データはキャッシュ内にローカルに存在するはずであるからである。現在のシナリオでは、現在位置がユーザ・デバイス１にとって未知であるので、ローカルの遅延決定は、ログブック・データが入手可能であるという条件で（図９ｂを参照して次に説明するように）サーバ４７が実施したような時間基準遅延決定に対応する。或いは、（例えば事前に、輸送手段の現在の移動に関する位置基準要求が何もなかったので）ログブック・データがキャッシュ化されない場合、時刻表３内に含まれる少なくとも参照データをユーザに表示できる。この分岐では、次に、２４で工程は終了する。

【0064】

２５で再検証により移動通信リンクが依然として存在又は利用可能であることを確認した場合、２６でユーザ・デバイス１は時間基準要求を生成する。要求は、ＰＮＲ識別及び現在時刻のタイムスタンプを含む（上述したように、タイムスタンプはサーバ４７が要求を受信したときにサーバ４７によって後で追加するだけであることも可能である）。サーバ側では（今度は再度図９ｂを参照して）、ステップ３１及び３２を前に説明したように実行する。３３での決定は要求が地理的位置を含まないこと、即ち要求が時間基準要求であることを示す。したがって、サーバ４７は、図９ｂの左手に視覚化した時間基準遅延決定を実施する。

【0065】

３４で、サーバ４７はＰＮＲ識別により示された輸送手段がログブック５内に存在するかどうかを確認する。そうでない場合には、ステップ３５及び３７で、サーバは時刻表情報を少なくとも抽出しようとし、３９で例えば次の到着駅及び予定到着をユーザ・デバイス１に返送する。このことは予定到着時刻にすぎず、実到着時刻ではないことを強調する警告又は注意を含めることが可能である。時刻表３内に含まれる予定到着情報が何らかの理由でアクセス可能ではない場合であっても、３８でエラー・メッセージがユーザ・デバイス１に返送されることになる。

【0066】

３４のテストによりユーザの現在の輸送手段に関する実時間遅延情報がログブック５内で入手可能であることが判明した場合、３６で時間基準遅延計算が実施される。輸送手段の現在の区間に関係するログブック５内の入力は、制約条件、実時間≦タイムスタンプ≦ｒｅａｌＡｒｒを適用することによって抽出される。パラメータ「実時間」及び「ｒｅａｌＡｒｒ」は、ログブック入力の一部である（図８を参照）。「実時間」値は、ログブック５の入力に誘導された以前の位置基準要求のタイムスタンプに対応する。「ｒｅａｌＡｒｒ」値は、以前の実時間遅延決定により推定された、次の駅の実到着を指す。したがって、現在の時間基準要求に関連するタイムスタンプの値以下である「実時間」値を有するログブック入力は、以前の遅延決定の結果を含む。現在の時間基準要求に関連するタイムスタンプ値以上である「ｒｅａｌＡｒｒ」の値を有するログブック入力は、おそらく、ユーザの輸送手段が位置する現在の区間を指す。しかし、「ｒｅａｌＡｒｒ」が要求のタイムスタンプよりも小さい場合、それぞれの入力が以前の区間を指し、輸送手段が既に次の到着駅に到着していることを想定できる。このことは、この入力が示した遅延がもはや最新ではないことの指摘である可能性がある。

【0067】

実時間遅延の計算方法は、ログブック入力回数及びそれらの時間値によって異なる。例えば、ログブック５が輸送手段の現在の区間に言及する１回の入力を含む場合、そのログブック入力の次の到着駅（「ｓｔＡｒｒ」）、推定到着時刻（「ｒｅａｌＡｒｒ」）及び遅延値（「遅延」）は、３６で抽出され、４０でユーザ・デバイス１に返送される。一方、ログブック入力のいずれもが上記の条件（即ち実時間≦タイムスタンプ≦ｒｅａｌＡｒｒ）を満たさない場合、３８でエラー・メッセージのみを返送できる。代替的に、少なくとも予定される情報（次の到着駅、予定到着）は、時刻表３から抽出でき、ユーザ・デバイス１に返送できる。しかし、ログブック５が以前の区間のみに関連するいくつかの入力を含む場合（即ちタイムスタンプ≧ｒｅａｌＡｒｒ）、こうしたより古い入力の遅延値に対して補外を実施でき、得られた遅延値を大まかな推定として返送できる。この場合、やはり、遅延情報が不正確であり得るという警告又は注意を追加する可能性がある。最後に、工程はユーザ・デバイス１に戻る（図９ｃ）。実現可能な場合（即ち実時間遅延情報がサーバ４７により提供された場合）、４６でユーザ・デバイス１はそのキャッシュを更新し、４８で工程は終了する。

【0068】

最後に、（ｉｖ）（位置決定も移動通信リンクも利用可能ではない）の場合のデータ・フローは、以下の通りである。

【0069】

２１でユーザ・デバイス１が移動通信リンクを利用できないことを既に最初に決定した場合、ローカルの時間基準決定は、ログブック・データが以前にキャッシュ化されている場合又は少なくとも時刻表データをユーザに提示できる場合に可能とすることができる。この場合、ケース（ｉｉ）を参照して上記で示したステップ２２及び２３の説明に言及できる。ログブック及び／又は時刻表データがキャッシュ内で利用可能ではない、したがって２２での確認がＮｏである場合、２４で工程は終了する。

【0070】

しかし、移動通信リンクが２１で利用可能である場合、２９及び３０でキャッシュが更新される。次に、移動通信リンクがその後解除され、２５で通信リンクのないことが決定された場合、２２及び２３で時間基準遅延決定が可能であるはずである。このことは、ケース（ｉｉｉ）を参照して詳細に説明したサーバによる時間基準遅延決定と同様である。この場合、同様に２４で工程は終了する。

【0071】

図１０は、本発明の遅延決定システムの可能な構成の高レベル概観を示す。この例では、ユーザ・デバイス１は、ＧＰＳ送受信器５０の形態の位置決定機能を含む。キャッシュ化機能を実装するために、ユーザ・デバイス・メモリ（揮発性ＲＡＭ又はフラッシュ・メモリ等の不揮発性メモリのいずれか）の特定部分をキャッシュ５３として利用する。本発明の遅延決定のクライアント関連機能は、遅延決定移動体アプリケーション５１によって実装される。ユーザ／乗客とのコミュニケーションは、タッチ・スクリーン等のグラフィカル・ユーザ・インターフェースを介して可能である。グラフィカル・ユーザ・インターフェースは、とりわけユーザがＰＮＲ番号等自分の旅程情報又は輸送手段関係情報を入力し、実時間遅延情報を表示させるために使用される。

【0072】

一方、サーバ側４７は、ウェブ・サービスをユーザ・デバイス１に提供する。サーバ側４７は、基礎をなすデータ、具体的には時刻表３、詳細参照スケジュール４及びログブック５を維持するインフラストラクチャを備える。電車の実時間遅延計算を対象とする例では、サーバ側インフラストラクチャは、レール・ディストリビューション・プラットフォーム５４（ＲＤＰ）、レールＩＴサーバ５５及びデータベース５６を備える。

【0073】

図１１及び図１２は、例示的スマートフォン１のグラフィカル・ユーザ・インターフェースの一例を視覚化しており、スマートフォン１により、スマートフォン１上にインストールしたソフトウェアが、決定した実時間遅延情報をユーザに表示する。図１１により示すメイン画面は、輸送手段の識別情報（「インターシティ１２３４５」）、次の計画停車駅（「ピサ」）、この次の駅に関連する予定される情報（「予定到着２０１１年１０月１９日、２０：１０」）、その駅への推定実到着（「実到着２０１１年１０月１９日、２０：１５」）及び遅延（「遅延：５分」）を示す。更にその下に、輸送手段の実位置及び特定の主要停車駅（「ナポリ」、「ローマ」、「トリノ」）が示される。輸送手段が定刻通りであった駅は、例えば緑色の背景色によって特に強調される。輸送手段が遅延した、又はおそらくは遅延する駅は、例えば赤色の背景色によって異なる様式で強調できる。例えば「スケジュール詳細」と表示されたボタンは、表形式概観の主要駅に関する予定到着／出発時刻及び計算した到着／出発時刻（図１２により示す）にユーザを誘導する。追加又は代替として、予定到着／出発時刻及び計算した到着／出発時刻と共に区間の完全なリスト及び次の到着駅が提示される。

【0074】

最後に、図１３は、ユーザ・デバイス１の内部構造の模式図である。ユーザ・デバイス１は、本明細書で論じた方法のうちいずれかをユーザ・デバイス１に実施させる１組の命令を実行するように構成される。移動通信デバイスは、プロセッサ１２１、メイン・メモリ１２２及びワイヤレス・ネットワーク・インターフェース１２３（Ｗｉ−Ｆｉ及び／又はＢｌｕｅｔｏｏｔｈインターフェース等）並びに／又は２Ｇ／３Ｇ／４Ｇ移動ネットワーク・インターフェース・デバイス（図示せず）を含み、これらは全てバス１２４を介して互いに通信する。移動通信デバイスは、スタティック・メモリ１２５、例えば取り外しができないフラッシュ・ドライブ若しくはソリッド・ステート・ドライブ、又は取り外し可能Ｍｉｃｒｏ ＳＤカード若しくはＭｉｎｉ ＳＤカードを更に含み、これら取り外し可能Ｍｉｃｒｏ ＳＤカード若しくはＭｉｎｉ ＳＤカードは、ユーザ・デバイス１がローカル遅延決定機能を実行可能にしサーバ側インフラストラクチャ４７と通信可能にするソフトウェアを永続的に保存する。更に、移動通信デバイスは、ディスプレイ１２７、好ましくはタッチ・スクリーン、ユーザ・インターフェース（タッチ・スクリーン）制御モジュール１２９及び任意選択で追加の（非仮想）英数字・カーソル入力デバイス１２８（そのような入力デバイスが存在する場合）を含む。ワイヤレス・ネットワーク・インターフェース・デバイス１２３は、ユーザ・デバイス１をサーバ側インフラストラクチャ４７に接続する。任意選択のＧＰＳ送受信器１２６は、位置決定を可能にする。上記した方法のいずれか１つ又は全てを具現化する１組の命令（即ちソフトウェア）１３０は、完全に又は少なくとも部分的にスタティック・メモリ１２５中に常駐する。それぞれの命令及び／又はデータは、実行時メイン・メモリ１２２及び／又はプロセッサ１２１内に常駐する。ソフトウェア１３０は、伝播信号１３２として、ワイヤレス・ネットワーク・インターフェース・デバイス１２３又は２Ｇ／３Ｇ／４Ｇ移動ネットワーク・インターフェースを介して或いはインターネットを介して図１０により示したサーバ側インフラストラクチャ内のサーバに更に送信／サーバから受信できる。

【0075】

サーバ側インフラストラクチャ４７は、これらの構成要素の一部又は全部がワイヤレス・ネットワーク・インターフェース及びＧＰＳモジュールのいずれももたない場合があることを除いて同様に構築される。

【0076】

本発明の教示に従って構築される特定の製品及び方法を本明細書で説明してきたが、本特許が包含する範囲は、それらに限定されるものではない。反対に、本特許は、文字通り又は等価物の原理下、添付の特許請求の範囲内に適正に入る本発明の教示の全ての実施形態を包含する。

【符号の説明】

【0077】

１ ユーザ・デバイス
３ 時刻表
４ 詳細参照スケジュール
５ ログブック
１２１ プロセッサ
１２２ メイン・メモリ
１２３ ワイヤレス・ネットワーク・インターフェース

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9a】

【図9b】

【図9c】

【図10】

【図11】

【図12】

【図13】