(57)【要約】【課題】ネットワークに接続された予定表上の予定を変更する場合に、予定の変更や代案の検索を容易に行うことが出来る技術を得る。【解決手段】ネットワークに接続して、時刻、場所、予定内容の少なくともいずれかから構成される予定を入力し、時刻、場所、予定内容の少なくともいずれかが変更された場合、入力された予定の一部もしくは全部の情報を用いて検索キーを作成し、該検索キーをネットワーク上の登録したサーバに送信し、変更された予定の代案をネットワーク上のサーバから受信して表示させることができる。【選択図】  図５
2004220135.tif 000002
【特許請求の範囲】
【請求項１】
時刻、場所、予定内容の少なくともいずれかから構成される予定を入力する手段と、時刻、場所、予定内容の少なくともいずれかを変更する手段と、該予定が変更された場合、入力された予定の一部もしくは全部の情報を用いて検索キーを作成する手段と、該検索キーをネットワーク上の登録したサーバに送信する手段と、変更された予定の代案をネットワーク上のサーバから受信して表示する手段とを備えることを特徴とする端末装置。
【請求項２】
請求項１記載の端末装置において、前記予定を変更する手段は、画面に表示されている予定を時間軸方向へ移動させることにより予定を変更することができることを特徴とする端末装置。
【請求項３】
請求項１記載の端末装置において、該検索キーはユーザが入力した予定とユーザ端末に設定されているユーザの個人情報から構成されることを特徴とする端末装置。
【請求項４】
請求項１記載の端末装置において、該検索キーに優先順位を付与することを特徴とする端末装置。
【請求項５】
請求項４記載の端末装置において、該優先順位はユーザが予定を入力した順番を用いることを特徴とする端末装置。
【請求項６】
請求項１記載の端末装置において、該受信した予定の代案を、変更された予定と同一の画面に表示する手段を備えることを特徴とする端末装置。
【請求項７】
ネットワークに接続可能なサーバであって、端末装置から検索キーを受信する手段と、該検索キーに関連する予定の代案を検索する手段と、該検索キーを送信した端末に代案を送信する手段とを備えることを特徴とするサーバ。
【請求項８】
請求項７記載のサーバにおいて、予定の代案の候補を受信し、代案のリストとして保持する手段を備えることを特徴とするサーバ。
【請求項９】
ネットワークに接続可能な端末装置であって、時間に関連する事業の情報を保持する手段と、該事業の情報から予定の代案の候補の情報を抽出し、ネットワーク上のサーバへ送信する手段とを備えることを特徴とする事業者端末装置。
【請求項１０】
予定を入力するステップと、予定を変更するステップと、該変更した予定から検索キーを作成するステップと、該検索キーをネットワーク上のサーバに送信するステップと、該サーバから予定の代案を受信するステップと、受信した予定の代案を表示するステップとを備えることを特徴とする情報受信方法。
【請求項１１】
検索キーを受信するステップと、該検索キーに関連する情報を検索するステップと、該関連する情報を、ネットワークを介して配信するステップとを備えることを特徴とする情報配信方法。
【請求項１２】
請求項１１記載の情報配信方法において、該検索キーに関連する情報を、ネットワークを介した事業者端末装置に要求するステップを備えることを特徴とする情報配信方法。
【請求項１３】
請求項１１記載の情報配信方法において、該検索キーに関連する情報を、ネットワークを介した事業者端末装置から受信するステップと、該受信した情報が検索キーに関連した情報かどうかを判定するステップとを備えることを特徴とする情報配信方法。
【請求項１４】
検索キーに関連する情報の要求を受信するステップと、端末内の状況の情報から検索キーに関連する情報を作成するステップと、該作成した情報をネットワーク上のサーバに送信するステップを備えることを特徴とする情報配信方法。
【請求項１５】
請求項１４記載の情報配信方法において、該端末内の状況の情報が更新されたことにより状況に関する情報を作成するステップと、該作成した情報をネットワーク上のサーバに送信するステップとを備えることを特徴とする情報配信方法。
【請求項１６】
請求項１記載の端末装置において、該予定を入力もしくは変更することにより該入力された予定と他の予定との時間間隔を計測する手段と、該時間間隔が一定値以下である場合に、時間間隔を形成する双方の予定もしくはいずれか一方の予定の時間を変更し、時間間隔を一定値以上にする手段とを備えることを特徴とする端末装置。
【請求項１７】
請求項１６記載の端末装置において、該予定の入力もしくは変更により時間間隔を一定以上にするために変更された予定に設定されている予約に関する情報を、事業者端末装置にネットワークを介して接続して更新する手段を備えることを特徴とする端末装置。
【請求項１８】
請求項１６記載の端末装置において、該予定の入力もしくは変更により時間間隔を一定以上にするために変更された予定の一部もしくは全部の情報を用いて検索キーを作成する手段と、該検索キーをネットワーク上の登録したサーバに送信する手段と、該予定の入力もしくは変更により時間間隔を一定以上にするために変更された予定の代案をネットワーク上のサーバから受信して表示する手段とを備えることを特徴とする端末装置。
【請求項１９】
請求項１６記載の端末装置において、該時間間隔の値として、該入力もしくは変更する予定と該時間間隔を設定する予定の位置情報から２点間の経路探索を行い、得られた時間を用いて該時間間隔の値とする手段を備えることを特徴とする端末装置。
【請求項２０】
請求項１０記載の情報受信方法において、入力もしくは変更した予定と他の入力済みの予定との時間間隔を計算するステップと、該時間間隔が一定値以下である場合に他の入力済みである予定の時間を該時間間隔が一定値以上になるよう変更するステップとを備えることを特徴とする情報受信方法。
【請求項２１】
請求項１０記載の情報受信方法において、入力もしくは変更した予定と他の入力済みの予定との時間間隔を計算するステップと、該時間間隔が一定値以上である時間に対して予定の代案を要求するステップと、該予定の代案を受信して表示するステップとを備えることを特徴とする情報受信方法。
【請求項２２】
請求項７記載のサーバにおいて、端末装置に代案を提供する対価として、代案を受信する該端末装置に課金する手段を備えることを特徴とするサーバ。
【請求項２３】
ユーザが操作する端末と、サービスを提供するサーバと、該サーバに対して情報を提供する事業者の端末と、該ユーザが操作する端末に代案を提供するサービスを提供する該サーバが該事業者の端末に対して対価を支払う手段とを備えることを特徴とする予定代案提供システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は予定代案提供システム及び予定代案提供方法に係り、ネットワークに接続される携帯端末等のユーザ端末、サービスサーバ、事業者端末を用いて、予定の代案に関する情報を検索及び配信する技術に関する。
【０００２】
【従来の技術】
従来から予定を格納する電子予定表が広く使用されている。これらは、紙により構成される手帳の延長線上にある、予定を記入及び保管し、閲覧することを主体としている。
また、近年ではネットワークを介して会議予定の調整を行う機能なども一般的に搭載されている。
また、予定表に対して広告などを配信するサービスも提案されている（特許文献１参照）。
【０００３】
【特許文献１】
特開２００２−３０４３４６号公報
【０００４】
【発明が解決しようとする課題】
予定表上の予定を変更する場合には、ユーザによる代案の検索が必要となる。また、予定が複数存在する場合は、すべての予定を調整する必要がある。
【０００５】
本発明の目的は、かかる従来技術の問題点に鑑み、簡単な操作で所望の予定を検索又は表示することができる技術を提供することにある。
【０００６】
【課題を解決するための手段】
上記目的を達成するために、第１の発明では、端末装置は、時刻、場所、予定内容の少なくともいずれかから構成される予定を入力する手段と、時刻、場所、予定内容の少なくともいずれかを変更する手段と、該予定が変更された場合、入力された予定の一部もしくは全部の情報を用いて検索キーを作成する手段と、該検索キーをネットワーク上の登録したサーバに送信する手段と、変更された予定の代案をネットワーク上のサーバから受信して表示する手段とを備える。
第２の発明では、第１の発明において、前記予定を変更する手段は、画面に表示されている予定を時間軸方向へ移動させることにより予定を変更することができる。
第３の発明では、第１の発明において、該検索キーはユーザが入力した予定とユーザ端末に設定されているユーザの個人情報から構成される。
第４の発明では、第１の発明において、該検索キーに優先順位を付与する。
第５の発明では、第４の発明において、該優先順位はユーザが予定を入力した順番を用いる。
第６の発明では、第１の発明において、該受信した予定の代案を、変更された予定と同一の画面に表示する手段を備える。
【０００７】
第７の発明では、サーバは、ネットワークに接続可能なサーバであって、端末装置から検索キーを受信する手段と、該検索キーに関連する予定の代案を検索する手段と、該検索キーを送信した端末に代案を送信する手段とを備える。
第８の発明では、第７の発明において、予定の代案の候補を受信し、該代案のリストとして保持する手段を備える。
【０００８】
第９の発明では、事業者端末装置は、ネットワークに接続可能な端末装置であって、時間に関連する事業の情報を保持する手段と、該事業の情報から予定の代案の候補の情報を抽出し、ネットワーク上のサーバへ送信する手段とを備える。
【０００９】
第１０の発明では、情報受信方法は、予定を入力するステップと、予定を変更するステップと、該変更した予定から検索キーを作成するステップと、該検索キーをネットワーク上のサーバに送信するステップと、該サーバから予定の代案を受信するステップと、受信した予定の代案を表示するステップとを備える。
【００１０】
第１１の発明では、配信方法は、検索キーを受信するステップと、該検索キーに関連する情報を検索するステップと、該関連する情報を、ネットワークを介して配信するステップとを備える。
第１２の発明では、第１１の発明において、該検索キーに関連する情報を、ネットワークを介した事業者端末装置に要求するステップを備える。
第１３の発明では、第１１の発明において、該検索キーに関連する情報を、ネットワークを介した事業者端末装置から受信するステップと、該受信した情報が検索キーに関連した情報かどうかを判定するステップとを備える。
【００１１】
第１４の発明では、情報配信方法は、検索キーに関連する情報の要求を受信するステップと、端末内の状況の情報から検索キーに関連する情報を作成するステップと、該作成した情報をネットワーク上のサーバに送信するステップを備える。
第１５の発明では、第１４の発明において、該端末内の状況の情報が更新されたことにより状況に関する情報を作成するステップと、該作成した情報をネットワーク上のサーバに送信するステップとを備える。
【００１２】
第１６の発明では、第１の発明において、該予定を入力もしくは変更することにより該入力された予定と他の予定との時間間隔を計測する手段と、該時間間隔が一定値以下である場合に、時間間隔を形成する双方の予定もしくはいずれか一方の予定の時間を変更し、時間間隔を一定値以上にする手段とを備える。
第１７の発明では、第１６の発明において、該予定の入力もしくは変更により時間間隔を一定以上にするために変更された予定に設定されている予約に関する情報を、事業者端末装置にネットワークを介して接続して更新する手段を備える。
第１８の発明では、第１６の発明において、該予定の入力もしくは変更により時間間隔を一定以上にするために変更された予定の一部もしくは全部の情報を用いて検索キーを作成する手段と、該検索キーをネットワーク上の登録したサーバに送信する手段と、該予定の入力もしくは変更により時間間隔を一定以上にするために変更された予定の代案をネットワーク上のサーバから受信して表示する手段とを備える。
第１９の発明では、第１６の発明において、該時間間隔の値として、該入力もしくは変更する予定と該時間間隔を設定する予定の位置情報から２点間の経路探索を行い、得られた時間を用いて該時間間隔の値とする手段を備える。
【００１３】
第２０の発明では、第１０の発明において、入力もしくは変更した予定と他の入力済みの予定との時間間隔を計算するステップと、該時間間隔が一定値以下である場合に他の入力済みである予定の時間を該時間間隔が一定値以上になるよう変更するステップとを備える。
第２１の発明では、第１０の発明において、入力もしくは変更した予定と他の入力済みの予定との時間間隔を計算するステップと、該時間間隔が一定値以上である時間に対して予定の代案を要求するステップと、該予定の代案を受信して表示するステップとを備える。
【００１４】
第２２の発明では、第７の発明において、端末装置に代案を提供する対価として、代案を受信する該端末装置に課金する手段を備える。
【００１５】
第２３の発明では、予定代案提供システムは、ユーザが操作する端末と、サービスを提供するサーバと、該サーバに対して情報を提供する事業者の端末と、該ユーザが操作する端末に代案を提供するサービスを提供する該サーバが該事業者の端末に対して対価を支払う手段とを備える。
【００１６】
【発明の実施の形態】
以下、本発明の実施例の形態につき、実施例を用い、図面を参照して説明する。
なお、本発明において、予定とは時間、場所、予定内容のいずれか１つ以上から構成されるものである。予定内容は、時間、場所以外の一般的にユーザがメモ的に使用する領域の情報を指すが、例えば階層化して分類した情報を用いてもよい。
【００１７】
キー情報とは、サービスサーバのデータベースより所望の予定を検索するときに用いる検索キーを指す。所望の予定とは、キー情報を用いて検索される予定を指す。本発明では、キー情報にはユーザの嗜好と、既に入力してある予定の一部もしくは全部を含む。
操作予定とは、ユーザが入力済みの予定の時間を移動させる時に、移動させる対象である予定を指す。
衝突予定とは、操作予定が移動した際に、時間的に影響を受ける予定を指す。例えば、時間的に重なる場合や、時間的に重ならなくても、操作予定の場所ともう一方の予定の場所間で経路検索を行い、移動に必要な時間を算出し、移動に必要な時間やその他設定した時間などよりもう一方の予定と操作予定との時間間隔が短い場合などは、時間的に影響を受ける。この場合はもう一方の予定が衝突予定である。
【００１８】
以下、図を用いて本発明による予定代案提供システムについて説明する。
図１は本発明による予定代案提供システムの一実施例を示す構成図である。図１において、１００はネットワーク、１０１はユーザ端末、１０２は予定代案提供サービスを行なうサービスサーバ、１０３は事業者端末である。本システムにおいて、ユーザ端末１０１は複数存在するが、事業者端末１０３も複数存在してもよい。
図２は本発明によるユーザ端末の一実施例を示すブロック図である。図において、２０１は装置制御用のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、２０２はＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、またはハードディスクなどから構成され、ユーザの予定や個人情報などを記録する記録部、２０３はタッチパネルやボタン、ダイヤル、マイクロフォンなどから構成される入力部、２０４は予定などを表示したり、音声を発生したりするための出力部、２０５は通信モジュールであり、携帯端末１０１をネットワーク１００に接続するための通信インタフェースを構成する。ユーザ端末１０１は一般的なＰＣやＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、携帯電話などを用いてよい。
【００１９】
図３は本発明によるサービスサーバの一実施例を示すブロック図である。図において、３０１は装置制御用のＣＰＵ、３０２はＲＡＭ、ＲＯＭ、またはハードディスクなどから構成され、ユーザとのサービスの契約情報や、事業者端末１０３のアドレスや事業者端末１０３と接続するためのパスワード、課金情報などを記録する記録部、３０３はキーボードやマウス、マイクロフォンなどから構成される入力部、３０４はサービスサーバを操作する際に画面出力などとして使用する出力部、３０５は通信モジュールであり、サービスサーバ１０２をネットワーク１００に接続するための通信インタフェースを構成する。
【００２０】
図４は本発明による事業者端末の一実施例を示すブロック図である。図において、４０１は装置制御用のＣＰＵ、４０２はＲＡＭ、ＲＯＭ、またはハードディスクなどから構成され、サービスサーバ１０２のアドレスや、サービスサーバに接続するためのパスワード、課金情報などを記録する記録部、４０３はキーボードやマウス、マイクロフォンなどから構成される入力部、４０４は事業者端末１０１を操作する際に画面出力などとして使用する出力部、４０５は通信モジュールであり、ネットワーク１００に接続するための通信インタフェースを構成する。
【００２１】
図５は本発明による予定代案提供サービスの基本フローを示すフローチャートである。ステップ５１１ａ、５１１ｂではユーザ端末１０１はサービスサーバ１０２と代案提供契約を行う。契約を行うとは、例えばユーザ端末１０１のネットワーク上のアドレスを示すＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）やプロファイル、サービスサーバに提供されるサービスの質をサービスサーバに登録し、サービスサーバのＵＲＬやサービスサーバに接続するためのパスワードをユーザ端末１０１に登録する手続きを含む。ユーザ端末１０１のプロファイルとは、ユーザ端末１０１のＩＤ、ユーザ端末１０１のユーザＩＤ、ユーザ端末１０１のユーザ名、ユーザの年齢や性別、住所、電話番号、郵便番号などや、ユーザの嗜好情報などである。サービスサーバ１０２に提供されるサービスの質とはサービスサーバ１０２がユーザ端末１０１に提供する情報の質であるが、情報の量や情報に対しての課金情報を含んでもよい。
ステップ５２１ではユーザがユーザ端末１０１に予定を入力する。この時、予定を入力した順番を入力した予定に関するユーザの入力時嗜好として保存してもよい。例えば、ユーザが時間、場所、予定内容の順で入力した場合は、嗜好が最も高いものから順に時間、場所、予定内容となる。予定に関するユーザの入力時嗜好は、１つの予定に対して予定内容が複数存在する場合にはその入力した順番を用いてもよい。ステップ５３１では、ユーザが予定を変更する。予定を変更するとは時間を変更することや、場所を変更することや、予定の内容を変更することなどである。ユーザが予定を変更した場合は、その変更内容が入力時嗜好が最上位となる。例えば、最初に予定を作成した際には時間を最後に入力した場合、時間の入力時嗜好は最低となるが、時間を変更すると時間の入力時嗜好は最高となる。ステップ５４１ではユーザ端末１０１がキー情報を作成する。キー情報は、入力時嗜好やユーザのプロファイル、予定などから作成される。ステップ５５１ではキー情報をサービスサーバ１０２に送信する。ステップ５５２でサービスサーバ１０２はキー情報を受信する。ステップ５６１ではキー情報を基に、類似代案を検索する。類似代案は予め事業者端末１０３により登録されるか、類似代案検索の開始時に事業者端末１０３に接続して検索する。ステップ５７１では検索した類似代案をユーザ端末１０１に送信し、ステップ５７２でユーザ端末１０１は類似代案を受信する。ステップ５８１ではユーザ端末１０１は類似代案を表示する。
【００２２】
図６はユーザ端末に入力された予定の表示例を示す正面図であり、図５のステップ５２１で入力された予定の例を示す。図において、６０１はユーザ端末である。６１１は１２時から１４時の間の予定であり、予定内容６２１、予定の場所６２２が表示されている。また、場所の地図を表示するボタン６２３が表示されている。６２４は予約済みであることを示す情報である。この予定を検索する際に予約を行い、予約が成立すると、予約済６２４としてその結果が表示される。６２５はクーポンありを示しており、クーポンあり６２５はクーポンがこの予定に付随していることを示している。この予定を検索する際にクーポンが事業者端末１０３などから送付され、そのクーポンの存在を示す表示がクーポンあり６２５でもよい。
【００２３】
図７はユーザ端末に入力された予定を変更する場合の表示例を示す正面図であり、図５のステップ５３１で修正した予定の例である。７０１はユーザ端末である。７１１は修正される前の予定であり、時間は１２時から１４時となっている。７２１はユーザの予定を修正する操作の方向を示す矢印であり、７０１上では表示されない。７１２は修正後の予定であり、時間は１４時から１６時に変更されている。なお、予定７１２では時間が変更されたため、予定７１１では予約済であった表示が未予約と表示されている。ステップ５３１においては自動的に予約時間の変更処理を行ってもよく、もし予約時間の変更が可能であれば７１２の予約の表示は予約済となる。また、予約時間が変更できない場合は、７１２の予約の表示は予約不可能などとしてもよい。
【００２４】
図８はキー情報の一実施例を示すテーブルであり、図５のステップ５４１で作成されたキー情報の例である。本実施例では、開始日８０１、終了日８０２、開始時刻８０３、終了時刻８０４、場所８０５、店名８０６の各項目の情報はユーザが入力した予定から直接取得できる情報である。年齢８１１、性別８１２、嗜好８１３の各項目の情報はユーザがユーザ端末７０１に設定したプロファイルなど個人情報から取得した情報である。また、８２１は開始時間８０１〜嗜好８１３の各内容を示している。８２２は開始時間８０１〜嗜好８１３の各情報において、ユーザにとって優先されるべき情報の順位を示している。例えば、開始時刻８０１の情報は場所８０５よりも優先順位が高いため、まず開始時刻８０１の情報を用いて検索が行われる。終了時刻８０４の情報は本情報の中では優先順位が最も低く、検索の際に用いられる順番は開始時刻８０１〜店名８０６までの中で最後となる。これらの優先順位を作成する方法は、例えばユーザがユーザ端末７０１に入力した順番を記録し用いてもよい。本例では、ユーザは日時を入力し、次に場所、次に開始時刻、次に店名、次に終了時刻を入力している。また、これらの優先順位はユーザが明示的に入力する形式でもよい。
【００２５】
図９は類似代案の検索の手順の一実施例を示すフローチャートであり、ステップ５６１の類似代案の検索の手順を示す。サービスサーバ１０２は、ステップ９０１において、図１２に示すような代案リストがサービスサーバ１０２に保存されているか否かチェックする。サービスサーバ１０２に保存されていない場合は、ステップ９０２で、事業者端末１０３に状況情報を要求する。サービスサーバ１０２は、状況情報を提供できる事業者端末１０３のリストを契約や検索により取得し、保持する。状況情報を提供できる事業者端末１０３とサービスサーバ１０２とは、互いに予め契約を結び状況情報の送受信の手続きと互いのネットワークアドレスなどを交換していてもよい。本フローチャートでは事業者端末１０３は１つであるが、事業者端末が複数存在してもよい。この場合、状況情報の要求ステップ９０２が複数の事業者端末に向けて要求を発信する。次に、ステップ９０３で、事業者端末１０３は状況情報要求を受信する。次に、ステップ９０４で、状況情報を作成する。
状況情報とは、図１１に示すように、事業者が予約受け入れ可能な枠数を示した情報である。また、状況を示す情報として、例えば、図１０に示す状況情報テーブルを用いてもよい。この状況情報テーブルは、予約や空席状況などを管理する端末などでの情報として用いてもよい。これについては、詳細後述する。
【００２６】
次に、図９において、ステップ９０５で、状況情報をサービスサーバ１０２に送信する。ステップ９０６で、サービスサーバ１０２で状況情報を受信すると、ステップ９０７で、代案リストを作成する。状況情報は複数受信する場合があり、その場合は状況情報を元に代案リストを作成する。代案リストの作成とは、状況情報をデータベースで再配列する操作と同等であり、代案リストのキーの順にソートを行ったデータでもよい。代案リストは検索に便利な方法であれば、いかなる形式でもよい。ステップ９０１において、代案リストが存在する場合は、ステップ９１１に移行して、代案リストを検索する。代案リストを用いない場合はステップ９１１をスキップし、ステップ９２１に移行して、検索を完了したか否かをチェックする。即ち、ステップ９１１では、ユーザ端末より受信したキー情報を用いて代案リストから予定を検索する。ステップ９２１では、検索が完了したかどうかをチェックする。検索が完了したとは、代案リストからユーザが設定した個数もしくはサービスサーバ１０２が設定した個数以上の類似代案が検索できた場合などである。ユーザもしくはサービスサーバの設定により、必ずステップ９０２を実行してもよい。検索が未了の場合は、ステップ９０２を実行する。本フローチャートでは、ステップ９２１において検索が未了の場合は事業者端末１０３に状況情報を要求するが、ステップ９０１で状況情報を要求した事業者端末とは異なる事業者端末に状況情報要求を送信してよい。この方式では、例えば、サービスサーバ１０２に存在する代案リストから検索を行い、かつ事業者端末に状況情報を要求することもできる。
【００２７】
図１０は事業者の状況情報の一実施例を示すテーブルであり、事業者端末１０３に保持されている。このテーブルは例えば、１６時１００１〜２２時１００７の時間、最大収容数１０１１、現在予約数１０１２、フリー数１０１３及び予約枠数１０１４が表示される。ステップ９０４においては、このテーブルに示されている事業者の予約枠リストを用いて、状況情報を作成する。１６時１００１〜２２時１００７における事業者が受け入れ可能な最大の収容数１０１１をみると、例えば、１６時の場合は最大３０の客を収容することができる。なお、本例では収容数などの単位を示していないが、人数でもよく、また組数でもよい。最大収容数が変化しているのは、予備スペースや人手などの影響である。１０１２は現在予約されている数である。フリー数１０１３は予約を受け付けないスペースの数である。現在予約数１０１４は実際に予約可能な予約枠数である。サービスサーバに送信する空きリストは、１６時１００１〜２２時１００７の項目と、予約数１０１４だけから構成してよい。
図１１は事業者の状況情報の他の実施例を示すテーブルである。図１１に示すように事業者固有の情報である事業者ＩＤ１１０１、事業者名１１０２と、状況を示す情報であるサービスタイプ１１０３、空き時間１１０４、予約枠１１０５から構成される。事業者ＩＤ１１０１は、サービスサーバ１０２が事業者を区別するために使用される。サービスタイプ１１０３はサービスの種類を表すキーワードであり、語句や数値、プログラムやスクリプトなどでもよい。類似のサービスを検索する際などに用いられる。
【００２８】
図１２は代案リストの一実施例を示すテーブルであり、図９のステップ９０７で作成される。１２０１から１２０８は１４時〜１６時における予約枠を示している。１２１１は時間を示しており、本例ではすべて１４時から１６時である。１２１２はサービスの種類を示している。１２１３は場所を示している。１２１４は事業者ＩＤを示している。１２１５は、事業者名を示している。この代案リストを用いると、キー情報から該当する予約枠を取得することができる。１２１６は予約枠数を示している。
【００２９】
図１３はサービスサーバ上の代案リストと事業者端末上の状況情報テーブルの関係一実施例をを示した模式図である。例えば、代案リスト１３０１の予約枠Ａ１は状況情報テーブル１３０２の予約枠Ａ１を反映している。これを示すために、代案リスト１３０１の予約枠Ａ１と状況情報テーブル１３０２の予約枠Ａ１は関係線１３１１で結ばれている。事業者端末１０３からサービスサーバ１０２へ送信されるデータは、状況情報として送信される。状況情報テーブル１３０２が更新されると自動的に代案リスト１３０１の内容が更新されるような設定にしてもよい。この場合、状況情報テーブル１３０２が更新されると、複数の事業者端末の内の当該事業者端末は自動的に更新された内容をサービスサーバ１０２に送信する。また、代案リスト１３０１のデータは、常に状況情報テーブルを参照する形式でもよい。この場合、代案リスト１３０１上のデータは、関係線１３１１〜１３１４で結ばれた状況情報テーブルのリンク情報となる。
【００３０】
図１４は状況情報テーブルが更新される場合の事業者端末とサービスサーバの処理手順の一実施例を示すフローチャートである。図において、状況情報テーブルが更新されると、ステップ１４０１で、更新された部分を抽出する。更新された部分とは、例えば、図１１において空き時間１９時の予約枠数が変更になったような場合であり、その変更部分だけを抽出し更新情報としてよい。また、抽出を行わずにすべての情報を更新情報としてもよい。次に、ステップ１４０２で、更新情報を送信する。サービスサーバ１０２は、ステップ１４１１で、更新情報を受信すると、ステップ１４１２で、代案リストに更新された情報を反映させる。
【００３１】
図１５はユーザ端末に入力された類似代案の表示例を示す正面図である。図において、１５０１はユーザ端末である。１５１１は移動後の予定であり、代案１５２１、１５２２が予定１５１１の代案として表示されている。１５２３は表示中の類似代案以外の類似代案を表示させるためのボタンである。１５２４は、代案１５２１、１５２２、ボタン１５２３が予定１５１１に関連していることを示す矢印である。本実施例では、表示の都合上１７時から１９時の領域に１４時から１６時の表示とともに類似代案を表示しているが、類似代案を予定１５１１上に表示してもよい。例えば、代案１である代案１５２１をユーザが選択すると、代案１５１１に代わり予定として表示される。この時、例えば予約がある場合は、自動的に予約の解約を行ってもよい。
【００３２】
図１６は移動後の予定が重なる場合の代案提供サービスの処理手順の一実施例を示すフローチャートである。ステップ１６１１ａ、１６１１ｂでは、ユーザ端末１０１とサービスサーバ１０２とは代案提供サービスに関する契約を行う。ステップ１６１１ａ、１６１１ｂは図５のステップ５１１ａ、５１１ｂと同様のことを行う。ステップ１６２１では、ユーザがユーザ端末１０１に予定を入力する。ステップ１６２１はステップ５２１と同様であるが、ステップ１６２１では予め１つ又はそれ以上の予定が入力されており、さらに予定を入力するか追加入力するかであり、複数の予定を一度に入力してもよい。ステップ１６３１では、ユーザが予定を移動する。予定を移動するとは、予定の時間を変更することである。ステップ１６４１では、ユーザの予定移動操作により、予定表上で予定が衝突したかどうかを判定する。予定が衝突するとは、予定の時間が重なる場合や、また、予定の場所が入力されている場合に、双方間の移動に必要な時間を算出し、その時間が予定間の時間よりも長い場合などである。ステップ１６４１において予定の衝突が検知されない場合は、図５のステップ５３１以降の処理を行う。また、ステップ１６３１では予定が修正されているため、ステップ５３１と同様の手順により移動した予定の代案を表示してもよいが、本例では移動した予定の代案は検索および表示しない。なお、ユーザがある予定を移動し、他の予定に衝突したとき、ユーザが移動させた予定を操作予定といい、衝突された予定を衝突予定という。
【００３３】
ステップ１６５１では、図１９で説明する移動処理を行う。移動処理とは、操作予定と衝突予定の間で発生する処理である。ステップ１６５２は、ステップ１６５１の移動処理に対応した代案の検索処理であり、図１９の類似代案検索処理に対応する。ステップ１６６１では、ステップ１６５１の移動処理およびステップ１６５２の類似代案検索処理で検索された代案を表示する。
【００３４】
図１７はユーザ端末に入力された予定の他の表示例を示す正面図であり、ステップ１６２１で入力した予定の例である。１７０１はユーザ端末である。１７１１は１２時から１４時の間の予定であり、予定内容１７２１が表示されている。また、１７２２は予定の場所を示しており、１７２３は場所の地図を表示するボタンである。１７２４は予約済を示す。この予定を検索する際に予約を行い、その結果の表示が予約済１７２４であってもよい。１７２５はクーポンを示し、クーポン１７２５がこの予定に付随していることを示している。この予定を検索する際にクーポンが事業者端末などから送付され、そのクーポンの存在を示す表示がクーポン１７２５であってもよい。１７３１は１５時から１６時半の間の予定であり、１７４１は予定内容である。また、１７４２は予定の場所を示し、１７４３は場所の地図を表示するボタンである。１７４４は予約済みであることを示す情報である。本例では１７３１にはクーポンが付属していないので、１７３１には１７２５と同様の表示は無い。
【００３５】
図１８はユーザ端末において予定を移動し直後の予定の他の表示例を示す正面図であり、図１６のステップ１６３１で予定を移動した直後の予定の例である。１８０１はユーザ端末である。１８１１は移動する前の操作予定であり、実際には画面上に表示されなくてもよい。１８２１は移動した操作予定である。１８３１は１８２１と衝突した衝突予定である。１８４１は予定１８１１が移動した方向を示す矢印である。
【００３６】
図１９は予定の移動処理の処理手順の一実施例を示すフローチャートであり、ステップ１６５１の移動処理のフローを示す。予約の移動処理を開始すると、ステップ１９０１で、ユーザ端末は衝突予定の移動時間帯を計算する。衝突予定の移動時間帯は、操作予定と衝突予定の時間間隔を維持するか、操作予定の場所と衝突予定の場所の間で経路探索を行い、移動所要時間から時間間隔を決定してもよい。次に、ステップ１９０２で、衝突予定の予約が変更可能かを、ネットワークを介して調べる。例えば、衝突予定の事業者に対して予定の移動時間帯へ予約の変更要求並びに既に取得済みの予約の取り消し要求を送信し、変更要求および取り消し要求の双方が受諾される場合のみ予約変更可能と判断する。予約変更が可能な場合は、ステップ１９０３で、衝突予定の予約を変更する。ステップ１９０２で、予約変更が不可能な場合は、ステップ１９０４で、図２１（詳細後述する）のように衝突予定を無視するかどうかをユーザに問い合わせるなどして判断する。ステップ１９０５では、衝突予定の類似代案を検索するかどうかを判断する。類似代案を検索する場合は、ステップ１９０６で、衝突予定の類似代案を検索する。ステップ１９０６は、図５のステップ５４１〜５７２までの一連の類似代案検索処理と同様であるが、キー情報の作成において、図２０（詳細後述）のように操作予定と衝突予定の両方を用いてもよい。両方を用いることで、よりユーザの嗜好に近い予定や、関連する予定を提案できる。ステップ１９０５もしくはステップ１９０６の処理が終了すると、衝突予定に関する処理は終了したので、次に、ステップ１９０８で、操作予定の変更処理を開始する。ステップ１９０４において、衝突予定を無視しない場合は、操作予定を移動することができないので、ステップ１９０７で、操作予定を変更するかどうかをユーザに問い合わせる。ステップ１９０８では、操作予定の予約変更が可能かを判断する。ステップ１９０９における操作予定予約変更、ステップ１９１０における操作予定の類似代案検索の要否、およびステップ１９１１における操作予定の類似代案検索はそれぞれステップ１９０３およびステップ１９０５およびステップ１９０６と同様の処理である。
【００３７】
図２０はキー情報の他の実施例を示すテーブルであり、ステップ１９０６、もしくはステップ１９１１で作成したキー情報の例を示す。本実施例では、開始日２００１、終了日２００２、開始時刻２００３、終了時刻２００４、場所２００５及び店名２００６は操作予定であり、開始日２０１１、終了日２０１２、開始時刻２０１３、終了時刻２０１４、場所２０１５及び店名２０１６は衝突予定である。各項目の内容２０３１は図８の項目８０１〜８０６と同様である。また、年齢２０２１、性別２０２２及び嗜好２０２３についても、図８の内容８１１〜８１３と同様である。また、２０３２は優先順位を示す。
【００３８】
図２１はユーザ端末において予約が変更不可能の場合の表示例を示す正面図であり、ステップ１９０２において予約が変更不可能であり、ステップ１９０３においてユーザに代案検索を行うかどうかを問い合わせている表示例である。図において、２１０１はユーザ端末である。２１１１は移動する前の操作予定であり、実際には画面上に表示されなくてもよい。２１２１はユーザが移動を試みている操作予定である。ユーザの操作を反映するため、一時的に操作予定２１２１として表示されているが、ユーザが移動取消を行うボタン２１５２を選択した場合には、操作予定２１２１は消去され、操作予定２１１１が画面上に表示される。
衝突予定２１３１の一部は操作予定２１２１の背後に表示されている。矢印２１４１はユーザが予定を移動した方向を示しており、実際に画面上に表示されなくてもよい。２１５１はユーザに予定２１３１が移動できないことを示すメッセージボックスである。２１５２は移動取消のボタンであり、操作予定２１１１および衝突予定２１３１が表示されている初期状態に画面が戻る。２１５３は新たな予定検索のボタンであり、衝突予定２１３１は破棄され、代案検索を行う。
【００３９】
図２２はユーザ端末において表示される類似代案の他の表示例を示す正面図であり、ステップ１６６１において表示される類似代案の表示例を示す。図において、２２０１はユーザ端末である。２２１１は移動した操作予定であり、２２２１は予約時間を変更した衝突予定である。２２２２は衝突予定の類似代案である。２２２３は表示中の類似代案以外の代案を表示させるためのボタンである。
【００４０】
【発明の効果】
以上述べたように、本発明によれば、簡易な操作で予定の時間を変更できる。また、予定の時間の変更に伴い維持できなくなった予定の代案を簡易な操作で表示できる。また、予定の時間を変更する際に影響を受ける他の予定を、簡易な操作で変更でき、また必要に応じて代案を表示できる。
【図面の簡単な説明】
【図１】本発明による予定代案提供システムの一実施例を示す構成図である。
【図２】本発明によるユーザ端末の一実施例を示すブロック図である。
【図３】本発明によるサービスサーバの一実施例を示すブロック図である。
【図４】本発明による事業者端末の一実施例を示すブロック図である。
【図５】本発明による予定代案提供サービスの基本フローを示すフローチャートである。
【図６】ユーザ端末に入力された予定の表示例を示す正面図である。
【図７】ユーザ端末に入力された予定を変更する場合の表示例を示す正面図である。
【図８】キー情報の一実施例を示すテーブルである。
【図９】類似代案の検索の手順の一実施例を示すフローチャートである。
【図１０】事業者の状況情報の一実施例を示すテーブルである。
【図１１】事業者の状況情報の他の実施例を示すテーブルである。
【図１２】代案リストの一実施例を示すテーブルである。
【図１３】サービスサーバ上の代案リストと事業者端末上の状況情報テーブルの関係の一実施例を示した模式図である。
【図１４】状況情報テーブルが更新される場合の事業者端末とサービスサーバの処理手順の一実施例を示すフローチャートである。
【図１５】ユーザ端末に入力された類似代案の表示例を示す正面図である。
【図１６】移動後の予定が重なる場合の代案提供サービスの処理手順の一実施例を示すフローチャートである。
【図１７】ユーザ端末に入力された予定の他の表示例を示す正面図である。
【図１８】ユーザ端末において予定を移動し直後の予定の他の表示例を示す正面図である。
【図１９】予定の移動処理の処理手順の一実施例を示すフローチャートである。
【図２０】キー情報の他の実施例を示すテーブルである。
【図２１】ユーザ端末において予約が変更不可能の場合の表示例を示す正面図である。
【図２２】ユーザ端末において表示される類似代案の他の表示例を示す正面図である。
【符号の説明】
１００…ネットワーク、１０１…ユーザ端末、１０２…サービスサーバ、１０３…事業者端末、２０１、３０１、４０１…ＣＰＵ、２０２、３０２、４０２…記録部、２０３、３０３、４０３…入力部、２０４、３０４、４０４…出力部、２０５、３０５、４０５…通信モジュール。
【図１】
2004220135.tif 000003
【図２】
2004220135.tif 000004
【図３】
2004220135.tif 000005
【図４】
2004220135.tif 000006
【図５】
2004220135.tif 000007
【図６】
2004220135.tif 000008
【図７】
2004220135.tif 000009
【図８】
2004220135.tif 000010
【図９】
2004220135.tif 000011
【図１０】
2004220135.tif 000012
【図１１】
2004220135.tif 000013
【図１２】
2004220135.tif 000014
【図１３】
2004220135.tif 000015
【図１４】
2004220135.tif 000016
【図１５】
2004220135.tif 000017
【図１６】
2004220135.tif 000018
【図１７】
2004220135.tif 000019
【図１８】
2004220135.tif 000020
【図１９】
2004220135.tif 000021
【図２０】
2004220135.tif 000022
【図２１】
2004220135.tif 000023
【図２２】
2004220135.tif 000024