IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社MaaS Tech Japanの特許一覧

<>
  • 特開-プログラム及び情報処理装置 図1
  • 特開-プログラム及び情報処理装置 図2
  • 特開-プログラム及び情報処理装置 図3
  • 特開-プログラム及び情報処理装置 図4
  • 特開-プログラム及び情報処理装置 図5
  • 特開-プログラム及び情報処理装置 図6
  • 特開-プログラム及び情報処理装置 図7
  • 特開-プログラム及び情報処理装置 図8
  • 特開-プログラム及び情報処理装置 図9
  • 特開-プログラム及び情報処理装置 図10
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022118141
(43)【公開日】2022-08-12
(54)【発明の名称】プログラム及び情報処理装置
(51)【国際特許分類】
   G06Q 50/30 20120101AFI20220804BHJP
【FI】
G06Q50/30
【審査請求】未請求
【請求項の数】10
【出願形態】OL
(21)【出願番号】P 2022099453
(22)【出願日】2022-06-21
(62)【分割の表示】P 2020070352の分割
【原出願日】2020-04-09
(71)【出願人】
【識別番号】518388498
【氏名又は名称】株式会社MaaS Tech Japan
(74)【代理人】
【識別番号】100176072
【弁理士】
【氏名又は名称】小林 功
(72)【発明者】
【氏名】日高 洋祐
(57)【要約】
【課題】ユーザの移動需要に応じた採算性のある運行ダイヤを決定する。
【解決手段】プログラムは、所定地域において交通機関の運行ダイヤを決定するためのプログラムであって、コンピュータを、複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける受付手段52、支払金額に応じて、少なくとも乗降場所、運行日時を含む運行ダイヤを決定する決定手段54、決定された運行ダイヤを、移動需要を送信した各ユーザに通知する通知手段58、として機能させる。
【選択図】図3

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

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、プログラム及び情報処理装置に関する。
【背景技術】
【0002】
従来から、目的地が同じ方向である複数のユーザが同乗する相乗りタクシーが知られている。
【0003】
これに関し、非特許文献1には、ユーザが乗車地や目的地等を入力することにより、同乗予定者を検索して、各ユーザが相乗りに同意すると、タクシーが順番に迎車する技術が開示されている。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】JapanTaxi株式会社、“空間も、お金も、相乗り。相乗りタクシー”、[online]、平成30年3月11日、[令和2年2月2日検索]、インターネット<URL:https://ainori.japantaxi.jp/>
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、非特許文献1に記載の技術では、ユーザは定期的に相乗りタクシーを利用したい場合でも、その都度、乗車地や目的地等を入力して、同乗予定者を検索しなければならない。このため、例えば山間部で高齢化率の高い地域(過疎地域)において、定期的に病院等へ通院しているユーザには、乗車地や目的地等を毎回入力する負担がかかるだけでなく、同乗予定者を容易に検索することができず、金銭的な負担もかかるという問題がある。
【0006】
また、交通機関(例えば、鉄道やバス等)を運行する事業者は、各ユーザによる支払金額(収入金額)を正確に予測することが難しいため、このような地域において新たな運行ダイヤを決定することに消極的であった。
【0007】
本発明はこのような課題に鑑みてなされたものであり、その目的は、ユーザの移動需要に応じた採算性のある運行ダイヤを決定することができるプログラム及び情報処理装置を提供することにある。
【課題を解決するための手段】
【0008】
上記課題を解決するために、本発明の第一態様に係るプログラムは、所定地域において交通機関の運行ダイヤを決定するためのプログラムであって、コンピュータを、複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける受付手段、前記支払金額に応じて、少なくとも乗降場所、運行日時を含む運行ダイヤを決定する決定手段、前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段、として機能させる。
【0009】
また、本発明の第二態様では、前記決定手段は、前記移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる希望乗降場所を優先して前記運行ダイヤを決定する。
【0010】
また、本発明の第三態様では、前記決定手段は、前記移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる利用日時を優先して前記運行ダイヤを決定する。
【0011】
また、本発明の第四態様では、前記決定手段は、前記移動需要それぞれに含まれる支払金額の合計である収入金額が、前記移動需要を送信したユーザ数に対応する運行コストに達している場合、前記運行ダイヤを決定する。
【0012】
また、本発明の第五態様では、前記通知手段は、前記収入金額が前記運行コストに達していない場合、前記移動需要を送信した各ユーザに、支払金額が不足していることを通知する。
【0013】
また、本発明の第六態様では、前記受付手段は、前記移動需要を送信した各ユーザから、新たな支払金額の送信を受け付け、前記決定手段は、各ユーザから前記送信された新たな支払金額の合計である収入金額が前記運行コストに達している場合、前記運行ダイヤを決定する。
【0014】
また、本発明の第七態様では、前記受付手段は、前記運行ダイヤで交通機関を利用している一のユーザから、利用を中止する要求を受け付け、前記通知手段は、前記一のユーザの支払金額を除いた前記収入金額が、前記一のユーザを除いた新たなユーザ数に対応する運行コストに達していない場合、前記運行ダイヤで交通機関を利用している他のユーザそれぞれに、支払金額が不足していることを通知する。
【0015】
また、本発明の第八態様では、前記受付手段は、前記他のユーザそれぞれから、新たな支払金額の送信を受け付け、前記決定手段は、前記他のユーザそれぞれから前記送信された新たな支払金額の合計である収入金額が前記新たなユーザ数に対応する運行コストに達している場合、前記交通機関の運行を継続することを決定する。
【0016】
また、本発明の第九態様では、前記決定手段は、前記一のユーザによる利用の中止に応じて、前記運行ダイヤに含まれる乗降場所又は運行日時を変更する。
【0017】
また、本発明の第十態様に係る情報処理装置は、所定地域において交通機関の運行ダイヤを決定するための情報処理装置であって、複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける受付手段と、前記支払金額に応じて、少なくとも乗降場所、運行日時を含む運行ダイヤを決定する決定手段と、前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段と、を備える。
【発明の効果】
【0018】
本発明によれば、ユーザの移動需要に応じた採算性のある運行ダイヤを決定することができる。
【図面の簡単な説明】
【0019】
図1】本発明の実施形態に係る運行ダイヤ決定システムの全体構成の一例を示すブロック図である。
図2図1に示すサーバ装置のハードウェア構成の一例を示すブロック図である。
図3図1に示すサーバ装置の機能的構成の一例を示すブロック図である。
図4】本実施形態に係る運行ダイヤ決定システムにおいて、交通機関の運行を決定する処理の流れの一例を示すフローチャートである。
図5】本実施形態に係る入力画面の一例を示す図である。
図6】本実施形態に係る運行決定通知画面の一例を示す図である。
図7】本実施形態に係る決定不可通知画面の一例を示す図である。
図8】本実施形態に係る運行ダイヤ決定システムにおいて、交通機関の運行を継続するための処理の流れの一例を示すフローチャートである。
図9】本実施形態に係る運行継続通知画面の一例を示す図である。
図10】本実施形態に係る金額不足通知画面の一例を示す図である。
【発明を実施するための形態】
【0020】
以下、添付図面を参照しながら本発明の実施形態(以下、「本実施形態」という。)について説明する。説明の理解を容易にするため、各図面において同一の構成要素及びステップに対しては可能な限り同一の符号を付して、重複する説明は省略する。
【0021】
<全体構成>
図1は、本発明の実施形態に係る運行ダイヤ決定システム1の全体構成の一例を示すブロック図である。
【0022】
図1に示すように、運行ダイヤ決定システム1は、サーバ装置10と、複数の端末装置12と、を備える。これらの装置は、インターネットや電話回線網等の通信ネットワークNTを介して互いに通信可能に構成されている。
【0023】
サーバ装置10は、運行ダイヤの決定に関する各種制御を行う装置(コンピュータ)である。このサーバ装置10は、端末装置12を介したユーザからの移動需要の送信に基づき、運行ダイヤを決定する。
【0024】
端末装置12は、ユーザが操作する装置である。これら端末装置12は、例えば、第一端末装置12Aと、第二端末装置12Bと、を含む。端末装置12としては、携帯電話やスマートフォン、タブレット、パーソナルコンピュータ等が挙げられる。
【0025】
第一端末装置12Aは、第一のユーザが操作する装置である。
【0026】
第二端末装置12Bは、第二のユーザが操作する装置である。
【0027】
<ハードウェア構成>
図2は、図1に示すサーバ装置10のハードウェア構成の一例を示すブロック図である。
【0028】
図2に示すように、サーバ装置10は、制御装置20と、通信装置26と、記憶装置28と、を備える。制御装置20は、CPU(Central Processing Unit)22及びメモリ24を主に備えて構成される。
【0029】
制御装置20では、CPU22がメモリ24或いは記憶装置28等に格納された所定のプログラムを実行することにより、各種の機能手段として機能する。この機能手段の詳細については後述する。
【0030】
通信装置26は、外部の装置と通信するための通信インターフェース等で構成される。通信装置26は、例えば、端末装置12との間で各種の情報を送受信する。
【0031】
記憶装置28は、ハードディスク等で構成される。記憶装置28は、制御装置20における処理の実行に必要な各種プログラムや各種の情報、及び処理結果の情報を記憶する。
【0032】
なお、サーバ装置10は、専用又は汎用のサーバ・コンピュータなどの情報処理装置を用いて実現することができる。また、サーバ装置10は、単一の情報処理装置より構成されるものであっても、通信ネットワークNT上に分散した複数の情報処理装置より構成されるものであってもよい。また、図2は、サーバ装置10が有する主要なハードウェア構成の一部を示しているに過ぎず、サーバ装置10は、サーバが一般的に備える他の構成を備えることができる。また、複数の端末装置12のハードウェア構成も、例えば操作手段や表示装置等を備える他は、サーバ装置10と同様の構成を備えることができる。
【0033】
<機能的構成>
図3は、図1に示すサーバ装置10の機能的構成の一例を示すブロック図である。
【0034】
図3に示すように、サーバ装置10は、機能的構成として、記憶手段50と、受付手段52と、決定手段54と、判定手段56と、通知手段58と、を備える。
【0035】
記憶手段50は、ユーザ情報50Aや、運行ダイヤ情報50B等を記憶する機能手段である。
【0036】
ユーザ情報50Aは、各ユーザの識別情報(ユーザID)に対応付けて、ユーザそれぞれのログインIDや、パスワード、ユーザ名、生年月日、性別、年齢、自宅住所、連絡先、移動需要等を含む。連絡先としては、電話番号や、メールアドレス、メッセージアプリケーションのユーザID等が挙げられる。移動需要は、少なくとも希望乗降場所、利用日時、支払金額を含む。この移動需要は、受付手段52が各ユーザの端末装置12から受け付けた情報である。希望乗降場所は、ユーザが希望する出発地と到着地を含む。この出発地は、例えばユーザの自宅に最も近い道路に面した地点である。この到着地は、例えばユーザの行き先(例えば病院、学校、スーパーマーケット等)である。利用日時は、ユーザが交通機関を利用する日時であって、利用日や、往路の到着時間、復路の出発時間を含む。例えば、利用日時には、利用日である曜日と、出発地である自宅から到着地である病院Aへの到着時間と、到着地である病院Aから出発地である自宅への出発時間とを含む。この到着時間と出発時間は、例えば15分単位の時間帯で設定される。支払金額は、ユーザが交通機関の利用で支払うことが可能な(支払ってもよい)金額であって、例えば1ヶ月間における利用額(月額料金)である。
【0037】
運行ダイヤ情報50Bは、各運行ダイヤの識別情報(運行ダイヤID)に対応付けて、運行ダイヤそれぞれの地域、利用ユーザ、収入金額、乗降場所、運行日時、運行車両、運行コスト、決定フラグ等を含む。地域は、運行ダイヤが決定している地域又は未決定の地域を特定する情報(例えば町名や村名)を含む。利用ユーザは、運行ダイヤを利用する又は利用を希望する各ユーザの識別情報を含む。収入金額は、各利用ユーザの移動需要に含まれる支払金額の合計である。この収入金額は、利用ユーザが増減することや、支払金額が増減することに伴って変化する。乗降場所は、運行ダイヤにおける停留所の名称と位置情報(例えば緯度及び経度、住所)を含む。運行日時は、運行ダイヤにおける運行日と運行時間を含む。この運行日時は、各停留所の時刻表として記憶されていてもよい。運行車両は、運行ダイヤにおいて利用される一又は複数の車両の識別情報(車両ID)に対応付けて、車両価格、車両燃費、乗車定員、必要免許等を含む。乗車定員は、乗車するユーザの最大人数に応じて定まる。運行コストは、所定期間(例えば1ヶ月)における運行にかかる費用である。この費用は、決定手段54によって、利用ユーザ数や移動距離、車両価格、車両燃費、車両維持費(例えば駐車場費や税金、メンテナンス費、保険料)、人件費(例えば運転手の給与)等に基づいて算出される。決定フラグは、運行ダイヤが決定しているか否かを示すフラグである。決定フラグには、「決定」と「未決定」の何れかが含まれ、初期値は「未定」である。
【0038】
受付手段52は、ユーザの端末装置12から各種情報を受け付ける機能手段である。本実施形態では、受付手段52は、複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける。
【0039】
また、受付手段52は、移動需要を送信した各ユーザから、新たな支払金額の送信を受け付ける。例えば、受付手段52は、通知手段58によって支払金額が不足していることが通知された各ユーザから、以前の支払金額から増額された新たな支払金額の送信を受け付ける。
【0040】
また、受付手段52は、決定手段54によって決定された運行ダイヤで交通機関を利用している一のユーザから、利用を中止する要求を受け付ける。また、受付手段52は、当該一のユーザを除いた当該交通機関を利用している他のユーザそれぞれから、新たな支払金額の送信を受け付ける。例えば、受付手段52は、通知手段58によって支払金額が不足していることが通知された当該他のユーザから、以前の支払金額から増額された新たな支払金額の送信を受け付ける。
【0041】
決定手段54は、所定地域において交通機関の(定期的な)運行ダイヤを決定する機能手段である。この所定地域としては、例えば過疎地域における町や村、集落が挙げられる。本実施形態では、決定手段54は、受付手段52が受け付けた各ユーザの移動需要に含まれる希望乗降場所や利用日時、支払金額に応じて、運行ダイヤを決定する。この運行ダイヤは、例えば利用ユーザ、収入金額、乗降場所、運行日時、運行車両、運行コスト等を含む。そして、決定手段54は、決定した運行ダイヤを運行ダイヤ情報50Bに記憶する。また、決定手段54は、運行ダイヤを決定したことに応じて、運行ダイヤ情報50Bの決定フラグを「決定」に更新する。
【0042】
例えば、決定手段54は、所定地域内の一又は複数の道路に面している地点を中心として500m四方に区画し、各ユーザの移動需要に含まれる2以上の希望乗降場所が、1つの区画に含まれる場合、各希望乗降場所からの距離が最も短い地点であって道路に面している地点を乗降場所(停留所)として運行ダイヤを決定する。また、例えば、決定手段54は、受付手段52が受け付けた移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる希望乗降場所を優先して運行ダイヤを決定する。具体的には、決定手段54は、同じ区画内に希望乗降場所を設定(希望)した各ユーザの支払金額の平均値を算出する。続いて、決定手段54は、或るユーザの支払金額が当該平均値を第一所定額(例えば2500円)上回っている場合、当該或るユーザの移動需要に含まれる希望乗降場所の第一所定範囲内(例えば200m以内)に乗降場所を決定する。また、決定手段54は、或るユーザの移動需要に含まれる支払金額が当該平均値を第二所定額(例えば5000円)上回っている場合、当該或るユーザの移動需要に含まれる希望乗降場所の第二所定範囲内(例えば150m以内)に乗降場所を決定する。
【0043】
例えば、決定手段54は、移動需要それぞれに同一の希望乗降場所が含まれる場合であって、当該移動需要それぞれに含まれる利用日時が、所定時間(1時間)以内であるとき、当該利用日時の平均値を運行日時として運行ダイヤを決定する。具体的には、決定手段54は、2以上の移動需要それぞれに同一の希望降車場所(例えば病院A)が含まれる場合であって、当該移動需要それぞれに含まれる利用日が同日であって、往路の到着時間が9時~10時までの間であるとき、当該到着時間の平均値を運行日時(到着時間)として運行ダイヤを決定する。また、例えば、決定手段54は、移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる利用日時を優先して運行ダイヤを決定する。具体的には、決定手段54は、移動需要それぞれに同一の希望降車場所(例えば病院A)が含まれる場合であって、当該移動需要それぞれに含まれる利用日が同日(同じ曜日)であり、到着時間が9時~10時までの間であるとき、当該到着時間を設定した各ユーザの支払金額の平均値を算出する。続いて、決定手段54は、或るユーザの移動需要に含まれる支払金額が当該平均値を第一所定額(例えば2500円)上回っている場合、当該或るユーザの移動需要に含まれる到着時間の第一所定時間内(例えば30分以内)に運行日時(病院Aへの到着時間)を決定する。また、決定手段54は、或るユーザの移動需要に含まれる支払金額が当該平均値を第二所定額(例えば5000円)上回っている場合、当該或るユーザの移動需要に含まれる到着時間の第二所定時間内(例えば15分以内)に運行日時(病院Aへの到着日時)を決定する。
【0044】
また、決定手段54は、判定手段56によって、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達していると判定された場合、運行ダイヤを決定する。一方、決定手段54は、判定手段56によって、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達していないと判定された場合、運行ダイヤを決定しない。
【0045】
また、決定手段54は、判定手段56によって、各ユーザから送信された新たな支払金額の合計である収入金額が運行コストに達していると判定された場合、運行ダイヤを決定する。一方、決定手段54は、判定手段56によって、当該収入金額が運行コストに達していないと判定された場合、運行ダイヤを決定しない。
【0046】
また、決定手段54は、決定した運行ダイヤで交通機関を利用している一のユーザから、利用を中止する要求があった後、判定手段56によって、当該交通機関を利用している他のユーザそれぞれから送信された新たな支払金額の合計である収入金額が新たなユーザ数(他のユーザの数)に対応する運行コストに達していると判定された場合、運行ダイヤ(運行)を継続することを決定する。一方、決定手段54は、当該一のユーザから、利用を中止する要求があった後、判定手段56によって、当該収入金額が新たなユーザ数に対応する運行コストに達していないと判定された場合、運行ダイヤ(運行)を継続しないことを決定する。
【0047】
また、決定手段54は、決定した運行ダイヤで交通機関を利用している一のユーザによる利用の中止に応じて、当該運行ダイヤに含まれる乗降場所又は運行日時を変更する。例えば、決定手段54は、当該一のユーザによる移動需要を除外して、他のユーザによる移動需要に基づいて、乗降場所や運行日時を再度決定する。
【0048】
判定手段56は、各種判定を行う機能手段である。本実施形態では、判定手段56は、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達しているか否かを判定する。また、判定手段56は、各ユーザから送信された新たな支払金額の合計である収入金額が運行コストに達しているか否かを判定する。また、判定手段56は、交通機関の利用を中止する要求を行った一のユーザを除く他のユーザそれぞれから送信された新たな支払金額の合計である収入金額が新たなユーザ数(他のユーザの数)に対応する運行コストに達しているか否かを判定する。
【0049】
通知手段58は、各ユーザの端末装置12に通知を行う機能手段である。本実施形態では、通知手段58は、決定手段54によって決定された運行ダイヤを、移動需要を送信した各ユーザの端末装置12に通知する。また、通知手段58は、移動需要それぞれに含まれる支払金額の合計である収入金額が運行コストに達していない場合、移動需要を送信した各ユーザの端末装置12に、支払金額が不足していることを通知する。
【0050】
また、通知手段58は、交通機関の利用を中止する要求を行った一のユーザの支払金額を除いた収入金額が、当該一のユーザを除いた新たなユーザ数に対応する運行コストに達していない場合、運行ダイヤで交通機関を利用している他のユーザそれぞれに、支払金額が不足していることを通知する。
【0051】
<運行決定に係る処理の流れ>
図4は、本実施形態に係る運行ダイヤ決定システム1において、交通機関の運行を決定する処理の流れの一例を示すフローチャートである。また、以下のステップの処理は、例えば、ユーザが端末装置12において移動需要を入力するための指示を行ったタイミングで開始される。なお、以下のステップの順番及び内容は、適宜、変更することができる。
【0052】
(ステップSP10)
受付手段52は、ユーザの端末装置12に、移動需要を入力するための入力画面を送信する。
【0053】
図5は、本実施形態に係る入力画面60の一例を示す図である。
【0054】
図5に示すように、入力画面60は、希望乗降場所入力領域62と、利用日時入力領域64と、支払金額入力領域66と、送信ボタン68と、が設けられている。希望乗降場所入力領域62には、希望する乗車場所である出発地と、希望する降車場所である到着地とを入力する入力欄が表されている。希望乗降場所入力領域62では、ユーザによって出発地又は到着地の入力欄に郵便番号や住所、電話番号、マップコード等の情報が入力されることにより、当該情報に関する周辺地図を表示する画面に遷移し、ユーザは詳細な地点(位置)を設定することができる。利用日時入力領域64には、ユーザが交通機関を利用する曜日である利用日と、往路の到着時間である希望到着時間と、復路の車場所である到着地を入力する入力欄が表されている。支払金額入力領域66には、支払金額である月額料金を入力する入力欄が評されている。支払金額入力領域66では、ユーザが希望乗降場所入力領域62の出発地や到着地、利用日時入力領域64に含まれる利用日が入力済である場合、移動距離や利用頻度に応じた参考金額を表してもよい。送信ボタン68は、ユーザにより各入力欄に入力された移動需要(希望条件)をサーバ装置10に送信するためのボタンである。
【0055】
図4に戻って、処理は、ステップSP12の処理に移行する。
【0056】
(ステップSP12)
入力画面60において送信ボタン68が押下されたことに応じて、受付手段52は、ユーザの端末装置12から移動需要の送信を受け付ける。そして、処理は、ステップSP14の処理に移行する。
【0057】
(ステップSP14)
決定手段54は、ユーザ情報50Aの移動需要において、ユーザの識別情報(ユーザID)に対応付けて、ステップSP12で受け付けた移動需要を追加する。また、決定手段54は、運行ダイヤ情報50Bの地域を参照して、当該移動需要に含まれる希望乗降場所を含む地域を検索する。続いて、決定手段54は、検索した運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザに、ステップSP12で移動需要を送信したユーザの識別情報(ユーザID)を追加する。続いて、決定手段54は、検索した運行ダイヤの識別情報(運行ダイヤID)に対応する収入金額に、当該移動需要に含まれる支払金額を加算する。そして、処理は、ステップSP16の処理に移行する。
【0058】
(ステップSP16)
決定手段54は、ユーザ情報50Aと運行ダイヤ情報50Bを参照して、ステップSP14において検索した運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザそれぞれの移動需要を取得する。続いて、決定手段54は、運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザの数(ユーザ数)と利用ユーザそれぞれの利用日時に基づいて車両と車両数を特定し、乗降場所や運行日時を含む運行ダイヤを仮決定する。続いて、決定手段54は、仮決定した運行ダイヤに応じて、所定地域において交通機関を定期的に運行するための運行コスト(例えば1ヶ月のコスト)を計算する。続いて、決定手段54は、計算した運行コストを運行ダイヤ情報50Bの運行コストに記憶する。そして、処理は、ステップSP18の処理に移行する。
【0059】
(ステップSP18)
判定手段56は、ステップSP14において検索された運行ダイヤの識別情報(運行ダイヤID)に対応する収入金額が、ステップSP16において計算された運行コストに達しているか否かを判定する。例えば、判定手段56は、当該収入金額が当該運行コストを超えている場合、判定を肯定する。そして、当該判定が肯定判定された場合には、処理は、ステップSP20の処理に移行する。一方、当該判定が否定判定された場合には、処理は、ステップSP22の処理に移行する。
【0060】
(ステップSP20)
決定手段54は、ステップSP16において仮決定した運行ダイヤを本決定する。すなわち、決定手段54は、運行ダイヤ情報50Bにおいて、ステップSP14において検索された運行ダイヤの識別情報(運行ダイヤID)に対応する決定フラグを「決定」に更新する。続いて、通知手段58は、決定手段54によって決定された運行ダイヤを、移動需要を送信した各ユーザの端末装置12に通知する。具体的には、通知手段58は、ステップSP14において検索された運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザそれぞれの端末装置12に対して、運行決定通知画面を送信する。
【0061】
図6は、本実施形態に係る運行決定通知画面70の一例を示す図である。
【0062】
図6に示すように、運行決定通知画面70は、運行通知領域72が設けられている。運行通知領域72には、運行ダイヤが決定したことや、運行日時、乗降場所(停留所)等が表されている。
【0063】
そして、処理は、図4に示す一連の処理を終了する。
【0064】
(ステップSP22)
通知手段58は、収入金額が不足していることを、移動需要を送信した各ユーザの端末装置12に通知する。具体的には、通知手段58は、ステップSP14において検索された運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザそれぞれの端末装置12に対して、決定不可通知画面を送信する。
【0065】
図7は、本実施形態に係る決定不可通知画面80の一例を示す図である。
【0066】
図7に示すように、決定不可通知画面80は、金額不足通知領域82と、再入力ボタン84と、が設けられている。金額不足通知領域82には、収入金額が不足していることにより、運行ダイヤが決定できないこと等が表されている。再入力ボタン84は、ユーザが新たに月額料金(支払金額)を再入力するためのボタンである。
【0067】
そして、処理は、図4に示す一連の処理を終了する。
【0068】
<運行継続に係る処理の流れ>
図8は、本実施形態に係る運行ダイヤ決定システム1において、交通機関の運行を継続するための処理の流れの一例を示すフローチャートである。また、以下のステップの処理は、例えば、一のユーザが端末装置12において交通機関の利用を中止する要求を行ったタイミングで開始される。なお、以下のステップの順番及び内容は、適宜、変更することができる。
【0069】
(ステップSP30)
受付手段52は、一のユーザの端末装置12から中止要求を受け付ける。そして、処理は、ステップSP32の処理に移行する。
【0070】
(ステップSP32)
決定手段54は、ユーザ情報50Aにおいて、一のユーザの識別情報(ユーザID)に対応付けられている支払金額を取得する。続いて、決定手段54は、運行ダイヤ情報50Bにおいて、当該一のユーザが利用ユーザとして記憶されている運行ダイヤを検索し、当該検索した運行ダイヤの識別情報(運行ダイヤID)に対応する収入金額から当該取得した支払金額を減算する。続いて、決定手段54は、検索した運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザから、当該一のユーザの識別情報(ユーザID)を削除する。そして、処理は、ステップSP34の処理に移行する。
【0071】
(ステップSP34)
決定手段54は、ユーザ情報50Aと運行ダイヤ情報50Bを参照して、ステップSP32において検索した運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザ(他のユーザ)それぞれの移動需要を取得する。続いて、決定手段54は、運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザの数(他のユーザの数)と利用ユーザ(他のユーザ)それぞれの利用日時に基づいて車両と車両数を再度特定し、乗降場所や運行日時を含む運行ダイヤを仮決定する。続いて、決定手段54は、特定した車両や車両数、仮決定した運行ダイヤに応じて、所定地域において交通機関を定期的に運行するための運行コスト(例えば1ヶ月のコスト)を再計算する。続いて、決定手段54は、再計算した運行コストを運行ダイヤ情報50Bの運行コストに記憶する。そして、処理は、ステップSP36の処理に移行する。
【0072】
(ステップSP36)
判定手段56は、ステップSP32において検索された運行ダイヤの識別情報(運行ダイヤID)に対応する収入金額が、ステップSP34において計算された運行コストに達しているか否かを判定する。例えば、判定手段56は、当該収入金額が当該運行コストを超えている場合、判定を肯定する。そして、当該判定が肯定判定された場合には、処理は、ステップSP38の処理に移行する。一方、当該判定が否定判定された場合には、処理は、ステップSP40の処理に移行する。
【0073】
(ステップSP38)
決定手段54は、ステップSP34において仮決定した運行ダイヤを本決定する。続いて、通知手段58は、決定手段54によって決定された運行ダイヤを、利用ユーザ(他のユーザ)の端末装置12に通知する。具体的には、通知手段58は、ステップSP32において検索された運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザ(他のユーザ)それぞれの端末装置12に対して、運行継続通知画面を送信する。
【0074】
図9は、本実施形態に係る運行継続通知画面90の一例を示す図である。
【0075】
図9に示すように、運行継続通知画面90は、運行継続通知領域92が設けられている。運行継続通知領域92には、交通機関の運行継続が決定したことや、変更された運行日時、乗降場所が表されている。
【0076】
そして、処理は、図8に示す一連の処理を終了する。
【0077】
(ステップSP40)
決定手段54は、運行ダイヤ情報50Bにおいて、ステップSP32において検索された運行ダイヤの識別情報(運行ダイヤID)に対応する決定フラグを「未決定」に更新する。続いて、通知手段58は、収入金額が不足していることを、利用ユーザ(他のユーザ)の端末装置12に通知する。具体的には、通知手段58は、ステップSP32において検索された運行ダイヤの識別情報(運行ダイヤID)に対応する利用ユーザ(他のユーザ)それぞれの端末装置12に対して、金額不足通知画面を送信する。
【0078】
図10は、本実施形態に係る金額不足通知画面100の一例を示す図である。
【0079】
図10に示すように、金額不足通知画面100は、金額不足通知領域102と、再入力ボタン104と、が設けられている。金額不足通知領域102には、収入金額が不足していることにより、交通機関の運行が継続できないこと等が表されている。再入力ボタン104は、ユーザが月額料金(支払金額)を再入力するためのボタンである。
【0080】
そして、処理は、図8に示す一連の処理を終了する。
【0081】
<効果>
以上、本実施形態では、所定地域において交通機関の定期的な運行ダイヤを決定するためのプログラムであって、コンピュータを、複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける受付手段52、支払金額に応じて、少なくとも乗降場所、運行日時を含む運行ダイヤを決定する決定手段54、決定された運行ダイヤを、移動需要を送信した各ユーザに通知する通知手段58、として機能させる。
【0082】
この構成によれば、複数のユーザから支払金額を含む移動需要を受け付け、当該支払金額に応じて運行ダイヤを決定するため、ユーザの移動需要に応じた採算性のある運行ダイヤを決定することができる。また、ユーザに対しては、同乗予定者の検索や金銭的な負荷を軽減することができる。
【0083】
また、本実施形態では、決定手段54は、移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる希望乗降場所を優先して運行ダイヤを決定する。
【0084】
この構成によれば、支払金額が多いほど希望乗降場所が優先された運行ダイヤが決定されるため、ユーザによる支払金額を高めることができ、もって採算性のある運行ダイヤを決定することができる。
【0085】
また、本実施形態では、決定手段54は、移動需要に含まれる支払金額が多いほど、当該移動需要に含まれる利用日時を優先して運行ダイヤを決定する。
【0086】
この構成によれば、支払金額が多いほど利用日時が優先された運行ダイヤが決定されるため、ユーザによる支払金額を高めることができ、もって採算性のある運行ダイヤを決定することができる。
【0087】
また、本実施形態では、決定手段54は、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達している場合、運行ダイヤを決定する。
【0088】
この構成によれば、収入金額が運行コストに達している場合に運行ダイヤを決定するため、採算性のある運行ダイヤを決定することができる。
【0089】
また、本実施形態では、通知手段58は、収入金額が運行コストに達していない場合、移動需要を送信した各ユーザに、支払金額が不足していることを通知する。
【0090】
この構成によれば、収入金額が運行コストに達していない場合に支払金額が不足していることを通知するため、利用を希望するユーザに対して納得感を与えることができる。
【0091】
また、本実施形態では、受付手段52は、移動需要を送信した各ユーザから、新たな支払金額の送信を受け付け、決定手段54は、各ユーザから送信された新たな支払金額の合計である収入金額が運行コストに達している場合、運行ダイヤを決定する。
【0092】
この構成によれば、収入金額が運行コストに達していない場合に新たな支払金額の送信を受け付け、新たな収入金額が運行コストに達していることにより運行ダイヤを決定するため、採算性のある運行ダイヤを決定することができるとともに、運行ダイヤを決定しやすくすることができる。
【0093】
また、本実施形態では、受付手段52は、運行ダイヤで交通機関を利用している一のユーザから、利用を中止する要求を受け付け、通知手段58は、一のユーザの支払金額を除いた収入金額が、一のユーザを除いた新たなユーザ数に対応する運行コストに達していない場合、運行ダイヤで交通機関を利用している他のユーザそれぞれに、支払金額が不足していることを通知する。
【0094】
この構成によれば、利用を中止する一のユーザがいる場合に、他のユーザそれぞれに支払金額が不足していることを通知するため、利用をしているユーザに対して納得感を与えることができる。
【0095】
また、本実施形態では、受付手段52は、他のユーザそれぞれから、新たな支払金額の送信を受け付け、決定手段54は、他のユーザそれぞれから送信された新たな支払金額の合計である収入金額が新たなユーザ数に対応する運行コストに達している場合、交通機関の運行を継続することを決定する。
【0096】
この構成によれば、収入金額が運行コストに達していない場合に新たな支払金額の送信を受け付け、新たな収入金額が運行コストに達していることにより交通機関の運行を継続するため、採算性のある運行ダイヤを決定することができるとともに、交通機関の運行を継続しやすくすることができる。
【0097】
また、本実施形態では、決定手段54は、一のユーザによる利用の中止に応じて、運行ダイヤに含まれる乗降場所又は運行日時を変更する。
【0098】
この構成によれば、一のユーザによる交通機関の利用中止に伴い、乗降場所又は運行日時が変更されるため、継続して交通機関を利用する他のユーザの利便性を向上させることができる。
【0099】
<変形例>
なお、本発明は上記の実施形態に限定されるものではない。すなわち、上記の実施形態に、当業者が適宜設計変更を加えたものも、本発明の特徴を備えている限り、本発明の範囲に包含される。また、上記実施形態及び後述する変形例が備える各要素は、技術的に可能な限りにおいて組み合わせることができ、これらを組み合わせたものも本発明の特徴を含む限り本発明の範囲に包含される。
【0100】
例えば、上記実施形態では、ステップSP10で送信される入力画面において、ユーザが希望する降車場所を入力する領域が設けられる場合を説明したが、この降車場所は所定地域内の予め定められた地点(例えば病院や学校、役場、スーパーマーケット)のみを入力可能としてもよい。また、この入力画面では、支払金額である月額料金を入力する入力欄が表される場合を説明したが、この入力欄の近傍において、支払金額が多いほど希望乗車場所や利用日時を優先することを表示してもよい。また、この入力画面では、往路の到着時刻と、復路の出発時刻を入力する入力欄が表される場合を説明したが、往路の出発時刻と復路の到着時刻を入力する入力欄が表されてもよい。
【0101】
また、判定手段56は、移動需要それぞれに含まれる支払金額の合計である収入金額が、移動需要を送信したユーザ数に対応する運行コストに達しているか否かを判定する場合を説明したが、この収入金額には、自治体からの助成金等を加算してもよい。
【0102】
また、通知手段58は、各ユーザに支払金額が不足していることを通知する場合を説明したが、支払金額が少ないユーザにのみ当該不足していることを通知してもよい。例えば、通知手段58は、各ユーザの支払金額の平均額よりも少ない支払金額を送信した一部のユーザにのみ、支払金額が不足していることを通知する。なお、例えば、通知手段58は、1人あたりの運行コストよりも少ない支払金額を送信した一部のユーザにのみ、支払金額が不足していることを通知してもよい。
【0103】
また、上記実施形態では、通知手段58は、決定手段54によって決定された運行ダイヤを、移動需要を送信した各ユーザの端末装置12に通知する場合を説明したが、当該決定された運行ダイヤを交通機関の端末装置に通知してもよい。
【0104】
[付記]
本発明には、以下の付記が含まれる。
<付記1>
所定地域において交通機関の運行ダイヤを決定するためのプログラムであって、コンピュータを、
複数のユーザから、少なくとも希望乗降場所、利用日時、支払金額を含む移動需要の送信を受け付ける受付手段、
前記支払金額及び2以上のユーザの支払金額の合計に応じて、少なくとも乗降場所、運行日時を含む運行ダイヤを決定する決定手段、
前記決定された運行ダイヤを、前記移動需要を送信した各ユーザに通知する通知手段、
として機能させるプログラム。
【符号の説明】
【0105】
10…サーバ装置(コンピュータ)、50…記憶手段、52…受付手段、54…決定手段、58…通知手段

図1
図2
図3
図4
図5
図6
図7
図8
図9
図10