JP5946932B2 - 管理装置 - Google Patents

Description

本発明は、個別に提供される複数のアプリケーションを管理する識別情報を紐付ける技術に関する。

近年、インターネット上でのアプリケーションを提供するサービスが急速に普及している。この種のサービスの一つとして、ＳＮＳ（Ｓocial Ｎetworking Ｓervice）などのサイトの利用者である会員に対して提供されるゲームなどのアプリケーションがある。ＳＮＳでは、会員を特定できる会員情報を管理する。したがって、同一の利用者のユーザ情報（以下、アカウントと称する）はアプリケーションごとに相違するが、ＳＮＳではこれらのアカウントを会員情報と紐付けることにより、交流のある会員どうしで互いにどのようなアプリケーションを利用しているかを知ることができるなど、複数のアプリケーションに関係する相互サービスを利用者に提供することが可能となる（例えば、特許文献１）。

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

ところで、ＳＮＳの会員ではなくても利用できるＳＮＳに依存しない一般的なアプリケーション（以下、一般アプリケーションと称する）がある。このような一般アプリケーションでも、アカウントに互換性がないため、互いの一般アプリケーションに関係する相互サービスを利用者に提供することができない。一方、利用者は、複数の一般アプリケーションを一つの端末装置で利用することができる。これらの複数の一般アプリケーションの利用者のアカウントを一元的に管理する場合、ＳＮＳプラットフォームのシステムと同様に、それらを統合する管理サーバが必要となる。
しかしながら、そのような管理サーバを導入する場合には、管理サーバに対する新たな管理用アカウントを利用者ごとに設け、且つ、複数の一般アプリケーションサーバでの互いのアカウントを紐付ける必要があった。このため、利用者は、既存のアカウントに加えて、新たな管理用アカウントを管理しなければならないといった問題があった。
本発明は、上述した事情に鑑みてなされたものであり利用者が管理する管理アカウントを新たに設けることなくＳＮＳに依存しない複数の一般アプリケーションによって提供される複数のアカウントを紐付けることが可能な管理装置を提供することなどを解決課題とする。

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

上述した課題を解決するため、管理装置（３）は、第１アプリケーションを提供する第１アプリケーション装置（４Ａ）及び第２アプリケーションを提供する第２アプリケーション装置（４Ｂ）を含む複数のアプリケーション装置（４Ａ、４Ｂ、４Ｃ…）と通信可能であり、前記第１アプリケーションを利用する複数の利用者のそれぞれを一意に識別する第１識別情報（FNWIDa）及び前記第２アプリケーションを利用する複数の利用者のそれぞれを一意に識別する第２識別情報（FNWIDb）を発行して管理するものであって、前記第１アプリケーション装置に対して利用者の第１識別情報に関連付けられた識別子（Ｔｘ）を発行する発行部（１１）と、前記第１アプリケーション及び前記第２アプリケーションを利用可能な端末装置（２）において、前記第１アプリケーションから前記第２アプリケーションに引き渡された前記識別子を受領する受領部（１２）と、前記発行部で発行した識別子と前記受領部で受領した識別子とが合致する前記第１識別情報と前記第２識別情報とを関連付けて管理する管理部（１３）と、を備える。

上述した管理装置において、前記複数のアプリケーション装置のそれぞれが提供するアプリケーションは、当該アプリケーション内での他の利用者と特定の関係が形成されるものであり、前記管理部は、複数のアプリケーションのそれぞれの利用者の前記特定の関係を示す関係情報を、前記複数のアプリケーション装置のそれぞれから取得して管理することが好ましい。

上述した管理装置において、前記第１アプリケーションを利用する端末装置または前記第１アプリケーション装置のいずれかから前記第２識別情報に対応付けられた関係情報の取得要求を受け付ける受付部（１４）と、前記取得要求をした前記端末装置または前記第１アプリケーション装置に、前記第２識別情報に対応付けられた関係情報を通知する通知部（１５）と、を備えることが好ましい。

上述した管理装置において、前記通知部で通知した関係情報の中から招待利用者が選択した被招待利用者に対する前記第１アプリケーションへの招待要求を受け付けて招待要求を蓄積する蓄積部（１６）を備えることが好ましい。

上述した管理装置において、前記通知部は、前記端末装置から招待要求の照会があると、当該端末装置の利用者が被招待利用者となっている招待要求が前記蓄積部に蓄積されている場合、前記招待利用者が前記第１アプリケーションへ招待することを示す招待情報を当該端末装置に通知することが好ましい。

上述した管理装置において、前記通知部は、当該通知部で通知した前記関係情報の中から招待利用者が選択した被招待利用者に対する招待要求があると、前記被招待利用者の前記第２アプリケーション装置へ前記招待利用者が前記第１アプリケーションに招待することを示す招待情報を通知することが好ましい。

次に、本発明に係る管理装置の制御方法は、第１アプリケーションを提供する第１アプリケーション装置及び第２アプリケーションを提供する第２アプリケーション装置を含む複数のアプリケーション装置と通信可能であり、前記第１アプリケーションを利用する複数の利用者のそれぞれを一意に識別する第１識別情報及び前記第２アプリケーションを利用する複数の利用者のそれぞれを一意に識別する第２識別情報を発行して管理する管理装置の制御方法であって、前記第１アプリケーション装置に対して、利用者の第１識別情報に関連付けられた識別子を発行し、前記第１アプリケーションから前記第２アプリケーションに引き渡された前記識別子を、前記第２アプリケーション装置から受領し、前記発行した識別子と前記受領した識別子とが合致する前記第１識別情報と前記第２識別情報とを関連付けて管理することを特徴とする。

次に、本発明に係るプログラムは、第１アプリケーションを提供する第１アプリケーション装置及び第２アプリケーションを提供する第２アプリケーション装置を含む複数のアプリケーション装置と通信可能であり、前記第１アプリケーションを利用する複数の利用者のそれぞれを一意に識別する第１識別情報及び前記第２アプリケーションを利用する複数の利用者のそれぞれを一意に識別する第２識別情報を発行して管理する管理装置のコンピュータに用いられるプログラムであって、前記管理装置のコンピュータを、前記第１アプリケーション装置に対して、利用者の第１識別情報に関連付けられた識別子を発行する発行部と、前記第１アプリケーションから前記第２アプリケーションに引き渡された前記識別子を、前記第２アプリケーション装置から受領する受領部と、前記発行部で発行した識別子と前記受領部で受領した識別子とが合致する前記第１識別情報と前記第２識別情報とを関連付けて管理する管理部として機能させることを特徴とする。

本発明の実施形態に係るアプリケーションシステムのブロック図である。 アカウントを関連付ける処理の概要を説明するための説明図である。 招待要求の照会についての処理の概要を説明するための説明図である。 管理サーバの構成を示すブロック図である。 利用者情報テーブルのデータ構造の一例を示す説明図である。 ＩＤ管理テーブルのデータ構造の一例を示す説明図である。 仲間関係テーブルのデータ構造の一例を示す説明図である。 インバイトテーブルのデータ構造の一例を示す説明図である。 端末装置の構成を示すブロック図である。 フレンドネットワーク識別情報の取得処理の内容を示すシーケンス図である。 仲間関係の同期処理の内容を示すシーケンス図である。 招待処理の内容を示すシーケンス図である。 変形例に係るフレンドネットワーク識別情報の取得処理の内容を示すシーケンス図である。

以下、実施形態として、本発明に係る管理サーバを用いたアプリケーションシステムについて、図面を参照しつつ説明する。
＜１．アプリケーションシステムの構成＞
図１は、本発明の実施形態に係るアプリケーションシステム１００のブロック図である。このアプリケーションシステム１００は、インターネットなどの通信網ＮＥＴ、利用者の端末装置２、管理サーバ３、アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…を備える。アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…は、独立して利用者のアカウントを管理し、それぞれのアプリケーションでの独自サービスを利用者に提供する。この例のアプリケーションサーバ４Ａ、４Ｂ、４Ｃ…は、独自サービスとしてゲームＡ、ゲームＢ、ゲームＣ…を提供する。ゲームＡ、ゲームＢ、ゲームＣ…は、ブラウザによって提供されるブラウザゲームであってもよいが、この例では、ゲームＡ、ゲームＢ、ゲームＣ…のプログラムを利用者の端末装置２にダウンロードし、端末装置２にプログラムがインストールされてプログラムが実行されるものとする。この場合、アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…は、ゲームＡ、ゲームＢ、ゲームＣ…の利用者のゲームデータを管理したり、得点ランキングなどを利用者に提供したりする。

また、アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…は、ゲームＡ、ゲームＢ、ゲームＣ…など各種のアプリケーション（例えば、写真や動画の共有）を提供するものであるが、アプリケーションが提供する独自サービスに利用者同士のコミュニケーションを図る機能を加えてもよい。そのようなコミュニケーション機能を用いて、例えば、各アプリケーションの利用者は、同じゲーム（アプリケーション）の利用者と仲間関係を構築し、仲間同士で挨拶やコメントなどのコミュニケーションを行うことによってゲーム上で交換価値があるポイントを獲得できる。また、ゲーム上での対戦では、仲間の応援が得られるなど、仲間の数が多いほどゲームが有利に進行する。仲間関係は、例えば利用者が仲間申請を行い、これを申請先の利用者が承認することによって構築される。

また、管理サーバ３はアプリケーションサーバ４Ａ、４Ｂ、４Ｃ…と通信可能である。さらに、利用者の端末装置２は、通信網ＮＥＴを介した通信が可能であり、例えば、パーソナルコンピュータや携帯電話機などが該当する。

ＳＮＳに依存しない複数のゲームに関係する相互サービスを利用者に提供するためには、互いのゲームのアカウントを関連付ける必要がある。アカウントの関連付けができると、相互サービスとして、例えば、あるゲームをプレイしている利用者が当該ゲームに、他のゲームで仲間となっている他の利用者を招待できるようになる。つまり、ゲームＡの利用者がゲームＢを利用している場合、当該利用者は、ゲームＢにおいて仲間関係にある利用者をゲームＡに招待することができるようになる。
ところで、このようなＳＮＳに依存しないゲームにおいては、利用者が利用しているゲームに対して他の利用者を招待する場合、ソーシャルメディアやメールなどを利用する方法が行われていた。この方法では招待したい相手がソーシャルメディアを利用しているか不明であるし、メールアドレスを知らない場合もある。そもそも、ゲームで仲間関係にある利用者は、必ずしも現実社会で友だち関係にあるとも限らない。また、ゲーム内で知られている利用者名（ニックネーム）と、現実社会で利用されているソーシャルメディアやメールでの利用者名（アカウント）とが一致していないため、ソーシャルメディアで招待したい相手を特定することが難しい。したがって、上記の方法では、ゲームで仲間関係にある利用者を招待することができない場合があった。そこで、ＳＮＳに依存しない複数のゲームのアカウントを関連付けることで、あるゲームをプレイしている利用者が当該ゲームに、他のゲームで仲間となっている他の利用者を招待できるようになる。

招待を行う場合には、第１に、招待する利用者（招待利用者）のゲームＡ（アプリケーションＡの一例）のアカウントとゲームＢ（アプリケーションＢの一例）のアカウントとを関連付ける必要がある。第２に、招待利用者とゲームＢにおいて仲間関係にある利用者を特定する必要がある。このような処理は、異なるゲームに跨る処理であるため、アプリケーションサーバ４Ａ及びアプリケーションサーバ４Ｂが単独で実行することはできない。
管理サーバ３は、招待利用者のゲームＡのアカウントとゲームＢのアカウントとを関連付ける関連付処理と、招待される利用者（被招待利用者）の候補を招待利用者に提示する招待処理とを実行する。

＜１−１：関連付処理の概要＞
図２Ａを参照して、関連付処理の概要を説明する。アプリケーションサーバ４Ａ及び４Ｂは利用者がアカウントを登録する際に、ローカル識別情報（以下、LocalIDと称する）を生成する。このLocalIDは、各アプリケーションサーバ４Ａ及び４Ｂのそれぞれにおいて、利用者を一意に識別する識別情報である。したがって、同一利用者であってもLocalIDは異なり互換性がない。
アプリケーションサーバ４Ａ及び４ＢはLocalIDの生成後の任意のタイミングで、管理サーバ３に対してフレンドネットワーク識別情報（以下、FNWIDと称する）の発行を要求する。FNWIDは、アプリケーションシステム１００全体で利用者を識別するための識別情報であって、管理サーバ３が一元的に管理する。但し、管理サーバ３は、アプリケーションサーバ４Ａ及び４ＢからのFNWID発行要求に応じてFNWIDを発行するので、ゲームＡの利用者とゲームＢの利用者とが同一であっても異なるFNWIDを発行する。
アプリケーションサーバ４ＡはゲームＡを利用する複数の利用者のそれぞれを一意に識別するLocalIDをFNWID（第１識別情報の一例）と対応づけて管理し、アプリケーションサーバ４ＢはゲームＢを利用する複数の利用者のそれぞれを一意に識別するLocalIDをFNWID（第２識別情報の一例）と対応づけて管理する。

この例では、ゲームＡをプレイする利用者に対するFNWIDの発行であって、アプリケーションサーバ４ＡからのFNWID発行要求に基づいて発行されるFNWIDをFNWIDaとする。またFNWIDaに対応するLocalIDをLocalIDaとする。また、ゲームＡをプレイする同一の利用者に対するFNWIDの発行であって、ゲームＢに対応したアプリケーションサーバ４ＢからのFNWID発行要求に基づいて発行されるFNWIDをFNWIDbとする。またFNWIDbに対応するLocalIDをLocalIDbとする。また、ゲームＡに対応する種別情報をAppIDaとし、ゲームＢに対応する種別情報をAppIDbとする。FNWIDaは、管理サーバ３、アプリケーションサーバ４Ａ及び端末装置２に保存される。同様に、FNWIDbは、管理サーバ３、アプリケーションサーバ４Ｂ及び端末装置２に保存される。また、LocalIDaはアプリケーションサーバ４Ａに、LocalIDbはアプリケーションサーバ４Ｂに保存される。但し、FNWIDaとFNWIDbとが発行された状態では、両者が同一の利用者に対して発行された識別情報であることは、管理サーバ３において把握できていない。

ここで、FNWIDaにFNWIDbを関連付ける関連付処理において、管理サーバ３はFNWIDaに対応づけたトークンTx（識別子）を発行し、アプリケーションサーバ４Ａに送信する（Ｓ１）。アプリケーションサーバ４Ａは受信したトークンTxをFNWIDaに対応する端末装置２のゲームＡに送信する（Ｓ２）。なお、管理サーバ３からアプリケーションサーバ４ＡにトークンTxを送信する（Ｓ１）タイミングと、アプリケーションサーバ４Ａから端末装置２にトークンTxを送信する（Ｓ２）タイミングとは連動していなくてもよい。例えば、端末装置２から要求に応じてアプリケーションサーバ４ＡからトークンTxを端末装置２に送信するようにしてもよい。
次に、端末装置２では、FNWIDaに対応するゲームＡからFNWIDbに対応するゲームＢにトークンTxが引き渡される（Ｓ３）。引き渡されたトークンTxとFNWIDbは、ゲームＢからアプリケーションサーバ４Ｂに送信される（Ｓ４）。アプリケーションサーバ４Ｂは、FNWIDbとトークンTxを管理サーバ３に送信する（Ｓ５）。ここで、ゲームＡからゲームＢにトークンTxを引き渡す処理において（Ｓ３）、端末装置２の記憶装置２３（図８参照）の所定の領域（アプリケーション共有エリア）を介在するようにしてもよい。

このように、管理サーバ３においてFNWIDaと対応づけて発行したトークンTxは、アプリケーションサーバ４Ａ→端末装置２のゲームＡ→端末装置２のゲームＢ→アプリケーションサーバ４Ｂ→管理サーバ３といった経路で転送され、FNWIDbと対応づけて受信される。管理サーバ３では、既に発行したトークンを検索し、受信したトークンと一致するトークンがある場合には、受信したトークンに対応づけられたFNWIDと発行したトークンに対応づけられたFNWIDとを紐付けする。この例では、受信したトークンはTxであり、これに対応づけられたFNWIDはFNWIDbである。そして、受信したトークンTxと一致するトークンはFNWIDaと対応づけられている。したがって、管理サーバ３は、FNWIDaとFNWIDbとを紐付けることができる。例えば、FNWIDaとFNWIDbとに共通の参照識別情報（以下、RefIDと称する）を発行する。ここで、FNWIDa及びFNWIDbに共通のRefIDをRefIDxとすれば、図２Ａに示すようにFNWIDa及びFNWIDbにRefIDxを対応づけて記憶するようにしてFNWIDaとFNWIDbとを紐付ける。

上述した関連付処理に関し、図１に示す管理サーバ３は、ゲームＡ（第１アプリケーションの一例）を提供するアプリケーションサーバ４Ａ（第１アプリケーション装置の一例）及びゲームＢ（第２アプリケーションの一例）を提供するアプリケーションサーバ４Ｂ（第２アプリケーション装置の一例）を含む複数のアプリケーションサーバと通信可能であり、ゲームＡを利用する複数の利用者のそれぞれを一意に識別するFNWIDa（第１識別情報）及びゲームＢを利用する複数の利用者のそれぞれを一意に識別するFNWIDb（第２識別情報）を発行して管理する。
さらに、管理サーバ３は、アプリケーションサーバ４Ａに対して利用者のFNWIDaに関連付けられたトークン（識別子の一例）を発行する発行部１１と、ゲームＡ及びゲームＢを利用可能な端末装置２において、ゲームＡからゲームＢに引き渡されたトークンを、アプリケーションサーバ４Ｂから受領する受領部１２と、発行部１１で発行したトークンと受領部１２で受領したトークンとが合致するFNWIDaとFNWIDbとを関連付けて管理する管理部１３とを備える。なお、この管理サーバ３が招待処理を実行する場合は、ここでの利用者はゲームＡに招待を行う招待利用者となる。

ここで、ゲームはアプリケーションの一例である。また、受領部１２は、ゲームＡからゲームＢに引き渡されたトークンを受領するが、その経路は問わない。例えば、トークンを端末装置２から直接的に受領してもよいし、アプリケーションサーバ４Ｂ（第２アプリケーション装置）を介して間接的に受領してもよい。また、トークンをゲームＡからゲームＢに引き渡す契機として利用者の操作に基づいたり、ゲームＡの自動的な処理に基づいたり、ゲームＡによって起動される端末装置で動作するプログラム処理に基づくものでもよい。また、トークンは、発行部で発行したものと受領部で受領したものとの一致が確認できる情報であれば、その生成方法や情報の中身は問わず、例えば、一意な英数字を組み合わせた文字列である。

一方、端末装置２は、利用可能なゲーム（アプリケーションの一例）ごとにFNWID（識別情報の一例）を記憶する記憶部２０５を備える。さらに端末装置２は、利用中のゲームＡのFNWIDaに対応づけられており管理サーバ３で発行されたトークンを取得する取得部２０７を備える。さらに端末装置２は、取得部２０７で取得したトークンとゲームＢのFNWIDbとの組を所定の経路で管理サーバ３に通知する識別子通知部２０８を備える。例えば、端末装置２の記憶部２０５は、ゲームＡのFNWIDaとゲームＢのFNWIDbを記憶している。端末装置２において、ゲームＡの利用中にゲームＢが選択されると、取得部２０７は、利用中のゲームＡについて招待利用者を識別するFNWIDaに対応づけられており管理サーバ３の発行部１１で発行されたトークンを取得する。そして、識別子通知部２０８は、取得部２０７で取得したトークンとゲームＢのFNWIDbとの組を所定の経路で管理サーバ３に通知する。

これにより、管理サーバ３に対して利用者が管理するアカウントを新たに設けなくても、管理サーバ３は、所定の経路でトークンを一巡させることによって、独立して運用されるアプリケーションサーバ４Ａのアカウントとアプリケーションサーバ４Ｂのアカウントとを紐付けて管理することができる。つまり、利用者は、管理サーバ３の存在を意識する必要がない。このように同一の利用者の異なるゲームのアカウントを紐付けることで、複数のゲームに関係する相互サービスを利用者に提供することが可能になる。例えば、相互サービスとして、一方のゲーム画面に他方のゲームにおける仲間リストを表示することが可能になる。仲間リストを表示することが可能になれば、他のゲームの仲間を、現在利用しているゲームに招待するような相互サービスが可能になる。上述したように関連付処理は、利用者の端末装置２において他のゲームが選択された場合に実行される。仮に、全ての利用者について他のゲームの選択とは無関係に、関連付処理を随時実行するとすれば、管理サーバ３の処理負荷が増大するが、本実施形態のように他のゲームが選択されるような所定の処理が発生したタイミングで関連付処理を実行すれば効率良く紐付けができるようになり、管理サーバ３の処理負荷を軽減することができる。なお、関連付処理の実行の契機を、他のゲームの選択後でなく、他のゲームの選択前としてもよい。つまり、当該利用者から複数のFNWIDを関連付けるための関連付処理の要求があったときに、同処理を実行するようにしてもよい。このように所定の処理が発生したタイミングで関連付処理が行われるようにすれば、同一利用者が複数のFNWIDを有している場合に全てのFNWIDの組について関連付処理を行う場合と比較して、管理サーバ３の処理負荷を軽減することができる。

そして、管理サーバ３の管理部１３は、複数のゲームのそれぞれの利用者の特定の関係を示す仲間リスト（関係情報の一例）を、複数のアプリケーションサーバ４のそれぞれから取得して管理する。これにより、複数のアプリケーションサーバ４のそれぞれで管理している仲間リストを管理サーバ３で一元管理することができる。
ここで、複数のアプリケーションサーバ４（アプリケーション装置の一例）のそれぞれが提供するゲーム（アプリケーションの一例）は、当該ゲーム内での他の利用者と特定の関係が形成されるものである。この特定の関係には、例えば、アプリケーションがゲームである場合、ある利用者がゲームを進める際に協力し合える仲間関係が含まれる。ゲームに協力するとは、仲間と一緒になってゲームを進めたり、仲間のゲーム能力値などのゲームデータを利用可能にすることであったりする。また、特定の関係には、仲間関係になることを拒否したブロック関係、あるいは、ある利用者が他の利用者をライバルとして認識し、他の利用者の受諾を必要としないライバル関係が含まれてもよい。また、アプリケーションがチャットのようなコミニケーションアプリでは、チャット相手が特定の関係に相当する。

また、管理サーバ３は、ゲームＡ（第１アプリケーションの一例）を利用する利用者の端末装置２からFNWIDb（第２識別情報の一例）に対応付けられた仲間関係を示す仲間リスト（関係情報の一例）の仲間リスト要求（取得要求の一例）を受け付ける受付部１４と、仲間リスト要求を送信した当該端末装置２またはアプリケーションサーバ４Ａ（第１アプリケーション装置の一例）にFNWIDbに対応付けられた仲間リストを通知する通知部１５とを備える。ここで、通知部１５がアプリケーションサーバ４Ａに対して仲間リストを通知する場合には、アプリケーションサーバ４Ａから利用者の端末装置２に対して仲間リストが通知される。換言すれば、通知部１５は、FNWIDbに対応付けられた仲間リストを直接的または間接的に端末装置２に通知する。
これにより、ゲームＡとゲームＢを利用する利用者の端末装置２は、ゲームＡにおいてゲームＢでの仲間リストを取得できる。つまり、あるゲームにおいて他のゲームの仲間リストを取得することが可能になる。例えば、アカウントに互換性がないゲーム間であっても、あるゲームからの操作に基づいて、他のゲームで仲間関係にある利用者に対して情報通知を行うことが可能となる。情報通知の対象となる情報として、メッセージ情報や、後述する招待情報が例示できる。この管理サーバ３が招待処理を実行する場合は、ゲームＡを利用する招待利用者の端末装置２は、招待を受けるゲームＢにおいて仲間リストを取得できる。取得された仲間リストの利用者は、ゲームＡに招待される被招待利用者の候補となる。

さらに、管理サーバ３は、通知部１５で通知した仲間リストの中から招待利用者が選択した被招待利用者に対するゲームＡの招待要求を受け付けた招待要求を蓄積して管理する招待情報管理部１６（蓄積部の一例）を備える。これにより、誰が誰をどのゲーム（アプリケーションの一例）に招待したかを管理サーバ３で一元的に管理することが可能となる。

次に、図２Ｂに招待要求の照会についての処理の概要を示す。被招待利用者の端末装置２において照会部２０１は、アプリケーションシステム１００で提供される複数のアプリケーションであるゲームＡ、ゲームＢ、ゲームＣ…のうち当該端末装置２で利用中のゲームから、管理サーバ３の招待情報管理部１６にゲームへの招待の有無に関する照会をする。
例えば、アプリケーションシステム１００が、ゲームＡ、ゲームＢ、ゲームＣ、及びゲームＤを提供し、被招待利用者の端末装置２においてゲームＢが利用可能であるならば、ゲームＢから招待の有無を照会する。具体的には、招待問い合わせ要求を管理サーバ３に送信することで招待要求の照会を行い、照会部２０１は当該端末装置２の利用者が被招待利用者となっている招待の有無を招待情報管理部１６に照会する。なお、照会は、当該端末装置２におけるゲームＢの起動を契機に実行することが好ましいが、起動時に照会することが必須ではなく、ゲームＢの利用中であればいつでもよい。例えば、管理サーバ３に対して、何らかの情報を送信する際に、送信すべき情報に照会要求を含ませてもよいし、ゲームＢの利用中になんらかのイベント（例えば、利用者からの操作指示）が発生した際に送信してもよい。

さらに、管理サーバ３の通知部１５は、端末装置２の利用者から招待要求の照会があると、当該端末装置２の利用者が被招待利用者となっている招待要求が招待情報管理部１６（蓄積部の一例）に蓄積されている場合、招待利用者が被招待利用者をゲームＡへ招待することを示す招待情報を端末装置２に通知する。これにより、アカウントに互換性がないゲーム間であっても、あるゲームで仲間関係にある利用者を他のゲームに招待することができる。

一方、端末装置２は、被招待利用者の端末装置２で利用しているゲームＢ（第２アプリケーションの一例）から招待情報を管理する招待情報管理部１６に対して、ゲームＡ（第１アプリケーションの一例）への招待を示す招待情報の有無を照会する照会部２０１と、照会に対応する招待情報を受領する招待情報受領部２０２と、表示部２０３と、招待情報に基づいて招待の内容を表示部２０３に表示させる表示制御部２０４とを備える。これにより、アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…において招待があったことを端末装置２に知らせるといった招待に関する処理を実行しなくても、端末装置２では、あるゲームでの仲間となっている利用者から当該利用者がプレイしている他のゲームへの招待を知ることができる。
ここで、招待情報管理部１６は、アプリケーションシステム１００の内部であれば、どこに設けられてもよく、例えば、管理サーバ３やアプリケーションサーバ４Ａ、４Ｂ、４Ｃ…のそれぞれに設けられてもよい。

なお、ゲーム（アプリケーション）の状態の一例として、非動作状態（Not running）と、何らかの処理を実行している通常動作状態（Active）と、何らかの処理を実行しているが画面に非表示とするバックグラウンド状態（BackGround）と、いずれの処理も実行せずに中断しているサスペンド状態（Suspended）がある。ここで、「ゲームの起動」とは、非動作状態（Not running）、サスペンド状態（Suspended）、またはサスペンド状態（Suspended）から通常動作状態（Active）に移行することをいう。また、「ゲームの終了」とは、通常動作状態（Active）から、非動作状態（Not running）、サスペンド状態（Suspended）、またはサスペンド状態（Suspended）に移行することをいう。また、複数のゲーム（アプリケーション）が同時に通常動作状態に成り得る場合には、「ゲームの起動」とは、例えば、ゲームが画面の最前面に表示されるなどして、利用者に対して操作可能な状態に移行することをいう。また、ゲーム（アプリケーション）での、LocalIDの生成は、ゲームを初めて起動したときやチュートリアルが終了した任意のタイミングで行われる。
また、ゲーム（アプリケーション）のインストールとは、端末装置２に導入されていないゲームのプログラムを新規に導入することだけでなく、アプリケーションシステム１００に対応するようにゲームのプログラムをアップデート（更新）することを含む。すなわち、端末装置２に搭載しているゲームに対して、アプリケーションシステム１００に対応するための更新プログラムをダウンロードして更新することを含む。

＜１−２：管理サーバ３の構成＞
図３に管理サーバ３の構成を示す。この図に示すように、管理サーバ３は、装置全体を制御するＣＰＵ（Central Processing Unit）３０、ＣＰＵ３０の作業領域として機能するＲＡＭ（Random Access Memory）３１、ブートプログラムなどを記憶したＲＯＭ（Read Only Memory）３２、各種のプログラムやデータを記憶するハードディスク３３、キーボードやマウスなどを含む入力部３４、画像を表示するディスプレイ３５、通信網ＮＥＴを介して外部の装置と通信を行う通信インターフェース３６、及びコンパクトディスクなどの情報記録媒体を読み取る読取装置３７を備える。ハードディスク３３には、利用者情報テーブルＴＢＬ１１、ＩＤ管理テーブルＴＢＬ１２、仲間関係テーブルＴＢＬ１３、及びインバイトテーブルＴＢＬ１４などが記憶されている。また、ＣＰＵ３０が各種のプログラムを実行することによって、ＣＰＵ３０は、発行部１１、受領部１２、管理部１３、受付部１４、通知部１５および招待情報管理部１６として機能する。すなわち、各種のプログラムは、ＣＰＵ３０（コンピュータ）を有する管理サーバ３を制御する。

図４に利用者情報テーブルＴＢＬ１１のデータ構造を示す。利用者情報テーブルＴＢＬ１１には複数のレコードが記録されている。１つのレコードは、レコードを一意に識別するレコード識別情報ID、アプリケーションの種別を示す種別情報AppID（以下、AppIDと称する）、利用者のニックネーム、FNWID、トークン、及びトークンを発行した日を示すトークン発行日とを含む。例えば、ID＝１のレコードは、FNWIDが「XCV56714」であり、これに対応づけられてトークン「56844SAS」が「2012/3/28」に発行されている。トークン発行日は、発行したトークンに有効期限を設ける場合に用いることができる。つまり、図１に示すように各アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…は、上述したデータ構造からなる利用者情報テーブルＴＢＬ１１Ａ、ＴＢＬ１１Ｂ、ＴＢＬ１１Ｃ…を備える。

図５に、ＩＤ管理テーブルＴＢＬ１２のデータ構造を示す。ＩＤ管理テーブルＴＢＬ１２には複数のレコードが記録されている。１つのレコードは、レコードを一意に識別するレコード識別情報ID、RefID、及びFNWIDを含む。FNWIDは、各アプリケーションサーバ４Ａ、４Ｂ、４Ｃ、…においてアカウントが登録される際に発行される。これに対して、RefIDは、関連付処理において、あるゲームのアカウントと他のゲームのアカウントとが同一の利用者に属することが判明された場合に発行される。この例では、ID＝１及びID＝2のレコードは、フレンドネットワーク識別情報FNWIDが「XCV56714」と「REK35460」であり相違するが、RefIDはともに「00000011」である。したがって、「XCV56714」と「REK35460」とは、同一の利用者に属するフレンドネットワーク識別情報FNWIDである。

図６に仲間関係テーブルＴＢＬ１３のデータ構造を示す。仲間関係テーブルＴＢＬ１３には複数のレコードが記録されている。１つのレコードは、レコード識別情報ID、AppID、関係の種別を示すグループ情報Group、仲間申請元の利用者のLocalIDである仲間申請元ローカル識別情報LocalID_From（以下、LocalID_Fromと称する）、仲間申請先の利用者のLocalIDである仲間申請先ローカル識別情報LocalID_To（以下、LocalID_Toと称する）、仲間申請元の利用者のFNWIDである仲間申請元フレンドネットワーク識別情報FNWID_From（以下、FNWID_Fromと称する）、仲間申請先のFNWIDである仲間申請先フレンドネットワーク識別情報FNWID_To（以下、FNWID_Toと称する）、及び仲間申請の状態を示す状態情報Statが対応づけられて記憶される。

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

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

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

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

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

また、図１に示すように各アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…は、仲間関係テーブルＴＢＬ１３Ａ、ＴＢＬ１３Ｂ、ＴＢＬ１３Ｃ…を備えている。各仲間関係テーブルＴＢＬ１３Ａ、ＴＢＬ１３Ｂ、ＴＢＬ１３Ｃ…は、ゲームごとに仲間関係を記憶しており、そのレコードは、レコード識別情報ID、グループ情報Group、LocalID_From、LocalID_To、FNWID_From、FNWID_To、及び仲間申請の状態を示す状態情報Statを対応づけて記憶している。そして、各アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…において、仲間関係に変更があり、各仲間関係テーブルＴＢＬ１３Ａ、ＴＢＬ１３Ｂ、ＴＢＬ１３Ｃ…の記憶内容が変更されると、アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…から変更通知が管理サーバ３に送信され、仲間関係の変更が仲間関係テーブルＴＢＬ１３に反映され、記憶内容が同期されるようになっている。

図７にインバイトテーブルＴＢＬ１４のデータ構造を示す。インバイトテーブルＴＢＬ１４には複数のレコードが記録されている。１つのレコードは、レコード識別情報ID、招待ゲームの種別情報InviteAppID（以下、InviteAppIDと称する）、招待利用者に対応するフレンドネットワーク識別情報InviteFNWID_From（以下、InviteFNWID_Fromと称する）、被招待利用者に対応するフレンドネットワーク識別情報InviteFNWID_To（以下、InviteFNWID_Toと称する）、被招待ゲームにおける招待利用者のニックネームを含む。インバイトテーブルＴＢＬ１４を参照することによって、ある利用者が被招待者として招待を受けているゲームがあることを知ることができる。

＜１−３：端末装置２の構成＞
図８に端末装置２の構成を示す。端末装置２は、利用者に互いに異なるゲーム等のアプリケーションを提供する複数のアプリケーションサーバ４（アプリケーション装置の一例）のそれぞれに対して利用者を一意に識別する識別情報（FNWID）を発行して管理し、同一の利用者について複数のアプリケーションサーバ４のそれぞれに対応する識別情報を紐付けて管理する管理サーバ３（管理装置の一例）と共に、アプリケーションシステム１００を構成する。なお、アプリケーションシステム１００を構成する装置、例えば管理サーバ３に、ゲームＢ（第２アプリケーションの一例）において招待利用者と特定の関係がある被招待利用者に対して招待利用者が利用しているゲームＡ（第１アプリケーションの一例）に招待する招待情報を管理する招待情報管理部１６を有する。
端末装置２は、装置全体を制御するＣＰＵ２０、ＣＰＵ２０の作業領域として機能するＲＡＭ２１、ブートプログラムなどを記憶したＲＯＭ２２、各種のプログラムやデータを記憶する記憶装置２３、テンキーやタッチキーなどを含む入力部２４、画像を表示するディスプレイ２５、及び通信網ＮＥＴを介して外部の装置と通信を行う通信インターフェース２６を備える。記憶装置２３には、ゲームなどの各種のアプリケーション、当該端末装置２で利用可能な各アプリケーションに対応するFNWID、及び装置全体を制御する制御プログラムが記憶される。
記憶装置２３は図１に示す記憶部２０５に相当し、ディスプレイ２５は表示部２０３に相当する。また、ＣＰＵ２０が制御プログラムを実行することによって、ＣＰＵ２０は、照会部２０１、招待情報受領部２０２、、表示制御部２０４、選択部２０６、取得部２０７、識別子通知部２０８、及び招待要求送信部２０９として機能する。すなわち、制御プログラムは、ＣＰＵ２０（コンピュータ）とディスプレイ２５を有する端末装置を制御する。

また、端末装置２にインストールされたアプリケーションがアプリケーションシステム１００に対応している場合には、このアプリケーションのプログラムに、ＳＤＫ（Software Development Kit）のプログラムを組み込むようにしてもよい。このＳＤＫは、例えば、端末装置２にインストールされたアプリケーションと管理サーバ３とを仲介するためのＡＰＩ（Application Programming Interface）の集合体で構成されており、ＳＤＫが組み込まれたアプリケーションを端末装置２で実行することにより、端末装置２を、被招待利用者の端末装置２で利用しているゲームＢ（第２アプリケーションの一例）から管理サーバ３の招待情報管理部１６に対して、ゲームＡ（第１アプリケーションの一例）への招待を示す招待情報の有無を照会する照会部２０１と、照会に対応する招待情報を受領する招待情報受領部２０２と、招待情報に基づいて招待の内容を表示部２０３に表示させる表示制御部２０４としての機能させることが可能となる。つまりＳＤＫを、ＣＰＵ２０（コンピュータ）とディスプレイ２５（表示部の一例）を有する端末装置にインストールされるゲームＡやゲームＢの制御プログラムに組み込まれるプログラムとして捉えることができる。
また、端末装置２は、照会部２０１、招待情報受領部２０２、及び表示制御部２０４とを含んで構成されると捉えることができる。なお、招待情報管理部１６は管理サーバ３に設けられており、照会部２０１は、管理サーバ３の招待情報管理部１６に招待情報の有無を照会する。
これにより、アカウントに互換性がないゲーム間で、招待しようとする利用者がプレイしているゲーム（例えばゲームＡ）に、他のゲーム（例えばゲームＢ）での仲間を招待できるようにして、招待される利用者が招待ゲームへの招待を知ることができる。換言すれば、あるゲーム（例えばゲームＢ）での仲間となっている利用者から当該利用者がプレイしている他のゲーム（例えばゲームＡ）への招待を知ることができる。

さらに、ＳＤＫが組み込まれたアプリケーションが、端末装置２において実行されたときに、当該端末装置２を、招待利用者の端末装置２で利用しているゲームＡにおいて、ゲームＢを選択可能な選択部２０６と、ゲームＡに対応する招待利用者を識別する識別情報に対応づけられており管理サーバ３（管理装置の一例）で発行されたトークン（識別子の一例）を取得する取得部２０７と、取得部２０７で取得したトークンと選択部２０６で選択されたゲームＢに対応する招待利用者の識別情報との組を所定の経路で管理サーバ３に通知する識別子通知部２０８として、機能させることが可能なように構成してもよい。また、端末装置２は、選択部２０６、取得部２０７、及び識別子通知部２０８をさらに含んで構成されると捉えることができる。これにより、管理サーバ３で同一の端末装置２で動作する異なるゲームのアカウントを紐付けることが可能になる。

端末装置２にインストールされているアプリケーションがアプリケーションシステム１００に対応していないバージョンである場合、ＳＤＫが組み込まれたバージョンのアプリケーションがダウンロード可能であれば、端末装置２にインストールされているアプリケーションのプログラムのバージョンを更新することにより、アプリケーションシステム１００に対応可能になる。つまり、アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…側のアプリケーションプログラムは、ＳＤＫを組み込み可能なように構成されている。
ここで、ＳＤＫの提供者は、例えば、管理サーバ３を管理する事業者である。この場合、アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…のサービス提供者は、管理サーバ３を管理する事業者によって提供されたＳＤＫのプログラムをゲームＡ、ゲームＢ、ゲームＣ…のアプリケーションプログラムに組み込んで、利用者の端末装置２に提供する。

＜２．アプリケーションシステムの動作＞
アプリケーションシステム１００の動作を、１）FNWIDの取得処理、２）仲間関係の同期処理、３）招待処理に分けて説明する。

＜２−１：FNWIDの取得処理＞
図９にFNWIDの取得処理の内容を示す。この例では、利用者がアプリケーションサーバ４ＡからゲームＡのプログラムを取得し、これに伴ってFNWIDaが取得されるものとする。
まず、利用者が端末装置２を操作して、ゲームＡのダウンロードサイトにアクセスしてゲームＡのダウンロードを選択すると、端末装置２は、アプリケーションサーバ４Ａに対してダウンロード要求を送信する。アプリケーションサーバ４Ａは、ダウンロード要求を受信すると、ゲームＡのプログラムを含むダウンロード応答を端末装置２に送信する。なお、ダウンロードサイトは第３者が運営するサーバであってもよい。

次に、利用者がゲームＡを起動すると、端末装置２のゲームＡが管理する記憶領域を参照して登録情報が記憶されているか否かに基づいて初回起動かを判断する。登録情報が記憶されておらず初回起動であると判断した場合には、利用者にニックネームを入力させる画面を端末装置２に表示させる。利用者が端末装置２を操作してニックネームを入力すると、端末装置２はニックネームを含む登録要求をアプリケーションサーバ４Ａに送信する。登録要求をアプリケーションサーバ４Ａが受信すると、アプリケーションサーバ４Ａは、ローカル識別情報LocalIDaを生成し、ニックネーム及びローカル識別情報LocalIDaを利用者情報テーブルＴＢＬ１１Ａに記憶して、アカウントの登録を実行する。

次に、生成されたローカル識別情報LocalIDa又はローカル識別情報LocalIDaに対応付けられた識別情報を端末装置２に通知する。端末装置２は、アプリケーションサーバ４Ａから通知されたローカル識別情報LocalIDa又はローカル識別情報LocalIDaに対応付けられた識別情報を受信し、ゲームＡが管理する記憶領域に登録情報としてニックネームと関連付けて記憶する。この後にアプリケーションサーバ４Ａと通信を行う場合には、端末装置２に登録情報として記憶されたローカル識別情報LocalIDa又はローカル識別情報LocalIDaに対応付けられた識別情報を含めることで、アプリケーションサーバ４Ａは利用者を特定することが可能となる。端末装置２に通知する識別情報として、ローカル識別情報LocalIDaの替わりにローカル識別情報LocalIDaに対応付けられた識別情報を利用する場合には、当該識別情報をローカル識別情報LocalIDaに関連付けて利用者情報テーブルＴＢＬ１１Ａに記憶するようにする。

この後、アプリケーションサーバ４ＡはFNWID発行要求を管理サーバ３に送信する。FNWID発行要求を受信した管理サーバ３は、利用者を一意に特定するFNWIDaを発行し、発行したFNWIDaを含むFNWID発行応答をアプリケーションサーバ４Ａに返信する。FNWID発行応答をアプリケーションサーバ４Ａが受信すると、ローカル識別情報LocalIDaに関連付けてFNWIDaを利用者情報テーブルＴＢＬ１１Ａに記憶する。

次に、アプリケーションサーバ４Ａは、ニックネーム及びFNWIDaを含むニックネーム通知を管理サーバ３に送信する。管理サーバ３はニックネーム通知を受信すると、ニックネームをFNWIDaに関連付けて記憶する。また、アプリケーションサーバ４Ａは、FNWIDaを端末装置２に送信する。端末装置２はFNWIDaを受信すると、ゲームＡが管理する記憶領域に記憶された登録情報にFNWIDaを追加して記憶する。

上記の例では、利用者のアカウントとしてのローカル識別情報LocalIDaをアプリケーションサーバ４Ａが生成するようにしたが、利用者にユニークな英数字を入力させるようにしたりメールアドレスをアカウントとして用いたりするようにしてもよい。
このようにして、利用者が端末装置２にゲームＡのプログラムをダウンロードし、これを利用者が起動すると、ゲームＡの起動を契機として、FNWIDaが管理サーバ３において発行され、発行されたFNWIDaが、管理サーバ３、アプリケーションサーバ４Ａ及び端末装置２において保存される。この場合、端末装置２の利用者は、アプリケーションサーバ４Ａに対してアカウントを設定するだけで、管理サーバ３に対して利用者が管理する管理アカウントを新たに設ける必要はない。

＜２−２：仲間関係の同期処理＞
次に、図１０に仲間関係の同期処理の内容を示す。アプリケーションサーバ４Ａにおいて、仲間関係に変更があり、仲間関係テーブルＴＢＬ１３Ａの記憶内容が変更されると、アプリケーションサーバ４Ａは変更通知を管理サーバ３に送信する。変更通知には仲間関係テーブルＴＢＬ１３Ａの変更内容が含まれている。例えば、アプリケーションサーバ４Ａは、変更のあったレコードを変更通知に含ませて送信してもよい。管理サーバ３は、変更通知を受信すると、仲間関係の変更内容を仲間関係テーブルＴＢＬ１３に反映させ、記憶内容を更新する。
このように、各アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…で管理する仲間関係は、管理サーバ３において一元的に把握される。

＜２−３：招待処理＞
図１１に招待処理の内容を示す。この例では、ゲームＡとゲームＢの両方をプレイしている招待利用者が、ゲームＢで仲間となっている他の利用者を被招待利用者としてゲームＡに招待するものとする。招待利用者のゲームＡに関するFNWIDをFNWIDaとし、ゲームＢに関するFNWIDをFNWIDbとする。さらに、招待利用者の端末装置の符号を「２ａ」とし、被招待利用者の端末装置の符号を「２ｂ」とする。

まず、招待利用者が端末装置２ａを操作して、ゲームＡを起動し、他のゲームでの仲間をゲームＡに招待するための招待ページを選択すると、端末装置２ａはトークン要求をアプリケーションサーバ４Ａに送信する。トークン要求を受信したアプリケーションサーバ４Ａは、端末装置２ａの招待利用者に対応するFNWIDaを取得する。例えば、トークン要求にFNWIDaが含まれる場合には、トークン要求に含まれるFNWIDaを取得すればよい。あるいは、トークン要求にローカル識別情報LocalIDa又はニックネームが含まれるのであれば、アプリケーションサーバ４Ａは利用者情報テーブルＴＢＬ１１Ａを参照して、ローカル識別情報LocalIDa又はニックネームに対応するFNWIDaを取得すればよい。

次に、アプリケーションサーバ４Ａは、取得したFNWIDaを含むトークン発行要求を管理サーバ３に送信する。トークン発行要求を受信した管理サーバ３は、トークンを発行し、発行したトークンをトークン発行要求に含まれるFNWIDaと対応づけて、利用者情報テーブルＴＢＬ１１に記憶する。例えば、FNWIDaが「XCV56714」であり、トークンが「56844SAS」であるとすれば、図４に示すように「XCV56714」と対応づけられて「56844SAS」が利用者情報テーブルＴＢＬ１１に記憶される。

この後、管理サーバ３は、発行したトークンを含むトークン発行応答をアプリケーションサーバ４Ａに送信する。トーク発行応答を受信したアプリケーションサーバ４Ａは、トークンを含むトークン応答を端末装置２ａに送信する。なお、アプリケーションサーバ４Ａは、管理サーバ３から、アプリケーションシステム１００に参加している他のアプリケーションサーバ４Ｂ、４Ｃ…が提供するゲームＢ、ゲームＣ…の内容を示すアプリケーション情報を予め取得している。そして、アプリケーションサーバ４Ａは、取得したアプリケーション情報を端末装置２ａに送信する。

端末装置２ａは、アプリケーション情報を受信すると、ディスプレイ２５にアプリケーション情報に基づいて１又は複数のゲームを利用者が選択可能なような招待ページを表示する。ここで、招待利用者が招待の対象となる被招待ゲーム（本実施例では、ゲームＢ）を選択すると、被招待ゲームが起動する。
なお、当該端末装置２ａにおいて選択された被招待ゲームがインストールされていなかったり、アンインストールされたりして起動不能の場合には、ディスプレイ２５に処理できない旨が表示される。被招待ゲームであるゲームＢが起動して、ゲームＡからトークンがゲームＢに引き渡されると、ゲームＢのFNWIDであるFNWIDbと引き渡されたトークンをアプリケーションサーバ４Ｂに通知する。なお、端末装置２ａにインストールされているゲームを特定して、当該ゲームだけが選択可能なような招待ページをディスプレイ２５に表示するようにしてもよい。

アプリケーションサーバ４Ｂは、FNWIDb及びトークンを受信すると、これを管理サーバ３に通知する。FNWIDb及びトークンを受信した管理サーバ３は、受領したトークンと発行したトークンが一致するかを判定する。例えば、利用者情報テーブルＴＢＬ１１を検索し、受領したトークンと一致する発行したトークンが有るか否かを判定する。なお、この判定において、トークンの発行日時を参照し、有効期限が過ぎたトークンについては、無効としてもよい。

この例では、受領したトークンと発行したトークンが一致するものとする。この場合、管理サーバ３は、FNWIDaとFNWIDbとを紐付ける。例えば、ＩＤ管理テーブルＴＢＬ１２に、FNWIDaとFNWIDbとに同一のRefIDを記憶する。例えば、FNWIDaが「XCV56714」であり、FNWIDbが「REK35460」である場合には、図５に示すように「00000011」が同一のRefIDとして、ＩＤ管理テーブルＴＢＬ１２に記憶される。

この後、端末装置２ａのゲームＡから仲間リスト要求が管理サーバ３に送信される。仲間リスト要求には、招待ゲームがゲームＡであることを示す種別情報AppIDと招待利用者のFNWIDaとが含まれている。仲間リスト要求を管理サーバ３が受信すると、管理サーバ３は、ゲームＢで招待利用者と仲間関係にある利用者を被招待利用者の候補として抽出する。

具体的には、管理サーバ３のＣＰＵ３０は、ＩＤ管理テーブルＴＢＬ１２を参照し、招待利用者のFNWIDaに対応するRefIDを取得し、さらに、同じRefIDと対応するゲームＢにおける招待利用者のFNWIDbを抽出する。例えば、図５に示す例において、FNWIDaが「XCV56714」である場合、「XCV56714」と対応づけられているRefIDは「00000011」であるので、ＣＰＵ３０は、FNWIDaに対応するRefIDとして「00000011」を取得する。さらに、ＣＰＵ３０は、RefIDが「00000011」となっている他のFNWIDを抽出する。この例では、「REK35460」（上述したFNWIDb）が抽出される。抽出されたFNWIDbは、招待利用者がプレイしている他のゲームのFNWIDである。抽出されたFNWIDbは、利用者情報テーブルＴＢＬ１１における、対応するAppIDを参照すれば、ゲームＢのFNWIDであることが特定できる。即ち、上述した関連付処理を実行することによって、招待利用者が招待しようとしているゲームＡとは別のゲーム（ゲームＢ）におけるFNWID（この例では、FNWIDb＝REK35460）を特定することが可能となる。

次に、ＣＰＵ３０は、仲間関係テーブルＴＢＬ１３を参照して、招待利用者が招待しようとするゲームＡ以外のゲーム（この例ではゲームＢ）の仲間を特定する。より具体的には、招待したい仲間がいるゲームＢを示すAppIDを有し、且つ、招待利用者のFNWIDbとFNWID_Fromとが一致するレコードからFNWID_Toを抽出して得られたFNWIDと、ゲームＢを示すAppIDを有し、且つ、FNWIDbとFNWID_Toとが一致するレコードからFNWID_Fromを抽出して得られたFNWIDを合わせたものが、被招待ゲーム（ゲームＢ）での仲間を示す。よって、抽出されたFNWIDはゲームＢに対応する仲間のFNWIDbである。
なお、この場合において、抽出した各FNWIDと同じレコードにおける状態情報Statを参照して、状態が仲間申請中「0」及び拒否「2」になっているFNWIDを抽出結果から除外する。ただし、仲間申請中「0」は仲間になる可能性があるため、抽出結果から除外しないようにしてもよい。

次に、ＣＰＵ３０は、抽出したFNWIDb（以下、「第１のFNWID」と称する）の中から、ゲームＡに対応したFNWID（以下、「第２のFNWID」と称する）が紐づけられていないものを、「候補の被招待利用者」のFNWIDとして特定する。被招待ゲームにおける仲間が招待ゲーム（ゲームＡ）をすでに利用していることが明らかな場合には、その仲間を候補の被招待利用者から除外するためである。
具体的には、ＣＰＵ３０は、第１に、ＩＤ管理テーブルＴＢＬ１２を参照して、抽出した第１のFNWIDそれぞれについて、対応するRefIDを特定する（第１の処理）。この第１の処理において、ＩＤ管理テーブルＴＢＬ１２を参照しても第１のFNWIDを有するレコードが存在しない場合がある。この場合には、ＣＰＵ３０は対応するRefIDを特定できないので、後述の第２及び第３の処理に進むことなく、当該第１のFNWIDを候補の被招待利用者のFNWIDとする。

第２に、ＣＰＵ３０は、このRefIDに基づいて、第２のFNWIDを特定する（第２の処理）。つまり、同一のRefIDを有する第２のFNWIDを特定する。第３に、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照し、第２のFNWIDがゲームＡに対応したFNWIDか否かを判定する（第３の処理）。つまり、第２のFNWIDを有するレコードにおいて、対応するAppIDがゲームＡを示すものか否かを判定する。この判定の結果、第２のFNWIDがゲームＡに対応したFNWIDでない場合、すなわち、ゲームＡ以外のゲームに対応するFNWIDである場合、この第２のFNWIDに対応する第１のFNWIDを、候補の被招待利用者のFNWIDとする。一方、上記判定の結果、第２のFNWIDがゲームＡに対応したFNWIDである場合には、候補の被招待利用者から除外する。
次に、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、候補の被招待利用者のFNWIDと、当該候補の被招待利用者のFNWIDに対応する招待したいゲーム（ゲームＢ）におけるニックネームと、AppID（ゲームＢを示すAppIDb）の組を含む仲間リストを生成する。管理サーバ３は端末装置２ａに対して仲間リストを含む仲間リスト応答を送信する。

端末装置２ａが、仲間リスト応答を受信すると、端末装置２ａのディスプレイ２５に仲間（候補の被招待利用者）のニックネームがゲーム名ごとに表示される。なお、本実施例では、ゲームＢが被招待ゲームであるため、招待利用者について、ゲームＡにおけるFNWIDaとトークンTxにより関連付けられたFNWIDは、ゲームＢにおけるFNWIDbのみである。このため、ディスプレイ２５に表示される仲間のニックネームは、ゲームＢについてのみとなる。複数の他のゲームを被招待ゲームとする場合には、複数のゲームの各々における仲間を含む仲間リストが生成され、仲間のニックネームがゲーム名ごとに表示されることになる。この場合には、上記関連付処理において、ゲームＡに対応するFNWIDaと、複数の他のゲームのFNWIDとが関連付けられることになる。
そして、招待利用者が端末装置２ａを操作して招待する仲間を選択すると、端末装置２ａは招待情報を含む招待要求を管理サーバ３に送信する（招待要求送信部２０９）。この招待情報には、招待ゲームＡにおける招待利用者のFNWIDaと、招待したい仲間がプレイしている被招待ゲームＢにおける被招待利用者のFNWIDbと、招待ゲームＡのAppIDとが含まれている。この際、複数の仲間を選択することも可能である。

次に、管理サーバ３が招待要求を受信すると招待情報を含むレコードをインバイトテーブルＴＢＬ１４に記憶する。上述したように、インバイトテーブルＴＢＬ１４における各レコードは、InviteAppID、InviteFNWID_From、InviteFNWID_To、被招待ゲームにおける招待利用者のニックネームを含む。この例では、被招待利用者のFNWIDがFNWIDbであり、被招待利用者はゲームＢにおいて招待利用者と仲間関係にあるものとする。よって、インバイトテーブルＴＢＬ１４における各レコードにおいては、InviteAppIDがゲームＡのAppIDaとなり、InviteFNWID_Fromが招待利用者のFNWIDaとなり、InviteFNWID_Toが被招待利用者のFNWIDbとなる。ＣＰＵ３０は、招待利用者と被招待利用者とが仲間関係にあるゲームＢにおける招待利用者のニックネームを取得する。具体的には、第１に、ＣＰＵ３０は、招待要求に含まれる招待利用者のFNWIDaを特定する。第２に、ＣＰＵ３０は、ＩＤ管理テーブルＴＢＬ１２を参照して、招待利用者のFNWIDaに対応するRefIDを取得する。第３に、ＣＰＵ３０は、ＩＤ管理テーブルＴＢＬ１２を参照して、取得したRefIDと対応づけて記憶されている、招待利用者のFNWID（FNWIDb）を抽出する。第４に、ＣＰＵ３０は、利用者情報テーブルＴＢＬ１１を参照して、抽出した、招待利用者のFNWID（FNWIDb）に対応づけられているレコードを特定し、当該レコードに含まれる招待利用者のニックネームを取得する。

この後、ＣＰＵ３０は、招待ゲームＡのAppIDa、招待利用者のゲームＡのFNWIDa、被招待利用者の被招待ゲームＢのFNWIDb、招待利用者の被招待ゲームＢにおけるニックネーム、をインバイトテーブルＴＢＬ１４に記憶する。インバイトテーブルＴＢＬ１４は、招待情報を蓄積する招待情報管理部１６（図１参照）として機能する。

この後、被招待利用者が端末装置２ｂを操作してゲームＢを起動すると、端末装置２ｂの照会部２０１はゲームＢの利用中に問い合わせ要求を管理サーバ３に送信する。招待問い合わせ要求には、ゲームＢにおける被招待利用者のFNWIDbが含まれている。なお、アプリケーションシステム１００に属するゲームＡ、ゲームＢ、ゲームＣ…のいずれかを起動しても、起動したゲームの実行中に、招待問い合わせ要求が管理サーバ３に送信される。

次に、管理サーバ３は、招待問い合わせ要求を受信すると、招待情報の検索を実行する。具体的には、ＣＰＵ３０は、インバイトテーブルＴＢＬ１４を参照して、FNWIDbがInviteFNWID_Toとして記録されているレコードを特定し、当該レコードにおいて、招待利用者のゲームＢのニックネームと招待ゲームＡを指定するAppIDaを特定する。なお、AppIDaには、招待ゲームＡをダウンロード可能なサイトのアドレスを示すリンク情報が含まれてもよい。これにより、ＣＰＵ３０は招待情報管理部１６として機能する。この後、ＣＰＵ３０は、通信インターフェース３６を介して、特定した招待情報であるニックネーム及びAppIDaを含む招待問い合わせ応答を端末装置２ｂに送信する。この場合、ＣＰＵ３０は通知部１５として機能する。

次に、招待問い合わせ応答を受信した端末装置２ｂは、招待利用者のニックネーム、招待を受けるゲーム名、及びリンク情報をディスプレイ２５に表示する。具体的には、端末装置２ｂの招待情報受領部２０２（ＣＰＵ２０）が、招待情報を含む招待問い合わせ応答を受領し、表示制御部２０４（ＣＰＵ２０）が、ディスプレイ２５に招待の内容を表示させる。
これによって、被招待利用者は、ゲームＢにおいて仲間関係にある招待利用者から、ゲームＡに招待があったことを知ることができる。

上述したように、端末装置２を、選択部２０６で選択したゲームＢにおいて、利用者（招待利用者）と特定の関係がある利用者（被招待利用者の候補）のうち招待される利用者（被招待利用者）に対する招待要求を管理サーバ３に通知する招待要求送信部２０９として、機能させることが可能なように構成してもよい。この招待要求は、管理サーバ３で管理する招待情報の基となる。また、端末装置２は、招待要求送信部２０９をさらに含んで構成されると捉えることができる。
このように、ゲームＡからの操作に基づきゲームＢを起動し、起動されたゲームＢから招待要求を管理サーバ３に通知したから、ゲームＡをプレイしている利用者が、ゲームＢで仲間となっている他の利用者をゲームＡに招待することが可能となる。つまり、アカウントに互換性がないゲーム間であっても、あるゲームからの操作に基づいて、他のゲームで仲間関係にある利用者に対して招待することが可能となる。ここで、ゲームＡからの操作に基づいて起動されるゲームＢは、利用者がゲームＢをプレイするときに起動されるゲームＢとは動作が異なる。つまり、ゲームＡからの操作に基づく場合、招待処理を行うための起動となる。

＜３.変形例＞
本発明は、上述した実施形態に限定されるものではなく、以下に述べる各種の変形が可能である。また、各変形例及び実施形態は、適宜、組み合わせてもよいことは勿論である。
（１）上述した実施形態では、各アプリケーションサーバ４Ａ、４Ｂ、４Ｃ…が、最初からアプリケーションシステム１００に組み込まれていることを前提としたが、本発明はこれに限定されるものではなく、あるアプリケーションサーバを既に運用しているアプリケーションシステム１００に組み込んでもよい。

例えば、アプリケーションサーバ４Ａが単独で運用されており、当該アプリケーションサーバ４Ａをアプリケーションシステム１００に新たに適用する場合を想定する。この場合は、端末装置２においてゲームＡのプログラムのアップデートを実行する必要がある。アプリケーションサーバ４Ａが単独で運用されている場合には、ゲームＡはアプリケーションサーバ４Ａとの間で動作すればよいので、トークンを他のゲームのプログラムに引き渡す機能や、招待処理の機能が無いからである。

図１２に変形例に係るFNWIDの取得処理の内容を示す。この例では、アプリケーションサーバ４Ａが新たにアプリケーションシステム１００に組み込まれたものとする。

まず、利用者が端末装置２ａを操作して、ゲームＡのダウンロードサイトにアクセスすると、更新プログラムのアップデートを促す画面がディスプレイ２５に表示される。利用者が端末装置２ａを操作して、アップデートを選択すると、端末装置２はアップデート要求をアプリケーションサーバ４Ａに送信する。アップデート要求を受信したアプリケーションサーバ４Ａは、更新プログラムを含むアップデート応答を端末装置２ａに返信する。

次に、アップデート応答を端末装置２ａが受信すると、ゲームＡの更新プログラムが端末装置２ａにインストールされる。更新プログラムのインストールにおいては、従前のゲームＡで用いたニックネーム及びLocalIDは登録情報の一部として引き継がれる。

ゲームＡを起動すると、ゲームＡの利用中に端末装置２ａのゲームＡが管理する記憶領域を参照してFNWIDが記憶されているか否かに基づいて初回起動かを判断する。FNWIDが記憶されておらず初回起動であると判断した場合には、端末装置２ａは初回起動であること示す初回起動通知をアプリケーションサーバ４Ａに送信する。
初回起動通知を受信したアプリケーションサーバ４Ａは、FNWID発行要求を管理サーバ３に送信する。FNWID発行要求を受信した管理サーバ３は、FNWIDaを発行し、発行したFNWIDaを含むFNWID発行応答をアプリケーションサーバ４Ａに返信する。FNWID発行応答をアプリケーションサーバ４Ａが受信すると、アプリケーションサーバ４Ａは、FNWIDaを、ニックネーム、及びローカル識別情報LocalIDaに対応づけて利用者情報テーブルＴＢＬ１１Ａに記憶する。また、アプリケーションサーバ４Ａは、FNWIDaを端末装置２ａに通知する。端末装置２ａはFNWIDaをゲームＡと関連付けて記憶する。

次に、アプリケーションサーバ４Ａは、ニックネーム及びFNWIDaを含むニックネーム通知を管理サーバ３に送信する。管理サーバ３はニックネーム通知を受信すると、これらを利用者情報テーブルＴＢＬ１１に記憶する。

このようにして、利用者が端末装置２ａにゲームＡの更新プログラムがダウンロードされ、これを利用者が起動すると、FNWIDaが管理サーバ３において発行され、発行されたFNWIDaが、管理サーバ３、アプリケーションサーバ４Ａ及び端末装置２ａにおいて保存される。この場合、端末装置２ａの利用者は、管理サーバ３に対して利用者が管理する管理アカウントを新たに設ける必要はない。

この変形例では、ゲームＡを初回起動した利用者に対して、FNWIDを逐次発行した。このため、更新プログラムを端末装置２にダウンロードしてもゲームＡをまだ利用していない利用者に関しては管理サーバ３で、当該利用者のFNWIDを管理しなくてもよいといった利点がある。

さらに、ある利用者が更新プログラムをアップデートした後に起動すると、当該利用者と仲間関係にある利用者についても、アプリケーションサーバ４Ａと管理サーバ３との間で一括してFNWIDを発行する処理を進めるようにしてもよい。但し、仲間関係にある利用者のうち既にFNWIDが発行されている利用者については、新たに、FNWIDを発行しない。この場合には、仲間関係にある利用者が更新プログラムをアップデートしてこれを起動すると、アプリケーションサーバ４ＡからFNWIDを当該仲間関係にある利用者の端末装置２に通知するようにしてもよい。

（２）上述した実施形態及び変形例では、アプリケーションの一例としてゲームを取り上げて説明したが本発明はこれに限定されるものではなく、どのようなアプリケーションであってもよい。例えば、チャットアプリや写真・動画共有アプリであってもよい。アプリケーション内での他の利用者と特定の関係とは、ゲームであれば「仲間」や「ライバル」などであり、チャットアプリであれば「チャット仲間」であり、写真・動画共有アプリであれば写真や動画を共有可能な「仲間」である。すなわち、特定の関係が形成されている同士と形成されていない同士とで、アプリケーションで提供されるサービスや機能の全部または一部に対して差異が設けられているものであれば、どのようなアプリケーションにも適用可能である。

（３）上述した実施形態及び変形例では、ある利用者と他の利用者とがアプリケーションを実行する際に助け合う仲間関係を一例として説明したが、本発明はこれに限定されるものではなく、あるアプリケーション内での他の利用者と特定の関係が形成されるものであればよい。また、仲間関係は、ある利用者が他の利用者に仲間関係になることを申し入れ、他の利用者がこれを受諾した場合に成立させてもよい。特定の関係には、仲間関係の他に、仲間関係になることを拒否したブロック関係、あるいは、ある利用者が他の利用者をライバルとして認識し、他の利用者の受諾を必要としないライバル関係が含まれてもよい。

（４）上述した実施形態及び変形例では、ゲームＡを利用する端末装置２は、ゲームＢのFNWIDに対応づけられた仲間関係を示す仲間リストを要求する仲間リスト要求を管理サーバ３に送信し、管理サーバ３は仲間リスト要求を受け付ける受付部１４と仲間リストを端末装置２に送信する通知部１５とを備えたが、本発明はこれに限定されるものではなく、受付部１４は、ゲームＡを提供するアプリケーションサーバ４Ａから仲間リスト要求を受け付け、通知部１５はアプリケーションサーバ４Ａに仲間リストを通知してもよい。この場合には、端末装置２と管理サーバ３との間にアプリケーションサーバ４Ａが介在することになる。即ち、端末装置２は、アプリケーションサーバ４Ａに対して仲間リスト要求を送信し、仲間リスト要求を受信したアプリケーションサーバ４Ａは、仲間リスト要求を管理サーバ３に送信する。仲間リスト要求を受信した管理サーバ３は仲間リストをアプリケーションサーバ４Ａに送信し、仲間リストを受信したアプリケーションサーバ４Ａは、仲間リストを端末装置２に送信する。

（５）上述した実施形態及び変形例では、管理サーバ３が端末装置２から招待要求を受信すると、招待情報管理部１６で招待要求を蓄積したが、本発明はこれに限定されるものではなく、管理サーバ３が招待情報管理部１６を備えないものであってもよい。この場合、管理サーバ３が端末装置２からゲームＢを利用している被招待利用者をゲームＡに招待する招待要求を受信すると、通知部１５は、被招待利用者のアプリケーションサーバ４ＢへゲームＡに招待することを示す招待情報を通知すればよい。アプリケーションサーバ４Ｂは、インバイトテーブルＴＢＬ１４を備えて招待情報を蓄積する（招待情報管理部１６）。被招待利用者が端末装置２でゲームＢを起動した後、端末装置２の照会部２０１は起動したゲームＢに対応するアプリケーションサーバ４Ｂに招待要求の照会を実行する。アプリケーションサーバ４Ｂは、インバイトテーブルＴＢＬ１４に被招待利用者の招待情報が蓄積されているかを検索し、招待情報を被招待利用者の端末装置２に送信すればよい。つまり、招待情報管理部１６は、複数のアプリケーションサーバ４のそれぞれに設けられており、照会部２０１は、端末装置で起動されたアプリケーションに対応するアプリケーションサーバ４の招待情報管理部１６に招待情報の有無を照会する。
このように、管理サーバ３の通知部１５は、当該通知部で通知した仲間リスト（関係情報の一例）の中から招待利用者が選択した被招待利用者に対する招待要求があると、被招待利用者のアプリケーションサーバ４Ｂ（第２アプリケーション装置の一例）へ招待利用者がゲームＡ（第１アプリケーションの一例）に招待することを示す招待情報を通知する。このように招待要求の蓄積には様々な代替実施形態を採用し得る。

（６）上述した実施形態及び変形例では、ゲームＡからゲームＢに引き渡されたトークンは、FNWIDbとともに、端末装置２から送信され、アプリケーションサーバ４Ｂを介して管理サーバ３の受領部１２で受領したが、本発明はこれに限定されるものではなく、どのような経路で管理サーバ３が取得するかは問わない。例えば、端末装置２から管理サーバ３に直接送信し、これを受領部１２で受領してもよい。つまり、管理サーバ３においてFNWIDaと対応づけて発行したトークンTxは、端末装置２のゲームＡ→端末装置２のゲームＢ→管理サーバ３といった経路で送信されてもよい。
上述した実施形態及び変形例では、端末装置２における招待利用者の操作に基づいて、ゲームＡからゲームＢにトークンが引き渡されたが、本発明はこれに限定されるものではなく、招待利用者の操作によらず、ゲームＡの自動的な処理に基づいて、トークンがゲームＡからゲームＢに引き渡されてもよい。あるいは、ゲームＡによって起動される端末装置２で動作するプログラム処理に基づくものでもよい。

１……通信網、２……端末装置、３……サーバ装置、３Ｂ,３Ｃ,３Ｄ……アプリケーションサーバ、ＴＢＬ１１……利用者情報テーブル、ＴＢＬ１２……ＩＤ管理テーブル、ＴＢＬ１３……仲間関係テーブル、ＴＢＬ１４……インバイトテーブル、１１……発行部、１２……受領部、１３……管理部、１４……受付部、１５……通知部、１６……招待情報管理部（蓄積部）、３０……ＣＰＵ、１００……アプリケーションシステム、２０１……照会部、２０２……招待情報受領部、２０３……表示部、２０４……表示制御部、２０５……記憶部、２０６……選択部、２０７……取得部、２０８……識別子通知部。

Claims (2)

1. 第１アプリケーション装置から提供される、第１アプリケーションでのサービスを利用する複数の利用者のそれぞれを一意に識別する第１識別情報、及び、第２アプリケーション装置から提供される、第２アプリケーションでのサービスを利用する複数の利用者のそれぞれを一意に識別する第２識別情報を発行して管理する管理装置であって、
   前記第１アプリケーションのサービスを利用する前記複数の利用者のうちの一の利用者の第１識別情報に関連付けられた識別子を、前記第１アプリケーション装置に対して発行する発行部と、
   前記第１アプリケーションのプログラム及び前記第２アプリケーションのプログラムをダウンロードして実行可能な前記一の利用者の端末装置において前記第１アプリケーションが起動されている場合において、前記第２アプリケーションが起動されると前記第１アプリケーションから前記第２アプリケーションに引き渡される前記識別子と、前記一の利用者の第２識別情報とを、前記第２アプリケーション装置又は前記第２アプリケーションから受領する受領部と、
   前記発行部で発行した識別子と前記受領部で受領した識別子とが合致する場合に、前記一の利用者の第１識別情報と前記前記一の利用者の第２識別情報とを関連付けて管理する管理部と、
   を備えることを特徴とする管理装置。
2. 前記識別子は、前記第１アプリケーションから前記第２アプリケーションが起動されたとき前記第１アプリケーションから前記第２アプリケーションに引き渡されることを特徴とする請求項１に記載の管理装置。

Images