JP2020173133A - スケジュール管理システム - Google Patents

Abstract

【課題】スケジュールに従った移動経路の設定及び変更を簡易に実現する技術を提供する。【解決手段】要求取得部（２３：Ｓ１１〜Ｓ１４）は、出発地、目的地、及び目的地への到着時刻を含んだ情報であるイベント情報、並びに識別情報を取得する。経路探索部（３４：Ｓ１２０、Ｓ１４０、Ｓ１５０、Ｓ２００）は、要求取得部で取得されたイベント情報及び識別情報に従い、ユーザ情報記憶部に記憶されたユーザ情報にて許可された交通手段を用いて経路探索を実行して一つ以上の経路候補を生成する。結果提示部（２３：Ｓ１８〜Ｓ１９）は、経路探索部での探索結果を提示する。【選択図】図１

Description

本開示は、社員の業務を支援する技術に関する。

特許文献１には、センタが、出張等のスケジュールに従って出発地から目的地までの経路を探索し、出発予定時刻、交通手段、及び到着予定時刻を算出して端末に通知するスケジュール管理システムが記載されている。このシステムでは、交通状況の変化によりスケジュールに間に合わないと推定される場合は、新たな出発予定時刻、若しくは新たな到着予定時刻を算出して、端末に通知する。

特開２００５−１１１９６号公報

ところで、カーシェアの普及に伴い、出張に使用できる交通手段の選択肢が増え、複数の交通手段を組み合わせた出張が行われている。しかしながら、発明者の詳細な検討の結果、特許文献１に記載の従来技術では、異なる複数の交通手段を利用するような状況に対応できないという課題が見出された。

また、交通手段の選択肢が増えたことで、会社の推奨する交通手段が設定されていたり、使用可能な交通手段が個人別に制限されていたりする場合がある。このような状況では、自分が使用してもよい交通手段であるか否かを確認しながら、スケジュールに従った移動経路の設定及び変更を行う必要があり、非常に手間がかかるという課題もあった。

本開示の１つの局面は、スケジュールに従った移動経路の設定及び変更を簡易に実現する技術を提供することにある。

本開示の一態様は、スケジュール管理システムであって、ユーザ情報記憶部（３２１）と、要求取得部（２３：Ｓ１１〜Ｓ１４）と、経路探索部（３４：Ｓ１２０、Ｓ１４０、Ｓ１５０、Ｓ２００）と、結果提示部（２３：Ｓ１８〜Ｓ１９）と、を備える。ユーザ情報記憶部は、あらかじめ用意された複数の交通手段のうち、利用を許可する交通手段が示された手段情報を含むユーザ情報が、ユーザを識別する識別情報に対応づけて記憶される。要求取得部は、出発地、目的地、及び目的地への到着時刻を含んだ情報であるイベント情報、並びに識別情報を取得するように構成される。経路探索部は、要求取得部で取得されたイベント情報及び識別情報に従い、ユーザ情報記憶部に記憶されたユーザ情報にて許可された交通手段を用いて経路探索を実行して一つ以上の経路候補を生成するように構成される。結果提示部は、経路探索部での探索結果を提示するように構成される。

このような構成によれば、ユーザ情報に示された、要求元のユーザが利用可能な交通手段を用いて経路探索を実施するため、利用可能な交通手段が何であるかをユーザに意識させることなく、目的地までの適切な移動経路を簡易に設定できる。

スケジュール管理システムの構成を示すブロック図である。 ユーザ情報の内容を例示する説明図である。 端末処理部が実行するスケジューラ処理のフローチャートである。 スケジュール情報に従って表示されるスケジュール表を示す説明図である。 イベント情報の新規入力画面を示す説明図である。 指定されたイベントに関する情報を表示するイベント画面である。 経路探索の結果である複数の経路候補を表示する候補提示画面である。 センタ処理部が実行するスケジュール設定処理のフローチャートである。 センタ処理部が実行する予約監視処理のフローチャートである。 経路が変更された場合の地図表示を例示する説明図である。 経路が変更された場合の経路情報に関するテキスト表示を例示する説明図である。 第２実施形態にてセンタ処理部が実行する経路探索処理のフローチャートである。 スケジュールにイベントを追加する動作に関する説明図である。 社外後予定が存在する場合にイベントを追加した場合の表示画面を示す説明図である。 第３実施形態にてセンタ処理部が実行する現在位置を出発地とする経路探索処理のフローチャートである。 第４実施形態にて車両に搭載された端末装置の端末処理部が実行する端末側処理のフローチャートである。 第４実施形態にてセンタ処理部が実行するセンタ側処理のフローチャートである。

以下、図面を参照しながら、本開示の実施形態を説明する。
［１．第１実施形態］
［１−１．構成］
図１に示すスケジュール管理システム１は、複数の端末装置２と、センタ装置３とを備える。センタ装置３は、例えば、会社内に設置される。また、端末装置２は、センタ装置３と社内ＬＡＮを介して接続されたパーソナルコンピュータ、及びセンタ装置３と無線通信回線を介して接続されるスマートフォンやタブレット等の携帯端末が含まれてもよい。ＬＡＮは、Local Area Networkの略である。

端末装置２は、ＨＭＩ部２１と、通信部２２と、端末処理部２３とを備える。ＨＭＩは、Human Machine Interfaceの略である。
ＨＭＩ部２１は、キーボード及びタッチパネルなどの入力装置、液晶パネルなどの表示装置、スピーカ及びマイクなどの音響装置を備える。ＨＭＩ部２１が有する入力装置は、スケジュールの登録に必要な各種情報、及びスケジュールに登録された目的地への移動に用いる移動経路の設定又は変更において必要となる指示を入力するためなどに用いられる。また、ＨＭＩ部２１が有する表示装置は、情報の入力に用いる入力用画面の表示、及び入力した情報に基づいて実行される処理結果を表示する結果用画面の表示などに用いられる。さらに、ＨＭＩ部２１が有する音響装置は、端末装置２のユーザに対して音声や警報音による聴覚を利用した報知を行うために用いられる。

通信部２２は、無線通信回線又は社内ＬＡＮを介してセンタ装置３との通信を実現する。
端末処理部２３は、ＣＰＵ２３ａと、ＲＡＭ、ＲＯＭ、フラッシュメモリなどの半導体メモリ（以下、メモリ２３ｂ）を有するマイクロコンピュータを備える。端末処理部２３は、ＣＰＵ２３ａがプログラムを実行することで実現される機能の構成として、スケジューラ２３１を備える。スケジューラ２３１の処理内容については後述する。

センタ装置３は、通信部３１と、データベース３２と、予約取得部３３と、センタ処理部３４とを備える。
通信部３１は、無線通信回線又は社内ＬＡＮを介して端末装置２との通信に用いられる。また、通信部３１は、端末装置２以外に、車両との通信、交通情報を提供するサーバとの通信などにも用いられる。

データベース３２は、記憶内容を書き換え可能な不揮発性のメモリで構成され、ユーザ情報記憶部３２１と、スケジュール記憶部３２２とを備える。
ユーザ情報記憶部３２１には、ユーザ情報が記憶される。ユーザ情報は、当該スケジュール管理システム１を利用する個々のユーザに関する情報である。ユーザ情報の設定及び更新は、社内ＬＡＮに接続された特定の端末装置２を介して行われてもよい。

図２に示すように、ユーザ情報には、ユーザ個人を識別する識別情報と対応づけて、そのユーザが利用可能な交通手段に関する手段情報、及びユーザの嗜好に関する嗜好情報が含まれる。

手段情報は、具体的には複数の交通手段のそれぞれについて、利用可能であることを表す「可」、利用不能であることを表す「不可」、異常時にのみ利用可能であることを表す「異常時可」のいずれかを示した情報である。手段情報にて示される交通手段には、マイカー、電車、タクシー、カーシェアリング、レンタカー、及びバスなどが含まれる。例えば、タクシーを「異常時可」とすることで、移動中におけるマイカー又はシェアカーの故障時、事故等による電車の不通時などにのみタクシーを利用できるようにしてもよい。なお、異常時の定義は車両の故障や電車の不通に限定されるものではない。また、手段情報には、マイカーについては、利用可否の情報に加えて、マイカーの停車位置も登録される。この停車位置の情報は、例えば、センタ装置３と車両との通信によって取得される。

嗜好情報には、出張先までの経路設定を行うときに、交通手段の選択において優先すべき事項を表す絞込情報が含まれる。絞込情報としては、例えば、移動時間が最短となることを優先する時間優先、経費が最少となることを優先する金額優先、時刻の遅延が発生し難いことを優先する確実性優先などがある。また嗜好情報には、時間が空いたときに行いたいレジャーの好み、及び食べ物の好みなどが含まれてもよい。レジャーは、大分類としては、スポーツ、映画鑑賞、観光、及び飲食などが含まれ、より詳しい好みを表す中分類や小分類が存在してもよい。例えば、観光については、神社／仏閣、博物館、史跡などの分類があってもよく、スポーツや映画鑑賞については、細かいジャンルを示す分類があってもよい。飲食については、洋食、和食などの大分類の他、ラーメン、ケバブ、鍋、寿司など料理の種類を表す小分類があってもよい。

スケジュール記憶部３２２には、スケジュール情報が記憶される。スケジュール情報は、ユーザを特定するユーザ識別情報に対応づけて記憶される。以下では、スケジュール情報に含まれる個々の予定をイベントという。つまり、スケジュール情報には、イベントの件名、イベントの日時、イベントの実施場所（すなわち目的地）、イベントの内容の他、イベントへの行き帰りの移動方法が含まれる。

予約取得部３３は、外部の予約システム群４に接続され、センタ処理部３４からの指示に従って、各種予約の設定、変更、キャンセルを自動的に実行する。予約システム群４に含まれる予約対象には、例えば、電車、カーシェアリング、タクシー、飛行機、及び駐車場等の交通手段に関する予約が含まれる。また、予約対象には、飲食店や各種レジャー施設に関する予約が含まれてもよい。

センタ処理部３４は、ＣＰＵ３４ａと、ＲＡＭ、ＲＯＭ、フラッシュメモリなどの半導体メモリ（以下、メモリ３４ｂ）を有するマイクロコンピュータを備える。センタ処理部３４は、ＣＰＵ３４ａがプログラムを実行することで実現される機能の構成として、スケジュール設定部３４１と、状況監視部３４２とを備える。

［１−２．端末側：スケジューラ処理］
端末処理部２３のスケジューラ２３１が実行するスケジューラ処理を、図３のフローチャートを用いて説明する。

スケジューラ処理は、端末装置２のＨＭＩ部２１を介して当該処理を起動する操作が入力されると、開始される。
Ｓ１１では、端末処理部２３は、ユーザを特定するユーザ識別情報を示したスケジュール情報要求をセンタ装置３に送信し、センタ装置３からの応答を受信すると、処理をＳ１２に進める。以下、ユーザ識別情報によって特定されるユーザを対象ユーザという。ユーザ識別情報は、スケジューラ処理の起動時にＨＭＩ部２１を介して入力されてもよいし、端末装置２にあらかじめ対応づけられていてもよい。

Ｓ１２では、端末処理部２３は、センタ装置３からの応答に示された対象ユーザに関するスケジュール情報に基づいて、ＨＭＩ部２１の画面にスケジュール表を表示する。スケジュール表は、図４に示すように、登録されたイベントを日付毎に時間軸に沿って並べた形態を有する。

続くＳ１３では、端末処理部２３は、ＨＭＩ部２１を介して新規のイベントを入力する新規入力操作が行われたか否かを判定する。端末処理部２３は、新規入力操作が行われたと判定した場合、処理をＳ１４に移行し、新規入力操作が行なわれていないと判定した場合、処理をＳ１６に移行する。

新規入力操作とは、以下に示す一連の操作をいう。すなわち、ＨＭＩ部２１から入力される指示に従って、情報入力用の画面（以下、新規入力画面）をＨＭＩ部２１の画面に表示させ、ユーザに情報の入力を促す。新規入力画面は、例えば、図５に示すように、イベントの件名、日時、出発地、目的地（すなわち、イベントの実施場所）、イベントの内容などを入力するための領域が含まれる。また、新規入力画面には、保存ボタンＢｓと、経路探索ボタンＢｄとが示される。端末処理部２３は、ＨＭＩ部２１を介した情報入力が行われ、経路探索ボタンＢｄが押下されると、新規入力操作が行われたもの判定する。

Ｓ１４では、端末処理部２３は、センタ装置３に対して登録要求を送信する。登録要求には、新規入力操作によって入力された情報であるイベント情報と、ユーザ識別情報とが含まれる。

続くＳ１５では、端末処理部２３は、登録要求に示されたイベント情報に基づき、経路探索が必要であるか否かを判定する。具体的には、イベントの実施場所が自社内である場合は、経路探索が不要であると判定する。端末処理部２３は、経路探索が必要であれば、処理をＳ１８に移行し、経路探索が不要であれば、センタ装置３からの登録通知の受信を待って、処理をＳ２７に移行する。

Ｓ１６では、端末処理部２３は、ＨＭＩ部２１を介して登録済みのイベントの内容を変更する変更入力操作が行われたか否かを判定する。端末処理部２３は、変更入力操作が行われたと判定した場合、処理をＳ１７に移行し、変更入力操作が行われていないと判定した場合、処理をＳ１３に戻す。

変更入力操作とは、以下に示す一連の操作をいう。すなわち、ＨＭＩ部２１から入力される指示に従って、スケジュール表に示されたイベントの一つを選択する。選択されたイベントの登録内容を表すイベント画面をＨＭＩ部２１の画面に表示させる。イベント画面には、例えば、図６に示すように、新規入力画面にて入力された内容に加えて、出発地から目的地への移動方法と、出発地から目的地までの簡易地図と、移動に利用する交通手段とが示される。利用する交通手段には、チェックボックスにチェックが入った状態で表示される。ユーザは、チェックボックスのチェックを外すことで、その交通手段を使用しないこと、すなわち、交通手段の変更を指示することができる。この他、新規入力画面での入力項目が変更されてもよい。そして、端末処理部２３は、ＨＭＩ部２１を介して、変更内容の入力が行われ、経路探索ボタンＢｄが押下されると、変更入力操作が行われたものと判定する。

Ｓ１７では、端末処理部２３は、センタ装置３に対して変更要求を送信して、処理をＳ１８に進める。変更要求には、変更入力操作によって入力された情報である変更情報と、ユーザ識別情報とが含まれる。

Ｓ１８では、端末処理部２３は、センタ装置３からの応答を受信するまで待機し、センタ装置３からの応答を受信すると、Ｓ１９に処理を進める。
Ｓ１９では、端末処理部２３は、センタ装置３からの応答に含まれる複数の経路情報を示す候補提示画面、ＨＭＩ部２１の表示画面に表示する。なお、候補提示画面に示される複数の経路情報は、登録要求又は変更要求に従ってセンタ装置３が経路探索を行った結果である。候補提示画面には、図７に示すように、複数の経路候補が示され、経路候補のそれぞれについて出発地から目的地までの移動方法と、出発地から目的地までの経路を表す簡易地図と、使用する交通手段とが表示される。交通手段については、変更入力画面と同様に、チェックボックスが示される。また、経路候補のそれぞれについても、どの経路候補を選択するかを指定するためのチェックボックスが示される。

続くＳ２０では、端末処理部２３は、ＨＭＩ部２１を介して経路選択操作が行われたか否かを判定する。経路選択操作とは、候補提示画面において、ユーザが、経路候補を指定するいずれかのチェックボックスにチェックを入れた上で、保存ボタンＢｓを押下する操作である。端末処理部２３は、経路選択操作が行われたと判定した場合、処理をＳ２３に移行し、経路選択操作が行われていないと判定した場合は処理をＳ２１に移行する。

Ｓ２１では、端末処理部２３は、ＨＭＩ部２１を介して変更入力操作が行なわれたか否かを判定する。変更入力操作は、先のＳ１６にて説明した操作と同様である。端末処理部２３は、変更入力操作が行われたと判定した場合、処理をＳ２２に移行し、変更入力操作が行われていないと判定した場合、処理をＳ２０に戻す。

Ｓ２２では、端末処理部２３は、Ｓ１７での処理と同様に、センタ装置３に対して変更要求を送信して、処理をＳ１８に戻す。
Ｓ２３では、端末処理部２３は、センタ装置３に対して予約要求を送信し、予約要求に対するセンタ装置３からの応答を受信するまで待機し、応答を受信すると、処理をＳ２３に進める。予約要求には、経路選択操作により選択された経路候補を表す選択経路と、ユーザ識別情報とが含まれる。

続くＳ２４では、端末処理部２３は、センタ装置３からの応答内容を確認し、選択経路に関する予約に成功したか否かを判定する。端末処理部２３は、応答が情報更新通知である場合は、予約に成功したと判定して処理をＳ２７に移行し、応答が予約失敗通知である場合は、予約に失敗したと判定して処理をＳ２５に移行する。

Ｓ２５では、端末処理部２３は、予約に失敗したことを、ＨＭＩ部２１を介して視覚的又は聴覚的にユーザに報知する。
続くＳ２６では、端末処理部２３は、ＨＭＩ部２１の画面に表示されている経路探索ボタンＢｄが押下されると、センタ装置３に再探索要求を送信して、処理をＳ１８に戻す。

Ｓ２７では、端末処理部２３は、スケジュールの更新（すなわち、新規登録又は変更）が完了したことを、ＨＭＩ部２１を介して視覚的又は聴覚的にユーザに報知する。
続くＳ２８では、端末処理部２３は、スケジュールの更新を確認したことを表す確認通知をセンタ装置３に送信して、処理を終了する。

なお、Ｓ１３及びＳ１６、Ｓ２０及びＳ２１において、予め設定された許容時間内に操作が確認されなかった場合は、処理を強制終了させてもよい。
スケジューラ処理において、Ｓ１１〜Ｓ１４が要求取得部に相当し、Ｓ１６〜Ｓ１７が変更取得部に相当し、Ｓ１８〜Ｓ１９が結果提示部に相当し、Ｓ２０〜Ｓ２３が選択部に相当する。

［１−３．センタ側処理］
センタ処理部３４は、後述するスケジュール設定処理及び状況監視処理の他、ユーザ情報処理、情報提供処理を行う。

ユーザ情報処理は、端末装置２からの要求に従って、データベース３２のユーザ情報記憶部３２１に記憶されるユーザ情報の追加、更新、削除を行う処理である。
情報提供処理は、端末装置２からスケジュール情報要求を受信すると、スケジュール情報要求に示されたユーザ識別情報から特定されるユーザに関して、スケジュール記憶部３２２に記憶されたスケジュール情報を、要求元の端末装置２に返送する処理である。スケジュール情報要求は、図３におけるＳ１１にて送信される。

［１−３−１．スケジュール設定処理］
センタ処理部３４が実行するスケジュール設定処理を、図８のフローチャートを用いて説明する。

スケジュール設定処理は、端末装置２からの登録要求、変更要求、又は再探索要求を受信した場合に開始される。登録要求は、図３におけるＳ１４にて送信され、変更要求は、図３におけるＳ１７にて送信され、再探索要求は、図３におけるＳ２６にて送信される。

Ｓ１１０では、センタ処理部３４は、端末装置２から受信した要求が、未登録のイベントに関する新規の登録要求であるか否かを判定する。センタ処理部３４は、端末装置２からの要求が登録要求であると判定した場合、処理をＳ１２０に移行し、端末装置２からの要求が登録要求ではないと判定した場合、処理をＳ１３０に移行する。

Ｓ１２０では、センタ処理部３４は、登録要求に示されたイベント情報及びユーザ識別情報と、そのユーザ識別情報に対応づけてユーザ情報記憶部３２１に記憶されたユーザ情報（以下、対象ユーザ情報）とに基づく経路探索を実施して、処理をＳ１６０に進める。ここでの経路探索では、手段情報にて許容された交通手段を用いて、イベント情報に示された出発地から目的地までの複数の移動経路（以下、経路候補）を生成し、絞込情報に従って、対象ユーザの嗜好に応じた所定個の経路候補を抽出する。抽出する経路候補の数は、例えば、ユーザ情報の一つとして設定されてもよい。

Ｓ１３０では、センタ処理部３４は、端末装置２からの要求が変更要求であるか否かを判定する。センタ処理部３４は、端末装置２からの要求が変更要求であると判定した場合、再探索条件が成立したとして、処理をＳ１４０に移行し、端末装置２からの要求が変更要求ではないと判定した場合、予約失敗時の再探索要求であるとして、処理をＳ１５０に移行する。

Ｓ１４０では、センタ処理部３４は、変更要求に示された変更情報と、対象ユーザ情報とに基づく経路探索を実施して、処理をＳ１６０に進める。ここでの経路探索は、登録情報の変わりに変更要求に示された変更情報が考慮される以外は、Ｓ１２０での経路探索と同様の処理が実行される。

Ｓ１５０では、センタ処理部３４は、後述するＳ２５０で記憶される予約失敗情報と、対象ユーザ情報とに基づく経路探索を実施して、処理をＳ１６０に進める。ここでの経路探索は、予約失敗情報に基づき、予約に失敗した交通手段を外す、又は時間をずらす変更を行ったうえで、Ｓ１２０での経路探索と同様の処理が実行される。

但し、Ｓ１２０、Ｓ１４０、Ｓ１５０、及び後述するＳ２００において、登録要求における出発地と目的地とが同じである場合、変更要求における変更が経路に関わる内容以外である場合には、経路探索は省略され、経路候補は生成されない。

Ｓ１６０では、センタ処理部３４は、経路探索によって経路候補が生成されたか否かを判定し、経路候補が生成されていると判定した場合、処理をＳ１７０に移行し、経路候補が生成されていないと判定した場合、処理をＳ２３０に移行する。

Ｓ１７０では、センタ処理部３４は、経路探索の結果である複数の経路候補を、要求の送信元となった端末装置２に返送する。
続くＳ１８０では、センタ処理部３４は、端末装置２から予約要求を受信したか否かを判定し、予約要求を受信したと判定した場合、処理をＳ２１０に移行し、予約要求を受信していないと判定した場合、処理をＳ１９０に移行する。予約要求は、図３におけるＳ２３にて送信される。

Ｓ１９０では、センタ処理部３４は、端末装置２から変更要求を受信したか否かを判定し、変更要求を受信したと判定した場合、処理をＳ２００に移行し、変更要求を受信していないと判定した場合、処理をＳ１８０に戻す。ここでの変更要求は、図３におけるＳ２２にて送信される。

Ｓ２００では、センタ処理部３４は、変更要求に示された変更情報と、対象ユーザ情報とに基づく経路探索を実施して、処理をＳ１６０に戻す。ここでの経路探索は、Ｓ１４０での経路探索と同様の処理が実行される。

Ｓ２１０では、センタ処理部３４は、予約要求に示された選択経路の内容に従って、予約を必要とする交通手段についての予約を取得させる指示を、予約取得部３３に送信し、予約取得部３３からの応答が得られると、処理をＳ２２０に進める。

Ｓ２２０では、センタ処理部３４は、予約取得部３３からの応答の内容から、予約に成功したか否かを判定し、予約に成功したと判定した場合、処理をＳ２３０に移行し、予約に失敗したと判定した場合、処理をＳ２４０に移行する。

Ｓ２３０では、センタ処理部３４は、登録要求，変更要求に従って追加又は変更されたイベントの内容、及びそのイベントの開催場所への移動経路に従って、スケジュール記憶部３２２に記憶されたスケジュール情報を更新する。更に、センタ処理部３４は、スケジュール情報を更新したことを表す情報更新通知を、その更新内容と共に端末装置２に送信して、処理を終了する。

Ｓ２４０では、センタ処理部３４は、予約要求に対する応答として、予約に失敗した旨を表す予約失敗通知を送信する。
続くＳ２５０では、センタ処理部３４は、予約失敗情報を一時的に記憶して、処理を終了する。予約失敗情報には、予約に失敗した交通手段を特定する情報が少なくとも含まれる。また、一時的に記憶するとは、予め設定された許容時間の間だけ記憶を保持することである。つまり、予約失敗通知を受信した端末装置２にて、経路探索ボタンＢｄが、許容時間内に再度押下されると、本処理が再起動したときに、Ｓ１５０にて予約失敗情報を利用した経路探索が実行される。

スケジュール設定処理において、Ｓ１２０、Ｓ１４０、Ｓ１５０、Ｓ２００が経路探索部に相当する。
［１−３−２．予約監視処理］
センタ処理部３４が実行する予約監視処理を、図９のフローチャートを用いて説明する。

予約監視処理は、予め設定された時間間隔で周期的に実行される。
Ｓ３１０では、センタ処理部３４は、通信部３１を介して外部のネットワーク上のサーバ等から、当該スケジュール管理システム１にて使用する交通手段に関する交通情報を取得する。交通情報には、道路の渋滞状況、道路の規制状況、鉄道の運行状況、カーシェアリングの空き状況、及び駐車場の空き状況等が含まれる。

続くＳ３２０では、センタ処理部３４は、スケジュール情報からいずれか一つのイベント情報を対象イベント情報として選択する。
続くＳ３３０では、センタ処理部３４は、Ｓ３１０で取得した交通情報と、対象イベント情報と共に記憶された移動経路とを照合する。

続くＳ３４０では、センタ処理部３４は、Ｓ３３０での照合の結果、経路変更が必要であるか否かを判定し、経路変更が必要であると判定した場合、再探索条件が成立したとして、処理をＳ３５０に移行し、経路変更が不要であると判定した場合、処理をＳ４３０に移行する。

Ｓ３５０では、センタ処理部３４は、経路変更が必要であると判定された移動経路について、交通情報を考慮した別経路の探索を実行する。具体的には、ある鉄道が不通である場合、別の鉄道を利用する経路や鉄道の代わりに車両（すなわち、カーシェアリング、バス、タクシー及びマイカーなど）を利用する経路を設定する。また、交通手段として車両を使用する場合、渋滞が生じている道路を回避する経路を設定したり、鉄道を利用する経路に変更したりする。別経路の探索によって生成される経路は、１つでも良いし複数でもよい。

続くＳ３６０では、センタ処理部３４は、Ｓ３５０での探索結果を、対象イベント情報を登録したユーザの端末装置（以下、対象端末装置）２に対して送信する。
続くＳ３７０では、センタ処理部３４は、対象端末装置２からの応答として変更承諾を受信したか否かを判定し、変更承諾を受信したと判定した場合、処理をＳ４００に移行し、変更承諾を受信していないと判定した場合、処理をＳ３８０に移行する。経路探索結果として複数の別経路を送信している場合は、変更承諾には、いずれの別経路を選択するかについての情報が含まれる。

Ｓ３８０では、センタ処理部３４は、対象端末装置２からの応答としてキャンセルを受信するか、又は探索結果の送信後、対象端末装置２からの応答がないまま許容時間を経過したか否かを判定する。センタ処理部３４は、キャンセルの受信又は応答なしと判定した場合は、処理をＳ３９０に移行し、キャンセルの受信及び応答なしのいずれでもないと判定した場合は、処理をＳ３７０に戻す。

Ｓ３９０では、センタ処理部３４は、Ｓ３２０にて選択された対象イベント情報を、スケジュール記憶部３２２から削除すると共にして、予約取得部３３に対象イベント情報に関する予約の取り消しを指示してＳ４３０に移行する。

Ｓ４００では、センタ処理部３４は、対象端末装置２からの変更承諾に従い、承諾された別経路について、交通手段に関する予約を取得させる指示を、予約取得部３３に送信し、予約取得部３３からの応答が得られると、処理をＳ４１０に進める。別経路に関する予約の実行と共に、変更前の経路に関する予約のキャンセルも実行する。

Ｓ４１０では、センタ処理部３４は、予約取得部３３からの応答の内容から、予約に成功したか否かを判定し、予約に成功したと判定した場合、処理をＳ４２０に移行し、予約に失敗したと判定した場合、処理をＳ３５０に戻す。この場合Ｓ３５０では、予約に失敗した交通手段を除いた別経路の探索を実行する。

Ｓ４２０では、センタ処理部３４は、変更承諾された別経路に従って、スケジュール記憶部３２２に記憶されたスケジュール情報を更新する。更に、センタ処理部３４は、スケジュール情報を更新したことを表す情報更新通知を、その更新内容と共に対象端末装置２に送信して、処理をＳ４３０に進める。

Ｓ４３０では、センタ処理部３４は、スケジュール記憶部３２２に記憶されたスケジュール情報に含まれる全てのイベント情報について、Ｓ３２０〜Ｓ４２０の処理が実行されたか否かを判定する。センタ処理部３４は、全てのイベント情報について処理が実行されたと判定した場合は、当該予約監視処理を終了し、未処理のイベント情報が存在すると判定した場合、処理をＳ３２０に戻して、未処理のスケジュール情報についての処理を続ける。

予約監視処理において、Ｓ３１０が状況取得部、Ｓ３２０〜Ｓ４３０が再実行部に相当する。
［１−４．システム動作］
スケジュール管理システム１における動作について説明する。

ユーザが端末装置２を操作して、センタ装置３から自身のスケジュール情報を取得すると、端末装置２の画面には、図４に示すスケジュール表が表示される。
ユーザは、新規のイベントを登録する場合は、図５に示す入力画面を表示させて、新規入力操作を実施する。登録済みのイベントを変更する場合は、スケジュール表において変更対象となるイベントを指定することで、図６に示すイベント画面を表示させて、変更入力操作を実施する。

ユーザにより、端末装置２を介して新規入力操作又は変更入力操作が実施されると、センタ装置３にて経路探索が実施され、端末装置２の画面には、図７に示すように、探索結果である複数の経路候補が列挙された候補提示画面が表示される。但し、新たに入力されたイベントの目的地が自社内である場合は、経路探索は行われずに、そのままスケジュール情報として登録される。

複数の経路候補の中にユーザが希望する経路候補がなく、ユーザにより、端末装置２を介して、交通手段の条件を変更する等の変更入力操作が実施されると、センタ装置３にて、変更された条件での経路探索が実施され、端末装置２の画面に候補提示画面が表示される。

複数の経路候補の中にユーザが希望する経路候補があり、ユーザにより、端末装置２を介して、経路候補のいずれかを選択する操作が実施されると、センタ装置３にて経路候補に関する予約の取得が実施され、予約に成功した場合には、イベントの登録が終了する。

予約に失敗した場合には、ユーザにより、端末装置２を介して、許容時間内に再検索を要求する操作が実施されると、センタ装置３にて予約に失敗した経路を除外した再検索が実施され、端末装置２の画面に候補提示画面が表示される。

次に、交通状況の変化によって、経路変更が必要な場合について説明する。
センタ装置３にて経路変更が必要な状況が検出されると、別経路の探索が実施され、対象となるユーザの端末装置２の画面に探索結果が表示される。このとき、予約まで確定した一つの探索結果を表示してもよいし、複数の経路候補を表示して、いずれかの経路候補をユーザ選択させてもよい。

また、端末装置２では、別経路の探索結果は、経路変更が実施されたことをユーザが理解しやすい形式で表示される。簡易地図の場合、例えば、図１０に示すように、変更前の経路と変更後の経路とがいずれも表示され、更に、変更の原因となった交通手段に利用不能であることを示すマークが重畳表示されてもよい。また、テキストの場合、例えば、図１１に示すように、変更後の経路に関するテキストと共に、取り消し線が上書きされた変更前の経路に関するテキストが表示されてもよい。

［１−５．効果］
以上詳述した第１実施形態によれば、以下の効果を奏する。
（１ａ）スケジュール管理システム１では、端末装置２を介してスケジュールにイベントが登録された場合、センタ装置３では、イベントの目的地までの移動経路を、ユーザ情報記憶部３２１に記憶されたユーザ情報を利用して探索する。特に、ユーザ情報のうち、要求元のユーザが利用可能な交通手段を表す手段情報が用いられる。従って、スケジュール管理システム１によれば、利用可能な交通手段が何であるかをユーザに意識させることなく、目的地までの適切な移動経路を簡易に設定できる。

（１ｂ）スケジュール管理システム１では、センタ装置３は、経路探索の結果として複数の経路候補を、端末装置２を介してユーザに提示し、ユーザによっていずれかの経路候補が選択されると、選択された経路に関する予約を自動的に実行する。従って、スケジュール管理システム１によれば、交通手段等の予約に要するユーザの手間を削減できる。

（１ｃ）スケジュール管理システム１では、センタ装置３は、ユーザに提示する複数の経路候補を、ユーザ情報に示された絞込情報に従って絞り込んで抽出する。従って、スケジュール管理システム１によれば、ユーザの好みに応じた経路候補を提示できる。

（１ｄ）スケジュール管理システム１では、センタ装置３は、定期的に交通状況を監視し、経路変更が必要な状況である場合は、自動的に別経路を検索して、端末装置２を介してユーザに提案し、ユーザに承認されると、自動的に予約を実行する。従って、スケジュール管理システム１によれば、目的地への移動中に、利用中又は利用予定の交通手段にトラブルが発生した場合でも、ユーザを煩わせることなく速やかに代替経路を設定できる。

［２．第２実施形態］
［２−１．第１実施形態との相違点］
第２実施形態は、基本的な構成は第１実施形態と同様であるため、相違点について以下に説明する。なお、第１実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。

前述した第１実施形態では、スケジュールに新規イベントを追加する時に、個々のイベントを対象にして経路探索を実施する場合について説明した。これに対し、第２実施形態では、すでに登録されている他のイベントを考慮した経路探索を実施する点で、第１実施形態と相違する。

［２−２．経路探索処理］
本実施形態において、センタ処理部３４が、Ｓ１３０で実行する経路探索処理を、図１２のフローチャートを用いて説明する。なお、イベントの時間を変更する要求があった場合は、Ｓ１４０、Ｓ１５０、Ｓ２００、Ｓ３５０でも、以下で説明する処理に準じた処理が実行される。

Ｓ５１０では、センタ処理部３４は、端末装置２からの登録要求に示されたイベントを対象イベントとして、対象イベントの目的地である対象目的地が自社外であるか否かを判定する。センタ処理部３４は、対象目的地が自社外であると判定した場合、処理をＳ５２０に移行し、対象目的地が自社内であると判定した場合、経路を探索する必要がないため、処理を終了する。

Ｓ５２０では、センタ処理部３４は、対象イベントより前の時間帯に既に登録されている最後のイベントであって目的地が自社外であるイベント（以下、社外前イベント）が存在するか否かを判定する。センタ処理部３４は、社外前イベントが存在しないと判定した場合、処理をＳ５３０に移行し、社外前イベントが存在すると判定した場合、処理をＳ５４０に移行する。

Ｓ５３０では、センタ処理部３４は、自社から対象目的地までの経路を探索して、処理をＳ５６０に進める。
Ｓ５４０では、センタ処理部３４は、社外前イベントの目的地（以下、前目的地）から一旦帰社し、改めて対象目的地に向かう一旦帰社経路を探索する。

続くＳ５５０では、センタ処理部３４は、前目的地から対象目的地に直行する直行経路を探索して、処理をＳ５６０に進める。
Ｓ５６０では、センタ処理部３４は、対象イベントより後の時間帯に既に登録されている最初のイベントであって目的地が自社外であるイベント（以下、社外後イベント）が存在するか否かを判定する。センタ処理部３４は、社外後イベントが存在しないと判定した場合、処理を終了し、社外後イベントが存在すると判定した場合、処理をＳ５７０に移行する。

Ｓ５７０では、センタ処理部３４は、対象目的地から一旦帰社し、改めて社外後イベントの目的地（以下、後目的地）に向かう一旦帰社経路を探索する。
続くＳ５８０では、センタ処理部３４は、対象目的地から後目的地に直行する直行経路を探索して、処理を終了する。

つまり、対象イベントが追加された場合、対象イベントへの移動に利用する経路として、社外前イベントが存在しない場合は、自社から対象目的地までの経路のみが探索され、社外前イベントが存在する場合は、一旦帰社経路と直行経路とが探索される。

更に、社外後イベントが存在する場合には、対象イベントから社外後イベントへの移動に利用する経路として、一旦帰社経路と直行経路とが探索される。
［２−３．システム動作］
図１３に示すように、登録済みのイベントの前に新規のイベントを登録について説明する。なお、登録済みのイベント（以下、社外後イベント）は、１／１６（水）の１１：００〜１２：００に設定され、新規のイベント（以下、対象イベント）は１／１６（水）の９：００〜１０：００を予定とする。いずれも目的地は社外である。

対象イベントを登録するための新規入力操作が端末装置２を介して実施されると、対象イベントへの移動に利用する経路については、第１実施形態での説明と同様の候補提示画面が表示される。

また、対象イベントが追加されたことにより、社外後イベントへの移動経路を変更するか否かユーザに検討させる必要がある。このため、端末装置２の画面には、図１４に示すように、対象目的地から後目的地へ移動する際に一旦帰社する一旦帰社経路と、帰社しないで直行する直行経路とをいずれも表示する候補提示画面が表示される。一旦帰社経路と直行経路とは、それぞれ一つの経路候補が表示されてもよいし、それぞれ複数の経路候補が表示されてもよい。また、候補提示画面上で、一旦帰社経路及び直行経路のいずれかを選択できるようにし、選択された側に関する複数の経路候補が表示されてもよい。

以下、候補提示画面に表示された経路候補から希望する経路を選択したり、条件を変更して再検索したりする手順は、第１実施形態にて説明した内容と同様である。
［２−４．効果］
以上詳述した第２実施形態によれば、前述した第１実施形態の効果（１ａ）〜（１ｄ）を奏し、さらに以下の効果を奏する。

（２ａ）スケジュール管理システム１では、対象イベントの前又は後に、他のイベントが既に登録されている場合、一旦帰社経路と直行経路とをいずれも検索してユーザに提示する。従って、スケジュール管理システム１によれば、スケジュール変更に伴う各イベント先への移動方法の再検討に要するユーザの手間を削減できる。

［３．第３実施形態］
［３−１．第１実施形態との相違点］
第３実施形態は、基本的な構成は第１実施形態と同様であるため、相違点について以下に説明する。なお、第１実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。

前述した第１実施形態では、スケジュールの追加変更を、スケジュールに沿った移動が開始される以前に行う場合について説明した。これに対し、第３実施形態では、スケジュールの追加変更を、スケジュールに沿った移動中にリアルタイムで行う場合の処理が追加されている点で、第１実施形態と相違する。

［３−２．経路探索処理］
本実施形態において、センタ装置３が実行する経路探索処理を、図１５のフローチャートを用いて説明する。なお、本処理は、センタ装置３が端末装置２から出発地を現在値とする登録要求を受信した場合に、Ｓ１２０にて実行される処理である。

Ｓ６１０では、センタ処理部３４は、登録要求に目的地の入力があるか否かを判定し、目的地の入力がないと判定した場合は、処理をＳ６２０に移行し、目的地の入力があると判定した場合は、処理をＳ６３０に移行する。

Ｓ６２０では、センタ処理部３４は、現在位置からスケジュールに登録された次のイベントの目的地（以下、次目的地）までの経路を探索して、処理を終了する。
Ｓ６３０では、センタ処理部３４は、登録要求に示された目的地がレジャー施設等の位置であるか否かを判定し、レジャー施設等の位置であると判定した場合、処理をＳ６４０に移行し、レジャー施設等の位置ではないと判定した場合、処理をＳ６５０に移行する。

Ｓ６４０では、センタ処理部３４は、現在位置から登録要求にて指定された目的地（すなわち、レジャー施設等の位置）を経由地とする現在位置から次目的地までの経路を探索して、処理を終了する。

Ｓ６５０では、センタ処理部３４は、登録要求の目的地に示された内容に従って、探索対象となるレジャー施設の分類を決定する。具体的には、目的地にレジャー施設の分類が明示されている場合は、その明示された分類を用いる。検索要求の目的地にレジャー施設の検索を要求する旨だけが示されレジャー施設の分類が明示されていない場合は、ユーザ情報に登録された対象ユーザの嗜好情報に従ってレジャー施設の分類を決定する。

続くＳ６６０では、センタ処理部３４は、登録要求に示された現在位置と、次目的地とに基づいて探索範囲を設定し、その探索範囲内に存在し、かつ、Ｓ６５０で決定された分類に含まれるレジャー施設を中間目的地として探索する。

続くＳ６７０では、センタ処理部３４は、Ｓ６３０で探索された中間目的地を経由値とする、現在位置から次目的地までの経路を探索して処理を終了する。但し、探索結果の絞り込みは、現在時刻、現在位置から中間目的地までの移動時間、中間目的地での最低滞在時間、中間目的地から次のイベントの目的地までの移動時間、次のイベントの開始時間などを考慮して行う。

［３−３．システム動作］
あるイベントが予定より早く終了し、次に予定されているイベントの開始時刻まで、時間が空いている状況を想定する。

ユーザが、次のイベントまでの空き時間を利用した寄り道を考えた場合、具体的に行きたい場所がある場合には、その場所を目的地とし、現在位置を出発地とする登録要求を、端末装置２からセンタ装置３に送信する。すると、センタ装置３は、指定目的地を経由地とする現在位置から次目的地までの経路探索を実施し、探索結果である複数の経路候補が端末装置２の画面に表示される。以下の動作は第１実施形態での説明と同様である。

また、具体的に行きたい場所はないが、食事をしたい等の目的がある場合は、目的に沿ったレジャー施設の分類を目的地とし、現在位置を出発地とする登録要求を、端末装置２からセンタ装置３に送信する。するとセンタ装置３では、目的に沿ったレジャー施設が探索され、その探索したレジャー施設を経由地とする現在位置から次目的地までの経路探索が実施され、探索結果である複数の経路候補が端末装置２の画面に表示される。以下の動作は第１実施形態での説明と同様である。

更に、特に何かをしたいとの目的もない場合は、レジャー検索を要求する旨を目的地とし、現在位置を出発地とする登録要求を、端末装置２からセンタ装置３に送信する。するとセンタ装置３では、あらかじめ登録されているユーザ情報に従ってユーザの嗜好に応じたレジャー施設が検索され、その探索したレジャー施設を経由地とする現在位置から次目的地までの経路探索が実施される。その探索結果である複数の経路候補が端末装置２の画面に表示される。以下の動作は第１実施形態での説明と同様である。

前のイベントの終了後、何らかの都合で次目的地へ向かう移動経路から外れた位置に移動してしまい、次目的地までの移動経路を再設定したい場合、出発地を現在位置とし、目的地を入力なしとした登録要求を、端末装置２からセンタ装置３に送信する。するとセンタ装置３では、現在位置から次目的地までの経路探索が実施され、探索結果である複数の経路候補が端末装置２の画面に表示される。以下の動作は第１実施形態での説明と同様である。

［３−４．効果］
以上詳述した第３実施形態によれば、前述した第１実施形態の効果（１ａ）〜（１ｄ）を奏し、さらに、以下の効果を奏する。

（３ａ）スケジュール管理システム１では、予め登録されたスケジュールに従った行動だけでなく、スケジュールの進行状況などに応じたユーザ要因での予定の追加や経路変更を、ユーザを煩わせることなく臨機応変に実行できる。

［４．第４実施形態］
［４−１．第１実施形態との相違点］
第４実施形態は、基本的な構成は第１実施形態と同様であるため、相違点について以下に説明する。なお、第１実施形態と同じ符号は、同一の構成を示すものであって、先行する説明を参照する。

前述した第１実施形態では、スマートフォンやタブレット等の一般的な携帯端末を端末装置２として用いる場合について説明した。これに対し、第４実施形態では、マイカーやシェアカーと一体に搭載された端末装置２、又はマイカーやシェアカーとの通信により車両の状況を判定するための情報を取得可能な端末装置２を前提とした処理について説明する。

［４−２．処理］
ここでは、ユーザ要因でスケジュールの変更を行う一例として、スケジュールに従い、予約されたシェアカーを利用して次の目的地まで移動しているときに、シェアカーに異常が生じた場合に対処するための処理について説明する。以下では、シェアカーを単に車両という。

［４−２−１．端末側処理］
まず、端末装置２の端末処理部２３が実行する端末側処理を、図１６のフローチャートを用いて説明する。なお、端末側処理は、予め設定された周期で繰り返し実行される。

Ｓ４１では、端末処理部２３は、車両の状態を表す情報を取得し、その情報に基づいて、車両に異常が発生しているか否かを判定する。端末処理部２３は、車両に異常が生じていると判定した場合は、処理をＳ４２に移行し、車両は正常であるあると判定した場合は、処理を終了する。

Ｓ４２では、端末処理部２３は、検出された異常の内容に基づき、車両の走行を継続することが可能であるか否かを判定し、走行を継続できると判定した場合、処理をＳ４３に移行し、走行を継続できないと判定した場合、処理をＳ４７に移行する。

Ｓ４３では、端末処理部２３は、ＨＭＩ部２１を介して、車両に異常が生じているが走行を継続することが可能であることを、車両の乗員に対して報知する。
続くＳ４４では、端末処理部２３は、ＨＭＩ部２１を介して、車両の交換を提案する報知を行う。

続くＳ４５では、端末処理部２３は、提案を行ってから予め設定された許容時間内に、ＨＭＩ部２１を介して、車両の交換を指示する交換要求が入力されたか否かを判定する。端末処理部２３は、交換要求が入力されたと判定した場合は、処理をＳ４６に移行し、交換要求が入力されていないと判定した場合は、Ｓ５０に処理を移行する。

Ｓ４６では、端末処理部２３は、走行を継続可能であるが車両交換を要求する旨が示された異常時変更要求をセンタ装置３に送信して、処理をＳ５０に進める。
つまり、車両の異常に対してユーザが車両交換を要求しない場合、スケジュール管理システム１では、通常時と同様の処理が行われる。一方、ユーザが車両交換を要求した場合、センタ装置３にて、車両交換が可能な店舗を経由地とする次目的地までの経路が探索され、その探索結果である複数の経路候補が端末装置２を介してユーザに提示される。

Ｓ４７では、端末処理部２３は、ＨＭＩ部２１を介して、車両に異常が生じていること、しかも車両は走行不能であることを、車両の乗員に対して報知する。
続くＳ４８では、端末処理部２３は、安全な場所を見つけて車両を停止させる退避走行を車両に実行させる。

続くＳ４９では、端末処理部２３は、走行不能でありことを示した異常時変更要求をセンタ装置３に送信して、処理をＳ５０に進める。
この場合、異常時変更要求に対してセンタ装置３では、現在位置から最寄りの代替交通手段への移動方法を含めた次目的地までの経路が探索され、その探索結果である複数の経路候補が端末装置２を介してユーザに提示される。

Ｓ５０では、端末処理部２３はＳ１３〜Ｓ２８までの処理が実行される。これにより、ユーザによって複数の経路候補のいずれかが選択されると、センタ装置３によって、選択された経路に関する交通手段等の予約が取得される。

［４−２−２．センタ側処理］
次に、センタ装置３のセンタ処理部３４が実行するセンタ側処理を、図１７のフローチャートを用いて説明する。センタ側処理は、端末装置２から異常時変更要求を受信した場合に起動する。

Ｓ７１０では、センタ処理部３４は、受信した異常時変更要求に含まれる情報に従って、要求元の端末装置２を搭載する車両（以下、要求元車両）が走行可能である否かを判定する。センタ処理部３４は、要求元車両は走行可能であると判定した場合は、処理をＳ７２０に移行し、要求元車両は走行不能であると判定した場合、処理をＳ７４０に移行する。

Ｓ７２０では、センタ処理部３４は、異常時変更要求に示された要求元車両の現在位置に基づき、車両交換に対応可能な最寄りのカーポートを検索する。
続くＳ７３０では、センタ処理部３４は、検索されたカーポートを経由地とする次目的地までの移動経路を探索して、処理を終了する。

Ｓ７４０では、センタ処理部３４は、異常事態であることを前提として、異常時変更要求に示された要求元車両の現在位置から、次目的地までの移動経路を探索して処理を終了する。つまり、通常時であれば、タクシーの利用が禁止されているユーザであっても、異常事態であればタクシーの利用を含めた移動経路が探索される。このため、例えば、要求元車両の現在位置から徒歩による移動圏内に他の交通手段が存在しない場合に、現在位置から最寄りの交通手段を利用できる場所までタクシーで移動する経路の設定が可能となる。

［４−３．効果］
以上詳述した第４実施形態によれば、前述した第１実施形態の効果（１ａ）〜（１ｄ）を奏し、さらに、以下の効果を奏する。

（４ａ）スケジュール管理システム１では、スケジュールに従って利用中の車両が故障した場合でも、代替の交通手段の提案及び手配を、ユーザを煩わせることなく実行できる。
［５．他の実施形態］
以上、本開示の実施形態について説明したが、本開示は上述の実施形態に限定されることなく、種々変形して実施することができる。

（５ａ）上記実施形態では、利用可能な交通手段がユーザ毎に設定されると共に、異常事態が生じた場合に利用可能な交通手段が増えるようにされているが、本開示はこれに限定されるものではない。例えば、打ち合わせの優先度に応じて、利用可能な交通手段の設定を変化させてもよい。また、打ち合わせへの参加者が一人である場合や、打ち合わせの責任者については、通常許可されていない交通手段（例えば、タクシー）の使用が許可されてもよい。

（５ｂ）本開示に記載の端末処理部２３及びセンタ処理部３４、並びにそれらの手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の端末処理部２３及びセンタ処理部３４、並びにそれらの手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の端末処理部２３及びセンタ処理部３４、並びにそれらの手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。端末処理部２３及びセンタ処理部３４に含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。

（５ｃ）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。

（５ｄ）上述したスケジュール管理システムの他、当該スケジュール管理システムとしてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体など、種々の形態で本開示を実現することもできる。

１…スケジュール管理システム、２…端末装置、３…センタ装置、４…予約システム群、２１…ＨＭＩ部、２２，３１…通信部、２３…端末処理部、２３ａ，３４ａ…ＣＰＵ、２３ｂ，３４ｂ…メモリ、３２…データベース、３３…予約取得部、３４…センタ処理部、２３１…スケジューラ、３２１…ユーザ情報記憶部、３２２…スケジュール記憶部、３４１…スケジュール設定部、３４２…状況監視部。

Claims (8)

1. あらかじめ用意された複数の交通手段のうち、利用を許可する前記交通手段が示された手段情報を含むユーザ情報が、ユーザを識別する識別情報に対応づけて記憶されるユーザ情報記憶部（３２１）と、
   出発地、目的地、及び前記目的地への到着時刻を含んだ情報であるイベント情報、並びに前記識別情報を取得するように構成された要求取得部（２３：Ｓ１１〜Ｓ１４）と、
   前記要求取得部で取得された前記イベント情報及び前記識別情報に従い、前記ユーザ情報記憶部に記憶された前記ユーザ情報にて許可された前記交通手段を用いて経路探索を実行して一つ以上の経路候補を生成するように構成された経路探索部（３４：Ｓ１２０、Ｓ１４０、Ｓ１５０、Ｓ２００）と、
   前記経路探索部での探索結果を提示するように構成された結果提示部（２３：Ｓ１８〜Ｓ１９）と、
   を備えるスケジュール管理システム。
2. 請求項１に記載のスケジュール管理システムであって、
   前記経路探索部にて生成された前記一つ以上の経路候補から選択された経路である選択経路を取得する選択部（２３：Ｓ２０，Ｓ２３）と、
   前記要求取得部で取得された前記イベント情報及び前記選択部にて取得された前記選択経路が、前記スケジュール情報の一部として記憶されるスケジュール記憶部（３２２）と、
   を更に備えるスケジュール管理システム。
3. 請求項２に記載のスケジュール管理システムであって、
   前記選択部にて選択された前記選択経路について、該選択経路に従った移動の実現に必要な予約を取得するように構成された予約取得部（３３）と、
   を更に備え、
   前記スケジュール記憶部には、前記予約取得部で取得された予約の内容が、前記スケジュール情報の一部として記憶される、
   スケジュール管理システム。
4. 請求項２又は請求項３に記載のスケジュール管理システムであって、
   あらかじめ設定された再探索条件が成立する場合に、前記スケジュール記憶部に記憶された前記スケジュール情報のそれぞれについて、前記経路探索部に前記経路探索を再実行させる再実行部（３４：Ｓ３２０〜Ｓ４３０）、
   を更に備えるスケジュール管理システム。
5. 請求項４に記載のスケジュール管理システムであって、
   前記複数の交通手段の状況を取得するように構成された状況取得部（Ｓ３１０）を更に備え、
   前記再探索条件には、前記複数の交通手段に関わる状況の変化が含まれる
   スケジュール管理システム。
6. 請求項４又は請求項５に記載のスケジュール管理システムであって、
   前記スケジュール記憶部に記憶された前記スケジュール情報に含まれる前記イベント情報の変更内容を表す変更情報、及び前記識別情報が示された変更要求を取得するように構成された変更取得部（２３：Ｓ１６〜Ｓ１７）を更に備え、
   前記再探索条件には、前記変更取得部にて前記変更要求が取得されることが含まれる
   スケジュール管理システム。
7. 請求項６に記載のスケジュール管理システムであって、
   前記変更情報には、前記出発地又は前記目的地の変更、前記交通手段の変更のうち、少なくとも一つが含まれる
   スケジュール管理システム。
8. 請求項１から請求項７までのいずれか１項に記載のスケジュール管理システムであって、
   前記交通手段には、マイカー、カーシェアリング、及びレンタカーのうち少なくとも一つが含まれる
   スケジュール管理システム。

Images