(57)【要約】【課題】ランチが成立しやすいメンバーをマッチングすること。【解決手段】情報処理装置１０１は、昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出する。図１の例では、４０分以上の共通する時間帯「１２：００〜１２：４０」が昼休みの時間帯に含まれるユーザＡ，Ｃ，Ｅが抽出される。情報処理装置１０１は、抽出した複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行う。図１の例では、各ユーザＡ，Ｃ，Ｅのアドレス宛に招待メール１１０が送信される。招待メール１１０には、ランチの開催日時、各メンバーの情報などが含まれる。【選択図】図１
2016045737.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータが、
昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出し、
抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行う、
処理を実行することを特徴とするランチのメンバー通知方法。
【請求項２】
抽出される前記複数のユーザは、共通する組織に属する、ことを特徴とする請求項１に記載のランチのメンバー通知方法。
【請求項３】
前記通知は、前記ランチを食べる場所の候補としての飲食店の情報を含む、ことを特徴とする請求項１または２に記載のランチのメンバー通知方法。
【請求項４】
前記コンピュータが、
前記通知に含まれる前記飲食店の選択がなされると、前記メンバーについてのランチの予約メッセージを送信する、処理を実行することを特徴とする請求項３に記載のランチのメンバー通知方法。
【請求項５】
前記通知は、前記ランチを食べる場所の候補としての飲食店のクーポンを含む、ことを特徴とする請求項１〜４のいずれか一つに記載のランチのメンバー通知方法。
【請求項６】
前記所定の時間幅以上の共通する時間帯は、抽出される前記複数のユーザのそれぞれについて登録されたスケジュール情報が、既に他の予定で埋まっていない、ことを特徴とする請求項１〜５のいずれか一つに記載のランチのメンバー通知方法。
【請求項７】
前記通知は、前記ランチを食べることに同意するか否かの問い合わせを含み、
前記コンピュータが、
該問い合わせに対して前記複数のユーザのうち所定数以上のユーザについて同意する旨の応答を受信すると、抽出した前記複数のユーザのそれぞれのスケジュールに前記ランチの予定を登録する、処理を実行することを特徴とする請求項１〜６のいずれか一つに記載のランチのメンバー通知方法。
【請求項８】
前記コンピュータが、
前記抽出した前記複数のユーザの中に、お弁当を持参する旨の情報が設定されたユーザが含まれる場合、前記抽出した前記複数のユーザに対して、お弁当を持参可能な飲食場所として登録された飲食場所を通知することを特徴とする請求項１〜７のいずれか一つに記載のランチのメンバー通知方法。
【請求項９】
コンピュータが、
スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出し、
抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行う、
処理を実行することを特徴とするランチのメンバー通知方法。
【請求項１０】
コンピュータに、
昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出し、
抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行う、
処理を実行させることを特徴とするランチのメンバー通知プログラム。
【請求項１１】
コンピュータに、
スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出し、
抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行う、
処理を実行させることを特徴とするランチのメンバー通知プログラム。
【請求項１２】
昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出し、抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行う制御部、
を有することを特徴とする情報処理装置。
【請求項１３】
スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出し、抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行う制御部、
を有することを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ランチのメンバー通知方法、ランチのメンバー通知プログラム、および情報処理装置に関する。
【背景技術】
【０００２】
従来、面識のない人とのランチの機会を提供するためのサービスがある。例えば、ユーザが「普段の勤務先」、「肩書き・職種」、「最寄りのランチエリア」を設定して、ランチのペアとなる人を選択すると、サービス提供者側からランチの相手（他のペア）が紹介され、互いに相手を気に入った場合にランチが成立するサービスがある。
【０００３】
先行技術としては、参加者用端末が、運営者側のコンピュータから対戦相手データを受信して、対戦者の端末との間でゲームを行い、対戦結果を運営者側に送信して、新たな対戦者データを受信すると、新たな対戦者の端末との間でゲームを行う技術がある。また、友人登録を行った２人のユーザに共通の友人が２人以上存在する場合に、その共通の友人の中からお互いに友人登録をしている２人を検索して、４人のコミュニティを作成し、その４人をメンバー登録して通知する技術がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−１５７７８２号公報
【特許文献２】特開２００８−２４２５２０号公報
【非特許文献】
【０００５】
【非特許文献１】“ソーシャルランチ  人気の秘策”、［ｏｎｌｉｎｅ］、ＺＥＲＯ  ＷＥＢ  株式会社  ［平成２６年７月１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｚｅｒｏ−ｗｅｂ．ｃｏ．ｊｐ／？ｐ＝３１１２＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来技術によれば、ランチが成立しやすいメンバーをマッチングすることが難しい。
【０００７】
一つの側面では、本発明は、ランチが成立しやすいメンバーをマッチングするランチのメンバー通知方法、ランチのメンバー通知プログラム、および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の一側面によれば、昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出し、抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行うランチのメンバー通知方法、ランチのメンバー通知プログラム、および情報処理装置が提案される。
【０００９】
また、本発明の一側面によれば、スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出し、抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行うランチのメンバー通知方法、ランチのメンバー通知プログラム、および情報処理装置が提案される。
【発明の効果】
【００１０】
本発明の一態様によれば、ランチが成立しやすいメンバーをマッチングすることができるという効果を奏する。
【図面の簡単な説明】
【００１１】
【図１】図１は、実施の形態１にかかるランチのメンバー通知方法の一実施例を示す説明図である。
【図２】図２は、実施の形態１にかかるランチメンバ通知システム２００のシステム構成例を示す説明図である。
【図３】図３は、情報処理装置１０１のハードウェア構成例を示すブロック図である。
【図４】図４は、クライアント装置２０１のハードウェア構成例を示すブロック図である。
【図５】図５は、ユーザＤＢ５００の記憶内容の一例を示す説明図である。
【図６】図６は、スケジュールＤＢ６００の記憶内容の一例を示す説明図である。
【図７】図７は、飲食場所ＤＢ７００の記憶内容の一例を示す説明図である。
【図８】図８は、グループＤＢ８００の記憶内容の一例を示す説明図である。
【図９】図９は、パーティ管理テーブル９００の記憶内容の一例を示す説明図である。
【図１０】図１０は、招待メールの具体例を示す説明図（その１）である。
【図１１】図１１は、実施の形態１にかかる情報処理装置１０１の機能的構成例を示すブロック図である。
【図１２】図１２は、パーティ管理テーブル９００の記憶内容の更新例を示す説明図である。
【図１３】図１３は、招待メールの具体例を示す説明図（その２）である。
【図１４】図１４は、開催メールの具体例を示す説明図（その１）である。
【図１５】図１５は、開催メールの具体例を示す説明図（その２）である。
【図１６】図１６は、中止メールの具体例を示す説明図である。
【図１７】図１７は、実施の形態１にかかる情報処理装置１０１の事前処理手順の一例を示すフローチャートである。
【図１８】図１８は、パーティ検索処理の具体的処理手順の一例を示すフローチャートである。
【図１９】図１９は、実施の形態１にかかる情報処理装置１０１の招待メール通知処理手順の一例を示すフローチャートである。
【図２０】図２０は、実施の形態１にかかる情報処理装置１０１の更新処理手順の一例を示すフローチャートである。
【図２１】図２１は、実施の形態１にかかる情報処理装置１０１の開催／中止メール通知処理手順の一例を示すフローチャートである。
【図２２】図２２は、実施の形態２にかかるランチのメンバー通知方法の一実施例を示す説明図である。
【図２３】図２３は、会議ＤＢ２３００の記憶内容の一例を示す説明図である。
【図２４】図２４は、招待メールの具体例を示す説明図（その３）である。
【図２５】図２５は、実施の形態２にかかる情報処理装置１０１の機能的構成例を示すブロック図である。
【図２６】図２６は、実施の形態２にかかる情報処理装置１０１の事前処理手順の一例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下に図面を参照して、本発明にかかるランチのメンバー通知方法、ランチのメンバー通知プログラム、および情報処理装置の実施の形態を詳細に説明する。
【００１３】
（実施の形態１）
図１は、実施の形態１にかかるランチのメンバー通知方法の一実施例を示す説明図である。図１において、情報処理装置１０１は、複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行うコンピュータである。
【００１４】
ここで、面識のない人とのランチの機会を提供することは、コミュニケーションを促進する手段として有効である。例えば、同一組織に属する者同士であっても互いに面識のないことは多く、そのような人達にランチの機会を提供することで、新しい人間関係が形成されて有意義な情報交換等が行われるなど、組織内の活性化を図ることができる。
【００１５】
ところが、昼休みの時間帯は、ユーザ間で異なる場合がある。例えば、同一組織であっても、所属部署が異なると昼休みの時間帯が異なることがある。このため、ランチを一緒に食べるメンバーを紹介されても、昼休みの時間帯が合わず、一緒にランチを食べたいと思っても、ランチに参加することができない場合がある。また、ランチに参加する人数が少なくなりすぎると、ランチ自体開催することができなくなる場合がある。
【００１６】
そこで、実施の形態１では、情報処理装置１０１は、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行うことで、ランチが成立しやすいメンバーのマッチングを実現する。以下、実施の形態１にかかる情報処理装置１０１の処理例について説明する。
【００１７】
（１）情報処理装置１０１は、昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出する。ここで、所定の時間幅は、任意に設定可能であり、少なくともランチを食べる時間を確保できる程度の時間幅に設定される。
【００１８】
図１の例では、ユーザＡ〜Ｅの昼休みの時間帯が登録されている。具体的には、ユーザＡの昼休みの時間帯は「１２：００〜１３：００」である。また、ユーザＢの昼休みの時間帯は「１３：００〜１４：００」である。また、ユーザＣの昼休みの時間帯は「１１：４０〜１２：４０」である。また、ユーザＤの昼休みの時間帯は「１１：００〜１２：００」である。また、ユーザＥの昼休みの時間帯は「１１：５０〜１２：５０」である。
【００１９】
ここで、所定の時間幅が「４０［分］」に設定されている場合を想定する。この場合、情報処理装置１０１は、ユーザＡ〜Ｅのうち、４０分以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出する。図１の例では、４０分以上の共通する時間帯「１２：００〜１２：４０」が昼休みの時間帯に含まれるユーザＡ，Ｃ，Ｅが抽出される。
【００２０】
（２）情報処理装置１０１は、抽出した複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行う。図１の例では、情報処理装置１０１は、抽出した各ユーザＡ，Ｃ，Ｅのアドレス宛に招待メール１１０を送信する。招待メール１１０には、例えば、ランチの開催日時、各メンバーの情報などが含まれる。
【００２１】
ランチの開催日としては、例えば、招待メール１１０の送信時刻以降のいずれかの日、例えば、当日や翌日などが設定される。ランチの開催時間としては、例えば、抽出された各ユーザＡ，Ｃ，Ｅの昼休みの時間帯のうちユーザ間で共通する時間帯「１２：００〜１２：４０」が設定される。
【００２２】
各メンバーの情報は、例えば、各メンバーの氏名、顔写真、自己紹介文などである。すなわち、抽出された複数のユーザが、ランチを一緒に食べるランチメンバとして紹介される。図１の例では、招待メール１１０において、ユーザＡ，Ｃ，Ｅが、ランチを一緒に食べるランチメンバとして紹介される。
【００２３】
このように、実施の形態１にかかる情報処理装置１０１によれば、昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出することができる。そして、情報処理装置１０１によれば、抽出した複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行うことができる。
【００２４】
これにより、ランチを一緒に食べることができる程度に昼休みの時間帯が重なる複数のユーザをランチメンバとしてマッチングすることができる。このため、昼休みの時間帯が合わないためにランチに参加できないという不都合が生じることを防いで、ランチが成立する確度を向上させることができる。
【００２５】
（ランチメンバ通知システム２００のシステム構成例）
つぎに、実施の形態１にかかるランチメンバ通知システム２００のシステム構成例について説明する。
【００２６】
図２は、実施の形態１にかかるランチメンバ通知システム２００のシステム構成例を示す説明図である。図２において、ランチメンバ通知システム２００は、情報処理装置１０１と、複数のクライアント装置２０１と、を含む。ランチメンバ通知システム２００において、情報処理装置１０１と複数のクライアント装置２０１は、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットなどである。
【００２７】
ここで、情報処理装置１０１は、複数のクライアント装置２０１に対して、ランチを一緒に食べるメンバーとしての通知を行う。情報処理装置１０１は、後述の図５〜図９に示すユーザＤＢ（データベース）５００、スケジュールＤＢ６００、飲食場所ＤＢ７００、グループＤＢ８００およびパーティ管理テーブル９００を有する。
【００２８】
クライアント装置２０１は、ランチメンバ通知システム２００のユーザが使用するコンピュータである。例えば、クライアント装置２０１は、ＰＣ（パーソナル・コンピュータ）、ノートＰＣ、タブレット型ＰＣ、スマートフォン、携帯電話機などである。
【００２９】
ランチメンバ通知システム２００のユーザは、例えば、共通する組織に属するユーザである。組織は、例えば、会社（企業）、官公庁、学校などである。以下の説明では、ランチメンバ通知システム２００のユーザとして、同じ会社（企業）に属するユーザを例に挙げて説明する。
【００３０】
（情報処理装置１０１のハードウェア構成例）
図３は、情報処理装置１０１のハードウェア構成例を示すブロック図である。図３において、情報処理装置１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）３０１と、メモリ３０２と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０３と、ディスクドライブ３０４と、ディスク３０５と、を有する。また、各構成部は、バス３００によってそれぞれ接続される。
【００３１】
ここで、ＣＰＵ３０１は、情報処理装置１０１の全体の制御を司る。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。
【００３２】
Ｉ／Ｆ３０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータ（例えば、図２に示したクライアント装置２０１）に接続される。そして、Ｉ／Ｆ３０３は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。Ｉ／Ｆ３０３には、例えば、モデムやＬＡＮアダプタなどを採用することができる。
【００３３】
ディスクドライブ３０４は、ＣＰＵ３０１の制御に従ってディスク３０５に対するデータのリード／ライトを制御する。ディスク３０５は、ディスクドライブ３０４の制御で書き込まれたデータを記憶する。ディスク３０５としては、例えば、磁気ディスク、光ディスクなどが挙げられる。
【００３４】
なお、情報処理装置１０１は、上述した構成部のほか、例えば、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、キーボード、マウス、ディスプレイなどを有することにしてもよい。
【００３５】
（クライアント装置２０１のハードウェア構成例）
図４は、クライアント装置２０１のハードウェア構成例を示すブロック図である。図４において、クライアント装置２０１は、ＣＰＵ４０１と、メモリ４０２と、ディスクドライブ４０３と、ディスク４０４と、Ｉ／Ｆ４０５と、ディスプレイ４０６と、入力装置４０７と、を有する。また、各構成部はバス４００によってそれぞれ接続される。
【００３６】
ここで、ＣＰＵ４０１は、クライアント装置２０１の全体の制御を司る。メモリ４０２は、例えば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ４０１のワークエリアとして使用される。メモリ４０２に記憶されるプログラムは、ＣＰＵ４０１にロードされることで、コーディングされている処理をＣＰＵ４０１に実行させる。
【００３７】
ディスクドライブ４０３は、ＣＰＵ４０１の制御に従ってディスク４０４に対するデータのリード／ライトを制御する。ディスク４０４は、ディスクドライブ４０３の制御で書き込まれたデータを記憶する。ディスク４０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。
【００３８】
Ｉ／Ｆ４０５は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータ（例えば、図２に示した情報処理装置１０１）に接続される。そして、Ｉ／Ｆ４０５は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。
【００３９】
ディスプレイ４０６は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ４０６は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ）、液晶ディスプレイ、有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどを採用することができる。
【００４０】
入力装置４０７は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置４０７は、キーボードやマウスなどであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。
【００４１】
なお、クライアント装置２０１は、上述した構成部のうち、例えば、ディスクドライブ４０３、ディスク４０４などを有さないことにしてもよい。また、クライアント装置２０１は、上述した構成部のほか、例えば、ＳＳＤ、スキャナ、プリンタなどを有することにしてもよい。
【００４２】
（各種ＤＢ等５００，６００，７００，８００，９００の記憶内容）
つぎに、図５〜図９を用いて、情報処理装置１０１が有する各種ＤＢ等５００，６００，７００，８００，９００の記憶内容について説明する。各種ＤＢ等５００，６００，７００，８００，９００は、例えば、図３に示した情報処理装置１０１のメモリ３０２、ディスク３０５等の記憶装置により実現される。
【００４３】
＜ユーザＤＢ５００の記憶内容＞
図５は、ユーザＤＢ５００の記憶内容の一例を示す説明図である。図５において、ユーザＤＢ５００は、ユーザＩＤ、アドレス、氏名、最寄駅、所属、職制、役職、ランチタイム、画像およびコメントのフィールドを有する。各フィールドに情報を設定することで、ユーザ情報（例えば、ユーザ情報５００−１〜５００−１０）がレコードとして記憶される。
【００４４】
ここで、ユーザＩＤは、ランチメンバ通知システム２００のユーザを識別する識別子である。アドレスは、ユーザのメールアドレスである。氏名は、ユーザの氏名である。最寄駅は、ユーザが通勤時に使用する駅であり、例えば、ユーザが所属する事業所や建物から最も近いところにある駅である。所属は、ユーザが所属する事業所、事業部、部署、建物などの名称である。図５では、一例として、ユーザが所属する建物名が示されている。
【００４５】
職制は、会社内のユーザが属する末端組織を示す。職制としては、例えば、研究、営業、開発、法務、デザイナー、事務などがある。役職は、ユーザが一般社員であるか管理職であるかを示す。ランチタイムは、ユーザの昼休み時間帯として登録された時間帯である。画像は、ユーザを撮影した画像であり、例えば、ユーザの顔写真である。コメントは、ユーザの自己紹介文である。
【００４６】
なお、図示は省略するが、ユーザＤＢ５００には、さらに、ユーザの性別、年齢、興味のあるキーワード、食べ物の好み（ジャンル）、ランチで話したい内容などが設定されることにしてもよい。
【００４７】
＜スケジュールＤＢ６００の記憶内容＞
図６は、スケジュールＤＢ６００の記憶内容の一例を示す説明図である。図６において、スケジュールＤＢ６００は、ランチメンバ通知システム２００の各ユーザのスケジュール情報（例えば、スケジュール情報６００−１〜６００−３）を記憶する。ただし、図６では、各ユーザのスケジュール情報の一部を抜粋して表示している。
【００４８】
一例として、スケジュール情報６００−１を例に挙げると、２０１４年７月１日の９時〜１０時のユーザＵ１のスケジュール「特許戦略検討会」を特定することができる。また、２０１４年７月１日の１４時のユーザＵ１のスケジュール「外出」を特定することができる。
【００４９】
＜飲食場所ＤＢ７００の記憶内容＞
図７は、飲食場所ＤＢ７００の記憶内容の一例を示す説明図である。図７において、飲食場所ＤＢ７００は、飲食場所ＩＤ、名称、最寄駅、ＵＲＬ、営業時間、定休日、ジャンル、予約用アドレス、クーポンおよび弁当持込可否のフィールドを有する。各フィールドに情報を設定することで、飲食場所情報（例えば、飲食場所情報７００−１〜７００−５）がレコードとして記憶される。
【００５０】
ここで、飲食場所ＩＤは、飲食場所を識別する識別子である。飲食場所は、例えば、社外の飲食店や社内の社員食堂などである。名称は、飲食場所の名称である。最寄駅は、飲食場所から最も近いところにある駅である。ＵＲＬは、飲食場所に関する情報にアクセスするためのＵＲＬであり、例えば、飲食店のＵＲＬである。
【００５１】
営業時間は、飲食場所の営業時間である。定休日は、飲食場所の定休日である。ジャンルは、飲食場所で提供される料理の種類を示す。ジャンルとしては、例えば、イタリアン、フレンチ、中華、和食、ラーメンなどがある。ただし、飲食場所が社員食堂の場合は、ジャンルとして「社員食堂」が設定される。
【００５２】
予約用アドレスは、インターネット経由で飲食場所の予約を行う場合に使用するアドレスである。クーポンは、飲食場所で使用できる割引券などである。弁当持込可否は、お弁当を飲食場所に持ち込むことができるか否かを示す。弁当持込可否には、お弁当を持込可の場合に「可」が設定され、お弁当を持込不可の場合は「不可」が設定される。
【００５３】
＜グループＤＢ８００の記憶内容＞
図８は、グループＤＢ８００の記憶内容の一例を示す説明図である。図８において、グループＤＢ８００は、グループＩＤ、ｆｒｏｍおよびｔｏのフィールドを有し、各フィールドに情報を設定することで、グループ情報８００−１〜８００−ｎをレコードとして記憶する。
【００５４】
ここで、グループＩＤは、グループＧを識別する識別子である。グループＧは、ユーザ間の友人関係を示す。ｆｒｏｍは、友人関係を有するペアのうち関係元のユーザを示す。ｔｏは、友人関係を有するペアのうち関係先のユーザを示す。例えば、グループＧ１は、ユーザＵ１からユーザＵ３への友人関係を示す。
【００５５】
＜パーティ管理テーブル９００の記憶内容＞
図９は、パーティ管理テーブル９００の記憶内容の一例を示す説明図である。図９において、パーティ管理テーブル９００は、パーティＩＤ、ステータス、集合時間、飲食場所ＩＤ、メンバーＩＤ、出欠および弁当フラグのフィールドを有する。各フィールドに情報を設定することで、パーティ情報９００−１〜９００−Ｋがレコードとして記憶される。
【００５６】
ここで、パーティＩＤは、パーティＰを識別する識別子である。パーティＰは、ランチを一緒に食べるメンバーとして抽出されたユーザの集合（ランチメンバ）を示す。ステータスは、パーティＰによるランチが開催されるか否かを示す。ステータスには、「開催」または「中止」が設定される。集合時間は、ランチが開催される場合の集合時間を示す。飲食場所ＩＤは、ランチが開催される飲食場所を識別する識別子である。
【００５７】
メンバーＩＤは、ランチを一緒に食べるメンバーを識別する識別子である。出欠は、メンバーの出欠を示す。出欠には、「出席」または「欠席」が設定される。弁当フラグは、メンバーがお弁当を持参するか否かを示すフラグである。弁当フラグには、初期状態として「０」が設定されており、お弁当を持参する場合に「１」が設定される。
【００５８】
（招待メールの具体例）
つぎに、ランチメンバに対して通知される招待メールの具体例について説明する。ランチメンバは、ランチを一緒に食べるメンバーとして抽出された複数のユーザである。招待メールは、情報処理装置１０１からクライアント装置２０１に送信されて、クライアント装置２０１のディスプレイ４０６（図４参照）に表示される。
【００５９】
図１０は、招待メールの具体例を示す説明図（その１）である。図１０において、ランチメンバに対して開催予定のランチの存在を通知する招待メール１０００がディスプレイ４０６に表示されている。招待メール１０００には、ランチの開催日時とランチメンバの顔写真、所属、氏名、自己紹介文が示されている。
【００６０】
招待メール１０００によれば、ユーザは、７月１日（火）の１１時５０分〜１２時３０分に開催予定のランチに招待されていることがわかる。また、ユーザは、ランチを一緒に食べる他のメンバーの顔写真、所属、氏名、自己紹介文などを閲覧して、ランチに参加するか否かを判断することができる。
【００６１】
招待メール１０００において、例えば、入力装置４０７（図４参照）を用いたユーザの操作入力により、参加ボタンＢ１をクリック（あるいは、タップ）してから、返信ボタンＢ４をクリック（あるいは、タップ）すると、ランチに参加する旨の返信メールを情報処理装置１０１に送信することができる。
【００６２】
また、招待メール１０００において、お弁当ボタンＢ３をクリック（あるいは、タップ）してから、返信ボタンＢ４をクリック（あるいは、タップ）すると、お弁当を持参でランチに参加する旨の返信メールを情報処理装置１０１に送信することができる。
【００６３】
また、招待メール１０００において、辞退ボタンＢ２をクリック（あるいは、タップ）してから、返信ボタンＢ４をクリック（あるいは、タップ）すると、ランチに参加しない旨の返信メールを情報処理装置１０１に送信することができる。
【００６４】
（情報処理装置１０１の機能的構成例）
図１１は、実施の形態１にかかる情報処理装置１０１の機能的構成例を示すブロック図である。図１１において、情報処理装置１０１は、抽出部１１０１と、作成部１１０２と、送信部１１０３と、受信部１１０４と、更新部１１０５と、を含む構成である。抽出部１１０１〜更新部１１０５は制御部となる機能であり、具体的には、例えば、図３に示したメモリ３０２、ディスク３０５などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、Ｉ／Ｆ３０３により、その機能を実現する。各機能部の処理結果は、例えば、メモリ３０２、ディスク３０５などの記憶装置に記憶される。
【００６５】
抽出部１１０１は、昼休みの時間帯が登録された複数のユーザのうち、時間幅Ｔ以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出する機能を有する。ここで、抽出される複数のユーザは、ランチを一緒に食べるランチメンバである。時間幅Ｔは、システム側で任意に設定可能であり、例えば、昼休み時間の長さ、食事にかかる時間、移動にかかる時間などを考慮して設定される。
【００６６】
具体的には、例えば、抽出部１１０１は、ユーザＤＢ５００を参照して、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれる複数のユーザを抽出する。一例として、時間幅Ｔを「Ｔ＝４０［分］」とすると、抽出部１１０１は、例えば、４０分以上の共通する時間帯がランチタイムに含まれるユーザＵ１，Ｕ３，Ｕ５，Ｕ７を抽出する。
【００６７】
この際、抽出部１１０１は、ランチの開催日における時間幅Ｔ以上の共通する時間帯に、既に他のスケジュールが埋まっているユーザについては、抽出対象から除外することにしてもよい。なお、ランチの開催日は、システム側で任意に設定可能である。また、ランチの開催日における各ユーザのスケジュールは、スケジュールＤＢ６００（図６参照）から特定することができる。
【００６８】
以下の説明では、「時間幅Ｔ以上の共通する時間帯が昼休みの時間帯に含まれる」という条件を、「条件１」と表記する場合がある。
【００６９】
また、抽出部１１０１は、昼休みの時間帯が登録された複数のユーザのうち、（条件１）を満たし、かつ、友人関係を有するユーザのペアの組み合わせにより形成される複数のユーザを抽出することにしてもよい。具体的には、例えば、抽出部１１０１は、グループＤＢ８００（図８参照）を参照して、（条件１）を満たし、かつ、グループＧの組み合わせにより形成される複数のユーザを抽出することにしてもよい。
【００７０】
以下の説明では、「友人関係を有するユーザのペア（グループＧ）の組み合わせにより形成される」という条件を、「条件２」と表記する場合がある。
【００７１】
また、抽出部１１０１は、昼休みの時間帯が登録された複数のユーザのうち、（条件１）を満たし、かつ、最寄駅が同一である複数のユーザを抽出することにしてもよい。具体的には、例えば、抽出部１１０１は、ユーザＤＢ５００を参照して、（条件１）を満たし、かつ、最寄駅が同一である複数のユーザを抽出することにしてもよい。
【００７２】
以下の説明では、「最寄駅が同一である」という条件を、「条件３」と表記する場合がある。
【００７３】
また、抽出部１１０１は、昼休みの時間帯が登録された複数のユーザのうち、（条件１）を満たし、かつ、所属する事業所または建物の少なくともいずれかが同一である複数のユーザを抽出することにしてもよい。具体的には、例えば、抽出部１１０１は、ユーザＤＢ５００を参照して、（条件１）を満たし、かつ、所属する事業所または建物が同一である複数のユーザを抽出することにしてもよい。
【００７４】
以下の説明では、「所属する事業所または建物の少なくともいずれかが同一である」という条件を、「条件４」と表記する場合がある。
【００７５】
また、抽出部１１０１は、昼休みの時間帯が登録された複数のユーザのうち、（条件１）を満たし、かつ、役職が同一である複数のユーザを抽出することにしてもよい。具体的には、例えば、抽出部１１０１は、ユーザＤＢ５００を参照して、（条件１）を満たし、かつ、役職が同一である複数のユーザを抽出することにしてもよい。
【００７６】
以下の説明では、「役職が同一である」という条件を、「条件５」と表記する場合がある。
【００７７】
また、抽出部１１０１は、昼休みの時間帯が登録された複数のユーザのうち、（条件１）を満たし、かつ、性別が同一である複数のユーザを抽出することにしてもよい。具体的には、例えば、抽出部１１０１は、ユーザＤＢ５００を参照して、（条件１）を満たし、かつ、性別が同一である複数のユーザを抽出することにしてもよい。
【００７８】
以下の説明では、「性別が同一である」という条件を、「条件６」と表記する場合がある。
【００７９】
また、抽出部１１０１は、昼休みの時間帯が登録された複数のユーザのうち、（条件１）を満たし、かつ、興味のあるキーワードが同一である複数のユーザを抽出することにしてもよい。具体的には、例えば、抽出部１１０１は、ユーザＤＢ５００を参照して、（条件１）を満たし、かつ、興味のあるキーワードが同一である複数のユーザを抽出することにしてもよい。
【００８０】
以下の説明では、「興味のあるキーワードが同一である」という条件を、「条件７」と表記する場合がある。
【００８１】
また、抽出部１１０１は、（条件１）を必須条件とし、（条件２）〜（条件７）を参考条件として、昼休みの時間帯が登録された複数のユーザのうち、必須条件を満たし、かつ、複数の参考条件を満たす複数のユーザを抽出することにしてもよい。
【００８２】
また、抽出部１１０１は、ランチメンバとして抽出するユーザの数の上限値Ｎmaxを設定することにしてもよい。上限値Ｎmaxは、任意に設定可能であり、例えば、４〜１０程度の値に設定される。
【００８３】
抽出された抽出結果は、パーティ管理テーブル９００（図９参照）に記憶される。具体的には、例えば、抽出部１１０１は、抽出したランチメンバに対してパーティＩＤを付与して、各メンバーのメンバーＩＤ（ユーザＩＤ）とともにパーティ管理テーブル９００に記憶する。これにより、新たなパーティＰのパーティ情報がレコードとしてパーティ管理テーブル９００に登録される。
【００８４】
作成部１１０２は、招待メールを作成する機能を有する。ここで、招待メールとは、ランチメンバに対して、ランチを一緒に食べるメンバーとしての通知を行うためのものである。ランチメンバは、パーティＰに対応しており、パーティ管理テーブル９００から特定される。招待メールには、例えば、パーティＰのパーティＩＤが含まれる。
【００８５】
具体的には、例えば、作成部１１０２は、ランチの開催日時と、ランチメンバについての情報と、を含む招待メールを作成する。ランチの開催日は、上述したように、システム側で任意に設定可能である。ランチの開催時間は、例えば、ランチメンバの昼休み時間帯（ランチタイム）のうち、全メンバー間で共通する時間帯に設定される。例えば、ランチメンバとしてユーザＵ１，Ｕ３，Ｕ５，Ｕ７が抽出された場合、ランチの開催時間として「１１：５０〜１２：３０」の時間帯が設定される。
【００８６】
また、ランチの開催時間は、飲食場所までの移動時間（例えば、５分）を考慮して、全メンバー間で共通する時間帯のうち、移動時間分前後の時間幅を縮めた時間帯に設定されることにしてもよい。例えば、ランチメンバとしてユーザＵ１，Ｕ３，Ｕ５，Ｕ７が抽出された場合、ランチの開催時間として「１１：５５〜１２：２５」の時間帯が設定されることにしてもよい。
【００８７】
ランチメンバについての情報は、例えば、ランチメンバの氏名、年齢、性別、アドレス、顔写真、職制、所属、役職、自己紹介文、興味のあるキーワード、食べ物の好み（ジャンル）、ランチで話したい内容などである。作成部１１０２は、ユーザＤＢ５００を参照して、ランチメンバについての情報を特定することができる。
【００８８】
また、作成部１１０２は、例えば、ランチを食べることに同意するか否かの問い合わせをさらに含む招待メールを作成することにしてもよい。また、作成部１１０２は、例えば、お弁当を持参するか否かの問い合わせをさらに含む招待メール（例えば、招待メール１０００）を作成することにしてもよい。
【００８９】
また、作成部１１０２は、例えば、ランチを食べる場所の候補としての飲食場所の情報をさらに含む招待メールを作成することにしてもよい。ランチを食べる場所の候補となる飲食場所（以下、「開催場所候補」と表記する場合がある。）の情報は、例えば、開催場所候補の名称、最寄駅、ジャンル、ＵＲＬ、クーポンなどである。
【００９０】
開催場所候補は、例えば、飲食場所ＤＢ７００（図７参照）から検索される。より具体的には、例えば、作成部１１０２は、飲食場所ＤＢ７００を参照して、最寄駅がランチメンバの少なくともいずれかのメンバーの最寄駅と一致する飲食場所を、開催場所候補として検索する。
【００９１】
この際、作成部１１０２は、ランチの開催日が定休日でなく、かつ、ランチの開催時間が営業時間に含まれる飲食場所を、開催場所候補として検索することにしてもよい。さらに、作成部１１０２は、ジャンルがランチメンバの少なくともいずれかのメンバーの食べ物の好み（ジャンル）と一致する飲食場所を、開催場所候補として検索することにしてもよい。
【００９２】
また、作成部１１０２は、例えば、複数の開催場所候補の中からいずれかの開催場所候補を選択可能な招待メールを作成することにしてもよい。開催場所候補を選択可能な招待メールの具体例については、図１３を用いて後述する。なお、招待メールに含む開催場所候補の数には上限（例えば、４つ）を設けることにしてもよい。
【００９３】
送信部１１０３は、作成された招待メールをランチメンバに送信する機能を有する。具体的には、例えば、送信部１１０３は、ユーザＤＢ５００を参照して、ランチメンバ（パーティＰ）の各メンバーのアドレス宛に招待メールを送信する。これにより、ランチメンバに対して、ランチを一緒に食べるメンバーとしての通知を行うことができる。
【００９４】
受信部１１０４は、送信された招待メールに対する返信メールをクライアント装置２０１から受信する機能を有する。返信メールには、例えば、ランチを食べることに同意するか否かの問い合わせ結果、お弁当を持参するか否かの問い合わせ結果、開催場所候補の選択結果などが含まれる。また、返信メールには、例えば、招待メールに含まれるパーティＩＤと同一のパーティＩＤが含まれる。
【００９５】
更新部１１０５は、受信された返信メールに基づいて、パーティ管理テーブル９００の記憶内容を更新する機能を有する。具体的には、例えば、更新部１１０５は、パーティ管理テーブル９００から、返信メールに含まれるパーティＩＤに対応するパーティ情報を検索して、検索したパーティ情報を更新する。
【００９６】
ここで、パーティ管理テーブル９００内のパーティ情報９００−１を例に挙げて、パーティ管理テーブル９００の記憶内容の更新例について説明する。
【００９７】
図１２は、パーティ管理テーブル９００の記憶内容の更新例を示す説明図である。図１２において、パーティＰ１のパーティ情報９００−１が示されている（図１２中、（１２−１））。ここで、パーティＰ１の各メンバーＵ１，Ｕ３，Ｕ５，Ｕ７から、ランチを食べることに同意する旨の返信メールを受信した場合を想定する。ただし、お弁当を持参するメンバーはいないものとする。
【００９８】
この場合、更新部１１０５は、パーティＰ１の各メンバーＵ１，Ｕ３，Ｕ５，Ｕ７の出欠に「出席」を設定する（図１２中、（１２−２））。なお、お弁当を持参する旨の返信メールを受信した場合には、更新部１１０５は、さらに、返信メールの送信元のメンバーの弁当フラグに「１」を設定する。
【００９９】
つぎに、更新部１１０５は、予め決められた日時になったら、パーティＰ１のランチメンバのうち、ランチを食べることに同意する旨の返信メールを受信したメンバー数が所定数Ｘ以上となったか否かを判断する。ここで、所定数Ｘは、システム側で任意に設定可能であり、例えば、３〜１０程度の値に設定される。
【０１００】
一例として、所定数Ｘを「Ｘ＝３」とすると、更新部１１０５は、例えば、パーティＰ１のランチメンバのうち出欠「出席」が設定されたメンバー数が３人以上となったか否かを判断する。（１２−２）の例では、出欠「出席」が設定されたメンバー数が４人のため、更新部１１０５は、パーティＰ１のランチメンバのうち出欠「出席」が設定されたメンバー数が３人以上となったと判断する。
【０１０１】
また、更新部１１０５は、ランチメンバのうち出欠「出席」が設定されたメンバー数が所定数Ｘ以上となったら、ステータスに「開催」を設定する。一方、ランチメンバのうち出欠「出席」が設定されたメンバー数が所定数Ｘ未満の場合には、更新部１１０５は、ステータスに「中止」を設定する。
【０１０２】
また、更新部１１０５は、ランチメンバのうち出欠「出席」が設定されたメンバー数が所定数Ｘ以上となったら集合時間および飲食場所ＩＤを設定する（図１２中、（１２−３））。集合時間としては、例えば、ランチの開始時刻が設定される。（１２−３）の例では、集合時間「１１：５０」が設定されている。
【０１０３】
飲食場所ＩＤとしては、例えば、飲食場所ＤＢ７００から開催場所候補として検索されるいずれかの飲食場所の飲食場所ＩＤが設定されることにしてもよい。また、返信メールに開催場所候補の選択結果が含まれる場合には、飲食場所ＩＤとして、選択された開催場所候補の飲食場所ＩＤが設定されることにしてもよい。
【０１０４】
この際、ランチメンバにより複数の開催場所候補が選択された場合には、飲食場所ＩＤとして、ランチメンバにより選択された選択数が最も多いいずれかの開催場所候補の飲食場所ＩＤが設定されることにしてもよい。（１２−３）の例では、飲食場所ＩＤ「Ｓ１」が設定されている。
【０１０５】
また、更新部１１０５は、ランチメンバのうち出欠「出席」が設定されたメンバー数が所定数Ｘ以上となったら、スケジュールＤＢ６００内の各メンバーのスケジュールにランチの予定を登録することにしてもよい。具体的には、例えば、更新部１１０５は、各メンバーＵ１，Ｕ３，Ｕ５，Ｕ７のスケジュールのうち、２０１４年７月１日の１１時５０分〜１２時３０分の時間帯に、ランチの予定を登録する。
【０１０６】
図１１の説明に戻り、作成部１１０２は、開催メールを作成する機能を有する。ここで、開催メールは、ランチの開催が決定したことの通知を行うためのものである。具体的には、例えば、作成部１１０２は、パーティ管理テーブル９００を参照して、ステータス「開催」のパーティＰについて、ランチの開催日時とランチメンバについての情報とを含む開催メールを作成する。
【０１０７】
また、作成部１１０２は、パーティ管理テーブル９００を参照して、集合時間、飲食場所についての情報をさらに含む開催メールを作成することにしてもよい。飲食場所についての情報は、例えば、パーティＰの飲食場所ＩＤから特定される飲食場所の名称、最寄駅、ジャンル、ＵＲＬ、クーポンなどである。
【０１０８】
なお、集合時間、飲食場所についての情報を含む開催メールの具体例については、図１４を用いて後述する。
【０１０９】
また、作成部１１０２は、パーティ管理テーブル９００を参照して、パーティＰのランチメンバのうち、弁当フラグが「１」のメンバーが存在するか否かを判断することにしてもよい。そして、弁当フラグが「１」のメンバーが存在する場合には、作成部１１０２は、飲食場所ＤＢ７００から開催場所候補として検索される飲食場所のうち弁当持込可否「可」の飲食場所についての情報をさらに含む開催メールを作成することにしてもよい。
【０１１０】
なお、弁当持込可否「可」の飲食場所についての情報を含む開催メールの具体例については、図１５を用いて後述する。
【０１１１】
また、作成部１１０２は、中止メールを作成する機能を有する。ここで、中止メールは、ランチの開催を中止したことの通知を行うためのものである。具体的には、例えば、パーティ管理テーブル９００を参照して、ステータス「中止」のパーティＰについて、ランチの開催日時とランチメンバについての情報とを含む中止メールを作成する。
【０１１２】
なお、中止メールの具体例については、図１６を用いて後述する。
【０１１３】
送信部１１０３は、作成された開催メールをランチメンバに送信する機能を有する。具体的には、例えば、送信部１１０３は、予め決められた日時になったら、ユーザＤＢ５００を参照して、ランチメンバ（パーティＰ）の各メンバーのアドレス宛に開催メールを送信する。これにより、ランチメンバに対して、ランチの開催が決定したことの通知を行うことができる。
【０１１４】
また、送信部１１０３は、ランチメンバについてのランチの予約メッセージを送信する機能を有する。具体的には、例えば、送信部１１０３は、飲食場所ＤＢ７００を参照して、ランチを食べる場所として選択された飲食場所の予約用アドレス宛に、ランチメンバについてのランチの予約メッセージを送信する。ランチを食べる場所として選択された飲食場所は、例えば、ランチメンバにより選択された選択数が最も多い開催場所候補である。なお、ランチメンバについてのランチの予約メッセージの送信タイミングは、少なくともランチの開催日時よりも前である。
【０１１５】
また、送信部１１０３は、作成された中止メールをランチメンバに送信する機能を有する。具体的には、例えば、送信部１１０３は、予め決められた日時になったら、ユーザＤＢ５００を参照して、ランチメンバ（パーティＰ）の各メンバーのアドレス宛に中止メールを送信する。これにより、ランチメンバに対して、ランチの開催を中止したことの通知を行うことができる。
【０１１６】
（開催場所候補を選択可能な招待メールの具体例）
ここで、開催場所候補を選択可能な招待メールの具体例について説明する。
【０１１７】
図１３は、招待メールの具体例を示す説明図（その２）である。図１３において、ランチメンバに対して開催予定のランチの存在を通知する招待メール１３００がディスプレイ４０６に表示されている。招待メール１３００には、ランチの開催日時と、ランチメンバについての情報と、開催場所候補についての情報が示されている。
【０１１８】
招待メール１３００によれば、ユーザは、７月１日（火）の１１時５０分〜１２時３０分に開催予定のランチに招待されていることがわかる。また、ユーザは、ランチを一緒に食べる他のメンバーの顔写真、所属、氏名、自己紹介文などを閲覧して、ランチに参加するか否かを判断することができる。さらに、ユーザは、開催場所候補の名称、最寄駅、ジャンル、あるいは、ＵＲＬを指定して表示される開催場所候補の詳細情報などを閲覧して、ランチで行ってみたい開催場所候補を選択することができる。
【０１１９】
具体的には、招待メール１３００において、ユーザの操作入力により、参加ボタンＢ１をクリック（あるいは、タップ）してから、返信ボタンＢ３をクリック（あるいは、タップ）すると、ランチに参加する旨の返信メールを情報処理装置１０１に送信することができる。
【０１２０】
また、招待メール１３００において、ユーザの操作入力により、チェックボックスＣ１〜Ｃ３のいずれかをクリック（あるいは、タップ）してから、返信ボタンＢ３をクリック（あるいは、タップ）すると、ランチに参加する旨の返信メールとして、開催場所候補の選択結果を含む返信メールを情報処理装置１０１に送信することができる。
【０１２１】
また、招待メール１３００において、辞退ボタンＢ２をクリック（あるいは、タップ）してから、返信ボタンＢ３をクリック（あるいは、タップ）すると、ランチに参加しない旨の返信メールを情報処理装置１０１に送信することができる。
【０１２２】
（開催メールの具体例）
つぎに、図１４および図１５を用いて、開催メールの具体例について説明する。
【０１２３】
図１４は、開催メールの具体例を示す説明図（その１）である。図１４において、ランチメンバに対してランチの開催が決定したことを通知する開催メール１４００がディスプレイ４０６に表示されている。開催メール１４００には、ランチの開催日時と、ランチメンバについての情報と、集合時間と、飲食場所についての情報が示されている。
【０１２４】
開催メール１４００によれば、ユーザは、７月１日（火）の１１時５０分〜１２時３０分に開催予定となっていたランチの開催が決定したことを知ることができる。また、ユーザは、当日は１１時５０分頃までに飲食場所として指定された店Ａに集合すればよいことがわかる。さらに、ユーザは、例えば、店Ａに入店した際に、開催メール１４００に示されているクーポン１４０１を提示することで割引を受けることができる。
【０１２５】
図１５は、開催メールの具体例を示す説明図（その２）である。図１５において、ランチメンバに対してランチの開催が決定したことを通知する開催メール１５００がディスプレイ４０６に表示されている。開催メール１５００には、ランチの開催日時と、ランチメンバについての情報と、集合時間と、飲食場所についての情報が示されている。
【０１２６】
開催メール１５００によれば、ユーザは、７月１日（火）の１１時５０分〜１２時３０分に開催予定となっていたランチの開催が決定したことを知ることができる。また、ユーザは、お弁当を持参するメンバーがいるために飲食場所として食堂Ｅ（社員食堂）が指定されており、当日は１１時５０分頃までに食堂Ｅ（社員食堂）に集合すればよいことがわかる。
【０１２７】
（中止メールの具体例）
つぎに、図１６を用いて、中止メールの具体例について説明する。
【０１２８】
図１６は、中止メールの具体例を示す説明図である。図１６において、ランチメンバに対してランチの開催を中止したことを通知する中止メール１６００がディスプレイ４０６に表示されている。中止メール１６００には、中止となったランチの開催日時と、ランチメンバについての情報が示されている。
【０１２９】
中止メール１６００によれば、ユーザは、７月１日（火）の１１時５０分〜１２時３０分に開催予定となっていたランチの開催が中止となったことを知ることができる。
【０１３０】
（情報処理装置１０１の事前処理手順）
つぎに、実施の形態１にかかる情報処理装置１０１の事前処理手順について説明する。事前処理は、例えば、平日（月曜日〜金曜日）の７時などの予め決められた時刻に定期的に実行される。
【０１３１】
図１７は、実施の形態１にかかる情報処理装置１０１の事前処理手順の一例を示すフローチャートである。図１７のフローチャートにおいて、まず、情報処理装置１０１は、グループＤＢ８００から選択されていない未選択のグループＧｉ（ｉ＝１，２，…，ｎ）を選択する（ステップＳ１７０１）。
【０１３２】
つぎに、情報処理装置１０１は、ユーザＤＢ５００を参照して、グループＧｉのユーザについて、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれるか否かを判断する（ステップＳ１７０２）。ここで、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれない場合（ステップＳ１７０２：Ｎｏ）、情報処理装置１０１は、ステップＳ１７０６に移行する。
【０１３３】
一方、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれる場合（ステップＳ１７０２：Ｙｅｓ）、情報処理装置１０１は、ユーザＤＢ５００を参照して、グループＧｉのユーザについて、最寄駅が同一であるか否かを判断する（ステップＳ１７０３）。ここで、最寄駅が異なる場合（ステップＳ１７０３：Ｎｏ）、情報処理装置１０１は、ステップＳ１７０６に移行する。
【０１３４】
一方、最寄駅が同一の場合（ステップＳ１７０３：Ｙｅｓ）、情報処理装置１０１は、スケジュールＤＢ６００を参照して、グループＧｉのユーザについて、当日における時間幅Ｔ以上の共通する時間帯に他のスケジュールがあるか否かを判断する（ステップＳ１７０４）。
【０１３５】
ここで、他のスケジュールがある場合（ステップＳ１７０４：Ｙｅｓ）、情報処理装置１０１は、ステップＳ１７０６に移行する。一方、他のスケジュールがない場合（ステップＳ１７０４：Ｎｏ）、情報処理装置１０１は、パーティ検索処理を実行する（ステップＳ１７０５）。なお、パーティ検索処理の具体的な処理手順については、図１８を用いて後述する。
【０１３６】
つぎに、情報処理装置１０１は、グループＤＢ８００から選択されていない未選択のグループＧｉがあるか否かを判断する（ステップＳ１７０６）。ここで、未選択のグループＧｉがある場合（ステップＳ１７０６：Ｙｅｓ）、情報処理装置１０１は、ステップＳ１７０１に戻る。
【０１３７】
一方、未選択のグループＧｉがない場合（ステップＳ１７０６：Ｎｏ）、情報処理装置１０１は、本フローチャートによる一連の処理を終了する。なお、ステップＳ１７０１において、情報処理装置１０１は、選択済のグループＧｉに含まれるユーザと同一のユーザを含むグループＧについては選択対象から除外することにしてもよい。
【０１３８】
＜パーティ検索処理の具体的処理手順＞
つぎに、図１７に示したステップＳ１７０５のパーティ検索処理の具体的な処理手順について説明する。
【０１３９】
図１８は、パーティ検索処理の具体的処理手順の一例を示すフローチャートである。図１８のフローチャートにおいて、まず、情報処理装置１０１は、グループＤＢ８００から選択されていない未選択のグループＧｊ（ｊ＝１，２，…，ｎ、ｊ≠ｉ）を選択する（ステップＳ１８０１）。
【０１４０】
つぎに、情報処理装置１０１は、ユーザＤＢ５００を参照して、グループＧｉ，Ｇｊのユーザについて、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれるか否かを判断する（ステップＳ１８０２）。ここで、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれない場合（ステップＳ１８０２：Ｎｏ）、情報処理装置１０１は、グループＤＢ８００から選択されていない未選択のグループＧｊがあるか否かを判断する（ステップＳ１８０３）。
【０１４１】
ここで、未選択のグループＧｊがある場合（ステップＳ１８０３：Ｙｅｓ）、情報処理装置１０１は、ステップＳ１８０２に戻る。一方、未選択のグループＧｊがない場合（ステップＳ１８０３：Ｎｏ）、情報処理装置１０１は、パーティ検索処理を呼び出したステップに戻る。
【０１４２】
また、ステップＳ１８０２において、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれる場合（ステップＳ１８０２：Ｙｅｓ）、情報処理装置１０１は、ユーザＤＢ５００を参照して、グループＧｉ，Ｇｊのユーザについて、最寄駅が同一であるか否かを判断する（ステップＳ１８０４）。
【０１４３】
ここで、最寄駅が異なる場合（ステップＳ１８０４：Ｎｏ）、情報処理装置１０１は、ステップＳ１８０３に移行する。一方、最寄駅が同一の場合（ステップＳ１８０４：Ｙｅｓ）、情報処理装置１０１は、スケジュールＤＢ６００を参照して、グループＧｊのユーザについて、当日における時間幅Ｔ以上の共通する時間帯に他のスケジュールがあるか否かを判断する（ステップＳ１８０５）。
【０１４４】
ここで、他のスケジュールがある場合（ステップＳ１８０５：Ｙｅｓ）、情報処理装置１０１は、ステップＳ１８０３に移行する。一方、他のスケジュールがない場合（ステップＳ１８０５：Ｎｏ）、情報処理装置１０１は、グループＧｉ，Ｇｊから形成されるパーティＰｋをパーティ管理テーブル９００に登録して（ステップＳ１８０６）、パーティ検索処理を呼び出したステップに戻る。
【０１４５】
これにより、上記（条件１）〜上記（条件３）を満たす複数のユーザを、ランチを一緒に食べるランチメンバとして抽出することができる。
【０１４６】
（情報処理装置１０１の招待メール通知処理手順）
つぎに、実施の形態１にかかる情報処理装置１０１の招待メール通知処理手順について説明する。招待メール通知処理は、例えば、平日（月曜日〜金曜日）の８時などの予め決められた時刻に定期的に実行される。
【０１４７】
図１９は、実施の形態１にかかる情報処理装置１０１の招待メール通知処理手順の一例を示すフローチャートである。図１９のフローチャートにおいて、まず、情報処理装置１０１は、パーティＰｋの「ｋ」を「ｋ＝１」として（ステップＳ１９０１）、パーティ管理テーブル９００からパーティＰｋを選択する（ステップＳ１９０２）。
【０１４８】
つぎに、情報処理装置１０１は、パーティＰｋのランチメンバに対する招待メールを作成する（ステップＳ１９０３）。そして、情報処理装置１０１は、ユーザＤＢ５００を参照して、作成した招待メールをランチメンバの各メンバーのアドレス宛に送信する（ステップＳ１９０４）。
【０１４９】
つぎに、情報処理装置１０１は、「ｋ」をインクリメントして（ステップＳ１９０５）、「ｋ」が「Ｋ」より大きくなったか否かを判断する（ステップＳ１９０６）。ここで、「ｋ」が「Ｋ」以下の場合（ステップＳ１９０６：Ｎｏ）、情報処理装置１０１は、ステップＳ１９０２に戻る。
【０１５０】
一方、「ｋ」が「Ｋ」より大きい場合（ステップＳ１９０６：Ｙｅｓ）、情報処理装置１０１は、本フローチャートによる一連の処理を終了する。これにより、ランチメンバに対して、ランチを一緒に食べるメンバーとしての通知を行うことができる。
【０１５１】
（情報処理装置１０１の更新処理手順）
つぎに、実施の形態１にかかる情報処理装置１０１の更新処理手順について説明する。更新処理は、パーティ管理テーブル９００の記憶内容を更新する処理である。
【０１５２】
図２０は、実施の形態１にかかる情報処理装置１０１の更新処理手順の一例を示すフローチャートである。図２０のフローチャートにおいて、まず、情報処理装置１０１は、招待メールに対する返信メールをクライアント装置２０１から受信したか否かを判断する（ステップＳ２００１）。
【０１５３】
ここで、情報処理装置１０１は、返信メールを受信するのを待つ（ステップＳ２００１：Ｎｏ）。そして、情報処理装置１０１は、返信メールを受信した場合（ステップＳ２００１：Ｙｅｓ）、パーティ管理テーブル９００から、返信メールに含まれるパーティＩＤに対応するパーティ情報を検索する（ステップＳ２００２）。
【０１５４】
つぎに、情報処理装置１０１は、返信メールの送信元のメンバーについて、検索したパーティ情報の出欠、弁当フラグを設定して（ステップＳ２００３）、本フローチャートによる一連の処理を終了する。これにより、招待メールに対する返信メールを受信したことに応じて、パーティ管理テーブル９００の記憶内容を更新することができる。
【０１５５】
（情報処理装置１０１の開催／中止メール通知処理手順）
つぎに、実施の形態１にかかる情報処理装置１０１の開催／中止メール通知処理手順について説明する。開催／中止メール通知処理は、例えば、平日（月曜日〜金曜日）の１１時などの予め決められた時刻に定期的に実行される。
【０１５６】
図２１は、実施の形態１にかかる情報処理装置１０１の開催／中止メール通知処理手順の一例を示すフローチャートである。図２１のフローチャートにおいて、まず、情報処理装置１０１は、パーティＰｋの「ｋ」を「ｋ＝１」として（ステップＳ２１０１）、パーティ管理テーブル９００からパーティＰｋを選択する（ステップＳ２１０２）。
【０１５７】
つぎに、情報処理装置１０１は、パーティＰｋの各メンバーの出欠を参照して、ランチの出席者が３人以上となったか否かを判断する（ステップＳ２１０３）。ここで、ランチの出席者が３人以上の場合（ステップＳ２１０３：Ｙｅｓ）、情報処理装置１０１は、スケジュールＤＢ６００内の出席者のスケジュールにランチの予定を登録する（ステップＳ２１０４）。
【０１５８】
つぎに、情報処理装置１０１は、パーティＰｋの各メンバーの弁当フラグを参照して、ランチの出席者にお弁当を持参するメンバーが含まれるか否かを判断する（ステップＳ２１０５）。ここで、お弁当を持参するメンバーが含まれない場合（ステップＳ２１０５：Ｎｏ）、情報処理装置１０１は、飲食場所ＤＢ７００を参照して、飲食場所を検索する（ステップＳ２１０６）。
【０１５９】
なお、検索される飲食場所は、例えば、最寄駅がランチの参加者の少なくともいずれかのメンバーの最寄駅と一致し、当日が定休日でなく、かつ、ランチの開催時間が営業時間に含まれる飲食場所である。
【０１６０】
つぎに、情報処理装置１０１は、パーティ管理テーブル９００内のパーティＰｋの飲食場所ＩＤに、検索した飲食場所の飲食場所ＩＤを設定し（ステップＳ２１０７）、パーティＰｋの集合時間を設定する（ステップＳ２１０８）。
【０１６１】
そして、情報処理装置１０１は、ランチの出席者に対する開催メールを作成して（ステップＳ２１０９）、ユーザＤＢ５００を参照して、作成した開催メールを、ランチの出席者のアドレス宛に送信する（ステップＳ２１１０）。
【０１６２】
つぎに、情報処理装置１０１は、「ｋ」をインクリメントして（ステップＳ２１１１）、「ｋ」が「Ｋ」より大きくなったか否かを判断する（ステップＳ２１１２）。ここで、「ｋ」が「Ｋ」以下の場合（ステップＳ２１１２：Ｎｏ）、情報処理装置１０１は、ステップＳ２１０２に戻る。
【０１６３】
一方、「ｋ」が「Ｋ」より大きい場合（ステップＳ２１１２：Ｙｅｓ）、情報処理装置１０１は、本フローチャートによる一連の処理を終了する。
【０１６４】
また、ステップＳ２１０５において、お弁当を持参するメンバーが含まれる場合（ステップＳ２１０５：Ｙｅｓ）、情報処理装置１０１は、飲食場所ＤＢ７００を参照して、弁当持込可否「可」の飲食場所を検索して（ステップＳ２１１３）、ステップＳ２１０７に移行する。
【０１６５】
また、ステップＳ２１０３において、ランチの出席者が３人未満の場合（ステップＳ２１０３：Ｎｏ）、情報処理装置１０１は、パーティＰｋのランチメンバに対する中止メールを作成する（ステップＳ２１１４）。そして、情報処理装置１０１は、ユーザＤＢ５００を参照して、作成した中止メールを、ランチメンバの各メンバーのアドレス宛に送信して（ステップＳ２１１５）、ステップＳ２１１１に移行する。
【０１６６】
これにより、ランチの出席者が３人以上の場合には、ランチの出席者に対して、ランチの開催が決定したことの通知を行うことができる。また、ランチの出席者が３人未満の場合は、ランチメンバに対して、ランチの開催を中止したことの通知を行うことができる。
【０１６７】
以上説明したように、実施の形態１にかかる情報処理装置１０１によれば、ユーザＤＢ５００を参照して、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれる複数のユーザを抽出することができる。そして、情報処理装置１０１によれば、抽出した複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行うための招待メールを送信することができる。
【０１６８】
これにより、ランチを一緒に食べることができる程度にランチタイムの時間帯が重なる複数のユーザをランチメンバとしてマッチングすることができる。このため、複数種類のランチタイムを有する組織に属する人達でランチメンバのマッチングを行う場合でも、ランチタイムの時間帯が合わないという不都合が生じることを防いで、ランチが成立する確度を向上させることができる。
【０１６９】
また、情報処理装置１０１によれば、ランチを食べる場所の候補となる飲食場所の情報を含む招待メールを送信することができる。これにより、面識のないユーザ同士でランチに行く場合であっても、ランチを食べる場所を決めやすくすることができる。
【０１７０】
また、情報処理装置１０１によれば、ランチを食べる場所として選択された飲食店に対して、ランチメンバについてのランチの予約メッセージを送信することができる。これにより、飲食店に行っても満席で入ることができないなどの状況を避けることができるとともに、ランチメンバに手間をかけることなく飲食店の予約を行うことができる。
【０１７１】
また、情報処理装置１０１によれば、ランチを食べる場所の候補となる飲食店のクーポンを含む招待メール（あるいは、開催メール）を送信することができる。これにより、ユーザが入店時などに、招待メール（あるいは、開催メール）に含まれるクーポンを提示することで、割引などの特典を得ることができる。
【０１７２】
また、情報処理装置１０１によれば、スケジュールＤＢ６００を参照して、ランチの開催日における時間幅Ｔ以上の共通する時間帯に、他のスケジュールが入っていないユーザをランチメンバとして抽出することができる。これにより、ランチタイムの時間帯は合っていても、既に他のスケジュールが入っているためにランチに参加できないという不都合が生じることを防いで、ランチが成立する確度を向上させることができる。
【０１７３】
また、情報処理装置１０１によれば、ランチを食べることに同意する旨の返信メールを受信したメンバー数が所定数Ｘ以上となった場合に、スケジュールＤＢ６００内の各メンバーのスケジュールにランチの予定を登録することができる。これにより、ランチが開催できる程度に人数が集まった場合に、各メンバーのスケジュールを更新して、各メンバーの予定を確保することができる。
【０１７４】
また、情報処理装置１０１によれば、ランチメンバの中にお弁当を持参するメンバーが含まれる場合、ランチを食べる場所として、お弁当を持参可能な飲食場所の情報を通知することができる。これにより、お弁当を持参するメンバーが含まれていても、ランチを一緒に食べることができる飲食場所の情報を提供することができる。
【０１７５】
また、情報処理装置１０１によれば、グループＤＢ８００を参照して、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれ、かつ、友人関係を有するグループＧの組み合わせにより形成される複数のユーザを抽出することができる。これにより、ランチメンバの誰とも面識がないという状況を回避して、ランチが成立する確度を向上させることができる。
【０１７６】
また、情報処理装置１０１によれば、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれ、かつ、最寄駅が同一である複数のユーザを抽出することができる。これにより、ランチタイムの時間帯は合っていても、メンバー間の勤務地（事業所や建物の場所）が離れすぎていて集まることができないという不都合が生じることを防いで、ランチが成立する確度を向上させることができる。
【０１７７】
これらのことから、実施の形態１にかかる情報処理装置１０１によれば、複数種類のランチタイムを有する組織に属する人達でマッチングを行う場合であっても、ランチが成立しやすいメンバーのマッチングを実現することが可能となり、ユーザ間のコミュニケーションを促進して組織内の活性化を図ることができる。
【０１７８】
（実施の形態２）
つぎに、実施の形態２にかかる情報処理装置１０１について説明する。なお、実施の形態１で説明した箇所と同様の箇所については、同一符号を付して図示および説明を省略する。
【０１７９】
実施の形態２では、情報処理装置１０１は、将来の共通するイベントの参加者に含まれる複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行うことで、ランチが成立しやすいメンバーのマッチングを実現する。
【０１８０】
図２２は、実施の形態２にかかるランチのメンバー通知方法の一実施例を示す説明図である。図２２において、情報処理装置１０１は、複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行うコンピュータである。以下、実施の形態２にかかる情報処理装置１０１の処理例について説明する。
【０１８１】
（１）情報処理装置１０１は、スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出する。ここで、イベントとは、例えば、プロジェクト、会議、社内行事などである。
【０１８２】
図２２の例では、ユーザＡ〜Ｅがそれぞれ将来参加する予定のプロジェクトについてのスケジュールが登録されている。具体的には、ユーザＡについて、７月７日〜９月５日の期間に参加する予定のプロジェクトＸについてのスケジュールが登録されている。また、ユーザＢについて、８月１１日〜９月１２日の期間に参加する予定のプロジェクトＹについてのスケジュールが登録されている。
【０１８３】
また、ユーザＣについて、７月７日〜９月５日の期間に参加する予定のプロジェクトＸについてのスケジュールが登録されている。また、ユーザＤについて、７月７日〜９月５日の期間に参加する予定のプロジェクトＸについてのスケジュールが登録されている。また、ユーザＥについて、７月１８日〜８月２９日の期間に参加する予定のプロジェクトＺについてのスケジュールが登録されている。
【０１８４】
この場合、情報処理装置１０１は、スケジュール登録されたユーザＡ〜Ｅのうち、プロジェクトＸの参加者に含まれるユーザＡ，Ｃ，Ｄを抽出する。
【０１８５】
（２）情報処理装置１０１は、抽出した複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行う。図２２の例では、情報処理装置１０１は、抽出した各ユーザＡ，Ｃ，Ｄのアドレス宛に招待メール２２００を送信する。招待メール２２００には、例えば、ランチの開催日時、各メンバーの情報などが含まれる。
【０１８６】
ランチの開催日時としては、例えば、招待メール２２００の送信時刻以降であって、将来の共通するイベントの発生前の日時が設定される。図２２の例では、招待メール２２００において、プロジェクトＸに参加するユーザＡ，Ｃ，Ｄが、ランチを一緒に食べるランチメンバとして紹介される。
【０１８７】
このように、実施の形態２にかかる情報処理装置１０１によれば、スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出することができる。そして、情報処理装置１０１によれば、抽出した複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行うことができる。
【０１８８】
これにより、将来同じイベントに参加する予定の人達に対して、ランチを一緒に食べる機会を提供することができる。また、将来同じ目標を達成するためや、同じ行事に参加するために集まる人達がランチメンバとなるため、互いに面識がなくてもランチの参加意欲を高めることができる。
【０１８９】
（会議ＤＢ２３００の記憶内容）
つぎに、実施の形態２にかかる情報処理装置１０１が有する会議ＤＢ２３００の記憶内容について説明する。会議ＤＢ２３００は、例えば、図３に示した情報処理装置１０１のメモリ３０２、ディスク３０５等の記憶装置により実現される。
【０１９０】
図２３は、会議ＤＢ２３００の記憶内容の一例を示す説明図である。図２３において、会議ＤＢ２３００は、会議ＩＤ、会議名、会議開催回数、会議開始日時、会議終了日時および出席者のフィールドを有し、各フィールドに情報を設定することで、会議情報（例えば、会議情報２３００−１，２３００−２）をレコードとして記憶する。
【０１９１】
ここで、会議ＩＤは、会議を識別する識別子である。会議名は、会議の名称である。会議開催回数は、会議が開催された回数である。会議開始日時は、次回開催される会議の開始予定日時である。会議終了日時は、次回開催される会議の終了予定日時である。出席者は、次回開催される会議の出席者である。
【０１９２】
例えば、会議情報２３００−１は、会議Ｍ１の会議名「○×戦略会議」、会議開催回数「０」、会議開始日時「２０１４／７／１５  ９：００」、会議終了日時「２０１４／７／１５  １２：００」および出席者「Ｕ１，Ｕ３，Ｕ５，Ｕ７」を示す。
【０１９３】
（招待メールの具体例）
つぎに、ランチメンバに対して通知される招待メールの具体例について説明する。招待メールは、情報処理装置１０１からクライアント装置２０１（図２参照）に送信されて、クライアント装置２０１のディスプレイ４０６（図４参照）に表示される。
【０１９４】
図２４は、招待メールの具体例を示す説明図（その３）である。図２４において、ランチメンバに対して開催予定のランチの存在を通知する招待メール２４００がディスプレイ４０６に表示されている。招待メール２４００には、ランチの開催日時とランチメンバの顔写真、所属、氏名、自己紹介文が示されている。
【０１９５】
招待メール２４００によれば、ユーザは、７月１日（火）の１１時５０分〜１２時３０分に開催予定のランチに招待されていることがわかる。また、ユーザは、ランチを一緒に食べる他のメンバーが、将来参加する予定の「○×戦略会議」の出席者であることがわかる。さらに、ユーザは、ランチを一緒に食べる他のメンバーの顔写真、所属、氏名、自己紹介文などを閲覧して、ランチに参加するか否かを判断することができる。
【０１９６】
招待メール２４００において、例えば、入力装置４０７（図４参照）を用いたユーザの操作入力により、参加ボタンＢ１をクリック（あるいは、タップ）してから、返信ボタンＢ３をクリック（あるいは、タップ）すると、ランチに参加する旨の返信メールを情報処理装置１０１に送信することができる。
【０１９７】
また、招待メール２４００において、辞退ボタンＢ２をクリック（あるいは、タップ）してから、返信ボタンＢ３をクリック（あるいは、タップ）すると、ランチに参加しない旨の返信メールを情報処理装置１０１に送信することができる。
【０１９８】
（情報処理装置１０１の機能的構成例）
つぎに、実施の形態２にかかる情報処理装置１０１の機能的構成例について説明する。なお、実施の形態１にかかる情報処理装置１０１と同一機能については、同一符号を付して説明を省略する。
【０１９９】
図２５は、実施の形態２にかかる情報処理装置１０１の機能的構成例を示すブロック図である。図２５において、情報処理装置１０１は、抽出部２５０１と、作成部２５０２と、送信部１１０３と、受信部１１０４と、更新部１１０５と、を含む構成である。抽出部２５０１〜更新部１１０５は制御部となる機能であり、具体的には、例えば、図３に示したメモリ３０２、ディスク３０５などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、Ｉ／Ｆ３０３により、その機能を実現する。各機能部の処理結果は、例えば、メモリ３０２、ディスク３０５などの記憶装置に記憶される。
【０２００】
抽出部２５０１は、スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出する機能を有する。ここで、イベントとは、上述したように、プロジェクト、会議、社内行事などである。以下の説明では、イベントとして「会議」を例に挙げて説明する。
【０２０１】
具体的には、例えば、まず、抽出部２５０１は、会議ＤＢ２３００（図２３参照）からいずれかの会議Ｍを選択する。そして、抽出部２５０１は、選択した会議Ｍの出席者を、将来の共通するイベントの参加者に含まれる複数のユーザとして抽出することにしてもよい。
【０２０２】
また、抽出部２５０１は、会議ＤＢ２３００から会議Ｍを選択する際に、会議開始日時が所定期間Ｐ後の会議Ｍを選択することにしてもよい。所定期間Ｐは、システム側で任意に設定可能であり、例えば、１４日〜２１日後の期間に設定される。これにより、当日や翌日といった直近に開催予定となっている会議Ｍや、数ヶ月後などの開催までに長い期間が空いている会議Ｍを選択対象から除外することができる。
【０２０３】
また、抽出部２５０１は、会議ＤＢ２３００から会議Ｍを選択する際に、会議開催回数が「０」の会議Ｍ、すなわち、次回が１回目の会議Ｍを選択することにしてもよい。これにより、既に出席者同士が顔を合わせたことがある会議Ｍを選択対象から除外することができる。
【０２０４】
ここで、会議Ｍの出席者の全員が同一部署に所属している場合がある。この場合、会議Ｍの出席者同士は既に顔なじみの可能性がある。このため、抽出部２５０１は、会議ＤＢ２３００から会議Ｍを選択する際に、出席者が所属している部署が２以上の会議Ｍを選択することにしてもよい。
【０２０５】
以下の説明では、「将来の共通する会議の参加者に含まれる」という条件を、「条件８」と表記する場合がある。
【０２０６】
また、抽出部２５０１は、上記（条件１）および（条件８）を必須条件とし、上記（条件２）〜上記（条件７）を参考条件として、必須条件を満たし、かつ、複数の参考条件を満たす複数のユーザを抽出することにしてもよい。抽出された抽出結果は、パーティ管理テーブル９００（図９参照）に記憶される。
【０２０７】
また、抽出部２５０１は、抽出した複数のユーザの数が、予め設定された上限値Ｎmaxを超えている場合には、抽出した複数のユーザを、複数のランチメンバに分割することにしてもよい。この際、抽出部２５０１は、一つのランチメンバに同じ部署のメンバーが偏らないように、複数のユーザを分割することにしてもよい。
【０２０８】
作成部２５０２は、招待メールを作成する機能を有する。招待メールは、例えば、イベントの発生前、すなわち、将来の共通する会議の開催前の日程でのランチを一緒に食べることを示唆するものである。具体的には、例えば、作成部２５０２は、ランチの開催日時と、ランチメンバについての情報と、を含む招待メール（例えば、招待メール２４００）を作成する。
【０２０９】
ここで、ランチの開催日時（開催日、開催時間）は、システム側で任意に設定可能である。具体的には、例えば、作成部２５０２は、「１２：００〜１３：００」といった典型的なランチタイムを、ランチの開催時間に設定することにしてもよい。また、作成部２５０２は、ランチメンバの昼休み時間帯（ランチタイム）のうち全メンバー間で共通する時間帯を、ランチの開催時間に設定することにしてもよい。
【０２１０】
さらに、作成部２５０２は、例えば、スケジュールＤＢ６００（図６参照）を参照して、将来の共通する会議Ｍが開催されるまでの期間の中で、ランチメンバのうちランチの開催時間に他のスケジュールが入っていないメンバーの数が最も多い日を、ランチの開催日に設定することにしてもよい。
【０２１１】
この際、作成部２５０２は、他のスケジュールが入っていないメンバーの数が最も多い日が複数存在する場合には、最も早い日をランチの開催日に設定することにしてもよい。なお、招待メールを作成する具体的な処理内容は、実施の形態１で説明した処理内容と同様のため説明を省略する。
【０２１２】
作成部２５０２は、開催メールを作成する機能を有する。また、作成部２５０２は、中止メールを作成する機能を有する。なお、開催メールおよび中止メールを作成する具体的な処理内容は、実施の形態１で説明した処理内容と同様のため説明を省略する。
【０２１３】
（情報処理装置１０１の事前処理手順）
つぎに、実施の形態２にかかる情報処理装置１０１の事前処理手順について説明する。事前処理は、例えば、平日（月曜日〜金曜日）の７時などの予め決められた時刻に定期的に実行される。
【０２１４】
図２６は、実施の形態２にかかる情報処理装置１０１の事前処理手順の一例を示すフローチャートである。図２６のフローチャートにおいて、まず、情報処理装置１０１は、会議ＤＢ２３００から選択されていない未選択の会議Ｍを選択する（ステップＳ２６０１）。
【０２１５】
つぎに、情報処理装置１０１は、会議ＤＢ２３００を参照して、選択した会議Ｍの会議開催回数が「０」であるか否かを判断する（ステップＳ２６０２）。ここで、会議開催回数が「０」でない場合（ステップＳ２６０２：Ｎｏ）、情報処理装置１０１は、ステップＳ２６０８に移行する。
【０２１６】
一方、会議開催回数が「０」の場合（ステップＳ２６０２：Ｙｅｓ）、情報処理装置１０１は、ユーザＤＢ５００を参照して、選択した会議Ｍの出席者の所属部署が２以上であるか否かを判断する（ステップＳ２６０３）。ここで、所属部署が２以上でない場合（ステップＳ２６０３：Ｎｏ）、情報処理装置１０１は、ステップＳ２６０８に移行する。
【０２１７】
一方、所属部署が２以上の場合（ステップＳ２６０３：Ｙｅｓ）、情報処理装置１０１は、ユーザＤＢ５００を参照して、選択した会議Ｍの出席者について、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれるか否かを判断する（ステップＳ２６０４）。ここで、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれない場合（ステップＳ２６０４：Ｎｏ）、情報処理装置１０１は、ステップＳ２６０８に移行する。
【０２１８】
一方、時間幅Ｔ以上の共通する時間帯がランチタイムに含まれる場合（ステップＳ２６０４：Ｙｅｓ）、情報処理装置１０１は、ユーザＤＢ５００を参照して、選択した会議Ｍの出席者について、最寄駅が同一であるか否かを判断する（ステップＳ２６０５）。ここで、最寄駅が異なる場合（ステップＳ２６０５：Ｎｏ）、情報処理装置１０１は、ステップＳ２６０８に移行する。
【０２１９】
一方、最寄駅が同一の場合（ステップＳ２６０５：Ｙｅｓ）、情報処理装置１０１は、スケジュールＤＢ６００を参照して、選択した会議Ｍの出席者について、当日における時間幅Ｔ以上の共通する時間帯に他のスケジュールがあるか否かを判断する（ステップＳ２６０６）。
【０２２０】
ここで、他のスケジュールがある場合（ステップＳ２６０６：Ｙｅｓ）、情報処理装置１０１は、ステップＳ２６０８に移行する。一方、他のスケジュールがない場合（ステップＳ２６０６：Ｎｏ）、情報処理装置１０１は、選択した会議Ｍの出席者から形成されるパーティＰｋをパーティ管理テーブル９００に登録する（ステップＳ２６０７）。
【０２２１】
つぎに、情報処理装置１０１は、会議ＤＢ２３００から選択されていない未選択の会議Ｍがあるか否かを判断する（ステップＳ２６０８）。ここで、未選択の会議Ｍがある場合（ステップＳ２６０８：Ｙｅｓ）、情報処理装置１０１は、ステップＳ２６０１に戻る。
【０２２２】
一方、未選択の会議Ｍがない場合（ステップＳ２６０８：Ｎｏ）、情報処理装置１０１は、本フローチャートによる一連の処理を終了する。これにより、上記（条件１）、上記（条件３）および上記（条件８）を満たす複数のユーザを、ランチを一緒に食べるランチメンバとして抽出することができる。
【０２２３】
なお、実施の形態２にかかる情報処理装置１０１の招待メール通知処理手順については、図１９に示した招待メール通知処理手順と同様のため図示および説明を省略する。また、実施の形態２にかかる情報処理装置１０１の更新処理手順については、図２０に示した更新処理手順と同様のため図示および説明を省略する。また、実施の形態２にかかる情報処理装置１０１の開催／中止メール通知処理手順については、図２１に示した開催／中止メール通知処理手順と同様のため図示および説明を省略する。
【０２２４】
以上説明したように、実施の形態２にかかる情報処理装置１０１によれば、開催が予定されている会議Ｍの参加者に含まれる複数のユーザを抽出することができる。そして、情報処理装置１０１によれば、抽出した複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行うための招待メールを送信することができる。
【０２２５】
これにより、将来同じ会議Ｍに出席する予定の人達に対して、ランチを一緒に食べる機会を提供することができる。この場合、将来同じ目標や目的を達成するために集まる人達がランチメンバとなるため、互いに面識がなくてもランチの参加意欲を高めることができる。また、会議Ｍの開催前にメンバー間で親睦を深めることができ、目標や目的を達成するための業務の円滑化を図ることができる。
【０２２６】
なお、本実施の形態で説明したランチのメンバー通知方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本ランチのメンバー通知プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本ランチのメンバー通知プログラムは、インターネット等のネットワークを介して配布してもよい。
【０２２７】
上述した実施の形態に関し、さらに以下の付記を開示する。
【０２２８】
（付記１）コンピュータが、
昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出し、
抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行う、
処理を実行することを特徴とするランチのメンバー通知方法。
【０２２９】
（付記２）抽出される前記複数のユーザは、共通する組織に属する、ことを特徴とする付記１に記載のランチのメンバー通知方法。
【０２３０】
（付記３）前記通知は、前記ランチを食べる場所の候補としての飲食店の情報を含む、ことを特徴とする付記１または２に記載のランチのメンバー通知方法。
【０２３１】
（付記４）前記コンピュータが、
前記通知に含まれる前記飲食店の選択がなされると、前記メンバーについてのランチの予約メッセージを送信する、処理を実行することを特徴とする付記３に記載のランチのメンバー通知方法。
【０２３２】
（付記５）前記通知は、前記ランチを食べる場所の候補としての飲食店のクーポンを含む、ことを特徴とする付記１〜４のいずれか一つに記載のランチのメンバー通知方法。
【０２３３】
（付記６）前記所定の時間幅以上の共通する時間帯は、抽出される前記複数のユーザのそれぞれについて登録されたスケジュール情報が、既に他の予定で埋まっていない、ことを特徴とする付記１〜５のいずれか一つに記載のランチのメンバー通知方法。
【０２３４】
（付記７）前記通知は、前記ランチを食べることに同意するか否かの問い合わせを含み、
前記コンピュータが、
該問い合わせに対して前記複数のユーザのうち所定数以上のユーザについて同意する旨の応答を受信すると、抽出した前記複数のユーザのそれぞれのスケジュールに前記ランチの予定を登録する、処理を実行することを特徴とする付記１〜６のいずれか一つに記載のランチのメンバー通知方法。
【０２３５】
（付記８）前記コンピュータが、
前記抽出した前記複数のユーザの中に、お弁当を持参する旨の情報が設定されたユーザが含まれる場合、前記抽出した前記複数のユーザに対して、お弁当を持参可能な飲食場所として登録された飲食場所を通知することを特徴とする付記１〜７のいずれか一つに記載のランチのメンバー通知方法。
【０２３６】
（付記９）前記抽出する処理は、
前記複数のユーザのうち、前記所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれ、かつ、友人関係を有するユーザのペアの組み合わせにより形成される複数のユーザを抽出することを特徴とする付記１〜８のいずれか一つに記載のランチのメンバー通知方法。
【０２３７】
（付記１０）前記抽出する処理は、
前記複数のユーザのうち、前記所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれ、かつ、最寄駅が同一である複数のユーザを抽出することを特徴とする付記１〜９のいずれか一つに記載のランチのメンバー通知方法。
【０２３８】
（付記１１）コンピュータが、
スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出し、
抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行う、
処理を実行することを特徴とするランチのメンバー通知方法。
【０２３９】
（付記１２）抽出される前記複数のユーザは、共通する組織に属する、ことを特徴とする付記１１に記載のランチのメンバー通知方法。
【０２４０】
（付記１３）前記通知は、前記イベントの発生前の日程でのランチを一緒に食べることを示唆する、ことを特徴とする付記１１または１２に記載のランチのメンバー通知方法。
【０２４１】
（付記１４）前記通知は、前記ランチを食べる場所の候補としての飲食店の情報を含む、ことを特徴とする付記１１〜１３のいずれか一つに記載のランチのメンバー通知方法。
【０２４２】
（付記１５）前記コンピュータが、
前記通知に含まれる前記飲食店の選択がなされると、前記メンバーについてのランチの予約メッセージを送信する、処理を実行することを特徴とする付記１４に記載のランチのメンバー通知方法。
【０２４３】
（付記１６）前記通知は、前記ランチを食べる場所の候補としての飲食店のクーポンを含む、ことを特徴とする付記１１〜１５のいずれか一つに記載のランチのメンバー通知方法。
【０２４４】
（付記１７）前記通知は、前記ランチを食べることに同意するか否かの問い合わせを含み、
前記コンピュータが、
該問い合わせに対して前記複数のユーザのうち所定数以上のユーザについて同意する旨の応答を受信すると、前記複数のユーザのそれぞれのスケジュールに前記ランチの予定を登録する、処理を実行することを特徴とする付記１１〜１６のいずれか一つに記載のランチのメンバー通知方法。
【０２４５】
（付記１８）コンピュータに、
昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出し、
抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行う、
処理を実行させることを特徴とするランチのメンバー通知プログラム。
【０２４６】
（付記１９）コンピュータに、
スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出し、
抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行う、
処理を実行させることを特徴とするランチのメンバー通知プログラム。
【０２４７】
（付記２０）昼休みの時間帯が登録された複数のユーザのうち、所定の時間幅以上の共通する時間帯が昼休みの時間帯に含まれる複数のユーザを抽出し、抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとして通知を行う制御部、
を有することを特徴とする情報処理装置。
【０２４８】
（付記２１）スケジュール登録された複数のユーザのうち、将来の共通するイベントの参加者に含まれる複数のユーザを抽出し、抽出した前記複数のユーザに対して、ランチを一緒に食べるメンバーとしての通知を行う制御部、
を有することを特徴とする情報処理装置。
【符号の説明】
【０２４９】
１０１  情報処理装置
２００  ランチメンバ通知システム
２０１  クライアント装置
５００  ユーザＤＢ
６００  スケジュールＤＢ
７００  飲食場所ＤＢ
８００  グループＤＢ
９００  パーティ管理テーブル
１１０１，２５０１  抽出部
１１０２，２５０２  作成部
１１０３  送信部
１１０４  受信部
１１０５  更新部
２３００  会議ＤＢ
【図１】
2016045737.tif 000003
【図２】
2016045737.tif 000004
【図３】
2016045737.tif 000005
【図４】
2016045737.tif 000006
【図５】
2016045737.tif 000007
【図６】
2016045737.tif 000008
【図７】
2016045737.tif 000009
【図８】
2016045737.tif 000010
【図９】
2016045737.tif 000011
【図１０】
2016045737.tif 000012
【図１１】
2016045737.tif 000013
【図１２】
2016045737.tif 000014
【図１３】
2016045737.tif 000015
【図１４】
2016045737.tif 000016
【図１５】
2016045737.tif 000017
【図１６】
2016045737.tif 000018
【図１７】
2016045737.tif 000019
【図１８】
2016045737.tif 000020
【図１９】
2016045737.tif 000021
【図２０】
2016045737.tif 000022
【図２１】
2016045737.tif 000023
【図２２】
2016045737.tif 000024
【図２３】
2016045737.tif 000025
【図２４】
2016045737.tif 000026
【図２５】
2016045737.tif 000027
【図２６】
2016045737.tif 000028