用于在通知画面上接受指示的系统的制作方法

1.本发明涉及一种信息处理系统、程序、方法和信息处理装置，其用于在诸如智能电话等的终端装置的通知画面上呈现针对通知源处的游戏应用(下文称为“游戏app”)的操作，并且接受来自用户(也称为“玩家”)的用于执行该操作的指示作为用户输入。


背景技术：

2.在诸如智能电话等的终端装置上玩的许多免费玩的移动端游戏中，指示以游戏的进行作为交换而消耗的成本的参数被引入作为限制连续的玩游戏的元素。这里，指示该成本的参数将被称为“耐力(stamina)”。然而，名称“耐力”仅仅是用于说明的示例，并且指示该成本的参数可以由除耐力之外的名称来指代。在针对诸如智能电话等的终端装置(下文也称为“玩家终端”或“终端”)的宽范围种类的游戏中采用耐力。耐力被用于多种功能，包括游戏内容消耗的速率的控制、保持效果和收费物品的销售。
3.移动端游戏一般在客户端
‑
服务器系统上运行。系统例如通过服务器和用作客户端的n个(n是大于或等于1的任意整数)玩家终端经由网络相互进行通信来实现。服务器管理游戏中的预定参数。例如，服务器管理诸如游戏中的耐力和游戏中的游戏内货币等的参数。
4.根据所执行的玩游戏的细节，以预定单位消耗耐力。在没有足够的玩游戏所需的耐力的情况下，游戏的用户可以通过恢复耐力来继续游戏。例如，用户可以通过选择是等待耐力随着时间的经过而恢复还是通过消耗通过支付所获得的游戏内货币而恢复耐力，来恢复耐力并继续游戏。这里，随着实际时间的经过而恢复到上限耐力值的耐力恢复将被称为“基于时间的恢复”。
5.在通过这种基于时间的恢复将耐力恢复到上限值的情况下，游戏app可以例如通过使用由智能电话的操作系统(os)提供的通知机制(例如，通知api)来执行推送通知，从而在智能电话的通知画面上显示指示耐力完全恢复的消息。
6.可以通过使用以预定单位恢复耐力值的物品(下文称为“恢复物品”)以及通过基于时间的恢复来恢复在游戏中消耗的耐力。恢复物品可以例如通过消耗通过支付所获得的游戏内货币来获得。
7.近来，正积极地开发与耐力值的控制有关的技术。例如，专利文献1公开了如下的技术：在剩余的耐力中间量小于游戏的进行所需的量的状态下通过使用恢复物品将耐力恢复到上限值的情况下，以超出针对耐力的剩余量的上限值的方式进一步恢复耐力。此外，专利文献2也公开了相同类型的技术。
8.引用列表
9.[专利文献]
[0010]
专利文献1：日本专利第6373520号
[0011]
专利文献2：日本专利第6377289号


技术实现要素：

[0012]
发明要解决的问题
[0013]
利用现有技术，在没有进行游戏所需的足够的耐力的情况下，玩游戏的用户可以通过使用恢复物品来将耐力恢复超出上限耐力值；然而，在用户不在玩游戏时通过基于时间的恢复将耐力恢复到其上限值的情况下，虽然在智能电话的通知画面上显示指示耐力完全恢复的消息等，但是不可能执行超出上限耐力值的基于时间的恢复。
[0014]
此外，当用户正忙碌且没有时间来启动游戏app时，即使当经由诸如显示在智能电话画面上的消息等的通知向用户通知通过基于时间的恢复的耐力完全恢复时，用户也不能对游戏进行任何操作，并且因此用户不能做任何事情而只能忽略用户能够最大程度地玩游戏的、耐力已经完全恢复的状态。
[0015]
这导致了通过基于时间的恢复的耐力完全恢复的通知对于忙碌且没有很多时间来玩游戏的用户不是那么重要的认识。特别地，对于在他或她的智能电话中安装了多个游戏app的用户，利用来自各游戏app的推送通知而显示在智能电话画面上并指示耐力完全恢复的通知是麻烦的。
[0016]
为了避免被这样的通知打扰，对于大多数用户来说关闭来自游戏app的推送通知已经成为常见的做法。这导致了用户拒绝所有通知的情形，这些通知不仅包括耐力完全恢复的通知，还包括其它通知(例如，与游戏中举行的事件有关的通知和与收费物品有关的通知)，其结果是不可能利用来自游戏app的推送通知来呈现用于鼓励用户玩游戏的信息。
[0017]
为了解决上述问题，本发明提供一种用于用户通过使用诸如智能电话等的终端装置从游戏app接收指示通过基于时间的恢复的耐力完全恢复的推送通知的信息处理系统等，这使得即使当玩家没有时间来启动游戏app和玩游戏时，用户也能够仅利用在推送通知的画面上的操作来更有利地执行玩游戏，并且使得能够激励用户开启从游戏app接收推送通知的功能。
[0018]
用于解决问题的方案
[0019]
作为根据本发明的信息处理的实施例，所述系统包括服务器和通信地连接到所述服务器的终端，
[0020]
其中，所述服务器包括：
[0021]
判断部件，用于基于以游戏的进行作为交换而消耗的参数来判断是否允许执行玩游戏；
[0022]
游戏进行部件，用于在所述判断部件判断为允许执行玩游戏的情况下，通过消耗所述参数来执行玩游戏；
[0023]
基于时间的恢复部件，用于随着时间的经过，将所述参数恢复到基于时间的恢复的上限值；
[0024]
服务器侧接收部件，用于从所述终端接收用于以超出所述基于时间的恢复的上限值的方式恢复所述参数的超恢复指示；以及
[0025]
超恢复部件，用于基于来自所述终端的所述超恢复指示，通过基于时间的恢复，以超出所述基于时间的恢复的上限值的方式恢复所述参数，以及
[0026]
其中，所述终端包括：
[0027]
预约部件，用于预约在预定定时执行推送通知的时间；
[0028]
通知显示部件，用于在所预约的时间到来时，在通知画面上显示所述推送通知；以及
[0029]
指示接受部件，用于通过所述通知画面从用户接受用于以超出所述参数的所述基于时间的恢复的上限值的方式恢复所述参数的所述超恢复指示。
[0030]
作为根据本发明的信息处理系统的第二实施例，所述系统包括服务器和通信地连接到所述服务器的终端，
[0031]
其中，所述服务器包括：
[0032]
判断部件，用于基于以游戏的进行作为交换而消耗的参数来判断是否允许执行玩游戏；
[0033]
游戏进行部件，用于在所述判断部件判断为允许执行玩游戏的情况下，通过消耗所述参数来执行玩游戏；
[0034]
基于时间的恢复部件，用于随着时间的经过，将所述参数恢复到基于时间的恢复的上限值；
[0035]
推送通知指示部件，用于在所述参数已恢复的预定定时向所述终端发送推送通知指示；
[0036]
服务器侧接收部件，用于从所述终端接收用于以超出所述基于时间的恢复的上限值的方式恢复所述参数的超恢复指示；以及
[0037]
超恢复部件，用于基于来自所述终端的所述超恢复指示，通过基于时间的恢复，以超出所述基于时间的恢复的上限值的方式恢复所述参数，以及
[0038]
其中，所述终端包括：
[0039]
终端侧接收部件，用于从所述服务器接收所述推送通知指示；
[0040]
通知显示部件，用于基于所述推送通知指示来在通知画面上显示推送通知；以及
[0041]
指示接受部件，用于通过所述通知画面从用户接受用于以超出所述参数的所述基于时间的恢复的上限值的方式恢复所述参数的所述超恢复指示。
[0042]
作为根据本发明的程序的实施例，所述程序由通信地连接到服务器的计算机执行，所述程序使所述计算机实现：
[0043]
判断结果接收功能，用于从所述服务器接收判断结果，所述判断结果是通过基于以游戏的进行作为交换而消耗的参数而判断是否允许执行玩游戏来获得的；
[0044]
游戏进行功能，用于在所述判断结果指示允许执行玩游戏的情况下执行玩游戏；
[0045]
通知显示功能，用于随着时间的经过并且所述参数的恢复，在所述参数被恢复达到预定时间或预定值时，在所述服务器处使推送通知被显示在信息处理装置的通知画面上；
[0046]
指示接受功能，用于通过所述通知画面从用户接受用于以超出所述参数的基于时间的恢复的上限值的方式恢复所述参数的超恢复指示；以及
[0047]
指示发送功能，用于向所述服务器发送所述超恢复指示，来通过基于时间的恢复，以超出所述基于时间的恢复的上限值的方式恢复所述参数。
[0048]
作为根据本发明的信息处理装置的实施例，所述信息处理装置通信地连接到服务器，并且包括：
[0049]
判断结果接收部件，用于从所述服务器接收判断结果，所述判断结果是通过基于
以游戏的进行作为交换而消耗的参数而判断是否允许执行玩游戏来获得的；
[0050]
游戏进行部件，用于在所述判断结果指示允许执行玩游戏的情况下执行玩游戏；
[0051]
通知显示部件，用于随着时间的经过并且所述参数的恢复，在所述参数被恢复达到预定时间或预定值时，在所述服务器处使推送通知被显示在通知画面上；
[0052]
指示接受部件，用于通过所述通知画面从用户接受用于以超出所述参数的基于时间的恢复的上限值的方式恢复所述参数的超恢复指示；以及
[0053]
指示发送部件，用于向所述服务器发送所述超恢复指示，来通过基于时间的恢复，以超出所述基于时间的恢复的上限值的方式恢复所述参数。
[0054]
作为根据本发明的信息处理方法的实施例，所述方法在通信地连接到服务器的信息处理装置处执行，并且包括：
[0055]
判断结果接收步骤，用于从所述服务器接收判断结果，所述判断结果是通过基于以游戏的进行作为交换而消耗的参数来判断是否允许执行玩游戏而获得的；
[0056]
游戏进行步骤，用于在所述判断结果指示允许执行玩游戏的情况下执行玩游戏；
[0057]
通知显示步骤，用于随着时间的经过并且所述参数的恢复，在所述参数被恢复达到预定时间或预定值时，在所述服务器处使推送通知被显示在所述信息处理装置的通知画面上；
[0058]
指示接受步骤，用于通过所述通知画面从用户接受用于以超出所述参数的基于时间的恢复的上限值的方式恢复所述参数的超恢复指示；以及
[0059]
指示发送步骤，用于向所述服务器发送所述超恢复指示，来通过基于时间的恢复，以超出所述基于时间的恢复的上限值的方式恢复所述参数。
[0060]
发明的效果
[0061]
利用根据本发明的信息处理系统等，在以游戏进行作为交换而消耗的参数(诸如耐力等)被完全恢复到基于时间的恢复的上限值的情况下，可以在发送给终端装置(诸如智能电话等)的推送通知的画面上从用户接收超恢复指示，该超恢复指示允许基于时间的耐力恢复超出基于时间的恢复的上限值。这使得即使当用户没有时间来玩游戏时，用户也能够在智能电话的通知画面上输入超恢复指示而无需启动游戏app，这使得能够以超出基于时间的恢复的上限值的方式进行基于时间的耐力恢复、直到用户有时间来玩游戏为止。
[0062]
因此，利用根据本发明的信息处理系统等在智能电话画面上显示的耐力完全恢复的通知用作为对没有很多时间来玩游戏的用户有利的通知，这是因为能够继续基于时间的耐力恢复以稍后玩游戏。即，根据本发明的信息处理系统等的通知激励用户积极地开启从游戏app接收推送通知的功能。
附图说明
[0063]
图1是根据本发明的第一实施例的信息处理系统的示意性配置图(系统配置图)。
[0064]
图2是根据本发明的第一实施例的服务器和终端的示意性配置图(框图)。
[0065]
图3是示出根据本发明的第一实施例的服务器和终端的功能配置的示例的示意性配置图(框图)。
[0066]
图4是示出根据本发明的第一实施例的随着时间的经过而恢复耐力的基于时间的恢复处理和超恢复处理的示例的示意图。
[0067]
图5是说明由图2所示并具有图3所示的功能配置的服务器和终端执行的玩游戏执行处理的流程的序列图。
[0068]
图6是说明由图2所示并具有图3所示的功能配置的服务器和终端执行的基于时间的恢复处理的流程的序列图。
[0069]
图7是说明由图2所示并具有图3所示的功能配置的服务器和终端执行的超恢复处理的流程的序列图。
[0070]
图8是示出根据本发明的第一实施例的推送通知画面的示例的图。
[0071]
图9是示出游戏app请求针对推送通知的许可的画面的示例的图。
[0072]
图10是示出根据本发明的第一实施例的用于在推送通知画面上接受超恢复指示的用户界面的示例的图。
[0073]
图11是示出根据本发明的第二实施例的信息处理服务器和终端的功能配置的示例的示意性配置图(框图)。
[0074]
图12示出根据本发明的第二实施例的推送通知处理的示例。
[0075]
图13是示出用于接受可以被显示在根据本发明的第一实施例和第二实施例的终端的通知画面上的自动玩指示的用户界面的示例的图。
具体实施方式
[0076]
下面将参考附图描述本发明的实施例。以下实施例是用于说明本发明的示例，并且不意在将本发明仅限制于这些实施例。此外，在不脱离其主旨的情况下，可以以各种形式修改本发明。此外，在所有附图中，尽可能对相同的组件赋予相同的附图标记，并且将省略重复的描述。
[0077]
图1是示出根据本发明的第一实施例的信息处理系统的配置的图。作为示例，信息处理系统100被配置为包括服务器1、n个(n是大于或等于1的任意整数)终端3(终端装置)和网络2。
[0078]
信息处理系统100是所谓的客户端
‑
服务器系统。信息处理系统100通过在用作客户端的n个终端3和服务器1之间经由网络2相互进行通信来实现。
[0079]
服务器1例如由服务器装置实现。此外，终端3例如由智能电话、游戏机或个人计算机实现。此外，网络2例如由诸如因特网或移动电话网络等的网络、lan(局域网)或者通过组合这些类型的网络而形成的网络实现。
[0080]
在附图中，终端3a和终端3n被示为n个终端3。然而，在下面的描述中，在没有区分的情况下，这些n个终端3将被简称为“终端3”，其中省略部分附图标记。
[0081]
图2是示出根据第一实施例的服务器和终端的硬件配置的框图。在图中，与服务器1的硬件相对应的附图标记以未添加括号的方式被示出，并且与终端3的硬件相对应的附图标记以被添加括号的方式被示出。
[0082]
作为示例，服务器1包括cpu(中央处理单元)11、由rom(只读存储器)、ram(随机存取存储器)等构成的存储器13、总线14、输入/输出接口15、输入单元16、输出单元17、存储单元18和通信单元19。
[0083]
cpu 11根据记录在存储器13中的程序或从存储单元18加载到存储器13中的程序执行各种处理。
[0084]
存储器13还适当地存储cpu 11执行各种处理所需的数据等。cpu 11和存储器13经由总线14彼此连接。输入/输出接口15也连接到总线14。输入单元16、输出单元17、存储单元18和通信单元19连接到输入/输出接口15。
[0085]
输入单元16由各种按钮、触摸屏、或麦克风等形成，并且根据由服务器1的管理员等执行的指示操作来接受各种信息的输入。可替代地，输入单元16可以由独立于用于容纳服务器1的其它单元的主单元的诸如键盘或鼠标等的输入装置实现。
[0086]
输出单元17由显示器、扬声器等构成，并输出图像数据和音乐数据。从输出单元17输出的图像数据和音乐数据作为图像和音乐以玩家可识别的形式从显示器、扬声器等输出。
[0087]
存储单元18由诸如dram(动态随机存取存储器)等的半导体存储器形成，并且存储各种数据。
[0088]
通信单元19实现与其它装置进行的通信。例如，通信单元19经由网络2与终端3相互进行通信。
[0089]
此外，尽管未示出，但是根据需要并适当地在服务器1中设置驱动器。例如，由磁盘、光盘、磁光盘或半导体存储器等形成的可移动介质被适当地加载到驱动器中。可移动介质存储用于执行游戏的程序和诸如图像数据等的各种数据。由驱动器从可移动介质读取的程序和诸如图像数据等的各种数据根据需要安装在存储单元18中。
[0090]
接下来，将描述终端3的硬件配置。如图2所示，作为示例，玩家终端3包括cpu 31、存储器33、总线34、输入/输出接口35、输入单元36、输出单元37、存储单元38以及通信单元39。这些单元各自具有与上述服务器1中具有相同名称和不同附图标记的单元的功能等同的功能。因此，将省略重复的描述。在终端3被配置为便携式装置的情况下，终端3的各硬件单元以及显示器和扬声器可以以集成装置的形式来实现。
[0091]
(功能配置)
[0092]
接下来，将参考图3描述服务器1的功能配置和终端3的功能配置。图3是示出根据本发明的第一实施例的服务器和终端的功能配置的示例的示意性配置图(框图)。图3是示出在图2所示的服务器1和终端3的功能配置中用于执行诸如玩游戏执行处理、基于时间的恢复处理和超恢复处理等的处理的功能配置的框图。
[0093]
这里，玩游戏执行处理是指执行涉及耐力消耗的玩游戏的处理。此外，基于时间的恢复处理是指随着时间的经过而恢复耐力的处理。此外，超恢复处理是指根据玩家对恢复物品等的选择而以超出基于时间的耐力恢复的上限值的方式执行基于时间的耐力恢复、并且消耗游戏内货币或恢复物品等作为恢复的代价的处理。
[0094]
在终端3处，如图3所示，在执行玩游戏执行处理、基于时间的恢复处理和超恢复处理的情况下，cpu 31用作用户操作接受单元311、游戏运行单元312、通知控制单元313和通知预约单元314。此外，在存储单元38的部分存储区域中设置游戏运行数据存储单元381。
[0095]
用户操作接受单元311是从玩家接受与游戏有关的操作的单元。用户操作接受单元311通过输入单元36接受由玩家执行的与游戏有关的操作。然后，用户操作接受单元311将所接受的操作的内容输出到游戏运行单元312。
[0096]
游戏运行单元312是执行用于运行游戏的处理的单元。游戏运行单元312基于包括在游戏运行数据存储单元381中的游戏软件和从用户操作接受单元311输入的玩家操作的
内容来运行游戏。
[0097]
此外，随着游戏运行，游戏运行单元312执行用于根据包括在游戏运行数据存储单元381中的图像数据生成游戏图像、并且在连接到输出单元37的显示器上显示所生成的图像的控制处理。类似地，随着游戏运行，游戏运行单元212执行用于根据包括在游戏运行数据存储单元381中的音乐数据和音频数据生成游戏音乐和音频、并且从连接到输出单元37的扬声器输出所生成的音乐和音频的控制处理。
[0098]
在本发明的第一实施例中，在服务器1处管理由游戏运行单元312运行的游戏中的预定参数。例如，在服务器1处管理诸如游戏中的耐力和游戏内货币等的参数。因此，在游戏中发生涉及这些预定参数的改变的处理(即，涉及参数值增大或减小的处理)的情况下，游戏运行单元312与服务器1进行通信以更新由服务器1管理的参数。然后，游戏运行单元212从服务器1接收更新后的参数，并根据更新后的参数继续运行游戏。
[0099]
例如，诸如玩游戏执行处理、基于时间的恢复处理和超恢复处理等的处理是涉及预定参数的改变的处理。因此，在发生这些类型的处理的情况下，游戏运行单元312与服务器1进行通信以更新参数。稍后将描述这些各种的处理的细节。
[0100]
由游戏运行单元312运行的游戏可以是通过消耗诸如耐力等的某种成本来执行玩游戏的任何游戏，并且关于游戏内容、游戏种类等没有特别限制。即，本实施例可应用于任何游戏。
[0101]
游戏运行单元312通过使用通信单元39来进行与服务器1的通信，通信单元39是终端3侧的发送/接收部件。注意，尽管如图1所示那样用于实现通信的网络2存在于终端3和服务器1之间，但在图3中未示出网络2。
[0102]
通知控制单元313是在连接到输出单元37的显示器等的通知画面上以预定定时(预设定时)执行推送通知的显示的单元。通知控制单元313可以在通知预约单元314预约的时间到来时在通知画面上显示推送通知，这将稍后描述。此外，当从服务器1接收到推送通知指示时，通知控制单元313可以在通知画面上显示推送通知。在终端3的通知画面上显示推送通知之后，通知控制单元313还可以在通知画面上显示用户界面，该用户界面使得可以基于在通知画面上接收到的玩家指示的内容来选择是激活游戏app还是向服务器1发送超恢复指示。如先前所述，超恢复指示包括基于时间的恢复的持续时间或基于时间的恢复中的恢复量的指示。
[0103]
通知预约单元314是以预定定时预约用于执行推送通知的时间的单元。通知预约单元314可以基于游戏正运行期间的预定定时的耐力量，来计算耐力将通过基于时间的恢复而被完全恢复到基于时间的耐力恢复的上限值的时间，并且可以预约推送通知的时间。例如，当执行在游戏中消耗耐力的操作时，通知预约单元314可以基于消耗后的耐力量来计算耐力将通过基于时间的恢复而被完全恢复到基于时间的耐力恢复的上限值的时间，并且可以预约该时间。
[0104]
此外，也可以在关闭游戏app时，通知预约单元314基于关闭时的耐力量来计算耐力将通过基于时间的恢复而被完全恢复到基于时间的耐力恢复的上限值的时间，并且可以预约执行推送通知的时间。由通知预约单元314执行的用于完全恢复的时间的计算和用于执行推送通知的时间的预约的定时不限于当在游戏中执行消耗耐力的操作时和当关闭游戏app时，并且可以基于在游戏app正运行期间的预定定时的耐力量来执行计算和预约。
[0105]
此外，通知预约单元314还可以检测到耐力通过基于时间的恢复已经完全恢复到基于时间的耐力恢复的上限值，并且可以基于该检测来预约推送通知的时间。例如，通知预约单元314可以进行预约，使得将在从该检测起的预定时间(例如，“一分钟”)内执行推送通知。
[0106]
游戏运行数据存储单元381是存储供游戏运行单元312运行游戏所需的各种数据的单元。用于运行游戏的各种数据是指例如构成用于执行游戏的程序的游戏软件、用于生成游戏图像等的图像数据以及音乐数据和音频数据。注意，尽管用于运行游戏的各种数据可以仅存储在存储单元38的游戏运行数据存储单元381中，但不限于该配置，用于运行游戏的各种数据可以存储在诸如可移动介质等的外部记录介质中，并且可以由诸如驱动器等的读取装置适当地读取。
[0107]
在服务器1处，在执行玩游戏执行处理、基于时间的恢复处理和超恢复处理的情况下，如图3所示，cpu 11用作可玩性判断单元111、游戏进行单元112、基于时间的恢复单元113、超恢复单元114和收费单元115。此外，参数存储单元181和物品信息存储单元182被设置在存储单元18的部分区域中。
[0108]
可玩性判断单元111是基于以游戏的进行作为交换而消耗的耐力来判断是否可以执行玩游戏的单元。可玩性判断单元111通过作为服务器1侧的发送/接收部件的通信单元19从终端3接收玩游戏请求，并且基于是否存在玩游戏所需的耐力量来判断是否可以根据请求执行玩游戏。
[0109]
游戏进行单元112是主要执行玩游戏执行处理的单元。在从终端3的游戏运行单元312接收到对于涉及耐力消耗的玩游戏的执行请求时，游戏进行单元112参考耐力值，该耐力值是存储在参数存储单元181中的参数之一。
[0110]
在存在执行玩游戏所需的耐力量的情况下，游戏进行单元112通过将耐力值减小执行玩游戏所需的量来更新存储在参数存储单元181中的耐力值。另外，作为对玩游戏的执行请求的响应，游戏进行单元112向终端3的游戏运行单元312发送用于执行玩游戏的指示和更新后的耐力值。在接收到该响应时，游戏运行单元312更新正由游戏运行单元312运行的游戏中的耐力值，并执行玩游戏。
[0111]
另一方面，在不存在执行玩游戏所需的耐力量的情况下，作为对玩游戏的执行请求的响应，游戏进行单元112向终端3的游戏运行单元312发送用于禁止玩游戏的执行的指示和用于显示用于选择恢复物品的画面(下文称为“恢复物品选择画面”)的指示。在接收到该响应时，游戏运行单元312代替执行玩游戏而显示恢复物品选择画面。该画面包括指示耐力不足以执行玩游戏的消息和允许玩家执行恢复物品选择的用户界面等。
[0112]
根据玩游戏的内容确定针对玩游戏的减少的耐力量(即，消耗的耐力量)。例如，根据玩游戏的难度或重要度来确定量。此外，针对玩游戏减少的耐力量可以在各玩游戏之间是一致的，但是也可以在各玩游戏之间不同。
[0113]
例如，对于具有比其它玩游戏更高的难度或重要度的玩游戏，与其它玩游戏相比，针对玩游戏减少的耐力量可以更多。另一方面，例如，对于具有比其它玩游戏更低的难度或重要度的玩游戏，与其它玩游戏相比，针对玩游戏减少的耐力量可以更少。
[0114]
基于时间的恢复单元113是主要执行基于时间的恢复处理的单元。如先前所述，基于时间的恢复处理是指随着时间的经过而恢复耐力的处理。超恢复单元114是主要执行超
恢复处理的单元。如先前所述，超恢复处理是指根据玩家对恢复物品等的选择而以超出基于时间的耐力恢复的上限值的方式执行基于时间的耐力恢复、并且消耗游戏内货币或恢复物品等作为恢复的代价的处理。
[0115]
稍后将参考图6描述基于时间的恢复处理中的具体处理和基于时间的恢复单元113的用于执行该处理的具体操作。稍后将参考图7描述超恢复处理中的具体处理和超恢复单元114用于执行该处理的具体操作。
[0116]
收费单元115是响应于玩家对代价的支付而执行用于增加游戏内货币的处理的单元，游戏内货币是存储在参数存储单元181中的参数之一。玩家对代价的支付例如通过利用信用卡的现金结算或通过电子货币的结算来实现。
[0117]
在从玩家接收到涉及玩家支付代价的用于购买游戏内货币的操作时，终端3的游戏运行单元312将操作的内容发送到收费单元115。在接收到操作的内容时，收费单元115执行用于执行代价支付的处理。用于执行代价支付的处理例如通过收费单元115与执行用于执行信用卡结算的认证的服务器或管理电子货币的服务器进行通信来实现。
[0118]
此外，除了用于执行代价支付的处理之外，收费单元115还执行用于根据支付金额增加存储在参数存储单元181中的游戏内货币的处理。例如，在以虚拟币的形式管理游戏内货币的游戏的情况下，收费单元115执行用于增加币的数量的处理。
[0119]
尽管如先前所述，增加游戏内货币的方法可以只限于涉及支付代价的方法，但是另外还可以允许通过其它方法增加游戏内货币。例如，可以允许通过使用游戏中玩家之间的通信、游戏中预定事件的完成等作为触发来增加游戏内货币。
[0120]
参数存储单元181是存储由终端3的游戏运行单元312运行的游戏中的参数的单元。存储在参数存储单元181中的参数的示例包括由游戏运行单元312运行的游戏中的耐力和游戏内货币。
[0121]
注意，在服务器1侧的参数存储单元181和终端3侧的游戏运行数据存储单元381中管理耐力值(耐力量)。类似地，还在服务器1和终端3这两者处管理用作基于时间的恢复的基准的“时间”。
[0122]
物品信息存储单元182是存储各种恢复物品的单元，恢复物品用于在超恢复处理中以超出基于时间的耐力恢复的上限值的方式执行基于时间的耐力恢复。例如，可以通过消耗利用支付获得的游戏内货币来获取恢复物品。恢复物品包括在超恢复处理中指示基于时间的恢复的持续时间的物品和指示基于时间的恢复中的恢复量的物品。
[0123]
(基于时间的恢复处理和超恢复处理)
[0124]
将参考图3、以及图4所示的基于时间的恢复处理和超恢复处理的示意图，来描述基于时间的恢复处理和超恢复处理。图4是示出根据本发明的第一实施例的随着时间的经过而恢复耐力的基于时间的恢复处理和超恢复处理的示例的示意图。如图4的(a)部分所示，利用基于时间的恢复处理，可以每预定时间(例如，“每五分钟”)将耐力值增加预定值(例如，“1”)。利用基于时间的恢复处理，图3所示的基于时间的恢复单元113通过以预设间隔增加存储在参数存储单元181中的耐力值来恢复耐力。随着时间的经过而执行基于时间的恢复处理，而无需任何特别的玩家操作。
[0125]
在耐力值大于基于时间的恢复的上限值(例如，“100”)的情况下，基于时间的恢复单元113不执行基于时间的恢复处理。如先前所述，对基于时间的恢复处理存在限制。此外，
基于时间的恢复单元113将更新后的耐力值发送到终端3的游戏运行单元312。游戏运行单元312基于接收到的更新后的耐力值来更新游戏运行单元312正在运行的游戏中的耐力值。
[0126]
如图4的(b)部分所示，在基于时间的恢复处理中达到基于时间的耐力恢复的上限值的情况下，在终端3处给出推送通知。终端3可以利用通知画面上的推送通知向玩家显示指示耐力完全恢复的消息。例如，终端3的通知画面由触摸屏构成，通知画面能够用作输入单元36和输出单元37。
[0127]
如图4的(c)部分所示，超恢复处理允许以超出基于时间的耐力恢复的上限值的方式进行基于时间的耐力恢复。例如，根据通过终端3的通知画面接受的来自玩家的超恢复指示(例如，“继续超恢复直到四小时后为止”)，超恢复处理允许以超出基于时间的耐力恢复的上限值的方式进行基于时间的耐力恢复。在图4的(c)部分所示的示例中，假设根据诸如“继续超恢复直到四小时后为止”等的超恢复指示，每5分钟恢复1个耐力值，可以超出基于时间的耐力恢复的上限值“100”地执行基于时间的耐力恢复以达到最大值“148”(＝4小时(240分钟)/5分钟)。
[0128]
还可以针对通过超恢复的基于时间的恢复来定义界限值。例如，在图4的(c)部分所示的示例中，可以将“999”设置为通过超恢复的基于时间的恢复的界限值(下文称为“超恢复上限值”)，这禁止接受超出超恢复上限值的超恢复指示。
[0129]
(玩游戏执行处理)
[0130]
图5是说明由图2所示并具有图3所示的功能配置的服务器和终端执行的玩游戏执行处理的流程的序列图。在由玩家执行用于请求执行涉及耐力消耗的玩游戏的操作的情况下，执行玩游戏执行处理。
[0131]
在步骤s11中，用户操作接受单元311根据玩家执行的请求执行玩游戏的操作来向服务器1发送玩游戏请求。
[0132]
在步骤s12中，可玩性判断单元111参考作为存储在参数存储单元181中的参数之一的耐力值来判断是否存在执行玩游戏所需的耐力量。
[0133]
首先，将描述执行玩游戏所需的耐力量的情况。在存在执行玩游戏所需的耐力量的情况下，步骤s12中的判断结果为“是”，并且处理进行到步骤s13。在步骤s13中，游戏进行单元112通过将存储在参数存储单元181中的耐力值减少执行玩游戏所需的量来更新耐力值。在这种情况下，在步骤s14中，作为对玩游戏的执行请求的响应，游戏进行单元112向终端3的游戏运行单元312发送用于执行玩游戏的指示和更新后的耐力值。此外，在步骤s15中，游戏运行单元312根据响应执行处理。具体地，根据响应，游戏运行单元312更新由游戏运行单元312正运行的游戏中的耐力值并执行玩游戏。然后，玩游戏执行处理完成。
[0134]
接下来，将描述不存在执行玩游戏所需的耐力量的情况。在不存在执行玩游戏所需的耐力量的情况下，步骤s112中的判断结果为“否”，并且处理进行到步骤s14。在这种情况下，在步骤s14中，作为对玩游戏的执行请求的响应，游戏进行单元112向终端3的游戏运行单元312发送用于禁止玩游戏的执行的指示和用于显示恢复物品选择画面的指示。此外，在步骤s15中，游戏运行单元312根据响应执行处理。具体地，根据响应，游戏运行单元312代替执行玩游戏而显示恢复物品选择画面。恢复物品选择画面包括指示耐力不足以执行玩游戏的消息和允许玩家执行恢复物品选择的用户界面。
[0135]
(基于时间的恢复处理)
[0136]
接下来，将参考图6描述基于时间的恢复处理。图6是说明由图2所示并具有图3所示的功能配置的服务器和终端执行的基于时间的恢复处理的流程的序列图。基于时间的恢复处理被不断地执行，而无需任何特别的玩家操作。
[0137]
在步骤s21中，在存储在参数存储单元181中的耐力值增加预定值(例如，“1”)的情况下，基于时间的恢复单元113判断耐力值是否超出基于时间的恢复的上限值。在超出基于时间的恢复的上限值的情况下，步骤s21中的判断结果为“是”，并且重复执行步骤s21中的判断。另一方面，在未超出基于时间的恢复的上限值的情况下，处理进行到s22。
[0138]
在步骤s22中，基于时间的恢复单元113判断从通过上一次基于时间的恢复处理而恢复耐力或者从为了执行上一次玩游戏而消耗耐力起、是否经过了预定时间(例如，“5分钟”)。在尚未经过预定时间的情况下，步骤s22中的判断结果为“否”，并且处理返回到步骤s21而不增加耐力值。另一方面，在经过了预定时间的情况下，步骤s22中的判断结果为“是”，并且处理进行到s23。
[0139]
在步骤s23中，基于时间的恢复单元113通过将耐力值增加预定值(例如，“1”)来更新存储在参数存储单元181中的耐力值，从而实现基于时间的恢复处理。
[0140]
在步骤s24中，基于时间的恢复单元113将更新后的耐力值发送到终端3的游戏运行单元312。游戏运行单元312基于接收到的更新后的耐力值来更新游戏运行单元312正在运行的游戏中的耐力值。
[0141]
注意，如先前所述，基于时间的恢复处理被不断地执行，而无需任何特别的玩家操作。然而，如果由于基于时间的恢复处理而导致的耐力值的更新发生在玩家不期望增加耐力的定时，则玩家可能会困惑。因此，该配置可以使得，例如，当正显示允许玩家执行恢复物品选择的用户界面时(即玩家不期望增加耐力的定时)，执行由于基于时间的恢复处理而导致的对耐力值的更新，但是不改变显示在用户界面上的耐力值。
[0142]
(超恢复处理)
[0143]
接下来，将参考图7描述超恢复处理。图7是说明由图2所示并具有图3所示的功能配置的服务器和终端执行的超恢复处理的流程的序列图。基于时间的恢复处理不断地被执行，而无需任何特别的玩家操作，直到步骤s35中的判断结果为“是”为止。
[0144]
在步骤s31中，服务器1利用游戏进行单元112或基于时间的恢复单元113，与玩游戏执行处理或基于时间的恢复处理相关联地更新耐力值。在步骤s32中，服务器1利用游戏进行单元112或基于时间的恢复单元113将更新后的耐力值发送给通知预约单元314。
[0145]
在步骤s33中，通知预约单元314计算当前的耐力值将被恢复到基于时间的恢复的上限值的时间。例如，当执行在游戏中消耗耐力的操作等时，通知预约单元314基于消耗后的耐力量来计算耐力将通过基于时间的恢复被完全恢复到基于时间的恢复的上限值的时间。在图4的(a)部分所示的基于时间的恢复处理的示例中，在当前的耐力值为“70”时，假设通过基于时间的耐力恢复，耐力每5分钟恢复“1”，则通知预约单元314将耐力将完全恢复到基于时间的恢复的上限值“100”的时间计算为150分钟(＝(100
‑
70)
×
5)。在步骤s34中，通知预约单元314基于计算出的时间预约用于执行推送通知的时间(一天中的时间)。在上述示例中，通知预约单元314预约150分钟之后的时间，以在150分钟之后执行推送通知。在已预约了推送通知的时间并且将要预约新计算出的时间的情况下，通知预约单元314可以丢弃已经预约的时间并且可以预约新计算出的时间。注意，在已经预约的时间和新计算出的
时间相同的情况下，通知预约单元314可以维持已经预约的时间。
[0146]
在步骤s35中，通知控制单元313判断预约时间是否已到来。在预约时间尚未到来的情况下，步骤s35中的判断结果为“否”，并且重复执行步骤s35中的判断。另一方面，在预约时间已到来的情况下，步骤s35中的判断结果为“是”，并且处理进行到步骤s36。在步骤s36中，通知控制单元313在通知画面上显示推送通知。图8中示出了通知画面的示例。
[0147]
图8是示出根据本发明的第一实施例的示例推送通知画面的图。例如，在显示推送通知的内容的诸如智能电话等的终端装置的通知画面上，显示表示“耐力完全恢复”的消息。此外，图9是示出游戏app请求针对推送通知的许可的示例画面的图。在终端3中安装了游戏app之后第一次执行推送通知的情况下，显示图9所示的对话框，这允许玩家选择是否允许推送通知。玩家可以选择(点击)“允许”以允许推送通知，并且可以选择“不允许”以不允许推送通知。可替代地，终端3可以被配置为在正运行游戏app时不执行推送通知。
[0148]
此外，通知控制单元313可以在通知画面上显示图形用户界面(gui)，图形用户界面用于从玩家接受用于以超出基于时间的耐力恢复的上限值的方式进行基于时间的耐力恢复的超恢复指示。例如，当玩家在图8所示的通知画面上通过安装在终端装置中的操作系统(os)所规定的方法(例如，长按或滑动)对通知画面中显示的消息部分执行操作时，如图10所示那样，显示用于从玩家接受超恢复指示的gui(例如，反应按钮)。即，如先前所述，通知控制单元313可以在通知画面上显示用于选择是启动游戏app还是向服务器1发送超恢复指示的用户界面。
[0149]
图10是示出根据本发明的第一实施例的用于在推送通知画面上接受超恢复指示的用户界面的示例的图。在图10所示的示例中，在通知画面上显示诸如“继续超恢复直到两小时后为止(消耗一个物品)”、“继续超恢复直到四小时后为止(消耗两个物品)”和“什么都不做”等的反应按钮。玩家可以通过选择反应按钮之一在推送通知画面上输入诸如超恢复或什么也不做等的指示。注意，反应按钮不限于以上列出的那些，并且其示例包括使得能够在通知画面上指定基于时间的恢复的持续时间的超恢复指示、使得能够在通知画面上指定通过基于时间的恢复的恢复量的超恢复指示、以及用于在通知画面上启动游戏app的指示。
[0150]
在步骤s37中，用户操作接受单元311判断是否已经接受作为来自玩家的用户输入的超恢复指示。在尚未接受超恢复指示的情况下，步骤s37中的判断结果为“否”，并且超恢复处理终止。例如，在图10所示的示例中，在玩家从显示在通知画面上的反应按钮中选择(点击)“什么也不做”的情况下，用户操作接受单元311可以判断为尚未接受超恢复指示。在已经接受了超恢复指示的情况下，步骤s37中的判断结果为“是”，并且处理进行到步骤s38。例如，在图10所示的示例中，在玩家在通知画面上显示的反应按钮中选择(点击)“继续超恢复直到两小时后为止(消耗一个物品)”或“继续超恢复直到四小时后为止(消耗两个物品)”的情况下，用户操作接受单元311可以判断为已接受超恢复指示。
[0151]
在步骤s38中，用户操作接受单元311将超恢复指示从玩家发送到服务器1的超恢复单元114。在步骤s39中，当接受到超恢复指示时，超恢复单元114在超恢复指示中所包括的基于时间的恢复的持续时间期间、或者直到耐力值达到超恢复指示中所包括的通过基于时间的恢复的恢复量为止，执行基于时间的耐力恢复处理。超恢复单元114可以基于来自终端3的超恢复指示，通过基于时间的恢复，以超出基于时间的耐力恢复的上限值的方式恢复耐力。
[0152]
在图7所示的超恢复处理的示例中，在从服务器1接收到更新后的耐力值之后，终端3的通知预约单元314执行步骤s33和步骤s34中的处理。即，在执行了在游戏中消耗耐力的操作的情况下，通知预约单元314可以基于消耗后的耐力量，计算耐力通过基于时间的恢复而将被完全恢复到基于时间的恢复的上限值的时间，并且可以预约该时间。此外，超恢复处理不限于图7所示的示例。例如，当关闭游戏app时，通知预约单元314还可以基于关闭时的耐力量来计算耐力将通过基于时间的恢复而被完全恢复到基于时间的恢复的上限值的时间，并且可以预约该时间。此外，通知预约单元314还可以检测到耐力通过基于时间的恢复已经被完全恢复到基于时间的恢复的上限值，并且可以基于该检测预约推送通知的时间。此外，通知预约单元314还可以基于游戏正运行期间的预定定时的耐力量来计算耐力将通过基于时间的恢复而被完全恢复到基于时间的恢复的上限值的时间，并且可以预约推送通知的时间。
[0153]
(功能配置)
[0154]
将参考图11描述本发明的第二实施例。图11是示出根据本发明的第二实施例的信息处理服务器和终端的功能配置的示例的示意性配置图(框图)。图11是示出根据本发明的第二实施例的服务器和终端的功能配置的示例的示意性配置图(框图)。图11是示出在图2所示的服务器1和终端3的功能配置中用于执行诸如玩游戏执行处理、基于时间的恢复处理和超恢复处理等的处理的功能配置的框图。在图11所示的第二实施例中，具有与图3所示的第一实施例中的那些附图标记相同的附图标记的部分具有相同的功能配置，并且因此将省略其描述。此外，第一实施例和第二实施例的功能配置可以彼此组合为一个实施例。
[0155]
在服务器1处，在执行玩游戏执行处理、基于时间的恢复处理和超恢复处理的情况下，如图11所示，cpu 11用作可玩性判断单元111、游戏进行单元112、基于时间的恢复单元113、超恢复单元114、收费单元115和推送通知指示单元116。此外，在存储单元18的部分区域中设置参数存储单元181和物品信息存储单元182。
[0156]
推送通知指示单元116是在耐力恢复时的预定定时向终端3发送推送通知指示的单元。推送通知指示单元116可以基于游戏正运行期间的预定定时的耐力量，来计算耐力将通过基于时间的恢复而被完全恢复到基于时间的耐力恢复的上限值的时间，并且可以在时间到来时向终端3发送推送通知指示。例如，当执行在游戏中消耗耐力的操作(玩游戏执行处理)时，推送通知指示单元116可以基于消耗后的耐力量来计算耐力将通过基于时间的恢复而被完全恢复到基于时间的耐力恢复的上限值的时间，并且可以在时间到来时向终端3发送推送通知指示。
[0157]
此外，推送通知指示单元116也可以在终端3处关闭游戏app时，基于关闭时的耐力量来计算耐力将通过基于时间的恢复而被完全恢复到基于时间的耐力恢复的上限值的时间，并且可以在时间到来时向终端3发送推送通知指示。
[0158]
此外，推送通知指示单元116还可以检测到耐力通过基于时间的恢复已经完全恢复到基于时间的耐力恢复的上限值，并且可以基于该检测向终端3发送推送通知指示。
[0159]
在图11所示的第二实施例中，由于推送通知指示单元116设置在服务器1侧，因此不需要如图3所示的第一实施例那样在终端3侧设置通知预约单元314。终端3的通知控制单元313可以在接收到从推送通知指示单元116发送的推送通知指示时，在通知画面上显示推送通知。通知画面的示例如图8所示。已经描述了图8中所示的通知画面的细节。
[0160]
(超恢复处理)
[0161]
将参考图12描述第二实施例中的超恢复处理。图12示出根据本发明的第二实施例的推送通知处理的示例。在步骤s51中，推送通知指示单元116计算当前的耐力值将被恢复到基于时间的恢复的上限值的时间。例如，当执行在游戏中消耗耐力的操作等时，推送通知指示单元116基于消耗后的耐力量来计算耐力将通过基于时间的恢复被完全恢复到基于时间的恢复的上限值的时间。在图4的(a)部分所示的基于时间的恢复处理的示例中，在当前的耐力值为“70”时，假设通过基于时间的耐力恢复，耐力每5分钟恢复“1”，则推送通知指示单元116将耐力将完全恢复到基于时间的恢复的上限值“100”的时间计算为150分钟(＝(100
‑
70)
×
5)。
[0162]
在步骤s52中，推送通知指示单元116判断在步骤s51中计算出的时间是否已到来。在时间尚未到来的情况下，步骤s52中的判断结果为“否”，并且重复执行步骤s52中的判断。另一方面，在预约时间已到来的情况下，步骤s52中的判断结果为“是”，并且处理进行到步骤s53。
[0163]
在步骤s53中，推送通知指示单元116向终端3的通知控制单元313发送推送通知指示。在接收到推送通知指示时，通知控制单元313在通知画面上显示推送通知。通知控制单元313的操作与第一实施例中的操作相同。
[0164]
(回归超恢复处理)
[0165]
关于图3所示的第一实施例和图12所示的第二实施例这两者中的超恢复处理，可以回归地应用超恢复处理，使得在经过了与超恢复指示相对应的基于时间的恢复的持续时间之后(例如，在指定“继续超恢复直到四小时后为止”的超恢复指示的情况下，在经过四小时之后)、或者在满足通过与超恢复指示相对应的基于时间的恢复的恢复量之后(例如，在指定“超恢复到150的耐力值”的超恢复指示的情况下，在耐力值达到150之后)，再次执行超恢复处理，从而在终端3上再次显示用于推送通知的通知画面(例如，参见图8和10)以接受来自玩家的指示
[0166]
在回归地应用超恢复处理的情况下，在本发明的第一实施例中，终端3的通知预约单元314可以基于超恢复指示中所包括的时间(例如，在指定“继续超恢复直到四小时后为止”的超恢复指示的情况下，在四小时后)来预约用于执行推送通知的时间(一天中的时间)。此外，在包括恢复量的超恢复指示的情况下，通知预约单元314可以预约耐力将达到恢复量的时间(例如，在指定“超恢复到150的耐力值”的超恢复指示的情况下，假设基于时间的耐力恢复的上限值为“100”，则耐力将通过基于时间的恢复而被恢复了50的时间)。
[0167]
此外，可以单独定义回归地应用超恢复处理的上限次数n。例如，在服务器1的参数存储单元181中存储和管理超恢复处理的上限值(下文称为“超恢复上限值”)，超恢复单元114可以判断超恢复处理已被执行的次数是否超出超恢复上限值，并且如果超恢复处理已被执行的次数未超出超恢复上限值，则执行超恢复处理。在超恢复处理已被执行的次数超出超恢复上限值的情况下，终端3在画面上显示指示无法执行超恢复的消息。此外，例如，在当前耐力值已达到图4中的(c)部分所示的超恢复上限值(例如，“999”)的情况下，使超恢复单元114不能接受超恢复指示。在这种情况下，终端3在画面上显示指示耐力值已达到超恢复上限值的消息。可替代地，服务器1的超恢复单元114可以被配置为不接受如果从当前耐力值执行超恢复处理则将超出超恢复上限值的超恢复指示。例如，在终端3的通知画面(参
见图10)上不显示将超出超恢复上限值的超恢复指示，使得玩家无法选择超恢复指示。
[0168]
(自动玩)
[0169]
在分别如图3和11所示的本发明的第一实施例和第二实施例中，当接收到利用推送通知的通知时，在终端3上显示诸如图8所示的通知画面等的通知画面，以及对在通知画面上的消息执行滑动等操作时，显示诸如图10所示的画面等的用于接受超恢复指示的画面。作为本发明的变形例，还通过发出自动玩指示来代替超恢复指示，即使在玩家没有时间激活游戏app并玩游戏时，玩家将能够仅通过对推送通知画面执行操作而更有利地执行玩游戏，这使得能够实现本发明的目的。这还可以激励玩家开启从游戏app接收推送通知的功能。
[0170]
在从玩家接受自动玩指示的终端3处，可以代替图10所示的画面而显示图13所示的画面。图13是示出用于接受可以被显示在根据本发明的第一实施例和第二实施例的终端的通知画面上的自动玩指示的用户界面的示例的图。这里，自动玩处理是指基于自动玩指示执行玩游戏执行处理的处理。在图13所示的示例中，在通知画面上显示诸如“执行自动玩(消耗所有耐力)”、“执行自动玩一次(消耗一个物品)”、“执行自动玩两次(消耗两个物品)”和“什么也不做”等的反应按钮。玩家可以通过选择反应按钮之一来在推送通知画面上输入诸如自动玩或什么也不做等的指示。例如，如果玩家选择“执行自动玩(消耗所有耐力)”，则重复玩游戏执行处理，直到玩游戏所需的耐力变得不可用为止。在游戏所需的耐力不可用的情况下，无需在通知画面上显示“执行自动玩(消耗所有耐力)”。注意，反应按钮不限于以上列出的那些，并且其示例包括用于在通知画面上指定执行自动玩三次或更多次的反应按钮和用于在通知画面上指示游戏app的启动的反应按钮。
[0171]
在本发明的变形例中，预先确定可以通过推送通知执行自动玩的游戏。一方面，可以通过推送通知来玩的游戏可以是由游戏开发者预先设置的游戏(下文称为“自动玩设置游戏”)。另一方面，可以允许玩家任意地选择多个选项之一并设置该选项。
[0172]
上述的游戏可以是能够在消耗耐力时被执行的任何游戏，诸如战斗游戏、益智游戏、弹球游戏、拼图游戏、城镇创建游戏或角色欣赏游戏等，并且对游戏的种类没有限制。
[0173]
此外，可以针对多个游戏单独设置难度，使得针对具有更高难度的游戏将消耗更多的耐力量。可替代地，可以进行设置使得针对更难的游戏，玩家将被给予更好的奖励(可获取的更多的经验值或更大量的游戏内货币、可获取的更高稀有度的物品等)。
[0174]
代替在诸如图10所示的通知画面等的通知画面上选择超恢复指示，玩家通过在诸如图13所示的通知画面等的通知画面上选择自动玩指示来发出用于在自动玩设置游戏中执行自动玩的指示。在自动玩处理中，终端3的用户操作接受单元311接受自动玩指示，并且用户操作接受单元311将自动玩指示发送到服务器1的游戏处理单元112。游戏处理单元112可以根据自动玩指示执行玩游戏执行处理。即，基于来自玩家的指示，从终端3向服务器1发出用于玩游戏的指示。
[0175]
在服务器1处，基于来自终端3的自动玩指示来执行自动玩设置游戏。与玩家相关联的耐力通过自动玩处理被消耗针对游戏设置的量，并且玩家可以获得预定奖励。
[0176]
一方面，在服务器1处，在自动玩设置游戏中自动执行玩游戏执行处理，而无需接受来自玩家的自动玩指示。在执行时，在游戏中执行预定自动处理。基于通过自动处理获得的游戏执行结果，玩家被给予预定奖励(经验值、游戏内货币或物品等)。
[0177]
此外，另一方面，可以不在基于服务器1处的自动玩来执行玩游戏执行处理的情况下，仅执行消耗耐力和获得奖励的处理。在这种情况下，不在服务器1处执行自动游戏处理。此外，可以通过预定抽选处理来确定奖励的内容。利用这种配置，可以在给予玩家与消耗的耐力相对应的奖励的情况下，不在服务器1处执行自动游戏处理，这用于减少服务器1上的处理负荷。
[0178]
利用根据本发明的信息系统等，通过采用第一实施例和第二实施例的配置以及自动玩的变形例，在终端3的画面上显示的指示耐力完全恢复的通知用作为对没有很多时间来玩游戏的玩家有利的通知，这是因为能够继续基于时间的耐力恢复以稍后玩游戏、或者通过执行自动玩来消耗通过基于时间的恢复而被完全恢复的耐力并继续基于时间的恢复。即，利用根据本发明的信息处理系统等的通知使得能够激励用户积极地开启从游戏app接收推送通知的功能。
[0179]
产业上的可利用性
[0180]
根据本发明的信息处理系统等可应用于在客户端
‑
服务器系统上运行的移动端游戏中的以消耗耐力作为交换而进行的游戏。
[0181]
附图标记说明
[0182]
1：服务器
[0183]
2：网络
[0184]
3：终端
[0185]
11(31)：cpu
[0186]
13(33)：存储器
[0187]
14(34)：总线
[0188]
15(35)：输入/输出接口
[0189]
16(36)：输入单元
[0190]
17(37)：输出单元
[0191]
18(38)：存储单元
[0192]
19(39)：通信单元
[0193]
100：信息处理系统
[0194]
111：可玩性判断单元
[0195]
112：游戏进行单元
[0196]
113：基于时间的恢复单元
[0197]
114：超恢复单元
[0198]
115：收费单元
[0199]
116：推送通知指示单元
[0200]
181：参数存储单元
[0201]
182：物品信息存储单元
[0202]
311：用户操作接受单元
[0203]
312：游戏运行单元
[0204]
313：通知控制单元
[0205]
314：通知预约单元
[0206]
381：游戏运行数据存储单元。