JP7131840B2 - プログラム及び情報処理装置 - Google Patents

Description

本発明は、プログラム及び情報処理装置に関する。

従来から、目的地が同じ方向である複数のユーザが同乗する相乗りタクシーが知られている。

これに関し、非特許文献１には、ユーザが乗車地や目的地等を入力することにより、同乗予定者を検索して、各ユーザが相乗りに同意すると、タクシーが順番に迎車する技術が開示されている。

JapanTaxi株式会社、"空間も、お金も、相乗り。相乗りタクシー"、［online］、平成３０年３月１１日、［令和２年２月２日検索］、インターネット＜URL：https://ainori.japantaxi.jp/＞

しかしながら、非特許文献１に記載の技術では、ユーザは定期的に相乗りタクシーを利用したい場合でも、その都度、乗車地や目的地等を入力して、同乗予定者を検索しなければならない。このため、例えば山間部で高齢化率の高い地域（過疎地域）において、定期的に病院等へ通院しているユーザには、乗車地や目的地等を毎回入力する負担がかかるだけでなく、同乗予定者を容易に検索することができず、金銭的な負担もかかるという問題がある。

また、交通機関（例えば、鉄道やバス等）を運行する事業者は、各ユーザによる支払金額（収入金額）を正確に予測することが難しいため、このような地域において新たな運行ダイヤを決定することに消極的であった。

本発明はこのような課題に鑑みてなされたものであり、その目的は、ユーザの移動需要に応じた採算性のある運行ダイヤを決定することができるプログラム及び情報処理装置を提供することにある。

上記課題を解決するために、本発明の第一態様に係るプログラムは、所定地域において交通機関の運行ダイヤを決定するためのプログラムであって、コンピュータを、複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける受付手段、前記支払金額に応じて、少なくとも乗降場所、運行日時を含む運行ダイヤを決定する決定手段、前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段、として機能させる。

また、本発明の第二態様では、前記決定手段は、前記移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる希望乗降場所を優先して前記運行ダイヤを決定する。

また、本発明の第三態様では、前記決定手段は、前記移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる利用日時を優先して前記運行ダイヤを決定する。

また、本発明の第四態様では、前記決定手段は、前記移動需要それぞれに含まれる支払金額の合計である収入金額が、前記移動需要を送信したユーザ数に対応する運行コストに達している場合、前記運行ダイヤを決定する。

また、本発明の第五態様では、前記通知手段は、前記収入金額が前記運行コストに達していない場合、前記移動需要を送信した各ユーザに、支払金額が不足していることを通知する。

また、本発明の第六態様では、前記受付手段は、前記移動需要を送信した各ユーザから、新たな支払金額の送信を受け付け、前記決定手段は、各ユーザから前記送信された新たな支払金額の合計である収入金額が前記運行コストに達している場合、前記運行ダイヤを決定する。

また、本発明の第七態様では、前記受付手段は、前記運行ダイヤで交通機関を利用している一のユーザから、利用を中止する要求を受け付け、前記通知手段は、前記一のユーザの支払金額を除いた前記収入金額が、前記一のユーザを除いた新たなユーザ数に対応する運行コストに達していない場合、前記運行ダイヤで交通機関を利用している他のユーザそれぞれに、支払金額が不足していることを通知する。

また、本発明の第八態様では、前記受付手段は、前記他のユーザそれぞれから、新たな支払金額の送信を受け付け、前記決定手段は、前記他のユーザそれぞれから前記送信された新たな支払金額の合計である収入金額が前記新たなユーザ数に対応する運行コストに達している場合、前記交通機関の運行を継続することを決定する。

また、本発明の第九態様では、前記決定手段は、前記一のユーザによる利用の中止に応じて、前記運行ダイヤに含まれる乗降場所又は運行日時を変更する。

また、本発明の第十態様に係る情報処理装置は、所定地域において交通機関の運行ダイヤを決定するための情報処理装置であって、複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける受付手段と、前記支払金額に応じて、少なくとも乗降場所、運行日時を含む運行ダイヤを決定する決定手段と、前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段と、を備える。

本発明によれば、ユーザの移動需要に応じた採算性のある運行ダイヤを決定することができる。

本発明の実施形態に係る運行ダイヤ決定システムの全体構成の一例を示すブロック図である。 図１に示すサーバ装置のハードウェア構成の一例を示すブロック図である。 図１に示すサーバ装置の機能的構成の一例を示すブロック図である。 本実施形態に係る運行ダイヤ決定システムにおいて、交通機関の運行を決定する処理の流れの一例を示すフローチャートである。 本実施形態に係る入力画面の一例を示す図である。 本実施形態に係る運行決定通知画面の一例を示す図である。 本実施形態に係る決定不可通知画面の一例を示す図である。 本実施形態に係る運行ダイヤ決定システムにおいて、交通機関の運行を継続するための処理の流れの一例を示すフローチャートである。 本実施形態に係る運行継続通知画面の一例を示す図である。 本実施形態に係る金額不足通知画面の一例を示す図である。

以下、添付図面を参照しながら本発明の実施形態（以下、「本実施形態」という。）について説明する。説明の理解を容易にするため、各図面において同一の構成要素及びステップに対しては可能な限り同一の符号を付して、重複する説明は省略する。

＜全体構成＞
図１は、本発明の実施形態に係る運行ダイヤ決定システム１の全体構成の一例を示すブロック図である。

図１に示すように、運行ダイヤ決定システム１は、サーバ装置１０と、複数の端末装置１２と、を備える。これらの装置は、インターネットや電話回線網等の通信ネットワークＮＴを介して互いに通信可能に構成されている。

サーバ装置１０は、運行ダイヤの決定に関する各種制御を行う装置（コンピュータ）である。このサーバ装置１０は、端末装置１２を介したユーザからの移動需要の送信に基づき、運行ダイヤを決定する。

端末装置１２は、ユーザが操作する装置である。これら端末装置１２は、例えば、第一端末装置１２Ａと、第二端末装置１２Ｂと、を含む。端末装置１２としては、携帯電話やスマートフォン、タブレット、パーソナルコンピュータ等が挙げられる。

第一端末装置１２Ａは、第一のユーザが操作する装置である。

第二端末装置１２Ｂは、第二のユーザが操作する装置である。

＜ハードウェア構成＞
図２は、図１に示すサーバ装置１０のハードウェア構成の一例を示すブロック図である。

図２に示すように、サーバ装置１０は、制御装置２０と、通信装置２６と、記憶装置２８と、を備える。制御装置２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２２及びメモリ２４を主に備えて構成される。

制御装置２０では、ＣＰＵ２２がメモリ２４或いは記憶装置２８等に格納された所定のプログラムを実行することにより、各種の機能手段として機能する。この機能手段の詳細については後述する。

通信装置２６は、外部の装置と通信するための通信インターフェース等で構成される。通信装置２６は、例えば、端末装置１２との間で各種の情報を送受信する。

記憶装置２８は、ハードディスク等で構成される。記憶装置２８は、制御装置２０における処理の実行に必要な各種プログラムや各種の情報、及び処理結果の情報を記憶する。

なお、サーバ装置１０は、専用又は汎用のサーバ・コンピュータなどの情報処理装置を用いて実現することができる。また、サーバ装置１０は、単一の情報処理装置より構成されるものであっても、通信ネットワークＮＴ上に分散した複数の情報処理装置より構成されるものであってもよい。また、図２は、サーバ装置１０が有する主要なハードウェア構成の一部を示しているに過ぎず、サーバ装置１０は、サーバが一般的に備える他の構成を備えることができる。また、複数の端末装置１２のハードウェア構成も、例えば操作手段や表示装置等を備える他は、サーバ装置１０と同様の構成を備えることができる。

＜機能的構成＞
図３は、図１に示すサーバ装置１０の機能的構成の一例を示すブロック図である。

図３に示すように、サーバ装置１０は、機能的構成として、記憶手段５０と、受付手段５２と、決定手段５４と、判定手段５６と、通知手段５８と、を備える。

記憶手段５０は、ユーザ情報５０Ａや、運行ダイヤ情報５０Ｂ等を記憶する機能手段である。

ユーザ情報５０Ａは、各ユーザの識別情報（ユーザＩＤ）に対応付けて、ユーザそれぞれのログインＩＤや、パスワード、ユーザ名、生年月日、性別、年齢、自宅住所、連絡先、移動需要等を含む。連絡先としては、電話番号や、メールアドレス、メッセージアプリケーションのユーザＩＤ等が挙げられる。移動需要は、少なくとも希望乗降場所、利用日時、支払金額を含む。この移動需要は、受付手段５２が各ユーザの端末装置１２から受け付けた情報である。希望乗降場所は、ユーザが希望する出発地と到着地を含む。この出発地は、例えばユーザの自宅に最も近い道路に面した地点である。この到着地は、例えばユーザの行き先（例えば病院、学校、スーパーマーケット等）である。利用日時は、ユーザが交通機関を利用する日時であって、利用日や、往路の到着時間、復路の出発時間を含む。例えば、利用日時には、利用日である曜日と、出発地である自宅から到着地である病院Ａへの到着時間と、到着地である病院Ａから出発地である自宅への出発時間とを含む。この到着時間と出発時間は、例えば１５分単位の時間帯で設定される。支払金額は、ユーザが交通機関の利用で支払うことが可能な（支払ってもよい）金額であって、例えば１ヶ月間における利用額（月額料金）である。

運行ダイヤ情報５０Ｂは、各運行ダイヤの識別情報（運行ダイヤＩＤ）に対応付けて、運行ダイヤそれぞれの地域、利用ユーザ、収入金額、乗降場所、運行日時、運行車両、運行コスト、決定フラグ等を含む。地域は、運行ダイヤが決定している地域又は未決定の地域を特定する情報（例えば町名や村名）を含む。利用ユーザは、運行ダイヤを利用する又は利用を希望する各ユーザの識別情報を含む。収入金額は、各利用ユーザの移動需要に含まれる支払金額の合計である。この収入金額は、利用ユーザが増減することや、支払金額が増減することに伴って変化する。乗降場所は、運行ダイヤにおける停留所の名称と位置情報（例えば緯度及び経度、住所）を含む。運行日時は、運行ダイヤにおける運行日と運行時間を含む。この運行日時は、各停留所の時刻表として記憶されていてもよい。運行車両は、運行ダイヤにおいて利用される一又は複数の車両の識別情報（車両ＩＤ）に対応付けて、車両価格、車両燃費、乗車定員、必要免許等を含む。乗車定員は、乗車するユーザの最大人数に応じて定まる。運行コストは、所定期間（例えば１ヶ月）における運行にかかる費用である。この費用は、決定手段５４によって、利用ユーザ数や移動距離、車両価格、車両燃費、車両維持費（例えば駐車場費や税金、メンテナンス費、保険料）、人件費（例えば運転手の給与）等に基づいて算出される。決定フラグは、運行ダイヤが決定しているか否かを示すフラグである。決定フラグには、「決定」と「未決定」の何れかが含まれ、初期値は「未定」である。

受付手段５２は、ユーザの端末装置１２から各種情報を受け付ける機能手段である。本実施形態では、受付手段５２は、複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける。

また、受付手段５２は、移動需要を送信した各ユーザから、新たな支払金額の送信を受け付ける。例えば、受付手段５２は、通知手段５８によって支払金額が不足していることが通知された各ユーザから、以前の支払金額から増額された新たな支払金額の送信を受け付ける。

また、受付手段５２は、決定手段５４によって決定された運行ダイヤで交通機関を利用している一のユーザから、利用を中止する要求を受け付ける。また、受付手段５２は、当該一のユーザを除いた当該交通機関を利用している他のユーザそれぞれから、新たな支払金額の送信を受け付ける。例えば、受付手段５２は、通知手段５８によって支払金額が不足していることが通知された当該他のユーザから、以前の支払金額から増額された新たな支払金額の送信を受け付ける。

決定手段５４は、所定地域において交通機関の（定期的な）運行ダイヤを決定する機能手段である。この所定地域としては、例えば過疎地域における町や村、集落が挙げられる。本実施形態では、決定手段５４は、受付手段５２が受け付けた各ユーザの移動需要に含まれる希望乗降場所や利用日時、支払金額に応じて、運行ダイヤを決定する。この運行ダイヤは、例えば利用ユーザ、収入金額、乗降場所、運行日時、運行車両、運行コスト等を含む。そして、決定手段５４は、決定した運行ダイヤを運行ダイヤ情報５０Ｂに記憶する。また、決定手段５４は、運行ダイヤを決定したことに応じて、運行ダイヤ情報５０Ｂの決定フラグを「決定」に更新する。

例えば、決定手段５４は、所定地域内の一又は複数の道路に面している地点を中心として５００ｍ四方に区画し、各ユーザの移動需要に含まれる２以上の希望乗降場所が、１つの区画に含まれる場合、各希望乗降場所からの距離が最も短い地点であって道路に面している地点を乗降場所（停留所）として運行ダイヤを決定する。また、例えば、決定手段５４は、受付手段５２が受け付けた移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる希望乗降場所を優先して運行ダイヤを決定する。具体的には、決定手段５４は、同じ区画内に希望乗降場所を設定（希望）した各ユーザの支払金額の平均値を算出する。続いて、決定手段５４は、或るユーザの支払金額が当該平均値を第一所定額（例えば２５００円）上回っている場合、当該或るユーザの移動需要に含まれる希望乗降場所の第一所定範囲内（例えば２００ｍ以内）に乗降場所を決定する。また、決定手段５４は、或るユーザの移動需要に含まれる支払金額が当該平均値を第二所定額（例えば５０００円）上回っている場合、当該或るユーザの移動需要に含まれる希望乗降場所の第二所定範囲内（例えば１５０ｍ以内）に乗降場所を決定する。

例えば、決定手段５４は、移動需要それぞれに同一の希望乗降場所が含まれる場合であって、当該移動需要それぞれに含まれる利用日時が、所定時間（１時間）以内であるとき、当該利用日時の平均値を運行日時として運行ダイヤを決定する。具体的には、決定手段５４は、２以上の移動需要それぞれに同一の希望降車場所（例えば病院Ａ）が含まれる場合であって、当該移動需要それぞれに含まれる利用日が同日であって、往路の到着時間が９時～１０時までの間であるとき、当該到着時間の平均値を運行日時（到着時間）として運行ダイヤを決定する。また、例えば、決定手段５４は、移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる利用日時を優先して運行ダイヤを決定する。具体的には、決定手段５４は、移動需要それぞれに同一の希望降車場所（例えば病院Ａ）が含まれる場合であって、当該移動需要それぞれに含まれる利用日が同日（同じ曜日）であり、到着時間が９時～１０時までの間であるとき、当該到着時間を設定した各ユーザの支払金額の平均値を算出する。続いて、決定手段５４は、或るユーザの移動需要に含まれる支払金額が当該平均値を第一所定額（例えば２５００円）上回っている場合、当該或るユーザの移動需要に含まれる到着時間の第一所定時間内（例えば３０分以内）に運行日時（病院Ａへの到着時間）を決定する。また、決定手段５４は、或るユーザの移動需要に含まれる支払金額が当該平均値を第二所定額（例えば５０００円）上回っている場合、当該或るユーザの移動需要に含まれる到着時間の第二所定時間内（例えば１５分以内）に運行日時（病院Ａへの到着日時）を決定する。

また、決定手段５４は、判定手段５６によって、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達していると判定された場合、運行ダイヤを決定する。一方、決定手段５４は、判定手段５６によって、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達していないと判定された場合、運行ダイヤを決定しない。

また、決定手段５４は、判定手段５６によって、各ユーザから送信された新たな支払金額の合計である収入金額が運行コストに達していると判定された場合、運行ダイヤを決定する。一方、決定手段５４は、判定手段５６によって、当該収入金額が運行コストに達していないと判定された場合、運行ダイヤを決定しない。

また、決定手段５４は、決定した運行ダイヤで交通機関を利用している一のユーザから、利用を中止する要求があった後、判定手段５６によって、当該交通機関を利用している他のユーザそれぞれから送信された新たな支払金額の合計である収入金額が新たなユーザ数（他のユーザの数）に対応する運行コストに達していると判定された場合、運行ダイヤ（運行）を継続することを決定する。一方、決定手段５４は、当該一のユーザから、利用を中止する要求があった後、判定手段５６によって、当該収入金額が新たなユーザ数に対応する運行コストに達していないと判定された場合、運行ダイヤ（運行）を継続しないことを決定する。

また、決定手段５４は、決定した運行ダイヤで交通機関を利用している一のユーザによる利用の中止に応じて、当該運行ダイヤに含まれる乗降場所又は運行日時を変更する。例えば、決定手段５４は、当該一のユーザによる移動需要を除外して、他のユーザによる移動需要に基づいて、乗降場所や運行日時を再度決定する。

判定手段５６は、各種判定を行う機能手段である。本実施形態では、判定手段５６は、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達しているか否かを判定する。また、判定手段５６は、各ユーザから送信された新たな支払金額の合計である収入金額が運行コストに達しているか否かを判定する。また、判定手段５６は、交通機関の利用を中止する要求を行った一のユーザを除く他のユーザそれぞれから送信された新たな支払金額の合計である収入金額が新たなユーザ数（他のユーザの数）に対応する運行コストに達しているか否かを判定する。

通知手段５８は、各ユーザの端末装置１２に通知を行う機能手段である。本実施形態では、通知手段５８は、決定手段５４によって決定された運行ダイヤを、移動需要を送信した各ユーザの端末装置１２に通知する。また、通知手段５８は、移動需要それぞれに含まれる支払金額の合計である収入金額が運行コストに達していない場合、移動需要を送信した各ユーザの端末装置１２に、支払金額が不足していることを通知する。

また、通知手段５８は、交通機関の利用を中止する要求を行った一のユーザの支払金額を除いた収入金額が、当該一のユーザを除いた新たなユーザ数に対応する運行コストに達していない場合、運行ダイヤで交通機関を利用している他のユーザそれぞれに、支払金額が不足していることを通知する。

＜運行決定に係る処理の流れ＞
図４は、本実施形態に係る運行ダイヤ決定システム１において、交通機関の運行を決定する処理の流れの一例を示すフローチャートである。また、以下のステップの処理は、例えば、ユーザが端末装置１２において移動需要を入力するための指示を行ったタイミングで開始される。なお、以下のステップの順番及び内容は、適宜、変更することができる。

（ステップＳＰ１０）
受付手段５２は、ユーザの端末装置１２に、移動需要を入力するための入力画面を送信する。

図５は、本実施形態に係る入力画面６０の一例を示す図である。

図５に示すように、入力画面６０は、希望乗降場所入力領域６２と、利用日時入力領域６４と、支払金額入力領域６６と、送信ボタン６８と、が設けられている。希望乗降場所入力領域６２には、希望する乗車場所である出発地と、希望する降車場所である到着地とを入力する入力欄が表されている。希望乗降場所入力領域６２では、ユーザによって出発地又は到着地の入力欄に郵便番号や住所、電話番号、マップコード等の情報が入力されることにより、当該情報に関する周辺地図を表示する画面に遷移し、ユーザは詳細な地点（位置）を設定することができる。利用日時入力領域６４には、ユーザが交通機関を利用する曜日である利用日と、往路の到着時間である希望到着時間と、復路の車場所である到着地を入力する入力欄が表されている。支払金額入力領域６６には、支払金額である月額料金を入力する入力欄が評されている。支払金額入力領域６６では、ユーザが希望乗降場所入力領域６２の出発地や到着地、利用日時入力領域６４に含まれる利用日が入力済である場合、移動距離や利用頻度に応じた参考金額を表してもよい。送信ボタン６８は、ユーザにより各入力欄に入力された移動需要（希望条件）をサーバ装置１０に送信するためのボタンである。

図４に戻って、処理は、ステップＳＰ１２の処理に移行する。

（ステップＳＰ１２）
入力画面６０において送信ボタン６８が押下されたことに応じて、受付手段５２は、ユーザの端末装置１２から移動需要の送信を受け付ける。そして、処理は、ステップＳＰ１４の処理に移行する。

（ステップＳＰ１４）
決定手段５４は、ユーザ情報５０Ａの移動需要において、ユーザの識別情報（ユーザＩＤ）に対応付けて、ステップＳＰ１２で受け付けた移動需要を追加する。また、決定手段５４は、運行ダイヤ情報５０Ｂの地域を参照して、当該移動需要に含まれる希望乗降場所を含む地域を検索する。続いて、決定手段５４は、検索した運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザに、ステップＳＰ１２で移動需要を送信したユーザの識別情報（ユーザＩＤ）を追加する。続いて、決定手段５４は、検索した運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する収入金額に、当該移動需要に含まれる支払金額を加算する。そして、処理は、ステップＳＰ１６の処理に移行する。

（ステップＳＰ１６）
決定手段５４は、ユーザ情報５０Ａと運行ダイヤ情報５０Ｂを参照して、ステップＳＰ１４において検索した運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザそれぞれの移動需要を取得する。続いて、決定手段５４は、運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザの数（ユーザ数）と利用ユーザそれぞれの利用日時に基づいて車両と車両数を特定し、乗降場所や運行日時を含む運行ダイヤを仮決定する。続いて、決定手段５４は、仮決定した運行ダイヤに応じて、所定地域において交通機関を定期的に運行するための運行コスト（例えば１ヶ月のコスト）を計算する。続いて、決定手段５４は、計算した運行コストを運行ダイヤ情報５０Ｂの運行コストに記憶する。そして、処理は、ステップＳＰ１８の処理に移行する。

（ステップＳＰ１８）
判定手段５６は、ステップＳＰ１４において検索された運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する収入金額が、ステップＳＰ１６において計算された運行コストに達しているか否かを判定する。例えば、判定手段５６は、当該収入金額が当該運行コストを超えている場合、判定を肯定する。そして、当該判定が肯定判定された場合には、処理は、ステップＳＰ２０の処理に移行する。一方、当該判定が否定判定された場合には、処理は、ステップＳＰ２２の処理に移行する。

（ステップＳＰ２０）
決定手段５４は、ステップＳＰ１６において仮決定した運行ダイヤを本決定する。すなわち、決定手段５４は、運行ダイヤ情報５０Ｂにおいて、ステップＳＰ１４において検索された運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する決定フラグを「決定」に更新する。続いて、通知手段５８は、決定手段５４によって決定された運行ダイヤを、移動需要を送信した各ユーザの端末装置１２に通知する。具体的には、通知手段５８は、ステップＳＰ１４において検索された運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザそれぞれの端末装置１２に対して、運行決定通知画面を送信する。

図６は、本実施形態に係る運行決定通知画面７０の一例を示す図である。

図６に示すように、運行決定通知画面７０は、運行通知領域７２が設けられている。運行通知領域７２には、運行ダイヤが決定したことや、運行日時、乗降場所（停留所）等が表されている。

そして、処理は、図４に示す一連の処理を終了する。

（ステップＳＰ２２）
通知手段５８は、収入金額が不足していることを、移動需要を送信した各ユーザの端末装置１２に通知する。具体的には、通知手段５８は、ステップＳＰ１４において検索された運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザそれぞれの端末装置１２に対して、決定不可通知画面を送信する。

図７は、本実施形態に係る決定不可通知画面８０の一例を示す図である。

図７に示すように、決定不可通知画面８０は、金額不足通知領域８２と、再入力ボタン８４と、が設けられている。金額不足通知領域８２には、収入金額が不足していることにより、運行ダイヤが決定できないこと等が表されている。再入力ボタン８４は、ユーザが新たに月額料金（支払金額）を再入力するためのボタンである。

そして、処理は、図４に示す一連の処理を終了する。

＜運行継続に係る処理の流れ＞
図８は、本実施形態に係る運行ダイヤ決定システム１において、交通機関の運行を継続するための処理の流れの一例を示すフローチャートである。また、以下のステップの処理は、例えば、一のユーザが端末装置１２において交通機関の利用を中止する要求を行ったタイミングで開始される。なお、以下のステップの順番及び内容は、適宜、変更することができる。

（ステップＳＰ３０）
受付手段５２は、一のユーザの端末装置１２から中止要求を受け付ける。そして、処理は、ステップＳＰ３２の処理に移行する。

（ステップＳＰ３２）
決定手段５４は、ユーザ情報５０Ａにおいて、一のユーザの識別情報（ユーザＩＤ）に対応付けられている支払金額を取得する。続いて、決定手段５４は、運行ダイヤ情報５０Ｂにおいて、当該一のユーザが利用ユーザとして記憶されている運行ダイヤを検索し、当該検索した運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する収入金額から当該取得した支払金額を減算する。続いて、決定手段５４は、検索した運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザから、当該一のユーザの識別情報（ユーザＩＤ）を削除する。そして、処理は、ステップＳＰ３４の処理に移行する。

（ステップＳＰ３４）
決定手段５４は、ユーザ情報５０Ａと運行ダイヤ情報５０Ｂを参照して、ステップＳＰ３２において検索した運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザ（他のユーザ）それぞれの移動需要を取得する。続いて、決定手段５４は、運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザの数（他のユーザの数）と利用ユーザ（他のユーザ）それぞれの利用日時に基づいて車両と車両数を再度特定し、乗降場所や運行日時を含む運行ダイヤを仮決定する。続いて、決定手段５４は、特定した車両や車両数、仮決定した運行ダイヤに応じて、所定地域において交通機関を定期的に運行するための運行コスト（例えば１ヶ月のコスト）を再計算する。続いて、決定手段５４は、再計算した運行コストを運行ダイヤ情報５０Ｂの運行コストに記憶する。そして、処理は、ステップＳＰ３６の処理に移行する。

（ステップＳＰ３６）
判定手段５６は、ステップＳＰ３２において検索された運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する収入金額が、ステップＳＰ３４において計算された運行コストに達しているか否かを判定する。例えば、判定手段５６は、当該収入金額が当該運行コストを超えている場合、判定を肯定する。そして、当該判定が肯定判定された場合には、処理は、ステップＳＰ３８の処理に移行する。一方、当該判定が否定判定された場合には、処理は、ステップＳＰ４０の処理に移行する。

（ステップＳＰ３８）
決定手段５４は、ステップＳＰ３４において仮決定した運行ダイヤを本決定する。続いて、通知手段５８は、決定手段５４によって決定された運行ダイヤを、利用ユーザ（他のユーザ）の端末装置１２に通知する。具体的には、通知手段５８は、ステップＳＰ３２において検索された運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザ（他のユーザ）それぞれの端末装置１２に対して、運行継続通知画面を送信する。

図９は、本実施形態に係る運行継続通知画面９０の一例を示す図である。

図９に示すように、運行継続通知画面９０は、運行継続通知領域９２が設けられている。運行継続通知領域９２には、交通機関の運行継続が決定したことや、変更された運行日時、乗降場所が表されている。

そして、処理は、図８に示す一連の処理を終了する。

（ステップＳＰ４０）
決定手段５４は、運行ダイヤ情報５０Ｂにおいて、ステップＳＰ３２において検索された運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する決定フラグを「未決定」に更新する。続いて、通知手段５８は、収入金額が不足していることを、利用ユーザ（他のユーザ）の端末装置１２に通知する。具体的には、通知手段５８は、ステップＳＰ３２において検索された運行ダイヤの識別情報（運行ダイヤＩＤ）に対応する利用ユーザ（他のユーザ）それぞれの端末装置１２に対して、金額不足通知画面を送信する。

図１０は、本実施形態に係る金額不足通知画面１００の一例を示す図である。

図１０に示すように、金額不足通知画面１００は、金額不足通知領域１０２と、再入力ボタン１０４と、が設けられている。金額不足通知領域１０２には、収入金額が不足していることにより、交通機関の運行が継続できないこと等が表されている。再入力ボタン１０４は、ユーザが月額料金（支払金額）を再入力するためのボタンである。

そして、処理は、図８に示す一連の処理を終了する。

＜効果＞
以上、本実施形態では、所定地域において交通機関の定期的な運行ダイヤを決定するためのプログラムであって、コンピュータを、複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける受付手段５２、支払金額に応じて、少なくとも乗降場所、運行日時を含む運行ダイヤを決定する決定手段５４、決定された運行ダイヤを、移動需要を送信した各ユーザに通知する通知手段５８、として機能させる。

この構成によれば、複数のユーザから支払金額を含む移動需要を受け付け、当該支払金額に応じて運行ダイヤを決定するため、ユーザの移動需要に応じた採算性のある運行ダイヤを決定することができる。また、ユーザに対しては、同乗予定者の検索や金銭的な負荷を軽減することができる。

また、本実施形態では、決定手段５４は、移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる希望乗降場所を優先して運行ダイヤを決定する。

この構成によれば、支払金額が多いほど希望乗降場所が優先された運行ダイヤが決定されるため、ユーザによる支払金額を高めることができ、もって採算性のある運行ダイヤを決定することができる。

また、本実施形態では、決定手段５４は、移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる利用日時を優先して運行ダイヤを決定する。

この構成によれば、支払金額が多いほど利用日時が優先された運行ダイヤが決定されるため、ユーザによる支払金額を高めることができ、もって採算性のある運行ダイヤを決定することができる。

また、本実施形態では、決定手段５４は、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達している場合、運行ダイヤを決定する。

この構成によれば、収入金額が運行コストに達している場合に運行ダイヤを決定するため、採算性のある運行ダイヤを決定することができる。

また、本実施形態では、通知手段５８は、収入金額が運行コストに達していない場合、移動需要を送信した各ユーザに、支払金額が不足していることを通知する。

この構成によれば、収入金額が運行コストに達していない場合に支払金額が不足していることを通知するため、利用を希望するユーザに対して納得感を与えることができる。

また、本実施形態では、受付手段５２は、移動需要を送信した各ユーザから、新たな支払金額の送信を受け付け、決定手段５４は、各ユーザから送信された新たな支払金額の合計である収入金額が運行コストに達している場合、運行ダイヤを決定する。

この構成によれば、収入金額が運行コストに達していない場合に新たな支払金額の送信を受け付け、新たな収入金額が運行コストに達していることにより運行ダイヤを決定するため、採算性のある運行ダイヤを決定することができるとともに、運行ダイヤを決定しやすくすることができる。

また、本実施形態では、受付手段５２は、運行ダイヤで交通機関を利用している一のユーザから、利用を中止する要求を受け付け、通知手段５８は、一のユーザの支払金額を除いた収入金額が、一のユーザを除いた新たなユーザ数に対応する運行コストに達していない場合、運行ダイヤで交通機関を利用している他のユーザそれぞれに、支払金額が不足していることを通知する。

この構成によれば、利用を中止する一のユーザがいる場合に、他のユーザそれぞれに支払金額が不足していることを通知するため、利用をしているユーザに対して納得感を与えることができる。

また、本実施形態では、受付手段５２は、他のユーザそれぞれから、新たな支払金額の送信を受け付け、決定手段５４は、他のユーザそれぞれから送信された新たな支払金額の合計である収入金額が新たなユーザ数に対応する運行コストに達している場合、交通機関の運行を継続することを決定する。

この構成によれば、収入金額が運行コストに達していない場合に新たな支払金額の送信を受け付け、新たな収入金額が運行コストに達していることにより交通機関の運行を継続するため、採算性のある運行ダイヤを決定することができるとともに、交通機関の運行を継続しやすくすることができる。

また、本実施形態では、決定手段５４は、一のユーザによる利用の中止に応じて、運行ダイヤに含まれる乗降場所又は運行日時を変更する。

この構成によれば、一のユーザによる交通機関の利用中止に伴い、乗降場所又は運行日時が変更されるため、継続して交通機関を利用する他のユーザの利便性を向上させることができる。

＜変形例＞
なお、本発明は上記の実施形態に限定されるものではない。すなわち、上記の実施形態に、当業者が適宜設計変更を加えたものも、本発明の特徴を備えている限り、本発明の範囲に包含される。また、上記実施形態及び後述する変形例が備える各要素は、技術的に可能な限りにおいて組み合わせることができ、これらを組み合わせたものも本発明の特徴を含む限り本発明の範囲に包含される。

例えば、上記実施形態では、ステップＳＰ１０で送信される入力画面において、ユーザが希望する降車場所を入力する領域が設けられる場合を説明したが、この降車場所は所定地域内の予め定められた地点（例えば病院や学校、役場、スーパーマーケット）のみを入力可能としてもよい。また、この入力画面では、支払金額である月額料金を入力する入力欄が表される場合を説明したが、この入力欄の近傍において、支払金額が多いほど希望乗車場所や利用日時を優先することを表示してもよい。また、この入力画面では、往路の到着時刻と、復路の出発時刻を入力する入力欄が表される場合を説明したが、往路の出発時刻と復路の到着時刻を入力する入力欄が表されてもよい。

また、判定手段５６は、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達しているか否かを判定する場合を説明したが、この収入金額には、自治体からの助成金等を加算してもよい。

また、通知手段５８は、各ユーザに支払金額が不足していることを通知する場合を説明したが、支払金額が少ないユーザにのみ当該不足していることを通知してもよい。例えば、通知手段５８は、各ユーザの支払金額の平均額よりも少ない支払金額を送信した一部のユーザにのみ、支払金額が不足していることを通知する。なお、例えば、通知手段５８は、１人あたりの運行コストよりも少ない支払金額を送信した一部のユーザにのみ、支払金額が不足していることを通知してもよい。

また、上記実施形態では、通知手段５８は、決定手段５４によって決定された運行ダイヤを、移動需要を送信した各ユーザの端末装置１２に通知する場合を説明したが、当該決定された運行ダイヤを交通機関の端末装置に通知してもよい。

［付記］
本発明には、以下の付記が含まれる。
＜付記１＞
所定地域において交通機関の運行ダイヤを決定するためのプログラムであって、コンピュータを、
複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける受付手段、
前記支払金額及び２以上のユーザの支払金額の合計に応じて、少なくとも乗降場所、運行日時を含む運行ダイヤを決定する決定手段、
前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段、
として機能させるプログラム。

１０…サーバ装置（コンピュータ）、５０…記憶手段、５２…受付手段、５４…決定手段、５８…通知手段

Claims (10)

1. 所定地域において交通機関の運行ダイヤを決定するためのプログラムであって、
   コンピュータを、
   複数のユーザから、少なくとも希望乗降場所及び支払金額を含む移動需要の送信を受け付ける受付手段、
   前記支払金額に応じて、前記希望乗降場所に基づき乗降場所を決定することにより、少なくとも前記乗降場所を含む運行ダイヤを決定する決定手段、
   前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段、
   として機能させ、
   前記決定手段は、前記移動需要に含まれる支払金額が所定額以上である場合に、当該移動需要に含まれる希望乗降場所に基づき前記乗降場所を決定することにより、前記運行ダイヤを決定する、プログラム。
2. 所定地域において交通機関の運行ダイヤを決定するためのプログラムであって、
   コンピュータを、
   複数のユーザから、少なくとも利用日時及び支払金額を含む移動需要の送信を受け付ける受付手段、
   前記支払金額に応じて、前記利用日時に基づき運行日時を決定することにより、少なくとも前記運行日時を含む運行ダイヤを決定する決定手段、
   前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段、
   として機能させ、
   前記決定手段は、前記移動需要に含まれる支払金額が所定額以上である場合に、当該移動需要に含まれる利用日時に基づき前記運行日時を決定することにより、前記運行ダイヤを決定する、プログラム。
3. 前記決定手段は、前記移動需要それぞれに含まれる支払金額の合計である収入金額が、前記移動需要を送信したユーザ数に基づき算出される運行コストに達している場合、前記運行ダイヤを決定する、
   請求項１又は２に記載のプログラム。
4. 前記通知手段は、前記収入金額が前記運行コストに達していない場合、前記移動需要を送信した各ユーザに、前記支払金額が不足していることを通知する、
   請求項３に記載のプログラム。
5. 前記受付手段は、前記移動需要を送信した各ユーザから、新たな支払金額の送信を受け付け、
   前記決定手段は、各ユーザから前記送信された新たな支払金額の合計である収入金額が前記運行コストに達している場合、前記運行ダイヤを決定する、
   請求項４に記載のプログラム。
6. 前記受付手段は、前記運行ダイヤで前記交通機関を利用している一のユーザから、利用を中止する要求を受け付け、
   前記通知手段は、前記一のユーザの前記支払金額を除いた前記収入金額が、前記一のユーザを除いた新たなユーザ数に基づき算出される運行コストに達していない場合、前記運行ダイヤで前記交通機関を利用している他のユーザそれぞれに、前記支払金額が不足していることを通知する、
   請求項３乃至５の何れか１項に記載のプログラム。
7. 前記受付手段は、前記他のユーザそれぞれから、新たな支払金額の送信を受け付け、
   前記決定手段は、前記他のユーザそれぞれから前記送信された新たな支払金額の合計である収入金額が前記新たなユーザ数に基づき算出される運行コストに達している場合、前記交通機関の運行を継続することを決定する、
   請求項６に記載のプログラム。
8. 前記決定手段は、前記一のユーザによる利用の中止に応じて、前記運行ダイヤを変更する、
   請求項７に記載のプログラム。
9. 所定地域において交通機関の運行ダイヤを決定するための情報処理装置であって、
   複数のユーザから、少なくとも希望乗降場所及び支払金額を含む移動需要の送信を受け付ける受付手段と、
   前記支払金額に応じて、前記希望乗降場所に基づき乗降場所を決定することにより、少なくとも前記乗降場所を含む運行ダイヤを決定する決定手段と、
   前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段と、
   を備え、
   前記決定手段は、前記移動需要に含まれる支払金額が所定額以上である場合に、当該移動需要に含まれる希望乗降場所に基づき前記乗降場所を決定することにより、前記運行ダイヤを決定する、情報処理装置。
10. 所定地域において交通機関の運行ダイヤを決定するための情報処理装置であって、
    複数のユーザから、少なくとも利用日時及び支払金額を含む移動需要の送信を受け付ける受付手段と、
    前記支払金額に応じて、前記利用日時に基づき運行日時を決定することにより、少なくとも前記運行日時を含む運行ダイヤを決定する決定手段と、
    前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段と、
    を備え、
    前記決定手段は、前記移動需要に含まれる支払金額が所定額以上である場合に、当該移動需要に含まれる利用日時に基づき前記運行日時を決定することにより、前記運行ダイヤを決定する、情報処理装置。

Images