JP2018147282A - 利用者と車両のマッチングを促進するシステムにおける管理サーバ、表示方法及びプログラム - Google Patents

Abstract

【課題】立体的かつ多くの建物が存在する３次元のマップ上で、マッチングした利用者と車両の対（ペア）を容易に確認できる方法を提供する。【解決手段】利用者と利用者が乗りたい車両をマッチングさせるシステムにおける管理サーバ１００が、利用者の乗車要求及び車両の位置情報に基づいて、乗車要求にマッチした車両を探索する利用者／車両マッチング手段１０４と、利用者及びマッチした車両の位置情報を含む３Ｄマップを生成する３Ｄマップ生成手段１０５と、表示する３Ｄマップから、利用者とマッチした車両の周辺にある建物等の立体画像を除去又は透視して表示する建物等除去／透視表示手段１０６と、を備える。ここで、利用者／車両マッチング手段１０４は、利用者と車両がマッチしたことを示す画像を３Ｄマップ上に表示する。【選択図】図３

Description

本発明は、利用者と利用者が乗りたい車両のマッチングを促進するシステムに関する。

従来、バス、タクシー、トラック等の交通手段や運送手段を探すとき、利用者に運送手段呼出サービスを提供する技術や、利用者が利用を希望する車両に対する車両要求と車両とのマッチングを行う技術が知られている。

例えば、特許文献１には、運送手段呼出サービスを提供する運送手段呼出サーバ、それを有する運送手段呼出サービスシステム及びそれを用いた運送手段呼出サービス方法が開示されている。

また、特許文献２には、複数の車両の各々の現在場所を示すデータにアクセス可能なサーバで車両要求を管理する方法であって、複数の車両要求をサーバで受信することと、複数の車両要求を各々が含む１つ以上のクラスタを生成することと、このクラスタ又は各クラスタ中の各車両要求と車両をマッチングすることとを備えることを特徴とする方法が開示されている。

特表２０１６−５０９２８７号公報 特開２０１７−３３５６８号公報

ところで、国が官民ＩＴＳ構想・ロードマップ２０１６で提示しているように、「限定地域での無人自動走行移動サービス」の実現に向けた取り組みが加速している。これは、制限された区域（限定地域）内において、地域公共交通に近いイメージのサービスを行おうとするものであり、基本的には、限定地域内から地域公共交通までをつなぐ移動手段という想定であるが、自宅玄関前からの乗降の可能性も検討されている。すでに大学や企業による公道での自動走行技術実証も進められており、この流れでいけば、政府のロードマップのとおり、２０２０年度にはサービスが普及し始めているかもしれないと、期待されている。ただし、一般道路を含む完全無人自動化にはまだまだ困難な課題が多く、限定地域で人間が同乗して自動化の試みが今後も続くと予想される。

発明者らは、主に以下の３つの社会的課題を意識し、実社会に組み込まれる無人自動走行移動サービスの早期立ち上げをめざして、地域交通事業者とともに実証実験を実施してきた。
１）バスやタクシーの運転手不足時代の到来という深刻な社会的課題
２）利用者の減少から運転手人件費が負担となり、公共交通が維持できない地域が加速的に増大
３）生活密着型の新しい移動手段がないと、急速に進む高齢化時代を支えられない

その中で、自動走行移動サービスの具体的課題の一つとして、利用者と利用者が乗りたい車両のマッチングを促進させる技術が重要であるとの認識に至った。しかし、単なる２次元のインターネット地図上だけで車両や自分の位置を把握しようとしても、車両がどこにあるのか、これから来るのか、行ってしまったのか、また自分がどこに居るのかが把握できず、利用者と車両との適切なマッチングの確認ができないケースがあった。このことは、車両が無人運転か有人運転かにはよらない。

したがって、本発明では、上記のような課題にかんがみ、将来の無人自動走行サービスの実現を見据えつつ、現在の有人での走行サービスにおいても適用可能な、立体的かつ多くの建物が存在する３次元のマップ上で、マッチングした利用者と車両の対（ペア）を容易に確認できる方法を提供することを目的とする。

上記課題を解決するため、本発明は、以下のような解決手段を提供する。

（１）利用者と前記利用者が乗りたい車両をマッチングさせるシステムにおける管理サーバであって、前記利用者の乗車要求及び車両の位置情報に基づいて、前記乗車要求にマッチした車両を探索する利用者／車両マッチング手段と、前記利用者及び前記マッチした車両の位置情報を含む３Ｄマップを生成する３Ｄマップ生成手段と、前記３Ｄマップから前記利用者と前記マッチした車両の周辺にある建物等（ビル、家屋、橋、駅、その他建造物）の立体画像を除去又は透視して表示する建物等除去／透視表示手段と、を備え、前記利用者／車両マッチング手段は、前記利用者と車両がマッチしたことを前記３Ｄマップ上に表示することを特徴とする。

（２）上記（１）の構成において、前記建物等除去／透視表示手段は、前記利用者の視点又は前記マッチした車両の運転者の視点からの３Ｄマップを表示することを特徴とする。

（３）上記（１）又は（２）の構成において、前記建物等除去／透視表示手段は、前記３Ｄマップ上で、停留所、信号機、道路標識、道路工事設置物等の道路交通に関係する物体である交通設置物が選択されたことに応じて、当該交通設置物に関連する情報を表示することを特徴とする。

（４）上記（１）〜（３）の構成において、前記利用者／車両マッチング手段は、前記マッチした車両に乗車する乗車地点及び前記乗車地点への当該車両の到着時間を予測して表示することを特徴とする。

（５）上記（１）〜（４）の構成において、前記利用者／車両マッチング手段は、前記マッチした車両が前記利用者の乗車要求に応じて移動していること表示することを特徴とする。

（６）上記（１）〜（５）の構成において、前記利用者／車両マッチング手段は、前記利用者の画像と前記マッチした車両の画像とを線分で結んだ線画像を表示することを特徴とする。

（７）上記（１）〜（６）の構成において、前記利用者／車両マッチング手段は、夜間の場合は前記利用者又は前記マッチした車両をスポットライトで照らしたように表示することを特徴とする。

（８）利用者と前記利用者が乗りたい車両をマッチングさせるシステムにおける表示方法であって、前記利用者の乗車要求及び車両の位置情報に基づいて、前記乗車要求にマッチする車両を探索する段階と、前記利用者及び前記マッチした車両の位置情報を含む３Ｄマップを生成する段階と、前記３Ｄマップから前記利用者と前記マッチした車両の周辺にある建物等（ビル、家屋、橋、駅、その他建造物）の立体画像を除去又は透視して表示する段階と、を含み、前記マッチする車両を探索する段階において、前記利用者と車両がマッチしたことを前記３Ｄマップ上に表示する段階を含むことを特徴とする。

（９）利用者と前記利用者が乗りたい車両をマッチングさせるシステムのプログラムあって、上記（８）に記載の各段階をコンピュータに実行させることを特徴とする。

本発明によれば、立体的かつ多くの建物が存在する３次元のマップ上で、マッチングした利用者と車両の対（ペア）を容易に確認できる方法を提供することができる。

本発明の実施形態に係る「利用者／車両マッチングシステム」の基本イメージを示す図である。 本発明の実施形態に係る「利用者／車両マッチングシステム」の基本イメージを示す続図である。 本発明の実施形態に係る「利用者／車両マッチングシステム」を制御する中核となる管理サーバの機能構成を示す図である。 本発明の実施形態に係る管理サーバのデータベース（ＤＢ）に格納されるデータの構成を示す図である。 利用者と車両のマッチングの処理フローを示す図である。 利用者の乗車リクエストの入力画面の例を示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号又は符号を付している。また、機能構成の図において、機能ブロック間の矢印は、データの流れ方向又は処理の流れ方向を表す。

（サービスの基本イメージ）
図１、図２は、本発明の実施形態に係る「利用者／車両マッチングシステム」(以下、「本システム」と呼ぶ。）が提供するサービスの基本イメージを示す図である。ここでいう「マッチング」とは、利用者と利用者が利用したい車両との間で、お互いの条件が適合することを意味する。

図１、図２の各図は、本システムが、利用者１０(車両の利用希望者）が所持する端末に表示する画面イメージである。ここで表示するのは、市街地又は非市街地を走行／停車／駐車する複数の車両の立体画像、当該車両の周辺又は利用者１０の周辺の、「建物等」（ビル、家屋、橋、駅、その他建造物）の立体画像を含む３次元マップ（３Ｄマップ）である。３次元マップであるので、当然、前後左右上下のあらゆる角度からの画像（動画を含む）の描写が可能である。また、３Ｄマップの視点は、利用者１０からの視点だけでなく、車両２０からの視点、その他、任意の場所からの視点にセット可能である。真上からの視点にセットすれば、普通の２次元マップになる。以下、３Ｄマップの様々な表示方法について説明する。

図１（ａ）では、上記３Ｄマップ上で、利用者１０の視界を遮る「建物等」を表示せず、車両２０（乗用車、バス、タクシー、トラック、自動二輪車、コミュニティビークル等）、及び停留所、信号機、道路標識、道路工事設置物等の道路交通に関係する物体（以下、「交通設置物」と呼ぶことにする。）を表示している。ここで、コミュニティビークル（Community vehicle：以下「ＣＶ」と略す。）とは、特定の地域でのみ使用される自動車であり、オンデマンドで運行するコミュニティバス、送迎等で使用される一般車を含み、有人車であるか、無人車であるかは問わない。また、図１、図２では、「交通設置物」として、バス停２１、タクシー乗り場２２のみを簡略化して示している。

また、図１（ａ）の点線２３で示すように、利用者１０とマッチングした車両２０は、両者がマッチしたことを示す線画像を、あたかも両者が「赤い糸」で結ばれたように、表示してもよい。図１（ａ）の表示画面を見た利用者１０は、視界に入っている車両はもちろん、建物等で遮られ視界に入らない車両や停留所等も容易に確認（発見）することができる。

図１（ｂ）は、周辺にある建物等の立体画像をすべて除去して表示するのではなく、道路や建物の境界線だけのデータ（高さ方向のデータがないＤＢ）を用いることによって、道路や建物の境界線だけで奥行きを持たせた表示をさせるようにしたものである。このようにすることで、図１（ａ）の表示方法よりも、建物等の形状が明確になるので、自分の位置や車両の位置が把握しやすい。

図１（ｃ）は、図１（ａ）のように建物等の画像を完全に除去するのではなく、建物等の立体的な輪郭（フレームの画像）だけを表示するようにしたものである。すなわち、利用者１０は、視界を遮る建物等を透視することができる。建物等の画像を完全に除去すると、車両や道路の状況の確認は容易になるが、一方で、周辺の建物等の輪郭を表示するほうが位置関係を把握するのには有利になることが多い（特に高低差がある場合）。本システムは、利用者１０の選択により、図１（ａ）、図１（ｂ）、図１（ｃ）のどの３Ｄマップも表示することができる。なお、街路樹や植木等は建物等や交通設置物の概念には含まれないが、視界を遮る物体となる場合もあるので、対象とする街や地域の視界の環境に応じて、建物等に含めてもよいし、交通設置物に含めてもよい（図では後者を採用している。）。

図２（ａ）は、マッチングした利用者１０と車両２０を線画像で結ぶ代りに、両者をスポットライトで照らしたように表示した３Ｄマップである。この処理は、利用者１０の端末が周囲の明るさを検知し、夜間ではこちらの表示画面に自動的に切り替えるようにしてもよい。

図２（ｂ）は、マッチした車両２０が、利用者１０からの乗車要求（乗車リクエスト）に応えて、利用者１０が待機している場所へ移動中であることを表示した画面である。このようにすることで、利用者１０は、対象の車両２０が現在どこを走っているのか、自分のほうに向かっているのか、遠ざかっているのか、渋滞に捕っていないか等を容易に把握することができるので、イライラせず安心感をもって、乗車予定地点で待つことができる。

このようにすることで、対象車両が視界に入っていなくても、例えば渋滞時には、乗車予定地点にかかわらず、車両２０に利用者自ら近づいていって乗車することができる。また、このとき、利用者１０が待機している場所が、一方通行や道路工事等で、車両２０の移動方向からは進入が困難なときは、最寄りの進入可能な場所（図中のＰ点）まで移動してもらうように、利用者１０に促すことも可能となる。

また、図示は省略するが、ホテル若しくは旅館、又は家族若しくは知人の車両に送迎してもらうときは、乗車希望場所（ピックアップ地点）又は降車希望場所（ドロップオフ地点）を利用者１０の端末から地図上でタッチすれば、その場所が車両の車載端末に表示されるようにしてもよい。逆に、車両の運転者から、ピックアップしやすい場所をタッチして、その情報を画像とともに利用者１０の端末に送信するようにしてもよい。また、このとき、ピックアップ地点やドロップオフ地点に所定の画像（これを「バーチャル停留所」と呼ぶことにする。）を３Ｄマップ上に表示するようにしてもよい。

図２（ｃ）は、利用者１０が車両２０ではなく、バスかタクシーを利用しようと思ったときに、バスの発車時刻、タクシーの利用料金等の情報を表示した画面である。例えば、図２（ｃ）で、バス停２１をタッチすると、そのバス停の時刻表、路線図、行先、運行状況等が表示されるようにしてもよい。また、タクシー乗り場２２をタッチすると、目的地までの料金や所要時間を表示するようにしてもよい。すなわち、交通設置物がタッチされたことに応じて、当該交通設置物に関連する情報を表示する。なお、このとき、高齢者や身体障害者を考慮し、利用者１０が必要な情報を入力する手間は、必要最小限にすることが望ましい。

また、例えば、利用者の希望する目的地が「Ｂ病院」であった場合、バス停をタッチすると、図２(ｃ）のように「Ｂ病院までは1250円です。」と表示してくれる。従来の乗車案内等のシステムでは、目的地を入れたら、どこのバス停に移動して、どこのバス停で降車して、徒歩でこのルートを歩きなさい、というように、最初から最後までを指示する回答が返ってくるものが普通である。一方で、本システムでは、例えば、「その先のバス停で行けますよ」などと人に聞いたときに、よく見ると目に入るバス停が二つあるという場合、一方のバス停をタッチすると、「Ｂ病院には行きません。」もう一方のバス停をタッチすると、「Ｂ病院行きです。料金は1250円です。」と表示することもできる。すなわち、全てをコンピュータから指示されるのではなく、インタラクティブな操作をする方が現場では分り易いことがあるので、このような場合にも対応できる。

以上のような人と車のマッチングの表示方法によって、生活密着型のきめ細かな交通サービスを提供することができる。

（機能構成）
図３は、本発明の実施形態に係る利用者／車両マッチングシステム（本システム）における管理サーバ１００の機能構成を示す図である。本システムは、管理サーバ１００を中核として、利用者端末１０と車載端末２０とがネットワーク３０で接続されるシステムである。

図示するように、管理サーバ１００（以下、単にサーバと呼ぶ）は、機能実行部として、位置情報取得手段１０１、利用者要求取得手段１０２、車両情報取得手段１０３、利用者／車両マッチング手段１０４、３Ｄマップ生成手段１０５、建物等除去／透視表示手段１０６、車両運行情報取得手段１０７を備えている。利用者端末１０は、スマートフォンやタブレット端末等の一般的な携帯端末であってもよいし、本システム専用の簡易端末であってもよい。また、車載端末２０は、車両に搭載された任意の情報端末装置であり、例えば、カーナビゲーションシステムであってもよい。

位置情報取得手段１０１は、利用者端末１０及び乗車サービスを提供する車両の位置情報を逐次取得する。利用者要求取得手段１０２は、利用者端末１０からの乗車要求（乗車リクエスト）を取得する。車両情報取得手段１０３は、車両の位置情報以外の様々な情報(例えば、車種、乗車定員、種別等）を取得する。

利用者／車両マッチング手段１０４は、利用者要求取得手段１０２が取得した利用者要求と、車両の位置情報を含む車両情報とに基づいて、利用者と車両のマッチングを行う。マッチングした車両が複数ある場合は、利用者が選択する手段を備える。また、マッチングの優先項目（例えば、到着時間優先、利用料金優先、乗り心地優先等）を指定できるようにしてもよい。

３Ｄマップ生成手段１０５は、前述した３Ｄマップの生成を行い、建物等除去／透視表示手段１０６は、建物等の画像の全部の除去、境界線を残しての部分除去、又は建物等を透視するためのフレーム画像を生成して利用者端末１０に表示させる。また、建物等除去／透視表示手段１０６は、３Ｄマップ上で前述の交通設置物が選択（例えば、画面上でタッチ）されたことに応じて、当該交通設置物に関連する情報を表示するようにしてもよい。このとき、図示は省略するが、交通設置物に対して利用者が望む情報を取得する手段、及び交通設置物に関連する情報を取得する手段を備えるのは言うまでもない。

車両運行情報取得手段１０７は、車両の運行情報、並びに乗車地点までの到着時間及び目的地点までの所要時間を予測する。定期運行の車両の場合は時刻表も取得する。その他、図示は省略するが、道路情報取得手段、等を備えていてもよい。取得した情報は、３Ｄマップに合成して利用者端末１０に表示させるようにしてもよい。

詳細は後述するが、サーバは、上記の機能実行部が処理に必要な各種データを格納するデータベース（ＤＢ）として、利用者の情報を格納する利用者ＤＢ１１１、車両の情報を格納する車両ＤＢ１１２、３次元の地図データを格納する３Ｄ地図データＤＢ１１３、公共交通機関等の運行情報を格納する交通機関運行情報ＤＢ１１４を備えている。

図４は、本発明の実施形態に係る管理サーバのデータベース（ＤＢ）に格納されるデータの構成を示す図である。図４では各ＤＢはサーバ側にあるものとしているが利用者端末側に一部又は全部があってもよい。

利用者ＤＢ１１１は、利用者の静的な情報をプロフィール情報１１１ａとして、格納している。具体的には、ユーザＩＤをはじめとして、マッチングをより精緻に行うための情報である、住所氏名、年齢、性別、喫煙の有無、趣味等が含まれる。これらのプロフィール情報は必須ではないが、例えば、年齢、性別、喫煙の有無が登録されていると、より利用者に適した車両をマッチングできる。また、利用者ＤＢ１１１には、そのときどきによって変化する動的情報１１１ｂとして、現在位置(利用者の位置情報）、本サービスを利用したことによって獲得できる獲得ポイント、相乗りの可否、相乗りした場合の同乗者情報、乗車履歴が含まれるようにしてもよい。

車両ＤＢ１１２は、車両の静的な情報をプロフィール情報１１２ａとして、格納している。具体的には、車両ＩＤをはじめとして、車両の所属（所有者）、種別（バス、乗用車、トラック等）、属性（営業用、個人用）、車種、乗車定員、燃費、自動走行タイプ（自動走行の可否、可の場合は有人運転か無人運転かの情報）、車両の管理者等の情報が格納される。これらのプロフィール情報は必ずしもすべてが必要なわけではないが、情報量が多いほど、より利用者の要求に適した車両をマッチングできる。また、車両ＤＢ１１２には、動的情報１１２ｂとして、現在位置（車両の位置情報）、走行速度、走行ルート（移動経路）、走行履歴等が含まれるようにしてもよい。一般車の場合は、その他の情報、例えば、乗客の情報を含ませてもよい。

交通機関運行情報ＤＢ１１４は、定期運行する車両（主に公共交通機関）の情報を格納したものであり、プロフィール情報１１４ａとして、交通機関ＩＤをはじめとして、交通機関種別（路線バス、高速バス、シャトルバス、タクシー、コミュニティバス等）、車両保有台数、保有する車両ごとの所属車両ＩＤ等が含まれる。なお、車両は、自動車に限らず電車であってもよい。例えば、路面電車のような車両であってもよい。これらのプロフィール情報も必ずしもすべてが必要なわけではない。また、交通機関運行情報ＤＢ１１４には、動的情報１１４ｂとして、路線ごとの、時刻表、走行車両ＩＤ、及び運行状況が含まれるようにしてもよい。交通機関運行情報ＤＢ１１４に格納された情報は、前述の車両運行情報取得手段１０７によって、必要なタイミングで、利用者端末１０に送信される。

上記の本システムの機能構成は、あくまで一例であり、一つの機能ブロック（データベース及び機能実行部）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＳＳＤ(Solid State Drive)、ハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。また、ここでいうプロログラムは、サーバ側のプログラム（管理プログラム）であってもよいし、端末側のプログラム（アプリケーション）であってもよい。

（処理フロー）
図５は、利用者と車両のマッチングを行うときのサーバが実行する処理フローを示す図である。以降の処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。また、以下では符号の記載は省略する。

ステップＳ１０：利用者端末からの乗車リクエストを受信するまで待機する。

ステップＳ１１：乗車リクエストを受信すると、乗車リクエストに含まれるユーザＩＤから、利用者ＤＢの利用者情報を取得する。乗車リクエストはユーザＩＤがなくても受け付けることができるが、そのときは、車両とのマッチングに必要な最低限の情報（出発地点、目的地点、乗車希望地点（出発地点と異なる場合）、出発希望時刻又は到着希望時刻、乗車人数）が入っているかをチェックし、必要な情報が入っていなければ、利用者に不足している情報の入力を求める。このとき、入力を必要最小限とするため、出発地点のデフォルトは、利用者の現在位置とし、出発希望時刻及び到着希望時刻のデフォルトは、「できるだけ早く」とし、乗車人数のデフォルトは、１人等としてもよい。

ステップＳ１２：乗車リクエストにマッチした車両を車両ＤＢから探索する。なお、乗客を待って待機中の車両から乗客希望リクエストを受け付けるようにしてもよい。

ステップＳ１３：マッチした車両が見つかったかどうかを判断する。完全に条件に一致しなくても所定の範囲で近い車両が見つかればそれも探索結果に含めてもよい。

ステップＳ１４：マッチした車両が見つからなかった場合は、その旨を利用者端末に送信し、その後ステップＳ１０に戻り、乗車リクエストの修正を求める。利用者は、場合によっては乗車リクエストを修正し、場合によっては乗車を諦めることになる。

ステップＳ１５：マッチした車両があれば、その中から利用者が乗車したい車両の選択を受け付ける。以後、選択車両の位置情報の追跡を開始する。車両の移動ルートは、サーバが指示することはないが、予想移動ルート上に渋滞や事故が発生している場合は、その旨を車両及び利用者に送信してもよい。また、必要であれば乗車希望地点を変更する。

ステップＳ１６：最終的な乗車場所周辺（所定範囲）の３Ｄ地図データを取得する。ここで所定範囲は、走行地域によって異なるが、通常は数百メートルから数キロメートル四方とする。

ステップＳ１７：取得した３Ｄ地図データから利用者端末に表示する３Ｄマップを生成する。このとき、建物等の画像を除去又は透視した３Ｄマップを生成する。

ステップＳ１８：生成した３Ｄマップを利用者及び車両の端末に送信する。３Ｄマップはすべてベクトルデータなので、端末側で任意に拡大、縮小、回転、変形、クリッピング等ができる。

ステップＳ１９：車両が走行している地点（走行地点）、又は乗車地点付近の情報があれば利用者端末に送信する。端末側では受信した情報を３Ｄマップ上に逐次表示する。

（画面例）
図６は、利用者の乗車リクエストの入力画面の例を示す図である。利用者と車両とのマッチングを行うには、利用者が求める要求をいかに多くかつ簡単に入力できるかが問題となる。そのためには様々な手段が考えられるが、ここでは、まず図６（ａ）に示す車両リクエスト（選択形式）の画面例を紹介する。この画面では、ユーザが個々の項目を入力する手間をできるだけ簡単にするために、文字入力は行わず、画面上の各項目の選択ボタンを押すだけで、必要な情報が入力できるようになっている。利用者がよく利用する選択肢ほど上位にくるように選択ボタンの順序が入れ替わる。また、高齢や視覚障害のある利用者のために文字やボタンはできるだけ大きいもの、ビジュアル的に目立つものを使用する。

図６（ｂ）は、選択形式ではなく、対話形式で乗車リクエストを作成するための画面である。この画面は、ＬＩＮＥ（登録商標）の友達同士の会話のような感覚で乗車リクエストが作成できる。ここでは文字をキー入力してもよいし、音声で文字を入力するようにしてもよい。

図のようにいちいち質問に答えるのが煩わしい場合は、「Ｂ病院に今すぐ行きたい」等の、一言で済ますこともできる。この場合は、利用者がよく使う基本フレーズを利用者ＤＢ１１１に登録しておくことで、また、その基本フレーズを組み合わせて様々なリクエストを合成することもできる。例えば、「病院」は「Ｂ病院」であることが登録されていれば、「病院、今すぐ」というだけでも乗車リクエストが自動的に生成される。このようにすることで、利用者と車両が友達のように対話し、あたかも「二人の世界」の会話のようにして、乗車リクエストを生成することができる。

（実施形態の効果）
本システムによれば、立体的かつ多くの建物が存在する３次元のマップ上で、自分の乗りたい車両の情報を利用者が容易に確認できる方法を提供することができる。視界を遮る建物等の画像を除去したり透視したりして３Ｄマップ上に表示するので、目的の車両や乗車地点等を容易に確認できる。また、乗りたい車両が近づいてきているのか、遠ざかって行くのかも容易に確認できる。

また、３Ｄマップ上で任意の地点に車両に乗る際のバーチャルな待合わせ場所（バーチャル停留所）を設定することもできる。また、利用者と車両の関係をビジュアルに表現することができる。例えば、利用者とマッチした車両を、あたかも「赤い糸」で結ばれているかのように、線分で結びつけて表現したり、夜間にはスポットライトで照らしたように、表現したりすることができる。また、利用者と車両が友達のように対話し、あたかも「二人の世界」の会話のようにして、乗車リクエストを生成することができる。このようすることで、地域を走行する車両サービスを利用者により親しみがわく密接なものとすることができる。

なお、上記の実施形態では、利用者と車両のマッチングシステムについて説明したが、本システムのマッチングの表示方法（「赤い糸」）は、他の用途、例えば、利用者とレストラン等の飲食店とのマッチング、人と人とのマッチング、車以外の物と人とのマッチングにも応用が可能である。

人の人とのマッチングは、初めて会う人と人、長期に会ってない人と人（１０年会っていない孫、２０年ぶりの同級生など）にも有効である（長い間合わないとすっかり様子が変わっている場合があるからである）。また、車以外の物と人とのマッチングとは、例えば、ピザの宅配と客などである。また、海外など見知らぬ街で予約した電車に乗るときは、まず駅舎と乗客、次に駅舎に入った後は複数のホームに停車する列車の中の一つの列車と乗客、最後に列車の中の座席と乗客、を「赤い糸」で結んで、目的物の見え方によって段階的に「赤い糸」の接続先を変えてもよい。また、バスの場合は、最初にバス停と結び、乗るべきバスが近づいて来たらバスと「赤い糸」で結ぶようなことができる。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されないことは言うまでもない。上記実施形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。また、その様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

なお、上記の実施形態では、本発明を物の発明として、利用者／車両マッチングシステムにおける管理サーバについて主に説明したが、本発明は、方法の発明（マッチングの表示方法）又は上記表示方法のそれぞれの段階をコンピュータに実行させるプログラムの発明（マッチングのプログラム）としても捉えることもできる。

１０ 利用者（又は利用者端末）
２０ 車両（又は車載端末）
２１ バス停
２２ タクシー乗り場
２３ 利用者と車両がマッチしたことを示す線画像（赤い糸）
３０ ネットワーク
１００ 管理サーバ
１０１ 位置情報取得手段
１０２ 利用者要求取得手段
１０３ 車両情報取得手段
１０４ 利用者／車両マッチング手段
１０５ ３Ｄマップ生成手段
１０６ 建物等除去／透視表示手段
１０７ 車両運行情報取得手段
１１１ 利用者ＤＢ
１１２ 車両ＤＢ
１１３ ３Ｄ地図データＤＢ
１１４ 交通機関運行情報ＤＢ
１１１ａ，１１２ａ，１１４ａ プロフィール情報
１１１ｂ，１１２ｂ，１１４ｂ 動的情報

Claims (9)

1. 利用者と前記利用者が乗りたい車両をマッチングさせるシステムにおける管理サーバであって、
   前記利用者の乗車要求及び車両の位置情報に基づいて、前記乗車要求にマッチした車両を探索する利用者／車両マッチング手段と、
   前記利用者及び前記マッチした車両の位置情報を含む３Ｄマップを生成する３Ｄマップ生成手段と、
   前記３Ｄマップから前記利用者と前記マッチした車両の周辺にある建物等（ビル、家屋、橋、駅、その他建造物）の立体画像を除去又は透視して表示する建物等除去／透視表示手段と、を備え、
   前記利用者／車両マッチング手段は、前記利用者と車両がマッチしたことを前記３Ｄマップ上に表示することを特徴とする管理サーバ。
2. 前記建物等除去／透視表示手段は、前記利用者の視点又は前記マッチした車両の運転者の視点からの３Ｄマップを表示することを特徴とする請求項１に記載の管理サーバ。
3. 前記建物等除去／透視表示手段は、前記３Ｄマップ上で、停留所、信号機、道路標識、道路工事設置物等の道路交通に関係する物体である交通設置物が選択されたことに応じて、当該交通設置物に関連する情報を表示することを特徴とする請求項１又は２に記載の管理サーバ。
4. 前記利用者／車両マッチング手段は、前記マッチした車両に乗車する乗車地点及び前記乗車地点への当該車両の到着時間を予測して表示することを特徴とする請求項１から３までのいずれか１項に記載の管理サーバ。
5. 前記利用者／車両マッチング手段は、前記マッチした車両が前記利用者の乗車要求に応じて移動していること表示することを特徴とする請求項１から４までのいずれか１項に記載の管理サーバ。
6. 前記利用者／車両マッチング手段は、前記利用者の画像と前記マッチした車両の画像とを線分で結んだ線画像を表示することを特徴とする請求項１から５までのいずれか１項に記載の管理サーバ。
7. 前記利用者／車両マッチング手段は、夜間の場合は前記利用者又は前記マッチした車両をスポットライトで照らしたように表示することを特徴とする請求項１から６までのいずれか１項に記載の管理サーバ。
8. 利用者と前記利用者が乗りたい車両をマッチングさせるシステムにおける表示方法であって、
   前記利用者の乗車要求及び車両の位置情報に基づいて、前記乗車要求にマッチする車両を探索する段階と、
   前記利用者及び前記マッチした車両の位置情報を含む３Ｄマップを生成する段階と、
   前記３Ｄマップから前記利用者と前記マッチした車両の周辺にある建物等（ビル、家屋、橋、駅、その他建造物）の立体画像を除去又は透視して表示する段階と、を含み、
   前記マッチする車両を探索する段階において、前記利用者と車両がマッチしたことを前記３Ｄマップ上に表示する段階を含むことを特徴とする表示方法。
9. 請求項８に記載の各段階をコンピュータに実行させることを特徴とするプログラム。