特許 7367627 情報処理装置、情報処理方法、およびプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-10-16

(45)【発行日】2023-10-24

(54)【発明の名称】情報処理装置、情報処理方法、およびプログラム

(51)【国際特許分類】

   G08G 1/00 20060101AFI20231017BHJP

   G06Q 10/02 20120101ALI20231017BHJP

   G06Q 50/30 20120101ALI20231017BHJP

   G16Y 10/40 20200101ALI20231017BHJP

【ＦＩ】

G08G1/00 D

G06Q10/02

G06Q50/30

G16Y10/40

【請求項の数】 18

(21)【出願番号】P 2020125738

(22)【出願日】2020-07-22

(65)【公開番号】P2022021873

(43)【公開日】2022-02-03

【審査請求日】2022-06-22

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】110002860

【氏名又は名称】弁理士法人秀和特許事務所

(72)【発明者】

【氏名】キン シン

【審査官】小林 勝広

(56)【参考文献】

【文献】特開２０２０－０６１１９０（ＪＰ，Ａ）

【文献】特開２０２０－０６７９３３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０８Ｇ １／００－９９／００

Ｇ０６Ｑ １０／００－１０／３０、３０／００－３０／０８、

５０／００－５０／２０、５０／２６－９９／００

Ｇ１６Ｙ １０／００－４０／６０

Ｇ１６Ｚ ９９／００

(57)【特許請求の範囲】

【請求項1】

複数のユーザが同乗する車両の運行スケジュールを決定する情報処理装置であって、
所定の乗車地点から前記車両への乗車を希望する一人以上のユーザから、乗車希望時刻を含む乗車リクエストをそれぞれ取得する第一の処理と、
前記乗車希望時刻の時間軸に対する密度を指定するパラメータを利用する密度ベースのクラスタリング手法に基づいて、一つ以上の前記乗車リクエストを一つ以上のグループにグループ化し、生成されたグループごとに、前記乗車地点に対する前記車両の到着時刻を決定する第二の処理と、
を実行する制御部を備える、情報処理装置。

【請求項2】

前記制御部は、全てのユーザについて、前記乗車希望時刻と前記到着時刻との差が所定値以下となるように、前記グループごとの前記到着時刻を決定する、
請求項１に記載の情報処理装置。

【請求項3】

前記制御部は、生成された各々のグループについて、前記ユーザの人数を用いて前記乗車希望時刻の加重平均を算出し、前記算出の結果に基づいて、前記グループごとの前記到着時刻を決定する、
請求項１または２に記載の情報処理装置。

【請求項4】

前記制御部は、生成された各グループに含まれる前記乗車リクエストの数に基づいて、対応する前記ユーザに対する前記車両の乗車料金を算出する、
請求項１から３のいずれか１項に記載の情報処理装置。

【請求項5】

前記制御部は、生成された各グループに含まれる前記乗車リクエストの数がより多い場合において、対応する前記ユーザに対する乗車料金をより低くする、
請求項４に記載の情報処理装置。

【請求項6】

前記制御部は、前記グループ化が完了した後で、算出した乗車料金を前記ユーザに提示し、予約の確定を行う、
請求項４または５に記載の情報処理装置。

【請求項7】

前記制御部は、前記ユーザから前記乗車リクエストを取得した段階で、既に生成された参加可能なグループがある場合に、いずれのグループに参加するかを前記ユーザに選択させる、
請求項４または５に記載の情報処理装置。

【請求項8】

前記制御部は、前記ユーザから前記乗車リクエストを取得した段階で、既に生成された参加可能なグループがある場合に、いずれのグループに参加するか、あるいは、新規のグループを生成するかを前記ユーザに選択させる、
請求項４または５に記載の情報処理装置。

【請求項9】

前記制御部は、グループごとに乗車料金を算出し、前記乗車料金をユーザに提示したうえで、前記ユーザに前記選択を行わせる、
請求項７または８に記載の情報処理装置。

【請求項10】

複数のユーザが同乗する車両の運行スケジュールを決定する情報処理装置が実行する情報処理方法であって、
所定の乗車地点から前記車両への乗車を希望する一人以上のユーザから、乗車希望時刻を含む乗車リクエストをそれぞれ取得する第一ステップと、
前記乗車希望時刻の時間軸に対する密度を指定するパラメータを利用する密度ベースのクラスタリング手法に基づいて、一つ以上の前記乗車リクエストを一つ以上のグループにグループ化し、生成されたグループごとに、前記乗車地点に対する前記車両の到着時刻を決定する第二ステップと、
を含む、情報処理方法。

【請求項11】

前記第二ステップでは、全てのユーザについて、前記乗車希望時刻と前記到着時刻との差が所定値以下となるように、前記グループごとの前記到着時刻を決定する、
請求項１０に記載の情報処理方法。

【請求項12】

前記第二ステップでは、生成された各々のグループについて、前記ユーザの人数を用いて前記乗車希望時刻の加重平均を算出し、前記算出の結果に基づいて、前記グループごとの前記到着時刻を決定する、
請求項１０または１１に記載の情報処理方法。

【請求項13】

前記第二ステップでは、生成された各グループに含まれる前記乗車リクエストの数に基づいて、対応する前記ユーザに対する前記車両の乗車料金を算出する、
請求項１０から１２のいずれか１項に記載の情報処理方法。

【請求項14】

前記第二ステップでは、生成された各グループに含まれる前記乗車リクエストの数がより多い場合において、対応する前記ユーザに対する乗車料金をより低くする、
請求項１３に記載の情報処理方法。

【請求項15】

前記第二ステップでは、前記グループ化が完了した後で、算出した乗車料金を前記ユーザに提示し、予約の確定を行う、
請求項１３または１４に記載の情報処理方法。

【請求項16】

前記第二ステップでは、前記ユーザから前記乗車リクエストを取得した段階で、既に生成された参加可能なグループがある場合に、いずれのグループに参加するかを前記ユーザに選択させる、
請求項１３または１４に記載の情報処理方法。

【請求項17】

前記第二ステップでは、グループごとに乗車料金を算出し、前記乗車料金をユーザに提示したうえで、前記ユーザに前記選択を行わせる、
請求項１６に記載の情報処理方法。

【請求項18】

請求項１０から１７のいずれか１項に記載の情報処理方法をコンピュータに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、同一の車両に複数のユーザが同乗して移動するための技術に関する。

【背景技術】

【0002】

交通渋滞の緩和や、燃料代の節約、環境対策などの目的で、一台の車両に複数のユーザが相乗りして移動を行う形態（ライドシェア）が、諸外国を中心に広がっている。
これに関して、例えば、特許文献１には、複数のユーザから取得した乗車リクエストに基づいて、相乗り車両の配車を行うシステムが開示されている。
輸送量が小規模である場合、需要に基づいて車両を都度派遣することで、運行ダイヤが定まっている路線バス等と比較して効率のよい輸送を行うことができる。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００３－３０８５９６号公報

【発明の概要】

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

【0004】

ユーザから送信されたリクエストに基づいて車両の配車を行う場合、全てのリクエストに個別に応えると、多くの車両が必要になってしまうという問題がある。

【0005】

本開示は上記の課題を考慮してなされたものであり、複数のユーザが同一の車両に乗車する交通システムにおいて、車両の適切な運行スケジュールを決定することを目的とする。

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

【0006】

本開示の第一の様態に係る情報処理装置は、
複数のユーザが同乗する車両の運行スケジュールを決定する情報処理装置であって、所定の乗車地点から前記車両への乗車を希望する一人以上のユーザから、乗車希望時刻を含む乗車リクエストをそれぞれ取得する第一の処理と、一つ以上の前記乗車リクエストを一つ以上のグループにグループ化し、生成されたグループごとに、前記乗車地点に対する前記車両の到着時刻を決定する第二の処理と、を実行する制御部を備えることを特徴とする。

【0007】

また、本開示の第二の様態に係る情報処理方法は、
複数のユーザが同乗する車両の運行スケジュールを決定する情報処理装置が実行する情報処理方法であって、所定の乗車地点から前記車両への乗車を希望する一人以上のユーザから、乗車希望時刻を含む乗車リクエストをそれぞれ取得する第一ステップと、一つ以上の前記乗車リクエストを一つ以上のグループにグループ化し、生成されたグループごとに、前記乗車地点に対する前記車両の到着時刻を決定する第二ステップと、を含むことを特徴とする。

【0008】

また、本開示の第三の態様は、上記の情報処理方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体である。

【発明の効果】

【0009】

本開示によれば、複数のユーザが同一の車両に乗車する交通システムにおいて、車両の
適切な運行スケジュールを決定することができる。

【図面の簡単な説明】

【0010】

【図1】第一の実施形態に係る交通システムの構成概略図である。

【図2】乗車希望時刻と到着時刻との関係を説明する図である。

【図3】第一の実施形態に係るユーザ端末１０のシステム構成図である。

【図4】乗車リクエストを説明する図である。

【図5】第一の実施形態に係るサーバ装置２０のシステム構成図である。

【図6】第一の実施形態においてサーバ装置が行う処理のフローチャートである。

【図7】サーバ装置が生成する運行スケジュールを説明する図である。

【図8】ステップＳ１２で行われる処理のフローチャートである。

【図9】第二の実施形態においてサーバ装置が行う処理のフローチャートである。

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

【0011】

本開示の第一の態様に係る情報処理装置は、複数のユーザから寄せられた乗車リクエストに基づいて、当該ユーザが乗車する車両（具体的には、定められたルートを走行するオンデマンドバス）の運行スケジュールを決定する装置である。乗車リクエストは、例えば、ユーザが車両に乗車する地点（停留所）と、乗車希望時刻とを含む。

【0012】

ユーザの乗車リクエストに応じて車両を運行させる交通システムにおいては、全てのユーザのリクエストに個別に応えた場合に、輸送効率が落ちてしまうという問題がある。
例えば、ある停留所から乗車を希望するユーザが３人おり、それぞれの乗車希望時刻が１５分ずつずれていた場合、３台の車両を運行する必要がある。しかし、各々の乗車希望時刻をずらしてもらい、３人を同時刻に乗車させた場合、１台の運行で済む。

【0013】

そこで、本開示の第一の形態に係る情報処理装置は、所定の乗車地点から前記車両への乗車を希望する一人以上のユーザから、乗車希望時刻を含む乗車リクエストをそれぞれ取得し、一つ以上の前記乗車リクエストを一つ以上のグループにグループ化し、生成されたグループごとに、前記乗車地点に対する前記車両の到着時刻を決定する。

【0014】

このように、乗車地点ごとに、複数の乗車リクエストをグループ化し、グループごとに車両の到着時刻を決定することで、個別に乗車リクエストを送信した複数のユーザを一度に車両に乗車させることが可能になり、輸送効率を向上させることができる。

【0015】

また、前記制御部は、前記乗車希望時刻の、時間軸に対する密度に基づいて前記乗車リクエストをグループ化することを特徴としてもよい。
例えば、時間軸上において、乗車希望時刻がより密集している箇所において、グループを優先的に生成するようにしてもよい。このような処理は、例えば、密度ベースのクラスタリング手法によって行うことができる。

【0016】

また、前記制御部は、全てのユーザについて、前記乗車希望時刻と前記到着時刻との差が所定値以下となるように、前記グループごとの前記到着時刻を決定することを特徴としてもよい。
かかる構成によると、ユーザ側にかかるコスト（典型的には待ち時間）を抑制することができる。

【0017】

また、前記制御部は、生成された各々のグループについて、前記ユーザの人数を用いて前記乗車希望時刻の加重平均を算出し、前記算出の結果に基づいて、前記グループごとの前記到着時刻を決定することを特徴としてもよい。
例えば、乗車希望時刻が同一（または実質同一）であるユーザが多いほど、当該時刻に
大きい重みを与えて加重平均を算出する。これにより、ユーザ側にかかる全体のコストを抑制することができる。

【0018】

また、前記制御部は、生成された各グループに含まれる前記乗車リクエストの数に基づいて、対応する前記ユーザに対する前記車両の乗車料金を算出することを特徴としてもよい。
車両がユーザをピックアップする回数を増やすと、時間的または金銭的なコストが増加する。そこで、グループに含まれる乗車リクエストの数に基づいて乗車料金を異ならせることで、増加コストを吸収することができる。

【0019】

また、前記制御部は、生成された各グループに含まれる前記乗車リクエストの数がより多い場合において、対応する前記ユーザに対する乗車料金をより低くすることを特徴としてもよい。
グループに含まれる乗車リクエストの数が多いほど、一度に多くのユーザを乗車させられる。すなわち、効率のよい配車ができるため、対応するユーザについては乗車料金を低く設定することができる。

【0020】

また、前記制御部は、前記グループ化が完了した後で、算出した乗車料金を前記ユーザに提示し、予約の確定を行うことを特徴としてもよい。
乗車料金を確認させるフェーズを実行することで、ユーザビリティを向上させることができる。

【0021】

また、前記制御部は、前記ユーザから前記乗車リクエストを取得した段階で、既に生成された参加可能なグループがある場合に、いずれのグループに参加するか（または、新規のグループを生成するか）を、前記ユーザに選択させることを特徴としてもよい。
また、前記制御部は、グループごとに乗車料金を算出し、前記乗車料金をユーザに提示したうえで、前記ユーザに前記選択を行わせることを特徴としてもよい。

【0022】

複数のグループが既に存在する場合、どちらに参加するかをユーザに選ばせることができる。その際、乗車料金を提示することで、「料金は安いが待つ必要があるグループ」と、「料金は高いがすぐに乗車できるグループ」といった選択肢をユーザに与えることが可能になる。また、当該ユーザのための新規のグループを生成することで、「料金は高いが希望時刻に乗車できるグループ」を提供することができる。

【0023】

以下、本開示の具体的な実施形態について図面に基づいて説明する。各実施形態に記載されているハードウェア構成、モジュール構成、機能構成等は、特に記載がない限りは開示の技術的範囲をそれらのみに限定する趣旨のものではない。

【0024】

（第一の実施形態）
第一の実施形態に係る交通システムの概略を図１に示す。本実施形態に係る交通システムは、オンデマンドバスに乗車するユーザに関連付いたユーザ端末１０と、オンデマンドバスの運行を管理するサーバ装置２０を含んで構成される。
オンデマンドバス（以下、単に車両と称する）は、運行路線と乗降地点（停留所）が予め定まっている交通機関であり、ユーザからの乗車リクエストに応じて随時運行される。

【0025】

車両への乗車を希望するユーザは、ユーザ端末１０を介して、乗車リクエストをサーバ装置２０に送信する。乗車リクエストは、例えば、乗車地点（乗車停留所）、乗車希望時刻、降車地点（降車停留所）などを含む。

【0026】

これらの情報は、例えば、ユーザ端末１０にインストールされた、交通システムを利用
するためのアプリケーションソフトウェアによって、生成および送信することができる。ただし、これらの情報は、必ずしも携帯端末を利用して生成されなくてもよい。例えば、ネットワークに接続可能な任意の端末（スマートフォン、携帯電話、タブレット端末、個人情報端末、またはウェアラブルコンピュータ等）やパーソナルコンピュータを利用して生成されてもよい。

【0027】

サーバ装置２０は、ユーザ端末１０から送信された乗車リクエストを収集し、車両の運行スケジュールを生成する。運行スケジュールは、例えば、運行経路上にある複数の停留所の到着時刻、各停留所で乗車させるユーザの数などを含む。

【0028】

本実施形態に係る交通システムにおいては、複数のユーザ端末１０、およびサーバ装置２０が、ネットワークによって相互に接続される。ネットワークには、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）やその他の通信網が採用されてもよい。また、ネットワークは、携帯電話等の電話通信網、Ｗｉ－Ｆｉ（登録商標）等の無線通信網を含んでもよい。

【0029】

本実施形態におけるサーバ装置２０は、同一の停留所から乗車を希望する複数のリクエストを受信した場合に、乗車リクエストのグループ化を行うことで運行コストを圧縮する。
図２は、複数の乗車リクエストと乗車時刻との関係を示した図である。
ここで、ある停留所から乗車を希望するユーザが４名いたとする。例えば、図２（Ａ）に示したように、それぞれの乗車希望時刻が、１３時２５分から１４時５分の間に分散していたものとする。この場合、全てのリクエストに応えようとした場合、車両が４台必要になる。一方で、図２（Ｂ）のように、複数の乗車リクエストをグループ化し、同時刻に４名を乗車させた場合、１台の車両で運行することができる。

【0030】

一方で、複数の乗車リクエストをグループ化すると、車両の運行コストは低下するが、ユーザが負担するコストが上昇するという問題がある。例えば、図示したように、４つの乗車リクエストをグループ化し、１３時４５分に車両を到着させた場合、乗車希望時刻と実際の乗車時刻との間に最大２０分のずれが発生する。ずれ時間が多く発生すると、交通機関に対する利便性が低下し、ユーザが離れてしまうおそれもある。

【0031】

本例においてユーザが負担するコストを減らす方法として、例えば、図２（Ｃ）のように、複数の乗車リクエストを２つのグループに分け、２台の車両を配車するという方法がある。このように、乗車リクエストをグループ化する方法を変えることで、車両の運行コストと、ユーザが負担するコストとのバランスを取ることができる。
本実施形態に係るサーバ装置２０は、所定の基準を用いて適切なグループ化処理を行うことで、前述した問題を解決する。

【0032】

次に、ユーザ端末１０の構成について説明する。図３は、ユーザ端末１０のシステム構成を示した図である。
ユーザ端末１０は、例えばスマートフォン、携帯電話、タブレットコンピュータ、個人情報端末、ノートブックコンピュータ、またはウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。ユーザ端末１０は、制御部１０１、記憶部１０２、無線通信部１０３、および入出力部１０４を含んで構成される。

【0033】

制御部１０１は、ユーザ端末１０が行う制御を司る演算装置である。制御部１０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することができる
。
制御部１０１は、乗車リクエスト部１０１１と、案内部１０１２の二種類の機能モジュ
ールを有して構成される。各機能モジュールは、後述する記憶部１０２に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

【0034】

乗車リクエスト部１０１１は、ユーザから、車両の乗車予約を行うためのリクエストを取得し、サーバ装置２０に送信する。具体的には、後述する入出力部１０４を介して、ユーザＩＤ、乗車地点（乗車停留所）、乗車希望時刻、降車地点（降車停留所）などを取得する。取得された情報は、乗車リクエストとしてサーバ装置２０へ送信される。図４は、生成された乗車リクエストの例である。また、乗車リクエスト部１０１１は、サーバ装置２０と対話することで、乗車予約を確定させる処理を行う。

【0035】

案内部１０１２は、乗車予約が確定した後で、サーバ装置２０から送信された、車両の運行についての情報（以下、運行情報）をユーザに提供する。運行情報は、複数の乗車リクエストに基づいてサーバ装置２０によって生成されたものであって、停留所の到着時刻等を含む。

【0036】

記憶部１０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部１０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。補助記憶装置には、制御部１０１で実行されるプログラムをアプリケーションとしてパッケージ化したものを記憶してもよい。また、これらのアプリケーションを実行するためのオペレーティングシステムを記憶してもよい。補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、制御部１０１によって実行されることで、以降に説明する処理が行われる。

【0037】

主記憶装置は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を含んでもよい。また、補助記憶装置は、ＥＰＲＯＭ（Erasable Programmable ROM）やハード
ディスクドライブ（ＨＤＤ、Hard Disk Drive）を含んでもよい。さらに、補助記憶装置
は、リムーバブルメディア、すなわち可搬記録媒体を含んでもよい。リムーバブルメディアは、例えば、ＵＳＢ（Universal Serial Bus）メモリ、あるいは、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）のようなディスク記録媒体である。

【0038】

無線通信部１０３は、ユーザ端末１０をネットワークに接続するための無線通信インタフェースである。無線通信部１０３は、例えば、無線ＬＡＮや３Ｇ、ＬＴＥ等の移動体通信サービスを介して、ネットワークへのアクセスを提供する。
入出力部１０４は、利用者が行った入力操作を受け付け、利用者に対して情報を提示する手段である。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。

【0039】

なお、図３に示した構成は一例であり、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。また、図示した以外の、主記憶装置および補助記憶装置の組み合わせによってプログラムの記憶ないし実行を行ってもよい。

【0040】

次に、サーバ装置２０の構成について説明する。
サーバ装置２０は、汎用のコンピュータにより構成することができる。すなわち、サーバ装置２０は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。なお、リムーバブルメディアは、例えば、ＵＳＢメモリ、あるいは、ＣＤやＤＶＤのようなディスク記録媒体であってもよい。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを実行することによって、後述するような、所定の目的に
合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。なお、サーバ装置２０は、単一のコンピュータで構成されてもよいし、互いに連携する複数台のコンピュータによって構成されてもよい。

【0041】

図５は、サーバ装置２０のシステム構成を示した図である。サーバ装置２０は、制御部２０１、記憶部２０２、および通信部２０３を含んで構成される。

【0042】

制御部２０１は、サーバ装置２０が行う制御を司る演算装置である。制御部２０１は、ＣＰＵなどの演算処理装置によって実現することができる。
制御部２０１は、乗車リクエスト取得部２０１１と、配車計画生成部２０１２の二種類の機能モジュールを有して構成される。各機能モジュールは、補助記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

【0043】

乗車リクエスト取得部２０１１は、複数のユーザ端末１０から乗車リクエストを取得し、記憶部２０２に一時的に記憶させる。取得され、記憶された乗車リクエストは、配車計画生成部２０１２によって利用される。
配車計画生成部２０１２は、収集した複数の乗車リクエストに基づいて、車両の運行スケジュールを生成する。具体的には、互いに乗車希望時刻が近い複数の乗車リクエストを、乗車地点（停留所）ごとにグループ化する処理と、グループ化の結果に基づいて、車両の運行スケジュールを生成する処理とを実行する。詳細な処理については後述する。

【0044】

記憶部２０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部２０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部２０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。主記憶装置および補助記憶装置については、記憶部１０２と同様であるため、詳細な説明は省略する。

【0045】

通信部２０３は、サーバ装置２０をネットワークに接続するための通信インタフェースである。通信部２０３は、例えば、ネットワークインタフェースボードや、無線通信のための無線通信回路を含んで構成される。

【0046】

次に、制御部２０１が行う処理の詳細について、図６に示すフローチャートを参照して説明する。図示した処理は、所定の周期で実行される。

【0047】

まず、ステップＳ１１で、乗車リクエスト取得部２０１１が、複数のユーザ端末１０から乗車リクエストを取得する。ユーザ端末１０は、例えば、所定の締め切り時刻（例えば、乗車希望時刻の３０分前）まで乗車リクエストを送信することができる。
取得した乗車リクエストは、所定のトリガが発生するまで蓄積される。トリガは、周期的（例えば、３０分おき等）に発生させてもよいし、定められた時刻に発生させてもよい。
所定のトリガが発生すると、処理はステップＳ１２へ遷移する。

【0048】

ステップＳ１２では、配車計画生成部２０１２が、（１）複数の乗車リクエストをグループ化する処理を実行し、（２）グループに対応する車両の到着時刻を決定し、（３）車両の運行スケジュールを生成する。

【0049】

図７を参照しながら説明する。ここでは、停留所Ａ，Ｂ，Ｃ，Ｄの順で車両が走行するものとする。また、ハッチングで示した領域は、乗車希望時刻が当該領域内にある複数の乗車リクエストを含むグループを表す。
配車計画生成部２０１２は、まず、グループ化する一つ以上の乗車リクエストを選択する処理を行う。この処理は、乗車地点（停留所）ごとに実行される。ここでは、停留所Ａについてグループ７０１とグループ７０２が生成され、停留所Ｂについてグループ７０３が生成され、停留所Ｃについてグループ７０４が生成されたものとする。

【0050】

次に、所定のルールに従い、グループに対応する車両の到着時刻を決定する。図中の白丸は到着時刻を示す。

【0051】

次いで、配車計画生成部２０１２が、車両の運行スケジュールを生成する。前述した処理によって、停留所ごとの車両の到着時刻が決まるため、当該到着時刻を通るように車両の運行スケジュールを生成する。図示した例では、符号７１１～７１４で示された、４台の車両の運行スケジュールが生成される。

【0052】

ここで、図８を参照して、ステップＳ１２において行われる処理をより詳細に説明する。
本ステップでは、所定の手法によって複数の乗車リクエストをグループ化する。所定の手法として、典型的にはｋ－ｍｅａｎｓといったクラスタリング手法を採用することができるが、複数の値をグループ化することができれば、どのような手法を採用してもよい。グループ化にクラスタリング手法を採用する場合、例えば、密度ベースのクラスタリング手法を採用することができる。

【0053】

また、クラスタリング以外の手法を用いる場合、所定の条件を満たすようにグループを生成することができる。所定の条件として、例えば、「乗車希望時刻が所定の時間幅（例えば、３０分）に含まれる複数の乗車リクエストをグループ化する」といったものが挙げられる。

【0054】

グループ化処理は、所定のパラメータを用いて行うことができる。
例えば、密度ベースのクラスタリングを行う場合、密度を指定するパラメータを利用することができる。また、単純に、乗車希望時刻が所定の時間幅に含まれる複数の乗車リクエストをグループ化する場合、当該時間幅を指定するパラメータを利用することができる。
グループの生成結果は、利用するパラメータによって変化しうる。また、グループの生成結果が変化すると、車両の運行スケジュールも変化しうる。そこで、本実施形態では、グループ化に用いるパラメータを複数生成して、パラメータごとに、異なるパターンのグループを生成する。そして、パターンごとに生成された複数の運行スケジュールを評価したうえで、最終的にどのパターンを採用するかを決定する。

【0055】

ステップＳ１２１では、グループ化に用いる複数のパラメータの候補を生成する。

【0056】

ステップＳ１２２では、生成したパラメータのうちの一つを用いて、停留所ごとに、一つ以上の乗車リクエストをグループ化する。
そして、ステップＳ１２３で、各グループに対応する到着時刻を決定する。グループに対応する到着時刻は、例えば、以下のような方法によって決定することができる。
（１）最も早い乗車希望時刻と、最も遅い乗車希望時刻との中間値
最も早い乗車希望時刻をＴ_１、最も遅い乗車希望時刻をＴ_２とした場合、
Ｔ_到着時刻＝（Ｔ_１＋Ｔ_２）／２
を到着時刻とする方法である。
（２）ユーザの人数を用いて算出した、乗車希望時刻の加重平均
時刻Ｔ_１…Ｔ_ｎに乗車を希望するユーザがそれぞれＵ_１…Ｕ_ｎ人ずついた場合、
Ｔ_到着時刻＝（Ｔ_１Ｕ_１＋Ｔ_２Ｕ_２＋…＋Ｔ_ｎＵ_ｎ）／（Ｕ_１＋Ｕ_２＋…＋Ｕ_ｎ）
を到着時刻とする方法である。例えば、１６時４０分に３人、１７時０分に２人、１７時１５分に１人が乗車を希望していた場合、１６時５２分が到着時刻となる。
（３）人数が最も多い乗車希望時刻
ユーザの数が最も多い乗車希望時刻を到着時刻とする方法である。
他の手法も採用可能である。例えば、グループに属する乗車リクエストのうち、最も遅い乗車希望時刻を到着時刻としてもよい。

【0057】

次に、ステップＳ１２４で、決定したグループによって、車両の運行スケジュールを生成し、これを評価する。例えば、図７に示したような運行スケジュールによって車両を運行した場合におけるコストを算出する。コストは、車両の運行コストと、ユーザが負担するコスト（以下、ユーザコスト）を含む。ユーザコストとは、例えば、乗車希望時刻と到着時刻との差をユーザごとに累計した値とすることができる。
ステップＳ１２２～Ｓ１２４の処理は、ステップＳ１２１で生成した複数のパラメータのそれぞれについて実行される。

【0058】

ステップＳ１２５では、パラメータごとに取得された評価結果に基づいて、最終的に採用するパターンを決定する。例えば、コストの累計が最も少ないパターンを選択してもよい。

【0059】

また、本ステップでは、所定の条件を満たさないパターンを除外してもよい。例えば、以下のような条件に該当するパターンについては除外してもよい。
（１）乗車希望時刻と到着時刻との差が所定値以上となるユーザが存在する場合（所定値は、固定の値であってもよいし、ユーザごとに設定された値であってもよい）
（２）ユーザコストが所定値を超過している場合
（３）ユーザの人数が車両の定員を超過している場合
他の条件を採用することもできる。

【0060】

以上の処理により、車両の運行スケジュールが確定する。
次に、ステップＳ１２６で、グループごとの乗車料金を決定する。車両の乗車料金は、例えば、同一の停留所から同一の車両に乗車するユーザの人数、または、同一の車両に乗車するユーザの述べ人数に基づいて決定することができる。

【0061】

例えば、一回の運行コストが３０００円であって、同一の停留所から６人が乗車する場合、１人あたりの乗車料金を５００円以上に設定することができる。なお、乗車料金を、同一の車両に乗車するユーザの述べ人数に基づいて決定する場合、乗車距離によって乗車料金を調整してもよい。いずれの場合であっても、同一の停留所から同一の車両に乗車するユーザの人数、または、同一の車両に乗車するユーザの述べ人数が多いほど、１人あたりの乗車料金は低くなる。車両の乗車料金は、予め記憶された数式やテーブルに基づいて算出してもよい。

【0062】

図６に戻って説明を続ける。
運行スケジュールが確定すると、ステップＳ１３で、配車計画生成部２０１２が、通知データを生成する。通知データとは、確定した到着時刻と、乗車料金をユーザに通知するためのデータである。
通知データは、ユーザ端末１０へ送信され、ユーザがこれを承認すると、乗車予約が確定する（ステップＳ１４）。また、確定した乗車予約に基づいて、サーバ装置２０が車両の配車を行う。例えば、車両が手動運転車両である場合、サーバ装置２０は、ドライバーに運行時刻を通知するためのデータを生成する。また、車両が自動運転車両である場合、サーバ装置２０は、車両に対する走行指令を生成する。
また、サーバ装置２０は、当該車両の運行情報をユーザ端末１０に送信する。運行情報
は、案内部１０１２によってユーザに提供される。

【0063】

以上説明したように、第一の実施形態に係る交通システムは、同一の停留所から乗車を希望するユーザが複数いた場合に、当該複数のユーザをグループ化し、当該停留所への車両の到着時刻を決定する。かかる構成によると、ユーザの利便性を損なわない範囲において、車両の運行コストの低減を図ることができる。

【0064】

（第一の実施形態の変形例）
第一の実施形態では、ステップＳ１１において、所定のトリガが発生するまで乗車リクエストを蓄積したが、ユーザが希望する場合、ステップＳ１２１～Ｓ１２４の処理を行うことなく、即座にグループを確定させてもよい。この場合、グループに属するユーザが１人となるため、複数人が同時に乗車する場合と比較して乗車料金は高額となるが、希望の時刻に確実に乗車することができる。

【0065】

また、第一の実施形態では、ステップＳ１４において、通知データの承認可否をユーザに求めたが、ユーザがこれを承認しなかった場合、該当する乗車リクエストを再度待ち状態とし、再度のグループ化を試行してもよい。これにより、例えば、「乗車料金が高いため、より多くの人数が集まるまで待ちたい」といった希望に応えることが可能になる。

【0066】

（第二の実施形態）
第一の実施形態に係る交通システムにおいては、グループが生成された後で、新しいユーザから乗車リクエストが送信される場合が考えられる。しかし、その都度グループを再生成することは現実的ではない。
第二の実施形態は、これに対応すべく、グループが生成された後において、新規の乗車リクエストを受け入れる実施形態である。

【0067】

図９は、第二の実施形態においてサーバ装置２０が実行する処理のフローチャートである。
第二の実施形態では、ユーザ端末１０から乗車リクエストを受信した際に、参加可能なグループ、具体的には、以下の条件を満たすグループが存在するかをステップＳ１０Ａにおいて判定する。
（１）乗車リクエストに含まれる乗車地点（停留所）に対応するグループ
（２）乗車リクエストに含まれる乗車希望時刻と到着時刻との差が所定の値以内であるグループ
条件を満たすグループが存在する場合、処理はステップＳ１０Ｂに遷移する。

【0068】

ステップＳ１０Ｂでは、グループに参加するか否か（グループが複数ある場合、どのグループに参加するか）を問い合わせるデータをユーザ端末１０に送信し、ユーザの選択を取得する。当該データには、グループごとの車両の到着時刻、および、乗車料金が含まれる。そして、ユーザの選択に基づいて、ステップＳ１４において予約を確定させる。
グループごとに到着時刻と乗車料金を提示することで、「料金は安いが待つ必要があるグループ」、「料金は高いがすぐに乗車できるグループ」といった選択肢をユーザに与えることができる。

【0069】

なお、ステップＳ１０Ｂにおいて、参加するグループを選択する代わりに、「新規のグループを生成する」という選択肢をユーザに与えてもよい。ユーザが新規のグループを生成することを希望した場合、当該ユーザのみを含むグループを新規に生成することができる。この場合、グループに属するユーザが１人となるため、複数人が同時に乗車する場合と比較して乗車料金は高額となるが、希望の時刻に確実に乗車することができる。

【0070】

ステップＳ１０Ａにおいて、条件を満たすグループが存在しない場合、処理はステップＳ１１に遷移する。すなわち、第一の実施形態と同様に、トリガが発生するまで待機してグループの生成を行う。なお、第一の実施形態の変形例と同様に、ユーザが希望する場合、ステップＳ１２１～Ｓ１２４の処理を行うことなく、即座にグループを確定させてもよい。

【0071】

第二の実施形態によると、既にグループが生成された状態であっても、新規の乗車リクエストを受け付けることが可能になる。

【0072】

（変形例）
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

【0073】

また、実施形態の説明では、オンデマンドバスの路線が一つであるとしたが、路線や運行方向（上り・下り）が複数ある場合、目的地や方向が同一であるユーザ（すなわち、同一の車両に乗車する利益があるユーザ）をグループ化の対象としてもよい。

【0074】

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

【0075】

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

【符号の説明】

【0076】

１０・・・ユーザ端末
１０１・・・制御部
１０２・・・記憶部
１０３・・・無線通信部
１０４・・・入出力部
２０・・・サーバ装置
２０１・・・制御部
２０２・・・記憶部
２０３・・・通信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】