JP7056463B2 - 情報処理装置、情報処理システム、及び、情報処理方法 - Google Patents

Description

本発明は、情報処理装置、情報処理システム、及び、情報処理方法に関する。

近年、同一の車両に複数のユーザが相乗りする移動形態である、所謂ライドシェアの利用が広がっている。また、このようなライドシェアの利用のために、複数のユーザをマッチングするための技術が開発されている。

また、特許文献１には、各端末の所持者同士が同一の車両に相乗りしているか否かを判定するための技術が開示されている。

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

本発明は、所定の目的地へ移動する車両への便乗乗車による移動サービスにおいて、安易な予約のキャンセルを抑制可能にしつつ、予約のキャンセルによるキャンセルされた側の支障を低減可能にする情報処理装置、情報処理方法及びプログラムを提供することを目的とする。

本発明の態様の一つは、
所定の目的地へ移動する車両への便乗乗車による移動サービスの予約を管理することと、
第１の車両による前記移動サービスの第１の予約が成立している、前記第１の車両の運転ユーザ又は前記第１の車両へ乗車する予定の乗車ユーザのいずれかである第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信することと、
前記第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信した場合に、
前記第１のユーザの代わりとなる運転ユーザ又は乗車ユーザを決定することと、
前記第１のユーザにペナルティを付与することと、
を実行する制御部、
を備える情報処理装置である。

また、本発明の他の態様の一つは、
所定の目的地へ移動する車両への便乗乗車による移動サービスの予約を管理することと、
第１の車両による前記移動サービスの第１の予約が成立している、前記第１の車両の運転ユーザ又は前記第１の車両へ乗車する予定の乗車ユーザのいずれかである第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信することと、
前記第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信した場合に、
前記第１のユーザの代わりとなる運転ユーザ又は乗車ユーザを決定することと、
前記第１のユーザにペナルティを付与することと、
を実行する１又は複数の制御部、
を備える情報処理システムである。

また、本発明の他の態様の一つは、
所定の目的地へ移動する車両への便乗乗車による移動サービスの予約を管理し、
第１の車両による前記移動サービスの第１の予約が成立している、前記第１の車両の運転ユーザ又は前記第１の車両へ乗車する予定の乗車ユーザのいずれかである第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信し、
前記第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信した場合に、
前記第１のユーザの代わりとなる運転ユーザ又は乗車ユーザを決定し、
前記第１のユーザにペナルティを付与する、
情報処理方法である。

本発明によれば、所定の目的地へ移動する車両への便乗乗車による移動サービスにおいて、安易な予約のキャンセルを抑制しつつ、予約のキャンセルによるキャンセルされた側の支障を低減することができる。

図１は、第１実施形態に係るライドシェアサービス提供システムのシステム構成の一例を示す図である。 図２は、センタサーバのハードウェア構成の一例を示す図である。 図３は、センタサーバの機能構成の一例を示す図である。 図４は、ユーザ情報ＤＢのデータ構造の一例を示す図である。 図５は、乗車希望ユーザスケジュール情報ＤＢのデータ構造の一例を示す図である。 図６は、運転ユーザスケジュール情報ＤＢのデータ構造の一例を示す図である。 図７は、予約情報ＤＢのデータ構造の一例を示す図である。 図８は、ランク情報の一例を示す図である。 図９は、第１実施形態に係るセンタサーバの乗車予約処理のフローチャートの一例である。 図１０Ａは、第１実施形態に係るセンタサーバのキャンセル処理のフローチャートの一例を示す図である。 図１０Ｂは、第１実施形態に係るセンタサーバのキャンセル処理のフローチャートの一例を示す図である。

実施形態の一つは、所定の目的地へ移動する車両への便乗乗車による移動サービスの予約を管理することと、第１の車両による移動サービスの第１の予約が成立している、第１の車両の運転ユーザ又は第１の車両へ乗車する予定の乗車ユーザのいずれかである第１のユーザのユーザ端末から第１の予約のキャンセル要求を受信することと、第１のユーザのユーザ端末から第１の予約のキャンセル要求を受信した場合に、第１のユーザの代わりとなる運転ユーザ又は乗車ユーザを決定すること、及び、第１のユーザにペナルティを付与すること、を実行する制御部、を備える情報処理装置である。第１のユーザが運転ユーザである場合には、第１のユーザの代わりとなる運転ユーザが決定される。第１のユーザが乗車ユーザである場合には、第1のユーザの代わりとなる乗車ユーザが決定される。

第１のユーザに付与されるペナルティは、キャンセル料の請求、次回以降の移動サービスの利用料金の値下げ又は値上げ、移動サービスの予約の優先順位の低下のいずれかであ
ってもよい。次回以降の移動サービスの利用料金の値下げは、例えば、第１の予約をキャンセルする第１のユーザが運転ユーザである場合に適用されてもよい。これによって、当該運転ユーザに支払われる移動サービスの利用料金が値下げされる。

移動サービスの予約のキャンセルに対して、キャンセルされた側のユーザに、代わりとなる運転ユーザ又は乗車ユーザを決定することで、キャンセルされた側のユーザに与える影響を低減することができる。また、キャンセルする第１のユーザにペナルティが与えられることによって、移動サービスの予約が安易にキャンセルされることを抑制できる。

また、実施形態の一つでは、第１のユーザの代わりとなるユーザが手配できない場合には、第１の予約をキャンセルされた側のユーザにインセンティブを付与するようにしてもよい。これによって、第１の予約をキャンセルされた側のユーザの、当該移動サービスに対する利用意欲の低下を抑制することができる。

また、実施形態の一つでは、制御部は、第１の予約をキャンセルする第１のユーザが運転ユーザである場合に、第１のユーザの代わりの運転ユーザとして、第１の予約の第１の乗車ユーザを乗車させる第２の車両の運転ユーザを決定し、第１の乗車ユーザの第２の車両への乗車によって、第２の車両について定員超過が発生する場合に、第２の車両へ乗車する第２の予約が確定している第２の乗車ユーザのユーザ端末へ、第２の予約のキャンセル依頼と第２の予約をキャンセルした場合に第２の乗車ユーザへ付与されるインセンティブの情報とを送信することと、を実行するようにしてもよい。インセンティブは、移動サービスの予約の優先度の向上、ポイント又はクーポンの付与のいずれかであってよい。

これによって、第１の予約においてキャンセルされた側である第１の乗車ユーザに優先的に他の車両への乗車を手配することができる。また、第２の予約のキャンセル依頼とともにインセンティブの情報も送信されることによって、第２の予約をキャンセルしてくれる乗車ユーザを募りやすくすることができる。

以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。

＜第１実施形態＞
図１は、第１実施形態に係るライドシェアサービス提供システム１のシステム構成の一例を示す図である。ライドシェアサービスは、所定の目的地への移動が予定されている車両（又は当該車両の運転者）と、当該目的地と同じ方面に目的地を有するユーザとをマッチングして当該車両にユーザを便乗させて、車両による移動の共有を提供するサービスである。例えば、車両の運転者には所定の報酬が支払われる。当該車両に乗車したユーザからは、例えば、所定の料金が徴収される。車両の運転者に支払われる報酬は、例えば、金銭、所定のサービスに利用可能なポイント、クーポン等である。金銭は、例えば、現金、所定の銀行口座への振込、電子マネー等によって支払われる。ライドシェアサービスは、「所定の目的地へ移動する車両への便乗乗車による移動サービス」の一例である。

ライドシェアサービス提供システム１は、車両１０、車両１０の運転者である運転ユーザが保持するユーザ端末２００Ａ、車両１０に非運転ユーザとして便乗することを希望する乗車希望ユーザが有するユーザ端末２００Ｂ、センタサーバ１００を含む。ライドシェアサービス提供システム１には、車両１０、ユーザ端末２００Ａ、ユーザ端末２００Ｂがそれぞれ複数含まれているが、簡略化のため、図１では、それぞれ１台ずつ抽出して示されている。また、ユーザ端末２００Ａとユーザ端末２００Ｂとを区別しない場合には、単に、ユーザ端末２００と表記する。運転ユーザは、「運転ユーザ」の一例である。乗車希望ユーザは、「乗車ユーザ」の一例である。

各ユーザ端末２００およびセンタサーバ１００は、ネットワークＮ１に接続しており、ネットワークＮ１によって相互に接続される。ネットワークＮ１には、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）やその他の通信網が採用されてもよい。また、ネットワークＮ１は、携帯電話等の移動体通信網、ＷｉＦｉ等の無線通信網を含んでもよい。

運転ユーザ及び乗車希望ユーザは、例えば、ライドシェアサービス提供システム１が提供するアプリケーションをユーザ端末２００にインストールし、当該アプリケーションを通じて、自身を運転ユーザ又は乗車希望ユーザのいずれかとして登録しているユーザである。ユーザ端末２００は、例えば、スマートフォン、タブレット端末、ノート型ＰＣ（Personal Computer）、携帯電話端末等のモバイル端末である。

運転ユーザは、ユーザ端末２００Ａを通じて、センタサーバ１００に車両１０による移動予定のスケジュール情報を登録する。乗車希望ユーザは、ユーザ端末２００Ｂを通じて、センタサーバ１００へ、乗車予約要求を送信する。乗車予約要求とともに、車両１０による移動を希望するスケジュール情報も送信される。スケジュール情報には、例えば、出発地、目的地、出発予定時刻又は出発希望時刻（乗車ユーザの場合）、到着予定時刻又は到着希望時刻（乗車ユーザの場合）が含まれている。

センタサーバ１００は、乗車希望ユーザのユーザ端末２００Ｂから乗車予約要求を受信すると、当該乗車希望ユーザのスケジュール情報と、予め登録されている運転ユーザのスケジュール情報とを照らし合わせて、乗車希望ユーザを乗車させる運転ユーザを決定する。スケジュール情報に基づいて、乗車希望ユーザを乗車させる運転ユーザ（又は車両１０）を決定すること、又は、運転ユーザの車両１０に乗車させる乗車希望ユーザを決定することを、マッチングと称する。

センタサーバ１００は、例えば、マッチングされた該乗車希望ユーザと運転ユーザとのスケジュール情報に基づいて、両者の合流予定地点、合流予定時刻を決定する。センタサーバ１００は、マッチングされた運転ユーザのユーザ端末２００Ａに乗車予約要求を送信し、マッチングされた運転ユーザに確認を行う。運転ユーザのユーザ端末２００Ａには、乗車予約要求とともに、乗車予約の識別情報、乗車予約の内容も送信される。乗車予約の内容には、例えば、乗車希望ユーザに関する情報、合流予定地点、合流予定時刻、乗車希望ユーザの目的地及び当該目的地への到着予定時刻が含まれる。乗車希望ユーザに関する情報には、例えば、乗車希望ユーザのユーザ名、性別、年代、連絡先（電話番号、電子メールアドレス）等が含まれる。

センタサーバ１００が運転ユーザのユーザ端末２００Ａから乗車予約要求に対するＯＫ応答を受信すると、乗車予約が確定する。乗車予約が確定すると、センタサーバ１００は、乗車予約要求の送信元の乗車希望ユーザのユーザ端末２００Ｂへ、乗車予約確定の通知を送信する。乗車希望ユーザのユーザ端末２００Ｂへは、乗車予約確定の通知とともに、乗車予約の識別情報、乗車予約の内容も送信される。乗車予約の内容には、例えば、運転ユーザに関する情報、合流予定地点、合流予定時刻、乗車希望ユーザの目的地及び当該目的地への到着予定時刻が含まれる。運転ユーザに関する情報には、例えば、運転ユーザのユーザ名、性別、年代、連絡先（電話番号、電子メールアドレス）、車両１０に関する情報が含まれる。車両１０に関する情報は、例えば、車両１０の画像であってもよいし、車両１０の車種、色、車両識別番号等の車両１０の外観に関する情報である。

ここで、乗車予約確定から当該乗車予約のサービスが開始されるまでの間に、例えば、運転ユーザ又は乗車希望ユーザの体調が悪くなったり、急な予定が入ったりして、運転ユ
ーザ又は乗車希望ユーザによって乗車予約がキャンセルされる場合がある。例えば、乗車予約がキャンセルされると、キャンセルされた側のユーザの予定も変更されることになり、支障をきたす場合がある。特に、乗車予約の合流予定時刻の直前にキャンセルが発生した場合には、顕著である。

そこで、第１実施形態では、センタサーバ１００は、乗車予約のキャンセルが発生した場合に、キャンセルされた側の運転ユーザ又は乗車希望ユーザについて、代替の乗車希望ユーザ又は運転ユーザを手配するために、新たにマッチングを行う。これによって、キャンセルされた側のユーザが運転ユーザである場合には、キャンセルされた乗車予約によって得られたはずの報酬を補てんすることができる。また、キャンセルされた側のユーザが乗車希望ユーザである場合には、キャンセルされた乗車予約による目的地までの移動を補てんすることができる。すなわち、キャンセルされた側のユーザにおいて発生する不利益を補てんすることができる。

また、第１実施形態では、センタサーバ１００は、乗車予約のキャンセルが発生した場合に、キャンセルした側のユーザに対してペナルティを課す。キャンセルした側のユーザに対するペナルティは、例えば、キャンセル料の支払い、保有ポイントの徴収、乗車予約の優先順位を低くする、次回以降のライドシェアサービスにおける料金を値下げ（運転ユーザの場合）又は値上げ（乗車起動ユーザの場合）する等である。乗車予約の優先順位は、例えば、ライドシェアサービスの利用回数に応じて決定される会員ランク等である。これによって、乗車予約が安易にキャンセルされることを抑制することができる。

図２は、センタサーバ１００のハードウェア構成の一例を示す図である。センタサーバ１００は、例えば、専用のコンピュータ、汎用のコンピュータである。センタサーバ１００は、ハードウェア構成として、プロセッサ１０１、主記憶部１０２、補助記憶部１０３、通信部１０４を有する。これらは、互いにバスによって接続される。主記憶部１０２および補助記憶部１０３は、コンピュータで読み取り可能な記録媒体である。センタサーバ１００は、「情報処理装置」の一例である。

補助記憶部１０３は、様々なプログラムや、各プログラムの実行に際してプロセッサ１０１が使用するデータを格納する。補助記憶部１０３は、例えば、ＥＰＲＯＭ（Erasable
Programmable ROM）やハードディスクドライブ（Hard Disc Drive）である。補助記憶部１０３に保持されるプログラムには、例えば、オペレーティングシステム（ＯＳ）、ライドシェアサービス制御プログラム、その他様々なアプリケーションプログラムを保持する。ライドシェア制御プログラムは、ライドシェアサービスの乗車予約の管理、ユーザ管理等のためのプログラムである。

主記憶部１０２は、プロセッサ１０１に、補助記憶部１０３に格納されているプログラムをロードする記憶領域および作業領域を提供したり、バッファとして用いられたりする記憶装置である。主記憶部１０２は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）のような半導体メモリを含む。

プロセッサ１０１は、例えば、ＣＰＵ（Central Processing Unit）である。プロセッ
サ１０１は、補助記憶部１０３に保持されたＯＳや様々なアプリケーションプログラムを主記憶部１０２にロードして実行することによって、様々な処理を実行する。プロセッサ１０１は、１つに限られず、複数備えられてもよい。プロセッサ１０１は、「制御部」の一例である。

通信部１０４は、ネットワークとの情報の入出力を行うインタフェースである。通信部１０４は、有線のネットワークと接続するインタフェースであってもよいし、無線のネッ
トワークと接続するインタフェースであってもよい。通信部１０４は、例えば、ＮＩＣ（Network Interface Card）や無線回路等である。

なお、図２に示されるセンタサーバ１００のハードウェア構成は、一例であり、上記に限られず、実施の形態に応じて適宜構成要素の省略や置換、追加が可能である。例えば、センタサーバ１００は、可搬記録媒体駆動装置を備え、可搬記録媒体に記録されたプログラムを実行してもよい。可搬記録媒体は、例えば、ＳＤカード、ｍｉｎｉＳＤカード、ｍｉｃｒｏＳＤカード、ＵＳＢ（Universal Serial Bus）フラッシュメモリ、ＣＤ（Compact Disc）、ＤＶＤ(Digital Versatile Disc)、Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ、又はフラッシュメモリカードのような記録媒体である。また、例えば、センタサーバ１００は、入力装置及び出力装置を備えてもよい。入力装置は、例えば、キーボード、マウス、タッチパネル等である。出力装置は、例えば、ディスプレイ等である。

なお、センタサーバ１００で実行される一連の処理は、プロセッサ１０１によるソフトウェアの実行によって達成させることに限定されず、例えば、ＦＰＧＡ（Field-Programmable Gate Array）等のハードウェアによって達成させることもできる。

ユーザ端末２００のハードウェア構成の図示は省略される。ユーザ端末２００は、上述のプロセッサ、主記憶部、補助記憶部、通信部に加えて、例えば、表示部、入力部等を有する。表示部は、例えば、ＬＣＤ（Liquid Crystal Display）、ＥＬ（Electroluminescence）パネル等である。入力部は、タッチパネル、押しボタン等を含む。また、入力部は
、映像や画像の入力を可能にするカメラや、マイクロフォンのような音声の入力部を含むことができる。通信部は、例えば、携帯電話等の移動体通信網、ＷｉＦｉ等の無線通信を利用してネットワークＮ１にアクセスするための通信回路である。ユーザ端末２００は、ユーザからの入力部を通じたアプリケーションへの操作入力によって、センタサーバ１００へ、乗車予約要求、スケジュール情報、ユーザ情報等を送信する。

図３は、センタサーバ１００の機能構成の一例を示す図である。センタサーバ１００は、機能構成要素として、予約処理部１１、マッチング処理部１２、端末通信部１３、ユーザ情報データベース（ＤＢ）１４、乗車希望ユーザスケジュール情報ＤＢ １５、運転ユーザスケジュール情報ＤＢ １６、予約情報ＤＢ １７、ランク情報ＤＢ １８、マッチング優先リスト１９を備える。これらの機能構成要素は、例えば、センタサーバ１００のプロセッサ１０１が補助記憶部１０３に格納されているライドシェアサービス制御プログラムを実行することによって達成される。

端末通信部１３は、ユーザ端末２００とのインタフェースである。端末通信部１３は、通信部１０４を通じて、ユーザ端末２００とのデータの送受信を行う。端末通信部１３がユーザ端末２００から受信するデータの一例には、乗車予約要求、乗車予約のキャンセル要求がある。端末通信部１３は、ユーザ端末２００から受信されたデータを予約処理部１１へ出力する。

予約処理部１１は、乗車予約に関する制御を行う。予約処理部１１の詳細な処理は、例えば、以下の通りである。予約処理部１１は、端末通信部１３を通じて、ユーザ端末２００からユーザ情報を受信した場合には、受信したユーザ情報を後述のユーザ情報ＤＢ １４に格納する。予約処理部１１は、端末通信部１３を通じて、運転ユーザのユーザ端末２００Ａからスケジュール情報を受信した場合には、当該スケジュール情報を後述の運転ユーザスケジュール情報ＤＢ １６に格納する。

予約処理部１１は、端末通信部１３を通じて、乗車希望ユーザのユーザ端末２００Ｂから乗車予約要求を受信した場合には、マッチング処理部１２に、マッチングを依頼する。
また、乗車希望ユーザのユーザ端末２００Ｂからは乗車予約要求とともに、当該乗車希望ユーザのスケジュール情報も受信される。乗車希望ユーザのスケジュール情報は、予約処理部１１によって、乗車希望ユーザスケジュール情報ＤＢ １５に格納される。

予約処理部１１は、マッチング処理部１２から、例えば、ユーザ端末２００Ｂの乗車希望ユーザについてマッチングされた運転ユーザの情報と、合流予定地点及び合流予定時刻の入力を受ける。予約処理部１１は、マッチングされた運転ユーザのユーザ端末２００Ａへ、端末通信部１３を通じて、乗車予約要求を送信する。乗車予約要求とともに、乗車予約の識別情報、乗車予約の内容も送信される。

予約処理部１１は、端末通信部１３を通じて、運転ユーザのユーザ端末２００Ａから乗車予約要求に対するＯＫ応答を受信した場合には、当該乗車予約の確定を判定し、乗車予約情報を予約情報ＤＢ １７に登録する。また、予約処理部１１は、端末通信部１３を通じて、乗車予約要求の送信元のユーザ端末２００Ｂへ、乗車予約確定の通知を送信する。乗車予約要求の送信元のユーザ端末２００Ｂへは、乗車予約確定の通知とともに、例えば、乗車予約の識別情報、乗車予約の内容も送信される。

予約処理部１１は、例えば、ユーザ端末２００から乗車予約のキャンセル要求を受信した場合には、対応する乗車予約のキャンセル処理を行う。乗車予約のキャンセル要求とともに、キャンセル対象となる乗車予約の識別番号も受信される。乗車予約のキャンセル処理として、予約処理部１１は、例えば、予約情報ＤＢ １７から該当する乗車予約の情報を削除し、当該乗車予約のキャンセルした側のユーザとキャンセルされた側のユーザのユーザ端末２００へ乗車予約のキャンセル通知を送信する。例えば、運転ユーザのユーザ端末２００Ａから乗車予約のキャンセル要求が受信された場合には、対象の乗車予約の乗車希望ユーザのユーザ端末２００Ｂと当該運転ユーザのユーザ端末２００Ｂとへ乗車予約のキャンセル通知が送信される。乗車希望ユーザは、キャンセルされたスケジュール情報について依然としてライドシェアサービスを利用したい場合には、例えば、再度ユーザ端末２００Ｂから乗車予約要求をセンタサーバ１００へ送信してもよい。

ただし、乗車予約のキャンセル要求を受信した際に、例えば、キャンセル対象の乗車予約の合流予定時刻から所定時間前の時刻が経過している場合には、キャンセルされた側の予定に与える影響が大きくなるため、予約処理部１１は、以下の処理を行う。乗車予約の合流予定時刻から所定時間前は、例えば、１日前、１時間前、等であり、ライドシェアサービス提供システム１の管理者によって任意に設定可能である。また、運転ユーザからのキャンセル要求の対象が複数の乗車希望ユーザの乗車予定である場合には、例えば、キャンセル要求の対象の複数の乗車予約のうち一番早い合流予定時刻を基準とする。

予約処理部１１は、キャンセル対象の乗車予約のキャンセルされた側である運転ユーザ又は乗車希望ユーザについて、代替の乗車希望ユーザ又は運転ユーザを手配するために、新たにマッチングをマッチング処理部１２に依頼する。例えば、運転ユーザから乗車予約のキャンセル要求があり、キャンセルされた側である乗車希望ユーザについてのマッチングによって、代替となる運転ユーザが手配できない場合には、当該乗車希望ユーザに、インセンティブが付与されてもよい。例えば、当該乗車希望ユーザに付与されるインセンティブは、乗車予約の優先権、会員ランクの昇格、ポイント又はクーポンの付与等であってもよい。

また、例えば、乗車希望ユーザからキャンセル要求があり、キャンセルされた側である運転ユーザについてのマッチングによって、代替となる乗車希望ユーザが見つからない場合には、予約処理部１１は、当該運転ユーザについて、マッチング優先リスト１９に登録する。

マッチング優先リスト１９は、例えば、センタサーバ１００の補助記憶部１０３に保持される。マッチング優先リスト１９には、乗車予約がキャンセルされた運転ユーザの識別情報と、キャンセルされた乗車予約のスケジュール情報が登録される。マッチング優先リストに登録されるスケジュール情報には、キャンセルされた乗車予約の合流予定地点、合流予定時刻、目的地、到着予定時刻が、それぞれ、出発地、出発予定時刻、目的地、到着予定時刻として含まれている。

予約処理部１１は、乗車希望ユーザのユーザ端末２００Ｂから乗車予約要求を受信し、当該乗車予約とともに受信されるスケジュール情報がマッチング優先リスト１９に登録されているスケジュール情報と類似する場合には、マッチング処理部１２にマッチングを依頼せずに、マッチング優先リスト１９に登録されている運転ユーザと、乗車予約要求の乗車希望ユーザとをマッチングさせる。これによって、乗車予約がキャンセルされた運転ユーザに、代替の乗車希望ユーザを割り当てる。

なお、当該乗車予約とともに受信されるスケジュール情報がマッチング優先リスト１９に登録されているスケジュール情報と類似するとは、両者の出発地及び到着地が所定の地理的範囲内に存在しており、出発予定時刻及び到着予定時刻が所定の時間的範囲内に存在していることをいう。マッチング優先リスト１９に運転ユーザが登録されることは、乗車予約をキャンセルされた運転ユーザにインセンティブを付与することの一例である。なお、乗車希望ユーザからキャンセル要求があり、キャンセルされた側である運転ユーザについてのマッチングによって、代替となる乗車希望ユーザが見つからない場合に当該運転ユーザに付与されるインセンティブはこれに限定されない。例えば、当該運転ユーザに付与されるインセンティブは、会員ランクの昇格、ポイント又はクーポンの付与等であってもよい。

一方、例えば、運転ユーザからキャンセル要求があった場合には、予約処理部１１は、キャンセル対象の乗車予約の乗車希望ユーザについての新たなマッチングをマッチング処理部１２に依頼する。マッチング処理部１２のマッチングの結果、当該乗車希望ユーザのマッチングされた車両１０の定員の超過が発生する場合には、予約処理部１１は、当該車両１０への乗車予約をキャンセルしてくれる乗車希望ユーザを募るため、当該車両１０への乗車予約がある乗車希望ユーザのユーザ端末へ、乗車予約のキャンセル依頼を送信する。乗車予約のキャンセル依頼とともに、対象の乗車予約の識別情報と、乗車予約をキャンセルした場合に当該乗車希望ユーザに付与されるインセンティブに関する情報と、が送信される。

乗車予約のキャンセル依頼に対して当該乗車予約をキャンセルした場合に乗車希望ユーザに付与されるインセンティブには、例えば、ライドシェアサービスを含む所定のサービスに使用可能なポイント、次回以降に使用可能なクーポン、会員ランクの昇格等がある。会員ランクの昇格は、移動サービスの予約の優先度の向上の一例である。

また、乗車予約のキャンセル要求が受信された際に、キャンセル対象の乗車予約の合流予定時刻から所定時間前の時刻が経過している場合には、予約処理部１１は、乗車予約のキャンセル要求の送信元の運転ユーザ又は乗車希望ユーザに、ペナルティを課す。乗車予約をキャンセルしたユーザに課されるペナルティには、例えば、罰金の徴収、当該ユーザが保有するポイントの徴収、会員ランクの降下、次回以降のライドシェアサービスの利用料金の値上げ（乗車ユーザの場合）又は値下げ（運転ユーザの場合）、運転ユーザの場合にはマッチング優先リスト１９からの削除等がある。

マッチング処理部１２は、予約処理部１１からの依頼に応じて、乗車予約要求の送信元
のユーザ端末２００Ｂに対応する乗車希望ユーザと運転ユーザとのマッチングを行う。マッチング処理部１２のマッチング方法は、周知の技術のいずれであってもよく、特定の方法に限定されない。例えば、マッチング処理部１２は、後述の運転ユーザスケジュール情報ＤＢ １６の中から、乗車予約要求とともに受信された乗車希望ユーザのスケジュール情報の出発希望時刻から到着予定時刻までの期間を含み、目的地又は経由地とその付近に乗車希望ユーザの出発地及び目的地を含む運転ユーザのスケジュール情報を抽出する。マッチング処理部１２は、抽出されたスケジュール情報の運転ユーザの中から、例えば、ランダムに、又は、評価値、属性等に基づいて、乗車希望ユーザのマッチング相手を選択する。

また、マッチング処理部１２は、例えば、乗車希望ユーザの出発地及び目的地、運転ユーザの目的地及び経由地に基づいて、合流予定地点を決定する。また、マッチング処理部１２は、乗車希望ユーザの出発希望時刻及び到着希望時刻と運転ユーザの他の乗車予約とに基づいて、合流予定時刻を決定する。合流予定地点、合流予定時刻の決定方法は、周知の技術のいずれであってもよく、特定の方法に限定されない。マッチング処理部１２は、選択した運転ユーザの情報、合流予定地点、合流予定時刻等を予約処理部１１に出力する。

なお、予約処理部１１、マッチング処理部１２、端末通信部１３の処理は、別々のコンピュータで実行されてもよい。

ユーザ情報ＤＢ １４、乗車希望ユーザスケジュール情報ＤＢ １５、運転ユーザスケジュール情報ＤＢ １６、予約情報ＤＢ １７、ランク情報ＤＢ １８は、それぞれ、例えば、プロセッサ１０１によって実行されるデータベース管理システム（Database Management System、ＤＢＭＳ）のプログラムが、補助記憶部１０３に記憶されるデータを管理することで構築される。ユーザ情報ＤＢ １４、乗車希望ユーザスケジュール情報ＤＢ １５、運転ユーザスケジュール情報ＤＢ １６、予約情報ＤＢ １７、ランク情報ＤＢ １８は、例えば、リレーショナルデータベースである。

図４は、ユーザ情報ＤＢ １４のデータ構造の一例を示す図である。ユーザ情報ＤＢ １４には、ユーザに関する情報が格納されている。ユーザ情報ＤＢ １４に格納されているユーザに関する情報には、例えば、ユーザＩＤ、ユーザ種別、ユーザの属性情報、ユーザの連絡先の情報、ユーザが運転ユーザである場合には車両ＩＤ、車両の外観情報、車両の店員等が含まれている。図４では、ユーザ情報ＤＢ １４に格納されるユーザに関する情報のうち、一部が抽出されて示されている。

図４では、ユーザ情報ＤＢ １４に格納されるユーザに関する情報のうち、ユーザＩＤ、ユーザ種別、年間利用実績、年間キャンセル回数、ランクのフィールドが示されている。ユーザ種別のフィールドには、運転ユーザ又は乗車希望ユーザのいずれであるかを示す情報が入力される。年間利用実績のフィールドには、ライドシェアサービスの直近の一年間の利用回数が格納される。乗車希望ユーザの場合には、利用回数は、ライドシェアサービスに登録される車両１０による移動の回数である。運転ユーザの場合には、利用回数は、車両１０によって移動させた乗車希望ユーザののべ人数である。

年間キャンセル実績のフィールドには、直近の一年間で、合流予定時刻の所定時間前の時刻の経過後にキャンセルした回数又は乗車予約の数が入力される。ランクのフィールドには、ユーザの会員ランクが入力される。会員ランクの詳細については後述される。

ユーザ情報ＤＢ １４の各フィールドの値は、例えば、予約処理部１１によって登録、更新、削除等がなされる。なお、ユーザ情報ＤＢ １４のデータ構造は、図４に示される
ものに限定されない。

図５は、乗車希望ユーザスケジュール情報ＤＢ １５のデータ構造の一例を示す図である。乗車希望ユーザスケジュール情報ＤＢ １５は、乗車希望ユーザのスケジュール情報を格納するデータベースである。図５に示される乗車希望ユーザスケジュール情報ＤＢ １５は、ユーザＩＤ、出発地、出発希望時刻、目的地、到着希望時刻のフィールドを有する。

ユーザＩＤのフィールドには、乗車希望ユーザのユーザ識別情報が入力される。出発地及び目的地のフィールドには、出発地又は目的地の住所、緯度及び経度等のいずれかが入力される。出発希望時刻及び到着希望時刻のフィールドには、それぞれ、年月日時分が入力される。

乗車希望ユーザスケジュール情報ＤＢ １５に格納される情報は、予約処理部１１によって登録、更新、削除がなされる。例えば、乗車希望ユーザのユーザ端末２００Ｂから乗車予約要求とともにスケジュール情報が受信されると、当該スケジュール情報が予約処理部１１によって乗車希望ユーザスケジュール情報ＤＢ １５の新たなエントリとして登録される。また、該当する乗車予約が終了した場合には、乗車希望ユーザスケジュール情報ＤＢ １５から該当するエントリが削除されるようにしてもよい。なお、乗車希望スケジュール情報ＤＢ １５に格納される情報は、図５に示される例に限られず、適宜フィールドの追加、変更、削除が可能である。

図６は、運転ユーザスケジュール情報ＤＢ １６のデータ構造の一例を示す図である。運転ユーザスケジュール情報ＤＢ １６は、運転ユーザのスケジュール情報を格納するデータベースである。図６に示される運転ユーザスケジュール情報ＤＢ １６は、ユーザＩＤ、出発地、車両ＩＤ、出発予定時刻、目的地、到着予定時刻のフィールドを有する。

ユーザＩＤのフィールドには、運転ユーザのユーザ識別情報が入力される。車両ＩＤのフィールドには、車両１０の識別情報が入力される。出発地及び目的地のフィールドには、出発地又は目的地の住所、緯度及び経度等のいずれかが入力される。出発予定時刻及び到着予定時刻のフィールドには、それぞれ、年月日時分が入力される。なお、車両１０に関する情報は、他のデータベースに格納されている。車両１０に関する情報には、例えば、車両の識別情報、運転ユーザの識別情報、車種、色、定員等である。

運転ユーザスケジュール情報ＤＢ １６に格納される情報は、予約処理部１１によって登録、更新、削除がなされる。例えば、運転ユーザのユーザ端末２００Ａからスケジュール情報が受信されると、当該スケジュール情報が予約処理部１１によって運転ユーザスケジュール情報ＤＢ １６の新たなエントリとして登録される。また、スケジュール情報の到着予定時刻から所定時間経過すると、当該エントリが運転ユーザスケジュール情報ＤＢ
１６から削除されるようにしてもよい。なお、運転スケジュール情報ＤＢ １６に格納される情報は、図６に示される例に限られず、適宜フィールドの追加、変更、削除が可能である。

図７は、予約情報ＤＢ １７のデータ構造の一例を示す図である。予約情報ＤＢ １７は、乗車予約に関する情報を保持するデータベースである。

図７に示される予約情報ＤＢ １７は、乗車予約ＩＤ、運転ユーザＩＤ、乗車希望者ＩＤ、合流予定地点、合流予定時刻、乗車希望ユーザの目的地、到着予定時刻を有する。乗車予約ＩＤのフィールドには、乗車予約の識別情報が入力される。乗車予約の識別情報は、例えば、ユーザ端末２００Ｂから乗車予約要求が受信されると、予約処理部１１によっ
て付与される。運転ユーザＩＤのフィールドには、運転者ユーザの識別情報が入力される。乗車希望ユーザＩＤのフィールドには、乗車希望ユーザの識別情報が入力される。

合流予定地点のフィールドには、マッチング処理部１２によって決定された合流予定地点の情報が入力される。合流予定地点フィールドには、例えば、合流予定地点の情報として、経度及び緯度、住所、ランドマークの名称等のいずれが入力されてもよい。合流予定時刻のフィールドには、マッチング処理部１２によって決定された合流予定時刻が入力される。

乗車希望ユーザの目的地及び到着予定時刻のフィールドに格納される情報は、例えば、乗車希望ユーザのスケジュール情報に基づいて入力される。

予約情報ＤＢ １７に格納される情報は、予約処理部１１によって、登録、更新、削除が行われる。例えば、乗車予約が確定すると、予約処理部１１によって新たなエントリが予約情報ＤＢ １７に登録される。また、ユーザ端末２００からキャンセル要求が受信されると、予約処理部１１によって、キャンセル対象のエントリが予約情報ＤＢ １７から削除される。なお、予約情報ＤＢ １７に格納される情報は、図７に示される例に限られず、適宜フィールドの追加、変更、削除が可能である。

図８は、ランク情報の一例を示す図である。ランク情報は、会員ランクの定義を格納しており、ランク情報ＤＢ １８に格納されている。第１実施形態では、５段階のユーザランクが用いられ、Ｃ＜Ｂ＜Ａ＜Ｓ´＜Ｓの順にランクが高くなる。各ランクには付与の条件が設けられている。

図８に示される例では、年間利用実績が１０回未満でランクＣが付与される。年間利用実績が１０回以上５０回未満でランクＢが付与される。年間利用実績が５０回以上１００回未満でランクＡが付与される。初回利用者にはランクＳ′が付与される。年間利用実績が１００回以上でランクＳが付与される。

ランクが高ければ高いほど、マッチングにおいて優待される。例えば、ランクＡの乗車希望ユーザ＃１とランクＳの乗車希望ユーザ＃２とから、ほぼ同じスケジュール情報の乗車予約要求が受信された場合には、ランクＳの乗車希望ユーザ＃２から優先的にマッチングされたり、より優良な運転ユーザとマッチングされたりしてもよい。また、会員ランクが高いほど、割り当てられる車両１０の車種高級になるようにしてもよい。また、会員ランクが高いほど、乗車希望ユーザとして支払う料金が安くなるようにしてもよい。運転ユーザの場合には、会員ランクが高いほど、より多くの乗車希望ユーザをマッチングしてもらえるようにしてもよい。

また、会員ランクは、年間キャンセル実績に応じても変更されるようにしてもよい。例えば、年間キャンセル実績の回数が１０回以上になると、会員ランクが一つ降格される等である。また、年間キャンセル実績に応じても会員ランクが降格することを乗車予約のキャンセル時のペナルティとしてもよい。

＜処理の流れ＞
図９は、第１実施形態に係るセンタサーバ１００の乗車予約処理のフローチャートの一例である。図９に示される処理は、例えば、所定の周期で繰り返し実行される。図９に示される処理の実行主体は、センタサーバ１００のプロセッサ１０１であるが、便宜上、機能構成要素である予約処理部１１を主体として説明する。以降のセンタサーバ１００の処理のフローチャートについても同様である。

ＯＰ１０１では、予約処理部１１は、端末通信部１３を通じて、乗車希望ユーザのユーザ端末２００Ｂから乗車予約要求を受信したか否かを判定する。乗車希望ユーザのユーザ端末２００Ｂから乗車予約要求が受信された場合には（ＯＰ１０１：ＹＥＳ）、処理がＯＰ１０２に進む。乗車予約要求が受信されていない場合には（ＯＰ１０１：ＮＯ）、図９に示される処理が終了する。

ＯＰ１０２では、予約処理部１１は、乗車予約要求とともに受信された乗車希望ユーザのスケジュール情報と、マッチング優先リスト１９内のスケジュール情報とを比較する。ＯＰ１０３では、予約処理部１１は、当該乗車希望ユーザのスケジュール情報と類似するスケジュール情報がマッチング優先リスト１９にあるか否かを判定する。

当該乗車希望ユーザのスケジュール情報と類似するスケジュール情報がマッチング優先リスト１９にある場合には（ＯＰ１０３：ＹＥＳ）、予約処理部１１は、マッチング優先リスト１９において当該スケジュール情報に対応付けられている運転ユーザと乗車予約要求の乗車希望ユーザとをマッチングする。当該乗車希望ユーザのスケジュール情報と類似するスケジュール情報がマッチング優先リスト１９に複数ある場合には、例えば、マッチング優先リスト１９の上位に連ねられているスケジュール情報に対応付けられている運転ユーザがマッチングされる。マッチングされた運転ユーザの情報は、マッチング優先リスト１９から削除される。その後、処理がＯＰ１０５に進む。

当該乗車希望ユーザのスケジュール情報と類似するスケジュール情報がマッチング優先リスト１９にない場合には（ＯＰ１０３：ＮＯ）、処理がＯＰ１０４に進む。ＯＰ１０４では、予約処理部１１は、マッチング処理部１２に、乗車予約要求の乗車希望ユーザのマッチングを依頼し、マッチング処理部１２によって、マッチング相手の運転ユーザ、合流予定地点、合流予定時刻等が決定される。

ＯＰ１０５では、予約処理部１１は、端末通信部１３を通じて、マッチングされた運転ユーザのユーザ端末２００Ａに乗車予約要求を送信する。ＯＰ１０６では、予約処理部１１は、運転ユーザのユーザ端末２００Ａから乗車予約要求に対するＯＫ応答を受信したか否かを判定する。運転ユーザのユーザ端末２００Ａから乗車予約要求に対するＯＫ応答を受信した場合には（ＯＰ１０６：ＹＥＳ）、処理がＯＰ１０７に進む。例えば、所定時間経過しても、運転ユーザのユーザ端末２００Ａから乗車予約要求に対するＯＫ応答が受信されない場合やＮＧ応答が受信された場合には（ＯＰ１０６：ＮＯ）、処理がＯＰ１０２に進み、再度マッチング優先リスト１９との比較から処理が行われる。

ＯＰ１０７では、予約処理部１１は、端末通信部１３を通じて、乗車予約要求の送信元の乗車希望ユーザのユーザ端末２００Ｂへ乗車予約確定の通知を送信する。また、予約処理部１１は、乗車予約情報を予約情報ＤＢ １７に格納する。その後、図９に示される処理が終了する。なお、乗車予約要求を受信した場合の処理は、図９に示される処理に限定されない。

図１０Ａ及び図１０Ｂは、第１実施形態に係るセンタサーバ１００のキャンセル処理のフローチャートの一例を示す図である。キャンセル処理は、ユーザ端末２００から乗車予約のキャンセル要求が受信された場合の処理である。図１０Ａ及び図１０Ｂに示される処理は、例えば、所定の周期で繰り返し実行される。

ＯＰ２０１では、予約処理部１１は、端末通信部１３を通じて、乗車希望ユーザのユーザ端末２００Ｂから乗車予約のキャンセル要求を受信したか否かを判定する。乗車希望ユーザのユーザ端末２００Ｂから乗車予約のキャンセル要求が受信された場合には（ＯＰ２０１：ＹＥＳ）、処理がＯＰ２０３に進む。乗車希望ユーザのユーザ端末２００Ｂから乗
車予約のキャンセル要求が受信されていない場合には（ＯＰ２０１：ＮＯ）、処理がＯＰ２０２に進む。

ＯＰ２０２では、予約処理部１１は、端末通信部１３を通じて、運転ユーザのユーザ端末２００Ａから乗車予約のキャンセル要求を受信したか否かを判定する。運転ユーザのユーザ端末２００Ａから乗車予約のキャンセル要求が受信された場合には（ＯＰ２０２：ＹＥＳ）、処理が図１０ＢのＯＰ３０１に進む。運転ユーザのユーザ端末２００Ａから乗車予約のキャンセル要求が受信されていない場合には（ＯＰ２０２：ＮＯ）、図１０Ａに示される処理が終了する。

ＯＰ２０３からＯＰ２１１の処理は、乗車希望ユーザのユーザ端末２００Ｂから乗車予約のキャンセル要求が受信された場合の処理である。ＯＰ２０３では、予約処理部１１は、キャンセル要求の対象の乗車予約の合流予定時刻から所定時間前であるか否かを判定する。対象の乗車予約の合流予定時刻から所定時間前である場合には（ＯＰ２０３：ＹＥＳ）、処理がＯＰ２１０に進む。対象の乗車予約の合流予定時刻から所定時間前の時刻が経過している場合には（ＯＰ２０３：ＮＯ）、処理がＯＰ２０４に進む。

ＯＰ２０４からＯＰ２０９の処理は、キャンセル要求の対象の乗車予約の合流予定時刻から所定時間前の時刻が経過している場合に行われる処理である。ＯＰ２０４では、予約処理部１１は、対象の乗車予約のキャンセル処理を実行する。具体的には、予約処理部１１は、対象の乗車予約の情報を予約情報ＤＢ １７から削除し、当該乗車希望ユーザのスケジュール情報を乗車希望ユーザスケジュール情報ＤＢ １５から削除する。また、予約処理部１１は、端末通信部１３を通じて、対象の乗車予約の運転ユーザのユーザ端末２００Ａとキャンセル要求の送信元の乗車希望ユーザのユーザ端末２００Ｂとへ、乗車予約がキャンセルされたことを通知する。また、ＯＰ２０４では、予約処理部１１は、キャンセル要求の送信元の乗車希望ユーザについて、ユーザ情報ＤＢ １４の年間キャンセル実績のフィールドの値を更新する。

ＯＰ２０５では、予約処理部１１は、乗車予約のキャンセル要求の送信元の乗車希望ユーザにペナルティを付与する。ペナルティの内容については、上述の通りである。予約処理部１１は、乗車希望ユーザに付与されたペナルティについて、当該乗車希望ユーザのユーザ端末２００Ｂへ通知してもよいし、例えば、ユーザ情報ＤＢ １４に記録してもよい。ＯＰ２０６では、予約処理部１１は、キャンセル要求の対象の乗車予約の運転ユーザについてのマッチングをマッチング処理部１２に依頼する。

ＯＰ２０７では、予約処理部１１は、キャンセル要求の対象の乗車予約の運転ユーザについてのマッチングで、新たにマッチングされる乗車希望ユーザが見つかったか否かを判定する。新たにマッチングされる乗車希望ユーザが見つかった場合には（ＯＰ２０７：ＹＥＳ）、処理がＯＰ２０９に進む。新たにマッチングされる乗車希望ユーザが見つからなかった場合には（ＯＰ２０７：ＮＯ）、処理がＯＰ２０８に進む。なお、ＯＰ２０７におけるマッチングは、いずれの運転ユーザともマッチングされていない乗車希望要求の送信元の乗車希望ユーザについて行われる。ただし、これに限られず、例えば、会員ランクの低い運転ユーザとの乗車予約が確定している乗車希望ユーザをマッチング対象としてマッチングが行われてもよい。

ＯＰ２０８では、予約処理部１１は、キャンセル要求の対象の乗車予約の運転ユーザと、当該乗車予約のスケジュール情報とを、マッチング優先リスト１９に登録する。これによって、以降、キャンセルされた乗車予約と類似するスケジュール情報の乗車予約要求が受信された場合に、当該運転ユーザが優先的にマッチングされるようになる（図９参照）。なお、ＯＰ２０８において、予約処理部１１は、キャンセル要求の対象の乗車予約の運
転ユーザのユーザ端末２００Ａへ、マッチング優先リスト１９へ登録されたことを通知してもよい。その後、図１０Ａに示される処理が終了する。

ＯＰ２０９では、予約処理部１１は、キャンセル要求の対象の乗車予約の運転ユーザについてのマッチングで、新たにマッチングされる乗車希望ユーザが見つかったので、当該マッチングについて乗車予約を確定させる。また、予約処理部１１は、端末通信部１３を通じて、キャンセル要求の対象の乗車予約の運転ユーザのユーザ端末２００Ａへ新たな乗車予約が確定したことを通知する。その後、図１０Ａに示される処理が終了する。

ＯＰ２１０とＯＰ２１１との処理は、キャンセル要求の受信時刻が対象の乗車予約の合流予定時刻から所定時間前である場合に行われる処理である。ＯＰ２１０では、予約処理部１１は、キャンセル要求の対象の乗車予約のキャンセル処理を行う。ＯＰ２１０で行われるキャンセル処理は、ＯＰ２０４で行われるキャンセル処理と同様である。ＯＰ２１１では、予約処理部１１は、端末通信部１３を通じて、対象の乗車予約の運転ユーザのユーザ端末２００Ａと乗車希望ユーザのユーザ端末２００Ｂとに、乗車予約がキャンセルされたことを通知する。その後、図１０Ａに示される処理が終了する。

図１０Ｂに示される処理は、運転ユーザのユーザ端末２００Ａから乗車予約のキャンセル要求が受信された場合の処理である。運転ユーザのユーザ端末２００Ａからの乗車予約要求とともに、キャンセル対象の乗車予約の識別情報も受信される。運転ユーザのキャンセル対象となる乗車予約は、車両１０の１回の移動で複数の乗車希望ユーザを乗車させる場合には、複数となる。

ＯＰ３０１では、予約処理部１１は、キャンセル要求の対象の乗車予約の合流予定時刻から所定時間前であるか否かを判定する。対象の乗車予約の合流予定時刻から所定時間前である場合には（ＯＰ３０１：ＹＥＳ）、処理がＯＰ３０２に進む。対象の乗車予約の合流予定時刻から所定時間前の時刻が経過している場合には（ＯＰ３０１：ＮＯ）、処理がＯＰ３０４に進む。

ＯＰ３０２とＯＰ３０３との処理は、キャンセル要求の受信時刻が対象の乗車予約の合流予定時刻から所定時間前である場合に行われる処理である。予約処理部１１は、キャンセル要求の対象の乗車予約のキャンセル処理を行い（ＯＰ３０２）、端末通信部１３を通じて、対象の乗車予約の運転ユーザのユーザ端末２００Ａへ、乗車予約がキャンセルされたことを通知する（ＯＰ３０３）。その後、図１０Ｂに示される処理が終了する。なお、運転ユーザのキャンセル対象の乗車予約が複数ある場合（車両１０の１回の移動で複数の乗車希望ユーザを乗車させる場合）には、各乗車予約についてキャンセル処理及び乗車希望ユーザへのキャンセル通知が行われる。

ＯＰ３０４からＯＰ３１２の処理は、キャンセル要求の対象の乗車予約の合流予定時刻から所定時間前の時刻が経過している場合に行われる処理である。ＯＰ３０４では、予約処理部１１は、乗車予約のキャンセル要求の送信元の運転ユーザにペナルティを付与する。ペナルティの内容については、上述の通りである。予約処理部１１は、運転ユーザに付与されたペナルティについて、当該運転ユーザのユーザ端末２００Ａへ通知してもよいし、運転ユーザに付与されたペナルティの情報が、例えば、ユーザ情報ＤＢ １４に記録されてもよい。

ＯＰ３０５からＯＰ３１２の処理は、１つの乗車予約の１の乗車希望ユーザについての処理であって、キャンセル対象の乗車予約の乗車希望ユーザごとに行われる。以降、ＯＰ３０５からＯＰ３１２の処理対象の乗車希望ユーザを、対象の乗車希望ユーザ、と称する。

ＯＰ３０５では、予約処理部１１は、対象の乗車希望ユーザについてのマッチングをマッチング処理部１２に依頼する。マッチング処理部１２は、既に乗車予定の乗車希望ユーザが定員に達している車両１０も含めて、対象の乗車希望ユーザについてマッチングを行う。ただし、これに限定されず、既に乗車予定の乗車希望ユーザが定員に達している車両１０は、マッチングの対象から除外してもよい。

ＯＰ３０６では、予約処理部１１は、対象の乗車希望ユーザについて、マッチング相手の車両１０が決定されたか否かを判定する。対象の乗車希望ユーザについて、マッチング相手の車両１０が決定された場合には（ＯＰ３０６：ＹＥＳ）、処理がＯＰ３０８に進む。対象の乗車希望ユーザについて、マッチング相手の車両１０が決定されなかった場合には（ＯＰ３０６：ＮＯ）、処理がＯＰ３０７に進む。

ＯＰ３０７では、マッチングが成立しなかったので、予約処理部１１は、対象の乗車希望ユーザに対して、所定のインセンティブを付与する。その後、他のキャンセル対象の乗車予約の乗車希望ユーザについて、ＯＰ３０５からの処理が行われるか、または、図１０Ｂに示される処理が終了する。

ＯＰ３０８では、予約処理部１１は、対象の乗車希望ユーザについて新たにマッチングされた車両１０は定員超過するか否かを判定する。対象の乗車希望ユーザについて新たにマッチングされた車両１０は定員超過する場合には（ＯＰ３０８：ＹＥＳ）、処理がＯＰ３０９に進む。対象の乗車希望ユーザについて新たにマッチングされた車両１０は定員超過しない場合には（ＯＰ３０８：ＮＯ）、予約処理部１１は、当該マッチングに従って乗車予約を確定し、対象の乗車希望ユーザのユーザ端末２００Ｂへ乗車予約確定の通知を送信する。その後、他のキャンセル対象の乗車予約の乗車希望ユーザについて、ＯＰ３０５からの処理が行われるか、または、図１０Ｂに示される処理が終了する。

以下、対象の乗車希望ユーザについて新たにマッチングされた車両１０であって、定員超過となる車両１０を、対象の車両１０と称する。

ＯＰ３０９では、予約処理部１１は、対象の車両１０に乗車予定の全乗車希望ユーザのユーザ端末２００Ｂへ、キャンセル依頼と、キャンセルした場合に付与されるインセンティブの情報と、を送信する。これは、対象の車両１０が定員超過となるので、乗車予約をキャンセルしてくれる乗車希望ユーザを募るための処理である。対象の車両１０に乗車予定の全ての乗車希望ユーザの情報は、例えば、予約情報ＤＢ １７から取得される。キャンセル依頼とともにキャンセル対象の乗車予約の識別情報も送信される。キャンセル依頼の送信先である、対象の車両１０に乗車予定の乗車希望ユーザを、以下、キャンセル依頼対象ユーザと称する。

ＯＰ３１０では、予約処理部１１は、キャンセル依頼対象ユーザのユーザ端末２００Ｂのいずれかからキャンセル依頼に対する乗車予約のキャンセル要求が受信されたか否かを判定する。キャンセル依頼対象ユーザのユーザ端末２００Ｂのいずれかからキャンセル依頼に対する乗車予約のキャンセル要求が受信された場合には（ＯＰ３１０：ＹＥＳ）、処理がＯＰ３１１に進む。例えば、キャンセル依頼の送信から所定時間が経過しても、キャンセル依頼対象ユーザのユーザ端末２００Ｂのいずれからも乗車予約のキャンセル要求が受信されない場合には（ＯＰ３１０：ＮＯ）、処理がＯＰ３０５に進み、再度マッチングが行われる。

ＯＰ３１１では、予約処理部１１は、ＯＰ３０８で受信が検出された乗車予約のキャンセル要求の送信元のキャンセル依頼対象ユーザにインセンティブを付与する。インセンテ
ィブの内容については、上述の通りである。予約処理部１１は、当該キャンセル依頼対象ユーザに付与されたインセンティブについて、当該キャンセル依頼対象ユーザのユーザ端末２００Ｂへ通知してもよいし、例えば、ユーザ情報ＤＢ １４に記録してもよい。

ＯＰ３１２では、予約処理部１１は、ＯＰ３０８で受信が検出された乗車予約のキャンセル要求の対象の乗車予約についてキャンセル処理を行う。乗車予約のキャンセル処理の内容は、図１０ＡのＯＰ２０４と同様である。また、予約処理部１１は、対象の車両１０の運転ユーザのユーザ端末２００ＡとＯＰ３０８で受信が検出された乗車予約のキャンセル要求の送信元のキャンセル依頼対象ユーザのユーザ端末２００Ｂとに、乗車予約のキャンセル通知を送信する。他のキャンセル対象の乗車予約の乗車希望ユーザについて、ＯＰ３０５からの処理が行われるか、または、図１０Ｂに示される処理が終了する。

なお、図１０Ａ及び図１０Ｂに示される、センタサーバ１００の乗車予約のキャンセル要求を受信した場合の処理は、一例であり、これに限定されない。

＜第１実施形態の作用効果＞
第１実施形態では、センタサーバ１００は、運転ユーザ又は乗車希望ユーザから乗車予約のキャンセル要求が発生した場合には、当該乗車予約の乗車希望ユーザ又は運転ユーザに、代替となる運転ユーザ又は乗車希望ユーザをマッチングする。これによって、乗車予約がキャンセルされた側のユーザの予定に与える影響を低減することができる。さらに、センタサーバ１００は、キャンセル要求の送信元の運転ユーザ又は乗車希望ユーザにペナルティを付与する。これによって、運転ユーザ又は乗車希望ユーザが安易に乗車予約のキャンセルを行うことを抑制することができる。

また、第１実施形態では、センタサーバ１００は、乗車予約がキャンセルされた乗車希望ユーザ又は運転ユーザに、代替となる運転ユーザ又は乗車希望ユーザのマッチング相手が見つからない場合には、当該乗車希望ユーザ又は運転ユーザにインセンティブを付与する。これによって、乗車予約のキャンセルによって発生する損害を補償することができ、ライドシェアサービスに対する利用意欲の低下を抑制することができる。

また、第１実施形態では、センタサーバ１００は、運転ユーザからの乗車予約のキャンセルが発生した場合に、当該乗車予約の乗車希望ユーザについて、代替となる運転ユーザ（車両１０）のマッチングを行う。マッチングされた車両１０が、当該乗車希望ユーザが乗車することで定員超過となる場合には、センタサーバ１００は、マッチングされた車両１０に乗車予定の他の乗車希望ユーザのユーザ端末２００Ｂへ、当該車両１０への乗車予約についてキャンセル依頼を送信する。これによって、マッチングされた車両１０の乗車予定の乗車希望ユーザから、当該車両１０への乗車をゆずってくれる乗車希望ユーザを募ることができる。キャンセル依頼に応じて乗車予約をキャンセルしてくれた乗車希望ユーザにはインセンティブが付与されるので、キャンセル依頼に応じてくれやすくなる。

＜その他の実施形態＞
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施しうる。

第１実施形態では、センタサーバ１００は、運転ユーザからの乗車予約のキャンセルが発生した場合に、当該乗車予約の乗車希望ユーザについて、代替となる運転ユーザ（車両１０）のマッチングを行い、マッチングされた車両１０が、当該乗車希望ユーザが乗車することで定員超過となる場合には、マッチングされた車両１０に乗車予定の他の乗車希望ユーザのユーザ端末２００Ｂへキャンセル依頼を送信する。これに代えて、キャンセル依頼の送信先となる乗車希望ユーザは、例えば、マッチングされた車両１０に乗車予定の乗
車希望ユーザのうち、会員ランクが最も低いユーザに限定されてもよい。これによって、会員ランクの高い乗車希望ユーザに対して、乗車予約がキャンセルされにくくなるという優待を提供することができる。

本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本発明は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク、ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１ ：ライドシェアサービス提供システム
１０ ：車両
１１ ：予約処理部
１２ ：マッチング処理部
１３ ：端末通信部
１４ ：ユーザ情報データベース
１５ ：乗車希望ユーザスケジュール情報データベース
１６ ：運転ユーザスケジュール情報データベース
１７ ：予約情報データベース
１８ ：ランク情報データベース
１９ ：マッチング優先リスト
１００ ：センタサーバ
１０１ ：プロセッサ
１０２ ：主記憶部
１０３ ：補助記憶部
１０４ ：通信部
２００ ：ユーザ端末
２００Ａ ：ユーザ端末
２００Ｂ ：ユーザ端末

Claims (5)

1. 所定の目的地へ移動する車両への便乗乗車による移動サービスの予約を管理することと、
   第１の車両による前記移動サービスの第１の予約が成立している、前記第１の車両の運転ユーザ又は前記第１の車両へ乗車する予定の乗車ユーザのいずれかである第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信することと、
   前記第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信した場合に、
   前記第１のユーザの代わりとなる運転ユーザ又は乗車ユーザを決定することと、
   前記第１のユーザにペナルティを付与することと、
   を実行する制御部を備える情報処理装置であって、
   前記制御部は、
   前記第１のユーザが運転ユーザである場合に、前記第１のユーザの代わりの運転ユーザとして、前記第１の予約の第１の乗車ユーザを乗車させる第２の車両の運転ユーザを決定することと、
   前記第１の乗車ユーザの前記第２の車両への乗車によって、前記第２の車両について定員超過が発生する場合に、前記第２の車両へ乗車する第２の予約が確定している第２の乗車ユーザのユーザ端末へ、前記第２の予約のキャンセル依頼と前記第２の予約をキャンセルした場合に前記第２の乗車ユーザへ付与されるインセンティブの情報とを送信することと、
   を実行する、
   情報処理装置。
2. 前記ペナルティは、キャンセル料の請求、次回以降の前記移動サービスの利用料金の値下げ又は値上げ、前記移動サービスの予約の優先順位の低下のいずれかである、
   請求項１に記載の情報処理装置。
3. 前記インセンティブは、前記移動サービスの予約の優先度の向上、ポイント又はクーポンの付与のいずれかである、
   請求項１又は２に記載の情報処理装置。
4. 所定の目的地へ移動する車両への便乗乗車による移動サービスの予約を管理することと、
   第１の車両による前記移動サービスの第１の予約が成立している、前記第１の車両の運転ユーザ又は前記第１の車両へ乗車する予定の乗車ユーザのいずれかである第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信することと、
   前記第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信した場合に、
   前記第１のユーザの代わりとなる運転ユーザ又は乗車ユーザを決定することと、
   前記第１のユーザにペナルティを付与することと、
   を実行する１又は複数の制御部を備える情報処理システムであって、
   前記１又は複数の制御部は、
   前記第１のユーザが運転ユーザである場合に、前記第１のユーザの代わりの運転ユーザとして、前記第１の予約の第１の乗車ユーザを乗車させる第２の車両の運転ユーザを決定することと、
   前記第１の乗車ユーザの前記第２の車両への乗車によって、前記第２の車両について定員超過が発生する場合に、前記第２の車両へ乗車する第２の予約が確定している第２の乗車ユーザのユーザ端末へ、前記第２の予約のキャンセル依頼と前記第２の予約をキャンセルした場合に前記第２の乗車ユーザへ付与されるインセンティブの情報とを送信することと、
   を実行する、
   情報処理システム。
5. 所定の目的地へ移動する車両への便乗乗車による移動サービスの予約を管理し、
   第１の車両による前記移動サービスの第１の予約が成立している、前記第１の車両の運転ユーザ又は前記第１の車両へ乗車する予定の乗車ユーザのいずれかである第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信し、
   前記第１のユーザのユーザ端末から前記第１の予約のキャンセル要求を受信した場合に、
   前記第１のユーザの代わりとなる運転ユーザ又は乗車ユーザを決定し、
   前記第１のユーザにペナルティを付与する、
   ことを含む、
   コンピュータによって実行される情報処理方法であって、
   前記第１のユーザが運転ユーザである場合に、前記第１のユーザの代わりの運転ユーザとして、前記第１の予約の第１の乗車ユーザを乗車させる第２の車両の運転ユーザを決定することと、
   前記第１の乗車ユーザの前記第２の車両への乗車によって、前記第２の車両について定員超過が発生する場合に、前記第２の車両へ乗車する第２の予約が確定している第２の乗車ユーザのユーザ端末へ、前記第２の予約のキャンセル依頼と前記第２の予約をキャンセルした場合に前記第２の乗車ユーザへ付与されるインセンティブの情報とを送信することと、
   を更に含む、
   情報処理方法。

Images