JP7201503B2 - 移動サービスシステムおよび移動サービス提供方法 - Google Patents

Description

本発明は、利用者の不満の度合いを利用して交通サービスの車両運行を制御する技術に関する。

一般的に、公共交通サービスでは、サービス提供者がサービス内容を予め決定し、運用している。つまり、サービス提供者が予め車両運行のスケジュール（ダイヤ）を定め、そのスケジュールに従って車両を運行している。

これに対して、特許文献１には、タイムテーブルに従って運行行路を運行するバスが所定の時刻にチェックポイントに到達していないと判定した場合、臨時乗り物を出動させる技術が開示されている。

特許文献２には、提供者の車両に他の利用者を相乗りさせるための技術が開示されている。提供者の車両の移動経路の過去の実績情報を蓄積し、その実績情報を参照して移動計画を立案した後、車両の提供者に相乗りの受け入れを依頼し、提供者が依頼を受け入れたら、提供者の車両に相乗り希望者を相乗りさせる。
特許文献３には、車両の疑似する仮想オブジェクトを使ったコンピュータシミュレーションによって、交通状況を再現して評価する技術が開示されている。

非特許文献１には、人の移動（乗用車）と物の移動（貨物車）について交通量を推計し、発生集中交通量、分布交通量、および配分交通量を含む将来の交通需要を推計する計算式およびパラメータが開示されている。

特開２００６－１６３７３８号公報 特開２０１５－１９１３６４号公報 特開２０１３－０８０２７２号公報

「技術調査 将来交通需要推計の見直し」、国土交通省、（http://www.mlit.go.jp/tec/tec_mn_000003.html（２０１８年１２月１１日））

上述したように、従来の公共交通サービスには、利用者が抱く不満を定量的に車両の運行に反映させるものはなかった。
本開示のひとつの目的は、利用者の不満の度合いを車両の運行に反映させることで、利用者への交通サービスの向上を可能にする技術を提供することである。

本開示によるひとつの移動サービスシステムは、移動リソースを運行して利用者を移動させるサービスを提供する移動サービスシステムであって、前記利用者に関する第１データベースを記憶し、前記利用者の要求を管理する第１管理装置と、前記移動リソースに関する第２データベースを記憶し、前記移動リソースの運行の状態を管理する第２管理装置と、前記第１管理装置および前記第２管理装置と連携して、前記移動リソースの運行を変更する第３管理装置と、を有し、前記第３管理装置は、前記利用者に発生する不満を数値で取得し、前記第１管理装置は、前記不満に応じて、前記移動リソースの運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを前記第１データベースに記録し、前記第３管理装置は、前記利用者から要求を受けて、前記第１データベースに管理されている該利用者に付与されているポイントと引き換えに、前記要求と前記第２データベースに管理されている前記移動リソースの運行の状態とに基づき、前記移動リソースの運行の計画を変更する。

本開示によれば、利用者の不満の度合いを車両の運行に反映させることで、利用者への交通サービスの向上を可能にする。

本実施形態に係る需要マネジメント型交通サービスシステムのハードウェア構成を示すブロック図である。 本実施形態の需要マネジメント型交通サービスシステムの各サーバ装置のハードウェア構成を説明するためのブロック図である。 本実施形態の需要マネジメント型交通サービスシステムの各端末装置のハードウェア構成を説明するためのブロック図である。 乗客情報管理サーバが備える住民データベースのＥＲ図である。 住民パラメータのスキーマを示すテーブルである。 バス運行管理サーバが備えるバスデータベースのＥＲ図である。 バス走行ログ１３－４５のスキーマを示すテーブルである。 運行計画サーバが備える集計データベースのＥＲ図である。 エリア別集計結果のスキーマを示すテーブルである。 本実施形態の需要マネジメント型交通サービスシステムが適用される全体サービスエリアの一例を示す図である。 本実施形態の需要マネジメント型交通サービスシステムによるオンラインでの運行計画の変更の様子を示す路線概念図である。 運行計画を変更するときの乗客情報端末の画面例を示す図である。 本実施形態の需要マネジメント型交通サービスシステムによるリクエストの処理を示すシーケンス図である。 需要マネジメント型交通サービスシステムが乗客からアンケートへの回答を取得する処理のシーケンス図である。 不満を集計した結果を表示したＧＵＩの画面例を示す図である。 各エリアの不満を集計した結果をエリア毎に表示したＧＵＩの画面例を示す図である。 バス運行計画を立案する処理を示すシーケンス図である。

本実施形態では乗客を移動させるために運行する移動リソースとしてバスを例示する。本実施形態のシステムは、バスを運行して乗客を移動させるサービスを提供するシステムである。本サービスは、乗客となりうる利用者がバスの運行の変更を要求することが可能なサービスである。バスは、移動リソースの一例であり、これに限定されるものではない。本例の他の陸上交通手段であっても良いし、水上交通手段や空中交通手段などであってもよい。
以下、本実施形態について図面を参照して説明する。
なお、以下に説明する実施形態は発明を限定するものではない。また、実施形態の中で説明されている諸要素及びその組み合わせの全てが発明に必須ではない。
図１は、本実施形態に係る需要マネジメント型交通サービスシステムのハードウェア構成を示すブロック図である。

図１において、需要マネジメント型交通サービスシステムは、運行計画サーバ１１、乗客情報管理サーバ１２、バス運行管理サーバ１３、およびバス運行指示端末１４を含んでいる。バス運行指示端末１４は、乗務員が操作可能にバス車両に搭載されるか、あるいはバスの乗務員が携帯する情報処理端末である。バス運行指示端末１４には乗務員にバスの運行を指示する情報が表示される。

乗客情報端末１５は、バスを利用する乗客が携帯する端末であり、乗客が所有するスマートホンなどのモバイル端末であってよい。

運行計画サーバ１１は、乗客情報管理サーバ１２、バス運行管理サーバ１３、バス運行指示端末１４、および乗客情報端末１５とネットワーク１６で相互に接続される。

ネットワーク１６の態様は、例えば、乗客情報管理サーバ１２およびバス運行管理サーバ１３では有線ネットワークで接続され、バス運行指示端末１４および乗客情報端末１５は無線ネットワークで接続されるケースがある。しかし、ネットワーク１６のどの部分が有線ネットワークあるいは無線ネットワークかについては特に限定されない。

図２は、本実施形態の需要マネジメント型交通サービスシステムの各サーバ装置のハードウェア構成を説明するためのブロック図である。運行計画サーバ１１と乗客情報管理サーバ１２とバス運行管理サーバ１３は基本的なハードウェア構成が共通する情報処理装置であり、そのハードウェア構成が図２に示されている。

図２を参照すると、情報処理装置は、ＣＰＵ１－０１、メモリ１－０２、通信ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１－０３、ハードディスクドライブ（以下、ＨＤＤという）１－０４、入出力コントローラ１－０５、モニタコントローラ１－０６、バス１－０７、ディスプレイ１－１３、キーボード１－１１、およびマウス１－１２を有している。ＣＰＵ１－０１、メモリ１－０２、通信ＮＩＣ １－０３、ＨＤＤ １－０４、入出力コントローラ１－０５およびモニタコントローラ１－０６はバス１－０７に接続されている。入出力コントローラ１－０５は、キーボード１－１１およびマウス１－１２に接続されている。モニタコントローラ１－０６には、ディスプレイ１－１３が接続されている。
ＣＰＵ１－０１は、メモリ１－０２上のソフトウェアプログラムを実行することで各サーバの機能を実現する。
メモリ１－０２は、サーバの機能を実現するためのソフトウェアプログラムおよびそのソフトウェアの処理に利用される各種データを記憶する装置である。
通信ＮＩＣ １－０３は、サーバがネットワーク１６に接続し、データ等を送受信するための装置である。

ＨＤＤ １－０４は、サーバの処理に利用されるデータベースが格納されている。例えば、乗客情報管理サーバ１２のＨＤＤ １－０４には、住民に関する情報を蓄積したデータベースが格納される。また、バス運行管理サーバ１３のＨＤＤ １－０４には、バスに関する情報を蓄積したデータベースが格納される。
入出力コントローラ１－０５は、キーボード１－１１およびマウス１－１２によるサーバへのデータの入出力を制御する装置である。
モニタコントローラ１－０６は、ディスプレイ１－１３への画面の表示を制御する装置である。
ディスプレイ１－１３は、操作者に対して、画像やテキストを含む画面を表示する表示装置である。
キーボード１－１１、およびマウス１－１２は、操作者による操作を受け、操作のデータを入出力コントローラ１－０５に出力する装置である。

図３は、本実施形態の需要マネジメント型交通サービスシステムの各端末装置のハードウェア構成を説明するためのブロック図である。バス運行指示端末１４と乗客情報端末１５は基本的なハードウェア構成が類似する情報処理装置であり、その説明のためのハードウェア構成が図３に示されている。

図３の端末装置は、図２のサーバ装置におけるキーボード１－１１、マウス１－１２およびディスプレイ１－１３の代わりにタッチパネル１－１５を有している。なお、端末装置のうち乗客情報端末１５は、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）モジュール１－０８とＩＣリーダモジュール１－１４を有している。
タッチパネル１－１５は、乗客に対して画面を表示し、かつ、乗客による画面への操作を受け付ける装置である。

ＧＰＳモジュール１－０８は、ＧＰＳ衛星からの電波を受信し、自身の位置情報を出力する装置である。位置情報は、乗客の位置を示す情報として処理に利用される。

ＩＣリーダモジュール１－１４は、ＩＣカードに記録されたデータを読みだして出力する装置である。ＩＣカードから読み出したデータは処理に利用されてもよい。

図４は、乗客情報管理サーバが備える住民データベースのＥＲ（Ｅｎｔｉｔｙ Ｒｅｌａｔｉｏｎｓｈｉｐ）図である。住民データベース１２－４０は、本需要マネジメント型交通サービスシステムがサービスを提供するサービスエリアの住民である。この住民がバスの乗客となることが想定されている。住民データベース１２－４０には、住民パラメータ１２－４１、リクエスト発行情報１２－４２、およびリクエスト消化ログ１２－４３が含まれている。住民パラメータ２１－４１には、本システムのバスの乗客となりうる地域の各住民に関する各種情報が設定されている。リクエスト発行情報１２－４２には、住民が発行したリクエストに関する情報が設定されている。住民パラメータ１２－４１にて管理されている１人の住民に、０個以上のリクエストが対応しうる。

リクエストには、乗客（バスに乗車しようとしている住民）がバスへの乗車に関して要求する要求事項が含まれている。バスの運行を変更する必要のあるような要求がリクエストに含まれている場合もある。リクエストが採用され、実施されると、そのリクエストは消化される。

リクエスト消化ログ１２－４３は、住民が発行したリクエストの消化に関する情報である。リクエストが発行されると、リクエスト発行情報テーブル１２－４２にそのリクエストのインデックス（不図示）が登録される。インデックスには、リクエストを発行した乗客、その乗客が乗車するバス、乗客がバスに乗車する乗車場所、乗客が降車する降車場所の情報が含まれている。

その後、そのリクエストが実行されると、そのリクエストが消化されたことがリクエスト消化ログテーブル１２－４３にログ情報として記録される。リクエストは、乗客がバスへ乗車し降車することにより実行される。バスの運行の変更を要するリクエストが採用された場合には、リクエストの実行はバスの運行の変更を伴う。

需要マネジメント型交通サービスシステムの提供するサービスに対して生じた住民の不満はポイントとして蓄積される。住民が乗客としてバスを利用すると、需要マネジメント型交通サービスシステムは、その住民がバスの運行に関連して抱いた不満を、その乗客がバスから降車するときにアンケートへの回答を求めることにより、知得する。ポイントは、バスの運行を自身の都合の良いように変更することを要求するために利用可能な仮想債券である。バスの乗客となるある住民が発行したリクエストが採用されると、リクエストの採用に伴い、リクエストを発行した住民の不満度は低下することが期待できる。そして、その住民の所持しているポイントは、そのリクエストの採用により発生が推定される他の住民（同じバスに乗車している他の乗客）の不満を相殺するだけのポイントが消化される。一方、同じバスに乗車している他の乗客には、別途される不満の表明に応じてポイントが付与される。

住民パラメータ１２－４１には、住民ＩＤ、不満度（時間／混雑／着席／騒音／場所）、不満度に係る係数（時間／混雑／着席／騒音／場所）、所有ポイント、住民の住所座標（経度，緯度）、徒歩速度［ｋｍ／ｈ］、騒音の発生レベルを表すパラメータ、リクエスト時刻決定用の乱数生成パラメータ（往路μ、往路σ、復路μ、復路σ）、住民の属性（性別、年齢、職業、その他）という項目が含まれている。図５は、住民パラメータのスキーマを示すテーブルである。住民パラメータ１２－４１の各項目には、図５に示されたスキーマに従って情報が設定される。

住民ＩＤは、各住民を個々に識別する識別情報である。

不満度は、当該住民の不満の度合いを数値で示す情報である。不満には、時間に関する不満、混雑に関する不満、着席に関する不満、騒音に関する不満、場所に関する不満が含まれている。時間に関する不満とは、バスの到着の遅れにより当該住民がバスの停留所（バス停）で待つ時間に対する不満である。混雑に関する不満とは、当該住民が搭乗したバス内の混雑に対する不満である。着席に関する不満とは、当該住民が搭乗したバスにおいて座席に座れないことに対する不満である。騒音に関する不満とは、当該住民が搭乗したバス内の騒音に対する不満である。場所に関する不満とは、バスの搭乗の前あるいは後に当該住民が歩く距離に対する不満である。例えば出発場所と乗車場所が異なれば住民はその間を歩く必要がある。また、降車場所と到着場所が異なれば住民はその間を歩く必要がある。

不満度に係る係数は、時間、混雑、着席、騒音、または場所のそれぞれに対する不満に対する当該住民の重視の度合いを示す値である。

所有ポイントは、当該住民が所有しているポイントを示す情報である。

住民の住所座標は、当該住民の住所を示す情報であり、経度および緯度により示される。

徒歩速度は、当該住民の歩く速度を示す情報であり、ｋｍ／ｈという単位で示される。

騒音の発生レベルを表すパラメータは、当該住民が搭乗することによりバス内の騒音が増大する度合いを示すパラメータである。

リクエスト時刻決定用の乱数生成パラメータは、リクエストが発行される時刻を決定するためのパラメータである。リクエスト時刻決定用の乱数生成パラメータとして、往路の出発時刻の平均値μおよび標準偏差σと、復路の出発時刻の平均値μおよび標準偏差σとが設定される。

住民の属性は、当該住民の各種属性を示す情報である。住民の属性には、性別、年齢、職業等が含まれる。

図６は、バス運行管理サーバが備えるバスデータベースのＥＲ図である。バスデータベース１３－４０には、バス車体パラメータ１３－４１、バス折返し発車予定時刻１３－４２、バス基本経路の移動順序－停留所対応表１３－４３、基本経路上の停留所１３－４４、およびバス走行ログ１３－４５が含まれている。

バス車体パラメータ１３－４１は、本システムの移動リソースとして乗客を移動させる各バス車体に関する情報である。バス車体パラメータテーブル１３－４１には、バス車体ＩＤ、バス識別名、バス基本経路ＩＤ、運賃収入［円］、走行距離［ｋｍ］、運賃計算用の係数のインデックスがあり、各インデックスに情報が記載される。

バス折返し発車予定時刻１３－４２は、各バス車体の始発場所からの運行に関する情報である。通常、１台のバス車体が１回以上の運行に利用されるので、バス折返し発車予定時刻テーブル１３－４２には、１台のバス車体に対して１つ以上の運行に関する情報が記録される。バス折返し発車予定時刻テーブル１３－４２には、バス車体ＩＤ、バスの出発方向（例えば逆方向か否か）、発車時刻のインデックス（不図示）があり、各インデックスに情報が記載される。

バス基本経路の移動順序－停留所対応表１３－４３は、各バス車体の運行における基本経路に関する情報である。基本経路は、変更のリクエストが無ければバスが運行する予定の経路である。通常、ひとつの基本経路を複数のバス車体が運行する。また通常、１台のバス車体は複数の基本経路を運行する。バス基本経路の移動順序－停留所対応表テーブル１３－４３には、バス基本経路ＩＤ、停留所順序番号、停留所ＩＤのインデックス（不図示）があり、各インデックスに情報が記載される。

基本経路上の停留所１３－４４は、基本経路上にある各停留所に関するテーブル情報である。基本経路上の停留所１３－４４のテーブルには、各停留所の停留所ＩＤ、停留所名称、ＧＩＳ節点ＩＤ、停留所種別のインデックス（不図示）があり、各インデックスに情報が記載される。

ＧＩＳ節点ＩＤは、地理情報システム（ＧＩＳ（Ｇｅｏｇｒａｐｈｉｃ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ）の節点を個々に識別する識別情報である。ＧＩＳ節点は例えば交差点である。ＧＩＳ節点は、例えば、節点番号、経度、緯度、ジオメトリ情報により示される。

バス走行ログ１３－４５は、各バス車体の運行に関する履歴情報のテーブルである。バス走行ログ１３－４５のテーブルには、車体ＩＤ、日付番号（何日目）、始発時刻、始発停留所、終着時刻、終着停留所、方向（逆方向か否か）、延べ乗車人数、走行１回分の運賃収入［円］、走行１回分の走行距離［ｋｍ］のインデックス（不図示）があり、各インデックスに情報が記載される。図７は、バス走行ログ１３－４５のスキーマを示すテーブルである。バス走行ログ１３－４５の各インデックスには、図５に示されたスキーマに従って情報が設定される。

図８は、運行計画サーバが備える集計データベースのＥＲ図である。集計データベース１１－４０には、集計結果１１－４１、エリア別集計結果１１－４２、およびエリア定義１１－４３が含まれている。

集計結果１１－４１は、バス運行の結果を集計した情報である。集計結果１１－４１のテーブルには、日付番号（何日目）、バスの総運賃収入（日計）［円］、バスの総走行距離（日計）［ｋｍ］のインデックスがあり、各インデックスに情報が記載される。

エリア別集計結果１１－４２は、バス運行の結果をエリア毎に集計した情報である。エリアは、全体サービスエリアを所定サイズの矩形に区分けしたエリアである。図９は、エリア別集計結果のスキーマを示すテーブルである。エリア別集計結果１１－４２のテーブルには、日付番号（何日目）、エリアＩＤ、エリア別満足度平均（終値）のインデックス（不図示）があり、各インデックスには、図９に示したスキーマに従った情報が記載される。エリア別満足度平均は、エリア毎に、時間、混雑、着席、騒音、および場所の全項目の不満の合計値を負数にした値である。更に、時間、混雑、着席、騒音、および場所の項目毎にエリア別満足度平均を求め、集計結果１１－４２に含めて記録してもよい。

エリア定義１１－４３は、全体サービスエリアに含まれる各エリアの定義情報である。エリア定義１１－４３のテーブルには、エリアＩＤ、矩形座標（左上座標、右下座標）のインデックス（不図示）があり、各インデックスに情報が記載される。

図１０は、本実施形態の需要マネジメント型交通サービスシステムが適用される全体サービスエリアの一例を示す図である。一例として、全体サービスエリアは、面積約３０平方キロメートル、人口約１２万人で、バスの利用者数が約４５００人／日である。

この全体サービスエリアには、５つのバス定期運行の路線があるとする。それらは、それぞれＧｒｅｅｎ Ｌｉｎｅ（ＧＬ）、Ｒｅｄ Ｌｉｎｅ（ＲＬ）、Ａｑｕａ Ｌｉｎｅ（ＡＬ）、Ｂｌｕｅ Ｌｉｎｅ（ＢＬ）、Ｙｅｌｌｏｗ Ｌｉｎｅ（ＹＬ）と称呼される路線である。

図１１は、本実施形態の需要マネジメント型交通サービスシステムによるオンラインでの運行計画の変更の様子を示す路線概念図である。図１２は、運行計画を変更するときの乗客情報端末の画面例を示す図である。

図１１に示されたバス８－１０は、その情報がバス車体パラメータテーブル１３－４１に記載されているバスであるとする。バス８－１０は、バス基本経路の移動順序－停留所対応表テーブル１３－４３に記載されている出発停留所８－０１から到着停留所８－０４に向けて運行をする。基本経路は、出発停留所８－０１、固定停留所８－０２、固定停留所８－０３、到着停留所８－０４とたどる経路である。固定停留所８－０２、８－０３は、運行計画を変更するときにも必ず通る必要のある停留所であるとする。

ここで、住民パラメータテーブル１２－４１に記載されている、ある乗客８－０５が、乗客情報端末１５を使って、バスへの乗車を要求するリクエストを発行したものとする。このリクエストは、乗客情報管理サーバ１２にてリクエスト発行情報１２－４２テーブルに登録される。

乗客８－０５は、リクエストにおいて、乗客自身の出発場所８－０６と到着場所８－０７を任意に指定できる。例えば、自宅をを出発場所とし、最終的に行きたい場所を到着場所に指定することができる。図１２に示された乗客情報端末１５の画面例８－０５０１には出発場所と到着場所を指定する例が示されている。画面例８－０５０１には、出発場所として自宅を指定し、到着場所としてＡ病院を指定した例が示されている。また、乗客８－０５は、リクエストにおいて、出発場所に近い場所８－０８にバスを停車してもらうという希望および／または到着場所に近い場所８－０９にバスを停車してもらうという希望を提示することができてもよい。

また、乗客８－０５はリクエストにおいて他の様々な希望について優先づけを指定することもできる。例えば、希望の場所への停車を他の項目よりも優先すること（場所優先）を指定できる。また、バス停にて待つ時間を短くすることを他の項目よりも優先すること（時間優先）を指定できる。また、車内が空いており空間的に余裕のあるバスを他の項目よりも優先すること（間隙優先）を指定できる。また、座席に座ることができることを他の項目よりも優先すること（着席優先）を指定できる。また、車内の騒音レベルが低いことを他の項目よりも優先すること（静寂優先）を指定できる。図１２の画面例８－０５０２には、到着希望時刻と共に時間優先を指定するときの画面例が示されている。図１２の画面例８－０５０２は画面例８－０５０１を下方にスクロールした一連の画面である。

乗客８－０５からのリクエストは、需要マネジメント型交通サービスシステムにて処理される。リクエストの処理の詳細は後述する。処理の結果、バス８－１０は、予め定められた基本路線から外れ、ある程度出発場所または到着場所に近い場所（例えば、図１１の場所８－１１）に停車する場合もあるし、予め定められた基本路線上の場所８－１２に停車する場合もある。リクエストに応じたバスの運行が行われると、バスの運行の結果は、リクエスト消化ログ１２－４３に記録される。

更に、乗客８－０５がバスを降車する場所（例えば、図１１の場所８－０９）にバス８－１０が到着すると、需要マネジメント型交通サービスシステムは、乗客８－０５の乗客情報端末１５にアンケートを提示し、乗客８－０５の回答を取得する。乗客８－０５は、バスの利用において不満があった場合にはこの回答にて不満を表明することができる。図１２の画面例８－０５０３には、アンケートを表示し、乗客へ回答を促す画面の例が示されている。需要マネジメント型交通サービスシステムが乗客からアンケートへの回答を取得する処理の詳細は後述する。
図１３は、本実施形態の需要マネジメント型交通サービスシステムによるリクエストの処理を示すシーケンス図である。

乗客情報端末１５はバスの乗車に関するリクエストを運行計画サーバ１１に送信（１５－９１１）する。リクエストを受信した運行計画サーバ１１は、バス運行管理サーバ１３に、出発場所および到着場所を提示して、乗客が利用可能なバスを問い合わせる（１１－９１１）。問い合わせを受けたバス運行管理サーバ１３は、提示された出発場所および到着場所を基に、利用可能なバスを選択し（１３－９１１）、運行計画サーバ１１に通知する。このとき１つ以上のバスが通知される。
乗客が利用可能なバスの通知を受けた運行計画サーバ１１は、通知されたバスの中に、乗客の希望を満たすバスがあるか否か調べる（１１－９１２）。
乗客の希望を満たすバスがある場合は、運行計画サーバ１１は、そのバスを選択する（１３－９１３）。

次に、運行計画サーバ１１は、リクエストに、出発場所または到着場所に近い場所へのバスのルートを変更することの要求（以下、付近ピックアップ要求という）が含まれているか否か調べる（１１－９１４）。付近ピックアップ要求が場合には、運行計画サーバ１１は、出発場所に近い停留所を乗客が乗車すべき停留所とし、到着場所に近い停留所を乗客が降車すべき停留所として、それら停留所を停車ポイントとし（１１－９１５）、乗客が利用可能な１以上のバスの候補を、停車ポイントと共に乗客情報端末１５に通知する。乗客情報端末１５は通知されたバスの情報を乗客が利用する候補として表示する（１５－９１２）。

ステップ１１－９１４にて、付近ピックアップ要求があった場合、すなわち、ルート変更の要求があった場合、バス運行管理サーバ１３は、リクエストを発行した乗客が利用可能なバスに既に乗車している乗客に生じると予測される不満の情報と、バスの運行を変更することにより生じるコストとの情報を、バス運行管理サーバ１３に要求する。バスの運行が変更されたとき、そのバスに乗車している乗客は、自身の降車場所へのバスの到着時刻が遅れれば、不満を抱くことが考えられる。更に、バス運行管理サーバ１３は、リクエストを発行した乗客の所持しているポイントの情報を乗客情報管理サーバ１２３に要求する。

バス運行管理サーバ１３は、当該バスに乗車している乗客を把握しており、乗客情報管理サーバ１２は、全ての住民の不満度係数を把握している。バス運行管理サーバ１３は、乗客情報管理サーバ１２と連携して当該バスに乗車している全ての乗客の不満度係数の情報を取得し、その不満度係数に基づいて、全ての乗客に生じる不満の合計値を算出する。例えば、バス運行管理サーバ１３は、当該バスの運行を変更したとき当該バスの全ての乗客が不満を表明した場合に生じる不満の合計値を算出すればよい。また、バス運行管理サーバ１３は、当該バスの運行を変更することにより生じるコストを算出する。そして、バス運行管理サーバ１３は、算出した不満の合計値の情報と算出したコストの情報とを運行計画サーバ１１に通知する（１３－９１２）。

また、乗客情報管理サーバ１２は、全ての住民の所持しているポイントを把握しているので、その中から、リクエストを発行した乗客の所持しているポイントの情報を運行計画サーバ１１に通知する（１２－９１１）。
ここで、図１３を用いたリクエスト処理の説明を一旦中断し、本システムにおける「不満」と「ポイント」について説明する。

本実施形態における「不満」はバスの運行あるいは乗車に対する不満である。不満には、上述したように、時間に関する不満、混雑に関する不満、着席に関する不満、騒音に関する不満、場所に関する不満という５つの項目の不満が含まれている。バスの運行あるいは乗車に対する不満は、これら５つの項目の不満の合計である。本実施形態では、時間、混雑、着席、騒音、場所に対する不満と、それらの合計であるバスの運行あるいは乗車に対する不満とは、数値により表現したり演算したりを可能としている。

「不満」は、過去３０日間の「不満変数」と「不満度係数」という２つの要素の積の総計である。「不満度係数」は、「不満変数」に対する係数であり、乗客の嗜好によって値が変動する。ただし、「不満度係数」が３０日間にわたりに変動しなかった場合、乗客情報管理サーバ１２は、「不満度係数」を予め定められた一定値に初期化する。

行動心理学において、「不満」は長期間維持しないが、短期間繰り返されることで蓄積し続ける」ことが知られている。また、類似事象である鉄道の運行の例では乗客の不満は２週間程度で忘却されることが経験的に推定されている。上記３０日は、一例として、マージンを含めて２週間の約２倍の期間を設定したものである。

一方、本実施形態における「ポイント」は、「不満」に対する代償として、バス会社から与えられる仮想的な債券である。「ポイント」は、上述した「不満」とは異なり、時間の経過で減失することはない。

需要マネジメント型交通サービスシステムは、リクエストを発行した乗客の所持している「ポイント」を、そのリクエストにより提示された希望を実現するか否かを判断する材料として使用する。そして、その希望を実現すると、需要マネジメント型交通サービスシステムは、実現した希望に応じた「ポイント」を消滅あるいは回収する。

このように「ポイント」は、乗客同士の互いに対立する利害を調整する媒体として使用される。「ポイント」の使用の結果として、乗客の「不満」が解消されることもある。

次に本実施形態における不満の算出について説明する。
本実施形態における不満は以下の式（１）により算出される。
Ｄｉｓ＝Ｐｔ・Ｔ＋Ｐｉ・Ｉ＋Ｐｓ・Ｓ＋Ｐａ・Ａ＋Ｐｌ・Ｌ …（１）

式（１）において、Ｄｉｓは乗客の不満を示す。不満Ｄｉｓは、直近の過去３０日についての不満度係数と不満変数の積の合計である。上記３０日は、類似事象である鉄道の運行の例では乗客の不満は２週間程度で忘却されるという経験則に基づき、マージンを含めて２週間の約２倍の期間を設定した例である。

Ｐｔは、Ｐｒｉｏｒｉｔｙ ｏｆ ｔｉｍｅの略であり、時間に関する不満に対する係数（不満度係数）である。時間優先が指定されると係数Ｐｔの値が大きくなる。Ｔは、乗客が停留所等でバスを待った時間を示す不満変数である。Ｐｉは、Ｐｒｉｏｒｉｔｙ ｏｆ ｉｎｔｅｒｖａｌの略であり、混雑に関する不満に対する係数である。Ｉは、バスの定員に対する実際に乗車している乗客の人数の割合すなわち乗車率を示す不満変数である。乗車率が低ければ、バス内での乗客同士の間隙が大きくなる。間隙優先が指定されると係数Ｐｉの値が大きくなる。Ｐｓは、Ｐｒｉｏｒｉｔｙ ｏｆ ｓｅａｔの略であり、着席に関する不満に対する係数である。Ｓは、乗客がバスに乗っている間に吸われたか否かを示す不満変数である。着席優先が指定されると、係数Ｐｓの値が大きくなる。Ｐａは、Ｐｒｉｏｒｉｔｙ ｏｆ ａｔｍｏｓｐｈｅｒｅの略であり、騒音に関する不満に対する係数である。Ａは、バス内の騒音レベルを示す不満変数である。静寂優先が指定されると係数Ｐａの値が大きくなる。Ｐｌは、Ｐｒｉｏｒｉｔｙ ｏｆ ｐｌａｃｅの略であり、乗車する場所に関する不満に対する係数である。Ｌは、出発場所から乗車した場所までの歩行距離を示す不満変数である。場所優先が指定されると係数Ｐｌの値が大きくなる。

以下、時間、混雑、着席、騒音、および場所の不満度係数の更に具体的な例について説明する。なお、不満および不満度係数の項目である混雑は、優先付けにおける間隙に対応する。つまり、間隙優先は混雑が低いことを優先させることである。同様に、不満および不満度係数の項目である騒音は優先付けにおける静寂に対応する。

時間、混雑、着席、騒音、および場所の各項目の不満度係数は、初期状態では、全て０．１となる。そして、図１２の画面例８－０５０２にチェックを入れ、優先する項目として指定されると、指定された項目の不満度係数に０．１が加算される。乗客が当該項目を優先するということは、その項目に関する不満は他の項目に関する不満よりも大きく感じることを考慮し、当該項目が乗客の感じた不満の数値に強く反映されるようにしている。ただし、不満度係数の上限は１．０とする。

なお、図１２の画面例８－０５０２において優先する項目のチェックボックスは、いずれか1つだけしかチェックが入れられないものとしてもよいし、複数にチェックが入れられるものとしてもよい。

そして、図１２の画面例８－０５０２から何れの項目に対するチェックも行われない期間が３０日間継続したら、全ての項目の不満度係数が０．１に初期化される。いずれかの項目にチェックがされてから３０日間が経過する前にいずれかの項目にチェックがされた場合には全ての項目の不満度係数は初期化されない。
なお、ここに示した３０日という期間は例示であり、これに限定されることはない。不満度係数の初期化の処理に用いる期間は任意に設定できるものとする。

続いて、時間、混雑、着席、騒音、および場所の各項目の不満変数の具体例について説明する。

上述のように、不満Ｄｉｓは、直近の過去３０日間の不満度係数と不満変数の積の合計値である。不満変数Ｔ、Ｉ、Ｓ、Ａ、Ｌは乗客がバスを利用するごとに取得される。

不満変数Ｔは、単位が時間である。時間に関する不満は、一例として、乗客が乗車する停留所へのバスの到着が遅れたことにより乗客が待たされた時間で示されるが、ここでは具体例として、その時間に、更に、乗客が乗車したバスが乗客が降車する停留所へ到着するのが遅れた時間と、乗客がバス利用を要求を発行してからその要求に対する応答として乗客が乗車可能なバスの候補が提示されるまでの応答時間とを加えた合計時間を用いるものとする。

不満変数Ｉは、乗車率であり、パーセントを正規化した単位を用いる。乗車率が１００％であるとき不満変数Ｉを０とし、乗車率が１５０％であるとき不満変数Ｉを１とする。乗車率が１００％未満であるときの不満変数Ｉを０とする。乗車率が１５０％以上であるときの不満変数Ｉを１とする。乗車率が１００％から１５０％の間は、不満変数Ｉは乗車率の変化に対して一定の度合いで変化する線形の値であるとする。

不満変数Ｓは、着席できたか否かを示す値であり、着席できたら値は０とし、着席できなかったら値は１とする。

不満変数Ａは、バス内の騒音レベルである。例えば、バス車内に音量計測センサを設置し、その計測値を正規化して不満変数Ａとしてもよい。あるいは、バス車内は騒音レベルがどの程度高くなる状況であるかを数値で表し、その数値を正規化して不満変数Ａとしてもよい。例えば、対象の乗客が乗車したバスの同乗者における１０才代の乗客の人数を用いてもよい。１０才代の同乗者が５人であるとき不満変数Ａを０とし、１０才代の同乗者が１０人であるとき不満変数Ａを１とし、１０才代の同乗者が５人から１０人の間であれば、人数の変化に対して一定の度合いで変化する線形の値であるとする。そして、１０才代の同乗者が５人未満であれば不満変数Ａは０とし、１０才代の同乗者が１０人以上であれば不満変数を１とする。

不満変数Ｌは、付近ピックアップ要求が採用されたか否かを示す値であり、付近ピックアップ要求が採用されたのであれば不満変数Ｌは０とし、ある場所を指定した付近ピックアップ要求が採用されず基本経路上の停留所での乗車が指示されたのであれば不満変数Ｌは１とする。付近ピックアップ要求で指定した場所と、基本路線上の停留所との間にある場所での乗車が指示されたのであれば、不満変数Ｌは、乗車が指示された場所と付近ピックアップ要求で指定した場所との距離と、乗車が指示された場所と基本路線上の停留所との距離との割合に応じて０と１の間の値とする。
次に、本実施形態における「ポイント」について説明する。

本実施形態のポイントは以下に示す式（２）および式（３）により算出することができる。式（２）は、需要マネジメント型交通サービスシステムの運営者（バス会社）がバスの乗客にポイントを付与するときの計算式であり、式（３）は、バス会社がポイントを回収するときの計算式である。
Ｐｏｉｎｔ＋＝Ｄｉｓ （降車時） …（２）
Ｐｏｉｎｔ－＝Σ（バスの乗客のＤｉｓの予測値） （ルート確定時） …（３）

リクエストを発行した乗客のポイントは、そのリクエストに基づいてバスの運行経路が確定した時点で、式（３）に示されているようにバス会社により回収される。また、リクエストによりバスの運行経路が変更され、他の乗客に不満が生じる場合にその乗客に付与されるポイントは、式（２）により算出される。

ポイントは０以上の数値を取り、また上述した不満とは異なり所定期間の経過により焼失することはない。

以上説明した「不満」と「ポイント」についてまとめると以下のようなことが言える。
＜１＞不満とポイントは同量とならない。
＜２＞ポイントは不満を参照として生成されるが、基本的に両者は独立した値である。
＜３＞不満は、短期間に繰替えさせることで増大するが、時間とともに減失していく。

ここで図１３の説明に戻る。

運行計画サーバ１１は、出発場所から基本経路上の停留所までの間で付近ピックアップが可能となる条件を満たすバスおよび乗車場所を抽出し、リクエストの発行した乗客の乗車するバスの候補を選出する（１１－９１６）。

運行計画サーバ１１は、ステップ１１－９１５あるいはステップ１１－９１６において、リクエストを発行した乗客が乗車するバスの候補を選出する。このとき、運行計画サーバ１１は、乗車を希望しリクエストを発行した乗客が所持しているポイントと、その時点で、リクエストに基づいてバスの運行を変更した場合に生じることが予測されるバスの乗客の全員の不満（Σ（バスの乗客のＤｉｓの予測値））とを比較する。リクエストを発行した乗客が所持しているポイントの方がバスの乗客の全員の予測易される不満よりも大きければ、リクエストに基づくバスの運行の変更が可能と判断され、リクエストを発行した乗客による選択を経て実行が決定される。バスの運行の変更が決定されると、リクエストを発行した乗客からポイントが回収される。この場合も、バスの運行が変更されたか否かとは関係なく、バスの乗客における不満は計算され、上述した方法で乗客にポイントが付与される。

逆に、乗客全員の予測される不満の合計値が、リクエストを発行した乗客の所持しているポイントよりも大きい場合、リクエストに基づくバスの運行の変更は実現されず、リクエストを発行した乗客からポイントは回収されない。ただし、この場合も、バスに乗車している乗客の不満は、バスの運行が変更されなかったこととは関係なく計算され、必要に応じて乗客にポイントが付与される。

なお、運行計画サーバ１１は、リクエストを発行した乗客が乗車するバスおよび乗車場所の候補を選出するとき、過去のリクエストの発行および消化の履歴に基づいてこれから発生が予想されるリクエストを、乱数を用いて疑似的に発生させ、予想されるリクエストを、候補の選出の際に考慮することにしてもよい。

また、運行計画サーバ１１は、乗車を希望しリクエストを発行した乗客が所持しているポイントと、予測されるバスの乗客の全員の不満との比較だけでなく、リクエストに基づいてバスの運行を変更した場合に生じる追加コストが所定の閾値以下となるように候補を選出することにしてもよい。運行計画サーバ１１は、ポイントおよび不満による条件、あるいは更に追加コストによる条件が満たされるのであれば、複数の候補を選出してもよい。

リクエストを発行した乗客の乗客情報端末１５は、運行計画サーバ１１で選出された候補を表示し、乗客に選択を促す（１５－９１２）。乗車を希望しリクエストを発行した乗客が、例えば、乗客情報端末１５に表示された候補の中からいずれか１つを選択すると、乗客情報端末１５は選択された候補を示す情報を運行計画サーバ１１に通知する（１５－９１３）。

運行計画サーバ１１は、乗客情報端末１５から通知された候補のバスと乗車場所とに基づいてバスの運行を変更し、それに伴ってバスの運行ダイヤを更新する（１１－９１７）。そして、運行計画サーバ１１は、新たなダイヤをバス運行管理サーバ１３およびバス運行指示端末１４に通知する。バス運行管理サーバ１３は、運行計画サーバ１１から通知された新しいダイヤをデータベースに記録する（１３－９１３）。また、バス運行指示端末１４は、運行計画サーバ１１から通知された新しいダイヤを表示する（１４－９１１）。

図１４は、需要マネジメント型交通サービスシステムが乗客からアンケートへの回答を取得する処理のシーケンス図である。需要マネジメント型交通サービスシステムは乗客の降車時にアンケートへの回答を取得する。

各バスのバス運行指示端末１４は、当該バスが運行し停留場所に停車すると、その停留場所に停車した旨をバス運行管理サーバ１３と運行計画サーバ１１に報告する（１４－１０１１）。停留場所は、予め定められた停留所であっても良いし、乗客からのリクエストにより停車することになった停留所あるいは停留所でない場所であってもよい。
バス運行管理サーバ１３は、停車の報告を受信すると、当該報告を走行ログテーブル１３－４５に付随する情報として記録してもよい（１３－１０１１）。

運行計画サーバ１１は、停車の報告を受信すると、当該報告に基づき停車するバスと停留場所とを確認し（１１－１０１１）、リクエスト発行情報１２－４２から、当該バスから当該停留場所で降車する乗客を抽出する（１１－１０１２）。更に、運行計画サーバ１１は、抽出した乗客の乗客情報端末１５にアンケートを送信する（１１－１０１３）。

乗客情報端末１５は、アンケートを受信して画面に表示する（１５－１０１１）。本実施形態におけるアンケートは図１２の画面例８－０５０３のように表示される。本実施形態では、バスの利用に満足したか否かを問う単純なアンケートが用いられている。乗客は、アンケートへの回答として満足または不満と回答するかあるいは無回答とすることができる。乗客情報端末１５は、アンケートに対して乗客が入力した回答を示すアンケート情報を乗客情報管理サーバ１２に送信する（１５－１０１２）。

乗客情報管理サーバ１２は、アンケート情報を受信すると（１２－１０１１）、そのアンケート情報に基づいて、当該乗客の不満の値とポイントとを更新する（１２－１０１２）。回答が不満であったら、乗客情報管理サーバ１２は、上述した式（１）により不満の値を算出し、上述した式（２）により、その不満の値をポイントに加算する。そして、乗客情報管理サーバ１２は、その更新結果を住民パラメータテーブル１２－４１に反映させる（１２－１０１３）。

バスが終着停留所に到着すると、当該バスのバス運行指示端末１４は、終着停留所に停車した旨をバス運行管理サーバ１３と運行計画サーバ１１に報告する（１４－１０１２）。ここでは終着停留所は乗客が降車する停留所ではないものとする。

バス運行管理サーバ１３は、停車の報告を受信すると、当該報告に基づいて走行ログテーブル１３－４５を更新する（１３－１０１１）。運行計画サーバ１１は、停車の報告を受信すると、当該報告に基づき停車するバスと停留場所とを確認する（１１－１０１４）。

本実施形態による運行計画サーバ１１は、住民の不満を様々な条件で集計し、表示することができる。一例として、運行計画サーバ１１は、エリア毎に、時間、混雑、着席、および騒音の項目毎にエリア毎の不満の合計値を算出し、グラフにして表示する。これにより、バス会社は、乗客を含む住民がどのようなことに不満を持っているかを容易に知ることができ、バスの運行やサービスの改善に役立てることができる。

運行計画サーバ１１は、例えば、以下に示す式（４）により、エリア別満足度平均を算出するとともに、各項目の不満の合計値あるいは不満の一人当たりの平均値をも算出する。

式（４）において、Ａはエリアである。Ｐは不満度係数である。Ｖは不満変数である。Ｚは不満の項目であり、時間、混雑、着席、騒音、場所の各項目を含む。ｕはエリアに属する住民である。全住民数はエリアの住民の総数である。

また、運行計画サーバ１１は、変形例として、バスの乗客の不満を降車時に取得するだけでなく、更に、バスの乗客の停留所での待ち時間に関する不満を乗車時に取得し、住民からバスの乗車の有無に関わらず不満を適時に取得してもよい。そして、運行計画サーバ１１は、バス待ち客の不満、バスの乗車の有無に関わらない住民の不満、バスの乗客の不満をグラフにして表示してもよい。

図１５は、不満を集計した結果を表示したＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）の画面例を示す図である。図１５には複数のグラフ１１－１１０１、１１－１１０２、１１－１１０３を含む画面例１１－１１０が示されている。図１５のグラフ１１－１１０１、１１０２、１１０３は、中央部分を中心から上下左右に４つの領域に区切り、それぞれを時間、騒音、着席、混雑という項目が割り当てられている。各項目の領域には、中心付近が扇形に欠けた扇形の領域が、その半径により不満の度合いを示すように描かれる。

グラフ１１－１１０２には、あるエリアに関わる（バスの乗車の有無の両方を含む）住民の各項目の不満の合計値が示されている。グラフ１１－１１０１には、バスを利用した乗客のバス待ち時の各項目の不満の合計値が示されている。グラフ１１－１１０３には、バスを利用した乗客の各項目の不満の合計値が示されている。ここでは不満の合計値をグラフ化する例を示したが、不満の一人当たりの平均値をグラフ化してもよい。

また、本実施形態の運行計画サーバ１１は、全体サービスエリアに含まれる各エリアにおけるバスを利用した乗客の不満をエリア毎に表示することができる。

図１６は、各エリアの不満を集計した結果をエリア毎に表示したＧＵＩの画面例を示す図である。ここでは図１０に示した全体サービスエリアには、図１６に示すように９つのエリアがあるものとする。

図１６には、全体サービスエリアの地図上に各エリアを区分けする境界線が引かれ、各エリアの領域の濃淡により不満の度合いを示す画面例が示されている。ここでは濃淡が濃いほど不満が高いことを意味している。

なお、乗客の不満がどのエリアにおける不満かを決める方法として、例えば、そのエリア内で乗車した乗客の不満はそのエリアにおける不満とすることにしてもよい。あるいは、そのエリア内で降車した乗客の不満はそのエリアにおける不満とすることにしてもよい。

また、図１６では、全体サービスエリアに９つのエリアが属する例を示しているが、全体サービスエリアに属するエリア数に上限はない。

また、図１６では、全体サービスエリアに属する各エリアの形状が矩形である例を示しているが、エリアの形状は特に限定されることはない。エリアが矩形や正六角形など等しい形状であっても良いし、エリア毎に異なる形状であってもよい。

また、本実施形態による需要マネジメント型交通サービスシステムは、住民から収集した不満の情報に基づいて、新たなバスの運行計画を立案することができる。

図１７は、バス運行計画を立案する処理を示すシーケンス図である。本処理はバスを運行する営業時間が終了した後にバッチ処理として実施してもよい。

乗客情報管理サーバ１２は、各エリアの各項目の不満を算出する（１２－１３１１）。このとき、乗客情報管理サーバ１２は、図４に示したリクエスト消化ログ１２－４３から乗客のバスへの乗車の情報から、各エリアと乗客とを対応付け、各エリアに対応する乗客の不満をそのエリアにおける不満とする。乗客が乗車した場所があるエリア内であれば、その乗客が降車時に取得された不満はそのエリアにおける不満として扱う。

そして、乗客情報管理サーバ１２は、住民パラメータ１２－４１を参照して住民の不満の値（不満度）と不満度係数とを取得し、エリア毎の乗客の不満の値の総和を算出する。更に、乗客情報管理サーバ１２は、エリアについて算出した不満の値の総和を、そのエリアの全住民数で除算することで、そのエリアに関わった乗客の不満の値の総和の平均値を算出する。

なお、ここでは、乗客がバスへ乗車した場所の属するエリアをその乗客の不満を集計するエリアとするものとしているが、これに限定されることはない。他の例として、乗客がバスを降車した場所の属するエリアをその乗客の不満を集計するエリアとしてもよい。また、乗客の住所の属するエリアをその乗客の不満を集計するエリアとしてもよい。

また、ここでは、住民から収集した不満の値を基にバスの運行計画を立案することにしているが、必ずしも不満の値を基にしなくてもよい。他の例として、不満の値の代わりにポイントを用い、住民の所持しているポイントを基にバスの運行計画を立案することにしてもよい。

再び図１７を参照すると、乗客情報管理サーバ１２は、各エリアの不満の性質を分析する（１２－１３１２）。具体的には、乗客情報管理サーバ１２は、各エリアにおける、時間、混雑、着席、騒音、および場所という各項目（不満の種類）の不満をそれぞれ算出し、エリアの住民の数および属性と関連付ける。各エリアの各項目の不満と各エリアの住民の数および属性との関連付けの手法は特に限定されないが、例えば重回帰分析あるいはベイズ推定法などを利用して相関を算出することにしても良い。

次に、乗客情報管理サーバ１２は、各エリア間における不満の性質を分析する（１２－１３１３）。具体的には、乗客情報管理サーバ１２は、２つのエリアの不満の相関を算出する。図１６に示した全体サービスエリアおよびエリアの例では、９つのエリアがあるので、エリアの組合せは３６個となり、その３６個の組合せのそれぞれについてエリア間の相関を算出する。
不満に強い相関のある２つのエリアには共通する不満の要素があると推定される。

次に、乗客情報管理サーバ１２は、エリア間の不満の相関に基づいて、新規に設けるバス路線の案を作成する（１２－１３１４）。具体的には、乗客情報管理サーバ１２は、相関の強いエリアの間の乗客のバスの利用のうち、その相関を強くしているバスの利用を特定する。更に、乗客情報管理サーバ１２は、その相関を強くしているバスの利用における乗車時刻および乗車場所と降車時刻および降車場所を抽出する。更に、乗客情報管理サーバ１２は、その乗車時刻および降車時刻を含む時間帯における、その乗車場所から降車場所へのバスの不足あるいは欠如が不満要因であると推定し、その時間帯にその経路を運行するバス路線を新規に設けることを提案する。例えば、１５：００～１６：００の時間帯における、あるエリアからショッピングモールへのバスが不満要因と推定されたのであれば、乗客情報管理サーバ１２は、そのエリアの代表地点からショッピングモールまで運行する直通バスを新路線として提案すればよい。
乗客情報管理サーバ１２は、提案する新路線の情報をバス運行管理サーバ１３に通知する。

バス運行管理サーバ１３は、提案された新路線の運行に要するコストを算出する（１３－１３１１）。例えば新路線におけるバスの走行距離からコストを算出してもよい。

更に、バス運行管理サーバ１３は、算出したコストを基に、新路線の採用の可否を判断する（１３－１３１２）。例えば、コストが所定の閾値以下であれば採用可能と判断することにしてもよい。

新路線が採用できないものであれば、バス運行管理サーバ１３は、その旨を乗客情報管理サーバ１２に通知し、乗客情報管理サーバ１２は、その通知を受けて処理を終了する（１２－１３１５）。

一方、新路線が採用できるものであれば、バス運行管理サーバ１３は、その旨を乗客情報管理サーバ１２に通知するとともに、新路線を含むバスの運行ダイヤを作成する。新路線が採用できる旨の通知を受けた乗客情報管理サーバ１２は、住民へ新路線の導入を告知する情報を作成し、乗客情報端末１５に送信する（１２－１３１６）。告知の情報を受信した乗客情報端末１５は、その情報に基づいて、新路線の導入を告知する広告を表示する（１５－１３１１）。

また、バス運行管理サーバ１３は、作成した運行ダイヤと共に、新路線の運行計画をバス運行指示端末１４に通知する（１３－１３１３）。通知を受けたバス運行指示端末１４は、運行計画を受理し（１４－１３１１）、新たな運行ダイヤによるバスの運行の指示を開始する。

上記の実施形態の一部又は全部は以下のような事項を含んでいる。ただし、本実施形態の開示が以下の事項に限定されるものではない。

移動リソース（バス）を運行して利用者（住民、乗客）を移動させるサービスを提供する移動サービスシステムは、利用者に関する第１データベース（住民データベース）を記憶し、利用者の要求を管理する第１管理装置（乗客情報管理サーバ）と、移動リソースに関する第２データベース（バスデータベース）を記憶し、移動リソースの運行の状態を管理する第２管理装置（バス運行管理サーバ）と、第１管理装置および第２管理装置と連携して、移動リソースの運行を変更する第３管理装置（運行計画サーバ）と、を有する。第３管理装置は、利用者に発生する不満を数値で取得し、第１管理装置は、不満に応じて、移動リソースの運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを第１データベースに記録し、第３管理装置は、利用者から要求を受けて、第１データベースに管理されているその利用者に付与されているポイントと引き換えに、要求と第２データベースに管理されている移動リソースの運行の状態とに基づき、移動リソースの運行の計画を変更する。

これによれば、利用者の不満の度合いを定量化し、その不満に応じて利用者にポイントを付与し、ポイントで移動リソースの運用の変更の要求を実現させるので、各利用者の不満の度合いを移動リソースの運用に反映させることができる。その結果、複数の利用者の不満をバランスさせ、利用者全体の満足の度合いを向上させるように移動リソースを運用することが可能となる。

また、第３管理装置は、移動リソースの運行の計画を変更したとすると、移動リソースの他の利用者に発生する不満を推定し、他の利用者の不満と、要求を発した利用者のポイントとに基づいて、移動リソースの運行の計画の変更が可能であるか否か判定する。これによれば、利用者が不満に応じて付与されたポイントを利用して移動リソースの運行を変更するとき、その利用者が所持しているポイントと、その変更により他の利用者が抱くであろう不満と、に基づいて、その要求を実施できるか否か判定するので、利用者間の不満をバランスさせることができる。

また、第３管理装置は、移動リソースの運行を計画を変更すると、要求を発した利用者のポイントから、他の利用者の不満に相当する分を減算する。これによれば、利用者の要求で移動リソースの運行を計画を変更すると、その要求を発した利用者のポイントから、他の利用者の不満の度合いに相当する分を減算するので、利用者の不満をバランスさせながら、利用者の要求に応じた移動リソースの運行を調整することができる。

また、第３管理装置は、不満の対象となる複数のサービス品質項目について、利用者による重視の度合いを係数とし、サービス品質項目についての事象の計測値を変数とし、サービス品質項目毎の係数と変数の積を複数のサービス品質項目について合計し、合計値を利用者の不満の値とする。これによれば、複数のサービス品質項目に分けて重視の度合いを考慮して利用者の不満の値を算出するので、サービスを多面的に捉えて利用者の項目毎の不満を的確に移動リソースの運用に反映させることが可能となる。

また、第３管理装置は、利用者からの要求にてサービス品質項目に対する嗜好の情報を取得して係数を更新する。これによれば、利用者が行った要求にて利用者のサービス品質項目に関する嗜好を取得するので、利用者による重視の度合いを反映させるために、利用者が別途嗜好を入力する手間を低減することができる。

また、第３管理装置は、利用者が移動リソースにより移動したときに利用者から不満の有無を知得し、不満が有りであれば、事象の計測値に基づいて第１管理装置に利用者の不満の値を更新させる。これによれば、利用者が移動したときに不満の発生を取得するので、利用者にて生じた不満を的確に把握し、不満の度合いとして算出することができる。

また、第３管理装置は、他の利用者の不満と、要求を発した利用者のポイントとに基づき、移動リソースの運行の計画の可能な変更を抽出し、要求を発した利用者に提示し、利用者の選択した変更を実施する。これによれば、複数の変更の案を利用者に提示し、選択された変更を実施するので、利用者は要求を満たす中で、より好ましいを変更の仕方を選択することができ、利用者の利便性がより向上する。

また、第３管理装置は、サービスが提供されるサービスエリアを区分けした複数のエリアのそれぞれについて不満の値を集計し、集計結果を表示する。これによれば、エリア毎に不満を集計し表示するので、エリア毎の不満の様子を視認し、移動リソースが適切に提供されているかどうか確認することができる。

また、第１管理装置は、集計結果に基づいて、エリアにおける不満の原因を解析し、原因を低減するように、エリアにおける移動リソースの運行の計画を提案する。これによれば、エリア毎の不満の集計結果に基づき不満の原因を解析し、原因を低減するような計画を提案するので、エリア毎の利用者の不満の状況に応じた移動リソースの運行計画の見直しが可能とある。

また、サービス品質項目には、移動リソースへ登場する場所、移動リソースを利用するために要する時間、移動リソース内の混雑、移動リソースにおける着席可否、または移動リソース内の騒音の少くとも１つが含まれる。これによれば、移動手段の利用に際して感じる不満を、移動リソースへ登場する場所、移動リソースを利用するために要する時間、移動リソース内の混雑、移動リソースにおける着席可否、または移動リソース内の騒音といったパラメータで計測するので、利用者の不満を適切に不満の値に反映させることができる。

また、第１管理装置は、第１データベースにて、利用者毎の不満の値を管理し、所定時間継続して新たな不満が発生しなかった利用者の不満の値を所定の初期値にする。これによれば、行動心理学における不満の継続性に適合した演算により、利用者の感じている不満を適切に数値で表現することができる。

１１…運行計画サーバ、１２…乗客情報管理サーバ、１３…バス運行管理サーバ、１４…バス運行指示端末、１５…乗客情報端末、１－０１…ＣＰＵ、１－０２…メモリ、１－０３…通信ＮＩＣ、１－０４…ハードディスクドライブ、１－０５…入出力コントローラ、１－０６…モニタコントローラ、１－０７…バス、１－０８…ＧＰＳモジュール、１－１１…キーボード、１－１２…マウス、１－１３…ディスプレイ、１－１４…ＩＣカードリーダーモジュール、１－１５…タッチパネル、１１－４０…集計データベース、１１－４１…集計結果テーブル、１１－４２…エリア別集計結果テーブル、１１－４３…エリア定義テーブル、１１－４４…ＧＩＳ節点情報テーブル、１１－４５…ＧＩＳ節点情報、１２－４０…住民データベース、１２－４１…住民パラメータテーブル、１２－４２…リクエスト発行情報テーブル、１２－４３…リクエスト消化ログテーブル、１３－４０…バスデータベース、１３－４１…バス車体パラメータテーブル、１３－４２…バス折返し発車予定時刻テーブル、１３－４３…バス基本経路の移動順序－停留所対応表テーブル、１３－４４…基本経路上の停留所テーブル、１３－４５…バス走行ログテーブル

Claims (11)

1. 移動リソースを運行して利用者を移動させるサービスを提供する移動サービスシステムであって、
   前記利用者に関する情報を記憶する第１データベースを備え、前記利用者の情報を管理する第１管理装置と、
   前記移動リソースに関する情報を記憶する第２データベースを備え、前記移動リソースの運行の状態を管理する第２管理装置と、
   前記第１管理装置および前記第２管理装置と連携して、前記移動リソースの運行を変更する第３管理装置と、を有し、
   前記第３管理装置は、前記利用者に発生する前記移動リソースの運行あるいは利用に対する不満を数値で取得し、
   前記第１管理装置は、前記不満に応じて、前記移動リソースの運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを前記第１データベースに記録し、
   前記第３管理装置は、前記利用者から前記移動リソースの利用の要求を受けて、前記第１データベースに管理されている該利用者に付与されているポイントと引き換えに、前記要求と前記第２データベースに管理されている前記移動リソースの運行の状態とに基づき、前記移動リソースの運行の計画を変更するものであり、
   前記第３管理装置は、前記移動リソースの運行の計画を変更したとすると、前記移動リソースの他の利用者に発生する不満を前記他の利用者が乗る場所および／または降りる場所への前記移動リソースの到着の遅れ時間に基づいて推定し、前記他の利用者の不満と、前記要求を発した利用者のポイントとに基づいて、前記移動リソースの運行の計画の変更が可能であるか否か判定する、
   移動サービスシステム。
2. 前記第３管理装置は、前記移動リソースの運行を計画を変更すると、前記要求を発した利用者のポイントから、前記他の利用者の不満に相当する分を減算する、
   請求項１に記載の移動サービスシステム。
3. 前記第３管理装置は、前記不満の対象となる複数のサービス品質項目について、前記利用者による重視の度合いを係数とし、前記サービス品質項目についての事象の計測値を変数とし、前記サービス品質項目毎の前記係数と前記変数の積を前記複数のサービス品質項目について合計し、合計値を前記利用者の前記不満の値とする、
   請求項１に記載の移動サービスシステム。
4. 前記第３管理装置は、前記利用者からの前記要求にて前記サービス品質項目に対する嗜好の情報を取得して前記係数を更新する、
   請求項３に記載の移動サービスシステム。
5. 前記第３管理装置は、前記利用者が前記移動リソースにより移動したときに前記利用者から不満の有無を知得し、前記不満が有りであれば、前記事象の計測値に基づいて前記第１管理装置に前記利用者の前記不満の値を更新させる、
   請求項４に記載の移動サービスシステム。
6. 前記第３管理装置は、前記他の利用者の不満と、前記要求を発した利用者のポイントとに基づき、前記移動リソースの運行の計画の可能な変更を抽出し、前記要求を発した利用者に提示し、前記利用者の選択した変更を実施する、
   請求項１に記載の移動サービスシステム。
7. 前記第３管理装置は、前記サービスが提供されるサービスエリアを区分けした複数のエリアのそれぞれについて前記不満の値を集計し、集計結果を表示する、
   請求項１に記載の移動サービスシステム。
8. 前記第３管理装置は、前記不満の対象となる複数のサービス品質項目のそれぞれにおける前記複数のエリアのそれぞれについての不満の値を集計して集計結果を算出し、
   前記第１管理装置は、前記集計結果に基づいて、前記エリアにおける前記不満の原因がどのサービス品質項目に関するものかを解析し、前記原因を低減するように、前記エリアにおける前記移動リソースの運行の計画を提案する、
   請求項７に記載の移動サービスシステム。
9. 前記サービス品質項目には、前記移動リソースへ登場する場所、前記移動リソースを利用するために要する時間、前記移動リソース内の混雑、前記移動リソースにおける着席可否、または移動リソース内の騒音の少くとも１つが含まれる、
   請求項３に記載の移動サービスシステム。
10. 前記第１管理装置は、前記第１データベースにて、利用者毎の不満の値を管理し、所定時間継続して新たな不満が発生しなかった利用者の不満の値を所定の初期値にする、請求項１に記載の移動サービスシステム。
11. 移動リソースを運行して利用者を移動させるサービスを提供するための移動サービス提供方法であって、
    前記利用者に関する情報を記憶する第１データベースを備え、前記利用者の情報を管理する第１管理装置と、前記移動リソースに関する情報を記憶する第２データベースを備え、前記移動リソースの運行の状態を管理する第２管理装置と、前記第１管理装置および前記第２管理装置と連携して、前記移動リソースの運行を変更する第３管理装置と、を有するシステムにおいて、
    前記第３管理装置が、前記利用者に発生する前記移動リソースの運行あるいは利用に対する不満を数値で取得し、
    前記第１管理装置が、前記不満に応じて、前記移動リソースの運用に対する要求を実施させるために利用可能なポイントを付与し、利用者毎のポイントを前記第１データベースに記録し、
    前記第３管理装置が、前記利用者から前記移動リソースの利用の要求を受けて、前記第１データベースに管理されている該利用者に付与されているポイントと引き換えに、前記要求と前記第２データベースに管理されている前記移動リソースの運行の状態とに基づき、前記移動リソースの運行の計画を変更するものであり、
    前記第３管理装置は、前記移動リソースの運行の計画を変更したとすると、前記移動リソースの他の利用者に発生する不満を前記他の利用者が乗る場所および／または降りる場所への前記移動リソースの到着の遅れ時間に基づいて推定し、前記他の利用者の不満と、前記要求を発した利用者のポイントとに基づいて、前記移動リソースの運行の計画の変更が可能であるか否か判定する、
    移動サービス提供方法。

Images