终端装置、其控制方法、计算机可读记录介质和应用系统

摘要

一种终端装置，包括：从由应用系统提供的至少两个游戏之中的在终端装置中使用的游戏关于向另一游戏的邀请向管理装置的邀请信息管理单元发送询问的询问单元；接收与询问对应的邀请信息的邀请信息接收单元；和根据邀请信息在显示单元上显示邀请的细节的显示控制单元。

说明书

技术领域

本发明涉及用于提供多个应用的应用系统中的终端装置。

背景技术

近年，提供因特网上的应用的服务迅速变得普及。作为这种类型 的服务的一个例子，SNS(社会网络服务)对作为站点用户的成员提 供诸如游戏的应用。SNS管理用于识别成员的成员信息。同一用户在 不同的应用中具有不同的用户信息(以下，称为账户)。SNS关联这 些账户与成员信息以能够提供与多个应用有关的连接服务。在连接服 务中，相互认识的用户可识别他们使用哪些应用。(例如，参见专利 文献1)。

在诸如游戏的应用中，存在用户建立同伴关系并且相互协作以在 游戏中行进的情况。在提供连接服务的应用系统中，存在用户邀请另 一用户到该用户正在使用的游戏的情况。

专利文献

专利文献1：未审查日本专利申请公开No.2007-206823

发明内容

技术问题

存在不依赖于SNS并且可被不是SNS的成员的人使用的应用(以 下，称为一般应用)。即使在这种一般应用中，由于账户是不兼容的， 因此，也不能向用户提供与一般应用有关的连接服务。因此，在一般 应用是游戏的情况下，存在用户不能将另一游戏中的同伴邀请到用户 正在使用的游戏的情况。

考虑到以上的情况，本发明的目的是，提供一种终端装置，该终 端装置允许希望邀请到用户正在玩的游戏的用户邀请另一游戏中的同 伴，这些游戏具有不兼容的账户，并且还允许被邀请用户识别对于邀 请游戏的邀请。

问题的解决方案

以下将描述本发明用于实现上述目的的手段。

为了实现以上的目的，本发明提供一种用于应用系统中的终端装 置，该应用系统包括：管理装置和邀请信息管理单元，所述管理装置 关于向用户提供相互不同的应用的至少两个应用装置中的每一个发出 和管理分别唯一地识别用户的多条识别信息，并且通过对同一用户相 互关联分别与至少两个应用装置中的每一个对应的多条识别信息来管 理多条识别信息，所述邀请信息管理单元管理将用户邀请到邀请用户 使用的第一应用的邀请信息，被邀请的用户在第二应用中与邀请用户 具有特定关系。终端装置包括：询问单元，所述询问单元被配置为从 在被邀请用户的终端装置中使用的第二应用向邀请信息管理单元发送 关于是否存在指示向第一应用的邀请的邀请信息的询问；邀请信息接 收单元，所述邀请信息接收单元被配置为接收与询问对应的邀请信息； 以及，显示控制单元，所述显示控制单元被配置为根据邀请信息在显 示单元上显示邀请的细节。

优选上述的终端装置还包括：被配置为在用于邀请用户的终端装 置中的第一应用中选择第二应用的选择单元；被配置为获取与识别对 应于第一应用的邀请用户的识别信息关联并且由管理装置发出的标识 符的获取单元；和被配置为通过预先确定的路径向管理装置报告一对 的通过获取单元获取的标识符和与由选择单元选择的第二应用对应的 邀请用户的识别信息的标识符报告单元。

优选上述的终端装置还包括被配置为向管理装置报告用作由管理 装置管理的邀请信息的基础并且用于在由选择单元选择的第二应用中 与邀请用户具有特定关系的至少一个用户之中的被邀请用户的邀请请 求的邀请请求发送单元。

优选地，在上述的终端装置中，邀请信息管理单元是对管理装置 设置的，并且，询问单元向管理装置的邀请信息管理单元发送关于是 否存在邀请信息的询问。

优选地，在上述的终端装置中，邀请信息管理单元是对至少两个 应用装置中的每一个设置的，并且，询问单元向与在终端装置中激活 的应用对应的应用装置的邀请信息管理单元发送关于是否存在邀请信 息的询问。

然后，本发明提供一种具有显示单元并且用于应用系统中的终端 装置的控制方法，该应用系统包括：管理装置，所述管理装置关于向 用户提供相互不同的应用的至少两个应用装置中的每一个发出和管理 分别唯一地识别用户的多条识别信息，并且通过对同一用户相互关联 分别与至少两个应用装置中的每一个对应的多条识别信息来管理多条 识别信息，以及邀请信息管理单元，所述邀请信息管理单元管理将用 户邀请到邀请用户使用的第一应用的邀请信息的，被邀请的用户在第 二应用中与邀请用户具有特定关系。控制方法包括：从在被邀请用户 的终端装置中使用的第二应用向邀请信息管理单元发送关于是否存在 指示向第一应用的邀请的邀请信息的询问；接收与询问对应的邀请信 息；和根据邀请信息在显示单元上显示邀请的细节。

优选上述的终端装置的控制方法还包括：在邀请用户的终端装置 中使用的第一应用中选择第二应用；获取与识别对应于第一应用的邀 请用户的识别信息关联并且由管理装置发出的标识符；和通过预先确 定的路径向管理装置报告一对的获取的标识符和与第二应用对应的邀 请用户的识别信息。

然后，本发明提供一种上面记录用于具有计算机和显示单元并且 用于应用系统中的终端装置的程序的计算机可读记录介质，该应用系 统包括关于向用户提供相互不同的应用的至少两个应用装置中的每一 个发出和管理分别唯一地识别用户的多条识别信息并且通过对同一用 户相互关联分别与至少两个应用装置中的每一个对应的多条识别信息 来管理多条识别信息的管理装置和管理将用户邀请到邀请用户使用的 第一应用的邀请信息的邀请信息管理单元，被邀请的用户在第二应用 中与邀请用户具有特定关系。程序使得计算机执行以下的处理：从在 被邀请用户的终端装置中使用的第二应用向邀请信息管理单元发送关 于是否存在指示向第一应用的邀请的邀请信息的询问的询问处理；接 收与询问对应的邀请信息的邀请信息接收处理；和根据邀请信息在显 示单元上显示邀请的细节的显示控制处理。

优选上述的程序使得计算机进一步执行以下的处理：在邀请用户 的终端装置中使用的第一应用中选择第二应用的选择处理；获取与识 别对应于第一应用的邀请用户的识别信息关联并且由管理装置发出的 标识符的获取处理；和通过预先确定的路径向管理装置报告一对的在 获取处理中获取的标识符和与在选择处理中选择的第二应用对应的邀 请用户的识别信息的标识符报告处理。

本发明还提供一种上面记录内置于安装于具有计算机和显示单元 并且用于应用系统中的终端装置中的应用的程序中的程序的计算机可 读记录介质，该应用系统包括关于向用户提供相互不同的应用的至少 两个应用装置中的每一个发出和管理分别唯一地识别用户的多条识别 信息并且通过对同一用户相互关联分别与至少两个应用装置中的每一 个对应的多条识别信息来管理多条识别信息的管理装置和管理将用户 邀请到邀请用户使用的第一应用的邀请信息的邀请信息管理单元，被 邀请的用户在第二应用中与邀请用户具有特定关系。内置程序使得计 算机执行以下的处理：从在被邀请用户的终端装置中使用的第二应用 向邀请信息管理单元发送关于是否存在指示向第一应用的邀请的邀请 信息的询问的邀请处理；接收与询问对应的邀请信息的邀请信息接收 处理；和根据邀请信息在显示单元上显示邀请的细节的显示控制处理。

优选上述的内置于应用的程序中的程序使得计算机进一步执行以 下的处理：在邀请用户的终端装置中使用的第一应用中选择第二应用 的选择处理；获取与识别对应于第一应用的邀请用户的识别信息关联 并且由管理装置发出的标识符的获取处理；和通过预先确定的路径向 管理装置报告一对的在获取处理中获取的标识符和与在选择处理中选 择的第二应用对应的邀请用户的识别信息的标识符报告处理。

然后，本发明提供一种应用系统，该应用系统包括：向用户提供 相互不同的应用并且对应用中的每一个管理指示用户之间的特定关系 的关系信息的至少两个应用装置，用户终端装置，以及对至少两个应 用装置中的每一个发出和管理分别唯一地识别用户的多条识别信息的 管理装置。管理装置包括：被配置为当在用于邀请用户的终端装置中 的第一应用中指定第二应用时与作为与第一应用对应的邀请用户的识 别信息的第一识别信息相关联地发出标识符的发出单元；被配置为在 由发出单元发出的标识符在邀请用户的终端装置中从第一应用被转送 到第二应用之后通过预先确定的路径接收一对的标识符和作为与第二 应用对应的识别信息的第二识别信息的接收单元；被配置为相互关联 地管理由发出单元发出的标识符匹配由接收单元接收的标识符的第一 识别信息和第二识别信息并且管理从至少两个应用装置获取的关系信 息的管理单元；被配置为当在用于邀请用户的终端装置中的第一应用 中指定第一应用时获取与邀请用户的第一识别信息对应的第二识别信 息并且向邀请用户的终端装置报告与第二识别信息对应的关系信息的 报告单元；和被配置为当在邀请用户的终端装置中从由报告的关系信 息识别的作为被邀请的候选用户的至少一个用户之中指定被邀请用户 时管理指示特定的被邀请用户被邀请到第一应用的邀请信息的邀请信 息管理单元。当从终端装置接收关于是否存在邀请信息的询问时，如 果邀请信息管理单元管理将终端装置的用户指定为被邀请用户的邀请 信息，那么报告单元向询问终端装置报告邀请信息。终端装置包括： 被配置为从在被邀请用户的终端装置中使用的第二应用向邀请信息管 理单元发送关于是否存在指示向第一应用的邀请的邀请信息的询问的 询问单元；被配置为接收与询问对应的邀请信息的邀请信息接收单元； 和被配置为根据邀请信息在显示单元上显示邀请的细节的显示控制单 元。

本发明还提供一种应用系统，该应用系统包括：向用户提供相互 不同的应用并且对应用中的每一个管理指示用户之间的特定关系的关 系信息的至少两个应用装置，用户终端装置，以及对至少两个应用装 置中的每一个发出和管理分别唯一地识别用户的多条识别信息的管理 装置。管理装置包括：被配置为当在用于邀请用户的终端装置中的第 一应用中指定第二应用时与作为与第一应用对应的邀请用户的识别信 息的第一识别信息相关联地发出标识符的发出单元；被配置为在由发 出单元发出的标识符在邀请用户的终端装置中从第一应用被转送到第 二应用之后通过预先确定的路径接收一对的标识符和作为与第二应用 对应的识别信息的第二识别信息的接收单元；被配置为相互关联地管 理由发出单元发出的标识符匹配由接收单元接收的标识符的第一识别 信息和第二识别信息并且管理从至少两个应用装置获取的关系信息的 管理单元；和被配置为当在用于邀请用户的终端装置中的第一应用中 指定第一应用时获取与邀请用户的第一识别信息对应的第二识别信息 并且向邀请用户的终端装置报告与第二识别信息对应的关系信息的报 告单元。在从管理装置接收与第二识别信息对应的关系信息之后，当 在邀请用户的终端装置中从由邀请用户的关系信息识别的作为被邀请 的候选用户的至少一个用户指定被邀请用户并且指示指定的被邀请用 户被邀请到第一应用的邀请信息被发送到与第二应用对应的应用装置 时，应用装置中的每一个包含邀请信息管理单元，邀请信息管理单元 被配置为管理邀请信息。当从终端装置接收关于是否存在邀请信息的 询问时，如果邀请信息管理单元管理将终端装置的用户指定为被邀请 用户的邀请信息，那么邀请信息被报告给终端装置。终端装置包括： 被配置为从在被邀请用户的终端装置中使用的第二应用向邀请信息管 理单元发送关于是否存在指示向第一应用的邀请的邀请信息的询问的 询问单元；被配置为接收与询问对应的邀请信息的邀请信息接收单元； 和被配置为根据邀请信息在显示单元上显示邀请的细节的显示控制单 元。

附图说明

图1是根据本发明的实施例的应用系统的框图。

图2A是表示用于关联账户的处理的概要的示图。

图2B是表示用于询问邀请请求的处理的概要的示图。

图3是表示管理服务器的结构的框图。

图4是表示用户信息表的示例性数据结构的示图。

图5是表示ID管理表的示例性数据结构的示图。

图6是表示伙伴关系表的示例性数据结构的示图。

图7是表示邀请表的示例性数据结构的示图。

图8是表示终端装置的结构的框图。

图9是表示用于获取朋友网络识别信息的获取处理的细节的次序 图。

图10是表示伙伴关系同步化处理的细节的次序图。

图11是表示邀请处理的细节的次序图。

图12是表示根据变更例的用于获取朋友网络识别信息的获取处 理的细节的次序图。

具体实施方式

以下将参照附图描述根据本发明的实施例的使用管理服务器的应 用系统。

1.应用系统的结构

图1是根据本发明的实施例的应用系统100的框图。应用系统100 包括诸如因特网的通信网络NET、用户终端装置2、管理服务器3和 应用服务器4A、4B、4C、…。应用服务器4A、4B、4C、…单独地 管理用户账户并且通过使用各应用向用户提供单独的服务。在本例子 中，应用服务器4A、4B、4C、…分别提供游戏A、游戏B、游戏C、… 作为单独的服务。游戏A、游戏B、游戏C、…可以是由浏览器提供 的浏览器游戏，但是，在本例子中，假定游戏A、游戏B、游戏C、… 的程序被下载到用户终端装置2中、被安装于用户终端装置2中并且 在其上面被执行。在这种情况下，应用服务器4A、4B、4C、…管理 游戏A、游戏B、游戏C、…的用户的游戏数据，并且向用户提供分 数等级和其它数据。

应用服务器4A、4B、4C、…提供各种类型的应用(例如，用于 共享照片和视频)，诸如游戏A、游戏B、游戏C、…，并且可具有 除了由应用提供的单独的服务以外用于在用户之间交换通信的功能。 各应用的用户可使用这种通信功能，以通过与玩同一游戏(应用)的 用户建立伙伴关系以通过问候和评论相互通信邀请获取可在游戏中交 换的点。拥有的伙伴越多，则越容易在游戏中进展，原因是可在游戏 战斗中获得来自伙伴的支持。例如，当用户提出伙伴申请并且先申请 的用户批准它时，建立伙伴关系。

管理服务器3可与应用服务器4A、4B、4C、…通信。用户终端 装置2可通过通信网络NET执行通信，并且例如是个人计算机或便携 式电话。

为了向用户提供与不依赖于SNS的多个游戏有关的连接服务，必 须相互关联在游戏中使用的账户。作为示例性的连接服务，当账户相 互关联时，正在玩游戏的用户变得能够邀请作为用户在另一游戏中的 伙伴的另一用户到该游戏。具体而言，当游戏A的用户使用游戏B时， 用户可邀请用户在游戏B中与其具有伙伴关系的用户到游戏A。

在这种不依赖于SNS的游戏中，当用户邀请另一邀请到用户正在 使用的游戏时，在常规上使用社会媒介或电子邮件。但是，不清楚被 邀请用户是否使用社会媒介。电子邮件地址可能是未知的。在游戏中 与其建立了伙伴关系的用户未必在实际社会中具有朋友关系。由于在 游戏中已知的用户名称(昵称)不匹配在实际社会中使用的电子邮件 或社会媒介中使用的用户名称(账户)，因此难以在社会媒介中识别 被邀请的用户。因此，在一些情况下，不能通过使用社会媒介或电子 邮件邀请在游戏中与其建立了伙伴关系的用户。当在不依赖于SNS的 多个游戏中使用的账户被关联时，正在玩游戏的用户变得能够将在另 一游戏中是用户的伙伴的另一用户邀请到该游戏。

为了进行邀请，首先必须关联提出邀请的用户(邀请用户)的游 戏A(应用A的例子)中的账户与游戏B(应用B的例子)中的账户。 其次，必须识别在游戏B中与邀请用户具有伙伴关系的用户。由于需 要在不同的应用上执行该处理，因此，应用服务器4A和应用服务器 4B都不能单独地执行处理。

管理服务器3执行用于关联邀请用户的游戏A中的账户和游戏B 中的账户的关联处理和用于向邀请用户提供接收邀请的用户(被邀请 用户)的候选的邀请处理。

1.1关联处理的概要

将参照图2A描述关联处理的概要。当用户注册账户时，应用服 务器4A和4B产生本地识别信息(以下，称为LocalID)。该LocalID 是在应用服务器4A和4B中的每一个中唯一地识别各用户的识别信 息。因此，同一用户具有不兼容的不同的LocalID。

在产生LocalID之后的希望的定时，应用服务器4A和4B请求管 理服务器3发出朋友网络识别信息(以下，称为FNWID)。FNWID 是用于在整个应用系统100中识别用户的识别信息，并且由管理服务 器3统一管理。管理服务器3响应从应用服务器4A和4B发送的 FNWID发出请求发出FNWID。因此，即使游戏A的用户和游戏B 的用户是同一用户，也发出不同的FNWID。

应用服务器4A相互关联地管理FNWID(第一识别信息的例子) 和唯一地识别使用游戏A的多个用户中的每一个的LocalID，并且， 应用服务器4B相互关联地管理FNWID(第二识别信息的例子)和唯 一地识别使用游戏B的多个用户中的每一个的LocalID。

在本例子中，假定响应对玩游戏A的用户从应用服务器4A发送 的FNWID发出请求发出的FNWID被称FNWIDa、与FNWIDa对应 的LocalID被称为LocalIDa、响应对玩游戏A的同一用户从与游戏B 对应的应用服务器4B发送的FNWID发出请求发出的FNWID被称为 FNWIDb、与FNWIDb对应的LocalID被称为LocalIDb、与游戏A 对应的类型信息被称为AppIDa且与游戏B对应的类型信息被称为 AppIDb。FNWIDa被存储于管理服务器3、应用服务器4A和终端装 置2中。以相同的方式，FNWIDb被存储于管理服务器3、应用服务 器4B和终端装置2中。LocalIDa被存储于应用服务器4A中，并且， LocalIDb被存储于应用服务器4B中。当发出FNWIDa和FNWIDb 时，管理服务器3还不能识别它们是向同一用户发出的识别信息。

在用于关联FNWIDa与FNWIDb的关联处理中，管理服务器3 发出与FNWIDa对应的令牌Tx(标识符)，并且将令牌Tx发送到应 用服务器4A(S1)。应用服务器4A将接收的令牌Tx发送到与FNWIDa 对应的终端装置2的游戏A(S2)。管理服务器3向应用服务器4A 发送令牌Tx(S1)的定时和应用服务器4A向终端装置2发送令牌 Tx(S2)的定时不需要被链接。例如，应用服务器4A可响应由终端 装置2提出的请求向终端装置2发送令牌Tx。

然后，在终端装置2中，令牌Tx从与FNWIDa对应的游戏A被 转送到与FNWIDb对应的游戏B(S3)。转送的令牌Tx和FNWIDb 从游戏B被发送到应用服务器4B(S4)。应用服务器4B将令牌Tx 和FNWIDb发送到管理服务器3(S5)。在用于将令牌Tx从游戏A 转送到游戏B的处理(S3)中，可以包括终端装置2的存储装置23 (参见图8)中的预先确定的区域(应用共享区域)。

以这种方式，关于FNWIDa由管理服务器3发出的令牌Tx通过 终端装置2中的游戏A、终端装置2中的游戏B和应用服务器4B从 应用服务器4A被传送到管理服务器3，并且与FNWIDb相关联地被 接收。管理服务器3搜索已发出的令牌。当接收的令牌匹配发出的令 牌时，管理服务器3关联与接收的令牌对应的FNWID和与发出的令 牌对应的FNWID。在本例子中，接收的令牌是令牌Tx，并且，与其 对应的FNWID是FNWIDb。在管理服务器3中，匹配接收的令牌Tx 的令牌Tx与FNWIDa关联。因此，管理服务器3可关联FNWIDa 与FNWIDb。例如，发出FNWIDa和FNWIDb共通的参照识别信息 (以下，称为RefID)。当FNWIDa和FNWIDb共通的RefID在这 里被称为RefIDx时，如图2A所示，FNWIDa和FNWIDb与RefIDx 相关联地被存储，以关联FNWIDa与FNWIDb。

参照上述的关联处理，图1所示的管理服务器3可与包含提供游 戏A(第一应用的例子)的应用服务器4A(第一应用装置的例子)和 提供游戏B(第二应用的例子)的应用服务器4B(第二应用装置的例 子)的多个应用服务器通信，并且发出唯一地识别使用游戏A的多个 用户中的每一个的FNWIDa(第一识别信息)和唯一地识别使用游戏 B的多个用户中的每一个的FNWIDb(第二识别信息)，并且管理它 们。

管理服务器3还包含用于向应用服务器4A发出与用户的 FNWIDa相关的令牌(示例性标识符)的发出单元11、用于在游戏A 和游戏B可用的终端装置2中从应用服务器4B接收从游戏A转送到 游戏B的令牌的接收单元12和用于相互关联地管理由发出单元11发 出的令牌和由接收单元12接收的令牌匹配的FNWIDa和FNWIDb的 管理单元13。当管理服务器3执行邀请处理时，这里的用户是邀请到 游戏A的邀请用户。

这里，游戏是示例性应用。接收单元12接收从游戏A转送到游 戏B的令牌，但是令牌的路由可被自由选择。例如，可直接从终端装 置2接收令牌，或者可间接地通过应用服务器4B(第二应用装置)接 收令牌。用于将令牌从游戏A转送到游戏B的触发器可基于用户的操 作、游戏A中的自动处理或者通过游戏A启动的在终端装置中执行的 程序处理。只要可检查由发出单元发出的令牌和由接收单元接收的令 牌是否匹配，就可使用任何产生方法，并且，令牌可具有任何内容。 例如，令牌可以是组合数字字母字符的唯一字符串。

另一方面，终端装置2包含用于对于各可用游戏(示例性应用) 存储FNWID(示例性识别信息)的存储单元205。终端装置2还包括 用于获取与正在使用的游戏中的FNWIDa对应且由管理服务器3发出 的令牌的获取单元207。终端装置2还包括用于通过预先确定的路径 向管理服务器3报告一对的由获取单元207获取的令牌和游戏B中的 FNWIDb的标识符报告单元208。例如，终端装置2的存储单元205 存储与游戏A对应的FNWIDa和与游戏B对应的FNWIDb。当在终 端装置2中在游戏A中选择游戏B时，获取单元207获取与在被使用 的游戏A中识别邀请用户的FNWIDa对应并且由管理服务器3的发 出单元11发出的令牌。标识符报告单元208通过预先确定的路径向管 理服务器3发送一组的由获取单元207获取的令牌和与游戏B对应的 FNWIDb。

通过这样做，即使不在管理服务器3中设置要由用户管理的新账 户，通过在预先确定的路径上绕过令牌，管理服务器3也可相互关联 地管理应用服务器4A的账户和应用服务器4B的账户。换句话说，用 户不必意识到管理服务器3的存在。当不同游戏的同一用户的账户以 这种方式关联时，能够向用户提供与多个游戏有关的连接服务。例如， 在连接服务中，能够在游戏的游戏画面上显示另一游戏中的伙伴列表。 显示伙伴列表使得能够实现可将另一游戏中的伙伴邀请到当前正在使 用的游戏的连接服务。如上所述，当在用户的终端装置2中选择另一 游戏时执行关联处理。料想，如果与其它游戏的选择无关地对于所有 的用户根据需要执行关联处理，那么管理服务器3的处理负担增加。 但是，由于在诸如选择其它游戏时的发生预先确定的处理的定时执行 关联处理，因此，在本实施例中，可进行有效的关联，并且管理服务 器3的处理负担减小。可不在选择其它游戏之后而在选择其它游戏之 前执行关联处理。换句话说，可在用户请求关联多个FNWID的关联 处理时执行关联处理。当如上面描述的那样在出现预先确定的处理的 定时执行关联处理时，与当同一用户具有多个FNWID时对于一组的 所有FNWID执行关联处理的情况相比，管理服务器3的处理负担减 小。

管理服务器3的邀请信息管理单元16从多个应用服务器4中的每 一个获取指示多个游戏中的每一个中的用户之间的特定关系的伙伴列 表(关系信息的例子)并且管理列表。因此，可由管理服务器3一并 管理单独地通过多个应用服务器4管理的伙伴列表。

这里，在由多个应用服务器4(示例性应用装置)中的每一个提 供的游戏(示例性应用)中，在游戏中形成与其它用户的特定关系。 例如，如果应用是游戏，那么特定关系包括用户可在游戏前进时与另 一用户协作的伙伴关系。游戏中的协作意味着与伙伴一起在游戏中前 进或者使得诸如伙伴的游戏能力值的游戏数据可用。特定关系包括拒 绝伙伴关系的阻挡关系或用户将另一用户识别为竞争者并且不需要另 一用户批准的竞争者关系。如果应用是诸如聊天的通信应用，那么聊 天好友与特定关系对应。

管理服务器3还包括用于从使用游戏A(第一应用的例子)的用 户的终端装置2接收用于请求指示与FNWIDb(第二识别信息的例子) 相关的伙伴关系的伙伴列表(示例性关系信息)的伙伴列表请求(示 例性获取请求)的接受单元14和用于向发送了伙伴列表请求的终端装 置2或者向应用服务器4A(第一应用装置的例子)报告与FNWIDb 相关的伙伴列表的报告单元15。这里，当报告单元15向应用服务器 4A报告伙伴列表时，应用服务器4A向用户的终端装置2报告伙伴列 表。换句话说，报告单元15直接或间接向终端装置2报告与FNWIDb 相关的伙伴列表。

因此，使用游戏A和游戏B的用户的终端装置2可在游戏A中 获取游戏B中的伙伴列表。换句话说，可在一个游戏中获取另一游戏 中的伙伴列表。例如，即使在账户不兼容的游戏之间，也能够基于另 一游戏中的动作向在一个游戏中具有伙伴关系的用户报告信息。要报 告的目标信息包括例如消息信息或后面描述的邀请信息。当管理服务 器3执行邀请处理时，使用游戏A的邀请用户的终端装置2可获取接 收邀请的游戏B中的伙伴列表。在获取的伙伴列表中列出的用户用作 被邀请到游戏A的用户候选人。

管理服务器3还包括从由报告单元15报告的伙伴列表之中接收将 由邀请用户选择的被邀请用户邀请到游戏A的邀请请求并且蓄积和管 理接收的邀请请求的邀请信息管理单元16(蓄积器的例子)。能够一 并管理谁邀请谁到管理服务器3中的哪个游戏(示例性应用)。

下面，图2B表示用于询问邀请请求的处理的概要。在被邀请用 户的终端装置2中，询问单元201向管理服务器3的邀请信息管理单 元16发送是否存在到游戏的邀请的询问，询问是从设置在应用系统 100中的多个应用即游戏A、游戏B、游戏C…中的在终端装置2中使 用的游戏提出的。

例如，当应用系统100提供游戏A、游戏B、游戏C和游戏D时 并且当游戏B在被邀请用户的终端装置2中可用时，终端装置2从游 戏B发送是否存在邀请的询问。具体而言，通过向管理服务器3发送 邀请询问请求执行关于邀请请求的询问。询问单元201向邀请信息管 理单元16发送关于是否存在终端装置2的用户是被邀请用户的邀请的 询问。优选当在终端装置2中激活游戏B时发送询问。但是，不需要 在激活时进行询问，而可在使用游戏B时进行询问。例如，当一些信 息被发送到管理服务器3时，询问请求可包含于被发送的信息中。作 为替代方案，当使用游戏B时，可在出现一些事件(例如，来自用户 的操作指令)时发送询问请求。

当从终端装置2的用户发送关于邀请请求的询问时，如果在邀请 信息管理单元16(蓄积器的例子)中蓄积终端装置2的用户是被邀请 用户的邀请请求，那么管理服务器3的报告单元15向终端装置2报告 指示邀请用户将被邀请用户邀请到游戏A的邀请信息。因此，即使在 账户不兼容的游戏之间，在一个游戏中具有伙伴关系的用户也可被邀 请到另一游戏。

另一方面，终端装置2包含用于从在被邀请用户的终端装置2中 使用的游戏B(第二应用的例子)向管理邀请信息的邀请信息管理单 元16发送关于是否存在指示向游戏A(第一应用的例子)的邀请的邀 请信息的询问的询问单元201、用于接收与询问对应的邀请信息的邀 请信息接收单元202、显示单元203和用于基于邀请信息在显示单元 203上显示邀请的细节的显示控制单元204。因此，即使不在应用服务 器4A、4B、4C、…中执行诸如向终端装置2报告邀请的邀请有关处 理，终端装置2也可识别从作为一个游戏中的伙伴的用户到用户正在 玩的另一游戏的邀请。

这里，邀请信息管理单元16可被设置在应用系统100内的任何位 置，并且可例如被设置在管理服务器3中或应用服务器4A、4B、4C、… 中的每一个中。

例如，游戏(示例性应用)可具有非运行状态、正在执行一些处 理的活动状态、在画面上什么也不显示但正在执行一些处理的背景状 态或不执行处理并且暂停游戏的暂停状态。游戏的激活意味着游戏从 非运行状态或暂停状态过渡到活动状态。游戏的结束意味着游戏从活 动状态过渡到非运行状态或暂停状态。当多个游戏(应用)可同时处 于活动状态中时，游戏的激活意味着游戏中的一个过渡到用户可操作 游戏的状态，诸如在画面的最前面显示游戏的状态。在诸如首先激活 游戏时或者完成教程时的任何定时在游戏(应用)中产生LocalID。

安装游戏(应用)不仅包括新导入还没有导入到终端装置2中的 游戏程序，而且包括与应用系统100兼容的游戏程序的更新。换句话 说，安装游戏包括对安装于终端装置2中的游戏下载与应用系统100 兼容的更新程序以更新其程序。

1.2管理服务器3的结构

图3表示管理服务器3的结构。如图所示，管理服务器3包含用 于控制整个服务器的中央处理单元(CPU)30、用作CPU30的工作 区域的随机存取存储器(RAM)31、在其中存储引导程序等的只读存 储器(ROM)32、用于存储各种类型的程序和数据的硬盘33、包括 键盘和鼠标的输入单元34、用于显示图像的显示单元35、用于通过通 信网络NET与外部装置通信的通信接口36和用于从诸如紧致盘的信 息记录介质读取数据的读取装置37。例如，硬盘33包括用户信息表 TBL11、ID管理表TBL12、伙伴关系表TBL13和邀请表TBL14。 当CPU30执行各种类型的程序时，CPU30用作发出单元11、接收 单元12、管理单元13、接受单元14、报告单元15和邀请信息管理单 元16。换句话说，各种类型的程序控制包括CPU30(计算机)的管 理服务器3。

图4表示用户信息表TBL11的数据结构。用户信息表TBL11 存储多个记录。各记录包含唯一地识别记录的记录识别信息ID、指示 应用的类型的类型信息AppID(以下，只称为AppID)、用户昵称、 FNWID、令牌和指示发出令牌的日期的令牌发出日期。例如，在具有 ID＝1的记录中，FNWID是“XCV56714”，并且，与FNWID相关 地在2012年3月28日发出令牌“56844SAS”。可对于对发出的令牌 指定有效周期的情况使用令牌发出日期。如图1所示，应用服务器4A、 4B、4C、…分别包含分别具有上述的数据结构的用户信息表TBL11A、 TBL11B，TBL11C、…。

图5表示ID管理表TBL12的数据结构。ID管理表TBL12存储 多个记录。各记录包含唯一地识别记录的记录识别信息ID、RefID和 FNWID。当在应用服务器4A、4B、4C、…中的每一个中登记账户时， 发出FNWID。相反，当在关联处理中确定一个游戏中的账户和另一 游戏中的账户属于同一用户时发出RefID。在本例子中，具有ID＝1 和ID＝2的记录具有不同的朋友网络识别信息FNWID“XCV56714” 和REK35460”和相同的RefID 00000011。因此，“XCV56714”和 REK35460”是属于同一用户的朋友网络识别信息FNWID。

图6表示伙伴关系表TBL13的数据结构。伙伴关系表TBL13 存储多个记录。各记录相互关联地存储记录识别信息ID、AppID、指 示关系的类型的组信息Group、指示伙伴申请源用户的LocalID的伙 伴申请源本地识别信息LocalID_From(以下，只称为LocalID_From)、 指示伙伴申请目的地用户的LocalID的伙伴申请目的地本地识别信息 LocalID_To(以下，只称为LocalID_To)、指示伙伴申请源用户的 FNWID的伙伴申请源朋友网络识别信息FNWID_From(以下，只称 为FNWID_From)、指示伙伴申请目的地的FNWID的伙伴申请目的 地朋友网络识别信息FNWID_To(以下，只称为FNWID_To)和指 示伙伴申请的状态的状态信息Stat。

记录伙伴关系以单独地包含伙伴申请源和伙伴申请目的地有利于 减少存储容量。如果用户的LocalID和与用户具有伙伴关系的所有用 户的LocalID被相互关联地存储，那么需要双倍的存储容量。例如， 假定用户A是伙伴申请源且用户B是伙伴申请目的地。当对各用户存 储与其它用户具有伙伴关系的用户的LocalID时，必须对用户A存储 与用户B的伙伴关系并且对用户B存储与用户A的伙伴关系。相反， 在本实施例中，由于伙伴申请目的地的LocalID和伙伴申请源的 LocalID被关联并且存储于一个记录中时，需要的存储容量减半。即 使当更新状态信息Stat时，需要的处理也减半。

用户和另一用户之间的关系可以是伙伴关系、竞争者关系或阻挡 关系。当来自用户的伙伴申请被发送到另一用户且另一用户批准申请 时，建立伙伴关系。当用户对用户视为竞争者的另一用户进行伙伴申 请但不需要另一用户的批准时，建立竞争者关系。例如，当用户和另 一用户玩同一游戏且用户希望将另一用户登记为竞争者时，使用它。 以与竞争者关系相同的方式，当用户请求阻挡用户希望阻挡的另一用 户且不需要另一用户的批准时，建立阻挡关系。当尽管先前拒绝仍从 另一用户重复接收伙伴申请时或者当另一用户出于诸如公告板上的发 言的一些原因麻烦用户时，使用它。

组信息Group对于具有伙伴关系的记录指定“朋友(Friends)”、 对具有竞争者关系的记录指定“对手(Rival)”并对具有阻挡关系的 记录指定“阻止(Block)”。状态信息Stat在伙伴申请未决时指定 “0”、在批准之后指定“1”，并在拒绝之后指定“2”。由于仅分别 通过伙伴申请和阻挡请求建立竞争者关系和阻挡关系，因此不必记录 状态信息Stat。因此，状态信息被设定为“Null”。状态信息Stat可 总是对于竞争者关系和阻挡关系被设定为“0”。

例如，具有ID＝1的记录指示，在具有AppID 00000001的游戏 中，具有LocalID 00000011的用户对具有LocalID 00003120的用户进 行伙伴申请并且申请得到批准。在具有LocalID 00000011的用户进行 伙伴申请的定时产生具有ID＝1的记录，并且，状态信息Stat被设定 为指示伙伴申请未决的“0”。当具有LocalID 00003120的用户接收 伙伴申请并且批准或拒绝它时，状态信息Stat被更新为“1”(批准) 或“2”(拒绝)。

当通过参照伙伴关系表TBL13中的相应的AppID关注特定游戏 时，可识别该游戏中的用户之间的伙伴关系。可通过参照状态信息Stat 识别与其提出了伙伴关系的用户或对其提出了伙伴申请的伙伴。从特 定用户的FNWID匹配FNWID_From的记录提取的FNWID_To指示 用户对其提出伙伴申请的伙伴，并且，从特定用户的FNWID匹配 FNWID_To的记录提取的FNWID_From指示特定用户已从其接收伙 伴申请的伙伴。

如果在建立伙伴关系之后解除伙伴关系，那么该记录被删除。作 为删除记录的替代，可以配置表，使得添加指示记录有效或无效的新 条目，从而使得解除伙伴关系的记录无效。如果重新与一旦解除伙伴 关系的用户建立伙伴关系，那么需要产生新的记录。

如图1所示，应用服务器4A、4B、4C、…分别包含伙伴关系表 TBL13A、TBL13B、TBL13C、…。各伙伴关系表TBL13A、TBL13B、 TBL13C、…存储各游戏的伙伴关系，并且各记录包含记录识别信息 ID、组信息Goup、LocalID_From、LocalID_To、FNWID_From、 FNWID_To和指示伙伴申请的状态的状态信息Stat。当伙伴关系在应 用服务器4A、4B、4C、…中的任一个中改变并且相应的伙伴关系表 TBL13A、TBL13B、TBL13C、…中的存储的内容改变时，从应用 服务器4A、4B、4C、…向管理服务器3发送变化通知，并且，在伙 伴关系表TBL13中反映伙伴关系的变化，因此使存储的内容同步化。

图7表示邀请表TBL14的数据结构。邀请表TBL14存储多个记 录。各记录包含记录识别信息ID、邀请游戏类型信息InviteAppID(以 下，只称为InviteAppID)、邀请用户的朋友网络识别信息 InviteFNWID_From、被邀请用户的朋友网络识别信息 InviteFNWID_To和与被邀请游戏对应的邀请用户的昵称。通过参照 邀请表TBL14，可以识别存在用户被邀请到的游戏。

1.3终端装置2的结构

图8表示终端装置2的结构。终端装置2与关于向用户提供相互 不同的诸如游戏的应用的多个应用服务器4(示例性应用装置)中的 每一个发出并且管理唯一地识别用户的识别信息(FNWID)并且通过 关联多条识别信息管理对同一用户与多个应用服务器4对应的多条识 别信息的管理服务器3(示例性管理装置)一起构成应用系统100。诸 如管理服务器3的构成应用系统100的装置包括用于管理将用户邀请 到邀请用户正在使用的游戏A(第一应用的例子)的邀请信息的邀请 信息管理单元16，使得被邀请用户在游戏B(第二应用的例子)中与 邀请用户具有特定关系。

终端装置2包含用于控制整个装置的CPU20、用作CPU20的工 作区域的RAM21、在其中存储引导程序和其它数据的ROM22、用 于存储各种类型的程序和数据的存储装置23、包括十键键盘和触摸敏 感键的输入单元24、用于显示图像的显示单元25和用于通过通信网 络NET与外部装置通信的通信接口26。存储装置23存储各种类型的 应用，诸如游戏、与在终端装置2中可用的各应用对应的FNWID和 用于控制整个装置的控制程序。

存储装置23与如图1所示的存储单元205对应，并且，显示装置 25与显示单元203对应。CPU20执行控制程序，由此CPU20用作 询问单元201、邀请信息接收单元202、显示控制单元204、选择单元 206、获取单元207、标识符报告单元208和邀请请求发送单元209。 换句话说，控制程序控制具有CPU20(计算机)和显示装置25的终 端装置。

当安装于终端装置2中的应用与应用系统100兼容时，软件开发 包(SDK)的程序可被加入到该应用的程序中。SDK由居于安装于终 端装置2中的应用和管理服务器3之间的应用编程接口(API)的集 合形成。当在终端装置2中执行其中加入SDK的应用时，可使得终端 装置2用作以下单元：向管理服务器3的邀请信息管理单元16发送关 于是否存在指示对游戏A(第一应用的例子)的邀请的邀请信息的询 问的询问单元201，使得邀请是从在被邀请用户的终端装置2中使用 的游戏B(第二应用的例子)提出的；接收与询问对应的邀请信息的 邀请信息接收单元202；和基于邀请信息在显示单元203上显示邀请 的细节的显示控制单元204。换句话说，SDK可被理解为加入到安装 于具有CPU20(计算机)和显示装置25(示例性显示单元)的终端 装置中的游戏A或游戏B的控制程序中的程序。

并且，终端装置2可被理解为包括询问单元201、邀请信息接收 单元202和显示控制单元204。对管理服务器3设置邀请信息管理单 元16，并且，询问单元201向管理服务器3的邀请信息管理单元16 发送关于是否存在邀请信息的询问。

因此，允许希望邀请到用户当前正在玩的游戏(例如，游戏A) 的用户邀请另一游戏(例子，游戏B)中的伙伴，这些游戏具有不兼 容的账户，并且，被邀请的用户能够获知向邀请游戏的邀请。换句话 说，可以识别从作为游戏(例如，游戏B)中的伙伴的用户向用户正 在玩的另一游戏(例如，游戏A)的邀请。

终端装置2可被配置，使得，当在终端装置2中执行其中加入SDK 的应用时，终端装置2可用作用于在被邀请用户的终端装置2中使用 的游戏A中选择游戏B的选择单元206、获取与识别与游戏A对应的 邀请用户的识别信息对应并且由管理服务器3(示例性管理装置)发 出的令牌(示例性标识符)的获取单元207、以及通过预先确定的路 径向管理服务器3报告一对的由获取单元207获取的令牌和识别与由 选择单元206选择的游戏B对应的邀请用户的识别信息的标识符报告 单元208。终端装置2可被理解为另外包括选择单元206、获取单元 207和标识符报告单元208。因此，管理服务器3能够关联在在同一终 端装置2中动作的不同游戏中使用的账户。

如果安装于终端装置2中的应用是不与应用系统100兼容的版本， 那么，当包含SDK的版本可被下载时，安装于终端装置2中的应用的 程序的版本被更新，从而允许应用与应用系统100兼容。换句话说， 应用服务器4A、4B、4C、…上的应用程序被配置为能够加入SDK。

例如，SDK由管理管理服务器3的商业实体提供。在这种情况下， 在将由商业实体提供的管理管理服务器3的SDK程序加入到游戏A、 游戏B、游戏C、…的应用程序中之后，应用服务器4A、4B、4C、… 的服务提供实体向终端装置2的用户提供应用程序。

2.应用系统的动作

关于(1)FNWID获取处理、(2)伙伴关系同步化处理和(3) 邀请处理描述应用系统100的动作。

2.1FNWID获取处理

图9表示FNWID获取处理的细节。在本例子中，假定用户从应 用服务器4A获取游戏A的程序，并且在该处理中获取FNWIDa。

当用户操作终端装置2以访问游戏A的下载站点并且选择游戏A 的下载时，终端装置2向应用服务器4A发送下载请求。当应用服务 器4A接收下载请求时，应用服务器4A向终端装置2发送包含游戏A 的程序的下载响应。下载站点可以是由第三方运营的服务器。

然后，当用户激活游戏A时，终端装置2中的游戏A通过参照由 游戏A管理的存储区域根据是否存储了登记信息确定它是否是初始激 活。当基于已存储登记信息的事实确定它是初始激活时，游戏A使得 终端装置2显示用于要求用户输入昵称的画面。当用户操作终端装置 2以输入昵称时，终端装置2向应用服务器4A发送包含昵称的登记请 求。当应用服务器4A接收登记请求时，应用服务器4A产生本地识别 信息LocalIDa、在用户信息表TBL11A中存储昵称和本地识别信息 LocalIDa，并且执行账户登记。

然后，应用服务器4A向终端装置2报告产生的本地识别信息 LocalIDa或与本地识别信息LocalIDa相关的识别信息。终端装置2 接收由应用服务器4A报告的本地识别信息LocalIDa或与本地识别信 息LocalIDa相关的识别信息，关联信息与昵称，并且在由游戏A管 理的存储区域中将它们存储为登记信息。当终端装置2然后与应用服 务器4A通信时，如果包含在终端装置2中存储为登记信息的本地识 别信息LocalIDa或与本地识别信息LocalIDa相关的识别信息，那么 应用服务器4A可识别用户。当与本地识别信息LocalIDa相关的识别 信息被用作向终端装置2报告的识别信息时，作为本地识别信息 LocalIDa的替代，识别信息与本地识别信息LocalIDa关联并且被存 储于用户信息表TBL11A中。

然后，应用服务器4A向管理服务器3发送FNWID发出请求。 当管理服务器3接收FNWID关联请求时，管理服务器3发送唯一地 识别用户的FNWIDa并且向应用服务器4A送回包含发出的FNWIDa 的FNWID发出响应。当应用服务器4A接收FNWID发出响应时，应 用服务器4A在用户信息表TBL11A中与本地识别信息LocalIDa关 联地存储FNWIDa。

然后，应用服务器4A向管理服务器3发送包含昵称和FNWIDa 的昵称通知。当管理服务器3接收昵称通知时，管理服务器3与 FNWIDa相关联地存储昵称。应用服务器4A还向终端装置2发送 FNWIDa。当终端装置2接收FNWIDa时，终端装置2向存储于由游 戏A管理的存储区域中的登记信息添加FNWIDa并且在其中存储 FNWIDa。

在上述的例子中，应用服务器4A产生用作用户的账户的本地识 别信息LocalIDa。用户可被要求输入唯一的数字文字字符作为账户。 电子邮件地址可被用作账户。

以这种方式，当用户将游戏A的程序下载到终端装置2中并且激 活游戏A时，由管理服务器3发出FNWIDa，并且，发出的FNWIDa 被存储于管理服务器3、应用服务器4A和终端装置2中，游戏A的 激活被用作触发器。在这种情况下，终端装置2的用户仅需要在应用 服务器4A中设置账户，而不需要另外在用户管理的管理服务器3中 设置管理账户。

2.2伙伴关系同步化处理

下面，图10表示伙伴关系同步化处理的细节。当伙伴关系改变且 伙伴关系表TBL13A的存储内容在应用服务器4A中改变时，应用服 务器4A向管理服务器3发送改变通知。改变通知包含伙伴关系表TBL 13中的变化。例如，应用服务器4A可在改变通知中包含改变的记录 并且可发送通知。当管理服务器3接收改变通知时，管理服务器3在 伙伴关系表TBL13中反映伙伴关系改变以更新存储内容。

以这种方式，由应用服务器4A、4B、4C、…管理的伙伴关系一 并由管理服务器3识别。

2.3邀请处理

图11表示邀请处理的细节。在本例子中，假定玩游戏A和游戏B 的邀请用户将作为被邀请用户的另一用户邀请到游戏A，该另一用户 是邀请用户在游戏B中的伙伴。还假定与游戏A对应的邀请用户的 FNWID是FNWIDa、与游戏B对应的邀请用户的FNWID是 FNWIDb、附图标记2a被分配给邀请用户的终端装置且附图标记2b 被分配给被邀请用户的终端装置。

当邀请用户操作终端装置2a以激活游戏A且选择用于将另一游 戏中的伙伴邀请到游戏A的邀请页时，终端装置2a向应用服务器4A 发送令牌请求。应用服务器4A在接收令牌请求时获取用于邀请终端 装置2a的用户的FNWIDa。例如，当令牌请求包含FNWIDa时，应 用服务器4A需要获取包含于令牌请求中的FNWIDa。作为替代方案， 当令牌请求包含本地识别信息LocalIDa或昵称时，应用服务器4A需 要参照用户信息表TBL11A以获取与本地识别信息LocalIDa或昵称 对应的FNWIDa。

然后，应用服务器4A向管理服务器3发送包含获取的FNWIDa 对应的令牌发出请求。当管理服务器3接收令牌发出请求时，管理服 务器3发出令牌、关联发出的令牌与包含于令牌发出请求中的 FNWIDa，并且在用户信息表TBL11中存储令牌。例如，当假定 FNWIDa是“XCV56714”并且令牌是“56844SAS”时，如图4所示， “56844SAS”与“XCV56714”关联并且存储于用户信息表TBL11 中。

然后，管理服务器3向应用服务器4A发送包含发出的令牌的令 牌发出响应。当应用服务器4A接收令牌发出响应时，应用服务器4A 向终端装置2a发送包含令牌的令牌响应。应用服务器4A事先从管理 服务器3获取指示由属于应用系统100的其它应用服务器4B、4C、… 提供的游戏B、游戏C、…的细节的应用信息。应用服务器4A向终 端装置2a发送获取的应用信息。

当终端装置2a接收应用信息时，终端装置2a基于应用信息在显 示装置25上显示用户可在上面选择游戏中的一个或多个的邀请页。当 邀请用户选择进行邀请的被邀请游戏(在本实施例中，为游戏B)时， 被邀请游戏被激活。

如果在终端装置2a中选择的被邀请游戏还被没有被安装或者已 被卸载使得被邀请游戏不能被激活时，在显示装置25上显示指示不能 执行该处理的消息。当作为被邀请游戏的游戏B被激活并且令牌从游 戏A被转送到游戏B时，终端装置2a向应用服务器4B报告作为与游 戏B对应的FNWID的FNWIDb和转送的令牌。邀请处理可被配置， 使得安装于终端装置2a中的游戏或多个游戏被识别，并且，在显示 25上显示只能在上面选择这些游戏的邀请页。

当应用服务器4B接收FNWIDb和令牌时，应用服务器4B向管 理服务器3报告它们。当管理服务器3接收FNWIDb和令牌时，管理 服务器3确定接收的令牌是否匹配发出的令牌。例如，管理服务器3 搜索用户信息表TBL11并且确定是否发现匹配接收的令牌的发出的 令牌。可进行这种确定，使得通过参照各令牌的发出日期使得具有过 期的有效日期的令牌无效。

在本例子中，假定接收的令牌匹配发出的令牌。在这种情况下， 管理服务器3关联FNWIDa与FNWIDb。例如，管理服务器3在ID 管理表TBL12中存储FNWIDa和FNWIDb的相同的RefID。例如， 当假定FNWIDa是“XCV56714”且FNWIDb是“REK35460”时， 如图5所示，“00000011”的相同的RefID被存储于ID管理表TBL12 中。

然后，终端装置2a的游戏A向管理服务器3发送伙伴列表请求。 伙伴列表请求包含指示邀请游戏是游戏A的类型信息AppID和邀请 用户的FNWIDa。当管理服务器3接收伙伴列表请求时，管理服务器 3提取在游戏B中与邀请用户具有伙伴关系的至少一个用户作为要被 邀请的候选用户。

具体而言，管理服务器3的CPU30参照ID管理表TBL12以获 取与邀请用户的FNWIDa对应的RefID，并然后提取具有相同的 RefID并与游戏B对应的邀请用户的FNWIDb。例如，在图5所示的 例子中，当FNWIDa是“XCV56714”时，由于与“XCV56714”关 联的RefID是“00000011”，因此，CPU30获取“00000011”作为 与FNWIDa相关的RefID。然后，CPU30提取具有“00000011”的 RefID的另一FNWID。在本例子中，提取“REK35460”(上述的 FNWIDb)。提取的FNWIDb是与邀请用户玩的另一游戏对应的 FNWID。当在用户信息表TBL11中参照相应的AppID时，提取的 FNWIDb可被识别为与游戏B对应的FNWID。换句话说，通过执行 上述的关联处理，可以识别与邀请用户将一些人邀请到的游戏A不同 的游戏(游戏B)所对应的FNWID(在本例子中，FNWIDb＝ REK35460)。

然后，CPU30参照伙伴关系表TBL13以识别与邀请用户将一些 人邀请到的游戏A不同的游戏(游戏B)中的至少一个伙伴。具体而 言，通过从具有指示要从中邀请伙伴的游戏B的AppID并且邀请用 户的FNWIDb匹配FNWID_From的记录提取FNWID_To获取的 FNWID和通过从具有指示游戏B的AppID并且FNWIDb匹配 FNWID_To的记录提取FNWID_From获取的FNWID一起指示被邀 请游戏(游戏B)中的伙伴。因此，提取的FNWID是与游戏B对应 的伙伴的FNWIDb。

在这种情况下，参照具有提取的FNWID的记录中的状态信息 Stat，并且，如果状态指示意味着伙伴申请未决的“0”或者意味着拒 绝的“2”，那么从提取结果排除FNWID。但是，由于意味着伙伴申 请未决的“0”表示成为伙伴的可能性，因此可在提取的结果中包括相 应的FNWID。

然后，CPU30从至少一个FNWIDb(以下，称为第一FNWID) 识别不与与游戏A对应的FNWID(以下，称为第二FNWID)相关的 一个作为要被邀请的候选用户的FNWID。这是由于，当很显然被邀 请游戏中的伙伴已使用邀请游戏(游戏A)时，需要从被邀请用户的 候选排除该伙伴。

具体而言，CPU30首先参照ID管理表TBL12，以识别与提取 的第一FNWID中的每一个对应的RefID(第一处理)。在该第一处 理中，存在ID管理表TBL12不包含具有第一FNWID的记录的情况。 在这种情况下，由于CPU30不能识别相应的RefID，因此处理不前 进到后面描述的第二或第三处理，并且，第一FNWID被视为被邀请 候选用户的FNWID。

第二，CPU30根据识别的RefID识别第二FNWID(第二处理)。 换句话说，CPU30识别具有相同的RefID的第二FNWID。第三，30 参照用户信息表TBL11，以确定第二FNWID是否是与游戏A对应 的FNWID(第三处理)。换句话说，在具有第二FNWID的记录中确 定相应的AppID是否指示游戏A。当确定第二FNWID不是与游戏A 对应的FNWID即第二FNWID是与游戏A以外的游戏对应的FNWID 时，与该第二FNWID对应的第一FNWID被视为被邀请候选用户的 FNWID。另一方面，如果确定第二FNWID是与游戏A对应的FNWID， 那么该伙伴不被视为被邀请的候选用户。

然后，CPU30参照用户信息表TBL11以产生包含由被邀请用户 的候选的FNWID、与被邀请用户的候选的FNWID对应的在进行邀请 的游戏(游戏B)中使用的昵称和AppID(指示游戏B的AppIDb) 形成的至少一个组的伙伴列表。管理服务器3向终端装置2a发送包含 伙伴列表的伙伴列表响应。

当终端装置2a接收伙伴请求列表时，终端装置2a在显示装置25 上对各游戏名称显示至少一个伙伴(被邀请候选用户)的昵称。在本 实施例中，由于游戏B是被邀请游戏，因此对邀请用户与令牌Tx和 与游戏A对应的FNWIDa相关的FNWID仅是与游戏B对应的 FNWIDb。因此，在显示装置25上显示的至少一个伙伴的昵称仅是用 于游戏B的昵称。当多个其它的游戏被视为被邀请游戏时，产生包含 多个游戏中的每一个中的伙伴的伙伴列表，并且，对于各游戏名称显 示伙伴的昵称。在这种情况下，与游戏A对应的FNWIDa在关联处 理中与多个其它游戏所对应的FNWID相关。

当邀请用户操作终端装置2a以选择被邀请的伙伴时，终端装置 2a(邀请请求发送单元209)向管理服务器3发送包含邀请信息的邀 请请求。该邀请信息包含与邀请游戏A对应的邀请用户的FNWIDa、 与被邀请伙伴玩的被邀请游戏B对应的被邀请用户的FNWIDb和邀 请游戏A的AppID。还能够选择多个伙伴。

然后，当管理服务器3接收邀请请求时，管理服务器3在邀请表 TBL14中存储包含邀请信息的记录。如上所述，邀请表TBL14中的 各记录包含InviteAppID、InviteFNWID_From、InviteFNWID_To和 与被邀请游戏对应的邀请用户的昵称。在本例子中，假定被邀请用户 的FNWID是FNWIDb且被邀请用户在游戏B中与邀请用户具有伙伴 关系。因此，在邀请表TBL14中的各记录中，InviteAppID是游戏A 的AppID，InviteFNWID_From是邀请用户的FNWIDa且 InviteFNWID_To是被邀请用户的FNWIDb。CPU30获取游戏B中 的邀请用户的昵称，这里，邀请用户与被邀请用户具有伙伴关系。具 体而言，CPU30首先识别邀请用户的FNWIDa，该FNWIDa包含于 邀请请求中。第二，CPU30参照ID管理表TBL12以获取与邀请用 户的FNWIDa对应的RefID。第三，CPU30参照ID管理表TBL12 以提取与获取的RefID相关联地存储的邀请用户的FNWID (FNWIDb)。第四，CPU30参照用户信息表TBL11以识别与邀请 用户的提取FNWID(FNWIDb)相关的记录并且获取包含于记录中 的邀请用户的昵称。

然后，CPU30在邀请表TBL14中存储邀请游戏A的AppID、 与游戏A对应的邀请用户的FNWIDa、与游戏B对应的被邀请用户的 FNWIDb和被邀请游戏B中的邀请用户的昵称。邀请表TBL14用作 蓄积邀请信息的邀请信息管理单元16(参见图1)。

然后，当被邀请用户操作终端装置2b以激活游戏B时，终端装 置2b的询问单元201在游戏B的使用过程中向管理服务器3发送询 问请求。邀请询问请求包含与游戏B对应的被邀请用户的FNWIDb。 即使当属于应用系统100的游戏A、游戏B、游戏C、…中的任一个 被激活时，也在被激活游戏的执行过程中向管理服务器3发送邀请询 问请求。

然后，当管理服务器3接收邀请询问请求时，管理服务器3搜索 邀请信息。具体而言，CPU30参照邀请表TBL14以识别FNWIDb 记录为InviteFNWID_To的记录并在该记录中识别与游戏B对应的邀 请用户的昵称和指示邀请游戏A的AppIDa。AppIDa可包含指示可下 载邀请游戏A的站点的地址的链接信息。以这种方式，CPU30用作 邀请信息管理单元16。然后，CPU30通过通信接口36向终端装置2b 发送作为识别的邀请信息的包含昵称和AppIDa的邀请询问响应。在 这种情况下，CPU30用作报告单元15。

然后，当终端装置2b接收邀请询问响应时，终端装置2b在显示 装置25上显示邀请用户的昵称、被邀请用户被邀请到的游戏的名称和 链接信息。具体而言，终端装置2b的邀请信息接收单元202(CPU20) 接收包含邀请信息的邀请询问响应，并且，显示控制单元204(CPU20) 在显示装置25上显示邀请细节。

通过这样做，被邀请用户可理解已在游戏B中具有伙伴关系的邀 请用户作出了到游戏A的邀请。

如上所述，终端装置2可被配置以用作邀请请求发送单元209， 该邀请请求发送单元209向管理服务器3发送对于在由选择单元206 选择的游戏B中与用户(邀请用户)具有特定关系的用户(待邀请的 候选用户)中的接收邀请的用户(被邀请用户)的邀请请求。该邀请 请求用作由管理服务器3管理的邀请信息的基础。并且，终端装置2 可被理解为另外包括邀请请求发送单元209。

由于以这种方式游戏B基于游戏A中的动作被激活并且被激活的 游戏B向管理服务器3发送邀请请求，因此，正在玩游戏A的用户能 够将在游戏B中作为用户的伙伴的另一用户邀请到游戏A。换句话说， 即使在账户不兼容的游戏之间，也能够基于另一游戏中的动作邀请在 游戏中具有伙伴关系的用户。这里，基于游戏A中的动作激活的游戏 B在动作上与当用户玩游戏B时激活的游戏B不同。换句话说，基于 游戏A中的动作激活的游戏B执行邀请处理。

3.变更例

本发明不限于上述的实施例。以下描述的各种类型的变更例是可 能的。当然，各变更例和实施例可被适当地组合。

(1)在以上的实施例中，应用服务器4A、4B、4C、…从开始被 加入到应用系统100中。本发明不限于这种情况。应用服务器可被加 入到已在动作的应用系统100中。

例如，假定应用服务器4A已独立动作并且向应用系统100新施 加应用服务器4A。在这种情况下，游戏A的程序需要在终端装置2 中被更新。这是由于，游戏A不具有用于向另一游戏的程序转送令牌 的功能或邀请处理功能，原因是，当应用服务器4A已独立动作时， 游戏A仅需要在应用服务器4A上动作。

图12表示根据变更例的FNWID获取处理。在本变更例中，假定 应用服务器4A新加入到应用系统100中。

首先，用户操作终端装置2a以访问游戏A的下载站点。然后， 在显示装置25上显示用于提示用户安装更新程序的画面。当用户操作 终端装置2a以选择更新时，终端装置2向应用服务器4A发送更新请 求。当应用服务器4A接收更新请求时，应用服务器4A向终端装置 2a送回包含更新程序的更新响应。

然后，当终端装置2a接收更新响应时，游戏A的更新程序被安 装于终端装置2a中。在更新程序的安装中，在前面的游戏A中使用 的昵称和LocalID作为登记信息的一部分被移交。

当游戏A被激活时，根据是否在游戏A的使用过程中已在由终端 装置2a的游戏A管理的存储区域中存储FNWID确定它是否是初始 激活。当基于还没有存储FNWID的事实确定它是初始激活时，终端 装置2a向应用服务器4A发送指示执行了初始激活的初始激活通知。

当应用服务器4A接收初始激活通知时，应用服务器4A向管理服 务器3发送FNWID发出请求。当管理服务器3接收FNWID发出请 求时，管理服务器3发出FNWIDa并且向应用服务器4A送回包含发 出的FNWIDa的FNWID发出响应。当应用服务器4A接收到FNWID 发出响应时，应用服务器4A与昵称和本地识别信息LocalIDa相关联 地在用户信息表TBL11A中存储FNWIDa。应用服务器4A还向终端 装置2a报告FNWIDa。终端装置2a与游戏A相关联地存储FNWIDa。

然后，应用服务器4A向管理服务器3发送包含昵称和FNWIDa 的昵称通知。当管理服务器3接收昵称通知时，管理服务器3将昵称 和FNWIDa存储于用户信息表TBL11中。

以这种方式，当用户将游戏A的更新程序下载到终端装置2a中 并且激活更新程序时，FNWIDa由管理服务器3发出，并且发出的 FNWIDa被存储于管理服务器3、应用服务器4A和终端装置2a中。 在这种情况下，终端装置2a的用户不需要在管理服务器3新设置由用 户管理的管理账户。

在本变更例中，首先向激活游戏A的用户发出FNWID。然后， 有利地，即使用户将更新程序下载到终端装置2中，管理服务器3也 不需要管理还没有使用游戏A的用户的FNWID。

当用户安装更新程序并然后激活程序时，对于与用户具有伙伴关 系的用户，也在应用服务器4A与管理服务器3之间一并执行FNWID 发出处理。但是，对于具有伙伴关系但已发出FNWID的用户，不新 发出FNWID。在这种情况下，当具有伙伴关系的用户安装更新程序 并然后激活程序时，应用服务器4A可向具有伙伴关系的用户的终端 装置2报告FNWID。

(2)在上述的实施例和变更例中，以游戏为应用的例子。本发明 不限于这些例子。本发明也可被应用于任何应用。例如，应用可包括 聊天应用以及照片和视频共享应用。例如，在应用中与另一用户的特 定关系在游戏中是伙伴或竞争者、在聊天应用中是聊天朋友，并且在 照片和视频共享应用中是可共享照片和视频的伙伴。换句话说，本发 明也可被应用于由应用提供的服务和功能的全部或一部分在具有特定 关系的用户和不具有特定关系的用户之间不同的任何应用。

(3)在上述的实施例和变更例中，以用户和另一用户在执行应用 时相互帮助的伙伴关系为例子。本发明不限于该例子。本发明也可被 应用于在应用中形成与另一用户的特定关系的情况。当用户要求另一 用户具有伙伴关系且另一用户批准它时，建立伙伴关系。除了伙伴关 系以外，特定关系可包括拒绝具有伙伴关系的阻挡关系或用户将另一 用户视为竞争者且不需要另一用户的批准的竞争者关系。

(4)在上述的实施例和变更例中，使用游戏A的终端装置2向 管理服务器3发送用于请求指示与与游戏B对应的FNWID相关的伙 伴关系的伙伴列表的伙伴列表请求；并且，管理服务器3包含用于获 取伙伴列表请求的接收单元14和用于向终端装置2发送伙伴列表的报 告单元15。本发明不限于这种情况。接收单元14可从提供游戏A的 应用服务器4A接受伙伴列表请求，并且，报告单元15可向应用服务 器4A发送伙伴列表。在这种情况下，应用服务器4A介于终端装置2 与管理服务器3之间。换句话说，终端装置2向应用服务器4A发送 伙伴列表请求，并且应用服务器4A在接收伙伴列表请求时向管理服 务器3发送伙伴列表请求。管理服务器3在接收伙伴列表请求时向应 用服务器4A发送列表请求，并且应用服务器4A接收伙伴列表并然后 向终端装置2发送伙伴列表。

(5)在上述的实施例和变更例中，当管理服务器3从终端装置2 接收邀请请求时，邀请信息管理单元16蓄积邀请请求。本发明不限于 这种情况。管理服务器3不需要具有邀请信息管理单元16。在这种情 况下，当管理服务器3从终端装置2接收用于将使用游戏B的被邀请 用户邀请到游戏A的邀请请求时，报告单元15需要向与被邀请用户 对应的应用服务器4B发送指示邀请到游戏A的邀请信息。应用服务 器4B包含邀请表TBL14并且蓄积邀请信息(邀请信息管理单元16)。 在被邀请用户在终端装置2中激活游戏B之后，终端装置2的询问单 元201向与被激活游戏B对应的应用服务器4B发送关于邀请请求的 询问。应用服务器4B需要确定是否已在邀请表TBL14中蓄积对被邀 请用户的邀请信息并且向被邀请用户的终端装置2发送邀请信息。换 句话说，对多个应用服务器4中的每一个设置邀请信息管理单元16， 并且，询问单元201向与在终端装置中激活的应用对应的应用服务器 4的邀请信息管理单元16发送关于是否发现邀请信息的询问。

以这种方式，当发现对由邀请用户从由管理服务器3的报告单元 15报告的伙伴列表(示例性关系信息)选择的被邀请用户的邀请请求 时，报告单元向与被邀请用户对应的应用服务器4B(第二应用装置的 例子)发送指示邀请用户邀请到游戏A(第一应用的例子)的邀请信 息。以这种方式，可对蓄积邀请请求使用各种替代性的实施例。

(6)在上述的实施例和变更例中，从游戏A转送到游戏B的令 牌与FNWIDb一起通过应用服务器4B从终端装置2被发送到管理服 务器3的接收单元12。本发明不限于这种情况。管理服务器3可通过 任何路由获取令牌。例如，终端装置2可直接向管理服务器3发送令 牌，并且接收单元可接收令牌。换句话说，在管理服务器3中与 FNWIDa相关联地发出的令牌Tx可通过终端装置2的游戏B从终端 装置2的游戏A被发送到管理服务器3。

在上述的实施例和变更例中，令牌基于终端装置2中的邀请用户 的动作从游戏A转送到游戏B。本发明不限于这种情况。令牌可不基 于邀请用户的动作而基于游戏A的自动处理从游戏A转送到游戏B。 作为替代方案，令牌可基于由游戏A激活并且在终端装置2中动作的 程序处理从游戏A转送到游戏B。

附图标记

1：通信网络

2：终端装置

3：服务器

3B、3C、3D：应用服务器

TBL11：用户信息表

TBL12：ID管理表

TBL13：伙伴关系表

TBL14：邀请表

11：发出单元

12：接收单元

13：管理单元

14：接受单元

15：报告单元

16：邀请信息管理单元(蓄积器)

30：CPU

100：应用系统

201：询问单元

202：邀请信息接收单元

203：显示单元

204：显示控制单元

205：存储单元

206：选择单元

207：获取单元

208：标识符报告单元