JP2013178752A - 管理サーバ、その制御方法、及びそのプログラム - Google Patents

Abstract

【課題】各種のアプリケーションにおける仲間全体の状況を利用者に知らせる。
【解決手段】 管理サーバ３Ａは、アクセス要求を受信すると、第１ランキング処理を実行する（Ｓ１６１）。まず、ＣＰＵは、関係テーブルを参照して、（Group= Friends）*｛（UID_To=UIDa）+（UID_From=UIDa）｝*（Stat=1）を充足するレコードを抽出し、それらに含まれる一又は複数の利用者識別情報を特定する。次に、ＣＰＵは、抽出した利用者識別情報の数を種別情報ごとに集計し、集計数に基づいてゲームの人気順を特定する。遊んでいる仲間の多い順にゲームの説明などを配置して第１ランキングページを生成し、アクセス応答に含ませて端末装置２に返信する。
【選択図】図１７

Description

本発明は、あるサービスで仲間になった人を他のサービスに誘う技術に関する。

近年、インターネット上でのアプリケーションを提供するサービスが急速に普及している。この種のサービスの一つとして、ＳＮＳ（Ｓocial Ｎetworking Ｓervice）などのサイトで提供するゲームがある。この場合、ゲームシステムは、メールやチャットあるいは掲示板などをコミュニケーションのツールとして提供することが多い。そして、利用者は、コミュニケーションのツールを用いて他の利用者と知り合い仲間関係を構築する。仲間となった利用者は、強い敵と共同で戦うために他の利用者のゲームに参加することもある。
また、従来のゲームシステムでは、仲間候補の提示について要求があった利用者に対して、仲間相手の候補となる利用者を抽出し、これを提示することが行われていた（非特許文献１）。

「ソーシャルゲーム総合情報誌 アプリＳＴＹＬＥ Ｖｏｌ．２」、株式会社イースト・プレス、平成２３年４月１日、ｐ.３７

ところで、前記ゲームシステムにおいては、複数のゲームが提供されることが多く、ゲームの種類ごとにゲームサーバが設けられていた。そして、従来のゲームシステムでは、ゲームサーバごとに仲間関係を管理しており、仲間関係はゲームごとに独立していた。
したがって、個々のゲームサーバにアクセスすることにより、そのゲームサーバで提供するゲームについて仲間の状況を知ることができても、他のゲームの仲間の状況を把握するためには、当該他のゲームを提供するゲームサーバにアクセスする必要があり、さらには、各ゲームにおける仲間の状況を一元的に把握することができないという課題があった。
本発明は、この点に鑑みてなされたものであり、各種のアプリケーションにおける仲間全体の状況を利用者に知らせる管理サーバなどを提供することを解決課題とする。

以上の課題を解決するために本発明が採用する構成を以下に説明する。なお、本発明の理解を容易にするために以下では図面の参照符号を便宜的に括弧書で付記するが、本発明を図示の形態に限定する趣旨ではない。

上述した課題を解決するため、本発明に係る第１態様の管理サーバは、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能であって、利用者の端末装置の操作に基づく要求を受ける受付部（１１）と、前記複数のアプリケーションのうち、前記受付部で受け付けた要求の利用者である要求利用者が利用したことがある利用済みアプリケーションにおいて、前記要求利用者と仲間関係が構築されている利用者が利用しているアプリケーションに関する利用情報を取得する情報取得部（１５）と、前記情報取得部で取得した前記利用情報を前記要求利用者の端末装置に表示させる表示制御部（１４）と、を備える。

この発明においては、利用情報は、例えば、人気ゲームランキング、遊んでいる人数、仲間申請できる人数、招待できる人数の情報を含む。
また、利用者の端末装置の操作に基づく要求には、管理サーバが提供するページを閲覧している要求利用者が端末装置を操作することによって、端末装置から管理サーバに直接送信される要求の他に、複数のアプリケーションサーバのいずれかが提供するページを閲覧している要求利用者が端末装置を操作することによって、アプリケーションサーバから管理サーバに送信される要求がある。

また、より具体的には、前記要求には、アプリケーションの種類を示す種別情報が含まれており、前記情報取得部は、前記アプリケーションの種類を示す種別情報に関連付けて仲間関係となる利用者情報の組を備える仲間関係テーブルを参照して、前記要求利用者の利用者情報と仲間関係にある利用者の利用者情報と前記種別情報との組みを抽出し、抽出した前記利用者情報と前記種別情報との組みに基づいて前記利用情報を取得することが好ましい。

また、本発明に係る第２態様の管理サーバは、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能であって、利用者の端末装置の操作に基づく要求を受ける受付部（１１）と、前記複数のアプリケーションのうち、前記要求に対応づけられたアプリケーションにおいて、前記受付部で受け付けた要求の利用者である要求利用者と仲間関係が構築されている利用者が利用しているアプリケーションに関する利用情報を取得する情報取得部（１５）と、前記情報取得部で取得した前記利用情報を前記要求利用者の端末装置に表示させる表示制御部（１４）と、を備えることを特徴とする。

利用者の端末装置の操作に基づく要求には、管理サーバが提供するページを閲覧している要求利用者が端末装置を操作することによって、端末装置から管理サーバに直接送信される要求の他に、複数のアプリケーションサーバのいずれかが提供するページを閲覧している要求利用者が端末装置を操作することによって、アプリケーションサーバから管理サーバに送信される要求がある。

また、要求が端末装置から管理サーバに送信される場合、前記要求には、複数のアプリケーションのうち要求利用者が選択したアプリケーションを示す種別情報が含まれており、前記情報取得部は、前記要求に含まれる種別情報に基づいて、前記要求に対応づけられたアプリケーションを特定してもよい。一方、要求がアプリケーションサーバから送信される場合、前記情報取得部は、送信元であるアプリケーションサーバで提供するアプリケーションを前記要求に対応づけられたアプリケーションとして特定してもよい。

また、より具体的には、前記要求には、アプリケーションの種類を示す種別情報が含まれており、前記情報取得部は、前記アプリケーションの種類を示す種別情報に関連付けて仲間関係となる利用者情報の組を備える仲間関係テーブルを参照して、前記要求利用者の利用者情報と仲間関係にある利用者の利用者情報と前記種別情報との組みを抽出し、前記種別情報とアプリケーションの内容を示すアプリ情報とを関連付けて備えるアプリ情報テーブルを参照して抽出した前記種別情報に対応するアプリ情報を前記利用情報として取得してもよい。

上述した第１態様または第２態様の管理サーバにおいて、前記表示制御部は、前記利用情報として、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、各アプリケーションを利用している前記要求利用者と仲間関係が構築されている利用者の数の多い順にアプリケーションの種類の一部または全部を表示することが好ましい。

この発明において、表示制御部は、要求利用者と仲間関係が構築されている利用者の数の多い順にアプリケーションの種類を表示するが、具体的には、前記情報取得部は、利用者の数をアプリケーションごとに集計し、アプリケーションごとの集計数を前記利用情報として生成し、表示制御部は、集計した利用者の数の多い順にアプリケーションの種類を表示すればよい。

上述した第１態様または第２態様の管理サーバにおいて、前記表示制御部は、アプリケーションの種類を示す種別情報、前記アプリケーションの利用日時を示す日時情報、および利用者を特定する利用者情報を関連付けて備えるアクセステーブルを用いて、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、前記要求利用者と仲間関係が構築されている利用者であって、且つ所定期間内にアプリケーションを利用している利用者の数の多い順にアプリケーションの種類の一部または全部を表示することが好ましい。

この発明においては、表示制御部は、所定期間内にアプリケーションを利用している利用者の数の多い順にアプリケーションの種類を表示するが、具体的には、前記情報取得部は、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、前記アクセステーブルを用いて、前記要求利用者と仲間関係が構築されている利用者であって、且つ所定期間内にアプリケーションを利用している利用者の数をアプリケーションごとに集計し、アプリケーションごとの集計数を前記利用情報として生成し、表示制御部は、集計した利用者の数の多い順にアプリケーションの種類を表示すればよい。

上述した第１態様または第２態様の管理サーバにおいて、前記情報取得部は、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、前記要求利用者と仲間関係が構築されている利用者の数をアプリケーションごとに特定して前記利用情報を生成し、前記表示制御部は、アプリケーションごとに前記利用者の数を表示することが好ましい。

上述した第１態様または第２態様の管理サーバにおいて、前記情報取得部は、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、前記アプリケーションの種類を示す種別情報、前記アプリケーションの利用日時を示す日時情報、および利用者を特定する利用者情報を関連付けて備えるアクセステーブルを用いて、前記要求利用者と仲間関係が構築されている利用者であって、且つ所定期間内にアプリケーションを利用している利用者の数をアプリケーションごとに特定して前記利用情報を生成し、前記表示制御部は、アプリケーションごとに前記利用者の数を表示することが好ましい。

上述した第２態様の管理サーバにおいて、前記受付部は、アプリケーションの種類を示す種別情報を含む要求を受け付け、前記情報取得部は、前記受付部で受付けた種別情報が示すアプリケーションを利用していることを第１条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第２条件、当該アプリケーションにおいて仲間上限数に達していないことを第３条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する仲間申請が可能な利用者数を特定し前記利用者情報として取得する、ことを特徴とする。
この発明においては、仲間申請が可能な候補利用者の一部または全部を選択できるように端末装置に表示させて、利用者が候補利用者の中から選択して仲間申請が可能にするようにしてもよい。

上述した第２態様の管理サーバにおいて、前記受付部は、アプリケーションの種類を示す種別情報を含む要求を受け付け、前記情報取得部は、前記受付部で受付けた種別情報が示すアプリケーションを利用していないことを条件としたとき、前記条件を充足する利用者の数である招待が可能な利用者数を前記利用者情報として取得することが好ましい。
この発明においては、招待が可能な候補利用者の一部または全部を選択できるように端末装置に表示させて、利用者が候補利用者の中から選択して招待が可能にするようにしてもよい。

さらに、仲間申請可能な利用者の数と招待可能な利用者の数と並べて表示させ、さらに仲間申請が可能な候補利用者と招待可能な利用者とを選択的に端末装置に表示させるようにすると、例えば、具体的にどのアプリケーションのどの仲間を誘いたいかがあらかじめ決まっているような場合に、その相手が要求されたアプリケーションを未だ利用していないことが判明した場合に、招待可能な利用者の表示に切り替えることで、仲間申請でなく招待をすることができるようになる。このように、あるアプリケーションに仲間申請したい相手が当該アプリケーションを利用していない場合もあり得るので、仲間申請の機能と招待の機能を組にして端末装置で利用者に提供させることは、利用者にとって利便性が高まることになる。

上述した発明は、管理サーバのコンピュータに用いられるプログラムとして把握することができる。この場合、本発明に係るプログラムは、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバのコンピュータに用いられ、前記コンピュータを、利用者の端末装置の操作に基づく要求を受ける受付部と、前記複数のアプリケーションのうち、前記受付部で受け付けた要求の利用者である要求利用者が利用したことがある利用済みアプリケーションにおいて、前記要求利用者と仲間関係が構築されている利用者が利用しているアプリケーションに関する利用情報を取得する情報取得部と、前記情報取得部で取得した前記利用情報を前記要求利用者の端末装置に表示させる表示制御部として、機能させることを特徴とする。

上述した発明は、管理サーバの制御方法としても捉えることができる。この場合、本発明に係る管理サーバの制御方法は、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバを制御する方法であって、利用者の端末装置の操作に基づく要求を受ける受付け、前記複数のアプリケーションのうち、前記受付部で受け付けた要求の利用者である要求利用者が利用したことがある利用済みアプリケーションにおいて、前記要求利用者と仲間関係が構築されている利用者が利用しているアプリケーションに関する利用情報を取得し、前記取得した前記利用情報を前記要求利用者の端末装置に表示させる、ことを特徴とする。

本発明の実施形態に係るアプリケーションシステムのブロック図である。 管理サーバの構成を示すブロック図である。 利用者情報テーブルのデータ構造の一例を示す説明図である。 仲間上限数テーブルのデータ構造の一例を示す説明図である。 関係テーブルのデータ構造の一例を示す説明図である。 インバイトテーブルのデータ構造の一例を示す説明図である。 端末装置の構成を示すブロック図である。 共通処理に係るアプリケーションシステムの動作シーケンスを示すシーケンス図である。 マイページのメニューから「仲間を誘う」を選択した場合に表示される画面の一例である。 仲間処理の処理内容を示すフローチャートである。 仲間処理の処理内容を示すフローチャートである。 仲間探しページの一例を示す説明図である。 詳細ページの一例を示す説明図である。 仲間申請処理に関するアプリケーションシステムの動作シーケンスを示すシーケンス図である。 招待処理に関するアプリケーションシステムの動作シーケンスを示すシーケンス図である。 招待用の詳細ページの一例を示す説明図である。 ランキング処理に関するアプリケーションシステムの動作シーケンスを示すシーケンス図である。 ランキング処理の内容を示すフローチャートである。 ランキングページの一例を示す説明図である。 仲間数処理に関するアプリケーションシステムの動作シーケンスを示すシーケンス図である。 仲間数処理の内容を示すフローチャートである。 仲間数ページの一例を示す説明図である。 ランキング処理の内容を示すフローチャートである。 変形例に係る仲間処理の処理内容を示すフローチャートである。 変形例に係るランキング処理の内容を示すフローチャートである。 変形例に係る仲間数処理の内容を示すフローチャートである。 変形例における管理サーバの機能を示すブロック図である。 変形例における共通処理に係るアプリケーションシステムの動作シーケンスを示すシーケンス図である。 変形例に係る仲間処理の処理内容を示すフローチャートである。 変形例に係る仲間処理の処理内容を示すフローチャートである。 変形例に係る端末装置の構成を示すブロック図である。 変形例に係るアプリケーションサーバの構成を示すブロック図である。 変形例に係る仲間上限数通知処理の処理内容を示すフローチャートである。 変形例における管理サーバの機能を示すブロック図である。 変形例における処理内容を示すフローチャートである。 変形例における処理内容を示すフローチャートである。 変形例における管理サーバの機能を示すブロック図である。 変形例における処理内容を示すフローチャートである。 変形例におけるランキング処理の内容を示すフローチャートである。 変形例におけるランキング処理の内容を示すフローチャートである。 変形例におけるランキングページの一例を示す説明図である。 変形例に係るアプリケーションシステムのブロック図である。 第２の利用者情報テーブルのデータ構造の一例を示す説明図である。 第２の仲間上限数テーブルのデータ構造の一例を示す説明図である。 第２の関係テーブルのデータ構造の一例を示す説明図である。 変形例に係るアプリケーションシステムのブロック図である。 変形例に係るアプリケーションシステムのブロック図である。

以下、実施形態として、本発明に係る管理サーバを用いたアプリケーションシステムについて、図面を参照しつつ説明する。
＜１．アプリケーションシステムの構成＞
図１は、本発明の実施形態に係るアプリケーションシステム１００のブロック図である。このアプリケーションシステム１００は、インターネットなどの通信網１、利用者の端末装置２、管理サーバ３Ａ、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…を備える。アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…は、利用者同士のコミュニケーションを可能にするＳＮＳサイトを各利用者に対して提供するとともに、各種のサービスを利用者に提供する。利用者同士のコミュニケーションとは、利用者の間でメッセージの授受を行うことをいう。メッセージの授受は、例えば、掲示板、メール、チャット等を用いて行われる。この例ではアプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…が提供するサービスはゲームｂ、ゲームｃ、ゲームｄ…である。各アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…の利用者は、同じゲーム（アプリケーション）の利用者と仲間関係を構築し、仲間同士で挨拶やコメントなどのコミュニケーションを行うことによってゲーム上で交換価値があるポイントを獲得できる。また、ゲーム上での戦闘では、仲間の応援が得られるなど、仲間の数が多いほどゲームが有利に進行する。

仲間関係は、申請元の利用者が仲間申請を行い、これを申請先の利用者が承認することによって構築される。くわえて、アプリケーションシステム１００では、あるゲームをプレイしている利用者が、当該ゲームをプレイしていない他の利用者を当該ゲームに招待できるようになっている。

また、管理サーバ３Ａは、利用者同士のコミュニケーションを可能にするＳＮＳサイトを各利用者に対して提供するとともに、ポータルサイトとしても機能する。即ち、管理サーバ３Ａは、各アプリケーションサーバ３Ｂ、３Ｃ、…で構築された仲間関係を一元的に管理している。

利用者の端末装置２は、通信網１を介した通信が可能であり、例えば、パーソナルコンピュータや携帯電話機が該当する。アプリケーションシステム１００は、利用者に対して、利用者どうしのコミュニティ機能やゲームあるいはサービス及び商品の販売を提供することが可能である。

図２に管理サーバの構成を示す。この図に示すように、管理サーバ３Ａは、装置全体を制御するＣＰＵ（Central Processing Unit）３０、ＣＰＵ３０の作業領域として機能するＲＡＭ（Random Access Memory）３１、ブートプログラムなどを記憶したＲＯＭ（Read Only Memory）３２、各種のプログラムやデータを記憶するハードディスク３３、キーボードやマウスなどを含む入力部３４、画像を表示するディスプレイ３５、通信網１を介して外部の装置と通信を行う通信インターフェース３６、及びコンパクトディスクなどの情報記録媒体を読み取る読取装置３７を備える。

ハードディスク３３には、利用者情報テーブルＴＢＬ１１、仲間上限数テーブルＴＢＬ１２、関係テーブルＴＢＬ１３、インバイトテーブルＴＢＬ１４、アプリ情報テーブルＴＢＬ１５、及びＩＤ管理テーブルＴＢＬ１６などが記憶されている。

図３に利用者情報テーブルＴＢＬ１１のデータ構造を示す。利用者情報テーブルＴＢＬ１１には複数のレコードが記録されている。１つのレコードは、レコードを一意に識別するレコード識別情報ID、アプリケーションの種別を示す種別情報AppID、利用者を一意に識別する参照識別情報RefID、アプリケーションと利用者を一意に識別する利用者識別情報UID、および最後にログインした日付を示すラストログイン情報LastLoginとを備える。

参照識別情報RefIDは利用者に知らされておらず、システムの内部で用いられる。参照識別情報RefIDはＩＤ管理テーブルＴＢＬ１６で、利用者に既知であるログイン識別情報UserIDと参照識別情報RefIDとが対応づけられて管理されている。参照識別情報RefIDは、利用者が同じであれば、アプリケーションの種別が異なっていても同一であるが、利用者識別情報UIDは、アプリケーション毎に異なる。即ち、利用者識別情報UIDの機能は、種別情報AppIDの機能と参照識別情報RefIDの機能とを組み合わせたものに相当する。ただし、利用者識別情報UIDのみからアプリケーションの種別を特定できる必要はない。

例えば、ID＝１,２,３の各レコードには参照識別情報RefIDが「00000011」である同一の利用者が割り当てられており、ID＝１,２,３の各レコードは、種別情報AppIDが異なっており、利用者識別情報UIDも異なっている。
また、ログイン識別情報UserIDと参照識別情報RefIDの対応づけをＩＤ管理テーブルＴＢＬ１６で管理することで、例えばログイン識別情報UserIDが第三者に盗まれた場合には、新たなログイン識別情報UserIDを発行し、これを参照識別情報RefIDと紐づければよい。即ち、ＩＤ管理テーブルを更新するだけで、他のテーブルには影響を与えることがない。

図４に仲間上限数テーブルＴＢＬ１２のデータ構造を示す。仲間上限数テーブルＴＢＬ１２には複数のレコードが記録されている。１つのレコードは、レコード識別情報ID、利用者識別情報UID、および仲間上限数Limitが対応づけられて記憶される。上述したように、各アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…はアプリケーションとしてゲームを提供するが、ゲームごとに仲間の上限数が定められており、さらに、利用者のレベルに応じて上限数が変動する。各アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…は利用者の仲間上限数が変化すると、利用者識別情報ＵＩＤと仲間上限数Limitとの組みを管理サーバ３Ａに仲間上限数通知を送信するようになっている。管理サーバ３Ａは、仲間上限数通知を受信すると、仲間上限数テーブルＴＢＬ１２の内容を更新する。これによって、管理サーバ３Ａは、各利用者の仲間上限数Limitを一元的に管理することができる。

図５に関係テーブルＴＢＬ１３のデータ構造を示す。関係テーブルＴＢＬ１３には複数のレコードが記録されている。１つのレコードは、レコード識別情報ID、種別情報AppID、関係の種別を示すグループ情報Group、申請元の利用者の参照識別情報RefIDである申請元参照識別情報RefID_From、申請先の利用者の参照識別情報RefIDである申請先参照識別情報RefID_To、申請元の利用者の利用者識別情報UIDである申請元利用者識別情報UID_From、申請先の利用者の利用者識別情報UIDである申請先利用者識別情報UID_To、及び申請の状態を示す状態情報Statが対応づけられて記憶される。

仲間関係を記憶する場合に、申請元と申請先を分けて記憶したのは、記憶容量を削減する利点がある。仮に、ある利用者識別情報UIDと当該利用者と仲間関係にある全ての利用者の利用者識別情報UIDとを対応づけて記憶したとすると、２倍の記憶容量が必要となる。例えば、利用者Ａが申請元であり利用者Ｂが申請先であるとする。各利用者ごとに仲間関係にある利用者の利用者識別情報を記憶する場合には、利用者Ａについて利用者Ｂが仲間関係にあることを記憶し、さらに、利用者Ｂについて利用者Ａが仲間関係にあることを記憶する必要がある。これに対して、本実施形態では、申請先の利用者識別情報と申請元の利用者識別情報とを対応づけて１つのレコードに記憶するので記憶容量を半分にすることができる。また、状態情報Statを更新する場合でも半分の処理となる。

ある利用者と他の利用者の関係には、仲間関係、ライバル関係、及びブロック関係がある。仲間関係は、ある利用者から仲間申請があったことが他の利用者に伝えられ、他の利用者が承諾したことによって成立する。ライバル関係は、ある利用者がライバル視する他の利用者を申請することによって成立し、他の利用者の承諾を必要としない関係である。例えば、同じゲームをプレイしており、気になる他の利用者をライバルとして登録する場合に用いられる。ブロック関係は、ライバル関係と同様にブロックしたい他の利用者を申請することによって成立し、他の利用者の承諾を必要としない関係である。拒否しているにも拘わらず仲間申請が度々あったり、掲示板での発言などから迷惑している他の利用者を登録する場合に用いられる。

グループ情報Groupは、レコードが仲間関係を示す場合に「Friends」、レコードがライバル関係を示す場合に「Rival」、レコードがブロック関係を示す場合に「Block」を記録する。また、状態情報Statは、仲間申請中で「0」、承認済みで「1」、拒否済みで「2」を記録する。なお、ライバル関係とブロック関係は、申請のみで成立するため、状態情報Statは記録する必要がないため、「null」に設定している。なお、ライバル関係及びブロック関係では状態情報Statを一律「0」としてもよい。

例えば、ID＝１のレコードは、種別情報AppIDが「00000001」のゲームにおいて、参照識別情報RefIDが「00000011」の利用者から参照識別情報RefIDが「00003120」の利用者に対して仲間申請して承認されたことを示している。参照識別情報RefIDが「00000011」の利用者が仲間申請を行ったタイミングでID＝１のレコードが生成され、状態情報Statが「0」にセットされる。この後、参照識別情報RefIDが「00003120」の利用者が仲間申請を受領し、承認又は拒否したタイミングで、状態情報Statが承認「1」又は拒否「2」に更新される。

関係テーブルＴＢＬ１３を参照して、種別情報AppID を特定のゲームに限定すれば、そのゲームにおける利用者の仲間関係を把握することができる。状態情報Statから、既に仲間関係にある相手や、仲間申請中の仲間を把握することができる。
また、仲間関係が構築された後で仲間関係が解除された場合には、そのレコードを削除する。なお、レコードを削除せずに、レコードの有効/無効を示す項目を新たに追加し、仲間関係が解除されたレコードを無効とするようにしてもよい。仲間関係を解除した相手と仲間関係を再び構築する場合には新たなレコードを作成すればよい。

図６に招待の履歴を管理するインバイトテーブルＴＢＬ１４のデータ構造を示す。インバイトテーブルＴＢＬ１４の１つのレコードは、レコード識別情報ID、種別情報AppID、招待元の利用者の参照識別情報RefIDである申請元参照識別情報RefID_From、招待先の利用者の参照識別情報RefIDである申請先参照識別情報RefID_To、招待の年月日を示す日時情報Date及び招待の状態を示す状態情報Statが対応づけられて記憶される。状態情報Statが「0」の場合は招待を申請中であることを示し、状態情報Statが「1」の場合は招待を承認又は拒否したことを示す。

インバイトテーブルＴＢＬ１４を参照することによって、誰から誰にどのゲームに招待したかを知ることができる。例えば、例えば、ID＝１のレコードは、種別情報AppIDが「00000001」のゲームにおいて、参照識別情報RefIDが「00000011」の利用者から参照識別情報RefIDが「00003120」の利用者に対して招待して承認又は拒否されたことを示している。参照識別情報RefIDが「00000011」の利用者が招待を行ったタイミングでID＝１のレコードが生成され、状態情報Statが「0」にセットされる。この後、参照識別情報RefIDが「00003120」の利用者が招待を受領し、承認又は拒否したタイミングで、状態情報Statが「1」に更新される。

状態情報Statが「1」の場合は招待が承認又は拒否されており、この場合、管理サーバ３Ａは、承認又は拒否された相手には再度招待することができないように制御している。また、ＣＰＵ３０は、招待の年月日を示す日時情報Dateに基づいて、招待してから所定期間を超えて、招待申請中が継続した場合には、強制的に状態情報Statを拒否「1」に書き換える。なお、レコードの有効/無効を示す項目を新たに追加し、所定期間が過ぎた場合にレコードを無効とするようにしてもよい。

次に、図２に示すアプリ情報テーブルＴＢＬ１５の１つのレコードは、レコード識別情報ID、種別情報AppID、アプリケーション名（ゲーム名）を示すアプリ名情報、アプリケーション（ゲーム）の内容を示す説明情報、及びアプリケーションに対応するアイコンを示すアイコン情報が対応づけられて記憶されている。

管理サーバ３ＡのＣＰＵ３０は、所定の制御プロクラムを実行することによって、図１に示す受付部１１、特定部１２、指示部１３、表示制御部１４、情報取得部１５、及び通知部１６として機能する。
受付部１１は、仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置２を操作して指定したアプリケーションの種類を示す種別情報AppIDを受け付ける。ここで、種別情報AppIDは端末装置２から提供されてもよいし、あるいは、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…から提供されてもよい。
仲間申請において、特定部１２は、受付部１１で受付けた種別情報AppIDが示すアプリケーションを利用していることを第１条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第２条件、当該アプリケーションにおいて仲間上限数に達していないことを第３条件としたとき、要求利用者が利用したことのある利用済みアプリケーションのうち仲間に誘おうとするアプリケーション以外において仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定する。即ち、仲間申請では、仲間に誘おうとするゲーム以外で要求利用者と仲間関係が構築されている他の利用者であることを前提とし、仲間に誘おうとするゲームを対象として仲間申請を行うのであるから、当該ゲームを既に利用していることが必要である（第１条件）。また。これらから仲間になるように誘うのであるから、まだ仲間関係にないのは当然である（第２条件）。さらに、仲間上限数を考慮する必要がある（第３条件）。
一方、招待において、特定部１２は、受付部１１で受付けた種別情報AppIDが示すアプリケーションを利用していないことを条件としたとき、前記条件を充足する候補利用者の一部又は全部を特定する。

表示制御部１４は、特定部１２で特定した一部又は全部の候補利用者を選択できるように要求利用者の端末装置２に表示させる。より具体的には、候補利用者を選択可能なページを生成する（後述する図１３参照）。ここで、特定部１２で特定した一部の候補利用者を選択できるようにするとは、全部の候補利用者のうち、所定個数単位でページを切り替えて、順番に候補利用者を要求利用者に選択可能にする態様や、全部の候補利用者の中からランダムまたは所定の規則に従って抽出された候補利用者を要求利用者に選択可能にする態様が含まれる。また、下記情報取得部１５により取得したアプリケーションに関する利用情報を要求利用者の端末装置２に表示させる。
指示部１３は、受付部１１で受付けた種別情報AppIDが示すアプリケーションに対応したアプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…に対して、要求利用者が候補利用者の中から選択した利用者に対して仲間申請を要求する指示を行う。これにより、仲間申請された利用者はアプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…にアクセスした際に、仲間申請がなされていることに気がつく。すなわち、仲間申請された利用者は、自身のマイページ等で仲間申請が来ていることが知らされる。
情報取得部１５は、後述する問合処理において、受付部１１で受付けた所定の仲間に人気のある所定のアプリケーションに関する利用情報を取得する。詳しくは後述する。
通知部１６は、端末装置２に表示された候補利用者の中から選択した候補利用者に対して、招待申請を通知する。詳しくは後述する。

図７に端末装置２の構成を示す。端末装置２は、装置全体を制御するＣＰＵ２０、ＣＰＵ２０の作業領域として機能するＲＡＭ２１、ブートプログラムなどを記憶したＲＯＭ２２、各種のプログラムやデータを記憶する記憶装置２３、テンキーなどを含む入力部２４、画像を表示するディスプレイ２５、及び通信網１を介して外部の装置と通信を行う通信インターフェース２６を備える。

＜２．アプリケーションシステムの動作＞
アプリケーションシステム１００では、ある利用者がプレイしているゲームに当該ゲームをプレイしていない他の利用者を招待したり、あるいは当該ゲームをプレイしている他の利用者（他のゲームでの仲間を含む）に対して仲間申請を行うことができる。また、利用者は自身がプレイしている複数のゲームでの仲間に人気が高いゲームや各ゲームをプレイしている仲間数などを問い合わせることができる。以下、招待と仲間申請に共通の共通処理、仲間申請に係る仲間申請処理、招待に係る招待処理、及び各種の問い合わせに関する問合処理について説明する。

＜２−１：共通処理＞
図８に共通処理に関するアプリケーションシステムの動作シーケンスを示す。端末装置２の利用者が、ウェブブラウザ上で動作したり、端末装置２にインストールされて動作するアプリケーションを起動して、アプリケーションのログインページにアクセスすると、端末装置２のディスプレイ２５には、ログイン画面が表示される。このログイン画面には、ログイン識別情報UserIDとパスワードPSWとを入力する入力ボックスが表示される。利用者が、入力ボックスに入力して送信ボタンを押すと、端末装置２のＣＰＵ２０は、入力したログイン識別情報UserID及びパスワードを含むログイン要求を管理サーバ３Ａに送信する。

ログイン要求を管理サーバ３ＡのＣＰＵ３０が受信すると、管理サーバ３ＡのＣＰＵ３０は認証処理を実行する（Ｓ１）。具体的には、ＣＰＵ３０は、ログイン識別情報UserIDとパスワードとの組みが記憶されているか否かを判定し、判定条件を充足する場合にはログインを許可し、判定条件が充足されない場合にはログインを拒絶する。そして、ＣＰＵ３０は判定結果を示すログイン応答を端末装置２に送信する。なお、図８に示す例では、ログインが許可されたものとする。一度、端末装置２で入力されたログイン識別情報UserIDとパスワードとの組みは、端末装置２に所定期間記憶されて、当該所定期間内であればログインを省略可能としてもよい。

この後、利用者がメニューを選択してゲームｂを選択したとする（Ｓ２）。この場合、端末装置２のＣＰＵ２０は、ゲームｂのマイページ閲覧要求を管理サーバ３Ａに送信する。
管理サーバ３ＡのＣＰＵ３０はマイページ閲覧要求を受信すると、ＩＤ管理テーブルＴＢＬ１６を参照して、ログイン識別情報UserIDに対応した参照識別情報RefIDを取得し、さらに利用者情報テーブルＴＢＬ１１を参照して、参照識別情報RefID及びゲームｂの種別情報AppIDに対応する利用者識別情報UIDを取得する（Ｓ３）。

この後、管理サーバ３ＡのＣＰＵ３０が、利用者識別情報UIDを含むマイページ閲覧要求をゲームｂを提供するアプリケーションサーバ３Ｂに送信すると、アプリケーションサーバ３Ｂは、利用者識別情報UIDに対応するゲームｂのマイページを生成し、これをページ閲覧応答として、管理サーバ３Ａを介して端末装置２に送信する。
なお、ステップＳ３で取得した利用者識別情報UIDを端末装置２へ通知し、それ以降、管理サーバ３Ａを介さずに、端末装置２とアプリケーションサーバ３Ｂとの間で通信を行わせるようにしてもよい。

端末装置２のＣＰＵ２０はマイページ閲覧応答を受信すると、ディスプレイ２５にゲームｂのマイページを表示する（Ｓ５）。利用者がマイページのメニューから「仲間を誘う」を選択すると、例えば、図９に示す画面が表示される。この画面において、利用者が「おまかせで申請」のボタン１１２をクリックすると、アプリケーションサーバ３Ｂは、当該利用者と仲間関係が構築されていない他の利用者を抽出し、抽出した利用者のリストのページを生成して端末装置２に通知する。利用者は、リストの中から仲間になりたい利用者を選択する。管理サーバ３ＡのＣＰＵ３０は、利用者によって選択された利用者に仲間申請があったことを当該利用者のマイページに表示することなどで伝える。なお、利用者の現在の仲間数がゲームｂでの仲間上限数に達している場合には、「おまかせで申請」のボタン１１２を操作できないように無効化されていたり、ボタン１１２が表示されないようになっている。

一方、この画面において、利用者がボタン１１１をクリックして「他のゲームから探す」を選択すると、管理サーバ３Ａの仲間ページへ移行する。即ち、ボタン１１１はＳＮＳサイトの仲間ページへのリンクが定義されたものである。なお、このリンクの定義には、ゲームｂを示す種別情報AppIDと利用者を示す利用者識別情報UIDが含まれる。管理サーバ３ＡのＣＰＵ３０が仲間ページへのアクセス要求を受信すると、管理サーバ３ＡのＣＰＵ３０は仲間処理を実行し（Ｓ７）、アクセス応答を返信する。

次に、仲間処理の処理内容を図１０及び図１１を参照して説明する。以下の説明では、「他のゲームから探す」を選択した利用者を利用者Ａと称し、利用者Ａに関する情報には「a」を添え字として付加し、他の利用者の情報には「*」を添え字として付加する。また、種別情報AppIDは、利用者Ａと他の利用者とに共通の情報であり、ゲームごとに一意に定められる情報なので、「ｘ」を添え字として付加する。さらに、利用者識別情報UIDは、ゲームごとに付与される情報であり、同一の利用者であってもゲームが異なれば利用者識別情報UIDも異なる。そこで、利用者Ａの利用者識別情報UIDには「aｘ」を添え字として付加し、他の利用者の利用者識別情報UIDには「*ｘ」を添え字として付加する。
まず、ＣＰＵ３０は、受信したアクセス要求に含まれる利用者識別情報UIDaxと、他の利用者を誘うゲームの種別情報AppIDxとを取得する（Ｓ１００）。ここで、取得した種別情報AppIDｘは「00000001」であり「ゲームｂ」を示しており、仲間申請や招待の対象となるゲームである。また、取得した利用者識別情報UIDaxは「XCV56714」とする。

次に、ＣＰＵ３０は、利用者Ａ自身が仲間上限数に達しているか否かの判断を行う処理（Ｓ１０１〜Ｓ１０４）を行う。まず、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、利用者Ａの利用者識別情報UIDaxと仲間関係（Stat=1）または仲間申請中（Stat=0）にある利用者の利用者識別情報UID*xを抽出し、その数を集計する（Ｓ１０１）。さらに、ＣＰＵ３０は、仲間上限数テーブルＴＢＬ１２を参照して、着目する利用者Ａの利用者識別情報UIDaxに対応する仲間上限数を取得する（Ｓ１０２）。

次に、ＣＰＵ３０は、取得した仲間上限数が仲間の利用者識別情報UID*xの集計数を超えるか否かを判定する(Ｓ１０３)。この判定条件が否定される場合は、既に利用者Ａにおける仲間の利用者識別情報UID*xは他の利用者を誘う対象となるゲームについて仲間上限数に達しているので、仲間申請が不能となる。この場合、ＣＰＵ３０は、仲間申請が不能である旨のフラグをセットする（Ｓ１０４）。

次に、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、利用者識別情報UIDaxから利用者Ａの参照識別情報RefIDaを取得する（Ｓ１０５）。さらに、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、利用者Ａの参照識別情報RefIDaに対応する種別情報AppIDxと利用者識別情報UIDaxとの組みを一又は複数特定する（Ｓ１０６）。例えば、利用者情報テーブルＴＢＬ１１の記憶内容が図３に示すものであり、利用者Ａの参照識別情報RefIDaが「00000011」であるとする。この場合、種別情報AppIDxと利用者識別情報UIDaxとの組みは、（AppID＝00000001,UID＝XCV56714）、（AppID＝00000002,UID＝YUJ85224）、（AppID＝00000003,UID＝23150QWE）となる。なお、抽出した全ての種別情報AppIDxと利用者識別情報UIDaxとの組みには、仲間申請や招待の対象となるゲームにおける組（AppID＝00000001,UID＝XCV56714）が含まれているので、以降の処理では当該ゲームを除いた組を、抽出した全ての種別情報AppIDxと利用者識別情報UIDaxとの組みとして説明する。つまり、当該ゲームで既に仲間となっている利用者に対しては、仲間申請や招待の対象に成りえないからである。

次に、ＣＰＵ３０は、抽出した全ての種別情報AppIDxと利用者識別情報UIDaxとの組みに対してＳ１０８〜Ｓ１１９の処理が終了したか否かを判定する（Ｓ１０７）。Ｓ１０８〜Ｓ１１９の処理が終了の処理が終了している場合には、仲間処理を終了する。一方、抽出したの種別情報AppIDxと利用者識別情報UIDaxとの組みのうち、Ｓ１０８〜Ｓ１１９の処理が終了していない場合には、未処理の種別情報AppIDxと利用者識別情報UIDaxとの組みのうち一つに着目する。

この後、ＣＰＵ３０は、アプリ情報テーブルＴＢＬ１５を参照して、着目する種別情報AppIDxに対応するアプリケーション名やアイコン情報を取得する（Ｓ１０８）。取得したアプリケーション名（ゲーム名）は、後述する仲間探しページの領域１２２に表示され（図１２参照）、アイコン情報で示されるアイコンは領域１２１に表示される。

次に、ＣＰＵ３０は、着目するアプリケーションでの仲間数を計数する処理（Ｓ１０９〜Ｓ１１０）を行う。まず、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、着目する利用者識別情報UIDaxに対応する仲間の利用者識別情報UID*xを抽出する（Ｓ１０９）。これによって、利用者Ａが他の利用者を誘おうとするゲーム以外のあるゲームにおいて、利用者Ａと仲間関係が構築されている仲間の利用者識別情報UID*xが抽出される。より具体的には、あるゲームにおける利用者Ａの利用者識別情報UIDaxと申請元利用者識別情報UID_Fromとが一致するレコードから申請先参照識別情報RefID_Toを抽出するとともに、利用者識別情報UIDaxと申請先利用者識別情報UID_Toとが一致するレコードから申請元参照識別情報RefID_Fromを抽出する。そして、抽出した申請先参照識別情報RefID_Toと抽出した申請元参照識別情報RefID_Fromに対応する利用者識別情報UIDが、利用者Ａと仲間関係が構築されている仲間の利用者識別情報UID*xとなる。

次に、ＣＰＵ３０は、抽出した仲間の利用者識別情報UID*xの数を集計する（Ｓ１１０）。集計された仲間の数は、仲間探しページにおいてゲームごとに表示される仲間数として表示される（後述する図１２の領域１２３を参照）。

次に、着目するアプリケーションに招待することが可能な利用者を特定する処理（Ｓ１１１〜Ｓ１１２）を行う。まず、ＣＰＵ３０は、招待の対象となるゲームをプレイしていない利用者を候補利用者としたとき、利用者情報テーブルＴＢＬ１１を参照して、Ｓ１０９で抽出した仲間の利用者識別情報UID*xの中で、招待するゲームをプレイしていない候補利用者の利用者識別情報UID*xを抽出する（Ｓ１１１）。具体的には、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、Ｓ１０９で抽出した仲間の利用者識別情報UID*xに対応する仲間の参照識別情報RefID*を取得し、さらに、取得した参照識別情報RefID*に対応する一又は複数の種別情報AppIDxを取得する。そして、取得した一又は複数の種別情報AppIDxに招待するゲームの種別情報AppIDxが含まれていない場合に、招待するゲームをプレイしていない候補利用者の利用者識別情報UID*xと参照識別情報RefID*とを抽出する。このように、本実施形態によれば、各種のゲームの種別情報と全ての利用者の利用者識別情報UIDとを対応づける利用者情報テーブルＴＢＬ１１を備えるので、複数のゲームの利用者を一元的に管理することが可能となる。

次に、ＣＰＵ３０は、インバイトテーブルＴＢＬ１４を参照して、利用者Ａを示す参照識別情報RefIDaが招待元、且つ候補利用者の利用者識別情報UID*xに対応する参照識別情報RefID*が招待先としてインバイトテーブルＴＢＬ１４に記録されている場合には、当該利用者識別情報UID*xを、候補利用者の利用者識別情報UID*xから除外し、残りの候補利用者の利用者識別情報UID*xを抽出し、集計する（Ｓ１１２）。即ち、インバイトテーブルＴＢＬ１４には招待中または招待済みの招待元の利用者と招待先の利用者とが組で記録されているので、過去に一度でも招待したことのある利用者の組では、再度招待しないようにしている。これにより、利用者Ａが招待可能な他の利用者とその人数とを特定することができる。集計された招待可能な仲間の数は、仲間探しページにおいてゲームごとに表示される（後述する図１２の領域１２４を参照）。

次に、ＣＰＵ３０は着目するアプリケーションで仲間申請が可能な利用者を特定する処理（Ｓ１１３〜Ｓ１１８）を行う。なお、Ｓ１０４の処理で仲間申請が不能である旨のフラグがセットされている場合、ＣＰＵ３０は、当該処理を行わずに、Ｓ１１９へ進む。まず、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、まだ仲間になっていない非仲間の利用者の利用者識別情報UID*xを抽出する（Ｓ１１３）。ＣＰＵ３０は、仲間に誘おうとするゲーム以外で仲間申請を行う利用者Ａと仲間関係がある他の利用者であって、当該ゲームを既に利用している利用者を抽出し（第１条件）、さらに、関係テーブルＴＢＬ１３を参照して、当該ゲームにおいて利用者Ａと仲間関係が構築されていない利用者（第２条件）を抽出する。したがって、本実施形態によれば、仲間申請において申請側と承諾側との組を関係テーブルＴＢＬ１３に記憶することにより、一つの利用者情報をキーとして当該利用者情報と仲間関係にある全ての利用者情報を記憶する必要はないので、データの記憶容量を削減することが可能となる。

上述したＳ１０５において、利用者Ａが利用しているゲームの種別を示す種別情報AppIDxとそれらのゲームの利用者Ａの利用者識別情報UIDaxが特定され、Ｓ１０６以降では、抽出された種別情報AppIDxと、当該種別情報AppIDxに対応するゲームを利用している他の利用者の利用者識別情報UIDaxとの組の一つに着目している。即ち、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、利用者Ａが利用しているゲームを利用している他の利用者（第１条件）を抽出している。
また、ＣＰＵ３０は、上述した第１の条件を充足する他の利用者を、Ｓ１０９の抽出結果を用いて特定してもよい。また、ＣＰＵ３０が、関係テーブルＴＢＬ１３を参照して、利用者Ａが仲間に誘おうとするゲームにおいて利用者Ａと仲間関係が構築されている他の利用者の利用者識別情報UID*xをＳ１０５の抽出結果を用いて特定してもよい。そして、ＣＰＵ３０は、第１条件を充足する他の利用者から、Ｓ１０５の抽出結果で特定される他の利用者を除いて、まだ仲間になっていない非仲間の利用者の利用者識別情報UID*xを抽出する。

次に、ＣＰＵ３０は、Ｓ１１３で抽出した全ての非仲間の利用者識別情報UID*xについて、Ｓ１１５〜Ｓ１１９の処理が完了したか否かを判定する（Ｓ１１４）。判定条件が充足される場合、ＣＰＵ３０は処理をＳ１１８に進める。一方、判定条件が充足されなかった場合、ＣＰＵ３０は処理をＳ１１５に進め、関係テーブルＴＢＬ１３を参照して着目する非仲間の利用者識別情報UID*xの仲間数を集計する。この場合、ＣＰＵ３０は、上述したＳ１０９と同様に、非仲間の利用者識別情報UID*xと申請元利用者識別情報UID_Fromとが一致するレコードから申請先参照識別情報RefID_Toを抽出するとともに、非仲間の利用者識別情報UID*xと申請先利用者識別情報UID_Toとが一致するレコードから申請元参照識別情報RefID_Fromを抽出する。そして、抽出した申請先参照識別情報RefID_Toと抽出した申請元参照識別情報RefID_Fromに対応する利用者識別情報UIDの数が、非仲間の利用者識別情報UID*xの数となり、ＣＰＵ３０はこれを集計する。

次に、ＣＰＵ３０は、仲間上限数テーブルＴＢＬ１２を参照して着目する非仲間の利用者識別情報UID*xの仲間上限数を取得する（Ｓ１１６）。この後、ＣＰＵ３０は、取得した仲間上限数と集計した仲間数とを比較し、集計数が仲間上限数に達していない場合に、非仲間の利用者を仲間申請可能であると判断し（第３条件を充足）、集計数が仲間上限数に達している場合に非仲間の利用者を仲間申請不可能であると判断する（Ｓ１１７）。次に、ＣＰＵ３０は処理をＳ１１４に戻し、Ｓ１１４の判定条件が充足されるまでＳ１１４からＳ１１７を繰り返し、Ｓ１１４の判定条件が充足されと、処理をＳ１１８に進める。

Ｓ１１８において、ＣＰＵ３０は、仲間申請可能な非仲間の利用者識別情報UID*xを特定し、非仲間の人数を集計する。非仲間の集計数は、当該ゲーム以外の他のゲームにおいて仲間関係にあり当該ゲームにおいて仲間関係にない利用者の人数である。非仲間の集計数は、仲間探しページにおいてゲームごとに表示される（後述する図１２の領域１２５を参照）。

次に、ＣＰＵ３０は、着目する種別情報AppIDxに対応するゲームについて、Ｓ１０４の処理で取得したゲーム情報、Ｓ１１０の処理で集計したプレイしている仲間数、Ｓ１１２の処理で集計した招待可能な人数、およびＳ１１８の処理で集計した仲間申請可能な人数を一時的に変数領域やワークエリアに記憶させる（Ｓ１１９）。
この後、ＣＰＵ３０は、処理を図１０に示すＳ１０７に戻す。そして、Ｓ１０２で抽出した全ての種別情報AppIDxについてＳ１０７からＳ１１９の処理を終了すると、仲間の人数が多い順にゲームを配置した仲間探しページを生成し（Ｓ１２０）、処理を終了する。
なお、Ｓ１０４の処理で仲間申請が不能である旨のフラグがセットされている場合には、Ｓ１１０の処理で集計したプレイしている仲間数の替わりに、その表示を非表示にしたり、「申請可能人数に達しているため申請できません」といった表示をする。

説明を図８に戻す。管理サーバ３Ａにおいて仲間処理が終了し（Ｓ７）、仲間探しページが生成されると、管理サーバ３ＡのＣＰＵ３０は仲間探しページを含む仲間応答を端末装置２に送信する。端末装置２のＣＰＵ２０は、仲間応答を受信すると、仲間探しページをディスプレイ２５に表示する。図１２に仲間探しページの一例を示す。この例では、ゲーム表示領域１２０、１３０、１４０が設けられており、利用している仲間の人数が多い順にゲームをゲーム表示領域１２０→ゲーム表示領域１３０→ゲーム表示領域１４０に表示する。

まず、領域１２１にはアプリ情報テーブルＴＢＬ１５から読み出したアイコン情報に基づいてアイコンが表示され、領域１２２にはアプリケーション名（ゲーム名）が表示される。これらの情報は、上述したＳ１０８の処理で取得される。次に領域１２３には、利用者Ａと仲間関係にある仲間の人数が表示される。この情報は、上述したＳ１１０の処理で取得される。次に領域１２４には、利用者Ａが招待可能な仲間の人数が表示される。この情報は、上述したＳ１１２の処理で取得される。さらに、領域１２５には、利用者Ａが仲間申請能な仲間の人数が表示される。この情報は、上述したＳ１１８の処理で取得される。
なお、この例では、ＣＰＵ３０は、利用済みアプリケーションごとに、利用者Ａが招待可能な仲間の人数と利用者Ａが仲間申請能な仲間の人数とを端末装置２に合わせて表示させたが、どちらか一方のみを表示させるように一部の機能だけを具備させてもよい。さらに、人数を表示させるのではなく、仲間申請または招待の候補となる利用者のユーザ名を表示されるようにしてもよいし、人数と候補となる利用者のユーザ名の両方を表示させるようにしてもよい。
また、この例では、ＣＰＵ３０は、仲間申請が可能な人数について、利用済みアプリケーションごとに特定し、利用済みアプリケーションごとに端末装置２に表示させたが、ＣＰＵ３０は、複数の利用済みアプリケーションの合計の仲間申請が可能な人数を特定し、これを要求利用者の端末装置２に表示させてもよい。また、招待可能な人数も仲間申請と同様に複数の利用済みアプリケーションの合計の人数を特定し、これを要求利用者の端末装置２に表示させてもよい。

次に、領域１２０、領域１３０、領域１４０に表示されるゲームのいずれかを利用者が選択すると（図８に示すＳ９）、端末装置２のＣＰＵ２０は、詳細ページ要求を管理サーバ３Ａに送信する。管理サーバ３ＡのＣＰＵ３０は詳細ページ要求を受信すると、選択されたゲームに対応する詳細ページを生成し（Ｓ１０）、詳細ページを含む詳細ページ応答を端末装置２に返送する。端末装置２のＣＰＵ２０は、詳細ページ応答を受信すると、詳細ページをディスプレイ２５に表示させる。

図１３に詳細ページの一例を示す。この例では、図１２に示す仲間探しページにおいて利用者Ａがゲームｂを選択したものとする。図１３に示すように詳細ページには、ボタン１４０とボタン１４１とが表示される。ボタン１４０は招待に対応しており、ボタン１４１は仲間申請に対応している。図１３に示す状態で利用者が「招待する」と表示されたボタン１４０をクリックすると、図１６に示す招待用の詳細ページに切り替わる。

また、図１３に示す仲間申請用の詳細ページには、領域１４２に、利用者Ａがゲームｂについて他のゲームで仲間の利用者を、あと何人、仲間申請可能かが表示される。仲間申請可能な人数は、図１２に示す領域１２５に表示される人数と同じであり、上述したＳ１１８の処理で取得される。なお、利用者Ａ自身の仲間上限数が、当該人数よりも少ない場合には、仲間上限数から現在の仲間数の差となる人数が表示される。また、領域１４３〜１４５には、仲間申請の候補となる利用者のユーザ名と、チェックボックス１４３ｂ、１４４ｂ、１４５ｂが表示される。チェックボックス１４３ｂ、１４４ｂ、１４５ｂにチェックを設定して、ボタン１４６をクリックすることにより、仲間申請を行うことができる。なお、仲間申請は、複数の相手に同時に行うことができる。
また、本実施形態によれば、利用済みゲームを選択できる画面を要求利用者の端末装置２に表示させ、選択した利用済みゲームについて仲間関係にあることが候補利用者の要件となるので、要求利用者は、招待しようとするゲームと類似する利用済みゲームを選択するなど、好みに合わせた選択が可能となる。

＜２−２：仲間申請処理＞
図１４に仲間申請処理に関するアプリケーションシステムの動作シーケンスを示す。まず、端末装置２において利用者Ａが仲間申請において仲間を選択すると（Ｓ１４０）、端末装置２のＣＰＵ２０は、仲間申請要求を管理サーバ３Ａに送信する。仲間申請要求には、申請元利用者識別情報UID_Fromと申請先利用者識別情報UID_Toが含まれている。

仲間申請要求を管理サーバ３ＡのＣＰＵ３０が受信すると、ＣＰＵ３０は、関係テーブルＴＢＬ１３の記憶内容を更新する（Ｓ１４１）。具体的には、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して申請元利用者識別情報UID_Fromに対応する申請元参照識別情報RefID_From及び申請先利用者識別情報UID_Toに対応する申請先参照識別情報RefID_Toを取得し、状態情報Statを「申請中」（Stat=0）に設定したレコードを生成し、関係テーブルＴＢＬ１３に記録する。このとき、種別情報AppIDは、仲間申請要求に含まれているのであれば、これを用いてもよいし、あるいは、利用者情報テーブルＴＢＬ１１を参照して申請元利用者識別情報UID_Fromあるいは申請先利用者識別情報UID_Toに対応する種別情報AppIDを取得してもよい。

ここで、利用者Ａが仲間申請しようとするのがゲームｂであり、ゲームｂでは仲間関係にはないが、ゲームｃにおいて仲間関係にある他の利用者に仲間申請する場合を想定する。この場合、管理サーバ３ＡのＣＰＵ３０は、仲間申請通知を申請先のゲームｂを管理するアプリケーションサーバ３Ｂに対して申請先の他の利用者の利用者識別情報UIDと共に送信する。即ち、ＣＰＵ３０は、ゲームｂを提供するアプリケーションサーバ３Ｂに対して、利用者Ａが候補利用者の中から選択した利用者に対して仲間申請を要求する指示を行う指示部として機能する。アプリケーションサーバ３Ｂは、仲間申請通知を受信すると、申請先の他の利用者のマイページにおいて、利用者Ａから仲間申請通知があったことを表示できるように管理テーブルを更新する（Ｓ１４２）。
また、管理サーバ３Ａは、仲間申請応答を端末装置２に返信する。端末装置２のＣＰＵ２０は、仲間申請応答を受信すると、マイページなどに仲間申請中であることを表示する。

このように本実施形態によれば、管理サーバ３Ａは第１条件乃至第３条件を充足する候補利用者を選択できるように利用者Ａの端末装置２に表示させる。ここで、第１条件乃至第３条件は以下の通りである。
第１条件：利用者Ａが利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち、利用者Ａが利用しているアプリケーションを利用している利用者。
第２条件：当該アプリケーションについて利用者Ａと仲間関係が構築されていない利用者。
第３条件：当該アプリケーションにおいて仲間上限数に達していない利用者。
これによって、異なるアプリケーションで形成された信頼関係を新しいアプリケーションでも活用できるようになる。つまり、あるゲームを利用者がプレイしている場合に、全く見知らぬ相手に仲間申請するのではなく、他のゲームで仲間になった気心の知れた利用者に仲間申請をすることができるので、新たなゲームを始める場合に、仲間関係を構築し易いといった利点がある。
また、本実施形態によれば、管理サーバ３Ａの関係テーブルＴＢＬ１３に、仲間関係となる利用者情報の組を記憶するから、各種のアプリケーションで構築される仲間関係を一元的に管理することができる。さらに、種別情報と利用者情報とを対応づけて記憶する利用者情報テーブルＴＢＬ１１を備えるので、この利用者情報テーブルＴＢＬ１１を参照することによって第１条件を充足することができる。
また、本実施形態によれば、申請側と承諾側との組を関係テーブルＴＢＬ１３に記憶することにより、一つの利用者情報をキーとして当該利用者情報と仲間関係にある全ての利用者情報を記憶する必要はないので、データの記憶容量を削減することが可能となる。
さらに、本実施形態によれば、第１の仲間上限数テーブルＴＢＬ１２を用いて、アプリケーションごとに定められる仲間上限数を管理サーバ３Ａで一元的に管理するので、第３条件を充足させることが可能となる。
また、本実施形態によれば、利用済みアプリケーションを選択できるように利用者Ａの端末装置２に表示させ、選択した利用済みアプリケーションについて仲間関係にあることが候補利用者の要件となるので、仲間申請を要求する利用者は、仲間関係を構築しようとするアプリケーションと類似する利用済みアプリケーションを選択することができたり、具体的にどのアプリケーションのどの仲間を誘いたいかがあらかじめ決まっている場合に探し易くなる。
さらに、本実施形態によれば、仲間申請が可能な人数を知ることができるので、仲間申請を要求する利用者に利便性が大幅に向上する。

＜２−３：招待処理＞
図１５に招待処理に関するアプリケーションシステムの動作シーケンスを示す。まず、端末装置２において利用者Ａが招待において仲間を選択すると（Ｓ１５０）、端末装置２のＣＰＵ２０は、招待要求を管理サーバ３Ａに送信する。図１６に招待用の詳細ページの一例を示す。この例では、図１２に示す仲間探しページにおいて利用者Ａがゲームｂを選択したものとする。招待用の詳細ページには、領域１４２に、利用者Ａがゲームｂについて他のゲームで仲間の利用者を、あと何人、招待可能かが表示される。招待可能な人数は、図１２に示す領域１２４に表示される人数と同じであり、上述したＳ１１２の処理で取得される。また、領域１４３〜１４５には、招待の候補となる利用者のユーザ名と、チェックボックス１４３ｂ、１４４ｂ、１４５ｂが表示される。チェックボックス１４３ｂ、１４４ｂ、１４５ｂにチェックを設定して、ボタン１４８をクリックすることにより、仲間の招待を行うことができる。なお、招待は、複数の相手に同時に行うことができる。
また、本実施形態によれば、招待申請が可能な人数を知ることができるので、要求利用者に利便性が大幅に向上する。
領域１４２に表示される招待可能な人数は、上述したＳ１１１及びＳ１１２の処理で取得される。まず、ＣＰＵ３０は、招待の対象となるゲームをプレイしていないことを条件として、この条件を満たす候補利用者を抽出する。つまり、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、招待の対象となるゲーム以外のあるゲームにおいて利用者Ａと仲間関係が構築されている仲間の利用者識別情報UID*xの中で、招待するゲームをプレイしていない候補利用者の利用者識別情報UID*xを抽出する（Ｓ１１１）。具体的には、利用者情報テーブルＴＢＬ１１を参照して、Ｓ１０９で抽出した仲間の利用者識別情報UID*xに対応する仲間の参照識別情報RefID*を取得し、さらに、当該仲間の利用者識別情報UID*xと、取得した参照識別情報RefID*と、当該参照識別情報RefID*に対応する一又は複数の種別情報AppIDxとの組を取得する。そして、取得した一又は複数の組の中から、招待するゲームの種別情報AppIDxを含まない組の候補利用者の利用者識別情報UID*xと参照識別情報RefID*、つまり、招待の対象となるゲームをプレイしていない候補利用者の利用者識別情報UID*xと参照識別情報RefID*とを抽出する。
次に、ＣＰＵ３０は、インバイトテーブルＴＢＬ１４を参照して、利用者Ａを示す参照識別情報RefIDaが招待元として、且つ候補利用者の利用者識別情報UID*xに対応する参照識別情報RefID*xが招待先としてインバイトテーブルＴＢＬ１４に記録されている組以外の組を抽出し、集計する（Ｓ１１２）。即ち、インバイトテーブルＴＢＬ１４に記録された招待中または招待済みの利用者を除外して、利用者Ａが新たに招待可能な候補利用者とその人数とを特定する。

図１５において、招待要求を管理サーバ３ＡのＣＰＵ３０が受信すると、ＣＰＵ３０は、インバイトテーブルＴＢＬ１４の記憶内容を更新する（Ｓ１５１）。具体的には、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して申請元利用者識別情報UID_Fromに対応する申請元参照識別情報RefID_From、申請先利用者識別情報UID_Toに対応する申請先参照識別情報RefID_To、及び種別情報AppID取得し、状態情報Statを「申請中」（Stat=0）に設定したレコードを生成し、インバイトテーブルＴＢＬ１４に記録する。図６に示すように、インバイトテーブルＴＢＬ１４の１つのレコードは、レコード識別情報ID、種別情報AppID、招待元の利用者の参照識別情報RefIDである申請元参照識別情報RefID_From、招待先の利用者の参照識別情報RefIDである申請先参照識別情報RefID_To、招待の年月日を示す日時情報Date及び招待の状態を示す状態情報Statが対応づけられて記憶される。状態情報Statが「0」の場合は招待を申請中であることを示し、状態情報Statが「1」の場合は招待を承認又は拒否したことを示す。ＣＰＵ３０は、状態に応じて状態情報Statの内容を書き換える。図６に示す例では、ＣＰＵ３０は、参照識別情報RefIDが「00000011」の利用者が招待を行ったタイミングでインバイトテーブルＴＢＬ１４におけるID＝１のレコードを生成し、状態情報Statを「0」に書き換える。この後、書換部５３は、参照識別情報RefIDが「00003120」の利用者が招待を受領し、承認又は拒否したタイミングで、状態情報Statを「1」に書き換える。
本実施形態においては、拒否と承認をまとめて第１状態としている。したがって、招待を拒否された場合だけでなく、招待が承認された場合にも候補利用者から除外される。招待を承認した利用者は、そもそも招待の対象となるゲームを既に利用しているから、招待する必要がない。このようなデータ構造を採用することにより、拒否した利用者と招待された利用者を同時に排除できるので処理負荷が軽減される。

ここで、利用者Ａが招待しようとするゲームがゲームｂであり、ゲームｃにおいて仲間関係にある他の利用者Ｂを招待する場合を想定する。利用者Ａは端末装置２-1を管理しており、利用者Ｂは端末装置２-2を管理しているとする。この場合、管理サーバ３ＡのＣＰＵ３０は、招待があったことを通知する招待メールを端末装置２-2に送信する。あるいは、管理サーバ３ＡのＣＰＵ３０は、利用者Ｂの管理サーバ３ＡのＳＮＳサイトのマイページに利用者Ａがゲームｂに招待していることを知らせるメッセージを表示するようにしてもよい。また、管理サーバ３ＡのＣＰＵ３０は、他のソーシャルメディアや掲示板へ招待記事を投稿するように送信してもよい。このようにＣＰＵ３０は、図１に示すように、利用者Ａが、端末装置２-1に表示された候補利用者の中から選択した候補利用者に対して招待申請を通知する通知部１６として機能する。

また、管理サーバ３ＡのＣＰＵ３０は、招待応答を端末装置２-1に返信する。端末装置２-1のＣＰＵ２０は、招待応答を受信すると、招待中であることを表示する。
このように本実施形態によれば、あるゲームを利用者がプレイしている場合に、全く見知らぬ相手を招待するのではなく、他のゲームで仲間になった気心の知れた利用者を招待することができるので、新たなゲームを他のゲームの仲間に広めることができ、さらに他のゲームの仲間が当該ゲームに参加した場合には、当該ゲームでも仲間関係を構築し易いといった利点がある。
また、特定部１２としてのＣＰＵ３０は、Ｓ１１２において、インバイトテーブルＴＢＬ１４を参照して招待可能な候補利用者の利用者識別情報UID*xを含むレコードを抽出する際、状態情報Statが「1」であるレコードについては、抽出対象のレコードから除外する。つまり、特定部１２は、状態情報Statが「1」の場合には招待が承認又は拒否されている場合なので、そのような相手には再度招待しないように制御している。したがって、本実施形態によれば、招待の状態を示す状態情報と利用者情報とを対応づけてインバイトテーブルＴＢＬ１４で管理するので、インバイトテーブルＴＢＬ１４を参照することによって、招待の状態を知ることができる。そして、状態情報が拒否を示す場合には、候補利用者から除かれるので、招待を拒否しているに拘わらず再度の招待があるといった迷惑行為を未然に防止することがきる。
また、本実施形態によれば、招待申請中の利用者も候補利用者から除かれるから、申請中に拘わらず、再度、招待を申請するといった無駄をなくし、管理サーバ３Ａの処理負荷を軽減することができる。

＜２−４：問合処理＞
問合処理は、利用者Ａの仲間の利用者が利用しているアプリケーションに関する利用情報を管理サーバ３Ａに問い合わせる処理である。利用情報には、仲間の中で人気のあるゲームのランキングやあるゲームを利用している仲間数、仲間申請できる人数、招待できる人数などが含まれる。
問合処理は、仲間に人気のゲームを知ることができるランキング処理と、あるゲームを特定して、特定したゲームを遊んでいる仲間の人数を問い合わせる仲間数処理を含む。
まず、ランキング処理について説明する。ランキング処理には、第１ランキング処理と第２ランキング処理とがある。第１ランキング処理は、特定のゲームで仲間関係にある利用者において人気のあるゲームの順位付けを行う処理である。一方、第２ランキング処理は、不特定のゲームで仲間関係にある利用者において人気のあるゲームの順位付けを行う処理である。

利用者Ａが端末装置２のディスプレイには、図９に示す画面が表示される。この画面においてボタン１１３は第１ランキング処理に対応しており、ボタン１１４は第２ランキング処理に対応している。

図１７にランキング処理に関するアプリケーションシステムの動作シーケンスを示す。 ボタン１１３（図９）をクリックして「この仲間に人気のゲームを見る」（第１ランキング処理）を選択すると（Ｓ１６０）、管理サーバ３Ａの人気アプリページへ移行する。即ち、ボタン１１３はＳＮＳサイトの人気アプリページへのリンクが定義されたものである。なお、このリンクの定義には、利用者を示す利用者識別情報UIDのリンク情報が含まれる。管理サーバ３ＡのＣＰＵ３０は、種別情報AppIDで示されるゲームでの仲間の間で人気アプリページへのアクセス要求を受信すると、第１ランキングページを生成する第１ランキング処理を実行する（Ｓ１６１）。

図２３に第１ランキング処理の内容を示す。まず、ＣＰＵ３０は、受信したアクセス要求に含まれる利用者識別情報UIDaxを取得する（Ｓ２００）。次に、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、グループ情報Groupが「Friends」を示し、利用者Ａの利用者識別情報UIDaxに対応する仲間の利用者の利用者識別情報UID*xを特定する（Ｓ２０１）。
より具体的には、ＣＰＵ３０は、（Group= Friends）*｛（UID_To=UIDax）+（UID_From=UIDax）｝*（Stat=1）を充足するレコードを抽出し、それらに含まれる一又は複数の利用者識別情報UID*xを特定する。
次に、ＣＰＵ３０は、抽出した利用者識別情報UID*xの数を種別情報AppIDxごとに集計する（Ｓ２０２）。さらに、ＣＰＵ３０は、仲間の利用者識別情報UID*xの集計数に基づいて、種別情報AppIDxで特定されるゲームの人気順を特定する。さらに、ＣＰＵ３０は、アプリ情報テーブルＴＢＬ１５を参照して、抽出した種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報を取得する。この後、ＣＰＵ３０は、第１ランキングページを生成する。この際、ＣＰＵ３０は、遊んでいる仲間の多い順にゲームの説明などを配置して第１ランキングページを生成する。
端末装置２は、管理サーバ３Ａから第１ランキングページを含むアクセス応答を受信すると、第１ランキングページをディスプレイ２５に表示する（Ｓ１６２）。
即ち、ＣＰＵ３０は、Ｓ２０１において複数のゲームのうち、図９に表示されるゲームにおける利用者Ａの利用者識別情報UIDaxを特定し、さらに、当該ゲームにおいて利用者Ａと仲間関係が構築されている利用者を利用者識別情報UID*xで特定し、さらに、特定した利用者、即ち、仲間がプレイしている各ゲームのランキングと、各ゲームをプレイしている仲間数とを示す利用情報を取得する情報取得部１５として機能する。
本実施形態によれば、情報取得部１５は、仲間の間で人気アプリページへのアクセス要求要求に対応づけられたアプリケーションにおいて、要求利用者である利用者Ａの仲間が利用しているアプリケーションに関する利用情報を取得する。そして、表示制御部１４はこれを端末装置２に表示させるので、要求利用者は特定のアプリケーションを介した仲間に関して様々な情報を得ることが可能となる。

また、ボタン１１４（図９）をクリックして「他の仲間に人気のゲームを見る」を選択すると（Ｓ１６３）、管理サーバ３Ａの人気アプリページへ移行する。即ち、ボタン１１３はＳＮＳサイトの人気アプリページへのリンクが定義されたものである。なお、このリンクの定義には、利用者を示す利用者識別情報UIDのリンク情報が含まれる。管理サーバ３ＡのＣＰＵ３０は、利用者がプレイした複数ゲームでの仲間の間で人気アプリページへのアクセス要求を受信すると、第２ランキングページを生成する第２ランキング処理を実行する（Ｓ１６４）。端末装置２のＣＰＵ２０は、管理サーバ３Ａから第２ランキングページを含むアクセス応答を受信すると、第２ランキングページをディスプレイ２５に表示する（Ｓ１６５）。
なお、ボタン１１３による人気アプリのランキングは、利用者の対象がある特定のゲームの仲間であることに対して、ボタン１１４による人気アプリのランキングは、利用者の対象が、当該利用者がプレイしている複数のゲームのいずれかで仲間であることである。仮に利用者が１つのゲームしかプレイしていない場合には、ボタン１１３による人気アプリのランキングの内容と、ボタン１１３による人気アプリのランキングの内容が同一になる。

図１８にランキング処理の内容を示す。まず、ＣＰＵ３０は、受信したアクセス要求に含まれる利用者識別情報UIDaxを取得する（Ｓ１７０）。次に、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、利用者識別情報UIDaxから利用者Ａの参照識別情報RefIDaを取得する（Ｓ１７１）。さらに、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、グループ情報Groupが「Friends」を示し、利用者Ａの参照識別情報RefIDaに対応する種別情報AppIDxと利用者識別情報UIDaxとの組みを特定する（Ｓ１７２）。
より具体的には、（Group= Friends）*｛（RefID_To=RefIDa）+（RefID_From=RefIDa）｝*（Stat=1）を充足するレコードを抽出し、それらに含まれる一又は複数の種別情報AppIDxと利用者識別情報UID*xとの組みを特定する。

次に、ＣＰＵ３０は、抽出した利用者識別情報UID*xの数を種別情報AppIDxごとに集計する（S１７３）。さらに、ＣＰＵ３０は、仲間の利用者識別情報UID*xの集計数に基づいて、種別情報AppIDxで特定されるゲームの人気順を特定する（Ｓ１７４）。次に、ＣＰＵ３０は、アプリ情報テーブルＴＢＬ１５を参照して、抽出した種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報を取得する。この後、ＣＰＵ３０は、ランキングページを生成する（Ｓ１７６）。この際、ＣＰＵ３０は、遊んでいる仲間の多い順にゲームの説明などを配置して第２ランキングページを生成する。端末装置２は、管理サーバ３Ａから第２ランキングページを含むアクセス応答を受信すると、第２ランキングページをディスプレイ２５に表示する。
即ち、ＣＰＵ３０は、Ｓ１７２において複数のゲームのうち、利用者Ａが利用したことがあるゲームの種別情報AppIDxを特定し、さらに、利用者と仲間関係が構築されている利用者を利用者識別情報UID*xで特定し、さらに特定した利用者、即ち、仲間がプレイしている各ゲームのランキングと、各ゲームをプレイしている仲間数とを示す利用情報を取得する情報取得部１５として機能する。

図１９に第２ランキングページの一例を示す。この例では、ランキング表示領域２２０、２３０、２４０が設けられており、ランキングの高い順にゲームをランキング表示領域２２０→ランキング表示領域２３０→ランキング表示領域２４０に表示する。
本実施形態によれば、仲間内で利用されている人数の多い順にアプリケーション（ゲーム）が表示されるので、利用者は、アプリケーション（ゲーム）の人気ランキングを一見して知ることができる。

まず、領域２２１にはアプリ情報テーブルＴＢＬ１５から読み出したアイコン情報に基づいてアイコンが表示され、領域２２２にはアプリケーション名（ゲーム名）が表示される。これらの情報は、上述したＳ１７５の処理で取得される。次に領域２２３には、利用者Ａがプレイしているゲームのいずれかで、利用者Ａと仲間関係にありゲームｂを遊んだことのある他の利用者の人数が表示される。この情報は、上述したＳ１７３の処理で取得される。次に領域２２４には、ゲームｂの説明が表示される。この情報は、上述したＳ１７５の処理で取得される。なお、ここで表示されるゲームは利用者Ａがプレイしていないものも含まれる。

このように本実施形態によれば、ゲームごとに利用者の仲間がプレイしている仲間数を知ることができるので、仲間内で人気のあるゲームを知ることができる。これにより、利用者は新しいゲームを選択する場合の目安を得ることができる。
また、本実施形態によれば、情報取得部１５は、要求利用者である利用者Ａが利用済みのアプリケーションにおいて仲間関係が構築されている仲間について、当該仲間が利用しているアプリケーションに関する利用情報を取得する。そして、表示制御部１４はこれを端末装置２に表示させる。したがって、要求利用者である利用者Ａは、仲間が利用しているアプリケーションの関して様々な情報を得ることが可能となる。

次に、仲間数処理について説明する。図２０に仲間数処理に関するアプリケーションシステムの動作シーケンスを示す。管理サーバ３Ａが提供する利用者ごとのＳＮＳサイトのマイページには、ゲームを特定して仲間数を問い合わせることができる仲間数ボタンが用意されている。

利用者Ａが端末装置２において、あるゲームに係る仲間数ボタンをクリックして仲間数を選択すると（Ｓ１８０）、端末装置２のＣＰＵ２０は仲間数要求を管理サーバ３Ａに送信する。管理サーバ３ＡのＣＰＵ３０は、仲間数要求を受信すると、仲間数ページを生成する仲間数処理を実行する（Ｓ１８１）。

図２１に仲間数処理の内容を示す。まず、ＣＰＵ３０は、受信した仲間数要求に含まれる利用者識別情報UIDaxと着目するゲームの種別情報AppIDxを取得する（Ｓ１９０）。次に、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、利用者識別情報UIDaxから利用者Ａの参照識別情報RefIDaを取得する（Ｓ１９１）。さらに、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、グループ情報Groupが「Friends」を示し、種別情報AppIDが「AppIDx」を示し、且つ、利用者Ａの参照識別情報RefIDaに対応する仲間の利用者の利用者識別情報UID*xを抽出する（Ｓ１９２）。
より具体的には、（Group= Friends）*（AppID= AppIDx）*｛（RefID_To=RefIDa）+（RefID_From=RefIDa）｝を充足するレコードを抽出し、それらに含まれる一又は利用者識別情報UID*xを抽出する。

次に、ＣＰＵ３０は、抽出した利用者識別情報UID*xの数を集計する（S１９３）。さらに、ＣＰＵ３０は、アプリ情報テーブルＴＢＬ１５を参照して、種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報を取得する。この後、ＣＰＵ３０は、仲間数ページを生成する（Ｓ１９５）。

図２２に仲間数ページの一例を示す。この例では、仲間数表示領域３２０に処理結果が表示される。具体的には、領域３２１にはアプリ情報テーブルＴＢＬ１５から読み出したアイコン情報に基づいてアイコンが表示され、領域３２２にはアプリケーション名（ゲーム名）が表示される。これらの情報は、上述したＳ１９４の処理で取得される。次に領域３２３には、利用者Ａと仲間関係にありゲームｂを遊んだことのある他の利用者の人数が表示される。この情報は、上述したＳ１９３の処理で取得される。次に領域３２４には、ゲームｂの説明が表示される。この情報は、上述したＳ１９４の処理で取得される。

このように本実施形態によれば、ゲームを指定して利用者の仲間がプレイしている仲間数を知ることができるので、利用者は気がかりなゲームについて、仲間内で当該ゲームがどの程度人気があるかを知ることができる。
また、本実施形態によれば、アプリケーション（ゲーム）を利用している利用者数が端末装置２に表示されるので、相対的なランキングよりも詳細な情報を利用者は得るこができる。

＜３．変形例＞
本発明は上述した実施形態に限定されるものではなく、以下の変形が可能である。また、各変形例は適宜組み合わせることができる。
（１）上述した実施形態では、アプリケーションの一例としてゲームを取り上げて説明したが本発明はこれに限定されるものではない。招待や人気アプリのランキングについては、どのようなものであってもよい。例えば、占いや診断のアプリケーション、便利ツールのアプリケーション、写真画像処理のアプリケーションであってもよい。仲間申請については、仲間関係を構築して利用するチャットや掲示板のアプリケーションが好適である。

（２）上述した実施形態では、仲間の候補利用者を特定する場合、あるいはランキング処理、もしくは、特定のゲームを特定した仲間数処理において、最後にログインした日時は問題としなかったが、本発明はこれに限定されるものではない。例えば、アクセステーブルの一例として利用者情報テーブルＴＢＬ１１を用い、利用者情報テーブルＴＢＬ１１に利用者識別情報UIDと関連付けて記憶されているラストログイン情報LastLoginを用いて、仲間申請の対象となるアプリケーションを利用している候補利用者を特定する場合、あるいはアプリケーションごとに利用している仲間数を特定する場合に、もしくは、特定のゲームにおける仲間数を特定する場合に、所定期間内にアプリケーションを利用していることを条件に加えてもよい。

例えば、図１０に示す仲間処理の代わりとして、図２４に示す仲間処理を行うようにしてもよい。図２４は、図１０に対応する仲間処理のフローチャートであり、ステップＳ１０９の処理の後に、ステップＳ２５０とステップＳ２５１の処理が追加されている。管理サーバ３ＡのＣＰＵ３０は、図１０に示す仲間処理と同様に、ステップＳ１００からステップＳ１０９までの処理を行う。その後、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、ステップＳ１０９で抽出した仲間の利用者識別情報UID*x及び着目する種別情報AppIDxの組と一致する組の最終ログイン日を取得する（Ｓ２５０）。最終ログイン日は、利用者情報テーブルＴＢＬ１１のラストログイン情報LastLoginのフィールドに記憶されている。そして、ＣＰＵ３０は、取得した最終ログイン日と、処理が行われている現在の日付とから、最終ログイン日が所定期間内である仲間の利用者識別情報UID*x及び着目する種別情報AppIDxの組を抽出し、さらに、抽出した組における仲間の利用者識別情報UID*xを抽出する（Ｓ２５１）。このような処理により、所定期間内にアプリケーションを利用している仲間の候補利用者のみを特定することが可能になる。

また、図１８に示すランキング処理の代わりとして、図２５に示すランキング処理を行うようにしてもよい。図２５は、図１８に示す第２ランキング処理に対応するランキング処理のフローチャートであり、ステップＳ１７２とステップＳ１７３の処理の間に、ステップＳ２５２とステップＳ２５３の処理が追加されている。管理サーバ３ＡのＣＰＵ３０は、図１８に示すランキング処理と同様に、受信したアクセス要求に含まれる利用者識別情報UIDaxを取得する（Ｓ１７０）。次に、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、利用者識別情報UIDaxから利用者Ａの参照識別情報RefIDaを取得する（Ｓ１７１）。さらに、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、グループ情報Groupが「Friends」を示し、利用者Ａの参照識別情報RefIDaに対応する種別情報AppIDxと仲間の利用者識別情報UID*xとの組みを特定する（Ｓ１７２）。その後、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１のラストログイン情報LastLoginを参照して、ステップＳ１７２で特定した仲間の利用者識別情報UID*x及び種別情報AppIDxの組と一致する組の最終ログイン日を取得する（Ｓ２５２）。最終ログイン日は、利用者情報テーブルＴＢＬ１１のラストログイン情報LastLoginのフィールドに記憶されている。そして、ＣＰＵ３０は、取得した最終ログイン日と、処理が行われている現在の日付とから、最終ログイン日が所定期間内である仲間の利用者識別情報UID*x及び種別情報AppIDxの組を抽出し、さらに、抽出した組における仲間の利用者識別情報UID*xを抽出する（Ｓ２５３）。
次に、ＣＰＵ３０は、抽出した利用者識別情報UID*xの数を種別情報AppIDxごとに集計する（S１７３）。さらに、ＣＰＵ３０は、仲間の利用者識別情報UID*xの集計数に基づいて、種別情報AppIDxで特定されるゲームの人気順を特定する（Ｓ１７４）。次に、ＣＰＵ３０は、アプリ情報テーブルＴＢＬ１５を参照して、抽出した種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報を取得する。この後、ＣＰＵ３０は、ランキングページを生成する（Ｓ１７６）。この際、ＣＰＵ３０は、遊んでいる仲間の多い順にゲームの説明などを配置して第２ランキングページを生成する。端末装置２は、管理サーバ３Ａから第２ランキングページを含むアクセス応答を受信すると、第２ランキングページをディスプレイ２５に表示する。このような処理により、所定期間内にアプリケーションを利用している仲間の候補利用者のみについて、アプリケーションごとにランキングを表示することが可能になる。

さらに、図２１に示す仲間数処理の代わりとして、図２６に示す仲間数処理を行うようにしてもよい。図２６は、図２１に対応する仲間数処理のフローチャートであり、ステップＳ１９２とステップＳ１９３の処理の間に、ステップＳ２５４とステップＳ２５５の処理が追加されている。管理サーバ３ＡのＣＰＵ３０は、図２１に示す仲間数処理と同様に、ステップＳ１９０からステップＳ１９２までの処理を行う。その後、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、ステップＳ１９２で抽出した仲間の利用者識別情報UID*x及び着目する種別情報AppIDxの組と一致する組の最終ログイン日を取得する（Ｓ２５４）。最終ログイン日は、利用者情報テーブルＴＢＬ１１のラストログイン情報LastLoginのフィールドに記憶されている。そして、ＣＰＵ３０は、取得した最終ログイン日と、処理が行われている現在の日付とから、最終ログイン日が所定期間内である仲間の利用者識別情報UID*x及び着目する種別情報AppIDxの組を抽出し、さらに、抽出した組における仲間の利用者識別情報UID*xを抽出する（Ｓ２５５）。これ以降の処理は図２１に示す仲間数処理と同様である。このような処理により、所定期間内にアプリケーションを利用している仲間の候補利用者のみについて、仲間数を表示することが可能になる。

ゲームでは試しにプレイして、気に入らないのでその後、全くプレイしないゲームもあるが、所定期間内にアプリケーションを利用していることを条件とすることで、そのゲームをプレイしている利用者に対して仲間申請を行うことができるようになる。なお、仲間申請する際に、利用者が所定期間として、「１カ月」「１週間」のように選択可能としてもよい。また、所定期間は、アプリケーションの種別に応じて異なる期間が設定されるようにしてもよい。また、本発明は、利用者識別情報UIDとラストログイン情報LastLoginとを対応づけて記憶するのであれば、どのようなテーブルを用いてもよく、これを利用者情報テーブルＴＢＬ１１とは別に設けてもよい。
本変形例によれば、アプリケーションの利用から所定期間内の候補利用者に限定しているので、アプリケーションを試しに利用し、その後、利用しなくなった利用者については候補利用者から除くので、着目するアプリケーションについて実際に使用している利用者を候補利用者とすることができるといった利点がある。

また、本変形例のによれば、日時情報を参照することによって、所定期間において仲間内で利用されている人数の多い順にアプリケーションが表示されるので、ある期間において仲間内で利用しているアプリケーションの人気ランキングを一見して知ることができる。アプリケーションを試しに利用し、その後、利用しなくなることも考えられ、このような試用をランキングの対象から除外したい場合もある。本変形例によれば、所定期間に利用されているアプリケーションをランキングの対象とするので、試用を除外したランキングを行うことが可能となる。
また、本変形例によれば、日時情報を参照することによって、所定期間において仲間内であるアプリケーションを利用している人数を特定するので、ある期間においてあるアプリケーションを仲間内で利用している人数を一見して知ることができる。
なお、本変形例では、第２ランキング処理において、各ゲームにおける仲間数を特定する場合に、所定期間内にゲームを利用していることを条件に加えた場合について説明したが、本変形例は、第１ランキング処理にも適用可能である。第１ランキング処理に本変形例を適用する場合には、図２３に示すＳ２０１とＳ２０２の間に、図２４に示すＳ３００に相当する処理を行えばよい。

（３）上述した実施形態において、招待は、複数の利用者に対して行うことができたが、これに制限を設けてもよい。具体的には、所定期間（例えば、１日、１週間）に招待できる利用者の数に制限を設けてもよい。あるいは、多数の招待メールが来ることを防止するために、招待メールの数に上限を設けてもよい。この場合には、インバイトテーブルＴＢＬ１４において申請先の利用者の状態情報Statが「0」（申請中）を示すレコードが１０件未満の利用者にしか「招待する」ができないようにしてもよい。また、申請を受ける側で受信を制限するようにしてもよい。例えば、状態情報Statが「0」（申請中）を示すレコードが１０件を超える場合には、招待メールを申請先に送信せずに招待を拒否にしてもよい。
さらに、申請元において状態情報Statが「0」（申請中）を示すレコードが１０件をこえないように制限をしてもよい。くわえて、招待した相手がそのゲームを開始した場合に、例えば、招待者にインセンティブ（ポイント等）を付与してもよい。

（４）上述した実施形態では、「仲間申請」や「招待する」や「ランキング」の処理は、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…におけるゲームのマイページから遷移する例を説明したが、本発明はこれに限定されるものではなく、管理サーバ３ＡのＳＮＳサイトのマイページから遷移できるようにしてもよい。
ゲームのマイページから「仲間申請」や「招待する」や「ランキング」の処理へ遷移する場合には、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…から「ゲームｂ」と「Ｘさん」からの要求であることの情報が通知される。管理サーバ３ＡのＳＮＳサイトのマイページから遷移する場合には、同様の情報を与えればよい。ＳＮＳサイトでは「Ｘさん」のマイページにログインしていることから、仲間申請要求や招待要求が「Ｘさん」であることは把握できる。このため、どのゲームを誘うのかを選択する手段を設ける。つまり、どのゲームへの「仲間申請」なのか「招待」なのか、またはどのゲームでの仲間に人気のあるアプリケーションの「ランキング」なのかを選択できるようにする。また、ゲームを指定しない「ランキング」も選択できるようにする。これらの選択は、ＳＮＳサイトのマイページに選択のためにボタンを設ければよい。なお、ゲームを指定した「ランキング」は、上述した実施形態の第１ランキング処理であり、ゲームを指定しない「ランキング」は、上述した実施形態の第２ランキング処理である。

（５）上述した実施形態では、各ゲームにおける利用者毎の仲間上限数を管理サーバ３Ａで一元的に管理したが、本発明はこれに限定されるものではなく、各アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…で管理するようにし、管理サーバ３Ａから必要に応じて各アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…に問い合わせるようにしてもよい。この場合、管理サーバ３ＡのＣＰＵ３０は、受付部１１で受付けた種別情報に対応するアプリケーションサーバ３Ｂ、３Ｃ、…において設定された利用者の仲間上限数を取得する取得部９として機能する（図２７参照）。あるいは、管理サーバ３ＡのＣＰＵ３０は、受付部１１で受付けた種別情報AppIDに対応するアプリケーションサーバ３Ｂ、３Ｃ、…に対して利用者の仲間上限数を問い合わせる要求を送信し、要求に対する応答として当該アプリケーションサーバ３Ｂ、３Ｃ、…から仲間上限数を取得する取得部９として機能してもよい（図２７参照）。

図２８は、図８の共通処理に関するアプリケーションシステムの動作シーケンスに対応する本変形例の動作シーケンスを示す。図２８示す動作シーケンスでは、管理サーバ３ＡのＣＰＵ３０が仲間処理を実行する際（Ｓ７）、必要に応じてアプリケーションサーバ３Ｂ、３Ｃ、…に対して利用者の仲間上限数を問い合わせる要求を送信し、要求に対する応答として当該アプリケーションサーバ３Ｂ、３Ｃ、…から仲間上限数を取得する。具体的には、図２９及び図３０に示すように仲間上限数の取得処理が行われる。図２９は図１０に対応する本変形例の仲間処理のフローチャートであり、図３０は図１１に対応する本変形例の仲間処理のフローチャートである。図２９に示すように、本変形例では、図１０に示すステップＳ１０２の代わりに、ステップＳ３００の処理が行われる。つまり、ＣＰＵ３０は、アプリケーションサーバ３Ｂ、３Ｃ、…に対して、着目する利用者Ａの利用者識別情報UIDaxに対応する仲間上限数を要求し、アプリケーションサーバ３Ｂ、３Ｃ、…から利用者Ａの利用者識別情報UIDaxに対応する仲間上限数を取得する（Ｓ３００）。また、図３０に示すように、本変形例では、図１１に示すステップＳ１１６の代わりに、ステップＳ３０１の処理が行われる。つまり、ＣＰＵ３０は、抽出された種別情報AppIDxに対応するアプリケーションを提供するアプリケーションサーバ３Ｂ、３Ｃ、…のうちのいずれかのアプリケーションサーバに対して、着目する非仲間の利用者識別情報UID*xの仲間上限数を要求し、当該アプリケーションサーバから当該仲間上限数を取得する（Ｓ３０１）。

また、仲間上限数以外のデータでも各アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…で管理することが可能なものは、同様に、各アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…で管理するようにし、管理サーバ３Ａから必要に応じて各アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…に問い合わせるようにしてもよい。
また、仲間上限数が各アプリケーションで固定化されていてもよい。その場合、例えば、アプリ情報テーブルＴＢＬ１５で種別情報AppIDに関連付けて固定化された仲間上限数が記録されていてもよい。さらに、アプリケーションによって仲間上限数が固定化されているものと変動するものを含む場合、アプリ情報テーブルＴＢＬ１５に種別情報AppIDに関連付けて仲間上限数が記憶されていれば固定化されているものとし、記憶されていなければ（null）仲間上限数テーブルＴＢＬ１２を参照するようにしてもよい。
本変形例によれば、アプリケーションサーバから仲間上限数を取得する取得部を備えるので、仲間上限数を取得することが可能となる。

（６）上述した実施形態では、管理サーバ３ＡのＳＮＳサイトのマイページからランキングの選択や仲間数の選択が実行できるようにしたが、本発明はこれに限定されるものではなく、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…が提供する画面（ページ）で利用者の操作に基づく要求（ランキング要求、仲間数要求）を受け付けて、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…が管理サーバ３Ａに要求するものであってもよい。なお、仲間数要求の場合には、利用者がどのゲームについて仲間数の提供を希望するかを選択できるようになっている。

（７）上述した実施形態では、仲間上限数が変化すると、各アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…から管理サーバ３Ａに通知が送信されたが、本発明はこれに限定されるものでない。例えば、アプリケーション（ゲーム）において、仲間上限数の変化に影響を与える事象(ゲームであればレベルがアップしたとき等)が発生した場合に、仲間上限数の変化の有無に関わらず仲間上限数を通知するようにしてもよい。さらに、端末装置２から管理サーバ３Ａに通知してしてもよい。この場合、端末装置２のＣＰＵ２０は、図３１に示すように、端末装置２の利用者の仲間上限数が変化したことを検出する検出部２７と、検出部２７によって仲間上限数が変化したことが検出されると、変化した後の仲間上限数を管理サーバ３Ａに通知する通知部２８として機能する。

また、種類の異なる複数のアプリケーション（ゲーム）のそれぞれにおける仲間関係が構築された利用者識別情報ＵＩＤをアプリケーション（ゲーム）の種類を示す種別情報に関連付けて一元的に管理する管理サーバと通信可能なアプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…に、図３２に示すように管理部５１と通知部５２とを備えるようにしてもよい。管理部５１は、利用者（プレイヤ）の所定の利用実績の度合い(レベルやゲーム進行度を示すステージ数)に関連付けて仲間関係を構築できる仲間上限数Limitを管理する。通知部５２は、アプリケーション（ゲーム）の利用中（ゲーム進行中）に前記利用実績を示す度合いが更新されて仲間上限数が変更された場合に、前記管理部５１で管理する前記利用実績の度合いに応じた仲間上限数Limitを、種別情報及び利用者識別情報ＵＩＤと関連付けて前記端末装置２に通知する。また、通知部５２は、アプリケーションの利用中に前記利用実績を示す度合いが更新された場合に通知するようにしてもよい。

本変形例においては、図３３に示すように、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…の管理部５１が利用者の前記所定の利用実績の度合いに関連付けて仲間関係を構築できる仲間上限数Limitを管理する（Ｓ４００）。そして、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…の通知部５２は、アプリケーションの利用中に前記利用実績を示す度合いが更新されて仲間上限数が変更された場合に、前記管理部５１で管理する前記利用実績の度合いに応じた仲間上限数Limitを、種別情報及び利用者識別情報ＵＩＤと関連付けて前記端末装置２に通知する。
アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…から種別情報及び利用者識別情報ＵＩＤと関連付けられた仲間上限数Limitの通知を受けた端末装置２は、検出部２７によって端末装置２の利用者の仲間上限数が変化したことを検出する（Ｓ４０１）。そして、端末装置２の通知部２８は、変化した後の仲間上限数を管理サーバ３Ａに通知する。
端末装置２から変化した後の仲間上限数の通知を受けた管理サーバ３ＡのＣＰＵ３０は、仲間上限数テーブルＴＢＬ１２に変化した後の仲間上限数を記憶させる（Ｓ４０２）。
なお、本変形例においては、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ、…の通知部５２は、前記管理部５１で管理する前記利用実績の度合いに応じた仲間上限数Limitを、種別情報及び利用者識別情報ＵＩＤと関連付けて前記管理サーバ３Ａに通知するようにしてもよい。

さらに管理サーバは、前記複数のアプリケーション（ゲーム）のうち他のアプリケーション（ゲーム）で仲間関係が構築されている利用者を対象に仲間の候補となる利用者を提示することを前記管理サーバに対して要求する要求部と、前記要求部の要求に応じて行われる前記管理サーバの処理の結果として、要求利用者が選択した利用者に対にする仲間申請の要求を、前記管理サーバから仲間申請の対象となるプレイヤ情報と関連付けて受付る受付部とから構成されてもよい。さらに、前記通知部は、前記仲間申請を受付けた利用者の承諾または拒否に応じた通知を前記管理サーバに通知するようにしてもよい。

（８）上述した実施形態では、ＣＰＵ３０は、インバイトテーブルＴＢＬ１４を参照して、利用者Ａが招待元となっている招待先の利用者を特定し、特定された利用者を候補利用者から除いた（Ｓ１１２）。インバイトテーブルＴＢＬ１４には、招待中（Stat=0）、拒否又は承諾（Stat=1）が記録されているので、これらに該当する利用者が除かれる。即ち、状態情報Statが拒否又は承諾を示す第１状態（Stat=1）及び状態情報Statが招待中を示す第２状態（Stat=0）の利用者は招待の候補利用者から除かれる。
本発明はこれに限定されるものではなく、以下の態様をとり得る。第１に、ＣＰＵ３０は、状態情報Statが第１状態である場合に、招待の候補利用者から除いてもよい。即ち、
状態情報Statが招待中を示す第２状態において、再度、招待を認めてもよい。
また、状態情報Statにおいて、Stat=1を拒否、Stat=2を承認といったように、拒否と承認を区別して管理してもよい。この場合、ＣＰＵ３０は、状態情報Statが「0」拒否を示す場合に招待の候補利用者から除いてもよい。
これらを、総合すると、ＣＰＵ３０は、状態情報Statによって示される招待の状態が少なくとも拒否である場合に、利用者を候補利用者から除外する。

また、管理サーバ３Ａは、図３４に示すように、インバイトテーブルＴＢＬ１４の替わりに、招待した利用者と招待を拒否した利用者とを管理する管理部５１を備え、特定部１２は、管理部５１を用いて、要求利用者が招待した利用者のうち、招待を拒否した利用者を特定し、特定した利用者を前記候補利用者から除くようにしてもよい。
具体的には、図３５に示す処理が行われる。図３５は、図１１に対応するフローチャートである。本変形例では、例えば、特定部１２は、Ｓ１１１の処理が行われた後に、管理部５１に対して、招待を拒否した利用者のリストを要求する。そして、特定部１２は、当該リスト中の利用者とＳ１１１で抽出した利用者との間で一致する利用者が存在した場合には、当該利用者を、招待を拒否した利用者として特定する（Ｓ５００）。
次に、ＣＰＵ３０は、インバイトテーブルＴＢＬ１４を参照して、利用者Ａを示す参照識別情報RefIDaが招待元、且つ候補利用者の利用者識別情報UID*xに対応する参照識別情報RefID*が招待先としてインバイトテーブルＴＢＬ１４に記録されている場合には、当該利用者識別情報UID*xを、候補利用者の利用者識別情報UID*xから除外し、残りの候補利用者の利用者識別情報UID*xを抽出する。そして、ＣＰＵ３０は、抽出した候補利用者の利用者識別情報UID*xの中から、Ｓ５００で特定した利用者の利用者識別情報UID*xを除外し、残りの利用者識別情報UID*xを集計する（Ｓ５０１）。
この変形例によれば、招待した利用者と招待を拒否した利用者とを対応づけて管理するので、一度、拒否された利用者を再度、招待することを未然に防止することができる。

（９）上述した実施形態では、ＣＰＵ３０は、インバイトテーブルＴＢＬ１４に記録された招待の年月日を示す日時情報Dateに基づいて、招待してから所定期間を超えて、招待申請中が継続した場合には、強制的に状態情報Statを拒否又は承認（第１状態）を示す「1」に書き換えた。
しかし、本発明はこれに限定されるものではなく、ＣＰＵ３０は、日時情報Dateに基づいて状態情報Statを書き換えるのではなく、状態情報Statが招待中を示している場合に、
招待の年月日を示す日時情報Dateから所定期間が経過した場合に、拒否されたとみなして取り扱ってもよい。例えば、本変形例では、図３６に示す処理が行われる。図３６は、図１１に対応するフローチャートである。図３６に示すように、ＣＰＵ３０は、招待を拒否した利用者と、招待中（第２状態）であって、招待日から所定期間が経過した利用者とを特定する（Ｓ５１０）。所定期間の経過は、招待の年月日を示す日時情報Dateに基づいて判断すればよい。

次に、ＣＰＵ３０は、インバイトテーブルＴＢＬ１４を参照して、利用者Ａを示す参照識別情報RefIDaが招待元、且つ候補利用者の利用者識別情報UID*xに対応する参照識別情報RefID*が招待先としてインバイトテーブルＴＢＬ１４に記録されている場合には、当該利用者識別情報UID*xを、候補利用者の利用者識別情報UID*xから除外し、残りの候補利用者の利用者識別情報UID*xを抽出する。そして、ＣＰＵ３０は、抽出した利用者識別情報UID*xの中から、Ｓ５１０で特定した利用者の利用者識別情報UID*xを含むレコードを除外し、残りの利用者識別情報UID*xを集計する（Ｓ５１１）。
この変形例によれば、招待を申請中の利用者に対して、再度の招待申請を許容する。これにより、招待を承認するか否かをまよっている利用者に対して、再び招待することによって、ゲームへの参加を促すことができる。しかしながら、何度も招待するのは迷惑である。そこで、本変形例は、状態情報が申請中を示していても、招待の日時から所定期間が経過すると、状態情報が申請中を示していても、候補利用者から除外している。これにより、ゲームへの参加を促しつつ、迷惑行為を防止することが可能となる。また、拒否と承認を一つの状態として管理できるので、データ構造を簡素化できる。

また、ＣＰＵ３０は、招待の年月日を示す日時情報Dateに基づいて、招待してから所定期間を超えて、招待申請中（第２状態）が継続した場合には、強制的にインバイトテーブルＴＢＬ１４の状態情報Statを拒否「1」（第１状態）に書き換えるようにしてもよい。この場合には、ＣＰＵ３０は、図３７に示すように書換部５３として機能する。具体的には、例えば図３８に示す処理が行われる。図３８は、図１５に示すように管理サーバ３Ａから端末装置２に招待メールを送信した後に、定期的に実行される処理のフローチャートである。図３７に示すように、ＣＰＵ３０は、端末装置２に招待メールを送信した後、インバイトテーブルＴＢＬ１４の日時情報Dateを読み取る（Ｓ５２０）。そして、ＣＰＵ３０は、日時情報Dateに基づいて、招待してから所定期間が経過したか否かを判断する（Ｓ５２１）。ＣＰＵ３０は、所定期間が経過していないと判断した場合には（Ｓ５２１：ＮＯ）、処理を終了する。しかし、ＣＰＵ３０は、所定期間が経過したと判断した場合には（Ｓ５２１：ＹＥＳ）、インバイトテーブルＴＢＬ１４の状態情報Statを拒否「1」に書き換える（Ｓ５２２）。
なお、インバイトテーブルＴＢＬ１４に、レコードの有効/無効を示す項目を新たに追加し、所定期間が過ぎた場合にレコードを無効とするようにしてもよい。
この変形例によれば、招待申請を通知した日時から所定期間が経過しても招待された利用者から応答がない場合、前記状態情報の状態を招待の申請中から招待の拒否へ書き換えるので、候補利用者に該当するか否かの判定を簡素化することができる。
また、招待を拒否された場合だけでなく、招待が承認された場合にも候補利用者から除外される。招待を承認した利用者は、そもそも招待の対象となるゲームを既に利用しているから、招待する必要がない。このようなデータ構造を採用することにより、拒否した利用者と招待された利用者を同時に排除できるので処理負荷が軽減される。

（１０）上述した問合処理において、ＣＰＵ３０は、図１０及び図１１を参照して説明した処理を実行して仲間申請可能な人数や招待可能な人数を端末装置２に表示させてもよい。
さらに、ＣＰＵ３０は、仲間申請可能な利用者の数と招待可能な利用者の数と並べて表示させるページを生成し、さらに仲間申請が可能な候補利用者と招待可能な利用者とを選択的に端末装置２に表示させてもよい。
具体的には、図３９及び図４０に示す処理が行われる。図３９は、図１８の第２ランキング処理に対応する本変形例におけるランキング処理のフローチャートである。図４０は、図１０及び図１１に示す仲間申請可能な人数及び招待可能な人数の算出処理に対応する本変形例の処理のフローチャートである。
まず、ＣＰＵ３０は、図３９に示すように、受信したアクセス要求に含まれる利用者識別情報UIDaxを取得する（Ｓ１７０）。次に、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、利用者識別情報UIDaxから利用者Ａの参照識別情報RefIDaを取得する（Ｓ１７１）。さらに、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、グループ情報Groupが「Friends」を示し、利用者Ａの参照識別情報RefIDaに対応する種別情報AppIDxと利用者識別情報UID*xとの組みを特定する（Ｓ１７２）。
より具体的には、ＣＰＵ３０は、（Group= Friends）*｛（RefID_To=RefIDa）+（RefID_From=RefIDa）｝*（Stat=1）を充足するレコードを抽出し、それらに含まれる一又は複数の種別情報AppIDxと利用者識別情報UID*xとの組みを特定する。

次に、ＣＰＵ３０は、特定した組に含まれる全ての利用者識別情報UID*xの中から、重複する利用者識別情報UID*xを除外して、ユニークな利用者識別情報UID*xを全て抽出する（Ｓ６００）。この処理により、利用者Ａの全ての仲間の利用者識別情報UID*xが抽出される。抽出した全ての仲間の利用者識別情報UID*xは後述する招待可能な利用者の人数算出処理の際に用いられる。
利用者Ａの全ての仲間の利用者識別情報UID*xを抽出した後、ＣＰＵ３０は、Ｓ１７２で抽出した組みにおいて、利用者識別情報UID*xの数を種別情報AppIDxごとに集計する（S１７３）。さらに、ＣＰＵ３０は、仲間の利用者識別情報UID*xの集計数に基づいて、種別情報AppIDxで特定されるゲームの人気順を特定する（Ｓ１７４）。
次に、ＣＰＵ３０は、抽出した全ての種別情報AppIDxと利用者識別情報UID*xとの組みに対してＳ７００〜Ｓ７１３の処理が終了したか否かを判定する（Ｓ６０１）。全ての組みに対してＳ７００〜Ｓ７１３の処理が終了していない場合には（Ｓ６０１：ＮＯ）、ＣＰＵ３０は、一つの種別情報AppIDxに着目し、当該種別情報AppIDxに対応するゲームに招待可能な利用者の人数の算出処理と、当該種別情報AppIDxに対応するゲームにおいて仲間申請可能な人数の算出処理とを行う。

まず、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、着目するAppIDxにおける利用者Ａの参照識別情報RefIDaに対応する利用者識別情報UIDaxを取得する（Ｓ７００）。例えば、着目する種別情報AppIDxが「00000001」であり、利用者Ａの参照識別情報RefIDaが「00000011」だとすると、利用者識別情報UIDaxは「XCV56714」となる。
次に、ＣＰＵ３０は、利用者Ａ自身が仲間上限数に達しているか否かの判断を行う処理（Ｓ７０１〜Ｓ７０３）を行う。まず、ＣＰＵ３０は、仲間上限数テーブルＴＢＬ１２を参照して、利用者Ａの利用者識別情報UIDaxに対応する仲間上限数を取得する（Ｓ７０２）。
そして、ＣＰＵ３０は、取得した仲間上限数が、図３９のＳ１７３で集計した種別情報AppIDxごとの仲間の利用者識別情報UID*xの数のうち、着目する種別情報AppIDxについての仲間の利用者識別情報UID*xの数を超えるか否かを判定する(Ｓ７０２)。この判定条件が否定される場合は（Ｓ７０２：ＮＯ）、着目する種別情報AppIDxに対応するゲームについて、既に利用者Ａにおける仲間の利用者識別情報UID*xの総数が、仲間上限数に達しているので、仲間申請が不能となる。したがって、ＣＰＵ３０は、仲間申請が不能である旨のフラグをセットする（Ｓ７０３）。しかし、前記判定条件が否定される場合は（Ｓ７０２：ＹＥＳ）、着目する種別情報AppIDxに対応するゲームについて、利用者Ａにおける仲間の利用者識別情報UID*xの総数は、未だ仲間上限数に達していないので、フラグをセットすることなく次の処理に移行する。

次に、着目する種別情報AppIDxに対応するゲームに招待することが可能な利用者を特定する処理（Ｓ７０４〜Ｓ７０５）を行う。まず、ＣＰＵ３０は、招待の対象となるゲームをプレイしていない利用者を候補利用者としたとき、図３９のＳ６００で抽出した全ての仲間の利用者識別情報UID*xの中から、着目する種別情報AppIDxに対応するゲームをプレイしていない候補利用者の利用者識別情報UID*xを抽出する（Ｓ７０４）。具体的には、ＣＰＵ３０は、全ての仲間の利用者識別情報UID*xのうち、一つの利用者識別情報UID*xに着目し、利用者情報テーブルＴＢＬ１１を参照して、着目する一つの利用者識別情報UID*xに対応する仲間の参照識別情報RefID*を取得する。さらに、ＣＰＵ３０は、取得した参照識別情報RefID*に対応する一又は複数の種別情報AppIDxを取得する。そして、ＣＰＵ３０は、取得した一又は複数の種別情報AppIDxに、着目する種別情報AppIDxが含まれているかどうかを判断する。含まれていない場合には、当該参照識別情報RefID*に対応する仲間は、着目する種別情報AppIDxに対応するゲームをプレイしていない場合なので、当該参照識別情報RefID*に対応する利用者識別情報UID*xを候補利用者の利用者識別情報UID*xとして抽出する。以上の処理を、図３９のＳ６００で抽出した全ての仲間の利用者識別情報UID*xについて行う。

次に、ＣＰＵ３０は、インバイトテーブルＴＢＬ１４を参照して、着目する種別情報AppIDxを含むレコードのうち、利用者Ａを示す参照識別情報RefIDaが招待元として記録され、且つ候補利用者の利用者識別情報UID*xに対応する参照識別情報RefID*が招待先として記録されているレコードを抽出する。そして、ＣＰＵ３０は、抽出したレコードに含まれる候補利用者の参照識別情報RefID*に対応する利用者識別情報UID*xを、Ｓ７０４で抽出した候補利用者の利用者識別情報UID*xから除外して、インバイトテーブルＴＢＬ１４に記録されていない候補利用者の利用者識別情報UID*xを抽出し、集計する（Ｓ７０５）。
即ち、インバイトテーブルＴＢＬ１４には招待中または招待済みの招待元の利用者と招待先の利用者とが組がレコードとして記録されており、このようなレコードに記録されている利用者というのは、過去に一度でも招待したことのある利用者ということになる。そこで、このように過去に一度でも招待したことのある利用者については、再度招待しないようにしている。これにより、利用者Ａが招待可能な他の利用者とその人数とを特定することができる。集計された招待可能な仲間の数は、本変形例の第２ランキングページにおいてゲームごとに表示される（後述する図４１の領域２２５を参照）。

次に、ＣＰＵ３０は、着目する種別情報AppIDxに対応するアプリケーションで仲間申請が可能な利用者を特定する処理（Ｓ７０６〜Ｓ７１１）を行う。なお、Ｓ７０３の処理で仲間申請が不能である旨のフラグがセットされている場合、ＣＰＵ３０は、当該処理を行わずに、フラグをリセットして、Ｓ７１２へ進む。
まず、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、着目する種別情報AppIDxについて、まだ仲間になっていない非仲間の利用者の利用者識別情報UID*xを抽出する（Ｓ７０６）。ＣＰＵ３０は、着目する種別情報AppIDxに対応するゲーム以外で仲間申請を行う利用者Ａと仲間関係がある他の利用者であって、当該ゲームを既に利用している利用者を抽出し（第１条件）、さらに、関係テーブルＴＢＬ１３を参照して、当該ゲームにおいて利用者Ａと仲間関係が構築されていない利用者（第２条件）を抽出する。

次に、ＣＰＵ３０は、Ｓ７０６で抽出した全ての非仲間の利用者識別情報UID*xについて、Ｓ７０８〜Ｓ７１０の処理が完了したか否かを判定する（Ｓ７０７）。判定条件が充足される場合（Ｓ７０７：ＹＥＳ）、ＣＰＵ３０は処理をＳ７１１に進める。一方、判定条件が充足されなかった場合（Ｓ７０７：ＮＯ）、ＣＰＵ３０は処理をＳ７０８に進め、関係テーブルＴＢＬ１３を参照して着目する非仲間の利用者識別情報UID*xの仲間数を集計する。この場合、ＣＰＵ３０は、関係テーブルＴＢＬ１３を参照して、非仲間の利用者識別情報UID*xと申請元利用者識別情報UID_Fromとが一致するレコードから申請先参照識別情報RefID_Toを抽出するとともに、非仲間の利用者識別情報UID*xと申請先利用者識別情報UID_Toとが一致するレコードから申請元参照識別情報RefID_Fromを抽出する。そして、抽出した申請先参照識別情報RefID_Toと抽出した申請元参照識別情報RefID_Fromに対応する利用者識別情報UID*xの数が、非仲間の利用者識別情報UID*xの数となり、ＣＰＵ３０はこれを集計する。

次に、ＣＰＵ３０は、仲間上限数テーブルＴＢＬ１２を参照して着目する非仲間の利用者識別情報UID*xの仲間上限数を取得する（Ｓ７０９）。この後、ＣＰＵ３０は、取得した仲間上限数と集計した仲間数とを比較し、集計数が仲間上限数に達していない場合に、非仲間の利用者を仲間申請可能であると判断し（第３条件を充足）、集計数が仲間上限数に達している場合に非仲間の利用者を仲間申請不可能であると判断する（Ｓ７１０）。次に、ＣＰＵ３０は処理をＳ７０７に戻し、Ｓ７０７の判定条件が充足されるまでＳ７０７からＳ７１０を繰り返し、Ｓ７０７の判定条件が充足されと、処理をＳ７１１に進める。
Ｓ７１１において、ＣＰＵ３０は、仲間申請可能な非仲間の利用者識別情報UID*xを特定し、非仲間の人数を集計する。非仲間の集計数は、当該ゲーム以外の他のゲームにおいて仲間関係にあり当該ゲームにおいて仲間関係にない利用者の人数である。非仲間の集計数は、本変形例の第２ランキングページにおいてゲームごとに表示される（後述する図４１の領域２２６を参照）。

次に、ＣＰＵ３０は、着目する種別情報AppIDxに対応するゲームについて、Ｓ７０５の処理で集計した招待可能な人数、およびＳ７１１の処理で集計した仲間申請可能な人数を一時的に変数領域やワークエリアに記憶させる（Ｓ７１２）。
この後、ＣＰＵ３０は、処理を図３９に示すＳ６０１に戻す。そして、Ｓ１７２で抽出した全ての種別情報AppIDxについてＳ７００からＳ７１３の処理を終了すると（Ｓ６０１：ＹＥＳ）、アプリ情報テーブルＴＢＬ１５を参照して、抽出した種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報を取得する。この後、ＣＰＵ３０は、Ｓ１７３で集計した各種別情報AppIDxに対応するゲームをプレイしている仲間数、Ｓ５１２で記憶させた各種別情報AppIDxに対応するゲームについて招待可能な人数及び仲間申請可能な人数、並びに、Ｓ１７５で取得した各種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報に基づいて、ランキングページを生成する（Ｓ１７６）。この際、ＣＰＵ３０は、遊んでいる仲間の多い順にゲームの説明などを配置して第２ランキングページを生成する。端末装置２は、管理サーバ３Ａから第２ランキングページを含むアクセス応答を受信すると、第２ランキングページをディスプレイ２５に表示する。
なお、Ｓ７０３の処理で仲間申請が不能である旨のフラグがセットされている場合には、仲間申請可能な人数の替わりに、その表示を非表示にしたり、「申請可能人数に達しているため申請できません」といった表示をする。

図４１に本変形例における第２ランキングページの一例を示す。この例では、ランキング表示領域２２０、２３０、２４０が設けられており、ランキングの高い順にゲームをランキング表示領域２２０→ランキング表示領域２３０→ランキング表示領域２４０に表示する。
領域２２１にはアプリ情報テーブルＴＢＬ１５から読み出したアイコン情報に基づいてアイコンが表示され、領域２２２にはアプリケーション名（ゲーム名）が表示される。これらの情報は、上述したＳ１７５の処理で取得される。次に領域２２３には、利用者Ａがプレイしているゲームのいずれかで、利用者Ａと仲間関係にありゲームｂを遊んだことのある他の利用者の人数が表示される。この情報は、上述したＳ１７３の処理で取得される。領域２２４には、ゲームｂの説明が表示される。この情報は、上述したＳ１７５の処理で取得される。なお、ここで表示されるゲームは利用者Ａがプレイしていないものも含まれる。
また、領域２２５には、利用者Ａがゲームｂについて他のゲームで仲間の利用者を、あと何人、招待可能かが表示される。招待可能な人数は、Ｓ７０５の処理で集計される。そして、領域２２６には、利用者Ａがゲームｂにおいて、新たに仲間申請可能な利用者の数が表示される。仲間申請可能な人数は、Ｓ７１１の処理で集計される。

以上のように、本変形例によれば、具体的にどのアプリケーションのどの仲間を誘いたいかがあらかじめ決まっているような場合に、その相手が要求されたアプリケーションを未だ利用していないことが判明すれば、招待可能な利用者の表示に切り替えることで、仲間申請でなく招待をすることができるようになる。このように、あるアプリケーションに仲間申請したい相手が当該アプリケーションを利用していない場合もあり得るので、仲間申請の機能と招待の機能を組にして端末装置２で利用者に提供させることは、利用者にとって利便性が高まることになる。
また、本変形例によれば、要求されたアプリケーションにおいて仲間関係が構築されている利用者がアプリケーションを利用しており（第１条件）、当該アプリケーションについて要求利用者と仲間関係が構築されておらず（第２条件）、当該アプリケーションにおいて仲間上限数に達していない（第３条件）利用者の数を表示することが可能となる。これにより、要求されたアプリケーションについて、仲間申請可能な人数を知ることができ、利便性が向上する。
さらに、本変形例によれば、要求されたアプリケーションについて、招待可能な仲間の人数を知ることができ、利便性が向上する。
なお、本変形例は、第２ランキング処理を行う際に、ランクキング表示された各ゲームに招待可能な人数、及び、各ゲームにおいて新たに仲間申請可能な人数を表示する例について説明した。しかし、本変形例は、第１ランキング処理を行う際にも同様に適用可能である。第１ランキング処理を行う際に本変形例を適用する場合には、図９に示す画面において表示されているゲーム（図９の例ではゲームｂ）に対応する種別情報AppIDxについて、図４０に示すＳ７００からＳ７１２までの処理を行うようにすればよい。

（１１）上述した実施形態および変形例においては、管理サーバ３Ａにおいて、利用者情報テーブルＴＢＬ１１、仲間上限数テーブルＴＢＬ１２、及び関係テーブルＴＢＬ１３を設け、各種の情報を集約して管理した。このような一元的な管理を行う場合に、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…の一部又は全部において、個別の利用者情報テーブルＴＢＬ１１ａ、個別の仲間上限数テーブルＴＢＬ１２ａ、及び個別の関係テーブルＴＢＬ１３ａを設け、利用者情報テーブルＴＢＬ１１と利用者情報テーブルＴＢＬ１１ａ、仲間上限数テーブルＴＢＬ１２と仲間上限数テーブルＴＢＬ１２ａ、及び関係テーブルＴＢＬ１３と関係テーブルＴＢＬ１３ａとの同期を取るようにしてもよい。

図４２に変形例に係るアプリケーションシステム１００のブロック図を示す。この例では、アプリケーションサーバ３Ｂが、個別の利用者情報テーブルＴＢＬ１１ａ、個別の仲間上限数テーブルＴＢＬ１２ａ、及び個別の関係テーブルＴＢＬ１３ａを備え、他のアプリケーションサーバ３Ｃ、３Ｄ…は、それらのテーブルを備えないものとする。但し、他のアプリケーションサーバ３Ｃ、３Ｄ…においてもそれらのテーブルを備えてもよい。

以下の説明では、管理サーバ３Ａとアプリケーションサーバ３Ｂとのテーブルを区別するため、管理サーバ３Ａに設けられた利用者情報テーブルＴＢＬ１１、仲間上限数テーブルＴＢＬ１２、及び関係テーブルＴＢＬ１３を第１の利用者情報テーブルＴＢＬ１１、第１の仲間上限数テーブルＴＢＬ１２、及び第１の関係テーブルＴＢＬ１３と称し、アプリケーションサーバ３Ｂに設けられた、利用者情報テーブルＴＢＬ１１ａ、仲間上限数テーブルＴＢＬ１２ａ、及び関係テーブルＴＢＬ１３ａを、第２の利用者情報テーブルＴＢＬ１１ａ、第２の仲間上限数テーブルＴＢＬ１２ａ、及び第２の関係テーブルＴＢＬ１３ａと称する。

図４３に第２の利用者情報テーブルＴＢＬ１１ａのデータ構造を示す。この図に示すように第２の利用者情報テーブルＴＢＬ１１ａには、複数のレコードが記録されている。１つのレコードは、レコードを一意に識別するレコード識別情報ID、利用者を一意に識別する利用者識別情報UID、および最後にログインした日付を示すラストログイン情報LastLoginとからなる。ここで、図３に示す第１の利用者情報テーブルＴＢＬ１１に記憶されている参照識別情報RefIDを第２の利用者情報テーブルＴＢＬ１１ａに記憶しないのは、参照識別情報RefIDは、管理サーバ３Ａにおける管理用の識別情報であり、アプリケーションサーバ３Ｂでは管理する必要がないからである。また、第１の利用者情報テーブルＴＢＬ１１に記憶されている種別情報AppIDを第２の利用者情報テーブルＴＢＬ１１ａに記憶しないのは、アプリケーションサーバ３Ｂが提供するのはゲームｂでありアプリケーションの種別は一意に特定されるため、種別情報AppIDを記憶する必要がないからである。

図４４に第２の仲間上限数テーブルＴＢＬ１２ａのデータ構造を示す。この図に示すように第２の仲間上限数テーブルＴＢＬ１２ａには複数のレコードが記録されている。１つのレコードは、レコード識別情報ID、利用者識別情報UID、および仲間上限数Limitが対応づけられて記憶される。図４に示す第１の仲間上限数テーブルＴＢＬ１２には、全てのアプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…で管理する仲間上限数Limitが集約されているのに対し、図４４に示す第２の仲間上限数テーブルＴＢＬ１２ａはアプリケーションサーバ３Ｂで管理するゲームｂに関する仲間上限数Limitが記憶されている点で相違する。

図４５に第２の関係テーブルＴＢＬ１３ａのデータ構造を示す。第２の関係テーブルＴＢＬ１３ａには複数のレコードが記録されている。１つのレコードは、レコード識別情報ID、種別情報AppID、関係の種別を示すグループ情報Group、申請元の利用者の利用者識別情報UIDである申請元利用者識別情報UID_From、申請先の利用者の利用者識別情報UIDである申請先利用者識別情報UID_To、及び申請の状態を示す状態情報Statが対応づけられて記憶される。図５に示す第２の関係テーブルＴＢＬ１３で記憶する申請元の利用者の参照識別情報RefIDである申請元参照識別情報RefID_From、及び申請先の利用者の参照識別情報RefIDである申請先参照識別情報RefID_Toを記憶しないのは、参照識別情報RefIDは、管理サーバ３Ａにおける管理用の識別情報であり、アプリケーションサーバ３Ｂでは管理する必要がないからである。

説明を図４２に戻す。アプリケーションサーバ３Ｂは、さらに同期部５０を備える。同期部５０は、管理サーバ３Ａの利用者情報同期部１０、仲間上限数同期部１８及び仲間関係同期部１９と連携して、第２の利用者情報テーブルＴＢＬ１１ａ、第２の仲間上限数テーブルＴＢＬ１２ａ、及び第２の関係テーブルＴＢＬ１３ａと、第１の利用者情報テーブルＴＢＬ１１、第１の仲間上限数テーブルＴＢＬ１２、及び第１の関係テーブルＴＢＬ１３との記憶内容を同期させるように動作する。具体的にはアプリケーションサーバ３ＢのＣＰＵが、所定のＡＰＩ（Application Programming Interface）を実行することによって、実現される。

利用者情報同期部１０は、第１の利用者情報テーブルＴＢＬ１１の記憶内容と第２の利用者情報テーブルＴＢＬ１１ａの記憶内容とを同期させる。具体的には、アプリケーションサーバ３Ｂにおいて、第２の利用者情報テーブルＴＢＬ１１ａの記憶内容に変化があると、同期部５０は、変更内容を示す利用者情報変更通知を管理サーバ３Ａに送信する。管理サーバ３Ａの利用者情報同期部１０は、利用者情報変更通知を受信すると、第１の利用者情報テーブルＴＢＬ１１の記憶内容を更新する。例えば、新たな利用者識別情報UIDが追加された場合、利用者識別情報UIDが削除された場合、ラストログイン情報LastLoginが変更された場合が該当する。

なお、同期部５０は、所定のタイミングで利用者情報変更通知を管理サーバ３Ａに送信すればよい。例えば、利用者識別情報UID及びラストログイン情報LastLoginの変更があれば直ちに利用者情報変更通知を送信してもよいし、所定時刻に変更分をまとめて送信してもよい。さらに、利用者情報同期部１０が、所定のタイミングで利用者情報の変更をアプリケーションサーバ３Ｂに問い合わせると、同期部５０は、前回の問い合わせからの変更内容を含む利用者情報変更通知を管理サーバ３Ａに送信してもよい。この場合、管理サーバ３Ａの利用者情報同期部１０は、利用者情報変更通知を受信すると、第１の利用者情報テーブルＴＢＬ１１の記憶内容を更新する。

仲間上限数同期部１８は、受付部１１で受付けた種別情報AppIDに対応するアプリケーションサーバにおいて設定された利用者の仲間上限数Limitを取得する取得部として機能する。仲間上限数同期部１８は、第１の仲間上限数テーブルＴＢＬ１２の記憶内容と第２の仲間上限数テーブルＴＢＬ１２ａの記憶内容とを同期させる。具体的には、アプリケーションサーバ３Ｂにおいて、第２の仲間上限数テーブルＴＢＬ１２ａの記憶内容に変化があると、同期部５０は、変更内容を示す仲間上限数変更通知を管理サーバ３Ａに送信する。管理サーバ３Ａの仲間上限数同期部１８は、仲間上限数変更通知を受信すると、第１の仲間上限数テーブルＴＢＬ１２ａの記憶内容を更新する。

仲間関係同期部１９は、第１の関係テーブルＴＢＬ１３の記憶内容と第２の関係テーブルＴＢＬ１３ａの記憶内容とを同期させる。具体的には、アプリケーションサーバ３Ｂにおいて、第２の関係テーブルＴＢＬ１３の記憶内容に変化があると、同期部５０は、変更内容を示す仲間関係変更通知を管理サーバ３Ａに送信する。管理サーバ３Ａの仲間関係同期部１９は、仲間関係変更通知を受信すると、第１の関係テーブルＴＢＬ１３の記憶内容を更新する。

同期部５０は、アプリケーションサーバ３Ｂにおいて、仲間申請が承認されて仲間関係が成立した場合に、仲間関係変更通知を管理サーバ３Ａに送信する。仲間申請が拒否されて不成立になった場合、同期部５０は仲間関係変更通知を管理サーバ３Ａに送信して第１の関係テーブルＴＢＬ１３の記憶内容と第２の関係テーブルＴＢＬ１３ａの記憶内容とを同期させてもよいが、この点は必須ではなく、仲間関係変更通知を送信せずに同期を取らなくてもよい。なお、状態情報Statについても記憶内容を同期させるようにすると、管理サーバ３Ａにおいて仲間申請中であることを知ることができる。

また、アプリケーションサーバ３Ｂにおいて、仲間関係が解除されると、第２の関係テーブルＴＢＬ１３ａに仲間関係が解除されたことが反映されるが、同期部５０はこれを検知して、仲間関係変更通知を管理サーバ３Ａに送信する。仲間関係同期部１９は、仲間関係変更通知を受信すると、仲間関係が解除されたことを第１の関係テーブルＴＢＬ１３の記憶内容に反映させる。

管理サーバ３Ａと連携しないアプリケーションサーバでは、第２の利用者情報テーブルＴＢＬ１１ａ、第２の仲間上限数テーブルＴＢＬ１２ａ、及び第２の関係テーブルＴＢＬ１３ａを用いて、当該アプリケーションサーバで閉じたサービスを提供している。この変形例によれば、そのようなアプリケーションサーバにおいても、ＡＰＩなどによって同期部５０を追加することによって、アプリケーションシステム１００に容易に取り込むことが可能となる。
このように、本変形例によれば、アプリケーションサーバに設けられた第２の利用者情報テーブルＴＢＬ１１ａ及び第２の関係テーブルＴＢＬ１３ａと、管理サーバ３Ａに設けられた第１の利用者情報テーブルＴＢＬ１１及び第１の関係テーブルＴＢＬ１３との同期を取るので、アプリケーションサーバにおける個別のアプリケーションの管理を管理サーバ３Ａに容易に反映させることができる。
また、本変形例によれば、アプリケーションサーバに設けられた第２の仲間上限数テーブルＴＢＬ１２ａと、管理サーバ３Ａに設けられた第１の仲間上限数テーブルＴＢＬ１２との同期を取るので、アプリケーションサーバにおける個別のアプリケーションにおける仲間上限数の管理を管理サーバ３Ａに容易に反映させることができる。
さらに、反映させた個別のアプリケーションの管理に基づいて、上述したような問合処理を行うことができる。

（１２）上述した実施形態および各変形例においては、利用者情報テーブル（アクセステーブル）ＴＢＬ１１、仲間上限数テーブルＴＢＬ１２、関係テーブルＴＢＬ１３、インバイトテーブルＴＢＬ１４を、管理サーバ３Ａのハードディスク３３に記憶させる例について説明した。しかしながら、本発明はこのような例に限定されるものではなく、図４６に示すように、通信網１を介して管理サーバ３Ａと通信可能なストレージサーバ６０に、利用者情報テーブル（アクセステーブル）ＴＢＬ１１、仲間上限数テーブルＴＢＬ１２、関係テーブルＴＢＬ１３、インバイトテーブルＴＢＬ１４を記憶させるようにしてもよい。この場合には、管理サーバ３Ａは、必要に応じてストレージサーバ６０にアクセスし、各テーブルから情報を読み取るようにすればよい。
また、図４７に示すように、通信網１を介して管理サーバ３Ａと通信可能なストレージサーバ７０に、利用者情報テーブル（アクセステーブル）ＴＢＬ１１、仲間上限数テーブルＴＢＬ１２、関係テーブルＴＢＬ１３を記憶させるようにしてもよい。また、通信網１を介してアプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…と通信可能なストレージサーバ８０に、利用者情報テーブルＴＢＬ１１ａ、仲間上限数テーブルＴＢＬ１２ａ、関係テーブルＴＢＬ１３ａを記憶させるようにしてもよい。
この場合には、管理サーバ３Ａは、必要に応じてストレージサーバ７０にアクセスし、各テーブルから情報を読み取るようにすればよい。また、アプリケーションサーバ３Ｂ、３Ｃ、３Ｄ…は、必要に応じてストレージサーバ６０にアクセスし、各テーブルから情報を読み取るようにすればよい。

（１３）上述した実施形態および各変形例においては、管理サーバ３Ａまたは端末装置２において実行されるプログラムは、コンピュータ読み取り可能な記録媒体に記憶させても良い。この記録媒体を用いれば、例えば前記コンピュータに前記プログラムをインストールすることができる。
なお、ここでいう「コンピュータ」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ、コンピュータに内蔵されるハードディスク等の非一過性の記録媒体であっても良い。
さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。また、本発明における機能またはその一部を実現するためのプログラムを配信する配信サーバ及び当該配信サーバに備えられた記憶媒体、及び当該配信サーバの外部に存在し、当該プログラムを前記配信サーバにより配信するために記憶している記憶媒体も、本発明の範囲に含まれる。
また、上述した機能の一部または全部を、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

＜４．実施形態及び変形例から導かれる発明＞
問合処理に関する発明の他、上述した実施形態及び変形例から、以下に述べる仲間申請処理に関する発明及び招待処理に関する発明なども導かれる。
（１）仲間申請処理に関する発明
あるアプリケーションで、他のアプリケーションで仲間関係となった利用者と仲間関係を容易に構築可能とするなどの課題を解決するため、管理サーバは、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能なものであって、仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付ける受付部と、前記受付部で受付けた種別情報が示すアプリケーションを利用していることを第１条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第２条件、当該アプリケーションにおいて仲間上限数に達していないことを第３条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定する特定部と、前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させる表示制御部と、前記受付部で受付けた種別情報が示すアプリケーションに対応したアプリケーションサーバに対して、前記要求利用者が前記候補利用者の中から選択した利用者に対して仲間申請を要求する指示を行う指示部と、を備える。

この発明によれば、管理サーバは第１乃至第３条件を充足する候補利用者を選択できるように要求利用者の端末装置に表示させるので、要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち、要求利用者が利用しているアプリケーションを利用しており（第１条件）、当該アプリケーションについて要求利用者と仲間関係が構築されておらず（第２条件）、当該アプリケーションにおいて仲間上限数に達していない（第３条件）利用者を仲間の候補として提示することが可能となる。
これによって、異なるアプリケーションで形成された信頼関係を新しいアプリケーションでも活用できるようになる。なお、アプリケーションとしては、ゲームアプリケーションを例示することができるが、本発明はこれに限定されるものではなく、いかなるものであってもよいことは勿論である。

上述した管理サーバにおいて、前記種別情報に関連付けて仲間関係となる利用者情報の組を記憶する仲間関係テーブルと、前記種別情報に関連付けて当該種別情報が示すアプリケーションを利用している利用者情報を記憶する利用者情報テーブルと、を備え、前記特定部は、前記利用者情報テーブルを参照して前記第１条件を充足する候補利用者を特定し、前記仲間関係テーブルを参照して前記第２条件を充足する候補利用者を特定することが好ましい。

この発明によれば、管理サーバの仲間関係テーブルに、仲間関係となる利用者情報の組を記憶するから、各種のアプリケーションで構築される仲間関係を一元的に管理することができる。さらに、種別情報と利用者情報とを対応づけて記憶する利用者情報テーブルを備えるので、この利用者情報テーブルを参照することによって第１条件を充足することができる。

上述した管理サーバにおいて、前記仲間関係テーブルが記憶する前記利用者情報の組は、仲間申請を行った利用者の利用者情報と、仲間申請を承諾した利用者の利用者情報とからなることが好ましい。
この発明によれば、申請側と承諾側との組を記憶することにより、一つの利用者情報をキーとして当該利用者情報と仲間関係にある全ての利用者情報を記憶する必要はないので、データの記憶容量を削減することが可能となる。
さらに、前記特定部は、前記仲間関係テーブルを参照して、前記要求利用者が利用したことのある利用済みアプリケーションに対応する種別情報と関連付けて記憶されている前記利用者情報の組のうち、仲間申請を行った利用者の利用者情報が前記要求利用者の利用情報と一致する仲間申請を受諾した利用者の利用者情報を抽出するとともに、仲間申請を受諾した利用者の利用者情報が前記要求利用者の利用情報と一致する仲間申請を行った利用者の利用者情報を抽出し、抽出した利用者情報の利用者を、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者とすることが好ましい。

上述した管理サーバにおいて、前記受付部で受付けた種別情報に対応する前記アプリケーションサーバにおいて設定された利用者の仲間上限数を取得する取得部と、前記取得部が取得した仲間上限数を利用者情報と関連付けて記憶する仲間上限数テーブルとを備え、前記特定部は、前記仲間上限数テーブルを参照して前記第３条件を充足する候補利用者を特定することが好ましい。この発明によれば、仲間上限数テーブルを用いて、アプリケーションごとに定められる仲間上限数を管理サーバで一元的に管理するので、第３条件を充足させることが可能となる。

上述した管理サーバにおいて、前記受付部で受付けた種別情報に対応する前記アプリケーションサーバに対して利用者の仲間上限数を問い合わせる要求を送信し、前記要求に対する応答として当該アプリケーションサーバから仲間上限数を取得する取得部を備え、 前記特定部は、前記取得部で取得した仲間上限数に基づいて前記第３条件を充足する候補利用者を特定することが好ましい。この例では、アプリケーションサーバから仲間上限数を取得する取得部を備えるので、仲間上限数を取得することが可能となる。

上述した管理サーバにおいて、アプリケーションの利用日時を示す日時情報を利用者識別情報と関連付けて記憶するアクセステーブルを備え、前記特定部は、前記アクセステーブルを参照して所定期間内にアプリケーションを利用していることを前記第1条件に加えて、前記第１条件を充足する候補利用者を特定することが好ましい。

この発明によれば、アプリケーションの利用から所定期間内の候補利用者に限定しているので、アプリケーションを試しに利用し、その後、利用しなくなった利用者については候補利用者から除くので、着目するアプリケーションについて実際に使用している利用者を候補利用者とすることができるといった利点がある。
なお、本発明は各種のテーブルの構造を限定するものではない。例えば、利用者情報テーブルとアクセステーブルとは同一のテーブルで構成してもよい。

上述した管理サーバにおいて、前記表示制御部は、前記要求利用者が利用したことのある利用済みアプリケーションを選択できるように前記要求利用者の端末装置に表示させ、 前記特定部は、前記端末装置において前記要求利用者が選択した利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定することが好ましい。

この発明によれば、利用済みアプリケーションを選択できるように要求利用者の端末装置に表示させ、選択した利用済みアプリケーションについて仲間関係にあることが候補利用者の要件となるので、要求利用者は、仲間関係を構築しようとするアプリケーションと類似する利用済みアプリケーションを選択することができたり、具体的にどのアプリケーションのどの仲間を誘いたいかがあらかじめ決まっている場合に探し易くなる。

上述した管理サーバにおいて、前記特定部は、前記要求利用者が利用したことのある利用済みアプリケーションについて、仲間申請が可能な人数を特定し、前記表示制御部は、前記特定部が特定した仲間申請が可能な人数を前記要求利用者の端末装置に表示させることが好ましい。
この発明によれば、仲間申請が可能な人数を知ることができるので、要求利用者に利便性が大幅に向上する。なお、仲間申請が可能な人数は、利用済みアプリケーションごとに特定し、利用済みアプリケーションごとに要求利用者の端末装置に表示させてもよいし、複数の利用済みアプリケーションの合計の仲間申請が可能な人数を特定し、これを要求利用者の端末装置に表示させてもよい。

上述した発明は、管理サーバのコンピュータに用いられるプログラムとして把握することができる。この場合、本発明に係るプログラムは、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバのコンピュータに用いられ、前記コンピュータを、仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付ける受付部と、前記受付部で受付けた種別情報が示すアプリケーションを利用していることを第１条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第２条件、当該アプリケーションにおいて仲間上限数に達していないことを第３条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定する特定部と、前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させる表示制御部と、前記受付部で受付けた種別情報が示すアプリケーションに対応したアプリケーションサーバに対して、前記要求利用者が前記候補利用者の中から選択した利用者に対して仲間申請を要求する指示を行う指示部として、機能させることを特徴とする。

上述した発明は、管理サーバの制御方法としても捉えることができる。この場合、本発明に係る管理サーバの制御方法は、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバを制御する方法であって、仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付け、受付けた種別情報が示すアプリケーションを利用していることを第１条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第２条件、当該アプリケーションにおいて仲間上限数に達していないことを第３条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定し、特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させ、受付けた種別情報が示すアプリケーションに対応したアプリケーションサーバに対して、前記要求利用者が前記候補利用者の中から選択した利用者に対して仲間申請を要求する、ことを特徴とする。

上述した発明は、端末装置のコンピュータに用いられるプログラムとして把握することができる。この場合、本発明に係るプログラムは、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバと接続された管理サーバと通信可能な利用者の端末装置のコンピュータに用いられるプログラムであって、前記複数のアプリケーションサーバの各々は、仲間の上限数を利用者ごとに管理しており、前記管理サーバは、仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付ける受付部と、前記受付部で受付けた種別情報が示すアプリケーションを利用していることを第１条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第２条件、当該アプリケーションにおいて仲間上限数に達していないことを第３条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定する特定部と、前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させる表示制御部と、前記受付部で受付けた種別情報が示すアプリケーションに対応したアプリケーションサーバに対して、前記要求利用者が前記候補利用者の中から選択した利用者に対して仲間申請を要求する指示を行う指示部と、を備え、前記端末装置のコンピュータを、当該端末装置の利用者の仲間上限数が変化したことを検出する検出部と、前記検出部によって前記仲間上限数が変化したことが検出されると、変化した後の仲間上限数を前記管理サーバに通知する通知部として、機能させること特徴とする。

（２）招待処理に関する発明
あるアプリケーションで、他のアプリケーションで仲間関係となった利用者を他のアプリケーションに招待可能とするため、本発明に係る管理サーバは、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能なサーバであって、招待の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付ける受付部と、前記受付部で受付けた種別情報が示すアプリケーションを利用していないことを条件としたとき、前記条件を充足する候補利用者の一部又は全部を特定する特定部と、前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させる表示制御部と、前記要求利用者が、前記端末装置に表示された候補利用者の中から選択した候補利用者に対して招待申請を通知する通知部と、を備える。

この発明によれば、複数のアプリケーションサーバと通信可能な管理サーバは、要求利用者が指定した招待の対象となるアプリケーションを利用していない候補利用者を特定する。したがって、要求利用者は、自身が利用しているアプリケーションであって、これを利用していない候補利用者の中から招待の対象となる利用者を選択することができる。これにより、他の利用者を自身が利用しているアプリケーションサービスに容易に誘うことができる。
なお、前記条件に、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されていることを付加してもよい。この場合には、要求利用者と他のアプリケーションで仲間関係が構築されている利用者を誘うことができるので、過去に形成された仲間に新たなアプリケーションを広めることが可能となる。
また、通知部は、選択された候補利用者に対して招待申請を通知するのであれば、どのような方法であってもよく、例えば、登録されたメールアドレスに対して招待申請のメールを送信してもよいし、あるいは、選択された候補利用者が管理するページに招待申請があった旨を表示するようにしてもよい。また、他のソーシャルメディアや掲示板へ招待記事を投稿をするように送信してもよい。

上述した管理サーバにおいて、前記種別情報に関連付けて当該種別情報が示すアプリケーションを利用している利用者情報を記憶する利用者情報テーブルと、を備え、前記特定部は、前記利用者情報テーブルを参照して、前記条件を充足する候補利用者を特定する、ことが好ましい。
この発明によれば、各種のアプリケーションの種別情報と全ての利用者の利用者識別情報とを対応づけて記憶する利用者情報テーブルを備えるので、複数のアプリケーションの利用者を一元的に管理することが可能となる。

上述した管理サーバにおいて、前記種別情報に関連付けて、仲間関係となる仲間申請を行った利用者の利用者情報と仲間申請を受諾した利用者の利用者情報との組を記憶する仲間関係テーブルを備え、前記特定部は、前記条件に加え、前記仲間関係テーブルを参照して、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築される利用者を前記候補利用者として特定することが好ましい。

この発明によれば、仲間申請において申請側と承諾側との組を記憶することにより、一つの利用者情報をキーとして当該利用者情報と仲間関係にある全ての利用者情報を記憶する必要はないので、データの記憶容量を削減することが可能となる。
さらに、前記特定部は、前記仲間関係テーブルを参照して、前記要求利用者が利用したことのある利用済みアプリケーションに対応する種別情報と関連付けて記憶されている前記利用者情報の組のうち、仲間申請を行った利用者の利用者情報が前記要求利用者の利用情報と一致する仲間申請を受諾した利用者の利用者情報を抽出するとともに、仲間申請を受諾した利用者の利用者情報が前記要求利用者の利用者情報と一致する仲間申請を行った利用者の利用者情報を抽出し、抽出した利用者情報の利用者を、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築される候補利用者とすることが好ましい。

上述した管理サーバにおいて、前記表示制御部は、前記要求利用者が利用したことのある利用済みアプリケーションを選択できるように前記要求利用者の端末装置に表示させ、前記特定部は、前記端末装置において前記要求利用者が選択した利用済みアプリケーションにおいて前記条件を充足する候補利用者の一部又は全部を特定することが好ましい。
この発明によれば、利用済みアプリケーションを選択できるように要求利用者の端末装置に表示させ、選択した利用済みアプリケーションについて仲間関係にあることが候補利用者の要件となるので、要求利用者は、招待しようとするアプリケーションと類似する利用済みアプリケーションを選択するなど、好みに合わせた選択が可能となる。

上述した管理サーバにおいて、前記特定部は、前記要求利用者が利用したことのある利用済みアプリケーションについて、招待が可能な人数を特定し、前記表示制御部は、前記特定部が特定した招待可能な人数を前記要求利用者の端末装置に表示させることが好ましい。
この発明によれば、招待申請が可能な人数を知ることができるので、要求利用者に利便性が大幅に向上する。なお、招待申請が可能な人数は、利用済みアプリケーションごとに特定し、利用済みアプリケーションごとに要求利用者の端末装置に表示させてもよいし、複数の利用済みアプリケーションの合計の招待申請が可能な人数を特定し、これを要求利用者の端末装置に表示させてもよい。

上述した管理サーバにおいて、前記種別情報に関連付けて、招待をした利用者の利用者情報と招待をされた利用者の利用者情報の組と、招待の状態を示す状態情報とを記憶した招待テーブルを備え、前記特定部は、前記招待テーブルを参照して、前記受付部で受付けた種別情報と関連付けて記憶されており、前記要求利用者の利用者情報と招待した利用者の利用者情報とが一致し、且つ前記状態情報が少なくとも拒否を示すレコードの招待をされた利用者の利用者情報を特定し、特定した利用者を前記候補利用者から除く、ことが好ましい。
この発明によれば、招待の状態を示す状態情報と利用者情報とを対応づけて招待テーブルで管理するので、招待テーブルを参照することによって、招待の状態を知ることができる。そして、状態情報が拒否を示す場合には、候補利用者から除かれるので、招待を拒否しているに拘わらず再度の招待があるといった迷惑行為を未然に防止することがきる。

上述した管理サーバにおいて、前記状態情報の示す状態は、招待を拒否又は承認したことを示す第１状態を含み、前記状態情報が少なくとも招待の拒否を示すとは、前記状態情報が前記第1状態である、ことが好ましい。
この発明によれば、拒否と承認をまとめて第１状態としている。したがって、招待を拒否された場合だけでなく、招待が承認された場合にも候補利用者から除外される。招待を承認した利用者は、そもそも招待の対象となるアプリケーションを既に利用しているから、招待する必要がない。このようなデータ構造を採用することにより、拒否した利用者と招待された利用者を同時に排除できるので処理負荷が軽減される。

上述した管理サーバにおいて、前記状態情報の示す状態は、招待の申請中であることを示す第２状態を含み、前記特定部は、前記招待テーブルを参照して、前記受付部で受付けた種別情報と関連付けて記憶されており、前記要求利用者の利用者情報と招待した利用者の利用者情報とが一致し、且つ前記状態情報が前記第２状態を示すレコードの招待をされた利用者の利用者情報を抽出し、抽出した利用者と前記特定した利用者とを、前記候補利用者から除くことが好ましい。
この発明によれば、招待申請中の利用者も候補利用者から除かれるから、申請中に拘わらず、再度、招待を申請するといった無駄をなくし、管理サーバの処理負荷を軽減することができる。

上述した管理サーバにおいて、招待した利用者と招待を拒否した利用者とを管理する管理部を備え、前記特定部は、前記管理部を用いて、前記要求利用者が招待した利用者として管理されている場合、招待を拒否した利用者を特定し、特定した利用者を前記候補利用者から除く、ことが好ましい。この発明によれば、招待した利用者と招待を拒否した利用者とを対応づけて管理するので、一度、拒否された利用者を再度、招待することを未然に防止することができる。

上述した管理サーバにおいて、前記種別情報に関連付けて、招待をした利用者の利用者情報と招待をされた利用者の利用者情報の組と、招待の状態を示す状態情報と、招待した日時を示す招待日時情報とを記憶した招待テーブルを備え、前記特定部は、前記招待テーブルを参照して、前記受付部で受付けた種別情報と関連付けて記憶されており、前記要求利用者の利用者情報と招待した利用者の利用者情報とが一致し、且つ前記状態情報が少なくとも招待の拒否を示すレコードと、前記状態情報が招待の申請中を示し、前記招待日時情報の示す日時から所定期間が経過しているレコードとについて、招待をされた利用者の利用者情報を特定し、特定した利用者を前記候補利用者から除く、ことが好ましい。

この発明によれば、招待を申請中の利用者に対して、再度の招待申請を許容する。これにより、招待を承認するか否かをまよっている利用者に対して、再び招待することによって、アプリケーションサービスへの参加を促すことができる。しかしながら、何度も招待するのは迷惑である。そこで、本発明は、状態情報が申請中を示していても、招待の日時から所定期間が経過すると、状態情報が申請中を示していても、候補利用者から除外している。これにより、アプリケーションサービスへの参加を促しつつ、迷惑行為を防止することが可能となる。
より具体的には、前記状態情報の示す状態は、招待を拒否又は承認したことを示す第１状態と、招待の申請中であることを示す第２状態とを含み、前記状態情報が少なくとも招待の拒否を示すとは、前記状態情報の状態が前記第1状態であり、前記状態情報が招待の申請中を示すとは、前記状態情報の状態が前記第２状態であることが好ましい。この場合には、拒否と承認を一つの状態として管理できるので、データ構造を簡素化できる。

上述した管理サーバにおいて、前記種別情報に関連付けて、招待をした利用者の利用者情報と招待をされた利用者の利用者情報の組と、招待の状態を示す状態情報と、招待した日時を示す招待日時情報とを記憶した招待テーブルを備え、前記特定部は、前記招待テーブルを参照して、前記受付部で受付けた種別情報と関連付けて記憶されており、前記要求利用者の利用者情報と招待した利用者の利用者情報とが一致し、且つ前記状態情報が少なくとも招待の拒否を示すレコードについて、招待された利用者の利用者情報を特定し、特定した利用者を前記候補利用者から除き、前記招待申請を通知した日時から所定期間が経過しても招待された利用者から応答がない場合、前記状態情報の状態を招待の申請中から招待の拒否へ書き換える書換部とを備える、ことが好ましい。
この発明によれば、招待申請を通知した日時から所定期間が経過しても招待された利用者から応答がない場合、前記状態情報の状態を招待の申請中から招待の拒否へ書き換えるので、候補利用者に該当するか否かの判定を簡素化することができる。

より具体的には、前記状態情報の状態は、招待の拒否又は承認を示す第1状態と、招待の申請中であることを示す第２状態とを含み、前記状態情報が少なくとも招待の拒否を示すとは、前記状態情報が前記第1状態である場合であり、前記書換部は、前記招待申請を通知した日時から所定期間が経過しても招待された利用者から応答がない場合、前記状態情報の状態を前記第２状態から前記第1状態に書き換える、ことが好ましい。
この発明によれば、招待を拒否された場合だけでなく、招待が承認された場合にも候補利用者から除外される。招待を承認した利用者は、そもそも招待の対象となるアプリケーションを既に利用しているから、招待する必要がない。このようなデータ構造を採用することにより、拒否した利用者と招待された利用者を同時に排除できるので処理負荷が軽減される。

次に、本発明は、管理サーバのプログラムとして把握される。種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバのコンピュータに用いられるプログラムであって、前記コンピュータを、招待の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付ける受付部と、前記受付部で受付けた種別情報が示すアプリケーションを利用していないことを条件としたとき、前記条件を充足する候補利用者の一部又は全部を特定する特定部と、前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させる表示制御部と、前記要求利用者が、前記端末装置に表示された候補利用者の中から選択した候補利用者に対して招待申請を通知する通知部として、機能させることを特徴とする。

次に、本発明は、管理サーバの制御方法としても把握される。この制御方法は、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバの制御する方法であって、招待の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付け、前記受付部で受付けた種別情報が示すアプリケーションを利用していないことを条件としたとき、前記条件を充足する候補利用者の一部又は全部を特定し、前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させ、前記要求利用者が、前記端末装置に表示された候補利用者の中から選択した候補利用者に対して招待申請を通知することを特徴とする。

１……通信網、２……端末装置、３Ａ……サーバ装置、３Ｂ,３Ｃ,３Ｄ……アプリケーションサーバ、ＴＢＬ１１……利用者情報テーブル、ＴＢＬ１２……仲間上限数テーブル、ＴＢＬ１３……関係テーブル、ＴＢＬ１４……インバイトテーブル、１１……受付部、１２……特定部、１３……指示部、１４……表示制御部、１５……情報取得部、１６……通知部、３０……ＣＰＵ、１００……アプリケーションシステム。

Claims (10)

1. 種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバであって、
   利用者の端末装置の操作に基づく要求を受ける受付部と、
   前記複数のアプリケーションのうち、前記受付部で受け付けた要求の利用者である要求利用者が利用したことがある利用済みアプリケーションにおいて、前記要求利用者と仲間関係が構築されている利用者が利用しているアプリケーションに関する利用情報を取得する情報取得部と、
   前記情報取得部で取得した前記利用情報を前記要求利用者の端末装置に表示させる表示制御部と、
   を備えることを特徴とする管理サーバ。
2. 種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバであって、
   利用者の端末装置の操作に基づく要求を受ける受付部と、
   前記複数のアプリケーションのうち、前記要求に対応づけられたアプリケーションにおいて、前記受付部で受け付けた要求の利用者である要求利用者と仲間関係が構築されている利用者が利用しているアプリケーションに関する利用情報を取得する情報取得部と、
   前記情報取得部で取得した前記利用情報を前記要求利用者の端末装置に表示させる表示制御部と、
   を備えることを特徴とする管理サーバ。
3. 前記表示制御部は、前記利用情報として、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、各アプリケーションを利用している前記要求利用者と仲間関係が構築されている利用者の数の多い順にアプリケーションの種類の一部または全部を表示する、ことを特徴とする請求項１に記載の管理サーバ。
4. 前記表示制御部は、アプリケーションの種類を示す種別情報、前記アプリケーションの利用日時を示す日時情報、および利用者を特定する利用者情報を関連付けて備えるアクセステーブルを用いて、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、前記要求利用者と仲間関係が構築されている利用者であって、且つ所定期間内にアプリケーションを利用している利用者の数の多い順にアプリケーションの種類の一部または全部を表示する、
   ことを特徴とする請求項３に記載の管理サーバ。
5. 前記情報取得部は、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、前記要求利用者と仲間関係が構築されている利用者の数をアプリケーションごとに特定して前記利用情報を生成し、
   前記表示制御部は、アプリケーションごとに前記利用者の数を表示する、
   ことを特徴とする請求項１に記載の管理サーバ。
6. 前記情報取得部は、アプリケーションの種類を示す種別情報、前記アプリケーションの利用日時を示す日時情報、および利用者を特定する利用者情報を関連付けて備えるアクセステーブルを用いて、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、前記要求利用者と仲間関係が構築されている利用者であって、且つ所定期間内にアプリケーションを利用している利用者の数をアプリケーションごとに特定して前記利用情報を生成し、
   前記表示制御部は、アプリケーションごとに前記利用者の数を表示する、
   ことを特徴とする請求項１に記載の管理サーバ。
7. 前記受付部は、アプリケーションの種類を示す種別情報を含む要求を受け付け、
   前記情報取得部は、前記受付部で受付けた種別情報が示すアプリケーションを利用していることを第１条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第２条件、当該アプリケーションにおいて仲間上限数に達していないことを第３条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する仲間申請が可能な利用者数を特定し前記利用者情報として取得する、
   ことを特徴とする請求項２に記載の管理サーバ。
8. 前記受付部は、アプリケーションの種類を示す種別情報を含む要求を受け付け、
   前記情報取得部は、前記受付部で受付けた種別情報が示すアプリケーションを利用していないことを条件としたとき、前記条件を充足する利用者の数である招待が可能な利用者数を前記利用者情報として取得することを特徴とする請求項２に記載の管理サーバ。
9. 種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバのコンピュータに用いられるプログラムであって、
   前記コンピュータを、
   利用者の端末装置の操作に基づく要求を受ける受付部と、
   前記複数のアプリケーションのうち、前記受付部で受け付けた要求の利用者である要求利用者が利用したことがある利用済みアプリケーションにおいて、前記要求利用者と仲間関係が構築されている利用者が利用しているアプリケーションに関する利用情報を取得する情報取得部と、
   前記情報取得部で取得した前記利用情報を前記要求利用者の端末装置に表示させる表示制御部として、
   機能させるためのプログラム。
10. 種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバの制御方法であって、
    利用者の端末装置の操作に基づく要求を受ける受付け、
    前記複数のアプリケーションのうち、前記受付部で受け付けた要求の利用者である要求利用者が利用したことがある利用済みアプリケーションにおいて、前記要求利用者と仲間関係が構築されている利用者が利用しているアプリケーションに関する利用情報を取得し、
    前記取得した前記利用情報を前記要求利用者の端末装置に表示させる、
    ことを特徴とする管理サーバの制御方法。

Images