JP2022050813A - 運行管理装置及び運行管理方法 - Google Patents

Abstract

【課題】運行効率を向上し、予約断り数を低減させる、運行スケジュールを生成する。【解決手段】運行管理装置は、複数のユーザの、乗車希望時刻又は降車希望時刻を含む許容時間、乗車許容範囲、及び降車許容範囲を示す情報を保持し、ユーザ全員の許容時間を満たす車両の運行スケジュールを生成できないと判定した場合、リクエスト出力対象ユーザの乗車希望時刻、降車希望時刻、乗車希望位置、及び降車希望位置を変更するリクエストであって、許容時間が満たされなかったユーザの当該許容時間を満たす運行スケジュールが生成可能となる１以上のリクエスト、を生成し、当該１以上のリクエストが示すリクエスト出力対象ユーザの、許容時間、乗車許容範囲、及び降車許容範囲に基づいて、１以上のリクエストから出力対象のリクエストを選択して出力する。【選択図】図２

Description

本発明は、運行管理装置及び運行管理方法に関する。

本技術分野の背景技術として、国際公開第２０１４／００２２６７号（特許文献１）及び特開２０１８－２００５５５号公報（特許文献２）がある。特許文献１には、「オンデマンドバス１０の複数のユーザは、要望として、運行管理センタ２０に対して、バス１０に乗車する希望乗車位置、希望乗車時刻及び希望乗車時間帯を指定するための乗車許容付加時間と、バス１０から降車する希望降車位置、希望降車時刻及び希望降車時間帯を指定するための降車許容付加時間とを含む予約情報を情報端末装置３０を利用して送信する。センタ２０は、それぞれの予約情報のうちの希望乗車時間帯及び希望降車時間帯の組み合わせを考慮して、複数のユーザが、希望乗車時間帯内で希望乗車位置にてバス１０に乗車し、希望降車時間帯内で希望降車位置にてバス１０から降車するように、バス１０を運行する運行スケジュールを決定する。」と記載されている（要約参照）。

また、特許文献２には、「乗車場所および降車場所が何れも同じという第１の条件に合致しなかったユーザのうち、出発地または目的地が第２の条件に合致するユーザに相乗り同乗者グループ内に入ることを提示し、承諾の応答が入力された場合に、当該ユーザを相乗り同乗者グループに追加する第２のマッチング部１５Ｂを備え、第２の条件として、出発地または目的地が、第１の条件に合致した乗車場所および降車場所をもとに設定される仮想ラインから所定の距離以内の場所にあるという条件を用いることにより、最初に設定されたルート上にない場所であっても、第２の条件を満たし、かつ、ユーザからの承諾が得られれば、途中乗車または途中下車する場所として設定され得るようにする。」と記載されている（要約参照）。

国際公開第２０１４／００２２６７号 特開２０１８－２００５５５号公報

特許文献１に記載の技術では、ユーザが希望乗車時間及び希望降車時間に対する許容時間を入力するか否かを決定することができ、即ち効率化された運行スケジュールを立案できるか否かはあくまでユーザの自主性に委ねられている。また、特許文献１に記載の技術では、多くのユーザが同時間帯に乗車を希望する場合には、多くの予約を断る必要がある。

また、特許文献２に記載の技術は、乗車場所と降車場所に加えて、乗車場所及び降車場所からの所定の距離範囲を含む仮想ラインを考慮して相乗り車両への同乗者を決定しているものの、この仮想ライン上に複数のユーザの乗車場所と降車場所を含む距離範囲が位置していない場合や、多くのユーザが同時間帯に乗車を希望する場合には、効率化された運行スケジュールを立案することはできない。

そこで、本発明の一態様は、運行効率を向上し、予約断り数を低減させることができる、運行スケジュールを生成する。

上記課題を解決するため、本発明の一態様は以下の構成を採用する。複数のユーザが乗車可能な車両の運行を管理する運行管理装置は、プロセッサとメモリとを有し、前記メモリは、前記複数のユーザそれぞれの、前記車両への乗車希望時刻又は前記車両からの降車希望時刻を含む許容時間と、前記車両への乗車希望位置を含む乗車許容範囲と、前記車両からの降車希望位置を示す降車許容範囲と、を示す予約情報を保持し、前記プロセッサは、前記複数のユーザの全員の前記許容時間を満たす、前記車両の運行スケジュールを生成できるかの判定を実行し、前記運行スケジュールを生成できないと判定した場合、前記複数のユーザに含まれるリクエスト出力対象ユーザを示し前記リクエスト出力対象ユーザの乗車希望時刻、降車希望時刻、乗車希望位置、及び降車希望位置の少なくとも１つを変更するリクエストであって、前記運行スケジュールにおいて前記許容時間が満たされなかったユーザの当該許容時間を満たすような運行スケジュールが生成可能となる１以上のリクエストを生成し、前記１以上のリクエストが示す前記リクエスト出力対象ユーザの、前記許容時間、前記乗車許容範囲、及び前記降車許容範囲の少なくとも１つに基づいて、前記１以上のリクエストから出力対象のリクエストを選択して出力し、前記出力したリクエストに対する諾否に基づいて、運行スケジュールを再生成する。

本発明の一態様によれば、運行効率を向上し、予約断り数を低減させる、運行スケジュールを生成することができる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

実施例１における運行管理システムの構成例を示すブロック図である。 実施例１における運行管理装置の構成例を示すブロック図である。 実施例１におけるユーザ情報テーブルの一例である。 実施例１における予約情報テーブルの一例である。 実施例１における運行情報テーブルの一例である。 実施例１における運行管理システムの全体処理の一例を示すシーケンス図である。 実施例１における運行管理装置による運行スケジュール算出処理の一例を示すフローチャートである。 実施例１におけるタイムテーブル作成処理の一例を示す説明図である。 実施例１における運行経路算出の処理の一例を示す説明図である。 実施例１における運行経路算出処理及び運行所要時間算出処理の一例を示す説明図である。 実施例１における重複判定処理の一例を示す説明図である。 実施例１における乗り合い判定の一例を示す説明図である。 実施例１における乗り合い判定の一例を示す説明図である。 実施例１における乗り合いを考慮した経路の一例を示す説明図である。 実施例１における乗車時刻／降車時刻調整処理の一例を示す説明図である。 実施例１における乗車時刻／降車時刻調整処理後のタイムテーブルである。 実施例１におけるゆずりあいリクエスト算出処理の一例を示すフローチャートである。 実施例１におけるゆずりあいリクエスト算出処理の別例を示すフローチャートである。 実施例１におけるインセンティブ算出処理Ａの一例を示すフローチャートである。 実施例１におけるインセンティブ算出処理Ｂの一例を示すフローチャートである。 実施例１における運行スケジュール算出処理において確定した経路の一例を示す説明図である。 実施例１における利用者端末に表示される予約入力画面の一例である。 実施例１における利用者端末に表示される予約入力画面の一例である。 実施例１における利用者端末に表示されるゆずりあいリクエスト受信画面の一例である。 実施例１における利用者端末に表示されるインセンティブ付与画面の一例である。 実施例２における複数台の車両の運行スケジュール算出処理の一例を示すフローチャートである。 実施例２における運行スケジュール算出処理の一例を示す説明図である。 実施例２における運行スケジュール算出処理の一例を示す説明図である。 実施例２における複数台の車両の運行スケジュール算出処理の別例を示すフローチャートである。

以下、本発明の実施形態を図面に基づいて詳細に説明する。本実施形態において、同一の構成には原則として同一の符号を付け、繰り返しの説明は省略する。なお、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。

図１は、運行管理システムの構成例を示すブロック図である。運行管理システムは、例えば、例えば、互いにインターネット等のネットワーク４００で接続された、運行管理装置１００、１以上の利用者端末２００、及び１以上の車載端末３００を含む。運行管理装置１００は、オンデマンド交通の管理を行う。具体的には、運行管理装置１００は、利用者端末２００からの要求に応じてオンデマンドで、車載端末３００を搭載する車両の運行を管理する。

利用者端末２００は、運行管理対象の車両の乗車希望者（ユーザ）が有する端末（例えば、スマートホン、タブレット、ＰＣ（Ｐｅｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等）であり、乗車予約を登録するための情報の入力を受け付け、運行管理装置１００に送信する。また、利用者端末２００は、予約確認情報、ゆずりあいリクエスト、及びポイント情報等を、運行管理装置１００から受信する。車載端末３００は、運行管理対象の車両に搭載された端末であり、車両の運行実績情報を車両から取得し、運行管理装置１００に送信する。また、車載端末３００は、運行スケジュールを示す情報を、運行管理装置１００から受信する。

なお、本実施形態では、運行管理システムが乗り合いバスやタクシー等の車両の運行を管理する例を説明するが、運行管理システムは船舶や航空機等のあらゆる乗り物の運行管理に適用可能である。

また、図１の例では、ユーザが利用者端末２００を用いて、運行管理装置１００とのデータや指示の送受信を行うが、例えば、ユーザが（例えば、バス会社の接客スペース等に設置された）運行管理装置１００に対してデータや指示を直接入力できるようにしてもよい。

図２は、運行管理装置１００の構成例を示すブロック図である。運行管理装置１００は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１、メモリ１０２、補助記憶装置１０３、通信装置１０４、入力装置１０５、及び出力装置１０６を有する計算機によって構成される。

ＣＰＵ１０１は、プロセッサを含み、メモリ１０２に格納されたプログラムを実行する。メモリ１０２は、不揮発性の記憶素子であるＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及び揮発性の記憶素子であるＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ））などを格納する。ＲＡＭは、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のような高速かつ揮発性の記憶素子であり、ＣＰＵ１０１が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。

補助記憶装置１０３は、例えば、磁気記憶装置（ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ））、フラッシュメモリ（ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ））等の大容量かつ不揮発性の記憶装置であり、ＣＰＵ１０１が実行するプログラム及びプログラムの実行時に使用されるデータを格納する。すなわち、プログラムは、補助記憶装置１０３から読み出されて、メモリ１０２にロードされて、ＣＰＵ１０１によって実行される。

入力装置１０５は、例えばキーボードやマウスなどの、オペレータからの入力を受ける装置である。出力装置１０６は、例えばディスプレイやプリンタなど、プログラムの実行結果をオペレータが視認可能な形式で出力する装置である。

通信装置１０４は、所定のプロトコルに従って、他の装置との通信を制御するネットワークインターフェース装置である。また、通信装置１０４は、例えば、ＵＳＢ等のシリアルインターフェースを含んでもよい。

ＣＰＵ１０１が実行するプログラムは、リムーバブルメディア（ＣＤ－ＲＯＭ、フラッシュメモリなど）又はネットワーク４００を介して運行管理装置１００に提供され、非一時的記憶媒体である不揮発性の補助記憶装置１０３に格納される。このため、運行管理装置１００は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。

運行管理装置１００は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。利用者端末２００及び車載端末３００についても同様である。

ＣＰＵ１０１は、例えば、運行スケジュール算出部１１１、ゆずりあいリクエスト算出部１１２、及びインセンティブ算出部１１３を含む。運行スケジュール算出部１１１は、利用者端末２００から受信した予約情報に基づいて、車両の運行スケジュールを算出する。具体的には、例えば、運行スケジュール算出部１１１は、車両の走行ルート、停車ポイント間の所要時間、及び停車ポイントへの到着時刻等を算出したり、複数の利用者の予約を調整したり、車両の配車スケジュールを算出したりする。

ゆずりあいリクエスト算出部１１２は、運行スケジュール算出部１１１が利用者端末２００のユーザの予約の調整が必要であると判定した場合に、少なくとも一部のユーザに対して乗車時間、降車時間、乗車位置、又は降車位置の変更を依頼するためのゆずりあいリクエストを算出する。インセンティブ算出部１１３は、ゆずりあいリクエストに対する諾否結果、並びに利用者端末２００のユーザが入力した許容時間及び許容距離に基づいて、ユーザに対して付与するインセンティブを算出する。

例えば、ＣＰＵ１０１は、メモリ１０２にロードされた運行スケジュール算出プログラムに従って動作することで、運行スケジュール算出部１１１として機能し、メモリ１０２にロードされたゆずりあいリクエスト算出プログラムに従って動作することで、ゆずりあいリクエスト算出部１１２として機能する。ＣＰＵ１０１に含まれる他の機能部についても、プログラムと機能部の関係は同様である。

なお、ＣＰＵ１０１含まれる機能部による機能の一部又は全部が、例えば、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等のハードウェアによって実現されてもよい。

補助記憶装置１０３は、例えば、ユーザ情報テーブル１２１、予約情報テーブル１２２、及び運行情報テーブル１２３を保持する。ユーザ情報テーブル１２１は、利用者端末２００のユーザに関する情報を保持する。予約情報テーブル１２２は、利用者端末２００のユーザからの乗車予約に関する情報を保持する。運行情報テーブル１２３は、車両の運行に関する情報を保持する。なお、補助記憶装置１０３に格納されている一部又は全部の情報は、メモリ１０２に格納されていてもよいし、運行管理装置１００に接続されているデータベースに格納されていてもよい。

なお、本実施形態において、運行管理システムが使用する情報は、データ構造に依存せずどのようなデータ構造で表現されていてもよい。本実施形態ではテーブル形式で情報が表現されているが、例えば、リスト、データベース又はキューから適切に選択したデータ構造体が、情報を格納することができる。

図３は、ユーザ情報テーブル１２１の一例である。ユーザ情報テーブル１２１は、例えば、ユーザＩＤ欄１２１１、ユーザ名欄１２１２、住所欄１２１３、連絡先欄１２１４、ゆずりあい履歴欄１２１５、ゆずりあいポイント欄１２１６、ごめんねポイント欄１２１７、及び備考欄１２１８を含む。

ユーザＩＤ欄１２１１は、ユーザ（利用者端末２００を利用する乗客）を識別する情報を保持する。ユーザ名欄１２１２は、ユーザの名称を示す情報を保持する。住所欄１２１３は、ユーザの住所を示す情報を保持する。連絡先欄１２１４は、ユーザの連絡先を示す情報を保持する。ゆずりあい履歴欄１２１５は、ゆずりあいリクエストに対するユーザの回答実績を示す情報を保持する。具体的には、例えば、ゆずりあい履歴欄１２１５は、ユーザが受けたゆずりあいリクエストの内容と、当該ゆずりあいリクエストに対する諾否結果と、ゆずりあいリクエストを受諾した場合における当該ゆずりあいリクエストが示す時刻と許容時間の開始時間又は終了時間との差、及び当該ゆずりあいリクエストが示す位置との許容距離との端部との差、を保持する。

ゆずりあいポイント欄１２１６は、ユーザが保持するゆずりあいポイント数を示す情報を保持する。ごめんねポイント欄１２１７は、ユーザが保持するごめんねポイント数を示す情報を保持する。備考欄１２１８は、ユーザに関する備考を示す情報を保持する。例えば、脚が悪く長い距離を歩けないユーザは、許容距離が極めて小さいため、乗車位置及び降車位置を変更させることは難しい。従って、このようなユーザの備考欄１２１８には、ゆずりあいリクエストの対象外（図中「Ｒｅｑ非対象」）であることを示す情報が格納されているとよい。

なお、備考欄１２１８には、当該ユーザが降車時間、乗車時間、乗車位置、及び降車位置のいずれかについてゆずりあいリクエストの非対象であることを示す情報が格納されていてもよい。また、備考欄１２１８には、例えば、当該ユーザに関連するユーザ（例えば、家族、友人など）のユーザＩＤが格納されていてもよい。

図４は、予約情報テーブル１２２の一例である。予約情報テーブル１２２は、例えば、ユーザＩＤ欄１２２１、乗車日欄１２２２、乗車時刻欄１２２３、降車時刻欄１２２４、許容時間（－）欄１２２５、許容時間（＋）欄１２２６、乗車位置欄１２２７、降車位置欄１２２８、乗車許容距離欄１２２９、降車許容距離欄１２２１０、及び乗車人数欄１２２１１を含む。詳細は後述するが、予約情報テーブル１２２は、予約が確定する前にはユーザの予約希望情報を保持し、予約が確定した後には予約登録情報を保持する。

ユーザＩＤ欄１２２１は、ユーザ（利用者端末２００を利用する乗客）を識別する情報を保持する。乗車日欄１２２２は、ユーザが車両に乗車する日（又は希望日）を示す情報を保持する。乗車時刻欄１２２３は、ユーザが車両に乗車する時刻（又は希望乗車時刻）を示す情報を保持する。降車時刻欄１２２４は、ユーザが車両から降車する時刻（又は希望降車時刻）を示す情報を保持する。

許容時間（－）欄１２２５は、ユーザが希望する乗車時刻又は降車時刻から早めることを許容できる時間の幅を示す情報を保持する。許容時間（＋）欄１２２６は、ユーザが希望する乗車時刻又は降車時刻から遅らせることを許容できる時間の幅を示す情報を保持する。なお、予約情報テーブル１２２は、許容時間欄を１つだけ有してもよく、この場合許容時間（－）と許容時間（＋）とが同じ値であるものとする。

乗車位置欄１２２７は、ユーザが車両に乗車する位置（又は希望乗車位置）を示す情報を保持する。降車位置欄１２２８は、ユーザが車両から降車する位置（又は希望降車位置）を示す情報を保持する。

乗車許容距離欄１２２９は、ユーザが希望する乗車位置から離れることを許容できる距離を示す情報を保持する。降車許容距離欄１２２１０は、ユーザが希望する降車位置から離れることを許容できる距離を示す情報を保持する。乗車人数欄１２２１１は、対象のユーザを含む乗車人数（又は乗車希望人数）を示す情報を保持する。なお、予約情報テーブル１２２は、乗車許容距離欄１２２０及び降車許容距離欄１２２１０の代わりに許容距離欄を１つだけ有してもよく、この場合、乗車許容距離と降車許容距離とが同じ値であるものとする。乗車人数欄１２２１１は、ユーザが希望する乗車人数を示す。

図５は、運行情報テーブル１２３の一例である。運行情報テーブル１２３は、例えば、車両ＩＤ欄１２３１、運行実績欄１２３２、車両位置欄１２３３、及び乗車率欄１２３４を含む。車両ＩＤ欄１２３１は、運行管理対象、即ち車載端末３００を有する車両を識別する情報を保持する。運行実績欄１２３２は、車両の運行実績（例えば、過去の走行距離及び走行ルートの時系列等）を示す情報を保持する。車両位置欄１２３３は、車両の現在位置を示す情報を保持する。乗車率欄１２３４は、車両の現在の乗車率を示す情報を保持する。

図６は、運行管理システムの全体処理の一例を示すシーケンス図である。利用者端末２００は、利用者端末２００のユーザから乗車基本情報の入力を受け付け、ユーザＩＤと乗車基本情報とを紐づけて、運行管理装置１００に送信する（Ｓ６０１）。乗車基本情報は、例えば、ユーザの希望乗車時刻又は希望降車時刻、当該ユーザの希望乗車位置及び希望降車位置、並びに乗車人数を含む。

運行管理装置１００の運行スケジュール算出部１１１は、受信した希望乗車時刻又は希望降車時刻、希望乗車位置又は希望降車位置、並びに過去の混雑履歴（例えば、運行管理装置１００が予め保持している、又は外部の装置から取得する）に基づいて、車両が通行する可能性がある道路の混雑予測を実行する（Ｓ６０２）。運行スケジュール算出部１１１は、ステップＳ６０２で実行した混雑予測の結果を、乗車基本情報を送信した利用者端末２００に送信して、利用者端末２００に表示させる（Ｓ６０３）。

なお、ステップＳ６０２及びステップＳ６０３の処理は実行されなくてもよい。また、ステップＳ６０２及びステップＳ６０３の処理に加えて又は代えて、運行スケジュール算出部１１１は、利用者端末２００のユーザの予約に有用な情報を、利用者端末２００に送信する処理を実行してもよい。具体的には、例えば、ユーザ情報テーブル１２１の備考欄１２８において、ユーザ同士の関連（例えば、家族、友人など）を示す情報（例えばユーザＩＤを用いて紐づけられている）が予め登録されており、運行スケジュール算出部１１１は、ステップＳ６０１で取得したユーザＩＤに関連するユーザＩＤに対応するユーザ名を、利用者端末２００に返信して表示させるようにしてもよい。また、例えば、運行管理装置１００は、各車両の空席数をリアルタイムで車載端末３００から受信し、運行スケジュール算出部１１１は、受信した空席数を利用者端末２００に送信して表示させるようにしてもよい。

混雑予測の結果を受信した利用者端末２００は、利用者端末２００のユーザから、希望乗車時刻又は希望降車時刻からの許容時間（前側の許容時間の長さと後側の許容時間の長さ）、並びに希望乗車位置及び希望降車位置入力からの許容距離の入力を受け付け、入力を受け付けた情報と、ユーザＩＤと、を紐づけて、運行管理装置１００に送信する（Ｓ６０４）。なお、利用者端末２００は、許容時間に代えて又は加えて複数の希望乗車時刻又は希望降車時刻を運行管理装置１００に送信してもよいし、許容距離に代えて又は加えて複数の希望乗車位置又は希望降車位置を運行管理装置１００に送信してもよい。

運行管理装置１００の運行スケジュール算出部１１１は、ステップＳ６０４において受信した情報を予約情報テーブル１２２に（仮）登録し（Ｓ６０５）、予約受付が完了したことを示す情報を、ステップＳ６０４において情報を送信した利用者端末２００に対して送信して表示させる（Ｓ６０６）。

なお、例えば、予約受付時間が運行管理装置１００のユーザによって設定可能であり、ステップＳ６０１からステップＳ６０６の処理は、この予約受付時間内に行われるものである。予約受付時間が終了するとステップＳ６０７の処理が開始する。なお、ステップＳ６０７以降の処理において出現する利用者端末２００は、特に説明がない限りステップＳ６０６における予約受付が完了したユーザが利用する利用者端末２００を示す。

運行管理装置１００は、受け付けた予約情報に基づいて運行スケジュールを算出し、必要に応じてゆずりあいリクエストを算出し、さらに利用者端末２００のユーザに対するインセンティブを算出し、確定した予約を予約情報テーブル１２２に登録する（Ｓ６０７）。なお、詳細は後述するが、ステップＳ６０７の一部の処理は、ステップＳ６０８～ステップＳ６１０のいずれかの処理の結果に応じて行われる。

ゆずりあいリクエスト算出部１１２は、ステップＳ６０７でゆずりあいリクエストを算出した場合、ゆずりあいリクエストの対象のユーザが利用する利用者端末２００に対してゆずりあいリクエストを送信する（Ｓ６０８）。ゆずりあいリクエストを受信した利用者端末２００は、当該利用者端末２００のユーザによって入力されたゆずりあいリクエストに対する諾否結果を運行管理装置１００に送信する（Ｓ６０８）。なお、運行スケジュール算出部１１１は、ゆずりあいリクエストを承認したユーザについては、当該ゆずりあいリクエストに従って、当該ユーザの乗車日、乗降者時刻、及び／又は乗降者位置を修正する。

運行スケジュール算出部１１１は、予約確認及び予約確定通知を利用者端末２００に送信する（Ｓ６１０）。予約確認は、予約が成立したか否かを示す情報を含む。ゆずりあいリクエストを受諾したユーザ又はゆずりあいリクエストを受信しなかったユーザが利用する利用者端末２００が受信する予約確認は、予約が成立したことを示す情報を含み、ゆずりあいリクエストを受諾しなかったユーザが利用する利用者端末２００が受信する予約確認は、予約が成立しなかったことを示す情報を含む。

予約確定通知は、例えば、確定した乗車日、乗降者時刻、乗降者位置、及び乗車人数を示す情報を含む。なお、運行スケジュール算出部１１１は、ゆずりあいリクエストを受諾しなかったユーザに対しては、予約確定通知を送信しない。また、例えば、車載端末３００が二次元コードを読み取る機能を有しているとよく、予約確定通知は当該車両を予約したユーザのユーザＩＤ、確定した乗車日、乗降者時刻、乗降者位置、及び乗車人数を示す二次元コードを含んでいるとよい。

予約が確定したユーザが利用する利用者端末２００は、当該ユーザの指示に従って、予約を了承する通知（支払い情報を含む）を運行管理装置１００に送信する（Ｓ６１１）。例えば、運行管理装置１００のユーザによって決定された予約了承時間までに当該通知を受信しなかったユーザについては予約がキャンセルされたものとして、運行スケジュール算出部１１１は予約情報テーブル１２２に格納されている予約のレコードを削除するとよい。

運行スケジュール算出部１１１は、予約が確定したユーザが乗車する車両に搭載された車載端末３００に対して配車指示を送信する（Ｓ６１２）。配車指示は、例えば、当該車両に乗車する予定の各ユーザのユーザＩＤ、乗車日、乗降者時刻、乗降者位置、及び乗車人数を示す情報、並びに運行スケジュール算出部１１１が算出した当該車両の走行ルートを示す情報を含む。

以下の処理は確定した予約に従って、車両が走行を開始してから実行される処理である。車載端末３００は、車両の位置情報をリアルタイムで運行管理装置１００に送信し（Ｓ６１３）、運行管理装置１００は受信した位置情報を運行情報テーブル１２３に格納する。なお、車載端末３００には、当該車両に乗車する予定の各ユーザのユーザＩＤ、乗車日、乗降者時刻、乗降者位置、及び乗車人数を示す情報、並びに当該車両の走行ルートを示す情報が表示されているとよい。

運行スケジュール算出部１１１は、車載端末３００から受信した位置情報に基づいて、予約が確定したユーザの利用者端末２００に対して、当該ユーザの乗車位置に車両が近付いた（例えば、当該乗車位置に所定距離以内に近づいた、又は混雑予測に基づいて所定時間以内に当該乗車位置に車両が到着すると予測した）ときに、車両が接近していることを示す通知を送信する（Ｓ６１４）。

例えば、車両に乗車する際に、車両に乗車するユーザの利用者端末２００は、当該ユーザの指示に従って、前述した二次元コードを表示し（Ｓ６１５）、車載端末３００は、前述した二次元コードを読み取ることで、当該ユーザが当該車両を予約した正当なユーザである（乗車日、乗車時刻、及び乗車位置が正しい）ことを確認する乗車確認を行う（Ｓ６１６）。車載端末６１６は、乗車確認が行われたユーザを示す情報を運行管理装置１００に送信する（Ｓ６１７）。

運行管理装置１００は、乗車確認が行われた、かつインセンティブポイント（ゆずりあいポイント及び／又はごめんねポイント）の付与対象であるユーザに対して、ポイントを付与（ユーザ情報テーブル１２１を更新）し、当該ユーザが利用する利用者端末２００に対して付与されたインセンティブポイントを示す情報を送信して表示させる。

図７は、運行管理装置１００による運行スケジュール算出処理の一例を示すフローチャートである。具体的には、図７は、ステップＳ６０１～ステップＳ６１１までの処理のうち運行管理装置１００によって実行される処理の詳細（但し一部の処理については説明を省略している）を示す。

運行スケジュール算出部１１１は、乗車予約を取得する（Ｓ７０１）。乗車予約とは、ステップＳ６０１で説明した乗車基本情報と、ステップＳ６０４で説明した許容時間及び許容距離と、を含む情報である。ステップＳ７０１の処理が終了することと、ステップＳ６０４までの処理が終了することは同義である。運行スケジュール算出部１１１は、予約受付時間が終了したら、乗車基本情報に含まれる、ユーザの希望乗車時刻又は希望降車時刻、当該ユーザの希望乗車位置及び希望降車位置、並びに乗車人数と、許容時間と、に基づいて、タイムテーブルを作成する（Ｓ７０２）。

図８は、タイムテーブル作成処理の一例を示す説明図である。運行スケジュール算出部１１１は、例えば、乗車基本情報を送信したユーザのユーザＩＤ（図中の予約者欄にユーザＩＤが格納されている）それぞれについて、希望乗車位置（図中の「－ｏ」で終わる位置）及び希望降車位置（図中の「－ｄ」で終わる位置）と、希望停車時刻（停車とは、乗車と降車のいずれかを指す）と、希望停車時刻からの前側の許容時間と後ろ側の許容時間との間の時間（許容時間）と、をタイムテーブルに格納する。運行スケジュール算出部１１１は、図８のように、希望停車時刻順にタイムテーブルをソートしてもよい。

図７の説明に戻る。運行スケジュール算出部１１１は、乗車基本情報に含まれる、ユーザの希望乗車時刻又は希望降車時刻、当該ユーザの希望乗車位置及び希望降車位置に基づいて、車両の運行経路及び運行にかかる所要時間を算出する（Ｓ７０３）。

図９は、運行経路算出の処理の一例を示す説明図である。運行スケジュール算出部１１１は、地図上に、各ユーザの希望乗車位置及び希望降車位置それぞれについて、当該位置を中心とし、半径が許容距離である円を生成する。

図１０は、図９の続きの運行経路算出処理及び運行所要時間算出処理の一例を示す説明図である。運行スケジュール算出部１１１は、出発地から目的地の間の最短経路を算出する所定の経路検索アルゴリズム（例えばカーナビなどで活用されるダイクストラ法など）に基づいて、各ユーザについての希望乗車位置と希望降車位置とを結ぶ経路と、当該経路を車両が走行した場合の運行にかかる所要時間とを算出する。運行スケジュール算出部１１１は、算出した運行時間をタイムテーブルに格納する（後述する図１１参照）。

図７の説明に戻る。運行スケジュール算出部１１１は、タイムテーブルにおいて、許容時間を含む希望乗車時間又は希望降車時間の少なくとも一部が重複している複数のユーザがいるかを判定する（Ｓ７０４）。運行スケジュール算出部１１１は、当該重複がないと判定した場合（Ｓ７０４：Ｎｏ）、乗り合いが発生しないものとして、生成済みのタイムテーブルが示す予約（配車スケジュール）を確定する（Ｓ７１４）。運行スケジュール算出部１１１は、当該重複があると判定した場合（Ｓ７０４：Ｙｅｓ）、当該重複があるユーザ間で乗り合いが可能かを判定する（Ｓ７０５）。

具体的には、例えば、運行スケジュール算出部１１１は、当該重複があるユーザ間で、許容時間を含めた希望乗車時間又は希望降車時間が重なっている（例えば許容時間内である）、出発地（当該重複の対象が許容時間を含めた希望乗車時間である場合）／到着地（当該重複の対象が許容時間を含めた希望降車時間である場合）が近接している（例えば許容距離以内である）、又は当該重複の対象の少なくとも１人のユーザの出発地（当該重複の対象が許容時間を含めた希望乗車時間である場合）／到着地（当該重複の対象が許容時間を含めた希望降車時間である場合）が、当該重複の対象の他のユーザのステップＳ７０３で算出した経路上（例えば当該少なくとも１人のユーザの許容距離内）にある、を含むいずれかの条件を満たすユーザ間で乗り合いが可能であると判定する。

図１１は、ステップＳ７０４における重複判定処理の一例を示す説明図である。図１１の例では、ユーザＩＤが「１」のユーザからユーザＩＤが「４」のユーザの組み合わせ、及びユーザＩＤが「５」のユーザとユーザＩＤが「６」のユーザの組み合わせ、それぞれについて、タイムテーブルにおける、許容時間を含む希望乗車時間又は希望降車時間の少なくとも一部が重複している（例えば、ユーザＩＤが「１」のユーザとユーザＩＤが「３」のユーザとでは重複は発生していないが、いずれもユーザＩＤが「２」のユーザと重複が発生しており、このように重複が連鎖しているユーザ間では重複が発生しているものとする）。従って、これらの組み合わせそれぞれにおいて、少なくとも１人のユーザの乗車時刻又は降車時刻の調整が必要である。図１１中における「算出した乗車時刻／降車時刻」は、経路と乗車時刻又は降車時刻の一方とから算出された、乗車時刻又は降車時刻の他方である。

図１２は、ステップＳ７０５における乗り合い判定の一例を示す説明図である。図１２の例では、運行スケジュール算出部１１１は、ユーザＩＤが「３」のユーザの降車時刻と、ユーザＩＤが「４」のユーザの乗車時刻と、が一致し、ユーザＩＤが「５」のユーザの乗車時刻と、ユーザＩＤが「６」のユーザの乗車時刻と、が一致するため、それぞれ乗り合いが可能であると判定している。さらに、停車順序が確定している。

図１３は、ステップＳ７０５における乗り合い判定の一例を示す説明図である。図１２で説明したように、ユーザＩＤが「３」のユーザと「４」のユーザとの乗り合いが可能であり、さらに、これら２人のユーザのそれぞれの許容距離の範囲内に位置する同じ位置になるよう、ユーザＩＤが「３」のユーザの降車位置と、ユーザＩＤが「４」のユーザの乗車位置と、が調整されている。同様に、ユーザＩＤが「５」のユーザとユーザＩＤが「６」のユーザそれぞれの許容距離の範囲内に位置する同じ位置になるよう、ユーザＩＤが「５」のユーザの乗車位置と、ユーザＩＤが「６」のユーザの乗車位置と、が調整されている。

図１４は、乗り合いを考慮した経路の一例を示す説明図である。ユーザＩＤが「３」のユーザの降車位置と、ユーザＩＤが「４」のユーザの乗車位置と、が一致し、さらにユーザＩＤが「５」のユーザの乗車位置と、ユーザＩＤが「６」のユーザの乗車位置と、が一致した経路と所要時間とが算出されている。図中の丸印と数字は停車位置及び停車順を示し、実線は車両に乗客が少なくとも１人は乗車している予定の走行ルートを示し、点線は車両に乗客が１人も乗車していない予定の走行ルートを示す。

図７の説明に戻る。運行スケジュール算出部１１１は、当該重複があるユーザ間で乗り合いが可能であるユーザについて（Ｓ７０５：Ｙｅｓ）、上記した条件に従って、許容時間の重複が発生したまま、当該乗り合いが可能なユーザの少なくとも１人について、許容時間内で乗車時刻又は降車時刻を変更し（Ｓ７０６）、許容距離以内で乗車位置及び／又は降車位置を変更して、経路を再生成する（Ｓ７０７）ことで、当該重複があるユーザ間で乗り合いが発生するように運行スケジュールを調整する。但し、車両の定員が予め定められている場合には、運行スケジュール算出部１１１は、乗車人数を参照して、当該定員を超過しないように運行スケジュールを調整する。

運行スケジュール算出部１１１は、当該重複があるユーザ間で乗り合いが可能でないユーザについて（Ｓ７０６：Ｎｏ）、許容時間の重複が発生しないように、当該乗り合いが可能でないユーザの少なくとも１人について、許容時間内で乗車時刻又は降車時刻を変更し（Ｓ７０８）、許容距離以内で乗車位置及び／又は降車位置を変更して、経路を再生成する（Ｓ７０９）ことで、当該重複がないユーザ間で乗り合いが発生しないように運行スケジュールを調整する。

運行スケジュール算出部１１１は、ステップＳ７０６～ステップＳ７０９における乗車時刻／降車時刻調整処理、及び乗車位置／降車位置調整処理において、例えば、以下の規則を用いて、乗車時刻、降車時刻、乗車位置、及び降車位置を調整する。

運行スケジュール算出部１１１は、複数のユーザの許容時間を含む希望乗車時刻又は希望降車時刻の少なくとも一部が重複している場合、当該許容時間の範囲内で乗車時刻又は降車時刻を調整する。また、複数のユーザの許容時間を含む希望乗車時刻又は希望降車時刻の少なくとも一部が重複している場合、車両の走行距離が最短となるように乗車時刻又は降車時刻を調整する。このとき、乗車時刻又は降車時刻の調整対象のユーザの希望乗車時刻又は希望降車時刻からずらされる時間の合計が最小となるように乗車時刻又は降車時刻を調整してもよいし、乗車時刻又は降車時刻の調整対象のユーザの希望乗車時刻又は希望降車時刻からずらされる時刻が当該ユーザ間でなるべく平等になるように（例えば、分散が小さくなるように、又はずらされる時刻が最大値と最小値との差が小さくなるように）調整してもよい。

図１５は、ステップＳ７０６及びステップＳ７０８における乗車時刻／降車時刻調整処理の一例を示す説明図である。図１５のタイムテーブルは、運行スケジュール算出部１１１が、各ユーザの乗車時刻又は降車時刻の許容時間の範囲内で、算出した経路における最短時間に基づいて、各ユーザの乗車時刻及び降車時刻を算出した結果を示している。

図１６は、ステップＳ７０６及びステップＳ７０８における乗車時刻／降車時刻調整処理後のタイムテーブルの一例である。図１６のタイムテーブルには、図１５で算出された乗車時刻と降車時刻が格納されている。

図７の説明に戻る。運行スケジュール算出部１１１は、予約を受け付けた全てのユーザについて、許容時間の範囲を満たす運行スケジュール（当該全てのユーザについて、ステップＳ７０６～Ｓ７０９における調整後の乗車時刻又は降車時刻が許容時間内に収まっている運行スケジュール）を生成したか否かを判定する（Ｓ７１０）。

運行スケジュール算出部１１１は、当該運行スケジュールを生成したと判定した場合（Ｓ７１０：Ｙｅｓ）、当該運行スケジュールにて予約を確定する（Ｓ７１４）。運行スケジュール算出部１１１が、当該運行スケジュールを生成していないと判定した場合（Ｓ７１０：Ｎｏ）、ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエスト算出処理を実行する（Ｓ７１１）。ゆずりあいリクエスト算出処理の詳細については後述する。

ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエストに対する諾否結果をゆずりあいリクエストを送信したユーザの利用者端末２００から受信し、当該ユーザそれぞれがゆずりあいリクエストを承諾したかを判定する（Ｓ７１２）。

ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエストを受諾したユーザ（Ｓ７１２：Ｙｅｓ）に対しては、当該ゆずりあいリクエストが示す乗車時間、降車時間、乗車位置、又は降車位置へと当該ユーザの予約を変更し、ゆずりあいリクエストを受諾しなかったユーザ（Ｓ７１２：Ｎｏ）に対しては、当該ユーザの利用者端末２００に対して予約を断ったことを示す通知を送信（さらに予約情報テーブル１２２から当該予約に対応するレコードを削除又は予約を断ったことを示す情報を追加）して（Ｓ７１３）、運行スケジュール算出部１１１は、予約配車スケジュールを確定する（Ｓ７１４）。

なお、ゆずりあいリクエストを受信した利用者端末２００は、ユーザの入力に従って、ゆずりあいリクエストにおけるゆずりあい度合いを調整する応答を送信可能なようにしてもよい。例えば、ゆずりあいリクエストにおいて、希望降車時間の許容時間よりも３０分遅らせること及び希望乗車位置の許容距離よりも１００ｍ離れていることが示されている場合において、利用者端末２００は、希望降車時間の許容時間よりも２０分遅らせるだけであればゆずりあいリクエストを受諾することや、希望乗車位置の許容距離よりも２００ｍ離れていてもゆずりあいリクエストを受諾すること等を示すゆずりあい調整情報を、運行管理装置１００に送信してもよい。

この場合、ゆずりあいリクエスト算出部１１２は、受信したゆずりあいリクエスト調整情報に基づいて、再度ゆずりあいリクエストを算出してもよい。このように、運行管理装置１００と利用者端末２００との間でインタラクティブにゆずりあいリクエストの内容を変更することで、予約が成立する可能性が高くなる。

続いて、運行スケジュール算出部１１１は、確定した予約配車スケジュールを、当該予約配車スケジュールにおいて走行する車両に搭載された車載端末３００に送信する（Ｓ７１５）。インセンティブ算出部１１３は、インセンティブ算出処理Ａを実行する（Ｓ７１６）。インセンティブ算出処理Ａの詳細については後述する。運行スケジュール算出部１１１は、予約が確定したユーザの利用者端末２００に対して、確定した予約の内容を示す通知を送信し（Ｓ７１７）、運行スケジュール算出処理を終了する。

図１７Ａは、ゆずりあいリクエスト算出処理の一例を示すフローチャートである。ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエストの１以上のパターンを算出する（Ｓ１７０１）。ゆずりあいリクエストは、例えば、ゆずりあいの対象となる１以上のユーザそれぞれのユーザＩＤ、当該ユーザそれぞれに対する乗車時刻、降車時刻、乗車位置、及び降車位置の少なくとも１つの変更リクエスト（変更後の情報）を含む。

例えば、ゆずりあいリクエスト算出部１１２は、ステップＳ７０４における重複判定処理により重複が発生していることが判定されており、かつ、ステップＳ７０５～Ｓ７１０の処理によって乗り合い乗車、又は許容時間内での時間変更が不可である少なくとも１人のユーザの希望乗車時刻、希望降車時刻、希望乗車位置、及び希望降車位置の少なくとも１つを、当該少なくとも１人以外のユーザの許容時間を満たす範囲（さらに許容距離を満たす範囲としてもよい）で、変更することで、１以上のゆずりあいリクエストを算出する。このとき、当該少なくとも１人のユーザについては許容時間及び／又は許容距離の範囲外（但し、例えば、許容時間のさらに前後の所定時間まで、許容距離に所定距離を加えた距離の範囲内に）となるように変更がなされてもよい。

なお、例えば、ゆずりあいリクエスト算出部１１２は、ユーザ情報テーブル１２１の備考欄１２１８を参照して、「Ｒｅｑ非対象」のユーザをゆずりあいリクエストの送信対象から除外した上でゆずりあいリクエストを算出する。また、例えば、ゆずりあいリクエスト算出部１１２は、例えば、ユーザ情報テーブル１２１の備考欄１２１８を参照して、ゆずりあいリクエストの送信対象のユーザに関連するユーザがいると判定した場合（例えば、家族、友人など）、当該送信対象のユーザの乗車時刻、降車時刻、乗車位置、又は降車位置が当該関連するユーザのものと一致するゆずりあいリクエストを算出してもよい。

これにより、ユーザがゆずりあいリクエストを受諾すると、自身と関連するユーザと同時に車両に乗車する時間帯が発生するため、ゆずりあいリクエストの受諾率が向上することが予想される。

続いて、ゆずりあいリクエスト算出部１１２は、ステップＳ１７０１において複数のリクエストパターンを算出したかを判定する（Ｓ１７０２）。ゆずりあいリクエスト算出部１１２は、複数のリクエストパターンを算出したと判定した場合（Ｓ１７０２：Ｙｅｓ）、例えば、当該複数のリクエストパターンそれぞれのゆずりあいの時間、距離、及び／又は過去のゆずりあい数（ゆずりあい数の定義については後述する）に基づいて、１つのリクエストパターンを選択する（Ｓ１７０３）。

具体的には、例えば、ゆずりあいリクエスト算出部１１２は、当該複数のリクエストパターンのうち、ゆずりあいリクエストの送信対象のゆずりあいの時間の合計値が最小のリクエストパターンを選択してもよいし、ゆずりあいリクエストの送信対象のゆずりあいの距離の合計値が最小のリクエストパターンを選択してもよいし、ゆずりあいリクエストの送信対象の過去のゆずりあい数の合計値が最小のリクエストパターンを選択してもよい。

また、例えば、ゆずりあいリクエスト算出部１１２は、例えば、ゆずりあいリクエストの送信対象のゆずりあいの時間の合計値と、ゆずりあいの距離の合計値と、の減少関数である所定の評価関数によって評価値を算出し、算出した評価値が最大のリクエストパターンを選択してもよい。また、例えば、ゆずりあいリクエスト算出部１１２は、例えば、ゆずりあいリクエストの送信対象の人数が最小のリクエストパターンを選択してもよい。

ゆずりあいリクエスト算出部１１２は、リクエストパターンを１つのみしか算出できなかったと判定した場合（Ｓ１７０２：Ｎｏ）、ステップＳ１７０４へと遷移する。続いて、ゆずりあいリクエスト算出部１１２は、決定したリクエストパターンが複数人に対するリクエストを含んでいるかを判定する（Ｓ１７０４）。

ゆずりあいリクエスト算出部１１２は、決定したリクエストパターンが１人に対するリクエストのみを含んでいると判定した場合（Ｓ１７０４：Ｎｏ）、インセンティブ算出処理Ｂを実行し（Ｓ１７１１）、リクエストパターンに含まれるゆずりあいリクエストを、送信対象である利用者端末２００に、優先順位に従って、送信して（Ｓ１７１２）、ゆずりあいリクエスト算出処理を終了する。

なお、インセンティブ算出処理Ｂの詳細については後述する。また、ゆずりあいリクエスト算出部１１２は、ステップＳ１７１２において、優先順位が高い順に所定数又は所定割合のゆずりあいリクエストを同時に送信してもよいし、順次送信（例えば、未送信のゆずりあいリクエストを送信し優先順位が最高のゆずりあいリクエストを送信し、当該ゆずりありリクエストが受諾されなかったら次のゆずりあいリクエストを送信することを、受諾されるまで繰り返す）してもよい。

ゆずりあいリクエスト算出部１１２は、決定したリクエストパターンが複数人に対するゆずりあいリクエストを含んでいると判定した場合（Ｓ１７０４：Ｙｅｓ）、ゆずりあいリクエスト送信対象者間の許容時間の差が大きいか（例えば最大の許容時間と最小の許容時間との差が所定値以上であるか）を判定する（Ｓ１７０５）。

ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエスト送信対象者間の許容時間の差が大きいと判定した場合（Ｓ１７０５：ＹＥＳ）、ゆずりあいリクエスト送信対象者間の許容時間に基づいて、ゆずりあいリクエスト送信の優先順位を決定し（Ｓ１７０６）、ステップＳ１７１１へ遷移する。具体的には、例えば、ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエスト送信対象者の許容時間が小さいゆずりあいリクエストほど高い優先順位を付与する（但し、許容時間の差が所定値（例えば５０ｍ）以内であるゆずりあいリクエスト送信対象者には同一の優先順位を付与してもよい）。これにより、許容時間が小さいユーザに対して、優先的にゆずりあいリクエストを送信することができるため、ユーザ間での公平性が高まる。

ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエスト送信対象者間の許容時間の差が大きくないと判定した場合（Ｓ１７０５：Ｎｏ）、ゆずりあいリクエスト送信対象者間の許容距離の差が大きいか（例えば最大の許容距離と最小の許容距離との差が所定値以上であるか）を判定する（Ｓ１７０７）。

ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエスト送信対象者間の許容距離の差が大きいと判定した場合（Ｓ１７０７：ＹＥＳ）、ゆずりあいリクエスト送信対象者間の許容距離に基づいて、ゆずりあいリクエスト送信の優先順位を決定し（Ｓ１７０８）、ステップＳ１７１１へ遷移する。具体的には、例えば、ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエスト送信対象者の許容距離が小さいゆずりあいリクエストほど高い優先順位を付与する（但し、許容距離の差が所定値（例えば５０ｍ）以内であるゆずりあいリクエスト送信対象者には同一の優先順位を付与してもよい）。これにより、許容距離が小さいユーザに対して、優先的にゆずりあいリクエストを送信することができるため、ユーザ間での公平性が高まる。

ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエスト送信対象者間の許容距離の差が大きくないと判定した場合（Ｓ１７０７：Ｎｏ）、ユーザ情報テーブル１２１のゆずりあい履歴欄１２１５が示す、ゆずりあいリクエスト送信対象者の過去のゆずりあい数を比較する（Ｓ１７０９）。なお、過去のゆずり数として、過去に受諾したゆずりあいリクエストにおいて譲った時間の合計と距離の合計に応じて高くなる値、過去にゆずりあいリクエストを受諾した回数、又はゆずりあいポイントの回数等が採用できる。

ゆずりあいリクエスト算出部１１２は、ステップＳ１７０９に比較結果に基づいて、ゆずりあいリクエスト送信の優先順位を決定し（Ｓ１７１０）、ステップＳ１７１１へ遷移する。具体的には、例えば、ゆずりあいリクエスト算出部１１２は、ゆずりあいリクエスト送信対象者の過去のゆずりあい数が少ないゆずりあいリクエストほど高い優先順位を付与する。

これにより、過去にゆずりあいリクエストを受諾した回数が少ないユーザに対して、優先的にゆずりあいリクエストを送信することができるため、ユーザ間での公平性が高まる。また、ユーザは、ゆずりあいリクエストを受諾するほど、ゆずりあいリクエストを受信する可能性が低くなるため、例えばゆずりあいリクエストを受信したときに時間に余裕があるユーザは未来の時間がない状況に備えて予め積極的にゆずりあいリクエストを受諾しやすくなる。

上記した例では、ゆずりあいリクエスト算出部１１２が、ゆずりあいリクエストの優先順位のみを算出する例を説明しているが、ゆずりあいリクエスト算出部１１２は、例えば、優先度の値（例えば、ステップＳ１７０５では許容時間の所定の減少関数から得られる値、ステップＳ１７０７では許容距離の所定の減少関数から得られる値、ステップＳ１７０９では過去のゆずりあい数の所定の減少関数から得られる値）を算出して、例えば、優先度の値が所定値以上であるゆずりあいリクエストを送信するようにしてもよい。

また、上記した例では、ゆずりあいリクエスト算出部１１２は、ステップＳ１７０５において許容距離の差が大きくないと判定した場合に、ステップＳ１７０７で許容距離の差が大きいかを判定し、さらにステップＳ１７０７で許容距離の差が大きくないと判定した場合に、ステップＳ１７０９において過去のゆずりあい数を比較している。ユーザの乗車時間又は降車時間を調整が、分散乗車又は乗り合い乗車の成立に対する効果が最も高いため、このような順序で判定が行われている。但し、これらの判定が実行される順序は上記した例に限らず、任意の順序で実行されてもよい。

具体的には、例えば、ゆずりあいリクエスト算出部１１２は、ステップＳ１７０４に続いて、許容距離の差が大きいかを判定して、許容距離の差が大きれば許容距離に基づく優先順位を決定し、許容距離の差が大きくなければ、過去のゆずりあいリクエスト数の差が大きいかを判定し、過去のゆずりあいリクエスト数の差が大きければ過去のゆずりあいリクエスト数に基づく優先順位を決定し、過去のゆずりあいリクエスト数の差が大きくなければ許容距離に基づく優先順位を決定するようにしてもよい。

また、ゆずりあいリクエスト算出部１１２は、許容時間、及び許容距離、及び過去のゆずりあい数の少なくとも２つに基づく優先順位を算出してもよい。具体的には、例えば、ゆずりあいリクエスト算出部１１２は、許容時間の減少関数であり、許容距離の減少関数であり、かつ過去のゆずりあい数の減少関数である所定の関数により評価値を算出して、当該評価値が大きい順にゆずりあいリクエストの優先順位が高くなるように、当該優先順位を付与してもよい。

また、例えば、運行管理装置１００はユーザからの予約受付時に乗車目的の入力を受け付け、ゆずりあいリクエスト算出部１１２は、前述した許容時間、許容距離、及び過去のゆずりあい数に加えて又は代えて、乗車目的に基づく優先順位を決定してもよい。例えば、乗車目的ごとに評価値が予め定められ（例えば乗車目的が「買い物」＞「通勤・通学」＞「通院」の順に評価値が小さくなる）、当該評価値が高いほどゆずりあいリクエストの優先順位が高くなるようにするとよい。

図１７Ｂは、ゆずりあいリクエスト算出処理の別例を示すフローチャートである。つまり、ゆずりあいリクエスト算出部１１２は、ステップＳ７１１の処理として、図１７Ａの処理を実行してもよいし、図１７Ｂの処理を実行してもよい。

ゆずりあいリクエスト算出部１１２は、図１７Ａと同様にステップＳ１７０１及びステップＳ１７０２の処理を実行する。ゆずりあいリクエスト算出部１１２は、リクエストパターンを１つのみしか算出できなかったと判定した場合（Ｓ１７０２：Ｎｏ）、ステップＳ１７１１のインセンティブ算出処理Ｂを実行し、ゆずりあいリクエストを一斉送信（即ち複数人に対するゆずりあいリクエストであっても当該複数人全員に送信）し（Ｓ１７２２）、ゆずりあいリクエスト算出処理を終了する。

ゆずりあいリクエスト算出部１１２は、複数のリクエストパターンを算出したと判定した場合（Ｓ１７０２：Ｙｅｓ）、当該複数のリクエストパターンのうちゆずりあいを行うユーザの人数（つまりゆずりあいリクエストを一斉送信するときの送信対象者数）が最小のリクエストパターンを選択し（Ｓ１７２１）、ステップＳ１７１１のインセンティブ算出処理Ｂを実行し、ゆずりあいリクエストを一斉送信し（Ｓ１７２２）、ゆずりあいリクエスト算出処理を終了する。

なお、ゆずりあいリクエスト算出部１１２は、ステップＳ１７２１において、予約の調整が必要なグループ（例えば、タイムテーブルにおいて許容時間を含む乗車時間又は降車時間の少なくとも一部が重複しているユーザ群）に一斉にリクエストを送信してもよい。また、例えば、ゆずりあいリクエストには、「予約時間を前後２時間程度ずらしてくれる人を募集」や、「乗車/降車位置を３００ｍｍずらしてくれる人を募集」等の、乗車時間、降車時間、乗車位置、及び／又は降車位置を変更してほしいことを示すメッセージが含まれているとよい。

図１８は、ステップＳ７１６におけるインセンティブ算出処理Ａの一例を示すフローチャートである。インセンティブ算出処理Ａは、ステップＳ７０１において乗車予約をしたユーザそれぞれに対して行われる。インセンティブ算出部１１３は、当該ユーザに対して予約が成立したかを判定する（Ｓ１８０１）。

インセンティブ算出部１１３は、当該ユーザに対して予約が成立しなかったと判定した場合（Ｓ１８０１：Ｎｏ）、当該ユーザに対してごめんねポイントを算出し（１８０２）付与する、即ちユーザ情報テーブル１２１の当該ユーザのごめんねポイント欄１２１７に格納する（Ｓ１８０５）、インセンティブ算出処理Ａを終了する。なお、インセンティブ算出部１１３は、ごめんねポイント付与対象のユーザに対して一律に同じごめんねポイントを付与してもよいし、ユーザごとに異なるごめんねポイントを付与してもよい（例えば、ゆずりあいリクエストの優先順位の高いユーザほど高い又は低い等）。また、インセンティブ算出部１１３は、予約不成立の状況に応じて異なるポイントを付与してもよい（例えば、同一ユーザが２回以上連続して予約が成立しなかった場合はポイントをさらに加算する等）。

インセンティブ算出部１１３は、当該ユーザに対して予約が成立したと判定した場合（Ｓ１８０１：Ｙｅｓ）、当該ユーザに対して、当該ユーザの許容時間及び／又は許容距離に応じた（例えば、許容時間が長いほど、許容距離が大きいほど高いポイント）ゆずりあいポイントを算出する（Ｓ１８０３）。さらに、インセンティブ算出部１１３は、当該ユーザの許容時間と受諾したゆずりあいリクエストが示す時間との差、及び当該ユーザの許容距離と受諾したゆずりあいリクエストが示す距離との差に基づいて、ゆずりあいポイントを算出する（Ｓ１８０４）。

インセンティブ算出部１１３は、ゆずりあいポイントの付与対象のユーザに対してステップＳ１８０３及びステップＳ１８０４で算出したゆずりあいポイントを付与する即ちユーザ情報テーブル１２１の当該ユーザのゆずりあいポイント欄１２１６に格納する（Ｓ１８０５）して、インセンティブ算出処理Ａを終了する。なお、インセンティブ算出部１１３は、ゆずりあいリクエストを受諾したユーザに対してのみゆずりあいポイントを算出して、付与することが望ましい。

図１９は、ステップＳ１７１１におけるインセンティブ算出処理Ｂの一例を示すフローチャートである。インセンティブ算出部１１３は、当該ユーザの許容時間と受諾したゆずりあいリクエストが示す時間との差、及び当該ユーザの許容距離と受諾したゆずりあいリクエストが示す距離との差に基づいて、ゆずりあいポイントを算出し（Ｓ１９０１）、付与する即ちユーザ情報テーブル１２１の当該ユーザのゆずりあいポイント欄１２１６に格納する（Ｓ１９０５）して、インセンティブ算出処理Ｂを終了する。

なお、インセンティブ算出部１１３は、図１８の処理においては予約が確定した全てのユーザに対してゆずりあいポイントを算出して付与する（但し許容時間及び許容距離が０であるユーザに対してはこのゆずりあいポイントは付与されない）が、図１９の処理において、ゆずりあいリクエストを受諾したユーザに対してのみゆずりあいポイントを算出する。

なお、インセンティブ算出部１１３は、ステップＳ１８０４及びステップＳ１９０１において、許容時間と受諾したゆずりあいリクエストが示す時間との差が大きいほど、及び当該ユーザの許容距離と受諾したゆずりあいリクエストが示す距離との差が大きいほど、ゆずりあいポイントが高くなるよう算出するとよい。

図２０は、運行スケジュール算出処理において確定した経路の一例を示す説明図である。図２０には全ての停車（即ち乗車又は降車）ポイント、停車地点における乗車ユーザ及び降車ユーザ、停車時刻、及び停車ポイント間の経路が示されている。

図２１及び図２２は、利用者端末２００に表示される予約入力画面の一例である。乗車予約開始画面２１００は、乗車日、乗車時刻又は降車時刻、乗車位置、降車位置、及び乗車人数それぞれの入力領域を含む。乗車予約開始画面２１００の「次へ」ボタンが選択されると、許容時間入力画面２１１０へと遷移する。

許容時間入力画面２１１０には、乗車予約開始画面２１００で入力された、乗車時刻又は降車時刻と、乗車時刻又は降車時刻（図中では１４時到着（降車））を中心として許容時間（斜線で塗りつぶされた部分）が示された時計の画像と、が表示されている。乗車予約開始画面２１００から許容時間入力画面２１１０へと遷移したときのデフォルト状態では、許容時間は、所定値（例えば、乗車時刻又は降車時刻の前後それぞれ１時間（図中では１３時から１５時までが許容時間））として表示される。

また、当該時計の画像には、車両が走行しておらず予約が不可能な時間帯が、休止時間として表示されている。また、当該時計の画像の外周にはステップＳ６０２で算出された時間帯ごとの混雑予測が表示されている。

許容時間入力画面２１２０は、許容時間入力画面２１１０においてユーザが後側の許容時間を変更した状態である。許容時間入力画面２１２０では、許容時間が１３時から１５時までに変更されている。許容時間入力画面２１１０及び許容時間入力画面２１２０において、「戻る」ボタンが選択されると乗車予約開始画面２１００へと遷移し、「次へ」ボタンが選択されると、許容距離入力画面２２００へと遷移する。

許容距離入力画面２２００には、乗車位置と降車位置の名称と、許容距離の範囲がドットで塗りつぶされた円を含む乗車位置と降車位置の地図と、が表示されている。許容時間入力画面２１１０から許容距離入力画面２２００へと遷移したときのデフォルト状態では、許容距離は、所定値（例えば、乗車位置及び降車位置のそれぞれ５０ｍ以内）として表示されている。

許容距離入力画面２２１０は、許容距離入力画面２２００においてユーザが許容距離を変更した状態である。許容距離入力画面２２１０では、乗車位置及び降車位置のそれぞれ５０ｍ以内に変更されている。許容距離入力画面２２００及び許容距離入力画面２２１０において、「戻る」ボタンが選択されると許容時間入力画面２１２０へと遷移し、「次へ」ボタンが選択されると、リクエスト送信画面２２２０へと遷移する。リクエスト送信画面２２２０の「送信」ボタンが選択されると、運行管理装置１００は利用者端末２００からの予約を受け付ける。

図２３は、利用者端末２００に表示されるゆずりあいリクエスト受信画面の一例である。ゆずりあいリクエスト受信画面２３００には、リクエスト送信画面２２２０で「送信」ボタンが選択されたことにより運行管理装置１００に送信された、乗車日、乗車時刻又は降車時刻、乗車位置、降車位置、許容時間、及び許容距離が表示されている。

さらに、ゆずりあいリクエスト受信画面２３００には、ゆずりあいリクエストが示す、変更後の乗車時刻又は降車時刻と、変更後の乗車位置及び／又は降車位置と、許容時間と変更後の乗車時刻又は降車時刻との時間差と、許容距離と変更後の乗車位置及び／又は降車位置との距離と、を示す情報が表示されている。

「受諾する」ボタンが選択されるとゆずりあいリクエストが受諾されたことを示す通知が運行管理装置１００に送信される。「受諾しない」ボタンが選択されるとゆずりあいリクエストが受諾されなかったことを示す通知が運行管理装置１００に送信される。

図２４は、利用者端末２００に表示されるインセンティブ付与画面の一例である。インセンティブ付与画面２４００には、例えば、ユーザに付与されたごめんねポイント及びゆずりあいポイントが表示される。

なお、ごめんねポイントは乗車チケットや金券のような金銭的価値を有するポイントでないことが望ましい（例えば、次回の乗車予約時に優先的に時間や距離をゆずってもらえるポイント等であることが望ましい）。仮にごめんねポイントが金銭的価値を有していると、ユーザが意図的に予約が成立しづらい時間帯、乗車位置、及び降車位置等を指定して、ごめんねポイントを貯めることができ車両の運行主体の利益を毀損するおそれがあるためである。

また、ゆずりあいポイントは、ユーザが時間や距離をゆずって実際に車両に乗車する場合に付与されるポイントであるため、ごめんねポイントは乗車チケットや金券のような金銭的価値を有するポイントであってもよい。ごめんねポイントとゆずりあいポイントとが、いずれも金銭的価値を有するポイントである、又はいずれも金銭的価値を有しないポイントである場合には、一度に付与されるごめんねポイントの価値よりもゆずりあいポイントの価値の方が高いことが望ましい。

本実施例の運行管理システムは、ユーザの予約時に許容時間及び許容距離の入力を受け付けることで、予約を成立させやすくし、仮に許容時間及び許容距離の範囲内で予約を成立しない場合であっても、許容時間、許容距離、及び／又は過去のゆずりあい数に基づくゆずりあいリクエストを送信することで、さらに予約を成立させやすくすることができる。また、運行管理システムは、ゆずりあいリクエストに対する諾否、並びに許容時間及び許容距離に基づくインセンティブをユーザに付与することで、ユーザがゆずりあいリクエストを受諾しやすくなる上に、許容時間及び許容距離を大きくとる可能性が高くなるため、さらに予約を成立させることができる。このように、予約が成立しやすくなることにより、ひいては車両の乗り合い率が向上し、車両の運行主体の運営コストが低下する。

本実施例の運行管理システムは、複数台の車両の運行管理を行う。以下、実施例１との相違点について説明する。まずは、運行管理システムが、複数台の車両それぞれが分割された異なるエリアをなるべく走行するよう車両の運行スケジュールを算出する例について説明する。以下、複数の車両が、分割されたどのエリア（以下、単にエリアとも呼ぶ）を担当（走行）するかが予め定められているものとする。

図２５は、複数台の車両の運行スケジュール算出処理の一例を示すフローチャートである。図７との相違点について説明する。運行スケジュール算出部１１１は、各エリア（即ち各車両）について、ステップＳ７０２～ステップＳ７０９の処理を実行する。つまり、運行スケジュール算出部１１１は、各エリア（車両）について、実施例１で示したタイムテーブルを作成する。

なお、ユーザの乗車位置と降車位置の双方が１つのエリアに含まれれば、当該ユーザは当該エリアに対応する車両に乗車するものとする。また、ユーザの乗車位置と降車位置がそれぞれ異なるエリアに含まれれば、例えば、運行スケジュール算出部１１１は、当該乗車位置と当該降車位置とが当該異なるエリアの一方のエリアに含まれるよう当該一方のエリアを拡張（つまり当該一方のエリアが拡張された分だけ当該他方のエリアを縮小）してもよい。

また、ユーザの乗車位置の許容距離の範囲が複数のエリアに跨る場合、又はユーザの降車位置の許容距離の範囲が複数のエリアに跨る場合、例えば、運行スケジュール算出部１１１は、当該許容距離の範囲が当該複数のエリアの１つのエリアに含まれるよう、当該１つのエリアを拡張（つまり当該１つのエリアが拡張された分だけ、許容距離の範囲が跨っていた他のエリアを縮小）してもよい。

運行スケジュール算出部１１１は、全ての車両についてステップＳ７０８又はステップＳ７０９の処理が終了すると、全ての車両について、予約を受け付けた全てのユーザについて、許容時間の範囲かつ許容距離の範囲を満たす運行スケジュール（当該全てのユーザについて、ステップＳ７０６～Ｓ７０９における調整後の乗車時刻又は降車時刻が許容時間内に収まっている運行スケジュール）を生成したか否かを判定する（Ｓ２５０１）。

運行スケジュール算出部１１１は、当該運行スケジュールを生成したと判定した場合（Ｓ２５０１：Ｙｅｓ）、当該運行スケジュールにて各車両の予約を確定する（Ｓ７１４）。運行スケジュール算出部１１１が、当該運行スケジュールを生成していないと判定した場合（Ｓ２５０１：Ｎｏ）、つまり許容時間の範囲かつ許容距離の範囲を満たさないユーザが発生する運行スケジュールしか生成できなかった車両（以下、ヘルプ対象車両とも呼ぶ）があると判定した場合、当該車両と異なるエリアの車両（以下、ヘルプ車両とも呼ぶ）によるヘルプを受けることができるかを判定する（Ｓ２５０２）。

具体的には、例えば、運行スケジュール算出部１１１は、許容時間の範囲及び／又は許容距離の範囲が満たされなかったユーザを、ヘルプ車両が当該許容時間の範囲及び当該許容距離の範囲で乗車させた場合に、当該いずれかの車両の全ユーザの許容時間の範囲及び許容距離の範囲を満たす運行スケジュールを生成できるかを判定すればよい。

運行スケジュール算出部１１１は、ヘルプ対象車両がヘルプ車両によるヘルプを受けることができると判定した場合（Ｓ２５０２：Ｙｅｓ）、ヘルプ対象車両がヘルプ車両によるヘルプを受けるよう変更された（つまり、ヘルプ対象車両に乗車予定だった少なくとも一部のユーザをヘルプ車両に乗車するよう変更された）、運行スケジュールにて各車両の予約を確定する（Ｓ７１４）。

運行スケジュール算出部１１１は、ヘルプ対象車両がヘルプ車両によるヘルプを受けることができないと判定した場合（Ｓ２５０２：Ｎｏ）、ヘルプ対象車両のエリアのユーザに対する、ゆずりあいリクエスト算出処理を実行する（Ｓ７１１）。他の処理については図７と同様である。

図２６及び図２７は本実施例の運行スケジュール算出処理の一例を示す説明図である。図２６のタイムテーブルによれば、ステップＳ７０７及びステップＳ７０９の処理が実行されたものの、エリアＡにおいて少なくとも一部のユーザの許容時間の範囲を満たすように車両ａを運行させることができない。

そこで、運行スケジュール算出部１１１は、例えば、エリアＡにおける時間調整の総和が最小となるように（具体的には、例えば、ステップＳ７１１で算出されるゆずりあいリクエストによって要請される調整時間の総和が最小となるように）、ヘルプ対象車両に乗車予定のユーザから、ヘルプ車両へ乗車させるユーザを選択する。従って、図２６の例では、運行スケジュール算出部１１１は、ユーザＩＤがａ２のユーザ（ユーザａ２とも呼ぶ）とユーザＩＤがａ３のユーザ（ユーザａ３とも呼ぶ）とを選択している。

さらに、例えば、運行スケジュール算出部１１１は、選択したユーザのうち、他のユーザと乗り合い乗車をしていないユーザを選択することが望ましい。従って、図２６の例では、ユーザＩＤがａ４のユーザと乗り合い乗車をするユーザａ３ではなく、他のユーザとの乗り合い乗車をしないユーザａ２を選択している。

続いて、運行スケジュール算出部１１１は、選択したユーザａ２の許容時間及び許容距離の範囲で乗車させることができるヘルプ車両があるかを判定する。図２６の例では、エリアＢの車両は８：３０～１０：３０まで予約がないため、エリアＡまで遠征してユーザａ２を乗車させるヘルプが可能である。

従って、運行スケジュール算出部１１１は、図２７のタイムテーブルが示すように、ユーザａ２を、エリアＡまで遠征するエリアＢの車両に乗車させるスケジュールを生成することによって、全てのエリアのユーザの許容時間及び許容距離の範囲を満たす運行スケジュールを生成することができる。
以下、運行管理システムが、複数台の車両それぞれが１つのエリアを走行するよう車両の運行スケジュールを算出する例について説明する。

図２８は、複数台の車両の運行スケジュール算出処理の別例を示すフローチャートである。図７との相違点について説明する。運行スケジュール算出部１１１は、ステップＳ７０２に続いて、乗車基本情報に含まれる希望乗車時刻又は希望降車時刻、当該ユーザの希望乗車位置及び希望降車位置に基づいて、各ユーザに対して車両を割り当て、ステップＳ７０３と同様の処理によって、各車両の運行経路及び運行にかかる所要時間を算出する（Ｓ２８０１）。

運行スケジュール算出部１１１は、例えば、ユーザを車両に割り当てる割り当てパターンのうち、各車両の走行距離の総和を算出し、当該総和が最小となる割り当てパターンを選択することで、各ユーザを車両に割り当てる。但し、運行スケジュール算出部１１１は、予約希望の全ユーザ（予約希望の所定割合以上のユーザであってもよい）の希望乗車時刻又は希望降車時刻の許容範囲を満たす運行スケジュールが生成できる割り当てパターンがある場合には、当該割り当てパターンのうち、当該総和が最小となる割り当てパターンを選択してもよい。

なお、例えば、利用者端末２００は、あるユーザと同じ車両に乗車したい（又は乗車したくない）等を示す乗車相手希望情報を、ユーザの入力に従って、乗車基本情報に含めてもよい。このとき、運行スケジュール算出部１１１は、予約希望の全ユーザ（予約希望の所定割合以上のユーザであってもよい）の希望乗車時刻又は希望降車時刻の許容範囲を満たす運行スケジュールが生成できる割り当てパターンがある場合に、乗車相手希望情報を満たす運行スケジュールが生成できる割り当てパターンを選択してもよい。

本実施例の運行管理システムは、上記した処理によって、複数台の車両の運行スケジュールの立案においても、実施例１の運行管理システムが奏する効果を実現することができる。つまり、本実施例の運行管理システムは、複数台の車両が運行する場合であっても予約が成立しやすくなり、ひいては、車両の乗り合い率が向上し、車両の運行主体の運営コストが低下する。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることも可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１００ 運行管理装置、１０１ ＣＰＵ、１０２ メモリ、１０３ 補助記憶装置、１０４ 通信装置、１０５ 入力装置、１０６ 出力装置、１１１ 運行スケジュール算出部、１１２ ゆずりあいリクエスト算出部、１１３ インセンティブ算出部、１２１ ユーザ情報テーブル、１２２ 予約情報テーブル、１２３ 運行情報テーブル、２００ 利用者端末

Claims (14)

1. 複数のユーザが乗車可能な車両の運行を管理する運行管理装置であって、
   プロセッサとメモリとを有し、
   前記メモリは、前記複数のユーザそれぞれの、前記車両への乗車希望時刻又は前記車両からの降車希望時刻を含む許容時間と、前記車両への乗車希望位置を含む乗車許容範囲と、前記車両からの降車希望位置を示す降車許容範囲と、を示す予約情報を保持し、
   前記プロセッサは、
   前記複数のユーザの全員の前記許容時間を満たす、前記車両の運行スケジュールを生成できるかの判定を実行し、
   前記運行スケジュールを生成できないと判定した場合、
   前記複数のユーザに含まれるリクエスト出力対象ユーザを示し前記リクエスト出力対象ユーザの乗車希望時刻、降車希望時刻、乗車希望位置、及び降車希望位置の少なくとも１つを変更するリクエストであって、前記運行スケジュールにおいて前記許容時間が満たされなかったユーザの当該許容時間を満たすような運行スケジュールが生成可能となる１以上のリクエスト、を生成し、
   前記１以上のリクエストが示す前記リクエスト出力対象ユーザの、前記許容時間、前記乗車許容範囲、及び前記降車許容範囲の少なくとも１つに基づいて、前記１以上のリクエストから出力対象のリクエストを選択して出力し、
   前記出力したリクエストに対する諾否に基づいて、運行スケジュールを再生成する、運行管理装置。
2. 請求項１に記載の運行管理装置であって、
   前記プロセッサは、
   前記判定において、
   前記複数のユーザに含まれる第１ユーザ及び第２ユーザの前記許容時間の少なくとも一部が重複していると判定した場合、又は前記第１ユーザ及び前記第２ユーザの前記乗車希望位置及び前記降車希望位置の少なくとも一方同士の距離が所定値以下である、若しくは前記第１ユーザ及び前記第２ユーザの一方の乗車経路上に他方の乗車希望位置若しくは降車希望位置があると判定した場合、
   前記第１ユーザと前記第２ユーザとが前記車両に乗り合う運行スケジュールを算出する、運行管理装置。
3. 請求項１に記載の運行管理装置であって、
   前記プロセッサは、
   １以上の前記リクエストからなる複数のリクエストパターンを生成し、
   前記複数のリクエストパターンそれぞれにおける、前記リクエスト出力対象ユーザの乗車希望時刻、降車希望時刻、乗車希望位置、及び降車希望位置の少なくとも１つの変更量に基づいて、前記複数のリクエストパターンから、１つのリクエストパターンを選択し、
   前記１つのリクエストパターンから、前記出力対象のリクエストを選択して出力する、運行管理装置。
4. 請求項１に記載の運行管理装置であって、
   前記プロセッサは、
   前記１以上のリクエストそれぞれについて、当該リクエストが示すリクエスト出力対象ユーザの前記許容時間が小さいユーザほど値が大きくなる優先度を算出し、
   前記算出した優先度に基づいて、前記出力対象のリクエストを選択する、運行管理装置。
5. 請求項１に記載の運行管理装置であって、
   前記プロセッサは、
   前記１以上のリクエストそれぞれについて、当該リクエストが示すリクエスト出力対象ユーザの前記乗車許容範囲及び前記降車許容範囲が小さいユーザほど値が大きくなる優先度を算出し、
   前記算出した優先度に基づいて、前記出力対象のリクエストを選択する、運行管理装置。
6. 請求項１に記載の運行管理装置であって、
   前記メモリは、前記複数のユーザの前記リクエストに対する受諾回数及び／又は受諾した前記リクエストによって変更された前記乗車希望時刻、前記降車希望時刻、前記乗車希望位置、及び前記降車希望位置の変更量の履歴を示すリクエスト受諾情報を保持し、
   前記プロセッサは、
   前記１以上のリクエストそれぞれについて、前記リクエスト受諾情報を参照して、当該リクエストが示すリクエスト出力対象ユーザの前記受諾回数及び／又は前記変更量が小さいユーザほど値が大きくなる優先度を算出し、
   前記算出した優先度に基づいて、前記出力対象のリクエストを選択する、運行管理装置。
7. 請求項１に記載の運行管理装置であって、
   前記プロセッサは、
   前記出力したリクエストに対するユーザの諾否に基づいて、当該ユーザに対して付与するポイントを算出し、
   前記算出したポイントと、当該ユーザを示す情報と、を紐づけて、前記メモリに格納する、運行管理装置。
8. 請求項７に記載の運行管理装置であって、
   前記プロセッサは、前記出力したリクエストを受諾したユーザに対して、前記リクエスト出力対象ユーザの乗車希望時刻、降車希望時刻、乗車希望位置、及び降車希望位置の少なくとも１つの変更量に基づく第１のポイントを算出する、運行管理装置。
9. 請求項７に記載の運行管理装置であって、
   前記プロセッサは、前記出力したリクエストを受諾しなかったユーザに対して、第２のポイントを算出し、
   当該ユーザの予約を断ったことを示す情報を出力する、運行管理装置。
10. 請求項１に記載の運行管理装置であって、
    前記プロセッサは、前記複数のユーザそれぞれに対して、前記許容時間と、前記乗車許容範囲と、前記降車許容範囲と、に基づくポイントを算出し、
    前記算出したポイントと、当該ユーザを示す情報と、を紐づけて、前記メモリに格納する、運行管理装置。
11. 請求項１に記載の運行管理装置であって、
    表示装置に接続され、
    前記プロセッサは、前記出力したリクエストにおける前記リクエスト出力対象ユーザの変更後の、乗車希望時刻、降車希望時刻、乗車希望位置、及び降車希望位置を示す情報を、前記表示装置に表示する、運行管理装置。
12. 請求項１に記載の運行管理装置であって、
    複数の前記車両の運行を管理し、
    前記複数の車両は、それぞれ異なるエリアに予め対応づけられ、
    前記プロセッサは、
    前記複数のユーザの前記乗車許容範囲及び前記降車許容範囲と、前記複数の車両それぞれに対応づけられたエリアと、に基づいて、前記複数のユーザそれぞれを前記複数の車両に含まれるいずれかの車両と対応づけ、
    前記車両それぞれについて、前記判定を実行し、
    前記運行スケジュールを生成できない車両があると判定した場合、
    前記運行スケジュールを生成できない車両と異なる車両に対応付けられたユーザの前記許容時間、前記乗車許容範囲、及び前記降車許容範囲に基づいて、当該異なる車両が前記運行スケジュールを生成できない車両に対応付けられた一部のユーザを乗車させるヘルプによって、前記複数のユーザの全員の前記許容時間を満たす運行スケジュールを生成できるかを判定し、
    前記ヘルプによって、前記複数のユーザの全員の前記許容時間を満たす運行スケジュールを生成できないと判定した場合、前記１以上のリクエストを生成する、運行管理装置。
13. 請求項１に記載の運行管理装置であって、
    複数の前記車両の運行を管理し、
    前記プロセッサは、
    前記複数のユーザの前記乗車許容範囲及び前記降車許容範囲に基づいて、前記複数のユーザそれぞれを前記複数の車両に含まれるいずれかの車両と対応づけ、
    前記車両それぞれについて、前記判定を実行し、
    前記運行スケジュールを生成できない車両があると判定した場合、前記１以上のリクエストを生成する、運行管理装置。
14. 複数のユーザが乗車可能な車両の運行を管理する運行管理装置による運行管理方法であって、
    前記運行管理装置は、プロセッサとメモリとを有し、
    前記メモリは、前記複数のユーザそれぞれの、前記車両への乗車希望時刻又は前記車両からの降車希望時刻を含む許容時間と、前記車両への乗車希望位置を含む乗車許容範囲と、前記車両からの降車希望位置を示す降車許容範囲と、を示す予約情報を保持し、
    前記運行管理方法は、
    前記プロセッサが、前記複数のユーザの全員の前記許容時間を満たす、前記車両の運行スケジュールを生成できるかの判定を実行し、
    前記プロセッサが、前記運行スケジュールを生成できないと判定した場合、
    前記プロセッサが、前記複数のユーザに含まれるリクエスト出力対象ユーザを示し前記リクエスト出力対象ユーザの乗車希望時刻、降車希望時刻、乗車希望位置、及び降車希望位置の少なくとも１つを変更するリクエストであって、前記運行スケジュールにおいて前記許容時間が満たされなかったユーザの当該許容時間を満たすような運行スケジュールが生成可能となる１以上のリクエスト、を生成し、
    前記プロセッサが、前記１以上のリクエストが示す前記リクエスト出力対象ユーザの、前記許容時間、前記乗車許容範囲、及び前記降車許容範囲の少なくとも１つに基づいて、前記１以上のリクエストから出力対象のリクエストを選択して出力し、
    前記プロセッサが、前記出力したリクエストに対する諾否に基づいて、運行スケジュールを再生成する、運行管理方法。

Images