JP2003308596A - 乗合タクシー予約・運行システム - Google Patents

Abstract

(57)【要約】 【課題】 利用時刻と場所の制約を緩和した利用客に対
する利便性の提供維持 【解決手段】 サーバとして機能する予約システム２０
と、タクシー営業者が所有するタクシーに備えられるタ
クシー端末３０と、利用者がタクシーの相乗りを予約す
るに当り希望する希望予約情報、および相乗りをするの
に都合の良い他の利用者からの希望予約情報の有無につ
いての連絡をもらうための連絡先情報を予約システムへ
送信するユーザー端末１０とを通信ネットワーク１００
で接続する。予約システムは、希望予約情報を受信する
と当該ユーザー端末へ利用料金を提示し、連絡先情報の
受信を該利用料金の了承と見なしてマッチング処理を行
い、マッチングが成立した場合には利用者識別情報を生
成して、該当する全ユーザー端末にマッチング成立の旨
と利用者識別情報を送信する。また配車するタクシーの
タクシー端末へは利用者識別情報および希望予約情報を
送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、利用客が通信ネッ
トワークを介して携帯電話等の端末から予約したタクシ
ーの乗合タクシー予約・運行システムに関する。

【０００２】

【従来の技術】国土交通省関東運輸局のホームページ
（http://www.ktt.mlit.go.jp/JIDOU_1/tabi2/index.ht
m）によると、乗合タクシーには下記６つの運行形態が
ある。 ・通勤型乗合タクシー：通勤客の需要に応えるため深夜
早朝に運行 ・循環型乗合タクシー：主に施設循環タクシーで広く一
般の人々の足として運行 ・リゾート型乗合タクシー：通年制リゾート地で住民の
足として活躍 ・観光型乗合タクシー：自然保護のため自家用車乗り入
れを制限された観光地用 ・過疎乗合タクシー：路線バスが廃止された地域の足と
して活躍 ・空港型乗合タクシー：空港と都心部間の足として活躍 例えば、特に多く運行されているのは、深夜型と呼ばれ
る、終電や終バスがなくなった後、駅などからその地域
の住宅街などへ向かうタクシーである。料金は、バスと
タクシーの中間くらいで、決められたコースを定額で走
ったり、ある区域間であれば定額でどこででも降車可能
である、という形態になっている。

【０００３】この深夜型タクシーに代表されるような乗
合タクシーは、路線バスの延長のような形で、出発時刻
が限られているという問題がある。例えば、毎日午前３
時にある駅を出発する便というのは運行していない。ま
た、路線バスや電車が運行している時間帯にも、ほとん
ど運行していない。これは、料金設定が、１人でタクシ
ーに乗るより安い料金設定になっているからであり、複
数人同時に乗せないと、タクシー会社は採算がとれない
ので採算が確実にとれそうな時間にのみ定期便として運
行しているからである。

【０００４】また、乗車地が限られているという問題も
ある。これも、たとえ利用客がひとりであっても定額で
運行しなければならないというリスクを避けるため、比
較的大規模な駅などからのみ出発するという運行形態を
採用しているからである。

【０００５】以上のような運行時刻と運行地域の制約を
緩和して利用客の利便性の向上を図った従来技術とし
て、特開2001-2294952に記載されている「運行方法およ
びシステム、受付処理システムならびにコンピュータが
読取り可能な記録媒体」を挙げることができる。

【０００６】この技術では、先ず、所定のエリア内で複
数の利用者側から入力される車両利用日時、車両利用場
所、目的地および単独／乗合希望情報を含む複数のサー
ビス予約情報に基づいて、複数の利用客に対して同一の
車両を配車可能であるか否かを判断する。その結果、同
一の車両を配車可能であれば、予約受付を利用者に通知
する。また、サービス予約情報それぞれの車両予約日
時、車両利用場所および目的地に基づいて車両の最適な
運行ルートを探索し、その最適運行ルートによる車両利
用場所および目的地への到着時刻を求める。最適運行ル
ート、車両利用場所および目的地への到着時刻は運行計
画情報として記憶され、車両側に通知される。

【０００７】

【発明が解決しようとする課題】しかしながら、上述し
た従来技術では、相乗りする場合の料金は相乗りのマッ
チングが成立した後に確定し、利用客に通知される仕組
みになっており、その料金を了承しない利用客が相乗り
を取消しても、残りの利用客に対して同一料金により運
行するので、運送業者の採算性が悪化するという問題点
がある。そのため、運送業者は、このようなサービスに
対して消極的になり、結果的には利用客の不便さにつな
がることとなる。

【０００８】本発明は、以上の問題点を解決するもので
あって、その目的は、利用時刻と利用場所の制約を緩和
した利用客に対する利便性提供サービスを維持できる乗
合タクシー予約システムを提供することにある。

【０００９】

【課題を解決するための手段】本発明の乗合タクシー予
約・運行システムは、サーバとして機能する予約システ
ム（図１の２０）と、タクシー営業者が所有するタクシ
ーに備えられるタクシー端末（図１の３０）と、利用者
がタクシーの相乗りを予約するに当り希望する希望予約
情報、および相乗りをするのに都合の良い他の利用者か
らの希望予約情報の有無についての連絡をもらうための
連絡先情報を予約システムへ送信するユーザー端末（図
１の１０）とを通信ネットワーク（図１の１００）で接
続し、予約システムは、希望予約情報を受信すると当該
ユーザー端末へ利用料金を提示し、連絡先情報の受信を
該利用料金の了承と見なして、相乗りをするのに都合の
良い他の利用者からの希望予約情報とのマッチング処理
を行い、マッチングが成立した場合には利用者識別情報
を生成して、該当する全ユーザー端末にマッチング成立
の旨と利用者識別情報を送信し、また配車するタクシー
のタクシー端末へは利用者識別情報および希望予約情報
を送信し、利用者識別情報および希望予約情報を受信し
たタクシー端末は、該情報を保持しておき、当該タクシ
ーは利用者から提示される利用者識別情報との一致を条
件に希望予約情報に基づいて運行することを特徴とする
ものである。

【００１０】予約システムは、連絡先情報を受信する
と、当該ユーザー端末に対してクレジットカード情報の
入力を促進し、受信したクレジットカード情報により利
用料金の決済をするようにしてもよい（図６）。

【００１１】また、予約システムは、連絡先情報を受信
すると、当該ユーザー端末に対して、いつまでにマッチ
ング処理の結果を連絡してほしいかという最終連絡時刻
情報の入力を促進し、受信した最終連絡時刻情報の時刻
までにマッチング処理を行うようにしてもよい（図
７）。

【００１２】また、予約システムは、マッチングがまだ
成立していない希望予約情報を他の利用者にホームペー
ジ上で公開するようにしてもよい。

【００１３】更に、予約システムは、マッチングがまだ
成立していない希望予約情報を過去に送信してきたこと
のある利用者の連絡先へ通知して、タクシーの相乗りを
勧誘するようにしてもよい。勧誘は、先ず、希望予約情
報と同一の希望予約情報を送信したことのある第１パタ
ーンの利用者に対して行い、それでもマッチングが成立
しない場合には希望予約情報に含まれる区間を希望予約
情報としたことのある第２パターンの利用者に対して行
うことができる（図８）。

【００１４】また、本発明の相乗りタクシー予約・運行
システムは、複数のタクシー営業者を対象に予約システ
ム運営者が運用しサーバとして機能する予約システム
（図９の１２０）と、予約システム運営者と予め契約し
ているタクシー業務運営者が運用する配車システム（図
９の１４０）と、タクシー営業者が所有するタクシーに
備えられるタクシー端末（図９の１３０）と、利用者が
タクシーの相乗りを予約するに当り希望する希望予約情
報、および相乗りをするのに都合の良い他の利用者から
の希望予約情報の有無についての連絡をもらうための連
絡先情報を予約システムへ送信するユーザー端末（図９
の１１０）とを通信ネットワーク（図９の２００）で接
続し、予約システムは、希望予約情報を受信すると当該
ユーザー端末へ利用料金を提示し、連絡先情報の受信を
該利用料金の了承と見なして、相乗りをするのに都合の
良い他の利用者からの希望予約情報とのマッチング処理
を行い、配車システムへマッチングの成立した希望予約
情報を送信して配車を依頼し、配車可能なタクシーがあ
る場合に利用者識別情報を生成して、該当する全ユーザ
ー端末にマッチング成立の旨と利用者識別情報を送信
し、また配車システムへ利用者識別情報を送信し、配車
システムは配車するタクシーのタクシー端末へ利用者識
別情報および希望予約情報を送信し、利用者識別情報お
よび希望予約情報を受信したタクシー端末は、該情報を
保持しておき、当該タクシーは利用者から提示される利
用者識別情報との一致を条件に希望予約情報に基づいて
運行することを特徴とするものである。

【００１５】

【発明の実施の形態】次に、本発明の実施例について図
面を参照しながら説明する。

【００１６】［第１の実施例］本発明の相乗りタクシー
予約システムの第１実施例を示す図１を参照すると、こ
のシステムは、ユーザー端末１０と、予約システム２０
と、タクシー端末３０と、これらを相互に接続するイン
ターネット等の通信ネットワーク１００とから構成され
ている。勿論、ユーザー端末１０やタクシー端末３０は
多数であるが、図面の煩雑化を回避して、それぞれ１つ
のみを明示している。

【００１７】ユーザー端末１０は、パーソナルコンピュ
ータ等の情報処理装置であり、利用者が希望する乗車地
や降車地、乗車したい時刻といった希望予約情報、およ
びマッチングが成立したかどうかの連絡をもらうための
連絡先情報をネットワーク１００経由で予約システム２
０に送出する機能を有する携帯電話やＰＤＡも含む。

【００１８】予約システム２０は、タクシー業務の営業
者により使用され、ワークステーション・サーバ等の情
報処理装置によって構成される。そして、利用者の操作
によりユーザー端末１０が送出した希望予約情報と連絡
先情報とを受け取り、マッチング処理を行う機能を備え
ている。ここでいうマッチング処理とは、相乗りをする
のに都合の良い、他の利用者の希望予約情報があるかど
うかを判別する処理である。マッチングは、希望予約情
報を送信してきた利用客に料金を提示した上で行う。こ
れにより、マッチング成立後に利用客が料金を不満とし
て予約を取り消すことがないようにする。

【００１９】利用者が乗車したい時刻（希望乗車時刻）
になっても相乗りをするのに都合の良い相手が、定めら
れた員数に達しなかった場合は、マッチングは不成立と
なる。逆に、時間内に、相乗りをするのに都合の良い者
が、定員数に達した段階でマッチングが成立となる。な
お、定員数は、タクシー１台に乗せる利用者の人数と
し、事前に固定値として決めておく方法でもよいし、希
望人数によってその場で定員数を増やす（配車するタク
シーの種類・大きさを変更する）方法などでもよい。

【００２０】また、予約システム２０は、マッチングが
成立した場合、利用者識別情報を生成して全員のユーザ
ー端末１０（連絡先）に、マッチングが成立した旨と利
用者識別情報を送信する機能を備えている。利用者識別
情報は、利用者と利用内容（希望予約情報）を識別する
ための情報であり、一度の予約に固有の情報として生成
される。また、マッチングが成立しなかった場合に、ユ
ーザー端末１０（連絡先）に、マッチングが成立しなか
った旨の連絡をする機能も備えている。

【００２１】タクシー端末３０は、予約システム２０を
使用するタクシー営業者が所有するタクシーに備えられ
る。タクシー端末３０は、予約システム２０から、その
タクシーを利用する予定の各利用者の利用者識別情報と
希望予約情報を受け取り、保持する。

【００２２】次に、図１〜図５を参照して本実施例の動
作について説明する。なお、これ以降の説明では、ネッ
トワーク１００はインターネットであるとする。

【００２３】図２は、本実施例においてマッチングが成
立した場合のフローチャートを示す。先ず、利用者は、
自分のユーザー端末１０を介して、予約システム２０が
インターネット１００上に開設している乗合タクシー予
約ホームページにアクセスする（図２のステップＡ
１）。すると、予約システム２０は、希望する乗車地，
降車地および乗車したい時刻の情報から成る希望予約情
報をユーザー端末１０の画面に入力するよう利用者に促
す（ステップＡ２）。乗車地や降車地は、住所でもよい
し、その場所が一意に識別可能なら店名やバス停名など
でもよい。

【００２４】図３は、ユーザー端末１０に表示される希
望予約情報画面のイメージ図であり、乗車地として東京
都港区芝浦、降車地として神奈川県横浜市青葉区、出発
時刻として2001年12月20日の23:30が示されている。利
用者によってユーザー端末１０の画面に入力された希望
予約情報は、利用者の指示（図３の「料金確認」ボタン
をクリック）によって予約システム２０にインターネッ
ト１００を介して送信される（ステップＡ３）。

【００２５】予約システム２０は、希望予約情報を受信
すると、その情報を用いて利用料金を計算する。利用料
金は、あらかじめ、各地をいくつかのグループ地域に分
けておき、そのグループ地域間ごとに定額に設定するな
どの方法が考えられる。例えば、東京都港区と東京都品
川区をグループＡ、東京都新宿区と東京都渋谷区をグル
ープＢとした場合、港区内および品川区内の任意の場所
から、新宿区内および渋谷区内の任意の場所までは、均
一料金という設定である。また、乗車時間によって深夜
料金など考慮してもよい。予約システム２０は、計算し
た利用料金の情報をユーザー端末１０に送信する（ステ
ップＡ４）。

【００２６】ユーザー端末１０が、予約システムから送
信された利用料金情報を受信し画面に表示する（ステッ
プＡ５）と、予約システム２０は、マッチング結果が成
立したか否かの連絡をもらうための連絡先情報をユーザ
ー端末１０の画面に入力するよう利用者に促す（ステッ
プＡ６）。利用者は、利用料金情報で示される料金に異
存が無ければ、図４のように連絡先の情報（例えばEメ
ールアドレス）yyzz@ddd.ne.jpをユーザー端末１０の画
面に入力する。そして、「予約」ボタンをクリックする
と、連絡先情報がインターネット１００を介して予約シ
ステム２０に送信される（ステップＡ７）。これによ
り、その利用客は相乗りに賛同したことになる。

【００２７】予約システム２０は、連絡先情報を受信す
ると、先に受信していた希望予約情報を用いて、マッチ
ング処理を行う（ステップＡ８）。この実施例において
のマッチング処理とは、相乗りをするのに都合の良い、
他の利用者の希望予約情報があるかどうかを判別する処
理であり、相乗りをするのに都合の良い希望予約情報と
は、希望する乗車地、降車地がそれぞれ同じ地域に含ま
れており、希望乗車時刻が同じである、といった場合
や、図５のように、必ず経由する地域での途中乗降がで
きる場合などが考えられる。図５では、３人の利用客
Ｘ，Ｙ，Ｚが同じ乗車地（地域Ａ）から乗車し、利用客
ＸとＹは地域Ｃで降車するが、利用客Ｚは途中の地域Ｂ
で降車することを示している。

【００２８】利用者が乗車したい時刻（希望乗車時刻）
になっても、相乗りをするのに都合の良い相手が定員数
に達しなかった場合にはマッチングは不成立となる。逆
に、時間内に、相乗りをするのに都合の良い者が定員数
に達した段階でマッチングが成立となる。

【００２９】なお、定員数は、タクシー1台に乗せる利
用者の人数とし、事前に固定値として決めておく方法で
もよいし、希望人数によってその場で定員数を増やす
（配車するタクシーの種類・大きさを変更する）方法な
どでもよい。

【００３０】マッチングが成立しなかった場合、予約シ
ステム２０は、ユーザー端末１０（連絡先）にその旨の
情報を送信する。また、マッチングが成立しても配車す
るタクシーがない場合は、マッチングが成立しなかった
場合と同様、予約システム２０は、ユーザー端末１０
（連絡先）にその旨の情報を送信する。

【００３１】マッチングが成立し、配車するタクシーが
ある場合、予約システム２０は、利用者および利用内容
（希望予約情報）を識別するための利用者識別情報を生
成し、マッチングが成立した旨とともに、ユーザー端末
１０（連絡先）に送信する（ステップＡ９）。また、予
約システム２０は、配車するタクシーのタクシー端末３
０に対して、マッチングの成立した各利用者の利用者識
別情報と希望予約情報を送信する（ステップＡ１０）。

【００３２】タクシーは、予約システム２０から送信さ
れた、各利用者の希望予約情報に基づいて、各利用者の
乗車希望地を回り、それぞれの利用者に対して、利用者
が提示する利用者識別情報と、タクシー端末３０に保持
された利用者識別情報とを比較する（ステップＡ１
１）。比較方法としては、タクシー運転手が目視で確認
したり、バーコード読み取りなどのデジタル情報処理等
が考えられる。タクシーは、これらの利用者識別情報が
一致した場合には、代金と引き換えに利用者を乗車させ
運行する（ステップＡ１２）。

【００３３】［第２の実施例］次に、本発明の第２の実
施例について説明する。本実施例のシステム構成自体
は、図１に示したのと異なるところがない。第２の実施
例は、利用者がユーザー端末１０を用いてタクシーの乗
車予約をするのと同時に、その利用者のクレジットカー
ドの情報を予約システム２０に送信し、マッチングが成
立した場合にクレジットカードで利用料金の決済を行う
点が第１の実施例と異なる。

【００３４】予約システム２０は、ユーザー端末１０か
ら送信された連絡先情報を受信すると、クレジットカー
ドにより決済を行うよう利用者に促す。具体的には、ク
レジットカードのカード情報をユーザー端末１０の画面
に入力するように利用者に促す。利用者がクレジットカ
ードのカード情報を入力すると、ユーザー端末１０は当
該カード情報を予約システム２０に送信する。予約シス
テム２０はマッチングが成立すると、クレジットカード
カード情報により、その利用客の利用料金について決済
する。

【００３５】次に、本実施例の動作について、マッチン
グが成立した場合のフローチャートを示す図６を参照し
て説明する。ユーザー端末１０が連絡先情報をネットワ
ーク１００経由で予約システム２０に送信するまでの処
理（図６のステップＢ１〜Ｂ７）は、第１実施例におけ
るステップＡ１〜Ａ７の処理と同様である。

【００３６】予約システム２０は、連絡先情報を受信す
ると、利用者にクレジットカードのカード情報を画面に
入力するよう促す（ステップＢ８）。ユーザー端末１０
は、利用者が入力したカード情報をインターネット１０
０経由で予約システム２０に送信する（ステップＢ
９）。

【００３７】予約システム２０は、クレジットカード情
報を受信すると、先に受信していた希望予約情報を用い
てマッチング処理を行う（ステップＢ１０）。マッチン
グ処理の内容については、第１の実施例と同様であり、
マッチングが成立しなかった場合、およびマッチングが
成立しても配車するタクシーがない場合の動作は、第１
の実施例と同様である。

【００３８】マッチングが成立すると、予約システム２
０は、クレジットカード情報を用いて、その利用客の利
用料金について決済する（ステップＢ１１）。これに続
く処理（ステップＢ１２〜Ｂ１４）は、第１実施例にお
ける処理（ステップＡ９〜Ａ１１）と同様である。

【００３９】最後に、タクシーは、利用者が提示する利
用者識別情報と、予約システム２０から事前に通知され
ていた利用者識別情報とが一致した場合には利用者を乗
車させる（ステップＢ１５）。決済されているからであ
る。

【００４０】なお、クレジットカードとしてはデビット
カードでもよく、更に、決済の方法は、今後新しく出て
くるであろう電子決済方法で置き換えることも可能であ
る。

【００４１】以上のように、第２の実施例では、マッチ
ングが成立した時点で利用料金の支払いがされるので、
利用者がマッチング成立後に乗車をしないという事態の
発生が避けられる。

【００４２】［第３の実施例］次に、本発明の第３の実
施例について説明する。本実施例のシステム構成自体
は、図１に示したのと異なるところがない。第３の実施
例は、利用者がユーザー端末１０を用いてマッチングが
成立したか否かの連絡をもらうための連絡先情報を送る
際に、いつまでにマッチング結果を連絡してほしいかと
いう最終連絡時刻情報も送信し、その時刻までにマッチ
ング処理を行うという点で第１の実施例および第２の実
施例と異なる。

【００４３】予約システム２０は、ユーザー端末１０か
ら送信された連絡先情報を受信すると、いつまでにマッ
チング結果の連絡がほしいかという最終連絡時刻情報を
ユーザー端末１０の画面に入力するように利用者に促
す。利用者が最終連絡時刻情報を入力すると、ユーザー
端末１０は最終連絡時刻情報を予約システム２０に送信
する。予約システム２０は、利用者の操作によりユーザ
ー端末１０が送出した希望予約情報と最終連絡時刻情報
を基にマッチング処理を行う。

【００４４】この実施例においては、マッチング処理と
は、相乗りをするのに都合の良い、他の利用者の希望予
約情報があるかどうかを判別する処理であり、最終連絡
時刻になっても相乗りをするのに都合の良い相手が、定
員数に達しなかった場合は、マッチングは不成立とな
る。一方、時間内に相乗りをするのに都合の良い者が、
定員数に達した段階でマッチングが成立となる。

【００４５】次に、本実施例の動作について、マッチン
グが成立した場合のフローチャートを示す図７を参照し
て説明する。ユーザー端末１０が連絡先情報をインター
ネット１００経由で予約システム２０に送信するまでの
処理（図３のステップＣ１〜Ｃ８）は、第１実施例にお
けるステップＡ１〜Ａ７の処理および第２実施例におけ
るステップＢ１〜Ｂ７の処理と同様である。

【００４６】予約システム２０は、連絡先情報を受信す
ると、いつまでにマッチング結果の連絡がほしいかとい
う最終連絡時刻情報をユーザー端末１０の画面に入力す
るように利用者に促す（ステップＣ８）。ユーザー端末
１０は、利用者が入力した最終連絡時刻情報をインター
ネット１００経由で予約システム２０に送信する（ステ
ップＣ９）。

【００４７】予約システム２０は、最終連絡時刻情報を
受信すると、先に受信していた希望予約情報と最終連絡
時刻情報を用いてマッチング処理を行う（ステップＣ１
０）。この実施例におけるマッチング処理とは、相乗り
をするのに都合の良い、他の利用者の希望予約情報があ
るかどうかを判別する処理である。最終連絡時刻内に、
相乗りをするのに都合の良い者が、定員数に達した段階
でマッチングが成立となる。最終連絡時刻になっても相
乗りをするのに都合の良い相手が、定員数に達しなかっ
た場合にマッチングは不成立となる。

【００４８】マッチングが成立した場合、およびマッチ
ングが成立しなかった場合ないしマッチングが成立して
も配車するタクシーがない場合の動作は第１の実施例と
同様である。したがって、これ以降の処理（ステップＣ
１１〜Ｃ１３）は、第１実施例におけるステップＡ９〜
Ａ１１の処理および第２実施例におけるステップＢ１２
〜Ｂ１４の処理と同様である。

【００４９】以上のように、第３の実施例では、利用者
が最終連絡時刻を指定できるので、「マッチングが成立
しなかったら早めに他の交通手段（例えば終電）で移動
する」という方法に切り替えることが可能であり、利用
者の要望に柔軟に対応することができる。なお、本実施
例においても、第２の実施例におけるように、クレジッ
トカードによる決済との組合せが可能である。

【００５０】［第４の実施例］次に、本発明の第４の実
施例について図８を参照して説明する。本実施例は、マ
ッチングが成立しやすいように、マッチングがまだ成立
していない希望予約情報を他の利用者などに公開し、更
には過去に同一の希望予約情報を送信したことのある客
を勧誘するという点で上述の各実施例と異なる。

【００５１】本実施例では、予約システム２０において
マッチング処理を行う際に、あと数人でマッチングが成
立する、という状態になったときなど、あらかじめ定め
られたタイミングで、その時の希望予約情報を公開す
る。公開は予約システム２０がインターネット１００上
に開設しているのホームページ上で行う。その希望予約
情報を見て予約を希望する利用者は、自分のユーザー端
末１０を用いてホームページにアクセスし予約を行うこ
とができる。

【００５２】また、希望予約情報を公開するだけに留ま
らず、過去に予約システム２０を利用したことのある利
用者の連絡先へ電子メールなどで通知して、タクシーの
相乗りを勧誘するという積極的な方法を採ってもよい。
そのためには、利用履歴のある利用者の希望予約情報や
連絡先は予約システム２０に格納しておき、希望予約情
報をキーとして連絡先を検索できるようにしておけばよ
い。

【００５３】図８は、利用客を勧誘する場合の一例を示
すフローチャートである。図２のステップＡ８，図６の
ステップＢ１０または図７のステップＣ１０において、
乗車地が地域Ａ、降車地が地域Ｂ、出発時刻が時刻Ｔの
利用希望者についてのマッチング処理を行った結果、マ
ッチングは成立しなかったが、あと１人で成立するとい
うような状態はよくあることであろう。そのような場
合、過去に乗車地が地域Ａ、降車地が地域Ｂという希望
予約情報を送信したことのある利用者（第１の乗車パタ
ーンの利用者）を検索し（図８のステップＤ１）、その
連絡先に、あと１人でマッチング成立するので乗合タク
シーを利用しないか、勧誘する旨を電子メールでユーザ
端末１０へ連絡して勧誘する（ステップＤ２）。

【００５４】連絡を受けた利用者から申込みがあり、そ
の結果、マッチングが成立すればよいが（ステップＤ３
でＹＥＳ）、成立しなかった場合には（ステップＤ３で
ＮＯ）、過去に乗車地Ａから降車地Ｂへのルートに含ま
れる区間を希望予約情報としたことのある利用客（第２
の乗車パターンの利用者）を検索し（ステップＤ４）、
その連絡先に、あと１人でマッチング成立するので乗合
タクシーを利用しないか、勧誘する旨を電子メールでユ
ーザ端末１０へ連絡して勧誘する（ステップＤ５）。そ
の後の処理は、図２のステップＡ８，図６のステップＢ
１０，または図７のステップＣ１０以降の処理と同様で
ある。

【００５５】本実施例によれば、タクシー業務の営業者
は利用者からの予約をただ待っているだけではなく、マ
ッチングがまだ成立していない希望予約情報を他の潜在
的な利用者などに公開し、または利用者を勧誘すること
により、マッチングの成立率を高めることができる。

【００５６】［第５の実施例］次に、本発明の第５の実
施例について図面を参照して説明する。本実施例は、マ
ッチング処理や予約受付処理を行う予約システムをタク
シー業務の営業者が運用するのではなく、複数のタクシ
ー営業者を対象として予約システム運営者が運用する、
という点で上述の各実施例と異なる。

【００５７】図９を参照すると、本発明の第５実施例
は、ユーザー端末１１０と、予約システム１２０と、配
車システム１４０と、タクシー端末１３０と、これらを
相互に接続するインターネット等のネットワーク２００
とから構成されている。

【００５８】ユーザー端末１１０は、パーソナルコンピ
ュータ等の情報処理装置であり、携帯電話やＰＤＡも含
む。ユーザー端末１１０は、利用者が希望する乗車地や
降車地、乗車したい時刻といった希望予約情報、および
マッチングが成立したかどうかの連絡をもらうための連
絡先情報を、ネットワーク２００を介して予約システム
１２０に送出する機能を有する。

【００５９】予約システム１２０は、予約システム運営
者により使用され、ワークステーション・サーバ等の情
報処理装置によって構成される。予約システム１２０
は、利用者の操作によりユーザー端末１１０が送出した
希望予約情報と連絡先情報とを受け取り、マッチング処
理を行う機能を備えている。ここでいうマッチング処理
とは、相乗りをするのに都合の良い、他の利用者の希望
予約情報があるかどうかを判別する処理である。

【００６０】利用者が乗車したい時刻（希望乗車時刻）
になっても相乗りをするのに都合の良い相手が定員数に
達しなかった場合にはマッチングは不成立となる。一
方、時間内に、相乗りをするのに都合の良い者が定員数
に達した段階でマッチングが成立となる。なお、定員数
は、タクシー1台に乗せる利用者の人数とし、事前に固
定値として決めておく方法でもよいし、希望人数によっ
てその場で定員数を増やす（配車するタクシーの種類・
大きさを変更する）方法などでもよい。

【００６１】また、予約システム１２０は、マッチング
が成立した場合、利用者識別情報を生成して全員のユー
ザー端末１１０（連絡先）に、マッチングが成立した旨
と利用者識別情報を送信する機能を備えている。利用者
識別情報は、利用者と利用内容（希望予約情報）を識別
するための情報であり、一度の予約に固有の情報として
生成される。また、予約システム１２０は、マッチング
が成立した場合、配車システム１４０にマッチングの成
立した希望予約情報を送信し、配車を依頼する機能を備
えている。

【００６２】また、予約システム１２０は、マッチング
が成立した場合には、配車システム１４０にマッチング
の成立した希望予約情報を送信し、配車を依頼する機能
を備えている。一方、マッチングが成立しなかった場合
には、ユーザー端末１１０（連絡先）に、マッチングが
成立しなかった旨の連絡をする機能も備えている。

【００６３】配車システム１４０は、予約システム運営
者と予め契約しているタクシー業務運営者により運用さ
れ、予約システム１２０からマッチングの成立した各利
用者の希望予約情報を受け取ると、配車可能なタクシー
があるかないかの情報を予約システム１２０に送信する
機能を備えている。

【００６４】タクシー端末１３０は、配車システム１４
０を使用するタクシー営業者が所有するタクシーに設け
られる。タクシー端末１３０は、配車システム１４０か
らそのタクシーを利用する予定の各利用者の利用者識別
情報と希望予約情報を受け取り、保持する。

【００６５】次に、本実施例の動作について、マッチン
グが成立した場合のフローチャートを示す図１０を参照
して説明する。図１０において、予約システム１２０が
ユーザー端末１１０から送信されてきた希望予約情報を
用いてマッチング処理を行うまでの動作（図１０のステ
ップＥ１〜Ｅ８）は、上述の各実施例における動作（第
１の実施例でいえばステップＡ１〜Ａ８）と同様であ
る。また、マッチング処理の内容、およびマッチングが
成立しなかった場合の動作も同様である。

【００６６】マッチングが成立した場合、予約システム
１２０は、マッチングが成立した各利用者の希望予約情
報を配車システム１４０に送信する（ステップＥ９）。
配車システム１４０は、予約システム１２０から送信さ
れてきた希望予約情報を受信すると、配車するタクシー
があるかないかの情報を予約システム１２０に送信する
（ステップＥ１０）。

【００６７】すべての配車システム１４０から、配車す
るタクシーがないという情報が返信された場合には、予
約システム１２０は、マッチングが成立しなかった場合
と同様に、ユーザー端末１１０（連絡先）にその旨の情
報を送信する。

【００６８】配車システム１４０から、配車するタクシ
ーがあるという情報が返信された場合、予約システム１
２０は、利用者および利用内容（希望予約情報）を識別
するための利用者識別情報を生成し、マッチングが成立
した旨とともに、ユーザー端末１１０（連絡先）に送信
する（ステップＥ１１）。

【００６９】また、予約システム１２０は、配車システ
ム１４０に、マッチングの成立した各利用者の利用者識
別情報を送信する（ステップＥ１２）。なお、予約シス
テム運営者と契約をしているタクシー営業者が複数あ
り、配車システムが複数存在しても構わない。この場
合、利用者識別情報を送信する方法として下記のやり方
が考えられる。

【００７０】・予約システム１２０は全ての配車システ
ムに希望予約情報を送信し、配車可能なタクシーがある
という情報を返信した配車システムの１つを選んで（例
えば、返信が一番早かった配車システムを選ぶなど）、
利用者識別情報を送信する。

【００７１】・予めルールや順序を決めておき、その順
序に沿って配車システムに希望予約情報を送信し、配車
するタクシーがないという情報が返信された場合には、
次順位の配車システムに希望予約情報を送信する。

【００７２】次に、予約システム１２０から利用者識別
情報を受信した配車システム１４０は、配車するタクシ
ーのタクシー端末１３０に、マッチングの成立した各利
用者の利用者識別情報と、希望予約情報を送信する（ス
テップＥ１３）。

【００７３】タクシーは、配車システム１４０から送信
された、各利用者の希望予約情報に基づいて、各利用者
の乗車希望地をまわり、それぞれの利用者に対して、利
用者が提示する利用者識別情報と、タクシー端末１３０
に保持された利用者識別情報とを比較する（ステップＥ
１４）。タクシーは、これらの利用者識別情報が一致し
た場合には、代金と引き換えに利用者を乗車させ運行す
る（ステップＥ１５）。勿論、第２の実施例のように、
クレジットカードで決済する方法を採用すれば、代金を
授受することなく、そのまま乗車させる。

【００７４】以上のように、第５の実施例では、マッチ
ング処理を予約システム運営者が行うので、複数のタク
シー営業者がそれぞればらばらにマッチング処理を行う
よりも、数多くの利用者を集めることが可能であり、マ
ッチングの成立率を高めることができる。また、複数の
タクシー営業者が参加することにより、配車可能なタク
シーの台数が増え、マッチングが成立しても配車できる
タクシーがないという事態が起こる確率を減らすことが
できる。

【００７５】なお、上述の第５実施例では第１実施例と
の組合せで記述したが、第２実施例，第３実施例または
第４実施例と組み合せてもよい。

【００７６】

【発明の効果】本発明によれば、利用料金を含めたマッ
チングが成立した場合、つまり相乗りをするのに都合の
良い、料金了承済みの利用者が定員に達した場合に乗合
タクシーを配車する構成としたため、タクシー営業者は
採算に合わない利用者数でも定額で運行しなければなら
ないというリスクがなくなり、その結果、利用時刻と利
用場所の制約を緩和した利用客に対する利便性の提供サ
ービスを持続できるという効果が得られる。

【図面の簡単な説明】

【図１】本発明の相乗りタクシー予約システムの第１実
施例を示す図

【図２】本発明の第１実施例のフローチャート

【図３】本発明においてユーザー端末に表示される希望
予約情報画面のイメージ図

【図４】本発明においてユーザー端末に表示される希望
予約情報入力画面のイメージ図

【図５】本発明における乗車モデル例のイメージ図

【図６】本発明の第２実施例のフローチャート

【図７】本発明の第３実施例のフローチャート

【図８】本発明の第４実施例における主要な処理のフロ
ーチャート

【図９】本発明の相乗りタクシー予約システムの第５実
施例を示す図

【図１０】本発明の第５実施例のフローチャート

【符号の説明】

１０，１１０ ユーザー端末 ２０，１２０ 予約システム ３０，１３０ タクシー端末 １００，２００ ネットワーク １４０ 配車システム

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０７Ｂ 13/00 Ｇ０７Ｂ 13/00 Ｇ

Claims (7)

【特許請求の範囲】
1. 【請求項１】 サーバとして機能する予約システムと、
   タクシー営業者が所有するタクシーに備えられるタクシ
   ー端末と、利用者が前記タクシーの相乗りを予約するに
   当り希望する希望予約情報、および相乗りをするのに都
   合の良い他の利用者からの希望予約情報の有無について
   の連絡をもらうための連絡先情報を前記予約システムへ
   送信するユーザー端末とを通信ネットワークで接続し、 前記予約システムは、前記希望予約情報を受信すると当
   該ユーザー端末へ利用料金を提示し、前記連絡先情報の
   受信を該利用料金の了承と見なして、前記相乗りをする
   のに都合の良い他の利用者からの希望予約情報とのマッ
   チング処理を行い、マッチングが成立した場合には利用
   者識別情報を生成して、該当する全ユーザー端末にマッ
   チング成立の旨と利用者識別情報を送信し、また配車す
   るタクシーのタクシー端末へは前記利用者識別情報およ
   び前記希望予約情報を送信し、 前記利用者識別情報および前記希望予約情報を受信した
   タクシー端末は、該情報を保持しておき、当該タクシー
   は利用者から提示される利用者識別情報との一致を条件
   に前記希望予約情報に基づいて運行することを特徴とす
   る乗合タクシー予約・運行システム。
2. 【請求項２】 前記予約システムは、前記連絡先情報を
   受信すると、当該ユーザー端末に対してクレジットカー
   ド情報の入力を促進し、受信したクレジットカード情報
   により利用料金の決済をすることを特徴とする請求項１
   に記載の乗合タクシー予約・運行システム。
3. 【請求項３】 前記予約システムは、前記連絡先情報を
   受信すると、当該ユーザー端末に対して、いつまでに前
   記マッチング処理の結果を連絡してほしいかという最終
   連絡時刻情報の入力を促進し、受信した最終連絡時刻情
   報の時刻までに前記マッチング処理を行うことを特徴と
   する請求項１または請求項２に記載の乗合タクシー予約
   ・運行システム。
4. 【請求項４】 前記予約システムは、前記マッチングが
   まだ成立していない希望予約情報を他の利用者にホーム
   ページ上で公開することを特徴とする請求項１ないし請
   求項３のいずれかに記載の乗合タクシー予約・運行シス
   テム。
5. 【請求項５】 前記予約システムは、前記マッチングが
   まだ成立していない希望予約情報を過去に送信してきた
   ことのある利用者の連絡先へ通知して、タクシーの相乗
   りを勧誘することを特徴とする請求項１ないし請求項４
   のいずれかに記載の乗合タクシー予約・運行システム。
6. 【請求項６】 前記勧誘は、先ず、前記希望予約情報と
   同一の希望予約情報を送信したことのある第１パターン
   の利用者に対して行い、それでもマッチングが成立しな
   い場合には前記希望予約情報に含まれる区間を希望予約
   情報としたことのある第２パターンの利用者に対して行
   うことを特徴とする請求項５に記載の乗合タクシー予約
   ・運行システム。
7. 【請求項７】 複数のタクシー営業者を対象に予約シス
   テム運営者が運用しサーバとして機能する予約システム
   と、前記予約システム運営者と予め契約しているタクシ
   ー業務運営者が運用する配車システムと、前記タクシー
   営業者が所有するタクシーに備えられるタクシー端末
   と、利用者が前記タクシーの相乗りを予約するに当り希
   望する希望予約情報、および相乗りをするのに都合の良
   い他の利用者からの希望予約情報の有無についての連絡
   をもらうための連絡先情報を前記予約システムへ送信す
   るユーザー端末とを通信ネットワークで接続し、 前記予約システムは、前記希望予約情報を受信すると当
   該ユーザー端末へ利用料金を提示し、前記連絡先情報の
   受信を該利用料金の了承と見なして、前記相乗りをする
   のに都合の良い他の利用者からの希望予約情報とのマッ
   チング処理を行い、前記配車システムへマッチングの成
   立した希望予約情報を送信して配車を依頼し、配車可能
   なタクシーがある場合に利用者識別情報を生成して、該
   当する全ユーザー端末にマッチング成立の旨と利用者識
   別情報を送信し、また前記配車システムへ前記利用者識
   別情報を送信し、 前記配車システムは配車するタクシーのタクシー端末へ
   前記利用者識別情報および前記希望予約情報を送信し、 前記利用者識別情報および前記希望予約情報を受信した
   タクシー端末は、該情報を保持しておき、当該タクシー
   は利用者から提示される利用者識別情報との一致を条件
   に前記希望予約情報に基づいて運行することを特徴とす
   る請求項２ないし請求項６のいずれかに記載の乗合タク
   シー予約・運行システム。