JP5930375B2

JP5930375B2 - スケジュール調整装置

Info

Publication number: JP5930375B2
Application number: JP2012030508A
Authority: JP
Inventors: 賢樹森下; 昌史榎本
Original assignee: 株式会社フォーカルワークス
Priority date: 2012-02-15
Filing date: 2012-02-15
Publication date: 2016-06-08
Anticipated expiration: 2032-02-15
Also published as: JP2013168003A

Description

本発明は、複数のユーザ間でスケジュールを調整する技術に関する。

ネットワークを介してユーザがスケジュールを書き込むことができるオンラインカレンダーが広く普及している。このようなオンラインカレンダーは、ネットワークを利用可能な環境さえ整っていれば、場所を問わずスケジュールの閲覧や追加が可能であるという利点がある。また、複数のユーザで一つのカレンダーを共有することも可能である。

複数のユーザ間で共通のスケジュール設定を自動的に行うシステムも知られている。例えば、特許文献１には、人員のスケジュールを管理するスケジュールデータベースを参照することで得られた参加予定者の空き時間帯から、期間設定手段で設定された期間内の複数の開催候補を抽出する手段を備えた、会議の設定管理を行う会議システムが開示されている。これによると、会議システムが会議の時間帯の候補を自動的に抽出し、いずれの候補が都合が良いかを問い合わせるメールを送信するので、会議のスケジュール設定を簡便に行うことができるとしている。

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

特許文献１に記載の技術では、会議に参加する全ての人員についてのスケジュールが前もってスケジュールデータベースに登録されている必要がある。しかしながら、そのデータベースの使用が義務づけられている企業内での会議を設定する場合などを除けば、あるイベントの参加者全員のスケジュールが共通のデータベースに登録されている確率は極めて低い。現実には、参加者毎に異なるスケジュール管理ソフトやウェブカレンダーを利用していたり、そのようなものを全く利用していなかったりするケースが大半である。このような場合、たとえ一部の参加者のスケジュールが共通のデータベースに登録されていたとしても、従来通り、まず誰か一人が会議などのイベントの候補日時をいくつか提案し、それに対して他のメンバーが参加可であるか否かの返信をしてスケジュールを調整する必要がある。しかも、全メンバーが参加可能な日時がなかった場合は、さらに誰か一人が別の候補日時を提案し、それを他のメンバーが確認するというように、全員の都合が付くまで同じプロセスをひたすら繰り返すことになる。このプロセスに要する作業時間は、メンバー数が増えるにつれて飛躍的に増大し、場合によってはエンドレスの煩雑なプロセスに陥ってしまう。したがって、特許文献１に記載の技術は、現実的な環境では実効性が低いと言える。

本発明はこうした状況に鑑みてなされたものであり、その目的は、あるイベントに参加する複数のメンバーの中に、その人のスケジュールがデータベースに一切登録されていないメンバーが存在する場合でも、メンバー間でスケジュールの調整を行えるようにする技術を提供することにある。

本発明の一態様は、複数のユーザ間でスケジュールを調整する装置である。この装置は、電子的なカレンダーをユーザ毎に保持するスケジュール保持部と、あるイベントについて集合すべき第１〜第ｎ（ｎは２以上の整数）のメンバーを複数のユーザの中から特定するメンバー特定部と、第１〜第ｎのメンバーのカレンダーを参照し、第１〜第ｎのメンバーに共通の空き日時から集合日時を決定するスケジュール管理部と、第１〜第ｎのメンバーのカレンダーにおいて、決定された集合日時にイベントを登録するイベント登録部と、第１〜第ｎのメンバーのうちスケジュール保持部内にカレンダーが存在しないメンバーについて、イベントが書き込まれていない状態でカレンダーを新規に生成するカレンダー生成部と、を備える。

この態様によると、イベントについて集合すべきメンバーの中に、スケジュール保持部にカレンダーが存在していないメンバーが存在する場合でも、そのユーザに対して新規にカレンダーを生成するので、スケジュール管理部によって決定された集合日時でイベントの登録を行うことができるようになる。

なお、「イベント」とは二人以上のユーザが集合する、ある程度以上の時間継続する予定のことであり、「メンバー」とはあるイベントの集合対象となるユーザのことを言う。また、イベントにおける「集合」とは、特定の場所にメンバー物理的に集まる場合のほか、各メンバーが特定の時刻にネットワークに接続可能な端末を操作できるように準備するような、距離をおいて集まる場合をも含む。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、あるイベントに参加する複数のメンバーの中に、スケジュールが把握されていないメンバーが存在する場合でも、スケジュールの調整を行うことが可能になる。

（ａ）〜（ｄ）は、本発明の概念を説明する図である。本発明の一実施形態に係るスケジュール調整システムの概略構成図である。スケジュールサーバのうち本実施形態に係るスケジュール調整に関与する部分の構成を示す図である。スケジュール調整部のより詳細な機能ブロック図である。スケジュール管理部のより詳細な機能ブロック図である。新規イベントの提案を希望するユーザが操作するクライアント端末に対して、イベント受付部によって提供される画面の遷移を説明する図である。ユーザ毎にスケジュール保持部内に保持されるカレンダーを構成するためのデータテーブルの一例を示す図である。データテーブルに基づき構成されるカレンダー画面の一例を示す図である。（ａ）〜（ｃ）は、スケジュール管理部によるスケジュール調整の変形例を説明する図である。スケジュール管理部によって候補日時が選定された後に、問い合わせ部から各メンバーに対して送信されるメール画面を説明する図である。スケジュール管理部によるイベントの集合日時の最終決定プロセスを説明するフローチャートである。店舗紹介部によって提供される画面の遷移を説明する図である。一実施形態に係るスケジュール調整プロセスを表すフローチャートである。イベントを簡便に登録できるイベント登録オブジェクトが配置されたウェブサイトの一例を示す図である。本発明の別の実施の形態に係るスケジュールサーバの構成を示す図である。図１５のリコメンド部の構成を示す図である。共通空き日時検索の様子を説明する図である。別の実施の形態に係るスケジュール調整プロセスを表すフローチャートである。

始めに、本発明の概念を図１（ａ）〜（ｄ）を参照して説明する。

図１（ａ）は、本発明に係るスケジュール調整システムの概略的なプロセスを説明するフローチャートである。まず、参加者を集めたいイベントと、そのイベントに参加するメンバーとをスケジュール調整システムに登録する（Ｓ１００）。すると、図１（ｂ）に示すように、各メンバー（ここではＡさん、Ｂさん、Ｃさんの三名について示す）のカレンダーがシステム内に生成される。次に、スケジュール調整システムが、各メンバーのカレンダーを参照し、他の予定が設定されていない日時の中からイベント日時の候補を選定する（Ｓ１０２）。図１（ｃ）に示すように、各メンバーのカレンダーには、既に確定しているいくつかの予定が×印で示されている。システムは、メンバー全員のカレンダーを参照して、全員に共通して予定のない日時をイベントの候補日時として選定する。図１（ｃ）では、各メンバーのカレンダーに、システムによって選定された候補日が○印で示される様子が描かれている。

続いて、スケジュール調整システムは、選定した候補日時にイベントを設定してよいか否かを問い合わせる通知を各メンバーに送信する（Ｓ１０４）。いずれかのメンバーから設定不可の返答が来ると（Ｓ１０４のＮ）、スケジュール調整システムは新たな候補日時を選定する。設定不可の返答をしたメンバーのカレンダーには、図１（ｃ）のカレンダー内にアンダーバー（＿）で示すように、その日時に既に他の何らかの予定があることが登録された様子が描かれている。次回以降の候補日時の選択では、設定不可の返答がなされた日時は対象外となる。このように、何らかの予定があることを随時登録することで、スケジュールの調整のために必要十分な情報がメンバーのカレンダーに蓄積される。全メンバーから設定可の返答が来ると（Ｓ１０６のＹ）、スケジュール調整システムはイベントの日時を確定して、全メンバーのカレンダーにイベントを登録する（Ｓ１０６）。図１（ｄ）には、図１（ｃ）で提案された候補日時にイベントが登録され、○印で示すようにカレンダーに表示される様子が描かれている。

本発明に係るスケジュール調整システムは、ビジネスの予定のスケジューリングよりも、飲み会やスポーツなどの遊びの予定のスケジューリングをする際に特に有用である。例えば、あるユーザが「近々飲みに行きたいな」と思いつき、何人かの友人に声を掛けるような場合を想定する。このような場合、ユーザは飲み会に誘いたい友人全員に電話やメールで連絡を取り、それぞれの予定を聞き出し、全員の都合がよい日時を調整しなければならない。人数が多かったり忙しい人が含まれたりする場合は、何度も日時設定と確認を繰り返すエンドレスの泥沼作業になってしまい、計画自体が放棄されてしまうようなこともある。

それに対し、詳細は後述するが、本発明では、飲み会を思いついたユーザはそのイベントをスケジュール調整システムに登録するだけでよい。その後は、スケジュール調整システムが友人のスケジュールを確認して全員の都合のよい日時を設定してくれる。したがって、電話やメールで連絡を取る場合に比べ作業量が激減する。

従来のスケジュール管理ソフトやウェブカレンダー等のツールでも、ユーザ間でイベントを共有することは可能であるが、その日時設定は誰かが行わなければならない。それに対し、本発明では、イベントの日時の設定もスケジュール調整システムが行うため、従来のツールに比べても圧倒的な利便性が提供される。

以下の実施の形態１では、メンバーの一人が何らかのイベントを登録し、他のメンバーがそのイベントに参加可能な日時をスケジュール調整システムが選定する、イベント契機の態様について説明する。その後、実施の形態２では、複数のメンバー間で共通の空き時間があるときに、その空き時間に入れることができるイベントをスケジュール調整システムが提案する、空き時間契機の態様について説明する。

実施の形態１．
この実施の形態１は、「行動派」と「受身派」の心理の違いに着目したスケジュール調整技術であると言うことができる。ここで、「行動派」とは、自らイベントを企画しそのイベントに参加する仲間を募る姿勢の人を指し、「受身派」とは、自らイベントを企画することはないが他人から誘われれば参加する意思のある人を指す。

この実施の形態１では、「行動派」が新たなイベントを提案して、スケジュール調整システムに登録し、スケジュール調整システムがメンバーのカレンダーから共通の空き日時を検索して「受身派」にイベントへの参加可否を問い合わせる。「受身派」は自発的にイベントを企画しなくても、システムからなされる問い合わせに対してＹｅｓ／Ｎｏで返答するだけでよい。したがって、受身派であっても心理的な抵抗なく予定を埋めていくことができる。また、各メンバーの回答は、スケジュール調整システムだけが把握するので、他のメンバーに予定を断った理由を詮索されることもなく、また、断ることに対して行き過ぎの気遣いをする必要もない。このため、ストレスを感じることなく、メンバー同士のイベントを決めることができる。

図２は、本発明の実施の形態１に係るスケジュール調整システム１０の概略構成図である。

スケジュールサーバ１２は、クライアント端末１６または外部サーバ１８からのイベントの登録を契機に複数のユーザ間でのスケジュール調整を実行する機能をブラウザベースのサービスとして提供するウェブサーバとして構成される。

スケジュールサーバ１２とクライアント端末１６は、ＬＡＮ（Local Area Network）、インターネット等のネットワーク１４を介して接続される。以下の説明では、サービスの主たる機能がスケジュールサーバ１２にあるものとして説明するが、例えばＪａｖａ（登録商標）アプレットのようにクライアント側に処理の主たる機能が移動するもの、サーバとクライアントの両方に処理の主たる機能であるＪａｖａ（登録商標）アプリケーションなどを配するものなど、他の態様で実現することも可能である。

クライアント端末１６は、例えばネットワーク接続機能を有するパーソナルコンピュータ（ＰＣ）であるが、ネットワーク接続機能を有する限り、ＰＤＡ、携帯電話、スマートフォン、ゲーム機などの任意のハードウェアであってもよい。クライアント端末１６とネットワーク１４との接続は、ケーブルを使用した有線接続であってもよいし、ＩＥＥＥ８０２．１ａ／ｂ／ｇ／ｎなどの無線ＬＡＮ、赤外線通信、パケット通信によるデータ通信等を利用した無線接続であってもよい。

クライアント端末１６は、ＣＰＵ（Central Processing Unit）、メインメモリ（ＲＡＭ：Random Access Memory）、ＲＯＭ（Read Only Memory）などの他、ポインティングデバイス、各種ボタン、タッチパネルなどのハードウェアに応じた任意の入力装置、ディスプレイなどの表示装置、データ通信を制御する通信制御装置等を備えており、周知のブラウザを介してスケジュールサーバ１２の提供するサービスを受けられるように構成されている。

上記のようなサーバ−クライアントシステムの構成自体は周知なので、これ以上の詳細な説明は省略する。

図３は、スケジュールサーバ１２のうち、本実施形態に係るスケジュール調整に関与する部分の構成を示す図である。この構成は、ハードウェア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

スケジュール調整部３０は、クライアント端末１６または外部サーバ１８からのイベントの登録を受け付ける。その後、スケジュール調整部３０は、イベントの集合対象となるメンバーを特定し、特定したメンバーのカレンダーを参照して当該イベントを設定可能な空き日時を検索し、各メンバーからの承認を待ってイベントの集合日時を決定する。スケジュール調整部３０の詳細な構成は図３を参照して説明する。

本実施形態において「イベント」とは、二人以上のユーザが参加する、ある程度以上の時間継続する予定のことを言い、あるイベントの参加対象ユーザを特に「メンバー」と呼ぶ。また、本実施形態では、イベントにメンバーが参加することを特に「集合」と呼ぶ。イベントの「集合」とは、特定の場所に物理的に集まる場合のほか、各メンバーが特定の時刻にネットワークに接続可能な端末を操作できるように準備する場合のように、距離をおいた集まりをも含む。

スケジュール保持部２４は、ユーザ毎に電子的なカレンダーを保持する。スケジュール保持部２４は、ユーザＩＤまたはユーザのメールアドレスに関連づけることでカレンダーをユーザ毎に管理する。

インタフェース部２２は、スケジュール調整部３０によるイベント登録によるのではなく、各ユーザによる自発的なカレンダーへの予定の入力を受け付け、この予定をスケジュール保持部２４内の各ユーザのカレンダーに反映させる。以下の説明では、インタフェース部２２を介してユーザが自身のカレンダーに入力するものを特に「スケジュール」と呼び、イベントと区別することがある。

インタフェース部２２は、スケジュール調整システム１０以外のオンラインカレンダーに保持されているカレンダーデータを、スケジュール保持部２４内の各ユーザのカレンダーにインポートする機能を備えていてもよい。

問い合わせ部２６は、スケジュール調整部３０によって空き日時が選択された後に、イベントの集合対象メンバーのメールアドレスに対して、その空き日時へのイベント登録を受け入れるか否かを問い合わせるメールを送信する。回答受付部２８は、このメールに対する各メンバーからの回答を受け付け、その結果をスケジュール調整部３０に渡す。

店舗紹介部６０は、スケジュール調整部３０によってイベントの集合日時が確定された後に、イベントを提案したユーザに対してそのイベントの集合場所等を紹介する。店舗情報保持部６２は、紹介すべき店舗の情報を保持する。

続いて、本実施形態に係るスケジュールサーバ１２の概略的な作用について説明する。スケジュールサーバ１２は、ユーザ毎に電子的なカレンダーをスケジュール保持部２４内に保持している。任意のユーザがあるイベントをスケジュール調整部３０に対して送信するとき、そのイベントのおおよその所要時間と集合すべきメンバーを少なくとも含むイベント情報をスケジュール調整部３０に与える。スケジュール調整部３０は、集合対象のメンバーのカレンダーをそれぞれ参照して、メンバーで共通してそのイベントの所要時間を確保可能である日時を検索し、問い合わせ部２６がこれを候補日時として各メンバーに受け入れの可否を問い合わせる。この候補日時に対する各メンバーの受け入れ可否の応答に基づき、スケジュール調整部３０が候補日時の中からいずれかを選びイベントの集合時間として確定させる。

図４は、図３に示したスケジュール調整部３０のさらに詳細な機能ブロック図である。

イベント受付部３２は、あるユーザからクライアント端末１６を介してなされるイベントの提案を受け付ける。受け付けたイベントの情報は、スケジュール保持部２４に一時的に格納される。イベント情報には、イベント名、所要時間、集合対象メンバーの情報が少なくとも含まれる。所要時間に関しては、必ずしもユーザが指定する必要はなく、予めシステムに組み込まれた所要時間がデフォルト値として利用されてもよい。イベントの受け付けについては、図５を参照してさらに後述する。

ユーザ情報保持部３４は、スケジュール保持部２４内にカレンダーが保持されているユーザに関する情報と、複数のメンバーから構成されるグループに関する情報を保持する。メンバーの情報には、少なくともユーザ名とメールアドレスが含まれ、これに加えて年齢、趣味、居住地、出身校などの属性情報が含まれてもよい。

メンバー特定部３６は、イベント受付部３２によって受け付けられたイベントの集合対象となるメンバーを特定する。また、メンバー特定部３６は、特定したメンバーのカレンダーがスケジュール保持部２４内に存在するか否かを確認する。スケジュール保持部２４内にカレンダーが存在しない新規のメンバーがいる場合、ユーザカレンダー生成部３８に指示して新規メンバーのカレンダーを生成させる。生成されたカレンダーはスケジュール保持部２４内に格納される。

スケジュール管理部４０は、メンバー特定部３６によって特定されたメンバーのカレンダーをそれぞれ参照して、メンバー間で共通の空き日時を一つ以上検索する。共通の空き日時を検索する具体的な方法については後述する。検索された一つ以上の空き日時は候補日時として問い合わせ部２６に送られ、各メンバーに対して都合が良い候補日時を問い合わせるメールが送信される。

回答管理部５２は、問い合わせ部２６によって送信されたメールに対して各メンバーから回答受付部２８が受け取る回答の有無を管理する。受け取られた回答は、一時的に回答保持部５４に保持される。回答管理部５２は、メールを送信してから所定の時間が経過したにも関わらず回答を受け取っていないメンバーがいる場合、リマインド部５６に対して回答のリマインドをするように指示する。回答管理部５２が受け取った回答の結果はスケジュール管理部４０に送られ、スケジュール管理部４０は、これに基づき候補日時の中から適切なものをイベントの集合日時として確定する。

イベント登録部５８は、イベントに集合可能なメンバーのカレンダーに対して、スケジュール管理部４０によって確定された集合日時にイベントを書き込む。書き込み後、イベント登録部５８は、イベントの日時が最終的に確定したことを知らせるメールを各メンバーに送信するように問い合わせ部２６に指示してもよい。このように、確定した日時を各メンバーのカレンダーに反映させることで、別のイベントが重複して登録されないようにすることができる。

図５は、スケジュール管理部４０のさらに詳細な機能ブロック図である。

空き日時検索部４２は、各メンバーのカレンダーを参照して、イベント受付部３２で受け付けられたイベントの所要時間を確保することができるメンバー間で共通の空き日時を検索する。検索された日時は、候補日時として候補日時保持部４６に一時的に保持される。

決定部４８は、回答管理部５２から受け取った回答に基づき、候補日時の中から最も適切な日時をイベントの開催日時として決定する。

空き日時を検索するとき、メンバー毎にイベントの集合場所への移動時間を考慮するようにしてもよい。移動時間計算部４４は、提案されたイベントの集合場所と、各メンバーのカレンダーで検索された空き日時の直前に確定済みのイベントの集合場所とを取得し、両地点間の移動に要する時間を計算する。この計算は、例えば内蔵の地図データを参照して両地点間の距離を求め、この距離を所定の計算式に代入して推定するようにしてもよいし、地図サイトや電車乗り換え検索サイトなどを提供する外部サーバ１８にアクセスして両地点を入力し、それらサイトによる移動時間の演算結果を受け取るようにしてもよい。当然なことに、この移動時間は各メンバーによって異なる。

この場合、空き日時検索部４２は、イベントの所要時間を確保することができるメンバー間で共通の空き日時を検索した後、今回のイベントと直前のイベントとの間にメンバー毎に計算された移動時間を確保することができるか否かを検証する。この検証の結果、移動時間を確保することができないメンバーが存在した場合、空き日時検索部４２は、その空き日時を後ろの時間にずらしたり候補日時から外したりするなどの処理を行う。代替的に、問い合わせ部２６が該当するメンバーに候補日時を問い合わせるメールの中に、「イベントへの移動時間が確保できないおそれがあります。」などのメッセージを追加するようにしてもよい。

続いて、図６ないし図１０を参照して、本実施形態に係るスケジュール調整部３０の詳細な動作について説明する。

図６は、新規イベントを提案したいユーザが操作するクライアント端末１６に対してイベント受付部３２によって提供される画面の遷移を説明する図である。

ユーザがブラウザを用いて所定のウェブサイトにアクセスすると、イベント受付部２０によってイベント登録画面１０２が送信される。画面１０２には、イベント名の入力欄１０４、イベントへの集合対象メンバーの入力欄１０６、イベントの調整目安の入力欄１０８、開始時間目安の入力欄１１０、所要時間の入力欄１１２が含まれる。

イベント名の入力欄１０４の右上には、イベントの選択肢を表示させるための選択ボタン１０４ａがある。ボタン１０４ａがクリックされると、イベント名選択画面１２０がユーザの端末に送信される。この画面１２０には、予め登録されているイベントの種類を選択できるラジオボタン１２４が含まれており、ユーザはいずれか一つの種類を選択した後に決定ボタン１２６をクリックして確定する。管理ボタン１２２をクリックして、ラジオボタン１２４に表示されるイベントの種類を新たに追加することもできる。

メンバー名の入力欄１０６の右上には、メンバーの選択肢を表示させるための選択ボタン１０６ａがある。ボタン１０６ａがクリックされると、メンバー選択画面１３０がユーザの端末に送信される。この画面１３０には、グループ選択欄１３４と、メンバー名表示部１３６が含まれる。グループ選択欄１３４には予め登録されているグループ名がプルダウンメニュー形式で表示され、ユーザがいずれかのグループを選択すると、その構成メンバーがメンバー名表示部１３６に表示されるように構成されている。グループおよびグループの構成メンバーの追加、削除、変更は、管理ボタン１３２をクリックして表示される管理画面（図示せず）で行うことができる。この管理画面では、メンバーに対応して必ず一つのメールアドレスの登録１３８が必要になっており、問い合わせ部２６による各メンバーへの問い合わせの際にはこのメールアドレスが使用される。グループまたはメンバーの追加、削除、変更があった場合、イベント受付部３２はその内容をユーザ情報保持部３４に反映させる。

なお、メンバーのメールアドレスは、メーラ、スケジューラ等のアプリケーションや、ウェブメール、ソーシャルネットワークサービス等のウェブ上のサービスから、インタフェース部２２を介してインポートされてもよい。

メンバー選択画面１３０には、グループ選択欄１３４に加えて、イベントの集合対象となるメンバーの属性を選択する属性選択欄（図示せず）が表示されてもよい。上述したように、ユーザ毎の属性は予めユーザ情報保持部３４に登録されているものとする。グループ選択欄１３４と属性選択欄の両方を用いることで、イベントへの集合対象となるメンバーを絞り込むことができる。

メンバー名表示部１３６において、各メンバー名の左にはメンバー選択チェックボックス１４０と必須メンバーチェックボックス１４２とが表示される。ユーザは、今回のイベントへの集合対象となるメンバーに対応するチェックボックス１４０をチェックする。また、必ず集合して欲しいメンバーについては、必須メンバーチェックボックス１４２を併せてチェックする。必須メンバーの扱いについては後述する。チェックボックス１４２、１４４へのチェック後、決定ボタン１４４のクリックによりメンバーが確定し、イベント登録画面１０２に戻る。

調整目安入力欄１０８では、現時点からどの程度の期間をおいて今回のイベントを設定するかを指定する。例えば、「最短で」「一週間以内」「一ヶ月以内」などの選択肢がプルダウンメニュー形式で表示される。代替的に、曜日または平日／休日を指定できるようにしてもよい。この場合、イベント名選択画面１２０で選択されたイベントに応じて自動的に曜日または平日／休日が指定されるように構成されてもよい。例えば画面１２０で「飲み会」が選択された場合は金曜日、「キャンプ」が選択された場合には休日が自動的に指定されるなどが考えられる。代替的に、特定の月や上旬／中旬／下旬の別を指定できたり、期間（例えば、○月○日から×月×日まで）を指定できるようにしてもよい。なお、調整目安は必ずしも指定される必要はない。

開始時間目安入力欄１１０では、今回のイベントの開始時間の目安を指定する。プルダウンメニュー形式で表示される選択肢は、例えば一時間刻みであってもよいし、午前中、午後、夜間などのようにおおざっぱな区切りであってもよい。開始時間の目安が、イベント名選択画面１２０で選択されたイベントに応じて自動的に設定されるように構成されてもよい。例えば、画面１２０で「飲み会」が選択された場合は、開始時間の目安が「夜間」に設定されるなどが考えられる。なお、開始時間の目安は必ずしも指定される必要はない。

所要時間入力欄１１２では、今回のイベントの所要時間を指定する。プルダウンメニュー形式で表示される選択肢は、例えば一時間刻みである。所要時間の目安も、イベント名選択画面１２０で選択されたイベントに応じて自動的に設定されるように構成されてもよい。

入力欄１０８、１１０、１１２で指定された調整目安、開始時間の目安、所要時間は、後述するスケジュール調整の際に参照される。

イベント登録画面１０２に対するイベント情報の入力が終了すると、ユーザは登録ボタン１１４をクリックする。これに応じて、イベント受付部３２は確認画面１５０をユーザの端末に送信する。修正ボタン１５４がクリックされた場合は、イベント登録画面１０２が再送信される。登録ボタン１５２がクリックされると、イベント受付部３２は、入力された内容を仮イベントとしてスケジュール保持部２４に格納するとともに、メッセージ画面１６０をユーザの端末に送信する。メッセージ画面１６０には、後述する店舗紹介機能の説明文、紹介画面へ移動するためのボタン１６２、イベント登録を終了させるためのボタン１６４とが含まれる。

イベント受付部３２によりイベントが受け付けられると、メンバー特定部３６は、そのイベントの集合対象メンバー名をイベント受付部３２から受け取る。メンバー特定部３６は、メンバーのメールアドレスをユーザ情報保持部３４から取得し、これを問い合わせ部２６に送る。また、メンバー特定部３６は、特定された全員のメンバーのカレンダーがスケジュール保持部２４内に既に存在しているか否かを確認する。カレンダーが存在しない新規メンバーがいる場合、ユーザカレンダー生成部３８は、その新規メンバーのカレンダーを生成する。

図７は、ユーザ毎にスケジュール保持部２４内に保持されるカレンダーを構成するためのデータテーブル１７０の一例を示す。データテーブル１７０は、ユーザ名１７２と、そのユーザのメールアドレス１７４とに関連づけられる。データテーブル１７０には、既にカレンダーに登録されているイベントの名称１７６、開始日時１７８、所要時間１８０、イベントの集合場所１８２、イベントに集合するグループ名１８４などの情報が含まれる。ユーザカレンダー生成部３８が新規メンバーのカレンダーを生成した場合は、イベントが登録されていない空のデータテーブルが生成される。

図８は、データテーブル１７０に基づき構成されるカレンダー画面１９０の一例を示す。カレンダーは、月表示、週表示、日表示などに切替可能に構成されるが、ここでは月表示の画面を示している。データテーブル１７０に保持されているイベントに対応して、２日と１０日にイベントが表示されていることが分かる。上述したように、各ユーザは、インタフェース部２２を介して自身のカレンダー画面１９０を自由に閲覧することができる。インタフェース部２２は、各ユーザのカレンダーを閲覧できる他ユーザの範囲を設定できるようにしてもよい。例えば、あらゆるユーザが自分のカレンダーを閲覧可能、特定のグループの構成メンバーのみが閲覧可能、自分のみが閲覧可能などの選択肢の中から選択できるようにしてもよい。

図４に戻り、空き日時検索部４２は、イベントの所要時間を確保することができるメンバー間で共通の空き日時を検索するのが通常の動作である。しかし、メンバーの数が多くなるほど、共通の空き日時が存在する可能性は低下する。そこで、空き日時検索部４２は、得きるだけ多くのメンバー間で共通して確保可能な空き日時を選び出し、メンバーの数が多い空き日時から順に、第１候補日時、第２候補日時、・・・のように選定するようにしてもよい。こうすることで、全メンバーで共通する空き日時が存在しないためにイベントが破棄される可能性を減らすことができる。また、各メンバーに対して、なるべく多くのメンバーが集合できる候補日時がどれなのかを知らせることができる。

代替的に、空き日時検索部４２は、イベント登録画面１０２で入力されるイベントの種類や開始時間目安に応じて、空き日時の検索方法を変更するようにしてもよい。これについて、図９（ａ）〜（ｃ）を参照して説明する。図９（ａ）〜（ｃ）は、メンバーＡ、Ｂ、Ｃの間でスケジュールを調整する様子を表しており、図中で上下方向に延びる長方形が、メンバーＡ、Ｂ、Ｃそれぞれのカレンダーにおける空き時間の長さを表している。

図９（ａ）は、花火大会やコンサートのように、開始時間目安と所要時間が確定しているイベントに対してメンバー間で空き時間を探すときの調整の様子を示す。この場合、空き日時検索部４２は、イベント（例えば、図９（ａ）の左端に示されている「コンサート」）の所要時間の前後に若干の余裕時間（例えば、３０分ずつ）を加えた空き時間が各メンバーのカレンダー内に存在するか否かを検索する。これは、イベント会場への入退場などを考慮して、その分の時間も確保しておく必要があるためである。このように、第三者によって開始時間が決められているイベントに対して調整する場合は、その開始時間より前に余裕を持たせるような時間設定をする。

図９（ｂ）は、会議や接待などのように、開始時間の若干の前後が許容されるイベントに対してメンバー間で空き時間を探すときの調整の様子を示す。この場合は、メンバーの全員参加を実現するために、空き日時検索部４２は、開始時間目安を多少前後させることで各メンバーのカレンダーで共通する空き日時を確保することができないかを試みる。前後させる時間の幅は、デフォルトであってもよいし、イベント登録画面１０２などで設定できるようにしてもよい。例えば、図９（ｂ）に示すように、「会議」イベントの開始予定時間では、いずれのメンバーも予定が空いていないが、会議の所要時間に相当する空き時間が全メンバーに共通して存在する場合は、空き日時検索部４２が「会議」イベントの開始時間を遅らせてイベントを設定するようにしてもよい。このようにすることで、メンバー全員の都合がつく日時を見つけ出しやすくなる。

図９（ｃ）は、飲み会や旅行などのように、一部のメンバーが途中で合流したり抜け出したりできるイベントに対してメンバー間で空き時間を探すときの調整の様子を示す。この場合、空き日時検索部４２は、グループのメンバーのうちできるだけ多くのメンバー間で共通する空き日時を検索する。言い換えると、一部のメンバーについてはその時間に他のイベントまたはスケジュールが入っていることを許容する。そして、問い合わせ部２６から送信されるメールにおいて、空き時間が共通していないメンバーに対しては、途中参加または途中退出すればそのイベントへの集合が可能であることを知らせるメッセージを含ませる。このメールに対して受け入れ可の回答がきた場合、当該メンバーのカレンダーでは、集合可能な時間帯のみにイベントを書き込むようにする。図９（ｃ）は、メンバーＡ、Ｃのカレンダーでは、「飲み会」イベントの所要時間全体にわたり空き時間が存在するが、メンバーＢのカレンダーではイベントの途中からしか空き時間が存在していない様子を示している。この場合、メンバーＡ、Ｃについては、「飲み会」イベントの全時間がそれぞれのカレンダーに登録されるのに対し、メンバーＢについては、集合可能な時間以降のみがカレンダーに登録されることになる。

図１０は、スケジュール管理部によってイベントの候補日時が選定された後に、問い合わせ部２６から各メンバーに対して送信されるメール画面を説明する図である。

スケジュール管理部４０は、候補日時を選定するとその内容を問い合わせ部２６に送り、問い合わせ部２６は各メンバーに対する問い合わせメール２００を作成する。問い合わせメール２００には、イベントへの集合を促すメッセージ２０２と、スケジュール管理部４０により選定された候補日時２０３と、候補日時の受け入れ可否を回答するためのリンク２０４、２０６とが含まれる。メッセージ２０２は定型文であってもよいし、イベントを提案したユーザが事前に作成した文章を入れるようにしてもよい。後者の場合、イベント登録画面１０２にメッセージ入力欄が含まれるようにするのが好ましい。

このメール２００を受け取った各メンバーは、「全てＯＫ」または「都合の悪い日がある」のいずれかのリンクをクリックする。このリンクは所定のウェブページのＵＲＬまたはＩＰアドレスを含んでおり、クリックに応じて各メンバーの端末のブラウザ上で対応するウェブページが表示される。「全てＯＫ」のリンク２０４がクリックされると、ページ２１０がブラウザに表示されるとともに、ブラウザから回答受付部２８に対して、メンバー名と候補日時の全てでイベントを受け入れ可能である旨の回答が送信される。「都合の悪い日がある」リンク２０６がクリックされると、ページ２１２がブラウザに表示される。このページ２１２には、都合の悪い日時を選択させるためのチェックボックス２１４が含まれる。メンバーが該当するチェックボックスを選択した後に返答ボタン２１６をクリックすると、ページ２１０がブラウザに表示されるとともに、ブラウザから回答受付部２８に対して、メンバー名と都合の悪い候補日時とを含む回答が送信される。

図４を再び参照して、回答管理部５２は、回答受付部２８に送信された各メンバーからの回答を一時的に回答保持部５４に格納する。所定の期間内に回答が送信されてこないメンバーが存在する場合、リマインド部５６は、問い合わせ部２６に対して、回答を促すリマインドメールを送信するように指示する。所定の回数リマインドメールを送信したにも関わらず回答がなされない場合、回答管理部５２は、当該メンバーは全ての候補日時を受け入れ不可であると判定してその旨をスケジュール管理部４０に伝える。

スケジュール管理部４０内の決定部４８は、回答管理部５２から受け取った各メンバーからの回答結果に基づき、候補日時の中から適切なものを選択する。この処理は、一例として以下のように行われる。

図１１は、スケジュール管理部４０によるイベントの集合日時の最終決定プロセスを説明するフローチャートである。まず、決定部４８は、集合対象となる全てのメンバーが受け入れ可能であると回答した候補日時があるか否かを判定する（Ｓ５０）。そのような候補日時がある場合（Ｓ５０のＹ）、決定部４８はその候補日時をイベントの集合日時として確定し、イベント登録部５８が全メンバーのカレンダーにそのイベントを登録する（Ｓ５２）。

全てのメンバーが受け入れ可とした候補日時が存在しない場合（Ｓ５０のＮ）、決定部４８は、メンバー選択画面１３０において必須メンバーが指定されたか否かを判定する（Ｓ５４）。必須メンバーが指定されていない場合（Ｓ５４のＮ）、全メンバーのうち予め定められた割合（例えば５０％）以上のメンバーが受け入れ可とした候補日時があるか否かを判定する（Ｓ５６）。そのような候補日時がある場合（Ｓ５６のＹ）、決定部４８はその候補日時をイベントの集合日時として確定し、イベント登録部５８は、その候補日時を受け入れ可と回答したメンバーのカレンダーにイベントを登録する（Ｓ５８）。さらに、イベント登録部５８は、受け入れ不可と回答したメンバーのカレンダーに、集合日時に何らかの予定があることを示すダミーイベントを登録する（Ｓ５８）。このダミーイベントをカレンダーに登録することで、別のイベントが提案されたときに、空き日時検索部４２がこの日時を空き日時と判定することがなくなる。したがって、一度イベントへの集合不可と回答したにもかかわらず、同じ日時へのイベント集合を促すメールを再び受け取るような事態を回避することができる。また、一度候補日時を受け入れ不可と回答したメンバーでも、自身のカレンダーを参照することで、都合がついた場合には集合できるイベントが存在することを知ることができる。ダミーイベントは、通常のイベントとは異なる色でカレンダーに表示されるようにしてもよい。

必須メンバーが指定されている場合（Ｓ５４のＹ）、決定部４８は、必須メンバーの全員が受け入れ可とした候補日時があるか否かを判定する（Ｓ６０）。そのような候補日時がある場合（Ｓ６０のＹ）、決定部４８はその候補日時をイベントの集合日時として確定し、イベント登録部５８は、その候補日時を受け入れ可と回答したメンバーのカレンダーにイベントを登録するとともに、受け入れ不可と回答したメンバーのカレンダーにダミーイベントを登録する（Ｓ５８）。

必須メンバーの全員が受け入れ可とした候補日時が存在しない場合（Ｓ６０のＮ）、および全メンバーのうち予め定められた割合以上のメンバーが受け入れ可とした候補日時が存在しない場合（Ｓ５６のＮ）、決定部４８は、今回提案されたイベントをスケジューリングすることが不可能であるとしてそのイベントを破棄し、イベントを提案したユーザに対して当該イベントは設定できない旨を知らせるメールを送信する（Ｓ６２）。

図１２は、店舗紹介部６０によって提供される画面の遷移を説明する図である。上述したように、店舗紹介部６０は、スケジュール調整部３０によってイベントの集合日時が確定されると、そのイベントを開催するのに適した店舗などを提案する。例えば、飲み会イベントが確定されると、そのイベントを開く居酒屋を紹介したり、夜間のイベントが確定されると、イベント会場近くのホテルを紹介したりすることが考えられる。

店舗紹介部６０は、イベントを提案したユーザの端末に対してモード選択画面２２０を送信する。モード選択画面２２０には、「おまかせモード」か「マニュアルモード」のいずれかを選択するためのラジオボタン２２２、登録ボタン２２６およびキャンセルボタン２２８が含まれる。ユーザはいずれかのモードを選択した後、登録ボタン２２６をクリックするか、またはキャンセルボタン２２８をクリックする。キャンセルボタン２２８がクリックされた場合、店舗紹介機能は実行されない。

「おまかせモード」が選択された場合、店舗紹介部６０は場所指定画面２３０をユーザの端末に送信する。場所指定画面２３０には、イベントの集合場所の入力欄２３４と選択ボタン２３６が含まれる。ユーザは、入力欄２３４に場所を入力した後、選択ボタン２３６をクリックして場所指定を完了する。

メンバーの住所および／または職場をユーザ情報保持部３４に登録しておくことで、店舗紹介部６０がイベントの集合場所を自動的に決定するように構成してもよい。例えば、店舗紹介部６０は、イベントに集合するメンバーの住所および／または職場の中間地点近傍をイベントの集合場所として決定してもよいし、沿線に住所および／または職場のあるメンバーが多い鉄道路線のターミナル駅などをイベントの集合場所として決定してもよい。場所指定画面２３０内の「メンバー管理」リンク２３２をクリックすることで、メンバー情報管理画面（図示せず）に移動してメンバーの住所および／または職場を入力することも可能である。

「マニュアルモード」が選択された場合、店舗紹介部６０は条件設定画面２４０をユーザの端末に送信する。条件設定画面２４０には、場所、店のカテゴリ、店の雰囲気、予算等の入力欄２４２と、各入力欄に対応する選択ボタン２４４とが含まれる。ユーザは、入力欄のうち少なくとも一つに条件を入力した後、選択ボタンをクリックして条件設定を完了する。

いずれかのモードで場所指定または条件設定が完了すると、店舗紹介部６０は店舗情報保持部６２に保持されている各店舗の場所、店のカテゴリ、店の雰囲気、予算などの情報に基づき、指定された場所に存在するか、条件に適合する店舗を選択する。店舗紹介部６０は、選択した店舗名とその情報（場所、クチコミ、実施中のプランなど）を含むメール２５０を作成して、イベントを提案したユーザの端末に送信する。このようにして、ユーザが店舗選択などを事前に考えずに思いつきでイベントを提案したとしても、適切な店舗を容易に見つけ出すことができる。

図１３は、本実施形態に係るスケジュール調整プロセスを表すフローチャートである。
まず、イベント受付部３２が、クライアント端末から新たなイベントの提案を受け付け、そのイベントをスケジュール保持部２４に一時的に格納する（Ｓ１０）。メンバー特定部３６は、イベント受付部３２によって受け付けられたイベントの集合対象となるメンバーを特定する。（Ｓ１２）。

メンバー特定部３６は、特定されたメンバーのカレンダーがスケジュール保持部２４内に存在するか否かを確認する。全メンバーのカレンダーが存在する場合（Ｓ１４のＹ）、Ｓ１８に進む。カレンダーの存在しないメンバーがいる場合（Ｓ１４のＮ）、ユーザカレンダー生成部３８がそのメンバーのカレンダーを新規作成してスケジュール保持部２４に格納する（Ｓ１６）。

スケジュール管理部４０は、メンバー特定部３６によって特定されたメンバーのカレンダーをそれぞれ参照し、イベントの所要時間に相当するメンバー共通の空き日時を検索する（Ｓ１８）。検索された一つ以上の空き日時は候補日時として問い合わせ部２６に送られ、問い合わせ部２６は、メンバーのメールアドレスに対して、受け入れ可能な候補日時を問い合わせるメールを送信する（Ｓ２０）。

スケジュール管理部４０は、各メンバーからの回答の結果に基づき、候補日時の中から最適と判断される一つを選択し、イベントの集合日時として確定する（Ｓ２２）。イベント登録部５８は、イベントに集合可能なメンバーのカレンダーに対して、スケジュール管理部４０によって確定された集合日時にイベントを書き込む（Ｓ２４）。店舗紹介部６０は、集合日時が確定したイベントの集合場所等の情報を、イベントを提案したユーザに対して紹介する（Ｓ２６）。

以上説明したように、本実施形態によれば、あるユーザが集合すべきメンバーを指定してイベントを提案するだけで、スケジュール調整部がメンバーのカレンダーを検索してメンバー共通の空き日時を見つけ出し、メンバーからの回答に基づきイベントの集合日時を決定し、各メンバーのカレンダーに反映させることができる。

一般に、イベントへの集合対象メンバーが多くなるほど、スケジュールの調整には時間と手間がかかりがちである。本実施形態ではスケジュールサーバに保持されている各メンバーのカレンダーから自動的にメンバー共通の空き日時が検索されるので、都合が良い日時を探すためにメンバー間で何度も連絡を取り合う必要がなくなり、イベントの企画者のスケジュール調整の負担が軽減される。

特に、本実施形態は、会議などのビジネス向けのイベントよりも、遊びなどの比較的気軽なイベントを設定する際に特に有用である。ビジネス会議のようなイベントは実施の期限が厳密なのが通常であるのに対し、遊びのイベントの場合、そのような期限がなく、仲間の時間が空いたときに実行されればよいことが多い。本実施形態によれば、イベントの登録時には集合対象のメンバーと大まかな所要時間を決めておくだけで、具体的な日時を設定することなく、メンバー間でスケジュールを調整することができるので、遊びのイベントの設定との親和性が高い。

また、本実施形態に係るスケジュール調整システムでは、イベントの集合対象メンバー全員のカレンダーが装置内に存在していない場合でも、新規のメンバーに対して自動的にカレンダーを生成してイベントの登録ができるようにした。今までこのカレンダーサービスを知らなかった新規のメンバーは、スケジュール調整システムからの問い合わせメールを受け取ることで、自身のカレンダーが自動的に生成されていることを知ることになる。こうして、当該カレンダーサービスに興味を持たせて今後カレンダーを使用してもらうきっかけを提供することができる。また、多数の既存ユーザからその新規メンバーを対象とするイベントが提案されていた場合、自分自身では一切予定の設定をしていないにも関わらず、スケジュール調整システムからの問い合わせに対して回答をしていくだけでカレンダーに次々とイベントが設定されていき予定が埋まっていくことになる。このようにして、新規ユーザのカレンダーサービスに対する興味を増進させることができる。

また、候補日時に対する受け入れ可否の回答結果はスケジュール調整システムのみが保持しているので、他メンバーに対する無用の気遣い等をする必要がなくなる。

さらに、本実施形態では、提案されたイベントを受け入れ不可と回答したメンバーのカレンダーに、そのイベントの候補日時に何らかの予定があることを示すダミーイベントを登録するようにした。このダミーイベントは、各メンバーのカレンダー上で、他のイベントまたは予定とは異なる態様で（例えば、日時にアンダーバーが付される（図１（ｃ）参照）、他のイベントとは色が異なるなど）表示されるようにしてもよい。このように、あるメンバーによって受け入れ不可とされたイベントであっても、代わりにダミーイベントをカレンダーに登録しておくことで、後日、別のイベントが提案されたときに、空き日時検索部４２がこの日時を空き日時と判定することがなくなる。したがって、あるメンバーがある候補日時に開催されるイベントへの集合不可と回答したことが過去にあるにもかかわらず、同じ候補日時または一部が重複する候補日時へのイベント集合を促すメールを再び受け取るような事態を回避することができる。

また、各メンバーの回答は、スケジュール調整システムだけが把握しているので、他のメンバーに予定を断った理由を詮索されることもなく、また、断ることに対して行き過ぎの気遣いをする必要もない。このため、ストレスを感じることなく、メンバー同士のイベントを決めることができる。

各ユーザによる自分のカレンダーへの予定記入、提案されたイベントを受け入れることによるイベントの登録、および提案されたイベントを拒否することによるダミーイベントの登録によって、各ユーザのカレンダーは次第に様々な予定やイベントによって埋められていくことになる。

以上のように、スケジュール管理技術にも関わらず、最初に具体的な日時を指定することなく、何らかのイベントがユーザや企業等から提案されることを契機として、特定のメンバー間での日時調整とイベントの登録が行われる点が、本実施の形態の特徴の一つである。

上述の実施の形態１では、ユーザがブラウザを用いて所定のウェブサイトにアクセスし、イベント登録画面１０２上でイベントに関する情報を入力することを述べた。しかしながら、この方法は入力に比較的手間がかかりユーザにとって負担になることもある。そこで、イベントの登録作業を簡素化する仕組みをウェブサイト上で提供するようにしてもよい。

図１４は、イベントを簡便に登録できるイベント登録オブジェクトが配置されたウェブサイト３００の一例を示す。このウェブサイトは、例えば映画、コンサート、演劇などのイベントの広告サイトであり、広告画面の他にイベント登録オブジェクト３０２が配置されている。ユーザがこのウェブサイトを見て、他の人と一緒にイベントに参加したいと考えた場合、イベント登録オブジェクト３０２をクリックする。すると、この情報がスケジュールサーバ１２のイベント受付部３２に送られ、イベント受付部３２がオブジェクトに関連づけられているイベント情報を取得し、スケジュール保持部２４に一時的に格納する。また、メンバー特定部３６は、オブジェクトをクリックしたユーザの情報をユーザ情報保持部３４から取得し、そのユーザが所属しているグループの中から、そのイベントを提案するのにふさわしいグループを選択する。一例として、グループに年代、趣味、出身地、居住地域、勤務先、所属校などの属性情報が付与されている場合、イベントに最も関連性が高い属性を有するグループを選択するようにしてもよい。例えば、ウェブサイトが映画の広告サイトであるときには、趣味に「映画」が指定されているグループを選択するなどが考えられる。

スケジュール管理部４０は、メンバー特定部３６で選択されたグループ毎に、全構成メンバーのカレンダーを参照して、少なくともある比率（例えば５０％）以上のメンバーで共通の空き日時を検索する。続いて、検索した空き日時と、広告しているイベントの開始時間とを比較し、イベントの開始時間が空き日時に含まれているグループを特定する。イベントの開始時間に共通の空き日時が存在しないグループはこの時点で対象外とする。

問い合わせ部２６は、スケジュール管理部４０によって特定された各グループの構成メンバーに対して、メンバー間で共通の空き日時があること、およびその空き日時でのイベント（この場合「映画」）参加の誘いがあることを知らせるメッセージを含んだメールを送信する。このメールの構成は、図９のメール２００と同様であってよい。回答管理部５２は各メンバーからの回答を受け取り、スケジュール管理部４０は、グループ毎にメンバーからの回答を集計し、上述の実施形態と同様にして最適なイベント集合日時を決定する。

様々なウェブサイト上にイベント登録オブジェクトを簡単に設置できるように、当該オブジェクトのＨＴＭＬコードを所定のウェブサイトで配布してもよい。

このように、イベント登録オブジェクトをイベント広告のウェブサイト上に設置することで、ユーザはオブジェクトをワンクリックするだけで、複数のメンバーにそのイベントを紹介できるのみならず、複数のメンバー間でのイベント参加スケジュールを調整することができる。したがって、イベントの登録に際してユーザに負担がかかることがなく、気軽にイベントを設定することができる。また、イベントの広告ウェブサイトを運営する側にとっても、イベントを気に入ったユーザがスケジュール調整システムを介してそのイベントの参加メンバーを集めてくれることになるため、スケジュール調整システムをイベントの販促ツールとして活用することが可能になる。

上述の実施の形態１では、各ユーザが自分の所属するグループに対してイベントを提案することを述べた。この代わりに、またはこれに加えて、イベント企画会社などの業者がイベントを提案し、これを契機としてスケジュール調整システムがメンバー間で共通の空き日時があるグループを検索し、その空き日時へのイベント設定をメンバーに提案するようにしてもよい。

例えば、イベント企画会社が本実施形態に係るスケジュール調整システムを活用してイベントの参加者を集めたいケースを想定する。この場合、イベント受付部３２が企画会社からのイベントを受け付けると、メンバー特定部３６は、ユーザ情報保持部３４を参照して、そのイベントを提案するのにふさわしいグループをいくつか選択する。一例として、グループに年代、趣味、出身地、居住地域、勤務先、所属校などの属性情報が付与されている場合、イベント企画会社が指定した属性を有するグループを選択するようにしてもよい。例えば、「ワインの試飲会」のイベントを提案するときには、趣味に「グルメ」「ワイン」などが指定されているグループを選択するなどが考えられる。

スケジュール管理部４０は、メンバー特定部３６で選択されたグループ毎に、全構成メンバーのカレンダーを参照して、少なくともある比率（例えば５０％）以上のメンバーで共通の空き日時を検索する。続いて、検索した空き日時と、イベント企画会社から提案されたイベントの開始時間とを比較し、イベントの開始時間が空き日時に含まれているグループを特定する。イベントの開始時間に共通の空き日時が存在しないグループはこの時点で対象外とする。

問い合わせ部２６は、スケジュール管理部４０によって特定された各グループの構成メンバーに対して、メンバー間で共通の空き日時があること、およびその空き日時にイベント（この場合「ワインの試飲会」）があることを知らせるメッセージを含んだメールを送信する。このメールの構成は、図９のメール２００と同様であってよい。回答管理部５２は各メンバーからの回答を受け取り、スケジュール管理部４０は、グループ毎にメンバーからの回答を集計し、上述の実施形態と同様にして最適なイベント集合日時を決定する。

イベント企画会社等によって企画されるイベント毎に、イベント受付部３２、メンバー特定部３６、スケジュール管理部４０等を含むスケジュール調整モジュールが存在し、各スケジュール調整モジュールが他のモジュールとは無関係に動作するようにスケジュールサーバを構成してもよい。この場合、各スケジュール調整モジュールは他のモジュールによる空き時間検索とは独立して動作するため、一部のユーザに対しては、同一の空き日時に二つ以上のモジュールからそれぞれ異なるイベントが提案されることもある。

ユーザによって登録されるイベントを処理するスケジュール調整モジュールと、イベント企画会社等によって登録されるイベントを処理するスケジュール調整モジュールとの間で、優先順序を付けるようにしてもよい。例えば、前者によるスケジュール調整を優先させ、そのイベントが確定した後に、後者によるスケジュール調整を行うようにしてもよい。

上述の実施の形態１では、空き日時検索部４２がメンバー共通の空き日時を複数見つけ出した場合、問い合わせ部２６がメンバーに対して複数の候補日時を含むメールを送信することを述べた。この代わりに、問い合わせ部２６は、候補日時のうちいずれか一つを含むメールを送信するようにしてもよい。スケジュール管理部４０が、全てのメンバーまたは所定の割合以上のメンバーからその候補日時について受け入れ可の回答が得られなかったと判定した場合、問い合わせ部２６が別の候補日時を含むメールを改めてメンバーに送信するようにしてもよい。全てのメンバーまたは所定の割合以上のメンバーから候補日時について受け入れ可の回答が得られるまで、上記ステップが繰り返される。このような構成にすることで、複数の空き候補日時をメンバーに対して提示したためにかえって票割れが生じ、イベント日時を確定できなくなるような事態を回避することができる。

上述の実施の形態１では、メンバー選択画面１３０において必須メンバーが指定されている場合、空き日時検索部４２は、まず必須メンバーのカレンダーを参照して全員に共通する空き日時を検索し、続いて、必須メンバー以外のメンバーのカレンダーを参照して、必須メンバーについて検索された空き日時の中から、残りのメンバーのうち最も多くのメンバーの予定が空いている日時を候補日時として選択するようにしてもよい。このようにすれば、少なくとも必須メンバーについては確実に集合可能な日時を空き候補日時として選定することができる。

実施の形態２．
上述の実施形態１では、ユーザや企業からのイベントの提案を契機にして、複数のメンバー間でスケジュールを調整することを説明した。実施の形態２では、あるグループのメンバー間で共通の空き日時が存在することをスケジュール調整システムが検出し、その空き日時に設定すべきイベントをメンバーに提案する。

図１５は、実施の形態２に係るスケジュールサーバ３１２の構成を示す機能ブロック図である。以下の説明において、実施の形態１で説明した各ブロックと同じ符号が付されたブロックは、同様の機能を有するものとする。

実施の形態２では、スケジュールサーバ３１２にリコメンド部３１６が追加される。このリコメンド部３１６は、所定のタイミングで各グループに属するメンバー間で共通して存在する空き日時を検索し、その空き日時に入れることができるイベントを提案する機能を有している。

図１６は、図１５に示したリコメンド部３１６の詳細な機能ブロック図である。リコメンド部３１６は、共通空き日時検索部３１８、イベント検索部３２０、イベント保持部３２２を含む。

共通空き日時検索部３１８は、所定のタイミングで、例えば定期的に、ユーザ情報保持部３４（図４参照）から各グループの構成メンバーの情報を取得し、スケジュール保持部２４に格納されている各メンバーのカレンダーを参照する。そして、グループ毎に、メンバー間で共通して存在する空き日時を検索する。

図１７は、共通空き日時検索部３１８による検索の様子を示す図である。ここでは、あるグループを構成するメンバーＡ、Ｂ、Ｃの３人の共通空き時間を検索する例を説明する。図中で上下方向に延びる長方形が、各メンバーのカレンダーにおける空き時間を模式的に表している。図示のように、メンバー毎に空き時間が異なるが、図中にハッチングで示す時間帯が共通している。共通空き日時検索部３１８は、この時間帯を共通空き日時として検出する。

図１６に戻り、イベント保持部３２２は、空き日時に設定するイベントに関する情報を保持する。イベントに関する情報には、イベント名、イベントの開始時間の目安、イベントの所要時間の目安などが含まれる。イベントには例えば以下のものが含まれる。

１．メンバーの一人が、開催日時の目安を指定することなく、共通の空き時間があるときに開催したいイベントとして登録されたイベント。
例えば、グループ内でスポーツイベント（スキー、ゴルフなど）や飲み会などを開催したいが、メンバーの空き時間が見つかったときに行えばよいイベントなどが考えられる。このようなイベントは、所定の図６に示したイベント登録画面を通じてイベント保持部３２２に登録できるように構成してもよい。

２．過去にグループで開催されたことのあるイベント。
イベント保持部３２２は、スケジュール保持部２４から過去にグループ内で設定されたイベントを検索し、そのイベントを再び開催するのに適した時期が訪れたときに提案すべきものを保持しておく。一例として、去年の冬にスキーのイベントが設定されたグループにおいて、メンバー間で共通の空き日時が存在することが検出された場合、各メンバーに対して「今年もそろそろスキーの季節です。予定の調整をしますか？」のようなメッセージを送り、メンバー間で共通の空き日時があることを示唆して新規イベントの登録を促すことなどが考えられる。

３．イベント保持部３２２が、イベント企画会社のサーバ等の外部サーバを検索して収集したイベント。
スポーツ、コンサート、演劇、映画等の、開催日時が予め決まっているイベント、飲食店や宿泊施設などにおける期間が限定されたイベントなどが考えられる。

イベント検索部３２０は、共通空き日時検索部３１８によって検索された共通空き日時に設定可能であるイベントを、イベント保持部３２２から検索する。イベント検索部３２０は、イベントの種類によっては、共通空き日時とは開始時間または終了時間が若干ずれているものも含めて検索してもよい。

図１８は、実施の形態２に係るスケジュール調整プロセスを表すフローチャートである。

まず、共通空き日時検索部３１８が、ユーザ情報保持部３４に記録されているグループ毎に、所属するメンバーのカレンダーをそれぞれ参照し、メンバー間で共通の空き日時がないか検索する（Ｓ１１２）。共通の空き日時が存在する場合（Ｓ１１４のＹ）、イベント検索部３２０は、その空き日時に設定可能であるイベントをイベント保持部３２２から検索する（Ｓ１１６）。適切なイベントが見つからない場合（Ｓ１１８のＮ）、問い合わせ部２６から、各メンバーに対して共通の空き日時が存在することを通知するメールを送信する（Ｓ１２４）。例えば、メールには、「友人達としばらく会っていませんね。来週なら調整できそうです。」のようなメッセージを含めてもよい。このような通知をすることで、メンバーに対して何らかの新規のイベントを企画してスケジュール調整システムに登録させるきっかけを与えることができる。

適切なイベントが見つかった場合（Ｓ１１８のＹ）、問い合わせ部２６から各メンバーのメールアドレスに対して、メンバー間で共通の空き日時が存在しかつその空き日時に参加可能であるイベントがある旨を通知し、そのイベントへの集合可否を問い合わせるメールを送信する（Ｓ１２０）。このメールには、イベントに関連づけて予めイベント保持部３２２に記憶されているメッセージを含めてもよい。例えば、来週の火曜日に共通する空き時間が検出され、提案するイベントが居酒屋のキャンペーンである場合、「来週の火曜日は居酒屋○○で飲み放題キャンペーンをやっていますが、グループでイベントを企画しますか？」のようなメッセージを追加するなどである。

スケジュール管理部４０は、各メンバーからのイベントへの集合可否に関する回答を受け取る。そして、イベント登録部５８は、イベントに集合可能と回答したメンバーのカレンダーに対して、そのイベントを書き込むとともに、集合不可と回答したメンバーのカレンダーに、空き日時に何らかの予定があることを示すダミーイベントを登録する（Ｓ１２２）。このダミーイベントをカレンダーに登録することで、別のイベントが提案されたときに、共通空き日時検索部３１８がこの日時を空き日時と判定することがなくなる。したがって、一度イベントへの集合不可と回答したにもかかわらず、同じ日時へのイベント集合を促すメールを再び受け取るような事態を回避することができる。

以上説明したように、実施の形態２によれば、イベントの具体的な提案がない場合でも、スケジュール調整システムがメンバーの共通の空き時間を検出する。空き時間の検出はグループのメンバーの意思に無関係に行われる。スケジュール調整システムからグループのメンバー間で共通の空き時間が存在することを通知することによって、何らかのイベントを企画しようというきっかけをメンバーに与えることができる。

また、スケジュール調整システムが検出した空き時間に設定可能なイベントを提案してくれるため、メンバーが自発的にイベントを企画しなくても適切なイベントをグループ内で簡便に設定することができる。

また、不定期に特定のメンバーで開催されるイベント、例えば季節毎のイベントなどがある場合でも、システムが共通の空き時間を検出してその空き時間にイベントを設定することを提案してくれるため、イベントの設定忘れや、長期間イベントが開催されなくなるという事態を回避することができる。

以上のように、スケジュール管理技術に関わらず、最初に具体的な日時を指定する必要がなく、特定のメンバー間で共通の空き日時が存在することを契機としてイベントの提案と登録が行われる点が、本実施の形態の特徴の一つである。

イベント保持部３２２に格納されているイベント毎に、共通空き日時検索部３１８が存在し、各検索部３１８が他の検索部とは無関係に動作するようにリコメンド部３１０を構成してもよい。この場合、各検索部３１８は他の検索部による共通空き日時検索とは独立して動作するため、一部のユーザに対しては、同一の空き日時に二つ以上のモジュールからそれぞれ異なるイベントが提案されることもある。

上述の実施の形態２では、スケジュール調整システムがあるグループのメンバー間で共通の空き日時があることを検出し、その空き日時に設定すべきイベントをメンバーに提案することを述べた。しかしながら、空き日時の検出は複数人に限られず、ユーザ毎の空き日時をスケジュール調整システムが検出してもよい。この場合、スケジュール調整システムは、検出した空き日時に設定することができるイベントを、イベント情報が登録されている外部サーバ等から検索してユーザ毎に提案してもよい。さらに、スケジュール調整システムは、何らかの規則にしたがう空き日時をユーザ毎に検索してもよい。例えば、あるユーザのカレンダーを定期的に参照して、毎週火曜日には予定が設定されていないことが多いことを検出した場合、スケジュール調整システムは、毎週火曜日に定期的に開催されるイベントを外部サーバ等から検索してそのユーザに提案してもよい。このとき、「毎週火曜日には予定が入っていないようですが、英会話スクールに通ってみてはいかがですか？」などのメッセージをそのユーザに送信してもよい。

以上、本発明をいくつかの実施の形態をもとに説明した。これらの実施の形態はあくまで例示であり、実施の形態同士の任意の組合せ、実施の形態の各構成要素や各処理プロセスの任意の組合せなどの変形例もまた、本発明の範囲にあることは当業者に理解されるところである。

上述したように、本発明に係るスケジュール調整装置は、ビジネス用途よりも遊びの用途に対する親和性が特に高い。そのため、クライアント端末が、ネットワーク接続機能を備えるいわゆるフィーチャーフォンやスマートフォン、タブレット端末などの、ユーザが常時携帯しどこでも気軽に使えるモバイル端末であると、一層便利である。例えば、あるユーザが「近々飲みに行きたいな」と思いつき、何人かの友人に声を掛けるような場合、いちいち全員のスケジュールを確認して日時を調整する作業は極めて煩雑である。本発明に係るスケジュール調整をモバイル端末を通じて利用することで、イベントを思いついた時点でそのイベントを登録するだけで簡便に参加者を集めることができるという、過去のツールでは実現不可能であった極めて有利な効果が発揮される。

本発明は、上述の各実施形態に限定されるものではなく、当業者の知識に基づいて各種の設計変更等の変形を加えることも可能である。各図に示す構成は、一例を説明するためのもので、同様な機能を達成できる構成であれば、適宜変更可能である。

実施の形態では、ユーザがクライアント端末のブラウザを介してスケジュールサーバからのサービスを受けることを述べたが、クライアント端末側に、スケジュールサーバに接続して簡便にサービスを受けられるように構成された専用のアプリケーションがインストールされていてもよい。このアプリケーションには、自身および他人のカレンダーを参照する機能、新規イベントを登録する機能、候補日時の問い合わせメールを送受信する機能のうち一つまたは複数が備えられていてもよい。

実施の形態では、新規イベントを提案したいユーザが、自身のクライアント端末を操作してサーバの提供する所定のサイトにアクセスし、イベント受付部を通じてイベントを登録することを述べた。これに加えて、またはこの代わりに、ユーザが自身のクライアント端末から所定のメールアドレスに対して、予め定められた形式にしたがって作成された電子メールを送信することで、イベント受付部を通じてイベントを登録できるようにスケジュール調整システムを構成してもよい。

実施の形態では、各機能ブロックが単一のスケジュールサーバに配置され、そのサーバからクライアント端末に対してサービスが提供されることを述べた。しかしながら、各機能ブロックに対応する機能が、ネットワークで接続可能である複数の機器に分散していてもよい。また、一部または全ての機能ブロックに対応する機能がクライアント端末側に存在していてもよい。これらの場合、本発明をスケジュール調整システムとして実装することができる。例えば、スケジュール保持部がクライアント端末に存在しその端末のユーザの電子的なカレンダーのみを保持しており、スケジュール管理部が各クライアント端末内のスケジュール保持部を参照するようにシステムを構成してもよい。

あるいは、統合的なスケジュールサーバが存在せず、全ての機能ブロックに対応する機能が各メンバーのクライアント端末に存在するシステムとして本発明を実装してもよい。この場合、いずれかのクライアント端末が一時的にマスタとなりサーバとして動作するように構成してもよいし、全ての端末が対等な関係で動作する、いわゆるピアツーピアシステムとして構成してもよい。

ユーザの属性情報として、そのユーザがイベントの集合に対してどのような性向を持つかを表すラベルを付与するようにしてもよい。例えば、多人数のイベントに余り参加しないユーザには「一匹狼」、インドアイベントであれば参加するユーザであれば「こたつの猫」のようなラベルを付与してもよい。このラベルは、ユーザが自分で設定できるように構成してもよいし、過去の複数のイベントへの集合の傾向に基づきスケジュール保持部が設定するように構成してもよい。

各ユーザが、空き日時として検索されたくない時間帯を自身のカレンダー上で指定できるように構成してもよい。例えば、特定の時間帯、曜日、日付にはイベントを入れたくない場合、予めこの指定をしておくことで、スケジュール管理部は指定された時間帯をそのユーザの空き日時として検索しなくなる。

イベントの種類に対して、そのイベントが仕事であるか遊びであるかを示す属性が予め付与されており、ユーザは、時間帯毎に設定可能なイベントの属性をカレンダー上で指定できるように構成されていてもよい。例えば、９時から１８時までは仕事のイベントの設定のみを受け付け、１８時から２４時までは遊びのイベントの設定のみを受け付けるなどである。この代わりに、またはこれに加えて、スケジュール調整部が、イベントの種類に応じて候補日時を検索する時間帯を調整するようにしてもよい。例えば、仕事のイベントの候補日時を検索する場合は、平日の９時から１８時まで、遊びのイベントの候補日時を検索する場合は、平日の１８時以降と休日のみを対象にするなどが考えられる。このような設定をしておくことで、例えば会議が２３時から設定されたり、飲み会が朝９時から設定されたりするなどの不都合を回避することができる。

あるユーザに対して、異なるグループから同時に複数のイベントが提案されることも考えられる。この場合、空き日時検索部４２は、ユーザ毎に予め設定された基準にしたがっていずれかのイベントの候補日時を優先的に確保するようにしてもよい。例えば、あるユーザが「仕事優先」という基準を設定しており、会議のイベントと遊びのイベントが提案された場合、空き日時検索部４２は、会議のイベントに対する候補日時を先に確保し、その後遊びのイベントの候補日時を確保するようにしてもよい。

スケジュール管理部４０は、イベントの特性に応じて適切な人数のメンバーが集まるようにスケジュールを調整してもよい。例えば、イベントが「麻雀」である場合には、メンバーの数が４の倍数になるような候補日時を選定するなどが考えられる。また、スケジュール管理部４０は、所定の条件を満足したときにのみイベントの集合日時を確定するようにしてもよい。例えば、５人以上集まった場合にはイベントを開催したいような場合に、スケジュール管理部４０は、複数の候補日時を含む問い合わせに対して５人以上から受け入れ可の回答があったものを集合日時として確定してもよい。５人未満からしか受け入れ可の回答がなかった場合には、そのイベントを取り消し、問い合わせ部２６から回答をしたメンバーに対してその旨を通知するようにしてもよい。５人以上から受け入れ可の回答があった候補日時が複数ある場合には、最も人数の多いものをイベントの集合日時として確定してもよいし、全ての候補日時をイベントの集合日時として確定してもよい。この実施例は、例えば何らかのインストラクター（例えばヨガなど）が自分の都合の良い日時にスクールを開催したいときなどに特に有効である。インストラクターは、自分の都合の良い日時を指定した多数のイベントを登録しておけば、スケジュール調整システムによって、採算の合う人数（例えば５人）が集合可能な日時だけに自動的にスクールイベントが設定されるので、生徒との連絡等の煩わしさが排除される。

スケジュールサーバ１２は、登録されたイベント毎に、イベントの集合メンバーのみが書き込みできるネット掲示板を提供してもよい。この掲示板への書き込みが、集合メンバーのメールアドレスにメール送信されるように構成してもよい。これによって、イベントに遅れる、現地合流するなどのメッセージをメンバーに容易に通知することが可能になる。掲示板の代わりに、イベントの集合メンバーに対して投稿内容が送信されるようなミニブログのアカウントを取得するようにしてもよい。

１０スケジュール調整システム、１２スケジュールサーバ、１４ネットワーク、１６クライアント端末、２０イベント受付部、２２インタフェース部、２４スケジュール保持部、２６問い合わせ部、２８回答受付部、３０スケジュール調整部、３４ユーザ情報保持部、３６メンバー特定部、３８ユーザカレンダー生成部、４０スケジュール管理部、４２空き日時検索部、４４移動時間計算部、４６候補日時保持部、４８決定部、５２回答管理部、５４回答保持部、５６リマインド部、５８イベント登録部、６０店舗紹介部、６２店舗情報保持部。

Claims

複数のユーザ間でスケジュールを調整する装置であって、
電子的なカレンダーをユーザ毎に保持するスケジュール保持部と、
あるイベントについて集合すべき第１〜第ｎ（ｎは２以上の整数）のメンバーを前記複数のユーザの中から特定するメンバー特定部と、
第１〜第ｎのメンバーのカレンダーを参照し、第１〜第ｎのメンバーに共通の空き日時から集合の候補日時を決定するスケジュール管理部と、
前記候補日時を受け入れるか否かを第１〜第ｎのメンバーに問い合わせる問い合わせ部と、
イベント登録部と、
を備え、
前記スケジュール管理部は、問い合わせに対する第１〜第ｎのメンバーからの回答に基づき前記イベントの集合日時を決定し、
前記イベント登録部は、第１〜第ｎのメンバーのうち前記候補日時を受け入れる旨の回答をしたメンバーのカレンダーにおいて、前記スケジュール管理部により決定された集合日時に前記イベントを登録し、
第ｋ（ｋ＝１，２，・・・ｎ）のメンバーが、前記候補日時に対して拒否の回答をしたとき、前記イベント登録部は、第ｋのメンバーのカレンダーにおいて、前記候補日時に何らかのスケジュールが存在していることを示すダミーイベントを登録し、
前記スケジュール管理部は、前記イベントとは別のイベントの候補日時を決定する場合に、第ｋのメンバーのカレンダーに前記ダミーイベントが登録されていれば、前記ダミーイベントの日時を空き日時でないと判定することを特徴とするスケジュール調整装置。
各メンバーによる自身のカレンダーへのスケジュールの書き込みを実現するインタフェース部をさらに備え、
前記スケジュール管理部は、各メンバーが自身で書き込んだスケジュールの日時と重複しないようにイベントの集合日時を決定することを特徴とする請求項１に記載のスケジュール調整装置。
前記スケジュール管理部は、イベントに集合するメンバーの数がイベントの特性に応じた人数になるようにイベントの集合日時を決定することを特徴とする請求項１または２に記載のスケジュール調整装置。
前記スケジュール管理部は、イベントの所要時間も条件に入れた上で第１〜第ｎのメンバーに共通の空き日時から前記集合日時を決定することを特徴とする請求項１から３のいずれかに記載のスケジュール調整装置。
前記メンバー特定部は、あるイベントについて必ず集合すべき必須メンバーを特定し、
前記スケジュール管理部は、最初に必須メンバーのカレンダーを参照し、共通の空き日時を初期候補日時として選定することを特徴とする請求項１から４のいずれかに記載のスケジュール調整装置。
前記スケジュール保持部は、メンバーとカレンダーとをメンバーのメールアドレスに関連づけて保持し、
前記メンバー特定部は、メンバーをそのメールアドレスで特定することを特徴とする請求項１から５のいずれかに記載のスケジュール調整装置。
前記スケジュール管理部によりイベントの集合日時が確定された後、そのイベントの開催に適した店舗を紹介する店舗紹介部をさらに備えることを特徴とする請求項１から６のいずれかに記載のスケジュール調整装置。
複数のユーザ間でスケジュールを調整する装置であって、
電子的なカレンダーをユーザ毎に保持するスケジュール保持部と、
イベントを広告する内容のウェブサイト上に表示されるイベント登録オブジェクトが、該ウェブサイトを閲覧するユーザにより選択されたときに本装置へ送信される情報であって、前記イベント登録オブジェクトがユーザにより選択されたことを示す情報に基づいて、該ユーザが所属しているグループを選択するメンバー特定部と、
選択されたグループの構成メンバーのカレンダーを参照し、該構成メンバー間で共通している空き日時を探し出すスケジュール管理部と、
前記構成メンバーに対して、前記空き日時での前記イベントへの参加を促すメッセージを送信する問い合わせ部と、
を備えることを特徴とするスケジュール調整装置。
イベントをメンバーまたはメンバー以外のイベント開催者から受け付ける受付部をさらに備え、
前記スケジュール管理部は、前記イベントに集合するメンバーの数が該イベントの特性に応じた人数になるようにイベントの集合日時を決定することを特徴とする請求項８に記載のスケジュール調整装置。