特開 2023-131019 運行管理システム、方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023131019

(43)【公開日】2023-09-21

(54)【発明の名称】運行管理システム、方法、およびプログラム

(51)【国際特許分類】

   G06Q 50/30 20120101AFI20230913BHJP

【ＦＩ】

G06Q50/30

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2022035662

(22)【出願日】2022-03-08

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000279

【氏名又は名称】弁理士法人ウィルフォート国際特許事務所

(72)【発明者】

【氏名】パティール プラティク

(72)【発明者】

【氏名】櫻井 壮希

(72)【発明者】

【氏名】ラジト アンジャリ

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049CC42

(57)【要約】

【課題】輸送事業者の収益の確保とユーザの利便性との両立を可能にする技術を提供する。
【解決手段】複数のユーザが利用料金を支払ってデマンドレスポンシブに共同で利用可能な乗物の運行を管理する運行管理システムは、ユーザから乗物の利用を希望する指定時間幅を指定したリクエストを受け付ける受付部と、複数のリクエストが指定時間幅を重複させて構成されたクラスタを特定し、該クラスタに対して前記乗物を運行させることで前記利用料金によって見込まれる収益を算出する状態算出部と、前記収益が所定の収益しきい値以上である場合に、前記クラスタに対して前記乗物を運行することを決定する運行決定部と、を有する。
【選択図】図３

【特許請求の範囲】

【請求項1】

複数のユーザが利用料金を支払ってデマンドレスポンシブに共同で利用可能な乗物の運行を管理する運行管理システムであって、
ユーザから乗物の利用を希望する指定時間幅を指定したリクエストを受け付ける受付部と、
複数のリクエストが指定時間幅を重複させて構成されたクラスタを特定し、該クラスタに対して前記乗物を運行させることで前記利用料金によって見込まれる収益を算出する状態算出部と、
前記収益が所定の収益しきい値以上である場合に、前記クラスタに対して前記乗物を運行することを決定する運行決定部と、
を有する運行管理システム。

【請求項2】

前記収益が前記収益しきい値に達しないクラスタに含まれるユーザに対して、前記収益が前記収益しきい値以上であるクラスタに入るようにリクエストを変更することを提案するレコメンドを提示するガイド部を更に有し、
前記運行決定部は、前記ユーザが前記レコメンドを受け入れて指定時間幅を変更し前記収益が前記収益しきい値以上になったら、前記クラスタに対して前記乗物を運行することを決定する、
請求項１に記載の運行管理システム。

【請求項3】

前記利用料金の必要最低限の金額として基本価格が予め設定されており、
前記受付部は、前記リクエストにおいて前記基本価格と同額または前記基本価格よりも高い金額の支払い提示金額を受け付け、
前記状態算出部は、前記クラスタにおける前記収益を該クラスタに含まれるリクエストにおける支払い提示金額に基づいて算出し、
前記運行決定部は、前記収益が前記収益しきい値に達しておらず前記基本価格よりも高い支払い提示金額を提示したユーザが存在するクラスタの利用料金を前記基本価格から値引きすることを、前記乗物を利用しようとするユーザに対して提示する、
請求項２に記載の運行管理システム。

【請求項4】

前記受付部は、乗車を希望する時刻である乗車希望時刻と該乗車希望時刻の変更を許容できる時間幅である乗車時刻マージンとを前記ユーザに指定させることによって、前記指定時間幅の指定を受け付ける、
請求項１に記載の運行管理システム。

【請求項5】

複数のユーザが利用料金を支払ってデマンドレスポンシブに共同で利用可能な乗物の運行を管理するための運行管理方法であって、
ユーザから乗物の利用を希望する指定時間幅を指定したリクエストを受け付け、
複数のリクエストが指定時間幅を重複させて構成されたクラスタを特定し、該クラスタに対して前記乗物を運行させることで前記利用料金によって見込まれる収益を算出し、
前記収益が所定の収益しきい値以上である場合に、前記クラスタに対して前記乗物を運行することを決定する、
ことをコンピュータが実行する運行管理方法。

【請求項6】

前記収益が前記収益しきい値に達しないクラスタに含まれるユーザに対して、前記収益が前記収益しきい値以上であるクラスタに入るようにリクエストを変更することを提案するレコメンドを提示し、
前記ユーザが前記レコメンドを受け入れて指定時間幅を変更し前記収益が前記収益しきい値以上になったら、前記クラスタに対して前記乗物を運行することを決定する、
ことをコンピュータが実行する、
請求項５に記載の運行管理方法。

【請求項7】

前記利用料金の必要最低限の金額として基本価格が予め設定されており、
前記リクエストにおいて前記基本価格と同額または前記基本価格よりも高い金額の支払い提示金額を受け付け、
前記クラスタにおける前記収益を該クラスタに含まれるリクエストにおける支払い提示金額に基づいて算出し、
前記収益が前記収益しきい値に達しておらず前記基本価格よりも高い支払い提示金額を提示したユーザが存在するクラスタの利用料金を前記基本価格から値引きすることを、前記乗物を利用しようとするユーザに対して提示する、
ことをコンピュータが実行する、
請求項６に記載の運行管理方法。

【請求項8】

複数のユーザが利用料金を支払ってデマンドレスポンシブに共同で利用可能な乗物の運行を管理するための運行管理プログラムであって、
ユーザから乗物の利用を希望する指定時間幅を指定したリクエストを受け付け、
複数のリクエストが指定時間幅を重複させて構成されたクラスタを特定し、該クラスタに対して前記乗物を運行させることで前記利用料金によって見込まれる収益を算出し、
前記収益が所定の収益しきい値以上である場合に、前記クラスタに対して前記乗物を運行することを決定する、
ことをコンピュータに実行させる運行管理プログラム。

【請求項9】

前記収益が前記収益しきい値に達しないクラスタに含まれるユーザに対して、前記収益が前記収益しきい値以上であるクラスタに入るようにリクエストを変更することを提案するレコメンドを提示し、
前記ユーザが前記レコメンドを受け入れて指定時間幅を変更し前記収益が前記収益しきい値以上になったら、前記クラスタに対して前記乗物を運行することを決定する、
ことをコンピュータに実行させる、
請求項８に記載の運行管理プログラム。

【請求項10】

前記利用料金の必要最低限の金額として基本価格が予め設定されており、
前記リクエストにおいて前記基本価格と同額または前記基本価格よりも高い金額の支払い提示金額を受け付け、
前記クラスタにおける前記収益を該クラスタに含まれるリクエストにおける支払い提示金額に基づいて算出し、
前記収益が前記収益しきい値に達しておらず前記基本価格よりも高い支払い提示金額を提示したユーザが存在するクラスタの利用料金を前記基本価格から値引きすることを、前記乗物を利用しようとするユーザに対して提示する、
ことをコンピュータに実行させる、
請求項９に記載の運行管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、オンデマンドで運行するモビリティサービスを実現する技術に関する。

【背景技術】

【0002】

Ｍｏｂｉｌｉｔｙ－ａｓ－ａ－Ｓｅｒｖｉｃｅ（ＭａａＳ）は、Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ（ＩＴ）によって各種の移動手段を一元的に管理し、出発地から目的地までのユーザの移動に関する計画、予約、および支払いを実現するサービスである。ＭａａＳでは、クラウド等で実現された情報システムをスマートフォンから利用することにより、柔軟でリアルタイム性の高い移動手段の提供が可能となる。ＭａａＳで提供される移動手段には、タクシーやカーシェアリングなどの個人で利用する乗物だけでなく、鉄道やバスなど複数のユーザが共同利用する公共交通機関の乗物も含まれる。

【0003】

駅や都市部から遠隔にある地域や人口密度の低い農村地域では移動手段の利用者が少ないことが想定される。そのような遠隔地域や農村地域においては、オンデマンドで運行するバスに複数のユーザが相乗り可能なデマンドレスポンシブバスサービスが注目されている（特許文献１参照）。

【0004】

デマンドレスポンシブバスサービスには主に次の３つのタイプが考えられている。

【0005】

（１）固定ルートタイプ：バスの始発地点から終着地点までの運行ルートが固定されており、ユーザはその運行ルート上で自身の乗車地点と降車地点を指定する。

【0006】

（２）可変ルートタイプ：バスの始発地点と終着地点は固定されているが、その間の運行ルートはある程度まで変更が可能である。ユーザは運行ルートの可変範囲内で乗車地点および降車地点を指定できる。

【0007】

（３）フリールートタイプ：ユーザからの要求に応じて、出発地点および終着地点を含めてバスの運行ルートが柔軟に設定される。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２０１７－１８２１３７号公報

【発明の概要】

【発明が解決しようとする課題】

【0009】

特許文献１のデマンド型運行システムは、バスなどの公共交通機関を提供する輸送事業者の負担を増大させずにユーザの利便性を向上させようというものである。しかしながら、特許文献１のデマンド型運行システムには、輸送事業者の収益性の観点がなく、必ずしも輸送事業者の収益を確保できるものとは言えなかった。

【0010】

本開示に含まれるひとつの目的は、輸送事業者の収益の確保とユーザの利便性との両立を可能にする技術を提供することである。

【課題を解決するための手段】

【0011】

本開示に含まれるひとつの態様による運行管理システムは、複数のユーザが利用料金を支払ってデマンドレスポンシブに共同で利用可能な乗物の運行を管理する運行管理システムであって、ユーザから乗物の利用を希望する指定時間幅を指定したリクエストを受け付ける受付部と、複数のリクエストが指定時間幅を重複させて構成されたクラスタを特定し、該クラスタに対して前記乗物を運行させることで前記利用料金によって見込まれる収益を算出する状態算出部と、前記収益が所定の収益しきい値以上である場合に、前記クラスタに対して前記乗物を運行することを決定する運行決定部と、

【0012】

を有する。

【発明の効果】

【0013】

本開示に含まれるひとつの態様によれば、輸送事業者の収益の確保とユーザの利便性との両立が可能となる。

【図面の簡単な説明】

【0014】

【図1】運行管理システムのブロック図である。

【図2】運行管理サーバの論理構成を示すブロック図である。

【図3】運行管理サーバのハードウェア構成を示すブロック図である。

【図4】ユーザ端末の論理構成を示すブロック図である。

【図5】運行管理システムの動作を示すフローチャートである。

【図6】輸送事業者ポータルサイトの画面の一例を示す図である。

【図7】ユーザ端末のアプリケーション画面を示す図である。

【図8】ユーザ端末の他のアプリケーション画面を示す図である。

【図9】ユーザ端末の更に他のアプリケーション画面を示す図である。

【図10】リクエストの状態を示すタイムチャートである。

【図11】モビリティサービスが利用される様子を説明するための概念図である。

【発明を実施するための形態】

【0015】

以下、本発明の実施形態について図面を参照して説明する。

【0016】

図１は、運行管理システムのブロック図である。運行管理システム１０は、ユーザが利用料金を支払ってデマンドレスポンシブに共同で利用可能な乗物であるバスの運行を提供するモビリティサービスを実現する情報システムである。本実施形態のモビリティサービスは、バスの始発地点から終着地点までの運行ルートが固定されており、ユーザはその運行ルート上で自身の希望する乗車地および降車地を指定する固定ルートタイプである。

【0017】

運行管理システム１０は、ユーザ端末３０１、運行管理サーバ４０１、および輸送事業者端末６０１を有している。

【0018】

ユーザ端末３０１は、各ユーザがモビリティサービスを利用するために用いる端末装置である。本実施形態では、ユーザ端末３０１は、ユーザ自身のスマートフォンにモビリティサービスに専用のアプリケーションをインストールしたものである。ユーザは、ユーザ端末３０１から、バスの運行を要求したり、他のユーザの要求やバス運行の予定等の状態を確認したりすることができる。

【0019】

運行管理サーバ４０１は、本モビリティサービスと統括し、ユーザからのリクエストに応じてバスの運行を決定するサーバ装置である。本実施形態の運行管理サーバ４０１はクラウド上に構築されるものであってもよい。運行管理サーバ４０１は、輸送事業者の収益の確保とユーザの利便性とを両立させるようにバスの運行を決定する。運行管理サーバ４０１が実行する処理の詳細は後述する。

【0020】

輸送事業者端末６０１は、本モビリティサービスにてバスを運行する輸送事業者が利用する端末装置である。輸送事業者は、輸送事業者端末６０１上で、運行管理サーバ４０１により提供されるポータルからモビリティサービスに必要な設定や操作等の作業を行う。また、輸送事業者は、運行管理サーバ４０１からバスの運行の依頼を輸送事業者端末６０１上で受け、その依頼に従って実際のバスを運行させる。

【0021】

図２は、運行管理サーバの論理構成を示すブロック図である。

【0022】

運行管理サーバ４０１は、受付部４０２、状態算出部４０３、および運行決定部４０４を有する。

【0023】

受付部４０２は、ユーザ端末３０１を介してユーザからバスの利用を希望するリクエストを受け付ける。リクエストでは、ユーザが希望する乗車地および降車地に加え、乗車時刻が幅を持った時間で指定される。この時間を指定時間幅と称することにする。状態算出部４０３は、複数のユーザからのリクエストが指定時間幅を重複させて構成されたクラスタを特定し、そのクラスタに対してバスを運行させることで、ユーザが支払う利用料金によって輸送事業者に見込まれる収益を算出する。運行決定部４０４は、その収益が所定の収益しきい値以上であれば、輸送事業者の収益性が確保されると判断し、そのクラスタに対してバスを運行することを決定する。これにより、ユーザへのデマンドレスポンシブなモビリティサービスにおいて輸送事業者の収益の確保とユーザの利便性との両立が可能になる。

【0024】

図３は、運行管理サーバのハードウェア構成を示すブロック図である。本実施形態の運行管理サーバ４０１は、インターネット等の通信ネットワーク経由でパーソナルコンピュータやスマートホン等から接続可能なサーバ装置である。

【0025】

運行管理サーバ４０１は、ハードウェアとして、プロセッサ４１１、メインメモリ４１２、記憶装置４１３、通信装置４１４、入力装置４１５、および表示装置４１６を有し、それらがバス４１７に接続されている。

【0026】

記憶装置４１３は、書込みおよび読み出しが可能にデータを記憶する装置である。記憶装置４１３には、ソフトウェアプログラムおよびそのソフトウェアプログラムの処理に利用されるデータが格納される。プロセッサ４１１は、記憶装置４１３に記憶されたソフトウェアプログラムをメインメモリ４１２に読み出し、メインメモリ４１２を利用してソフトウェアプログラムの処理を実行する。プロセッサ４１１がソフトウェアプログラムを実行することにより、図２に示した受付部４０２、状態算出部４０３、および運行決定部４０４が実現される。通信装置４１４は、プロセッサ４１１にて処理された情報を有線または無線あるいはそれら両方を含む通信ネットワークを介して送信し、また通信ネットワークを介して受信した情報をプロセッサ４１１に伝達する。受信した情報はプロセッサ４１１にて処理に利用される。入力装置４１５は、キーボードやマウスなど操作者による操作入力による情報を受け付ける装置であり、入力された情報はプロセッサ４１１にて処理に利用される。表示装置４１６は、プロセッサ４１１による処理に伴って画像やテキストの情報をディスプレイ画面に表示する装置である。運行管理サーバ４０１がクラウド上のコンピュータである場合、プロセッサ４１１、メインメモリ４１２、記憶装置４１３、通信装置４１４はクラウド上にあり、入力装置４１５および表示装置４１６は外部にあってクラウド上のコンピュータに接続するものであってもよい。

【0027】

図４は、ユーザ端末の論理構成を示すブロック図である。

【0028】

ユーザ端末３０１は、アクション部３０２およびガイド部３０３を有している。アクション部３０２は、ユーザに、リクエストの各情報を入力し、そのリクエストを運行管理サーバ４０１に送信するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を提供する。ガイド部３０３は、ユーザに、輸送事業者の収益性が確保されないためにリクエストに設定された指定時間幅にバスが運行されない場合に指定時間幅の変更を提案するレコメンドを提示するＧＵＩを提供する。

【0029】

図５は、運行管理システムの動作を示すフローチャートである。

【0030】

ステップＳ１０１にて、輸送事業者は、輸送事業者端末６０１から、運行管理サーバ４０１により提供される輸送事業者ポータルサイトにアクセスし、各種パラメータを設定する。

【0031】

図６は、輸送事業者ポータルサイトの画面の一例を示す図である。

【0032】

画面６１１には、始発地点＆終着地点アップロードボタン６１２、時間枠＆受付終了時刻設定ボタン６１３、収益しきい値設定ボタン６１４、値引き割合設定ボタン６１５、および運行計画受信ボタン６１６が配置されている。

【0033】

始発地点＆終着地点アップロードボタン６１２は、輸送事業者が運行するバスの始発地点と終着地点を登録するサブ画面に移行するボタンである。サブ画面で設定された始発地点および終着地点の情報はパラメータとして運行管理サーバ４０１のデータベース（不図示）に格納される。

【0034】

時間枠＆受付終了時刻設定ボタン６１３は、ユーザからのリクエストを集計する時間単位となる時間枠と、その時間枠に対するリクエストの受け付けを終了する時刻（受付終了時刻）とを設定するためのサブ画面に移行するボタンである。サブ画面で設定された時間枠および受付終了時刻の情報はパラメータとして運行管理サーバ４０１のデータベース（不図示）に格納される。

【0035】

収益しきい値設定ボタン６１４は、バスを運行することによりどれだけの収益が見こまれる場合にバスを運行することにするかを判定するためのしきい値（収益しきい値）を設定するためのサブ画面に移行するボタンである。サブ画面で設定された収益しきい値の情報はパラメータとして運行管理サーバ４０１のデータベース（不図示）に格納される。

【0036】

値引き割合設定ボタン６１５は、バスの利用を希望するユーザが表明した金額と基本価格との差額に対する、それにより他のユーザに提示する値引き金額の割合（値引き割合）を設定するためのサブ画面に移行するボタンである。サブ画面で設定された値引き割合の情報はパラメータとして運行管理サーバ４０１のデータベース（不図示）に格納される。

【0037】

運行計画受信ボタン６１６は、輸送事業者が運行管理サーバ４０１からバス運行計画を手動で取得するためのボタンである。このボタンを押下することにより、運行管理サーバ４０１から輸送事業者端末６０１にバス運行計画がダウンロードされ、画面に表示される。

【0038】

図５に戻り、ステップＳ３０１にて、ユーザ端末３０１は、アクション部３０２により、ユーザによる入力されたバスの運行を要求するための情報を取得する。

【0039】

図７は、ユーザ端末のアプリケーション画面を示す図である。画面１０１は、ユーザが希望するバスの乗車地と降車地とを選択するための画面である。画面１０１には複数の選択ボタン１０２が配置されている。選択ボタン１０２は乗車地と降車地の組み合わせ毎に設けられている。

【0040】

図８は、ユーザ端末の他のアプリケーション画面を示す図である。画面１０３は、バスの利用を希望する時間枠を選択するための画面である。

【0041】

画面１０３には複数の選択ボタン１０４が配置されている。選択ボタン１０４は時間枠毎に設けられている。各時間枠には、その時間枠の開始時刻および終了時刻１０５と、受付終了時刻１０６とが予め定められている。

【0042】

ユーザが、図７の画面１０１から乗車地点および降車地点を選択し、図８の画面１０３から時間枠を選択すると、ユーザ端末３０１のアプリケーションは、リクエストを生成するための画面を表示し、ユーザに情報の入力を促す。

【0043】

図９は、ユーザ端末の更に他のアプリケーション画面を示す図である。画面１０７は、ユーザがリクエストの各種情報を入力するための画面である。画面１０７には、状態表示領域１０８、ガイド表示領域１０９、アクション表示領域１１０の３つの領域が配置されている。

【0044】

状態表示領域１０８には、対象の時間枠の受付終了時刻までの残り時間と、ユーザが選択した乗車地および降車地とが含まれている。状態表示領域１０８には、更に、当該時間枠に対するリクエストの状態を示すタイムチャートが含まれている。このタイムチャートには、運行管理サーバ４０１がリクエストを集計することにより算出したリクエストの状態が表示される。

【0045】

アクション表示領域１１０には、ユーザがリクエストを送るための情報入力が可能な画面が示されている。アクション表示領域３０４には、初期状態では、当該ユーザｋが以前に送信したリクエストで選択したことのある乗車希望時刻ｔｋ、乗車時刻マージンｍｋ、および支払い提示金額Ｐｋが表示されている。

【0046】

乗車希望時刻ｔｋは、ユーザｋがバスの乗車を希望する時間幅すなわち指定時間幅の開始時刻である。乗車時刻マージンｍｋは、ユーザｋが希望する指定時間幅の幅である。支払い提示金額Ｐｋは、ユーザｋがバスの利用料として支払うことを提示する金額である。バスの利用料金には必要最低限の金額として基本価格が設定されている。支払い提示金額Ｐｋは、Ｐｋ≧Ｐ０の範囲内で設定することができる。いずれかのユーザが基本価格Ｐ０よりも高い支払い提示金額Ｐｋを提示した場合、その差額は、当該時間枠を利用する他のユーザに対する利用価格の値引に充てられる。

【0047】

ユーザｋは、初期状態で表示された以前と同じ乗車希望時刻ｔｋ、乗車時刻マージンｍｋ、および支払い提示金額Ｐｋでリクエストを送信することもできるし、それらの数値を変更してリクエストを送信することもできる。

【0048】

ユーザｋがユーザ端末３０１のモバイルアプリケーションの画面１０１、１０３上でユーザが乗車地および降車地と時間枠を選択し、画面１０７上で乗車希望時刻、乗車時刻マージン、および支払い提示金額を入力してリクエストを送信する操作を行うと、ユーザ端末３０１は、アクション部３０２により、ステップＳ３０２にて、リクエストを運行管理サーバ４０１に送信する。

【0049】

運行管理サーバ４０１は、ステップＳ２０１にてリクエストを受信すると、ステップＳ２０２にてそのリクエストを処理するバッチ処理を開始する。

【0050】

運行管理サーバ４０１は、バッチ処理ステージであるステップＳ２０３にて、複数のユーザからのリクエストを集計し、リクエストの指定時間幅の重複を確認し、指定時間幅が重複している箇所をリクエストのクラスタとして特定する。

【0051】

更に、運行管理サーバ４０１は、ステップＳ２０４にて、各クラスタにおけるリクエストの指定時間幅の重複の度合いに基づく潜在的な収益を算出し、その収益の値と収益しきい値とを比較することにより、当該クラスタにおける輸送事業者の所定の収益が確保されるか否か判断する。

【0052】

このとき、運行管理サーバ４０１は、特定された各クラスタについてそのクラスタに含まれるリクエストを送信した各ユーザの支払い提示金額を集計する。クラスタに含まれるユーザの支払い提示金額が基本価格Ｐ０に等しければ、そのクラスタに参加してバスを利用するために支払うことが必要な最低限の金額は基本価格のまま変更されない。一方、クラスタ内の一部のユーザが基本価格よりも高い支払い提示金額を提示している場合、その支払い提示金額が基本価格を超過した分を使用することにより、そのクラスタに参加してバスを利用するために支払うことが必要な最低限の金額が引き下げられる。例えば、輸送事業者の収益が所定の収益しきい値に達していないクラスタに含まれるユーザが、自身の支払い提示金額を高く設定することにより、そのクラスタに他のユーザを勧誘するすることができる。上述したように、支払い提示金額が基本価格を超過した追加支払い金額に対する、他のユーザに対する値引金額の割合はパラメータとして予め設定されている。

【0053】

図１０は、リクエストの状態を示すタイムチャートである。タイムチャート２０１には、時刻Ｔ１から時刻Ｔ２までの時間枠に対して各ユーザから受信したリクエストが示されている。各ユーザからのリクエストが指定時間幅にわたる矩形で示され、リクエストのクラスタがハッチング付き矩形で示されている。所定の収益が確保される見込みのクラスタが右下がりハッチングで示され、所定の収益が確保されるクラスタが右上がりハッチングで示されている。ここでは一例として、支払い提示金額として基本価格を提示した3人のユーザのリクエストが重複するクラスタは収益性が確保される見込みとなっている。

【0054】

図5に戻り、運行管理サーバ４０１は、ステップＳ２０５にて、当該時間枠の受付終了時刻Ｄに達しているか否か判定する。受付終了時刻Ｄに達していなければ、運行管理サーバ４０１は、ステップＳ２０６にて、最新のクラスタの状態を保存するとともに、その状態の情報をユーザ端末３０１に通知する。通知を受けたユーザ端末３０１は、アクション部３０２により、最新のクラスタの状態を取得し、その状態を画面１０７における状態表示領域１０８の表示に反映させる。

【0055】

状態表示領域１０８のタイムチャートには、運行管理サーバ４０１により、モビリティサービス事業者に提示される表示と同等の表示である。ユーザからのリクエストはあるが輸送事業者の収益性が確保されていない時間幅は、タイムチャート上の右上がりのハッチングが施されている時間幅として示されている。そのような時間幅に対するリクエストにおいて基本価格を超える支払い提示金額を設定したユーザがいる場合、支払い提示金額と基本価格との差額つまり追加支払い金額に応じた値引を行った価格（値引後価格）を示す吹き出しメッセージが表示される。この値引きは、輸送事業者の所定の収益性が確保されていない時間幅へ他のユーザのリクエストを誘引するインセンティブとなる。

【0056】

更に、ユーザ端末３０１では、ガイド部３０３が、適宜、ガイド表示領域１０９にユーザへの提案を示したガイドのメッセージを表示する。

【0057】

図９に例示したガイド表示領域１０９のメッセージは、現在、当該ユーザｋのリクエストは輸送事業者の収益性を満たすクラスタに入っていないが、乗車時刻マージンをｍ´だけ増大させれば、輸送事業者の収益性を満たすクラスタに入ることができることを通知している。

【0058】

図５に戻り、ステップＳ３０３にて、ユーザ端末３０１では、アクション部３０２が定期的に受付終了時刻に達しているか否か確認する。受付終了時刻に達していれば、ステップＳ３０４にて、ユーザ端末３０１は、アクション部３０２により、当該ユーザのリクエストを含むクラスタにおいて輸送事業者の収益が所定の収益しきい値に達しているか否か、すなわち当該クラスタに対してバスを運行させることが可能であるか否か判定する。

【0059】

当該ユーザのリクエストを含むクラスタにおいて輸送事業者の収益が所定の収益しきい値に達している場合には、ユーザ端末３０１にて、アクション部３０２は、ステップＳ３０５にて、当該ユーザのバスの予約を確定するようにユーザに促し、ユーザが確定の操作を行うと、予約を確定させる。

【0060】

ステップＳ３０４にて、当該ユーザのリクエストを含むクラスタにおいて輸送事業者の収益が所定の収益しきい値に達していない場合、アクション部３０２は、当該ユーザに対して、輸送事業者の収益が所定の収益しきい値に達しているクラスタへ参加することを提案する。ユーザがその提案を受け入れて、あるクラスタへの変更を希望した場合、アクション部３０２は、そのクラスタに対して運行されるバスを利用するように変更されたリクエストを運行管理サーバ４０１へ送信する。

【0061】

運行管理サーバ４０１は、ステップＳ２０５にて、受付終了期限に達した後、ユーザ端末３０１から変更されたリクエストを受信すると、ステップＳ２０７にて、そのリクエストに従って当該ユーザを所望のクラスタに追加で登録する。このとき、クラスタの時間幅および価格には変化は生じない。運行管理サーバ４０１は、更に、輸送事業者端末６０１に対して、輸送事業者の収益性が確保されたクラスタの時間幅内にバスの運行を設定するように依頼する。

【0062】

図１１は、モビリティサービスが利用される様子を説明するための概念図である。図１１に示すような遠隔地域あるいは農村地域５０５と駅付近の商業地域５０４との間にデマンドレスポンシブなバスを運行するモビリティサービスが提供されている。本例では、１５：００から１８：００までの時間枠があり、その時間枠に対する受付終了時刻が１４：３０であるものとする。また、複数のユーザ５０１、５０２、５０３が、同じ遠隔または農村の地域５０５から同じ駅付近の商業地域５０４に移動するというシナリオを想定する。ユーザ５０１、５０２、５０３はある程度の時間的な余裕をもって移動を行うものとする。３人のユーザ５０１、５０２、５０３の全員が同じ上記時間枠に移動できるものとする。

【0063】

図１１の例では、ユーザ５０１は、乗車希望時刻であり１６：１５であり、乗車時刻マージンが３０分であるリクエストを送っている。ユーザ５０２は、乗車希望時刻であり１６：０５であり、乗車時刻マージンが１５分であるリクエストを送っている。ユーザ５０３は、乗車希望時刻であり１６：１５であり、乗車時刻マージンが１０分であるリクエストを送っている。そして、全てのユーザ５０１、５０２、５０３が支払い提示金額として基本価格を提示したものとする。

【0064】

この例では、１６：１５から１６：２０の時間幅に３人のリクエストを含むクラスタが構成される。３人の支払い提示金額の合計額により、輸送事業者の収益は所定の収益しきい値を超えるものとする。したがって、３人のユーザ５０１、５０２、５０３は、１台のバスを共同で利用して商業地域５０４に移動することができる。もし、本実施形態の運行管理システム１０によるサービスが提供されていなければ、ユーザ５０１、５０２、５０３は個々に料金を支払ってタクシーやシェアカーで移動することになったかもしれない。

【0065】

上述した実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の範囲を逸脱することなしに、他の様々な態様で本発明を実施することができる。

【0066】

上述した実施形態には以下に示す事項が含まれている。ただし、本実施形態に含まれる事項が以下に示すもののみに限定されることはない。

【0067】

（事項１）
複数のユーザが利用料金を支払ってデマンドレスポンシブに共同で利用可能な乗物の運行を管理する運行管理システムは、ユーザから乗物の利用を希望する指定時間幅を指定したリクエストを受け付ける受付部と、複数のリクエストが指定時間幅を重複させて構成されたクラスタを特定し、該クラスタに対して前記乗物を運行させることで前記利用料金によって見込まれる収益を算出する状態算出部と、前記収益が所定の収益しきい値以上である場合に、前記クラスタに対して前記乗物を運行することを決定する運行決定部と、を有する。
これによれば、ユーザへのデマンドレスポンシブな移動手段の提供において輸送事業者の収益の確保とユーザの利便性との両立が可能になる。

【0068】

(事項２)
事項１に記載の運行管理システムは、前記収益が前記収益しきい値に達しないクラスタに含まれるユーザに対して、前記収益が前記収益しきい値以上であるクラスタに入るようにリクエストを変更することを提案するレコメンドを提示するガイド部を更に有し、前記運行決定部は、前記ユーザが前記レコメンドを受け入れて指定時間幅を変更し前記収益が前記収益しきい値以上になったら、前記クラスタに対して前記乗物を運行することを決定する。
これによれば、ユーザの当初のリクエストによって輸送事業者の収益性が確保されない場合でも収益性が確保されるような指定時間幅の変更をユーザに提案するので、輸送事業者の収益の確保とユーザの利便性とをより高めることができる。

【0069】

（事項３）
事項２に記載の運行管理システムは、前記利用料金の必要最低限の金額として基本価格が予め設定されており、前記受付部は、前記リクエストにおいて前記基本価格と同額または前記基本価格よりも高い金額の支払い提示金額を受け付け、前記状態算出部は、前記クラスタにおける前記収益を該クラスタに含まれるリクエストにおける支払い提示金額に基づいて算出し、前記運行決定部は、前記収益が前記収益しきい値に達しておらず前記基本価格よりも高い支払い提示金額を提示したユーザが存在するクラスタの利用料金を前記基本価格から値引きすることを、前記乗物を利用しようとするユーザに対して提示する。
これによれば、ユーザの当初のリクエストによって輸送事業者の収益性が確保されそうもない場合に、追加の料金を支払って他のユーザを勧誘する手段をユーザに与えることにより、輸送事業者の収益の確保とユーザの利便性とをより高めることができる。

【0070】

（事項４）
事項１に記載の運行管理システムにおいて、前記受付部は、乗車を希望する時刻である乗車希望時刻と該乗車希望時刻の変更を許容できる時間幅である乗車時刻マージンとを前記ユーザに指定させることによって、前記指定時間幅の指定を受け付ける。
これによれば、希望時刻とその変更を許容できる時間とを指定させることによりユーザに直感的に指定時間幅を指定させることができる。

【符号の説明】

【0071】

１０…運行管理システム、１０１…画面、１０２…選択ボタン、１０３…画面、１０４…選択ボタン、１０５…終了時刻、１０６…受付終了時刻、１０７…画面、１０８…状態表示領域、１０９…ガイド表示領域、１１０…アクション表示領域、３０１…ユーザ端末、３０２…アクション部、３０３…ガイド部、３０４…アクション表示領域、４０１…運行管理サーバ、４０２…受付部、４０３…状態算出部、４０４…運行決定部、４１１…プロセッサ、４１２…メインメモリ、４１３…記憶装置、４１４…通信装置、４１５…入力装置、４１６…表示装置、４１７…バス、５０１…ユーザ、５０２…ユーザ、５０３…ユーザ、５０４…商業地域、５０５…遠隔地域あるいは農村地域、６０１…輸送事業者端末、６１１…画面、６１２…始発地点＆終着地点アップロードボタン、６１３…時間枠＆受付終了時刻設定ボタン、６１４…値設定ボタン、６１５…割合設定ボタン、６１６…運行計画受信ボタン

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】