JP4458453B2

JP4458453B2 - 相乗り仲介管理装置及びそのプログラム

Info

Publication number: JP4458453B2
Application number: JP2001229003A
Authority: JP
Inventors: 労雄山内
Original assignee: Casio Computer Co Ltd
Current assignee: Casio Computer Co Ltd
Priority date: 2001-07-30
Filing date: 2001-07-30
Publication date: 2010-04-28
Anticipated expiration: 2021-07-30
Also published as: JP2003044702A

Description

【０００１】
【発明の属する技術分野】
この発明は、通信ネットワークを介して、賃走車両に相乗りする候補相手を仲介する相乗り仲介管理装置及びそのプログラムに関する。
【０００２】
【従来の技術】
従来、タクシーの配車手配の方法として、タクシー管理センターは、各タクシー毎に、その料金メータから乗車／空車中かの情報を取得すると共に、車載端末に備えられている位置測定システム（ＧＰＳ）からその現在位置を取得し、これらの情報に基づいて利用者の近傍に位置している空車タクシーを検索して配車手配を行う配車手配システムが知られている。
とろこで、タクシーの相乗りや乗合バス（賃走車両）を利用する場合には、各利用者が携帯電話等からタクシー管理センターへ配車手配を依頼すると、その相乗り場所にタクシーや乗合バスを配車手配するようにしたシステムも考えられている。このような相乗り手配システムは、例えば、環境問題に対する対策の他に、過疎地域での路線バスの廃止による代替手段としても期待されている。
【０００３】
【発明が解決しようとする課題】
しかしながら、相乗りタクシーや乗合バスを利用する場合において、利用者にとっては、単独でタクシーを利用した場合よりも料金はかなり割安となるが、相乗り者が乗車する場所や下車する場所によっては、単独でタクシーを利用した場合よりも、走行距離や時間が極端に多くかかるケースがある。また、相乗りタクシーや乗合バスのように狭い空間の中に長時間、見知らぬ人と同乗することは、同乗相手によっては不快な思いをすることもある。
このため、よほど料金が格安になるか、緊急を要する場合を除けば、相乗りタクシーや乗合バスを敬遠する傾向にあり、路線バスの代替手段として期待されている相乗り構想もその運用の仕方によっては、現実味のないものとなる。
【０００４】
第１の発明の課題は、賃走車両の相乗りを利用する場合に、その相乗り希望条件を申し込んでおくだけで、利用者が希望する通りの相乗りを実現できるようにすることである。
第２の発明の課題は、賃走車両の相乗りを利用する場合に、その利用者自身に相乗りした場合の優劣を直接判断させることで、利用者が希望する通りの相乗りを実現できるようにすることである。
第３の発明の課題は、賃走車両の相乗りを利用する場合に、その利用者自身に相乗り相手を直接確認させることで、利用者が希望する通りの相乗りを実現できるようにすることである。
【０００５】
【課題を解決するための手段】
本発明は、通信ネットワークを介して、賃走車両に相乗りする相手を紹介する相乗り仲介管理装置であって、利用者毎に、利用者端末より受信した少なくとも、乗車時刻、乗車地、目的地を含む乗車情報を記憶管理する乗車情報記憶手段と、相乗り申込者より受信した乗車情報を元に、前記乗車情報記憶手段を検索し、乗車時刻、乗車地の乗車情報が近い候補相手情報を検索し、更に目的地の乗車情報に応じて走行方向が略同様である相乗り可能な候補相手情報を選択する選択手段と、この選択手段で選択された候補相手情報の乗車情報と相乗り申込者の乗車情報に基づいて相乗りした場合の距離及び時間を算出する算出手段と、相乗り申込者と前記選択手段で選択された候補相手に対して前記算出手段によって算出された距離及び時間を送信すると共に、相乗り申込者と前記選択手段で選択された候補相手から相乗りの同意を受信した場合に、乗車地の乗車情報を送信する送信手段を具備したことを特徴とする。
【００１９】
【発明の実施の形態】
以下、図１〜図１２を参照してこの発明の一実施形態を説明する。
図１は、この実施形態における相乗り仲介システムの全体構成を示したブロック図である。
この相乗り仲介システムは、賃走車両（タクシー）に相乗りする相手を紹介する紹介サービスを通信ネットワーク網（インターネット、移動体通信網）を介して行うもので、誰でも容易に利用可能な広域通信システムであり、全国のタクシー会社と契約することによって、このような紹介サービスを全国規模で展開するようにしている。
【００２０】
この相乗り仲介サービスを行う事業者側には、仲介管理サーバ１が設けられており、この仲介管理サーバ１には、通信ネットワーク網（インターネット）２を介して複数のタクシー会社Ａ、Ｂ‥‥側に設置されているタクシー会社端末３に接続されていると共に、各タクシー会社に所属している各タクシーの車載端末４やタクシーを利用する顧客側の利用者端末５がネットワーク網（インターネット、移動体通信網）２を介して接続されている。なお、仲介管理サーバ１は、契約タクシー会社に所属している各タクシーを一元管理するようにしている。
【００２１】
仲介管理サーバ１は、通信ネットワーク網２を介して利用者端末５からの相乗り依頼を受け付けると共に、その相乗り希望条件を受け付けて記憶管理する。そして、仲介管理サーバ１は、走行方向が略同様（許容範囲内）である相乗り可能な利用者を相乗り相手の候補として選択すると共に、その利用者同士の相乗り希望条件が適合するかを判別し、希望条件が適合する場合には、相乗りした際に予想される走行経路のずれに関する情報、各人が負担する料金に関する情報、利用者に関する情報を電子メールによって各利用者に案内通知した後、各利用者から同意を得た場合に、相乗りが成立したものとして決定するようにしている。すなわち、各利用者から予め申し込まれた相乗り希望条件に基づいて相乗り相手を選択した後に、各利用者の承諾を得る為に各種の案内情報を提示し、合意が得られた場合に相乗りを成立させるようにしている。
なお、仲介管理サーバ１側には、ユーザデータベース１１、タクシー管理データベース１２、相乗り管理データベース１３、地図データベース１４等が設けられている。
【００２２】
タクシー会社は、この相乗り仲介サービス事業者との間で加入契約を交わす際に、タクシー会社端末３からネットワーク網２を介して仲介管理サーバ１をアクセスし、加入登録に必要な事項、例えば、「タクシー会社名」、「住所」、「連絡先（電話番号、メールアドレス）」、「金融機関の口座番号」等の他、「タクシーの所有台数」を入力して会員登録を行うようにしている。
その際、仲介管理サーバ１は、タクシーの所有台数分の「タクシーＩＤ」を生成発行して、タクシー会社端末３へ送信する。タクシー会社側では、この「タクシーＩＤ」を各タクシーに割り当て、その車載端末４内に設定するようにしている。
【００２３】
車載端末４は、中低軌道周回衛星を利用する位置測定システム（ＧＰＳ機能）を有し、空車の場合に一定タイミング毎に現在位置を取得して仲介管理サーバ１へ送信するようにしている。
利用者端末５は、携帯電話端末やモバイル型無線通信装置等であり、乗車依頼時には「希望乗車時刻」、「乗車地」、「目的地」、「同乗人数」を入力すると共に、「相乗り希望条件」を入力するようにしている。なお、この実施形態においては、これらの情報をキー操作で行うようにしているが、音声によって入力するようにしてもよい。
【００２４】
なお、この実施形態においては、例えば、ＴＣＰ／ＩＰ通信プロトコルを利用したＨＴＴＰプロトコル等によって、仲介管理サーバ１とタクシー会社端末３、車載端末４、利用者端末５との間でデジタル化（パケット化）されたデータの送受信を行うようにしており、また、コード化された制御情報を含むデータによって互いに必要な処理内容を認識しながら連携し合ってデータ処理を行うようにしている。なお、配車管理サーバ１は、データベースサーバ機能、メール機能、Ｗｅｂサーバ機能等の各種のサーバ機能を有し、タクシー会社端末３、車載端末４、利用者端末５は、Ｗｅｂブラウザ機能を備えている。
【００２５】
図２（Ａ）は、ユーザデータベース１１の内容を概念的に示した図である。
このユーザデータベース１１は、この相乗り仲介サービス事業者との間で会員契約を交わした会員ユーザの情報を記憶管理するもので、各ユーザレコードは、「ユーザＩＤ」、「パスワード」、「氏名」、「住所」、「電話番号」、「メールアドレス」、「性別」、「年代」等の各項目を有している。「ユーザＩＤ」は、仲介管理サーバ１側で会員登録時に発行されたユーザ識別情報である。「氏名」、「性別」、「年代」は、相乗り相手として妥当かを判断する際にも参照される情報である。
【００２６】
図２（Ｂ）は、タクシー管理データベース１２の内容を概念的に示した図である。
このタクシー管理データベース１２は、契約関係にあるタクシー会社毎に、その会社に所属している各タクシーに関する情報を一元管理するもので、各タクシーレコードは、「タクシーＩＤ」、「現在位置（経緯度）」、「空車フラグ」の各項目を有している。「タクシーＩＤ」は、契約時に予め割り当てられたタクシー固有の識別情報であり、「現在位置」は、位置測定システム（ＧＰＳ）によって得られたタクシーの現在位置を示す情報である。「空車フラグ」は、空車中を示すフラグである。
【００２７】
図３は、相乗り管理データベース１３の内容を概念的に示した図である。
この相乗り管理データベース１３は、利用者端末５から相乗り依頼を受け付けた際に、利用者（会員ユーザ）別にその依頼内容を記憶管理するもので、各依頼レコードは、「ユーザＩＤ」、「希望乗車時刻」、「乗車地」、「目的地（下車地）」、「同乗人数」、「相乗り希望条件」等の各項目を有している。
「希望乗車時刻」は、余り厳密な時刻ではなく、例えば、１２時１０分〜２０分ごろ乗車希望のように、１０分程度の誤差も許容する程度の希望時刻である。「乗車地」、「目的地」は、自分が乗車する乗車範囲を示すもので、仲介管理サーバ１は、「乗車地」、「目的地」に基づいて地図データベース１４、地図ファイル群１５をアクセスし、最適な走行経路を求めるようにしている。
「相乗り希望条件」として、この実施形態においては、相乗り相手の「性別」、「年代」を任意に指定するようにしている。
【００２８】
図４は、仲介管理サーバ１の基本的構成要素を示したブロック図である。
ＣＰＵ１０１は、記憶装置１０２内のオペレーティングシステムや各種アプリケーションソフトにしたがってこの仲介管理サーバ１の全体動作を制御する中央演算処理装置である。記憶装置１０２は、オペレーティングシステムや各種アプリケーションソフトの他、上述したユーザデータベース１１、タクシー管理データベース１２、相乗り管理データベース１３、地図データベース１４等が格納され、磁気的、光学的、半導体メモリ等によって構成されている記録媒体１０３やその駆動系を有している。
この記録媒体１０３はハードディスク等の固定的な媒体若しくは着脱自在に装着可能なＣＤ−ＲＯＭ、フロッピィデスク、ＲＡＭカード、磁気カード等の可搬型の媒体である。また、この記録媒体１０３内のプログラムやデータは、必要に応じてＣＰＵ１０１の制御によりＲＡＭ（例えば、スタティックＲＡＭ）１０４にロードされたり、ＲＡＭ１０４内のデータが記録媒体１０３にセーブされる。更に、記録媒体は外部機器側に設けられているものであってもよく、ＣＰＵ１０１は伝送制御部１０５を介してこの記録媒体内のプログラム／データを直接アクセスして使用することもできる。
【００２９】
また、ＣＰＵ１０１は記録媒体３内に格納されるその一部あるいは全部を他の機器側から伝送制御部１０５を介して取り込み、記録媒体１０３に新規登録あるいは追加登録することもできる。更に、プログラム／データは外部機器側で記憶管理されているものであってもよく、ＣＰＵ１０１は伝送制御部１０５を介して外部機器側のプログラム／データを直接アクセスして使用することもできる。
一方、ＣＰＵ１０１にはその入出力周辺デバイスである伝送制御部１０５、入力部１０６、表示部１０７がバスラインを介して接続されており、入出力プログラムにしたがってＣＰＵ１０１はそれらの動作を制御する。
【００３０】
次に、この実施形態における仲介管理サーバ１の動作アルゴリズムを図５〜図８、図１０および図１１に示すフローチャートを参照して説明する。ここで、これらのフローチャートに記述されている各機能は、読み取り可能なプログラムコードの形態で記録媒体１０３に格納されており、ＣＰＵ１０１はこのプログラムコードにしたがった動作を逐次実行する。また、ＣＰＵ１０１は伝送媒体を介して伝送されてきた上述のプログラムコードにしたがった動作を逐次実行することもできる。すなわち、記録媒体の他、伝送媒体を介して外部供給されたプログラム／データを利用してこの実施形態特有の動作を実行することもできる。
【００３１】
図５〜図７は、各利用者が相乗り場所で合流して相乗りする場合において、利用者端末５からの相乗り要求に応じて実行開始される仲介管理サーバ１側の動作を示したフローチャートである。
図９は、各利用者が相乗り場所で合流してタクシーを相乗し、目的地に到着するまでの走行経路を概念的に示したものである。この例は、利用者Ａ、Ｂの目的地が異なるケースを示し、走行途中において、やや遠回りして利用者Ｂを下車させた後、元の路線に戻り、利用者Ａの目的地まで走行する場合を示している。
【００３２】
先ず、仲介管理サーバ１は、「ユーザＩＤ」、「パスワード」の入力を促す入力ページ画面を要求元の利用者端末５へ送信し、これに応答して送信されて来た「ユーザＩＤ」、「パスワード」に基づいてユーザデータベース１１を参照することにより、ユーザ認証を行う（ステップＡ１）。
この結果、正規のユーザでなければ（ステップＡ２）、このフローの終了となって相乗り要求を拒否するが、正規のユーザであれば（ステップＡ２）、乗車希望の情報を送信すべきことを要求する（ステップＡ３）。この場合、仲介管理サーバ１は、乗車希望の入力ページを送信するようにしている。この入力ページには、「希望乗車時刻」、「乗車地」、「目的地」、「同乗人数」、「相乗り希望条件」の各入力項目を有し、利用者がその中に必要事項を記入すると、この入力ページの内容は、仲介管理サーバ１に送信される。
【００３３】
仲介管理サーバ１は、「希望乗車時刻」、「乗車地」、「目的地」、「同乗人数」、「相乗り希望条件」を受信すると（ステップＡ４）、それを１レコード分のデータとして、相乗り管理データベース１３へ新規登録する（ステップＡ５）。そして、この受信情報に基づいて相乗り管理データベース１３を参照し、その「希望乗車時刻」、「乗車地」が近く、「相乗り希望条件」に合致する相乗り相手ユーザを検索する（ステップＡ６、Ａ７）。
すなわち、「希望乗車時刻」、「乗車地」に基づいて相乗り管理データベース１３を検索し、例えば、「希望乗車時刻」が１０分程度の差、「乗車地」が５００ｍ程度の差の相乗り相手を選択して、その「ユーザＩＤ」を取得すると共に（ステップＡ６）、この「ユーザＩＤ」に基づいてユーザデータベース１１を参照し、「相乗り希望条件」としての「性別」、「年代」が一致する相手を選択する（ステップＡ７）。
【００３４】
この結果、該当する相手ユーザが居た場合には（ステップＡ８）、更に、その相手ユーザの「目的地」を相乗り管理データベース１３から取得し、各相手ユーザの「目的地」と今回の相乗り申込者の「目的地」とに基づいてタクシーの走行方向が略同様である相手ユーザを選択する（ステップＡ９）。すなわち、「希望乗車時刻」、「乗車地」が近く、「相乗り希望条件」が合致する各相手ユーザの中から走行方向が略同様のユーザを絞り込む為の処理を行う。この場合、走行方向が略同様とは、全体の走行経路を考慮し、相乗りによって影響される走行経路の時間的な“ずれ”、距離的な“ずれ”が予め設定されている許容範囲内（例えば、２０％以内）にあるかに基づいてその判断を行うようにしている。
【００３５】
いま、走行方向が略同様の相手ユーザが居た場合には（ステップＡ１０）、その相手ユーザを相乗り候補として抽出するが（ステップＡ１１）、抽出候補が多数居る場合には（ステップＡ１２）、その中から最適な相手を更に選ぶ（ステップＡ１３）。つまり、「希望乗車時刻」、「乗車地」が最も近いユーザあるいは走行方向が最も近似しているユーザを相乗り相手として選択する。
更に、今回の相乗り申込者の「同乗人数」と相手ユーザの「同乗人数」とに基づいて１台のタクシーに同乗可能かを判別し（ステップＡ１４）、同乗不可能であれば、同乗可能な他の相手ユーザを選択する（ステップＡ１５）。この場合、他の相手ユーザが居なければ（ステップＡ１６）、検索基準の拡大処理を行う（ステップＡ１７）。
【００３６】
このステップＡ１７は、相乗りの検索基準を拡大する処理を行うもので、ステップＡ８、Ａ１０、Ａ１６のいずれかで該当無しと判別された場合に、「希望乗車時刻」、「乗車地」の検索基準や「走行方向」の検索基準を緩和するようにしている。すなわち、「希望乗車時刻」の許容範囲が１０分程度の差、「乗車地」の許容範囲が５００ｍ程度の差、走行経路の時間的、距離的な許容範囲が２０％以内としている場合には、その基準を１ランク緩め、例えば、１５分、７００ｍ、３０％に変更するようにしている。
なお、ステップＡ８、Ａ１０、Ａ１６に対応して「希望乗車時刻」、「乗車地」、「走行方向」の検索基準を緩和するようにしているが、「希望乗車時刻」、「乗車地」、「走行方向」のうち、どれを緩和するか、どのような順序で緩和するかは、任意である。
【００３７】
このようにして検索基準を拡大した後、上述したステップＡ７〜Ａ１５と同様の検索処理を再開する（ステップＡ１８）。この再検索処理の結果、該当する相手ユーザの有無をチェックするが（ステップＡ１９）、検索基準を拡大しても該当する相手ユーザが居ない場合には、“該当なし”を示すメール通知を要求元の利用者端末５へ送信し（ステップＡ２０）、それに応じて利用者端末５から相乗り拒否応答を受信した場合には（ステップＡ２１）、その利用者対応の相乗り管理データベース１３内の登録情報を削除する（ステップＡ２２）。
【００３８】
一方、上述の検索処理で相乗り相手が選択された場合には、図６のステップＡ１７に移り、今回の相乗り申込者に基づいてユーザデータベース１１をアクセスし、そのユーザ情報を読み出す。そして、選択した候補ユーザの相乗り希望条件と今回の相乗り申込者のユーザ情報とを比較して、相乗り候補ユーザにとって今回の相乗り申込者は、その希望条件に合致するかを判別する（ステップＡ１８）。
ここで、合致しない場合には（ステップＡ１９）、相乗りが不成立であるとするが、合致する場合には、相乗りの各ユーザ毎に、その目的地に応じて最適な走行経路（例えば、最短経路）を、地図データベース１４を参照することによって決定すると共に（ステップＡ２０）、各ユーザ毎に求めた走行経路に応じて走行距離、走行予測時間を算出する（ステップＡ２１）。なお、走行距離、走行予測時間を厳密に求める必要はなく、概算値であってもよい。
【００３９】
これによって算出した各ユーザ毎の走行距離、走行予測時間を比較検討し、相乗りによる距離・時間の増加分の割合を算出する（ステップＡ２２）。つまり、最短の距離・時間に対して、例えば、距離的に１０％増し、時間的に１１％増し等のように、相乗りによって距離・時間がどの程度遠回りとなるかを示す増加分の割合を算出する。
そして、各ユーザ毎に求めた走行経路に応じて求めた走行距離、走行予測時間、相乗りによる距離・時間の増加分の割合、相乗り対象のユーザ数（同伴する同乗者を除く）に基づいて各人が負担する料金の減額割合を算出する（ステップＡ２３）。この場合、相乗りによって減額される料金の減額割合としては、相乗りしなかった場合の料金に対し、相乗りした場合の料金がどの程度、減額されるかを示すもので、例えば、４２％格安等の割合である。
【００４０】
そして、各相乗りユーザの「氏名」をユーザデータベース１１から読み出した後（ステップＡ２４）、各ユーザ宛に送信する案内メールをユーザ毎に作成する（ステップＡ２５）。この場合、上述のようにして算出した「距離・時間の増加割合」、「料金の減額割合」、「相手の氏名」を含む案内メールを各ユーザ毎に作成する。これによって作成された案内メールを相乗りの各ユーザ宛にその利用者端末５に対して送信した後（ステップＡ２６）、そのユーザからの応答待ちとなる。
この案内メールを受信した各利用者端末５は、「距離・時間の増加割合」、「料金の減額割合」、「相手の氏名」をその端末画面に表示させるが、この画面内容を確認したユーザは、相乗りに伴う優劣を判断し、相乗りに合意するかを意思決定し、その旨を仲介管理サーバ１へ応答する。
【００４１】
仲介管理サーバ１は、相乗りの各ユーザからの応答内容を受信すると（ステップＡ２７）、図７のステップＡ２８に移り、相乗りの各ユーザから合意が得られたかを判別し、各ユーザの合意が得られなければ、相乗りの不成立とするが、各ユーザの合意が得られた場合には、相乗りの各ユーザ宛にその利用者端末５に対して合意通知と共に、待ち合わせ場所（乗車地）の送信要求を行う（ステップＡ２９）。
そして、いずれかのユーザから待ち合わせ場所を受信すると、それを他の相乗り相手に対して送信する（ステップＡ３０）。このような動作は、待ち合わせ場所が決定されるまで繰り返す（ステップＡ２９〜Ａ３１）。
【００４２】
これによって待ち合わせ場所が決定されると、各相乗りユーザへ現在の特徴の送信要求を行う（ステップＡ３２）。つまり、待ち合わせ相手を容易に判断することが可能な「身体的な特徴」、「現在の服装、持ち物」等を示す特徴情報の送信を要求し、これに応答して特徴情報が送信されて来た場合には、それを受信し（ステップＡ３３）、相手先へ決定した待ち合わせ場所と共に特徴情報を送信する（ステップＡ３４）。
このようにして待ち合わせ場所や特徴情報の仲介を行った後、タクシー管理データベース１２を参照し、待ち合わせ場所の近くに居る空車タクシーを検索し、そのタクシーの車載端末４に対して必要事項を送信して、相乗りによる配車手配を行う（ステップＡ３５）。この場合、必要事項とは、相乗りユーザ毎の乗車地や目的地および乗車時刻である。
【００４３】
図８は、仲介管理サーバ１が一定時間毎に実行開始する相乗り管理データベース１３の更新処理を示したフローチャートである。
仲介管理サーバ１は、相乗り管理データベース１３の先頭レコードから１レコード分のデータを選択し（ステップＢ１）、その「希望乗車時刻」を抽出して現在のシステム日時と比較し、乗車時刻間際かを判別する（ステップＢ２）。例えば、「希望乗車時刻」の“１０分”前かを判別し、乗車時刻間際でなければ、ステップＢ８に移るが、乗車時刻間際であれば、そのユーザに対して相乗り相手が居ないことを示す“該当なし通知”を行う（ステップＢ３）。
【００４４】
ここで、そのユーザからの応答を受信すると（ステップＢ４）、相乗り拒否応答かを判別し（ステップＢ５）、拒否応答であれば、相乗り管理データベース１３から当該ユーザのレコード（乗車希望情報）を削除する（ステップＢ６）。また、乗車時刻の延長申込を受信した場合には、そのユーザの相乗り管理データベース１３内の「希望乗車時刻」を延長する処理を行う（ステップＢ７）。
そして、相乗り管理データベース１３内の全レコード分の処理を終了したかを判別し（ステップＢ８）、全レコード分の処理が終了するまでステップＢ１に戻り、以下、上述の動作を繰り返す。
【００４５】
図１０および図１１は、走行途中で相手を拾って相乗りする場合において、利用者端末５からの相乗り要求に応じて実行開始される仲介管理サーバ１側の動作を示したフローチャートである。
図１２は、走行途中で相手を拾ってタクシーに相乗し、目的地に到着するまでの走行経路を概念的に示したものである。この例は、利用者Ａの乗車地（最初の乗車地）から出発し、その走行途中において、やや遠回りして利用者Ｂを同乗させた後、元の路線に戻り、利用者Ａをその目的地で下車させてから利用者Ｂの目的地まで走行する場合を示している。
【００４６】
先ず、仲介管理サーバ１は、上述した図５のステップＡ１〜Ａ６に対応する処理を行う（ステップＣ１〜Ｃ３）。つまり、仲介管理サーバ１は、相乗り申込者に対するユーザ認証処理を行った後（ステップＣ１）、正規なユーザであれば、「希望乗車時刻」、「乗車地」、「目的地」、「同乗人数」、「相乗り希望条件」を受信して相乗り管理データベース１３へ登録する登録処理を行うと共に（ステップＣ２）、相乗り希望条件「性別」、「年代」に合致する相手ユーザを検索する検索処理を行う（ステップＣ３）。
この結果、相乗り希望条件に合致する相手ユーザが居なければ（ステップＣ４）、“該当なし通知”を行うが（ステップＣ１３）、条件に合致する相手ユーザが居る場合には、次のステップＣ５に移り、相乗り申込者から受信した「乗車地」、「目的地」に基づいて走行方向を算出する。
【００４７】
そして、相乗り希望条件に合致するいずれかの相手ユーザに着目し、この着目ユーザ対応のレコードを相乗り管理データベース１３から取得する（ステップＣ６）。次に、この着目レコード内の「乗車地」、「目的地」に基づいて走行方向を算出すると共に（ステップＣ７）、その「希望乗車時刻」を起点として、「乗車地」から「目的地」までに要する所要時間（走行時間）帯を算出する（ステップＣ８）。例えば、その着目ユーザの「希望乗車時刻」が午後２時００分で、「乗車地」から「目的地」までに要する所要予測時間が４５分であれば、その着目ユーザの走行時間帯は、午後２時００分〜午後２時４５分となる。
【００４８】
次に、今回の申込者の走行方向と着目ユーザの走行方向が略同様であり、かつ着目ユーザの走行時間帯内に今回の申込者の「希望乗車時刻」が該当するかを調べる（ステップＣ９）。この場合、走行方向が略同様かの判定は、例えば、走行経路の時間的、距離的な“ずれ”が許容範囲内（２０％以内）であるか否かに基づいて行われる。ここで、走行経路の時間的、距離的な“ずれ”が許容範囲内であり、かつ、着目ユーザの走行時間帯が午後２時００分〜午後２時４５分で、今回の申込者の「希望乗車時刻」が午後２時２０分であれば、相乗り可能と判断される（ステップＣ１０）。
【００４９】
ここで、相乗り可能であれば、その着目ユーザを相乗り候補として抽出する（ステップＣ１１）。そして、相乗り希望条件に合致する相手ユーザが他に居るかを判別し（ステップＣ１２）、その条件合致するユーザに対する処理が終了するまでステップＣ６に戻り、以下、上述の動作を繰り返す。
これによって相乗り希望条件に合致するユーザのうち、相乗り候補として抽出されたユーザが多数居る場合には（図１１のステップＣ１６）、相乗り候補の走行方向のうち、今回の申込者の走行方向に一番近似している相乗り候補を選択する（ステップＣ１７）。
【００５０】
更に、今回の相乗り申込者の「同乗人数」と相手ユーザの「同乗人数」とに基づいて１台のタクシーに同乗可能かを判別し（ステップＣ１８）、同乗不可能であれば、同乗可能な他の相手ユーザを選択する（ステップＣ１８）。この場合、他の相手ユーザが居なければ（ステップＣ２０）、“該当なし通知”を行う（図１０のステップＣ１３）。
また、該当する相手ユーザが居る場合には（ステップＣ２０）、相乗り候補のユーザ条件に合致するかのチェック処理を行う（ステップＣ２１）。このチェック処理は、図６のステップＡ１７、Ａ１８に対応する処理であり、選択された相乗り候補ユーザの相乗り希望条件と今回の相乗り申込者のユーザ情報とが合致するかをチェックする。
【００５１】
ここで、合致しない場合には（ステップＣ２２）、相乗りが不成立であるとするが、合致する場合には、距離・時間の増加分の割合、減額割合を算出すると共に、相乗り同士の氏名を読み出す処理を行う（ステップＣ２３）。この処理は、図６のステップ２０〜Ａ２４に対応の処理であり、相乗りによる距離・時間の増加分の割合、各人が負担する料金の減額割合を算出し、そして、各相乗りユーザの「氏名」を読み出す。
この「距離・時間の増加割合」、「料金の減額割合」、「相手の氏名」を含む案内メールを各ユーザ毎に作成して、相乗りの各ユーザ宛に送信した後、そのユーザからの応答待ちとなる（ステップＣ２４）。
【００５２】
仲介管理サーバ１は、相乗りの各ユーザからの応答内容を受信すると（ステップＣ２４）、相乗りの各ユーザから合意が得られたかを判別し（ステップＣ２５）、各ユーザの合意が得られなければ、相乗りの不成立とするが、各ユーザの合意が得られた場合には、相乗りの各ユーザ宛に合意通知を行うと共に（ステップＣ２６）、空車タクシーを検索し、そのタクシーに対して必要事項を送信して、相乗りによる配車手配を行う（ステップＣ２７）。この場合、相乗りの各ユーザのうち、最初に乗車するユーザの乗車地近くに居る空車タクシーを検索する。
【００５３】
以上のように、この実施形態において仲介管理サーバ１は、タクシーの相乗りが申し込まれた場合に、相乗り管理データベース１３を参照し、ユーザ同士の相乗り希望条件が適合するかを判別し、例えば、「女性に限る」、「同年輩に限る」の条件に適合する場合には、相乗りが成立したものとして決定するようにしたから、相乗り希望条件を申し込んでおくだけで、ユーザが希望する通りの相乗りを実現することができる。したがって、例えば、年代は問わない女性同士の相乗り、同年輩の女性同士の相乗り、性別を問わない同年輩同士の相乗りが可能となり、タクシーの狭い空間の中に長時間、見知らぬ人と相乗りする場合に効果的なものとなり、これによってタクシーの相乗りを促進することが可能となる。
【００５４】
仲介管理サーバ１は、相乗り申込を受け付けた場合に、相乗り管理データベース１３を参照し、走行方向が略同様である相乗り可能な候補相手を選択すると共に、今回の相乗り申込者と選択された候補相手とが相乗りした場合に、予想される走行経路のずれに関する情報、各人が負担する料金に関する情報を算出して、相乗りの各ユーザへ案内通知した後において、各ユーザから相乗りの同意を得た場合には、相乗りが成立したものとして決定するようにしたから、各ユーザに相乗りした場合の優劣をユーザ自身に直接判断させことができ、利用者が希望する通りの相乗りを実現することが可能となる。
この場合、予想される走行経路のずれに関する情報として、例えば、距離的に１０％増の遠回りである旨を案内したり、時間的に１０分増の遠回りである旨を案内したり、各人が負担する料金に関する情報として、例えば、４０％の減額等を案内することができるので、相乗りした場合の優劣を即座に判断することができる。
【００５５】
仲介管理サーバ１は、相乗り申込を受け付けた場合に、相乗り管理データベース１３を参照し、走行方向が略同様である相乗り可能な候補相手を選択すると共に、今回の相乗り申込者と選択された候補相手に対し、そのユーザに関する情報を相互に案内した後に、各ユーザから相乗りの同意を得た場合には、相乗りが成立したものとして決定するようにしたから、ユーザ自身にに相乗り相手を直接確認させることができ、ユーザが希望する通りの相乗りを実現することが可能となる。この場合、ユーザに関する情報として、氏名を案内するようにしたので、嫌いな人との同乗を拒否することが可能となる。
【００５６】
また、相乗りが成立した場合に、その相乗り相手同士が合流する為に必要とされる情報として、相乗り場所を案内したり、同乗者の服装や特徴等を案内するようらにしたから、相乗り場所で相手を容易に確認することができ、合流をスムーズに行うことが可能となる。
更に、相乗りが成立した場合に、タクシー対して配車手配を行うと共に、相乗りユーザ毎にその乗車地や目的地を案内するようにしたから、例えば、相乗り場所の近くに居る空車タクシーをその場所に直ちに出向かせたり、また、走行途中で利用者を乗車させたり、下車させる場合でも、運転手に対して各利用者の乗り降り場所を間違い無く知らせることができる。
【００５７】
また、相乗りを希望する各ユーザが相乗り場所に合流して相乗りする場合には、乗車希望時刻および乗車地が近い各ユーザを相乗り相手とするので、各ユーザが相乗り場所に合流して相乗りする場合、適切なユーザを相乗り相手とすることができる。また、相乗りを希望する各ユーザの乗車地が相違する場合には、その乗車地の付近および乗車希望時刻の近くをタクシーで通過する可能性のあるユーザを相乗り相手とするので、各ユーザが相乗り場所に合流して相乗りする場合に限らず、走行途中からの同乗も可能な相乗りも可能となる。
【００５８】
なお、上述した実施形態においては、相乗りを希望する各ユーザが相乗り場所に合流して相乗りする場合に、仲介管理サーバ１は、待ち合わせ場所や各ユーザの特徴情報（身体的特徴、服装等）の受け渡しを仲介するようにしたが、ユーザ同士が直接電話で話し合うようにする為、仲介管理サーバ１が利用者端末（携帯電話）５同士を通話接続させる為の接続情報を相互に送信するようにしてもよい。
図１３は、各ユーザが相乗り場所に合流して相乗りする場合において、上述した図７に代わる動作を示したフローチャートである。
【００５９】
すなわち、仲介管理サーバ１は、各ユーザの合意が得られた場合には（ステップＤ１）、ユーザデータベース１１をアクセスして各ユーザの「電話番号」を取得し、各ユーザの利用者端末５へ合意通知を行った後に（ステップＤ２）、各利用者端末５同士を通話接続させる為の接続情報（電話番号）を相互に送信する（ステップＤ３）。これによって各ユーザ同士の端末接続（通話接続）が可能となる為に、電話で話し合いながら相乗り場所を決めたり、身体的特徴、服装等を相手に知らせることができる。
ここで、いずれからのユーザから仲介管理サーバ１へ相乗り場所が送信されて来た場合には、それを受信すると共に（ステップＤ４）、その相乗り場所近くに居るタクシーに対して相乗りの配車手配を行う（ステップＤ５）。
このように、ユーザ同士が相乗り場所や特徴等を直接電話で話し合うことができるので、相乗りをスムーズに行うことが可能となる。
【００６０】
また、上述した実施形態においては、相乗り希望条件として、「性別」、「年代」を例示したが、相乗り希望条件は任意である。
例えば、「遠回りでも距離的に１０％増以内を限度とする」、「遠回りでも時間的に１０分増以内を限度とする」、「特定者（近所の嫌いな人など）を除く」、「同じ学校や会社の人に限る」、「料金が２０％以上格安になる場合に限る」、「午前７時４５分以前（出勤時）の乗車に限る」等を相乗り希望条件として申し込むことができるようにしてもよい。
【００６１】
ここで、相乗り希望条件が「遠回りでも距離的に１０％増以内を限度とする」、「遠回りでも時間的に１０分増以内を限度とする」等のような場合には、上述した図６のステップＡ２０〜Ａ２２に対応する処理を図５のステップＡ６において実行すればよい。また、相乗り希望条件が「料金が２０％以上格安になる場合に限る」等のような場合には、図６のステップＡ２３の処理を図５のステップＡ６において実行すればよい。
同様に、「特定者（近所の嫌いな人など）を除く」、「同じ学校や会社の人に限る」等のような場合には、そのユーザ情報を参照して、特定者か否かを判別する処理を実行すればよく、「午前７時４５分以前（出勤時）の乗車に限る」等の場合には、現在のシステム日時が希望時刻に該当するかを判別すればよい。
【００６２】
上述した実施形態においては、ユーザに関する情報として、「氏名」を案内するようにしたが、ユーザに関する情報としては、その他に、「性別」、「年代」、「体重」、「住所としての町名」、「同伴者数」、「同伴者に関する情報」等を取得して、相手ユーザに案内するようにすれば、更に、自分の好みに合った相乗り相手を探すことができる。
また、利用者端末５は、タクシーの相乗り希望する時に、仲介管理サーバ１に対して配車依頼を行う際、地上系／衛星移動体通信網を介して現在位置（乗車地点）を取得して、仲介管理サーバ１へ送信するようにしてもよい。更に、利用者端末５としては、携帯電話に限らず、自宅に設置されているデスクトップ型、ノート型のパーソナルコンピュータ等であってもよい。
【００６３】
上述した実施形態においては、相乗りの配車手配を最寄のタクシーへ行うようにしたが、配車手配をタクシー会社に対して行うようにしてもよい。また、相乗り相手の紹介サービス事業者は、タクシー会社であってもよい。
その他、各人が負担する料金に関する情報として、同伴者（同乗者）が多いユーザに対して料金の負担割合を多くしてもよく、また、各人が負担する料金に関する情報としては、負担割合ではなく、実際の予測料金を算出して案内するようにしてもよい。更に、賃走車両としては、タクシーに限らず、乗合バス、ハイヤー等であってもよい。
【００６４】
一方、コンピュータに対して、上述した各手段を実行させるためのプログラムコードをそれぞれ記録した記録媒体（例えば、ＣＤ−ＲＯＭ、フロッピィデスク、ＲＡＭカード等）を提供するようにしてもよい。
すなわち、コンピュータが読み取り可能なプログラムコードを有する記録媒体であって、賃走車両を利用する利用者毎に、相乗り希望条件を記憶管理する機能と、前記相乗り希望条件を参照し、利用者同士の相乗り希望条件が適合するかを判別する機能と、相乗り希望条件が適合することが判別された場合に、相乗りが成立したものとして決定する機能とを実現させるためのプログラムを記録したコンピュータが読み取り可能な記録媒体を提供するようにしてもよい。
【００６５】
また、コンピュータが読み取り可能なプログラムコードを有する記録媒体であって、利用者毎に、少なくとも、乗車地、目的地を含む乗車情報を記憶管理する機能と、相乗り申込を受け付けた場合に、前記乗車情報を参照し、走行方向が略同様である相乗り可能な候補相手を選択する機能と、今回の相乗り申込者と前記選択手段で選択された候補相手とが相乗りした場合に、予想される走行経路のずれに関する情報、各人が負担する料金に関する情報のうち、少なくとも、そのいずれかを算出する機能と、算出された情報を今回の相乗り申込者と前記選択された候補相手に対して案内する機能と、今回の相乗り申込者と前記選択手段で選択された候補相手から相乗りの同意を得た場合に、相乗りが成立したものとして決定する機能とを実現させるためのプログラムを記録したコンピュータが読み取り可能な記録媒体を提供するようにしてもよい。
【００６６】
更に、コンピュータが読み取り可能なプログラムコードを有する記録媒体であって、利用者毎に、少なくとも、乗車地、目的地を含む乗車情報を記憶管理する機能と、相乗り申込を受け付けた場合に、前記乗車情報を参照し、走行方向が略同様である相乗り可能な候補相手を選択する機能と、今回の相乗り申込者と前記選択手段で選択された候補相手に対し、その利用者に関する情報を相互に案内する機能と、今回の相乗り申込者と前記選択された候補相手から相乗りの同意を得た場合に、相乗りが成立したものとして決定する機能とを実現させるためのプログラムを記録したコンピュータが読み取り可能な記録媒体を提供するようにしてもよい。
【００６７】
【発明の効果】
本発明は、相乗りによって変化する距離及び時間を知ることができ、これをもとに相乗りに同意するかどうかを判断することができる。
【図面の簡単な説明】
【図１】相乗り仲介システムの全体構成を示したブロック図。
【図２】（Ａ）は、ユーザデータベース１１の内容を概念的に示した図、（Ｂ）は、タクシー管理データベース１２の内容を概念的に示した図。
【図３】相乗り管理データベース１３の内容を概念的に示した図。
【図４】仲介管理サーバ１の基本的構成要素を示したブロック図。
【図５】各利用者が相乗り場所で合流して相乗りする場合において、利用者端末５からの相乗り要求に応じて実行開始される仲介管理サーバ１側の動作を示したフローチャート。
【図６】図５に続く、仲介管理サーバ１側の動作を示したフローチャート。
【図７】図５、図６に続く、仲介管理サーバ１側の動作を示したフローチャート。
【図８】仲介管理サーバ１が一定時間毎に実行開始する相乗り管理データベース１３の更新処理を示したフローチャート。
【図９】各利用者が相乗り場所で合流してタクシーを相乗し、目的地に到着するまでの走行経路を概念的に示した図。
【図１０】走行途中で相手を拾って相乗りする場合において、利用者端末５からの相乗り要求に応じて実行開始される仲介管理サーバ１側の動作を示したフローチャート。
【図１１】図１０に続く、仲介管理サーバ１側の動作を示したフローチャート。
【図１２】走行途中で相手を拾ってタクシーに相乗し、目的地に到着するまでの走行経路を概念的に示した図。
【図１３】第１実施形態の変形応用例を説明するもので、各ユーザが相乗り場所に合流して相乗りする場合において、図７に代わる動作を示したフローチャート。
【符号の説明】
１仲介管理サーバ
２ネットワーク網
３タクシー会社端末
４車載端末
５利用者端末
１１ユーザデータベース
１２タクシー管理データベース
１３相乗り管理データベース
１４地図データベース
１０１ＣＰＵ
１０２記憶装置
１０３記録媒体
１０５伝送制御部
１０６入力部

Claims

通信ネットワークを介して、賃走車両に相乗りする相手を紹介する相乗り仲介管理装置であって、
利用者毎に、利用者端末より受信した少なくとも、乗車時刻、乗車地、目的地を含む乗車情報を記憶管理する乗車情報記憶手段と、
相乗り申込者より受信した乗車情報を元に、前記乗車情報記憶手段を検索し、乗車時刻、乗車地の乗車情報が近い候補相手情報を検索し、更に目的地の乗車情報に応じて走行方向が略同様である相乗り可能な候補相手情報を選択する選択手段と、
この選択手段で選択された候補相手情報の乗車情報と相乗り申込者の乗車情報に基づいて相乗りした場合の距離及び時間を算出する算出手段と、
相乗り申込者と前記選択手段で選択された候補相手に対して前記算出手段によって算出された距離及び時間を送信すると共に、相乗り申込者と前記選択手段で選択された候補相手から相乗りの同意を受信した場合に、乗車地の乗車情報を送信する送信手段と
を具備したことを特徴とする相乗り仲介管理装置。
前記送信手段によって乗車地を送信した後に、各利用者の端末同士を接続させる為の接続情報を相互に送信するようにしたことを特徴とする請求項１記載の相乗り仲介管理装置。
前記送信手段によって乗車地を送信した後に、賃走車両あるいはタクシー会社側の端末に対して配車手配を行うと共に、利用者毎の乗車地や目的地を示す情報を案内するようにしたことを特徴とする請求項１記載の相乗り仲介管理装置。
相乗りを希望する各利用者の乗車地が相違する場合には、その乗車地の付近および乗車希望時刻の近くを賃走車両で通過する可能性のある利用者を前記乗車情報記憶手段より検索して相乗り相手とするようにしたことを特徴とする請求項１記載の相乗り仲介管理装置。
通信ネットワークを介して、賃走車両に相乗りする相手を紹介する相乗り仲介管理装置のコンピュータを、
利用者毎に、利用者端末より受信した少なくとも、乗車時刻、乗車地、目的地を含む乗車情報を記憶管理する乗車情報記憶手段、
相乗り申込者より受信した乗車情報を元に、前記乗車情報記憶手段を検索し、乗車時刻、乗車地の乗車情報が近い候補相手情報を検索し、更に目的地の乗車情報に応じて走行方向が略同様である相乗り可能な候補相手情報を選択する選択手段、
この選択手段で選択された候補相手情報の乗車情報と相乗り申込者の乗車情報に基づいて相乗りした場合の距離及び時間を算出する算出手段、
相乗り申込者と前記選択手段で選択された候補相手に対して前記算出手段によって算出された距離及び時間を送信すると共に、相乗り申込者と前記選択手段で選択された候補相手から相乗りの同意を受信した場合に、乗車地の乗車情報を送信する送信手段
として機能させるためのプログラム。