JP7378831B2 - 情報処理装置、情報処理方法及びプログラム - Google Patents

Description

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

バス等の交通機関において、乗客からの利用要求に応じて運行経路を動的に計画するデマンドバスシステムが提案されている。例えば特許文献１では、利用者からの利用要求に応じてバスの運行計画を生成するデマンド型運行管理システムであって、第１利用者が乗降する第１の乗降地点と、第２利用者が乗降する第２乗降地点との中間地点を停車位置とした運行計画を生成するデマンド型運行管理システムが開示されている。

特許第６２７３６５６号公報

しかしながら、特許文献１に係る発明は、基準運行ダイヤで予め定められた運行ルートから時間的に許容された範囲内で運行できるよう運行計画を生成するものであり、許容範囲外の運行計画を生成することができない。

一つの側面では、運行計画の動的生成を好適に行うことができる情報処理装置等を提供することを目的とする。

一つの側面に係る情報処理装置は、複数の乗客が相乗りする車両の利用を所定の時点までに既に予約している前記乗客の乗車地点又は降車地点と、該乗客の乗車時刻又は降車時刻とを示す第１乗客情報を取得する第１取得部と、前記所定の時点までに取得した前記第１乗客情報に基づき、前記既に予約している乗客を複数の集合に分類する分類部と、前記集合毎に、複数の前記乗客を乗車又は降車させながら運行する経路を示す運行計画を生成する生成部と、前記車両の利用を前記所定の時点以降に申し込んだ新たな前記乗客の乗車地点又は降車地点と、該乗客の乗車時刻又は降車時刻とを示す第２乗客情報を取得する第２取得部とを備え、前記所定の時点以降に前記第２乗客情報を取得した場合、前記分類部は、該第２乗客情報に基づき、前記既に予約している乗客の前記集合に前記新たな乗客を分類すべきか否かを判定し、前記新たな乗客を前記集合に分類すべきと判定した場合、前記生成部は、前記既に予約している乗客が乗車する前記車両に変更が生じない範囲で、前記集合に対応する前記車両に前記新たな乗客を乗車又は降車させるように、生成済みの前記運行計画を更新することを特徴とする。

一つの側面では、運行計画の動的生成を好適に行うことができる。

運行計画システムの構成例を示す模式図である。 サーバの構成例を示すブロック図である。 端末の構成例を示すブロック図である。 ユーザＤＢ、バスＤＢ、運転手ＤＢ、及び運行計画ＤＢのレコードレイアウトの一例を示す説明図である。 地点指定画面の一例を示す説明図である。 バス予約画面の一例を示す説明図である。 運行計画生成処理に関する説明図である。 運行計画の更新処理に関する説明図である。 運行計画の更新処理に関する説明図である。 予約確認画面の一例を示す説明図である。 運行状況確認画面の一例を示す説明図である。 サーバが実行する処理手順の一例を示すフローチャートである。 端末が実行する処理手順の一例を示すフローチャートである。 実施の形態２の概要を示す説明図である。 運行計画の一覧画面の一例を示す説明図である。 運転手情報の表示画面の一例を示す説明図である。 運転手情報の表示画面の一例を示す説明図である。 運転手端末の表示画面の一例を示す説明図である。 事業者端末が実行する処理手順の一例を示すフローチャートである。 運転手端末が実行する処理手順の一例を示すフローチャートである。

以下、本発明をその実施の形態を示す図面に基づいて詳述する。
（実施の形態１）
図１は、運行計画システムの構成例を示す模式図である。本実施の形態では、複数の乗客が相乗りする車両（バス）の運行計画を動的に生成する運行計画システムについて説明する。運行計画システムは、情報処理装置１、ユーザ端末２、２、２…、バス３、事業者端末４、運転手端末５を含む。各装置は、インターネット等のネットワークＮを介して相互に通信接続されている。なお、本実施の形態では、車両の一例としてバスをあげるが、バスでなくとも、乗用車、シャトル等複数の乗客を乗車させることができる乗り物であれば、車両の種類は限定されない。

本実施の形態では、所定の出発地と目的地との間を往復するバス３について運行計画を生成する。例えばバス３は、ホテルを出発地とし、空港を目的地とするシャトルバスであるが、出発地及び目的地は特に限定されない。本実施の形態では、本システムの会員として予め登録されているユーザからのバス３の利用要求に応じて、バス３の運行経路、運行時刻等を動的に変更した運行計画を生成する。

情報処理装置１は、種々の情報処理、情報の送受信が可能な情報処理装置であり、例えばサーバ装置、パーソナルコンピュータ等である。本実施の形態では情報処理装置１がサーバ装置であるものとし、以下では簡潔のためサーバ１と読み替える。サーバ１は、各ユーザからバス３の利用要求を受け付け、運行計画を生成してバス３の運転手に通知する。

ユーザ端末２は、本システムを利用するユーザ（乗客）が操作する端末装置であり、例えばスマートフォン、タブレット端末等の携帯端末である。ユーザ端末２には、本システムに係る機能を実現するためのアプリケーションプログラムが予めインストールされており、ユーザ端末２は、当該アプリケーションプログラムを実行して後述の処理を行う。サーバ１は、ユーザ端末２から利用要求を受け付けて運行計画を生成する。

バス３は、上述の如く出発地と目的地との間を往復するシャトルバスであり、サーバ１からの指示に従って運転手が運転を行うデマンドバスである。なお、バス３はデマンドバスと呼ばれる車両（バス）に限定されず、サーバ１からの指示に従って運行する車両であればよい。また、図１では図示の便宜上、バス３を一台のみ図示してあるが、本実施の形態では複数のバス３の運行計画を生成するものとする。例えばサーバ１は、運転手が携帯する携帯端末（運転手端末５）等との間で通信を行い、バス３の運行計画を運転手に通知すると共に、バス３の位置情報（例えばＧＰＳ（Global Positioning System）座標値）を逐次取得し、管理する。

事業者端末４は、バス３を運行する運行事業者（バス会社）の端末装置であり、例えばパーソナルコンピュータ等である。運転手端末５は、個々のバス３の運転手が携帯する端末装置であり、例えばスマートフォン、タブレット端末等である。サーバ１は、ユーザからの利用要求に応じて生成された運行計画を事業者端末４、運転手端末５等に通知し、バス３を運行させる。

なお、本システムと連携してバス３を運行させる運行事業者は単一であってもよく、複数であってもよい。また、本実施の形態ではバス３の運転手と連携する際に、携帯端末である運転手端末５と通信を行うが、例えばバス３に搭載された車載システムと通信を行い、運行計画を運転手に通知するようにしてもよい。

図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、主記憶部１２、通信部１３、及び補助記憶部１４を備える。
制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有し、補助記憶部１４に記憶されたプログラムＰ１を読み出して実行することにより、種々の情報処理、制御処理等を行う。主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の一時記憶領域であり、制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。通信部１３は、通信に関する処理を行うための通信モジュールであり、外部と情報の送受信を行う。

補助記憶部１４は、大容量メモリ、ハードディスク等の不揮発性記憶領域であり、制御部１１が処理を実行するために必要なプログラムＰ１、その他のデータを記憶している。また、補助記憶部１４は、ユーザＤＢ１４１、バスＤＢ１４２、運転手ＤＢ１４３、及び運行計画ＤＢ１４４を記憶している。ユーザＤＢ１４１は、ユーザの情報を格納するデータベースである。バスＤＢ１４２は、バス３の情報を格納するデータベースである。運転手ＤＢ１４３は、バス３を運転する運転手の情報を格納するデータベースである。運行計画ＤＢ１４４は、バス３の運行計画に関する情報を格納するデータベースである。

なお、補助記憶部１４はサーバ１に接続された外部記憶装置であってもよい。また、サーバ１は複数のコンピュータからなるマルチコンピュータであっても良く、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。

また、本実施の形態においてサーバ１は上記の構成に限られず、例えば操作入力を受け付ける入力部、画像を表示する表示部等を含んでもよい。また、サーバ１は、ＣＤ（Compact Disk）－ＲＯＭ、ＤＶＤ（Digital Versatile Disc）－ＲＯＭ等の可搬型記憶媒体１ａを読み取る読取部を備え、可搬型記憶媒体１ａからプログラムＰ１を読み取って実行するようにしても良い。あるいはサーバ１は、半導体メモリ１ｂからプログラムＰ１を読み込んでも良い。

図３は、ユーザ端末２の構成例を示すブロック図である。ユーザ端末２は、制御部２１、主記憶部２２、通信部２３、表示部２４、入力部２５、位置情報取得部２６、補助記憶部２７を備える。
制御部２１は、一又は複数のＣＰＵ、ＭＰＵ等の演算処理装置を有し、補助記憶部２７に記憶されたプログラムＰ２を読み出して実行することにより、ユーザ端末２に係る種々の情報処理、制御処理等を行う。主記憶部２２は、ＲＡＭ等の一時記憶領域であり、制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。通信部２３は、通信を行うためのアンテナ、処理回路等を含み、外部と情報の送受信を行う。表示部２４は、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ等の表示装置であり、制御部２１から与えられた画像を表示する。入力部２５は、タッチパネル、メカニカルキー等の操作インターフェイスであり、操作内容を制御部２１に入力する。位置情報取得部２６は、ユーザ端末２の位置情報（例えばＧＰＳ座標値）を取得する通信モジュールである。補助記憶部２７はＲＯＭ（Read Only Memory）等の不揮発性記憶領域であり、制御部２１が処理を実行するために必要なプログラムＰ２、その他のデータを記憶している。

なお、ユーザ端末２は、可搬型記憶媒体２ａを読み取る読取部を備え、可搬型記憶媒体２ａからプログラムＰ２を読み取って実行するようにしても良い。あるいはユーザ端末２は、半導体メモリ２ｂからプログラムＰ２を読み込んでも良い。

図４は、ユーザＤＢ１４１、バスＤＢ１４２、運転手ＤＢ１４３、及び運行計画ＤＢ１４４のレコードレイアウトの一例を示す説明図である。
ユーザＤＢ１４１は、ユーザＩＤ列、ユーザ名列、アドレス列、ユーザ情報列を含む。ユーザＩＤ列は、各ユーザを識別するためのユーザＩＤを記憶している。ユーザ名列、アドレス列、ユーザ情報列はそれぞれ、ユーザＩＤと対応付けて、ユーザの氏名、メールアドレス、及びその他のユーザ情報を記憶している。ユーザ情報列には、例えばユーザの年齢、性別、国籍、所属団体（会社等）、趣味、居住エリア、ユーザのランク（バス３の利用頻度等に応じた顧客優良度）などの属性情報（乗客属性情報）が記憶されている。

バスＤＢ１４２は、バスＩＤ列、運行会社列、バス情報列を含む。バスＩＤ列は、各バス３を識別するためのバスＩＤを記憶している。運行会社列及びバス情報列はそれぞれ、バスＩＤと対応付けて、運行会社（運行事業者）の社名、及びバス３に関する情報を記憶している。バス情報列には、例えばバス３の乗車可能人数、座席番号等のほかに、バス３の評価値を表す車両ランク、各座席の評価値を表す座席ランク、女性専用車両であるか否か、福祉車両であるか否か、車両内で提供するサービス（例えば観光ガイドサービス、マッサージサービス、ネイルサービス等）などの属性情報（車両属性情報）が記憶されている。

運転手ＤＢ１４３は、運転手ＩＤ列、運転手名列、運転バス列、運転手属性列を含む。運転手ＩＤ列は、バス３を運転する運転手を識別するための運転手ＩＤを記憶している。運転手名列、運転バス列、及び運転手属性列はそれぞれ、運転手ＩＤと対応付けて、運転手の氏名、運転するバス３のバスＩＤ、及び運転手に関するその他の情報を記憶している。運転手属性列には、例えば運転手が会話可能な言語、ユーザからの運転手の評価値、性別等の運転手属性情報が記憶されている。

運行計画ＤＢ１４４は、バスＩＤ列、現在位置列、運行計画列を含む。バスＩＤ列は、各バス３を識別するためのバスＩＤを記憶している。現在位置列及び運行計画列はそれぞれ、バスＩＤと対応付けて、バス３の現在位置、及びバス３の運行計画に関する情報を記憶している。例えば運行計画列には、バス３が順次停車を予定している第１地点、第２地点…それぞれについて、各地点の位置、到着予定時刻、乗降人数等が記憶されている。

図５は、地点指定画面の一例を示す説明図である。以下では本実施の形態の概要を説明する。
上述の如く、バス３は出発地と目的地との間を往復するシャトルバスであり、出発地で乗客を乗車させて目的地へと向かうと共に、目的地で再び乗客を乗車させて出発地へと戻る。なお、バス３が停車する地点は出発地及び目的地の２地点に限定されず、出発地及び目的地の間のその他の地点でも乗客を乗車又は降車させるようにしてもよい。サーバ１は、各ユーザのユーザ端末２からバス３の利用要求を受け付け、目的地に向かう往路と、出発地に戻る復路とを規定する運行計画を生成する。

ユーザ端末２はまず、図５に示す地点指定画面を表示し、ユーザが乗車を希望する希望乗車地点と、降車を希望する希望降車地点との指定入力を受け付ける。なお、以下の説明では便宜上、ユーザが乗車を希望する希望乗車地点と、降車を希望する希望降車地点とを総称する場合に、単に「希望地点」と記す。例えばユーザ端末２は、地点指定画面において地図画像を表示し、ユーザから希望地点の指定入力を受け付ける。あるいはユーザ端末２は、希望地点についてテキスト入力を受け付け、入力されたテキストに基づいて候補地をサーバ１に検索させて、候補地から希望地点の指定入力を受け付けるようにしてもよい。また、ユーザ端末２は、予め候補地として登録されている地点を複数表示し、表示した候補地から希望地点の指定入力を受け付けるようにしてもよい。また、ユーザ端末２は、位置情報取得部２６を介して取得した位置情報に基づきユーザの現在位置を割り出し、ユーザの現在位置を希望乗車地点として指定するようにしてもよい。

図６は、バス予約画面の一例を示す説明図である。地点指定画面で希望地点の指定入力を完了後、ユーザ端末２は図６に示すバス予約画面に遷移する。
ユーザ端末２は、バス予約画面の上部に、バス３の出発地及び目的地を示す地図画像を表示する。また、ユーザ端末２はバス予約画面に時刻アイコン６１、荷物アイコン６２、人数アイコン６３をそれぞれ表示する。

まずユーザ端末２は、時刻アイコン６１への操作入力を受け付けた場合、時刻指定欄６４をポップアップ表示する。ユーザ端末２は時刻指定欄６４により、希望乗車時刻又は希望降車時刻の指定入力を受け付ける。希望乗車時刻及び希望降車時刻は、ユーザがバス３への乗車を希望する時刻、及び目的地でバス３からの降車を希望する時刻である。例えばユーザ端末２は、希望乗車時刻又は希望降車時刻のいずれか一方について指定入力を受け付ける。なお、以下の説明では便宜上、希望乗車時刻及び希望降車時刻を総称する場合、単に「希望時刻」と記す。

また、ユーザ端末２は、荷物アイコン６２又は人数アイコン６３への操作入力を受け付けた場合、荷物／人数指定欄６５をポップアップ表示する。ユーザ端末２は荷物／人数指定欄６５により、ユーザが持つ荷物情報（例えば、荷物の種類（バッグ、スーツケース等）、重さ、大きさ、数等）、及び乗車するユーザの人数について指定入力を受け付ける。

サーバ１は、上述の如くユーザ端末２に入力された各種情報、すなわち希望地点、希望時刻、荷物情報、人数等を示す乗客情報をユーザ端末２から取得し、利用要求を受け付ける。サーバ１は、取得した乗客情報に基づき、各バス３がユーザ（乗客）を乗車又は降車させながら運行する経路を規定する運行計画を生成する。

なお、本実施の形態ではバス３がユーザ（及びユーザの手荷物）のみ乗せて運行するものとするが、本実施の形態はこれに限定されるものではなく、荷物のみの運送依頼を受け付けてもよい。ここで言う荷物は、例えばバス３に乗車しないものの、ホテルへの荷物の運搬を希望するユーザの荷物のように、バス３の乗客と無関係の荷物を含む。例えばサーバ１は、上記の乗客情報のほかに、目的地への運送を希望する荷物の運送依頼（例えば発送地、目的地、希望発送時刻、希望到着時刻等を含む）をユーザ端末２から受け付ける。この場合にサーバ１は、荷物も乗客（ユーザ）と同様に乗車物の一つと捉え、下記のクラスタリングを行って運行計画を生成する。このように、サーバ１はユーザに加えて荷物を運送する運行計画を生成してもよい。

図７は、運行計画生成処理に関する説明図である。図７に基づき、運行計画の生成処理の概要について説明する。
サーバ１は、各ユーザのユーザ端末２、２、２…から、希望地点及び希望時刻を含む乗客情報（第１乗客情報）を取得する。サーバ１は、各ユーザからの乗客情報が示す希望地点及び希望時刻に基づき、各ユーザを複数のクラスタ（集合）に分類するクラスタリングを行う。

図７に、クラスタリングに係るベクトル空間を概念的に図示する。図７において横軸は時間を、縦軸は地理的空間（地点）を表す。また、横軸を挟んで上側は往路におけるベクトル空間を、下側は復路におけるベクトル空間を表す。また、縦軸の点線は所定時間（例えば３０分間）毎に区切られる時間帯の境界を表す。なお、実際には３次元以上の多次元空間でクラスタリングを行うが、図７では図示の便宜上、ベクトル空間を２次元で図示している。

サーバ１は、各ユーザの希望地点及び希望時刻に基づき、各ユーザをベクトル空間にマッピングする。そしてサーバ１は、所定時間で区切った時間帯毎に、一又は複数のユーザをグルーピングするクラスタリングを行い、各クラスタを生成していく。クラスタリングの手法は特に限定されないが、例えばサーバ１は、ｋ－ｍｅａｎｓ法、ｃ－ｍｅａｎｓ法等の手法を用いてクラスタを生成する。

なお、サーバ１が所定の時間帯毎にクラスタリングを行うのは、本実施の形態では空港への送迎を想定しているため、航空機の離発着時刻の所定時間前までに送迎が完了するようにするためである。所定時間で区切った時間帯毎にクラスタを生成することで、目的地への送迎を好適に行うことができる。

本実施の形態でバス３は、出発地及び目的地の間を往復するシャトルバスであるため、サーバ１は、往路で乗車するユーザと、復路で乗車するユーザとを別々にクラスタリングする。すなわち、サーバ１は、バス３の目的地を希望降車地点とする乗客情報をユーザ端末２から取得した場合、当該ユーザ端末２のユーザは往路側のベクトル空間にマッピングし、クラスタリングを行う。バス３の目的地を希望乗車地点とする乗客情報をユーザ端末２から取得した場合、当該ユーザ端末２のユーザは復路側のベクトル空間にマッピングし、クラスタリングを行う。

サーバ１は、希望地点及び希望時刻が近接する一又は複数のユーザをグルーピングし、クラスタを生成する。サーバ１は、上記のクラスタリング結果に基づき、各バス３の運行計画を生成する。

具体的には、サーバ１は、各クラスタにバス３を割り当て、クラスタ毎に各ユーザを乗車させる運行計画を生成する。例えばサーバ１は、図７に示すように、ある時間帯の往路（又は復路）のクラスタに一のバス３を割り当てた後、次の時間帯で当該バス３に割り当てる復路のクラスタを選択し、当該クラスタに属するユーザを乗降させるように運行させる。さらにサーバ１は、次の時間帯の往路のクラスタを選択し、運行させる。サーバ１は、本システムで運行を指示する複数のバス３、３、３…にそれぞれクラスタの割り当てを行い、全てのクラスタについてユーザを乗車させるよう運行計画を生成する。

例えばサーバ１は、クラスタ内の各ユーザの希望地点がそれぞれ異なる場合、各ユーザを乗車又は降車させる乗車地点又は降車地点（以下、適宜に「乗降地点」と記す）と、各ユーザを乗車又は降車させる乗車時刻又は降車時刻（以下、適宜に「乗降時刻」と記す）とを定め、各ユーザを乗車又は降車させながら運行する最適経路を推定する。サーバ１は、個々のクラスタについて最適経路を推定し、運行計画を完成させる。

本実施の形態でサーバ１は、上記の運行計画を、巡回セールスマン問題の手法を用いて生成する。すなわちサーバ１は、複数のバス３、３、３…が与えられる場合に、バス３、３、３…により全てのユーザを乗降させる組合せの最適解を見つけるという組み合わせ最適化問題に帰着させて運行計画を生成する。例えばサーバ１は、各ユーザの待ち時間、クラスタ間のバス３の待機時間、バス３の運行時間、運行距離等に基づき、運行計画を評価するためのコスト値を算出する。サーバ１は、コスト値が最小化するように運行計画を生成する。

この場合にサーバ１は、個々のバス３の総運行時間、出発地と目的地との間の往復回数等について制約条件を設け、制約条件下で運行計画を生成するようにしてもよい。これにより、バス３の運転手の労働環境の管理を好適に行うことができる。

また、サーバ１は、全てのバス３、３、３…のうち、乗客が無乗車であるバス３の台数に応じて各バス３の運行計画を生成すると好適である。乗客が無乗車であるバス３とは、例えば所定の車両基地に待機していて運行していないバス３、乗客を乗せずに路上で待機しているバス３、乗客を乗車させずに運行しているバス３（回送しているバス３）などである。例えばサーバ１は、車両基地に待機している待機台数が多いほどコスト値を低く算出することで、全体としてバス３の運行台数を減らすように運行計画を生成する。また、例えばサーバ１は、路上に待機しているバス３の台数、又は乗客を乗車させずに運行しているバス３の台数が少ないほどコスト値が低くなるように算出することで、バス３の運行の無駄を減らすように運行計画を生成する。これにより、乗客数の偏りが解消され、適切なバス３の運行を行うことができる。

なお、巡回セールスマン問題は運行計画の最適化手法の一例であって、サーバ１は他のアルゴリズムに基づいて運行計画の最適化を行ってもよい。

運行計画の生成は、一度だけ行ってもよいし、定期的又は予約状況の変化等に応じて複数回行ってもよい。例えばサーバ１は、所定の予約確定時点（例えば、バスの運営会社への運行当日に手配するバスの台数を発注する期限（例えば運行当日の午前０時）までに、バス予約画面を介して予約を申し込んだユーザについて運行計画を生成し、予約を確定させる。この場合にサーバ１は、予定確定時点までクラスタの生成を繰り返し、運行計画を逐次的に生成する。例えばサーバ１は、既にユーザＡ、Ｂをあるクラスタに分類して運行計画を生成済みであっても、新たにユーザＣからバス３の利用要求（予約）を受け付けた場合に、ユーザＢを除外してユーザＡ、Ｃを同じクラスタに分類する方が運行計画のコストが低い場合、ユーザＡ、Ｃを同じクラスタとして再度クラスタリングを行う。このように、サーバ１は、ユーザが属するグループ（クラスタ）を繰り返し入れ替え、運行計画を逐次的に生成する。予約確定時点を経過した場合は予約済みのユーザについてグループの入れ替えは生じず、後述の運行計画の更新処理はグループの入れ替えが生じない範囲で行われる。

上記の運行計画の生成時に、サーバ１は、ユーザを乗車又は降車させる乗降時刻が、ユーザが指定した希望時刻とは異なる時刻とした運行計画を生成してもよい。例えばサーバ１は、利用要求を受け付ける場合に、希望時刻からユーザが許容する許容時間の設定入力を受け付け、乗客情報としてユーザ端末２から取得する。サーバ１は、図７で示すように、許容時間の範囲内でベクトル空間上のユーザの位置を変動させ、ユーザを乗車させるバス３を決定する。

この場合、後述するように、サーバ１は許容時間に応じてユーザの乗車料金を変動させると好適である。これにより、運行計画の最適化を容易に行うことができる。

また、サーバ１は、乗降時刻だけでなく、ユーザを乗車又は降車させる乗車地点又は降車地点を、ユーザの希望地点とは異なる地点としてもよい。例えば、サーバ１は、希望地点とは異なる地点で乗車させる方が運行時間が基準時間以上短くなる場合、希望地点とは異なる地点としてもよい。例えばサーバ１は、ユーザの希望乗車地点がある道路の一の車線側の地点である場合において、反対車線の地点で乗車させる方が運行時間が短くなる場合、反対車線の地点を乗車地点とする。あるいはサーバ１は、現在のバス３の経路上において、ユーザの希望乗車地点から最も近い地点を乗車地点としてもよい。その際、乗車地点を、地図上の目印となる地点（交差点、施設など）としてもよい。

この場合、例えばサーバ１は、後述するように、実際に設定される乗車地点をユーザ端末２に通知すると好適である。これにより、ユーザを乗車地点に容易に誘導することができる。

また、サーバ１は、希望地点及び希望時刻以外の情報を参照してユーザを乗車させるバス３の割り当て（マッチング）を行い、運行計画を生成してもよい。例えばサーバ１は、各ユーザの年齢、性別、国籍等の属性情報（乗客属性情報）に基づいてクラスタリング（分類）を行い、ユーザを乗車させるバス３を選択する。例えばサーバ１は、ユーザ同士の属性情報のマッチングを行い、属性情報が同一又は類似するユーザを同一のクラスタに分類し、バス３を割り当てる。これにより、例えば女性専用車両を設けるなど、適宜にバス３の運用を行うことができる。

なお、上記はユーザの属性情報を用いた割り当ての一例であって、本実施の形態はこれに限定されるものではない。例えばサーバ１は、ユーザの所属団体（会社等）に応じて、同業者は同じバス３に割り当てられないようにしてもよい。また、サーバ１は、趣味が共通するユーザを同じバス３に優先的に割り当てるようにしてもよい。あるいはサーバ１は、ランク（顧客優良度）が高いユーザを優先的に割り当てるようにしてもよい。このように、ユーザの属性情報に基づく割り当てには種々の方法が考えられる。

また、例えばサーバ１は、ユーザの属性情報以外にも、バス３の運転手の属性情報（運転手属性情報）に基づいてクラスタリングを行い、バス３の割り当てを行ってもよい。運転手の属性情報は、例えば運転手の技能（会話可能言語等）、ユーザからの評価などである。例えばサーバ１は、ユーザの属性情報と運転手の属性情報とのマッチングを行い、ユーザを乗車させるバス３を選択する。これにより、例えばユーザが外国人観光客である場合に、ユーザの国籍に対応する言語を会話可能な運転手のバス３を割り当てるなど、適切な運用を行うことができる。

また、例えばサーバ１は、バス３自体の属性情報（車両属性情報）に基づいてクラスタリングを行い、バス３の割り当てを行ってもよい。バス３の属性情報は、例えばバス３の評価値を表す車両ランク、各座席の評価値を表す座席ランク、女性専用車両であるか否か、福祉車両であるか否か、車内で提供するサービスなどである。例えばサーバ１は、ユーザ端末２から乗客情報としてバス３の車両ランク、座席ランク等の希望条件を取得した場合、バス３の属性情報とのマッチングを行い、バス３を選択する。

上記のマッチング（クラスタリング）を行う上で、例えばサーバ１は、ユーザ端末２から利用要求を受け付ける場合に、同乗者、運転手、バス３等について希望条件の入力を受け付け、希望条件に従ってマッチングを行ってもよい。また、例えばサーバ１は、希望条件の入力を受け付けずとも、ユーザＤＢ１４１、バスＤＢ１４２、運転手ＤＢ１４３等の各データベースに格納された属性情報を参照し、マッチングを自動的に行ってもよい。

図８は、運行計画の更新処理に関する説明図である。本実施の形態でサーバ１は、ユーザ端末２から利用要求を継続的に受け付け、運行計画をリアルタイムで更新していく。図８では、運行計画の更新処理について、処理内容を概念的に図示している。

図８Ａでは、運行計画を変更し、新たに利用要求を受け付けたユーザをバス３に追加乗車させる場合の処理内容を概念的に図示している。ユーザ端末２から新たなユーザの乗客情報（第２乗客情報）を取得した場合、サーバ１は、新たに取得した乗客情報が示す希望地点及び希望時刻に基づき、当該新たなユーザを、既にバス３を予約済みのユーザのクラスタに分類すべきか否かを判定する。すなわち、サーバ１は、図８Ａにおいて太線で示すように、新たなユーザを希望地点及び希望時刻に基づいてベクトル空間にマッピングし、クラスタリングを行った結果、当該ユーザが、予約済みのユーザのクラスタであって、運行計画を生成済みのクラスタに分類されたか否かを判定する。生成済みのクラスタに分類された場合、サーバ１は、当該クラスタの運行計画に係る運行経路、運行時刻等を変更し、当該ユーザを乗車させるように運行計画を更新する。

図８Ｂは、バス３が次に乗車させるユーザのクラスタを動的に生成する処理内容を概念的に図示している。上述の如く、サーバ１は各クラスタにバス３を割り当て、クラスタ毎にバス３の運行計画を生成する。本実施の形態においてサーバ１は、少なくともバス３が一のクラスタに係る運行計画に従って運行を開始した後の所定のタイミングで、当該一のクラスタに続く次のクラスタを生成してバス３を割り当て、次の運行計画を生成する。

例えばサーバ１は、一のクラスタに係る運行計画の運行完了後、又は当該運行計画に従って運行を開始してから運行が完了するまでの間のタイミングで、現在の時間帯の次の時間帯を希望時刻とするユーザのクラスタリングを行い、新たにクラスタを生成する。この場合にサーバ１は、予約済みのユーザについてグループ（クラスタ）の入れ替えを生じない範囲で、新たなユーザを含めたクラスタリングを行う。サーバ１は、新たに生成したクラスタから、当該バス３を次に割り当てるべきクラスタを選択し、選択したクラスタの運行計画を生成する。これによりサーバ１は運行計画を更新し、更新した運行計画に係る運行経路、運行時刻等を運転手に通知し、バス３を運行させる。

このように、サーバ１は一のクラスタについてバス３の運行開始後に次のクラスタを生成するようにすることで、新たに利用要求を受け付けたユーザを次の運行計画で最大限含めるようにすることができ、運行計画を好適に更新することができる。

図６に戻って説明を続ける。希望時刻、荷物情報、人数等の指定入力が完了した場合、ユーザ端末２はユーザの乗客情報をサーバ１に送信する。この場合、上述の如くサーバ１は、当該ユーザを含む各乗客の乗客情報に基づいて運行計画を生成する。ユーザ端末２は、生成された運行計画に従って予約されたバス３の情報（運行案内）をサーバ１から取得し、バス予約画面に表示する。

例えばユーザ端末２は、予約されたバス３の名称等を表示すると共に、乗車料金を表示する。また、ユーザ端末２は、バス３の運行経路を地図画像上に表示する。より詳細には、ユーザ端末２は、運行経路に加えて当該バス３に乗車する場合の所要時間及び乗車料金を表示すると共に、他の交通手段（例えばタクシー）を利用した場合の所要時間及び乗車料金を併せて表示する。

この場合にサーバ１は、ユーザの乗降時刻が希望時刻とは異なる運行計画を生成した場合、ユーザが許容した許容時間に応じて乗車料金を規定料金からディスカウントした金額に設定し、ディスカウント後の乗車料金をユーザ端末２に表示させる。これにより、運行計画の最適化を容易にすることができる。

なお、本実施の形態では乗降時刻と希望時刻との差分が許容時間内である場合に乗降時刻が希望時刻と異なる運行計画を生成するものとするが、本実施の形態はこれに限定されるものではない。例えばサーバ１は、許容時間以上であっても、ディスカウントした金額をユーザ端末２に出力してユーザから承認を得た場合、乗降時刻と希望時刻との差分が許容時間以上の運行計画を生成してもよい。

図９は、予約確認画面の一例を示す説明図である。図６のバス予約画面においてユーザ端末２は、表示したバス３を予約するか否か、ユーザから入力を受け付けてサーバ１に通知する。予約された場合、サーバ１は運転経路等を運転手端末５に通知して運行させる。ユーザ端末２は、バス予約画面から図９の予約確認画面に遷移し、バス３の予約が完了したことをユーザに提示する。

なお、本実施の形態ではユーザ（乗客）からのみ予約の確認を受けるが、後述する実施の形態３のように、バス３の運行会社からも確認（承認）を受けるようにすると好適である。バス３の運行会社、及び個々の運転手向けのＧＵＩ（Graphical User Interface）上の処理について、詳しくは実施の形態３で説明する。

図１０は、運行状況確認画面の一例を示す説明図である。図９の予約確認画面を表示後、ユーザ端末２は図１０の運行状況確認画面に遷移し、サーバ１と通信を行いながら、予約したバス３の運行状況（運行案内）をリアルタイムで表示する。

例えばユーザ端末２は、図１０左側の運行状況確認画面に示すように、地図画像を表示し、地図画像上に、ユーザの現在位置を示すユーザアイコン１０１と、バス３の停車予定位置（乗車地点）を示す停車位置アイコン１０２とを表示する。上述の如く、ユーザが希望した希望乗車地点とは異なる乗車地点の運行計画が生成された場合に、図１０に示すように、サーバ１は実際の乗車地点をユーザ端末２に通知して停車位置アイコン１０２を表示させることで、円滑なバス３の運行を行うことができる。また、ユーザの現在位置を併せて表示させることで、さらに円滑なバス３の運行を行うことができる。

また、ユーザ端末２は、バス３の現在位置と、バス３の停車予定位置との距離から推定される到着予想時間を併せて表示する。バス３の現在位置が表示中の地図画像上の位置まで移動した場合、ユーザ端末２は、図１０右側の運行状況確認画面に示すように、バス３の現在位置を示すバスアイコン１０３を表示する。

また、例えばユーザ端末２は、バス情報欄１０４を画面下部に表示し、予約したバス３の情報（例えば自動車登録番号）を表示する。また、例えばユーザ端末２は、バス情報欄１０４内に、バス３の運転手と連絡を取るための通話アイコン１０５、及びメッセージアイコン１０６を表示する。通話アイコン１０５又はメッセージアイコン１０６への操作入力を受け付けた場合、ユーザ端末２はサーバ１を経由して、運転手端末５との間で通話、又はメッセージの送受信を行う。また、さらにバス情報欄１０４に対する上方向へのスワイプ操作を受け付けた場合、ユーザ端末２は、予約時に登録された乗車人数、荷物情報、目的地又は出発地、乗車料金等を表示する。

なお、上記でサーバ１は、バス３を予約したユーザのユーザ端末２に当該バス３の運行状況を通知して表示させるものとしたが、本実施の形態はこれに限定されるものではない。例えばサーバ１は、バス３を予約していない他のユーザ（乗客候補者）のユーザ端末２にも運行状況を通知し、当該バス３の利用要求を受け付けるようにしてもよい。例えばサーバ１は、生成済みの運行計画を参照して、運行中のバス３の空き状況を判定する。座席に空きがあると判定した場合、サーバ１は、当該バス３の現在位置、目的地、空き乗車可能人数等を他のユーザのユーザ端末２に通知し、利用要求を受け付ける。あるいはサーバ１は、ウエブサイト、所定箇所に設置された電光掲示板、旅行ツアー会社等に宛てて出力し、利用要求を受け付けてもよい。このように、バス３の空き状況を出力し、出力先から利用要求を受け付けることで、バス３を急に利用したい場合などに、ユーザは現在運行しているバス３の空き状況を考慮して好適に利用要求を行うことができる。

なお、バス３の空き状況をユーザに通知する際に、例えばサーバ１は、ユーザのスケジュールを外部のＡＰＩ（スケジューラ）から取得して乗車見込みの有無を判定し、乗車見込みがあると判定したユーザに対して空き状況を通知するようにしてもよい。なお、乗車見込みの有無は、例えば航空機への搭乗又は降機の予定の有無、イベントへの参加の予定の有無、ホテルでのチェックイン又はチェックアウトの有無などで判定する。これにより、バス３の利用を好適に促すことができる。

図１１は、サーバ１が実行する処理手順の一例を示すフローチャートである。図１１に基づき、サーバ１が実行する処理内容について説明する。
サーバ１は、各ユーザのユーザ端末２、２、２…から乗客情報（第１乗客情報）を取得し、利用要求を受け付ける（ステップＳ１１）。乗客情報は、少なくとも希望地点（希望乗車地点又は希望降車地点）と、希望時刻（希望乗車時刻又は希望降車時刻）とを含む。より具体的には、乗客情報は、希望地点及び希望時刻の他に、乗降人数、荷物情報、希望時刻と実際の乗車時刻との許容時間等を含む。

サーバ１は、各ユーザの希望地点及び希望時刻に基づき、各ユーザを複数のクラスタ（集合）に分類する（ステップＳ１２）。そしてサーバ１は、各クラスタにバス３を割り当て、クラスタ毎にユーザを乗降させる運行計画を生成する（ステップＳ１３）。この場合にサーバ１は、希望地点及び希望時刻以外に、乗客属性情報、運転手属性情報、車両属性情報等も参照してユーザを乗車させるバス３を選択し、運行計画を生成してもよい。

サーバ１は、生成した運行計画に応じて乗車料金を設定し、乗車料金を含むバス３の情報（運行案内）をユーザ端末２に通知する（ステップＳ１４）。例えばサーバ１は、ユーザがバス３に乗車する乗車時刻が希望時刻と異なる場合に、ユーザが設定した許容時間に応じて乗車料金を設定する。サーバ１は、乗車料金以外に、バス３の運行経路、所要時間等の情報をユーザ端末２に通知し、バス３の予約を確定させるか否か、応答を受け付ける。バス３の予約を確定させる旨の応答をユーザ端末２から受け付けた場合、サーバ１は運行計画を確定し、運転手端末５に運行経路等を通知する（ステップＳ１５）。

サーバ１はさらに、ステップＳ１１で利用要求を受け付けたユーザ（既に予約している乗客）とは異なる新たなユーザのユーザ端末２から、乗客情報（第２乗客情報）を取得して利用要求を受け付ける（ステップＳ１６）。サーバ１は、新たに取得した乗客情報に基づき、当該ユーザを既に生成済みのクラスタに分類すべきか否かを判定する（ステップＳ１７）。生成済みのクラスタに分類すべきと判定した場合（Ｓ１７：ＹＥＳ）、サーバ１は、分類すべきと判定したクラスタに対応するバス３の運行計画を、当該ユーザを乗車させるように運行経路、運行時刻等を変更して更新する（ステップＳ１８）。

ステップＳ１８の処理を終了後、又はステップＳ１７でＮＯの場合、サーバ１は、バス３の次の運行計画を生成すべき所定のタイミングであるか否かを判定する（ステップＳ１９）。ステップＳ１９で判定基準とするタイミングは、少なくともバス３が現在の運行計画に従い、割り当てられたクラスタのユーザを乗降させるべく運行を開始した後のタイミングである。例えばサーバ１は、バス３が当該クラスタに係る運行計画について運行完了したタイミング、又は運行を開始してから運行が完了するまでの間のタイミングであるか否かを判定する。

次の運行計画を生成すべきタイミングであると判定した場合（Ｓ１９：ＹＥＳ）、サーバ１は、予約済みのユーザで未送迎のユーザと、ステップＳ１６で新たに乗客情報を取得したユーザとを複数のクラスタに分類するクラスタリングを行い、新たにクラスタを生成する（ステップＳ２０）。そしてサーバ１は、新たに生成したクラスタにバス３を割り当て、新たな運行計画を生成する（ステップＳ２１）。

サーバ１は、バス３の運行を終了する所定の終了条件（例えば営業時間の終了）を満たしたか否かを判定する（ステップＳ２２）。ステップＳ１９又はＳ２２でＮＯの場合、サーバ１は処理をステップＳ１６に戻す。ステップＳ２２でＹＥＳの場合、サーバ１は一連の処理を終了する。

図１２は、ユーザ端末２が実行する処理手順の一例を示すフローチャートである。図１２に基づき、ユーザ端末２が実行する処理内容について説明する。
ユーザ端末２は、地点入力画面を表示して希望地点の入力を受け付け、サーバ１に送信する（ステップＳ４１）。ユーザ端末２はバス予約画面に遷移し、希望時刻、乗車人数、荷物情報等の入力を受け付けてサーバ１に送信する（ステップＳ４２）。

ユーザ端末２は、ステップＳ４１、Ｓ４２で入力した各情報に基づき運行計画を生成したサーバ１から、ユーザに配車されるバス３の情報（運行案内）を取得してバス予約画面に表示する（ステップＳ４３）。例えばユーザ端末２は、バス３の乗車料金、所要時間等のほかに、他の交通機関を利用した場合の乗車料金、所要時間等を表示する。ユーザ端末２は、ユーザからの操作入力に従って、バス３の利用予約を確定するか否かを判定する（ステップＳ４４）。

予約を確定すると判定した場合（Ｓ４４：ＹＥＳ）、ユーザ端末２は予約確認画面を表示した後、配車状況確認画面に遷移して、現在のバス３の運行状況（運行案内）を表示する（ステップＳ４５）。例えばユーザ端末２は、ユーザの現在位置、ユーザがバス３に乗車する乗車位置、バス３の到着時間、バス３の現在位置等を表示する。ユーザ端末２は、バス３が乗車地点に到着してユーザが乗車したか否かを判定する（ステップＳ４６）。乗車していないと判定した場合（Ｓ４６：ＮＯ）、ユーザ端末２は処理をステップＳ４５に戻して運行状況の表示を継続する。ステップＳ４４でＮＯ、又はステップＳ４６でＹＥＳの場合、ユーザ端末２は一連の処理を終了する。

以上より、本実施の形態１によれば、バス３の利用を既に予約しているユーザ（乗客）の乗客情報（第１乗客情報）と、新たにバス３の利用要求を行ったユーザの乗客情報（第２乗客情報）とに基づき、好適に運行計画の動的生成を行うことができる。

また、本実施の形態１によれば、乗客情報が示す乗降地点及び乗降時刻に基づいてクラスタリングを行い、クラスタ毎に運行計画を生成することで、複数のユーザが相乗りするバス３の運行計画を好適に生成することができる。

また、本実施の形態１によれば、新たに利用要求を受け付けたユーザを既存のクラスタに分類すべきか否かを判定し、分類すべきと判定した場合に、当該ユーザを乗降させるよう当該クラスタの運行計画を更新することで、運行計画のリアルタイムでの更新を好適に行うことができる。

また、本実施の形態１によれば、ユーザ（乗客）、運転手、バス３（車両）等の属性情報に応じてユーザを乗降させるバス３を選択することで、より好適な運行計画を生成することができる。

また、本実施の形態１によれば、所定の出発地と目的地との間を往復するバス３について、往路及び復路の運行計画を動的に生成することができる。

また、本実施の形態１によれば、運行計画を生成する複数のバス３、３、３…のうち、ユーザが無乗車であるバス３の台数に応じて運行計画を生成することで、バス３、３、３…全体で運行効率を最適化することができる。

また、本実施の形態１によれば、希望乗車地点とは異なる乗車地点で乗客を乗車させる場合に、実際の乗車地点をユーザに通知することで、ユーザの利便性を高めることができる。

また、本実施の形態１によれば、希望乗降時刻と実際の乗降時刻との間に許容時間を設けることで、運行計画の最適化を容易にすることができる。また、許容時間に応じて乗車料金を変動させることで、運行計画の最適化にユーザを協力させるインセンティブを与えることができる。

また、本実施の形態１によれば、バス３の利用を予約していないユーザに、座席の空き状況を含むバス３の運行状況を通知することで、ユーザの利便性を向上させることができる。

（変形例１）
実施の形態１では、予約済みのユーザ以外の新たなユーザからバス３の利用要求を受けて運行計画を生成する旨を説明した。しかし、当該新たなユーザは現にバス３の利用要求（予約）を行うユーザのみならず、バス３の利用が予測されるユーザであってもよい。

例えばサーバ１は、予約済みのユーザ以外に、バス３の利用が見込まれる他のユーザ（新たなユーザ）によるバス３の需要値を予測し、予測した需要値から運行計画を生成してもよい。当該需要値は、例えば出発地（ホテル等）、目的地（空港等）、その他の地点におけるユーザの流出入に関する値を予測した予測値である。ホテルを例にした場合、例えばサーバ１は、ホテルにおけるチェックイン又はチェックアウトの時間帯、ホテルの部屋数等から、ホテルに宿泊するユーザから受け付ける利用要求の希望地点及び希望時刻（第２乗客情報）を予測する。また、空港を例にした場合、例えばサーバ１は、航空機の運航ダイヤから、空港を利用するユーザから受け付ける利用要求の希望地点及び希望時刻を予測する。サーバ１は、外部システム（例えば旅行サイト、航空機の予約サイト等）から、これらの需要値に関連する需要情報を取得し、運行計画の生成に用いる。

具体的には、サーバ１は、需要値の高低に応じてバス３の運行台数を定め、当該運行台数で運行を行う運行計画を生成する。例えばサーバ１は、需要値が高い日時は運行台数を多くし、バス３、３、３…にユーザを分散して乗車させることで、当日新たに利用要求を受け付けた場合にも対応可能とする。また、サーバ１は、需要値が低い日時は運行台数を減らし、一台当たりの乗車人数が多くなるように運行計画を生成することで、確保するバス３、３、３…の台数を減らす。

なお、上記ではホテル及び空港を例にバス３の需要情報について説明したが、本実施の形態はこれに限定されるものではなく、需要情報は、新たなユーザからの利用要求を予測可能な何らかのデータであればよい。例えばサーバ１は、外部システム経由で需要情報を取得することなく、過去の運行計画から需要値を予測して新たな運行計画の生成に用いてもよい。

また、例えばサーバ１は、バス３の需要値ではなく、新たなユーザを乗降させることが可能か否か、バス３の供給値（供給情報）を予測して運行計画に用いてもよい。バス３の供給値は、例えば各バス３の乗車率、あるいはバス３、３、３…全体での運行台数等であり、バス３によって全てのユーザを乗降させることが可能か否か、バス３の供給力を示すデータである。例えばサーバ１は、過去の運行計画を参照して時間帯別にバス３の乗車率、運行台数を予測し、予測した乗車率等から各時間帯の運行計画を生成する。これにより、例えばサーバ１は、時間帯によってはバス３を満席にせず、一定の空き座席を設けて運行計画を生成するなど、好適に運行計画を生成することができる。

上述の如く、サーバ１は、新たなユーザによるバス３の需要情報又は供給情報に基づき、運行計画を生成してもよい。この場合にサーバ１は、需要情報又は供給情報に応じてユーザの乗車料金を設定すると好適である。例えばサーバ１は、需要値が高く、多くのユーザの利用が見込まれる時間帯の場合に、乗車料金を高く設定する。また、例えばサーバ１は、供給値が低く、バス３の空き座席が少ないと見込まれる時間帯の場合に、乗車料金を高く設定する。これにより、各ユーザの利用頻度を分散させ、バス３の運行をスムーズにすることが期待できる。

（変形例２）
実施の形態１では、ユーザは一の地点（乗車地点）から他の地点（降車地点）まで全ての経路をバス３で移動する形態について説明した。しかし、当該一の地点から他の地点までの移動の一部にバス３以外の公共交通機関を組み合わせてもよい。

公共交通機関は、例えば航空機、鉄道などであるが、バス３以外の移動手段であればよく、特に限定されない。サーバ１は、ユーザがこれらの公共交通機関を利用することを前提に運行計画を生成してもよい。

例えばサーバ１は、ユーザが希望する希望乗車地点及び希望降車地点の間の一部を公共交通機関で移動した方が料金が安くなる場合、公共交通機関とバス３とを組み合わせて利用することをユーザに提案する。例えばサーバ１は、ユーザの乗客情報（希望地点、希望時刻等）を取得してバス３の利用要求を受け付けた場合に、希望乗車地点及び希望降車地点の間を全てバス３で移動する運行計画と、公共交通機関及びバス３を組み合わせた運行計画とを各々生成する。なお、公共交通機関（航空機、鉄道等）とバス３とを組み合わせて移動経路を生成する手段は公知なので、ここでは説明を省略する。サーバ１は、前者の運行計画に基づくバス３の料金と、後者の運行計画に基づく料金（公共交通機関の料金及びバス３の料金の合算値）とを算出し、後者の料金が前者の料金よりも低い場合に、公共交通機関を組み合わせた運行計画を採用する。例えばサーバ１は、採用した運行計画の情報をユーザ端末２に出力し、ユーザから承認を得る。

また、例えばサーバ１は、ユーザが希望する２地点の間の一部をバス３が運行不可能な場合、公共交通機関とバス３とを組み合わせて利用することをユーザに提案する。このケースは、長距離移動（例えば東京～福岡間）を行うケースが考えられる。例えばサーバ１は、２地点の間の距離、移動時間等が所定の閾値以上であるか否かを判定し、閾値以上の場合、公共交通機関を組み合わせた運行計画（例えば東京～羽田間をバス３で移動し、羽田～福岡間を航空機で移動する計画）を生成する。

上述の如く、バス３だけでなく公共交通機関も組み合わせて運行計画を生成してもよい。

（実施の形態２）
実施の形態１では、バス３が所定の目的地との間を往復するシャトルバスである形態について説明した。しかし、バス３は特定の目的地を有さず、一定の地域を巡回してユーザを乗降させるデマンドバスであってもよい。本実施の形態では、バス３が一定の地域を巡回するデマンドバスである形態について説明する。

図１３は、実施の形態２の概要を示す説明図である。図１３では、本実施の形態に係るクラスタリング時のベクトル空間を概念的に図示している。図１３に基づき、本実施の形態の概要を説明する。

上述の如く、本実施の形態においてバス３は特定の出発地及び目的地を有さず、一定の地域を巡回して各ユーザを乗降させる。従ってサーバ１は、往路及び復路でベクトル空間を区分せず、代わりにバス３が巡回する地域を所定単位で分割した地区毎に区分する。また、時間軸を所定単位の時間帯毎に区分することは、実施の形態１と同様である。これにより、図１３に示すように、サーバ１は地区及び時間帯別にベクトル空間を区分する。

サーバ１は、各ユーザのユーザ端末２から取得した乗客情報に基づき、各ユーザをベクトル空間にマッピングする。そしてサーバ１は、各ユーザを複数のクラスタに分類する。運行計画を生成する場合に、サーバ１は、ある時間帯のクラスタにバス３を割り当てて運行計画を生成した後、次の時間帯のクラスタのうち、いずれかの地区のクラスタを割り当てて次の運行計画を生成する。サーバ１は、実施の形態１と同様に、例えば巡回セールスマン問題の手法を用いて運行計画の最適化を行う。

この場合にサーバ１は、実施の形態１と同様に、無乗車のバス３の台数に応じて運行計画を生成すると好適である。具体的には、サーバ１は、無乗車のバス３の台数が少ないほどコスト値が低く計算することで、全てのバス３、３、３…に乗客が分散して乗車するように運行計画を生成する。

上述の如く、実施の形態１に係る運行計画システムを、特定の目的地を有しない巡回型のデマンドバスに応用することもできる。バス３の運行形態が異なる点以外は実施の形態１と同様であるため、本実施の形態ではフローチャートその他の詳細な説明を省略する。

（実施の形態３）
実施の形態１では、各ユーザ（乗客）からバス３の利用要求を受け付けてクラスタリングを行い、クラスタ毎に運行計画を生成してバス３を運行させる旨を説明した。本実施の形態では、実際に運行事業者にバス３を運行させる際の処理として、生成した運行計画を運行事業者に係る各運転手及びバス３に割り当てると共に、割り当てられた運行計画に従った運転経路をバス３の運転手（運転手端末５）に提示する処理について説明する。

図１４は、運行計画の一覧画面の一例を示す説明図である。上述の如く、サーバ１はクラスタ毎に運行計画を生成する。本実施の形態では、サーバ１は各クラスタに対応する運行計画を事業者端末４に配信し、図１４の一覧画面に表示させる。本実施形態は、例えば、バス３の利用要求を受け付けたユーザに基づく新たなクラスタを生成した上で、クラスタ毎の新たな運行計画に対し、バス３を配車する場面（具体的には、所定日時に、自宅から、空港に向かう人々のクラスタを生成した上で、運行計画を生成し、所定日時に人々の自宅から空港を走行するバスを配車する場面等）、あるいは、既に生成された運行計画があり、当該運行計画に割り当てられたバス３が走行中に、バス３の利用要求を受け付けたユーザを既に生成されたクラスタに分類をし、既に生成された運行計画に当該ユーザの乗車又は降車を含める場面（具体的には、走行中のタクシーの近隣にいるユーザが利用要求をした場合に、当該ユーザを当該タクシーに乗車させる場面）のいずれにも用いることができる。

例えば事業者端末４は、出発地及び目的地、運行時間帯、乗客の人数、各乗客の荷物情報などを含む各運行計画の情報を一覧表示する。また、例えば事業者端末４は、各運行計画について、事業者端末４が自動的に割り当てた運転手及びバス３をそれぞれ、運転手表示欄４１、バス表示欄４２にデフォルト表示する。例えば運転手表示欄４１、バス表示欄４２はそれぞれ、プルダウンによる操作入力が可能となっており、運転手及びバス３の設定変更（設定入力）が可能となっている。経路表示４４を選択した場合、運行計画の出発地、乗車地、降車地、目的地の地点を経由した経路が表示される。

事業者端末４が運行計画に運転手を自動的に割り当てる際に、後述する図１５Ａの各運転手のスケジュール（各車両のスケジュールであってもよい。本実施の形態において以下同じ。）を参照し、運行計画における出発時間及び到着時間の間の時間帯のスケジュールに空きがある運転手（スケジュール上、運送可能な運転手）を割り当てる。その際、スケジュールに空きがある運転手が複数いる場合は、運行計画に乗車する乗客情報（使用言語、出身国、住所、位置情報等）、運転手情報（使用言語、乗客からの評価、位置情報等）、車両情報（車両ランク、座席ランク、空き座席の乗車可能人数等）等に基づき、適切な運転手を割り当てることとしてもよい。また、スケジュールに空きがある運転手が複数いる場合、乗客と、近接した位置に所在する運転手を割り当ててもよい。具体的には、乗客の位置情報（ＧＰＳ情報）と、運転手の位置情報（ＧＰＳ情報）が近い運転手を割り当てることとしてもよい。また、乗客の入力した乗車地点及び乗車時間と、運転手の業務スケジュールから予測される乗車時間における所在地点が、近い運転手を割り当てることとしてもよい（例えば、運行計画において乗客が１４時に羽田空港から乗車することを希望している場合に、運転手のスケジュールが、１３時４５分に羽田空港で降車させるスケジュールであったときは、当該運転手を当該運行計画に割り当てる）。

また、事業者端末４が運行計画に車両（あるいは当該車両を運転する運転手）を自動的に割り当てる際に、運行計画に含まれる乗客の人数、乗客の荷物情報に基づき、バス３の車両情報に含まれる乗車可能人数、積載可能荷物量から、運送可能な乗客の人数、乗客の荷物量であるか否かを判断し、運送可能な車両（あるいは当該車両を運転する運転手）を、割り当てることとしてもよい。この場合、運行計画に含まれる乗客の人数が、車両情報に含まれる乗車可能人数以下であれば、乗客を運送可能と判断してもよい。また、運行計画に含まれる乗客の荷物情報が、車両情報に含まれる積載可能荷物量の範囲内であれば、荷物を運送可能と判断してもよい。さらに、運行計画に含まれる乗客の荷物情報が、車両情報に含まれる積載可能荷物量の範囲に含まれない場合であって、運行計画に含まれる乗客の人数が、車両情報に含まれる乗車可能人数を下回る場合は、車両中の乗客が乗車していない座席に、車両情報に含まれる積載可能荷物量の範囲を上回る運行計画に含まれる乗客の荷物情報に対応する荷物を積載することが可能であると判断したときに、荷物を運送可能と判断してもよい。車両中の乗客が乗車していない座席に、車両情報に含まれる積載可能荷物量の範囲を上回る運行計画に含まれる乗客の荷物情報に対応する荷物を積載することが可能であるか否かの判断は、例えば、荷物１個を、車両の乗車人数１人と換算して（あるいは荷物の種類ごとに、乗車人数何人分に換算するかをあらかじめパラメーターとして定めておき、当該パラメーターに基づき、換算してもよい）、運行計画に含まれる車両の乗車人数と当該換算した人数の合計が、車両情報に含まれる乗車可能人数以下であれば、荷物を積載することが可能であると判断してもよい。なお、ここでは、乗客が所持する荷物を例に説明したが、乗客が所持しない荷物（乗客以外の者が所持する荷物、例えば、荷物のみを車両で運送する場合）であってもよい。

事業者端末４が運行計画に運転手又は車両を自動的に割り当てる際に、運行計画における出発地、乗車地、降車地又は目的が、事業者のサービス提供エリア（運転することが可能な地域）でなかった場合は、当該運行計画には運転手又は車両を割り当てない処理をしてもよい。

上述の処理により、事業者端末４は、運転手及び車両のスケジュール、乗客情報、運転手情報、車両情報等を参照して、運行計画に割り当てる運転手及び車両を判定してデフォルト表示する。運転事業者はデフォルト表示された運転手及び車両の割り当てに対し、運転手表示欄４１及びバス表示欄４２を操作して任意の割り当ての設定変更を行う。

図１５は、運転手情報の表示画面の一例を示す説明図である。事業者端末４は、運行事業者からの操作入力に応じて、図１４の一覧画面から、図１５Ａのスケジュール画面、又は図１５Ｂのプロフィール画面に切り換えて表示する。

スケジュール画面は、当該運行事業者の下で運転に従事する各運転手の業務スケジュール（運行スケジュール）をタイムチャートで一覧表示する表示画面である。また、例えばスケジュール画面には、各運転手の勤務時間も併せて表示される。サーバ１は、事業者端末４からスケジュール画面の出力要求を受けて、運行計画ＤＢ１４４を参照してスケジュール画面を生成し、事業者端末４に配信して表示させる。

プロフィール画面は、各運転手の氏名、電話番号等の書誌的事項のほかに、運転手の属性情報（図１５Ｂでは会話可能言語）を一覧表示する表示画面である。事業者端末４からの出力要求に応じて、サーバ１はプロフィール画面を生成し、事業者端末４に表示させる。

なお、本実施の形態では運転手情報のみを表示するものとして説明を行うが、例えば事業者端末４は、運行事業者が所有する各バス３の運行スケジュール、乗車可能人数、積載可能荷物量、車種等の車両情報も一覧表示するようにしてもよい。これにより、運行事業者は車両情報を把握してバス３の割り当てを容易に行うことができる。

スケジュール画面及びプロフィール画面により、運行事業者は各運転手のスケジュール、及びプロフィール（特に運転手の属性情報）を容易に確認することができる。図１４に戻って、運行事業者は運転手表示欄４１及びバス表示欄４２を操作し、デフォルトで自動的に割り当てられた運転手及びバス３の割り当ての設定変更の入力を行う。上述の処理により、事業者端末４が自動的に決定した運転手及びバス３の割り当てを修正し、運行計画をより適切なものにすることができる。

なお、本実施の形態では事業者端末４が運転手及びバス３の割り当てを自動的に設定し、運行事業者が手動で変更するものとするが、事業者端末４は運転手及びバス３の割り当てを行わずに、運行事業者が手動で設定（判定）するものとしてもよい。すなわち、事業者端末４が運転手及び／又はバス３の割り当てを判定可能であればよく、当該処理は事業者端末４が自動的に判定を行ってもよく、手動入力の結果に応じて判定を行ってもよい。

また、上記では、運転手の業務スケジュールから、バス３の出発時間及び到着時間の間に空きがある運転手を運行計画に割り当てるものとしたが、これとは逆に、運行計画に応じて運転手の業務スケジュール（すなわち、業務のシフト）を変更してもよい。例えば事業者端末４は、各運転手の月当たりの業務時間、一日当たりの業務時間、必要な休日日数、運転（走行）可能な一日当たりの最大走行距離などを保持したテーブルを参照して、運転手を各バス３の運行計画に割り当てていき、業務スケジュールを生成して運行事業者（あるいは運転手）に提示して承認を得る。このように、運転手のスケジュールから割り当てを行うのではなく、運行計画に割り当て可能なように運転手のスケジュールを変更してもよい。

また、運転手のスケジュールを変更する場合、変形例１で説明した需要情報も考慮してスケジュールの変更を行ってもよい。例えば事業者端末４は、バス３の需要値（ユーザ乗降数の予測値）が一定値以上であるか否かを判定し、一定値以上であると判定した場合は業務時間等の上限値を引き上げてスケジュールを生成する。このように、バス３の需要も考慮して運転手のスケジュールを変更してもよい。

図１４に基づき説明を続ける。事業者端末４は、各運行計画に対応して、承認ボタン４３を表示する。承認ボタン４３への操作入力を受け付けた場合、図１４のように「承認する」及び「お断りする」の操作メニューがプルダウン表示され、運行計画を承認するか否か、操作入力を受け付ける。なお、既に承認済みの運行計画については、承認ボタン４３が「承認済み」の表示に変更される。この場合、事業者端末４は、当該運行計画を承認する旨をサーバ１に通知（出力）する。

例えばサーバ１は、複数の運行事業者と連携しており、各運行事業者の事業者端末４に運行計画を配信（出力）する。例えばサーバ１は、図１４の画面を全ての事業者端末４に表示をし、事業者毎に先着順で承認を受けつけることとしてもよい。あるいはサーバ１は、各事業者の優先順位に係るテーブルを保有しており、優先順位の高い事業者に対し、順番に、各運行計画を表示し、承認を得られた場合に承認を受け付け、承認を得られなかった場合に、承認が得られるまで、次順位の事業者に、各運行計画の表示を繰り返し、承認を得ることとしてもよい。一の運行事業者の事業者端末４から承認を受け付けた場合、サーバ１は、他の運行事業者の事業者端末４で表示する一覧画面から、承認された運行計画を消去する。

なお、本実施の形態でサーバ１は、運行計画を事業者端末４に出力し、運行事業者が運行計画を承認するものとしたが、運行計画を運転手端末５に出力し、運転手から承認を受け付けるようにしてもよい。

以上の実施形態では、運行事業者は、事業者端末４に表示された各運行計画を承認するか否かを説明してきたが、運行事業者は、複数の運行計画を１つの運行計画に集約して、承認してもよい。すなわち、区間および時間が近接しており、集約しても、運行可能な運行計画がある場合、運行事業者が、集約可能な運行計画を選択した上で、集約することを選択することにより、事業者端末４には、集約された運行計画が表示される。運行事業者は、事業者端末４を用いて、当該集約された運行計画を承認することができる。

なお、上記では先着順で運行計画の承認（受注）を受け付けることにしたが、本実施の形態はこれに限定されるものではない。例えばサーバ１は、運行事業者が運行計画を請け負う受注代金に応じて、いずれの運行事業者に委託するかを決定してもよい。例えば事業者端末４は、「承認する」の操作入力を受け付けた場合、さらに運行計画の受注代金の入力を受け付けてサーバ１に通知する。サーバ１は、各運行事業者の事業者端末４から受注代金に関する通知を受信し、例えば受注代金が最も低い運行事業者への委託を決定する。受注代金に応じて運行計画の委託先を決定することで、送迎サービスを好適に実施することができる。

この場合に、サーバ１は、運行計画を配信してから受注代金の通知を受け付けるまでに、制限時間（例えば５分間）を設けると好適である。制限時間を設けることにより、運行計画の早急な承認（受注）を促すことができる。

また、上記では、運行事業者が、運行計画の承認（受注）を手動で行っていたが、事業者端末４が、運行計画の承認（受注）を自動的に行ってもよい。例えば、事業者端末４は、運転手及びバス３の割り当てられる処理が行われた運行計画を全て自動的に承認する（この場合、運転手及びバス３の割り当てられる処理が、承認の処理を含む処理としてもよい）こととしてもよい。また、事業者端末４は、運転手及びバス３の割り当てられる処理が行われた運行計画のうち、所定の条件（例えば、出発地と目的地の距離が所定距離以上であることや、乗車人数が所定人数以上であること等）を満たした運行計画を自動的に承認することとしてもよい。

他にも、サーバ１は、複数の運行事業者が「承認する」の操作入力を受け付けた場合に、運行事業者を決定する方法として、運行事業者情報（乗客からの評価、サービス提供エリア等）、乗客情報（使用言語、出身国、住所、性別等）、運転手情報（使用言語、乗客からの評価、性別等）、車両情報（乗車可能人数、ランク等）、受注代金等の要素の全部又は一部の要素に基づいて、運行事業者を決定してもよい。

事業者端末４から運行計画の承認を受け付けた場合、サーバ１は、乗車時刻、乗車地点等のほかに、運行事業者、バス３の種類等を含む電子メール、ショートメールメッセージ等（不図示）をユーザ端末２に通知する。この場合に、例えばサーバ１は、開封（閲覧）確認の要求付きの電子メール等を生成して、ユーザ端末２に通知する。当該通知が開封された場合、ユーザ端末２は、通知が開封された旨をサーバ１に自動的に返信する。サーバ１は、当該返信を受信した場合、運行計画が確定した旨を事業者端末４に通知する。以上の処理により、ユーザと運行事業者との間を仲介するオペレータを不要として、運行計画を確定させることができる。

運行事業者が、運行計画を承認した後も、当該運行計画に分類可能な乗客を、当該運行計画に分類することとしてもよい。

図１６は、運転手端末５の表示画面の一例を示す説明図である。運行計画が確定した場合、サーバ１は、当該運行計画に関する情報を、担当する運転手の運転手端末５に配信し、図１６の画面を表示させる。

例えば運転手端末５はまず、図１６左側に示すように、当日運転手が担当する各運行計画（往路又は復路の便）を一覧表示する。運行計画を示す各テキストがタップされた場合、運転手端末５は、各ユーザの乗降時刻と、乗降地点とをプルダウン表示する。

例えば運転手端末５は、いずれかの運行計画を選択する選択入力を受け付け、選択された運行計画に係る経路を示す図１６中央の画面に遷移する。なお、例えば運転手端末５は、運行開始時刻になった場合に図１６中央の画面を自動的に表示するようにしてもよい。図１６中央に示すように、運転手端末５は、バス３の現在位置から、ユーザを乗車又は降車させる乗降地点に向かう運行経路を示す地図画像を表示する。

以下の説明では簡潔のため、出発地から出発したバス３が各地点でユーザを乗車させ、目的地に向かう往路についてのみ説明を行う。

運転手端末５はまず、最初のユーザの乗車地点に向かう運行経路を表示する。また、運転手端末５は運行経路のほかに、乗車地点を示す住所、乗車させるユーザ名等の情報を画面下部に表示する。また、例えば運転手端末５は、当該乗車地点に到着すべき到着予定時刻、乗車地点から発車すべき発車予定時刻、現在位置からの距離、現在位置から予測される残り運行時間等を表示する。

また、例えば運転手端末５は画面下部に、表示中の乗車地点で乗車させるユーザと連絡を取るための通話アイコン１６１、メッセージアイコン１６２等のオブジェクトを表示する。通話アイコン１６１又はメッセージアイコン１６２への操作入力を受け付けた場合、運転手端末５は、サーバ１を経由して当該ユーザのユーザ端末２との間で通話又はメッセージの送信を行う。

例えば運転手端末５は、運転手からの操作入力に応じて、画面下部の表示を、図１６右側の表示に切り換える。具体的には、運転手端末５は、乗車地点に到着した旨を入力するための到着ボタン１６３を画面下部に表示する。なお、例えば運転手端末５は、バス３の現在位置と乗車地点との距離等に応じて到着ボタン１６３を自動的に表示するなどしてもよい。

乗車地点に到着した場合、運転手は到着ボタン１６３をタップする。運転手端末５は、到着ボタン１６３への操作入力を受け付けた場合、乗車地点に到着したことを判定し、サーバ１を経由して、バス３が到着した旨をユーザ端末２に通知する。例えば運転手端末５は、電子メール、ショートメールメッセージ等の手段で通知を行ってもよく、あるいはユーザ端末２への通話発信を行ってもよい。これにより、バス３が到着したことを早急にユーザに報知することができる。また、運転手は到着ボタン１６３をタップせずとも、運転手端末５が、バス３の位置情報から、乗車地点に到着したことを判定した場合に、運転手端末５はサーバ１を経由して、バス３が到着した旨をユーザ端末２に通知する。

ユーザの乗車が完了した場合、サーバ１は、次の乗車地点への経路に切り換えて運転手端末５に表示させる。例えば運転手端末５が、到着ボタン１６３と同様のオブジェクト（ボタン）を表示し、運転手からの操作入力を受け付けることで、ユーザが乗車したか否かを判定する。あるいはサーバ１は、バス３及びユーザ（ユーザ端末２）それぞれの位置情報に基づいて乗車したか否かを判定するなどしてもよい。ユーザが乗車した場合、運転手端末５は次のユーザの乗車地点への経路を表示し、運行を再開させる。

なお、乗車時刻になってもユーザが乗車地点に到着しない場合、すなわち乗り遅れる場合、サーバ１はユーザの乗車予定をキャンセルしてもよい。例えばサーバ１は、乗車時刻までに到着ボタン１６３が操作されず、ユーザが乗車していないと判定した場合、乗車をキャンセルするか否かをユーザ端末２に問い合わせる。なお、上記と同様にサーバ１は、ユーザが乗車したか否かを位置情報等に基づいて自動的に判定してもよい。問い合わせに対し、キャンセルを承認する旨の応答をユーザ端末２から取得した場合、サーバ１はユーザの乗車予定をキャンセルし、その旨を運転手端末５に通知する。

ユーザが乗り遅れた場合、サーバ１は、別のバス３に当該ユーザを乗車させてもよい。例えばサーバ１は、付近を運行しているバス３の内、空き座席があるバス３を運行計画ＤＢ１４４から特定し、当該バス３の運転手の運転手端末５にユーザを乗車させるよう通知する。

なお、上記ではユーザの到着が遅れる場合について説明したが、バス３の到着が遅れる、又は早まる場合もあり得る。その場合にサーバ１は、各バス３、３、３…の運行状況に応じて、ユーザを乗車させるバス３を変更してもよい。例えばサーバ１は、ユーザが乗車予定のバス３の運行予定が遅れている場合（各ユーザの乗降を予定している各乗降地点への到着時刻が、予定されている乗降時刻よりも一定時間以上遅れている場合）において、後続のバス３（出発地及び目的地が先行のバス３と同じであり、かつ、出発時刻が先行のバス３よりも遅いバス３）の運行予定も遅れている場合、後続のバス３に乗車させる。また、例えばサーバ１は、ユーザが乗車予定のバス３の運行予定が早まっている場合（各ユーザの乗降を予定している各乗降地点への到着時刻が、予定されている乗降時刻よりも一定時間以上早い場合）において、先行のバス３の運行予定も早まっている場合、先行のバス３に乗車させる。このように、サーバ１は、バス３、３、３…の運行状況に応じてユーザを乗車させるバス３を変更するよう運行計画を修正（更新）してもよい。

一の乗車地点でユーザの乗車を確認（判定）した場合、例えばサーバ１は、次の乗車地点で乗車するユーザのユーザ端末２に、前の乗車地点で他のユーザ（先客）が乗車したこと、及びバス３が次の乗車地点に到着する到着予想時刻を通知するようにしてもよい。これにより、各ユーザはバスの運行状況を正確に知ることができ、利便性を向上させることができる。

各乗車地点でユーザが乗車する毎に、運転手端末５は運行経路を切り換えて表示する。最終的に全てのユーザを乗車させた場合、運転手端末５は目的地（空港等）への運行経路を表示し、バス３を目的地に運行させる。

復路の場合、運転手端末５は出発地（空港等）から各ユーザの降車地点への経路を順次表示する。この場合、例えば運転手端末５は、出発地に到着した場合に到着ボタン１６３への操作入力を受け付け、各ユーザのユーザ端末２にバス３が到着した旨を通知して、乗車させる。運転手端末５は、バス３の運行状況に応じて各ユーザの降車地点への経路を表示し、降車地点を通過する毎に運行経路を切り換え、バス３が各降車地点に向かうよう経路案内を行う。

図１７は、事業者端末４が実行する処理手順の一例を示すフローチャートである。図１７に基づき、事業者端末４が実行する処理内容について説明する。
事業者端末４はサーバ１から、各ユーザからの利用要求（乗客情報）に基づいて生成された運行計画を複数取得する（ステップＳ３０１）。事業者端末４は、運行計画の内容と、運転手のスケジュール、車両のスケジュール、乗客情報、運転手情報、車両情報等とに基づき、各運行計画に割り当てる運転手及び車両を判定する（ステップＳ３０２）。事業者端末４は、取得した複数の運行計画を一覧表示する（ステップＳ３０３）。この場合に事業者端末４は、ステップＳ３０２で判定した運転手及び車両を割り当てた運行計画の一覧を表示する。

事業者端末４は、運行事業者からの操作入力に従い、当該運行事業者の下でバス３の運転に従事する各運転手の運転手情報を一覧表示する（ステップＳ３０４）。例えば事業者端末４は、図１５で例示したように、各運転手のバス３の運行スケジュール、運転手属性情報を含む各運転手のプロフィール等を一覧表示する。事業者端末４は、運行事業者からの操作入力に従って運行計画の一覧画面に戻り、各運行計画に割り当てる運転手及び車両の設定入力を受け付ける（ステップＳ３０５）。なお、運転手が決まれば、車両は当該運転手の使用する車両が決まる場合もあることから、車両の情報の入力を受けることは必須でない。逆に、車両が決まれば、当該車両を運転する運転手が決まる場合もあることから、運転手の情報の入力を受けることは必須でない。

事業者端末４は、運行事業者からの操作入力に基づき、運行計画を承認するか否かを判定する（ステップＳ３０６）。運行計画を承認すると判定した場合（Ｓ３０６：ＹＥＳ）、事業者端末４は、運行計画を承認する旨をサーバ１に通知する（ステップＳ３０７）。ステップＳ３０７の処理を実行後、又はステップＳ３０６でＮＯの場合、事業者端末４は一連の処理を終了する。

図１７には図示しないが、Ｓ３０７の後のサーバ１の処理について、説明する。サーバ１は、事業者端末４から、運行事業者が、運行計画を承認する旨の通知を受信した場合、当該受信に基づき、運行計画に、運行事業者（当該運行事業者の運転手又は車両であってもよい）を割り当てる処理をする。このように、運行計画に、運行事業者を割り当てる処理をした後も、当該運行計画に対応するクラスタに、新たに利用要求をした乗客が分類され、当該運行計画が修正されてもよい。運行計画の修正には、当該修正後の運行計画を運行事業者が承認することを条件としてもよい。また、このような運行計画の修正は、運行開始時刻から所定時間前まで行うことができることとしてもよい。さらに、運行開始時刻から所定時間前の時間に、運行計画が確定したこととして、当該運行計画に基づき運送する各ユーザに対し、各ユーザの乗車時間を通知してもよい。

図１７では、事業者端末４が、事業者端末４が実行する処理手順の一例を示すフローチャートとして説明をしたが、Ｓ３０１～Ｓ３０５までの処理をサーバ１が行い、運転手及び車両が設定された運行計画を、事業者端末４に送信し、事業者端末４が、当該運行計画を承認するか否かを判定する（ステップＳ３０６）こととしてもよい。

図１８は、運転手端末５が実行する処理手順の一例を示すフローチャートである。図１８に基づき、運転手端末５が実行する処理内容について説明する。
運転手端末５はサーバ１から、各ユーザからの利用要求（乗客情報）に基づいて生成された運行計画を取得する（ステップＳ３２１）。例えば運転手端末５は、運転手が当日運行予定の一又は複数の運行計画の情報を取得する。運転手端末５は、取得した一又は複数の運行計画を表示し、運行経路を表示する運行計画の選択入力を受け付ける（ステップＳ３２２）。

運転手端末５は、選択された運行計画について、各ユーザを乗車させる運行経路を表示する（ステップＳ３２３）。例えばステップＳ３２３で、まず運転手端末５は最初に乗車させるユーザの乗車地点に向かう経路を表示する。例えば運転手端末５は、乗車地点に向かう経路のほかに、当該乗車地点の到着予定時刻、当該乗車地点からの発車予定時刻、現在位置からの距離、残り運行時間等を表示する。また、例えば運転手端末５は、当該乗車地点で乗車させるユーザと連絡を取るためのオブジェクト（通話アイコン１６１、メッセージアイコン１６２等）を表示する。

運転手端末５は、連絡オブジェクトへの操作入力に応じて、乗車予定のユーザとの間で連絡を取るか否かを判定する（ステップＳ３２４）。連絡を取ると判定した場合（Ｓ３２４：ＹＥＳ）、運転手端末５は、サーバ１を経由して、表示中の乗車地点に対応するユーザのユーザ端末２との間で通話、又はメッセージの送信を行う（ステップＳ３２５）。

ステップＳ３２４でＮＯ、又はステップＳ３２５の処理を実行後、運転手端末５は、到着ボタン１６３への操作入力に基づき、バス３が乗車地点に到着したか否かを判定する（ステップＳ３２６）。到着していないと判定した場合（Ｓ３２６：ＮＯ）、運転手端末５は処理をステップＳ３２４に戻す。到着したと判定した場合（Ｓ３２６：ＹＥＳ）、運転手端末５はサーバ１を経由して、到着した乗車地点に対応するユーザのユーザ端末２に、バス３が到着した旨を通知する（ステップＳ３２７）。

運転手端末５は、運転手からの操作入力に応じて、ユーザが乗車したか否かを判定する（ステップＳ３２８）。乗車していないと判定した場合（Ｓ３２８：ＮＯ）、運転手端末５は処理を待機する。ユーザが乗車したと判定した場合（Ｓ３２８：ＹＥＳ）、運転手端末５は、全てのユーザを乗車させたか否かを判定する（ステップＳ３２９）。全てのユーザを乗車させていないと判定した場合（Ｓ３２９：ＮＯ）、運転手端末５は、次のユーザの乗車地点への経路に切り換えて表示し（ステップＳ３３０）、処理をステップＳ３２４に戻す。全てのユーザを乗車させたと判定した場合（Ｓ３２９：ＹＥＳ）、運転手端末５は目的地への経路を表示し（ステップＳ３３１）、一連の処理を終了する。

なお、運転手端末５は、目的地に到達した場合、サーバ１に対し、目的地に到達したことを通知してもよい。サーバ１は、目的地に到達した場合に、ユーザに対し、目的地に到達したことを通知すると共に、ユーザの乗車代金の支払いに関する処理を行ってもよい。

以上より、本実施の形態３によれば、サーバ１が自動生成した運行計画の円滑な遂行を支援することができる。

今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ サーバ（情報処理装置）
１１ 制御部
１２ 主記憶部
１３ 通信部
１４ 補助記憶部
Ｐ１ プログラム
１４１ ユーザＤＢ
１４２ バスＤＢ
１４３ 運転手ＤＢ
１４４ 運行計画ＤＢ
２ ユーザ端末
２１ 制御部
２２ 主記憶部
２３ 通信部
２４ 表示部
２５ 入力部
２６ 位置情報取得部
２７ 補助記憶部
Ｐ２ プログラム
３ バス（車両）
４ 事業者端末
５ 運転手端末

Claims (16)

1. 複数の乗客が相乗りする車両の利用を所定の時点までに既に予約している前記乗客の乗車地点又は降車地点と、該乗客の乗車時刻又は降車時刻とを示す第１乗客情報を取得する第１取得部と、
   前記所定の時点までに取得した前記第１乗客情報に基づき、前記既に予約している乗客を複数の集合に分類する分類部と、
   前記集合毎に、複数の前記乗客を乗車又は降車させながら運行する経路を示す運行計画を生成する生成部と、
   前記車両の利用を前記所定の時点以降に申し込んだ新たな前記乗客の乗車地点又は降車地点と、該乗客の乗車時刻又は降車時刻とを示す第２乗客情報を取得する第２取得部とを備え、
   前記所定の時点以降に前記第２乗客情報を取得した場合、前記分類部は、該第２乗客情報に基づき、前記既に予約している乗客の前記集合に前記新たな乗客を分類すべきか否かを判定し、
   前記新たな乗客を前記集合に分類すべきと判定した場合、前記生成部は、前記既に予約している乗客が乗車する前記車両に変更が生じない範囲で、前記集合に対応する前記車両に前記新たな乗客を乗車又は降車させるように、生成済みの前記運行計画を更新する
   ことを特徴とする情報処理装置。
2. 前記乗客の属性を表す乗客属性情報を取得する第３取得部を備え、
   前記生成部は、前記乗客属性情報に基づき、前記乗客を前記複数の集合に分類する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記車両の運転手の属性を表す運転手属性情報を取得する第４取得部を備え、
   前記生成部は、前記運転手属性情報に基づき、前記乗客を前記複数の集合に分類する
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記車両の属性を表す車両属性情報を取得する第５取得部を備え、
   前記生成部は、前記車両属性情報に基づき、前記乗客を前記複数の集合に分類する
   ことを特徴とする請求項１～３のいずれか１項に記載の情報処理装置。
5. 前記車両は、所定の出発地と、目的地である空港との間を往復する車両であって、
   前記生成部は、前記第１及び第２乗客情報に基づき、前記車両の往路又は復路を示す前記運行計画であって、前記乗客が利用する航空機の離発着時刻の所定時間前までに送迎を完了させる前記運行計画を生成する
   ことを特徴とする請求項１～４のいずれか１項に記載の情報処理装置。
6. 前記分類部は、所定時間で区切った時間帯毎に前記乗客を前記集合に分類し、
   前記生成部は、前記時間帯毎に分類された前記集合毎に前記運行計画を生成することで、前記離発着時刻の所定時間前までに送迎を完了させる前記運行計画を生成する
   ことを特徴とする請求項５に記載の情報処理装置。
7. 前記生成部は、複数の前記車両のうち、前記乗客が無乗車である前記車両の台数を参照して前記運行計画を生成する
   ことを特徴とする請求項１～６のいずれか１項に記載の情報処理装置。
8. 前記生成部は、前記乗客が希望する乗車地点とは異なる乗車地点で前記乗客を乗車させる前記運行計画を生成し、
   前記運行計画で定めた乗車地点を前記乗客に通知する通知部を備える
   ことを特徴とする請求項１～７のいずれか１項に記載の情報処理装置。
9. 前記第１又は第２取得部は、前記乗客が希望する乗車時刻又は降車時刻と、前記車両が前記乗客を乗車又は降車させる乗車時刻又は降車時刻との間で許容される許容時間を含む前記第１乗客情報又は第２乗客情報を取得し、
   前記生成部は、前記許容時間の範囲内で前記乗車時刻又は降車時刻を定めた前記運行計画を生成する
   ことを特徴とする請求項１～８のいずれか１項に記載の情報処理装置。
10. 前記許容時間に応じて前記乗客の乗車料金を設定する第１設定部を備える
    ことを特徴とする請求項９に記載の情報処理装置。
11. 前記第２取得部は、前記新たな乗客の需要に関連する需要情報、又は前記車両の供給に関連する供給情報を取得し、
    前記生成部は、前記需要情報又は供給情報に応じて前記車両に空き座席を設けた前記運行計画を生成する
    ことを特徴とする請求項１～１０のいずれか１項に記載の情報処理装置。
12. 前記需要情報又は供給情報に基づき、前記乗客の乗車料金を設定する第２設定部を備える
    ことを特徴とする請求項１１に記載の情報処理装置。
13. 前記運行計画を参照して、前記車両の座席の空き状況を判定する判定部と、
    前記座席の空き状況を、所定の乗客候補者の携帯端末に出力する出力部と
    を備え、
    前記第２取得部は、前記座席の空き状況の出力先から前記第２乗客情報を取得する
    ことを特徴とする請求項１～１２のいずれか１項に記載の情報処理装置。
14. 前記運行計画に割り当てる運転手又は車両を、前記運行計画の内容と、前記運転手のスケジュール、前記車両のスケジュール、前記第１乗客情報、前記第２乗客情報、前記運転手に関する運転手情報、及び前記車両に関する車両情報の少なくとも何れか一つとに基づき判定する第２判定部を備える
    ことを特徴とする請求項１～１３のいずれか１項に記載の情報処理装置。
15. 複数の乗客が相乗りする車両の利用を所定の時点までに既に予約している前記乗客の乗車地点又は降車地点と、該乗客の乗車時刻又は降車時刻とを示す第１乗客情報を取得し、
    前記所定の時点までに取得した前記第１乗客情報に基づき、前記既に予約している乗客を複数の集合に分類し、
    前記集合毎に、複数の前記乗客を乗車又は降車させながら運行する経路を示す運行計画を生成し、
    前記車両の利用を前記所定の時点以降に申し込んだ新たな前記乗客の乗車地点又は降車地点と、該乗客の乗車時刻又は降車時刻とを示す第２乗客情報を取得し、
    前記所定の時点以降に前記第２乗客情報を取得した場合、該第２乗客情報に基づき、前記既に予約している乗客の前記集合に前記新たな乗客を分類すべきか否かを判定し、
    前記新たな乗客を前記集合に分類すべきと判定した場合、前記既に予約している乗客が乗車する前記車両に変更が生じない範囲で、前記集合に対応する前記車両に前記新たな乗客を乗車又は降車させるように、生成済みの前記運行計画を更新する
    処理をコンピュータが実行することを特徴とする情報処理方法。
16. 複数の乗客が相乗りする車両の利用を所定の時点までに既に予約している前記乗客の乗車地点又は降車地点と、該乗客の乗車時刻又は降車時刻とを示す第１乗客情報を取得し、
    前記所定の時点までに取得した前記第１乗客情報に基づき、前記既に予約している乗客を複数の集合に分類し、
    前記集合毎に、複数の前記乗客を乗車又は降車させながら運行する経路を示す運行計画を生成し、
    前記車両の利用を前記所定の時点以降に申し込んだ新たな前記乗客の乗車地点又は降車地点と、該乗客の乗車時刻又は降車時刻とを示す第２乗客情報を取得し、
    前記所定の時点以降に前記第２乗客情報を取得した場合、該第２乗客情報に基づき、前記既に予約している乗客の前記集合に前記新たな乗客を分類すべきか否かを判定し、
    前記新たな乗客を前記集合に分類すべきと判定した場合、前記既に予約している乗客が乗車する前記車両に変更が生じない範囲で、前記集合に対応する前記車両に前記新たな乗客を乗車又は降車させるように、生成済みの前記運行計画を更新する
    処理をコンピュータに実行させることを特徴とするプログラム。

Images