JP2020177349A - 予約管理システム及びプログラム - Google Patents

Abstract

【課題】次の予約の場所又は次の予定の場所への移動が間に合わない可能性があってもユーザに通知されない場合とは異なり、空間の予約の見直しをユーザが事前に判断できるようにする。【解決手段】予約管理システムは、ユーザの予定に関連して予約された空間の場所と、空間の予約に前後する他の予定に関連する場所との間で、次の予約又は次の予定が開始する時刻までに移動が間に合うか否かの情報を取得する取得手段と、移動が間に合わない可能性がある場合、予約の見直しをユーザに通知する通知手段とを有する。【選択図】図７

Description

本発明は、予約管理システム及びプログラムに関する。

周囲が壁等で囲まれた箱型の空間から周囲に開放された空間まで、今日、時間単位で空間の占用を予約できるサービスがある。例えば駅や通路に設置した箱型の空間の占用を時間の単位で予約するサービスが実用化されている。このサービスは、移動中の空き時間の有効な活用を可能とする。

特開２０１７−１６７６３６号公報

空間の占用を予約する日時は、必ずしも空間を占用する日時の直前に限らない。例えば空間を占用する日時の前日以前に、空間の占用が予約されることがある。
ところで、空間の占用の予約は、ユーザの生活や活動に関する予定の一つである。このため、空間を占用する日時の前後に、新たな予定が事後的に入ることもあれば、空間を占用する日時の直前の予定の終了が偶発的に遅れることもある。
一方、時間的に連続する２つの予定の間で対応する場所への移動が可能か否かの判断は、ユーザ個人に委ねられている。このため、ユーザが、予約された時間帯に予約された空間に移動できないことに気づかないことが起こり得る。

本発明は、次の予約の場所又は次の予定の場所への移動が間に合わない可能性があってもユーザに通知されない場合とは異なり、空間の予約の見直しをユーザが事前に判断できるようにすることを目的とする。

請求項１に記載の発明は、ユーザの予定に関連して予約された空間の場所と、当該空間の予約に前後する他の予定に関連する場所との間で、次の予約又は次の予定が開始する時刻までに移動が間に合うか否かの情報を取得する取得手段と、移動が間に合わない可能性がある場合、前記予約の見直しをユーザに通知する通知手段とを有する予約管理システムである。
請求項２に記載の発明は、前記予約に前後する前記他の予定に関連する場所と時刻に関する情報は、ユーザの予定表を管理する端末から取得される、請求項１に記載の予約管理システムである。
請求項３に記載の発明は、前記空間の予約の直前に設定されている前記他の予定に複数人が関与する場合、移動が間に合うか否かは、当該予約と当該予定の間の数値上の空き時間よりも短い時間について判断される、請求項２に記載の予約管理システムである。
請求項４に記載の発明は、移動が間に合うか否かの前記情報は、前記予約の前後に新たな予定が追加される場合に取得される、請求項２に記載の予約管理システムである。
請求項５に記載の発明は、移動が間に合わない可能性の前記通知は、想定される移動の手段別に与えられる、請求項１に記載の予約管理システムである。
請求項６に記載の発明は、移動が間に合わない可能性の前記通知は、当該通知の不要をユーザが設定するまで、予め定めた規則に基づき再送される、請求項５に記載の予約管理システムである。
請求項７に記載の発明は、移動が間に合わない可能性は、再送の時点における情報に基づいて通知される、請求項６に記載の予約管理システムである。
請求項８に記載の発明は、移動が間に合うか否かの前記情報は、ユーザが携帯する端末から取得される位置と、前記予約に前後する前記他の予定の場所との間で取得される、請求項１に記載の予約管理システムである。
請求項９に記載の発明は、前記予約の取り消し又は変更の指示は、当該予約の見直しに含まれるアドレス先への接続により実現される、請求項１に記載の予約管理システムである。
請求項１０に記載の発明は、コンピュータに、ユーザの予定に関連して予約された空間の場所と、当該空間の予約に前後する他の予定に関連する場所との間で、次の予約又は次の予定が開始する時刻までに移動が間に合うか否かの情報を取得する機能と、移動が間に合わない可能性がある場合、前記予約の見直しをユーザに通知する機能とを実行させるプログラムである。

請求項１記載の発明によれば、次の予約の場所又は次の予定の場所への移動が間に合わない可能性があるユーザに対し、空間の予約を見直す機会を事前に与えることができる。
請求項２記載の発明によれば、場所の予約とユーザの予定表とが別々に管理される場合にも、予約を見直す機会を与えることができる。
請求項３記載の発明によれば、数値上の空き時間だけでは分からない事情も含めて移動が間に合わない可能性をユーザに通知できる。
請求項４記載の発明によれば、新たな予定の追加によって移動が間に合わない可能性が生じるか否かをユーザに通知できる。
請求項５記載の発明によれば、移動が間に合わない可能性を移動の手段別にユーザに通知できる。
請求項６記載の発明によれば、予約の見直しの機会となる通知をユーザが不要と判断するまで何度でも受け取ることができる。
請求項７記載の発明によれば、移動が間に合わない可能性の通知の正確性を高めることができる。
請求項８記載の発明によれば、予定の場所とは異なる場所にいる場合にも移動が間に合うかを知ることができる。
請求項９記載の発明によれば、ユーザは、空間の予約を管理するシステムにログインするための特別な操作無しに予約の取り消し又は変更を指示できる。
請求項１０記載の発明によれば、次の予約の場所又は次の予定の場所への移動が間に合わない可能性があるユーザに対し、空間の予約を見直す機会を事前に与えることができる。

実施の形態で使用する管理システムの全体構成の例を概略的に示す図である。 ブース型の空間の例を説明する図である。 実施の形態で使用する管理サーバのハードウェア構成の一例を説明する図である。 実施の形態で使用するユーザ端末のハードウェア構成の一例を示す図である。 空間予約サーバで管理される管理データの一例を説明する図である。 予定管理サーバで管理される管理データの一例を説明する図である。 移動管理サーバの機能構成の例を説明する図である。 本実施の形態における移動判定モジュールを構成する機能構成の例を説明する図である。 移動管理サーバにより実行される処理の例を説明するフローチャートである。 ユーザ端末に表示される通知用の画面の例を説明する図である。 ユーザ端末に表示される通知用の画面の他の例を説明する図である。 ユーザ端末に表示される通知用の画面の他の例を説明する図である。

以下、図面を参照して、本発明の実施の形態を説明する。
＜実施の形態＞
通信機器の小型化、通信速度の高速化等により、今日のビジネスパーソンは、自席以外の空間で仕事をする機会が増えている。例えば会議への出席、客先への訪問等も、自席以外の空間で行われる仕事の一例である。また、時間の有効活用を目的として、移動中の空き時間に、予め予約した空間で仕事することもある。
今日、予定は、電子データとして管理されることも多い。例えばスマートフォンにインストールされたアプリケーションプログラムを用いて予定を管理する場合もあれば、ネットワークサービスやクラウドサービスを用いて予定を管理する場合もある。また、予定の管理には、個人の予定を管理する場合と複数人の予定を管理する場合があり、複数人の予定の共有を目的としたサービスはグループウェアとも呼ばれる。

本実施の形態で想定する予定は、開始日時と終了日時によって管理される。また、個々の予定には、ビジネスパーソンが利用する空間を特定する情報が含まれている。なお、予定で利用する空間は、予約を必要とする空間もあれば、予約を必要としない空間もある。
予約を必要とする空間の管理は、予約の対象として空間を提供する事業者によって管理されている。このため、空間の予約を管理する端末は、基本的に、予約者である個人の他の予定は知りえない状態にある。このため、ある予定で利用される空間の場所から次の予定で利用される空間の場所への移動が可能か否かの判断は、基本的に個人の判断に委ねられている。このため、予約した場所に予約が開始する時間に到着しない事故の発生が起こり得る。
本実施の形態では、予約を要しない空間と予約を必要とする空間との間における移動が、予約又は予定が開始する時間までに可能であるか否かを予約者であるユーザに通知するサービスについて説明する。

＜空間予約システムの全体構成＞
図１は、実施の形態１で使用する管理システム１の全体構成の例を概略的に示す図である。
本実施の形態における管理システム１は、空間２の予約者の移動に関する通知サービスの提供を目的とする。
本実施の形態における空間２は、ブース、宿泊施設等の客室、会社内等の会議室等を含む。これらは、壁や間仕切り等によって周囲から区切られている空間の一例である。また、本実施の形態における空間２は、飲食店や理髪店等でサービスの提供を受けるテーブルや座席等を含む。これらは、周囲に開放された区間の一例である。
また、本実施の形態における空間２には、別の地点からの移動、又は、別の地点への移動に要する経路の探索に必要となる住所その他の位置に関する情報が登録されている。
さらに、本実施の形態における空間２には、管理上の名称や番号等が付与されている。
なお、空間２の予約は、有料でも無料でもよい。

図１に示す管理システム１は、クラウドネットワーク３に接続された各種の端末で構成されている。
図１では、クラウドネットワーク３に接続される端末の例として、予約の対象である空間２、ユーザが操作するユーザ端末４、空間２の予約を管理する空間予約管理サーバ５、予約者であるユーザの予定を管理する予定管理サーバ６、時間的に前後する複数の予定の間で次の予定の開始日時までに場所の移動が可能であるかを管理する移動管理サーバ７が示されている。
もっとも、空間２は、予約者等がサービスの提供を受けるテーブルや座席等のように、端末としての機能を有しない場合も考えられる。

図１の場合、目的別又は機能別に１台のサーバが用意されている。すなわち、空間予約管理サーバ５、予定管理サーバ６、移動管理サーバ７がそれぞれ１台ずつ用意されている。
しかし、１つの目的又は機能に対して、複数台のサーバを用意してもよいし、１台のサーバで複数の目的又は機能を分担してもよい。
ある空間２の予約を管理する事業者は、単独でも複数でもよい。例えば予約の管理、入退室や室内の利用状況などの管理、ユーザに対する利用料金の請求に関する管理、利用者として登録されている会員の管理のそれぞれを、異なる事業者が分担してもよい。
前述したように、予約の対象として管理される空間２は、同種である必要もない。例えば空間２の一部はブースであり、空間２の一部は飲食店等の座席やテーブルでもよい。
また、１つの目的又は機能についての管理を、複数の事業者が協働で提供してもよい。

空間２の扉に電子錠が取り付けられている場合、空間２の利用は、事前に配布された電子鍵を有することが利用の条件になる。また、扉を有しない空間２の場合には、事前に配布された認証コードを用いて予約者を認証する方法、空間２の管理者が予約者の氏名を確認する方法等が利用の条件になる。
本実施の形態では、ユーザ端末４として、予約者であるユーザが携帯可能なスマートフォンを想定する。もっとも、携帯可能なユーザ端末４は、いわゆるウェアラブル端末でもよいし、ノート型のコンピュータやゲーム端末でもよい。

空間予約管理サーバ５は、空間２の予約に関連する各種の情報を管理する。空間予約管理サーバ５は、例えば予約者を特定する情報、予約の対象である空間２を特定する情報、予約の開始日時、予約の終了日時を管理する。
予約者を特定する情報には、例えば予約者の氏名、性別、年齢、アカウント、パスワード、個人に付された管理用の情報が含まれる。また、予約の対象である空間２を特定する情報には、例えば住所又は所在の場所を特定する情報、管理用の名称や番号が含まれる。
なお、空間予約管理サーバ５は、空間２に関連付けられている物品やサービスの予約を管理してもよい。例えば貸し出しや使用の許諾が可能な物品やサービス、消費される又は消耗する物品やサービスを管理してもよい。
本実施の形態の場合、空間予約管理サーバ５が管理する予約の情報には、予約者であるユーザの事前の同意の下、移動管理サーバ７からアクセスが可能になっている。

予定管理サーバ６は、予約者であるユーザが予定の管理に使用するアプリケーションやグループウェア等が実行される端末である。もっとも、ユーザ端末４にインストールしたアプリケーションで個人の予定を管理する場合、予定管理サーバ６は不要である。予定管理サーバ６は、例えば管理の対象であるユーザのアカウント、パスワード、予定の件名、予定の場所、開始日時、終了日時が含まれる。
本実施の形態の場合、予定管理サーバ６が管理する予約の情報には、利用者であるユーザの事前の同意の下、移動管理サーバ７からアクセスが可能になっている。

移動管理サーバ７は、先の予定の終了時刻から次の予定の開始時刻までに、先の予定の場所から次の予定の場所への移動が可能か否かを管理するサービスを提供する端末である。
ここでの先の予定には、予約も含まれる。従って、移動管理サーバ７は、予約されている空間２から別の空間２への移動が開始時刻までに間に合うか否か、予定について設定されている場所から予約されている空間２への移動が開始時刻までに間に合うか否か、予約されている空間２から予定について設定されている場所への移動が開始時刻までに間に合うか否かを管理する。

本実施の形態における移動管理サーバ７は、例えばユーザのアカウントを利用して、空間予約管理サーバ５と予定管理サーバ６のそれぞれから、各ユーザが設定している予約の情報と予定の情報を取得する。
本実施の形態における移動管理サーバ７は、予約毎に、予約の前後に設定された他の予定との間における時間内に移動が間に合うか否かを判定し、間に合わない可能性がある場合にはユーザに対して事前に通知する。なお、移動管理サーバ７の機能は、ユーザ端末４にインストールされたアプリケーションとして実現することも可能である。
ここでの移動管理サーバ７は、予約管理システムの一例である。

＜空間の外観構成＞
図２は、ブース型の空間２の例を説明する図である。
図２に示すブース型の空間２は、例えば駅の構内、空港、オフィスビル、飲食店やデパート等の商業施設、銀行、図書館、美術館、博物館、公共機関や施設、連絡通路、公園等、室内外を問わずに配置される。
図２に示すブース型の空間２は、天井が取り付けられている閉鎖型のブースである。ただし、閉鎖型とは、密閉の意味ではなく、実用的な防音性能を備えていればよい。このため、通気口や小窓等の開口や隙間が、空間２を構成する躯体の一部分に設けられていてもよい。また、窓は開閉が可能でもよい。

図２に示す空間２の躯体は、天井２０Ａと、床面２０Ｂと、開閉可能な扉２２が取り付けられている壁面２０Ｃと、壁面２０Ｃの両側に位置する２つの壁面２０Ｄ及び２０Ｅと、扉２２の対面側に位置する壁面２０Ｆとで構成される。
図２の場合、天井２０Ａには、換気口２３が設けられている。換気口２３には、開口面積の調整が可能なルーバ２３Ａが取り付けられている。図２のルーバ２３Ａは、全開状態にある。
本実施の形態の場合、扉２２は、壁面２０Ｃに沿って移動が可能な引き戸を想定する。図２の場合、扉２２は、一方向にスライドされる片引き扉であるが、２枚以上の部材を行き違わせて開閉する引き違い扉でも、２枚の部材を左右にスライドする引き分け扉でもよい。

もっとも、扉２２は、引き戸に限らない。例えば扉２２は、１枚の部材が弧を描くように移動する片開きの開き戸でもよいし、１つの開口部を２枚の扉部材で仕切る両開きの開き戸でもよい。
また、扉２２は、蝶番で連結された２枚１組の扉部材を折り畳むように開く折れ戸でもよい。折れ戸にも、片方にのみ開くタイプと、両方向に開くタイプがある。
また、特殊なタイプとして、収納時に扉２２が壁の中に引き込まれる引き込み戸や間仕切り戸であってもよい。
なお、扉２２は内開きでも外開きでも構わない。
本実施の形態の場合、扉２２には、開閉時にユーザが掴む取手２２Ａが取り付けられている。

また、扉２２の中央部分には、秘匿性と防犯性を考慮した加工が施された部材２２Ｂが配置されている。部材２２Ｂは、例えば多数の孔が配列された金属製の板（例えばパンチングメタル）が内側に取り付けられた透明板でもよいし、目隠しとなる部材が隙間を空けて内側に取り付けられた透明板でもよいし、正面からは内部の確認が容易であるが斜め方向からは内部の確認が困難なフィルムが貼り付けられた透明板でもよいし、内部の視認性を低下させる加工が施された透明板でもよい。
ここでの透明板には、例えばガラス、アクリル樹脂を用いる。また、秘匿性と防犯性のために貼り付けられるフィルムの透過性に関する特性は、扉２２の位置とユーザの作業位置との関係で定まる。扉２２の正面奥でユーザが作業を行う場合には、正面からは内部の確認が困難であるが、斜め方向からは内部の確認が容易なフィルムを用いればよい。

ここでのフィルムは、透過と白濁を電気的に切り替え可能な液晶フィルムや透過率を電気的に制御可能な偏光フィルムでもよい。
また、視認性を低下させる加工には、例えば光が散乱するように部材の表面に細かい傷を付けることを含む。
なお、当該加工は、部材２２Ｂの一部に施されていてもよい。例えば床面や天井の付近は透明であるが、作業中のモニタを覗き込める範囲は、加工によって視認性が低下される構造でもよい。
部材２２Ｂを配置することで、モニタの画面を外部から隠しつつも、ユーザの在不在を外部から確認することが可能になる。
この他、扉２２には、電子鍵による解錠が可能な電子錠２２Ｃが取り付けられている。
もっとも、秘匿性と防犯性を考慮した加工は、扉２２以外の部材にも施されることを妨げない。例えば壁面２０Ｄ、２０Ｅ、２０Ｆの少なくとも一部に秘匿性と防犯性を考慮した加工が施されていてもよい。

空間２の利用人数は、空間２の容積によっておおよそ決まる。本実施の形態における空間２は、基本的に１人が使用する個室型を想定する。もっとも、空間２は、多人数を収容可能な大部屋でもよい。大部屋は、単独の部屋として構成されていてもよいが、空間２の壁面２０Ｄ及び２０Ｅの一方又は両方を取り除いた複数の空間２を連結することで形成してもよい。
なお、個室型とは１人しか利用できない意味ではなく、少人数、例えば２〜３人の利用が可能な意味で使用する。
空間２を構成する躯体の形状や構造、提供される設備や性能は任意である。例えば天井２０Ａを取り除いた構成も可能である。
本実施の形態の場合、躯体の内部には、不図示の机と椅子が１つずつ配されている。机の上には、備え付けの備品及び機器、予約された備品及び機器等が配置される。

＜端末の構成＞
図３は、実施の形態で使用する管理サーバのハードウェア構成の一例を説明する図である。本実施の形態における管理サーバは、空間予約管理サーバ５（図１参照）、予定管理サーバ６（図１参照）、移動管理サーバ７（図１参照）である。
管理サーバは、装置全体の動作を制御する制御ユニット１０１と、管理データ等を記憶するハードディスクドライブ１０２と、ＬＡＮ（＝Local Area Network）ケーブル等を介した通信を実現するネットワークインターフェース１０３とを有している。
制御ユニット１０１は、ＣＰＵ（＝Central Processing Unit）１１１と、基本ソフトウェアやＢＩＯＳ（＝Basic Input Output System）等が記憶されたＲＯＭ（＝Read Only Memory）１１２と、ワークエリアとして用いられるＲＡＭ（＝Random Access Memory）１１３とを有している。ＣＰＵ１１１はマルチコアでもよい。また、ＲＯＭ１１２は、書き換え可能な不揮発性の半導体メモリでもよい。制御ユニット１０１は、いわゆるコンピュータである。

ハードディスクドライブ１０２は、円盤状の基板表面に磁性体を塗布した不揮発性の記憶媒体にデータを読み書きする装置である。もっとも、不揮発性の記憶媒体は、半導体メモリや磁気テープでもよい。
この他、管理サーバは、必要に応じ、キーボード、マウス等の入力デバイス、液晶ディスプレイ等の表示デバイスも備える。
制御ユニット１０１と、ハードディスクドライブ１０２と、ネットワークインターフェース１０３は、バス１０４や不図示の信号線を通じて接続されている。

図４は、実施の形態で使用するユーザ端末４のハードウェア構成の一例を示す図である。図４に示す構成は、ユーザ端末４がスマートフォンの場合を想定する。
ユーザ端末４は、装置全体の動作を制御する制御ユニット２０１と、各種のデータを記憶するメモリカード２０２と、無線通信の規格に準拠する各種の通信インターフェース２０３と、タッチセンサ等の入力デバイス２０４と、液晶ディスプレイや有機ＥＬ（＝Electro Luminescence）ディスプレイ等の表示デバイス２０５と、ＧＰＳ（＝Global Positioning System）センサ２０６を有している。

制御ユニット２０１は、ＣＰＵ２１１と、ファームウェアやＢＩＯＳ等が記憶されたＲＯＭ２１２と、ワークエリアとして用いられるＲＡＭ２１３とを有している。ＣＰＵ２１１はマルチコアでもよい。また、ＲＯＭ２１２は、書き換え可能な不揮発性の半導体メモリでもよい。
通信インターフェース２０３は、例えば移動通信システムとの接続に使用されるインターフェース、無線ＬＡＮとの接続に使用されるインターフェースである。
ＧＰＳセンサ２０６は、ＧＰＳ衛生からの電波を受信してユーザ端末４の位置を測定するセンサである。ＧＰＳセンサ２０６から出力される緯度、経度、高度の情報は、ユーザ端末４の現在位置を与える。なお、ＧＰＳセンサ２０６は、屋内用の測位システムに対応してもよい。

＜管理データの例＞
図５は、空間予約管理サーバ５（図１参照）で管理される管理データの一例を説明する図である。
本実施の形態における空間予約管理サーバ５は、予約の対象である空間２毎に予約の情報を管理している。
図５に示す管理データは、ブース番号が「０００１」、ブース名が「Ａ駅改札前広場１」である空間２の例である。なお、この空間２には、場所を特定する情報として、人の管理に用いられる位置情報の他、緯度、経度等の位置データが記録されている。
図５の場合、予約の管理データは、予約日、開始時刻、終了時刻、ユーザ名等で構成される。例えば「２０１９／４／１１」の「９：００」から「９：３０」の時間帯は、「ユーザＡ」が予約している。
図５の場合、予約の単位は、１５分単位である。もっとも、予約の単位は１０分刻み等、他の単位でもよい。

図６は、予定管理サーバ６（図１参照）で管理される管理データの一例を説明する図である。
図６では、管理データを予定表の形式で表現している。予定は、ユーザ毎に管理される。図６に示す予定表は、ユーザＡのある週の予定を表している。
図６の場合、月曜日には、１２：３０から１５：３０の時間帯に「予定１」が設定されている。火曜日には、９：００から１１：３０の時間帯に「予定２」が設定され、１６：３０から１８：３０の時間帯に「予定３」が設定されている。木曜日には、１２：００から１８：００の時間帯に「予定４」が設定されている。金曜日の１１：００から１５：００の時間帯には「予定５」が設定されている。
図６の場合、個々の予定は、名称等の場所の管理情報、場所の位置情報、開始日時、終了日時等で管理されている。
図６では、予定表では管理されていない予定の時間帯を破線で囲んで示している。ここでの予定は、例えば空間予約管理サーバ５で管理される予約である。

＜移動管理サーバの機能構成＞
図７は、移動管理サーバ７（図１参照）の機能構成の例を説明する図である。
移動管理サーバ７の機能は、制御ユニット１０１によるプログラムの実行を通じて実現される。以下では、各機能に対応するプログラムをモジュールという。
本実施の形態に係る移動管理サーバ７は、空間予約管理サーバ５（図１参照）から予約の情報を取得する予約情報取得モジュール３０１と、予定管理サーバ６（図１参照）から予定の情報を取得する予定情報取得モジュール３０２と、ユーザの現在位置を取得する現在位置取得モジュール３０３と、処理対象とする予約と前後の予定との間における移動が開始時刻に間に合わない可能性があるか否かを判定する移動判定モジュール３０４と、次の予定の開始時刻までに移動が間に合わない可能性がある場合にユーザに予定の変更を促す通知を送信する通知モジュール３０５の機能を有している。

予約情報取得モジュール３０１は、通知サービスを利用するユーザについて、空間２（図１参照）の予約の情報を取得する。予約情報取得モジュール３０１は、取得手段の一例である。
予定情報取得モジュール３０２は、通知サービスを利用するユーザについての予定表の情報を取得する。予定情報取得モジュール３０２は、取得手段の一例である。
現在位置取得モジュール３０３は、ＧＰＳセンサ２０６（図４参照）で測定された位置情報をユーザ端末４（図１参照）から取得する。ここで取得される位置情報は、ユーザの現在位置である。ユーザの現在位置は、例えばユーザが直前の予定の場所にいない場合等に、移動が間に合うか否かを判定するのに活用される。現在位置取得モジュール３０３は、取得手段の一例である。

移動判定モジュール３０４は、判定の対象である予約とその前後の時間帯に設定されている他の予定との間で移動に利用可能な時間、移動に用いる移動の手段、移動の手段に応じた移動の経路等の情報に基づいて移動が次の予定の開始時刻に間に合うか否かを判定する。ここでの他の予定には、他の予約も含まれる。
通知モジュール３０５は、移動が間に合わない可能性があると判定された場合には関連する予定の変更を促す通知を送信する一方で、移動が間に合わない可能性が無いと判定された場合には何らの通知も送信しない。通知モジュール３０５は、通知手段の一例である。

図８は、本実施の形態における移動判定モジュール３０４（図７参照）を構成する機能構成の例を説明する図である。
本実施の形態に係る本実施の形態に係る移動管理サーバ７は、中間に他の予定を含まない２つの予定の間で移動に割り当て可能な時間を特定する移動時間特定モジュール３１１と、時間的に先の予定の場所から時間的に後の予定の場所への移動の経路を算出する移動経路算出モジュール３１２と、経路別に移動に要する時間を算出する移動時間算出モジュール３１３と、経路別に移動が間に合わない可能性を判定する移動可否判定モジュール３１４と、判定結果に基づいて通知を送信するか否かを判定する通知可否判定モジュール３１５の機能を有している。

本実施の形態の場合、２つの予定の間で移動に割り当て可能な時間は、例えば先の予定の終了時刻と次の予定の開始時刻として特定される。
もっとも、予定の終了時刻に移動が開始できるとは限らないし、準備のために予定の開始時刻の前に到着しなければならない場合もある。
そこで、移動に割り当て可能な時間は、予め定めた調整時間を考慮して特定してもよい。調整時間は、予定の終了時刻から移動が開始されるまでの期間に対応する調整時間と、次の予定の場所に到着してから予定の開始時刻までの期間に対応する調整時間で別々に設定してもよい。なお、調整時間の設定は、ユーザが個別に設定してもよい。

また、移動に割り当て可能な時間は、移動の起点となる先の予定に関連付けられているユーザが複数人か否かによって調整してもよい。例えば先の予定が、複数人が参加する会議である場合、予定した終了時刻に会議が終わらない可能性がある。
そこで、本実施の形態では、移動の起点となる先の予定に複数人が関連付けられている場合には、予約の終了時刻に付加する調整時間を、個人の予定の場合よりも長く設定する。換言すると、移動に割り当て可能な時間差を、個人の予定の場合よりも短く設定する。例えば個人の予定の場合には、調整時間が５分だとしても、複数人が関連付けられている予定の場合には調整時間を２０分とする。勿論、この数値は一例である。

移動経路算出モジュール３１２が算出する移動の経路は、２つの予定の場所に応じて１つの場合もあれば複数の場合もある。例えば同じ建物内の移動であれば、徒歩による移動となるので、推奨される経路は基本的に１つになる。勿論、複数の経路が検討される場合もある。
また、移動の距離が長い場合には、車による移動、自転車による移動、公共交通機関を利用する移動等が考えられる。なお、都市部の場合には、公共交通機関を利用する場合にも複数の路線を利用できる場合もある。このような場合には、複数の移動経路が算出される。
移動経路が算出されると、移動時間算出モジュール３１３は、移動の時間帯に応じた移動時間を算出する。車や公共交通機関を利用する移動経路の場合、移動に用いられる時間帯、道路の渋滞状況、路線の混雑状況等によって移動に要する時間が変動する可能性があるためである。

なお、移動経路算出モジュール３１２と移動時間算出モジュール３１３は、他の事業者がインターネット上で提供しているサービスを活用してもよい。
移動に要する時間は、移動経路毎に算出される。そこで、本実施の形態における移動判定モジュール３０４（図７参照）は、移動経路毎に次の予定の開始時刻までに移動が間に合うか否かを判定する。前述したように、調整時間が設定されている場合には、調整後の時刻に基づいて移動が間に合うか否かが判定される。
本実施の形態の場合、移動判定モジュール３０４による判定は、例えば新たな予約や予定が設定された場合、既存の予約や予定に場所や時間の変更があった場合に実行される。また、移動判定モジュール３０４による判定は、判定時に活用できる最新の情報が用いられる。

＜移動管理サーバの処理＞
図９は、移動管理サーバ７（図１参照）により実行される処理の例を説明するフローチャートである。
図９に示す処理は、通知サービスの提供対象であるユーザの予約毎に実行される。ここで、判定対象とする予約は、例えば新たに設定された予約である。この他、判定対象とする予約には、新たな予約又は予定の設定により移動が間に合うか否かを判定する他方の予約又は予定に変化が生じた予約を含めてもよい。また、判定対象とする予約には、移動が間に合うかを判定する他方の予約又は予定の開始日時、終了時刻、場所等に変更があった予約を含めてもよい。

まず、移動管理サーバ７は、判定対象とする予約の情報を取得する（ステップ１）。例えば移動管理サーバ７は、予約の対象である空間２（図１参照）の場所、予約の開始時刻、予約の終了時刻、予約で設定されている空間２の使用人数を取得する。
次に、移動管理サーバ７は、同じユーザに関し、判定対象とする予約の時間帯に前後する他の予定の情報を取得する（ステップ２）。例えば移動管理サーバ７は、取得された予定毎に、設定されている場所、予定の開始時刻、予定の終了時刻、予定が他のユーザと共有されているか否かの情報を取得する。

続いて、移動管理サーバ７は、直前の予定又は判定対象とする予約に他のユーザも関係するか否かを判定する（ステップ３）。
ステップ３で肯定結果が得られた場合、移動管理サーバ７は、該当する予定又は予約の終了時刻を移動経路の探索用に調整する（ステップ４）。
例えば判定対象とする予約の直前の予定に他のユーザが関係している場合、移動管理サーバ７は、移動経路の探索に用いる終了時刻を遅らせる。前述したように、予約の終了時刻に開始する次の予定がない場合、複数人が関係する予定の終了時刻は一人の予定の終了時刻よりも延長され易いためである。そこで、事前に設定された調整時間分、移動経路の探索用の終了時刻を調整する。ここでの予定には他の予約も含まれる。
判定対象である予約に他のユーザが関係している場合も同様である。

ステップ３で否定結果が得られた場合、又は、ステップ４の処理の後、移動管理サーバ７は、全ての移動経路で移動時間内に移動が可能か否かを判定する（ステップ５）。
移動経路は、直前の予定の場所から処理対象である予約の場所への移動経路と、処理対象である予約の場所から直後の予定の場所への移動経路である。
ステップ５の判定の時点が判定対象とする予約の前日以前の場合や予約当日の直前の予定より前の時間帯の場合、移動管理サーバ７は、ユーザ端末４（図１参照）のＧＰＳ位置を用いずに、全ての移動経路について移動が間に合うか否かを判定する。
一方、ステップ５の判定の時点が判定対象とする予約が開始した後である場合や判定対象とする予約が開始している場合、移動管理サーバ７は、ユーザ端末４のＧＰＳ位置を用いて移動が間に合うか否かを判定する。このとき、移動管理サーバ７は、最新の交通情報を取得して移動が間に合うか否かを判定する。これにより、より正確な判定が可能になる。

ステップ５で肯定結果が得られた場合、移動管理サーバ７は、何らの通知を行わずに処理を終了する。
ステップ５で否定結果が得られた場合、移動管理サーバ７は、移動時間内に移動が可能な移動経路がないかを判定する（ステップ６）。
ここで、ステップ６で肯定結果が得られる場合とは、探索された全ての移動経路で次の予定又は予約の開始時刻までに移動が間に合わないことを意味する。一方、ステップ６で否定結果が得られる場合とは、少なくとも１つの移動経路は、次の予定又は予約の開始時刻までに移動が間に合うことを意味する。

ステップ６で肯定結果が得られた場合、移動管理サーバ７は、いずれの移動経路についても移動が間に合わない可能性をユーザに通知する（ステップ７）。
図１０は、ユーザ端末４（図１参照）に表示される通知用の画面の例を説明する図である。図１０に示す例は、判定対象である予約の場所への移動が間に合わない可能性がある場合に通知される。
図１０に示す画面は、次の予約の場所への移動が間に合わない可能性がある旨を示す文４０１と、直前の予定の内容４０２と、対象とする予約の内容４０３を含んでいる。
図１０の場合、直前の予定の場所から対象とする予約の場所への移動に割り当て可能な最大時間が３０分である。

また、図１０に示す画面には、空間予約管理サーバ５が用意する予約のキャンセル又は変更のための専用ページへのリンク情報４０４も含まれている。リンク情報４０４のクリックにより、ログイン画面の表示と入力操作のスキップが可能になる。リンク情報４０４は、例えばＵＲＬ（＝Uniform Resource Locator）である。ここでのリンク情報４０４は、アドレスの一例である。
さらに、図１０に示す画面には、予め定めた条件を満たす場合の再通知をワンクリックで完了するためのリンク情報４０５も含まれている。予め定めた条件には、例えば最新の通知からの予め定めた時間の経過、予約の開始時刻に対して予め定めた時間前等である。
ここでのリンク情報４０５もアドレスの一例である。

図１１は、ユーザ端末４（図１参照）に表示される通知用の画面の他の例を説明する図である。図１１に示す例は、判定対象である予約の場所から次の予定の場所への移動が間に合わない可能性がある場合に通知される。
なお、図１１には、図１０との対応部分に対応する符号を付して示している。
図１１に示す画面は、次の予定の場所への移動が間に合わない可能性がある旨を示す文４０１Ａと、対象とする予約の内容４０２Ａと、直後の予定の内容４０３Ａを含んでいる。
図１１の場合、対象とする予約の場所から直後の予定の場所への移動に割り当て可能な最大時間が３０分である。
なお、図１１に示す画面にも、リンク情報４０４と４０５が含まれている。

図９の説明に戻る。
一方、ステップ６で否定結果が得られた場合、移動管理サーバ７は、移動が間に合う移動経路と、移動が間に合わない移動経路をユーザに通知する（ステップ８）。
図１２は、ユーザ端末４（図１参照）に表示される通知用の画面の他の例を説明する図である。図１２に示す例は、直前の予定の場所から判定対象である予約の場所への移動が一部の移動経路で間に合わない可能性がある場合に通知される。
図１２には、図１０との対応部分に対応する符号を付して示している。
図１２に示す画面には、移動に使用する主な移動手段別に移動が間に合うかについての情報を示す欄４０６が含まれており、この点で図１２に示す画面は図１０と異なっている。図１２の場合、電車とタクシーによる移動は可能であるが、バスと自転車と徒歩による移動は困難である。図１２には示されていないが、移動手段別に算出に用いた移動経路の内容を表示するボタンが用意されていてもよい。

図９の説明に戻る。
この後、移動管理サーバ７は、再通知不要の設定がないかを判定する（ステップ９）。再通知不要の設定は、リンク情報４０５（図１０、図１１、図１２参照）のクリックにより実行される。
再通知不要の設定がある場合、移動管理サーバ７は、ステップ９で否定結果を得る。この場合、移動管理サーバ７は、再通知を行うことなく処理を終了する。
一方、ステップ９で肯定結果が得られた場合、移動管理サーバ７は、予め定めた条件を満たすか否かを判定する（ステップ１０）。
ステップ１０で否定結果が得られている間、移動管理サーバ７は、判定を繰り返す。
一方、ステップ１０で肯定結果が得られた場合、移動管理サーバ７は、ステップ１に戻る。本実施の形態でステップ１に戻るのは、予約や予定に修正が加えられる可能性があるためである。すなわち、再通知のための判定では、同判定の時点における情報が用いられる。

＜他の実施の形態＞
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は前述した実施の形態に記載の範囲に限定されない。前述した実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。
例えば前述の実施の形態においては、ビジネスでの使用を前提としているが、私生活における予定の管理にも活用が可能である。例えば自宅以外の空間での習い事や買い物等、開始日時と終了日時が予め定まっている予定や予約の管理に使用できる。
また、前述の実施の形態では、空間予約管理サーバ５で管理される予約と他の予定との間で移動が間に合うか否かを判定しているが、予定管理サーバ６で管理する予定間で移動が間に合うか否かを判定してもよい。

１…管理システム、２…空間、３…クラウドネットワーク、４…ユーザ端末、５…空間予約管理サーバ、６…予定管理サーバ、７…移動管理サーバ、３０１…予約情報取得モジュール、３０２…予定情報取得モジュール、３０３…現在位置取得モジュール、３０４…移動判定モジュール、３０５…通知モジュール、３１１…移動時間特定モジュール、３１２…移動経路算出モジュール、３１３…移動時間算出モジュール、３１４…移動可否判定モジュール、３１５…通知可否判定モジュール

Claims (10)

1. ユーザの予定に関連して予約された空間の場所と、当該空間の予約に前後する他の予定に関連する場所との間で、次の予約又は次の予定が開始する時刻までに移動が間に合うか否かの情報を取得する取得手段と、
   移動が間に合わない可能性がある場合、前記予約の見直しをユーザに通知する通知手段と
   を有する予約管理システム。
2. 前記予約に前後する前記他の予定に関連する場所と時刻に関する情報は、ユーザの予定表を管理する端末から取得される、請求項１に記載の予約管理システム。
3. 前記空間の予約の直前に設定されている前記他の予定に複数人が関与する場合、移動が間に合うか否かは、当該予約と当該予定の間の数値上の空き時間よりも短い時間について判断される、請求項２に記載の予約管理システム。
4. 移動が間に合うか否かの前記情報は、前記予約の前後に新たな予定が追加される場合に取得される、請求項２に記載の予約管理システム。
5. 移動が間に合わない可能性の前記通知は、想定される移動の手段別に与えられる、請求項１に記載の予約管理システム。
6. 移動が間に合わない可能性の前記通知は、当該通知の不要をユーザが設定するまで、予め定めた規則に基づき再送される、請求項５に記載の予約管理システム。
7. 移動が間に合わない可能性は、再送の時点における情報に基づいて通知される、請求項６に記載の予約管理システム。
8. 移動が間に合うか否かの前記情報は、ユーザが携帯する端末から取得される位置と、前記予約に前後する前記他の予定の場所との間で取得される、請求項１に記載の予約管理システム。
9. 前記予約の取り消し又は変更の指示は、当該予約の見直しに含まれるアドレス先への接続により実現される、請求項１に記載の予約管理システム。
10. コンピュータに、
    ユーザの予定に関連して予約された空間の場所と、当該空間の予約に前後する他の予定に関連する場所との間で、次の予約又は次の予定が開始する時刻までに移動が間に合うか否かの情報を取得する機能と、
    移動が間に合わない可能性がある場合、前記予約の見直しをユーザに通知する機能と
    を実行させるプログラム。