JP2007334415A

JP2007334415A - 予約管理装置および予約変更方法およびプログラムおよび記録媒体

Info

Publication number: JP2007334415A
Application number: JP2006162282A
Authority: JP
Inventors: Ryoko Mori; 涼子毛利; Tomoe Nagamatsu; ともえ永松
Original assignee: Canon Software Inc
Current assignee: Canon IT Solutions Inc
Priority date: 2006-06-12
Filing date: 2006-06-12
Publication date: 2007-12-27

Abstract

【課題】複数のサービスを予約している場合、その中のある予約が実行できないときにその予約を自動変更する際に、従来発生していた、ユーザによる、それ以降の予約の手動変更の手間を省くこと。
【解決手段】予約管理サーバ１００は、予約ＤＢ１０５で管理される各予約情報を監視して遂行の可否を判断し、変更の必要があると判断された予約情報と、該予約情報の変更に基づき、影響される他の１又は複数の予約情報を連動して変更又は取り消し制御する構成を特徴とする。
【選択図】図１

Description

本発明は、複数のサービスの予約情報を複数記憶管理し、予約が実行できないときにその予約を自動変更する予約管理装置の予約変更制御に関する。

従来より、予定の遅れにより予約が実行不可能となった場合、自動的に予約を変更するシステムが提案されている（特許文献１〜３）。
特開２００４−１３９２８７号公報特開２００２−２９７９８４号公報特開平１０−６３７２８号公報

しかしながら、特許文献１〜３に記載の技術では、時間差で複数の予約を行っていた場合、ひとつ目の予約は自動的に変更されるが、それ以降の予約については考慮されていないため、ユーザが自分で予約を変更しなければならないという問題点があった。

本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、予定が遅延した場合、それ以降の複数の予約を自動的に変更することにより、ユーザが予約変更を行う手間を省くことができる仕組を提供することである。

本発明は、複数のサービスの予約情報を複数記憶管理する記憶手段と、前記記憶手段に記憶管理される各予約情報を監視して遂行の可否を判断する監視手段と、前記監視手段により変更の必要があると判断された予約情報と、該予約情報の変更に基づき、影響される他の１又は複数の予約情報を連動して変更又は取り消し制御する制御手段と、を有することを特徴とする。

本発明によれば、ユーザが複数のサービスを予約しており、その中のある予約が実行できないときにその予約を自動変更した場合、それ以降の予約についても実行可能か判定し、変更が必要な場合は自動変更することが可能となる等の効果を奏する。

以下、図面を参照して、本発明の詳細を説明する。

〔第１実施形態〕
図１は、本発明の一実施形態を示す自動予約変更システムの構成の一例を示すシステム構成図である。

図１に示すように、予約管理サーバ１００は、予約ＤＢ１０５、予約変更条件ＤＢ１０６、顧客ＤＢ１０７を有し、サービスの予約から自動予約変更までを制御する。

予約ＤＢ１０５には、ユーザの予約情報が、予約変更条件ＤＢ１０６には各予約の変更条件が、顧客ＤＢ１０７にはユーザの情報がそれぞれセットされており、これらの情報をもとに予約管理サーバ１００は自動予約変更を行う。

端末２００は、ユーザがサービス予約をする際に使用する端末であり、ネットワーク３００に接続されている。携帯端末２０１は、ユーザが移動中に携帯する、通信機能及びＧＰＳ機能を有する端末である。この携帯端末２０１は、ＧＰＳ７００やネットワーク３００に接続されており、予約管理サーバ１００は、この携帯端末２０１によりユーザの現在位置の取得や、予約変更のユーザへの通知を行う。また、この携帯端末２０１からもサービス予約が可能である。

サービス予約サーバ４００は、各予約センターに設置されており、実際にサービスの予約を行う。

サービス情報ＤＢ４０１には、予約センターが提供する各サービスの内容、エリア、時間等の情報がセットされている。サービス予約情報ＤＢ４０２には、各サービスの予約情報がセットされている。

予約管理サーバ１００は、ネットワーク３００を介し、各サービス予約サーバ４００にアクセスすることで、サービス照会、サービス予約、予約のキャンセル等を行う。なお、サービス予約サーバ４００は、システム外部のものであり、複数存在する。

運行情報管理サーバ５００も、システム外部のサーバであり、公共の交通機関の運行情報を管理している。ユーザが公共の交通機関を利用している場合に、予約管理サーバ１００は、運行情報管理サーバ５００から情報を取得し、ユーザの遅延予測の計算等を行う。

位置情報管理サーバ６００は、位置情報ＤＢ６０１を有し、これをもとにエリア情報を位置座標へマッピングする処理を行う。位置情報ＤＢ６０１には、エリア情報に対応した位置座標がセットされている。予約管理サーバ１００は、ネットワーク３００を介し、位置情報管理サーバ６００へアクセスし、各サービスの位置情報を取得する。

図２は、図１に示した予約管理サーバ１００のハードウェア構成を示すブロック図であり、図１と同一のものには同一の符号を付してある。なお、予約管理サーバ１００以外のサーバ、各種端末及び予約管理サーバ以外のサーバのハードウェア構成も、外部メモリの構成を除けば予約管理サーバ１００と同様である。外部メモリの構成はサーバごとに異なる。

図２において、１０１はＣＰＵであり、サーバ装置の中枢となる制御装置である。１０２はＲＡＭ（Random Access Memory）であり、プログラムのワークエリアや一時的に保持するデータのバッファとして利用される。１０３はＲＯＭ（Read Only Memory）であり、ブートプログラム等の保存等を行う。

１０４は外部メモリであり、プログラム，各種データの保持を行う。外部メモリ１０４は、具体的にはハードディスクドライブ等である。なお、この外部メモリ１０４には、予約ＤＢ１０５，予約変更条件ＤＢ１０６，顧客ＤＢ１０７の各データが記憶さている。

１０８は入力装置であり、この装置を通じてデータ，指示等の入力が行われる。なお、入力装置１０８は、具体的にはキーボードやポインティングデバイス（マウス等）である。１０９は表示装置であり、具体的にはディスプレイ等である。

１１１は通信インターフェースであり、通信ネットワーク３００と接続する部分である。

以下、図３〜図８を用いて、図１に示した各ＤＢのデータ構成について説明する。

図３は、図２に示した予約管理サーバ１００の外部メモリ１０４に記憶されている予約ＤＢ１０５の一例を示す図である。

図３に示すように、予約ＤＢ１０５は、予約番号１０００，ユーザＩＤ，予約センターＩＤ１００２，予約センター予約番号１００３，予約内容１００４，サービス開始エリア１００５，サービス開始位置データ１００６，サービス終了エリア１００７，サービス終了位置データ１００８，予約開始日時１００９，予約終了日時１０１０の各項目の情報から構成される。

以下、各項目について説明する。

予約番号１０００とは、予約管理サーバ１００で各予約に割り当てられた番号のことである。ユーザＩＤ１００１は、各ユーザに付与されているＩＤであり、別々にとられた予約をユーザごとにまとめて管理するために必要となる。

予約センターＩＤ１００２は、各予約センターのサービス予約サーバのＩＤを示し、このＩＤをもとに予約管理サーバ１００は、各サービス予約サーバ４００にアクセスする。

予約センター予約番号１００３は、各予約センターのサービス予約サーバ４００によって各予約に付与された番号である。予約内容１００４には、予約されたサービスが記録されている。

サービス開始エリア１００５とは、予約内容の実行開始時のエリアである。サービス開始位置データ１００６とは、サービス開始エリア１００５が位置情報管理サーバ６００でマッピングデータに変換されたものである。

サービス終了エリア１００７は、予約内容の実行終了時のエリアであり、サービス終了位置データ１００８とは、サービス終了エリア１００７がマッピングデータに変換されたものである。

予約開始日時１００９は、予約内容の実行開始日と時間、予約終了日時１０１０は予約内容の実行終了日と時間を示している。なお、サービス内容等によっては予約終了日時１０１０がセットされない場合もある。

図４は、図２に示した予約管理サーバ１００の外部メモリ１０４に記憶されている予約変更条件ＤＢ１０６の一例を示す図である。このデータベースは、ユーザが予約内容を変更した場合や、既に予約したものに遅延が発生するなど予約内容を変更する必要性が発生した場合に、ユーザの操作なしに、自動的に予約内容の変更を行うためのデータベースである。

以下、各項目について説明する。

図４に示すように、予約変更条件ＤＢ１０６は、予約番号１１００，取り消し１１０１，時間変更１１０２，変更許容時間帯１１０３，優先度１１０４の各項目の情報から構成される。

予約番号１１００は、予約ＤＢ１０５の予約番号１０００と共通であり、予約管理サーバ１００で各予約に割り当てられた番号のことである。

取り消し１１０１は、その予約を自動的に取消すことが可能か示し、これが「可」になっている場合には、その予約を自動的に取消すことができ、一方、「不可」になっている場合には、その予約を自動的に取消すことはできない。

なお、取り消し１１０１が不可になっている予約の実行が不可能になった場合には、その旨をユーザに通知する。また、取り消し１１０１が不可になっている予約同士で実行可能時間が重なってしまった場合は、その旨をユーザに通知する。

時間変更１１０２は、予約時間を自動的に変更することが可能か示し、これが「可」になっている場合には、その予約の時間を自動的に変更することができ、一方、「不可」になっている場合には、その予約の時間を自動的に変更することはできない。

変更許容時間帯１１０３は、時間変更１１０２が「可」となっている場合にセットされる情報であり、ここにセットされている時間帯であれば、予約時間を自動的に変更することができる。そのため、変更許容時間帯が重なる予約がある場合には、その予約の順序が入れ替わる可能性があることをユーザに対し通知する。

優先度１１０４は、ユーザにとってのその予約の重要度を示す。同一ユーザのある予約とある予約の実行可能時間が重なってしまった場合に、より優先度の低い予約が取消される。なお、取り消し１１０１が「不可」となっている場合には、優先度は「１」となる。

図５は、図２に示した予約管理サーバ１００の外部メモリ１０４に記憶されている顧客ＤＢ１０７の一例を示す図である。このデータベースは、顧客の登録情報を管理するためのデータベースである。

図５に示すように、顧客ＤＢ１０７は、ユーザＩＤ１２００，ユーザ名１２０１，電話番号１２０２，メールアドレス１２０３，自宅住所１２０４，登録地１２０５，１２０６，クレジットカード情報１２０７，移動手段１（１２０８），移動手段２（１２０９），移動手段３（１２１０）の各項目の情報から構成される。

以下、各項目について説明する。

ユーザＩＤ１２００は、予約ＤＢ１０５のユーザＩＤ１００１と共通であり、登録顧客を識別するために使用される。ユーザ名１２０１は、ユーザの氏名である。

電話番号１２０２は、登録顧客の電話番号である。メールアドレス１２０３は、ユーザのメールアドレスであり、ユーザに通知が必要な際の連絡手段として使用する。自宅住所１２０４は、ユーザの自宅住所であり、自宅から予約したサービスの開始場所への経路探索などに利用してもよい。なお、この項目は必須ではない。

登録地１２０５，１２０６は、ユーザがよく利用する施設の場所（会社、学校など）であり、予約の実施前にどこにいるかを指定しておくことで、指定地からサービス開始場所への経路探索などに利用してもよい。なお、この項目は必須ではない。

クレジットカード情報１２０７は、ユーザが予約したサービスの支払いに使用するカードの情報である。移動手段１〜３（１２０８〜１２１０）は、ユーザが利用可能な移動手段とその速度である。速度はユーザが指定してもよいし、平均速度を自動的に割り当ててもよい。移動手段と速度は、経路探索や所要時間の計算などに利用する。なお、移動手段１〜３（１２０８〜１２１０）は、必須ではない。

図６は、図１に示した位置情報管理サーバ６００の外部メモリに記憶されている位置情報ＤＢ６０１の一例を示す図である。このデータベースは、位置の住所やエリアコードなどを位置座標の情報として管理するためのデータベースである。

図６に示すように、位置情報ＤＢ６０１は、ＩＤ６３００，都道府県６３０１，市区町村６３０２，番地６３０３，ビル名など６３０４，位置情報６３０５の各項目の情報から構成される。

以下、各項目について説明する。

ＩＤ６３００は、位置情報管理サーバ６００で各位置情報に割り当てられた番号のことである。都道府県６３０１、市区町村６３０２、番地６３０３、ビル名など１３０４は、ある場所を特定するための住所である。これらのデータは、場所が特定可能であれば住所以外の情報でもよい。

位置情報６３０５は、住所によって特定された場所を北緯、東経によって数値で表した位置データである。この位置データは独自のマッピング座標を用いてもよい。

図７は、図１に示したサービス予約サーバ４００の外部メモリに記憶されているサービス情報ＤＢ４０１の一例を示す図である。このデータベースは、予約可能なサービスの情報を管理するためのデータベースであり、ユーザによるサービスの照会、予約、予約変更といったときに利用される。ここでは、映画の座席予約サービス情報を例として挙げている。

図７に示すように、サービス情報ＤＢ４０１は、サービス番号１４００，場所１４０１，映画館１４０２，タイトル１４０３，開始時間１４０４，終了時間１４０５，最大予約数１４０６の各項目の情報から構成される。

以下、各項目について説明する。

サービス番号１４００は、サービス予約サーバ４００で各サービスに割り当てられた番号のことである。場所１４０１は、サービスが実施される場所の情報である。ただし、サービス内容が、新幹線や飛行機のチケット予約など移動が伴うサービスの場合は、サービス開始場所とサービス終了場所の２つの場所データが必要となる。

映画館１４０２は、サービスが実施される設備名である。タイトル１４０３は、サービスの内容を示す名前である。開始時間１４０４は、サービスが開始する時間である。終了時間１４０５は、サービスが終了する時間である。最大予約数１４０６は、サービスの予約を受付可能な最大数である。

なお、上記各項目の情報１４０１〜１４０６は、サービス内容によって必要な情報が異なる。

図８は、図１に示したサービス予約サーバ４００の外部メモリに記憶されているサービス予約情報ＤＢ４０２の一例を示す図である。このデータベースは、サービス予約サーバで提供している各サービスの予約情報を管理するためのデータベースである。

図８に示すように、サービス予約情報ＤＢ４０２は、予約番号１５００，ユーザＩＤ１５０１，サービス番号１５０２，予約開始日時１５０３，予約受付日時１５０４の各項目の情報から構成される。

以下、各項目について説明する。

予約番号１５００は、サービス予約サーバ４００で各サービスの予約に割り当てられた番号のことである。ユーザＩＤ１５０１は、予約を行った顧客を識別するために使用される。サービス番号１５０２は、サービス情報ＤＢ４０１のサービス番号１４００と共通であり、ユーザが予約したサービスの番号である。

予約開始日時１５０３は、ユーザが予約したサービスを開始する年月日である。予約受付日時１５０４は、ユーザが予約を行った年月日である。

なお、予約開始日時１５０３，予約受付日時１５０４は、サービス内容によって必要な情報が異なる。

以下、図９〜図２７を参照して、本発明の予約管理サーバにおける予約処理動作および予約変更処理動作について説明する。以下、ユーザは携帯端末２０１で操作を行うものとして説明するが、ユーザが端末２００から操作を行う場合も同様である。

まず、図９〜図１６を用いて、本発明の各処理で携帯端末２０１の表示部に表示される各画面について説明する。

図９〜図１６は、ユーザの携帯端末の表示部に表示される各画面の模式図である。まず、ここで各画面に共通なボタンについて説明する。

図９〜図１６において、１３０１は決定ボタンであり、この決定ボタン１３０１が押下されると、各画面でユーザが選択した内容を確定する。

１３０２はキャンセルボタンであり、このキャンセルボタン１３０２が押下されると、各画面でユーザが選択や変更した内容を確定せずに、元のデータのままとなる。１３０３は戻るボタンであり、この戻るボタン１３０３が押下されると、ひとつ前に表示されていた画面に戻る。

１３０４，１３０５はラジオボタンであり、ラジオボタン１３０４はユーザが選択した状態を示し、ラジオボタン１３０５はユーザが選択していない状態を示す。１３０６は予約一覧表示ボタンであり、この予約一覧表示ボタン１３０６を押下すると、予約一覧表示画面を表示し、ユーザの一連の予約内容を確認することができる。なお、各画面の詳細については後述する。

図９は、本発明の予約自動変更装置におけるユーザ情報設定画面を示す模式図である。

図９は、ユーザ登録時にユーザがユーザ情報を設定するときに表示される。または、新規予約を行うときに表示するようにしてもよい。

図９において、１３１０，１３１１は移動手段選択チェックボックスである。チェックボックス１３１０は、ユーザが移動手段を選択している状態であり、チェックボックス１３１１は、ユーザが移動手段を選択していない状態である。１３１２は移動手段の速度を示す。

図１０は、本発明の予約自動変更装置における予約画面を示す模式図であり、ユーザが指定した条件に合致するサービスを表示する。

図１０において、１３２０はユーザが指定した条件である。１３２３はサービスを受ける地域の情報である。１３２４はサービスを受ける場所の情報である。１３２５はサービスの開始時間および終了時間である。

図１１は、本発明の予約自動変更装置における予約遅延通知画面を示す模式図であり、ユーザが予約しているサービスの予約開始日時までに、ユーザの到着は不可能であるとサーバが予測した時点で表示される。

この画面で、ユーザは予約の遅延予測内容を確認することができるとともに、ボタン１３３１「予約の変更またはキャンセル」、ボタン１３３２「遅延の通知」、ボタン１３３３「何もしない」などの選択肢から、以降の操作を選択できる。

図１２は本発明の予約自動変更装置における予約変更／キャンセル画面を示す模式図であり、ユーザが図１１に示した画面でボタン１３３１「予約の変更またはキャンセル」を選択したときに変更可能な予約データが表示される。

図１２において、ラジオボタン１３４０は、変更可能な時間帯にユーザが希望する選択肢がない場合に、他の類似したサービスで希望の時間帯に空きがあるものがないか検索するための選択肢である。

また、アイコン１３４１「＊」は、アイコンが表示されている変更可能な時間帯をユーザが選択した場合は、予約Ａ以降に予約されているサービスを変更する必要があることを示している。

図１３は、本発明の予約自動変更装置における予約一覧表示画面を示す模式図であり、ユーザが各画面の「予約一覧表示」ボタン１３０６を押下したとき、または予約を変更またはキャンセルした操作の最後に表示される。

この画面は、ユーザの予約一覧を時系列で表示する。また、この画面で、アイコン１３５０「！」は、遅延により実行不可能となった予約であることを示している。

図１４は、本発明の予約自動変更装置における予約変更条件設定画面を示す模式図であり、ユーザの予約の変更／キャンセルが必要になった場合、どのように変更／キャンセルを行うかを決定するための条件を設定する画面である。

図１４において、１３６０はユーザが予約した予約の内容である。１３６１は予約の取り消しが「可」または「不可」を設定する項目である。１３６２は予約の時間変更が「可」または「不可」を設定する項目である。１３６３は１３６２の時間変更が「可」の場合のみ設定する項目で、時間変更の許容時間を設定する項目である。１３６４は予約の優先度を設定する項目である。

図１５は、本発明の予約自動変更装置における予約変更通知画面を示す模式図であり、ユーザが設定した予約変更条件により、予約管理サーバ１００が自動的に予約の変更やキャンセルを行えないときに表示される。

図１５において、予約内容１３７１は、予約管理サーバ１００が変更した予約の内容である。変更前日時１３７２は、予約管理サーバ１００が変更した予約の変更前の予約開始日時と終了日時である。変更後日時１３７３は、予約管理サーバ１００が自動的に変更した新規の予約開始日時と終了日時である。

図１６は、本発明の予約開始画面の一例を示す模式図であり、ユーザが予約を開始したときに携帯端末２０１の表示部に表示される。

図１６において、１３８１は予約検索が可能なサービスのジャンルである。１３８２は検索するサービスの時間を指定する項目である。１３８３は事前に登録してあるユーザＩＤを入力する項目である。

＜予約処理＞
以下、図１７〜図２０を用いて、本発明の予約自動変更システムにおける予約処理動作について説明する。

図１７〜図２０は、本発明の自動予約変更システムシステムにおける第１の制御処理手順の一例を示すフローチャートであり、本発明の予約自動変更システムにおける予約処理動作に対応する。なお、Ｓ４０１〜Ｓ４４４は各ステップを示す。

また、携帯端末２０１側の処理は、携帯端末２０１のＣＰＵがＲＯＭ等に格納されるプログラムを読み出して実行することにより実現される。また、サービス予約サーバ４００側の処理は、サービス予約サーバ４００のＣＰＵ１０１が、外部メモリに格納されるプログラムをＲＡＭ上に読み出して実行することにより実現される。さらに、予約管理サーバ１００側の処理は、予約管理サーバ１００のＣＰＵ１０１が、外部メモリ１０４に格納されるプログラムをＲＡＭ１０２上に読み出して実行することにより実現される。また、位置情報管理サーバ６００側の処理は、位置情報管理サーバ６００のＣＰＵが、外部メモリに格納されるプログラムをＲＡＭ上に読み出して実行することにより実現される。

まず、ユーザが、携帯端末２０１を操作して図１６のサービス検索条件入力画面から、ユーザＩＤ、及び、サービス検索条件を入力し、決定ボタン１３０１を押下する。

すると、ステップＳ４０１において、携帯端末２０１のＣＰＵは、予約管理サーバ１００に対し、ユーザＩＤ及び、図１６のサービス検索条件入力画面から入力されたサービス検索条件およびサービス照会の開始要求を予約管理サーバ１００に送信する。

すると、ステップＳ４０２において、予約管理サーバ１００のＣＰＵ１０１は、ユーザＩＤとサービス照会開始要求を受信すると、ステップＳ４０３において、予約管理サーバ１００のＣＰＵ１０１は、指定されたサービス検索条件に合致したサービスを提供しているサーバであるサービス予約サーバ４００にサービス照会要求を送信する。

すると、ステップＳ４０４において、サービス予約サーバ４００のＣＰＵは、このサービス照会要求を受信し、指定されたサービス検索条件に基づいて、サービス情報ＤＢ４０１からアクセスし条件に合致するサービスを検索する。そして、ステップＳ４０５において、サービス予約サーバ４００のＣＰＵは、ステップＳ４０４で検索した結果を予約管理サーバ１００に送信する。

すると、ステップＳ４０６において予約管理サーバ１００のＣＰＵ１０１は、ユーザが指定した条件に合致するサービスの検索結果一覧を取得する。そして、ステップＳ４０７において、予約管理サーバ１００のＣＰＵ１０１は、サービス検索結果一覧をユーザ端末に送信する。

すると、ステップＳ４０８においてユーザ端末は、このサービス検索結果一覧受信し、表示部に図１０に示すようにサービス検索結果一覧を表示する。

ステップＳ４０９において、携帯端末２０１は、ユーザにステップＳ４０８で表示されたサービス検索結果一覧から、予約を行うサービスを選択させる。このとき、予約管理サーバ１００はユーザが選択したサービスを遂行するための移動手段の情報をユーザから受け付け、予約ＤＢ１０５にセットするようにしても良い。もしくは、ユーザが選択したサービス遂行前のユーザの位置から適した移動手段を検索、提示し、ユーザに選択させ、予約ＤＢ１０５にセットするようにしても良い。

次に、ステップＳ４１０において、携帯端末２０１のＣＰＵは、ユーザが選択したサービスのサービス番号と予約開始要求を予約管理サーバ１００に送信する。

すると、ステップＳ４１１において、予約管理サーバ１００のＣＰＵ１０１は、サービス開始要求（予約開始を行うサービス番号）を取得する。次に、ステップＳ４１２において、予約管理サーバ１００のＣＰＵ１０１は、ユーザが指定したサービス番号およびサービス番号と一致するサービスの「サービス開始エリア」、「サービス終了エリア」の取得要求をサービス予約サーバ４００に送信する。

すると、ステップＳ４１３において、サービス予約サーバ４００のＣＰＵは、取得したサービス番号と一致するサービスの「サービス開始エリア」と「サービス終了エリア」をサービス情報ＤＢ４０１から取得する。

次に、ステップＳ４１４において、サービス予約サーバ４００のＣＰＵは、「サービス開始エリア」、「サービス終了エリア」を予約管理サーバ１００に送信する。

すると、ステップＳ４１５において、予約管理サーバ１００のＣＰＵ１０１は、サービス予約サーバ４００から送信された「サービス開始エリア」、「サービス終了エリア」を取得する。

そして、ステップＳ４１６において、予約管理サーバ１００のＣＰＵ１０１は、位置情報管理サーバ６００に「サービス開始エリア」を座標データに変換した「サービス開始位置」、および「サービス終了エリア」を座標データに変換した「サービス終了位置」の取得要求を送信する。

すると、ステップＳ４１７において、位置情報管理サーバ６００のＣＰＵは、予約管理サーバ１００から送信された要求を取得し、該取得した「サービス開始エリア」および「サービス終了エリア」の情報に対応する位置情報「サービス開始位置」および「サービス終了位置」を、位置情報ＤＢ６０１から取得する。

そして、ステップＳ４１８において、位置情報管理サーバ６００のＣＰＵは、「サービス開始位置」および「サービス終了位置」を予約管理サーバ１００に送信する。

すると、ステップＳ４１９において、予約管理サーバ１００のＣＰＵ１０１は、位置情報管理サーバ６００から送信された「サービス開始位置」および「サービス終了位置」を取得する。

そして、ステップＳ４２０において予約管理サーバ１００のＣＰＵ１０１は、ステップＳ４０２で取得したユーザＩＤをキーにして、予約ＤＢ１０５からユーザの既存の予約すべてについて一連の情報を取得する。

さらに、ステップＳ４２１において、予約管理サーバ１００のＣＰＵ１０１は、ユーザの一連の予約情報とユーザが選択したサービスの、サービス開始位置データ、サービス終了位置データ、予約開始日時、予約終了日時、移動手段から新規予約サービスが遂行可能か計算する。

ステップＳ４２２において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ４２１での計算結果に基づいて、ユーザが選択したサービスが遂行可能か否かを判定し、遂行不可能と判定した場合には、ステップＳ４３９に処理を進め、ユーザが選択したサービスの予約処理を中止するか、ユーザが選択したサービスの遂行を可能にするため、その他の予約内容の変更、もしくはキャンセルを行うかをユーザに選択させるようにする。なお、詳細は後述する。

一方、ステップＳ４２２で、予約管理サーバ１００のＣＰＵ１０１は、ユーザが選択したサービスが遂行可能と判定した場合には、ステップＳ４２３に処理を進める。

そして、ステップＳ４２３において、予約管理サーバ１００のＣＰＵ１０１は、ユーザが選択したサービスのサービス番号と予約開始日時、予約終了日時を指定し、サービス番号に対応したサービスの新規予約要求をサービス予約サーバ４００に送信する。

すると、ステップＳ４２４において、サービス予約サーバ４００のＣＰＵは、サービス番号、予約開始日時、予約終了日時を受信し、サービス番号に一致するサービスの新規予約処理を受付ける。

さらに、ステップＳ４２５において、サービス予約サーバ４００のＣＰＵは、サービス予約情報ＤＢ４０２にユーザＩＤ,サービス番号、予約開始日時、予約終了日時、予約受付日時の情報をセットする。

さらに、ステップＳ４２６において、サービス予約サーバ４００のＣＰＵは、サービスの新規予約処理が完了した旨を予約管理サーバ１００に通知する。

すると、ステップＳ４２７において、予約管理サーバ１００のＣＰＵ１０１は、新規予約処理が完了した通知を受信する。

そして、ステップＳ４２８において、予約管理サーバ１００のＣＰＵ１０１は予約番号、ユーザＩＤ、予約センターＩＤ、予約センター予約番号、予約内容、サービス開始エリア、サービス開始位置データ、サービス終了エリア、サービス終了位置データ、予約開始日時、予約終了日時を予約ＤＢ１０５にセットする。

さらに、ステップＳ４２９において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ４２０で取得した一連の予約情報のなかの予約番号をキーにして、予約変更条件ＤＢ１０６から一連の予約の変更条件を取得する。

そして、ステップＳ４３０において、予約管理サーバ１００のＣＰＵ１０１は、既存の予約とその変更条件の一覧情報、およびユーザが選択した新規予約の予約変更条件の設定要求を、携帯端末２０１に送信する。

すると、ステップＳ４３１において、携帯端末２０１のＣＰＵは、予約管理サーバ１００から送信された既存の予約とその変更条件を受信し、図１４の予約変更条件設定画面に、既存の予約とその変更条件を一覧表示する。そして、携帯端末２０１のＣＰＵは、ユーザに新規予約について取り消し可能か否か、時間変更可能か否か、変更許容時間帯、優先度等の予約変更条件の設定の入力を促す。

そして、ステップＳ４３２において、携帯端末２０１のＣＰＵは、ユーザが設定した新規予約に対する予約変更条件を、予約管理サーバ１００に送信する。

すると、ステップＳ４３３において、予約管理サーバ１００のＣＰＵ１０１は、携帯端末２０１から送信された新規予約に対する予約変更条件を受信する。

そして、ステップＳ４３４において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ４３３で受信した予約変更条件（取り消し、時間変更、変更許容時間、優先度）を、予約変更条件ＤＢ１０６にセットする。

さらに、ステップＳ４３５において、予約管理サーバ１００のＣＰＵ１０１は、予約完了通知を携帯端末２０１に送信する。なお、この予約完了通知には、該当するユーザが予約しているサービスの一覧情報を含むものとする。

すると、ステップＳ４３６において、携帯端末２０１のＣＰＵは、予約管理サーバ１００から送信された予約完了通知を受信し、図１３の予約一覧表示画面にて表示する。

そして、ステップＳ４３７において、ユーザが決定ボタン１３０１を押下すると、携帯端末２０１のＣＰＵは、予約完了の確認を予約管理サーバ１００に通知する。

すると、ステップＳ４３８において予約管理サーバ１００は、携帯端末２０１から送信された予約完了の確認を受信し、本フローチャートの予約処理を終了する。

また、上述したステップＳ４２２で、予約管理サーバ１００のＣＰＵ１０１が、ユーザが選択したサービスが遂行可能でないと判定した場合には、ステップＳ４３９に処理を進める。

ステップＳ４３９において、予約管理サーバ１００のＣＰＵ１０１は、ユーザが選択した新規予約サービスの変更またはキャンセルの要求を携帯端末２０１に送信する。

すると、ステップＳ４４０において、携帯端末２０１のＣＰＵは、予約管理サーバ１００から送信された予約変更またはキャンセルの要求を受信し、図１２の予約変更／キャンセル画面を表示する。

そして、ユーザが決定ボタン１３０１を指示した場合には、ステップＳ４４１において、携帯端末２０１のＣＰＵは、ユーザが変更する処理を選択したか否かを判定する。そして、ユーザが変更する処理を選択したと判定した場合には、ステップＳ４４２に処理を進める。

そして、ステップＳ４４２において、携帯端末２０１のＣＰＵは、予約変更要求を予約管理サーバ１００に送信する。

すると、ステップＳ４４３において、予約管理サーバ１００のＣＰＵ１０１は、携帯端末２０１から送信された予約変更要求を受信する。そして、ステップＳ４４４において、予約管理サーバ１００のＣＰＵ１０１は、ユーザが選択した予約をサービス検索結果一覧から削除し、ステップＳ４０７に処理を戻す。

一方、ステップＳ４４１において、携帯端末２０１のＣＰＵが、ユーザが変更する処理を選択しなかった（キャンセルを選択した）と判定した場合には、ステップＳ４４５に処理を進める。

そして、ステップＳ４４５において、携帯端末２０１のＣＰＵは、キャンセル要求を予約管理サーバ１００に送信する。

すると、ステップＳ４４６において、予約管理サーバ１００のＣＰＵ１０１は、携帯端末２０１から送信されたキャンセル要求を受信し、本フローチャートの予約処理を終了する。

＜遅延監視処理＞
以下、図２１を参照して、本発明の予約自動変更システムにおける遅延監視処理について説明する。

図２１は、本発明の自動予約変更システムにおける第２の制御処理手順の一例を示すフローチャートであり、本発明の予約自動変更システムにおける遅延監視処理に対応する。なお、Ｓ５０１〜Ｓ５１２は各ステップを示す。

また、予約管理サーバ１００側の処理は、予約管理サーバ１００のＣＰＵ１０１が、外部メモリ１０４に格納されるプログラムをＲＡＭ１０２上に読み出して実行することにより実現される。また、位置情報管理サーバ６００側の処理は、位置情報管理サーバ６００のＣＰＵが、外部メモリに格納されるプログラムをＲＡＭ上に読み出して実行することにより実現される。

まず、ステップＳ５０１〜Ｓ５１０で、予約管理サーバ１００のＣＰＵ１０１は、ユーザの現在位置を取得し、次の予約が実行可能かどうか判断しているが、この処理は随時行われている。以下、詳細に示す。

まず、ステップＳ５０１において、予約管理サーバ１００のＣＰＵ１０１は、予約ＤＢ１０５にアクセスし、ユーザの監視が必要な既存予約があるか確認する。監視が必要な既存予約がなければ、予約管理サーバ１００のＣＰＵ１０１は、監視を終了する。

一方、ステップＳ５０１で、予約管理サーバ１００のＣＰＵ１０１が、ユーザの監視が必要な既存予約があると判定した場合には、ステップＳ５０２に処理を進める。

次に、ステップＳ５０２において、予約管理サーバ１００のＣＰＵ１０１は、監視対象の予約の開始時間までの時間が、一定時間経過しているか確認する。まだ一定時間経過していないと判定した場合には、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ５０１に処理を戻し、予約の開始時間までが指定した時間となったときに再開する。

一方、ステップＳ５０２で、予約管理サーバ１００のＣＰＵ１０１が、監視対象の予約の開始時間までの時間が一定時間経過していると判定した場合には、ステップＳ５０３に処理を進める。

そして、ステップＳ５０３において、予約管理サーバ１００のＣＰＵ１０１は、通信ネットワーク３００にアクセスし、ユーザの現在位置のエリア情報を取得する。

そして、ステップＳ５０４において、予約管理サーバ１００のＣＰＵ１０１は、位置情報管理サーバ６００にユーザの現在位置のエリア情報およびそのエリア情報に対応した位置データの取得要求を送信する。

すると、ステップＳ５０５において、位置情報管理サーバ６００のＣＰＵは、予約管理サーバ１００から位置データの取得要求（エリア情報を含む）を受信し、該受信したエリア情報を位置座標にマッピングしたデータを位置情報ＤＢ６０１から取得する。

そして、ステップＳ５０６において、位置情報管理サーバ６００のＣＰＵは、位置データを予約管理サーバ１００に送信する。

すると、ステップＳ５０７において、予約管理サーバ１００のＣＰＵ１０１は、位置情報管理サーバ６００から送信されたユーザの現在の位置データを取得する。

そして、ステップＳ５０８において、予約管理サーバ１００のＣＰＵ１０１は、予約ＤＢ１０５からユーザが次に実行する予定の予約データ（予約ａとする）のサービス開始位置データ１００６および予約開始日時１００９を取得する。

そして、ステップＳ５０９において、予約管理サーバ１００のＣＰＵ１０１はユーザの現在位置データ、サービス開始位置データ、予約開始日時、移動手段およびその速度を用いて、予約ａの予約開始日時までにユーザが到着可能か計算する。なお、移動手段については、顧客ＤＢ１０７に登録されている、当該ユーザの移動手段から、予約管理サーバ１００のＣＰＵ１０１が、経路に最適なものを自動的に選択する。ここで、移動手段およびその速度はあらかじめユーザが指定していてもよいし、予約管理サーバ１００が経路に最適な移動手段と平均的な速度を割り出してもよい。

次に、ステップＳ５１０において、予約管理サーバ１００のＣＰＵ１０１は、予約の変更が必要か否かを判定する。なお、ステップＳ５０９の計算結果でサービス開始位置に予約開始日時迄に到達不可能と計算され、予約ａに遅延が発生することが判明した場合、予約管理サーバ１００のＣＰＵ１０１は、予約の変更が必要であると判定する。

そして、ステップＳ５１０で、予約管理サーバ１００のＣＰＵ１０１は、予約の変更が必要でないと判定した場合には、ステップＳ５０１に処理を戻す。

一方、ステップＳ５１０で、予約管理サーバ１００のＣＰＵ１０１は、予約の変更が必要であると判定した場合には、ステップＳ５１１に処理を進める。

次に、ステップＳ５１１において、予約管理サーバ１００のＣＰＵ１０１は、予約ａの予約番号をキーに、予約変更条件ＤＢ１０６にアクセスし、設定された予約変更条件を取得する。

本実施例では、ユーザが予約を遂行できるかどうかを、図２１で示すように、本発明の自動予約変更システムが予約情報を監視し、予約サービスに間に合うかを判断している。

なお、本実施例とは別に、到着が遅れる場合の判断をユーザが行い、本発明のシステムに指示する方法もある。ユーザの判断には、変更、取消があるが、変更を選択した後は、本実施例におけるステップ５１２へ行き、予約変更条件に基づき、ユーザの最も有利な変更を行うように制御されることは言うまでもない。

いずれにしても、次に、ステップＳ５１２において、予約管理サーバ１００のＣＰＵ１０１は、予約変更条件判定処理（詳細は、図２２〜図２５に示す）を実行し、ステップＳ５０１に処理を戻す。

＜予約変更条件判定処理＞
以下、図２２〜図２５を参照して、図２１のステップＳ５１２の予約変更条件判定処理について説明する。

図２２〜図２４は、本発明の自動予約変更システムシステムにおける第３の制御処理手順の一例を示すフローチャートであり、図２１のステップＳ５１２の予約変更条件判定処理に対応する。なお、Ｓ６０１〜Ｓ６３６は各ステップを示す。

また、予約管理サーバ１００側の処理は、予約管理サーバ１００のＣＰＵ１０１が、外部メモリ１０４に格納されるプログラムをＲＡＭ１０２上に読み出して実行することにより実現される。さらに、サービス予約サーバ４００側の処理は、サービス予約サーバ４００のＣＰＵ１０１が、外部メモリに格納されるプログラムをＲＡＭ上に読み出して実行することにより実現される。

また、図２５は、図２２〜図２４のフローチャートを説明するための予約例を示す図である。

まず、ステップＳ６０１において、予約管理サーバ１００のＣＰＵ１０１は、図２１のステップＳ５１１で取得した変更が発生した予約の予約番号に対する予約変更設定が時間変更可か否かを判定する。そして、時間変更が「不可」と判定した場合には、ステップＳ６０６に処理を進める。ステップＳ６０６以降の処理については後述する。

一方、ステップＳ６０１で、予約管理サーバ１００のＣＰＵ１０１は、時間変更が「可」と判定した場合には、ステップＳ６０２に処理を進める。

そして、ステップＳ６０２において、予約管理サーバ１００のＣＰＵ１０１は、ユーザが設定した予約変更条件ＤＢ１０６にアクセスし、予約番号をキーとして変更許容時間帯１１０３を取得する。そして、取得した変更許容時間帯に、変更する予約と同様のサービスの予約に空きがあるかチェックする。このとき、予約管理サーバ１００のＣＰＵ１０１は、サービス予約サーバ４００に空きチェック要求を送信し、サービス予約サーバ４００はサービス情報ＤＢ４０１やサービス予約情報ＤＢ４０２にアクセスし、指定されたサービスに空きがあるかチェックする。空きがある場合は、そのサービス情報を取得する。

次に、ステップＳ６０３において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ６０２のサービス空き調査結果から、空きサービスがあるか否かを判定し、空きサービスがないと判定した場合には、ステップＳ６０６に処理を進める。

一方、ステップＳ６０３で、予約管理サーバ１００のＣＰＵ１０１は、空きサービスがあると判定した場合には、ステップＳ６０４に処理を進める。

そして、ステップＳ６０４において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ６０２で取得した空きサービス（「代替予約(1)」と呼ぶ）の中に、ユーザの既存の予約と衝突しないサービスがあるかチェックする（図２５参照）。衝突のチェックでは、変更が発生した予約以降に開始する予約があるか確認し、ある場合は以降の予約と「代替予約(1)」の予約時間が重ならないことをチェックする。以降、この処理を衝突チェックと呼ぶ。

そして、ステップＳ６０４で、予約管理サーバ１００のＣＰＵ１０１は、衝突しないサービスがあると判定した場合には、ステップＳ６１２に処理を進める。ステップＳ６１２以降の処理については後述する。

一方、ステップＳ６０４で、予約管理サーバ１００のＣＰＵ１０１は、衝突しないサービスがないと判定した場合には、ステップＳ６０５に処理を進める。

そして、ステップＳ６０５において、予約管理サーバ１００のＣＰＵ１０１は、代替予約と衝突した既存予約で時間変更可の設定のものがあるかチェックする（図２５参照）。このとき、時間変更可の既存予約があると判定した場合には、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ６１６に処理を進める。なお、ステップＳ６１６以降の処理については後述する。

一方、ステップＳ６０５で、代替予約と衝突した既存予約で時間変更可のものがないと判定した場合には、ステップＳ６２７に処理を進める。なお、ステップＳ６２７以降の処理については後述する。

ここで、ステップＳ６０６以降の処理について説明する。

ステップＳ６０６において、予約管理サーバ１００のＣＰＵ１０１は、変更発生した予約の設定が、取り消し可かチェックする。そして、取り消し不可と判定した場合には、ステップＳ６０７に処理を進め、ユーザ操作による予約変更処理（図２８〜図３１）を実行し、図２１のステップＳ５０１に処理を進める。

一方、ステップＳ６０６で、予約管理サーバ１００のＣＰＵ１０１は、変更発生した予約の設定が取り消し可と判定した場合には、ステップＳ６０８に処理を進める。

そして、ステップＳ６０８において、予約管理サーバ１００のＣＰＵ１０１は、変更発生した予約のキャンセル処理の実行要求を、サービス予約サーバ４００に送信する。

すると、ステップＳ６０９において、サービス予約サーバ４００のＣＰＵは、予約管理サーバ１００から予約のキャンセルの実行要求（予約番号を含む）を受信し、該キャンセルする予約の予約番号に対して、予約キャンセル処理（図２６）を実行し、キャンセル処理の完了通知を予約管理サーバ１００に送信する。

すると、ステップＳ６１０において、予約管理サーバ１００のＣＰＵ１０１は、サービス予約サーバ４００より送信されたキャンセル処理の完了通知を受信する。そして、ステップＳ６１１において、予約管理サーバ１００のＣＰＵ１０１は、変更発生した予約のキャンセルを行った旨をユーザの携帯端末２０１に送信し、図２１のステップＳ５０１へ処理を戻す。なお、ユーザの携帯端末２０１は、この通知を受信して、図１５の予約変更通知画面を表示する。

ここで、ステップＳ６１２以降の処理について説明する。

ステップＳ６１２において、予約管理サーバ１００のＣＰＵ１０１は、変更発生した予約を、衝突しない「代替予約(1)」に変更する変更要求をサービス予約サーバ４００に送信する。

すると、ステップＳ６１３において、サービス予約サーバ４００のＣＰＵは、予約管理サーバ１００から送信された変更発生した予約を衝突しない代替予約(1)に変更する変更要求を受信し、予約変更処理（図２７）を実行する。

そして、ステップＳ６１５において、予約管理サーバ１００のＣＰＵ１０１は、変更発生予約から代替予約(1)へ変更した旨をユーザの携帯端末に送信し、図２１のステップＳ５０１へ処理を戻す。なお、ユーザの携帯端末２０１は、この通知を受信して、図１５の予約変更通知画面を表示する。

ここで、ステップＳ６１６以降の処理について説明する。

ステップＳ６１６において、予約管理サーバ１００のＣＰＵ１０１は、「代替予約(1)」の中で、衝突した既存予約が時間変更可だったものを、「変更候補代替予約」とする（図２５参照）。

そして、ステップＳ６１７において、予約管理サーバ１００のＣＰＵ１０１は、時間変更可の既存予約のサービス空き調査を行う。手順はステップＳ６０２と同様である。

そして、ステップＳ６１８において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ６１７のサービス空き調査結果から、空きサービスがあるか否かを判定する。そして、空きサービスがないと判定した場合には、ステップＳ６２７へ処理を進める。なお、ステップＳ６２７以降の処理は後述する。

一方、ステップＳ６１８で、予約管理サーバ１００のＣＰＵ１０１は、時間変更可の既存予約の空きサービスがあると判定した場合には、ステップＳ６１９に処理を進める。

そして、ステップＳ６１９において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ６１８で取得した空きサービス（「代替予約(2)」と呼ぶ）の中に、既存予約と「変更候補代替予約」のいずれとも衝突しないものがあるかチェックする。そして、衝突しないものがないと判定した場合には、ステップＳ６２７へ処理を進める（図２５参照）。

一方、ステップＳ６１９で、予約管理サーバ１００のＣＰＵ１０１は、既存予約と「変更候補代替予約」のいずれとも衝突しない「代替予約(2)」があると判定した場合には、ステップＳ６２０に処理を進める。

そして、ステップＳ６２０において、予約管理サーバ１００のＣＰＵ１０１は、変更が必要な予約を、「変更候補代替予約」の中で元の予約に時間帯が最も近いものに予約変更する要求（図２５参照）、およびキャンセルする予約（変更が必要な予約）の予約番号と変更先の新規予約のサービス番号を、サービス予約サーバ４００に送信する。

すると、ステップＳ６２１において、サービス予約サーバ４００のＣＰＵは、予約管理サーバ１００から送信された要求（キャンセルする予約の予約番号，変更先の新規予約のサービス番号）を受信し、予約変更処理（図２７）を実行する。

そして、ステップＳ６２３において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ６２２で変更した「代替予約(1)」と衝突する既存予約を、「代替予約(2)」の中で元の予約に時間帯が最も近いものに変更する要求、およびキャンセルする既存予約の予約番号と変更先の新規予約のサービス番号を、サービス予約サーバ４００に送信する（図２５参照）。

すると、ステップＳ６２４において、サービス予約サーバ４００のＣＰＵは、予約管理サーバ１００から送信された要求（キャンセルする予約の予約番号，変更先の新規予約のサービス番号）を受信し、予約変更処理（図２７）を実行する。

そして、ステップＳ６２６において、予約管理サーバ１００のＣＰＵ１０１は、予約を変更した旨をユーザの携帯端末２０１に送信し、図２１のステップＳ５０１へ処理を戻す。なお、ユーザの携帯端末２０１は、この通知を受信して、図１５の予約変更通知画面を表示する。

ここで、ステップＳ６２７以降の処理について説明する。

ステップＳ６２７において、予約管理サーバ１００のＣＰＵ１０１は、予約変更条件ＤＢ１０６にアクセスし、「代替予約(1)」と衝突した既存予約の予約番号をキーにして優先度の設定を取得する。

ステップＳ６２８において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ６２７で取得した優先度の中で優先度が「１」（取り消し不可）以外の予約があるか確認する。優先度が「１」以外の既存予約がない場合は、すべて「取り消し不可」ということであり、このときはステップＳ６２９へ処理を進め、ユーザ操作による予約変更処理（図２８〜図３１）を実行し、図２１のステップＳ５０１へ処理を戻す。

一方、ステップＳ６２８で、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ６２７で取得した優先度の中で優先度が「１」（取り消し不可）以外の予約があると判定した場合には、ステップＳ６３０に処理を進める。

そして、ステップＳ６３０において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ６２７で取得した優先度が最も低い既存予約の予約番号、および予約キャンセル要求を、サービス予約サーバ４００に送信する。

すると、ステップＳ６３１において、サービス予約サーバ４００のＣＰＵは、予約管理サーバ１００から送信されたキャンセル要求（優先度が最も低い既存予約の予約番号）を受信し、予約キャンセル処理（図２６）を実行する。

そして、ステップＳ６３３において、予約管理サーバ１００のＣＰＵ１０１は、遅延が予測された既存予約を、ステップＳ６３１でキャンセルした予約と衝突していた「代替予約(1)」に変更する要求を、サービス予約サーバ４００に送信する。このとき、遅延予測された既存予約の予約番号と、「代替予約(1)」のサービス番号も送信する。

すると、ステップＳ６３４において、サービス予約サーバ４００のＣＰＵは、予約管理サーバ１００から送信された要求（遅延予測された既存予約の予約番号と、「代替予約(1)」のサービス番号）を受信し、予約変更処理（図２７）を実行する。

そして、ステップＳ６３６において、予約管理サーバ１００のＣＰＵ１０１は、予約変更結果をユーザ携帯端末２０１に通知し、図２１のステップＳ５０１に処理を戻す。なお、ユーザの携帯端末２０１は、この通知を受信して、図１５の予約変更通知画面を表示する。

＜予約キャンセル処理＞
以下、図２６を参照して、図２２〜図２４のステップＳ６０９，Ｓ６３１の予約キャンセル処理について説明する。

図２６は、本発明の自動予約変更システムシステムにおける第４の制御処理手順の一例を示すフローチャートであり、図２２〜図２４のステップＳ６０９，Ｓ６３１の予約キャンセル処理に対応する。なお、Ｓ７０１〜Ｓ７０６は各ステップを示す。

なお、本予約キャンセル処理は、予約をキャンセルするときに実行されるフローチャートの一部である。本フローチャートは、予約管理サーバ１００がサービス予約サーバ４００にアクセスし、対象となる予約をキャンセルする一連の処理を示す。

まず、ステップＳ７０１において、サービス予約サーバ４００のＣＰＵは、予約管理サーバ１００から送信される、予約キャンセル要求と、サービス予約ＤＢ４０１が保持するキャンセルする予約の予約番号を受信する。

そして、ステップＳ７０２において、サービス予約サーバ４００のＣＰＵは、サービス予約ＤＢ４０１にアクセスし、予約番号をキーとしてキャンセルする予約を検索する。そして、ヒットしたキャンセルする予約のデータをサービス予約ＤＢから削除する。

次に、ステップＳ７０３において、サービス予約サーバ４００のＣＰＵは、予約のキャンセル処理が完了した旨を予約管理サーバ１００に通知する。

すると、ステップＳ７０４において、予約管理サーバ１００のＣＰＵ１０１は、サービス予約サーバ４００が送信した予約のキャンセル処理が完了した通知を受信する。

そして、ステップＳ７０５において、予約管理サーバ１００のＣＰＵ１０１は、予約ＤＢ１０５にアクセスし、予約番号をキーとして予約情報を検索する。そして、ヒットした予約情報を予約ＤＢ１０５から削除する。

そして、ステップＳ７０６において、予約管理サーバ１００のＣＰＵ１０１は、予約変更条件ＤＢ１０６にアクセスし、予約番号をキーとして予約変更条件情報を検索する。そして、ヒットした予約変更条件情報を予約変更条件ＤＢ１０６から削除する。そして、本フローチャートの処理を終了する。

＜予約変更処理＞
以下、図２７を参照して、図２２〜図２４のステップＳ６１３，６２１，Ｓ６２４，Ｓ６３４の予約変更処理について説明する。

図２７は、本発明の自動予約変更システムシステムにおける第５の制御処理手順の一例を示すフローチャートであり、図２２〜図２４のステップＳ６１３，６２１，Ｓ６２４，Ｓ６３４の予約変更処理に対応する。なお、Ｓ８０１〜Ｓ８０６は各ステップを示す。

なお、本予約変更処理は、予約を変更するときに実行されるフローチャートの一部である。本フローチャートは、予約管理サーバ１００がサービス予約サーバ４００にアクセスし、対象となる既存予約をキャンセルし、代替となる新規のサービスを予約する一連の処理を示す。

まず、ステップＳ８０１において、サービス予約サーバ４００のＣＰＵは、サービス予約サーバ４００から送信される、予約変更要求と、サービス予約情報ＤＢ４０２が保持する変更前の予約の予約番号１５００およびユーザＩＤ、変更後のサービス番号、予約開始日時を受信する。

そして、ステップＳ８０２において、サービス予約サーバ４００のＣＰＵは、ステップＳ８０１で受信したユーザＩＤ１５０１、変更後のサービス番号１５０２、予約開始日時１５０３および予約受付日時１５０４を、サービス予約情報ＤＢ４０２に追加登録し、新規予約を行う。

そして、ステップＳ８０３において、サービス予約サーバ４００は、サービス予約情報ＤＢ４０２にアクセスし、予約番号１５００をキーとしてキャンセルする予約データを検索する。そして、ヒットした予約データをサービス予約情報ＤＢ４０２から削除する。

さらに、ステップＳ８０４においてサービス予約サーバ４００のＣＰＵは、予約の変更処理が完了した旨を予約管理サーバ１００に通知する。

すると、ステップＳ８０５において、予約管理サーバ１００のＣＰＵ１０１は、サービス予約サーバ４００から送信される、予約の変更処理が完了した通知を受信する。

そして、ステップＳ８０６において、予約管理サーバ１００のＣＰＵ１０１は、予約ＤＢ１０５にアクセスし、変更前の予約番号をキーとして予約情報を検索する。そして、ヒットした予約情報を、変更する新規サービスの情報に書き換える。なお、ここで、新規サービスの情報は、ステップＳ８０１で、予約管理サーバ１００からサービス予約サーバ４００に送信した情報であり、予約管理サーバ１００のＣＰＵ１０１はＲＡＭ１０２上に保持している。

＜ユーザ操作による予約変更処理＞
以下、図２８〜図３１を参照して、図２２〜図２４のステップＳ６０７，６２９のユーザ操作による予約変更処理について説明する。

図２８〜図３１は、本発明の自動予約変更システムシステムにおける第６の制御処理手順の一例を示すフローチャートであり、図２２〜図２４のステップＳ６０７，６２９のユーザ操作による予約変更処理に対応する。なお、Ｓ１０１１〜Ｓ１０４１は各ステップを示す。

なお、携帯端末２０１側の処理は、携帯端末２０１のＣＰＵがＲＯＭ等に格納されるプログラムを実行することにより実現される。また、予約管理サーバ１００側の処理は、予約管理サーバ１００のＣＰＵ１０１が、外部メモリ１０４に格納されるプログラムをＲＡＭ１０２上に読み出して実行することにより実現される。さらに、サービス予約サーバ４００側の処理は、サービス予約サーバ４００のＣＰＵ１０１が、外部メモリに格納されるプログラムをＲＡＭ上に読み出して実行することにより実現される。

まず、ステップＳ１０１１において、予約管理サーバ１００のＣＰＵ１０１は、予約変更発生の通知と予約変更が発生した予約情報を、ユーザの携帯端末２０１に送信する。

すると、ステップＳ１０１２において、ユーザ携帯端末２０１のＣＰＵは、予約変更発生の通知を受信する。

そして、ステップＳ１０１３において、ユーザ携帯端末２０１のＣＰＵは、表示部に図１１の予約遅延通知画面を表示し、遅延に対する対処を「変更またはキャンセルする」または「遅延を通知する」または「何もしない」からユーザに選択させる。

次に、ステップＳ１０１４において、ユーザ携帯端末２０１のＣＰＵは、ステップＳ１０１３でユーザが選択した結果を、予約管理サーバ１００に送信する。

すると、ステップＳ１０１５において、予約管理サーバ１００のＣＰＵ１０１は、携帯端末２０１から送信される、ユーザが選択した遅延に対する対処を受信する。さらに、ステップＳ１０１６において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ１０１５で取得した選択結果を判定する。

そして、ステップＳ１０１６で、ユーザの選択結果が「何もしない」であると判定した場合には、予約管理サーバ１００のＣＰＵ１０１は、そのまま処理を終了させる。

また、ステップＳ１０１６で、ユーザの選択結果が「変更またはキャンセルする」であると判定した場合には、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ１０２０に処理を進める。なお、ステップＳ１０２０以降の処理については後述する。

また、ステップＳ１０１６で、ユーザの選択結果が「遅延を通知する」であると判定した場合には、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ１０１７に処理を進める。

そして、ステップＳ１０１７において、予約管理サーバ１００のＣＰＵ１０１は、ユーザが予約しているサービスの開始時刻までに到着できない可能性があることをサービス予約サーバ４００に通知する。

すると、ステップＳ１０１８において、サービス予約サーバ４００のＣＰＵは、予約管理サーバ１００から送信された、遅延通知を受信する。そして、サービス予約サーバ４００のＣＰＵは、遅延通知を正常に受信したことを、予約管理サーバ１００に通知する。

すると、ステップＳ１０１９において、予約管理サーバ１００のＣＰＵ１０１は、サービス予約サーバ４００からの通知を受信し、遅延通知がサービス予約サーバ４００に正常に送信できたことを確認できたら、遅延通知を完了として本フローチャートを終了する。

ここで、ステップＳ１０２０以降の処理について説明する。

ステップＳ１０２０において、予約管理サーバ１００のＣＰＵ１０１は、サービス予約サーバ４００に空きチェック要求を送信し、サービス予約サーバ４００はサービス情報ＤＢ４０１やサービス予約情報ＤＢ４０２にアクセスし、他の時間帯で指定されたサービスに空きがあるかチェックする。空きがある場合は、そのサービス情報を取得する。

次に、ステップＳ１０２１において、ＣＰＵ１０１は、ステップＳ１０２０のサービスの空き調査結果を判定し空きサービスがなかったと判定した場合には、ステップＳ１０２２において、予約管理サーバ１００のＣＰＵ１０１は、空きサービスがなかった旨および「他のサービスを探す」または「キャンセルする」から処理を選択する要求を、ユーザ携帯端末２０１に送信する。

一方、ステップＳ１０２１で、予約管理サーバ１００のＣＰＵ１０１が、ステップＳ１０２０のサービスの空き調査結果、空きサービスがあったと判定した場合には、ステップＳ１０２３へ処理を進める。

そして、ステップＳ１０２３において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ１０２０で検索した空きサービス情報（「代替予約(1)」と呼ぶ）とユーザの既存予約衝突チェックを行う。ここで、衝突するサービスがひとつでも存在したと判定した場合には、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ１０２４へ処理を進める。

そして、ステップＳ１０２４において、予約管理サーバ１００のＣＰＵ１０１は、ステップＳ１０２３で既存予約と予約時間が衝突すると判定された「代替予約(1)」に対して、衝突していることを示すフラグを「ＯＮ」にし、ＲＡＭ１０２上に記憶しておく。そして、ステップＳ１０２５へ処理を進める。

一方、衝突するサービスがひとつもなかったと判定した場合には、予約管理サーバ１００のＣＰＵ１０１は、そのままステップＳ１０２５へ処理を進める。

次に、ステップＳ１０２５において、予約管理サーバ１００のＣＰＵ１０１は、ユーザ携帯端末２０１に「代替予約に変更する」または「他のサービスを探す」または「キャンセルする」からユーザに選択させる要求を送信する。また、このときステップＳ１０２１で取得した空きサービス情報およびステップＳ１０２４で取得した衝突予約情報も送信する。

すると、ステップＳ１０２６において、ユーザ携帯端末２０１のＣＰＵは、「他のサービスを探す」または「キャンセルする」のいずれかを選択する要求および、衝突予約情報を受信する。

そして、ユーザ携帯端末２０１のＣＰＵは、図１２の予約変更／キャンセル画面を表示部に表示し、代替予約情報の一覧、「他のサービスを探す」、「キャンセルする」から予約変更処理をユーザに選択させる。

ステップＳ１０２７において、ユーザ携帯端末２０１のＣＰＵは、ユーザ選択結果を判定し、ユーザにより「別のサービスを探す」が選択されたと判定した場合には、ステップＳ１０２８へ処理を進める。なお、ステップＳ１０２８以降の処理については後述する。

また、ステップＳ１０２７で、ユーザ携帯端末２０１のＣＰＵが、ユーザにより「キャンセルする」が選択されたと判定した場合には、ステップＳ１０３５へ処理を進める。なお、ステップＳ１０３５以降の処理については後述する。

また、ステップＳ１０２７で、ユーザ携帯端末２０１のＣＰＵが、ユーザにより、代替予約のいずれかが選択されたと判定した場合には、ステップＳ１０２９へ処理を進める。

そして、ステップＳ１０２９において、ユーザ携帯端末２０１のＣＰＵは、遅延が予測された予約からユーザが選択した代替予約へ予約を変更する要求を予約管理サーバ１００へ送信する。

すると、ステップＳ１０３０において、予約管理サーバ１００のＣＰＵ１０１は、携帯端末２０１から送信された、新たに予約する代替予約のサービス番号および予約変更要求を受信し、サービス予約サーバ４００に転送する。

すると、サービス予約サーバ４００は、ステップＳ１０３１において、新たに予約する代替予約のサービス番号および予約変更要求を受信し、予約変更処理（図２７）を実行する。

そして、ステップＳ１０３２において、予約管理サーバ１００のＣＰＵ１０１は、サービス予約サーバ４００から予約変更処理の完了通知を受信する。そして、ステップＳ１０３３において、予約管理サーバ１００のＣＰＵ１０１は、予約変更の完了通知をユーザ携帯端末２０１に送信する。

すると、ステップＳ１０３４において、ユーザ携帯端末２０１のＣＰＵは、予約管理サーバ１００から予約の変更が完了した通知を受信し、図１５の予約変更通知画面を表示部に表示し、処理を終了する。

ここで、ステップＳ１０３５以降の処理について説明する。

ステップＳ１０３５において、ユーザ携帯端末２０１のＣＰＵは、遅延が予測された予約をキャンセルする要求を、予約管理サーバ１００に送信する。

すると、ステップＳ１０３６において、予約管理サーバ１００のＣＰＵ１０１は、遅延が予測された予約をキャンセルする要求を受信し、ステップＳ１０３７において、該受信した遅延が予測された予約をキャンセルする要求を、サービス予約サーバ４００に転送する。

すると、ステップＳ１０３８において、サービス予約サーバ４００は、遅延が予測された予約をキャンセルする要求を受信し、予約キャンセル処理（図２６）を実行する。

そして、ステップＳ１０３９において、予約管理サーバ１００のＣＰＵ１０１は、サービス予約サーバ４００から予約キャンセル処理が完了した通知を受信する。そして、ステップＳ１０４０において、予約管理サーバ１００のＣＰＵ１０１は、予約キャンセル処理が完了した通知を、ユーザ携帯端末２０１に送信する。

すると、ステップＳ１０４１において、ユーザ携帯端末２０１のＣＰＵは、予約管理サーバ１００から予約キャンセル処理が完了した通知を受信し、予約キャンセルした旨を表示部に表示し、本フローチャートの処理を終了する。

以上の処理により、予約内容が遂行可否を監視し、予約が遂行不可能となった場合、自動的に予約を変更するとともに、該変更が影響するその他の複数の予約内容が遂行可能かも判断し、遂行不可能であった場合は、該複数の予約内容の変更、もしくは取り消しを、ユーザの手間を省き、自動で行うことが可能となる。

従って、予約を実行できなくなった場合でも、ユーザが複数の予約を逐次、ずらしていく等の特別且つ煩雑な操作を必要とせずに、実用的且つユーザフレンドリな予約環境を構築することができる。

〔第２実施形態〕
上記第１実施形態では、予約管理サーバが、予約変更条件ＤＢに基づいて予約を自動的に変更する構成について説明したが、ユーザの操作に基づいて予約を変更するように構成してもよい。以下、その実施形態について説明する。

＜遅延監視処理＞
以下、図３２を参照して、本発明の第２実施形態の予約自動変更システムにおける遅延監視処理について説明する。

図３２は、本発明の自動予約変更システムシステムにおける第７の制御処理手順の一例を示すフローチャートであり、本発明の第２実施形態の予約自動変更システムにおける遅延監視処理に対応する。なお、Ｓ１１０１〜Ｓ１１１１は各ステップを示す。

まず、ステップＳ１１０１〜Ｓ１１１０は、上記第１実施形態で示した図２１のステップＳ５０１〜Ｓ５１０の処理と同一の処理であり、説明は省略する。

ステップＳ１１１０で、予約管理サーバ１００のＣＰＵ１０１が、予約の変更が必要でると判定した場合には、ステップＳ１１１１において、予約管理サーバ１００のＣＰＵ１０１は、ユーザ操作による予約変更処理（図２８〜図３１）を実行し、処理を終了する。

以上示したように、予約内容に変更の必要が発生した場合でも、ユーザの特別な操作を必要とせずに、予約開始日時，予約終了日時から、その予約内容の変更で影響するその他の１又は複数の予約内容が遂行可能か判断し、遂行不可能であった場合は、他の１又は複数の予約内容の変更、もしくは取り消しを連動して行うように制御することにより、変更に伴って影響される複数の予約の変更をユーザが行う手間を省くことができる。

従って、時間差で複数の予約を行っていた場合、ひとつ目の予約が遅延等により自動的に変更された際でも、従来のように、それ以降の予約について、ユーザが手動で変更する必要がなく、煩雑な手間を省くことができる。

なお、上述の各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

以下、図３３に示すメモリマップを参照して本発明に係る自動予約変更システムシステムを構成する各情報処理装置（予約管理サーバ１００，端末２００，携帯端末２０１，サービス予約サーバ４００，運行情報管理サーバ５００，位置情報管理サーバ６００）で読み取り可能なデータ処理プログラムの構成について説明する。

図３３は、本発明に係る本発明に係る自動予約変更システムシステムを構成する各情報処理装置（予約管理サーバ１００，端末２００，携帯端末２０１，サービス予約サーバ４００，運行情報管理サーバ５００，位置情報管理サーバ６００）で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図１７〜図２０，図２１，図２２〜図２４，図２６，図２７，図２８〜図３１，図３２に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各種実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

本発明の一実施形態を示す自動予約変更システムの構成の一例を示すシステム構成図である。図１に示した予約管理サーバのハードウェア構成を示すブロック図である。図２に示した予約管理サーバ１の外部メモリに記憶されている予約ＤＢの一例を示す図である。図２に示した予約管理サーバの外部メモリに記憶されている予約変更条件ＤＢの一例を示す図である。図２に示した予約管理サーバの外部メモリに記憶されている顧客ＤＢ１０７の一例を示す図である。図１に示した位置情報管理サーバの外部メモリに記憶されている位置情報ＤＢの一例を示す図である。図１に示したサービス予約サーバの外部メモリに記憶されているサービス情報ＤＢの一例を示す図である。図１に示したサービス予約サーバの外部メモリに記憶されているサービス予約情報ＤＢの一例を示す図である。本発明の予約自動変更装置におけるユーザ情報設定画面を示す模式図である。本発明の予約自動変更装置における予約画面を示す模式図である。本発明の予約自動変更装置における予約遅延通知画面を示す模式図である。本発明の予約自動変更装置における予約変更／キャンセル画面を示す模式図である。本発明の予約自動変更装置における予約一覧表示画面を示す模式図である。本発明の予約自動変更装置における予約変更条件設定画面を示す模式図である。本発明の予約自動変更装置における予約変更通知画面を示す模式図である。本発明の予約開始画面の一例を示す模式図である。本発明の自動予約変更システムシステムにおける第１の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第１の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第１の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第１の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第２の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第３の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第３の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第３の制御処理手順の一例を示すフローチャートである。図２２〜図２４のフローチャートを説明するための予約例を示す図である。本発明の自動予約変更システムシステムにおける第４の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第５の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第６の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第６の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第６の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第６の制御処理手順の一例を示すフローチャートである。本発明の自動予約変更システムシステムにおける第７の制御処理手順の一例を示すフローチャートである。本発明に係る本発明に係る自動予約変更システムシステムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

符号の説明

１００予約管理サーバ
１０１ＣＰＵ
１０２ＲＡＭ
１０３ＲＯＭ
１０４外部メモリ
１０５予約ＤＢ
１０６予約変更条件ＤＢ
１０７顧客ＤＢ
１０８入力装置
１０９表示装置
１１０印刷装置
１１１通信インターフェース
２００端末装置
２０１移動体通信端末装置
３００通信ネットワーク
４００サービス予約サーバ装置
４０１サービス情報ＤＢ
４０２サービス予約情報ＤＢ
５００運行情報管理サーバ
６００位置情報管理サーバ
６０１位置情報ＤＢ

Claims

複数のサービスの予約情報を複数記憶管理する記憶手段と、
前記記憶手段に記憶管理される各予約情報を監視して遂行の可否を判断する監視手段と、
前記監視手段により変更の必要があると判断された予約情報と、該予約情報の変更に基づき、影響される他の１又は複数の予約情報を連動して変更又は取り消し制御する制御手段と、
を有することを特徴とする予約管理装置。
前記記憶手段は、前記各予約情報を変更条件とともに記憶管理するものであり、
前記制御手段は、該予約情報の変更に基づき、影響される他の１又は複数の予約情報を、該予約情報の変更条件に基づいて変更又は取り消し制御することを特徴とする請求項１記載の予約管理装置。
前記変更条件は、優先度を示す情報，変更の可否を示す情報，変更許容時間帯を示す情報，取り消しの可否を示す情報を含むことを特徴とする請求項２記載の予約管理装置。
前記監視手段は、前記各予約情報に基づき、該サービス開始日時までにユーザが到着可能かの推測計算を含むことを特徴とする請求項１記載の予約管理装置。
複数のサービスの予約情報を複数記憶管理する予約管理装置における予約変更方法において、
前記記憶手段に記憶管理される各予約情報を監視して遂行の可否を判断する監視ステップと、
前記監視ステップで変更の必要があると判断された予約情報と、該予約情報の変更に基づき、影響される他の１又は複数の予約情報を連動して変更又は取り消し制御する変更ステップと、
を有することを特徴とする予約変更方法。
請求項１乃至４のいずれかに１項に記載された予約管理装置としてコンピュータを機能させるための、又は、請求項５に記載された予約変更方法をコンピュータに実行させるためのプログラム。
請求項１乃至４のいずれかに１項に記載された予約管理装置としてコンピュータを機能させるための、又は、請求項５に記載された予約変更方法をコンピュータに実行させるためのプログラムをコンピュータが読み取り可能に記憶した記録媒体。