JP2003141219A - サービススケジューリング方法及びプログラム - Google Patents

Abstract

(57)【要約】 【課題】客からの利用要求や変更希望に対し迅速かつ柔
軟に応えることのできるサービススケジューリング方法
及びプログラムを提供すること。 【解決手段】利用可能なリソースに関するリソース情
報、既に受け付けた利用要求、及び該利用要求に対応す
る第１のスケジュールを記憶する。第１のスケジュール
は該当する客に通知し、その通知内容を表す通知情報を
記憶しておく。また制約情報も記憶しておく。新規な利
用要求を客から受け付けたとき、記憶している通知情報
及び制約情報に基づいて第２のスケジュールを作成す
る。この第２のスケジュールの作成結果から新規な利用
要求の受付可否を決定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、資源割当て型サー
ビスにおける利用要求受付け、資源運用スケジューリン
グ、およびスケジュール通知を行うサービススケジュー
リング方法及びプログラムに関する。

【０００２】

【従来の技術】公共交通業や物流業等（以下、単に「業
者」という）が提供するサービスは、典型的な資源割当
て型のサービスである。複数の客がサービスの利用に係
る要求を発すると、かかる利用要求は業者側に受け付け
られる。利用要求を受け付けた業者は、利用要求に応じ
て必要な資源を割り当てて運用することで、サービスを
提供する。

【０００３】業者は、乗務員や車両等、自己が保有する
資源もしくは利用可能な資源を効率よく運用するために
運用スケジュールを作成する。しかし、これら資源には
限りがあるので、客からの利用要求を無制限に受付ける
ことはできない。従って、業者は、各利用要求に対しサ
ービスを提供することが可能か否かの判断を行い、受付
け可否の回答やスケジュール内容の通知を行う必要があ
る。利用要求に対する受付け可否の判断においては、当
該利用要求と、業者が保有する資源もしくは利用可能な
資源、資源の運用効率、既に受付け済みの他の利用要
求、既に作成済み又は通知済みのスケジュール内容など
を勘案する必要がある。従来、この種の作業は人手によ
り行われてきた。

【０００４】また、客側の都合により生じる利用要求の
変更、新規な利用要求へのサービス提供に伴う資源の再
割当て、資源保有状況の変化、などによって通知済みの
スケジュールを更新する場合がある。この場合、スケジ
ュールを通知済みの客からの利用要求の内容、当該利用
要求の受付時に通知した内容等を勘案してスケジュール
更新を行う必要があるとともに、更新後のスケジュール
を客に再通知する必要があるか否かの判断が必要であ
る。これらの作業についても従来、人手により行われて
きた。

【０００５】スケジューリングした資源の運用に伴う以
上のような作業は、多大な労力を要し、とりわけ、多数
の客を対象とし大規模な資源を複雑に運用するような場
合には、人手では対応しきれなくなることも想定され
る。

【０００６】

【発明が解決しようとする課題】本発明は、資源の運用
をスケジューリングするにあたり、客からの利用要求や
変更希望に対し迅速かつ柔軟に応えることのできるサー
ビススケジューリング方法及びプログラムを提供するこ
とを目的とする。

【０００７】

【課題を解決するための手段】本発明に係るサービスス
ケジューリング方法は、サービスの利用要求に応えるリ
ソースの運用スケジュールを作成するサービススケジュ
ーリング方法において、新規の利用要求を受け付けるス
テップと、利用可能なリソースに関するリソース情報を
参照するステップと、既に受け付けた利用要求を受けて
作成された運用スケジュールに関するスケジュール情報
及び該スケジュールに関する制約情報を参照するステッ
プと、前記リソース情報、前記スケジュール情報、及び
前記制約情報に基づいて前記新規の利用要求を受けた仮
スケジュールを作成するステップと、前記仮スケジュー
ルの作成結果から前記新規な利用要求の受付可否を決定
するステップとを具備することを特徴とする。

【０００８】

【発明の実施の形態】以下、図面を参照しながら本発明
の実施形態を説明する。

【０００９】図１は、本発明の一実施形態に係るサービ
ススケジューリングシステムの概念的な構成を示すブロ
ック図である。同図に示すようにサービススケジューリ
ングシステム１はネットワーク（例えばインターネッ
ト）に接続されており、同ネットワークを介して利用者
端末２０が接続されている。利用者端末２０は、サービ
ス提供を希望する客が保持する電話機やファクシミリ
（ＦＡＸ）、携帯電話機、パーソナルコンピュータ（Ｐ
Ｃ）等からなる。サービススケジューリングシステム１
は、利用要求受付け部２、客情報保持部４、リソース情
報保持部６、スケジュール作成部（スケジューラ）８、
応答制御部１２、および通知部１０を備えて成る。

【００１０】利用要求受付け部２は、利用者端末２０か
ら例えばインターネット経由で送られてきたサービス利
用要求を受付けるＷＷＷサーバー装置、あるいは、公衆
電話網を経由して電話機あるいはファクシミリ等により
受付けた利用要求を記録する任意の情報処理装置等から
成る。客情報保持部４は、オペレータが直接入力した利
用要求情報や、利用要求受付け部２から送られてくる利
用要求情報を、その要求内容に従って適宜に処理して保
持する部分であり、大容量の磁気ディスク装置や半導体
メモリなど各種の記憶装置を備える。リソース情報保持
部６は、車両や乗務員に関する情報や、道路ネットワー
クに関する情報など、サービス提供業者が保有するリソ
ース（資源）に関する情報を保持する。スケジュール作
成部８は、後述する応答制御部１２から駆動され、客情
報保持部４に保持される客情報とリソース情報保持部６
に保持されるリソース情報とを元に、運用側にて設定さ
れる各種制約条件の下にリソースを最適に運用するスケ
ジュールを作成する。

【００１１】応答制御部１２は、利用要求受付け部２に
おいて受け付けられた利用要求の内容について、客情報
やリソース情報を元に各種判断処理を実行するものであ
り、その具体的な処理の内容については後に詳しく説明
する。応答制御部１２にはスケジュール作成部８および
通知部１０が接続される。本実施形態では、スケジュー
ル作成部８は、応答制御部１２から駆動され、客対応時
に仮のスケジュール作成や再スケジュールの作成も行え
るよう構成される。また、通知部１０は応答制御部１２
における処理の結果について、利用者端末２０に対して
通知することが必要な情報を同応答制御部１２からの指
示によりネットワークを経由して通知する。なお、利用
者端末２０からの利用要求とは別に、リソースに生じた
変更等をスケジュールに反映させるための変更処理等も
行うよう構成されている。

【００１２】次に、本発明に係るサービススケジューリ
ングシステムを具体的なサービス業務に適用した実施形
態について説明する。図２は資源割当て型のサービスの
一種である乗合車両運行サービスに適用したサービスス
ケジューリングシステムの構成を示すブロック図であ
る。図２に示される各構成要素について、図１と同様の
ものには同一の参照数字が付してある。以下、図１に示
した基礎的なシステムとの構成上の相違点について説明
する。

【００１３】利用要求受付け部２は、乗合車両運行サー
ビスの利用に係る要求を利用者端末２０から受け付け
る。この要求の内容についての情報は客情報保持部４に
送られる。客情報保持部４は、利用要求受付け部２が受
け付けた各利用要求を保持し、さらに乗合車両運行スケ
ジュール情報として、乗車・降車時刻、乗車・降車地
点、配車車両ＩＤなどの情報を保持する。また、各利用
要求に関する制約情報を含む場合がある。顧客データベ
ース３は、顧客の氏名、電話番号や住所、過去に本サー
ビスを利用した時の迎え先・送り先、およびその地点へ
の道順など、各客のサービス利用実績情報等を保持す
る。

【００１４】運用情報保持部５は、本乗合車両運行サー
ビスに使用される車両の定員、積載可能荷物量、所属車
両基地、所属会社、利用可能日、利用可能時間帯、利用
不可能時間帯などの車両情報や乗務員勤務状況などの運
用情報及びこれら運用情報に関する制約情報を保持す
る。また、各車両もしくは各乗務員に対し、割り当てら
れた利用要求や、巡回経路、巡回時刻などを含む乗合車
両運行スケジュール情報を保持する。

【００１５】通知内容・制約情報保持部７は、客への通
知内容および通知内容に関する制約を保持する。保持さ
れる通知内容としては、受付け可否、乗降車時刻、割り
当て車両情報などがあり、通知内容に関する制約情報と
しては通知乗降車時刻からのずれの許容範囲、通知した
割当車両からの変更可否などが含まれる。制約情報に
は、上記した各利用要求に関する制約情報および運用情
報に関する制約情報に基づいて、客に通知すべき内容が
設定される。なお、所定の情報を制約情報として予め設
定しておいてもよい。

【００１６】道路ネットワーク情報取得部９は、道路ネ
ットワーク内の地点の位置や名前などの地点情報、２地
点間距離や移動所用時間を取得する部分である。また、
道路ネットワーク情報取得部９は交通状況の変化に応じ
て更新される情報を随時に取得する。これら運用情報保
持部５、通知内容・制約情報保持部７、および道路ネッ
トワーク情報取得部９は、図１に示したリソース情報保
持部６に相当する。

【００１７】乗合車両運行自動スケジューラ１１は、客
情報保持部４および運用情報保持部５に保持された情
報、および本サービス提供地域に関する道路ネットワー
ク情報から乗合車両の運行スケジュールを作成する。こ
れは、図１に示したスケジュール作成部８に相当する。

【００１８】応答制御部１２は、利用要求受付け部２が
受け付けた利用要求について、客情報保持部４、運用情
報保持部５、通知内容・制約情報保持部７、および道路
ネットワーク情報取得部９により保持、取得された各種
情報から、当該利用要求をなした客（利用者端末２０）
への応答制御を行う部分である。乗合車両運行自動スケ
ジューラ１１は、応答制御部１２から駆動され、客対応
時に仮のスケジュール作成や再スケジュールの作成が行
えるよう構成される。また、乗合車両運行スケジュール
出力部１３は、応答制御部１２における処理の結果につ
いて、利用者端末２０に対して通知することが必要な情
報を同応答制御部１２からの指示によりネットワークを
経由して通知する。乗合車両運行スケジュール出力部１
３にディスプレイやプリンタ等の出力機器を接続し、乗
合車両運行自動スケジューラ１１によって作成されたス
ケジュールを指定された表示形態によって出力するよう
にしてもよい。また、乗合車両運行スケジュール出力部
１３は、利用者端末２０や車両搭載端末に適切な情報を
送信するための通信装置を含む。この乗合車両運行スケ
ジュール出力部１３は、図１に示した通知部１０に相当
する。

【００１９】乗合車両運行スケジュール変更部１４は、
客からの利用要求の変更、車両情報や乗務員情報などの
運用情報の変化、道路交通状況の変化などにより、乗合
車両運行スケジュールへの変更要請が生じた場合、かか
る変更要請に従って、応答制御部１２を介して乗合車両
運行自動スケジューラ１１を駆動し、当該乗合車両運行
スケジュールの変更を実行する。また手動による乗合車
両運行スケジュールの変更操作の支援を行う。

【００２０】以下、乗合車両運行サービスの一形態とし
て、空港向け乗合車両運行サービスを例にあげて説明す
る。このサービスは、ある市内を営業地域とし、多数の
顧客がそれぞれ指定した営業地域内の乗降車地点を複数
台の乗合車両で巡回し、乗合により空港・各顧客指定乗
降車地点間のＤｏｏｒ−ｔｏ−Ｄｏｏｒ（ドアツード
ア）送迎を行うサービスである。

【００２１】各客は利用要求の申込みに際し、市内から
空港への送迎利用の場合には市内の自宅や駅、ホテルな
どを迎え場所として指定する。また、空港到着希望時刻
や利用人数、荷物数などを指定する。一方、空港から市
内への送迎利用の場合は、市内送り先、空港出発希望時
刻、利用人数、荷物数などを指定する。空港到着・出発
希望時刻は、利用する航空便の発着時刻をもとに運用側
で自動的に指定するようにしても良い。各客は、希望す
る利用日の例えば２日前までに利用要求の申込みを行う
こととする。

【００２２】図３に利用要求の申込みの例を示す。本サ
ービスの利用を希望する客は、パーソナルコンピュータ
や携帯電話機などの利用者端末２０を用い、例えば運用
側が提供する利用要求受付サーバ２にネットワークを介
してアクセスする。客が利用要求申込みを希望し、本サ
ービスのＷｅｂページにアクセスすると、利用者端末２
０のディスプレイに図３のような利用要求の申込みのフ
ォーム３０が表示される。客は氏名、住所、連絡先とい
った客個人情報、送迎先や利用人数、希望利用日時など
サービス利用に関する情報を記入もしくは選択する。ま
た図３の例では「オプション」ボタン３１を押すと、図
４のような、オプション設定フォーム４０が表示され
る。

【００２３】オプション設定フォーム４０では、上記以
外の項目、例えば車両の貸し切り希望や希望乗車時刻か
らのずれについて特別な設定をすることができる。運用
側はこれらの項目にデフォルト値を設定しておき、客が
それとは異なる設定をオプションとして設定すると料金
が加算もしくは減算されるように構成してもよい。図４
の例では、運用側が設定するデフォルト値は例えば、
「スケジュール通知期限」４１は１日前まで、「空港到
着希望時刻からのずれ」４２は３０分前まで、「車両貸
し切り希望」４３はしない、といった設定である。この
設定のままなら料金の加算あるいは減算は発生しない。
なお、図４の例では、客がオプション設定フォームの
「車両貸し切り」チェック欄にチェックを付与してお
り、車両の貸し切りを希望したため、料金が１０００円
加算されている。客は必要な項目を設定し終わると「設
定して戻る」ボタン４４を押し、図３のフォームに戻
る。なお、上記オプションの設定を、利用要求の申込み
と同一のフォームで行うように構成してもよい。客は設
定した利用要求を申し込む際には「ＯＫ」ボタン３２を
押す。利用要求を設定したが、申し込みは行わない場合
は「キャンセル」ボタン３３を押す。

【００２４】なお、利用要求が電話機やファクシミリか
ら音声等によってなされた場合、オペレータが記入もし
くは設定し申し込みの代行処理を行うことになる。当該
客の個人情報は、一度本サービスを利用すると、顧客デ
ータベース３に顧客情報として登録される。この登録さ
れた顧客情報は顧客ＩＤやパスワード、電話番号、氏名
などを検索キーとして顧客データベース３から呼び出し
可能になる。これにより次回以降の利用要求申込み時に
は、顧客情報を最初から入力する作業が不要になる。

【００２５】利用要求の申込みが行われると、利用要求
がなされた端末２０においては、図５に示すように運用
側から利用要求が受付けられた旨の通知フォーム５０が
表示される。この通知フォーム５０には、利用要求内容
と、その内容から算出された料金、発行された予約番号
等が表示されている。客が表示された内容に満足し、
「ＯＫ」ボタン５１を押すと、正式に利用要求が受付け
られる。一方、「キャンセル」ボタン５２を押すと、利
用要求は取り消される。なお、かかる通知に代えて利用
要求受付けの正式な完了とし、利用要求が受付けられた
旨のみ表示するよう構成してもよい。通知フォーム５０
において表示される料金については、利用要求の内容、
利用要求の申込みの行われた日時、サービス利用日時、
スケジュール通知日時などを引数とし、事前に設定した
関数等により算出される。

【００２６】ある客が新規に利用要求を申し込んだと
き、既に受付済みの他の利用要求や、利用日に本サービ
スのために使用可能な車両台数などの状況によっては、
当該客からの要求に応える配車が不可能な場合がある。
そこで本実施形態のサービススケジューリングシステム
では、後述する利用要求受付手順に従い、利用要求の申
込みがなされた時、その利用要求を受付可能か否かを自
動的に判定し、利用要求が受付けられたか否かを通知す
る。

【００２７】利用要求を受付けた際には図５に示したよ
うな通知を行うが、利用要求が受付けられない場合は図
６のようにその旨を通知する。図６の例では、利用要求
の内容に加え、利用要求が受付けられなかった理由６０
も合わせて表示される。客が利用要求の内容を変更し
て、再度利用要求の申込みを行う場合は「再申込み」ボ
タン６１を押して図３の利用要求申込みフォームに戻る
ことができる。

【００２８】利用要求の受付処理に関し他の実施形態で
は、利用要求がそのままの内容では受付けられないが、
少なくとも一つ以上の項目を変更すればその変更した内
容で受付可能となる場合、変更案を提示する。この変更
案を利用者が受け入れて利用要求の申込みを再度行うか
否かを問い合わせるようにする。なお、受付可能な変更
案が複数ある場合は、可能な限りそれを全て客に提示
し、いずれかの変更案を選択して利用者が申込みを行え
るように構成することが好ましい。

【００２９】運用側は、各利用日の一定時間前に当該利
用日についての利用要求の受付けを締め切る。上述した
利用要求は利用日の一定時間前までの任意の時刻に発生
し得る。図７に示す例では、締め切りは各利用日の二日
前で、それまでに受付けられた利用要求は利用日毎に分
類され保持される（要求Ａ；利用日Ａの利用要求、要求
Ｂ；利用日Ｂの利用要求）。各利用日における締め切り
Ａ，Ｂの後、当該利用日についての利用要求に対し、そ
れらの要求にできるだけ沿い、かつ運用効率が高くなる
よう乗合車両運行スケジュールＳＡ，ＳＢが作成され
る。各々のスケジュールの内容に沿って各客に必要事項
が通知され、利用日を迎え、実際の運行が行われる。図
８に示す例では、客に対して利用日、送迎地点、送迎時
刻などが通知フォーム８０により通知されている。ま
た、各乗務員に対しては、図示しないが、各員に割り当
てられた客の送迎先の巡回順や巡回時刻、乗降人数など
必要事項が通知される。なお、利用要求受付時に、上述
した受付可否の判定を行わず、スケジューリング時に配
車可不可の判定を行い、スケジュール通知時などに合わ
せて受付け可否の通知を行う構成としてもよい。

【００３０】（利用要求受付手順の具体例）上述したよ
うに、応答制御部１２は利用要求受付け部２が受け付け
た利用要求について、客情報保持部４、運用情報保持部
５、通知内容・制約保持部７、および道路ネットワーク
情報取得部９により保持、取得された各種情報から、当
該利用要求をなした客（利用者端末２０）への応答制御
を行う部分である。利用要求の受付時において、応答制
御部１２は利用要求に指定された利用日時について、こ
れらの情報から新規利用要求を受付け可能か否かを判定
する。具体的には、乗合車両運行サービスにおける新規
利用受付けに際し、例えば次に説明する利用要求受付手
順Ａ又は同受付手順Ｂのいずれかを適用する。

【００３１】［利用要求受付手順Ａ（手順１〜手順
２）］ （手順１）客から新規の利用要求を随時に受付ける。 （手順２）客からの新規利用要求と、既に受付けた利用
要求の中で新規利用要求と同一の乗合車両運行スケジュ
ールに割り当てられる利用要求とを対象に、仮のスケジ
ューリングを実行する。これらすべての利用要求に対す
る客制約と、運用側の制約を満たすスケジュールが存在
すれば、当該客に利用要求が受付けられた旨を通知す
る。存在しなければ利用要求が受付けられなかった旨を
通知して手順１へ戻る。

【００３２】なお、手順２における「乗合車両運行スケ
ジュール」とは、運用側のスケジュール管理単位によっ
て識別される複数台の乗合車両の運行内容に関する情報
である。例えば、本実施形態に係る空港向け乗合車両サ
ービスでは利用日毎にスケジュールを管理しており、利
用日毎に、使用される全車両について一つの乗合車両運
行スケジュールが存在するものとなっている。

【００３３】これにより手順２においては、利用日が同
じである利用要求を同一の乗合車両運行スケジュールに
割り当てる。なお、運用側のスケジュール管理単位を利
用日と目的地の組とする場合は、利用日と目的地とが同
じ利用要求を同一の乗合車両運行スケジュールに割り当
てるようにする。スケジュール管理単位としてはこの他
にも考えられ、利用日と出発地の組、又は時間帯毎、週
毎、月毎、及びこれらと目的地・出発地の組、業務内容
や運行地域、車種などとの組などである。

【００３４】このような利用要求受付け手順Ａの具体的
な実行例を図９に示す。この例では、まず（利用）要求
１が発生する。この要求１の要求内容は客情報保持部４
に保持される。客情報保持部４の内容に基づいた仮スケ
ジューリングの結果、配車可能と判定され、さらに受付
けられ、その旨が当該客に通知される。その後、新規に
要求２が発生している。この要求２の要求内容は客情報
保持部４に追加され、受付け済みの要求１と新規の要求
２を含めた客情報保持部４の内容に基づく仮スケジュー
リングが実行される。この例では、仮スケジューリング
の結果、車両台数の不足といった運用側の事情や要求１
の利用要求の内容との兼ね合いにより配車不可能と判定
され、当該要求２は受付けられない。この場合、要求２
を客情報保持部４から削除しても良い。その後、要求３
が発生する。この要求３の内容についても客情報保持部
４に追加され、同様に仮スケジューリングが行われる。
ここでは、例えば要求１と全く異なる時間帯での利用要
求であったなどの理由で要求２は配車可能と判定されて
いる。これにより要求３は受付けられ、その旨が通知さ
れる。次に説明する利用要求受付手順Ｂでは、仮スケジ
ューリングの結果が配車不能であった場合に、利用要求
の内容を変更する案を当該客に提示する。

【００３５】［利用要求受付手順Ｂ（手順１〜手順
３）］ （手順１）客から新規な利用要求を随時に受付ける。 （手順２）当該客からの新規利用要求と、既に受付けた
利用要求の中で客からの新規利用要求と同一の乗合車両
運行スケジュールに割り当て可能な利用要求とを対象と
し、仮のスケジューリングを実行する。これらすべての
利用要求に対する客制約と運用側の制約を満たすスケジ
ュールが存在すれば、当該客に利用要求が受付けられた
旨を通知して手順１に戻る。

【００３６】（手順３）当該客についての客制約、もし
くは利用日時、利用人数、荷物数、客グループ指定、乗
合指定、車種、座席、料金などの要求内容を変更し、こ
れまでに受付けた利用要求と合わせて、再度、仮スケジ
ューリングを実行する。これら全ての利用要求に対する
客制約と運用側の制約とを満たすスケジュールが存在す
れば、かかる変更内容を当該客に提示し、その内容であ
れば利用要求を受付けることが可能な旨を通知する。当
該客が提示された変更内容を承認すれば、この変更内容
で当該客からの利用要求を受付ける。変更内容に当該客
が承認しない場合は、利用要求は受付けられない旨を通
知して手順１に戻る。なお、制約を満たすスケジュール
が存在しない場合についても利用要求が受付けられない
旨を通知して手順１に戻る。

【００３７】このような利用要求受付け手順Ｂの具体的
な実行例を図１０に示す。図９の例と同様に、まず要求
１が仮スケジューリングを経て受付けられる。その後に
要求２が発生し、その内容が客情報保持部４に追加され
る。この客情報保持部４の保持内容に基づいた仮スケジ
ューリングの結果、要求２に対しては配車不可能と判定
される。この時、要求２の利用要求内容に対し、例え
ば、利用人数を減らす、荷物数を減らす、目的地希望到
着時刻の変更、あるいは特別料金で特別車両の配車を指
定する、などといった幾つかの利用要求変更案が提示さ
れる。要求２を行った客は、これらの変更案の中からい
ずれか一つを受け入れるか、変更案を受け入れずに利用
要求を取り消すことができる。変更案を受け入れた場合
は、その変更の内容で利用要求が受付けられた旨が当該
客に通知される。

【００３８】［スケジュール通知・客回答処理手順例］
応答制御部１２は、通知したスケジュール内容に対して
客が承認／否認の回答を行うにあたり以下の処理を実行
する。

【００３９】（手順１）随時、客から新規に利用要求を
受付け、その新規利用要求を未処理利用要求として客情
報保持部４に登録する。

【００４０】（手順２）未処理利用要求に対し、スケジ
ューリング可能であればスケジューリングを行い、スケ
ジューリング結果を出力する。スケジューリング不可能
であれば、当該客に対し待機指示を通知して手順１に戻
る。

【００４１】（手順３）スケジューリング結果に基づ
き、当該客に必要事項の通知を行う。通知事項は、受付
け可・不可のみの場合や、乗降車時刻、配車車両ＩＤな
どを含む場合もある。

【００４２】（手順４）スケジューリング結果は当該客
に通知済であるとみなし、通知内容・制約保持部７に通
知内容を記録する。また通知内容・制約保持部７には今
後のスケジュール更新において発生し得る、通知内容か
らのずれの許容範囲や、配車車種や車両ＩＤの変更制限
など通知内容からの変更制限といった制約が記録され
る。また乗合車両運行自動スケジューラ１１はスケジュ
ーリング可能状態に設定される。

【００４３】（手順５）当該客からのスケジュール承認
／否認の回答を受付ける。回答内容が承認の場合通知内
容は正式に通知済みとなる。回答内容が否認であれば、
客情報保持部４から当該客の利用要求が削除され、また
通知内容・制約保持部７から当該利用要求に関する制約
が削除される。

【００４４】なお、手順３において、受付け可・不可の
みの場合は、上述した利用要求受付け手順と同様の処理
手順となる。

【００４５】各新規利用要求に対し、スケジュール内容
通知時刻からの回答期限を設けてもよい。この場合、回
答期限内に当該客が回答を行わなかった場合は、当該客
は通知内容を否認したと見なし、客情報保持部４、通知
内容・制約保持部７の内容の更新を行う。回答期限は一
定時間とする場合の他、当該利用要求に割り当てられた
乗車時刻の一定日時間前としたり、料金に応じた時間と
する場合などである。

【００４６】ある利用要求に対するスケジュール通知終
了後や、スケジューリング実行中に他の新規利用要求が
発生する場合や、ある客にスケジューリング結果を通知
してから、当該客がその通知内容に対し承認か否認の回
答を行うまでの間に、他の新規利用要求が発生する場合
が起こり得る。

【００４７】上記処理手順によれば、一度客に通知した
スケジューリング結果が、その後に発生する他の利用要
求に対するスケジューリングによって変更を強いられる
場合であっても、その変更の範囲が限定されるように制
約を設けることができる。以下、上記処理手順例を適用
したより具体的な処理例を説明する。

【００４８】（スケジュール通知・客回答終了後の新規
利用要求処理例）ここでは、ある利用要求に対し、スケ
ジューリングを行い、当該客に結果を通知し、客が通知
内容に対し承認もしくは否認の回答を行った後に、別の
新規利用要求が発生した場合の、処理例について述べ
る。

【００４９】図１１は、客の利用要求発生から受付けか
ら、スケジューリング、回答処理に至るまでに本実施形
態のシステムが実行する一連の処理を時間経過（一列
目）に沿って例示したものである。

【００５０】まず、時刻ｔ１に客Ａが利用要求を発生す
ると、上記手順１に従って、応答制御部１２がこれを受
付け、未処理利用要求として客情報保持部４に登録する
（時刻ｔ２）。この時点でスケジューラ１１はスケジュ
ーリング可能状態である。この例では時刻ｔ４に未処理
利用要求のチェックが行われる。この未処理利用要求の
チェック以前に他の新規利用要求が発生した場合は、上
述した客Ａの場合と同様に処理され、客情報保持部４に
追加登録される。

【００５１】時刻ｔ４において少なくとも客Ａの利用要
求が未処理であるから、上記手順２に従って応答制御部
１２は時刻ｔ５にスケジューラ１１を駆動する。スケジ
ューラ１１は全未処理利用要求を対象としてスケジュー
リングを行い、時刻ｔ７にスケジューリング結果を応答
制御部１２に出力している。続いて上記手順３に従って
結果を処理し、客Ａの利用要求を処理済とする。続いて
時刻ｔ８に客Ａに対して必要事項の通知を行う。通知内
容は受付け可・不可のみの場合や、乗降車時刻や配車車
両などを含む場合がある。続く時刻ｔ９に上記手順４に
従って客Ａへの通知内容および通知内容に関する制約が
通知内容・制約保持部７に追加記録される。この例で
は、時刻ｔ８での通知内容は「受付け可・不可，乗車地
点，乗車時刻，降車地点，降車時刻」であるとする。ま
た通知内容に関する制約は「通知した乗車時刻からのず
れ：±５分以内、通知した降車時刻からのずれ±１０分
以内」とする。この場合、時刻ｔ９での通知内容・制約
保持部７への記録内容は図１２に示すものとなる。図
中、通知内容の「車両」は「―」となっているが、これ
は「配車車両ＩＤは客Ａに未通知（あるいは非通知）で
ある」ことを示す。この後の新規な客受付けなどによ
り、客Ａの乗車時刻は更新される可能性があるが、図
中、制約の「乗車時刻ずれ：±５分」は、乗車時刻の更
新が生じてもその更新結果が、「通知した乗車時刻「１
０：３０分」から±５分以内になるようにする」という
制約を示す。「降車時刻ずれ：±１０分」についても同
様である。

【００５２】図１２の通知内容の項目および制約の項目
は運用に従って変化し、例えば通知内容として「乗車時
間」を含む場合などもあり得、ここに示したものに限ら
ない。また通知内容・制約保持部７の記録内容は、各客
が通知内容に対し否認の回答を行った場合と、その客へ
のサービスが終了した場合に削除され、否認回答前の客
やサービス終了前の客についての記録内容は保持されて
いる。

【００５３】以上の通知内容・制約の記録が完了し、応
答制御部１２は続く時刻ｔ１０にスケジューラ１１をス
ケジューリング可能状態に設定する。この設定は、時刻
ｔ７のスケジューリング結果出力の直後に、スケジュー
ラ１１自身が行ってもよい。

【００５４】続いて時刻ｔ１２に客Ａは時刻ｔ８の通知
内容に対し「承認／否認」の回答を行う。ここでの回答
内容が「承認」であれば、客Ａへの配車は正式に決定さ
れ、応答制御部１２は手順５に従って客Ａに対し配車完
了処理を行い、客情報保持部４における客Ａからの利用
要求を配車済みとする。客Ａの利用者端末２０において
は配車が完了した旨の通知が表示される。「否認」であ
れば、応答制御部１２は通知内容・制約保持部７の客Ａ
に対する通知内容・制約を削除する。また客情報保持部
４の客Ａについての利用要求内容も削除する。客Ａの利
用者端末２０においては配車を行わずサービスを提供し
ない旨の表示がなされる。

【００５５】時刻ｔ１７に客Ｂが新規に利用要求を発生
している。この利用要求を含む未処理の利用要求は、客
Ａの場合と同様に、手順１〜５に従って処理される。手
順２のスケジューリングにおいては、図１２に示したと
おり、時刻ｔ９に記録した客Ａについての通知内容・制
約を含む、通知内容・制約保持部７に保持されている全
客の記録内容が考慮され、記録されている制約を満たす
ようにスケジューリングが行われる。従って、時刻ｔ９
での客Ａへの通知内容からの変更が生じたとしても、そ
の変更は、記録された制約を満たす範囲内に納まること
が保証される。この例では、時刻ｔ２３で出力されるス
ケジューリング結果における客Ａの乗車時刻は１０：２
５〜１０：３５の間にあり、降車時刻は１０：５０〜１
１：１０までの間にある。

【００５６】応答制御部１２は、時刻ｔ２４にスケジュ
ーリング結果を客Ｂに通知し、時刻ｔ２５に客Ｂへの通
知内容および制約の記録を行っている。これにより、通
知内容・制約保持部７の記録内容は図１３に示すものと
なる。以降、別の新規利用要求が発生した場合、客Ｂへ
の通知内容および制約も考慮されることになる。客Ｂは
時刻ｔ２８に回答を行っている。この回答に対し応答制
御部１２は客Ａの場合と同様の処理を行う。

【００５７】なお、以上の各時点で実行されるスケジュ
ーリングにおいては、通知内容・制約保持部７の記録内
容のみならず、受付け済みの利用要求および新規利用要
求の客制約や運用制約も守られる。また通知内容・制約
保持部７への時刻や通知済み／未通知の記録方法や識別
記号は上記の例に限定されない。このことは以下に挙げ
る例においても同様である。

【００５８】（スケジュール通知後・客回答前の他新規
利用要求処理例）図１１の例では、客Ａが通知内容に対
し回答を行った後に別の新規利用要求が発生する場合の
処理に関して説明したが、ここでは客Ａが回答する前に
別の新規利用要求が発生する場合の処理について述べ
る。

【００５９】図１４に示すように、客Ａが時刻ｔ１に利
用要求を発生し、これに対し応答制御部１２は図１１の
場合と同様の処理を行う。すなわち時刻ｔ７にスケジュ
ーリング結果を応答制御部１２に出力して、時刻ｔ８に
客Ａに必要事項の通知を行い、時刻ｔ９に通知内容およ
び制約の記録を行っている。ここでは、この通知内容に
対し客Ａが承認もしくは否認の回答を行う前の時刻ｔ１
１に、客Ｂから別の新規利用要求が発生している。これ
に対し本実施形態のシステムでは客Ａの場合と同様に、
手順１〜５に従って処理を行う。

【００６０】時刻ｔ１４に開始するスケジューリングに
おいて、客Ａは通知内容に対してまだ未回答であるが、
この例では、通知内容・制約保持部７の内容は図１２の
上図に示したものであるとし、記録されている制約を満
たすようにスケジューリングが行われる。

【００６１】その後、スケジューリングが終了し、時刻
ｔ１８に客Ｂへの通知を行っている。さらに客Ａの回答
と客Ｂの回答を受付け、それぞれ上記手順５に従って回
答処理を行っている。ここで、客Ａと客Ｂの回答の順序
は問わない。またこの例では、客Ａの回答が、図１４に
示すとおり客Ｂに対するスケジューリング終了後の時刻
ｔ２２に発生しているが、図１５に示すように、客Ｂに
対するスケジューリング中に発生する場合（図１５では
時刻ｔ１７に発生）も、その回答内容にかかわらず、客
Ｂに対するスケジューリングにおいて参照される通知内
容・制約保持部７の内容は時刻ｔ９に記録されたものと
する。したがって、客Ｂに通知されるスケジューリング
結果は図１４の処理の場合と同じものとなる。

【００６２】また、客Ａの回答内容が否認であった場
合、応答制御部１２がスケジューラ１１にスケジューリ
ング停止指示を発し、これにより客Ｂへのスケジューリ
ングを停止し、通知内容・制約保持部７において客Ａに
ついての記録を削除し、客Ｂへのスケジューリングを再
実行しても良い。この場合、客Ａへの通知内容は客Ｂに
対するスケジューリング結果に影響しない。なお、スケ
ジューリング中に複数客が回答する場合も、それぞれ上
述した客Ａの場合と同様に受付け、通知内容・制約保持
部７の更新を行う。

【００６３】（スケジューリング中の新規利用要求受付
け処理例）以上では、ある利用要求に対するスケジュー
リング終了後に別の新規利用要求が発生する場合の処理
例について述べたが、ここでは、ある利用要求に対する
スケジューリング実行中に新規利用要求が発生した場合
の処理例について、図１６に沿って説明する。

【００６４】まず、時刻ｔ１に客Ａが利用要求を発生し
ている。これに対し図１１に示した処理例と同様に、利
用要求を受付け、時刻ｔ５にスケジューリングを開始し
ている。時刻ｔ１１にスケジューリングが終了し、時刻
ｔ１２に客Ａに対して通知を行い、時刻ｔ１３に上記手
順４に従って客Ａへの通知内容および通知内容に関する
制約を通知内容・制約保持部７に追加記録している。

【００６５】この例では、スケジューリング開始（時刻
ｔ５）から終了（時刻ｔ１１）の間に、時刻ｔ７に他の
客Ｂが利用要求を発生している。この時点ではスケジュ
ーラ１１が動作中であるため、客Ｂのために仮スケジュ
ーリングを含むスケジューリングは行われない。そのた
め応答制御部１２は、まず利用要求を受付けた上で客Ｂ
に待機指示を出している。客Ｂの利用要求は未処理の利
用要求として客情報保持部４に登録される。この間、客
Ｂ以外に複数客が利用要求を発生した場合は、客Ｂの場
合と同様の処理を行い、その利用要求を未処理の利用要
求として客情報保持部４に追加登録する。

【００６６】時刻ｔ１１にスケジューリングが終了し、
上記手順３に従って結果が処理され、時刻ｔ１２に客Ａ
に必要事項の通知がなされている。通知内容は受付け可
・不可のみの場合や、乗降車時刻や配車車両などを含む
場合もある。続く時刻ｔ１３に上記手順４に従って客Ａ
への通知内容および通知内容に関する制約が通知内容・
制約保持部７に追加記録される。通知内容・制約の記録
が完了し、応答制御部１２は続く時刻ｔ１４にスケジュ
ーラ１１をスケジューリング可能状態に設定する。

【００６７】さらに、応答制御部１２は時刻ｔ１６に未
処理利用要求のチェックを行う。この時点で時刻ｔ９に
待機指示を出していた客Ｂの利用要求が未処理であるか
ら、上記手順２〜４を実行する。手順２においてはその
時点で未処理の全利用要求が一括してスケジューリング
対象となる。

【００６８】この時点で客Ａは通知されたスケジュール
に対し未回答であるが、時刻ｔ１７に開始する客Ｂに対
するスケジューリングにおいては、時刻ｔ１３に記録し
た客Ａについての通知内容・制約を含む、通知内容・制
約保持部７に保持されている全客の記録内容が考慮され
る。

【００６９】さらに、時刻ｔ２６に客Ａは時刻ｔ１２の
通知内容に対し「承認／否認」の回答を行う。さらに時
刻ｔ３１に客Ｂは時刻ｔ２１の通知内容に対し「承認／
否認」の回答を行い、客Ａの場合と同様の処理が実行さ
れる。この場合も客Ａと客Ｂの回答の順序は問わない。
また客Ａの回答が客Ｂに対するスケジューリング中に発
生した場合も図１５に示した例と同様の処理を行う。

【００７０】この例では、スケジューリング中に発生し
た新規利用要求に対しては待機指示を出しているが、応
答制御部１２がスケジューラ１１に停止指示を発し、新
規利用要求を追加してスケジューリングを再実行するよ
うにしても良い。また新規利用要求がスケジューリング
により作成中のスケジュールに全く無関係の利用要求で
あり、他のスケジュールに関するものである場合には、
待機指示を出さずにこれを受付け、実行中のスケジュー
リングとは別にスケジューリングを実行しても良い。

【００７１】（スケジュール分割通知を含む新規利用要
求処理例）以上の例では、スケジューリング結果の通知
内容は乗降車時刻を含んでおり、通知回数も一回であっ
たが、以下では各客への通知を複数回に分割して行う場
合の上記処理手順の適用例について述べる。

【００７２】図１７に示す例では、まず時刻ｔ１に客Ａ
が利用要求を発生し、上記処理手順１〜５に従って応答
制御部１２はこれを受付け、スケジューリングを実行
し、客Ａに結果を通知し、回答を受付けている。ここ
で、時刻ｔ５のスケジューリングは仮スケジューリング
とし、時刻ｔ８のスケジューリング結果の通知内容は利
用要求の受付け可・不可のみであるとする。「受付け
可」とは利用要求に対する客制約を満たし、指定した乗
降車地点を送迎する車両が配車可能であることを意味す
る。

【００７３】本例では、客Ａへの通知内容は「受付け
可」であるとする。この場合の時刻ｔ９における通知内
容・制約保持部７への客Ａについての記録内容を図１８
に示す。時刻ｔ８での通知では、乗降車時刻の通知は行
っていないので、通知内容の「乗車時刻」および「降車
時刻」の欄は未通知を示す「―」が記入されており、制
約の「乗車時刻ずれ」および「降車時刻ずれ」の欄も未
設定を示す「―」が記入されている。なお通知内容が
「受付け不可」の場合は通知内容の「受付け」欄に受付
け不可を示す「×」が記入されることとし、客がこれを
承認すれば通知内容・制約保持部７の客Ａについての記
録は削除され、客情報保持部４の客Ａの利用要求も削除
される。否認する場合は、客Ａは利用要求内容を変更し
て再度、利用要求を申し込むことになる。スケジューリ
ング結果が「不可」となった場合、即座に通知内容・制
約保持部７の客Ａについての記録と客情報保持部４の客
Ａの利用要求を削除する構成としてもよい。客Ａが否認
した場合は、利用要求内容を変更し、これを新規利用要
求として受付ける。

【００７４】続いて、時刻ｔ１３に客Ｂによる新規利用
要求が発生している。客Ｂの利用要求は乗降車地点およ
び希望乗降車時刻に加え「車椅子乗車可能車両」という
車種指定も含まれている。

【００７５】ここで、客Ｂに対するスケジューリングも
仮スケジューリングとする。この仮スケジューリングに
おいては、客Ａへの乗降車時刻の通知内容に関する制約
は無い。ただし、客Ａの利用要求は既に受付け済みであ
るから、客Ａの利用要求に対する客制約は守られる。

【００７６】時刻ｔ２０に客Ｂに対し受付け可・不可の
通知を行う。ここでは客Ｂへの通知内容は「受付け可」
であるとする。この場合の時刻ｔ２１での通知内容・制
約保持部７の記録内容を図１９に示す。客Ｂへは「車椅
子乗車可能車両」の配車を行うことを含めて「受付け
可」と通知したので、通知内容の「車両」欄に「車椅子
可」と記入し、制約の「車両」欄にも「車椅子可」と記
入している。以後別の新規利用要求が発生した場合も客
Ｂへの車椅子乗車可能車両の配車は保証される。

【００７７】さらに、時刻ｔ２５に客Ａと客Ｂに乗車時
刻および降車時刻の通知を行い、時刻ｔ２５に通知内容
・制約保持部７に客Ａと客Ｂについての通知内容と制約
の記録を行っている。この時点での記録内容を図２０に
示す。それまで未記入であった「乗車時刻」欄と「降車
時刻」欄に通知内容が記入され、「乗車時刻ずれ」欄と
「降車時刻ずれ」欄に制約が記入されている。続いて時
刻ｔ３６に客Ｃが利用要求を出しているが、この利用要
求に対するスケジューリングにおいては図２０の制約が
守られる。

【００７８】空港向け乗合車両運行サービスのように、
実際の利用日時の一定時間前まで利用要求を受付け、締
め切り後にスケジューリングを行い各客に乗降車時刻な
どの通知を行う場合は、この分割通知の例のとおり、利
用要求受付け時には受け付け可否や割り当て車種が通知
済みとなって通知内容・制約保持部７に記録され、さら
にスケジューリング後に乗降車時刻が通知内容・制約保
持部７に記録される。

【００７９】（スケジュール通知運用の実施形態）ここ
で、上述した利用要求受付け手順例およびスケジュール
通知・客回答処理手順例を適用したより具体的な実施形
態を説明する。

【００８０】（利用要求受付け締め切り後に全客一斉に
通知）例えば、利用日の２日前や運行開始時刻の１時間
前までなど、運用側で設定した締め切りまで利用要求を
受付ける。その後、乗合車両運行自動スケジューラ１１
により当該利用日の乗合車両運行スケジュールを作成
し、各客に利用要求受付け可否、乗車時間や降車時間な
どを通知する。各利用要求受付け時に、仮スケジューリ
ングを用いた上述した利用要求受付け手順を適用し、受
付け可否を判定する処理を行ってもよい。また上述した
スケジュール通知・客回答処理手順例を適用すれば、受
付け済みの客の配車車両に関する制約なども守ることが
できる。また、締め切り前の最後の利用要求受付け時に
行った仮スケジューリング結果を実際の運行スケジュー
ルとして利用するように構成してもよい。

【００８１】スケジュール管理を利用日毎に行っている
場合の、利用要求受付けからスケジュール通知に至るま
での流れを図２１に示す。この例では、随時受付けられ
た利用要求は利用日毎に仕分けされ（要求Ａ：利用日Ａ
の利用要求、要求Ｂ：利用日Ｂの利用要求）、客情報保
持部４に追加され、各利用日の２日前に受付けが締め切
られる。締め切り後、当該利用日についてのスケジュー
リングが行われ、作成されたスケジュールに沿って、各
客に乗降車地点、乗降車時刻など必要事項が通知され、
利用日を迎える。図２１では、ＳＡが利用日Ａのスケジ
ュールであり、ＳＢが利用日Ｂのスケジュールである。

【００８２】（利用要求受付け時に通知）この通知形態
では、新規利用要求受付け毎に、乗合車両運行スケジュ
ールを作成して通知する。その際、既にスケジュール通
知済みの客がある場合は、上述したスケジュール通知・
客回答処理手順例を適用し、通知内容・制約保持部７の
記録内容を参照することにより、通知済みの客（もしく
は送迎中の客）に関する制約を守りつつ、これを更新す
る形で新規利用要求を含めた乗合車両運行スケジュール
を作成する。ここで行うスケジューリングでは、当該利
用要求の受付け可否も自動的に判定し、スケジュール通
知時に利用要求受付け可否の通知を行う。スケジューリ
ングにおいては、既にスケジュール通知済みの客の利用
要求がより優先されるよう客の重みを設定することが好
ましい。

【００８３】受付け・通知手順を図２２に示す。まず客
１による要求１を受付け、スケジューリングを行いスケ
ジュールＳを作成し、スケジュールＳ内容の内容に従っ
て、客１に乗降車時刻や乗降車地点など必要事項を通知
する。そして客１への通知内容およびそれに関する制約
を通知内容・制約保持部７に記録する。

【００８４】その後、客２により要求２がなされ、スケ
ジューリングが行われる。その際、前回作成したスケジ
ュールＳは客１に対して既に通知済みであるから、今回
のスケジューリングでは通知内容・制約保持部７の内容
に加え、客情報保持部４に保持されている要求１の要求
内容も考慮される。例えば、スケジュルＳで客１に配車
した車両にさらに客２を乗車させることが可能だが、そ
の場合、乗り合いによる迂回が生じ、客１の乗車時刻や
降車時刻が通知済みのスケジュールＳに記載の時刻から
ずれるとする。そのずれが要求１についての客制約のみ
ならず、通知内容・制約保持部７の客１への通知内容に
関する制約を満たす場合、客１と客２を乗合させるとい
うスケジュールの更新が認められる。この更新後のスケ
ジュールをＳ’とする。スケジュールＳ’の内容は客２
に通知され、また客１に関して制約は満たしていても再
通知の必要があれば、客１に対して更新後のスケジュー
ルＳ’が通知される。客２が別の車両に割り当てられた
場合など、客１に関してスケジュール変更が無い場合は
当然ながら再通知の必要はない。また客２への通知内容
および関係する制約が通知内容・制約保持部７に記録さ
れ、客１への再通知が発生した場合は再通知の内容およ
び関係する制約も記録される。

【００８５】その後さらに、客３によって要求３がなさ
れ、スケジューリングが行われる。その際、前回作成の
スケジュールＳ’を反映した通知内容・制約保持部７の
内容、客情報保持部４に保持されている受付け済みの要
求、および新規に追加された要求３に基づいてＳ’が更
新されＳ”が作成される。各客への更新・再通知回数の
上限や、各客に対する更新・再通知可能期限（乗車時刻
の１時間前まで更新・再通知可能など）を設け、通知を
行ってもよい。

【００８６】（一定時間毎に通知）この通知形態では、
一定時間に限り利用要求を受付け、その後スケジューリ
ングを行い、乗合車両運行スケジュールを通知する。ス
ケジューリングの後、再び一定時間ほど利用要求を受付
け、スケジューリングおよびこの一定時間内に利用要求
を受付けた各客へのスケジュール内容の通知を行い、各
客への通知内容を通知内容・制約保持部７に記録し、以
上の処理を運行前の所定時刻まで繰り返す。一定時間毎
に繰り返し行われるスケジューリングにおいては、通知
内容・制約保持部７の内容を参照することにより、客制
約を守るだけでなく通知済みのスケジュールの内容から
のずれが制限範囲内になるように乗合車両運行スケジュ
ールを更新する。なお、通知内容・制約保持部７の記録
内容によって、各客への初回通知内容や最近通知内容を
参照するよう構成しても良い。

【００８７】更新されるスケジュール内容が、通知済み
の客に関して、通知したスケジュール内容と異なる場合
は、これに該当する客もしくは全客に最新スケジュール
を再通知する。あるいは、通知済みスケジュールの内容
と最新スケジュールの内容との相違が一定範囲を超えた
客のみに通知するようにしても良い。図２３の例では、
まずスケジュールＳの内容に基づき、要求１、２の客に
対してそれぞれ乗降車時刻や乗降車地点を含む必要事項
が通知される。その後、スケジュールＳをＳ’に更新し
通知を行う場合、例えば、要求１についてのみ乗車時刻
がスケジュールＳにおける通知内容と５分以上のずれが
生じている一方、要求２に対しては通知内容の変化が無
いとする。この時、スケジュールＳ’に従って、要求
１、３、４の客に必要事項が通知される。

【００８８】また、一定時間毎に行われるスケジューリ
ングでは、前回スケジューリング以降に受付けた各客の
利用要求受付け可否についても自動的に判定し、スケジ
ュール通知時に受付け可否の通知を行う。あるいは、新
規利用要求受付け毎に、前回作成・通知済みのスケジュ
ールを考慮しつつ、前回スケジューリング以降に受付け
た利用要求と新規利用要求を含めて、上記利用要求受付
け手順を適用することにより、新規利用要求の受付け可
否を自動的に判定する。

【００８９】（他の処理手順例）通知に関する他の処理
手順は、例えば、受付け可否未通知利用要求数もしくは
未配車利用要求数が一定数以上になったか、一つ以上の
未配車利用要求があり、かつ前回スケジューリングから
一定時間経過した場合に再スケジューリングを行うとい
うものである。図２に示した応答制御部１２は、前回あ
るいは次回スケジューリング実行時刻や受付け可否未通
知利用要求数、未配車利用要求数などの管理、およびス
ケジューリング実行要否の判定を行い、スケジューリン
グ実行の必要が生じた場合、乗合車両自動運行スケジュ
ーラ１１に対してスケジューリング実行の指示を発する
ことができる。

【００９０】この他、客が、即答を含むスケジュール通
知時刻を指定できる構成とした場合、指定された時刻ま
でにその客に関するスケジューリングし通知し、スケジ
ュール通知時刻を指定しない客については、一定時間毎
あるいは各客の利用日時の一定時間前あるいは受付け締
め切り後にスケジューリングし通知するようにしても良
い。この場合、客に請求する料金を、利用要求の内容の
みならず、利用要求の申込み日時、利用日時、スケジュ
ール通知日時をも引数として所定の関数により算出す
る。

【００９１】［スケジュール変更例］乗合車両運行スケ
ジュールの変更の必要が生じた場合、当該乗合車両運行
スケジュールの更新を自動もしくは手動で行う。変更の
必要が生じる場合としては、客からの利用要求の変更、
車両情報や乗務員情報などの運用情報の変化、道路交通
状況の変化などがある。その際、変更操作をスケジュー
ル出力表、又は、地図・道路ネットワーク上で行う。変
更の必要が生じた乗合車両運行スケジュールが、関係す
るいずれの客にも通知済みでなく、かつ、いずれの乗務
員にも通知済みでない場合は、当該乗合車両運行スケジ
ュールを破棄し、変更に応じて客情報や運用情報を適宜
更新し、乗合車両運行スケジュールを再作成すればよ
い。あるいは、必要な部分のみ変更してもよい。

【００９２】一方、既にいずれかの客もしくは乗務員に
通知済みの乗合車両運行スケジュールに変更の必要が生
じた場合は、本システムでは、通知内容・制約保持部７
の記録内容を参照することにより通知済みの乗合車両運
行スケジュールからの差が適宜設定した制限範囲内にな
るように、当該乗合車両運行スケジュールを更新し、客
もしくは乗務員に適切にスケジュール通知を行う。

【００９３】なお、変更前のスケジュールの保存や任意
の変更状態でのスケジュールの保存や変更履歴の保存を
行っておくことが好ましい。さらに、変更履歴を辿るこ
と（遡及）が可能なように構成することが好ましい。

【００９４】既にいずれかの客もしくは乗務員に通知済
みの乗合車両運行スケジュールを様々な状況に応じて変
更する方法を以下に詳しく説明する。

【００９５】（客から利用要求の変更要請があった場
合）客から利用要求の変更要請があった場合には、その
客に関するスケジュールの変更が必要となる。客は、利
用要求の変更を行うにあたっては、予約番号や、客ＩＤ
あるいは氏名、住所等の客個人情報により利用要求を特
定して変更要請を発する。なお、変更要請は複数回行う
ことが可能なように構成してもよい。空港向け乗合車両
運行サービスについて、利用要求変更の流れを以下に説
明する。

【００９６】図２４の例では、客が本サービスのＷｅｂ
ページにアクセスし、予約番号２４０を指定し、自分の
利用要求と通知されたスケジュール内容の表示要請を行
っている。この操作により、図２５に示すように、この
客の元の利用要求とスケジュール内容（通知内容）２５
０が表示される。スケジュールが未作成もしくは未通知
の場合、スケジュール内容の欄は空白となる。この例で
は利用要求の変更をしたい場合は「利用要求を変更す
る」ボタン２５１を押し、利用要求をキャンセルする場
合は「利用要求をキャンセルする」ボタン２５２を押
し、ここままで良い場合は「ＯＫ」ボタン２５３を押
す。「利用要求を変更する」ボタン２５１を押した場合
は、図２６のように、利用要求の申込みと同様のフォー
ム２６０が表示される。

【００９７】利用要求の変更としては、利用要求のキャ
ンセル、利用日や利容人数、荷物数、希望乗降車時刻、
乗降車地点など利用要求に含まれる任意の項目に関する
変更がありえる。運用側で変更不可能な項目などを設定
してもよい。図２６の例では、例えばこの客は「利用航
空便時刻」２６１と「空港到着希望時刻」２６２を変更
している。客が必要な項目を変更し、「ＯＫ」ボタン２
６３を押すと変更要請が発せられる。

【００９８】利用要求の変更要請を受けた場合、その利
用要求に対応する乗合車両運行スケジュールを、変更要
請に沿うように自動的に更新することができる。その
際、当該乗合車両運行スケジュールに関する他の客の客
制約や運用制約などを満たすように、乗合車両運行スケ
ジュールを更新することができる。さらに当該乗合車両
運行スケジュールを既に他のいずれかの客に通知済みの
場合は、通知内容・制約保持部７の記録内容を参照する
ことによりスケジュール通知済み客への通知内容との差
が、一定範囲内になるように、乗合車両運行スケジュー
ルを更新してもよい。

【００９９】また、客が利用要求の変更要請を行った場
合、当該客に請求する変更手数料を、元の利用要求の内
容と、利用要求の変更内容と、変更要請がなされた日時
と、当該乗合車両運行スケジュールの運行日時と、当該
客の行った変更要請の回数などの関数として算出しても
よい。図２７に示す例では、変更要請を行った客に対
し、変更されたスケジュール内容に沿って必要事項が通
知されており、また変更手数料も提示されている。

【０１００】ある客から利用要求の変更要請を受付け、
乗合車両運行スケジュールの更新を行う場合、その更新
方法としては、例えば以下の３つが挙げられる。

【０１０１】（１）その客のみ車両割り当てを変更し、
他の客の車両割り当ては変更しないように再スケジュー
リングを行う。

【０１０２】（２）その客の利用日時や利用地域の付近
を運行する車両に関するスケジュールなど、当該乗合車
両運行スケジュールの一部を破棄し、破棄された部分に
関連する客を車両未割り当てとし、再スケジューリング
を行う。

【０１０３】（３）当該乗合車両運行スケジュールを全
て破棄し、再スケジューリングを行う。

【０１０４】以下、上記（１）の方法を適用した場合の
利用要求変更処理手順の一例を説明する。

【０１０５】＜キャンセル処理手順例（手順１〜手順
３）＞ （手順１）利用要求のキャンセル要請を随時受付ける。 （手順２）キャンセル要請がなされた利用要求に対応す
る乗合車両運行スケジュールの乗合車両の巡回経路か
ら、この利用要求の乗降車地点への巡回を削除し、削除
後の巡回経路、およびこの乗合車両に割り当てられてい
る他の利用要求内容に従って巡回時刻を算出し、当該乗
合車両運行スケジュールを更新する。

【０１０６】（手順３）更新された乗合車両運行スケジ
ュールについて、通知済みのスケジュールの内容と更新
後のスケジュールの内容の差が、一定範囲以上の客につ
いては更新後のスケジュールに従って再通知し確認を取
る。

【０１０７】＜利用要求内項目変更要請処理手順例（手
順１〜手順５）＞ （手順１）利用要求内項目変更要請を随時受付ける。

【０１０８】（手順２）変更内容が、利用人数や荷物数
の変更など、客の乗降車地点、乗降車時刻に関するもの
でない場合は、現スケジュールにて変更可能かどうかチ
ェックする。変更可能な場合は、スケジュールを更新
し、客に変更が完了した旨と更新後のスケジュール内容
を通知する。変更不可能な場合は手順３に移行する。

【０１０９】（手順３）現スケジュールにおいて、変更
を要請した客に割り当てられた車両の巡回経路から、こ
の客の乗降車地点への巡回を削除し、削除後の巡回経路
およびこの車両に割り当てられた他客の利用要求内容か
らこの車両の巡回時刻や乗降車人数を算出し、現スケジ
ュールを更新する。

【０１１０】（手順４）変更後の利用要求を未配車の利
用要求として客情報保持部４に登録し、この利用要求に
対し、スケジューリングを行う。その際、上記利用要求
受付け手順を用い、変更後の利用要求が割り当てられる
スケジュールが通知済みの場合はその内容を考慮し、ま
た、そのスケジュールに割り当てられている他の受付け
済み利用要求の内容を考慮し、変更後の利用要求の受付
け可否を自動的に判定する。

【０１１１】（手順５）更新後の各スケジュール内容
が、更新前の各スケジュールのいずれかの客への通知内
容と異なる場合は、該当する客に更新後スケジュール内
容を再通知する。

【０１１２】キャンセルする客の利用人数が多く、この
客に割り当てた車両の乗車率が運用側設定の下限以下に
なった場合など、他の客の車両割り当ても変更する必要
が生じた場合は、上述した方法（２）や（３）が適用さ
れる。

【０１１３】図２８に示す例では、要求１〜３が受付け
られた後、スケジュールＳが作成され、通知されてい
る。その後、要求１に対する変更要請である変更１が発
生し、受付けられ、Ｓが更新され、Ｓ’が作成され通知
されている。さらに締め切り後に要求４が発生し、受付
けられ、Ｓ’が更新されＳ’’が作成され通知されてい
る。各更新においては、通知内容・制約保持部７の記録
内容と客情報保持部４に保持されている利用要求内容が
参照されている。

【０１１４】＜表形式表示でのスケジュール変更結果表
示＞乗合車両運行スケジュールは、スケジュール出力部
１３により、ディスプレイなどに表形式や地図形式で表
示される。乗合車両運行スケジュールの表形式での出力
・表示例を図２９に示す。この例では、最初のセクショ
ンで車両ごとにまず運転手名が表示される。次のセクシ
ョンでは車両の巡回経路に関する表示がなされ、行き帰
りごとの巡回経路上の訪問地点および各地点への巡回時
刻、その地点での乗降人数が巡回順に表示される。この
他、各訪問地点における乗降客の顧客情報なども表示し
てもよい。図２９の例では車両１は行き帰りともに乗車
があり、車両２は行きのみ、車両３は帰りのみ乗車があ
る。最後のセクションでは行き帰りごとの総乗車人数と
売り上げが表示される。

【０１１５】本実施形態においては、乗合車両運行スケ
ジュール作成後もしくは通知後に、ある客から利用要求
の変更が合った場合、上述した利用要求の変更処理によ
るスケジュールの更新結果を反映し表形式で出力する。
また更新後のスケジュール内容と前回もしくは前回以前
もしくは初回のスケジュール通知内容との差が一定範囲
を超えており、スケジュール際通知の必要のある客につ
いては、表上でその客に関するセルの色を変えるなど表
示形態を変えて出力してもよい。また再通知が済み、通
知内容について承認を得た客に関するセルの表示形態を
通常の表示形式に戻す、もしくは表示色を変えるなど再
通知が完了したことが識別される表示形態で出力しても
よい。また当該スケジュールにおいて各客に行った再通
知の回数が識別できるように、各客に対する再通知回数
に応じて表示形態を変えて出力してもよい。上記の表示
形態を本システム使用者が設定可能に構成してもよい。

【０１１６】＜表形式スケジュール表示画面上でのスケ
ジュール手動変更操作例＞利用要求の変更処理を、図２
９に例示する表形式の画面上で手動にて行う場合の操作
例を図３０に示す。図３０に示される操作例では、ま
ず、利用要求の変更要請を行った客（車両１が６：００
に新宿で迎える客）に関するセルが、オペレータによる
手動操作（たとえばマウスクリック）やオペレータの入
力した客ＩＤや客氏名、予約番号などによる指定、もし
くは客による利用要求変更要請内の客ＩＤや予約番号に
よって自動的に選択されている。さらにその脇に、変更
の種類を選択するウインドウが表示されている（内容変
更、キャンセル）。ここでは変更の種類としてキャンセ
ル３００が選択されている。その結果、選択されたセル
が削除され、削除後の巡回経路と、他客の利用要求内容
に沿って、車両１の巡回時刻３０１が更新されている。
変更の種類として、利用要求の内容を変更する場合は、
変更の種類を選択するウインドウにおいて「内容変更」
３０２を選択すると、図２６のように、利用要求項目設
定ウインドウが表示され、要求内容を変更できる。その
後、変更内容に従って、再スケジューリングが行われ、
スケジュール更新結果が出力される。

【０１１７】また、図３１に示すように、表形式の表示
画面上で、各車両の巡回経路を変更し巡回時刻を更新す
る操作や客の割当車両の変更操作を行うことができる。
図３１ではまず表形式の表示画面上で、車両１の運行ス
ケジュール上の巡回地点のセル３１０が選択されてお
り、次にこれをマウス操作などで、車両１の巡回経路か
ら切り取り、次にこのセルを車両２の巡回経路中の巡回
地点との間に挿入している。この時自動的に巡回地
点に対応する降車地点も車両１の巡回経路から切り取
られ、車両２の巡回経路に挿入される。以上の操作によ
り、車両１と車両２の巡回経路が更新され、更新後の巡
回経路と各客の利用要求内容に従って、各車両の巡回時
刻が更新される。更新後、スケジュール再通知の必要が
ある客に関するセルを形態を変えて表示してもよい。

【０１１８】図３１の例では、更新後の車両２のスケジ
ュールにおいて、巡回地点への巡回時刻が更新前に比
べて１０分遅くなっており、再通知の必要があるとして
色を変えて表示している。また変更操作による更新後ス
ケジュールが、客の乗降車希望時刻からのずれなどの客
制約や、乗車定員などの運用制約に違反している場合、
あるいはいずれかの客の降車が乗車より先になっている
等の矛盾を含む場合は、違反している客に関するセルや
車両に関する列、あるいは矛盾個所などを表示色などの
形態を変えて表示してもよい。また制約に違反している
場合、遅れ時間や、乗員数など違反内容を表示してもよ
い。また矛盾を含む場合は、その内容を表示してもよ
い。またある変更操作を行う場合、その操作に従ってス
ケジュールを更新する前に、更新後のスケジュールが制
約を満たすかどうか、あるいはスケジュールに矛盾が生
じないどうかをチェックし、その操作が制約違反をもた
らす、あるいは矛盾を生じる場合は、その操作が実行不
可である旨を表示し、操作前の状態に戻すよう構成して
もよい。また、上記操作においては、各車両の巡回経路
上の複数個のセルを同時に選択し、他の車両の巡回経路
中に挿入することができるよう構成してもよい。

【０１１９】＜地図形式表示でのスケジュール変更結果
表示＞スケジュールの更新結果は地図形式での表示にも
反映される。また上記の利用要求変更処理を地図形式で
のスケジュール表示画面上にて行ってもよい。地図形式
でのスケジュール表示例を図３２に示す。表示スケジュ
ールは図２９のものと同じである。この例では各客の迎
え先を白丸印、送り先を四角印で表示し、それらを矢印
で結び各車両の巡回経路を表示している。また、迎え先
と送り先の側の長方形枠内にそれぞれの地点での乗車・
降車に関する情報を表示している。長方形枠内の表示内
容は、車両番号（円内の数字）、巡回時刻、乗降車人数
である。この枠内には、地点名、客氏名、荷物数を表示
することも可能である。また空港地点の側の楕円形枠内
にそれぞれの車両の車両番号（円内の数字）、空港到着
時刻あるいは空港出発時刻、乗降車人数を表示してい
る。この他、各車両の巡回地点における乗降客の顧客情
報や、乗務員情報を表示してもよい。

【０１２０】＜地図形式スケジュール表示画面上におけ
るスケジュール手動変更操作例＞このような地図形式で
の表示画面上での利用要求変更処理例を図３３に示す。
上記表形式での表示画面上と同様に、車両１が６：００
に新宿で迎える客が利用要求のキャンセルを行った場
合、その客に関する表示マーク３３０が、オペレータに
よる手動操作（たとえばマウスクリック）やオペレータ
の入力した客ＩＤや客氏名、予約番号などによる指定、
もしくは客による利用要求変更要請内の客ＩＤや予約番
号によって自動的に選択されている。さらにその脇に変
更の種類を選択するウインドウ３３１が表示されている
（内容変更、キャンセル）。以降、上記表形式の表示画
面上における操作と同様の操作にて、変更処理が行わ
れ、スケジュールが更新される。なお、スケジュール更
新後、再通知の必要がある客について形態を変えて表示
してもよい。

【０１２１】また、地図形式の表示画面上で、各車両の
巡回経路を変更し巡回時刻を更新する操作や客の割当車
両の変更操作を行えるようにしてもよい。その操作の一
例を図３４に示す。図中、は客１の乗車を表し、四角
印１は客１の降車を表す。他の客に付いても同様の表示
がなされている。図の状態１に示す乗合車両運行スケジ
ュールでは、車両１は客１と客２を乗車させ、その後、
客２、客１の順で降車させている。車両２は客３を乗車
させ、その後、降車させている。このスケジュールに対
し、表示画面上で以下の操作により、客２の割当車両を
車両１から車両２に変更し、各車両の巡回経路と巡回時
刻を更新する。

【０１２２】まず、図の状態２に示すように、から
への矢印を選択し、その終端を四角印１へ付替える。こ
の時、客２は車両未割当の状態となり、自動的に状態１
での〜四角印１間の矢印は削除される。状態２でスケ
ジュールを決定し更新すると、車両１は客１のみ乗車さ
せ、車両２は客３のみ乗車させ、客２は車両未割当とな
る。ここでは、状態２ではスケジュールを決定せず、車
両２の巡回経路のから四角印３への矢印を選択し、そ
の終端をに付替える。矢印の付替えにおいては、いず
れかの客の降車が乗車より先になる等の矛盾を含む巡回
経路が形成される付替えは許容されない、もしくは警告
が表示される。状態２では、車両２の巡回経路は→
で、客２、３ともに降車が完了しておらず、状態２をス
ケジュールとして決定し更新することはできない。乗車
した客の降車の完了は自動的にチェックされる。状態２
においてさらにと四角印２、および四角印２と四角印
３の間を結合した状態３で全客の乗降車が完了し、この
状態をスケジュールとして決定し更新することが可能と
なる。以上のように車両の巡回経路をさせスケジュール
として決定する際、矢印の結線により決定される各車両
の巡回経路に、乗車したが未降車あるいは降車が乗車よ
り先になっている等の巡回経路の矛盾が自動的にチェッ
クされる。さらに巡回経路上の各地点への巡回時刻が遅
れ時間や乗車定員といった客制約や運用制約を満たして
いるかも自動的にチェックされ、違反している場合は、
違反理由、違反個所が表示され、その状態ではスケジュ
ール保存ができない、もしくは警告が表示されるように
してもよい。

【０１２３】（利用要求受付け締め切り後、スケジュー
ル作成後あるいは通知後の利用要求受付け）利用要求受
付けの締め切り後、利用要求の申込みが合った場合、当
該乗合車両運行スケジュールを未通知であれば、受付け
可否を判定し、受付ける。締め切り後の受付けであるた
め、特別利用料金あるいは手数料を請求する構成として
もよい。当該乗合車両運行スケジュールを既にいずれか
の客に通知済みの場合は、当該乗合車両運行スケジュー
ルの内容や受付済み客の利用要求内容に基づき、受付可
否を判定する。この利用要求を受付け、当該乗合車両運
行スケジュールを更新する場合は、通知済み客の客制約
や運用制約を満たし、かつスケジュール通知済み客が被
る不利益の上限や通知内容からのずれの上限を設定し、
更新後のスケジュールがこの範囲内に収まるようにスケ
ジュールを更新してもよい。また、既に受付済みの客の
利用要求がより優先されるよう、客の重みを設定し、ス
ケジュールの更新を行ってもよい。また、締め切り後に
受付けた客の客制約を緩和するように構成してもよい。
スケジュールの更新結果は、表形式もしくは地図形式の
表示においても反映される。

【０１２４】（車両の利用可能状況に変更が合った場
合）乗合車両運行スケジュール作成後に、当該スケジュ
ールで客を割り当てられている車両が故障のために使用
不可能になった場合など、割当車両の変更の必要が生じ
た場合、本実施形態のシステムは、自動的に車両割当を
変更し、乗合車両運行スケジュールを更新する。かかる
処理の手順例を以下に説明する。

【０１２５】（手順１）車両の利用可能情報の変更に応
じて、運用情報保持部５において当該車両に関する車両
情報を更新する。

【０１２６】（手順２）当該車両に割り当てられた全ス
ケジュールの中で、更新後の利用可能情報の元では運行
不可能なスケジュールにおいて当該車両に割り当てられ
た全客を車両未割当とし客情報保持部４において客情報
を更新する。

【０１２７】（手順３）更新された車両情報と客情報の
もとで、再度乗合車両運行自動スケジューラにより、車
両未割当客に対する再スケジューリングを行う。

【０１２８】（手順４）上記再スケジューリングの結果
を反映し、車両情報を更新する。

【０１２９】上記手順２において客情報を更新する前
に、当該車両の運行を肩代わりできる車両を運用情報保
持部５において検索し、該当する車両が有れば、その中
で最適な車両を割り当て、上記処理を終了してもよい。
また当該スケジュールを破棄し、最新の車両情報に基づ
いて再スケジューリングを行ってもよい。スケジュール
の更新結果は、表形式もしくは地図形式の表示において
も反映される。また上記処理を表形式もしくは地図形式
で表示されたスケジュール上で手動にて行ってもよい。
表形式での表示画面上での車両変更操作例を図３５に示
す。図３５に示すスケジュールにおいて、まず運用情報
保持部５に保持された車両情報から自動的にこのスケジ
ュールでの運行は不可能と判断され選択され、もしくは
オペレータにより選択された車両（車両２）の車両ＩＤ
セルの表示色３５０が変更されており、次に車両２の運
行を代行可能な車両の車両ＩＤリスト３５１が表示され
る。リストの表示順は、例えば当該日時付近の車両利用
状態に基づく利用容易度順や、当該週間月間走行距離の
平均化などの指標にもとづいた使用推奨順、ＩＤ順であ
る。また複数事業者が登録した利用可能車両を表示して
もよい。この例では、リスト３５１の先頭の車両（車両
ＩＤ：２５）が選択され、スケジュールが更新されてい
る。なお、リスト３５１に、利用可能車両と各車両を運
転する乗務員が併せて表示され、乗務員と車両が同時に
選択され、割当変更されるようにしてもよい。また、同
様の操作を地図形式の表示画面上でも実行できるように
してもよい。更新結果に従って、運用情報保持部５の車
両情報などは自動的に更新される。

【０１３０】（乗務員の勤務状況に変更があった場合）
乗合車両運行スケジュール作成後に、当該スケジュール
で客を割り当てられている乗務員が勤務不可能になった
場合など、割当乗務員の変更の必要が生じた場合、本実
施形態のシステムは、自動的に乗務員割当を変更し、乗
合車両運行スケジュールを更新する。その処理の手順例
を以下に示す。

【０１３１】（手順１）乗務員の勤務予定の変更に応
じ、運用情報保持部５において当該乗務員に関する乗務
員情報を更新する。

【０１３２】（手順２）当該乗務員に割り当て済みの全
スケジュールの中で、更新後の勤務予定では運行不可能
なスケジュールの当該乗務員への運行割当を削除する。

【０１３３】（手順３）乗務員情報更新後の勤務予定に
基づいて、乗務員未割当の運行に乗務員を再度割り当
て、乗合車両運行スケジュールを更新する。

【０１３４】（手順４）更新後の乗合車両運行スケジュ
ールに基づいて乗務員情報を更新する。

【０１３５】なお、手順３において、更新後の乗務員情
報の元では乗務員の割り当てが不可能な場合、一度、乗
合車両運行スケジュールを削除し、再スケジューリング
する。あるいは当該スケジュールを破棄し、最新の乗務
員情報に基づいて再スケジューリングする。スケジュー
ルの更新結果は、表形式もしくは地図形式の表示におい
ても反映される。また上記処理を表形式もしくは地図形
式で表示されたスケジュール上で手動にて行ってもよ
い。表形式での表示画面上での乗務員変更操作例を図３
６に示す。図３６に示すスケジュールにおいて、まず運
用情報保持部５に保持された乗務員情報から自動的にこ
のスケジュールでの勤務は不可能と判断され選択され、
もしくはオペレータにより選択された乗務員のセルの表
示色３６０が変更されており、次に当該乗務員の勤務を
代行可能な乗務員の氏名リスト３６１が表示される。リ
ストの表示順は、当該日時付近の乗務員勤務状態に基づ
く勤務割当容易度順や当該週間月間運行時間の平均化な
どの指標にもとづいた勤務割当推奨順、氏名順などであ
る。複数事業者が登録した勤務可能乗務員を表示しても
よい。この例では、リスト３６１の先頭の乗務員が選択
され、スケジュールが更新されている。リスト３６１
に、勤務可能乗務員と各乗務員の使用する車両が併せて
表示され、乗務員と車両が同時に選択され割当変更され
るようにしてもよい。また、同様の操作を地図形式での
表示画面上でも実行できるようにしてもよい。また更新
結果に従って、運用情報保持部５の乗務員情報などは自
動的に更新される。

【０１３６】（道路交通状況に変化があった場合）乗合
車両運行スケジュール作成後に、使用予定道路が通行止
めになった場合など、道路交通状況に変化が合った場
合、本実施形態のシステムは、この変化に従って自動的
に乗合車両運行スケジュールを更新する。かかる処理手
順の一例を以下に示す。

【０１３７】（手順１）道路交通状況の変化の生じた日
時の乗合車両運行スケジュールにおいて、各車両の巡回
時刻を、最新の道路交通情報と作成済みの巡回経路に従
って再計算する。

【０１３８】（手順２）再計算後の巡回時刻の元で、全
客について乗降車時刻に関し、客制約を満たしていれば
この巡回時刻を採用し当該乗合車両運行スケジュールを
更新し処理を終了する。客制約を満たしていない客があ
れば、その客が割り当てられている車両の運行を削除
し、関連する全客を車両未割当とし、客情報および車両
情報を更新する。

【０１３９】（手順３）最新の道路交通情報と客情報に
基づいて、車両未割当の客に対する再スケジューリング
を行う。

【０１４０】なお、手順２においては、運行を削除する
車両の全客を車両未割当とするのではなく、客制約を満
たさない客のみ車両未割当とし、その客への当該車両の
巡回を削除し、削除後の巡回経路に沿って巡回時刻を更
新し、その後手順３を実行するように構成してもよい。
また交通状況の変化により、例えば運用側の設定したあ
る一定数以上の客について客制約を満たせない場合な
ど、多数の客に影響が生じる場合は、当該スケジュール
を破棄し、最新の交通情報に基づいて再スケジューリン
グしてもよい。スケジュールの更新結果は、表形式もし
くは地図形式の表示においても反映される。また道路交
通情報の更新を手動にて行い、スケジュールの更新を行
ってもよい。図３７には、黒丸印とそれらを結ぶ線で表
現された、営業地域の道路ネットワークと、その上に地
図形式で車両の巡回経路と巡回時刻が表示されている。
この例では、車両の巡回経路は→→→である
が、スケジュール作成後、からへの移動に使用して
いる地点Ａ、Ｂ間の道路が通行止めになったとする。こ
のような道路交通状況の変化を反映するため、この例で
は道路ネットワーク上で当該道路を選択し、道路交通の
状態を設定する道路交通状況設定ウインドウ３７０を表
示している。道路交通状況ウインドウ３７０内で該当す
る状況（通行止め）を選択し道路ネットワーク情報を更
新し、その結果に従って車両の巡回経路と巡回時刻の更
新を行っている。道路交通状況設定ウインドウ３７０で
は、選択した道路の通過所要時間や、混雑の度合いなど
を道路の両側路線もしくは片側路線ごともしくは複数道
路や地域ごとに設定可能とすることが好ましい。さらに
これらを月、週、日、時間帯、天候毎などによって設定
可能とすることが好ましい。

【０１４１】なお、本発明は上述した実施形態に限定さ
れず種々変形して実施可能である。

【０１４２】例えば上述した実施形態は、空港向け乗合
車両運行サービスに本発明を適用したものであったが、
この他、乗合タクシーサービスやデマンドバスサービ
ス、観光向け乗合バス・タクシーなど、各種車両運行サ
ービスにおいて本発明を実施することができる。また、
車両運行サービスのみならず、宅配の輸送注文を荷主か
らインターネット経由で受付け、輸送車両の配車を行う
ような資源割当て型の様々なサービスシステムにも本発
明は実施可能である。

【０１４３】

【発明の効果】以上説明したように、本発明によれば、
客からの利用要求や変更希望に対し迅速かつ柔軟に応え
ることのできるサービススケジューリング方法及びプロ
グラムを提供できる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係るサービススケジュー
リングシステムの概念的な構成を示すブロック図

【図２】乗合車両運行サービスに適用したサービススケ
ジューリングシステムの構成を示すブロック図

【図３】利用要求の申込みの例を示す図

【図４】オプション設定フォームの一例を示す図

【図５】運用側から利用要求が受付けられた旨を通知す
るフォームの一例を示す図

【図６】利用要求が受付けられない場合の通知例を示す
図

【図７】利用要求の発生を時系列に示す流れ図

【図８】客に対して利用日、送迎地点、送迎時刻などを
通知するフォームの一例を示す宇図

【図９】利用要求受付け手順Ａの具体的な実行例を示す
流れ図

【図１０】利用要求受付け手順Ｂの具体的な実行例を示
す流れ図

【図１１】客の利用要求発生から受付けから、スケジュ
ーリング、回答処理に至るまでに実施形態のシステムが
実行する一連の処理を時間経過に沿って示す図

【図１２】客Ａに対する通知内容及び制約を示す図

【図１３】客Ａおよび客Ｂに対する通知内容及び制約を
示す図

【図１４】客Ａが回答する前に別の新規利用要求が発生
する場合の処理の流れを示す図

【図１５】客Ｂに対するスケジューリング中に客Ａから
の回答が発生する場合の処理の流れを示す図

【図１６】ある利用要求に対するスケジューリング実行
中に新規利用要求が発生した場合の処理の流れを示す図

【図１７】各客への通知を複数回に分割して行う場合の
処理の流れを示す図

【図１８】各客への通知を複数回に分割して行う場合の
処理の流れを説明するための図であって、ある時刻にお
ける通知の内容を示す図

【図１９】各客への通知を複数回に分割して行う場合の
処理の流れを説明するための図であって、別の時刻にお
ける通知の内容を示す図

【図２０】各客への通知を複数回に分割して行う場合の
処理の流れを説明するための図であって、制約が記入さ
れた通知の内容を示す図

【図２１】スケジュール管理を利用日毎に行っている場
合の、利用要求受付けからスケジュール通知に至るまで
の流れを示す図

【図２２】受付け・通知手順の一例を示す図

【図２３】受付け・通知手順の他の例を示す図

【図２４】利用要求および通知されたスケジュール内容
の表示要請を行うフォームの一例を示す図

【図２５】元の利用要求とスケジュール内容（通知内
容）の表示例を示す図

【図２６】変更要請を指定するためのフォームの一例を
示す図

【図２７】変更要請後の通知フォームの一例を示す図

【図２８】受付け・通知手順の他の例を示す図

【図２９】乗合車両運行スケジュールの表形式での出力
・表示例を示す図

【図３０】利用要求の変更処理を、図２９に例示する表
形式の画面上で手動にて行う場合の操作例を示す図

【図３１】表形式の表示画面上で、各車両の巡回経路を
変更し巡回時刻を更新する操作や客の割当車両の変更操
作を行う場合を示す図

【図３２】地図形式でのスケジュール表示例を示す図

【図３３】地図形式での表示画面上での利用要求変更処
理例を示す図

【図３４】地図形式の表示画面上で、各車両の巡回経路
を変更し巡回時刻を更新する操作や客の割当車両の変更
操作を行う場合を示す図

【図３５】表形式での表示画面上での車両変更操作例を
示す図

【図３６】表形式での表示画面上での乗務員変更操作例
を示す図

【図３７】道路交通情報の更新を手動にて行う例を示す
図

【符号の説明】

１…サービススケジューリングシステム ２…利用要求受付け部 ４…客情報保持部 ６…リソース情報保持部 ８…スケジュール作成部 １０…通知部 ２０…利用者端末

───────────────────────────────────────────────────── フロントページの続き (72)発明者 田中 俊明 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内

Claims (11)

【特許請求の範囲】
1. 【請求項１】 サービスの利用要求に応えるリソースの
   運用スケジュールを作成するサービススケジューリング
   方法において、 新規の利用要求を受け付けるステップと、 利用可能なリソースに関するリソース情報を参照するス
   テップと、 既に受け付けた利用要求を受けて作成された運用スケジ
   ュールに関するスケジュール情報及び該スケジュールに
   関する制約情報を参照するステップと、 前記リソース情報、前記スケジュール情報、及び前記制
   約情報に基づいて前記新規の利用要求を受けた仮スケジ
   ュールを作成するステップと、 前記仮スケジュールの作成結果から前記新規な利用要求
   の受付可否を決定するステップとを具備することを特徴
   とするサービススケジューリング方法。
2. 【請求項２】 前記受付可否を通知するステップと、 前記受付可否の通知に対する回答を受け付けるステップ
   と、 前記受付可否が可と決定された場合であって、前記回答
   によりそれが承認された場合に、前記仮スケジュールを
   運用スケジュールとすることを特徴とするサービススケ
   ジューリングシステム。
3. 【請求項３】 前記受付可否が否と決定された場合に、
   前記新規な利用要求の変更案を作成するステップと、 前記変更案を通知するステップとを具備することを特徴
   とする請求項１に記載のサービススケジューリング方
   法。
4. 【請求項４】 前記仮スケジュールにより、前記運用ス
   ケジュールに変更が生じた場合、その変更に係る情報を
   再通知するステップを具備することを特徴とする請求項
   １又は２に記載のサービススケジューリング方法。
5. 【請求項５】 前記利用要求の変更を受け付けるステッ
   プと、 前記利用要求の変更が反映された変更スケジュールを作
   成するステップと、 前記変更スケジュールを再通知するステップとを具備す
   ることを特徴とする請求項１乃至４のいずれか一項に記
   載のサービススケジューリング方法。
6. 【請求項６】 前記リソース情報の変更を受け付けるス
   テップと、 前記リソース情報の変更が反映された変更スケジュール
   を作成するステップと、 前記変更スケジュールを再通知するステップとを具備す
   ることを特徴とする請求項１乃至５のいずれか一項に記
   載のサービススケジューリング方法。
7. 【請求項７】 サービス利用要求に応じて、複数地点を
   巡回する乗合車両及びその乗務員を含むリソースを運用
   するためのスケジュールを作成する乗合車両運行サービ
   ススケジューリング方法において、 新規の利用要求を受け付けるステップと、 利用可能なリソースに関するリソース情報を参照するス
   テップと、 既に受け付けた利用要求を受けて作成された運用スケジ
   ュールに関するスケジュール情報及び該スケジュールに
   関する制約情報を参照するステップと、 前記リソース情報、前記スケジュール情報、及び前記制
   約情報に基づいて前記新規の利用要求を受けた仮スケジ
   ュールを作成するステップと、 前記仮スケジュールの作成結果から前記新規な利用要求
   の受付可否を決定するステップとを具備することを特徴
   とする乗合車両運行サービススケジューリング方法。
8. 【請求項８】 前記制約情報は、道路交通情報を含むこ
   とを特徴とする請求項７に記載の乗合車両運行サービス
   スケジューリング方法。
9. 【請求項９】 前記リソース情報の変更を、表形式又は
   地図形式で表された前記第１又は第２のスケジュール上
   で指示するステップを具備することを特徴とする請求項
   ７又は８に記載の乗合車両運行サービススケジューリン
   グ方法。
10. 【請求項１０】 サービスの利用要求に応えるリソース
    の運用のスケジュールを作成するサービススケジューリ
    ングに適用されるプログラムであって、 コンピュータに、 新規の利用要求を受け付けるステップと、 利用可能なリソースに関するリソース情報を参照するス
    テップと、 既に受け付けた利用要求を受けて作成された運用スケジ
    ュールに関するスケジュール情報及び該スケジュールに
    関する制約情報を参照するステップと、 前記リソース情報、前記スケジュール情報、及び前記制
    約情報に基づいて前記新規の利用要求を受けた仮スケジ
    ュールを作成するステップと、 前記仮スケジュールの作成結果から前記新規な利用要求
    の受付可否を決定するステップとを実行させるプログラ
    ム。
11. 【請求項１１】 サービス利用要求に応じて、複数地点
    を巡回する乗合車両及びその乗務員を含むリソースを運
    用するためのスケジュールを作成する乗合車両運行サー
    ビススケジューリングプログラムであって、 コンピュータに、 利用可能なリソースに関するリソース情報を参照するス
    テップと、 既に受け付けた利用要求を受けて作成された運用スケジ
    ュールに関するスケジュール情報及び該スケジュールに
    関する制約情報を参照するステップと、 前記リソース情報、前記スケジュール情報、及び前記制
    約情報に基づいて前記新規の利用要求を受けた仮スケジ
    ュールを作成するステップと、 前記仮スケジュールの作成結果から前記新規な利用要求
    の受付可否を決定するステップとを実行させる乗合車両
    運行サービススケジューリングプログラム。