JP6432205B2 - 予約管理方法、予約管理プログラムおよび予約管理装置 - Google Patents

Description

本発明は予約管理方法、予約管理プログラムおよび予約管理装置に関する。

現在、バスなど複数人が乗り合い可能な車両を、固定のスケジュールで運行する代わりに、ユーザからの要求に応じた可変のスケジュールで運行するオンデマンド型の公共交通システムが登場している。オンデマンド型の公共交通システムは、例えば、各ユーザから乗車場所、降車場所、希望時間帯などを指定した予約を受け付け、予約状況に応じて、車両を運行する時間帯、車両数、運行経路などを決定する。オンデマンド型の公共交通システムは、既存の公共交通システムの空白地域を補完する目的で運用されることがあり、また、人口減少や採算性の低下によって出発時刻や運行経路が固定である鉄道や路線バスを維持することが難しくなった地域において運用されることがある。

オンデマンド型の公共交通システムに関して、ユーザの予約作業を支援するシステムが提案されている。このシステムは、各ユーザの予約履歴から当該ユーザの定期的な移動パターンを検出し、検出した移動パターンに基づいて当該ユーザに対して次の予約を提案する。また、このシステムは、あるユーザに対して降車場所や時間帯などの点で行動が類似している他のユーザを検出し、当該ユーザがまだ降車したことがなくかつ行動が類似する他のユーザが頻繁に降車している場所を、新たな目的地として提案して利用を促す。

また、オンデマンド型の公共交通システムの運行経路を決定する方法として、ノード挿入法と呼ばれるアルゴリズムが提案されている。このアルゴリズムは、現在の運行経路に対して新たなユーザの乗降地点を追加する場合、経路長が最小となる位置に挿入する。

また、複数の乗り合い車両にユーザを割り振るスケジューリングシステムが提案されている。このスケジューリングシステムは、乗車地点または降車地点が異なるユーザを含むグループが同一車両への乗車を希望した場合、１つの車両に当該グループを割り当て、グループ内の一部のユーザのために乗換車両を用意することを検討する。また、医療機関からの帰宅時に複数の患者がタクシーを乗り合い使用することを支援する配車システムが提案されている。この配車システムは、乗り合いを希望する患者の中から診察時間帯と居住地域が共通する患者の集合を検出し、検出した患者の集合のために、診察時間帯に応じた時刻に医療機関へタクシーを配車するようタクシー会社に対して指示を出す。

特開２００２−３４２８７３号公報 特開２００３−２１６７２７号公報

国立大学法人 東京大学、日本アイ・ビー・エム株式会社、"東京大学と日本IBM、機能強化したオンデマンド交通システムを共同開発 三重県玉城町で今月より運用開始"、[online]、2011年11月21日、[2014年6月4日検索]、インターネット<URL:http://www.k.u-tokyo.ac.jp/news/20111121press.html> 山口周一郎、前田竜士、内村圭一、"Dial-a-Rideシステムにおける経路探索手法の提案"、第17回熊本県産学官技術交流会講演論文集 104、2003年1月21日

オンデマンド型の公共交通システムを運用している地域では、一便当たりの乗車人数や乗車率が少なく、維持コストに見合った収益を得られないことがある。そのため、システムは、ユーザの潜在的な需要を喚起すること、または、複数のユーザが出発日時の異なる別々の車両便ではなく可能であれば同じ車両便に乗車するよう促すことが好ましい。

しかし、非特許文献１に記載の方法は、目的地をユーザに提案するだけであり、ユーザが外出する動機付けが強いとは言えない。また、提案を受けたユーザは他のユーザとは独立に外出を検討するため、乗車する日時がユーザ間で分散してしまい乗車率が向上しない可能性がある。また、特許文献１に記載の方法は、同乗を希望するグループが既に形成されていることを前提としており、そのようなグループの形成を促すものではない。また、特許文献２に記載の方法は、同じ時間帯に同じ場所からの乗車を予定している複数のユーザが存在することを前提としており、そのようなユーザを増やすものではない。

１つの側面では、本発明は、複数のユーザが同じ車両便に乗車することを促す予約管理方法、予約管理プログラムおよび予約管理装置を提供することを目的とする。

１つの態様では、コンピュータが実行する予約管理方法が提供される。予約管理方法では、複数のユーザのうち一のユーザが乗車を予約した未出発の第１の車両便を示す予約便情報と、一のユーザを示す予約ユーザ情報とを含む予約情報を取得する。過去に運行した出発日時の異なる複数の第２の車両便それぞれを示す運行便情報に対して、複数のユーザのうち当該第２の車両便に乗車したユーザの情報を対応付けた履歴情報に基づいて、複数のユーザのうち一のユーザと同じ運行便情報が対応付けられた１または２以上の他のユーザを判定する。予約情報と対応付けて、判定した１または２以上の他のユーザのうち少なくとも一部の他のユーザを示す他ユーザ情報を出力する。

また、１つの態様では、コンピュータに実行させる予約管理プログラムが提供される。
また、１つの態様では、記憶部と判定部とを有する予約管理装置が提供される。記憶部は、過去に運行した出発日時の異なる複数の車両便それぞれを示す運行便情報に対して、複数のユーザのうち当該車両便に乗車したユーザの情報を対応付けた履歴情報を記憶する。判定部は、複数のユーザのうち一のユーザが乗車を予約した未出発の他の車両便を示す予約便情報と、一のユーザを示す予約ユーザ情報とを含む予約情報を取得し、履歴情報に基づいて、複数のユーザのうち一のユーザと同じ運行便情報が対応付けられた１または２以上の他のユーザを判定し、予約情報と対応付けて、判定した１または２以上の他のユーザのうち少なくとも一部の他のユーザを示す他ユーザ情報を出力する。

１つの側面では、複数のユーザが同じ車両便に乗車することを促すことができる。

第１の実施の形態の予約管理装置を示す図である。 第２の実施の形態の情報処理システムを示す図である。 予約者のユーザインタフェースの例を示す図である。 同乗候補者のユーザインタフェースの例を示す図である。 予約管理サーバのハードウェア例を示すブロック図である。 ユーザ端末のハードウェア例を示すブロック図である。 予約管理サーバとユーザ端末の機能例を示すブロック図である。 ユーザテーブルと場所テーブルと車両テーブルの例を示す図である。 運行予定情報の例を示す図である。 運行実績情報の例を示す図である。 乗車テーブルと同乗集計テーブルの例を示す図である。 予約者と予約管理サーバの間のメッセージ例を示す図である。 予約管理サーバと同乗候補者の間のメッセージ例を示す図である。 予約者端末の処理の手順例を示すフローチャートである。 同乗者端末の処理の手順例を示すフローチャートである。 予約管理サーバの処理の手順例を示すフローチャートである。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の予約管理装置を示す図である。

第１の実施の形態の予約管理装置１０は、オンデマンド型の交通システムの予約を管理する。この交通システムは、出発日時の異なる（出発日および出発時刻の少なくとも一方が異なる）複数の車両便を、ユーザからの予約状況に応じて運行する。例えば、ある出発日時について、予約期限までにユーザからの予約が少なくとも１件あれば当該出発日時に車両を運行し、予約が１件もなければ運行しない。複数の車両便それぞれには、バスやタクシーなど道路を走行可能な車両が用いられ、２以上のユーザが乗り合い可能である。複数の車両便が使用する車両は、同一でもよいし異なってもよい。ユーザは、乗車したい車両便を選択して乗車前に予約を行う。予約管理装置１０は、例えば、ユーザ端末からネットワークを介して予約を受け付ける。ただし、オペレータがユーザから口頭で予約を受け付け、予約内容を予約管理装置１０に入力してもよい。

予約管理装置１０は、記憶部１１および判定部１２を有する。予約管理装置１０は、コンピュータを用いて実装することが可能である。例えば、記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性メモリ、または、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性の記憶装置であってもよい。判定部１２は、ＣＰＵ（Central Processing Unit）やＤＳＰ（Digital Signal Processor）などのプロセッサであってもよい。また、判定部１２は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を含んでもよい。なお、プロセッサは、ＲＡＭなどのメモリに記憶されたプログラムを実行する。複数のプロセッサの集合（マルチプロセッサ）を「プロセッサ」と呼ぶこともある。

記憶部１１は、履歴情報１４を記憶する。履歴情報１４は、過去に運行した複数の車両便（複数の第２の車両便）それぞれを示す運行便情報を含む。また、履歴情報１４は、運行便情報と対応付けて、複数のユーザのうち当該運行便情報が示す第２の車両便に乗車したユーザの情報を含む。複数の第２の車両便は、車両便２１，２２を含む。複数のユーザは、ユーザＵ１，Ｕ２，Ｕ３を含む。例えば、Ｘ１日１０時出発の車両便２１には、ユーザＵ１，Ｕ２が乗車したとする。また、Ｘ２日１０時出発の車両便２２には、ユーザＵ２，Ｕ３が乗車したとする。降車可能な場所が２以上ある場合、履歴情報１４は、更にユーザＵ１，Ｕ２，Ｕ３の降車場所を示す降車場所情報を含んでもよい。

判定部１２は、予約情報１３を取得する。予約情報１３は、未出発の１または２以上の車両便（１または２以上の第１の車両便）のうち、あるユーザが乗車を予約した第１の車両便を示す予約便情報を含む。また、予約情報１３は、予約を行ったユーザを示す予約ユーザ情報を含む。例えば、Ｘ３日１０時出発の車両便２３およびＸ３日１５時出発の車両便２４への乗車を予約可能であるときに、ユーザＵ１が車両便２３への乗車を予約したとする。予約情報１３は、予約を行ったユーザの使用するユーザ端末からネットワーク経由で取得してもよい。また、予約情報１３は、オペレータからの入力によって取得してもよいし、予約完了後に予約内容を記憶するデータベースから抽出するようにしてもよい。

予約情報１３を取得すると、判定部１２は、予約を行ったユーザと同じ第２の車両便に乗車したことのある１または２以上の他のユーザを判定する。ユーザ間の関係を把握するにあたり、判定部１２は、記憶部１１に記憶された履歴情報１４に基づいて、あるユーザと同じ運行便情報が対応付けられた他のユーザを判定する。例えば、履歴情報１４において、車両便２１を示す運行便情報にユーザＵ１，Ｕ２の情報が対応付けられ、車両便２２を示す運行便情報にユーザＵ２，Ｕ３の情報が対応付けられているとする。すると、判定部１２は、履歴情報１４に基づいて、ユーザＵ１とユーザＵ２とが同じ第２の車両便に乗車したことがあると判定する。履歴情報１４に降車場所情報が含まれる場合、判定部１２は、あるユーザと同じ第２の車両便に乗車し、かつ、その第２の車両便において同じ場所で降車したことがある１または２以上の他のユーザを判定してもよい。

判定する他のユーザは、同じ第２の車両便に乗車する頻度が高い者、または、同じ第２の車両便に乗車し同じ場所で降車した頻度が高い者（例えば、該当する回数が閾値以上である者）に絞り込んでもよい。なお、判定部１２は、同じ第２の車両便に乗車したことがあるユーザの組み合わせや、同じ第２の車両便に乗車する頻度が高いユーザの組み合わせなどを、予約情報１３を取得する前に予め算出しておいてもよい。

１または２以上の他のユーザを判定すると、判定部１２は、予約情報１３と対応付けて、判定した他のユーザの少なくとも一部を示す他ユーザ情報１５を出力する。例えば、予約情報１３が、ユーザＵ１がＸ３日１０時の車両便２３を予約したことを示し、予約情報１３と対応付けられる他ユーザ情報１５が、ユーザＵ２を示す。他ユーザ情報１５が示す他のユーザは、予約を行ったユーザと同じ第１の車両便に乗車することを希望する可能性があり、同じ第１の車両便への乗車を提案する相手とすることが考えられる。

例えば、判定部１２は、他ユーザ情報１５が示す他のユーザに対応する宛先（例えば、電子メールアドレスやＩＰ（Internet Protocol）アドレスなど）を指定して、予約情報１３が示す第１の車両便への乗車を提案するメッセージを送信してもよい。また、オペレータが当該他のユーザに電話して、口頭で当該第１の車両便への乗車を提案してもよい。

第１の実施の形態の予約管理装置１０によれば、ユーザＵ１が車両便２３を予約すると、ユーザＵ１と同じ車両に乗車したことがある（または、同じ車両に乗車し同じ場所で降車したことがある）ユーザＵ２が判定される。そして、予約情報１３と対応付けて、ユーザＵ２を示す他ユーザ情報１５が出力される。例えば、ユーザＵ２に対して、車両便２３への乗車が提案される。このとき、ユーザＵ２はユーザＵ１の友人や知人である可能性がある。このように、履歴情報１４を用いてユーザ間の人間関係を分析し、人間関係に基づいて同じ車両便２３の利用を提案することで、提案を受けたユーザＵ２の心理的障壁を低くし、ユーザＵ２がユーザＵ１と同じ車両便２３に乗車する可能性を高くできる。

その結果、乗車人数または乗車率を向上させることができる。例えば、提案によってユーザＵ２の潜在的な需要を喚起する可能性があり、オンデマンド型の交通システムの総需要を増大させることができる。また、ユーザＵ１とユーザＵ２とが別々の車両便を予約してしまう可能性を減らし、同じ車両便２３に乗車する可能性を高くすることができ、車両便の数を減らしてオンデマンド型の交通システムの運営を効率化できる。

［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。
第２の実施の形態の情報処理システムは、オンデマンド型の公共交通システムの管理に用いられる。管理される公共交通システムは、車両４１，４２を含む複数の車両を、固定のスケジュールではなくユーザからの要求に応じた可変のスケジュールで運行する。車両４１，４２は、複数のユーザが乗り合い可能な自動車であり、例えば、マイクロバスや大型タクシーなど通常の路線バスよりも座席数の少ない車両である。この公共交通システムは、地方自治体や民間事業者などによって運営される。また、一般的には、この公共交通システムは、ユーザ登録を行ってコミュニティに所属したユーザから利用される。ある時間帯に車両４１，４２が運行するか否かや何れの経路を走行するかは、ユーザからの予約の状況に応じて変化する。

この公共交通システムを管理する情報処理システムは、予約管理サーバ１００を含む。予約管理サーバ１００は、ネットワーク３０に接続されたサーバコンピュータである。ネットワーク３０は、インターネットなどの広域データ通信網を含んでもよい。予約管理サーバ１００は、ネットワーク３０を介してユーザ端末２００，２００ａ，２００ｂから予約要求を受信することができる。予約要求では、ユーザが乗車を希望する時間帯、乗車場所、降車場所が指定される。予約管理サーバ１００は、予約要求に応じて時間帯毎に、走行させる車両や運行経路などの運行スケジュールを決定する。予約管理サーバ１００は、決定した運行スケジュールを各車両の運転手に通知する。例えば、予約管理サーバ１００は、車両４１，４２が備える運転手端末に運行スケジュールを送信する。

ユーザ端末２００，２００ａ，２００ｂは、コミュニティに属するユーザが操作する端末装置である。ユーザ端末２００，２００ａ，２００ｂは、スマートフォンなどの携帯電話機でもよいし、ＰＤＡ（Personal Digital Assistant）などの携帯情報端末であってもよい。また、ユーザ端末２００，２００ａ，２００ｂは、タブレット型コンピュータ、ノート型コンピュータ、デスクトップ型コンピュータなどのクライアントコンピュータであってもよい。ユーザ端末２００，２００ａ，２００ｂは、ネットワーク３０を介して予約管理サーバ１００にアクセスすることができる。このとき、ユーザ端末２００，２００ａ，２００ｂは、ネットワーク３０に含まれる基地局と無線リンクで接続してもよい。

例えば、ユーザ端末２００，２００ａ，２００ｂは、Ｗｅｂブラウザを起動し、Ｗｅｂブラウザ上でのユーザ操作に応じてＨＴＴＰ（Hypertext Transfer Protocol）を用いて予約管理サーバ１００にアクセスしてもよい。また、例えば、ユーザ端末２００，２００ａ，２００ｂは、予約管理に用いる端末ソフトウェアをダウンロードし、端末ソフトウェアを起動して予約管理サーバ１００と通信を行ってもよい。ただし、コミュニティに属するユーザは、ユーザ端末２００，２００ａ，２００ｂまたは他の電話機を用いて、口頭で座席の予約を行うようにしてもよい。この場合、電話を受け付けたオペレータが、予約管理サーバ１００に対して予約要求を入力するようにしてもよい。

ユーザは、識別情報を記憶したＩＣ（Integrated Circuit）カードを保持している。車両４１には、カードリーダ４１ａが設置されている。ユーザが車両４１を利用する場合、乗車時および降車時に、カードリーダ４１ａに当該ユーザのＩＣカードの識別情報を読み込ませる。カードリーダ４１ａは、読み込んだ識別情報と対応付けて、乗車場所、乗車時刻、降車場所、降車時刻などを示すカード履歴を記憶する。同様に、車両４２には、カードリーダ４２ａが設置されている。カードリーダ４１ａ，４２ａは、運行を終えて車庫に到着すると、予約管理サーバ１００にカード履歴を送信する。ただし、カードリーダ４１ａ，４２ａは、無線で随時、予約管理サーバ１００にカード履歴を送信してもよい。これにより、予約管理サーバ１００には、車両４１，４２の運行実績が蓄積される。ただし、ＩＣカードやカードリーダがない場合、運転手が把握したユーザの乗降状況に基づいて運行実績を予約管理サーバ１００に入力するようにしてもよい。

ここで、第２の実施の形態の情報処理システムは、車両４１，４２の乗車人数または乗車率が向上するように、座席を予約したユーザと異なる他のユーザに同乗を提案する提案機能を備える。提案機能により、提案を受けた他のユーザの潜在的な需要が喚起されて、公共交通システムの総需要量が増加する可能性がある。また、提案機能により、座席の予約が同じ時間帯に集約されて、車両４１，４２の運行回数を削減できる可能性がある。この提案機能は、同乗を促す要因として、ユーザ間のつながり（人間関係）を利用する。

具体的には、予約管理サーバ１００は、車両４１，４２の運行実績を分析して、同じ運行便（同じ時間帯の同じ車両）を利用して同じ場所に向かう頻度が高いユーザの組み合わせを検出する。予約管理サーバ１００は、あるユーザ（例えば、ユーザ端末２００のユーザ）がある運行便の座席を予約すると、当該ユーザと同乗する頻度が高い他のユーザ（例えば、ユーザ端末２００ａのユーザ）に同じ運行便の座席の予約を提案する。

なお、予約管理サーバ１００からユーザ端末２００，２００ａ，２００ｂへの同乗提案は、電子メールを用いて送信してもよい。また、ユーザ端末２００，２００ａ，２００ｂが端末ソフトウェアを常時実行しておき、端末ソフトウェアを用いて各自のユーザ端末宛ての同乗提案があるか定期的に予約管理サーバ１００に問い合わせるようにしてもよい。

図３は、予約者のユーザインタフェースの例を示す図である。
ここでは、ユーザ端末２００のユーザが座席を予約する場合を考える。
ユーザ端末２００のディスプレイには、画面５１が表示される。画面５１は、例えば、Ｗｅｂブラウザを用いて予約管理サーバ１００にアクセスしたとき、または、端末ソフトウェアを起動したときに表示される。画面５１は、希望日時を指定する入力フィールドと、乗車場所を指定する入力フィールドと、降車場所を指定する入力フィールドを含む。

希望日時は、ユーザが公共交通システムを利用したい日付と時間帯の組み合わせである。例えば、希望日時として２０１４年６月１日の１０時台を指定する。希望日時は、複数の選択肢の中から選択することができる。乗車場所は、予め設定された複数の停車可能な場所のうち、ユーザが乗車を希望する場所である。降車場所は、予め設定された複数の停車可能な場所のうち、ユーザが降車を希望する場所である。乗車場所および降車場所は、複数の選択肢の中から選択することができる。停車可能な場所を示す情報は、ユーザ端末２００が予約管理サーバ１００から受信してもよい。なお、ユーザ端末２００には、ユーザの自宅の緯度経度が記録されている。ＧＰＳによって測定された現在位置が自宅を指し示している場合、乗車場所の既定値として「自宅前」が自動的に選択され得る。

ユーザ端末２００は、画面５１で入力された希望日時、乗車場所、降車場所を含む予約要求を、予約管理サーバ１００に送信する。予約管理サーバ１００は、予約要求に応じて運行スケジュールを更新し、予約結果をユーザ端末２００に送信する。座席の予約に成功した場合、ユーザ端末２００のディスプレイには、画面５２が表示される。画面５２は、予約結果として、運行便、乗車場所、乗車時刻、降車場所、降車予定時刻の情報を含む。

運行便は、日付と時間帯の組み合わせによって特定され、原則として画面５１で入力された希望日時によって特定されるものである。画面５２に含まれる乗車場所および降車場所は、原則として画面５１で入力されたものと同じである。乗車時刻は、運行便が乗車場所に到着する時刻であり、現時点の運行スケジュールから予約管理サーバ１００が算出したものである。降車予定時刻は、運行便が降車場所に到着する時刻であり、現時点の運行スケジュールと標準的な道路混雑状況から予約管理サーバ１００が予測したものである。

また、座席の予約に成功した場合、予約管理サーバ１００は、ユーザ端末２００のユーザと同乗する可能性がある他のユーザ（同乗候補者）のリストを含む選択要求を、ユーザ端末２００に送信する。同乗候補者は、前述のように、予約管理サーバ１００が車両４１，４２の運行実績を分析することで算出される。同乗候補者は、ユーザ端末２００のユーザと同じ運行便を利用して同じ場所に向かう頻度が高い、すなわち、乗車する車両および時間帯と降車場所とが共通する頻度が高い他のユーザである。算出される同乗候補者は、ユーザ端末２００のユーザと友人関係にある可能性が高い。

ユーザ端末２００のディスプレイには、画面５３が表示される。画面５３は、同乗候補者の氏名のリストと、今回予約した運行便への同乗を提案する同乗候補者を選択する入力フィールドを含む。また、画面５３は、同乗候補者毎に、過去に同じ運行便に乗車しかつ同じ場所で降車したことのある回数（同乗回数）と、過去に画面５３において選択した回数（選択回数）のリストを含む。画面５３において、ユーザ端末２００のユーザは、１または２以上の同乗候補者を選択することができる。また、ユーザ端末２００のユーザは、全く同乗候補者を選択しないこともできる。ユーザ端末２００は、同乗候補者の選択結果を示す選択通知を、予約管理サーバ１００に送信する。

図４は、同乗候補者のユーザインタフェースの例を示す図である。
ここでは、ユーザ端末２００ａのユーザが同乗候補者である場合を考える。
ユーザ端末２００ａは、同乗提案を予約管理サーバ１００から受信する。ユーザ端末２００ａが同乗提案を受信する方法としては、前述のように、電子メールや端末ソフトウェアによるポーリングなど任意の通信方法を用いることができる。同乗提案を受信すると、ユーザ端末２００ａのディスプレイには、画面５４が表示される。画面５４は、予約者の氏名や予約された運行便、降車場所、降車予定時刻などの情報を含む。

画面５４に続いて、ユーザ端末２００ａのディスプレイには、画面５５が表示される。画面５５は、希望日時および降車場所を示す情報と、乗車場所を指定する入力フィールドとを含む。ユーザ端末２００ａのユーザが同乗を希望する場合、乗車する運行便および降車場所はユーザ端末２００のユーザと同じであるため、希望日時および降車場所は予め記入されている。乗車場所は、画面５１と同様に、複数の選択肢の中から選択することができる。なお、ユーザ端末２００ａには、ユーザ端末２００ａのユーザの自宅の緯度経度が記録されている。ＧＰＳによって測定された現在位置が自宅を指し示している場合、乗車場所の既定値として「自宅前」が自動的に選択され得る。

ユーザ端末２００ａは、画面５５で入力された乗車場所を含む予約要求を、予約管理サーバ１００に送信する。予約管理サーバ１００は、予約要求に応じて運行スケジュールを更新し、予約結果をユーザ端末２００ａに送信する。座席の予約に成功した場合、ユーザ端末２００ａのディスプレイには、画面５６が表示される。画面５６は、予約結果として、運行便、乗車場所、乗車時刻、降車場所、降車予定時刻の情報を含む。なお、画面５５において、ユーザ端末２００ａのユーザが同乗を希望しない場合、ユーザ端末２００ａから予約管理サーバ１００に予約要求は送信されず、画面５６は表示されない。

次に、予約管理サーバ１００とユーザ端末２００のハードウェアを説明する。
図５は、予約管理サーバのハードウェア例を示すブロック図である。
予約管理サーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７を有する。上記のユニットは、それぞれバス１０８に接続されている。

ＣＰＵ１０１は、プログラムの命令を実行する演算回路を含むプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを備えてもよく、予約管理サーバ１００は複数のプロセッサを備えてもよく、以下で説明する処理を複数のプロセッサまたはプロセッサコアを用いて並列に実行してもよい。また、複数のプロセッサの集合（マルチプロセッサ）を「プロセッサ」と呼んでもよい。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、予約管理サーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。プログラムには、車両の予約を管理する予約管理プログラムが含まれる。なお、予約管理サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

画像信号処理部１０４は、ＣＰＵ１０１からの命令に従って、予約管理サーバ１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ（ＰＤＰ：Plasma Display Panel）、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなどを用いることができる。

入力信号処理部１０５は、予約管理サーバ１００に接続された入力デバイス１１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１１２としては、マウスやタッチパネルやタッチパッドやトラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、予約管理サーバ１００に、複数の種類の入力デバイスが接続されていてもよい。

媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

通信インタフェース１０７は、ネットワーク３０に接続され、ユーザ端末２００，２００ａ，２００ｂと通信を行う。通信インタフェース１０７は、スイッチなどの通信装置とケーブルで接続される有線通信インタフェースでもよいし、基地局またはアクセスポイントと無線リンクで接続される無線通信インタフェースでもよい。

なお、予約管理サーバ１００は、媒体リーダ１０６を備えていなくてもよく、ユーザが操作する端末装置から制御可能である場合には画像信号処理部１０４や入力信号処理部１０５を備えていなくてもよい。また、ディスプレイ１１１や入力デバイス１１２が、予約管理サーバ１００の筐体と一体に形成されていてもよい。

図６は、ユーザ端末のハードウェア例を示すブロック図である。
ユーザ端末２００は、無線通信部２０１、ＣＰＵ２０２、ＲＡＭ２０３、不揮発性メモリ２０４、ディスプレイ２０５、タッチパネル２０６、スピーカ２０７ａ、マイクロホン２０７ｂおよびＧＰＳ受信機２０８を有する。上記のユニットは、それぞれバス２０９に接続されている。ユーザ端末２００ａ，２００ｂも、同様のハードウェアで実現できる。

無線通信部２０１は、ネットワーク３０に属する基地局またはアクセスポイントと無線リンクで接続され、無線通信を行う無線通信インタフェースである。無線通信部２０１は、基地局またはアクセスポイントを介して、予約管理サーバ１００と通信することができる。無線通信部２０１が準拠する無線通信規格としては、例えば、Ｗ−ＣＤＭＡ（Wideband - Code Division Multiple Access）、ＬＴＥ（Long Term Evolution）、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１などが挙げられる。ただし、ユーザ端末２００は、無線通信部２０１に代えてまたは無線通信部２０１と共に、通信装置とケーブルで接続される有線通信インタフェースを備えてもよい。

ＣＰＵ２０２は、予約管理サーバ１００のＣＰＵ１０１と同様、プログラムの命令を実行する演算回路を含むプロセッサである。ＲＡＭ２０３は、予約管理サーバ１００のＲＡＭ１０２と同様、ＣＰＵ２０２が実行するプログラムやＣＰＵ２０２が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。

不揮発性メモリ２０４は、各種ソフトウェアのプログラムおよびデータを記憶する不揮発性の記憶装置である。不揮発性メモリ２０４としては、例えば、フラッシュメモリやＳＳＤなどを用いることができる。記憶されるプログラムには、予約管理サーバ１００と連携して車両の予約などを行うアプリケーションプログラムが含まれてもよい。なお、ユーザ端末２００は、ＨＤＤなどの他の種類の記憶装置を備えてもよい。

ディスプレイ２０５は、予約管理サーバ１００のディスプレイ１１１と同様、ＣＰＵ２０２からの指示に応じて操作画面などの画像を表示する。ディスプレイ２０５としては、例えば、ＬＣＤや有機ＥＬディスプレイなどを用いることができる。前述の画面５１〜５６は、ディスプレイ２０５に表示することができる。

タッチパネル２０６は、ユーザからの入力を受け付ける入力装置である。タッチパネル２０６は、ディスプレイ２０５に重ねて設置される。タッチパネル２０６は、ディスプレイ２０５に表示された画面に対するユーザのタッチ操作を検出し、タッチ位置をＣＰＵ２０２に通知する。タッチ位置の検出方法としては、抵抗膜方式や静電容量方式などの任意のものを使用できる。なお、ユーザ端末２００は、タッチパネル２０６に代えてまたはタッチパネル２０６と共に、キーパッドなどの他の入力装置を備えてもよい。

スピーカ２０７ａは、ＣＰＵ２０２から音声信号としての電気信号を取得し、物理振動に変換して音を再生する。例えば、ユーザが通話を行っているとき、通話相手の声や背景雑音が再生される。マイクロホン２０７ｂは、音の物理振動を電気信号に変換し、音声信号としての電気信号をＣＰＵ２０２に出力する。例えば、ユーザが通話を行っているとき、ユーザの声や背景雑音がマイクロホン２０７ｂから入力される。

ＧＰＳ受信機２０８は、複数のＧＰＳ（Global Positioning System）衛星それぞれからＧＰＳ信号を受信し、受信したＧＰＳ信号を用いてユーザ端末２００の現在位置を算出する。ＧＰＳ信号には、ＧＰＳ衛星が当該ＧＰＳ信号を送信した時刻が含まれる。現在位置は、複数のＧＰＳ衛星からのＧＰＳ信号の伝送時間の違いに基づいて算出することができる。現在位置は、例えば、経度、緯度、高度で表現することができる。

次に、予約管理サーバ１００とユーザ端末２００の機能を説明する。
図７は、予約管理サーバとユーザ端末の機能例を示すブロック図である。
予約管理サーバ１００は、登録情報記憶部１２１、スケジュール記憶部１２２、履歴記憶部１２３、運行実績収集部１２４、ユーザ関係分析部１２５、運行予定更新部１２６、同乗候補者判定部１２７、同乗提案部１２８およびメッセージ通信部１２９を有する。

登録情報記憶部１２１、スケジュール記憶部１２２および履歴記憶部１２３は、例えば、ＲＡＭ１０２またはＨＤＤ１０３に確保した記憶領域として実現される。ただし、登録情報記憶部１２１、スケジュール記憶部１２２および履歴記憶部１２３のデータを、予約管理サーバ１００の外部の記憶装置に格納するようにしてもよい。運行実績収集部１２４、ユーザ関係分析部１２５、運行予定更新部１２６、同乗候補者判定部１２７、同乗提案部１２８およびメッセージ通信部１２９は、例えば、ＣＰＵ１０１が実行するプログラムのモジュールとして実装される。ただし、運行実績収集部１２４、ユーザ関係分析部１２５、運行予定更新部１２６、同乗候補者判定部１２７、同乗提案部１２８およびメッセージ通信部１２９の一部または全部を、専用の電子回路を用いて実装してもよい。

登録情報記憶部１２１は、ユーザまたはオペレータによって予め登録された情報を記憶する。登録情報記憶部１２１に記憶される情報には、ユーザの氏名などを示すユーザ情報と、停車可能な場所を示す場所情報と、車両の座席数などを示す車両情報とが含まれる。

スケジュール記憶部１２２は、各運行便の運行スケジュールを記憶する。運行スケジュールは、使用する車両、停車場所、停車予定日時、各停車場所での乗降予定者などを示す情報を含む。運行スケジュールは、ユーザ端末２００，２００ａ，２００ｂからの予約要求の受信に応じて、運行予定更新部１２６によって随時更新される。

履歴記憶部１２３は、車両４１，４２の運行実績を記憶する。運行実績は、運行スケジュールに対応し、使用した車両、停車場所、停車日時、各停車場所での乗降者などを示す情報を含む。運行実績は、運行実績収集部１２４によってカードリーダ４１ａ，４２ａから収集されることがある。また、運行実績は、運転手またはオペレータによって入力されることがある。また、履歴記憶部１２３は、同乗集計情報を記憶する。同乗集計情報は、一のユーザと他の一のユーザとが同じ運行便に乗車し同じ場所で降車した頻度を示す。同乗集計情報は、複数の運行便についての運行実績を分析することで生成される。

運行実績収集部１２４は、車両４１，４２が車庫に到着したとき、または、車両４１，４２の運行中に適宜、カードリーダ４１ａ，４２ａから運行実績を受信することがある。その場合、運行実績は、カードリーダ４１ａ，４２ａがユーザの乗車時および降車時にＩＣカードの識別情報を読み取ることで生成される。運行実績収集部１２４は、カードリーダ４１ａ，４２ａから受信した運行実績を履歴記憶部１２３に格納する。また、運行実績収集部１２４は、運転手が把握したユーザの乗降状況の入力を、運転手またはオペレータから受け付けることがある。その場合、運行実績収集部１２４は、入力に応じて運行実績を生成し履歴記憶部１２３に格納する。

ユーザ関係分析部１２５は、登録情報記憶部１２１に記憶されたユーザ情報や場所情報を参照して、履歴記憶部１２３に記憶された複数の運行便についての運行実績を分析する。ユーザ関係分析部１２５は、一のユーザと他の一のユーザとが同じ運行便に乗車し同じ場所で降車した頻度（同乗頻度）を示す同乗集計情報を生成し、履歴記憶部１２３に格納する。ユーザ関係分析部１２５は、間欠的に（定期的または不定期に）様々なユーザの組み合わせについて同乗頻度を算出しておくことが好ましい。ただし、ユーザ関係分析部１２５は、何れかのユーザが座席の予約を行ったときに、予約を行ったユーザと他のユーザとの間の同乗頻度をリアルタイムに算出するようにしてもよい。

運行予定更新部１２６は、メッセージ通信部１２９を介してユーザ端末２００，２００ａ，２００ｂから予約要求を受信する。すると、運行予定更新部１２６は、登録情報記憶部１２１に記憶された車両情報とスケジュール記憶部１２２に記憶された運行スケジュールを参照して、ユーザが希望する運行便に空き座席があるか判断する。空き座席がある場合、運行予定更新部１２６は、予約要求に従って座席の予約を実行する。すなわち、運行予定更新部１２６は、予約要求が指定する乗車場所および降車場所で停車するように運行経路を算出し、スケジュール記憶部１２２に記憶された運行スケジュールを更新する。

運行経路の算出方法としては、例えば、非特許文献２（山口周一郎、前田竜士、内村圭一、"Dial-a-Rideシステムにおける経路探索手法の提案"、第17回熊本県産学官技術交流会講演論文集 104）に記載されたノード挿入法を用いることができる。ノード挿入法では、経由する場所がノードとして表現され、運行経路がノード列として表現される。運行経路の始点（出発地）と終点（目的地）は、予め設定される。現在の運行経路に対して新たな乗車場所や降車場所を追加する場合、経路長が最小となるように、現在のノード列の中の何れかの区間に乗車場所や降車場所に相当する新たなノードを挿入する。

座席の予約に成功した場合、運行予定更新部１２６は、運行便、乗車日時、降車予定日時などを示す予約結果を、メッセージ通信部１２９を介して返信する。一方、満席などの理由で予約に失敗した場合、運行予定更新部１２６は、予約失敗を示す予約結果を返信する。また、座席の予約に成功した場合、運行予定更新部１２６は、予約が行われた運行便に更に空き座席があるか判断する。そして、運行予定更新部１２６は、他のユーザに同乗を提案するため、予約結果と空き座席数を同乗候補者判定部１２７に通知する。

同乗候補者判定部１２７は、登録情報記憶部１２１に記憶されたユーザ情報および場所情報と、履歴記憶部１２３に記憶された同乗集計情報を参照して、同乗候補者を判定する。同乗候補者は、予約を行ったユーザとの間で同乗頻度が高い他のユーザである。同乗候補者判定部１２７は、判定した同乗候補者のリストを含む選択要求を、予約要求を送信したユーザ端末に対してメッセージ通信部１２９を介して送信する。ただし、空き座席がない場合は、同乗候補者がないことを示す選択要求が送信される。その後、同乗候補者判定部１２７は、メッセージ通信部１２９を介して選択通知を受信する。同乗候補者判定部１２７は、選択された同乗候補者を示す情報と予約結果を同乗提案部１２８に通知する。

同乗提案部１２８は、同乗候補者判定部１２７から通知された同乗候補者が使用するユーザ端末に対して、提案者、運行便、降車場所、降車予定日時を示す同乗提案をメッセージ通信部１２９を介して送信する。提案者は、その同乗候補者を選択した予約者である。同乗提案は、例えば、電子メールを用いて送信することができる。その場合、登録情報記憶部１２１に記憶されたユーザ情報には、各ユーザの電子メールアドレスが含まれる。また、同乗提案は、例えば、同乗候補者のユーザ端末がポーリングによって予約管理サーバ１００にアクセスしたときに送信することができる。なお、同乗提案に対する同乗候補者からの予約要求は、運行予定更新部１２６によって受信される。

メッセージ通信部１２９は、ユーザ端末２００，２００ａ，２００ｂとの間で各種メッセージを送受信する。メッセージ通信部１２９は、受信した予約要求を運行予定更新部１２６に渡し、運行予定更新部１２６が生成した予約結果を送信する。また、メッセージ通信部１２９は、同乗候補者判定部１２７が生成した選択要求を送信し、受信した選択通知を同乗候補者判定部１２７に渡す。また、メッセージ通信部１２９は、同乗提案部１２８が生成した同乗提案を送信する。メッセージ形式の詳細は後述する。

ユーザ端末２００は、ユーザ情報記憶部２２１、画面制御部２２２およびメッセージ通信部２２３を有する。ユーザ情報記憶部２２１は、例えば、ＲＡＭ２０３または不揮発性メモリ２０４に確保した記憶領域として実現される。画面制御部２２２およびメッセージ通信部２２３は、例えば、ＣＰＵ２０２が実行するプログラムのモジュールとして実装される。ユーザ端末２００ａ，２００ｂも、同様のモジュール構成で実現できる。

ユーザ情報記憶部２２１は、ユーザ端末２００を使用するユーザの識別情報（ユーザＩＤ）を記憶する。また、ユーザ情報記憶部２２１は、ユーザ端末２００を使用するユーザの自宅の位置を示す位置情報を記憶する。自宅の位置は、ＧＰＳ受信機２０８によって測定された現在位置と比較されるものであり、経度緯度によって表現される。ユーザＩＤおよび位置情報は、ユーザの操作に応じてユーザ情報記憶部２２１に予め格納される。

画面制御部２２２は、ディスプレイ２０５に表示する画面を制御する。画面制御部２２２は、Ｗｅｂブラウザを用いて実装されてもよいし、専用の端末ソフトウェアを用いて実装されてもよい。画面制御部２２２は、ユーザが座席を予約したいとき、予約内容を入力する画面５１をディスプレイ２０５に表示する。このとき、画面制御部２２２は、乗車場所や降車場所の選択肢を示す情報を予約管理サーバ１００から取得してもよい。画面制御部２２２は、画面５１に対するユーザの入力操作に応じて予約要求を生成する。

予約要求に対する予約結果を取得すると、画面制御部２２２は、予約内容を示す画面５２をディスプレイ２０５に表示する。その後、選択要求を取得すると、画面制御部２２２は、同乗を提案する他のユーザを選択する画面５３をディスプレイ２０５に表示する。画面制御部２２２は、画面５３に対するユーザの選択操作に応じて選択通知を生成する。

また、画面制御部２２２は、他のユーザが座席を予約したときに、同乗提案を取得することがある。すると、画面制御部２２２は、他のユーザの予約内容を示す画面５４をディスプレイ２０５に表示し、提案を受け入れて同乗する場合に予約内容を入力する画面５５をディスプレイ２０５に表示する。画面制御部２２２は、画面５５に対するユーザの入力操作に応じて同乗の予約要求を生成する。同乗の予約要求に対する予約結果を取得すると、画面制御部２２２は、予約内容を示す画面５６をディスプレイ２０５に表示する。

メッセージ通信部２２３は、予約管理サーバ１００との間で各種メッセージを送受信する。メッセージ通信部２２３は、画面制御部２２２が生成した予約要求を送信し、受信した予約結果を画面制御部２２２に渡す。また、メッセージ通信部２２３は、受信した選択要求を画面制御部２２２に渡し、画面制御部２２２が生成した選択通知を送信する。また、メッセージ通信部２２３は、受信した同乗提案を画面制御部２２２に渡す。

図８は、ユーザテーブルと場所テーブルと車両テーブルの例を示す図である。
ユーザテーブル１３１は、登録情報記憶部１２１に記憶されている。ユーザテーブル１３１には、公共交通システムを利用することがあるユーザが予め登録される。ユーザテーブル１３１は、ユーザＩＤ、氏名および自宅住所の項目を有する。ユーザＩＤは、ユーザ登録時に予約管理サーバ１００が当該ユーザに付与した識別情報である。氏名および自宅住所は、ユーザ登録時に申請した当該ユーザの氏名と自宅の住所である。

場所テーブル１３２は、登録情報記憶部１２１に記憶されている。場所テーブル１３２には、車両４１，４２が停車可能な場所であって、ユーザが乗車場所または降車場所として選択可能な場所が予め登録される。場所テーブル１３２は、場所ＩＤ、場所名、座標およびカテゴリの項目を有する。場所ＩＤは、場所を識別する識別情報である。場所名は、場所の特徴を表すユーザが理解容易な名称であり、その場所の近隣に存在する施設の名称を用いてもよい。座標は、場所の位置を経度緯度を用いて表現したものである。カテゴリは、その場所で降車する目的の種類を表現したものであり、その場所の近隣に存在する施設の種類（例えば、入浴施設、公共施設、ショッピングセンタなど）を用いてもよい。

車両テーブル１３３は、登録情報記憶部１２１に記憶されている。車両テーブル１３３には、マイクロバスや大型タクシーなど、公共交通システムで使用する車両が予め登録される。車両テーブル１３３は、車両ＩＤおよび座席数の項目を有する。車両ＩＤは、車両を識別する識別情報である。座席数は、ユーザが着席可能な座席の数であり、全員着席が求められる車両における保安定員に相当する。第２の実施の形態では、ある運行便に予約要求が発生したとき、その予約要求の乗車区間と既存の予約の乗車区間との間の重なりを調べ、予約要求の乗車区間の中の少なくとも一部の区間で重なり数（予約数）が座席数に達すると、その運行便の該当区間は満席と判断されてその予約要求は拒否される。ただし、立ち乗車を許容し、座席数より多い予約を受け付けるようにしてもよい。また、座席数に代えて車両テーブル１３３に定員を登録し、予約数が定員に達するまで予約を受け付けるようにしてもよい。定員は、座席数に所定数を加えた値としてもよい。

図９は、運行予定情報の例を示す図である。
運行予定情報１３４は、運行予定更新部１２６によって運行便毎に生成され、スケジュール記憶部１２２に格納される。運行予定情報１３４は、予定ＩＤ、車両、出発地、出発日時、乗車者、目的地、到着予定日時および降車者の項目を有する。また、運行予定情報１３４は、経由場所毎に、停車場所、停車予定日時および乗降者の項目を有する。

予定ＩＤは、出発前の運行便を識別する識別情報である。運行便は、日付と時間帯と車両の組み合わせによって特定される。運行便に使用される車両は、車両テーブル１３３に登録された車両ＩＤを用いて表現される。出発地は、運行経路の始点となる場所であり、場所テーブル１３２に登録された場所ＩＤを用いて表現される。出発日時は、車両が出発地を発つ予定日時である。乗車者は、出発地において乗車する予定のユーザであり、ユーザテーブル１３１に登録されたユーザＩＤを用いて表現される。

停車場所は、出発地と目的地との間で停車する場所（経由する場所）であり、場所ＩＤを用いて表現される。停車予定日時は、車両が停車場所に到着する予定日時である。乗降者は、停車場所において乗車または降車する予定のユーザであり、ユーザＩＤを用いて表現される。乗車するユーザと降車するユーザは、フラグを用いて区別される。例えば、フラグ＝１（ＯＮ）は乗車を表し、フラグ＝０（ＯＦＦ）は降車を表す。停車場所が複数ある場合、それら複数の停車場所は停車順に列挙され、停車場所毎に停車予定日時と乗降者が登録される。目的地は、運行経路の終点となる場所であり、場所ＩＤを用いて表現される。到着予定日時は、車両が目的地に到着する予定日時である。降車者は、目的地において降車する予定のユーザであり、ユーザＩＤを用いて表現される。

あるユーザが座席を予約すると、運行予定情報１３４が更新される。このとき、そのユーザの乗車場所および降車場所と対応付けて、そのユーザのユーザＩＤが運行予定情報１３４に登録される。これに伴い、停車場所が追加されて運行経路が変更されることがある。運行経路は、前述のノード挿入法などのアルゴリズムを用いて算出することができる。運行経路が変更されると、各停車場所の停車予定日時や到着予定日時が変更されることがある。停車予定日時や到着予定日時は、地図データを用いて算出される走行距離と、走行する道路の標準的な混雑状況とに基づいて予測することができる。

なお、予約管理サーバ１００は、出発日時の所定時間（例えば、３０分）前まで座席の予約を受け付けることができる。例えば、１０時台の運行便についての予約は、９時３０分まで受け付けられる。予約期限を過ぎた後の予約要求は拒否される。

図１０は、運行実績情報の例を示す図である。
運行実績情報１３５は、運行便の実績を示すものであり、運行予定情報１３４に対応する。運行実績情報１３５は、ある車両が運行予定情報１３４に従って走行した後に生成され、履歴記憶部１２３に格納される。運行実績情報１３５は、実績ＩＤ、車両、出発地、出発日時、乗車者、目的地、到着日時および降車者の項目を有する。また、運行実績情報１３５は、経由場所毎に、停車場所、停車日時および乗降者の項目を有する。

実績ＩＤは、過去の運行便を識別する識別情報である。実績ＩＤとして、運行予定情報１３４に登録された予定ＩＤを用いてもよい。車両、出発地、停車場所および目的地は、運行予定情報１３４に登録されたものと同じである。出発日時は、車両が出発地を発った日時である。乗車者は、出発地において乗車したユーザであり、ユーザテーブル１３１に登録されたユーザＩＤを用いて表現される。停車日時は、車両が停車場所に到着した日時である。乗降者は、停車場所において乗車または降車したユーザであり、ユーザＩＤを用いて表現される。到着日時は、車両が目的地に到着した日時である。降車者は、目的地において降車したユーザであり、ユーザＩＤを用いて表現される。

出発日時および到着日時は、例えば、運転手の操作に応じて記録される。各停車場所の停車日時は、例えば、カードリーダ４１ａ，４２ａがＩＣカードの識別情報を読み取った日時から算出できる。乗車者、降車者および各停車場所の乗降者は、例えば、カードリーダ４１ａ，４２ａが読み取ったＩＣカードの識別情報から特定できる。ただし、運転手が把握した運行状況に応じて、運転手またはオペレータが出発日時、乗車者、各停車場所の停車日時、各停車場所の乗降者、到着日時および降車者を入力してもよい。また、各車両にＧＰＳ受信機を搭載して、ＧＰＳ位置情報と時刻情報とを対応付けて記録しておき、この記録から出発日時、各停車場所の停車日時および到着日時を推定してもよい。

なお、運行実績情報１３５の乗車者、降車者および各停車場所の乗降者は、運行予定情報１３４に登録されたユーザと一致するか、または、運行予定情報１３４に登録されたユーザよりも少ない。

図１１は、乗車テーブルと同乗集計テーブルの例を示す図である。
乗車テーブル１３６は、履歴記憶部１２３に記憶されている。乗車テーブル１３６は、運行実績情報１３５が履歴記憶部１２３に格納されるときに、運行実績収集部１２４によって併せて更新される。乗車テーブル１３６は、ユーザＩＤおよび実績ＩＤの項目を有する。乗車テーブル１３６のユーザＩＤは、ある運行便に乗車したユーザを識別する。乗車テーブル１３６の実績ＩＤは、その運行便の運行実績情報１３５を識別する。乗車テーブル１３６では、ユーザＩＤと実績ＩＤとが多対多に対応付けられる。すなわち、乗車テーブル１３６は、何れのユーザが何れの運行便に乗車したかを示す。ある運行便に乗車したユーザのユーザＩＤは、運行実績情報１３５から抽出することができる。

同乗集計テーブル１３７は、履歴記憶部１２３に記憶されている。同乗集計テーブル１３７は、ユーザ関係分析部１２５が運行実績情報１３５および乗車テーブル１３６を分析することで更新される。この分析は、例えば、一定期間の運行便の情報が履歴記憶部１２３に蓄積されたときにバッチ方式で実行される。同乗集計テーブル１３７は、ユーザＩＤ、同乗者、同乗回数、選択回数、カテゴリおよび除外ユーザの項目を有する。

ユーザＩＤは、公共交通システムを利用したことのあるユーザを示す。同乗者は、ユーザＩＤが示すユーザと同じ運行便に乗車しかつ同じ場所で降車したことのある他のユーザである。例えば、ユーザ関係分析部１２５は、あるユーザが乗車した運行便を乗車テーブル１３６から検索する。そして、ユーザ関係分析部１２５は、検索した運行便についての運行実績情報１３５から当該ユーザの降車場所を特定し、同じ場所で降車した他のユーザを検出する。同乗者は、ユーザテーブル１３１に登録されたユーザＩＤで表現できる。

同乗回数は、ユーザＩＤが示すユーザと「同乗者」とが過去に同乗した回数、すなわち、同じ運行便に乗車しかつ同じ場所で降車した回数である。同乗回数は、運行実績情報１３５および乗車テーブル１３６を用いて、上記の方法によってカウントすることができる。同乗回数をカウントする対象とする運行便は、直近の一定期間内の運行便に限定してもよい。選択回数は、ユーザＩＤが示すユーザが、画面５３において「同乗者」を選択した回数である。選択回数は、選択通知に応じて同乗候補者判定部１２７によって更新される。選択回数は、一定期間毎にリセットするようにしてもよい。なお、選択回数に代えて、選択回数を画面５３に「同乗者」が表示された回数で割った選択率を登録してもよい。

カテゴリは、ユーザＩＤが示すユーザと「同乗者」とが降車した場所の種類であり、場所テーブル１３２に登録されたものである。同乗回数は、降車場所のカテゴリ毎に区分してカウントされる。例えば、一のユーザと他の一のユーザとが、近隣に入浴施設が存在する場所でｍ回同時に降車したことがあり、近隣に公共施設（例えば、図書館や公民館）が存在する場所でｎ回同時に降車したことがあるとする。この場合、入浴施設についての同乗回数ｍと公共施設についての同乗回数ｎとが区別されてカウントされる。

除外ユーザは、ユーザＩＤが示すユーザにとって同乗候補者にならない他のユーザである。除外ユーザは、ユーザテーブル１３１に登録されたユーザＩＤを用いて表現できる。ユーザは、除外ユーザを予め同乗集計テーブル１３７に登録しておくことができる。予約管理サーバ１００は、あるユーザと同乗頻度が高い他のユーザは、そのユーザの友人や知人であると推定して、同乗候補者を判定する。これに対し、予約管理サーバ１００の上記の判定が妥当でない場合（例えば、同乗頻度が高い特定の他のユーザが、友人や知人でない場合）には、除外ユーザを設定することで判定精度を改善できる。

なお、ユーザ関係分析部１２５は、同乗候補者の判定精度を向上させるため、過去の運行便のうち所定の条件を満たす運行便を除外して、同乗回数をカウントするようにしてもよい。例えば、通勤時間帯には、友人や知人でない多くのユーザが同じ運行便に乗車し、近隣に駅や勤務地が存在する場所で降車する可能性がある。そこで、ユーザ関係分析部１２５は、通勤時間帯の運行便を除外して同乗回数をカウントすることが考えられる。

次に、予約管理サーバ１００およびユーザ端末２００，２００ａ，２００ｂの間で送信されるメッセージについて説明する。ここでは、ユーザ端末２００のユーザが座席を予約し、ユーザ端末２００ａのユーザに対して同乗を提案する場合を考える。

図１２は、予約者と予約管理サーバの間のメッセージ例を示す図である。
ユーザ端末２００は、予約要求６１を予約管理サーバ１００に送信する。予約要求６１は、ユーザＩＤ、希望日時、乗車場所および降車場所の項目を有する。ユーザＩＤは、ユーザ端末２００を使用するユーザを示す。希望日時、乗車場所および降車場所は、画面５１においてユーザが入力したものである。ただし、乗車場所および降車場所は、場所テーブル１３２に登録された場所ＩＤを用いて表現される。場所名と場所ＩＤとの間の対応関係を示す情報は、予めユーザ端末２００に記憶されていてもよいし、予約管理サーバ１００からユーザ端末２００に適宜ダウンロードされてもよい。

予約管理サーバ１００は、予約要求６１に応答して、予約結果６２をユーザ端末２００に送信する。予約結果６２は、ユーザＩＤ、予定ＩＤ、乗車場所、乗車日時、降車場所および降車日時の項目を有する。ユーザＩＤは、予約要求６１と同じものである。予定ＩＤは、運行予定情報１３４に含まれるものであり、予約された運行便を識別する。乗車場所および降車場所は、予約要求６１で指定されたものである。ただし、予約結果６２では、画面５２の表示が容易になるように、場所名を用いて乗車場所および降車場所が表現されている。乗車日時は、予約された運行便が乗車場所に到着する予定日時である。降車日時は、予約された運行便が降車場所に到着する予定日時である。

予約管理サーバ１００は、予約結果６２に続いて、選択要求６３をユーザ端末２００に送信する。選択要求６３は、ユーザＩＤ、候補者、氏名、同乗回数および選択回数の項目を有する。ユーザＩＤは、予約要求６１および予約結果６２と同じものである。候補者は、予約された運行便に同乗する可能性のある他のユーザ（同乗候補者）であり、同乗集計テーブル１３７に基づいて判定される。候補者は、ユーザＩＤを用いて表現される。氏名は、候補者の氏名である。同乗回数は、ユーザ端末２００を使用するユーザと候補者とが過去に同乗した回数である。選択回数は、ユーザ端末２００を使用するユーザが画面５３において、同乗を提案する相手として候補者を選択した回数である。

ユーザ端末２００は、選択要求６３に応答して、選択通知６４を予約管理サーバ１００に送信する。選択通知６４は、ユーザＩＤおよび候補者の項目を有する。ユーザＩＤは、選択要求６３と同じものである。候補者は、画面５３においてユーザが選択した他のユーザである。候補者は、ユーザＩＤを用いて表現される。画面５３において、ユーザは１つの同乗候補者も選択しないことがあり、また、複数の同乗候補者を選択することがある。よって、選択通知６４に含まれる候補者のユーザＩＤは、０個または１個以上である。

図１３は、予約管理サーバと同乗候補者の間のメッセージ例を示す図である。
予約管理サーバ１００は、ユーザ端末２００のユーザ（予約者）によってユーザ端末２００ａのユーザ（同乗候補者）が選択されると、同乗提案６５をユーザ端末２００ａに送信する。同乗提案６５は、ユーザＩＤ、提案者、予定ＩＤ、降車場所および降車日時の項目を有する。ユーザＩＤは、同乗候補者を示す。提案者は、予約者である。提案者は、画面５４の表示が容易になるように、氏名で表現される。予定ＩＤは、予約された運行便を示す。降車場所は、予約者が降車予定の場所である。降車場所は、画面５４の表示が容易になるように、場所名で表現される。降車日時は、降車場所に到着する予定日時である。

ユーザ端末２００ａは、同乗提案６５に応答して、予約要求６６を予約管理サーバ１００に送信する。予約要求６６は、ユーザＩＤ、予定ＩＤ、乗車場所および降車場所の項目を有する。ユーザＩＤ、乗車場所および降車場所は、予約要求６１と同じものである。予定ＩＤは、予約された運行便を示す。予約要求６６は、ユーザ端末２００ａのユーザがユーザ端末２００のユーザと同じ運行便に乗車することを要求している。よって、予約要求６１では希望日時が指定されるのに対し、予約要求６６では予定ＩＤが指定される。なお、同乗候補者が指定する乗車場所は、予約者が指定した乗車場所と異なる可能性がある。

予約管理サーバ１００は、予約要求６６に応答して、予約結果６７をユーザ端末２００ａに送信する。予約結果６７は、ユーザＩＤ、予定ＩＤ、乗車場所、乗車日時、降車場所および降車日時の項目を有する。これらの項目は、予約結果６２と同じものである。ユーザ端末２００ａを使用するユーザは、独立の予約者ではなく、独立の予約者から誘われた同乗者である。よって、予約結果６７の後に選択要求は送信されない。

次に、予約管理サーバ１００およびユーザ端末２００が行う処理について説明する。ユーザ端末２００ａ，２００ｂも、ユーザ端末２００と同様の処理を行うことができる。
図１４は、予約者端末の処理の手順例を示すフローチャートである。

ここでは、ユーザ端末２００のユーザが座席を予約する場合を考える。
（Ｓ１０）画面制御部２２２は、予約内容を入力する画面５１をディスプレイ２０５に表示する。予約内容には、希望日時、乗車場所および降車場所の情報が含まれる。乗車場所や降車場所は、停車可能な複数の場所の中から選択することができる。停車可能な場所を示す情報は、例えば、予約管理サーバ１００から取得される。画面５１を表示するとき、画面制御部２２２は、ＧＰＳ受信機２０８が測定したユーザ端末２００の現在位置を検出する。画面制御部２２２は、ユーザ情報記憶部２２１に記憶された位置情報が示す自宅位置と現在位置とを比較して、ユーザ端末２００を使用するユーザが自宅にいるか判定する。ユーザが自宅にいる場合、乗車場所の初期値を当該ユーザの自宅前に設定する。

（Ｓ１１）メッセージ通信部２２３は、画面５１で入力された予約内容を示す予約要求６１を、予約管理サーバ１００に送信する。予約要求６１には、入力された希望日時、乗車場所および降車場所の情報に加え、予約を行うユーザのユーザＩＤが含まれる。なお、画面５１が表示される前に、ユーザＩＤおよびパスワードを用いてユーザ端末２００と予約管理サーバ１００との間でログイン手続が行われてもよい。

（Ｓ１２）メッセージ通信部２２３は、予約結果６２を予約管理サーバ１００から受信する。満席や予約期限経過などが原因で予約に失敗した場合、予約結果６２には、予約失敗を示す情報が含まれる。予約に成功した場合、予約結果６２には、予定ＩＤ、乗車場所、乗車日時、降車場所および降車日時の情報が含まれる。予定ＩＤは、日付と時間帯と車両の組み合わせによって特定される運行便を識別する。乗車日時と降車日時は、現在の運行経路から予約管理サーバ１００が予測した日時である。

（Ｓ１３）画面制御部２２２は、予約結果６２に応じて画面５２をディスプレイ２０５に表示する。満席や予約期限経過などが原因で予約に失敗した場合、画面５２にはその旨が表示される。予約に成功した場合、画面５２には、予約された運行便の日付と時間帯、乗車場所、乗車時刻、降車場所および降車予定時刻が表示される。

（Ｓ１４）画面制御部２２２は、予約結果６２に基づいて、予約に成功したか判断する。予約に成功した場合はステップＳ１５に処理が進み、予約に失敗した場合は予約者端末の処理を終了する。このとき、再び画面５１をディスプレイ２０５に表示してもよい。

（Ｓ１５）メッセージ通信部２２３は、選択要求６３を予約管理サーバ１００から受信する。ただし、選択要求６３を、予約結果６２と同時に受信するようにしてもよい。選択要求６３には、同乗候補者のリストと、各同乗候補者の同乗回数および選択回数の情報が含まれる。リストは、２人以上の同乗候補者を含むことがあり、また、条件に該当する他のユーザが存在しない場合には１人の同乗候補者も含まないことがある。

（Ｓ１６）画面制御部２２２は、１人以上の同乗候補者が選択要求６３に記載されているか判断する。１人以上の同乗候補者が記載されている場合はステップＳ１７に処理が進み、同乗候補者が記載されていない場合は予約者端末の処理を終了する。

（Ｓ１７）画面制御部２２２は、選択要求６３に応じて画面５３をディスプレイ２０５に表示する。画面５３には、同乗候補者それぞれの氏名、同乗回数および選択回数が表示される。ユーザ端末２００のユーザは、画面５３において、予約した運行便への同乗を提案する同乗候補者を選択する。ユーザは、２人以上の同乗候補者を選択することができ、また、１人の同乗候補者も選択しないこともできる。なお、同乗回数と選択回数は、ユーザによる同乗候補者の選択を支援するために画面５３に表示される。

（Ｓ１８）メッセージ通信部２２３は、選択通知６４を予約管理サーバ１００に送信する。選択通知６４には、ユーザによって選択された同乗候補者を示す情報が含まれる。
図１５は、同乗者端末の処理の手順例を示すフローチャートである。

ここでは、ユーザ端末２００のユーザが同乗候補者として選択された場合を考える。
（Ｓ２０）メッセージ通信部２２３は、同乗提案６５を予約管理サーバ１００から受信する。同乗提案６５には、提案者、予定ＩＤ、降車場所および降車日時の情報が含まれる。提案者は、ユーザ端末２００のユーザを同乗候補者として選択した他のユーザである。予定ＩＤは、提案者が予約した運行便を示す。なお、メッセージ通信部２２３は、同乗提案６５を電子メールとして受信してもよい。また、メッセージ通信部２２３は、電子メールの受信を契機として予約管理サーバ１００にアクセスし、同乗提案６５を取得するようにしてもよい。また、メッセージ通信部２２３は、定期的に予約管理サーバ１００にアクセスし、ユーザ端末２００宛ての同乗提案６５が存在するか確認してもよい。

（Ｓ２１）画面制御部２２２は、同乗提案６５に応じて画面５５をディスプレイ２０５に表示する。画面５５には、提案者の氏名、提案者が予約した運行便の日付と時間帯、降車場所および降車予定時刻が表示される。その後、画面制御部２２２は、画面５６をディスプレイ２０５に表示する。同乗を希望する場合、ユーザ端末２００のユーザは、画面５６において乗車場所を入力する。希望日時や降車場所は、提案者の予約と同じであるため入力しなくてもよい。一方、同乗を希望しない場合、ユーザ端末２００のユーザは、画面５６において座席の予約が不要であることを示す操作を行うことができる。

なお、乗車場所は、停車可能な複数の場所の中から選択することができる。停車可能な場所を示す情報は、例えば、予約管理サーバ１００から取得される。画面５６を表示するとき、画面制御部２２２は、ＧＰＳ受信機２０８が測定したユーザ端末２００の現在位置を検出する。画面制御部２２２は、ユーザ情報記憶部２２１に記憶された位置情報が示す自宅位置と現在位置とを比較して、ユーザ端末２００を使用するユーザが自宅にいるか判定する。ユーザが自宅にいる場合、乗車場所の初期値を当該ユーザの自宅前に設定する。

（Ｓ２２）画面制御部２２２は、ユーザ端末２００のユーザが画面５６に対して同乗希望の操作を行ったか判断する。同乗希望の操作を行った場合はステップＳ２３に処理が進み、同乗希望の操作を行わなかった場合は同乗者端末の処理を終了する。

（Ｓ２３）メッセージ通信部２２３は、予約要求６６を予約管理サーバ１００に送信する。予約要求６６には、ユーザ端末２００を使用するユーザのユーザＩＤ、予定ＩＤ、入力された乗車場所および降車場所の情報が含まれる。予定ＩＤと降車場所は、同乗提案６５に記載されていたものを用いることができる。

（Ｓ２４）メッセージ通信部２２３は、予約結果６７を予約管理サーバ１００から受信する。満席や予約期限経過などが原因で予約に失敗した場合、予約結果６７には、予約失敗を示す情報が含まれる。予約に成功した場合、予約結果６７には、予定ＩＤ、乗車場所、乗車日時、降車場所および降車日時の情報が含まれる。乗車日時と降車日時は、現在の運行経路から予約管理サーバ１００が予測した日時である。

（Ｓ２５）画面制御部２２２は、予約結果６７に応じて画面５６をディスプレイ２０５に表示する。満席や予約期限経過などが原因で予約に失敗した場合、画面５６にはその旨が表示される。予約に成功した場合、画面５６には、予約された運行便の日付と時間帯、乗車場所、乗車時刻、降車場所および降車予定時刻が表示される。

図１６は、予約管理サーバの処理の手順例を示すフローチャートである。
（Ｓ３０）メッセージ通信部１２９は、予約要求６１または予約要求６６を受信する。
（Ｓ３１）運行予定更新部１２６は、予約要求６１が指定する希望日時に相当する運行便または予約要求６６が指定する運行便の出発時刻を確認する。出発時刻は、例えば、運行予定情報１３４から特定する。そして、運行予定更新部１２６は、現在日時がその運行便の予約期限以前であるか（例えば、出発時刻の３０分以上前など、出発時刻の所定時間以上前であるか）判断する。予約期限以前である場合、ステップＳ３２に処理が進む。予約期限を経過している場合、予約失敗と判定されてステップＳ３３に処理が進む。

（Ｓ３２）運行予定更新部１２６は、予約要求６１または予約要求６６に従って運行スケジュールを算出する。このとき、運行予定更新部１２６は、車両テーブル１３３に登録された座席数と運行予定情報１３４に登録されたユーザの乗降状況から、指定された乗車区間における空席数の最小値（最小空席数）を算出する。最小空席数が０の場合、満席のため予約失敗と判定される。最小空席数が１以上の場合、運行予定更新部１２６は、ノード挿入法などのアルゴリズムを用いて、予約要求６１または予約要求６６が指定する乗車場所と降車場所を経由する運行経路を算出し、運行予定情報１３４を更新する。

（Ｓ３３）メッセージ通信部１２９は、予約要求６１に対応する予約結果６２または予約要求６６に対応する予約結果６７を送信する。満席または予約期限経過のため予約失敗と判定された場合、予約結果６２または予約結果６７にはその旨の情報が含まれる。

（Ｓ３４）運行予定更新部１２６は、ステップＳ３２で予約が成功し、かつ、成功した予約が独立の予約であるか判断する。独立の予約は、他のユーザからの同乗提案に応じて要求された予約ではなく、予約要求６１に応じて実行された予約である。条件を満たす場合はステップＳ３５に処理が進み、条件を満たさない場合は予約処理が終了する。

（Ｓ３５）運行予定更新部１２６は、車両テーブル１３３に登録された座席数とステップＳ３２で更新した後の運行予定情報１３４に登録されたユーザの乗降状況から、予約要求６１が指定する乗車区間における最新の最小空席数を算出する。

（Ｓ３６）運行予定更新部１２６は、ステップＳ３５で算出した最小空席数が１以上であるか判断する。最小空席数が１以上である、すなわち、今回予約された座席以外に更に空席がある場合、ステップＳ３７に処理が進む。最小空席数が０である、すなわち、今回予約された座席以外の空席がない場合、ステップＳ３９に処理が進む。

（Ｓ３７）同乗候補者判定部１２７は、同乗集計テーブル１３７を参照して、予約要求６１を送信したユーザ（予約者）にとっての同乗候補者を判定する。これは、予約者の友人や知人を、各ユーザの乗車履歴から推定していると言うことができる。

例えば、第１の判定方法として、同乗候補者判定部１２７は、予約者との同乗回数が閾値以上である他のユーザを同乗集計テーブル１３７から抽出し、抽出した他のユーザを同乗候補者と判定する。また、例えば、第２の判定方法として、同乗候補者判定部１２７は、偶然に発生し得る回数を超えて予約者と同乗した他のユーザを、統計処理によって同乗集計テーブル１３７から抽出し、抽出した他のユーザを同乗候補者と判定する。ただし、同乗候補者判定部１２７は、予約者と対応付けて同乗集計テーブル１３７に登録された除外ユーザを確認し、除外ユーザは同乗候補者に含めないようにする。

上記の第２の判定方法では、例えば、同乗候補者判定部１２７は、任意の２人のユーザが偶然に同乗する回数が次のポアソン分布に従うと仮定する：ｐ（ｋ）＝λ^k×ｅ^-λ／ｋ！。このポアソン分布において、ｋはある２人のユーザの同乗回数、ｐはその同乗回数が生じる確率、λは全てのユーザの組み合わせについての平均同乗回数、ｅはネイピア数、！は階乗を表す。同乗候補者判定部１２７は、同乗集計テーブル１３７からλおよびｋを算出し、ｐが閾値以下（例えば、０．０１以下）になる他のユーザを、偶然でなく意図的に予約者と同乗している者と推定して同乗候補者と判定する。

なお、同乗候補者の判定に使用する同乗回数は、降車場所のカテゴリを考慮しない値であってもよい。その場合、同乗候補者判定部１２７は、同乗集計テーブル１３７に登録されたカテゴリ別の同乗回数を合計すればよい。また、同乗候補者の判定に使用する同乗回数は、降車場所のカテゴリを考慮した値であってもよい。その場合、同乗候補者判定部１２７は、場所テーブル１３２を参照して、予約者が今回指定した降車場所のカテゴリを特定し、そのカテゴリについての同乗回数を使用する。これにより、例えば、入浴施設に一緒に行く友人とショッピングセンタに一緒に行く友人とを区別して、今回予約された運行便に同乗する可能性の高い友人を同乗候補者と判定することができる。

また、同乗候補者判定部１２７は、ステップＳ３５で算出した最小空席数に応じて、同乗候補者を絞り込んでもよい。例えば、同乗候補者判定部１２７は、同乗候補者の数が最小空席数または最小空席数に所定値を加えた数になるように絞り込む。最小空席数を超える同乗候補者を抽出するのは、予約者が全ての同乗候補者を選択するとは限らず、また、選択された同乗候補者の全てが同乗を希望するとは限らないことを考慮したものである。同乗候補者を絞り込む場合、同乗候補者判定部１２７は、同乗集計テーブル１３７に登録された同乗回数が多い他のユーザを、優先的に同乗候補者と判定するようにしてもよい。また、同乗候補者判定部１２７は、同乗集計テーブル１３７に登録された選択回数が多い他のユーザを、優先的に同乗候補者と判定するようにしてもよい。

（Ｓ３８）メッセージ通信部１２９は、ステップＳ３７で判定された同乗候補者を列挙した選択要求６３を、予約者に対して送信する。そして、ステップＳ４０に処理が進む。
（Ｓ３９）メッセージ通信部１２９は、同乗候補者がないことを示す選択要求６３を、予約者に対して送信する。そして、予約処理が終了する。

（Ｓ４０）メッセージ通信部１２９は、選択要求６３に対応する選択通知６４を受信する。選択通知６４には、予約者によって選択された同乗候補者の情報が含まれる。選択された同乗候補者は、０人であることもあるし１人以上であることもある。

（Ｓ４１）同乗提案部１２８は、ステップＳ４０で受信した選択通知６４に基づいて、１人以上の同乗候補者が選択されたか判断する。選択された同乗候補者が１人以上である場合はステップＳ４２に処理が進み、０人である場合は予約処理が終了する。

（Ｓ４２）メッセージ通信部１２９は、予約者が選択した同乗候補者宛てに、同乗提案６５を送信する。同乗提案６５は、電子メールなど、同乗候補者が使用するユーザ端末からのアクセスを待たずに送信可能な通信方法を用いて送信してもよい。また、同乗提案６５は、同乗候補者が使用するユーザ端末からのアクセスを待って送信してもよい。なお、同乗提案部１２８は、ステップＳ３５で算出された最小空席数に応じて、同乗提案６５を送信する同乗候補者をこの段階で絞り込むようにしてもよい。

なお、上記の説明では、あるユーザからの予約の要求、他のユーザへの同乗の提案、他のユーザからの予約の要求を、ネットワーク３０上のメッセージ送信によって実現した。これに対し、あるユーザからの予約の要求、他のユーザへの同乗の提案、他のユーザからの予約の要求の一部または全部を、電話により口頭で行えるようにしてもよい。

例えば、オペレータを介した次のようなワークフローが考えられる。オペレータがあるユーザから電話で予約を受け付け、予約内容を予約管理サーバ１００に入力する。すると、予約管理サーバ１００は、同乗候補者を判定して同乗候補者の情報をディスプレイ１１１に表示する。オペレータは、表示された同乗候補者の情報に基づいて、同乗候補者に電話をかけて同じ運行便への乗車を提案する。同乗候補者が提案を受け入れると、オペレータが同乗候補者の予約内容を予約管理サーバ１００に入力する。

第２の実施の形態の情報処理システムによれば、オンデマンド型の公共交通システムにおいて、あるユーザが運行便を予約するとき、複数のユーザそれぞれの乗車履歴に基づいて、予約者と一緒に行動する頻度が高い他のユーザ（同乗候補者）が判定される。そして、判定された他のユーザに対して、同じ運行便の利用が提案される。

このように、ユーザ間の人間関係に着目して運行便の利用を提案することで、提案を受けた他のユーザの心理的障壁を低くし、当該他のユーザが予約者と同じ運行便に乗車する可能性を高くすることができる。また、予約者と同乗した複数の他のユーザが互いに知り合いではない場合であっても、予約者を介して複数の他のユーザの間で新たな交流が生まれる可能性がある。また、友人グループの中の１人が運行便を予約すれば、友人グループ内の他のユーザに自動的にその旨が通知されるため、何れの運行便を利用するかを事前に友人グループ内で調整しなくてもよく、予約手続が容易となる。

その結果、乗車人数または乗車率を向上させることができる。例えば、同乗の提案によって他のユーザの潜在的な需要を喚起する可能性があり、オンデマンド型の公共交通システムの総需要を増大させることができる。また、あるユーザと他のユーザとが別々の運行便を予約してしまう可能性を減らし、同一の運行便に乗車する可能性を高くすることができ、運行便の数を減らして公共交通システムの運営を効率化できる。

なお、前述のように、第１の実施の形態の情報処理は、コンピュータにプログラムを実行させることで実現できる。第２の実施の形態の情報処理は、予約管理サーバ１００やユーザ端末２００，２００ａ，２００ｂにプログラムを実行させることで実現できる。

プログラムは、コンピュータ読み取り可能な記録媒体（例えば、記録媒体１１３）に記録しておくことができる。記録媒体としては、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどを使用できる。磁気ディスクには、ＦＤおよびＨＤＤが含まれる。光ディスクには、ＣＤ、ＣＤ−Ｒ（Recordable）／ＲＷ（Rewritable）、ＤＶＤおよびＤＶＤ−Ｒ／ＲＷが含まれる。プログラムは、可搬型の記録媒体に記録されて配布されることがある。その場合、可搬型の記録媒体からＨＤＤなどの他の記録媒体（例えば、ＨＤＤ１０３）にプログラムをコピーして実行してもよい。

１０ 予約管理装置
１１ 記憶部
１２ 判定部
１３ 予約情報
１４ 履歴情報
１５ 他ユーザ情報
２１，２２，２３，２４ 車両便
Ｕ１，Ｕ２，Ｕ３ ユーザ

Claims (4)

1. コンピュータが実行する予約管理方法であって、
   複数のユーザのうち一のユーザが乗車を予約した未出発の第１の車両便を示す予約便情報と、前記一のユーザを示す予約ユーザ情報と、前記一のユーザの降車予定場所を示す降車予定場所情報とを含む予約情報を取得し、
   複数の場所それぞれのカテゴリを示す場所情報に基づいて、前記降車予定場所情報が示す降車予定場所のカテゴリを判定し、
   過去に運行した出発日時の異なる複数の第２の車両便それぞれを示す運行便情報に対して、前記複数のユーザのうち当該第２の車両便に乗車したユーザの情報と、前記複数の場所のうち当該ユーザの降車場所を示す降車場所情報とを対応付けた履歴情報に基づいて、前記複数のユーザのうち前記一のユーザと同じ運行便情報および同じ降車場所情報が対応付けられた他のユーザであって、前記同じ降車場所情報が示す降車場所のカテゴリが前記降車予定場所情報が示す降車予定場所のカテゴリと一致した回数が閾値以上であることを満たす１または２以上の他のユーザを判定し、
   前記予約情報と対応付けて、判定した前記１または２以上の他のユーザのうち少なくとも一部の他のユーザを示す他ユーザ情報を出力する、
   予約管理方法。
2. 前記他ユーザ情報の出力では、前記少なくとも一部の他のユーザに対応する宛先に対して、ネットワークを介して前記予約情報を送信する、
   請求項１記載の予約管理方法。
3. コンピュータに、
   複数のユーザのうち一のユーザが乗車を予約した未出発の第１の車両便を示す予約便情報と、前記一のユーザを示す予約ユーザ情報と、前記一のユーザの降車予定場所を示す降車予定場所情報とを含む予約情報を取得し、
   複数の場所それぞれのカテゴリを示す場所情報に基づいて、前記降車予定場所情報が示す降車予定場所のカテゴリを判定し、
   過去に運行した出発日時の異なる複数の第２の車両便それぞれを示す運行便情報に対して、前記複数のユーザのうち当該第２の車両便に乗車したユーザの情報と、前記複数の場所のうち当該ユーザの降車場所を示す降車場所情報とを対応付けた履歴情報に基づいて、前記複数のユーザのうち前記一のユーザと同じ運行便情報および同じ降車場所情報が対応付けられた他のユーザであって、前記同じ降車場所情報が示す降車場所のカテゴリが前記降車予定場所情報が示す降車予定場所のカテゴリと一致した回数が閾値以上であることを満たす１または２以上の他のユーザを判定し、
   前記予約情報と対応付けて、判定した前記１または２以上の他のユーザのうち少なくとも一部の他のユーザを示す他ユーザ情報を出力する、
   処理を実行させる予約管理プログラム。
4. 過去に運行した出発日時の異なる複数の車両便それぞれを示す運行便情報に対して、複数のユーザのうち当該車両便に乗車したユーザの情報と、複数の場所のうち当該ユーザの降車場所を示す降車場所情報とを対応付けた履歴情報を記憶する記憶部と、
   前記複数のユーザのうち一のユーザが乗車を予約した未出発の他の車両便を示す予約便情報と、前記一のユーザを示す予約ユーザ情報と、前記一のユーザの降車予定場所を示す降車予定場所情報とを含む予約情報を取得し、
   前記複数の場所それぞれのカテゴリを示す場所情報に基づいて、前記降車予定場所情報が示す降車予定場所のカテゴリを判定し、
   前記履歴情報に基づいて、前記複数のユーザのうち前記一のユーザと同じ運行便情報および同じ降車場所情報が対応付けられた他のユーザであって、前記同じ降車場所情報が示す降車場所のカテゴリが前記降車予定場所情報が示す降車予定場所のカテゴリと一致した回数が閾値以上であることを満たす１または２以上の他のユーザを判定し、
   前記予約情報と対応付けて、判定した前記１または２以上の他のユーザのうち少なくとも一部の他のユーザを示す他ユーザ情報を出力する判定部と、
   を有する予約管理装置。

Images