JP2005234918A

JP2005234918A - 交通手段情報提供システム

Info

Publication number: JP2005234918A
Application number: JP2004043829A
Authority: JP
Inventors: Misao Kishimoto; 操岸本
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-02-20
Filing date: 2004-02-20
Publication date: 2005-09-02

Abstract

【課題】
利用者毎に異なる利用者に望まれる交通手段に関する情報を提供すること。
【解決手段】
本発明の目的は利用者が事前に交通手段に関する予備知識が一切無い場合においても利用者にとって最適な交通手段に関する情報を利用者に提供する事である。具体的には、利用者が目的地の最寄駅を知らなくても交通手段に関する情報を得られる。三次元の位置情報を用いることによって高さ方向の概念を用いた交通手段に関する情報を提供する。
【選択図】図１

Description

本発明は交通手段の情報提供システムに関わる。

任意の２点間の交通手段を提供するものとしてカーナビゲーションシステムや公共の交通手段に対するルート検索サービスが有る。カーナビゲーションシステムではＧＰＳにより自車位置情報を取得し、目的地に対し時間優先、距離優先等のオプションを考慮した交通手段に関する情報を提供している。鉄道、航空、バス等の公共の交通手段に対するルート検索サービスでは出発駅、到着駅の情報より目的地に対し時間優先、距離優先等のオプションを考慮した交通手段に関する情報を提供している。また、特開平９−７０８８号公報では駅周辺図や路線案内図を交通手段に関する情報と共に提供している。

特開平９−７０８８号公報

発明が解決しようとする課題として一つ目は現状の技術では現在地及び目的地を利用者が明確に規定する必要が有り、利用者が事前に現在地及び目的地の最寄駅を知っておかなければ目的地までの交通手段に関する情報を入手するのは困難である。

二つ目は現在地や目的地付近の地図情報を提供する技術はあるが、二次元情報のものを前提としており例えば目的地が横浜ランドマークタワーの最上階だったとしても一階迄の情報しか得られず、ＤｏｏｒｔｏＤｏｏｒでの交通手段に関する情報が提供されていない。

三つ目は駅構内図に関しても単なる地図情報であり、ＪＲ東京駅のように、駅の構造がＪＲ中央線とＪＲ横須賀線の高低差が地下を含めて七階層も有る場合や、ＪＲ横須賀線とＪＲ京葉線プラットフォームの端と端が極めて距離が長い場合は高さ方向を含めた移動時間は考慮されていない。

最後に、利用者にとって利便性を考慮した交通手段に関する情報が提供されていない。利便性とは例えば、従来からある最短時間で移動できることであるとか乗換えが少ないことといったもの以外に、バリアフリー施設の充実した施設を選択するとか女性専用車両を利用するとか喫煙地域を考慮して、移動する経路が地図にマッピングされることにより誰でも迷うことなく移動が可能になることである。

本発明の目的は利用者が事前に交通手段に関する予備知識が一切無い場合においても利用者にとって最適な交通手段に関する情報を利用者に提供することである。

本発明の目的を達成するため、交通手段検索サーバが有する手段として以下のものがある。

ネットワークを介し交通手段取得クライアントより取得した現在地及び目的地情報より利用者の現在地及び目的地の最寄駅とその候補駅を取得する手段。

利用者の現在地及び目的地の最寄駅とその候補駅を用いて交通手段を検索する手段と、利用者の契約内容に基づき交通手段を決定する手段を有し、交通手段取得クライアントに配信する手段。

ネットワークを介して利用者に配信された交通手段に対する課金を制御する際に、前記交通手段の利用者に対する価値の重み付けに対する価値を課金ＤＢに反映する手段。

交通手段取得クライアントが有する手段として以下のものがある。

利用者の現在地を経度、緯度、標高などによる三次元の情報として所定時間間隔で取得する手段と、交通手段検索サーバに渡す手段を有する現在位置取得システムと、利用者の求める契約条件をパラメータ化して取得する手段と、利用者の現在地及び目的地の最寄駅とその候補を取得する手段と、交通手段検索サーバに渡す手段。

本発明によれば、利用者が事前に交通手段に関する予備知識が一切無い場合においても利用者にとって最適な交通手段に関する情報を利用者に提供し、且つ、利用者毎に異なる利用者に望まれる交通手段を契約内容に沿った付加価値を付けた状態にカスタマイズできる。

以下，本発明の実施例を、図面を用いて詳細に説明する。

図１は、本発明の全体構成図である。交通手段検索サーバ１０１と複数の交通手段取得クライアント１０２と複数の交通情報提供者１０３が、ネットワーク１０４を介して接続されている。複数の交通情報提供者１０３は、提供する交通情報の価値に応じて交通手段提供システムの利用者より徴収した課金の一部を受け取ることができる。また、交通手段取得クライアント１０２は画像表示機能を有する携帯電話などの移動端末であって、交通手段検索サーバ１０１とは有線又は無線の電話回線で接続されていてもよい。

交通手段検索サーバ１０１は、契約条件取得部１０５と交通手段検索部１０６と交通手段配信部１０７と課金部１０８と情報格納ＤＢ１０９からなる。

契約条件取得部１０５は交通手段情報に関する利用者が契約した条件を取得するものである。利用者の契約の変更状況に伴い情報格納ＤＢ内の課金ＤＢ１１１に保持される。契約した内容を呼び出した契約条件画面例を図５に示す。

交通手段検索部１０６は、交通手段取得クライアント１０２より三次元情報として取得された利用者の現在地及び目的地情報より現在地及び目的地の最寄駅とその候補に基づいて交通手段を検索する。その検索処理の詳細フローを図６に示す。

交通手段配信部１０７は、交通手段検索部１０６で検索された交通手段を交通手段取得クライアント１０２に配信するものであり、そのフローを図７に示す。

課金部１０８は、有料のオプションサービスの契約条件とサービスを受けた実績に基づき課金をするものであり、その実績は課金ＤＢ１１１に反映される。

情報格納ＤＢ１０９は、交通情報提供者１０３から提供される公共の交通機関の基本情報が格納されている交通情報ＤＢ１１０と課金情報が格納されている課金ＤＢ１１１からなる。交通情報ＤＢ１１０のテーブル例を図８に示す。

課金ＤＢ１１１は、契約条件と利用実績と交通手段検索時に契約条件を反映させるテーブルからなり、契約条件のテーブル例を図９に、利用実績のテーブル例を図１０に示す。また、交通手段検索時に契約条件を反映させるための情報を格納しているテーブルを図１１に示す。

図２は交通手段取得クライアント１０２の詳細図である。契約条件発信部２０１と利用者位置情報発信部２０２と交通情報受信部２０３からなる。

契約条件発信部２０１は、利用者の契約条件を交通手段検索サーバ１０１の契約条件取得部１０５に渡す機能を有する。利用者位置情報発信部２０２は、本サービス実行時に交通手段取得クライアント１０２で経度、緯度、標高からなる三次元情報として得る事が出来る利用者の現在位置情報と目的地情報を交通手段検索サーバ１０１の交通手段検索部１０６へ渡す機能を有する。この情報は交通手段を検索する基本情報として用いられる。交通情報受信部２０３は、交通手段検索サーバ１０１で検索された交通手段を交通手段配信部１０７より受信して表示する機能を有する。

図３は交通手段取得クライアント１０２の交通手段の候補を得る迄の操作および動作のフローである。利用者はサービス画面を起動する（３０１）。利用者は個人認証を行いログインする。この際の認証方法はユーザＩＤ、パスワード認証方式の他、バイオメトリクスによる認証方式等により実現する（３０２）。ログインに対して応答されて契約条件が表示される（図５）。利用者は契約条件を確認し、変更点が有れば修正する（３０３）。利用者が「決定」（図５の５０６）を選択すると、契約条件を交通手段取得クライアント１０２の契約条件発信部２０１が交通手段検索サーバ１０１の契約条件取得部１０５に対し送信し（３０４）、目的地入力画面に遷移する。

次に、利用者位置情報発信部２０２が利用者の現在位置を三次元情報の形で取得する（３０５）。利用者の現在位置を三次元情報の形で取得するためには、例えば、ＧＰＳからの情報を処理することで三次元の位置情報が得られる。特に、三次元の位置情報に含まれる標高に関する情報を用いることにより、後述のように、ビルの上位階あるいは地下に関する情報を取得できる。さらに、この位置情報を所定の時間間隔で取得する。

次に、利用者は目的地を入力し、それを基に交通情報ＤＢ１１０にアクセスして三次元情報の形で取得する（３０６）。利用者の三次元情報として得られた現在地及び目的地情報を利用者位置情報発信部２０２が交通手段検索サーバ１０１の交通手段検索部１０６に対し送信する（３０７）。交通情報受信部２０３が、交通手段検索サーバ１０１で検索された交通手段の候補を交通手段検索サーバ１０１より受信する（３０８）。交通情報受信部２０３は交通手段の候補を表示する（３０９）。

図４は交通手段取得クライアント１０２における交通手段表示例のフローである。例として東京国際フォーラムから幕張メッセに行く交通手段をあげる。交通手段候補及び概略を表示する（４０１）。交通手段候補とは東京国際フォーラムの最寄駅及びその候補であるＪＲであれば有楽町駅と東京駅、営団地下鉄であれば有楽町駅と日比谷駅があげられる。また、目的地の最寄駅及びその候補はＪＲ海浜幕張駅があげられる。それぞれをキーとして得られたいくつかの交通手段候補が提示され（図１４のようにタブで選択可能なようにしても良いし、スクロールで表示させるなど、幾つかの方法が考えられる。）、利用者は自分にとって最も適した交通手段を選択する。今回はＪＲ東京駅迄徒歩で移動し、ＪＲ京葉線でＪＲ海浜幕張駅まで移動し、幕張メッセまで徒歩で移動するパターンを選択したとする（４０２）（図１４の候補１）。

ここで、交通手段取得クライアント１０２は交通手段検索サーバ１０１より、選択した交通手段の詳細情報を取得する（４０３）。交通手段取得クライアント１０２は、利用者に対し、最初の経由地点であるＪＲ東京駅の改札口迄のルート情報を地図上にマッピングした形で表示する（４０４）（図１５）。利用者はこのルート情報に従いＪＲ東京駅の改札口迄移動する。駅に到着すると表示される地図情報は駅構内図に切り替わり、当該プラットフォームまでのルート情報を駅構内情報とマッピングして表示する（４０５）（図１６）。

目的地の最寄駅に着くまでこのフローを繰り返す（４０６）。電車で移動中は、利用者が電車に対し絶対的に同じ地点にいるため特に処理はせず「移動中」と表示をする。最寄駅に到着したら当該改札口までのルート情報を駅構内情報とマッピングして表示する（４０７）。改札口まで移動したら目的地地図情報及び目的地点までのルート情報を表示する（４０８）。ルート情報は利用者の現在位置情報に合わせて動的に変化できる（図１７）。このように現在地から目的地までの交通手段及び地図上でのルート情報を提供することにより誰でも迷うことなく移動が可能になる。

図５は契約した内容を呼び出した契約条件画面例である。いくつかのカテゴリーから欲しい条件を選択して契約出来るようになっており、契約条件取得部１０５はこの情報を交通手段取得クライアント１０２から取得する。契約条件は大きく分けて無料の標準メニュー（５０１）のみを申し込むか、有料のオプションメニュー（５０２）も申し込むかを選択することが出来る。有料のオプションメニュー（５０２）を申し込む場合、いくつかのカテゴリーに対し個々にオプションを選択できるようになっている。

この例では標準メニュー（無料メニュー）で「(1)時間優先」と「(3)乗換えが少ない」が契約されている。また、オプションメニュー（有料メニュー）で「（１）バリアフリー設備」の「(1)エレベータ設備有る」（５０３）と「（２）乗換え情報」の「(1)同一プラットフォーム乗換えを優先」（５０４）と「（３）天候を考慮」の「(2)荒天時はタクシー優先」（５０５）が契約されている。サービス開始時に契約条件を変更することが出来、決定キー（５０６）を押下する事により契約条件が確定される。この契約条件によって最終的に配信される交通手段がカスタマイズされる。また、オプションサービスのカテゴリーの数量に伴って課金される。

図６は交通手段検索部１０６のフローである。交通手段検索部１０６は交通手段取得クライアント１０２の利用者位置情報発信部２０２より利用者の現在地情報と目的地情報を経度、緯度、標高からなる三次元の情報として取得し出発地点と目的地を明確に規定する（６０１）。次に、契約条件を契約条件取得部１０５から取得する（６０２）。契約条件には交通手段検索時の基本要素として深く関わる契約と交通手段検索時には関わらないが利用者に付加価値を与えるための契約が有り、図１１に示されるテーブルで規定される。現在地の最寄駅及び最寄駅候補を交通情報ＤＢ１１０に格納されている地図情報より三次元の情報で取得する（６０３）。同様に目的地の最寄駅及び最寄駅候補を三次元の情報で取得する（６０４）。ここで、基本要素として深く関わる契約である交通手段検索時の影響度が大のもの（１１０６）を最寄駅及び最寄駅候補算出に反映させる（６０５）。例えば、天候が悪かった場合、「荒天時はバス優先」となっていたと仮定する。目的地の最寄駅に目的地の傍を通るバスが無く、目的地の二つ前の駅に有るバスならば目的地の傍を通る場合、目的地の二つ前の駅が候補に反映される。

現在地の最寄駅及び最寄駅候補及び目的地の最寄駅及び最寄駅候補を基に交通手段（案）を検索し、乗換駅候補を取得する（６０６）。ここで基本要素として深く関わる契約である交通手段検索時の影響度が中のもの（１１０４）を乗換駅候補に反映させる（６０７）。例をあげると、ベビーカーを用いて幼児と電車に乗る為に、エレベータ設備が有る駅での乗換えを望んだ場合、エレベータ設備の無い新橋駅では乗換えないように反映する（図１２の１２０６）。交通手段（案）にあわせて現在地から現在地最寄駅までの地図を交通情報ＤＢ１１０より取得する（６０８）。現在地から最寄駅までのルート（案）及び距離を算出し（６０９）、目的地最寄駅から同様に目的地までの地図を交通情報ＤＢ１１０より取得する（６１０）。目的地最寄駅から目的地までのルート（案）及び距離を算出する（６１１）。ここで、基本要素として深く関わる契約である交通手段検索時の影響度が小のもの（１１０５）を交通手段（案）に反映させ（６１２）、交通手段候補を完成させる（６１３）。例をあげると、「降車時は階段の近く」（図１１の１１０５）では交通手段（案）を一旦作成した後に、当該車両のどの位置で乗降すべきかの情報を反映する。

図７は交通手段配信部１０７のフローである。交通手段検索部１０６で検索した交通手段候補及び概略を交通手段取得クライアント１０２へ配信する（７０１）。交通手段取得クライアント１０２が交通手段を選択したことを受けて交通手段の詳細情報を交通手段取得クライアント１０２へ配信する（７０２）とともに配信実績を課金ＤＢ１１１へ反映させる（７０３）。

図８は交通情報ＤＢ１１０のテーブル例である。交通情報提供者１０３から提供される公共の交通手段に関する情報が格納されている。駅名（８０１）、駅間の距離（８０２）、駅構内情報（８０３）、事故情報等（８０４）が格納されている。運賃や時刻表は駅名や駅間距離をキーとして別テーブルから参照される。人身事故等によりダイヤが乱れた場合に代替情報を提供するため事故情報等の有無を格納することにより交通手段提供サービスの質を落とさずに提供する。

図９は課金ＤＢ１１１の契約条件のテーブル例である。図５に示した契約条件の画面例の内容を示しており、契約者ＩＤ（９０１）とメニュー種別（９０２）とカテゴリー（９０３）と契約カテゴリー識別子１（９０４）と契約詳細カテゴリー識別子（９０５）からなる。

契約者ＩＤ（９０１）は契約者に割り当てられたユニークな番号である。メニュー種別（９０２）は標準メニューとオプションメニューを表している。カテゴリー（９０３）はオプションメニューの項目を表している。契約カテゴリー識別子１（９０４）はメニュー種別及びカテゴリーに対する契約を示しており、行９０６の場合、１であり標準メニューのカテゴリーが契約されていることを示す。契約詳細カテゴリー識別子（９０５）はカテゴリーを形成する項目に対する契約を示しており、行９０６の場合、「１０１」であり標準メニューの「(1)時間優先」と「(3)乗換えが少ない」が契約されていることを示す。同様に、行９０７の場合、契約カテゴリー識別子１（９０４）は１で契約詳細カテゴリー識別子（９０５）は「１００」であるため、オプションメニュー（有料メニュー）の「（１）バリアフリー設備」が契約されており、その中の「(1)エレベータ設備有る」が契約されている。

図１０は課金ＤＢ１１１の利用実績のテーブル例である。契約者ＩＤ（１００１）をキーとして契約条件のテーブルと連動している。契約者名（１００２）とオプションメニュー有無（１００３）と契約カテゴリー識別子（１００４）と配信カウンタ（１００５）と課金重み付け（１００６）と課金（１００７）からなる。契約カテゴリー識別子（１００４）は契約条件のテーブルの契約カテゴリー識別子１（９０３）の内容を示している。配信カウンタ（１００５）は交通手段を交通情報取得クライアント１０２へ配信したタイミングでカウントアップされる。課金重み付け（１００６）はオプションメニューのカテゴリーの多さに基づいて決定され、行１００８では３カテゴリー、行１００９では０カテゴリー、行１０１０では２カテゴリーが選択されている事を示している。課金（１００７）は配信カウンタ（１００５）と課金重み付け（１００６）の積で表される課金対象となる情報量を示している。

図１１は、課金ＤＢ１１１の交通手段検索時に契約内容を反映させるための情報を格納しているテーブルである。契約項目（１１０１）と交通手段検索時の影響度（１１０２）と条件反映時期（１１０３）からなる。交通手段検索時の影響度（１１０２）とは、図６で示される交通手段の検索フローにおける契約内容毎の交通手段検索における影響度である。影響度は大、中、小で表される。条件反映時期（１１０３）とは、図６で示される交通手段の検索フローにおける契約情報の反映時期を示している。条件反映時期（１１０３）はＡ、Ｂ、Ｃからなり、それぞれ図６のＡ．契約情報の反映（６０５）、Ｂ．契約情報の反映（６０７）、Ｃ．契約情報の反映（６１３）で反映される。

図１２及び図１３はオプションメニューにより提供される各駅の情報を定義したテーブル例である。

図１２はオプションメニューのうちバリアフリー設備のテーブル例である。駅名（１２０１）とエレベータ設備有無（１２０２）とエスカレータ設備有無（１２０３）とバリアフリー設備有無（１２０４）からなる。現在地及び目的地の最寄駅とその候補駅と乗換駅の駅名と駅名（１２０１）をマッチングさせることにより、課金ＤＢ１１１の契約条件のテーブル（図９）の内容と現在地及び目的地の最寄駅とその候補駅と乗換駅が関連付けられる。東京駅の例（１２０５）では、エレベータ設備有無（１２０２）とエスカレータ設備有無（１２０３）とバリアフリー設備有無（１２０４）は全て完備している。新橋の例（１２０６）ではエレベータ設備が無い。

図１３は同一プラットフォーム乗換え可能駅のテーブル例である。

駅名（１３０１）と山手線ホーム（１３０２）と京浜東北線ホーム（１３０３）と東海道本線ホーム（１３０４）からなる。現在地及び目的地の最寄駅とその候補駅と乗換駅の駅名と駅名（１３０１）をマッチングさせることにより、課金ＤＢ１１１の契約条件のテーブル（図９）の内容と現在地及び目的地の最寄駅とその候補駅と乗換駅が関連付けられる。東京駅の例（１３０５）では、山手線ホームと京浜東北線ホームは共にＡであることより同一プラットフォームである。品川駅の例（１３０６）では、山手線ホームと京浜東北線ホームと東海道本線ホームはそれぞれＡ、Ｂ、Ｃである事よりそれぞれが異なるプラットフォームである。

図１４は交通手段検索サーバ１０１から配信された交通手段候補の例である。交通手段検索サーバ１０１から複数の交通手段及び概要が配信される。ここでは二つの交通手段の候補を例にあげる。一つ目（１４０１）は、ＪＲ東京駅まで徒歩で移動し（１４０３）、ＪＲ京葉線でＪＲ京浜幕張駅まで電車で移動し（１４０４）、幕張メッセまで徒歩で移動する（１４０５）例である。移動時間の合計（１４０６）は４７分である。もう一つ（１４０２）は、ＪＲ有楽町駅まで徒歩で移動し（１４０７）、ＪＲ山手線で東京駅まで電車で移動し（１４０８）、ＪＲ東京駅の山手線のプラットフォームからＪＲ京葉線のプラットフォームまで徒歩で移動し（１４０９）、ＪＲ京葉線でＪＲ京浜幕張駅まで電車で移動し（１４１０）、幕張メッセまで徒歩で移動する（１４１１）例である。移動時間の合計（１４１２）は５７分である。現在地から最寄駅までの移動時間はＪＲ有楽町駅迄が１分、ＪＲ東京駅迄が３分であり、ＪＲ有楽町駅迄移動する方が楽に移動出来そうであるが、実際にはＪＲ東京駅迄移動する方が移動時間の合計は少ない。利用者は交通手段候補より自分に合った交通手段を選択し、決定ボタン（１４１３）を押下する。決定ボタンを押下する事によって詳細情報が交通手段検索サーバ１０１より配信される。

図１５は詳細情報として得られた、ルート情報と地図をマッピングした例である。利用者の現在地（１５０１）と最寄駅であるＪＲ有楽町駅（１５０２）及び最寄駅候補であるＪＲ東京駅（京葉線）（１５０３）、営団地下鉄有楽町駅（１５０４）が地図上に示される。利用者が決定した交通手段に応じて、最初に行くべき経由地点迄のルートが地図上にマッピングされる（１５０５）。

図１６は駅構内図の例である。利用者が地図上にマッピングされたルートに従って移動し、経由地である駅に到着すると交通情報ＤＢ１１０のテーブルより選択された駅構内情報（８０３）が表示される。駅構内情報は階層別に作成される。この例では地上階（１６０１）と地下一階（１６０２）と地下二階（１６０３）を示す。駅構内情報には利用者の現在地（１６０４）と当該プラットフォームに至るまでのルート（１６０５）がマッピングされて示される。

図１７は、地図上にマッピングされた利用者の現在地とルート情報が動的に変化することを示した例である。初期情報と利用者が移動したＴ秒後の情報を比較するために、初期情報を破線でＴ秒後の情報を実線で示す。交通手段検索サーバ１０１より交通手段を受信した直後は利用者の現在地（１７０１）と経由地である駅までのルート情報が表示される（１７０２）。ルート情報は利用者の現在位置情報にあわせて動的に変化し、Ｔ秒後の利用者の現在地（１７０３）の場合、ルート情報も変化する（１７０４）。

本発明の全体構成図である。交通手段取得クライアントの詳細図である。交通情報取得クライアントの操作のフローである。交通情報取得クライアントにおける交通手段表示例のフローである。契約条件の画面例である。交通手段検索部１０６のフローである。交通手段配信部１０７のフローである。交通情報ＤＢのテーブル例である。契約条件のテーブル例である。課金ＤＢの利用実績のテーブル例である。交通手段検索時に契約内容を反映させるための情報を格納しているテーブルである。バリアフリー設備のテーブル例である。同一プラットフォーム乗換え可能駅のテーブル例である。交通手段検索サーバから配信された交通手段候補の例である。ルート情報と地図をマッピングした例である。駅構内図の例である。現在地とルート情報が動的に変化することを示した例である。

符号の説明

１０１：交通手段検索サーバ
１０２：交通手段取得クライアント
１０３：交通情報提供者
１０４：ネットワーク
１０５：契約条件取得部
１０６：交通手段検索部
１０７：交通手段配信部
１０８：課金部
１０９：情報格納ＤＢ
１１０：交通情報ＤＢ
１１１：課金ＤＢ
２０１：契約条件発信部
２０２：利用者位置情報発信部
２０３：交通情報受信部

Claims

交通手段取得クライアントにより利用者の現在地を取得する現在位置取得システムは、
利用者の現在地を経度、緯度、標高を含む三次元の情報として所定の時間間隔で取得する手段と、
前記情報を交通手段検索サーバに渡す手段を有することを特徴とする現在位置取得システム。
情報伝達システムは、
ネットワークを介して利用者の求める契約条件をパラメータ化して取得する手段と、
前記契約条件に基づいて、利用者の現在地及び目的地の最寄駅とその候補に関する情報を取得する手段と、
前記候補を交通手段検索サーバに渡す手段を有することを特徴とする情報伝達システム。
ネットワークを介して交通手段を配信する配信システムにおいて、
パラメータ化された利用者の契約条件によって交通手段を生成する手段と、
前記交通手段を交通情報取得クライアントに渡す手段を有することを特徴とする配信システム。
ネットワークを介して交通手段に対する課金を制御する課金システムにおいて、
前記交通手段の利用者に対する価値の重み付けに対する価値を課金に反映する手段を有することを特徴とする課金システム。
利用者の位置情報を取得し、目的地に関する情報検索ための契約条件を送付し、受け取った情報に基づいて前記目的地に関する交通手段を選択し、前記目的地内での利用者の移動に応じて前記受け取った情報を表示する少なくとも１つのクライアントと、
前記クライアントからの契約条件に基づいて前記目的地に関する交通手段の候補を決定し、前記候補に関する情報を前記クライアントに送付し、前記情報に応じた課金を利用者ごとに処理するサーバとを有することを特徴とする交通手段情報提供システム。
少なくとも１つのクライアントと前記クライアントに交通手段情報を提供するサーバからなる計算機システムにおいて、
前記クライアントは、利用者の位置情報を取得し、目的地に関する情報検索ための契約条件を前記サーバに送付し、
前記サーバは、前記クライアントからの契約条件に基づいて前記目的地に関する交通手段の候補を決定し、前記候補に関する情報を前記クライアントに送付し、
前記クライアントは、前記目的地内での利用者の移動に応じて前記受け取った情報を表示し、
前記サーバは、前記情報に応じた課金を利用者ごとに処理することを特徴とする交通手段情報提供方法。