JP4951188B2

JP4951188B2 - トラフィック又は関連情報提供方法およびシステム

Info

Publication number: JP4951188B2
Application number: JP2002505591A
Authority: JP
Inventors: トレイフォード，ロス; カール，チャールス; バンレアーサム，ジュリアン
Original assignee: Stratech Systems Pte Ltd
Current assignee: Stratech Systems Pte Ltd
Priority date: 2000-06-26
Filing date: 2001-06-26
Publication date: 2012-06-13
Anticipated expiration: 2021-06-26
Also published as: EP1316079A4; CN1449551A; ATE383635T1; US6882930B2; CA2414531A1; NO20026257D0; WO2002001532A1; DE60132340T2; NZ523742A; KR20030022161A; EP1316079B1; EP1316079A1; US20040038671A1; JP2004501474A; KR100823210B1; HK1055830A1; MXPA03000171A; NO20026257L; DE60132340D1

Description

【０００１】
【発明の属する技術分野】
本発明はトラベラ（旅行者）情報サービスに関し、特に予報トラフィック（交通）情報を個別トラベラ（旅行者）に提供するシステムに関する。
【０００２】
【従来の技術】
トラフィック状態を監視且つ報告することは、トラフィックフロー（交通の流れ）の管理において大変重要な要因である。モータリスト（運転者又は旅行者）の観点からも、それは通勤時間の節約および不必要な遅延を避けるために必須である。モータリスト又はその他のユーザがトラフィックおよび関連情報にタイムリにアクセス可能にする施設の提供に相当の努力がなされてきた。
【０００３】
周知のトラフィック情報の１つのタイプは、「スポッタ」の使用であり、即ちトラフィックインシデント（道路工事、閉鎖、事故等の出来事）をラジオ局又は中央コントローラ（管制局）にレポートして、その後にそれを一般大衆に広める指定された人又は一般のメンバーである。しかし、斯かるシステムは、今日のユーザの要求に十分応えることができない。
【０００４】
より進んだ従来システムは、道路の傍にカメラ等の複数のセンサを配置し、それを中央設備に連結してトラフィック情報を広める。センサは、フリーウエイおよび主要道路への出口／入口等に戦略的に配置される。他のシステムは、センサ付き携帯／移動電話又は主要道路およびフリーウエイに配置された指定スポッタである。これらシステムは、中央制御施設と統合され、トラフィックフロー、事故、迂回路、道路工事その他の情報を携帯電話ネットワークの利用者に提供する。また、利用者はダイヤルインしてフリーウエイ等のトラフィックネットワーク（以下「道路網」と記す。）の特定アスペクト（事項）に関する瞬間情報の検索を行う機会を有する。
【０００５】
【発明が解決しようとする課題】
しかしながら、上述した従来システムは、サブスクライバ（予約購入者）への有用な情報提供能力が制限されている。それらは一般に、問題の持続の手がかりを与えるかも知れない更新された／事故レポートにより補足された最新トラフィック状態の提供に制限されている。これは、現在混雑している場所を通ってトラベルに出かけようとしているとき、近い将来に状態がどのように推移するかに関する情報を必要とするモータリストのニードを満足させることはできない。更に、これらのシステムは、代替ルートがあるか否かおよび／又はこれら代替ルートの詳細について示すことができない。
【０００６】
即ち、従来システムの顕著な欠点は、個別のサブスクライバにカスタマイズされ且つ厳密な時間を有する情報を提供することができないことである。
【０００７】
従って、各モータリストに対してタイムリおよびカスタマイズされたトラフィック情報を報告するシステムを提供するのが好ましい。更に、ネットワークの各サブスクライバに対して各サブスクライバに関する予報トラフィック情報を提供するのが好ましい。
【０００８】
【課題を解決するための手段】
本発明は、道路網の１以上の交差点に関する履歴トラフィックデータを蓄積し、且つ実質的に前記１以上の交差点に関するリアルタイムトラフィックデータ及び関連トラフィックデータを受信するよう動作するデータベースと、前記データベースに蓄積されるサブスクライバのプロファイルに関する前記履歴及びリアルタイムトラフィック及び関連トラフィックデータを決定論的に統合し、カスタマイズされた予報トラフィック情報を生成する統合生成手段と、該カスタマイズされた予報トラフィック情報をサブスクライバに送信する手段とを備え、前記カスタマイズされた予報トラフィック情報は、前記サブスクライバのプロファイルに記載された１つのトラベルルート用のトラベル遅延予測よりなり、前記トラベルルートの特定の交差点に関して履歴トラフィックデータ又はリアルタイムトラフィックデータが不十分な場合に、前記統合生成手段は、前記トラベルルートのトラベル遅延予測を提供するために、マッチング要因に基づいてマッチングした交差点を決定し、前記マッチングした交差点から利用可能な履歴トラフィックデータ又はリアルタイムトラフィックデータを使用するように動作することを特徴とするトラフィック又は関連情報を提供するシステムを提供する。
【０００９】
好適実施形態では、カストマイズされた予報トラフィック情報は、トラベラ情報をユーザへ配布する情報配布者に送信され、ユーザは、トラベル要求に関するトラフィック情報を受け取る目的で情報配布者からサブスクライブ（予約購入）する。この場合に、サブスクライバは、カストマイズされた情報を受信するためにリモートターミナルを有するのが好ましい。このシステムおよびターミナルは、サブスクライバからシステムへの通信を提供することが可能である。
【００１０】
履歴およびリアルタイムトラフィックデータは、主として道路網の戦略的な位置に設けられたトラフィックコントロール（交通管制）信号、トラフィックセンサおよび検出器よりなるのが好ましい。データベースは、履歴およびリアルタイムトラフィックデータおよび／又は関連データを蓄積して頻繁に検索可能に動作する。データベースに蓄積された履歴トラフィックデータは、サブスクライバに関心のある地理的エリアに関する前のトラフィックデータのサンプルを含むのが好ましい。斯かるデータは、交通渋滞エリア、特定のランドマークにおけるトラフィックフローおよび特定ルートに沿う速度等の戦略的に重要な位置のデータを含んでもよい。関連するデータは、温度や降雨を測定および報告するセンサ等の他のセンサから集めたデータを含み、更に道路網のフローにインパクトを与える特定イベント（例えば休日）に関するデータを含んでもよい。
【００１１】
データベースに蓄積された関連トラフィックデータは、好ましくは事件、事故、道路工事、代替（迂回）ルートおよび天気情報等を含んでいる。関連データは、任意の印刷、電子又はラジオ通信から取得し、これらをデータベースに蓄積のためのデータに変換し、その後にシステムに使用される。
【００１２】
履歴、リアルタイムおよび関連トラフィックデータの統合手段は、モデリングを含み、履歴レコードに基づく特定リンクの推定遅延の表示を提供する。ベースデータの参照に比較して、モデリングを使用すると、ストレージの要件を低減させ、計算時間を短縮するので、タイムリな結果の提供が可能である。
【００１３】
本発明によるシステムを提供することにより、サブスクライバ者は、トラベルの前又はトラベル中に自己のトラベルルートに関するトラフィック又は関連情報の受け取りが可能になる。このシステムは、サブスクライバに習慣になっているトラベルパターン関して予報した更新されたおよび関連する時間の情報を提供する。
【００１４】
本願出願人は、「スペースタイムウインドウ」があることを認識した。即ち、モータリストは、個人的な、カストマイズされた、そして局地的なトラベル情報を必要とし且つこの「スペースタイムウインドウ」期間の前後に受けた情報は、トラベラに利用が制限される。
【００１５】
勿論、このシステムは、サブスクライバに関する情報のデータベースも含み且つカストマイズされた予報トラフィック情報をサブスクライバに直接供給してもよい。
【００１６】
本発明の好適実施形態において、トラフィックおよび関連情報をサブスクライバのターミナルに提供するシステムであって、サブスクライバデータベースと、少なくともテキストメッセージの受信が可能なネットワークの複数のサブスクライバターミナルと、実質的にリアルタイムのトラフィックデータおよび関連データを受信するように動作する履歴トラフィックデータを蓄積するデータベースと、サブスクライバデータベースに蓄積されたサブスクライバプロファイルに関する履歴データおよびリアルタイムデータを統合して、各サブスクライバのカストマイズされた予報トラフィック情報を得る手段と、このカストマイズされた予報トラフィック情報をネットワークの各サブスクライバターミナルへ、各サブスクライバのクリティカル時間に送信する手段とを含み、カストマイズされた予報トラフィック情報は、サブスクライバのトラベルプロファイルに記載されたトラベルルートの推定トラベル遅延を含むことを特徴とする。
【００１７】
本発明の好適実施形態によると、サブスクライバは、モータリストであり且つネットワークは、携帯又は移動通信ネットワークである。このネットワークは、ショートメッセージサービス（ＳＭＳ）、ワイヤレスアプリケーションプロトコル（ＷＡＰ）又は第３世代（３Ｇ）ワイヤレスブロードバンドネットワークである。
【００１８】
サブスクライバデータベースは、好ましくはサブスクライバの識別関連情報を含む各サブスクライバプロファイルを不揮発性メモリに個別サブスクライバプロファイルを蓄積するのが好ましい。また、プロファイルは、ユーザの通常トラベル時間、通常取られるルートおよびサブスクライバがカストマイズされた予報トラフィック情報の受信を希望する時間等のパラメータを含んでいてもよい。これらの時間は、個別サブスクライバにとりクリティカルであると考えられる。サブスクライバは、データベースへのアクセスが与えられ、自己のプロファイルのパラメータの変更を可能にする。このアクセスは、専用のＷｅｂサイトを介して提供してもよい。
【００１９】
サブスクライバターミナルは、トラフィック情報および／又はその他関連情報を受信可能な移動通信装置を含んでいてもよい。この装置は、移動通信ネットワークの一部を形成する移動電話でもよく且つＳＭＳ、ＷＡＰ又は３Ｇフォーマットを受信するようにしてもよい。更に、この装置は、音声テキスト又はＩＶＲ技術を組み込んでもよい。
【００２０】
好ましくは、この装置は履歴又はリアルタイムトラフィック情報に関するデータベースから情報を要求可能にする。
【００２１】
履歴およびリアルタイムデータを統合する手段は、履歴データに基づき各種のトラフィックリンクの予想遅延モデルを含んでもよい。この場合には、モデルは、予報トラフィック情報のためのアダプティブマセマティカル（適応数学）モデリングを含んでいるのが好ましい。また、このモデリングは、サブスクライバのトラベルルートに従うリアルタイムデータと履歴データ変数と比較可能である。統計技法を適応して、データ変数を決定し且つマルチバリエート回帰、マルチバリエート時系列、スペクトル解析ピースワイズデイリーテンプレート等又はこれらの組み合わせを含んでもよい。トラフィック密度による予想遅延に加えて、事故が履歴的に予想した遅延を大幅に増加することがある。サブスクライバへの予報遅延に大幅に影響を与える事故の発生は、サブスクライバの大幅なルート変更の前にこのサブスクライバへ送信し、これによりサブスクライバが幾つかの代替ルートの選択を行い、サブスクライバの予想とラベル時間が増加するのを回避する試みを可能にする。
【００２２】
特に好適実施形態では、システムは、トラベルネットワークを介してトラベルの最適パスを決定する手段を含んでいる。このネットワークを介してトラベルの最適パスを決定する手段は、道路網の各個別トラベルリンクのトラフィックフローの方向を考慮する方法を採用してもよい。更に、この方法は、信号制御された交差点を通る個別トラフィックフローに対する交通信号による遅延の差を考慮するのが好ましい。
【００２３】
特定道路網又はその一部において利用可能な履歴トラフィックデータが制限されている場合もある。更に、リアルタイムトラフィック信号データは、トラベル時間を予想する目的に十分に関係する頻度で、利用可能な道路網の信号制御交差点の数が制限されるかも知れない。この場合には、道路網を介する最適トラベルパスの決定手段は、制限された数の信号制御交差点から受けたデータで、タイムリなトラフィック信号データが得られない道路網の残りの交差点をマッチングする方法を実施するのが好ましい。
【００２４】
同様に、利用可能なトラフィックデータが制限されている又はトラフィックデータが全くない道路網で使用されることを意図するシステムの場合には、システムは、トラベルフロー推定を決定する手段を含み、この手段は、トラフィックデータが制限された道路網に既知データの道路網からの信号制御交差点をマッチングさせる方法を実施する。これにより、システムが少なくとも第１推定を確立し、時間の経過と共にそのネットワークの多くのトラフィックデータが利用可能になるに連れて、その推定精度に磨きがかけられる。
【００２５】
好適実施形態では、道路網全体のトラフィック制御交差点からのデータのマッチングは、交差点の形状、交差点の向きおよび特定トラフィック信号の結果に基づくその同じ信号により可能な最大流れに対する実際のトラフィックフローの割合等の各種要因を考慮する。この最後の要因は、「飽和度（ＤＯＳ）」と称される。勿論、道路網全体の交差点のマッチングには、交差点の１日当たりの信号サイクル時間の履歴平均値等の付加要因を含んでもよい。交差点間のマッチングを決定するために使用される各種要因には、優先度又は重み付けを行い、各要因の重要度の順序を確立する。これら個別要因の順序又は重み付けは、他の市における他の道路網等の既知のデータで交差点のマッチングを行うとき変化するかも知れない。更に、個別要因の順序又は重み付けは、道路網の１つの地域と他の地域とでは変化するかも知れない。
【００２６】
カストマイズされたトラフィック情報を定期的に送信する手段は、少なくともテキストメッセージの送信が可能な少なくとも１個のデータベースを含んでいてもよい。このカストマイズされたトラフィック情報は、好ましくは、サブスクライバの移動ネットワークへ送信される。生成され且つ送り出される情報の頻度および時間は、サブスクライバのトラベルプロファイルにより決定してもよい。この情報は、サブスクライバのトラベルルートの前および／又は途中で送信してもよい。
【００２７】
別の形態では、予報情報は、サブスクライバの場所に応じてカストマイズしてもよい。サブスクライバの場所又は位置は、全地球測位システム（ＧＰＳ）、移動測位システム（ＭＰＳ）その他の手段により決定される。
【００２８】
他のアスペクトによると、本発明は、ａ）履歴、及びリアルタイムトラフィックデータ、及び関連データをデータベースに蓄積する工程と、ｂ）前記データベースに記憶されたサブスクライバのプロファイルに関する前記履歴、及びリアルタイムトラフィックデータ、及び関連データを決定論的に統合して、カスタマイズされた予報トラフィック情報を生成する統合生成工程と、ｃ）該カスタマイズされた予報トラフィック情報をサブスクライバへ送信する工程とを備え、前記カスタマイズされた予報トラフィック情報は、前記サブスクライバのプロファイルに記載されたトラベルルートのトラベル遅延予測よりなり、前記トラベルルートの交差点に関する履歴又はリアルタイムトラフィックデータが不十分な場合には、前記統合生成工程は、マッチングする要因に基づいてマッチングした交差点を決定し、前記マッチングした交差点から利用可能な履歴又はリアルタイムトラフィックデータを使用してトラベル遅延予測を提供することを特徴とするトラフィック又は関連情報を提供する方法を提供する。
【００２９】
１つの実施形態では、本発明は、トラフィック又は関連情報を提供する方法であって、（ａ）履歴、リアルタイム及び関連トラフィックデータをデータベースに蓄積する工程、（ｂ）サブスクライバのプロファイルに関する履歴、リアルタイム及び関連データを統合してこれらサブスクライバのプロファイルに関するカストマイズされたトラフィック情報を得る工程及び（ｃ）このカストマイズされたトラフィック情報をネットワーク中で少なくともテキストメッセージを、サブスクライバにクリティカルな時間に受信可能なサブスクライバのターミナルに送信する工程とを含み、カストマイズされた予報トラフィック情報は、サブスクライバプロファイルに記載されたトラベルルートの予想トラベル遅延を含むことを特徴とする。
【００３０】
特に好適実施形態では、この方法は、好ましくはネットワークの各個別トラベルリンクのトラフィックフローの方向を考慮してトラベルネットワークを介するトラベルの最適パスを決定する工程を含んでいる。更に、この方法は、信号制御交差点を通る個別トラフィックフローの交通信号により生じる遅延差を考慮するのが好ましい。
【００３１】
特定の道路網又はその一部では、利用可能な履歴データが制限されている場合がある。更に、リアルタイムトラフィック信号データは、道路網の信号制御交差点の数が、トラベル時間を予測する目的に関し、十分な頻度ではない程度に制限される場合もある。この場合には、道路網を通る最適パスの決定手段は、制限された数の信号制御交差点から得たデータをもって、タイムリなトラフィック信号データが得られない道路網の残りの交差点とマッチングする方法を実施するのが好ましい。
【００３２】
同様に、利用可能なトラフィックデータが制限されるか又は全くトラフィックデータが利用できない道路網で使用を意図する方法の場合には、この方法が既知のデータの道路網から、制限されたトラフィックデータのネットワークにマッチングする工程を含んでもよい。
【００３３】
好適実施形態では、道路網全体の交通制御交差点からのデータのマッチングの方法は、交差点の幾何学形状、交差点の向きおよび同じ信号（即ちＤＯＳ）に可能な最大トラフィックフローに対する特定トラフィック信号の結果による実際のトラフィックフローの割合を含む各種要因を考慮する。勿論、道路網全体の交差点のマッチング方法は、交差点の１日当たりの信号サイクルタイムの履歴平均等の付加要因を含んでもよい。交差点間でマッチングを決定するために使用される各種要因には、各要因の重要度を確立するために、優先度又は重み付けが与えられてもよい。これら個別要因の順序又は重み付けは、既知データを有する交差点を他の市におけるもの等の他の道路網でマッチングするときは、変化し得る。更に、個別要因の順序又は重み付けは、１つの道路網と他の道路網では変化し得る。
【００３４】
【発明の実施の形態】
以下、本発明の実施形態を添付した図１乃至図６を参照して詳細に説明する。
【００３５】
リアルタイムトラフィック関連データ
先ず、図１を参照すると、本発明のトラフィック情報システム１の第１実施形態の説明図を示す。この好適実施形態の場合には、システムは、カスタマイズされたトラフィック情報をサブスクライバ（予約購入者）に受信させるように、このトラフィック情報をトラベラに直接送信する手段を含んでいる。勿論、このシステムは、カスタマイズされた情報を第三者情報配布者に提供し、この情報配布者が更にカスタマイズされた情報を個別サブスクライバに配布するようにしてもよい。
【００３６】
図１のシステムは、リアルタイムトラフィック関連データを提供する各種ソース（信号源）２を含んでいる。これらのソース２は、公共利用可能なデータ、プライベート（個人的な）データ又は専有データを含んでもよい。データベース３は、履歴トラフィックデータを蓄積する。データベース３は、ソース２とインタフェースし、リアルタイムトラフィックデータおよび関連データを受信する。また、データベース３は、履歴、リアルタイムおよび関連トラフィックデータを統合する手段を含み、データの統計解析手段を含み且つカスタマイズされたトラベラ情報パッケージ作成するよう適合される。
【００３７】
会員（メンバー）又はサブスクライバデータベース４は、個別サブスクライバのトラベルプロファイルを蓄積し、個別サブスクライバ７のトラベル情報パッケージを生成するとき考慮される。ＳＭＳサーバ５は、データベース３および移動又はＧＳＭネットワーク等のワイヤレスネットワーク６間のゲートウエイを提供する。
【００３８】
サブスクライバ７は、移動ネットワーク６を介して伝送されるデータを受信するよう動作する移動電話の如き移動通信手段を有する。好適実施形態では、カスタマイズされたテキストメッセージがサブスクライバのトラベルプロファイルに従って関連するトラフィック情報に関しサブスクライバの電話に受信される。サブスクライバ７には、インターネット又はその他のアクセス手段により、サブスクライバデータベース４に蓄積された自己のプロファイルにアクセス可能にされる。これにより、サブスクライバ７は、自己のトラベルプロファイルを編集および変更する機会が与えられる。
【００３９】
各種データソース２は、一般にリアルタイムトラフィック関連データを提供する。斯かるデータソース２は、ハイウエイループ検出器、ビデオカメラ、公的および私的に所有されたソース、および道路網を通る車両の走行に関するデータを送信する無線又は移動通信装置を有するＧＰＳ装置を備える車両を含んでいる。更に、空中探査を、一般的なメディアリポートとして使用可能である。
【００４０】
データベース３およびデータソース２間のインタフェースは、天気予報その他の視覚および音声情報等の各種Ｗｅｂサイトから自動的に収集した公的情報を含み、これらの情報はオペレータによりキーインされ、自動的に収集された情報に加えられる。
【００４１】
履歴、リアルタイムおよび関連トラフィックデータの統合
データベース３には、ソフトウエアを組み込んでおり、サブスクライバのトラベルプロファイルに関する履歴データおよびリアルタイムデータの統合および処理を行う。この処理には、種々の技法が利用可能である。好適実施形態におけるソフトウエアは、Ｐｅｒｌ（ＰｒａｃｔｉｃａｌＥｘｔｒａｃｔｉｏｎａｎｄＲｅｐｏｒｔＬａｎｇｕａｇｅ）で書かれており、１実施形態では、このソフトウエアは、Ｌｉｎｕｘオペレーティングシステム（ＯＳ）を使用するＰＣ（パーソナルコンピュータ）上で動作する。
【００４２】
次に、表１を参照すると、データベース３に蓄積された情報のタイプの例を示している。
【表１】

【００４３】
この場合において、リアルタイムデータは履歴データと統合され、特定ルートに対する予想トラベル時間を作成する。この例は、郊外からビクトリア州メルボルンのＭｏｎａｓｈフリーウエイへのトラベルに関する。ここに示す如く、エントリ番号１３４５は、１例である。この情報をエントリに含むことにより、システムはＳｏｕｔｈＷａｎｔｉｒｎａを午前６：４５に出発すると、Ｓｐｒｉｎｇｖａｌｅエントランスを介してフリーウエイに７：００頃に入ることを意味する。ＨｏｄｄｌｅＳｔ出口の通過は、午前７：３０頃が予想される。この情報は、データベース３に含まれ、連続的に更新され得る。
【００４４】
再度図１を参照すると、ＳＭＳサーバ５は、データベース３からカスタマイズされたメッセージを電子メールの形態で受信する。この電子メールは、個別サブスクライバ７のカスタマイズされた予想トラフィック情報を含んでいる。予想トラベル時間情報、出来事および天気情報は、移動ネットワーク６を介してサブスクライバ７の移動電話にＳＭＳサーバ５を介して配達される。この予想情報は、前日の夜、トラベルの直前、トラベルルート中、又は分岐点の直前等の各種タイムウインドウで配布可能であり、目的地への代替ルートの選択を提供する。サブスクライバデータベース４に含まれるサブスクライバプロファイルは、配布される予想情報の頻度および時間を決定する。
【００４５】
表２は、作成され個別サブスクライバに配布されるカスタマイズされた情報のスナップショットである。
【表２】

【００４６】
例えば、午前７：１６にＳａｔｈｉｓｈへ送ったメッセージは、ＰｕｎｔＲｄに着くには約２２分かかると予想している。同様に、午前７：２１にＧｅｏｒｇｅへ送ったメッセージは、ＨｏｄｄｌｅＳｔに着くまでに１６分かかると予想している。典型的には、これらのメッセージは、トラベルの前にサブスクライバへ送られる。
【００４７】
例えば、午前８：００にＲｏｗｖｉｌｌｅから家を出発し、ＷｅｌｌｉｎｇｔｏｎＲｄで午前８：１５にＭｏｎａｓｈフリーウエイに入るサブスクライバは、午前７：５５に標準予想トラフィック情報メッセージを受け取る。もし、午前７：５５から午前８：１５の間に何らかのインシデント（出来事）があれば、彼がフリーェウエイに入る前に、そのサブスクライバに更なるメッセージが移動電話により送られる。これにより、彼のトラベルルートのトラフィック状態のクリティカルな時間にサブスクライバは情報を受け、これによりサブスクライバは、自分の通常のトラベルルートを変更し、このインシデントにより生じ得る遅延を回避する。
【００４８】
表２の更に下に、フリーウエイのトラフィック情報の処理を示す３つのエントリがある。これは、リアルタイムデータを履歴データと統合して予報情報を提供する動作を示す。この処理は、定期的又は更新されたリアルタイムデータがデータベースに受信した際に実行される。
【００４９】
次に、図２を参照すると、統計的モデリングを採用するトラフィック予報処理の１例のフローチャートを示している。このプロセスフローチャートは、次のステップを含んでいる。
【００５０】
ステップ１：
累積された一連の履歴データを取得する。この累積データは、種々の地域における連続した２−１０分の平均遅延時間であり、タイムステップの一連の履歴遅延の形態になる。
【００５１】
ステップ２：
従来のスペクトラル法を採用して、履歴データの季節トレンド（変化傾向）を取得し履歴データから削除し、その結果をトラフィックデータとして出力すると共にテーブル化する。
【００５２】
ステップ３：
履歴天候データを取得し且つそれを残りの非変更トラフィックデータとスプライス（突合せ）し、トラフィックデータテーブルの（ａ）最後に降った雨からの経過日数（Ｄｒ）および（ｂ）過去３時間の雨量（Ｒ）の欄を追加する。次に、前に出力した出力トラフィックデータテーブルに追加された欄は、次の何れか又は全てに該当するか否か示す。
（ｉ）学校の休暇期間（Ｓｈ＝０又は１）
（ｉｉ）共通の夏期休暇期間（Ｃｈ＝０又は１）
（ｉｉｉ）週末／週日（ウイークデイ）（Ｗｅ＝１／０）
（ｉｖ）祝日又はその前後（Ｐｈ，Ｐｈ− ，Ｐｈ＋）
【００５３】
上述した変数は、処理内にモデリング可能なイベントのタイプに関する関連トラフィックデータの例であり、また他の変数も同様に入力可能である。上述した付加欄を追加することにより、各種イベントに関する天気パターンの効果および時間間隔がトラフィックデータテーブルに加えられる。
【００５４】
予測解析に好適な履歴データのモデルを作成するために、トラフィックデータは週の曜日に対応する７個のファイルに分割される。各ファイルのデータは、必要とする頻度に応じて１５分又は３０分の平均値を表す平均化により合成される。典型的には、３０分の期間で十分である。動作において、例えば月曜日の朝８：３０における平均遅延を検討する。特定の又は与えられたトラベルルートの遅延データの代表値は、交差点および／又はフリーウエイの個別遅延（これをリンクという）よりなり、各ルートのリンクの予想開始時間における値である。午前８：３０から午前９：００間の３０分間の各リンクの平均遅延は、３０分間の２分間隔の時間平均から得られる。２分のサンプル間隔は、フリーウエイ、交差点等におけるセンサ等から得られたデータの連続ストリームである。この期間は、必要な頻度に応じて変化してもよい。
【００５５】
月曜日の朝、８：３０に収集したこれら平均遅延データの全ては、別のファイルにグループ分けされ、少なくともデータの最小自乗（スクエアフィット）を、次の関数を使用して実行する。
遅延＝ａ０＋ａ１＊Ｄｒ／（ａ２＋Ｄｒ）＋ａ３＊Ｒ／（ａ４＋Ｒ）＋ａ５＊Ｓｈ＋ａ６＊Ｃｈ＋ａ７＊Ｗｅ＋ａ８＊Ｐｈ＋ａ９＊Ｐｈ− ＋ａ１０＊Ｐｈ＋
ここで、Ｄｒ：最近の雨からの経過日数
Ｒ：過去３時間の降雨量
Ｓｈ：学校の休暇期間
Ｃｈ：共通の夏期休暇期間
Ｗｅ：週末／週日
Ｐｈ：祝日
Ｐｈ−：祝日の前日
Ｐｈ＋：祝日の翌日
【００５６】
好適実施形態では、上述のモデリングは、７日間の毎日について３０分間行われる。これは、１０個の係数（ａ０￣ａ９）の３３６セットを生じ、各リンクの履歴データとなる。必ずしも必要ではないが、履歴データを説明するモデルを使用することにより、ＲＡＭに利用可能な平均履歴データの全てを蓄積することに比較して一次および二次蓄積要件を軽減することになる。モデルを使用すると、モデルは略６ヶ月毎に作成し直されることが期待される。この好適実施形態の場合には、少なくとも最小自乗法解析を６ヶ月毎に実施し、各リンクの新しい３３６セットの係数（ａ０￣ａ９）を生成する。
【００５７】
ステップ４：
ネットワークの測定したリンク遅延およびネットワークのリンクの実際の天候状態に関する関連データに関する各種ソースからリアルタイムデータを取得する。
【００５８】
ステップ５：
ネットワークの各リンクにつき、季節調整された遅延および測定された天候状態に基づく履歴期待遅延を決定し且つ各リンクについてリンクの最新の測定遅延と測定された遅延に対応するタイムステップにおけるリンクの履歴期待遅延の比を計算する。この比には、「ＪＶＬ」のラベルを付す。
【００５９】
ステップ６：
開始ノードから目的地ノードまでの期待遅延を予測するとき、各リンクの履歴期待遅延を決定するが、これは各リンクの期待される開始時間であり且つ各リンクの履歴期待遅延の加算の前に、ルートの各リンクの履歴期待遅延にリンクの対応するＪＶＬ比を掛け、開始ノードから目的地ノードまでのトラベルの予想期待遅延を形成する。
【００６０】
ネットワークにおけるトラフィックリンクに対する期待トラベル遅延に影響するインシデントが、オペレータによりデータベースに手動で入力される。インシデントは幅広く変化する性質を有するので、影響を受けたリンクのトラフィックに起きるであろう期待遅延は、必ず監視者の推定に依存する。インシデント監視者の観察およびそのインシデントから生じる期待されるリンク遅延は、統合手段が規則的にアクセスして履歴期待リンク遅延のデータベースを更新するデータベースに入力される。他の実施形態では、インシデントにより生じるトラフィックリンクへの期待遅延は、履歴期待リンク遅延のデータベースとは別のデータベースに留まるかも知れず、これら２つのデータベースは、ネットワークの開始ノードから目的地ノードまでトラベルするトラベラに対して予想した実際の遅延を提供するときにアクセスされる。時間が経つと、インシデントに関して更に監視結果を受けるので、インシデントデータベースを更新して、このインシデントにより生じる期待遅延の変化を反映させてもよい。
【００６１】
好適実施形態において、インシデントデータベースは、トラベラのプロファイルがサブスクライバへトラベル遅延の予想および伝送を行わせる毎にアクセスされる。
【００６２】
道路網を通る最適パス
本発明の好適実施形態において、カスタマイズされた予報トラフィック情報システムは、サブスクライバが自己の目的地へ最小時間で到達する道路網を通る最適パスの決定を含んでいる。道路網を通る最適パスの検索は、各リンクのフロー方向およびトラフィック制御信号により各交差点を通ってトラフィックの移動に生じる各種の異なる遅延並びにオペレータの入力その他の自動データ供給を考慮する。
【００６３】
次に、図３を参照すると、交差点１１を示す図が示され、この交差点１１には、インカミング／アウトゴーイングリンクが設けられ、それには交差点（ノード）１２、１３、１４および１５が接続されている。これらリンクは双方向性であり、ノード１１には、図３に示された以外の多くのノードがあってもよい。一般に、Ｂに到着するトラフィック（又はＢで止まっている行列）は、この交差点を通ってＣ、Ｄ又はＥへ移動するのに異なる時間を要する。これらの時間は、これらリンクの各々における混雑状態および交差点１１におけるトラフィック信号の設定に依存することとなる。
【００６４】
本明細書の目的のために、「飽和度（ＤＯＳ）」の用語は、特定トラフィック信号の結果による実際のトラフィック移動の流れとこの信号により可能な最大トラフィックの流れの比に言及するために使用される。ＤＯＳは、交差点の混雑の目安であり、場合のよっては特定の移動の遅延（秒）に変換される。
【００６５】
本明細書の目的のため、「平均フリートラベル時間」の用語は、全てのトラフィック制御装置を除去した場合のリンクにおけるトラベル時間に言及するために使用される。
【００６６】
図４を参照すると、車両のフローと車両の集中度の典型的な関係を、典型的なトラフィックリンクで詳細に示す。図４から明らかな如く、この関係は凸状曲線であり、ある車両集中度および飽和度０点において車両集中度軸と交差する。このトラフィックリンクの「平均フリースピード」の値は、図４から、車両フロー（１秒当たりの車両数で表す）を対応する集中度（１メートル当たりの車両数で表す）で除算することにより決定される。当業者は認識する如く、「平均フリースピード」は、決定が困難な量である。
【００６７】
本発明の好適実施形態において、車線の各リンクの平均フリースピードは、各種の異なるクラスの道路（例えば、フリーウエイ、幹線および郊外の道路）における車両集中度と車両フロー速度間の関係から得る。また、図４は、トラフィックリンクの飽和フロー（ｘｍ，ｆｍ）が生じる点の詳細を示している。
【００６８】
異なるクラスの道路における典型的な関係の詳細を図５に示している。また、車両集中度と飽和度の更なる関係を決定するのが好ましい。ＤＯＳは、車両フローに正比例するので、車両フローはＤＯＳから推論できるかも知れない。リンクの飽和フロー未満（即ち、図４のｆｍ未満）の車両フローに対して、平均フリースピードは、フロー（ＤＯＳから推定）を対応する集中度で除算することにより計算可能である。高いＤＯＳに対応する飽和フローより大きい車両フローに対しては、車両は平均フリースピードが０近くに低下するのが速くなる。平均フリースピードとＤＯＳ間の関係を図６に示す。飽和フローに対応する飽和度を超える実際の関係は、実験により求める。従って、ＤＯＳは、車両集中度で除算して平均フリースピードを得るフローレート（流れ率）の推定に使用可能である。
【００６９】
ＡからＢ、ＣおよびＦへのトラベル時間のモデルは、ＡからＢおよびＣからＦへの非混雑トラベル時間とＢからＣへの移動の遅延の和である。この非混雑トラベル時間は、平均フリートラベル時間である。これらの時間は、特定のタイプの道路では一般に一定である平均フリートラベルスピードおよびリンク長から計算可能である。計算のためには、リンクトラベル時間を平均フリートラベル時間とその直ぐ上流の交差点を通り抜ける時間の和と定義するのが便利である。即ち、リンクＢＣＦのトラベル時間は、リンクＣＦのフリートラベル時間とムーブメントＢＣの通過時間の和である。後者は規則的な時間間隔（例えば１分）でトラフィック管制システムから送信される量（数値）から計算できる。例えば、ＳＣＡＴＳ（ＳｙｄｎｅｙＣｏｏｒｄｉｎａｔｅｄＡｄａｐｔｉｖｅＴｒａｆｆｉｃＳｙｓｔｅｍ）トラフィック管制システムでは、交差点移動遅延の計算に必要な変数は次のとおりである。
‐日付／時間
‐交差点戦略アプローチ番号（例えば、リンク番号）
‐地域コンピュータ名／番号（データを提供するコンピュータの識別）
‐サブシステム番号
‐戦略アプローチの緑信号時間
‐戦略アプローチの信号サイクル時間
‐戦略アプローチのＤＯＳ
【００７０】
上述の如くリンクトラベル時間を定義すると、例えばＤｉｊｋｓｔｒａの伝統的な最適パス探索法が使用可能であることを意味する。しかし、各特定リンクに関連する幾つかのトラベル時間があることも意味する。例えば、各リンクに関連するトラベル時間は、交差点移動ＢＣ、ＥＣ、ＤＣおよびＣＦＣ（Ｕターン）時間およびダウンリンクＣＦ平均トラベル時間の和よりなる４リンクトラベル時間である。
【００７１】
一般に、ノードで連結されたｎ個のリンクがあると、このノードに関連してｎ＊ｎのトラベル時間がある。１つのノードから次のノードの最適パスの探索を行うとき、現在のノードのパス上の上流のノードを知る必要があり、これにより新しいノードへの正しいトラベル時間が計算可能である。
【００７２】
本発明の好適実施形態において、最適パス探索を行う日の各異なる時間について、単一の連続ベクトルとしてリンクトラベル時間が蓄積される。他のベクトルは、最初のベクトルの索引（インデックス）を含み、これにより特定ノードを通る遅延に関する情報が見つけられる。
【００７３】
例えば、ＮＣＯＳＴがトラベル時間のベクトルであり、ＮＩＮＤＥＸ（ｎｎ）がＮＣＯＳＴにおいてリンクトラベル時間を開始する交差点ｎｎのインデックスであると仮定する。この交差点ｎｎで連結されるｋ個のリンクがあると、ノードｎｎで連結されるリンクのリンクトラベル時間は、ベクトルＮＣＯＳＴでＮＩＮＤＥＸ（ｎｎ）からＮＩＮＤＥＸ（ｎｎ）＋ｋ＊ｋ −１の位置を占める。特に、もしｉ＝（ＮＩＮＤＥＸ（ｎｎ）＋ｊ＊ｋ −１＋ｎ）で，ｊ＜ｋおよびｎ＜＝ｋであれば、ＮＣＯＳＴ（ｉ）は、上流ノードｎからノードｎｎのトラフィックが入力されていると、ノードｎｎおよびそれから下流ｊ番目間の遅延である。このアプローチは、リンク遅延を蓄積する比較的有効な方法であり、新たな交差点遅延が得られると容易に更新可能である。
【００７４】
ノード１への到達がＢＡを経た場合のＣＦのトラベル時間は、ノード１への到達がＦＣを経た場合のＢＡのトラベル時間よりベクトルＮＣＯＳＴの異なる位置を占めるので、ノード間の単一の接続を蓄積することのみが必要である。双方向フローは、このように取り扱われる。
【００７５】
実際問題として、ＮＣＯＳＴは２次元であり、第１次元は１日の時間であり、第２次元は上述したリンク遅延である。例えば、システムがトラフィック制御信号から１０分の平均データで動作していると、１日には１４４の分離された１０分の期間が存在するので、第１次元は１４４である。
【００７６】
道路工事、臨時／永久道路閉鎖および事故等のトラフィックインシデントは、ＮＣＯＳＴの適当な位置にインシデントの既知又は推定時間として極めて大きいリンクトラベル時間を入力することにより、上述のスキームで取り扱うことが可能である。単方向リンクの場合には、非常に大きいリンク遅延を違法移動方向に関するＮＣＯＳＴの位置に永久的に入力してもよい。
【００７７】
大部分のインシデントは、インシデントに関するコードをファイルにオペレータがタイプ入力することにより取り扱う。コンピュータプログラムは、ファイルを規則的（例えば、５秒毎）に読み、ＮＣＯＳＴを更新する。もしインシデントが生じ、適当なリンクの遅延が大きい値に設定されると、トラフィック管制システムから来るデータは、このインシデントに影響されるネットワークの部分の履歴データと比較される。このインシデントがクリアされると、ダイナミックデータは「通常」に復帰し、そして大きいリンク遅延も通常の値に復帰される。従って、ダイナミック遅延は、インシデント検出オペレータにフィードバックパスを提供する。
【００７８】
トラフィック信号からの履歴データは、週の各日の完全な２４時間の典型データセットが存在するように収集される。このデータの収集の前に、最小サンプリング期間（例えば、１０分）を決定するべきである。１日の開始に際し、関連するデータセットがＮＣＯＳＴにローディングされるべきである。
【００７９】
各日が進むと、システムは現在の信号データを収集し、それをＮＣＯＳＴの関連タイムスロットを満たすのに適当な形体に処理し且つ履歴データベースのオフライン修正用に記録保管する。
【００８０】
最適又は固定トリップ時間の要求を受けると、トラフィック信号データの最後の幾つかの期間から収集されたリンク遅延を対応する履歴データと比較する、そして次のものを含む各種方法を使用する次のｎタイムステップのＮＣＯＳＴの完全なベクトルの各エレメントの推定を行う。
‐時系列解析
‐指数重み付け
‐履歴値に各リンク遅延の履歴遅延に対する現在利用可能な遅延の比の直接積算。
【００８１】
インシデントは、必要に応じてオペレータによりダイナミックに加入又は削除する。インシデントレポートは、音声により受けてもよく且つ音声認識技法を使用して必要な情報を電子的に抜き取り且つインシデントレポートのデータベースに転送する。
【００８２】
本発明の好適実施形態は、トリップのスタート時に、トリップ全体にわたるリンク遅延部はその同じスタート時間における遅延ではないことを認識する。サーチ方法の進行につれて、そのトリップの各ノードへの経過時間を計算し且つその特定時間に適当なＮＣＯＳＴのベクトルを使用して、トリップの次のリンク遅延を計算する。明らかに、ダイナミックデータ供給がないと、履歴データを使用するが、ダイナミックデータが利用可能になると、それを使用してＮＣＯＳＴの履歴データの次のベクトルの修正に使用し、最新のトラフィック状態を反映する。トリップの既知の出発地および目的地から、トリップトラベル時間の適当な推定が、１日のその時間に適切である悲観的平均トラベルスピードの近似推定を行う。次に、これを使用して、予測を行わなければならないＮＣＯＳＴの幾つかの期間の推定に使用される。
【００８３】
以上、好適実施形態をＳＣＡＴＳシステムに関して説明したが、本発明はＳＣＯＯＴ（ＳｐｌｉｔＣｙｃｌｅＯｆｆｓｅｔＯｐｔｉｍｉｚａｔｉｏｎＴｅｃｈｎｉｑｕｅ）システム等の代替トラフィック制御システムにて収集されたデータを受信および活用にも容易に適用できる。
【００８４】
道路網移動遅延の予測
トラフィック制御システムの中には、各交差点での移動遅延の完全に更新されたセット１時間以内に提供できないものもある。しかし、それらは、道路網の交差点の恐らく１０％を、１０分未満で更新可能である。トラフィックデータを収集する交差点を慎重に選択することにより、このデータを、タイムリなデータが得られない残りの交差点にマッチングできる。
【００８５】
データの収集のために選択された交差点は、タイムリなデータが利用できない交差点の形状および能力範囲をカバーしなければならない。能力の１つの目安は、１日にわたる平均ＤＯＳである。履歴データは、全ての交差点におけるこの量の計算および適切なデータの収集を可能にする。任意の２つの見込みマッチングは、同様のＤＯＳを有するべきである。同様に、もし履歴グリーンシグナル（緑信号）時間および信号サイクル時間が利用可能であれば、これらの日毎の平均値も使用して対をなす交差点のマッチングに使用可能である。
【００８６】
任意の２つのマッチングした交差点は、同じ数の交差リンクを有するのが好ましい。データマッチングの目的のため、交差点の向きは、中央商業地域に向かう点に最も近いリンクがアライメントされるように配置されるのが好ましい。更に、両方の交差点は、中央商業地域からできる限り同じ距離であるのが好ましい。
【００８７】
上述した全てのマッチング基準は、「オフライン」で利用可能である。即ち、ネットワークの形状および適当な履歴データのみが既知であれば、それらはこのシステムに適用可能である。適用可能なマッチング要因が多ければ多いほど、交差転換のマッチングは一層正確になる。好適実施形態では、マッチングするリンク数、中央商業地区からの距離、中央商業地区に対する向きの基準が常に使用される。一度マッチングが決定されると、収集された交差点データは、交差点のマッチングにエキスポート（輸出）でき、ネットワーク全体のトラフィックデータのフルセットを提供する。
【００８８】
マッチングプロセスに関して、リンク遅延の誤差は、多数のリンクを横切るトリップ全体では相殺される傾向にある。
【００８９】
もしトラフィックデータが１つの市の一部について利用可能であるが、この第１の市と同様のトラフィックフロー特性を有する他の市では利用不可能である場合には、上述した属性の幾つかを使用して交差点マッチングを行い、トラフィックデータがない市におけるトラフィックデータを推定する。マッチングされるその市のローカル知識により、データが既に収集された市における交差点の日毎の平均ＤＯＳ値の範囲に等価された「混雑度」による交差点のクラス分けを可能にする。次に、その新しい市における１日全体のトラベル時間の推定が可能である。このアプローチにより、そのような設備が既に稼動している市のトラフィック特性と同様と思われる他の市におけるトラベル時間アドバイスシステムを確立することができる。時間が経つと、この「新しい」市における適当なデータが収集でき、履歴データベースが改善できる。理想的には、この履歴データは、真のリアルタイムトラベラ情報を提供可能にするため、フローティング又はシードされた車両からのダイナミックデータと補完される必要がある。いずれにしろ、トラフィックデータマッチングプロセスを適用することにより、少なくとも最初の推定を実際にトラフィックデータが利用できない市に対して確立可能にする。
【００９０】
トラフィック情報配布の代替手段
メッセージを配布する代替手段は、テキスト‐音声変換を含んでもよい。予報トラフィック情報は、会話（スピーチ）に変換されボイスコール又は応答がなければその後に回復されるボイスメッセージの何れかにより伝送される。他の形態として、データベースからのトラフィック情報は、メニューベースの対話型音声応答（ＩＶＲ）により利用可能にしてもよい。更に、ＨＴＭＬテキストＷＡＰおよび／又は３Ｇ移動電話の表示に適切な一層基本的なＷＭＬテキストに短縮することが可能である。
【００９１】
再度図１を参照すると、代替構成として、個別サブスクライバ７の位置データサーバ５で決定し且つ関連付けてもよい。ＧＰＳ、ＭＰＳ又はその他の適当な測位システムを採用して個別サブスクライバの正しい位置および状態を決定する。もしサブスクライバが、自分のトラベル出発時間を変更すると、このサブスクライバ用のカスタマイズされたメッセージを、その位置データにより決定された最新の状態に基づいてダイナミックに更新可能である。また、サブスクライバは、必要に応じて特定情報の要求が可能である。ＳＭＳプロトコルで呼び出されたサービスは、「プッシュ」および「プル」メッセージと称される。プッシュ／プルサービスは、トラフィック情報を要求する（プル）サブスクライバの電話から送られたＳＭＳメッセージおよびこれに対する要求された情報を含むＳＭＳメッセージの送信（プッシュ）である。また、サブスクライバは、一般大衆用情報を有する専用Ｗｅｂサイトにアクセスすると共にサブスクライバ用の特定アクセスもできる。サブスクライバは、必要に応じて自己のプロファイルを変更可能である。サブスクライバプロファイル内に含まれる情報のタイプは、サブスクライバの期待出発時間、サブスクライバになじみのある主および代替ルートおよびサブスクライバの好きな天気予報情報を含んでいる。
【００９２】
結論
本発明の方法およびシステムは、多くの効果を有し且つ当業者にはここに広く説明した本発明の特定実施形態の精神および範囲を逸脱することなく、多くの変更および／又は変形が可能であることが理解されよう。従って、本発明の実施形態は、あらゆる点において本発明の単なる例示に過ぎず何らそれを限定するものではない。
【図面の簡単な説明】
【図１】本発明によるトラフィック情報システムの１実施形態のブロック図である。
【図２】本発明によるトラフィック予報プロセスの１実施形態を示すフローチャートである。
【図３】トラベルリンクおよび個別トラフィックフローを識別する典型的な交差点を示す図である。
【図４】典型的なトラフィックリンクの車両フローと車両集中度の関係を示すグラフである。
【図５】種々の異なるクラスの道路に対する車両フローおよび車両集中度の典型的な関係を示すグラフである。
【図６】本発明の実施形態において得られる平均フリー車両スピードと飽和度の関係を示すグラフである。
【符号の説明】
１トラフィック情報システム
２ソース（情報源）
３データベース
４メンバー（サブスクライバ）データベース
５ＳＭＳサーバ
６無線ネットワーク
７サブスクライバ（カスタマ）

Claims

道路網の１以上の交差点に関する履歴トラフィックデータを蓄積し、且つ実質的に前記１以上の交差点に関するリアルタイムトラフィックデータ及び関連トラフィックデータを受信するよう動作するデータベースと、
前記データベースに蓄積されるサブスクライバのプロファイルに関する前記履歴及びリアルタイムトラフィック及び関連トラフィックデータを決定論的に統合し、カスタマイズされた予報トラフィック情報を生成する統合生成手段と、
該カスタマイズされた予報トラフィック情報をサブスクライバに送信する手段とを備え、
前記カスタマイズされた予報トラフィック情報は、前記サブスクライバのプロファイルに記載された１つのトラベルルート用のトラベル遅延予測よりなり、
前記トラベルルートの特定の交差点に関して履歴トラフィックデータ又はリアルタイムトラフィックデータが不十分な場合に、前記統合生成手段は、前記トラベルルートのトラベル遅延予測を提供するために、マッチング要因に基づいてマッチングした交差点を決定し、前記マッチングした交差点から利用可能な履歴トラフィックデータ又はリアルタイムトラフィックデータを使用するように動作することを特徴とするトラフィック又は関連情報を提供するシステム。
マッチングした前記交差点の決定は、
ａ）前記交差点の形状
ｂ）前記交差点の向き
ｃ）前記交差点の信号サイクルタイムの日毎の履歴平均値
ｄ）前記交差点から比較的高人口密度の位置までの距離
の１以上を考慮に入れることを特徴とする請求項１に記載のシステム。
個別のサブスクライバは、全てのサブスクライバのプロファイルの前記カスタマイズされた予報トラフィック情報を受信し、各トラベルプロファイルに関する前記情報を分離し、次にそのプロファイルに従って個別トラベラへ伝送することを特徴とする請求項１又は２に記載のシステム。
トラベルプロファイルを有する前記サブスクライバは、伝送されるカスタマイズされた予報トラフィック情報を受信するリモートターミナルを有することを特徴とする請求項１〜３の何れかに記載のシステム。
前記リモートターミナルは、情報を前記データベースへ伝送するよう動作することを特徴とする請求項４に記載のシステム。
前記リモートターミナルは、移動電話であることを特徴とする請求項４又は５に記載のシステム。
前記カスタマイズされた予報トラフィック情報は、トラベル開始前にサブスクライバに送信する手段により伝送されることを特徴とする請求項１〜６の何れかに記載のシステム。
前記カスタマイズされた予報トラフィック情報は、前記サブスクライバのトラベル中に、サブスクライバに送信する手段により伝送されることを特徴とする請求項１〜７の何れかに記載のシステム。
個別トラベルプロファイルを蓄積するサブスクライバデータベースを含み、前記トラベルプロファイルは、前記サブスクライバを識別するデータ及び前記サブスクライバの通常トラベルルートに関するデータ及びこれらルートの通常開始時間を含むことを特徴とする請求項１〜８の何れかに記載のシステム。
前記トラベルプロファイルは、前記サブスクライバが前記カスタマイズされた予報トラフィック情報を受信したい時間を示すことを特徴とする請求項１〜９の何れかに記載のシステム。
個別サブスクライバは、前記サブスクライバデータベースにアクセスが提供され、前記データベース内に含まれる自己のプロファイルに関するデータを改変可能にすることを特徴とする請求項９又は１０に記載のシステム。
前記統合生成手段は、学校の休暇期間、夏期休暇期間、祝日及び週末等のイベントに関するデータを受信し、該データと履歴トラフィックデータとの相関をとることを特徴とする請求項１〜１１の何れかに記載のシステム。
ａ）履歴、及びリアルタイムトラフィックデータ、及び関連データをデータベースに蓄積する工程と、
ｂ）前記データベースに記憶されたサブスクライバのプロファイルに関する前記履歴、及びリアルタイムトラフィックデータ、及び関連データを決定論的に統合して、カスタマイズされた予報トラフィック情報を生成する統合生成工程と、
ｃ）該カスタマイズされた予報トラフィック情報をサブスクライバへ送信する工程とを備え、
前記カスタマイズされた予報トラフィック情報は、前記サブスクライバのプロファイルに記載されたトラベルルートのトラベル遅延予測よりなり、
前記トラベルルートの交差点に関する履歴又はリアルタイムトラフィックデータが不十分な場合には、前記統合生成工程は、マッチングする要因に基づいてマッチングした交差点を決定し、前記マッチングした交差点から利用可能な履歴又はリアルタイムトラフィックデータを使用してトラベル遅延予測を提供することを特徴とするトラフィック又は関連情報を提供する方法。
マッチングした前記交差点の決定は、
ａ）前記交差点の形状
ｂ）前記交差点の向き
ｃ）前記交差点の信号サイクルタイムの日毎の履歴平均
ｄ）前記交差点から比較的高人口密度の位置までの距離
の１以上を考慮に入れて行うことを特徴とする請求項１３に記載の方法。
前記個々のサブスクライバが、全てのサブスクライバのプロファイルの前記カスタマイズされた予報トラフィック情報を受信し、そのプロファイルに従って各個別トラベラに伝送するため、各トラベルのプロファイルに関する情報を仕分けする工程を備えることを特徴とする請求項１３又は１４に記載の方法。
トラベルのプロファイル及びリモートターミナルを有する前記サブスクライバが前記ターミナルにカスタマイズされた予報トラフィック情報を受信する工程を備えることを特徴とする請求項１３〜１５の何れかに記載の方法。
前記リモートターミナルは、情報を前記データベースに伝送するように動作し、前記方法は個別サブスクライバが情報を前記データベースへ伝送する工程を備えることを特徴とする請求項１６に記載の方法。
前記トラベルのプロファイルから前記サブスクライバの通常トラベルルート及びこれらルートの通常開始時間を決定する工程を備えることを特徴とする請求項１３〜１７の何れかに記載の方法。
前記トラベルのプロファイルからサブスクライバが前記カスタマイズされた予報トラフィック情報を受信したい時間を決定する工程を備えることを特徴とする請求項１３〜１８の何れかに記載の方法。
前記カスタマイズされた予報トラフィック情報を、前記トラベルのプロファイルから決定された情報を受信する希望時間に従ってトラベラへ送信する工程を備えることを特徴とする請求項１９に記載の方法。
サブスクライバが蓄積された自己のトラベルのプロファイルにアクセスし且つ前記プロファイルに含まれるデータを改変する工程を含むことを特徴とする請求項１９又は２０に記載の方法。
サブスクライバのプロファイルに関する履歴、リアルタイム及び関連トラフィックデータの前記統合生成工程は、学校の休暇期間、夏期休暇期間、祝日及び週末等のイベントに関するデータを受信し、該データと前記履歴トラフィックデータとの相関を取る工程を含むことを特徴とする請求項１３〜２１の何れかに記載の方法。