JP5662605B2 - 管理装置、管理方法、及びプログラム - Google Patents

Description

本発明は、管理装置、管理方法、及びプログラムに関する。

ＳＮＳ（Social Networking Service）の会員に対して提供されるソーシャルゲームが知られている（例えば、非特許文献１参照）。このＳＮＳは、会員に対して提供されるソーシャルゲームのポータルサイトとしても機能しており、ＳＮＳにおけるユーザの会員情報と、それぞれのソーシャルゲームにおけるユーザのユーザ情報とを対応付けて管理している。そのため、例えば友だち関係にある会員どうしでは、互いにいずれのゲームをプレイしているかを知ることができるとともに、自分がプレイしていても友だち関係にある会員がプレイしていないゲームがある場合には、ＳＮＳを介してその会員に当該ゲームをプレイするように招待することも可能である。

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

ところで、ＳＮＳの会員に対して提供されるソーシャルゲームではなく、ＳＮＳの会員ではなくても利用できるようなソーシャルゲーム（以下、独立型ソーシャルゲームと称する）がある。この独立型ソーシャルゲームのようなアプリケーションは、例えば、アプリケーションを販売するストアサイトや各アプリケーションの専用サイトからダウンロードしてユーザ端末にインストールすることにより利用できる所謂ネイティブ型のアプリケーションである。

このようなネイティブ型のアプリケーションでは、ユーザが利用しているアプリケーションに対して他のユーザを招待する場合、ソーシャルメディアやメールなどを利用する方法が行われていた。この方法では、招待するユーザのユーザＩＤを通知（招待通知）し、招待を受けるユーザが、招待を受けたアプリケーションを開始するときに招待者のユーザＩＤを入力することで、招待するユーザと招待を受けるユーザとを紐付けするようにしていた。
ところで、あるアプリケーションで友だち関係にあるユーザを、別のアプリケーションに招待したい場合がある。しかし、上記の方法では、招待したいユーザが、ソーシャルメディアを利用しているかも不明であるし、メールアドレスを知らない場合もある。そもそも、アプリケーションで友だち関係にあるユーザは、必ずしも現実社会で友だち関係にあるとも限らず、アプリケーション内で知られているユーザ名（ニックネーム）と、現実社会で利用されているソーシャルメディアやメールでのユーザ名（アカウント名）とが一致していない場合が多い。したがって、上記の方法では招待したいユーザに対して効果的に招待通知ができないことがあった。そのため、招待するアプリケーションと招待を受けるアプリケーションとの間で、ユーザを招待できる仕組みが望まれていた。しかしながら、それぞれのアプリケーションにおけるユーザのユーザ情報を独自に管理しているため、アプリケーション間でユーザ情報に互換性がない。そのため、あるアプリケーションで友だち関係にあるユーザを、他のアプリケーションに招待することができないことがあった。

本発明は、このような状況に鑑みてなされたもので、あるアプリケーションで友だち関係にあるユーザを他のアプリケーションに招待する際の利便性を向上させることができる管理装置、管理方法、及びプログラムを提供する。

以下では、本発明の理解を容易にするために添付図面の参照符号を便宜的に括弧書きにて付記するが、それにより本発明が図示の態様に限定されるものではない。

上述した課題を解決するために、本発明の一態様は、第１ゲームおよび第２ゲームが実行されたことがある第１ユーザの端末装置（１００）から、当該第２ゲームで当該第１ユーザと所定の関係にあるユーザの端末装置に対して、当該第１ゲームを導入させるための招待処理を制御する制御部（２３０）を備え、前記制御部が、前記第２ゲームから前記所定の関係にあるユーザを示す所定関係ユーザ情報を取得した場合に当該所定関係ユーザ情報に含まれるユーザのうち、前記第１ゲームへの招待候補となるユーザを抽出条件に基づいて抽出する抽出部（２３９）と、前記抽出部が抽出した前記第１ゲームへの招待候補となるユーザを示す招待候補ユーザ情報を、前記第１ユーザの端末装置に対して送信する招待候補ユーザ通知部（２４０）と、前記招待候補ユーザ情報に示されるユーザのうちの第２ユーザを前記第１ゲームへ招待申請する招待申請情報を前記第１ユーザの端末装置から受け取る招待申請受取部（２３３）と、前記第２ユーザの端末装置に対して、前記招待申請情報に基づく招待通知情報を送信する招待通知部（２３６）と、を備えることを特徴とする管理装置（２００）である。

また、本発明の一態様は、上記管理装置において、前記抽出部が、前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請をしたことがあるユーザを抽出対象から除くことを特徴とする。

また、本発明の一態様は、上記管理装置において、前記抽出部が、前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請が成立している当該招待申請がされたことがあるユーザを抽出対象から除くことを特徴とする。

また、本発明の一態様は、上記管理装置において、前記抽出部が、前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請がされたことのあるユーザであって、当該招待申請が成立されていない招待申請中のユーザを抽出対象から除くことを特徴とする。

また、本発明の一態様は、上記管理装置において、前記抽出部が、前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請を却下したことがあるユーザを抽出対象から除くことを特徴とする。

また、本発明の一態様は、上記管理装置が、前記第１ゲームおよび前記第２ゲームを含む複数のゲームのそれぞれに関する情報を管理するアプリケーション管理部（２３１）、を備え、前記アプリケーション管理部が、当該情報に前記第１ゲームへのユーザの再招待を許可するか否かを示す情報を含んで管理し、前記抽出部が、前記抽出条件として、前記アプリケーション管理部を参照して、前記第１ゲームへのユーザの再招待が許可されている場合、前記第１ゲームへの招待申請を却下したことがあるユーザを抽出対象に含めることを特徴とする。

また、本発明の一態様は、上記管理装置において、前記抽出部が、前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請を却下したユーザであっても、当該招待申請と異なる第１ユーザからの招待申請である場合には当該ユーザを抽出対象に含めることを特徴とする。

また、本発明の一態様は、上記管理装置において、前記抽出部が、前記抽出条件として、前記第１ユーザからの招待申請を拒否する設定がされたユーザを抽出対象から除くことを特徴とする。

また、本発明の一態様は、上記管理装置が、前記第１ゲームおよび前記第２ゲームを含む複数のゲームのそれぞれに関する情報を管理するアプリケーション管理部、を備え、前記アプリケーション管理部が、招待申請の禁止を設定する設定側ユーザと、当該設定側ユーザに対する招待申請が禁止される被設定側ユーザとを組みにした第１禁止情報を管理し、前記抽出部が、前記抽出条件として、前記アプリケーション管理部が管理している前記第１禁止情報のうち、前記第１ユーザを前記被設定側ユーザに設定している第１禁止情報がある場合には、当該第１禁止情報が示す設定側ユーザを、前記第１ユーザからの招待申請を拒否する設定がされたユーザとして抽出対象から除くことを特徴とする。

また、本発明の一態様は、上記管理装置において、前記抽出部が、前記抽出条件として、前記第１ゲームへの招待申請を拒否する設定がされたユーザを抽出対象から除くことを特徴とする。

また、本発明の一態様は、上記管理装置において、前記第１ゲームおよび前記第２ゲームを含む複数のゲームのそれぞれに関する情報を管理するアプリケーション管理部、を備え、前記アプリケーション管理部が、招待申請の禁止を設定する設定側ユーザと、当該設定側ユーザに対する招待申請が禁止される被設定側ゲームとを組みにした第２禁止情報を管理し、前記抽出部が、前記抽出条件として、前記アプリケーション管理部が管理している前記第２禁止情報のうち、前記第１ゲームを前記被設定側ゲームに設定している第２禁止情報がある場合には、当該第２禁止情報が示す設定側ユーザを、前記第１ゲームへの招待申請を拒否する設定がされたユーザとして抽出対象から除くことを特徴とする。

また、本発明の一態様は、上記管理装置が、前記招待通知情報に対応する前記第２ゲームから前記第１ゲームへの招待が成立したことを示す招待成立情報を、前記第２ユーザの端末装置又は前記第１ゲームに対応するサーバ装置から受け取る招待成立受取部（２３７）、を備えることを特徴とする。

また、本発明の一態様は、管理装置の管理方法であって、第１ゲームおよび第２ゲームが実行されたことがある第１ユーザの端末装置から、当該第２ゲームで当該第１ユーザと所定の関係にあるユーザの端末装置に対して、当該第１ゲームを導入させるための招待処理を制御する制御ステップを有し、前記制御ステップが、前記第２ゲームから前記所定の関係にあるユーザを示す所定関係ユーザ情報を取得した場合に当該所定関係ユーザ情報に含まれるユーザのうち、前記第１ゲームへの招待候補となるユーザを抽出条件に基づいて抽出するステップと、前記抽出した前記第１ゲームへの招待候補となるユーザを示す招待候補ユーザ情報を、前記第１ユーザの端末装置に対して送信するステップと、前記招待候補ユーザ情報に示されるユーザのうちの第２ユーザを前記第１ゲームへ招待申請する招待申請情報を前記第１ユーザの端末装置から受け取るステップと、前記第２ユーザの端末装置に対して、前記招待申請情報に基づく招待通知情報を送信するステップと、を含むことを特徴とする管理方法である。

また、本発明の一態様は、第１ゲームおよび第２ゲームが実行されたことがある第１ユーザの端末装置から、当該第２ゲームで当該第１ユーザと所定の関係にあるユーザの端末装置に対して、当該第１ゲームを導入させるための招待処理を制御するコンピュータに、前記第２ゲームから前記所定の関係にあるユーザを示す所定関係ユーザ情報を取得した場合に当該所定関係ユーザ情報に含まれるユーザのうち、前記第１ゲームへの招待候補となるユーザを抽出条件に基づいて抽出するステップと、前記抽出した前記第１ゲームへの招待候補となるユーザを示す招待候補ユーザ情報を、前記第１ユーザの端末装置に対して送信するステップと、前記招待候補ユーザ情報に示されるユーザのうちの第２ユーザを前記第１ゲームへ招待申請する招待申請情報を前記第１ユーザの端末装置から受け取るステップと、前記第２ユーザの端末装置に対して、前記招待申請情報に基づく招待通知情報を送信するステップと、を実行させるためのプログラムである。

以上説明したように、本発明によれば、あるアプリケーションで友だち関係にあるユーザリストのうち、他のアプリケーションに招待する招待候補を所定の抽出条件に基づいて抽出するため、あるアプリケーションで友だち関係にあるユーザを他のアプリケーションに招待する際の利便性を向上させることができる。

第１の実施形態によるネットワークシステムの構成の一例を示す概略構成図である。 第１の実施形態によるユーザ端末の構成の一例を示す概略構成図である。 第１の実施形態の相互招待システムの構成及び処理の一例を説明する説明図である。 招待処理におけるユーザ端末の表示画面の表示例を示す図である。 本実施形態によるユーザ端末のＳＤＫに基づいて実行する機能構成の一例を示す構成図である。 第１の実施形態による管理サーバの構成の一例を示す構成図である。 アプリケーション設定記憶部に記憶される情報の一例を示す図である。 招待申請情報記憶部に記憶される情報の一例を示す図である。 第１の実施形態による招待処理の動作の第１例を示すフローチャートである。 第１の実施形態による招待処理の動作の第２例を示すフローチャートである。 第２の実施形態による管理サーバの構成の一例を示す構成図である。 相互招待拒否設定記憶部に記憶される情報の一例を示す図である。 第３の実施形態による招待処理の動作の一例を示すフローチャートである。 第３の実施形態による管理サーバの構成の一例を示す構成図である。 招待申請拒否ユーザ設定記憶部に記憶される情報の一例を示す図である。 招待申請拒否アプリ設定記憶部に記憶される情報の一例を示す図である。 招待申請記録に基づいてフィルタリングする処理の第１例を説明する図である。 招待申請記録に基づいてフィルタリングする処理の第２例を説明する図である。 招待申請記録に基づいてフィルタリングする処理の第３例を説明する図である。 招待申請記録に基づいてフィルタリングする処理の第４例を説明する図である。 招待申請記録に基づいてフィルタリングする処理の第５例を説明する図である。 通信セッションの確立処理の動作を説明するフローチャートである。

以下、本発明の一実施形態について、図面を参照して説明する。
＜第１の実施形態＞

〔相互招待システムの概要〕
まず、本実施形態による相互招待システムの概要を説明する。この相互招待システムは、互いに異なる種類の第１アプリケーションおよび第２アプリケーションがインストールされているユーザのユーザ端末から、当該第２アプリケーションにおいて当該ユーザと所定の関係にある他のユーザのユーザ端末に対して、第１アプリケーションをインストールさせるように招待するシステムである。

例えば、ＳＮＳ（Social Networking Service）の会員に対して提供されるソーシャルゲームでは、それぞれのソーシャルゲームにおけるユーザのユーザ情報とＳＮＳにおけるユーザの会員情報とが対応付けられて管理されている。そのため、例えば友だち関係にある会員どうしでは、この会員情報を用いた対応付けにより、互いにいずれのゲームをプレイしているかを知ることができるとともに、自分がプレイしていても友だち関係にある会員がプレイしていないゲームがある場合には、ＳＮＳを介してその会員に当該ゲームをプレイするように招待することも可能である。

ところで、ＳＮＳの会員に対して提供されるソーシャルゲームではなく、ＳＮＳの会員ではなくても利用できるようなソーシャルゲーム（以下、独立型ソーシャルゲームとも称する）がある。この独立型ソーシャルゲームのようなアプリケーションは、例えば、アプリケーションを販売するストアサイトや各アプリケーションの専用サイトからダウンロードしてユーザ端末にインストールすることにより利用できる所謂ネイティブ型のアプリケーションである。

しかしながら、このようなネイティブ型のアプリケーションでは、それぞれのアプリケーションにおけるユーザのユーザ情報を独自に管理しているため、アプリケーション間でユーザ情報に互換性がない。そのため、あるアプリケーションで友だち関係にあるユーザを、他のアプリケーションに招待することができない場合がある。そこで、本実施形態では、利便性の高いアプリケーション間の相互招待システムを提供することを目的とし、ユーザ情報に互換性がないアプリケーション間であっても、あるアプリケーションで友だち関係にあるユーザを、他のアプリケーションに招待することができるように構成する。

なお、アプリケーションのインストールとは、ユーザ端末に導入されていないアプリケーションのプログラムを新規に導入することだけでなく、相互招待システムに対応するようにアプリケーションのプログラムをアップデート（更新）することを含む。すなわち、ユーザ端末に搭載しているアプリケーションに対して、相互招待システムに対応するための更新プログラムをダウンロードして更新することを含む。

〔ネットワークシステムの構成〕
図１は、相互招待システムを実現する本発明の第１の実施形態によるネットワークシステム１の構成の一例を示す概略構成図である。ネットワークシステム１は、複数のユーザ端末１００−Ｎ（Ｎは正の整数。ユーザ端末１００−１、ユーザ端末１００−２、・・・）と、管理サーバ２００と、複数のアプリサーバ３００（アプリサーバ３１０、アプリサーバ３２０、・・・）と、アプリストア４００とのコンピュータ装置を備えており、これらのコンピュータ装置はネットワークＮＷを介して通信可能に接続される。ここで、複数のユーザ端末１００−Ｎは同様の構成であるので、特に区別しない場合には、「−１」、「−２」等の記載を省略してユーザ端末１００として説明する。

管理サーバ２００は、本実施形態の相互招待システムに対応するアプリケーションに関する情報を管理するとともに、ユーザ端末１００と通信することにより、アプリケーション間の招待情報の管理や招待処理を制御する管理装置である。具体的には、管理サーバ２００は、第１アプリケーションおよび第２アプリケーションがインストールされたユーザのユーザ端末１００から、当該第２アプリケーションで当該ユーザと所定の関係にある他のユーザの、当該第２アプリケーションがインストールされたユーザ端末１００に対して、当該第１アプリケーションをインストールさせる招待処理を制御する。

アプリサーバ３００は、ユーザ端末１００にインストール可能なアプリケーションに対応するサーバ装置である。ここでは、ユーザ端末１００にインストールされるアプリケーションがゲームである場合を例として、ゲームＡに対応するアプリサーバ３１０と、ゲームＢに対応するアプリサーバ３２０とが、ネットワークＮＷを介してユーザ端末１００と接続されることを示している。なお、ネットワークシステム１には、アプリサーバ３１０及びアプリサーバ３２０に限らず、ユーザ端末１００にインストールされてプレイすることができるゲームに対応して複数のアプリサーバ３００が備えられる。ここで、ユーザ端末１００にインストールされるアプリケーションとは、アプリケーションのプログラムがユーザ端末１００にインストールされることにより、インストールされたプログラムに基づいてユーザ端末１００がアプリケーションに関する処理（例えば、ゲームの処理）を行う、所謂ネイティブ型のアプリケーションである。ユーザ端末１００は、ゲームをプレイするユーザに対応したユーザ情報をアプリサーバ３００に送信したり、ゲームのプレイ中に必要な情報やゲームにおいて所定の関係（例えば、友だち関係）にあるユーザのユーザリストをアプリサーバ３００から取得したりする。

アプリストア４００は、ユーザ端末１００にインストール可能なアプリケーションをダウンロード可能なストアサイト（ダウンロードサービスサイト）を提供するサーバ装置である。ユーザは、自身のユーザ端末１００からネットワークＮＷを介してアプリストア４００に接続して所望のアプリケーションを有料または無料で購入することにより、購入したアプリケーションを自身のユーザ端末１００にダウンロードしてインストールすることができる。

ユーザ端末１００は、ユーザによって使用される端末装置であり、例えば、携帯電話やスマートフォン、タブレット端末、パーソナルコンピュータ、通信機能付きゲーム機などが用いられる。ここでは、ユーザ端末１００はスマートフォンであるとして説明する。

図２は、本実施形態によるユーザ端末１００の構成の一例を示す概略構成図である。この図に示すように、ユーザ端末１００は、入力部１１０と、表示部１２０と、端末通信部１３０と、端末記憶部１４０と、端末制御部１５０とを備えている。

入力部１１０は、ユーザからの操作に応じてユーザの指示を受付けて、指示内容に応じた入力指示情報を生成する入力デバイスである。入力部１１０には、例えば、キーボードやボタン、タッチパネル、マウス、マイクロホン等を適用できる。
表示部１２０は、画像や文字等の情報を表示する表示デバイスであり、例えば、ＬＣＤ（Liquid Crystal Display）、有機ＥＬ（Electro Luminescence）ディスプレイ等を適用できる。入力部１１０と表示部１２０とは一体に構成されてユーザからの操作入力を受け付けるタッチパネルとして適用することもできる。
端末通信部１３０は、ネットワークＮＷを介して管理サーバ２００またはアプリサーバ３００と通信する。
端末記憶部１４０は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュＲＯＭ、ＨＤＤ（Hard Disk Drive）等の記録媒体またはこれらの組合せを用いて構成され、ユーザ端末１００が備える各部を制御するためのプログラム（例えば、端末制御部１５０に基本動作を行わせるためのＯＳ（Operating System））、インストールされたアプリケーションのプログラム、各種情報等を記憶する。

端末制御部１５０は、ユーザ端末１００の制御中枢として機能するＣＰＵ（Central Processing Unit）等の情報処理装置を備えており、ユーザ端末１００が備える各部を制御する。例えば、端末制御部１５０は、端末記憶部１４０に記憶されているＯＳに基づく基本動作の処理を実行するとともに、アプリケーションのプログラム（ゲームのプログラム）に基づく処理を実行する。また、端末制御部１５０は、ＯＳ上で動作可能な各種のアプリケーション（Ｗｅｂブラウザや、アプリストア４００が提供するストアサイトのストアページを表示させるアプリケーション等）の機能をＯＳを介して実行する処理を行う。

ネットワークＮＷは、例えば、携帯電話網、ＰＨＳ（Personal Handy-phone System）網、ＶＰＮ（Virtual Private Network）網、専用通信回線網、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、ＰＳＴＮ（Public Switched Telephone Network；公衆交換電話網）など、またはこれらの組み合わせによって構成される情報通信ネットワークである。

〔相互招待システムの構成及び処理〕
次に、図３を参照して、本実施形態の相互招待システムの構成及び処理について説明する。
図３は、本実施形態のネットワークシステム１における相互招待システムの構成及び処理の一例を説明する説明図である。この図において図１の各部と対応する構成には同一の符号を付している。ここで、ユーザＸのユーザ端末１００をユーザ端末１００−１とし、ユーザＹのユーザ端末１００をユーザ端末１００−２とする。また、ユーザ端末１００にインストール可能なゲームＡとゲームＢとは相互招待システムに対応するアプリケーションであり、ユーザ端末１００−１にはゲームＡとゲームＢとがインストールされており、ユーザ端末１００−２にはゲームＢがインストールされている（ゲームＡはインストールされていない）ものとする。また、ユーザＸとユーザＹとは、ゲームＢにおいて友だち関係にあるとする。

この図は、ユーザＸ（招待ユーザ）のユーザ端末１００−１のゲームＡから、ゲームＢにおいて友だち関係にあるユーザＹ（被招待ユーザ）のユーザ端末１００−２に対して、ゲームＡをインストールさせるように招待申請する招待処理を説明する図である。つまり、この招待処理は、ユーザＸ（招待ユーザ）がプレイしている招待申請元のアプリケーション（以下、申請元アプリと称する）であるゲームＡへ、招待申請先のアプリケーション（以下、申請先アプリと称する）であるゲームＢにおいて友だち関係にあるユーザＹ（被招待ユーザ）を招待する処理である。なお、申請元アプリ１０（ゲームＡ）と申請先アプリ２０（ゲームＢ）とは、招待処理が行われる以前はそれぞれ申請元と申請先とになっていないが、便宜上、それぞれ申請元アプリ１０と申請先アプリ２０と称して説明する。

なお、ゲームＡが申請元アプリ１０でありゲームＢが申請先アプリ２０である場合の例を説明するが、ゲームＢが申請元アプリ１０となりゲームＡが申請先アプリ２０となることもありうる。相互招待システムにおける「相互招待」とは、各アプリケーションのそれぞれにおいて所定の関係（例えば、友だち関係）にあるユーザを、アプリケーション間で互いに招待することができることをいう。

ここでは、ユーザ端末１００−１には、申請元アプリ１０（ゲームＡ）及び申請先アプリ２０（ゲームＢ）がインストールされていることを模式的に示している。一方、ユーザ端末１００−２には、申請先アプリ２０（ゲームＢ）がインストールされており、申請元アプリ１０（ゲームＡ）が初めはインストールされておらず、ユーザＸからの招待申請に基づいてインストールされることを模式的に示している。

申請元アプリ１０（ゲームＡ）は、ゲームＡをプレイするユーザに対応したユーザ情報をアプリサーバ３１０（ゲームＡ）に送信したり、ゲームＡのプレイ中に必要な情報をアプリサーバ３１０（ゲームＡ）から取得したりする。同様に、申請先アプリ２０（ゲームＢ）は、ゲームＢをプレイするユーザに対応したユーザ情報をアプリサーバ３２０（ゲームＢ）に送信したり、ゲームＢのプレイ中に必要な情報をアプリサーバ３２０（ゲームＢ）から取得したりする。さらに、本実施形態の相互招待システムでは、申請先アプリ２０（ゲームＢ）は、例えば、申請元アプリ１０（ゲームＡ）からの指示に基づいて、申請先アプリ２０（ゲームＢ）におけるユーザリストをアプリサーバ３２０（ゲームＢ）から取得する。

また、アプリサーバ３１０（ゲームＡ）とアプリサーバ３２０（ゲームＢ）とは、それぞれのユーザのユーザ情報を独自の形式により管理している。そのため、申請元アプリ１０（ゲームＡ）と申請先アプリ２０（ゲームＢ）とのユーザ情報には互換性がない。ここで、このユーザ情報とは、例えば、それぞれのアプリケーションにおけるユーザを一意に識別する識別情報であって、アプリケーション毎に独自に管理される識別情報（以下、「ユーザＩＤ」と称する）である。なお、ユーザＩＤは、ユーザが把握できない不可視化情報（内部情報）であってもよい。また、ユーザＩＤとユーザ自身が登録したユーザ名とが関連付けられてユーザ情報として登録されてもよい。

また、本実施形態の相互招待システムに対応するアプリケーションには、招待処理用のソフトウェア（以下、ＳＤＫ（Software Development Kit）１１と称する）が組み込まれている。このＳＤＫ１１は、例えば、ユーザ端末１００にインストールされた相互招待システムに対応する各アプリケーションと管理サーバ２００とを仲介するためのＡＰＩ（Application Programming Interface）の集合体で構成されている。この図では、申請元アプリ１０（ゲームＡ）にはＳＤＫ１１Ａが組み込まれ、申請先アプリ２０（ゲームＢ）にはＳＤＫ１１Ｂが組み込まれている。ＳＤＫ１１ＡとＳＤＫ１１Ｂとのそれぞれは、申請元アプリ１０と申請先アプリ２０とのそれぞれに対応する機能を実行する構成を備えており、各アプリケーションに応じて必要な機能が実行される。なお、相互招待システムに対応するアプリケーションは、申請元アプリ１０と申請先アプリ２０のどちらにもなり得るので、ＳＤＫ１１ＡとＳＤＫ１１Ｂの両方の構成を備えたＳＫＤ１１が組み込まれている。

つまり、上述のＳＤＫ１１を組み込み可能なようにアプリケーションを構成すれば、当該アプリケーションは、本実施形態の相互招待システムに対応するアプリケーションとなる。なお、上述のＳＤＫ１１が予め組み込まれているアプリケーションがダウンロード可能に提供されてもよいし、インストールされているアプリケーションに対して後から組込み可能なＳＤＫ１１が提供されてもよい。

なお、相互招待システムに対応するアプリケーションの中には、申請先アプリ２０にのみに対応するアプリケーションがあってもよい。その場合には、ＳＤＫ１１Ｂのみが組み込まれているようにしてもよいし、ＳＤＫ１１を組み込んでＳＤＫ１１Ａを機能させないようにしてもよい。例えば、アプリケーションによるサービスの提供が終了することが決まって新たなユーザの登録を受け付けないようなアプリケーションは、申請元アプリ１０としての機能を具備しないようにしてもよい。また、相互招待システムに対応するアプリケーションの中には、申請元アプリ１０にのみに対応するアプリケーションがあってもよい。その場合には、ＳＤＫ１１Ａのみが組み込まれているようにしてもよいし、ＳＤＫ１１を組み込んでＳＤＫ１１Ｂを機能させないようにしてもよい。なお、これらの場合は「相互招待」ではなく「一方向招待」となる。つまり、相互招待システムは「相互招待」と「一方向招待」のどちらか一方のみに対応させたり、アプリケーションに応じて「相互招待」と「一方向招待」のどちらかを対応させたりすることができる。

上述のＳＤＫ１１（この図ではＳＤＫ１１Ａ、ＳＤＫ１１Ｂ）と管理サーバ２００とを備えた構成が本実施形態の相互招待システムの主要な構成であり（符号５００参照）、以下、相互招待システム５００と符号を付して記述する。なお、以下の記述において、相互招待システム５００に対応するアプリケーションを、「対応アプリケーション」とも称する。また、アプリケーションを一意に識別する識別情報を「アプリＩＤ」と称する。

管理サーバ２００は、対応アプリケーションに関する情報を管理する。また、管理サーバ２００は、ユーザ端末１００にインストールされた対応アプリケーションに組み込まれたＳＤＫ１１と通信することにより、招待処理を制御する。

この図に示すように管理サーバ２００は、通信部２１０と、記憶部２２０と、制御部２３０と、を備えている。通信部２１０は、ネットワークＮＷを介してユーザ端末１００、アプリサーバ３１０（ゲームＡ）、またはアプリサーバ３２０（ゲームＢ）と通信する。記憶部２２０は、対応アプリケーションに関する情報、招待申請に関する情報等の各種情報を記憶する。制御部２３０は、ユーザ端末１００またはアプリサーバ３１０（ゲームＡ）との招待処理に関する情報の授受や招待処理の制御を行う。

続いて、相互招待システム５００における招待処理の概略の流れについて説明する。ここで、ユーザＸのユーザ端末１００−１には、申請元アプリ１０（ゲームＡ）及び申請先アプリ２０（ゲームＢ）がインストールされている。一方、ユーザＹのユーザ端末１００−２には、申請先アプリ２０（ゲームＢ）がインストールされている（申請元アプリ１０（ゲームＡ）はインストールされていない）ものとする。
なお、ユーザ端末１００に対応アプリケーションがインストールされて初めて実行（起動）した際に、例えば、対応アプリケーション本体からＳＤＫ１１に、当該対応アプリケーションのアプリＩＤ、及び当該対応アプリケーションにおける自ユーザのユーザＩＤが設定されているものとする。

（１）申請元アプリから管理サーバへアプリケーションリスト要求（招待ユーザのユーザ端末）
招待ユーザであるユーザＸのユーザ端末１００−１にインストールされている申請元アプリ１０（ゲームＡ）のＳＤＫ１１Ａは、通常モードで動作中の申請元アプリ１０（ゲームＡ）における第１操作（ユーザＸによる操作）に基づいて、複数の対応アプリケーションの一部または全部からなるアプリケーションリストを要求するアプリケーションリスト要求情報を、管理サーバ２００に対して送信する（ＲＥＱ１１）。ここで、上述の第１操作とは、被招待ユーザを申請元アプリ１０へ招待申請が可能な（申請先アプリ２０として選択可能な）対応アプリケーションのアプリケーションリストを取得するための例えば入力部１１０に対する操作である。

管理サーバ２００は、ユーザ端末１００−１（ＳＤＫ１１Ａ）からアプリケーションリスト要求情報を取得すると、被招待ユーザを申請元アプリ１０（ゲームＡ）へ招待申請が可能な対応アプリケーションのアプリケーションリストをユーザＸのユーザ端末１００−１（ＳＤＫ１１Ａ）に対して送信する（ＲＥＳ１１）。ユーザ端末１００−１（ＳＤＫ１１Ａ）は、管理サーバ２００からアプリケーションリストを取得すると、取得したアプリケーションリストの中からユーザ端末１００−１にインストールされている対応アプリケーションの少なくとも一部を表示部１２０に表示する。

（２）申請先アプリのフレンド一覧表示（招待ユーザのユーザ端末）
ユーザ端末１００−１の表示部１２０に表示されたアプリケーションリストの中からユーザＸの第２操作により、申請元アプリ１０（ゲームＡ）へ招待したいユーザが登録されている対応アプリケーションが選択される。ここで、上述の第２操作とは、表示部１２０に表示されたアプリケーションリストに含まれる複数の対応アプリケーションのいずれかを選択するための例えば入力部１１０に対する操作である。
アプリケーションリスト含まれる複数の対応アプリケーションのいずれか（ここでは、申請先アプリ２０（ゲームＢ））が選択されると、ユーザ端末１００−１（ＳＤＫ１１Ａ）は、選択された申請先アプリ２０（ゲームＢ）を特定モードで起動させる。

ここで、対応アプリケーションの起動には、「通常モードの起動」と「特定モードの起動」がある。「通常モードの起動」とは、対応アプリケーションを利用（例えば、ゲームをプレイ）する目的での起動であり、「特定モードでの起動」とは、対応アプリケーションが有する機能のうちの特定の機能を呼び出す（実行する）形式の起動である。例えば、申請先アプリ２０（ゲームＢ）を特定モードで起動した場合、申請先アプリ２０（ゲームＢ）は、自身が有する機能のうちの特定の機能を実行する特定モードでの動作状態に移行する。ここでの特定の機能とは、申請先アプリ２０（ゲームＢ）において招待ユーザ（ユーザＸ）と所定の関係（例えば、友だち関係）にあるユーザのユーザリストに対応するフレンド一覧をユーザ端末１００−１の表示部１２０に表示させる機能である。

なお、対応アプリケーションの動作状態の一例として、非動作状態（Not running）と、何らかの処理を実行している動作状態（Active）と、何らかの処理を実行しているが画面に非表示とするバックグラウンド状態（BackGround）と、いずれの処理も実行せずに中断しているサスペンド状態（Suspended）がある。ここで、「対応アプリケーションの起動」とは、非動作状態（Not running）、サスペンド状態（Suspended）、またはサスペンド状態（Suspended）から動作状態（Active）に移行することをいう。また、「対応アプリケーションの終了」とは、動作状態（Active）から、非動作状態（Not running）、サスペンド状態（Suspended）、またはサスペンド状態（Suspended）に移行することをいう。

例えば、上述の申請先アプリ２０（ゲームＢ）を特定モードで起動するとは、申請先アプリ２０（ゲームＢ）を、特定モードの動作状態（Active）に移行することをいう。このとき、申請元アプリ１０（ゲームＡ）は、通常モードの動作状態（Active）から、非動作状態（Not running）、サスペンド状態（Suspended）、またはサスペンド状態（Suspended）に移行する。また、申請先アプリ２０（ゲームＢ）の特定モードの動作が終了するとは、特定モードの動作状態（Active）にある申請先アプリ２０（ゲームＢ）を、非動作状態（Not running）、サスペンド状態（Suspended）、またはサスペンド状態（Suspended）に移行することをいう。

なお、複数の対応アプリケーションが同時に動作状態に成り得る場合には、「対応アプリケーションの起動」とは、例えば、対応アプリケーションが画面の最前面に表示されるなどして、ユーザに対して操作可能な状態に移行することをいう。

ユーザ端末１００−１において、特定モードで起動した申請先アプリ２０（ゲームＢ）は、申請先アプリ２０（ゲームＢ）においてユーザＸと所定の関係（例えば、友だち関係）にあるユーザのユーザリストをアプリサーバ３２０（ゲームＢ）に問い合わせて取得する。そして、ユーザ端末１００−１の申請先アプリ２０（ゲームＢ）のＳＤＫ１１Ｂは、申請先アプリ２０（ゲームＢ）が取得したユーザリストに対応するフレンド一覧を表示部１２０に表示する。

（３）申請先アプリから管理サーバへ招待申請（招待ユーザのユーザ端末）
ユーザ端末１００−１の表示部１２０に表示されたフレンド一覧の中から、申請元アプリ１０（ゲームＡ）へ招待される被招待ユーザであるユーザＹを招待ユーザであるユーザＸが選択すると、ユーザ端末１００−１（ＳＤＫ１１Ｂ）は、選択されたユーザＹを申請元アプリ１０（ゲームＡ）へ招待申請する招待申請情報を管理サーバ２００に対して送信する（ＲＥＱ１３）。このとき被招待ユーザが複数選択されてもよい。複数の被招待ユーザが選択された場合には、ユーザ端末１００−１（ＳＤＫ１１Ｂ）は、それぞれの被招待ユーザに対応する複数の招待申請情報を管理サーバ２００に対して送信する。管理サーバ２００は、ユーザ端末１００−１（ＳＤＫ１１Ｂ）から送信された招待申請情報を受け取ると、受け取った招待申請情報の記録を記憶部２２０に記憶させて管理する。

（４）申請先アプリから管理サーバへ申請照会（被招待ユーザのユーザ端末）
被招待ユーザであるユーザＹのユーザ端末１００−２にインストールされている申請先アプリ２０（ゲームＢ）のＳＤＫ１１Ｂは、管理サーバ２００に管理されている招待申請情報の中に被招待ユーザがユーザＹとなる招待申請情報があるか否かを所定のタイミング（起動時や起動中の所定の時間間隔等）で照会する（ＲＥＱ２１）。被招待ユーザがユーザＹとなる招待申請情報が管理サーバ２００に管理されている場合、管理サーバ２００は、ユーザ端末１００−２（ＳＤＫ１１Ｂ）からの上述の照会に応じて、当該招待申請情報に基づく招待通知情報をユーザ端末１００−２（ＳＤＫ１１Ｂ）に対して送信する（ＲＥＳ２１）。ユーザ端末１００−２（ＳＤＫ１１Ｂ）は、管理サーバ２００から送信された招待通知情報を取得する。

また、ユーザ端末１００−２（ＳＤＫ１１Ｂ）は、管理サーバ２００から招待通知情報を取得した場合、表示部１２０に表示される申請先アプリ２０（ゲームＢ）の起動画面や所定の画面に招待通知情報を取得したことを示す招待通知の表示を行う。これにより、ユーザＸがユーザＹを申請元アプリ１０（ゲームＡ）へ招待する招待申請が申請先アプリ２０（ゲームＢ）を介してユーザＹに通知される。また、ユーザ端末１００−２（ＳＤＫ１１Ｂ）は、取得した招待通知情報に基づいて、招待申請の内容を示す招待情報（招待ユーザを示す情報や申請元アプリ１０（ゲームＡ）を示す情報等）を表示部１２０に表示させる。

（５）申請元アプリのインストール（被招待ユーザのユーザ端末）
被招待ユーザであるユーザＹは、通知された招待申請の承諾も拒否も可能である。なお、通知された招待申請の申請元アプリ１０（ゲームＡ）が既にユーザ端末１００−２にインストールされている場合には、ユーザ端末１００−２（ＳＤＫ１１Ｂ）は、その旨を表示部１２０に表示させてもよい。
通知された招待申請をユーザＹが承諾した場合、ユーザ端末１００−２（ＳＤＫ１１Ｂ）は、承諾した招待申請に対応する招待通知情報を端末記憶部１４０に記憶させる。また、ユーザ端末１００−２は、アプリストア４００から提供されるストアサイトの申請元アプリ１０（ゲームＡ）をダウンロード可能なストアページを表示部１２０に表示する。
ユーザＹは、このストアページから申請元アプリ１０（ゲームＡ）をユーザ端末１００−２にダウンロードしてインストールする。ユーザ端末１００−２にインストールされた申請元アプリ１０（ゲームＡ）が、ユーザＹの操作によって起動すると、当該申請元アプリ１０（ゲームＡ）のＳＤＫ１１Ａは、申請先アプリ２０（ゲームＢ）のＳＤＫ１１Ｂが管理サーバ２００から取得して端末記憶部１４０に記憶させた招待通知情報を取得する。この招待通知情報の有無により、上記招待申請に基づいてインストールされた対応アプリケーションであるか否かが判定できる。

（６）申請先アプリから管理サーバへ招待成立通知（被招待ユーザ端末）
上記招待申請に基づいてユーザ端末１００−２にインストールされた申請元アプリ１０（ゲームＡ）をユーザＹが起動したことや、プレイを開始して予め設定された成果地点に到達したことに基づいて、ユーザ端末１００−２（ＳＤＫ１１Ａ）は、この招待申請による招待が成立したことを示す招待成立情報を管理サーバ２００に対して送信する（ＲＥＱ２２）。ここで、上述の成果地点とは、ある程度ゲームＡが進行した（プレイされた）地点であり、チュートリアルの終了、またはゲーム進行における所定のステージの終了や所定のポイントの獲得などアプリケーション側で任意に設定可能な成果地点である。

（７）管理サーバから申請元アプリのアプリサーバへ招待完了通知
管理サーバ２００は、ユーザ端末１００−２（ＳＤＫ１１Ａ）から送信された招待成立情報を受け取ると、この招待申請による招待が完了したことを示す招待完了通知情報をアプリサーバ３１０（ゲームＡ）に対して送信する（ＲＥＱ２３）。アプリサーバ３１０（ゲームＡ）は、管理サーバ２００から送信された招待完了通知情報を受け取ると、招待が完了（成立）したことによる所定の報酬（例えば、インセンティブ）を申請元アプリ１０（ゲームＡ）におけるユーザＸに対して付与する。この所定の報酬は、例えば、申請元アプリ１０（ゲームＡ）内で使用できる仮想通貨やアイテムである。

このような処理の流れにより、申請元アプリ１０（ゲームＡ）への招待申請が申請先アプリ２０（ゲームＢ）を介して行われる。ここで、相互招待システム５００においては、被招待ユーザを申請元アプリ１０（ゲームＡ）へ招待申請する招待申請情報を、招待ユーザと被招待ユーザとが所定の関係（例えば、友だち関係）にある申請先アプリ２０（ゲームＢ）を介して管理サーバ２００に対して送信することができる。そのため、相互招待システム５００では、ユーザ情報に互換性がないアプリケーション間であっても、あるアプリケーションで所定の関係（例えば、友だち関係）にあるユーザを、他のアプリケーションに招待することができる。

また、相互招待システム５００では、管理サーバ２００が上述の招待申請情報の記録（招待申請記録）を管理することにより、アプリケーション間でユーザ情報が異なる場合の招待処理を管理するため、ＳＮＳにおいて、アプリケーション毎の独自のユーザ情報を紐づけて管理するものとは異なる。よって、相互招待システム５００では、ＳＮＳのような会員ＩＤによるＳＮＳサーバへのログイン操作が不要であり、ユーザは管理サーバ２００の存在を意識する必要なくアプリケーションへの招待が可能である。したがって、本実施形態によれば、アプリケーション間でユーザを招待する際の利便性を向上させることができる。

〔招待処理におけるユーザ端末１００の表示画面例〕
次に、図４を参照して、相互招待システム５００における招待処理において、ユーザ端末１００の表示部１２０に表示される表示画面の一例を説明する。
図４は、招待処理におけるユーザ端末１００の表示画面の表示例を示す図である。この図において、符号（ａ）、（ｂ）、（ｃ）、（ｄ）に示す表示画面は、招待処理の過程（図３の（１）〜（３）の処理の過程）において招待ユーザであるユーザＸのユーザ端末１００−１の表示部１２０に表示される表示画面を示している。また、符号（ｅ）、（ｆ）に示す表示画面は、招待処理の過程（図３の（４）〜（５）の処理の過程）において被招待ユーザであるユーザＹのユーザ端末１００−２の表示部１２０に表示される表示画面を示している。

ここで、符号１２０ａの領域が招待処理に関する表示画面の全体の領域を示している。また、符号１２０ａの領域には、タイトル等が表示される符号１２０ｂの領域と、そのタイトルに対応するコンテンツ等が表示される符号１２０ｃの領域とが含まれている。

まず、招待ユーザであるユーザＸのユーザ端末１００−１の表示部１２０に表示される表示画面について説明する。
（ａ）に示す表示画面は、申請元アプリ１０（ゲームＡ）における招待画面の例である（図３の（１）の処理において表示される表示画面例）。符号１２０ｂの領域には、動作中の申請元アプリ１０（ゲームＡ）のタイトル（ここでは、「ゲームＡ」）が表示される。符号１２０ｃの領域には、他のゲームの友だちを招待する招待処理を開始する「招待ボタン」Ｋ１が表示される。この「招待ボタン」Ｋ１は、アプリケーションリスト要求情報をユーザ端末１００−１（ＳＤＫ１１Ａ）から管理サーバ２００に対して送信させるための操作子として表示される。例えば、ユーザＸがこの「招待ボタン」Ｋ１に対して操作（第１操作）することにより、ユーザ端末１００−１（ＳＤＫ１１Ａ）は、アプリケーションリスト要求情報を管理サーバ２００に対して送信する（図３の（１）のＲＥＱ１１）。

（ｂ）に示す表示画面は、アプリケーションリストに対応した対応アプリケーションの一覧の表示画面（アプリ一覧画面）の例である（図３の（１）の処理において表示される表示画面例）。上述の「招待ボタン」Ｋ１に対する操作に基づいて、ユーザ端末１００−１（ＳＤＫ１１Ａ）は、管理サーバ２００から送信されたアプリケーションリストを取得すると（図３の（１）のＲＥＳ１１）、取得したアプリケーションリストの中からユーザ端末１００−１にインストールされている対応アプリケーションの少なくとも一部をアプリ一覧画面として、招待画面から切り替えて表示部１２０に表示する。符号１２０ｂの領域には、この表示画面のタイトルとして「アプリ一覧」が表示される。符号１２０ｃの領域には、招待申請が可能（被招待ユーザを選択可能）な対応アプリケーションを示す情報が並べて表示される。ここで、この符号１２０ｃに表示される対応アプリケーションを示す情報のそれぞれは、ユーザＸからの操作（第２操作）に応じて対応アプリケーションを選択可能な操作子として表示される。また、符号１２０ｂの領域には、一つ前の表示画面に戻る操作子として「戻るボタン」Ｋ２が表示される。

なお、ユーザ端末１００−１（ＳＤＫ１１Ａ）は、申請元アプリ１０（ゲームＡ）以外の対応アプリケーションがユーザ端末１００−１にインストールされていない場合には、その旨を通知するメッセージ、または、対応アプリケーションを紹介する情報等を表示部１２０に表示する。

（ｃ）に示す表示画面は、フレンド一覧が表示された表示画面（フレンド一覧画面）の例である（図３の（２）の処理において表示される表示画面例）。（ｂ）に示すアプリ一覧画面からユーザＸの操作（第２操作）により選択された申請先アプリ２０（ゲームＢ）が特定モードで起動すると、ユーザ端末１００−１（ＳＤＫ１１Ｂ）は、申請先アプリ２０（ゲームＢ）においてユーザＸと所定の関係（例えば、友だち関係）にあるユーザのユーザリストに対応するフレンド一覧が表示されたフレンド一覧画面を、申請元アプリ１０（ゲームＡ）における表示画面であるアプリ一覧画面から切り替えて表示部１２０に表示する。符号１２０ｂの領域には、この表示画面のタイトルとして「ゲームＢのフレンド一覧」が表示される。符号１２０ｃの領域には、被招待ユーザとして選択可能なユーザを示す情報が並べて表示される。ここで、この符号１２０ｃに表示されるユーザを示す情報のそれぞれは、ユーザＸからの操作に応じて被招待ユーザを選択可能な操作子として表示される。なお、このフレンド一覧画面において被招待ユーザを複数選択することも可能である。例えば、複数のユーザを示す情報それぞれに対応して表示されるチェックボックスのオンとオフ（チェックありとチックなし）を切替えることにより、一または複数のユーザを被招待ユーザとして選択可能である。符号１２０ｂの領域には、符号１２０ｃの領域において選択されたユーザを決定（選択確定）する操作子として「決定ボタン」Ｋ３が表示される。また、符号１２０ｂの領域には、一つ前の表示画面に戻る操作子として「戻るボタン」Ｋ２が表示される。

ユーザ端末１００−１（ＳＤＫ１１Ｂ）は、申請先アプリ２０（ゲームＢ）においてユーザＸと所定の関係（例えば、友だち関係）にあるユーザがいない場合には、その旨を通知するメッセージを表示部１２０に表示する。

（ｄ）に示す表示画面は、被招待ユーザに対する招待申請が完了したことを示す表示画面（招待申請完了画面）の例である（図３の（３）の処理において表示される表示画面例）。ユーザ端末１００−１（ＳＤＫ１１Ｂ）は、（ｃ）に示すフレンド一覧画面からユーザＸの操作に応じて選択されたユーザ（ここでは、ユーザＹ）を被招待ユーザとして、ユーザＹを申請元アプリ１０（ゲームＡ）へ招待申請する招待申請情報を管理サーバ２００に対して送信すると（図３の（３）のＲＥＱ１３）、フレンド一覧画面から切り替えてこの招待申請完了画面を表示部１２０に表示する。符号１２０ｂの領域には、この表示画面のタイトルとして「招待申請完了」が表示される。符号１２０ｃの領域には、ユーザＸからの操作により招待処理を終了する操作子として「終わるボタン」Ｋ４と、招待処理を継続する操作子として「続けるボタン」Ｋ５とが表示される。

「続けるボタン」Ｋ５に対して操作がされた場合には、ユーザ端末１００−１（ＳＤＫ１１Ｂ）は、例えば、（ｃ）に示すフレンド一覧画面に表示を切り替える。一方、「終わるボタン」Ｋ４に対して操作がされると、ユーザ端末１００−１（ＳＤＫ１１Ｂ）は、招待申請完了画面の表示を終了するとともに特定モードの動作を終了する。そして、表示部１２０の表示画面は、申請元アプリ１０（ゲームＡ）における招待画面の表示に戻る。

ここで、上述の（ａ）に示す招待画面、及び（ｂ）に示すアプリ一覧画面は、ユーザ端末１００−１（ＳＤＫ１１Ａ）が、申請元アプリ１０（ゲームＡ）の通常モードの動作において表示する表示画面である。一方、上述の（ｃ）に示すフレンド一覧画面、及び（ｄ）に示す招待申請完了画面は、ユーザ端末１００−１（ＳＤＫ１１Ｂ）が、申請先アプリ２０（ゲームＢ）の特定モードの動作において表示する表示画面である。申請先アプリ２０（ゲームＢ）が特定モードの動作状態（Active）にあって、（ｃ）に示すフレンド一覧画面、又は（ｄ）に示す招待申請完了画面を表示している期間は、申請元アプリ１０（ゲームＡ）の動作状態は、非動作状態（Not running）、サスペンド状態（Suspended）、またはサスペンド状態（Suspended）となっている。

次に、被招待ユーザであるユーザＹのユーザ端末１００−２の表示部１２０に表示される表示画面について説明する。申請先アプリ２０（ゲームＢ）におけるユーザＹを被招待ユーザとした招待申請の通知は、ユーザＹのユーザ端末１００−２において、申請先アプリ２０（ゲームＢ）が通常モードで起動したときに、ユーザＹに通知される。

（ｅ）に示す表示画面は、被招待ユーザがユーザＹとなる招待申請がある場合に、その旨が通知される招待通知画面の例である（図３の（４）の処理において表示される表示画面例）。この招待通知画面は、例えば、申請先アプリ２０（ゲームＢ）の起動画面（起動したときに表示されるゲームのプレイを開始可能な画面）である。符号１２０ｂの領域には、動作中の申請先アプリ２０（ゲームＢ）のタイトル（ここでは、「ゲームＢ」）が表示される。符号１２０ｃの領域には、ユーザＹ宛てに届くメッセージ（お知らせ）の表示領域が含まれ、被招待ユーザがユーザＹとなる招待申請があることを示す招待通知メッセージが表示される。また、この招待通知メッセージは、ユーザＹからの操作に応じて、申請先アプリ２０（ゲームＢ）においてユーザＹ宛に届いている招待情報の一覧を表示する招待情報一覧画面に切り替える操作子として表示される。

（ｆ）に示す表示画面は、招待情報の一覧を表示する招待情報一覧画面の例である（図３の（４）の処理において表示される表示画面例）。ユーザ端末１００−２（ＳＤＫ１１Ｂ）は、（ｅ）に示す招待通知画面に表示された招待通知メッセージに対するユーザＹの操作に応じて、招待通知画面から切り替えて招待情報一覧画面を表示部１２０に表示する。符号１２０ｂの領域には、この表示画面のタイトルとして「招待情報一覧」が表示される。符号１２０ｃの領域には、申請先アプリ２０（ゲームＢ）においてユーザＹ宛に届いている招待情報が並べて表示される。ここで、この招待情報として、招待ユーザを示す情報（例えば、ユーザＸ）と、ユーザＹを招待する対応アプリケーションである申請元アプリ１０（ゲームＡ）を示す情報（例えば、ゲームＡ）とが表示される。また、この招待情報は、ユーザＹからの招待を承諾する操作（第３操作）に応じて、アプリストア４００にアクセスして申請元アプリ１０（ゲームＡ）をダウンロード可能なストアページの表示画面に切り替える操作子として表示される。また、符号１２０ｂの領域には、一つ前の表示画面に戻る操作子として「戻るボタン」Ｋ２が表示される。

〔ユーザ端末１００（ＳＤＫ１１）の機能構成〕
次に、図５を参照して、相互招待システム５００においてユーザ端末１００（ＳＤＫ１１）が実行する招待処理の機能構成について説明する。図５は、本実施形態によるユーザ端末１００において、端末制御部１５０がＳＤＫ１１に基づいて実行する招待処理の機能構成の一例を示す構成図である。

ＳＤＫ１１は、アプリケーションリスト取得部１６１と、特定モード起動部１６２（起動部）と、ユーザリスト取得部１６３と、招待申請通知部１６４と、特定モード終了部１６５と、照会部１６６と、招待通知取得部１６７と、提示部１６８と、画面遷移部１６９と、招待情報管理部１７０と、招待成立通知部１７１とを備えている。

アプリケーションリスト取得部１６１は、相互招待システム５００に対応する複数の対応アプリケーションの一部または全部からなるアプリケーションリストを管理サーバ２００から取得する。例えば、アプリケーションリスト取得部１６１は、通常モードで動作中の対応アプリケーション（申請元アプリ１０）における前述の第１操作に基づいて、上述のアプリケーションリストを要求するアプリケーションリスト要求情報を管理サーバ２００に対して送信する。そして、アプリケーションリスト取得部１６１は、アプリケーションリスト要求情報を取得した管理サーバ２００から送信されたアプリケーションリストを管理サーバ２００から取得する。

特定モード起動部１６２は、アプリケーションリストに含まれる対応アプリケーションの中から選択されたアプリケーションである申請先アプリ２０を特定モードで起動させる。例えば、申請元アプリ１０のＳＤＫ１１Ａの特定モード起動部１６２は、アプリケーションリストに含まれる対応アプリケーションの中から選択された申請先アプリ２０を特定モードで起動させる。ここで、前述したように、申請先アプリ２０を特定モードで起動するとは、例えば、申請先アプリ２０を特定モードの動作状態（Active）に移行することをいう。

また、特定モード起動部１６２は、通常モードで動作中の申請元アプリ１０における招待ユーザ（例えば、ユーザＸ）のユーザＩＤを申請先アプリ２０のＳＤＫ１１Ｂに対して通知する。これにより、申請元アプリ１０における招待ユーザ（例えば、ユーザＸ）のユーザＩＤを申請先アプリ２０のＳＤＫ１１Ｂから管理サーバ２００に対して通知することが可能となる。さらに、特定モード起動部１６２は、通常モードで動作中の申請元アプリ１０のアプリＩＤを申請先アプリ２０に対して通知する。これにより、申請元アプリ１０のアプリＩＤを申請先アプリ２０のＳＤＫ１１Ｂから管理サーバ２００に対して通知することが可能となる。

なお、特定モード起動部１６２は、申請元アプリ１０における招待ユーザ（例えば、ユーザＸ）のユーザＩＤ、又は申請元アプリ１０のアプリＩＤを、申請先アプリ２０のＳＤＫ１１Ｂに対して、直接的又は当該ユーザ端末１００の端末記憶部１４０を介して間接的に通知する。

ユーザリスト取得部１６３は、特定モードで動作中の申請先アプリ２０に対応するアプリサーバ３００（例えば、申請先アプリ２０（ゲームＢ）に対応するアプリサーバ３２０（ゲームＢ））が管理している招待ユーザ（例えば、ユーザＸ）と所定の関係（例えば、友だち関係）にあるユーザのユーザリストを取得する。具体的には、例えば、申請先アプリ２０が申請先アプリ２０に対応するアプリサーバ３００からユーザリストを取得し、申請先アプリ２０が取得したユーザリストを申請先アプリ２０のＳＤＫ１１Ｂが備えるユーザリスト取得部１６３が取得する。即ち、申請先アプリ２０のＳＤＫ１１Ｂが備えるユーザリスト取得部１６３は、申請先アプリ２０を介して申請先アプリ２０に対応するアプリサーバ３００からユーザリストを取得する。

招待申請通知部１６４は、ユーザリスト取得部１６３が取得したユーザリストの中から選択された被招待ユーザ（例えば、ユーザＹ）を、申請元アプリ１０へ招待申請することを示す招待申請情報を管理サーバ２００に対して送信する。この招待申請情報には、例えば、申請元アプリ１０における招待ユーザ（例えば、ユーザＸ）のユーザＩＤ、特定モードで起動された申請先アプリ２０における招待ユーザ（例えば、ユーザＸ）のユーザＩＤ、または、ユーザリストの中から選択された被招待ユーザ（例えば、ユーザＹ）の申請先アプリ２０におけるユーザＩＤが含まれる。これにより、申請元アプリ１０における招待ユーザ（例えば、ユーザＸ）が、申請先アプリ２０において招待ユーザとして、ユーザリストの中から選択された被招待ユーザ（例えば、ユーザＹ）に対して、招待申請することができる。

なお、招待申請情報には、申請元アプリ１０のアプリＩＤがさらに含まれてもよい。また、招待申請情報には、申請先アプリ２０のアプリＩＤがさらに含まれてもよい。

ここで、招待申請情報に含まれる申請元アプリ１０における招待ユーザ（例えば、ユーザＸ）のユーザＩＤ又は申請元アプリ１０のアプリＩＤは、招待ユーザ（例えば、ユーザＸ）のユーザ端末１００にて申請先アプリ２０が、申請元アプリ１０から直接的又は当該ユーザ端末１００の端末記憶部１４０を介して間接的に取得したものである。

特定モード終了部１６５は、特定モードで起動された申請先アプリ２０を終了させる。例えば、特定モードで起動された申請先アプリ２０のＳＤＫ１１Ｂが備える特定モード終了部１６５は、当該ＳＤＫ１１Ｂが備える招待申請通知部１６４が招待申請情報を送信した後に、当該申請先アプリ２０の特定モードの動作を終了させる。ここで、前述したように、申請先アプリ２０の特定モードの動作の終了とは、特定モードの動作状態（Active）にある申請先アプリ２０（ゲームＢ）を、非動作状態（Not running）、サスペンド状態（Suspended）、またはサスペンド状態（Suspended）に移行することをいう。

照会部１６６は、通常モードで動作中の申請先アプリ２０において、被招待ユーザが自ユーザ（例えば、ユーザＹ）となる招待申請情報（即ち、自ユーザに対する招待申請情報）の記録（招待申請記録）の有無を管理サーバ２００に対して照会（申請照会）する。例えば、照会部１６６は、招待申請情報（招待申請記録）に含まれる被招待ユーザの申請先アプリ２０におけるユーザＩＤが、自ユーザ（例えば、ユーザＹ）のユーザＩＤとなる招待申請情報（招待申請記録）の有無を管理サーバ２００に対して照会する。

招待通知取得部１６７は、照会部１６６が照会した結果、自ユーザ（例えば、ユーザＹ）のユーザＩＤが申請先アプリ２０における被招待ユーザのユーザＩＤとなる招待申請情報（招待申請記録）が有る場合に、当該招待申請情報（招待申請記録）に基づく招待通知情報を管理サーバ２００から取得する。

提示部１６８は、取得されたアプリケーションリスト、ユーザリスト等に含まれる各種情報に基づく表示画面を生成して表示部１２０に表示させることにより、当該各種情報を提示する。例えば、提示部１６８（第１提示部、アプリケーションリスト提示部）は、アプリケーションリスト取得部１６１が取得したアプリケーションリストの中からユーザ端末１００にインストールされている対応アプリケーションを提示する（図４の（ｂ）に示すアプリ一覧画面の例参照）。

ここで、アプリケーションリストの中からユーザ端末１００にインストールされている対応アプリケーションを検出する方法としては、例えばＵＲＬスキームを用いる方法がある。ＵＲＬスキームは、アプリケーションまたはアプリケーション内の特定の機能を呼び出すものであり、アプリケーション毎に定められている。そのため、ＵＲＬスキームを利用することによって対応アプリケーションの識別が可能である。

例えば、ユーザ端末１００に対応アプリケーションがインストールされて初めて実行（起動）した際に、当該インストールされた対応アプリケーションのＳＤＫ１１には、初期化処理において当該対応アプリケーションのＵＲＬスキームが設定される。また、アプリケーションリスト取得部１６１は、アプリケーションリストとともに、アプリケーションリストに含まれる対応アプリケーションのそれぞれに対応するＵＲＬスキームを取得する。そして、提示部１６８は、インストールされた対応アプリケーションのＵＲＬスキームと、アプリケーションリストに含まれる対応アプリケーションのＵＲＬスキームとに基づいて、ユーザ端末１００にインストールされている対応アプリケーションを検出し、検出した対応アプリケーションを提示する。

なお、ＯＳの標準の機能等によりユーザ端末１００にインストール済みの対応アプリケーションの一覧が取得可能な場合には、提示部１６８は、このインストール済みの対応アプリケーションの一覧を用いることにより、アプリケーションリストの中からユーザ端末１００にインストールされている対応アプリケーションを検出してもよい。

また、提示部１６８は、ユーザリスト取得部１６３が取得したユーザリストに含まれるユーザの少なくとも一部を提示する。例えば、提示部１６８は、申請先アプリ２０において招待ユーザ（例えば、ユーザＸ）と所定の関係（例えば、友だち関係）にあるユーザのユーザリスト画面（フレンド一覧画面）を表示部１２０に表示させる（図４の（ｃ）に示すフレンド一覧画面の例参照）。

また、提示部１６８（第２提示部、招待情報提示部）は、招待通知取得部１６７が取得した招待通知情報に基づく招待情報を提示する。例えば、提示部１６８は、被招待ユーザが自ユーザ（例えば、ユーザＹ）となる招待情報の一覧を表示する招待情報一覧画面を表示部１２０に表示させる（図４の（ｆ）に示す招待情報一覧画面の例参照）。

画面遷移部１６９は、提示部１６８が提示した招待情報のうちの被招待ユーザによって招待が承諾された招待情報が示す申請元アプリ１０をインストール可能な画面に遷移させる。例えば、画面遷移部１６９は、提示部１６８が提示した招待情報に対する前述の第３操作に基づいて、当該招待情報が示す申請元アプリ１０をインストール可能な画面に遷移させる。
例えば、画面遷移部１６９は、申請元アプリ１０をインストール可能（ダウンロード可能）なストアサイトのストアページを表示するアプリケーション（アプリストア）を起動させる。そして、この起動させたアプリストアが、アプリストア４００から申請元アプリ１０をインストール可能なストアページを取得して表示部１２０に表示させる。

招待情報管理部１７０は、提示部１６８が提示した招待情報のうちの被招待ユーザ（例えば、ユーザＹ）によって招待が承諾された招待情報に対応する招待通知情報をユーザ端末１００の端末記憶部１４０に記憶させる。なお、招待情報管理部１７０は、招待通知情報に含まれる少なくとも一部の情報をユーザ端末１００の端末記憶部１４０に記憶させてもよい。

招待成立通知部１７１は、通常モードで動作中の対応アプリケーションにおいて所定の条件が充足された場合に、ユーザ端末１００の端末記憶部１４０に、当該動作中の対応アプリケーションに対応した招待通知情報が記憶されていることを条件として、当該招待通知情報に対応する招待が成立したことを示す招待成立情報を管理サーバ２００に対して送信する。ここで、上述の対応アプリケーションにおいて所定の条件が充足された場合とは、図３を用いて説明したように、例えば、この対応アプリケーションにおいて予め設定された成果地点に到達した場合である。この成果地点には、対応アプリケーションがインストールされて初めて実行（起動）したときが含まれてもよい。すなわち、対応アプリケーションを通常モードで初めて実行（起動）した場合に所定の条件が充足されることとしてもよい。

ここで、上述の招待成立情報には招待通知情報の一部または全部が含まれている。この招待通知情報の一部または全部は、被招待ユーザのユーザ端末１００にて申請元アプリ１０のＳＤＫ１１Ａが、申請先アプリ２０のＳＤＫ１１Ｂから直接的又は当該ユーザ端末１００の端末記憶部１４０を介して間接的に取得したものである。例えば、被招待ユーザ（例えば、ユーザＹ）のユーザ端末１００（例えば、ユーザ端末１００−２）において、申請元アプリ１０のＳＤＫ１１Ａの招待成立通知部１７１は、申請先アプリ２０のＳＤＫ１１Ｂの招待情報管理部１７０が端末記憶部１４０に記憶させた招待通知情報に含まれる少なくとも一部の情報を取得する。

なお、図５に示すＳＤＫ１１が実行する招待処理の機能構成のうち、例えば、アプリケーションリスト取得部１６１と、特定モード起動部１６２（起動部）と、提示部１６８と、招待情報管理部１７０と、招待成立通知部１７１とが、申請元アプリ１０のＳＤＫ１１Ａの機能構成（すなわち、申請元の機能構成）に対応する。また、例えば、ユーザリスト取得部１６３と、招待申請通知部１６４と、特定モード終了部１６５と、照会部１６６と、招待通知取得部１６７と、提示部１６８と、画面遷移部１６９とが、申請先アプリ２０のＳＤＫ１１Ｂの機能構成（すなわち、申請先の機能構成）に対応する。

〔管理サーバ２００の構成〕
次に、図６を参照して、管理サーバ２００の構成の詳細について説明する。
図６は、本実施形態による管理サーバ２００の構成の一例を示す構成図である。管理サーバ２００は、図３を参照して説明したように、通信部２１０と、記憶部２２０と、制御部２３０とを備えており、ここでは、記憶部２２０と、制御部２３０とのそれぞれの構成について詳しく説明する。

記憶部２２０は、制御部２３０により管理される各種情報を記憶する。この図に示すように、記憶部２２０は、アプリケーション設定記憶部２２１と、招待申請情報記憶部２２２とを備えている。なお、各種情報は、データベースのテーブル形式やＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標）Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式など、その情報の利用に適した形式で格納されていればよい。

アプリケーション設定記憶部２２１は、相互招待システム５００に対応する対応アプリケーションに関する情報（アプリケーション情報）を記憶する。図７は、アプリケーション設定記憶部２２１に記憶されるアプリケーション情報の一例を示す図である。アプリケーション情報には、対応アプリケーションのアプリＩＤ（ApID）と、通知先ＵＲＬ（NoticeURL）と、ストアＵＲＬ（ApStoreURL）と、当該対応アプリケーションの名称を示すアプリ名称（ApNAME）と、当該対応アプリケーションに関する説明情報であるアプリ説明（ApDOC）と、当該対応アプリケーションを示すアイコン画像であるアプリアイコン画像（ApICO）と、再招待許可フラグ（FlagResultInvite）とが関連付けられている。
通知先ＵＲＬ（NoticeURL）は、招待完了通知情報の通知先のＵＲＬ（Uniform Resource Locator）であって、例えば、当該対応アプリケーションに対応するアプリサーバ３００のＵＲＬが設定される。ストアＵＲＬ（ApStoreURL）は、当該対応アプリケーションをダウンロード可能な販売サイト（アプリストア４００）のページのＵＲＬである。アプリＵＲＬスキーム（ApURI）は、当該対応アプリケーションにおいて定められているＵＲＬスキームが設定される。再招待許可フラグ（FlagResultInvite）は、当該対応アプリケーションが再招待可能であるか否かを表すフラグ情報が設定される。例えば、再招待許可フラグ（FlagResultInvite）には、再招待不可である場合にはフラグ「０」が設定され、再招待可である場合にはフラグ「１」が設定される。
なお、これらのアプリケーション情報は、例えば、対応アプリケーションがアプリストア４００からダウンロード可能になる前に予め設定されてアプリケーション設定記憶部２２１に記憶される。

招待申請情報記憶部２２２は、ユーザ端末１００から送信されて管理サーバ２００が取得した招待申請情報に含まれる情報を招待申請記録として記憶する。即ち、招待申請情報記憶部２２２は、申請元アプリ１０の招待ユーザ（例えば、ユーザＸ）が、申請先アプリ２０において招待ユーザと所定の関係（例えば、友だち関係）にある被招待ユーザ（例えば、ユーザＹ）を、申請元アプリ１０へ招待申請する招待申請情報に含まれる情報を招待申請記録として記憶する。

この招待申請記録は、例えば、ユーザ端末１００から送信された招待申請情報を管理サーバ２００が取得したときに、その招待申請情報に対応する新たなレコード（一つ分の招待申請情報のデータ）が生成されて招待申請情報記憶部２２２にその招待申請情報の記録として記憶される。

なお、この招待申請記録は、ユーザ端末１００から取得した招待申請情報に含まれる情報以外の情報も含み、これらの情報の中には招待処理の過程において更新される情報も含む。

図８は、招待申請情報記憶部２２２に記憶される招待申請記録の一例を示す図である。招待申請記録には、招待ＩＤ（InviteID）と、申請元アプリＩＤ（ApIDfrom）と、申請元アプリの招待ユーザＩＤ（Apfrom_UIDfrom）と、申請元アプリの被招待ユーザＩＤ（Apfrom_UIDto）と、申請先アプリＩＤ（ApIDto）と、申請先アプリの招待ユーザＩＤ（Apto_UIDfrom）と、申請先アプリの被招待ユーザＩＤ（Apto_UIDto）と、招待申請の状態（StatusInvite）と、が関連付けられている。

招待ＩＤ（InviteID）は、招待申請記録として記憶される招待申請情報毎に識別可能なように各招待申請情報を取得した順に発行される管理ＩＤである。申請元アプリＩＤ（ApIDfrom）は、申請元アプリ１０のアプリＩＤであり、申請元アプリの招待ユーザＩＤ（Apfrom_UIDfrom）は、招待ユーザの申請元アプリ１０におけるユーザＩＤであり、申請元アプリの被招待ユーザＩＤ（Apfrom_UIDto）は、被招待ユーザの申請元アプリ１０におけるユーザＩＤである。申請先アプリＩＤ（ApIDto）は、申請先アプリ２０のアプリＩＤであり、申請先アプリの招待ユーザＩＤ（Apto_UIDfrom）は、招待ユーザの申請先アプリ２０におけるユーザＩＤであり、申請先アプリの被招待ユーザＩＤ（Apto_UIDto）は、被招待ユーザの申請先アプリ２０におけるユーザＩＤである。

招待申請の状態（StatusInvite）は、ユーザ端末１００から送信された招待申請情報に基づく招待処理の進行度合いの状態を表すフラグ情報が設定される。例えば、招待申請の状態（StatusInvite）には、管理サーバ２００が受け取った招待申請情報に基づく招待通知情報が被招待ユーザへ未通知の状態ではフラグ「０」（招待申請未通知）が設定され、被招待ユーザへ通知済となった場合にフラグ「０」からフラグ「１」（招待申請通知済）に更新される。また、この招待申請情報に対応する招待成立情報を、被招待ユーザのユーザ端末１００から管理サーバ２００が受け取った場合、招待申請の状態（StatusInvite）は、フラグ「１」からフラグ「２」（招待成立未通知）に更新される。さらに、管理サーバ２００が受け取った招待成立情報に基づいて、招待成立したことを申請元アプリ１０に対して通知する招待成立通知情報を、申請元アプリ１０に対応するアプリサーバ３００に送信した場合、招待申請の状態（StatusInvite）は、フラグ「２」からフラグ「３」（招待成立通知済）に更新される。また、管理サーバ２００が受け取った招待申請情報が被招待ユーザによって拒否された場合、及び招待申請の状態（StatusInvite）にフラグ「０」またはフラグ「１」が設定されている状態が予め定められた時間以上経過した場合や招待申請が拒否された場合、招待申請の状態（StatusInvite）は、招待が失敗したことを示すフラグ「−１」（失敗）に更新される。

なお、招待申請記録には、申請先アプリの招待ユーザ名（Apto_NAMEfrom）と、申請先アプリの招待ユーザ画像ＵＲＬ（Apto_URLfrom）とがさらに関連付けられていてもよい。ここで、申請先アプリの招待ユーザ名（Apto_NAMEfrom）は、招待ユーザの申請先アプリ２０におけるユーザ名であり、申請先アプリの招待ユーザ画像ＵＲＬ（Apto_URLfrom）は、招待ユーザの申請先アプリ２０におけるユーザ画像のリンク先を示すＵＲＬである。これらの情報は、図３に示す（１）から（７）の招待処理の流れにおいて必ずしも必要ではないが、これらの情報が招待申請記録（招待申請情報）に含まれることにより、招待通知情報を受け取った被招待ユーザのユーザ端末１００の申請先アプリ２０において、ＳＤＫ１１Ｂの処理だけで招待ユーザのユーザ名やユーザ画像を表示することが可能となる。

制御部２３０は、申請元アプリ１０および申請先アプリ２０がインストールされた招待ユーザのユーザ端末１００から、当該申請先アプリ２０で当該招待ユーザと所定の関係にある被招待ユーザの、当該申請先アプリ２０がインストールされたユーザ端末１００に対して、当該申請元アプリ１０をインストールさせる招待処理を制御する。この図に示すように、制御部２３０は、アプリケーション管理部２３１と、アプリケーションリスト通知部２３２と、招待申請受取部２３３と、招待申請管理部２３４と、申請照会部２３５と、招待通知部２３６と、招待成立受取部２３７と、招待成立処理部２３８とを備えている。

アプリケーション管理部２３１は、相互招待システム５００に対応する対応アプリケーションに関する情報を管理する。このアプリケーション管理部２３１が管理する対応アプリケーションに関する情報は、例えば、相互招待システム５００に対応する対応アプリケーションがアプリストア４００からダウンロード可能になる前に予め設定されてアプリケーション設定記憶部２２１に記憶される。

アプリケーションリスト通知部２３２は、ユーザ端末１００からの要求に基づいて、アプリケーション管理部２３１を参照して、対応アプリケーションのアプリケーションリストをユーザ端末１００に対して送信する。例えば、アプリケーションリスト通知部２３２は、招待ユーザ（例えば、ユーザＸ）のユーザ端末１００（例えば、ユーザ端末１００−１）の申請元アプリ１０に対して、申請元アプリ１０への招待申請が可能な対応アプリケーションのアプリケーションリストを送信する。

招待申請受取部２３３は、ユーザ端末１００から送信された招待申請情報を受け取る。具体的には、招待申請受取部２３３は、招待ユーザのユーザ端末１００においてアプリケーションリストから選択されることにより起動（特定モードで起動）された申請先アプリ２０から送信された被招待ユーザを申請元アプリ１０へ招待申請する招待申請情報を受け取る。

例えば、招待申請受取部２３３は、招待ユーザ（例えば、ユーザＸ）のユーザ端末１００（例えば、ユーザ端末１００−１）においてアプリケーションリストから選択されることにより起動（特定モードで起動）された申請先アプリ２０から送信された被招待ユーザ（例えば、ユーザＹ）を申請元アプリ１０へ招待申請する招待申請情報を受け取る。

ここで、この招待申請情報には、例えば、申請元アプリ１０における招待ユーザ（例えば、ユーザＸ）のユーザＩＤ、申請先アプリ２０における招待ユーザ（例えば、ユーザＸ）のユーザＩＤ、および申請先アプリ２０において所定の関係（例えば、友だち関係）にあるユーザのうちの選択されたユーザである被招待ユーザ（例えば、ユーザＹ）のユーザＩＤが含まれる。また、この招待申請情報には、申請元アプリ１０のアプリＩＤ、および申請先アプリ２０のアプリＩＤが含まれる。そして、招待申請受取部２３３は、受け取った招待申請情報を招待申請管理部２３４に供給する。

招待申請管理部２３４は、招待申請受取部２３３が受け取った招待申請情報に含まれるそれぞれのアプリＩＤ及びユーザＩＤを関連付けて招待申請記録として招待申請情報記憶部２２２に記憶させて管理する。例えば、招待申請管理部２３４は、その招待申請情報に対応する新たなレコードを生成して招待申請記録として招待申請情報記憶部２２２に記憶させる。

申請照会部２３５は、被招待ユーザのユーザ端末１００の申請先アプリ２０からの照会（申請照会）に基づいて、招待申請情報記憶部２２２を参照して、申請先アプリ２０における当該被招待ユーザに対する招待申請記録（当該被招待ユーザへの招待申請情報の記録）の有無を照会する。例えば、申請照会部２３５は、被招待ユーザ（例えば、ユーザＹ）のユーザ端末１００（例えば、ユーザ端末１００−２）からの照会（申請照会）に含まれる申請先アプリ２０における被招待ユーザ（例えば、ユーザＹ）のユーザＩＤに対する招待申請記録（招待申請情報）の有無を照会する。

招待通知部２３６は、申請照会部２３５が照会した結果、被招待ユーザ（例えば、ユーザＹ）に対する招待申請記録（招待申請情報）が有る場合に当該被招待ユーザ（例えば、ユーザＹ）のユーザ端末１００（例えば、ユーザ端末１００−２）の申請先アプリ２０に対して、当該招待申請記録（招待申請情報）に基づく招待通知情報を送信する。当該招待申請記録（招待申請情報）に基づく招待通知情報は、当該招待申請記録（招待申請情報）に含まれる情報の少なくとも一部を含む招待通知情報である。

招待成立受取部２３７は、被招待ユーザ（例えば、ユーザＹ）のユーザ端末１００（例えば、ユーザ端末１００−２）で申請元アプリ１０（招待された対応アプリケーション）が起動したことや、予め設定された成果地点に到達したことに基づいて、招待通知情報に対応する招待が成立したことを示す招待成立情報を、当該被招待ユーザ（例えば、ユーザＹ）のユーザ端末１００（例えば、ユーザ端末１００−２）の申請元アプリ１０から受け取る。

招待成立処理部２３８は、招待成立受取部２３７が受け取った招待成立情報に基づく所定の処理を行う。例えば、招待成立処理部２３８は、管理サーバ２００が受け取った招待成立情報に基づいて、申請元アプリ１０への招待が成立したことを通知する招待成立通知情報を、申請元アプリ１０に対応するアプリサーバ３００（例えば、申請元アプリ１０（ゲームＡ）に対応するアプリサーバ３１０（ゲームＡ））に送信する。

〔招待処理の動作の詳細〕
次に、図９および図１０を参照して、本実施形態による相互招待システム５００の招待処理の動作の詳細について説明する。図９及び図１０は、本実施形態による招待処理の動作の一例を示すフローチャートである。この図９及び図１０に示す処理は、図３を参照して説明した概略処理の流れの詳細例を示すものである。

まず、図９を参照して、招待ユーザであるユーザＸのユーザ端末１００−１と管理サーバ２００とが実行する処理について説明する。即ち、図３に示す（１）の処理から（３）の処理までの詳細例を説明する。

（１）申請元アプリから管理サーバへアプリケーションリスト要求（招待ユーザのユーザ端末）
招待ユーザであるユーザＸのユーザ端末１００−１にインストールされている申請元アプリ１０（ゲームＡ）のＳＤＫ１１Ａは、他のゲームの友だちを招待する招待処理を開始する招待画面（図４の（ａ）に示す招待画面の例参照）を表示部１２０に表示させる（ステップＳＡ１１０）。

表示部１２０に表示された招待画面に対してユーザＸによる操作（第１操作）がされると、ユーザ端末１００−１のＳＤＫ１１Ａのアプリケーションリスト取得部１６１は、複数の対応アプリケーションの一部または全部からなる招待可能なアプリケーションリストを要求するアプリケーションリスト要求情報を管理サーバ２００に対して送信する（ＲＥＱ１１、ステップＳＡ１２０）。ここで、アプリケーションリスト要求情報には、申請元アプリＩＤ（ApIDfrom）が含まれている。ここでは、申請元アプリＩＤ（ApIDfrom）には、申請元アプリ１０（ゲームＡ）のアプリＩＤが設定されている。

管理サーバ２００のアプリケーションリスト通知部２３２は、ユーザ端末１００−１（ＳＤＫ１１Ａ）からアプリケーションリスト要求情報を取得すると、アプリケーション管理部２３１が管理するアプリケーション設定記憶部２２１を参照して、対応アプリケーションのアプリケーションリストをユーザ端末１００−１（ＳＤＫ１１Ａ）に対して送信する。例えば、アプリケーションリスト通知部２３２は、取得したアプリケーションリスト要求情報に含まれる申請元アプリＩＤ（ApIDfrom）に基づいて、アプリケーションリスト要求情報を送信した申請元アプリ１０（ゲームＡ）が相互招待システム５００に参加していることを確認する。そして、アプリケーションリスト通知部２３２は、相互招待システム５００に参加している申請元アプリ１０（ゲームＡ）からの要求に対しては、対応アプリケーションのアプリケーションリストを送信する（ＲＥＳ１１、ステップＳＥ１１０）。

ここで、アプリケーションリスト通知部２３２がユーザ端末１００−１（ＳＤＫ１１Ａ）に対して送信するアプリケーションリストには、例えば、一または複数の対応アプリケーションのアプリＩＤ（ApID）が含まれる。この一または複数の対応アプリケーションのアプリＩＤ（ApID）には、アプリケーションリストに含まれる対応アプリケーションのアプリＩＤが設定される。

なお、アプリケーションリスト通知部２３２は、取得したアプリケーションリスト要求情報に含まれる申請元アプリＩＤ（ApIDfrom）に基づいて、アプリケーションリスト要求情報を送信した申請元アプリ１０（ゲームＡ）を除いた対応アプリケーションのアプリケーションリストをユーザ端末１００−１（ＳＤＫ１１Ａ）に対して送信してもよい。また、アプリケーションリスト通知部２３２がユーザ端末１００−１（ＳＤＫ１１Ａ）に対して送信するアプリケーションリストには、一または複数の対応アプリケーションのアプリＩＤ（ApID）に関連付けて、それぞれの対応アプリケーションのＵＲＬスキームを送信してもよい。

次に、ユーザ端末１００−１のＳＤＫ１１Ａのアプリケーションリスト取得部１６１は、管理サーバ２００から送信された招待可能なアプリケーションリストを取得する（ステップＳＡ１３０）。また、アプリケーションリスト取得部１６１は、取得したアプリケーションリストを提示部１６８に供給する。

ユーザ端末１００−１のＳＤＫ１１Ａの提示部１６８は、アプリケーションリスト取得部１６１が取得したアプリケーションリストに含まれる対応アプリケーションの中からユーザ端末１００−１にインストールされているアプリケーションを検出する。例えば、提示部１６８は、アプリケーションリスト取得部１６１が取得したアプリケーションリストに含まれる対応アプリケーションそれぞれのＵＲＬスキームを用いて、ユーザ端末１００−１にインストールされている対応アプリケーションを検出する（ステップＳＡ１４０）。

そして、提示部１６８は、検出結果に基づいて、アプリケーションリスト取得部１６１が取得したアプリケーションリストに含まれる対応アプリケーションの中からユーザ端末１００−１にインストールされている対応アプリケーションが検出された場合には、その少なくとも一部を表示部１２０に表示させる（図４の（ｂ）に示すアプリ一覧画面の例参照、ステップＳＡ１５０）。また、提示部１６８は、ユーザ端末１００−１にインストールされている申請元アプリ１０（ゲームＡ）以外の対応アプリケーションが検出されなかった場合には、その旨を通知するメッセージを表示部１２０に表示させる。

（２）申請先アプリのフレンド一覧表示（招待ユーザのユーザ端末）
ユーザ端末１００−１の表示部１２０に表示されたアプリケーションリストに対するユーザＸの操作（第２操作）により、申請先アプリ２０（ゲームＢ）が選択されたとする。この場合、ユーザ端末１００−１のＳＤＫ１１Ａの特定モード起動部１６２は、申請先アプリ２０（ゲームＢ）を特定モードで起動させる（ステップＳＡ１６０）。
このとき、特定モード起動部１６２は、申請元アプリ１０（ゲームＡ）のアプリＩＤが設定された申請元アプリＩＤ（ApIDfrom）と、申請元アプリ１０（ゲームＡ）におけるユーザＸのユーザＩＤが設定された申請元アプリの招待ユーザＩＤ（Apfrom_UIDfrom）とを、申請先アプリ２０（ゲームＢ）のＳＤＫ１１Ｂに対して通知する。

次に、特定モードで起動した申請先アプリ２０（ゲームＢ）がアプリサーバ３２０（ゲームＢ）からユーザリストを取得する。なお、このユーザリストを取得する処理（以下のステップＳＢ１１０及びＳＢ１２０の処理）は、ＳＤＫ１１Ａが実行する処理ではなく、申請先アプリ２０（ゲームＢ）が実行する処理である。

ユーザ端末１００−１において特定モードで起動した申請先アプリ２０（ゲームＢ）は、申請先アプリ２０（ゲームＢ）においてユーザＸと所定の関係（例えば、友だち関係）にあるユーザのユーザリストを要求するフレンド一覧要求情報をアプリサーバ３２０（ゲームＢ）に送信する（ステップＳＢ１１０）。ここで、フレンド一覧要求情報には、ＳＤＫ１１ＡからＳＤＫ１１Ｂに対して通知された申請先アプリ２０（ゲームＢ）におけるユーザＸのユーザＩＤが含まれる。

アプリサーバ３２０（ゲームＢ）は、ユーザ端末１００−１の申請先アプリ２０（ゲームＢ）からフレンド一覧要求情報を取得すると、申請先アプリ２０（ゲームＢ）においてユーザＸと所定の関係（例えば、友だち関係）にあるユーザのユーザリストを、ユーザ端末１００−１（申請先アプリ２０（ゲームＢ））に対して送信する（ステップＳＤ１１０）。

ユーザ端末１００−１の申請先アプリ２０（ゲームＢ）は、アプリサーバ３２０（ゲームＢ）からユーザリストを取得する（ステップＳＢ１２０）。また、申請先アプリ２０（ゲームＢ）は、取得したユーザリストをＳＤＫ１１Ｂに受け渡す。これにより、ユーザ端末１００−１のＳＤＫ１１Ｂのユーザリスト取得部１６３は、この申請先アプリ２０（ゲームＢ）が取得したユーザリストを取得する。

次に、ユーザ端末１００−１のＳＤＫ１１Ｂの提示部１６８は、申請先アプリ２０（ゲームＢ）が取得したユーザリストに含まれるユーザの少なくとも一部をフレンド一覧として表示部１２０に表示させる。即ち、提示部１６８は、申請先アプリ２０（ゲームＢ）においてユーザＸ（招待ユーザ）と所定の関係（例えば、友だち関係）にあるユーザのユーザリストに対応するフレンド一覧を表示部１２０に表示させる（図４の（ｃ）に示すフレンド一覧画面の例参照、ステップＳＢ１５０）。

（３）申請先アプリから管理サーバへ招待申請（招待ユーザのユーザ端末）
ユーザ端末１００−１の表示部１２０に表示されたフレンド一覧の中から、申請元アプリ１０（ゲームＡ）へ招待するユーザ（ここでは、ユーザＹ）をユーザＸが選択すると、ユーザ端末１００−１のＳＤＫ１１Ｂの招待申請通知部１６４は、選択されたユーザＹを被招待ユーザとして申請元アプリ１０（ゲームＡ）へ招待申請する招待申請情報を管理サーバ２００に対して送信する（ＲＥＱ１３、ステップＳＢ１６０）。

ここで、招待申請情報には、申請元アプリ１０（ゲームＡ）におけるユーザＸ（招待ユーザ）のユーザＩＤと、申請先アプリ２０（ゲームＢ）におけるユーザＸ（招待ユーザ）のユーザＩＤと、申請先アプリ２０（ゲームＢ）におけるユーザＹ（被招待ユーザ）のユーザＩＤとが含まれる。また、招待申請情報には、申請元アプリ１０（ゲームＡ）のアプリＩＤと、申請先アプリ２０（ゲームＢ）のアプリＩＤとが含まれる。

管理サーバ２００の招待申請受取部２３３は、ユーザ端末１００−１（ＳＤＫ１１Ｂ）から送信された招待申請情報を受け取る。そして、招待申請受取部２３３は、受け取った招待申請情報を招待申請管理部２３４に供給する。招待申請管理部２３４は、招待申請受取部２３３が受け取った招待申請情報に対応する新たなレコードを生成して招待申請記録として招待申請情報記憶部２２２に記憶させる（ステップＳＥ１３０）。

ここで、招待申請情報記憶部２２２に招待申請記録として記憶される招待申請情報の新たなレコードは、招待申請受取部２３３が受け取った招待申請情報に含まれる情報に基づいて、次のように設定される。申請元アプリＩＤ（ApIDfrom）には申請元アプリ１０（ゲームＡ）のアプリＩＤが設定され、申請元アプリの招待ユーザＩＤ（Apfrom_UIDfrom）には申請元アプリ１０（ゲームＡ）におけるユーザＸ（招待ユーザ）のユーザＩＤが設定される。申請先アプリＩＤ（ApIDto）には申請先アプリ２０（ゲームＢ）のアプリＩＤが設定され、申請先アプリの招待ユーザＩＤ（Apto_UIDfrom）には申請先アプリ２０（ゲームＢ）におけるユーザＸ（招待ユーザ）のユーザＩＤが設定され、申請先アプリの被招待ユーザＩＤ（Apto_UIDto）には申請先アプリ２０（ゲームＢ）におけるユーザＹ（被招待ユーザ）のユーザＩＤが設定される。

また、招待申請の状態（StatusInvite）にはフラグ「０」（招待申請未通知）が設定される。なお、申請元アプリの被招待ユーザＩＤ（Apfrom_UIDto）は、ユーザＹ（被招待ユーザ）が申請元アプリ１０（ゲームＡ）をユーザ端末１００−２にインストールした後に設定されるため、新にレコード生成した場合には例えば「ｎｕｌｌ」が設定される。

なお、ユーザ端末１００−１のＳＤＫ１１Ｂの提示部１６８は、招待申請通知部１６４が招待申請情報を管理サーバ２００に対して送信した後に、被招待ユーザに対する招待申請が完了したことを示す招待申請完了画面を表示部１２０に表示させる（図４の（ｄ）に示す招待完了画面の例参照）。

次に、ユーザ端末１００−１のＳＤＫ１１Ｂの特定モード終了部１６５は、特定モードで起動された申請先アプリ２０（ゲームＢ）を終了させる（ステップＳＢ１７０）。申請先アプリ２０（ゲームＢ）が終了することにより、ユーザ端末１００−１の表示部１２０の表示は、申請元アプリ１０（ゲームＡ）の招待画面（ステップＳＡ１１０において表示された招待画面）の表示に戻る（ステップＳＡ１７０）。このとき、申請元アプリ１０（ゲームＡ）が非動作状態（Not running）、サスペンド状態（Suspended）、またはサスペンド状態（Suspended）の場合には、通常モードの動作状態（Active）に移行させる。

このように、図９を参照して説明したここまでの処理により、ユーザＸ（招待ユーザ）が申請先アプリ２０（ゲームＢ）において所定の関係（例えば、友だち関係）にあるユーザＹ（被招待ユーザ）を申請元アプリ１０（ゲームＡ）へ招待申請することができる。

次に、図１０を参照して、被招待ユーザであるユーザＹのユーザ端末１００−２と管理サーバ２００とが実行する処理について説明する。即ち、図３に示す（４）の処理から（７）の処理までの詳細例を説明する。

（４）申請先アプリから管理サーバへ申請照会（被招待ユーザのユーザ端末）
被招待ユーザであるユーザＹのユーザ端末１００−２にインストールされている申請先アプリ２０（ゲームＢ）が通常モードで起動すると、申請先アプリ２０（ゲームＢ）は、起動画面を表示部１２０に表示させる（ステップＳＢ２１０）。

ユーザ端末１００−２において申請先アプリ２０（ゲームＢ）が通常モードで起動すると、申請先アプリ２０（ゲームＢ）のＳＤＫ１１Ｂの照会部１６６は、被招待ユーザがユーザＹ（自ユーザ）となる招待申請情報（招待申請記録）の有無を管理サーバ２００に対して照会（申請照会）する。例えば、照会部１６６は、被招待ユーザがユーザＹ（自ユーザ）となる招待申請情報（招待申請記録）の有無を照会する申請照会情報であって、申請先アプリＩＤ（ApIDto）と申請先アプリの被招待ユーザＩＤ（Apto_UIDto）とを含む申請照会情報を管理サーバ２００に対して送信する（ＲＥＱ２１、ステップＳＢ２２０）。

ここで、申請先アプリＩＤ（ApIDto）には申請先アプリ２０（ゲームＢ）のアプリＩＤが設定され、申請先アプリの被招待ユーザＩＤ（Apto_UIDto）には申請先アプリ２０（ゲームＢ）におけるユーザＹのユーザＩＤが設定されている。

管理サーバ２００の申請照会部２３５は、ユーザ端末１００−２（ＳＤＫ１１Ｂ）から申請照会情報を取得すると、招待申請情報記憶部２２２に記憶されている招待申請記録を参照して、招待申請の状態（StatusInvite）がフラグ「０」（招待申請未通知）となっている、申請先アプリ２０（ゲームＢ）におけるユーザＹが被招待ユーザとなる招待申請記録（即ち、ユーザＹに対する招待申請記録）の有無を照会する。具体的には、申請照会部２３５は、取得した申請照会情報に基づいて、招待申請情報記憶部２２２に記憶されている招待申請記録の中に、申請先アプリＩＤ（ApIDto）に申請先アプリ２０（ゲームＢ）のアプリＩＤが設定され、且つ申請先アプリの被招待ユーザＩＤ（Apto_UIDto）に申請先アプリ２０（ゲームＢ）におけるユーザＹのユーザＩＤが設定されている招待申請記録があるか否かを照会する。

申請照会部２３５が紹介した結果、申請先アプリ２０（ゲームＢ）におけるユーザＹが被招待ユーザとなる招待申請記録がある場合には、招待通知部２３６は、ユーザＹのユーザ端末１００−２（ＳＤＫ１１Ｂ）に対して、当該招待申請記録（招待申請情報）に基づく招待通知情報を送信する（ＲＥＳ２１、ステップＳＥ２１０）。

また、管理サーバ２００の招待申請管理部２３４は、招待通知部２３６が招待通知情報をユーザＹのユーザ端末１００−２（ＳＤＫ１１Ｂ）に対して送信すると、招待申請情報記憶部２２２に記憶される招待申請記録に含まれる招待申請の状態（StatusInvite）を、フラグ「０」（招待申請未通知）からフラグ「１」（招待申請通知済）に更新する。

ここで、招待通知情報には、当該招待申請記録（招待申請情報）に含まれる情報の少なくとも一部が含まれる。例えば、招待通知情報には、当該招待申請記録（招待申請情報）に含まれる招待ＩＤ（InviteID）と、申請元アプリＩＤ（ApIDfrom）と、申請先アプリの招待ユーザＩＤ（Apto_UIDfrom）と、申請先アプリの招待ユーザ名（Apto_NAMEfrom）と、申請先アプリの招待ユーザ画像ＵＲＬ（Apto_URLfrom）とが含まれる。

次に、ユーザ端末１００−２のＳＤＫ１１Ｂの招待通知取得部１６７は、管理サーバ２００から送信された招待通知情報を取得する。即ち、招待通知取得部１６７は、照会部１６６が照会した結果、ユーザＹ（自ユーザ）のユーザＩＤが申請先アプリ２０（ゲームＢ）における被招待ユーザのユーザＩＤとなる招待申請情報記録が有る場合に、当該招待申請記録（招待申請情報）に基づく招待通知情報を管理サーバ２００から取得する。（ステップＳＢ２３０）。

また、ユーザＹが被招待ユーザとなる招待申請記録がある場合、ユーザ端末１００−２の申請先アプリ２０（ゲームＢ）は、ユーザＹが被招待ユーザとなる招待申請があることを示す招待通知メッセージが表示された起動画面（図４の（ｅ）に示す招待通知画面の例参照）を表示部１２０に表示させる（ステップＳＢ２４０）。なお、この起動画面は、ステップＳＢ２１０において表示部１２０に表示された申請先アプリ２０（ゲームＢ）の起動画面であって、ＳＤＫ１１Ｂの処理ではなく申請先アプリ２０（ゲームＢ）の処理によって表示部１２０に表示される。

次に、ユーザ端末１００−２のＳＤＫ１１Ｂの提示部１６８は、招待通知取得部１６７が取得した招待通知情報に基づく招待情報を提示する。例えば、提示部１６８は、ユーザＹ（自ユーザ）が被招待ユーザとなる招待情報の一覧を表示する招待情報一覧画面（図４の（ｆ）に示す招待情報一覧画面の例参照）を表示部１２０に表示させる（ステップＳＢ２５０）。

ここで、招待情報一覧画面に表示される招待情報には、招待ユーザのユーザ名またはユーザ画像が表示される。本実施形態では、招待通知情報に招待ユーザ名（Apto_NAMEfrom）と招待ユーザ画像ＵＲＬ（Apto_URLfrom）を含ませているため、ユーザ端末１００−２のＳＤＫ１１Ｂの処理だけで、招待情報一覧画面に招待ユーザのユーザ名またはユーザ画像を表示させることを可能としている。例えば、図４の（ｆ）に示す招待情報一覧画面の例では、招待ユーザのユーザ名が表示される例を示しているが、この招待ユーザのユーザ名に対応付けてその招待ユーザのユーザ画像を表示させてもよい。

なお、招待情報に招待ユーザのユーザ名やユーザ画像が含まれない構成とした場合には、招待ユーザＩＤ（Apto_UIDfrom）に対応したユーザ名やユーザ画像を、例えば、アプリサーバ３２０から直接的または申請先アプリ２０（ゲームＢ）を介して取得する必要があるため処理が複雑になる。

なお、ユーザ端末１００−２のＳＤＫ１１Ｂの提示部１６８は、招待通知取得部１６７が取得した招待通知情報に基づく招待情報を提示する際に、ＵＲＬスキームを用いて、ユーザ端末１００−２にインストールされている対応アプリケーションを検出してもよい。そして、このＳＤＫ１１Ｂの提示部１６８は、招待しようとする申請元アプリ１０（ゲームＡ）がインストールされていると検出された場合には、該当する招待情報を除外して招待情報一覧画面を表示部１２０に表示させるようにしたり、該当する招待情報にインストール済みである旨の情報を付加して招待情報一覧画面を表示部１２０に表示させるようにしたりしてもよい。

（５）申請元アプリのインストール（被招待ユーザのユーザ端末）
表示部１２０に表示された招待情報一覧画面において、被招待ユーザであるユーザＹが申請元アプリ１０（ゲームＡ）への招待を承諾する操作（第３操作）がされると（ステップＳＢ２６０）、ユーザ端末１００−２のＳＤＫ１１Ｂの招待情報管理部１７０は、承諾された招待情報に対応する招待通知情報に含まれる少なくとも一部の情報をユーザ端末１００の端末記憶部１４０に記憶させる（ステップＳＢ２７０）。

また、ユーザ端末１００−２のＳＤＫ１１Ｂの画面遷移部１６９は、アプリストア４００にアクセスして申請元アプリ１０（ゲームＡ）をダウンロード可能なストアページを表示するアプリストアを起動させる（ステップＳＢ２８０）。

（６）申請先アプリから管理サーバへ招待成立通知（被招待ユーザ端末）
上記招待申請に基づいてユーザ端末１００−２に申請元アプリ１０（ゲームＡ）がインストールされた後に、当該申請元アプリ１０（ゲームＡ）が通常モードで起動したとする。例えば、ユーザＹは、ステップＳＢ２８０において起動したアプリストアから申請元アプリ１０（ゲームＡ）をユーザ端末１００−２にダウンロードし、インストールされた申請元アプリ１０（ゲームＡ）を起動したとする。

ユーザ端末１００−２にインストールされた申請元アプリ１０（ゲームＡ）のＳＤＫ１１Ａの招待情報管理部１７０は、端末記憶部１４０に記憶されている招待通知情報を取得する（ステップＳＡ２１０）。

ユーザ端末１００−２においては、申請元アプリ１０（ゲームＡ）をユーザＹがプレイしてゲームを進行させる（ステップＳＡ２２０）。そして、申請元アプリ１０（ゲームＡ）は、所定の成果地点に到達したか否かを判定する（ステップＳＡ２３０）。なお、このステップＳＡ２２０及びステップＳＡ２３０の処理は、ＳＤＫ１１Ａが実行する処理ではなく申請元アプリ１０（ゲームＡ）が実行する処理である。

ユーザ端末１００−２にインストールされて起動した申請元アプリ１０（ゲームＡ）のゲーム進行に応じて、所定の成果地点に到達した場合（ステップＳＡ２３０：ＹＥＳ）、申請元アプリ１０（ゲームＡ）は、当該到達したことを示す情報を当該申請元アプリ１０（ゲームＡ）のＳＤＫ１１Ａに受け渡す。一方、所定の成果地点に到達していない場合（ステップＳＡ２３０：ＮＯ）、所定の成果地点に到達するまで、申請元アプリ１０（ゲームＡ）におけるゲームの進行が継続される。

ユーザ端末１００−２のＳＤＫ１１Ａが、所定の成果地点に到達したことを示す情報を申請元アプリ１０（ゲームＡ）から受け取った場合、ＳＤＫ１１Ａの招待成立通知部１７１は、当該申請元アプリ１０（ゲームＡ）に対応した招待通知情報が端末記憶部１４０に記憶されていることを条件として、当該招待通知情報に対応する招待が成立したことを示す招待成立情報を管理サーバ２００に対して送信する（ＲＥ２２、ステップＳＡ２４０）。ここで、招待成立情報には、例えば、招待ＩＤ（InviteID）と、申請元アプリの被招待ユーザＩＤ（Apfrom_UIDto）とが含まれる。招待ＩＤ（InviteID）には、この招待成立情報に対応する招待通知情報に含まれていた招待ＩＤ（InviteID）が設定される。申請元アプリの被招待ユーザＩＤ（Apfrom_UIDto）には、申請元アプリ１０（ゲームＡ）におけるユーザＹのユーザＩＤが設定される。なお所定の成果地点には、ユーザ端末１００−２に申請元アプリ１０（ゲームＡ）がインストールされて初めて実行（起動）したときが含まれてもよい。

（７）管理サーバから申請元アプリのアプリサーバへ招待完了通知
管理サーバ２００の招待成立受取部２３７は、ユーザ端末１００−２（ＳＤＫ１１Ａ）から送信された申請元アプリ１０（ゲームＡ）における招待成立情報を受け取る（ステップＳＥ２２０）。また、招待成立受取部２３７は、招待成立受取部２３７が受け取った招待成立情報を招待申請管理部２３４に供給する。
招待申請管理部２３４は、当該招待成立情報に基づいて、招待申請情報記憶部２２２に記憶されている招待申請記録に含まれる申請元アプリの被招待ユーザＩＤ（Apfrom_UIDto）に、申請元アプリ１０（ゲームＡ）におけるユーザＹのユーザＩＤを設定する。また、招待申請管理部２３４は、招待申請の状態（StatusInvite）を、フラグ「１」（招待申請通知済）からフラグ「２」（招待申請成立未通知）に更新する。

次に、管理サーバ２００の招待成立処理部２３８は、招待成立受取部２３７が受け取った招待成立情報に基づく所定の処理を行う。例えば、招待成立処理部２３８は、上記所定の処理として、管理サーバ２００が受け取った招待成立情報に基づいて、ユーザＸ（招待ユーザ）からの申請元アプリ１０（ゲームＡ）への招待が成立したことを通知する招待成立通知情報を、申請元アプリ１０（ゲームＡ）に対応するアプリサーバ３１０（ゲームＡ）に送信する（ＲＥＱ２３、ステップＳＥ２３０）。ここで、招待成立通知情報には、申請元アプリ１０（ゲームＡ）におけるユーザＸ（招待ユーザ）のユーザＩＤが含まれる。また、招待申請管理部２３４は、招待申請の状態（StatusInvite）を、フラグ「２」（招待申請成立未通知）からフラグ「３」（招待成立通知済）に更新する。なお、このフラグの更新は、招待成立通知情報の通知に対するアプリサーバ３１０（ゲームＡ）からの応答通知を受け取ったときでもよい。

なお、招待申請管理部２３４は、招待成立情報に代えて、上述の申請元アプリ１０（ゲームＡ）のインストール済みを示す情報に基づいて、招待申請の状態（StatusInvite）を、フラグ「１」（招待申請通知済）からフラグ「２」（招待申請成立未通知）に更新してもよい。また、招待成立処理部２３８は、招待成立受取部２３７が受け取った上述の申請元アプリ１０（ゲームＡ）のインストール済みを示す情報に基づいて、ユーザＸ（招待ユーザ）からの申請元アプリ１０（ゲームＡ）への招待が成立したことを通知する招待成立通知情報を、申請元アプリ１０（ゲームＡ）に対応するアプリサーバ３１０（ゲームＡ）に送信してもよい。

アプリサーバ３１０（ゲームＡ）は、管理サーバ２００から送信された招待完了通知情報を受け取る（ステップＳＣ２１０）と、招待が完了したことによる所定の報酬（例えば、インセンティブ）を、招待成立通知情報に含まれるユーザＩＤが示す申請元アプリ１０（ゲームＡ）におけるユーザＸに対して付与する（ステップＳＣ２２０）。この所定の報酬は、例えば、申請元アプリ１０（ゲームＡ）内でユーザＸが使用できる仮想通貨やアイテムである。

〔まとめ〕
（１）以上説明してきたように、本実施形態の管理サーバ２００（管理装置の一例）は、申請元アプリ１０（第１アプリケーションの一例）および申請先アプリ２０（第２アプリケーションの一例）がインストールされた招待ユーザ（第１ユーザの一例）のユーザ端末１００（端末装置の一例）から、当該申請先アプリ２０（第２アプリケーション）で当該招待ユーザと所定の関係（例えば、友だち関係）にある被招待ユーザ（第２ユーザの一例）の、当該申請先アプリ２０がインストールされたユーザ端末１００に対して、当該申請元アプリ１０をインストールさせる招待処理を制御する制御部２３０を備えている。
この制御部２３０は、招待申請受取部２３３と、申請照会部２３５と、招待通知部２３６と、を備えている。招待申請受取部２３３は、所定の関係にあるユーザのうちの選択されたユーザである被招待ユーザを申請元アプリ１０へ招待申請する招待申請情報を招待ユーザのユーザ端末１００から受け取る。申請照会部２３５は、被招待ユーザのユーザ端末１００からの申請照会に基づいて、被招待ユーザに対する招待申請情報の有無を照会する。招待通知部２３６は、申請照会部２３５が照会した結果、被招待ユーザに対する招待申請情報が有る場合に、当該被招待ユーザのユーザ端末１００に対して、当該招待申請情報に基づく招待通知情報を送信する。ここで、招待通知情報には、例えば、招待ＩＤ（InviteID）や当該招待ＩＤ（InviteID）と関連付けられたトークン情報（例えば、招待申請トークン）のような情報が含まれる。ここで、関連付けられた情報とは、恒久的に関連付けられている必要はなく、一時的なものであってもよい。また、招待ＩＤ（InviteID）やトークン情報に代えて、例えば、招待ＩＤ（InviteID）に対応した招待申請記録で示される各種情報であってもよい。
この招待ＩＤ（InviteID）と関連付けられたトークン情報（例えば、招待申請トークン）は、例えば、管理サーバ２００で生成される。このトークン情報を生成するタイミングは、例えば、管理サーバ２００が招待申請情報を取得したときである。

これにより、管理サーバ２００は、申請元アプリ１０と申請先アプリ２０とがインストールされているユーザ端末１００を利用する招待ユーザから受け取った、申請先アプリ２０において当該招待ユーザと所定の関係（例えば、友だち関係）にある被招待ユーザを申請元アプリ１０へ招待申請する招待申請を、当該被招待ユーザのユーザ端末１００に通知することができる。よって、相互招待システム５００では、ユーザ情報に互換性がないアプリケーション間であっても、あるアプリケーションで所定の関係（例えば、友だち関係）にあるユーザを、他のアプリケーションに招待することができる。即ち、相互招待システム５００は、ユーザ情報に互換性がないアプリケーション間であっても、容易にアプリケーション間でユーザを招待することができる。

ここで、申請元アプリ１０および申請先アプリ２０がインストールされた招待ユーザのユーザ端末１００とは、例えば、申請元アプリ１０および申請先アプリ２０がインストールされて実行されたことがあるユーザ端末１００のことをいう。つまり、招待ユーザのユーザ端末１００では、申請先アプリ２０が実行されたことがあり、且つ実行された申請先アプリ２０において、少なくとも一人以上のユーザと所定の関係（例えば、友だち関係）になっている。なお、申請元アプリ１０は、申請先アプリ２０で所定の関係（例えば、友だち関係）にあるユーザ（被招待ユーザ）を申請元アプリ１０へ招待申請する際に、少なくとも実行されている。また、申請先アプリ２０で招待ユーザと所定の関係（例えば、友だち関係）にある被招待ユーザの、当該申請先アプリ２０がインストールされたユーザ端末１００とは、例えば、当該申請先アプリ２０がインストールされて実行されたことがあるユーザ端末１００のことをいう。つまり、被招待ユーザのユーザ端末１００では、申請先アプリ２０が実行されたことがあり、且つ実行された申請先アプリ２０において、少なくとも招待ユーザと所定の関係（例えば、友だち関係）になっている。

例えば、本実施形態の管理サーバ２００（管理装置の一例）は、申請元アプリ１０（第１アプリケーションの一例）および申請先アプリ２０（第２アプリケーションの一例）が実行されたことがある招待ユーザ（第１ユーザの一例）のユーザ端末１００（端末装置の一例）から、当該申請先アプリ２０（第２アプリケーション）で当該招待ユーザと所定の関係（例えば、友だち関係）にあるユーザのうちの被招待ユーザ（第２ユーザの一例）のユーザ端末１００に対して、当該申請元アプリ１０を導入させるための招待処理を制御する制御部２３０を備えている。なお、申請先アプリ２０において招待ユーザと被招待ユーザとは所定の関係になっているので、被招待ユーザのユーザ端末１００では申請先アプリ２０が実行されていることになる。

なお、上述したように、申請元アプリ１０または申請先アプリ２０が実行されたとは、例えば、申請元アプリ１０または申請先アプリ２０がインストールされて実行されたことをいう。この場合、申請元アプリ１０または申請先アプリ２０が実行するプログラムの全部がユーザ端末１００にインストールされる構成としてもよいし、一部がユーザ端末１００にインストールされ、当該プログラムの残りの部分がユーザ端末１００以外の装置により実行される構成としてもよい。例えば、ユーザ端末１００にインストールされる申請元アプリ１０または申請先アプリ２０を実行するプログラムは、当該申請元アプリ１０または申請先アプリ２０の実行を開始するために最低限必要なプログラムのみであってもよい。そして、残りのプログラムはユーザ端末１００と通信可能なサーバ装置（例えば、アプリサーバ３００）や他の端末装置（例えば、他のユーザ端末１００）により実行される構成としてもよい。
また、ユーザ端末１００により実行される申請元アプリ１０または申請先アプリ２０のプログラムの全部がユーザ端末１００以外の装置により実行される構成であってもよい。つまり、申請元アプリ１０または申請先アプリ２０を実行するプログラムは、ユーザ端末１００にはインストールされず、ユーザ端末１００と通信可能なサーバ装置（例えば、アプリサーバ３００）や他の端末装置（例えば、他のユーザ端末１００）により実行される構成としてもよい。例えば、申請元アプリ１０または申請先アプリ２０がユーザ端末１００で実行されたとは、ユーザ端末１００からの指示により、ユーザ端末１００と通信網を介して接続されるサーバ装置において当該申請元アプリ１０または申請先アプリ２０が実行された場合も含む。この場合、サーバ装置において実行された結果を示す情報（例えば、表示情報）がユーザ端末１００で表示される。つまり、ユーザ端末１００により実行される申請元アプリ１０または申請先アプリ２０は、所謂クラウド型やＷＥＢ型のアプリケーションであってもよい。

また、被招待ユーザのユーザ端末１００に対して申請元アプリ１０を導入させるとは、当該ユーザ端末１００に申請元アプリ１０のプログラムの一部または全部をインストールさせることであってもよいし、申請元アプリ１０が所謂クラウド型やＷＥＢ型のアプリケーションの場合には、申請元アプリ１０のプログラムを実行する主体となるサーバ装置に対して、ユーザ端末１００からの指示により通信網を介して当該申請元アプリ１０が実行可能な状態となるように利用登録（例えば、ユーザ登録）させることであってもよい。例えば、上記実施形態では、被招待ユーザのユーザ端末１００に対して申請元アプリ１０を導入させるために、申請元アプリ１０をインストール可能な画面を被招待ユーザのユーザ端末１００に表示させる例を説明したが、これに代えて、申請元アプリ１０の利用登録画面を被招待ユーザのユーザ端末１００に表示させるようにしてもよい。

また、管理サーバ２００は、被招待ユーザのユーザ端末１００からの申請照会が無くとも、被招待ユーザに対する招待申請情報に基づく招待通知情報を当該被招待ユーザのユーザ端末１００に対して送信してもよい。例えば、管理サーバ２００は、被招待ユーザのユーザ端末１００において申請先アプリ２０が起動したことを契機として、当該被招待ユーザに対する招待申請情報に基づく招待通知情報を当該被招待ユーザのユーザ端末１００に対して送信してもよい。また、管理サーバ２００は、被招待ユーザのユーザ端末１００に対して招待通知情報を所定の時間周期で送信してもよいし、所定の時刻に定期的に送信してもよい。

つまり、制御部２３０は、招待申請受取部２３３と、招待通知部２３６とを、少なくとも備えた構成としてもよい。招待申請受取部２３３は、招待ユーザ（第１ユーザの一例）と所定の関係にあるユーザのうちの被招待ユーザ（第２ユーザの一例）を申請元アプリ１０（第１アプリケーションの一例）へ招待申請する招待申請情報を招待ユーザのユーザ端末１００から受け取る。そして、招待通知部２３６は、招待申請受取部２３３が受け取った招待申請情報のうち被招待ユーザに対する招待申請情報に基づく招待通知情報を、当該被招待ユーザのユーザ端末１００に対して送信する。

これにより、管理サーバ２００は、申請元アプリ１０と申請先アプリ２０とが実行されたことがあるユーザ端末１００を利用する招待ユーザから受け取った、申請先アプリ２０において当該招待ユーザと所定の関係（例えば、友だち関係）にある被招待ユーザを申請元アプリ１０へ招待申請する招待申請を、当該被招待ユーザのユーザ端末１００に通知することができる。よって、相互招待システム５００では、ユーザ情報に互換性がないアプリケーション間であっても、あるアプリケーションで所定の関係（例えば、友だち関係）にあるユーザを、他のアプリケーションに招待することができる。即ち、相互招待システム５００は、ユーザ情報に互換性がないアプリケーション間であっても、容易にアプリケーション間でユーザを招待することができる。

例えば、招待申請受取部２３３は、招待ユーザのユーザ端末１００の申請元アプリ１０において、アプリケーションリスト通知部２３２（アプリケーション情報通知部の一例）が送信した情報の少なくとも一部により示される対応アプリケーションのうちの、申請元アプリ１０から起動された申請先アプリ２０（第２アプリケーションの一例）から、招待ユーザと所定の関係（例えば、友だち関係）にあるユーザのうちの被招待ユーザを申請元アプリ１０へ招待申請する招待申請情報を受け取る。そして、招待通知部２３６は、被招待ユーザのユーザ端末１００の申請先アプリ２０対して招待通知情報を送信する。このように、招待ユーザの申請元アプリ１０から申請先アプリ２０を介在させて、被招待ユーザの申請先アプリ２０へ招待通知情報を通知するようにしたので、申請元アプリ１０と申請先アプリ２０のようにユーザ情報に互換性がないアプリケーション間であっても容易にユーザを招待することができるようになる。この場合、現実社会で利用しているソーシャルメディアを用いずに被招待ユーザだけに招待通知情報を通知することができるので、無関係なユーザを招待することを防止することができる。また、現実社会で利用しているメセンジャーアプリ（メールソフトやチャット）を利用すれば被招待ユーザだけに招待通知情報を通知することができるが、この場合であればユーザのメセンジャーアプリにおける宛先(メールアドレスやアカウント)を知る必要がないため、アプリケーション（仮想社会）でクローズした所定の関係を維持することができる。

なお、上記実施形態で説明したように、管理サーバ２００は、被招待ユーザ（第２ユーザの一例）のユーザ端末１００からの申請照会に基づいて、被招待ユーザに対する招待申請情報の有無を照会する申請照会部２３５を備えてもよい。この場合、招待通知部２３６は、申請照会部２３５が照会した結果、被招待ユーザに対する招待申請情報が有る場合に、当該被招待ユーザのユーザ端末１００に対して、当該招待申請情報に基づく招待通知情報を送信する。
これにより、管理サーバ２００は、被招待ユーザのユーザ端末１００から申請照会を受け取ったことを契機として、招待ユーザからの招待申請を、当該被招待ユーザのユーザ端末１００に通知することができる。

（２）ユーザ端末１００（端末装置の一例）は、ユーザ端末１００にインストールされている申請元アプリ１０（第１アプリケーションの一例）と申請先アプリ２０（第２アプリケーションの一例）のうち、当該申請先アプリ２０で自ユーザと所定の関係にある他ユーザの当該申請先アプリ２０がインストールされている他のユーザ端末１００（端末装置の一例）に対して、当該申請元アプリ１０（第１アプリケーション）をインストールさせる招待処理を制御する管理サーバ２００と通信可能な端末装置である。

これにより、ユーザ端末１００は、申請元アプリ１０での操作に基づいて、特定モードで起動させた申請先アプリ２０において自ユーザ（招待ユーザの一例）と所定の関係（例えば、友だち関係）にある他のユーザ（被招待ユーザの一例）を申請元アプリ１０へ招待申請する招待申請を、管理サーバ２００に送信することができる。そして、招待申請は、管理サーバ２００を介して当該他のユーザのユーザ端末１００に通知される。よって、相互招待システム５００では、ユーザ情報に互換性がないアプリケーション間であっても、あるアプリケーションで所定の関係（例えば、友だち関係）にあるユーザを、他のアプリケーションに招待することができる。即ち、相互招待システム５００は、ユーザ情報に互換性がないアプリケーション間であっても、容易にアプリケーション間でユーザを招待することができる。

（３）ユーザ端末１００（自端末装置の一例）は、特定モード起動部１６２（起動部の一例）と、ユーザリスト取得部１６３と、招待申請通知部１６４とを備えている。
特定モード起動部１６２は、ユーザ端末１００にインストールされている対応アプリケーションにおいて、当該ユーザ端末１００にインストールされている他の対応アプリケーションを特定モードで起動させる（特定の機能を実行させる）。
ユーザリスト取得部１６３は、特定モードで動作中（特定の機能を実行中）の申請先アプリ２０（アプリケーションの一例）において自ユーザと所定の関係（例えば、友だち関係）にあるユーザのユーザリストを取得する。このユーザリストは、例えば、申請先アプリ２０に対応するアプリサーバ３００（サーバ装置の一例）で管理されており、ユーザリスト取得部１６３は、申請先アプリ２０に対応するアプリサーバ３００からこのユーザリストを取得する。
招待申請通知部１６４は、ユーザリスト取得部１６３が取得したユーザリストの中から選択されたユーザ（被招待ユーザの一例）を、申請先アプリ２０を特定モードで起動させた（申請先アプリ２０の特定の機能を実行させた）対応アプリケーション（例えば、申請元アプリ１０）へ招待申請する招待申請情報を管理サーバ２００（管理装置の一例）に対して送信する。

なお、上述のユーザリストは、ユーザを示す情報の一例であって、その情報の形態はいずれの形態であってもよい。例えば、ユーザ端末１００が備えるユーザリスト取得部１６３と、招待申請通知部１６４とのそれぞれの構成は、以下のように記載することができる。
ユーザリスト取得部１６３（ユーザ情報取得部の一例）は、特定モードで動作中（特定の機能を実行中）の申請先アプリ２０（アプリケーションの一例）において自ユーザと所定の関係（例えば、友だち関係）にあるユーザを示す情報（例えば、ユーザリスト）を取得する。招待申請通知部１６４は、ユーザリスト取得部１６３が取得した所定の関係にあるユーザを示す情報（例えば、ユーザリスト）により示されるユーザのうち、申請先アプリ２０を特定モードで起動させた（申請先アプリ２０の特定の機能を実行させた）申請元アプリ１０（アプリケーションの一例）へ招待される被招待ユーザを、当該申請元アプリ１０へ招待申請する招待申請情報を管理サーバ２００に対して送信する。このように、招待申請情報を招待ユーザの申請元アプリ１０から管理サーバ２００に対して送信するのではなく、申請元アプリ１０から申請先アプリ２０を介在（起動）させて管理サーバ２００に対して送信するようにしたので、申請元アプリ１０と申請先アプリ２０のようにユーザ情報に互換性がないアプリケーション間であっても容易にユーザを招待することができるようになる。

これにより、ユーザ端末１００は、申請元アプリ１０での操作に基づいて、特定モードで起動させた申請先アプリ２０において自ユーザ（招待ユーザの一例）と所定の関係（例えば、友だち関係）にある他のユーザ（被招待ユーザの一例）を申請元アプリ１０へ招待申請する招待申請を、管理サーバ２００に送信することができる。そして、招待申請は、管理サーバ２００を介して当該他のユーザのユーザ端末１００に通知される。よって、相互招待システム５００では、ユーザ情報に互換性がないアプリケーション間であっても、あるアプリケーションで所定の関係（例えば、友だち関係）にあるユーザを、他のアプリケーションに招待することができる。即ち、相互招待システム５００は、ユーザ情報に互換性がないアプリケーション間であっても、容易にアプリケーション間でユーザを招待することができる。

（４）管理サーバ２００は、相互招待システム５００に対応する対応アプリケーションに関する情報を管理するアプリケーション管理部２３１を備えている。即ち、アプリケーション管理部２３１は、申請元アプリ１０（第１アプリケーションの一例）および申請先アプリ２０（第２アプリケーションの一例）を含む複数の対応アプリケーションのそれぞれに関する情報を管理する。また、管理サーバ２００は、アプリケーション管理部２３１を参照して、申請元アプリ１０への招待申請が可能な対応アプリケーションのアプリケーションリストを招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信するアプリケーションリスト通知部２３２を備えている。例えば、アプリケーションリスト通知部２３２は、招待ユーザのユーザ端末１００の申請元アプリ１０に対して、アプリケーションリストを送信する。

ここで、上述のアプリケーションリストは、相互招待システム５００に対応する対応アプリケーションのうちの少なくとも一の対応アプリケーションを示す情報であればよく、その情報の形態はいずれの形態であってもよい。例えば、上述のアプリケーションリストは、少なくとも一の対応アプリケーションを示す情報（例えば、アプリ名称、アプリアイコン画像、アプリＩＤ等）が含まれるデータであってもよいし、少なくとも一の対応アプリケーションを示す情報が表示情報として表示されるアプリ一覧画面のデータであってもよいし、アプリ一覧画面のリンク先を示す情報であってもよい。なお、アプリ一覧画面においては、複数の対応アプリケーションを示す情報が、上下方向（縦方向）の並びで表示（所謂リスト表示）されてもよいし（図４（ｂ）参照）、左右方向（横方向）の並びで表示されてもよいし、または、縦及び横方向に升目状（格子状）の並びで表示（所謂グリッド表示）されてもよい。

また、招待申請が可能なアプリケーションとは、相互招待システム５００に対応する対応アプリケーション（即ち、アプリケーション管理部２３１が情報を管理しているアプリケーション）のことであってもよい。例えば、アプリケーション管理部２３１は、申請元アプリ１０（第１アプリケーションの一例）および前記第２アプリケーションを含む複数のアプリケーションのそれぞれを示す情報を管理する。そして、アプリケーションリスト通知部２３２（アプリケーション情報通知部の一例）は、アプリケーション管理部２３１が管理する情報の少なくとも一部（例えば、アプリケーションリスト）を上記アプリケーションリスト（アプリケーションを示す情報の一例）として、招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信する。

なお、招待申請が可能なアプリケーションとは、相互招待システム５００に対応する対応アプリケーションのうち、管理サーバ２００において、招待申請が禁止されていない対応アプリケーションであってもよい。例えば、アプリケーション管理部２３１は、複数の対応アプリケーションのそれぞれを示す情報と、対応アプリケーションのそれぞれに設定された招待申請の禁止に関する情報とを管理してもよい。そして、アプリケーションリスト通知部２３２（アプリケーション情報通知部の一例）は、アプリケーション管理部２３１を参照して、申請元アプリ１０への招待申請が可能であるか否か（例えば、招待申請の禁止が設定されてないか）を判定し、招待申請が可能なアプリケーションを示すアプリケーションリスト（アプリケーションを示す情報の一例）を招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信してもよい。このように、招待申請が禁止されていない対応アプリケーションを招待申請が可能なアプリケーションとする場合の処理については、第２の実施形態で後述する。

また、ユーザ端末１００（自端末装置の一例）は、アプリケーションリスト取得部１６１を備えている。
アプリケーションリスト取得部１６１は、管理サーバ２００から、招待処理に対応する複数の対応アプリケーションの一部または全部からなるアプリケーションリストを取得する。例えば、アプリケーションリスト取得部１６１は、通常モードで動作中の申請元アプリ１０（アプリケーションの一例）における第１操作に基づいて、相互招待システム５００（招待処理の一例）に対応する複数の対応アプリケーションの一部または全部からなるアプリケーションリストを管理サーバ２００から取得する。
そして、提示部１６８（第１提示部の一例、アプリケーションリスト提示部の一例）は、アプリケーションリスト取得部１６１が取得したアプリケーションリストの中からユーザ端末１００にインストールされている対応アプリケーションを提示する。

これにより、管理サーバ２００は、相互招待システム５００に対応する対応アプリケーションに関する情報を管理することができる。また、管理サーバ２００が対応アプリケーションのアプリケーションリストを招待ユーザのユーザ端末１００に送信し、ユーザ端末１００がこのアプリケーションリストを取得して提示するので、招待ユーザは、被招待ユーザを選択する対応アプリケーションを当該アプリケーションリストの中から容易に選択することができる。

なお、上述したように、アプリケーションリストは、相互招待システム５００に対応する対応アプリケーションのうちの一または複数の対応アプリケーションを示す情報であればよく、その情報の形態はいずれの形態であってもよい。
つまり、アプリケーションリスト取得部１６１（アプリケーション情報取得部の一例）は、招待処理に対応する複数の対応アプリケーションのうちの少なくとも一のアプリケーション（一または複数のアプリケーションの一例）を示す情報を管理サーバ２００から取得する。例えば、アプリケーションリスト取得部１６１は、通常モードで動作中の申請元アプリ１０（アプリケーションの一例）における第１操作に基づいて、一または複数の対応アプリケーションを示す情報を管理サーバ２００から取得する。
そして、提示部１６８（第１表示制御部の一例）は、アプリケーションリスト取得部１６１が取得した、一または複数の対応アプリケーションを示す情報のうちのユーザ端末１００にインストールされている対応アプリケーションを示す情報を表示部１２０に表示させる。

（５）ユーザ端末１００（自端末装置の一例）のアプリケーションリスト取得部１６１は、アプリケーションリストとともに、アプリケーションリストに含まれる対応アプリケーションのそれぞれに対応するＵＲＬスキームを取得する。そして、提示部１６８（第１提示部の一例、アプリケーションリスト提示部の一例）は、取得したＵＲＬスキームを用いて、ユーザ端末１００にインストールされている対応アプリケーションを検出して自ユーザに提示する。

なお、ＵＲＬスキームを利用してユーザ端末１００にインストールされている対応アプリケーションを検出する例を説明したが、これに限られるものではない。例えば、ＯＳがユーザ端末１００にインストール済みの対応アプリケーションを示す情報を取得可能な場合には、このＯＳが取得したインストール済みの対応アプリケーションを示す情報を利用して、ユーザ端末１００にインストールされている他アプリケーションを検出してもよい。

例えば、提示部１６８（第１表示制御部の一例）は、ユーザ端末１００（自端末装置の一例）が具備する機能を用いて、アプリケーションリスト取得部１６１（アプリケーション情報取得部の一例）が取得した、一又は複数の対応アプリケーションを示す情報により示される対応アプリケーションのうちからユーザ端末１００にインストールされている対応アプリケーションを検出し、検出した対応アプリケーションを示す情報を表示部１２０に表示させてもよい。

これにより、ユーザ端末１００は、管理サーバ２００から取得した対応アプリケーションリストの中から、ユーザ端末１００にインストールされている対応アプリケーションのみを提示する（表示部１２０に表示させる）ことができる。

なお、提示部１６８（第１表示制御部の一例）は、招待ユーザのユーザ端末１００にインストールされている対応アプリケーションを示す情報を表示部１２０に表示させる場合、招待ユーザのユーザ端末１００で起動したことがある対応アプリケーションであるか否かを判定することにより、招待ユーザのユーザ端末１００で起動したことがあると判定した対応アプリケーションを示す情報を、招待ユーザのユーザ端末１００にインストールされている対応アプリケーションを示す情報として表示部１２０に表示させてもよい。

また、管理サーバ２００は、相互招待システム５００に対応する対応アプリケーションのうち、招待ユーザのユーザ端末１００にインストールされている対応アプリケーションを招待申請が可能なアプリケーションとしてもよい。例えば、ユーザ端末１００から管理サーバ２００に、ユーザ端末１００にインストールされている対応アプリケーションを示す情報が送信されることにより、管理サーバ２００は、ユーザ端末１００にインストールされているアプリケーションを認識してもよい。
例えば、アプリケーション管理部２３１は、申請元アプリ１０（第１アプリケーションの一例）および申請先アプリ２０（第２アプリケーションの一例）を含む複数の対応アプリケーションのそれぞれに関する情報（複数の対応アプリケーションのそれぞれを示す情報やユーザ端末１００にインストールされているか否かを示す情報など）を管理してもよい。そして、アプリケーションリスト通知部２３２（アプリケーション情報通知部の一例）は、アプリケーション管理部２３１を参照して、申請元アプリ１０への招待申請が可能であるか否か（例えば、インストールされている否か）を判定し、招待申請が可能なアプリケーションを示すアプリケーションリスト（アプリケーションを示す情報の一例）を招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信してもよい。
これにより、管理サーバ２００は、相互招待システム５００に対応する対応アプリケーションのうち、招待ユーザのユーザ端末１００にインストールされている対応アプリケーションのみを、招待ユーザのユーザ端末１００に通知することができる。

なお、管理サーバ２００は、招待ユーザのユーザ端末１００で起動したことがある対応アプリケーションを示す情報を取得できる場合には、相互招待システム５００に対応する対応アプリケーションのうち、招待ユーザのユーザ端末１００で起動したことがある対応アプリケーションを招待ユーザのユーザ端末１００にインストールされている対応アプリケーションとして、招待申請が可能なアプリケーションとしてもよい。

（６）ユーザ端末１００の特定モード起動部１６２（起動部の一例）は、提示部１６８（第１提示部の一例、アプリケーションリスト提示部の一例）が提示した対応アプリケーションの中から第２操作に基づいて選択された対応アプリケーションである申請先アプリ２０に対して、通常モードで動作中の申請元アプリ１０（アプリケーションの一例）における招待ユーザ（自ユーザの一例）に対応した第１ユーザ情報（例えば、ユーザＩＤ（識別情報の一例））を管理サーバ２００に通知可能なように当該選択された申請先アプリ２０（アプリケーションの一例）を特定モードで起動させる。このように、申請先アプリ２０を特定モードで起動させることで、ユーザが対応アプリケーションを利用する目的で起動する場合と異ならせることができ、対応アプリケーションが有する機能のうちの特定の機能を呼び出すことが可能となる。

つまり、特定モード起動部１６２（起動部の一例）は、提示部１６８（第１表示制御部の一例）が表示部１２０に表示させた一または複数の対応アプリケーションを示す情報により示される対応アプリケーションのうちから第２操作に基づいて選択された申請先アプリ２０（第２アプリケーションの一例）を特定モードで起動させる。

なお、上述の特定モード（特定の機能の一例）は、特定モードを実行した申請先アプリ２０（第２アプリケーションの一例）における招待ユーザ（自ユーザの一例）のユーザＩＤ（識別情報の一例）を、当該申請先アプリ２０に対応するアプリサーバ３２０（サーバ装置の一例）に送信することにより、申請先アプリ２０において招待ユーザと所定の関係（例えば、友達関係）にあるユーザのユーザリスト（所定の関係にあるユーザを示す情報の一例、所定関係ユーザ情報の一例）を取得する機能を有してもよい。
これにより、ユーザ端末１００は、申請元アプリ１０から、申請先アプリ２０において招待ユーザと所定の関係（例えば、友達関係）にあるユーザの情報を取得することができ、当該ユーザを被招待ユーザとして申請元アプリ１０へ招待することが可能となる。

（７）招待申請通知部１６４は、申請元アプリ１０（他のアプリケーションに対して特定の機能を実行させたアプリケーション）における招待ユーザ（自ユーザの一例）に対応した情報（例えば、ユーザＩＤ（識別情報））をさらに含めた招待申請情報を管理サーバ２００に対して送信する。

なお、招待ユーザに対応した情報は、招待申請情報に関連付けられていればよく、当該招待申請情報に含まれなくともよい。例えば、招待申請通知部１６４は、申請元アプリ１０（他のアプリケーションに対して特定の機能を実行させたアプリケーションの一例）における招待ユーザ（自ユーザの一例）に対応したユーザＩＤ（識別情報の一例、招待ユーザに対応した情報の一例）がさらに関連付けられた招待申請情報を管理サーバ２００に対して送信してもよい。

例えば、招待申請通知部１６４は、申請元アプリ１０（第１アプリケーションの一例）における招待ユーザ（自ユーザの一例）に対応したユーザＩＤ（識別情報の一例、第１ユーザ情報の一例）、及び被招待ユーザに対応したユーザＩＤ（識別情報の一例、第２ユーザ情報の一例）が関連付けられた招待申請情報を管理サーバ２００に対して送信してもよい。

これにより、ユーザ端末１００は、申請元アプリ１０における招待ユーザに対応した情報（例えば、ユーザＩＤ（識別情報））を、特定モードで起動した申請先アプリ２０を介して管理サーバ２００へ通知することができる。

（８）特定モード起動部１６２（起動部の一例）は、申請先アプリ２０（選択されたアプリケーションの一例）に対して通常モードで動作中の申請元アプリ１０（アプリケーションの一例）のアプリＩＤ（識別情報の一例）を示すアプリケーション情報をさらに通知可能なように当該申請先アプリ２０を特定モードで起動させてもよい。そして、招待申請通知部１６４は、通常モードで動作中の申請元アプリ１０（他のアプリケーションに対して特定の機能を実行させたアプリケーションの一例）のアプリＩＤを示すアプリケーション情報をさらに含む招待申請情報を管理サーバ２００に対して送信してもよい。

つまり、特定モード（特定の機能）は、特定モードを実行させた申請元アプリ１０（アプリケーションの一例）のアプリＩＤ（識別情報の一例）、及び特定モードを実行させた申請元アプリ１０における招待ユーザ（自ユーザの一例）のユーザＩＤ（識別情報の一例）を管理サーバ２００に通知する機能をさらに有してもよい。

なお、アプリＩＤを示すアプリケーション情報は、招待申請情報に関連付けられていればよく、当該招待申請情報に含まれなくともよい。例えば、招待申請通知部１６４は、通常モードで動作中の申請元アプリ１０（第１アプリケーションの一例、他のアプリケーションに対して特定の機能を実行させたアプリケーションの一例）のアプリＩＤ（識別情報の一例、第１アプリケーションを示す情報の一例）がさらに関連付けられた招待申請情報を管理サーバ２００に対して送信してもよい。

これにより、ユーザ端末１００は、申請元アプリ１０のアプリＩＤ（即ち、被招待ユーザを招待したい対応アプリケーション）を、特定モードで起動した申請先アプリ２０を介して管理サーバ２００へ通知することができる。よって、管理サーバ２００は、申請元アプリ１０のアプリＩＤにより、被招待ユーザが招待された対応アプリケーションを特定することができる。

（９）招待申請通知部１６４は、申請先アプリ２０における被招待ユーザ（選択されたユーザの一例）に対応した情報（例えば、ユーザＩＤ（識別情報の一例））を含む招待申請情報を管理サーバ２００に対して送信してもよい。

なお、被招待ユーザ（招待されるユーザの一例）に対応した情報は、招待申請情報に関連付けられていればよく、当該招待申請情報に含まれなくともよい。例えば、招待申請通知部１６４は、申請先アプリ２０における被招待ユーザに対応した情報（例えば、ユーザＩＤ（識別情報の一例））が関連付けられた招待申請情報を管理サーバ２００に対して送信してもよい。

これにより、ユーザ端末１００は、申請先アプリ２０における被招待ユーザのユーザＩＤを管理サーバ２００へ通知することができる、よって、管理サーバ２００は、被招待ユーザのユーザＩＤにより、被招待ユーザを特定することができるとともに、被招待ユーザのユーザ端末１００を特定することができる。

（１０）招待申請通知部１６４は、申請先アプリ２０（特定の機能を実行中のアプリケーションの一例）における自ユーザに対応した情報（例えば、ユーザＩＤ（識別情報の一例））、及び申請先アプリ２０における被招待ユーザ（選択されたユーザの一例）に対応した情報（例えば、ユーザＩＤ）を含む招待申請情報を管理サーバ２００に対して送信してもよい。

なお、自ユーザに対応した情報、及び申請先アプリ２０における被招待ユーザに対応した情報は、招待申請情報に関連付けられていればよく、当該招待申請情報に含まれなくともよい。例えば、招待申請通知部１６４は、申請先アプリ２０（特定の機能を実行中のアプリケーションの一例）における自ユーザに対応した情報（例えば、ユーザＩＤ（識別情報の一例））、及び申請先アプリ２０における被招待ユーザに対応した情報（例えば、ユーザＩＤ）が関連付けられた招待申請情報を管理サーバ２００に対して送信してもよい。

これにより、ユーザ端末１００は、さらに申請先アプリ２０における自ユーザ（招待ユーザの一例）のユーザＩＤを管理サーバ２００へ通知することができる、よって、管理サーバ２００は、招待ユーザのユーザＩＤにより、被招待ユーザのユーザ端末１００に対して、誰からの招待申請であるかを通知することができる。

（１１）招待申請情報に含まれる申請元アプリ１０（第１アプリケーションの一例）における招待ユーザ（第１ユーザの一例）に対応した情報は、招待ユーザのユーザ端末１００にて申請先アプリ２０（第２アプリケーションの一例）が、申請元アプリ１０から直接的又は当該ユーザ端末１００の端末記憶部１４０（記憶部の一例）を介して間接的に取得したものである。ここで、招待ユーザに対応した情報は、ユーザＩＤ（識別情報の一例）や当該ユーザＩＤと関連付けられたトークン情報（例えば、招待者トークン）など、管理サーバ２００で招待ユーザを特定できる情報であればよい。これにより、管理サーバ２００は、申請先アプリ２０（第２アプリケーション）から受け取った招待申請が誰からの招待申請であるかを特定することができる。
このユーザＩＤと関連付けられたトークン情報（例えば招待者トークン）は、例えば、管理サーバ２００で生成される。このトークン情報を生成するタイミングは、例えば、管理サーバ２００がアプリケーションリスト要求情報を取得したときや、招待申請情報を取得するまでの間において申請元アプリ１０から所定の情報（例えば、選択された申請先アプリ２０の情報）を取得したときである。

なお、申請元アプリ１０における招待ユーザに対応した情報は、招待申請情報に関連付けられていればよく、当該招待申請情報に含まれなくともよい。例えば、招待申請情報に関連付けられている申請元アプリ１０（第１アプリケーションの一例）における招待ユーザ（第１ユーザの一例）に対応した情報は、招待ユーザのユーザ端末１００にて申請先アプリ２０（第２アプリケーションの一例）が、申請元アプリ１０から直接的又は当該ユーザ端末１００の端末記憶部１４０（記憶部の一例）を介して間接的に取得したものであってもよい。

（１２）ユーザ端末１００は、招待申請通知部１６４が招待申請情報を送信した後に、特定モードで起動された申請先アプリ２０（選択されたアプリケーションの一例）を終了させる特定モード終了部１６５を備える。

これにより、ユーザ端末１００は、特定モードで起動した申請先アプリ２０から招待申請をした後に、特定モードで起動された申請先アプリ２０を終了することができる。このように、ユーザ端末１００は、通常モードで動作している申請元アプリ１０に対する招待ユーザの一連の操作の中で、招待ユーザに意識させることなく一時的に起動した申請先アプリ２０の特定の機能を利用して、被招待ユーザの選択が可能である。

（１３）例えば、ユーザ端末１００の提示部１６８（ユーザリスト提示部の一例）は、ユーザリスト取得部１６３が取得したユーザリストの少なくとも一部を、申請元アプリ１０（特定の機能を実行させたアプリケーションの一例）への招待候補となるユーザのユーザリストとして提示する。

なお、提示部１６８は、例えば、招待候補となるユーザのユーザリストを表示部１２０に表示させることにより、当該ユーザリストを被招待ユーザに対して提示する。例えば、提示部１６８（第３表示制御部の一例）は、ユーザリスト取得部１６３（ユーザ情報取得部の一例）が取得したユーザリスト（所定の関係にあるユーザを示す情報の一例）の少なくとも一部を、申請元アプリ１０への招待候補となるユーザのユーザリスト（特定の機能を実行させたアプリケーションへ招待される候補となるユーザを示す情報の一例）として表示部１２０に表示させる。

これにより、申請元アプリ１０での操作に基づいて、申請先アプリ２０の特定の機能を実行させることにより、申請元アプリ１０への招待候補となる申請先アプリ２０におけるユーザリストを、ユーザ端末１００に表示させることができるようになる。

（１４）このとき、提示部１６８（ユーザリスト提示部の一例）は、取得したユーザリストの少なくとも一部を含むユーザリストの表示画面を、申請元アプリ１０（特定の機能を実行させたアプリケーションの一例）により表示部１２０に表示されていた表示画面から切り替わるように表示させる。

例えば、提示部１６８（第３表示制御部の一例）は、取得したユーザリストの少なくとも一部を含むユーザリスト（所定の関係にあるユーザを示す情報の少なくとも一部を含む情報の一例）の表示画面を、申請元アプリ１０（特定の機能を実行させたアプリケーションの一例）により表示部１２０に表示されていた表示画面から切り替わるように表示させる。

このように、ユーザ端末１００は、通常モードで動作している申請元アプリ１０における表示画面と、被招待ユーザを選択するための申請先アプリ２０における表示画面との表示の切り替えを、招待ユーザにアプリケーションが切り替わることを意識させることなく行うことができる。

（１５）提示部１６８（第２提示部の一例、招待情報提示部の一例）は、招待申請通知部１６４が招待申請情報を管理サーバ２００に対して送信した後、申請元アプリ１０（特定の機能を実行させたアプリケーションの一例）により表示される表示画面へ切り替わるように、表示部１２０に表示させたユーザリストの表示画面の表示を終了させる。

例えば、提示部１６８（第３表示制御部の一例）は、招待申請通知部１６４が招待申請情報を管理サーバ２００に対して送信した後、申請元アプリ１０（特定の機能を実行させたアプリケーションの一例）により表示される表示画面へ切り替わるように、表示部１２０に表示させたユーザリスト（所定の関係にあるユーザを示す情報の少なくとも一部を含む情報の一例）の表示画面の表示を終了させる。

このように、ユーザ端末１００は、通常モードで動作している申請元アプリ１０における表示画面と、被招待ユーザを選択するための申請先アプリ２０における表示画面との表示の切り替えを、招待ユーザにアプリケーションが切り替わることを意識させることなく行うことができる。これにより、ユーザ端末１００は、招待申請を終えたユーザに対して、引き続き申請元アプリ１０を利用させることができ、例えば、ユーザに対して、申請先アプリ２０の利用の止めどきを生じさせないようにすることができる。

（１６）管理サーバ２００の招待申請受取部２３３は、招待ユーザ（第１ユーザの一例）のユーザ端末１００においてアプリケーションリストから選択されることにより起動された申請先アプリ２０（第２アプリケーションの一例）から、招待申請情報を受け取る。
ここで、招待申請情報には、申請元アプリ１０（第１アプリケーションの一例）における招待ユーザに対応した情報および申請先アプリ２０における被招待ユーザ（第２ユーザの一例）に対応した情報が含まれている。
なお、招待ユーザに対応した情報は、ユーザＩＤ（識別情報の一例）や当該ユーザＩＤと関連付けられたトークン情報（例えば、招待者トークン）など、管理サーバ２００で招待ユーザを特定できる情報であればよい。また、被招待ユーザに対応した情報がトークン情報である場合に、そのトークン情報から招待ユーザだけでなく、申請元アプリ１０も特定できるようにしてもよい。
また、被招待ユーザに対応した情報は、ユーザＩＤや当該ユーザＩＤと関連付けられたトークン情報など、管理サーバ２００で招待ユーザを特定できる情報であればよい。
また、管理サーバ２００は、招待申請情報に含まれるそれぞれのアプリＩＤ及びユーザＩＤを関連付けて招待申請記録として管理する招待申請管理部２３４を備えている。すなわち、管理サーバ２００の招待申請管理部２３４は、招待申請情報に対応する招待申請記録を管理する。

さらに、招待申請情報には、申請先アプリ２０（第２アプリケーションの一例）における招待ユーザ（第１ユーザの一例）のユーザＩＤ（識別情報の一例）を含めてもよい。なお、ユーザ端末１００（ＳＤＫ１１）と管理サーバ２００との間の通信セッションが確立されている場合には、招待申請情報を送信するユーザ（申請先アプリ２０における招待ユーザ）を、通信セッションに係る情報（例えば、セッション情報）から特定することができるので、招待申請情報における申請先アプリ２０における招待ユーザ情報のようにセッション情報で特定できる情報は招待申請情報に含めなくてもよい。なお、セッション情報で特定できる情報を含めなくてよいのは、招待申請情報に限ったことでなく他の情報でも同様である。

これにより、管理サーバ２００は、招待ユーザのユーザ端末１００から送信された招待申請情報を取得して招待申請記録として管理することができる。また、管理サーバ２００は、取得した招待申請情報に含まれるユーザＩＤに基づいて、申請元アプリ１０における招待ユーザ、申請先アプリ２０における招待ユーザ、および申請先アプリ２０における被招待ユーザを特定することができる。

なお、上記実施形態では、招待申請情報には、申請元アプリ１０における招待ユーザに対応した情報および申請先アプリ２０における被招待ユーザに対応した情報が含まれている例を説明したが、これに限られるものではない。例えば、申請元アプリ１０における招待ユーザに対応した情報および申請先アプリ２０における被招待ユーザに対応した情報は、招待申請情報に関連付けられていればよく、何れか一方が招待申請情報に含まれなくてもよいし、両方が招待申請情報に含まれなくてもよい。
例えば、招待申請受取部２３３は、招待申請情報を、申請元アプリ１０（第１アプリケーションの一例）における招待ユーザ（第１ユーザの一例）に対応した情報および申請先アプリ２０（第２アプリケーションの一例）における被招待ユーザ（第２ユーザの一例）に対応した情報と関連付けて取得してもよい。そして、招待申請管理部２３４は、招待申請受取部２３３が関連付けて取得した招待申請情報と、申請元アプリ１０における招待ユーザに対応した情報と、申請先アプリ２０における被招待ユーザに対応した情報と、を関連付けて招待申請記録として管理してもよい。

また、招待申請受取部２３３は、招待申請情報を、申請元アプリ１０における招待ユーザに対応した情報を取得しなくでもよい。例えば、被招待ユーザに対して招待ユーザが誰であるかを知らせない場合、または招待が成立したときに招待ユーザに対して報酬を付与しない場合等は、管理サーバ２００は、申請元アプリ１０における招待ユーザに対応した情報を取得する必要が無く、取得した招待通知情報を被招待ユーザにユーザ端末１００に対して送信しさえすればよい。
例えば、招待申請受取部２３３は、招待申請情報を、申請先アプリ２０（第２アプリケーションの一例）における被招待ユーザ（第２ユーザの一例）に対応した情報と関連付けて取得してもよい。そして、招待申請管理部２３４は、招待申請受取部２３３が関連付けて取得した招待申請情報と申請先アプリ２０における被招待ユーザに対応した情報とを関連付けて招待申請記録として管理してもよい。

（１７）管理サーバ２００の申請照会部２３５は、被招待ユーザ（第２ユーザの一例）のユーザ端末１００の申請先アプリ２０（第２アプリケーションの一例）からの申請照会に基づいて、申請先アプリ２０における当該被招待ユーザに対する招待申請記録の有無を照会する。例えば、申請照会部２３５は、被招待ユーザのユーザ端末１００からの申請照会に含まれる申請先アプリ２０における被招待ユーザに対応した情報に対応する招待申請記録の有無を照会する。一例として、申請照会部２３５は、上記申請照会に含まれる申請先アプリ２０における被招待ユーザのユーザＩＤ（識別情報の一例）に対応する招待申請記録の有無を照会する。

なお、申請先アプリ２０の被招待ユーザに対応した情報（例えば、ユーザＩＤ）は、申請照会に関連付けられていればよく、当該申請照会に含まれなくともよい。例えば、申請照会部２３５は、被招待ユーザ（第２ユーザの一例）のユーザ端末１００からの申請照会に関連付けられた申請先アプリ２０（第２アプリケーションの一例）における被招待ユーザに対応した情報（例えば、ユーザＩＤ）、に対応する招待申請記録の有無を照会してもよい。

これにより、管理サーバ２００は、被招待ユーザのユーザ端末１００のからの申請照会に基づいて、当該被招待ユーザに対する招待申請記録を管理しているか否かを照会することができる。

（１８）ユーザ端末１００は、通常モードで動作中の申請先アプリ２０（第２アプリケーションの一例）において、自ユーザに対応した情報（例えば、ユーザＩＤ（識別情報の一例））が被招待ユーザに対応する情報（第２ユーザ情報の一例、例えば、ユーザＩＤ）となる招待申請情報の有無を管理サーバ２００に対して照会する照会部１６６を備えている。
そして、ユーザ端末１００の招待通知取得部１６７は、照会部１６６が照会した結果、自ユーザに対応した情報（例えば、ユーザＩＤ）が被招待ユーザに対応する情報（例えば、ユーザＩＤ）となる招待申請情報が有る場合に、当該招待申請情報に基づく招待通知情報を管理サーバ２００から取得する。

つまり、ユーザ端末１００の招待通知取得部１６７は、例えば、他のユーザ端末１００（他端末装置の一例）から管理サーバ２００に対して送信された招待申請情報に含まれる被招待ユーザ（選択されたユーザの一例）のユーザＩＤ（識別情報の一例）に基づいて、申請元アプリ１０（特定の機能を実行させたアプリケーションの一例）へ招待申請されたユーザ（被招待ユーザの一例）が自ユーザとなる招待申請情報に基づく招待通知情報を管理サーバ２００から取得する。また、ユーザ端末１００の提示部１６８（第２提示部の一例、招待情報提示部の一例）は、招待通知取得部１６７が取得した招待通知情報に基づく招待情報を提示する。

なお、被招待ユーザ（招待されるユーザの一例）に対応した情報は、招待申請情報に関連付けられていればよく、当該招待申請情報に含まれなくともよい。例えば、ユーザ端末１００の招待通知取得部１６７は、他のユーザ端末１００（他端末装置の一例）から管理サーバ２００に対して送信された招待申請情報に関連付けられた被招待ユーザ（招待されるユーザの一例）のユーザＩＤ（識別情報の一例）に基づいて、申請元アプリ１０（特定の機能を実行させたアプリケーションの一例）へ招待申請されたユーザ（被招待ユーザの一例）が自ユーザとなる招待申請情報に基づく招待通知情報を管理サーバ２００から取得してもよい。

すなわち、招待通知取得部１６７は、他のユーザ端末１００（他端末装置の一例）から管理サーバ２００に対して送信された招待申請情報のうち、被招待ユーザ（招待されるユーザの一例）が自ユーザとなる招待申請情報に基づく招待通知情報を管理サーバ２００から取得してもよい。そして、提示部１６８（第２表示制御部の一例）は、例えば、招待通知取得部１６７が取得した招待通知情報に基づく招待情報を表示部１２０に表示させる。

これにより、ユーザ端末１００は、自ユーザが被招待ユーザとなる招待申請記録が管理サーバ２００に管理されている場合、当該招待申請記録に基づく招待通知情報を取得して提示する（表示部１２０に表示させる）ことができる。即ち、相互招待システム５００において、招待ユーザからの招待申請が被招待ユーザに通知される。

（１９）ユーザ端末１００は、提示部１６８（第２提示部の一例）が提示した招待情報に対する第３操作に基づいて、当該招待情報が示す申請元アプリ１０（アプリケーションの一例）をインストール可能な画面に遷移させる画面遷移部１６９を備えている。

例えば、画面遷移部１６９は、提示部１６８（第２表示制御部の一例）が表示部１２０に表示させた招待情報に対する第３操作に基づいて、当該招待情報が示す申請元アプリ１０（アプリケーションの一例）をインストール可能な画面に遷移させる。

これにより、ユーザ端末１００は、管理サーバ２００から取得した招待通知情報に基づく招待情報が承諾された場合、承諾された招待情報に対応する申請元アプリ１０をインストール可能なストアページをユーザに特別な操作をさせることなく自動で表示することができる。

（２０）ユーザ端末１００は、提示部１６８（第２提示部の一例、招待情報提示部の一例）が提示した招待情報のうちの第３操作がされた招待情報に対応する招待通知情報に含まれる少なくとも一部の情報をユーザ端末１００（自端末装置の一例）の端末記憶部１４０（記憶部の一例）に記憶させる招待情報管理部１７０を備えている。

なお、招待情報管理部１７０は、招待通知情報に含まれる少なくとも一部の情報に代えて、招待通知情報に関連付けられた少なくとも一部の情報を端末記憶部１４０に記憶させてもよい。
例えば、招待情報管理部１７０は、提示部１６８（第２表示制御部の一例）が表示部１２０に表示させた招待情報のうちの第３操作がされた招待情報に対応する招待通知情報に関連付けられた少なくとも一部の情報をユーザ端末１００（自端末装置の一例）の端末記憶部１４０（記憶部の一例）に記憶させてもよい。

これにより、ユーザ端末１００は、承諾された招待情報に対応する招待通知情報を記憶させておくことにより、この招待情報に対応する申請元アプリ１０がインストールされた場合に、当該インストールされた申請元アプリ１０が招待申請されたものであることを特定できる。

（２１）ユーザ端末１００は、提示部１６８（招待情報提示部の一例）が提示した招待情報のうちのいずれかに対応する申請元アプリ１０（特定の機能を実行させたアプリケーションの一例）がユーザ端末１００（自端末装置の一例）にインストールされ、且つ所定の条件が充足された場合に、招待情報に対応した招待成立情報を管理サーバ２００に対して送信する招待成立通知部１７１を備えている。この所定の条件には、申請元アプリ１０がインストールされて初めて実行（起動）したことが含まれてもよい。

例えば、招待成立通知部１７１は、提示部１６８（第２表示制御部の一例）が表示部１２０に表示させた招待情報のうちのいずれかに対応する申請元アプリ１０（特定の機能を実行させたアプリケーションの一例）がユーザ端末１００（自端末装置の一例）にインストールされ、且つ所定の条件が充足された場合に、招待情報に対応した招待成立情報を管理サーバ２００に対して送信する。

例えば、招待成立通知部１７１は、通常モードで動作中の申請元アプリ１０（アプリケーションの一例）において所定の条件が充足された場合に、ユーザ端末１００の端末記憶部１４０に、申請元アプリ１０（動作中のアプリケーションの一例）に対応した招待通知情報に含まれる少なくとも一部の情報が記憶されていることを条件として、招待通知情報に対応した招待成立情報を管理サーバ２００に対して送信する。

なお、上述したように、招待情報管理部１７０は、提示部１６８（第２表示制御部の一例、招待情報提示部の一例）が表示部１２０に表示させた招待情報のうちの第３操作がされた招待情報に対応する招待通知情報に関連付けられた少なくとも一部の情報をユーザ端末１００（自端末装置の一例）の端末記憶部１４０（記憶部の一例）に記憶させてもよい。この場合、招待成立通知部１７１は、通常モードで動作中の申請元アプリ１０（第１アプリケーションの一例）において所定の条件が充足された場合に、ユーザ端末１００の端末記憶部１４０に、申請元アプリ１０に対応した招待通知情報に関連付けられた少なくとも一部の情報が記憶されていることを条件として、招待通知情報に対応した招待成立情報を管理サーバ２００に対して送信してもよい。

これにより、ユーザ端末１００は、招待ユーザからの招待申請に基づいて被招待ユーザが申請元アプリ１０をインストールして利用したことによって、当該招待申請により招待が成立したことを管理サーバ２００に通知することができる。ここで、招待成立情報を管理サーバ２００に対して送信するタイミングを、申請元アプリ１０において、申請元アプリ１０を利用後の所定の条件が充足された場合とすれば、単に申請元アプリ１０がインストールされただけで利用されていない場合を招待成立の条件が除くことができる。

（２２）管理サーバ２００は、招待成立受取部２３７と、招待成立処理部２３８とを備えている。招待成立受取部２３７は、被招待ユーザ（第２ユーザの一例）のユーザ端末１００で申請元アプリ１０（第１アプリケーションの一例）が起動したことに基づいて、招待通知情報に対応する招待が成立したことを示す招待成立情報を、被招待ユーザのユーザ端末１００から受け取る。例えば、招待成立受取部２３７は、被招待ユーザのユーザ端末１００の申請元アプリ１０（第１アプリケーションの一例）から招待成立情報を受け取る。
招待成立処理部２３８は、招待成立受取部２３７が受け取った招待成立情報に基づく所定の処理を行う。

これにより、管理サーバ２００は、招待ユーザからの招待申請による招待が成立した場合、例えば、招待が成立したことによる所定の報酬（例えば、インセンティブ）を申請元アプリ１０における招待ユーザに対して付与することができる。

なお、招待成立受取部２３７は、上記招待成立情報を、申請元アプリ１０に対応するアプリサーバ３１０（ゲームＡ）から取得してもよい。例えば、被招待ユーザのユーザ端末１００で申請元アプリ１０が起動した場合、申請元アプリ１０に対応するアプリサーバ３１０（ゲームＡ）は、被招待ユーザのユーザ端末１００との間で通信が行われ、被招待ユーザのユーザ端末１００で申請元アプリ１０が起動したことを認識することができる。そこで、上記招待成立情報を、申請元アプリ１０に対応するアプリサーバ３１０（ゲームＡ）から管理サーバ２００に送信するようにしてもよい。
例えば、招待成立受取部２３７は、被招待ユーザ（第２ユーザの一例）のユーザ端末１００で申請元アプリ１０（第１アプリケーションの一例）が起動したことに基づいて被招待ユーザのユーザ端末１００又は申請元アプリ１０に対応するアプリサーバ３１０（サーバ装置の一例）から送信された、招待通知情報に対応する招待が成立したことを示す招待成立情報を受け取る。そして、招待成立処理部２３８は、招待成立受取部２３７が受け取った招待成立情報に基づく所定の処理を行う。

これにより、管理サーバ２００は、招待ユーザからの招待申請による招待が成立した場合、成立したことを認識することができる。また、管理サーバ２００は、招待ユーザからの招待申請による招待が成立したことを認識した場合、例えば、所定の報酬が申請元アプリ１０における招待ユーザに対して付与されるようにすることができる。

例えば、招待成立処理部２３８は、所定の処理として、招待成立受取部２３７が受け取った招待成立情報に基づいて、招待通知情報に対応する招待が成立したことを通知する招待完了通知情報を、招待ユーザ（第１ユーザの一例）のユーザ端末１００又は申請元アプリ１０（第１アプリケーションの一例）に対応するアプリサーバ３１０（サーバ装置の一例）に送信する。
これにより、招待ユーザのユーザ端末１００で実行されている申請元アプリ１０又は申請元アプリ１０に対応するアプリサーバ３１０は、招待通知情報に対応する招待が成立したことを条件として、報酬を付与することができる。

具体的には、招待成立処理部２３８は、招待成立受取部２３７が受け取った招待成立情報に基づいて、申請元アプリ１０（第１アプリケーションの一例）における招待ユーザ（第１ユーザの一例）に報酬が付与されるように、少なくとも申請元アプリ１０における招待ユーザに対応する情報を招待完了通知情報として、招待ユーザのユーザ端末１００又は申請元アプリ１０に対応するアプリサーバ３１０（サーバ装置の一例）に送信する。
これにより、招待ユーザのユーザ端末１００で実行されている申請元アプリ１０又は申請元アプリ１０に対応するアプリサーバ３１０は、招待通知情報に対応する招待が成立したことを条件として、招待ユーザに対して報酬を付与することができる。

なお、管理サーバ２００は、招待ユーザからの招待申請による招待が成立した場合、所定の報酬が申請元アプリ１０における被招待ユーザに対して付与されるようにしてもよい。また、管理サーバ２００は、申請先アプリ２０における招待ユーザ又は被招待ユーザに対して所定の報酬が付与されるようにしてもよいし、複数のアプリケーションにおいて共通で利用できる報酬が招待ユーザ又は被招待ユーザに対して付与されるようにしてもよい。

また、上述の報酬は、申請元アプリ１０及び申請先アプリ２０とは異なる他のアプリケーションで利用できる報酬、またはウェブサイトで利用できる報酬（例えば、通信網を介した通信により商品やサービスを売買するときに利用するできる通貨やポイント等）としてもよい。この場合、管理サーバ２００は、例えば、ユーザに付与された報酬に関する情報を一旦管理し、その後所定の手続きが行われることで、他のアプリケーションで利用できる報酬、またはウェブサイトで利用できる報酬となるように、当該管理している報酬に関する情報を他のアプリケーションに対応するサーバ装置、またはウェブサイトに対応するサーバ装置に送信してもよい。

（２３）招待成立情報には招待通知情報の一部または全部が含まれ、当該招待通知情報の一部または全部は、被招待ユーザ（第２ユーザの一例）のユーザ端末１００にて申請元アプリ１０（第１アプリケーションの一例）が、申請先アプリ２０（第２アプリケーションの一例）から直接的又は当該ユーザ端末１００の端末記憶部１４０（記憶部の一例）を介して間接的に取得したものである。

これにより、ユーザ端末１００は、申請先アプリ２０において取得された招待通知情報の一部または全部が含まれる招待成立情報を、申請元アプリ１０から送信することができる。

なお、招待通知情報の一部または全部は、招待成立情報に関連付けられていればよく、当該招待成立情報に含まれなくともよい。例えば、招待成立情報には招待通知情報の一部または全部が関連付けられており、当該招待通知情報の一部または全部は、被招待ユーザ（第２ユーザの一例）のユーザ端末１００にて申請元アプリ１０（第１アプリケーションの一例）が、申請先アプリ２０（第２アプリケーションの一例）から直接的又は当該ユーザ端末１００の端末記憶部１４０（記憶部の一例）を介して間接的に取得したものであってもよい。
これにより、管理サーバ２００は、招待通知情報の一部または全部が関連付けられた招待成立情報を取得することができる。

（２４）上述のアプリケーションリスト取得部１６１の機能と、特定モード起動部１６２の機能と、ユーザリスト取得部１６３の機能と、招待申請通知部１６４の機能と、特定モード終了部１６５の機能と、照会部１６６の機能と、招待通知取得部１６７の機能と、提示部１６８の機能と、画面遷移部１６９の機能と、招待情報管理部１７０の機能と、招待成立通知部１７１の機能とが、ユーザ端末１００にインストールされる対応アプリケーションのプログラム（例えば、申請元アプリ１０及び申請先アプリ２０のそれぞれのプログラム）に組み込まれたＳＤＫ１１（プログラム（ソフトウェア）の一例）に基づいて実行される。

すなわち、ユーザ端末１００にインストールされる対応アプリケーションのプログラム（例えば、申請元アプリ１０及び申請先アプリ２０のそれぞれのプログラム）に組み込まれたＳＤＫ１１（プログラム（ソフトウェア）の一例）が実行されることにより、上述のアプリケーションリスト取得部１６１の機能と、特定モード起動部１６２（起動部の一例）の機能と、ユーザリスト取得部１６３（招待候補ユーザ情報取得部の一例）の機能と、招待申請通知部１６４の機能と、特定モード終了部１６５の機能と、照会部１６６の機能と、招待通知取得部１６７の機能と、提示部１６８（第１表示制御部の一例、第２表示辞制御部の一例）の機能と、画面遷移部１６９の機能と、招待情報管理部１７０の機能と、招待成立通知部１７１の機能と、が実現される。

例えば、申請元アプリ１０に組み込まれたＳＤＫ１１Ａが、アプリケーションリスト取得部１６１の機能と、特定モード起動部１６２の機能と、提示部１６８の一部の機能と、招待成立通知部１７１の機能とを実行し、申請先アプリ２０に組み込まれたＳＤＫ１１Ｂが、ユーザリスト取得部１６３の機能と、招待申請通知部１６４の機能と、特定モード終了部１６５の機能と、照会部１６６の機能と、招待通知取得部１６７の機能と、提示部１６８の一部の機能と、画面遷移部１６９の機能と、招待情報管理部１７０の機能とを実行する。なお、ＳＤＫ１１ＡとＳＤＫ１１Ｂとはそれぞれ同様の機能を有しており、申請元アプリ１０に組み込まれているか、または申請先アプリ２０に組み込まれているかに応じて対応する機能を実行する。

例えば、ユーザ端末１００にインストールされる申請元アプリ１０（アプリケーションの一例）のプログラムに組み込まれたＳＤＫ１１Ａ（プログラム（ソフトウェア）の一例）が実行されることにより、特定モード起動部１６２（起動部の一例）の機能が実現され、ユーザ端末１００にインストールされる申請先アプリ２０（他のアプリケーションの一例）のプログラムに組み込まれたＳＤＫ１１Ｂ（プログラム（ソフトウェア）の一例）が実行されることにより、ユーザリスト取得部１６３（ユーザ情報取得部の一例）の機能と、招待申請通知部１６４の機能とが実現される。

このように、アプリケーションにＳＤＫ１１を組み込むことにより、本実施形態の相互招待システム５００に対応した対応アプリケーションとすることができる。よって、例えば、既存のアプリケーションやこれから開発するアプリケーションにおいても、ＳＤＫ１１を組み込み可能なようにアプリケーションのプログラムを更新または小変更すれば、当該アプリケーションを相互招待システム５００に対応した対応アプリケーションとすることができる。

なお、上記実施形態では、例えば、アプリケーションリスト取得部１６１と、特定モード起動部１６２（起動部）と、提示部１６８と、招待情報管理部１７０と、招待成立通知部１７１とが、申請元アプリ１０のＳＤＫ１１Ａが実行する機能構成であり、ユーザリスト取得部１６３と、招待申請通知部１６４と、特定モード終了部１６５と、照会部１６６と、招待通知取得部１６７と、提示部１６８と、画面遷移部１６９とが、申請先アプリ２０のＳＤＫ１１Ｂが実行する機能構成である例を説明したが、これに限られるものではない。
上述した、申請元アプリ１０に組み込まれたＳＤＫ１１Ａと、申請先アプリ２０に組み込まれたＳＤＫ１１Ｂとのそれぞれが実行する招待処理の機能構成は、一例であって、ＳＤＫ１１ＡとＳＤＫ１１Ｂ」とのそれぞれが実行する機能構成を適宜変更してもよい。例えば、招待申請通知部１６４をＳＤＫ１１Ａが実行する機能構成としてもよい。

＜第２の実施形態＞
次に、本発明の第２の実施形態を説明する。本実施形態の相互招待システム５００の構成は、予め設定した任意の対応アプリケーションを、被招待ユーザを選択可能な対応アプリケーションのアプリケーションリストから除外できるようにした点が第１の実施形態に対して相違する。

図１１は、第２の実施形態による管理サーバ２００の構成の一例を示す構成図である。この図に示す管理サーバ２００は、記憶部２２０がさらに抽出条件記憶部２２５を備えていることと、制御部２３０が抽出部２３９をさらに備えていることが、図６に示す第１の実施形態による管理サーバ２００の構成と相違する。なお、図１１において、図６に示す各部に対応する構成には同じ符号を付けている。以下、図１１を参照して、本実施形態に係る特徴的な構成と処理について説明する。

抽出条件記憶部２２５は、申請元アプリ１０（第１アプリケーションの一例）への招待申請が可能な対応アプリケーションを抽出する抽出条件を記憶する。例えば、抽出条件記憶部２２５は、上記抽出条件として、相互招待システム５００において互いに招待させたくない対応アプリケーションの組み合わせに関する設定を示す相互招待禁止設定情報を記憶する相互招待拒否設定記憶部２２６を備えている。

具体的には、相互招待拒否設定記憶部２２６は、招待申請の禁止を設定する設定側アプリケーションと、当該設定側アプリケーションに対する招待申請を禁止される被設定側アプリケーションとを組みにした相互招待禁止設定情報（第３禁止情報）を記憶する。図１２は、相互招待拒否設定記憶部２２６に記憶される相互招待禁止設定情報の一例を示す図である。相互招待禁止設定情報には、フィルタＩＤ（FilterID）と、ブロックするアプリＩＤ（ApIDfrom）と、ブロックされるアプリＩＤ（ApIDto）とが関連付けられている。

フィルタＩＤ（FilterID）は、相互招待禁止設定情報毎に識別可能なように各相互招待禁止設定情報が登録された順に発行される管理ＩＤである。ブロックするアプリＩＤ（ApIDfrom）には、招待申請の禁止を設定する設定側アプリケーションのアプリＩＤが設定される。ブロックされるアプリＩＤ（ApIDto）には、招待申請を禁止される被設定側アプリケーションのアプリＩＤが設定される。

例えば、申請元アプリ１０のアプリＩＤがブロックされるアプリＩＤ（ApIDto）に設定されている場合には、ブロックするアプリＩＤ（ApIDfrom）に設定されている対応アプリケーションがアプリケーションリストから除かれる。つまり、申請元アプリ１０（ゲームＡ）から申請先アプリ２０（ゲームＢ）に対する招待を禁止したい場合には、ブロックされるアプリＩＤ（ApIDto）に申請元アプリ１０（ゲームＡ）のアプリＩＤを設定し、ブロックするアプリＩＤ（ApIDfrom）に申請先アプリ２０のアプリＩＤを設定すればよい。

なお、申請元アプリ１０のアプリＩＤがブロックするアプリＩＤ（ApIDfrom）に設定されている場合には、ブロックされるアプリＩＤ（ApIDto）に設定されている対応アプリケーションがアプリケーションリストから除かれてもよい。即ち、ブロックするアプリＩＤ（ApIDfrom）とブロックされるアプリＩＤ（ApIDto）とにそれぞれ設定される招待申請の禁止を設定する設定側アプリケーションと、招待申請を禁止される被設定側アプリケーションとに対して、一方向に対して招待申請が禁止されるようにしてもよいし、双方向に対して招待申請が禁止されるようにしてもよい。

ここで、上述の相互招待拒否設定記憶部２２６に記憶される相互招待禁止設定情報は、アプリケーション管理部２３１によって管理される。即ち、アプリケーション管理部２３１は、招待申請の禁止を設定する設定側アプリケーションと、当該設定側アプリケーションに対する招待申請を禁止される被設定側アプリケーションとを組みにした相互招待禁止設定情報を管理する。

抽出部２３９は、相互招待拒否設定記憶部２２６に記憶されている相互招待禁止設定情報に基づいた抽出条件により、対応アプリケーションの中から申請元アプリ１０（第１アプリケーション）への招待申請が可能な対応アプリケーションを抽出する。

そして、アプリケーションリスト通知部２３２は、抽出部２３９が抽出した対応アプリケーションの少なくとも一部を含むアプリケーションリストを、申請元アプリ１０（第１アプリケーションの一例）への招待申請が可能な対応アプリケーションのアプリケーションリストとして、招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信する。

これにより、招待禁止情報を予め設定しておくことで、任意の対応アプリケーションを、被招待ユーザを選択可能な対応アプリケーションのアプリケーションリストから除外することができる。

〔まとめ〕
以上説明したように、アプリケーション管理部２３１は、申請元アプリ１０（第１アプリケーションの一例）および申請先アプリ２０（第２アプリケーションの一例）を含む複数の対応アプリケーションのそれぞれに関する情報を管理する。ここで、アプリケーション管理部２３１が管理する複数の対応アプリケーションのそれぞれに関する情報とは、例えば、複数の対応アプリケーションのそれぞれを示す情報や複数の対応アプリケーションのそれぞれに設定された招待申請の禁止に関する情報である。
そして、アプリケーションリスト通知部２３２（アプリケーション情報通知部の一例）は、アプリケーション管理部２３１を参照して、申請元アプリ１０への招待申請が可能であるか否か（例えば、招待申請の禁止が設定されてないか）を判定し、招待申請が可能なアプリケーションを示すアプリケーションリスト（アプリケーションを示す情報の一例）を招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信する。
これにより、管理サーバ２００は、招待申請可能な対応アプリケーションのみのアプリケーションリストを招待ユーザのユーザ端末１００に対して送信することができる。

例えば、アプリケーション管理部２３１は、招待申請の禁止を設定する設定側アプリケーションと、当該設定側アプリケーションに対する招待申請が禁止される被設定側アプリケーションと、を組みにした招待禁止情報を管理する。
アプリケーションリスト通知部２３２（アプリケーション情報通知部の一例）は、アプリケーション管理部２３１が管理している招待禁止情報を参照して、申請元アプリ１０（第１アプリケーションの一例）を被設定側アプリケーションに設定している招待禁止情報がある場合には、当該招待禁止情報（第３禁止情報の一例）が示す設定側アプリケーションを除いた対応アプリケーションのアプリケーションリストを、招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信する。

具体的には、アプリケーションリスト通知部２３２は、抽出部２３９が抽出条件に基づいて抽出した対応アプリケーションのアプリケーションリストを、申請元アプリ１０への招待申請が可能な対応アプリケーションのアプリケーションリストとして招待ユーザのユーザ端末１００に対して送信してもよい。
例えば、抽出条件として、アプリケーション管理部２３１で管理している招待禁止情報のうち、申請元アプリ１０を被設定側アプリケーションに設定している招待禁止情報があるとする。この場合には、抽出部２３９は、当該招待禁止情報が示す設定側アプリケーションに対応する対応アプリケーションを、申請元アプリ１０への招待申請を拒否する設定がされた対応アプリケーションとして除いた対応アプリケーションを抽出する。そして、アプリケーションリスト通知部２３２は、抽出部２３９の抽出結果に基づいて、申請元アプリ１０への招待申請を拒否する設定がされた対応アプリケーションを除いたアプリケーションリストを、招待ユーザのユーザ端末１００に対して送信する。

これにより、相互招待システム５００では、相互招待させたくない対応アプリケーションの関係を管理サーバ２００に設定することができる。例えば、対応アプリケーションの中でレイティング（年齢制限）が設定されているものがあれば、レイティングが設定されていない申請元アプリ１０から、レイティングが設定されている申請先アプリ２０への招待を行わせないように、レイティングが設定されている申請先アプリ２０をアプリケーションリストから除外することができる。

これにより、相互招待禁止設定情報の設定側アプリケーションと被設定側アプリケーションとのそれぞれに設定された対応アプリケーションは、互いに（双方向に）アプリケーションリストへの掲載を禁止（ブロック）することができる。

なお、図１２に示すアプリ間フィルタ情報におけるブロックするアプリＩＤ（設定側アプリケーションのアプリＩＤ）とブロックされるアプリＩＤ（被設定側アプリケーションのアプリＩＤ）とは双方向に掲載が禁止される関係としてもよい。即ち、アプリケーションリスト通知部２３２（アプリケーション情報通知部の一例）は、アプリケーション管理部２３１が管理している相互招待禁止設定情報を参照して、申請元アプリ１０を設定側アプリケーションに設定している招待禁止情報がある場合には、当該招待禁止情報が示す被設定側アプリケーションを除いたアプリケーションのアプリケーションリスト（アプリケーションを示す情報の一例）を、招待ユーザのユーザ端末１００に対して送信してもよい。

このように、双方向に対して招待申請が禁止されるようにすることで、互いに一方向の相互招待禁止設定情報を記憶する必要がなくなるので相互招待拒否設定記憶部２２６の記憶容量を削減することができる。なお、相互招待拒否設定記憶部２２６に記憶する相互招待禁止設定情報に、一方向に有効か双方向に有効かを示す情報を付加してもよい。

＜第３の実施形態＞
次に、本発明の第３の実施形態を説明する。本実施形態の相互招待システム５００の構成は、被招待ユーザとして選択可能なユーザのユーザリストから、予め設定されたユーザを除外できるようにした点が第１の実施形態に対して相違する。

第１の実施形態では、特定モードで動作中の申請先アプリ２０に対応するアプリサーバ３００（例えば、申請先アプリ２０（ゲームＢ）に対応するアプリサーバ３２０（ゲームＢ））から取得したユーザリストに対応するフレンド一覧が表示部１２０に表示される構成を説明した。本実施形態では、このユーザリストに含まれユーザを所定の抽出条件に従ってフィルタリングしてから新たなユーザリスト（以下、招待候補ユーザリストとも称する）として表示部１２０に表示されるように構成する。このユーザリストのフィルタリング処理は、アプリサーバ３００から取得したユーザリストが、ユーザ端末１００−１（ＳＤＫ１１Ｂ）から管理サーバ２００に通知されることによって、管理サーバ２００において行われる。

〔ユーザリストのフィルタリング処理の動作の説明〕
図１３を参照して、ユーザリストをフィルタリングする場合の招待処理の動作について説明する。図１３は、本実施形態による招待処理の動作の一例を示すフローチャートである。この図に示す招待処理は、図９に示す第１の実施形態の招待処理に対して、ユーザリストのフィルタリング処理（ステップＳＢ１３０、ＳＥ１２０、ＳＢ１４０）が追加されている点が相違する。なお、この図１３において、図９に示す処理と同様の処理には同じ符号を付けており、その説明を省略する。

ステップＳＢ１２０において、ユーザ端末１００−１の申請先アプリ２０（ゲームＢ）は、アプリサーバ３２０（ゲームＢ）からユーザリストを取得すると、申請先アプリ２０（ゲームＢ）のＳＤＫ１１Ｂのユーザリスト取得部１６３は、当該ユーザリストを申請先アプリ２０（ゲームＢ）から取得し、取得したユーザリストを管理サーバ２００に通知する。例えば、ユーザリスト取得部１６３は、当該ユーザリストに含まれるユーザのユーザＩＤを含むフィルタリング要求情報を管理サーバ２００に対して送信する（ＲＥＱ１２、ステップＳＢ１３０）。

ここで、フィルタリング要求情報には、例えば、申請元アプリＩＤ（ApIDfrom）と、申請先アプリＩＤ（ApIDto）と、申請先アプリの招待ユーザＩＤ（Apto_UIDfrom）と、申請先アプリの被招待ユーザＩＤ（Apto_UIDto）とが含まれる。

次に、管理サーバ２００は、ユーザ端末１００−１（ＳＤＫ１１Ｂ）からフィルタリング要求情報を受け取ることによりユーザリストを取得すると、所定の抽出条件に従ってフィルタリング処理を行い、フィルタリング結果としてフィルタリング後の招待候補ユーザリストをユーザ端末１００−１（ＳＤＫ１１Ｂ）に対して送信する（ＲＥＳ１２、ステップＳＥ１２０）。このフィルタリング後の招待候補ユーザリスト（フィルタリング結果）には、ユーザ端末１００−１（ＳＤＫ１１Ｂ）から管理サーバ２００に通知されたユーザリストの中から所定の抽出条件によって抽出されたユーザのユーザＩＤが含まれている。

そして、ユーザ端末１００−１のＳＤＫ１１Ｂのユーザリスト取得部１６３は、送信したフィルタリング要求情報に対応するフィルタリング結果として、フィルタリング後の招待候補ユーザリストを取得する（ステップＳＢ１４０）。

ステップＳＢ１４０において、ユーザリスト取得部１６３がフィルタリング後の招待候補ユーザリストを取得すると、ユーザ端末１００−１のＳＤＫ１１Ｂの提示部１６８は、当該招待候補ユーザリストに含まれるユーザの少なくとも一部を、申請元アプリ１０（ゲームＡ）への招待候補となるユーザリストに対応するフレンド一覧を表示部１２０に表示させる（ステップＳＢ１５０）。

〔第３の実施形態の管理サーバ２００の構成〕
次に、上述のフィルタリング処理を実行する管理サーバ２００の構成について説明する。
図１４は、本実施形態による管理サーバ２００の構成の一例を示す構成図である。この図に示す管理サーバ２００は、制御部２３０がユーザリスト通知部２４０をさらに備えていることと、抽出条件記憶部２２５が招待申請拒否ユーザ設定記憶部２２７と、招待申請拒否アプリ設定記憶部２２８とを備えていることが、図１１に示す第２の実施形態による管理サーバ２００の構成と相違する。なお、図１４において、図１１に示す各部に対応する構成には同じ符号を付けている。以下、図１４を参照して、本実施形態に係る特徴的な構成と処理について説明する。

管理サーバ２００のユーザリスト通知部２４０は、ユーザ端末１００において特定モードで動作中の申請先アプリ２０（ＳＤＫ１１Ｂ）からユーザリストのフィルタリングを要求するフィルタリング要求情報を取得する。取得した場合、ユーザリスト通知部２４０は、抽出部２３９によるフィルタリング結果（抽出結果）に基づいて、当該ユーザリストに含まれるユーザのうち申請元アプリ１０への招待候補となるユーザのユーザリスト（招待候補ユーザリスト）をユーザ端末１００（ＳＤＫ１１Ｂ）に対して送信する。

また、本実施形態では、抽出部２３９は、ユーザ端末１００の申請先アプリ２０（ＳＤＫ１１Ｂ）からユーザリストを取得した場合に当該ユーザリストに含まれるユーザのうち、申請元アプリ１０への招待候補となるユーザを所定の抽出条件に基づいてフィルタリング（抽出）する。

抽出部２３９が抽出する所定の抽出条件は、アプリケーション管理部２３１によって管理されており、具体的には、抽出条件記憶部２２５に記憶されている。抽出条件記憶部２２５は、招待申請拒否ユーザ設定記憶部２２７と、招待申請拒否アプリ設定記憶部２２８と、を備えている。

〔招待申請拒否ユーザ設定〕
招待申請拒否ユーザ設定記憶部２２７は、抽出部２３９の抽出条件として、相互招待システム５００において、招待を受け入れたくないユーザに関する設定を示す招待申請拒否ユーザ設定情報を記憶する。例えば、招待申請拒否ユーザ設定記憶部２２７は、招待申請の禁止を設定する設定側ユーザと、当該設定側ユーザに対する招待申請を禁止される被設定側ユーザと、この設定を有効にする対応アプリケーションとを組みにした招待申請拒否ユーザ設定情報（第１禁止情報）を記憶する。

図１５は、招待申請拒否ユーザ設定記憶部２２７に記憶される招待申請拒否ユーザ設定情報の一例を示す図である。招待申請拒否ユーザ設定情報には、フィルタＩＤ（FilterID）と、アプリＩＤ（FilterApID）と、ブロックするユーザ（UIDfrom）と、ブロックされるユーザ（UIDto）とが関連付けられている。フィルタＩＤ（FilterID）は、招待申請拒否ユーザ設定情報毎に識別可能なように各招待申請拒否ユーザ設定情報が登録された順に発行される管理ＩＤである。アプリＩＤ（FilterApID）には、この禁止設定を有効にする対応アプリケーション（申請先アプリ２０）のアプリＩＤが設定される。ブロックするユーザ（UIDfrom）には、招待申請の禁止を設定する設定側ユーザのユーザＩＤが設定される。ブロックされるユーザ（UIDto）には、招待申請を禁止される被設定側ユーザのユーザＩＤが設定される。

例えば、申請先アプリ２０がアプリＩＤ（FilterApID）に設定され、且つ招待ユーザのユーザＩＤがブロックされるユーザ（UIDto）に設定されている場合には、招待ユーザの申請先アプリ２０における招待候補ユーザリストから、ブロックするユーザ（UIDfrom）に設定されているユーザが除かれる。従って、申請先アプリ２０（ゲームＢ）において、ユーザＸからの招待をユーザＹが受けたくない場合には、例えば、アプリＩＤ（FilterApID）に申請先アプリ２０（ゲームＢ）のアプリＩＤを設定し、ブロックされるユーザ（UIDto）にユーザＸのユーザＩＤを設定し、ブロックするユーザ（UIDfrom）にユーザＹのユーザＩＤを設定すればよい。これにより、ユーザＸの申請先アプリ２０（ゲームＢ）では、招待候補ユーザリストからユーザＹが除外される。

なお、申請先アプリ２０がアプリＩＤ（FilterApID）に設定され、且つ招待ユーザのユーザＩＤがブロックするユーザ（UIDfrom）に設定されている場合には、招待ユーザの申請先アプリ２０における招待候補ユーザリストから、ブロックされるユーザ（UIDto）に設定されているユーザが除かれてもよい。即ち、ブロックするユーザ（UIDfrom）とブロックされるユーザ（UIDto）とにそれぞれ設定される招待申請の禁止を設定する設定側ユーザと、招待申請を禁止される被設定側ユーザとに対して、一方向に対して招待申請が禁止されるようにしてもよいし、双方向に対して招待申請が禁止されるようにしてもよい。

なお、ＳＤＫ１１の機能として、ユーザ端末１００から、招待を受け入れたくないユーザを設定可能とする。ユーザ（ブロックするユーザ）が、対応アプリケーションのいずれかで当該ブロック設定を行うと、アプリＩＤ（FilterApID）として当該対応アプリケーションのアプリＩＤ、ブロックするユーザ（UIDfrom）としてブロック設定を行うユーザのユーザＩＤ、ブロックされるユーザ（UIDto）として招待を受け入れたくないユーザのユーザＩＤのそれぞれが設定された招待申請拒否ユーザ設定情報が招待申請拒否ユーザ設定記憶部２２７に登録されて記憶される。

〔招待申請拒否アプリ設定〕
招待申請拒否アプリ設定記憶部２２８は、抽出部２３９の抽出条件として、相互招待システム５００において、ユーザが招待を受け入れたくない対応アプリケーションに関する設定を示す招待申請拒否アプリ設定情報を記憶する。

図１６は、招待申請拒否アプリ設定記憶部２２８に記憶される招待申請拒否アプリ設定情報の一例を示す図である。招待申請拒否アプリ設定情報には、フィルタＩＤ（FilterID）と、ブロックするユーザ（UIDfrom）と、ブロックされる対応アプリケーションのアプリＩＤ（FilterApID）とが関連付けられている。フィルタＩＤ（FilterID）は、招待申請拒否アプリ設定情報毎に識別可能なように各招待申請拒否アプリ設定情報が登録された順に発行される管理ＩＤである。アプリＩＤ（FilterApID）には、ユーザが招待を受け入れたくない対応アプリケーションのアプリＩＤが設定される。ブロックするユーザ（UIDfrom）には、このアプリＩＤ（FilterApID）に設定されたアプリＩＤが示す対応アプリケーションにおいて招待を受け入れたくないユーザのユーザＩＤが設定される。

なお、ＳＤＫ１１の機能として、ユーザ端末１００から、ユーザが招待を受け入れたくない対応アプリケーションを設定可能とする。ユーザ（ブロックするユーザ）が、対応アプリケーションのいずれかで当該ブロック設定を行うと、アプリＩＤ（FilterApID）として当該対応アプリケーションのアプリＩＤ、ブロックするユーザ（UIDfrom）としてブロック設定を行うユーザのユーザＩＤのそれぞれが設定された招待申請拒否アプリ設定情報が招待申請拒否アプリ設定記憶部２２８に登録されて記憶される。

例えば、申請先アプリ２０（ゲームＢ）がアプリＩＤ（FilterApID）に設定され、且つユーザＹのユーザＩＤがブロックするユーザ（UIDfrom）に設定されていたとする。この場合には、招待ユーザ（例えば、ユーザＸ）の申請先アプリ２０（ゲームＢ）において提示される招待候補ユーザリストからユーザＹが除かれる。

また、申請元アプリ１０（ゲームＡ）がアプリＩＤ（FilterApID）に設定され、且つユーザＹのユーザＩＤがブロックするユーザ（UIDfrom）に設定されていたとする。この場合には、招待ユーザ（例えば、ユーザＸ）に対して提示される招待候補のフレンド一覧のうちの申請元アプリ１０（ゲームＡ）へ招待する招待候補ユーザのフレンド一覧からユーザＹが除かれる。これにより、例えば、既にインストールされている対応アプリケーション、または一度プレイされた後にアンインストールされた対応アプリケーションへの招待申請がされないようにブロックすることができる。

〔まとめ〕
（１）以上説明したように、本実施形態のユーザ端末１００（端末装置の一例）は、アプリケーションリスト取得部１６１と、特定モード起動部１６２（起動部の一例）と、提示部１６８（第１提示部の一例、第２提示部の一例）と、ユーザリスト取得部１６３と、招待申請通知部１６４と、照会部１６６と、招待通知取得部１６７と、画面遷移部１６９と、招待情報管理部１７０とを備えている。
アプリケーションリスト取得部１６１は、通常モードで動作中の申請元アプリ１０（アプリケーションの一例）における第１操作に基づいて、申請先アプリ２０（第２アプリケーションの一例）がインストールされたユーザ端末１００に対して、当該申請元アプリ１０（第１アプリケーションの一例）をインストールさせる処理（招待処理の一例）に対応する複数の対応アプリケーションの一部または全部からなるアプリケーションリストを管理サーバ２００から取得する。提示部１６８（第１提示部の一例、アプリケーションリスト提示部の一例）は、アプリケーションリスト取得部１６１が取得したアプリケーションリストの中からユーザ端末１００（自端末装置の一例）にインストールされている対応アプリケーションを提示する。
そして、特定モード起動部１６２（起動部の一例）は、提示部１６８（第１提示部の一例、アプリケーションリスト提示部の一例）が提示した対応アプリケーションの中から第２操作に基づいて選択された対応アプリケーションである申請先アプリ２０に対して、通常モードで動作中の申請元アプリ１０（アプリケーションの一例）における招待ユーザ（自ユーザの一例）に対応した第１ユーザ情報（ユーザＩＤや当該ユーザＩＤに関連付けられたトークン情報）を管理サーバ２００に通知可能なように当該選択された申請先アプリ２０（アプリケーションの一例）を特定モードで起動させる。

ユーザリスト取得部１６３は、申請先アプリ２０（アプリケーションの一例）が特定モードで動作中に管理サーバ２００から招待候補となるユーザのユーザリストを取得する。そして、招待申請通知部１６４は、第１ユーザ情報、及びユーザリスト取得部１６３が取得したユーザリストの中から選択されたユーザ（被招待ユーザの一例）に対応した第２ユーザ情報（例えばユーザＩＤ）を含む招待申請情報を管理サーバ２００に対して送信する。

照会部１６６は、通常モードで動作中の申請先アプリ２０において、被招待ユーザが自ユーザ（例えば、ユーザＹ）となる招待申請情報（即ち、自ユーザに対する招待申請情報）の記録（招待申請記録の一例）の有無を管理サーバ２００に対して照会（申請照会の一例）する。そして、招待通知取得部１６７は、照会部１６６が照会した結果、自ユーザに対応した情報が、被招待ユーザに対応した第２ユーザ情報（例えばユーザＩＤ）となる招待申請情報が有る場合に、当該招待申請情報に基づく招待通知情報を管理サーバ２００から取得する。

また、提示部１６８（第２提示部の一例、招待情報提示部の一例）は、招待通知取得部１６７が取得した招待通知情報に基づく招待情報を提示する。画面遷移部１６９は、提示部１６８が提示した招待情報に対する第３操作に基づいて、当該招待情報が示す申請元アプリ１０をインストール可能な画面に遷移させる。
そして、招待情報管理部１７０は、提示部１６８が提示した招待情報のうちの第３操作がされた（被招待ユーザ（例えば、ユーザＹ）によって招待が承諾された）招待情報に対応する招待通知情報に含まれる少なくとも一部の情報をユーザ端末１００の端末記憶部１４０に記憶させる。

なお、ＳＤＫ１１が対応アプリケーションのアプリケーションリストを備えていてもよく、その場合には、当該アプリケーションリストを管理サーバ２００から取得する必要が無いため、ユーザ端末１００は、アプリケーションリスト取得部１６１の構成がなくともよい。
また、被招待ユーザのユーザ端末１００は、管理サーバ２００に対して申請照会を行わなくとも、管理サーバ２００から送信された、当該被招待ユーザに対する招待申請情報に基づく招待通知情報を取得してもよい。例えば、管理サーバ２００は、被招待ユーザのユーザ端末１００において申請先アプリ２０が起動したことを契機として、当該被招待ユーザに対する招待申請情報に基づく招待通知情報を当該被招待ユーザのユーザ端末１００に対して送信してもよい。また、管理サーバ２００は、被招待ユーザのユーザ端末１００に対して招待通知情報を所定の時間周期で送信してもよいし、所定の時刻に定期的に送信してもよい。

従って、本実施形態のユーザ端末１００（端末装置の一例）は、特定モード起動部１６２（起動部の一例）と、提示部１６８（第１表示制御部の一例、第２表示制御部の一例）と、ユーザリスト取得部１６３（招待候補ユーザ情報取得部の一例）と、招待申請通知部１６４と、招待通知取得部１６７と、画面遷移部１６９と、を少なくとも備えた構成としてもよく、各構成について以下のように記載することができる。

提示部１６８（第１表示制御部の一例）は、ユーザ端末１００（自端末装置の一例）にインストールされている申請元アプリ１０（第１アプリケーションの一例）における第１操作に基づいて、一または複数の対応アプリケーションを示す情報を表示部１２０に表示させる。特定モード起動部１６２（起動部の一例）は、提示部１６８が表示させた一または複数の対応アプリケーションを示す情報により示される対応アプリケーションのうちから第２操作に基づいて選択された申請先アプリ２０（第２アプリケーションの一例）を特定モードとして起動させる。ユーザリスト取得部１６３（招待候補ユーザ情報取得部の一例）は、特定モードで動作中の申請先アプリ２０において、管理サーバ２００から申請元アプリ１０へ招待される招待候補となるユーザを示すユーザリスト（招待候補ユーザ情報の一例）を取得する。招待申請通知部１６４は、ユーザリスト取得部１６３が取得した招待候補ユーザリストのうち申請元アプリ１０へ招待される被招待ユーザに対応した第２ユーザ情報（例えばユーザＩＤ）が関連付けられた招待申請情報を管理サーバ２００に対して送信する。

招待通知取得部１６７は、通常モードで動作中の申請元アプリ１０において、自ユーザに対応した情報が被招待ユーザに対応する第２ユーザ情報となる招待申請情報が管理サーバ２００に有る場合に、当該招待申請情報に基づく招待通知情報を管理サーバ２００から取得する。提示部１６８（第２表示制御部の一例）は、招待通知取得部１６７が取得した招待通知情報に基づく招待情報を表示部１２０に表示させる。画面遷移部１６９は、提示部１６８が表示部１２０に表示させた招待情報に対する第３操作に基づいて、当該招待情報が示すアプリケーションをインストール可能な画面に遷移させる。

これにより、ユーザ端末１００は、申請元アプリ１０における招待ユーザの操作に基づいて申請先アプリ２０を特定モードで起動させることにより、申請元アプリ１０への招待候補となるユーザを示す招待候補ユーザリストを取得して表示部１２０に表示することができる。ここで、この招待候補ユーザリストにより示されるユーザは、例えば、申請先アプリ２０において招待ユーザと所定の関係（例えば、友だち関係）にある他のユーザの中から招待候補となるユーザとして抽出されたユーザであって、申請先アプリ２０へ招待可能なユーザの候補である。よって、ユーザ端末１００は、被招待ユーザとして選択可能なユーザのみを表示することができるため、招待ユーザが被招待ユーザを選択する際の利便性を向上させることができる。

また、ユーザ端末１００は、招待ユーザが申請先アプリ２０において所定の関係（例えば、友だち関係）にある被招待ユーザを申請元アプリ１０へ招待申請することができるため、あるアプリケーションで所定の関係（例えば、友だち関係）にあるユーザを、他のアプリケーションに招待することができる。また、被招待ユーザのユーザ端末１００では、招待ユーザから招待申請があった場合には、申請先アプリ２０において申請先アプリ２０への招待情報が表示部１２０に表示されるため、被招待ユーザは、申請先アプリ２０へ招待されたことを容易に認識することができる。また、その表示部１２０に表示された招待情報への操作によって、申請先アプリ２０をインストール可能な画面に遷移されるため、被招待ユーザが、招待された申請先アプリ２０を容易にインストールすることができる。

（２）ユーザ端末１００は、招待成立通知部１７１を備えている。招待成立通知部１７１は、通常モードで動作中の申請元アプリ１０（アプリケーションの一例）において所定の条件が充足された場合に、ユーザ端末１００（自端末装置の一例）の端末記憶部１４０（記憶部の一例）に、申請元アプリ１０（動作中のアプリケーションの一例）に対応した招待通知情報に含まれる少なくとも一部の情報が記憶されていることを条件として、招待通知情報に対応した招待成立情報を管理サーバ２００に対して送信する。

なお、第１実施形態で説明したように、招待情報管理部１７０は、提示部１６８（第２表示制御部の一例、招待情報提示部の一例）が表示部１２０に表示させた招待情報のうちの第３操作がされた招待情報に対応する招待通知情報に関連付けられた少なくとも一部の情報をユーザ端末１００（自端末装置の一例）の端末記憶部１４０（記憶部の一例）に記憶させてもよい。この場合、招待成立通知部１７１は、通常モードで動作中の申請元アプリ１０（第１アプリケーションの一例）において所定の条件が充足された場合に、ユーザ端末１００の端末記憶部１４０に、申請元アプリ１０に対応した招待通知情報に関連付けられた少なくとも一部の情報が記憶されていることを条件として、招待通知情報に対応した招待成立情報を管理サーバ２００に対して送信してもよい。

これにより、ユーザ端末１００は、招待ユーザからの招待申請に基づいて被招待ユーザが申請元アプリ１０をインストールして利用したことによって、当該招待申請により招待が成立したことを管理サーバ２００に通知することができる。さらに、招待通知情報に含まれる少なくとも一部の情報が記憶されていることを条件とすることで、例えば相互招待システム５００を利用せずにユーザ自身でインストール（招待ユーザからの招待申請に基づかないインストール）したものを除外することができる。つまり、招待ユーザからの招待申請により招待が成立したものだけを管理サーバ２００に通知することができる。
ここで、招待成立情報を管理サーバ２００に対して送信するタイミングを、申請元アプリ１０において利用後の所定の条件が充足された場合とすれば、単に申請元アプリ１０がインストールされただけで利用されていない場合を招待成立の条件から除くことができる。

（３）ユーザ端末１００のアプリケーションリスト取得部１６１は、アプリケーションリストとともに、アプリケーションリストに含まれる対応アプリケーションのそれぞれに対応するＵＲＬスキームを取得する。そして、提示部１６８（第１提示部の一例、アプリケーションリスト提示部の一例）は、取得したＵＲＬスキームを用いて、ユーザ端末１００（自端末装置の一例）にインストールされている対応アプリケーションを検出して自ユーザに提示する。

なお、ＵＲＬスキームを利用してユーザ端末１００にインストールされている対応アプリケーションを検出する例を説明したが、これに限られるものではない。例えば、ＯＳがユーザ端末１００にインストール済みの対応アプリケーションを示す情報を取得可能な場合には、このＯＳが取得したインストール済みの対応アプリケーションを示す情報を利用して、ユーザ端末１００にインストールされている他アプリケーションを検出してもよい。

例えば、提示部１６８（第１表示制御部の一例）は、ユーザ端末１００（自端末装置の一例）が具備する機能を用いて、アプリケーションリスト取得部１６１（アプリケーション情報取得部の一例）が取得した、一又は複数の対応アプリケーションを示す情報により示される対応アプリケーションのうちからユーザ端末１００にインストールされている対応アプリケーションを検出し、検出したアプリケーションを示す情報を表示部１２０に表示させてもよい。

これにより、ユーザ端末１００は、管理サーバ２００から取得した対応アプリケーションリストの中から、ユーザ端末１００（自端末装置の一例）にインストールされている対応アプリケーションのみを提示する（表示部１２０に表示させる）ことができる。

（４）本実施形態のユーザ端末１００（端末装置の一例）にインストールされた対応アプリケーションのＳＤＫ１１のユーザリスト取得部１６３は、特定モードで動作中の申請先アプリ２０（アプリケーションの一例）に対応したアプリサーバ３００（サーバ装置の一例）から取得したユーザリストを管理サーバ２００（管理装置の一例）へ通知してもよい。そして、ユーザリスト取得部１６３は、通知したユーザリストから所定の抽出条件に基づいてフィルタリング（抽出の一例）されたユーザのリストを管理サーバ２００から取得して新たなユーザリスト（例えば、招待候補ユーザリスト）とする。

なお、第１実施形態で説明したように、ユーザリストは、ユーザを示す情報の一例であって、その情報の形態はいずれの形態であってもよい。例えば、ユーザリスト取得部１６３（招待候補ユーザ情報取得部）は、特定モードで動作中の申請先アプリ２０（第２アプリケーションの一例）において招待ユーザ（自ユーザの一例）と所定の関係（例えば、友だち関係）にあるユーザを示すユーザリスト（所定関係ユーザ情報の一例）を管理サーバ２００へ通知してもよい。そして、ユーザリスト取得部１６３は、通知したユーザリストから所定の抽出条件に基づいて抽出されたユーザを示す情報を管理サーバ２００から取得して招待候補ユーザリスト（招待候補ユーザ情報の一例）としてもよい。

これにより、ユーザ端末１００は、申請先アプリ２０において招待ユーザと所定の関係（例えば、友だち関係）にあるユーザのうち予め設定されたユーザを除外した招待候補ユーザリストを、被招待ユーザを選択可能なユーザのフレンド一覧として、招待ユーザに提示することができる。よって、招待ユーザは、招待を受け入れたくないユーザが除かれたフレンド一覧の中から被招待ユーザを選択することができる。

（５）管理サーバ２００（管理装置の一例）の制御部２３０は、抽出部２３９と、ユーザリスト通知部２４０と、招待申請受取部２３３と、招待通知部２３６と、招待成立受取部２３７を備えている。抽出部２３９は、申請先アプリ２０（第２アプリケーションの一例）から所定の関係（例えば、友だち関係）にあるユーザのユーザリストを取得した場合に当該ユーザリストに含まれるユーザのうち、申請元アプリ１０（第１アプリケーションの一例）への招待候補となるユーザを所定の抽出条件に基づいてフィルタリング（抽出）する。ユーザリスト通知部２４０は、抽出部２３９が抽出した申請元アプリ１０（第１アプリケーションの一例）への招待候補となるユーザのユーザリストである招待候補ユーザリストを、招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信する。招待申請受取部２３３は、フィルタリング後の招待候補ユーザリストのうちの選択されたユーザである被招待ユーザ（第２ユーザの一例）を申請元アプリ１０へ招待申請する招待申請情報を招待ユーザのユーザ端末１００から受け取る。招待通知部２３６は、被招待ユーザのユーザ端末１００に対して、当該招待申請情報に基づく招待通知情報を送信する。招待成立受取部２３７は、申請先アプリ２０から申請元アプリ１０への招待が成立したことを示す招待成立情報を、被招待ユーザのユーザ端末１００から受け取る。

これにより、管理サーバ２００は、申請先アプリ２０において招待ユーザと所定の関係（例えば、友だち関係）にあるユーザのユーザリストから、予め設定された抽出条件に基づいて抽出したユーザの招待候補ユーザリストを、ユーザ端末１００に通知することができる。よって、あるアプリケーションで友だち関係にあるユーザを他のアプリケーションに招待する際の招待するユーザの利便性を向上させることができる。

なお、管理サーバ２００（管理装置の一例）の制御部２３０は、招待成立受取部２３７を備えていない構成としてもよく、抽出部２３９と、ユーザリスト通知部２４０と、招待申請受取部２３３と、招待通知部２３６と、を少なくとも備えた構成としてもよい。例えば、抽出部２３９は、申請先アプリ２０（第２アプリケーションの一例）から所定の関係（例えば、友だち関係）にあるユーザのユーザリスト（所定の関係にあるユーザを示す所定関係ユーザ情報の一例）を取得した場合に、当該ユーザリストに含まれるユーザのうち、申請元アプリ１０（第１アプリケーションの一例）への招待候補となるユーザを抽出条件に基づいてフィルタリング（抽出）する。ユーザリスト通知部２４０（招待候補ユーザ通知部の一例）は、抽出部２３９が抽出した申請元アプリ１０への招待候補となるユーザを示す招待候補ユーザリスト（招待候補ユーザ情報の一例）を、招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信する。招待申請受取部２３３は、送信した招待候補ユーザリストに示されるユーザのうちの被招待ユーザ（第２ユーザの一例）を申請元アプリ１０へ招待申請する招待申請情報を招待ユーザのユーザ端末１００から受け取る。招待通知部２３６は、被招待ユーザのユーザ端末１００に対して、当該招待申請情報に基づく招待通知情報を送信する。

これにより、管理サーバ２００は、申請先アプリ２０において招待ユーザと所定の関係（例えば、友だち関係）にあるユーザのユーザリストのうちの招待候補となるユーザのみを抽出して招待ユーザのユーザ端末１００に通知することができる。よって、あるアプリケーションで友だち関係にあるユーザを他のアプリケーションに招待する際の招待するユーザの利便性を向上させることができる。

例えば、抽出部２３９は、申請元アプリ１０から起動された申請先アプリ２０から所定の関係にあるユーザのユーザリストを取得した場合に、申請元アプリ１０への招待候補となるユーザを抽出条件に基づいて抽出する。そして、ユーザリスト通知部２４０は招待候補ユーザリストを、招待ユーザのユーザ端末１００の申請先アプリ２０に対して送信する。招待申請受取部２３３は、被招待ユーザを申請元アプリ１０へ招待申請する招待申請情報を招待ユーザのユーザ端末１００の申請先アプリ２０から受け取る。このように、招待申請情報を招待ユーザの申請元アプリ１０から受け取るのではなく、申請元アプリ１０から申請先アプリ２０を介在（起動）させて受け取るようにしたので、申請元アプリ１０と申請先アプリ２０のようにユーザ情報に互換性がないアプリケーション間であっても容易にユーザを招待することができるようになる。

また、管理サーバ２００は、申請先アプリ２０（第２アプリケーションの一例）から申請元アプリ１０（第１アプリケーションの一例）への招待が成立したことを示す招待成立情報を、被招待ユーザ（第２ユーザの一例）のユーザ端末１００から受け取る招待成立受取部２３７を備えた構成としてもよい。
この構成によれば、管理サーバ２００は、招待ユーザからの招待申請による招待が成立した場合、成立したことを認識することができる。例えば、管理サーバ２００は、招待ユーザからの招待申請による招待が成立したことを認識した場合、所定の報酬が申請元アプリ１０における招待ユーザに対して付与されるような処理を行ってもよい。

（６）例えば、抽出部２３９は、上記抽出条件として、招待ユーザ（第１ユーザの一例）からの招待申請を拒否する設定がされたユーザを抽出対象から除く。

これにより、管理サーバ２００は、招待ユーザからの招待申請を拒否する設定がされたユーザを除いた招待候補ユーザリストを招待ユーザのユーザ端末１００に対して送信することができる。

具体的には、例えば、アプリケーション管理部２３１は、ブロックするユーザ（招待申請の禁止を設定する設定側ユーザ）と、ブロックされるユーザ（設定側ユーザに対する招待申請を禁止される被設定側ユーザ）とを組みにした招待申請拒否ユーザ設定情報（第１禁止情報の一例）を、招待申請拒否ユーザ設定記憶部２２７に記憶させて管理する。
そして、抽出部２３９は、抽出条件として、アプリケーション管理部２３１が管理している招待申請拒否ユーザ設定情報のうち、招待ユーザ（第１ユーザの一例）をブロックされるユーザ（被設定側ユーザの一例）に設定している招待申請拒否ユーザ設定情報がある場合には、当該招待申請拒否ユーザ設定情報が示すブロックするユーザ（設定側ユーザの一例）を、招待ユーザからの招待申請を拒否する設定がされたユーザとして抽出対象から除く。

なお、招待ユーザ（第１ユーザの一例）をブロックするユーザ（設定側ユーザの一例）に設定している招待申請拒否ユーザ設定情報がある場合には、当該招待申請拒否ユーザ設定情報が示すブロックされるユーザを、招待ユーザからの招待申請を拒否する設定がされたユーザとして除いてもよい。つまり、ブロックするユーザと、ブロックされるユーザとに対して、一方向に対して招待申請が禁止されるようにしてもよいし、双方向に対して招待申請が禁止されるようにしてもよい。

これにより、相互招待システム５００では、相互招待させたくない対応アプリケーションにおけるユーザの関係を管理サーバ２００に設定することができる。よって、相互招待システム５００は、任意の対応アプリケーションにおいて招待を受け入れたくない招待ユーザから被招待ユーザへの招待申請がされないようにすることができる。

（７）抽出部２３９は、上記抽出条件として、申請元アプリ１０（第１アプリケーションの一例）への招待申請を拒否する設定がされたユーザを抽出対象から除いてもよい。

具体的には、例えば、アプリケーション管理部２３１は、ブロックするユーザ（招待申請の禁止を設定する設定側ユーザ）と、ブロックされる対応アプリケーション（設定側ユーザに対する招待申請を禁止される被設定側アプリケーション）とを組みにした招待申請拒否アプリ設定情報（第２禁止情報の一例）を招待申請拒否アプリ設定記憶部２２８に記憶させて管理する。
そして、抽出部２３９は、抽出条件として、アプリケーション管理部２３１が管理している招待申請拒否アプリ設定情報のうち、申請元アプリ１０（第１アプリケーションの一例）をブロックされるアプリケーション（被設定側アプリケーションの一例）に設定している招待申請拒否アプリ設定情報がある場合には、当該招待申請拒否アプリ設定情報が示すブロックするユーザ（設定側ユーザの一例）を、申請元アプリ１０への招待申請を拒否する設定がされたユーザとして抽出対象から除く。

これにより、管理サーバ２００は、申請元アプリ１０への招待申請を拒否する設定がされたユーザを除いた招待候補ユーザリストを招待ユーザのユーザ端末１００に対して送信することができる。よって、相互招待システム５００は、ユーザが招待を受け入れたくない対応アプリケーションへの招待申請がされないようにすることができる。したがって、相互招待システム５００では、例えば、ユーザが自身のユーザ端末１００に既にインストールされている対応アプリケーション、または一度プレイされた後にアンインストールされた対応アプリケーションへの招待申請を拒否する設定を行えば、当該ユーザに対して当該対応アプリケーションへの招待申請がされないようにブロックすることができる。

＜第４の実施形態＞
次に、本発明の第４の実施形態を説明する。本実施形態の相互招待システム５００の構成は、第３の実施形態の構成と同様であるため、本実施形態において特徴的な処理について説明する。第３の実施形態では、抽出条件記憶部２２５に記憶されている招待申請拒否ユーザ設定情報または招待申請拒否アプリ設定情報に基づいて、ユーザリストをフィルタリングする処理を説明した。本実施形態では、招待申請情報記憶部２２２に記憶されている招待申請記録に基づいて、ユーザリストをフィルタリングする処理を説明する。

例えば、管理サーバ２００の抽出部２３９は、ユーザ端末１００の申請先アプリ２０（ＳＤＫ１１Ｂ）からユーザリストを取得した場合に、当該ユーザリストに含まれるユーザの中から申請元アプリ１０への招待候補となる招待候補ユーザを、招待申請記録に基づいてフィルタリング（抽出）する。

本実施形態によるフィルタリング処理において優先されるべき第１の目的は、申請元アプリ１０をインストールしていて、既に利用している招待候補ユーザを招待候補ユーザリストから除外することである。また、第２の目的は、招待申請中の招待候補ユーザを招待候補ユーザリストから除外することである。さらに、第３の目的は、招待が失敗または拒否された招待候補ユーザを招待候補ユーザリストから除外することである。

以下に、図１７から図２１を参照して、招待申請記録に基づいてフィルタリングする処理の例を説明する。ここでは、フィルタリング処理の例として第１例から第５例を説明する。なお、第１例及び第２例が上記第１の目的に関するフィルタリング処理の例であり、第３例が上記第２の目的に関するフィルタリング処理の例であり、第４例及び第５例が上記第３の目的に関するフィルタリング処理の例である。
ここで、図１７から図２１は、招待申請情報記憶部２２２に記憶されている招待申請記録に含まれる情報の一部を示している。また、各図において、招待申請記録に含まれる情報のうちの「＝」が記載されている情報は、抽出部２３９がフィルタリングする際の抽出条件として、過去に招待申請された招待申請記録に設定されているＩＤと同一となることを示している。

（１）図１７は、招待申請記録に基づいてフィルタリングする処理の第１例を説明する図である。この第１例に示す処理は、申請元アプリ１０（ゲームＡ）を既に利用(プレイ)している招待候補ユーザに対して招待申請（再招待）がされないように、申請元アプリ１０（ゲームＡ）への招待申請を行ったことがある招待候補ユーザを、招待候補ユーザリストから除くフィルタリング処理である。この招待申請は、同一の申請元アプリ１０、及び同一の申請先アプリ２０であって、招待候補ユーザが招待ユーザとなっている招待申請であることをいう。

管理サーバ２００の抽出部２３９は、招待申請情報記憶部２２２に記憶されている招待申請記録に対して、申請元アプリＩＤ（ApIDfrom）と、申請先アプリＩＤ（ApIDto）とがそれぞれ一致し、且つ申請先アプリの招待ユーザＩＤ（Apto_UIDfrom）に招待候補ユーザのユーザＩＤが一致する条件の招待申請（再招待）がされないように、この条件を満たす招待候補ユーザを、招待候補ユーザリストから除外する。即ち、申請先アプリの招待ユーザＩＤ（Apto_UIDfrom）に設定されているユーザＩＤが申請先アプリの被招待ユーザＩＤ（Apto_UIDto）となる招待申請がされないように、当該、申請先アプリの招待ユーザＩＤ（Apto_UIDfrom）に設定されているユーザＩＤが示す招待候補ユーザを招待候補ユーザリストから除外する。

（２）図１８は、招待申請フィルタリング処理の第２例を説明する図である。この第２例に示す処理は、申請元アプリ１０（ゲームＡ）を既に利用(プレイ)している招待候補ユーザに対して招待申請（再招待）がされないように、申請元アプリ１０（ゲームＡ）への招待が成立済みである招待候補ユーザを、招待候補ユーザリストから除くフィルタリング処理である。

図１８に示す招待申請情報は、招待申請の状態（StatusInvite）に、フラグ「２」、及び「３」のうちのいずれかが設定されており、この招待申請は招待成立済みであることを示している。管理サーバ２００の抽出部２３９は、招待申請情報記憶部２２２に記憶されている招待申請記録に対して、申請元アプリＩＤ（ApIDfrom）と、申請先アプリＩＤ（ApIDto）と、申請先アプリの被招待ユーザＩＤ（Apto_UIDto）とがそれぞれ一致する条件の招待申請がされないように、この条件を満たす招待候補ユーザを、招待候補ユーザリストから除外する。

なお、この第２例に示す処理は、第１例に示す処理に加えて適用してもよく、その場合、申請元アプリ１０（ゲームＡ）を既に利用(プレイ)している招待候補ユーザを招待候補ユーザリストから除くフィルタリング処理となる。

（３）図１９は、招待申請フィルタリング処理の第３例を説明する図である。この第３例に示す処理は、例えば、申請先アプリ２０（ゲームＢ）から申請元アプリ１０（ゲームＡ）への招待申請が招待申請中（招待中）の招待候補ユーザを招待候補ユーザリストから除くフィルタリング処理である。

図１９に示す招待申請情報は、招待申請の状態（StatusInvite）に、フラグ「０」、及び「１」のうちのいずれかが設定されており、この招待申請は招待申請中（招待申請未通知または招待申請通知済）であることを示している。管理サーバ２００の抽出部２３９は、招待申請情報記憶部２２２に記憶されている招待申請記録に対して、申請元アプリＩＤ（ApIDfrom）と、申請先アプリＩＤ（ApIDto）と、申請先アプリの被招待ユーザＩＤ（Apto_UIDto）とがそれぞれ一致する条件の招待申請がされないように、この条件を満たす招待候補ユーザを、招待候補ユーザリストから除外する。

なお、この第３例に示す処理は、第１例または第２例に示す処理に加えて適用してもよく、その場合、申請元アプリ１０（ゲームＡ）を既に利用(プレイ)している招待候補ユーザまたは招待申請中の招待候補ユーザを招待候補ユーザリストから除くフィルタリング処理となる。

（４）図２０は、招待申請フィルタリング処理の第４例を説明する図である。この第４例に示す処理は、例えば、申請先アプリ２０（ゲームＢ）から申請元アプリ１０（ゲームＡ）への招待申請が失敗または拒否されている招待候補ユーザを招待候補ユーザリストから除くフィルタリング処理である。

なお、この第４例に示す処理は、アプリケーション設定記憶部２２１に記憶されているアプリケーション情報の再招待許可フラグ（FlagResultInvite）がフラグ「０」（再招待不可）に設定されている対応アプリケーションが申請元アプリ１０または申請先アプリ２０となる場合に適用される。

図２０に示す招待申請情報は、招待申請の状態（StatusInvite）に、フラグ「−１」が設定されており、この招待申請は失敗または拒否されていることを示している。管理サーバ２００の抽出部２３９は、招待申請情報記憶部２２２に記憶されている招待申請記録に対して、申請元アプリＩＤ（ApIDfrom）と、申請先アプリＩＤ（ApIDto）と、申請先アプリの被招待ユーザＩＤ（Apto_UIDto）とがそれぞれ一致する条件の招待申請がされないように、この条件を満たす招待候補ユーザを、招待候補ユーザリストから除外する。

なお、再招待許可フラグ（FlagResultInvite）がフラグ「１」（再招待可）に設定されている対応アプリケーションが申請元アプリ１０及び申請先アプリ２０となる場合には、上記条件を満たす被招待ユーザを、招待候補ユーザリストから除外しない。

なお、この第４例に示す処理は、第１例から第３例に示す処理に加えて適用してもよく、その場合、申請元アプリ１０（ゲームＡ）を既に利用(プレイ)している招待候補ユーザ、招待申請中の招待候補ユーザ、または失敗若しくは拒否されている招待候補ユーザを、招待候補ユーザリストから除くフィルタリング処理となる。

（５）図２１は、招待申請フィルタリング処理の第５例を説明する図である。この第５例に示す処理は、第４例に示す処理において、さらに招待ユーザが同一の場合に申請先アプリ２０（ゲームＢ）から申請元アプリ１０（ゲームＡ）への招待申請が失敗している招待候補ユーザをから除くフィルタリング処理である。即ち、第４例に示す処理において、申請先アプリ２０（ゲームＢ）から申請元アプリ１０（ゲームＡ）への招待申請が失敗している被招待ユーザであっても、招待ユーザが異なれば、当該招待候補ユーザを招待候補ユーザリストから除外しなくてもよい。

図２１に示す招待申請情報は、招待申請の状態（StatusInvite）に、フラグ「−１」が設定されており、この招待申請は失敗していることを示している。管理サーバ２００の抽出部２３９は、招待申請情報記憶部２２２に記憶されている招待申請記録に対して、申請元アプリＩＤ（ApIDfrom）と、申請先アプリＩＤ（ApIDto）と、申請先アプリの招待ユーザＩＤ（Apto_UIDfrom）と、申請先アプリの被招待ユーザＩＤ（Apto_UIDto）とがそれぞれ一致する条件の招待申請がされないように、この条件を満たす招待候補ユーザを、招待候補ユーザリストから除外する。

〔まとめ〕
以上説明したように、本実施形態では、第３の実施形態と同様に、所定の抽出条件に基づいてフィルタリング（抽出）されたユーザのリストを新たなユーザリスト（招待候補ユーザリストの一例）とする。ここで、本実施形態では、招待申請記録に基づく抽出条件でフィルタリングが行われる。

（１）本実施形態の管理サーバ２００（管理装置の一例）の制御部２３０は、抽出部２３９と、ユーザリスト通知部２４０と、招待申請受取部２３３と、招待通知部２３６と、招待成立受取部２３７を備えている。抽出部２３９は、申請先アプリ２０（第２アプリケーションの一例）から所定の関係（例えば、友だち関係）にあるユーザのユーザリストを取得した場合に当該ユーザリストに含まれるユーザのうち、申請元アプリ１０（第１アプリケーションの一例）への招待候補となるユーザを所定の抽出条件に基づいてフィルタリング（抽出）する。ユーザリスト通知部２４０は、抽出部２３９が抽出した申請元アプリ１０への招待候補となるユーザのユーザリストである招待候補ユーザリストを、招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信する。招待申請受取部２３３は、フィルタリング後の招待候補ユーザリストのうちの選択されたユーザである被招待ユーザ（第２ユーザの一例）を申請元アプリ１０へ招待申請する招待申請情報を招待ユーザのユーザ端末１００から受け取る。招待通知部２３６は、被招待ユーザのユーザ端末１００に対して、当該招待申請情報に基づく招待通知情報を送信する。招待成立受取部２３７は、申請先アプリ２０から申請元アプリ１０への招待が成立したことを示す招待成立情報を、被招待ユーザのユーザ端末１００から受け取る。

これにより、管理サーバ２００は、申請先アプリ２０において招待ユーザと所定の関係（例えば、友だち関係）にあるユーザのユーザリストから、予め設定された抽出条件に基づいて抽出したユーザの招待候補ユーザリストを、ユーザ端末１００に通知することができる。よって、あるアプリケーションで友だち関係にあるユーザを他のアプリケーションに招待する際の招待するユーザの利便性を向上させることができる。

なお、管理サーバ２００（管理装置の一例）の制御部２３０は、招待成立受取部２３７を備えていない構成としてもよく、抽出部２３９と、ユーザリスト通知部２４０と、招待申請受取部２３３と、招待通知部２３６と、を少なくとも備えた構成としてもよい。例えば、抽出部２３９は、申請先アプリ２０（第２アプリケーションの一例）から所定の関係（例えば、友だち関係）にあるユーザのユーザリスト（所定の関係にあるユーザを示す所定関係ユーザ情報の一例）を取得した場合に、当該ユーザリストに含まれるユーザのうち、申請元アプリ１０（第１アプリケーションの一例）への招待候補となるユーザを抽出条件に基づいてフィルタリング（抽出）する。ユーザリスト通知部２４０（招待候補ユーザ通知部の一例）は、抽出部２３９が抽出した申請元アプリ１０への招待候補となるユーザを示す招待候補ユーザリスト（招待候補ユーザ情報の一例）を、招待ユーザ（第１ユーザの一例）のユーザ端末１００に対して送信する。招待申請受取部２３３は、送信した招待候補ユーザリストに示されるユーザのうちの被招待ユーザ（第２ユーザの一例）を申請元アプリ１０へ招待申請する招待申請情報を招待ユーザのユーザ端末１００から受け取る。招待通知部２３６は、被招待ユーザのユーザ端末１００に対して、当該招待申請情報に基づく招待通知情報を送信する。

これにより、管理サーバ２００は、申請先アプリ２０において招待ユーザと所定の関係（例えば、友だち関係）にあるユーザのユーザリストのうちの招待候補となるユーザのみを抽出して招待ユーザのユーザ端末１００に通知することができる。よって、あるアプリケーションで友だち関係にあるユーザを他のアプリケーションに招待する際の招待するユーザの利便性を向上させることができる。

（２）例えば、管理サーバ２００の抽出部２３９は、上記抽出条件として、申請先アプリ２０（第２アプリケーションの一例）から申請元アプリ１０（第１アプリケーションの一例）への招待申請をしたことがあるユーザを抽出対象から除く（第１抽出条件）。ここで、申請先アプリ２０から申請元アプリ１０への招待申請をしたことがあるユーザとは、既に申請元アプリ１０を利用しているユーザを示す。

これにより、管理サーバ２００は、既に申請元アプリ１０を利用しているユーザが招待候補ユーザリストに掲載されることを抑制することができる。つまり、管理サーバ２００は、当該招待候補ユーザリストを招待ユーザのユーザ端末１００に対して送信することができ、招待するユーザの利便性を向上させることができる。

（３）抽出部２３９は、上記抽出条件として、申請先アプリ２０（第２アプリケーションの一例）から申請元アプリ１０（第１アプリケーションの一例）への招待申請が成立している当該招待申請がされたことがあるユーザを抽出対象から除いてもよい（第２抽出条件）。ここで、申請先アプリ２０から申請元アプリ１０への招待申請が成の一例立している当該招待申請がされたことがあるユーザとは、既に申請元アプリ１０を利用しているユーザを示す。

これにより、管理サーバ２００は、既に申請元アプリ１０を利用しているユーザが招待候補ユーザリストに掲載されることを抑制することができる。つまり、管理サーバ２００は、当該招待候補ユーザリストを招待ユーザのユーザ端末１００に対して送信することができ、招待するユーザの利便性を向上させることができる。
さらに上記の第１抽出条件と、この第２抽出条件を組み合わせることで、既に申請元アプリ１０を利用しているユーザを招待候補ユーザリストに掲載されることをさらに抑制することができる。

（４）抽出部２３９は、上記抽出条件として、申請先アプリ２０（第２アプリケーションの一例）から申請元アプリ１０（第１アプリケーションの一例）への招待申請がされたことがあるユーザであって、当該招待申請が成立されていない招待申請中のユーザを抽出対象から除いてもよい（第３抽出条件）。

これにより、管理サーバ２００は、他のユーザから招待申請がされているユーザが招待候補ユーザリストに掲載されないようになるので、招待申請が失敗する可能性があるユーザが招待候補ユーザリストに掲載されることを抑制することができる。つまり、管理サーバ２００は、当該招待候補ユーザリストを招待ユーザのユーザ端末１００に対して送信することができ、招待するユーザの利便性を向上させることができる。
さらに、上記の第１抽出条件または第２抽出条件と、この第３抽出条件を組み合わせることで、当該招待申請が成立しやすいユーザが招待候補ユーザリストに掲載されるようになる。

（５）抽出部２３９は、上記抽出条件として、申請先アプリ２０（第２アプリケーションの一例）から申請元アプリ１０（第１アプリケーションの一例）への招待申請を却下したことがあるユーザを抽出対象から除いてもよい（第４抽出条件の一例）。ここで、申請先アプリ２０から申請元アプリ１０への招待申請を却下したことがあるユーザとは、被招待ユーザによって招待申請を拒否したユーザや、招待申請中の状態が予め定められた時間以上経過するまで招待申請を放置したユーザを示す。

このような申請先アプリ２０から申請元アプリ１０への招待申請を却下したユーザは、再度、申請元アプリ１０への招待申請をしても招待申請が失敗する可能性がある。これにより、管理サーバ２００は、招待申請が失敗する可能性のあるユーザが招待候補ユーザリストに掲載されることを抑制することができる。つまり、管理サーバ２００は、当該招待候補ユーザリストを招待ユーザのユーザ端末１００に対して送信することができ、招待するユーザの利便性を向上させることができる。
さらに、上記の第１抽出条件もしくは第２抽出条件、または上記の第３抽出条件に、この第４抽出条件を組み合わせることで、当該招待申請が成立しやすいユーザが招待候補ユーザリストに掲載されるようになる。

（６）管理サーバ２００のアプリケーション管理部２３１は、複数の対応アプリケーションに関する情報に申請元アプリ１０（第１アプリケーションの一例）へのユーザの再招待を許可するか否かを示す情報を含んで管理する。管理サーバ２００の抽出部２３９は、上記抽出条件として、アプリケーション管理部２３１を参照して申請元アプリ１０（第１アプリケーションの一例）へのユーザの再招待が許可されている場合、申請元アプリ１０への招待申請を却下したことがあるユーザを抽出対象に含める。

これにより、管理サーバ２００は、再招待が許可されている申請元アプリ１０（第１アプリケーション）への招待申請の場合には、再招待を許可することができる。

（７）抽出部２３９は、上記抽出条件において、申請先アプリ２０（第２アプリケーションの一例）からの申請元アプリ１０（第１アプリケーションの一例）への該招待申請を却下したユーザであっても、当該招待申請と異なる招待ユーザ（第１ユーザの一例）からの招待申請である場合には当該ユーザを抽出対象に含めてもよい。

これにより、管理サーバ２００は、過去に同じ対応アプリケーションからの招待申請を却下した被招待ユーザであっても、招待ユーザが異なる場合には再招待を許可することができる。

＜変形例＞
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成は上述の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。例えば、上述の第１、２、３の実施形態において説明した各機能は、任意に組み合わせることができる。

（１）上記実施形態では、管理サーバ２００の通信部２１０（送受信部の一例）は、アプリケーションリスト（アプリケーション管理部２３１が管理する情報の少なくとも一部の一例）、招待申請情報、招待通知情報、および招待成立情報を、直接的に招待ユーザのユーザ端末１００又は被招待ユーザのユーザ端末１００と通信する例を説明した。同様にユーザ端末１００の端末通信部１３０（送受信部の一例）は、アプリケーションリスト、ユーザリスト（招待候補ユーザ情報の一例）、招待申請情報、招待通知情報、および招待成立情報を直接的に管理サーバ２００と通信する例を説明した。

ここで、管理サーバ２００の通信部２１０は、申請元アプリ１０（第１アプリケーションの一例）又は申請先アプリ２０（第２アプリケーションの一例）に対応するアプリサーバ３００（サーバ装置の一例）を介して通信セッションを確立させた後で、直接的に招待ユーザのユーザ端末１００又は被招待ユーザのユーザ端末１００と通信してもよい。同様にユーザ端末１００の端末通信部１３０は、申請元アプリ１０又は申請先アプリ２０（動作中のアプリケーションの一例）に対応するアプリサーバ３００を介して通信セッションを確立させた後で、直接的に管理サーバ２００と通信してもよい。

なお、ユーザ端末１００から直接的に管理サーバ２００と通信する場合に、必要に応じて通信セッションを確立させるようにしてもよい。つまり、通信セッションを確立させる前に直接的に管理サーバ２００と通信する場合と、通信セッションを確立させた後に直接的に管理サーバ２００と通信する場合との両方を含んでもよい。

図２２は、通信セッションの確立処理の動作を説明するフローチャートである。この通信セッションの確立処理（通信セッション確立処理）は、申請元アプリ１０または申請先アプリ２０がユーザ端末１００で起動された後に、管理サーバ２００と通信を行う前に必要に応じて行われる処理である。図２２では、ユーザ端末１００にインストールされている申請元アプリ１０のＳＤＫ１１Ａから直接的に管理サーバ２００と通信する場合に行われる通信セッションの確立処理を示している。なお、この通信セッションの確立処理は、申請先アプリ２０のＳＤＫ１１Ｂから直接的に管理サーバ２００と通信する場合も同様に行うことができる。なお、ユーザ端末１００とアプリサーバ３１０とは既に通信セッションが確立されている前提となる。

まず、ユーザ端末１００のＳＤＫ１１Ａは、ワンタイムトークンの取得を要求するワンタイムトークン取得要求情報をアプリサーバ３１０に対して送信する（ステップＳＡ１０）。アプリサーバ３１０は、ユーザ端末１００（ＳＤＫ１１Ａ）からワンタイムトークン取得要求情報を取得すると、取得したワンタイムトークン取得要求情報に基づくワンタイムトークン生成要求情報を管理サーバ２００に対して送信する（ステップＳＣ１０）。管理サーバ２００は、アプリサーバ３１０からワンタイムトークン生成要求情報を取得すると、ワンタイムトークンを生成し、生成したワンタイムトークンをアプリサーバ３１０に対して送信する（ステップＳＥ１０）。アプリサーバ３１０は、管理サーバ２００からワンタイムトークンを取得すると、取得したワンタイムトークンをユーザ端末１００（ＳＤＫ１１Ａ）に対して送信する（ステップＳＣ２０）。ユーザ端末１００のＳＤＫ１１Ａは、アプリサーバ３１０からワンタイムトークンを取得すると、取得したワンタイムトークンを含んだセッション確立要求情報を管理サーバ２００に対して送信する（ステップＳＡ２０）。管理サーバ２００は、ユーザ端末１００（ＳＤＫ１１Ａ）からセッション確立要求情報を取得すると、取得したセッション確立要求情報に含まれるワンタイムトークンが正しい情報である場合（ユーザ端末１００（ＳＤＫ１１Ａ）に対して送信したワンタイムトークンと一致する場合）には、通信セッションを確立して、相互招待システム５００による通信が許可される（ステップＳＥ２０）。以後、例えば、図９、図１０、及び図１３を参照して説明した相互招待システム５００による招待処理が行われる。なお、管理サーバ２００は、ユーザ端末１００（ＳＤＫ１１Ａ）から取得したセッション確立要求情報に含まれるワンタイムトークンが正しい情報でない場合には通信エラーとし、相互招待システム５００による通信が許可されない。また、管理サーバ２００がユーザ端末１００（ＳＤＫ１１Ａ）からセッション確立要求情報を取得できない場合には、当然、相互招待システム５００による通信が許可されない。
このように、通信セッションを確立させた後で、相互招待システム５００による通信を開始することで、相互招待システム５００を含むネットワークシステム１内のセキュリティを向上させることができる。

なお、アプリケーションリスト、招待申請情報、招待通知情報、および招待成立情報の一部は、ユーザ端末１００から直接的に管理サーバ２００と通信せずに、申請元アプリ１０（第１アプリケーションの一例）又は申請先アプリ２０（第２アプリケーションの一例）に対応するアプリサーバ３００（サーバ装置の一例）を介してユーザ端末１００と通信してもよい。すなわち、管理サーバ２００の通信部２１０（送受信部の一例）は、アプリケーションリスト、招待申請情報、招待通知情報、又は招待成立情報を申請元アプリ１０又は申請先アプリ２０に対応するアプリサーバ３００を介して招待ユーザのユーザ端末１００又は被招待ユーザのユーザ端末１００と通信、若しくは直接的に招待ユーザのユーザ端末１００又は被招待ユーザのユーザ端末１００と通信するようにしてもよい。同様に、ユーザ端末１００の端末通信部１３０（送受信部の一例）は、アプリケーションリスト、ユーザリスト、招待申請情報、招待通知情報、又は招待成立情報を申請元アプリ１０又は申請先アプリ２０（動作中のアプリケーションの一例）に対応するアプリサーバ３００を介して管理サーバ２００と通信、若しくは直接的に管理サーバ２００と通信してもよい。

さらに、管理サーバ２００の通信部２１０（送受信部の一例）は、アプリケーションリスト、招待申請情報、招待通知情報、および招待成立情報を申請元アプリ１０（第１アプリケーションの一例）又は申請先アプリ２０（第２アプリケーションの一例）に対応するアプリサーバ３００（サーバ装置の一例）を介して招待ユーザのユーザ端末１００又は被招待ユーザのユーザ端末１００と通信してもよい。同様に、ユーザ端末１００の端末通信部１３０（送受信部の一例）は、アプリケーションリスト、ユーザリスト、招待申請情報、招待通知情報、および招待成立情報を申請元アプリ１０又は申請先アプリ２０（動作中のアプリケーションの一例）に対応するアプリサーバ３００を介して管理サーバ２００と通信してもよい。
このように、相互招待システム５００は、アプリサーバ３００を介してユーザ端末１００と管理サーバ２００とが通信しても、上記実施形態と同様の招待処理を行うことができ、同様の効果を得ることができる。

（２）上記第３の実施形態および第４の実施形態では、ユーザ端末１００−１の申請先アプリ２０（ゲームＢ）が、アプリサーバ３２０（ゲームＢ）からユーザリストを取得し、取得したユーザリストに含まれるユーザのユーザＩＤを含むフィルタリング要求情報を管理サーバ２００に通知する例を説明したが、これに限られるものではない。

例えば、ユーザ端末１００−１の申請先アプリ２０（ゲームＢ）は、アプリサーバ３２０（ゲームＢ）からユーザリストを取得せずにフィルタリング要求情報を管理サーバ２００に通知する。そして、管理サーバ２００は、ユーザ端末１００−１（ＳＤＫ１１Ｂ）からフィルタリング要求情報を受け取ると、アプリサーバ３２０（ゲームＢ）に対して、ユーザＸと所定の関係（例えば、友だち関係）にあるユーザのユーザリストを要求するフレンド一覧要求情報をアプリサーバ３２０（ゲームＢ）に送信する。

次に、アプリサーバ３２０（ゲームＢ）は、管理サーバ２００からフレンド一覧要求情報を取得すると、ユーザＸと所定の関係（例えば、友だち関係）にあるユーザのユーザリストを、管理サーバ２００に対して送信する。そして、管理サーバ２００は、アプリサーバ３２０（ゲームＢ）からユーザリストを取得すると、所定の抽出条件に従ってフィルタリング処理を行い、フィルタリング結果としてフィルタリング後の招待候補ユーザリストをユーザ端末１００−１（ＳＤＫ１１Ｂ）に対して送信する。

このように、管理サーバ２００が、アプリサーバ３２０（ゲームＢ）からユーザリストを取得する場合に、アプリサーバ３２０（ゲームＢ）から直接的又はユーザ端末１００−１（ＳＤＫ１１Ｂ）を介して間接的に取得してよい。

（３）上記実施形態では、相互招待システム５００に対応する対応アプリケーションとしてゲームを例に説明したが、この対応アプリケーションはゲームに限られるものではなく、ゲーム以外のいずれのアプリケーションであってもよい。

また、上記実施形態では、申請先アプリ２０において招待ユーザと所定の関係にあるユーザを、招待ユーザと友だち関係にあるユーザとして説明したが、この所定の関係は友だち関係に限られるものではない。例えば、この所定の関係は、申請先アプリ２０において同じグループに属する関係、会社関係、親族関係等としてもよいし、単に申請先アプリ２０に登録されているユーザの関係としてもよい。

また、管理サーバ２００の記憶部２２０は、管理サーバ２００とは異なるサーバ装置に備えられてもよい。そして、管理サーバ２００の制御部２３０が管理サーバ２００とは異なるサーバ装置に備えられた記憶部２２０に対してネットワークＮＷを介して通信することにより、記憶部２２０が備える各部が記憶する各情報を管理してもよい。

また、管理サーバ２００とアプリサーバ３００とが一体となったサーバ装置として構成されてもよい。

また、上記実施形態では、相互招待システム５００に対応する対応アプリケーションがネイティブ型のアプリケーションである例を説明したが、これに限られるものではない。例えば、相互招待システム５００に対応する対応アプリケーションは、当該対応アプリケーションに関する処理の実行主体がユーザ端末１００ではなくアプリサーバ３００となるような、所謂、ブラウザ型（Ｗｅｂ型）のアプリケーションであってもよい。

なお、上述の制御部２３０またはＳＤＫ１１の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより上述の各部の処理を行ってもよい。ここで、「記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行する」とは、コンピュータシステムにプログラムをインストールすることを含む。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。このように、プログラムを記憶した記録媒体は、ＣＤ−ＲＯＭ等の非一過性の記録媒体であってもよい。また、記録媒体には、当該プログラムを配信するために配信サーバからアクセス可能な内部または外部に設けられた記録媒体も含まれる。配信サーバの記録媒体に記憶されるプログラムのコードは、端末装置で実行可能な形式のプログラムのコードと異なるものでもよい。すなわち、配信サーバからダウンロードされて端末装置で実行可能な形でインストールができるものであれば、配信サーバで記憶される形式は問わない。なお、プログラムを複数に分割し、それぞれ異なるタイミングでダウンロードした後に端末装置で合体される構成や、分割されたプログラムのそれぞれを配信する配信サーバが異なっていてもよい。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

また、上述した機能の一部または全部を、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

１ ネットワークシステム、１０ 申請元アプリ、１１、１１Ａ、１１Ｂ ＳＤＫ、２０ 申請先アプリ、１００ ユーザ端末（端末装置）、１１０ 入力部、１２０ 表示部、１３０ 端末通信部、１４０ 端末記憶部（記憶部）、１５０ 端末制御部、１６１ アプリケーションリスト取得部、１６２ 特定モード起動部（起動部）、１６３ ユーザリスト取得部、１６４ 招待申請通知部、１６５ 特定モード終了部、１６６ 照会部、１６７ 招待通知取得部、１６８ 提示部、１６９ 画面遷移部、１７０ 招待情報管理部、１７１ 招待成立通知部、２００ 管理サーバ（管理装置）、２１０ 通信部、２２０ 記憶部、２２１ アプリケーション設定記憶部、２２２ 招待申請情報記憶部、２２５ 抽出条件記憶部、２２６ 相互招待拒否設定記憶部、２２７ 招待申請拒否ユーザ設定記憶部、２２８ 招待申請拒否アプリ設定記憶部２２０ 制御部、２３１ アプリケーション管理部２３１ アプリケーションリスト通知部、２３３ 招待申請受取部、２３４ 招待申請管理部、２３５ 申請照会部、２３６ 招待通知部、２３７ 招待成立受取部、２３８ 招待成立処理部、２３９ 抽出部、２４０ ユーザリスト通知部、３００ アプリサーバ、３１０ アプリサーバ（ゲームＡ）、３２０ アプリサーバ（ゲームＢ）、４００ アプリストア、５００ 相互招待システム

Claims (14)

1. 第１ゲームおよび第２ゲームが実行されたことがある第１ユーザの端末装置から、当該第２ゲームで当該第１ユーザと所定の関係にあるユーザの端末装置に対して、当該第１ゲームを導入させるための招待処理を制御する制御部を備え、
   前記制御部は、
   前記第２ゲームから前記所定の関係にあるユーザを示す所定関係ユーザ情報を取得した場合に当該所定関係ユーザ情報に含まれるユーザのうち、前記第１ゲームへの招待候補となるユーザを抽出条件に基づいて抽出する抽出部と、
   前記抽出部が抽出した前記第１ゲームへの招待候補となるユーザを示す招待候補ユーザ情報を、前記第１ユーザの端末装置に対して送信する招待候補ユーザ通知部と、
   前記招待候補ユーザ情報に示されるユーザのうちの第２ユーザを前記第１ゲームへ招待申請する招待申請情報を前記第１ユーザの端末装置から受け取る招待申請受取部と、
   前記第２ユーザの端末装置に対して、前記招待申請情報に基づく招待通知情報を送信する招待通知部と、
   を備えることを特徴とする管理装置。
2. 前記抽出部は、
   前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請をしたことがあるユーザを抽出対象から除く
   ことを特徴とする請求項１に記載の管理装置。
3. 前記抽出部は、
   前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請が成立している当該招待申請がされたことがあるユーザを抽出対象から除く
   ことを特徴とする請求項１または２に記載の管理装置。
4. 前記抽出部は、
   前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請がされたことのあるユーザであって、当該招待申請が成立されていない招待申請中のユーザを抽出対象から除く
   ことを特徴とする請求項１から３のいずれか一項に記載の管理装置。
5. 前記抽出部は、
   前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請を却下したことがあるユーザを抽出対象から除く
   ことを特徴とする請求項１から４の何れか一項に記載の管理装置。
6. 前記第１ゲームおよび前記第２ゲームを含む複数のゲームのそれぞれに関する情報を管理するアプリケーション管理部、
   を備え、
   前記アプリケーション管理部は、当該情報に前記第１ゲームへのユーザの再招待を許可するか否かを示す情報を含んで管理し、
   前記抽出部は、前記抽出条件として、前記アプリケーション管理部を参照して、前記第１ゲームへのユーザの再招待が許可されている場合、前記第１ゲームへの招待申請を却下したことがあるユーザを抽出対象に含める
   ことを特徴とする請求項５に記載の管理装置。
7. 前記抽出部は、
   前記抽出条件として、前記第２ゲームから前記第１ゲームへの招待申請を却下したユーザであっても、当該招待申請と異なる第１ユーザからの招待申請である場合には当該ユーザを抽出対象に含める
   ことを特徴とする請求項５に記載の管理装置。
8. 前記抽出部は、
   前記抽出条件として、前記第１ユーザからの招待申請を拒否する設定がされたユーザを抽出対象から除く
   ことを特徴とする請求項１から７の何れか一項に記載の管理装置。
9. 前記第１ゲームおよび前記第２ゲームを含む複数のゲームのそれぞれに関する情報を管理するアプリケーション管理部、
   を備え、
   前記アプリケーション管理部は、
   招待申請の禁止を設定する設定側ユーザと、当該設定側ユーザに対する招待申請が禁止される被設定側ユーザとを組みにした第１禁止情報を管理し、
   前記抽出部は、
   前記抽出条件として、前記アプリケーション管理部が管理している前記第１禁止情報のうち、前記第１ユーザを前記被設定側ユーザに設定している第１禁止情報がある場合には、当該第１禁止情報が示す設定側ユーザを、前記第１ユーザからの招待申請を拒否する設定がされたユーザとして抽出対象から除く
   ことを特徴とする請求項８に記載の管理装置。
10. 前記抽出部は、
    前記抽出条件として、前記第１ゲームへの招待申請を拒否する設定がされたユーザを抽出対象から除く
    ことを特徴とする請求項１から９の何れか一項に記載の管理装置。
11. 前記第１ゲームおよび前記第２ゲームを含む複数のゲームのそれぞれに関する情報を管理するアプリケーション管理部、
    を備え、
    前記アプリケーション管理部は、
    招待申請の禁止を設定する設定側ユーザと、当該設定側ユーザに対する招待申請が禁止される被設定側ゲームとを組みにした第２禁止情報を管理し、
    前記抽出部は、
    前記抽出条件として、前記アプリケーション管理部が管理している前記第２禁止情報のうち、前記第１ゲームを前記被設定側ゲームに設定している第２禁止情報がある場合には、当該第２禁止情報が示す設定側ユーザを、前記第１ゲームへの招待申請を拒否する設定がされたユーザとして抽出対象から除く
    ことを特徴とする請求項１０に記載の管理装置。
12. 前記招待通知情報に対応する前記第２ゲームから前記第１ゲームへの招待が成立したことを示す招待成立情報を、前記第２ユーザの端末装置又は前記第１ゲームに対応するサーバ装置から受け取る招待成立受取部、
    を備えることを特徴とする請求項１から１１の何れか一項に記載の管理装置。
13. 管理装置の管理方法であって、
    第１ゲームおよび第２ゲームが実行されたことがある第１ユーザの端末装置から、当該第２ゲームで当該第１ユーザと所定の関係にあるユーザの端末装置に対して、当該第１ゲームを導入させるための招待処理を制御する制御ステップを有し、
    前記制御ステップは、
    前記第２ゲームから前記所定の関係にあるユーザを示す所定関係ユーザ情報を取得した場合に当該所定関係ユーザ情報に含まれるユーザのうち、前記第１ゲームへの招待候補となるユーザを抽出条件に基づいて抽出するステップと、
    前記抽出した前記第１ゲームへの招待候補となるユーザを示す招待候補ユーザ情報を、前記第１ユーザの端末装置に対して送信するステップと、
    前記招待候補ユーザ情報に示されるユーザのうちの第２ユーザを前記第１ゲームへ招待申請する招待申請情報を前記第１ユーザの端末装置から受け取るステップと、
    前記第２ユーザの端末装置に対して、前記招待申請情報に基づく招待通知情報を送信するステップと、
    を含むことを特徴とする管理方法。
14. 第１ゲームおよび第２ゲームが実行されたことがある第１ユーザの端末装置から、当該第２ゲームで当該第１ユーザと所定の関係にあるユーザの端末装置に対して、当該第１ゲームを導入させるための招待処理を制御するコンピュータに、
    前記第２ゲームから前記所定の関係にあるユーザを示す所定関係ユーザ情報を取得した場合に当該所定関係ユーザ情報に含まれるユーザのうち、前記第１ゲームへの招待候補となるユーザを抽出条件に基づいて抽出するステップと、
    前記抽出した前記第１ゲームへの招待候補となるユーザを示す招待候補ユーザ情報を、前記第１ユーザの端末装置に対して送信するステップと、
    前記招待候補ユーザ情報に示されるユーザのうちの第２ユーザを前記第１ゲームへ招待申請する招待申請情報を前記第１ユーザの端末装置から受け取るステップと、
    前記第２ユーザの端末装置に対して、前記招待申請情報に基づく招待通知情報を送信するステップと、
    を実行させるためのプログラム。