CN102999570A - 移动设备中应用程序关键数据的离线控制方法和系统 - Google Patents

Abstract

本发明公开了一种在离线状态下，控制游戏客户端所获取的应用程序关键数据不被随意共享的方法。通过该方法，游戏软件可以让游戏用户在离线状态下继续进行游戏活动并获得应用程序关键数据。在本发明所述方法的控制下，游戏用户在离线状态下获得的应用程序关键数据不能被随意地共享给其它游戏用户，而游戏开发者则可藉此控制应用程序关键数据。

Description

移动设备中应用程序关键数据的离线控制方法和系统

技术领域

本发明涉及移动互联设备的数据安全领域，特别涉及一种应用程序关键数据的离线控制方法和系统。

背景技术

当前，面向移动互联设备的游戏开发是一个活跃的领域。为了防止游戏程序被随意复制使用，游戏开发商有时会将一些与游戏进程相关的资源（比如虚拟道具、虚拟金币之类的应用程序关键数据）存放在服务器上，并要求游戏客户端登录网络进行游戏，以此来加强对非法用户的限制。但是，在现有的网络条件下，移动设备并不总是能连接到或流畅地连接到游戏服务器，无法访问网络服务器上的游戏资源的情况会时有发生，这将直接地影响到游戏用户的游戏体验。在这种情况下，如果能将一部分游戏资源存放在移动设备中并在离线状态下随着游戏进程逐步地提供给游戏用户使用将是一种解决办法。不过，随之而来的一个新问题是——如何防止用户将其在游戏中获得的这些资源随意复制给其他用户使用。

发明内容

为了支持离线支付应用程序关键数据，并防止游戏用户随意将其在游戏中获得的应用程序关键数据共享给其它游戏用户使用，本发明设计了一种应用程序关键数据的表示方法及其使用方式。

 

附图说明

图1是本发明的系统构架模块示意图； 图2是本发明的一种应用程序关键数据存储格式； 图3是本发明中签发操作的工作流程图； 图4是本发明的实施例一中的应用程序关键数据支付环节的流程图； 图5是本发明的实施例二中的应用程序关键数据支付环节的流程图。

具体实施方式

为使本发明所述内容更加清楚，下面结合附图和实施例对本发明做进一步的说明。

本发明公开了一种管理应用程序关键数据的方法，可用于实现在离线状态下的应用程序关键数据的发放功能，并能防止用户随意将其在游戏中获得的应用程序关键数据共享给其他用户。这种方法略加改动也可用于管理游戏中其它类型的虚拟道具。

另外，这种计数值的改变应该也可以用于其他类型应用程序中关键数据的管理和控制。

所述应用程序关键数据的表示方法包括：应用程序关键数据体现为一个包含若干数据项的数据记录，其中至少包含有计数幅度信息、所有者标识信息和数字签名。必要时，还可包含游戏标识信息。在数据结构上，每个应用程序关键数据的构成可以表示为：

[游戏标识]<面值><用户标识><数字签名>

其中：方括号“[ ]”和尖括号“< >”不是数据的组成部分而只是语法标记；方括号表示被包括的数据项是可选项，尖括号表示被包括的数据项是必需项。

所述计数幅度“面值”也可以称为“计数幅度信息”，是指应用程序关键数据的计数幅度，是一个数值。应用程序关键数据的计数幅度只能在预先设定的一个或几个特定的数值中取值。例如：如果预先设定只有“1元”这一种计数幅度，则所有应用程序关键数据都只能是1元计数幅度的。如果预先设置有“1元、10元、100元、500元”四种计数幅度，则一个应用程序关键数据的计数幅度可以是且只能是这四种计数幅度中的一种。

所述“所有者标识信息”是指在游戏开发商的一个游戏中能用来唯一地代表某个游戏用户的数字或字符串。

所述“数字签名”是指用来防止计数幅度信息、所有者标识信息被篡改的一个二进制数据项，通常是由多个字节构成的。

所述“游戏标识”是指在一个游戏开发商的一系列游戏产品中能惟一地代表某个游戏产品的数字或字符串。

所述应用程序关键数据的使用方式包括：应用程序关键数据的属性规则和实施模块。所述应用程序关键数据的属性规则包括：应用程序关键数据在使用过程中作为一个独立的对象存在，其计数幅度始终不变；应用程序关键数据在使用时要检查应用程序关键数据的有效性，如果无效则禁止使用。

所述应用程序关键数据在使用过程中作为一个独立的对象存在并且计数幅度不变是指：应用程序关键数据在使用时表现为一个包含计数幅度和所有者标识信息的数据记录，这个数据记录在发送、接收、存储、删除时都作为一个整体对待；这个数据记录中的计数幅度信息在发送、接收、存储过程中不能被修改；代表多个小计数幅度应用程序关键数据的数据记录可按其计数幅度的合计值来用于支付，但在发送、接收和存储时不能合并成一个代表大计数幅度应用程序关键数据的数据记录；一个代表大计数幅度应用程序关键数据的数据记录也不能被替换为代表多个小计数幅度应用程序关键数据的多个数据记录。

根据本发明的一个实施方式，例如在游戏应用程序的情况下，当应用程序关键数据为游戏中的虚拟金币时，在需要支付49元虚拟金币的时候，如果拥有4个10元的虚拟金币和9个1元的虚拟金币，则可以完成支付；如果只有一个50元的虚拟金币，则不能拆成4个10元和10个1元的来进行支付。

所述应用程序关键数据的支付是指：将一个或一组代表应用程序关键数据的数据记录从持有者一方发送到接收方；在支付成功后，要把这些数据记录从原来的持有者一方的存储设备中删除；在支付成功后，要在接收方的存储设备中添加这些代表应用程序关键数据的数据记录。

所述应用程序关键数据在使用时要检查其有效性是指：在使用时，接收方要检查代表应用程序关键数据的数据记录中的数字签名是否与内容匹配，如果不匹配则视为无效并禁止使用；接收方还要检查代表应用程序关键数据的数据记录中的所有者标识与预期的游戏用户的标识是否一致，否则视为无效并禁止使用。

如图1所示，所述应用程序关键数据的实施模块构成包括：一个运行在服务器端的应用程序关键数据签发模块，一个运行在移动设备中的应用程序关键数据池模块和一个运行在移动设备中的游戏客户端模块。

如图1所示，所述应用程序关键数据签发模块运行在游戏服务器中，用于在联线状态下签发一定数量的应用程序关键数据到移动设备中的应用程序关键数据池。在签发过程中，首先要由运行于移动设备中的应用程序关键数据池模块发出“签发请求”，该签发请求中应包含请求签发的应用程序关键数据的数额。根据本发明的一个实施方式，如果需要，该签发请求中还可包含游戏的唯一标识。在收到“签发请求”后，应用程序关键数据签发模块按照请求中指定的数额，同时也依照应用程序关键数据生成规则，生成代表一定数量的应用程序关键数据的数据记录，并发送到运行于移动设备中的应用程序关键数据池模块。

根据本发明的一个实施方式，所述的“应用程序关键数据生成规则”指：每次签发的应用程序关键数据应由一组具有特定计数幅度的应用程序关键数据组成，而非是单独的一个应用程序关键数据；并且，这些小额应用程序关键数据应能构成1元到签发金额之间（含），以1元为单位的，所有可能的数额。根据本发明的一个实施方式，例如：1000元的应用程序关键数据可由9个100元，9个10元，10个1元计数幅度的应用程序关键数据组成，而不应只是一个计数幅度1000元的应用程序关键数据。这样，由这些小计数幅度的应用程序关键数据可以构成1到1000之间（含），以1元为单位的所有可能的数额。根据本发明的一个实施方式，具体的计数幅度设置、拆分方法可由游戏开发商自定。

如图1所示，当代表应用程序关键数据的数据记录生成后，应用程序关键数据签发模块将把它们发送到运行于移动设备的“应用程序关键数据池模块”。根据本发明的一个实施方式，为进一步加强数据安全，可以在通讯过程中对数据进行加密。当运行于服务器的“应用程序关键数据签发模块”将所需数额的应用程序关键数据发送到运行于移动设备的“应用程序关键数据池模块”后，移动设备就可以关闭与服务器的连接，而转由应用程序关键数据池模块管理应用程序关键数据到游戏模块的发放工作。

如图1所示，本发明所述的应用程序关键数据池模块运行在移动设备中，用于：转发游戏用户要求服务器签发应用程序关键数据的请求；接收服务器签发的应用程序关键数据；在本地存储设备中存储应用程序关键数据；同时在离线状态下依照游戏进程将应用程序关键数据发放给游戏客户端模块。

所述“转发游戏用户要求服务器签发应用程序关键数据的请求”是指：当游戏用户需要服务器签发应用程序关键数据到本地以供其离线使用时，游戏用户应通过游戏提供的用户界面指定所需应用程序关键数据的数额；然后游戏程序将该数额、游戏用户标识、游戏标识发送给“应用程序关键数据池模块”，并通过后者构造一个符合服务器要求的“签发请求”给运行于服务器中的应用程序关键数据签发模块。根据本发明的一个实施方式，所述的“签发请求”至少应包含游戏用户指定的应用程序关键数据的数额、游戏用户标识。根据本发明的一个实施方式，如果需要，还可包含“游戏标识”等内容。

所述“接收服务器签发的应用程序关键数据”是指：应用程序关键数据池模块通过网络从运行于服务器上的应用程序关键数据签发模块接收代表应用程序关键数据的数据记录，并按本地存储应用程序关键数据时所需的特定格式将接收到的代表应用程序关键数据的数据记录存储到本地存储设备中。

为实现应用程序关键数据的本地离线存储，应用程序关键数据池模块可将代表应用程序关键数据的数据记录存储在本地文件或数据库中。根据本发明的一个实施方式，在存储时，应为每个代表应用程序关键数据的数据项保存应用程序关键数据计数幅度、游戏用户标识、游戏标识等内容。

为了防止数据被篡改或复用，还应保存一个数字签名和一个操作序列号。所述“数字签名”用于防止对数据的篡改。根据本发明的一个实施方式，实施时可利用常见的方法来构造数字签名，例如：先用MD5算法对所有的应用程序关键数据、操作序号计算一个数字摘要，然后用DES算法对所得到的数字摘要进行加密构成所述的“数字签名”。

所述“操作序列号”用于表示本模块执行支付操作次数，其数值在每次向游戏用户支付应用程序关键数据后都会改变；但是从应用程序关键数据签发模块接收应用程序关键数据的操作不会改变此数值；通过该序号防止游戏用户重复使用存储有应用程序关键数据数据的旧文件。

所述在离线状态下依照游戏进程将应用程序关键数据发放给游戏用户是指：在移动设备关闭了与服务器的网络连接后，游戏用户仍可继续使用游戏应用程序；游戏用户在游戏中所获得的应用程序关键数据由“应用程序关键数据池模块”进行支付。

根据本发明的一个实施方式，所述支付包括：随着游戏的进行，游戏程序在需要向游戏用户支付游戏中应用程序关键数据时，将游戏用户所获得的应用程序关键数据数额、游戏用户标识、游戏标识组成符合一定格式的支付请求发送给应用程序关键数据池模块；应用程序关键数据池模块在收到支付请求后，检查现存应用程序关键数据是否能完成支付；如果能够支付，然后计算应用什么计数幅度的应用程序关键数据来完成支付；确定要使用哪些计数幅度的应用程序关键数据后，从本地存储设备中删除这些应用程序关键数据的数据记录，然后发送支付消息给游戏程序；游戏程序在收到支付消息后，给游戏用户的虚拟账户中添加指定的应用程序关键数据记录。

在上述过程中，由于应用程序关键数据是以固定计数幅度的应用程序关键数据的形式存在的，因此要有一个计算使用何种计数幅度的应用程序关键数据及每种计数幅度使用多少的过程。如果所有应用程序关键数据只有“1元”这一种计数幅度，则计算过程很简单；如果有多种计数幅度，则需要根据具体情况来计算，通常要求各种计数幅度的应用程序关键数据的数量要能够构成1到N之间的以1元为单位的所有数额，这需要在计数幅度设计和签发过程中统一考虑。根据本发明的一个实施方式，随着应用程序关键数据的计数幅度设计的不同，在某些情况下，支付过程中可能会包含类似于日常生活中“找零”的过程。

在上述过程中所述的“支付消息”中包含有支付时所用的应用程序关键数据的计数幅度和各种计数幅度的应用程序关键数据的数量，根据本发明的一个实施方式，实施时，可以直接用一组应用程序关键数据的数据记录来表示。

本发明的游戏客户端模块运行在移动设备中，用于：向游戏用户提供操作界面用于请求服务器签发应用程序关键数据；向“应用程序关键数据池模块”发送“请求支付所获得的应用程序关键数据”的消息；从应用程序关键数据池模块接收所获得的应用程序关键数据并存储在游戏程序的存储设备中。根据本发明的一个实施方式，随着应用程序关键数据的计数幅度设计的不同，游戏客户端模块需要实现向“应用程序关键数据池模块”返还应用程序关键数据的功能，以实现“找零”的功能。

所述向游戏用户提供操作界面，用于请求签发应用程序关键数据是指：游戏开发者应提供一个操作界面，供游戏用户指定要求服务器签发的应用程序关键数据的数额；该界面在游戏程序与游戏服务器联网的情况下可以使用。

所述“向应用程序关键数据池模块发送‘请求支付所获得的应用程序关键数据’的消息”是指：按照游戏设计，当游戏用户在游戏中获得了一定数额的应用程序关键数据后，游戏程序应向应用程序关键数据池模块发送消息请求支付所获得的应用程序关键数据。该消息的构成应该至少包括所需应用程序关键数据的数额、游戏用户标识。根据本发明的一个实施方式，如果需要，还包含游戏标识以便“应用程序关键数据池模块”区分不同的游戏程序。

所述接收并存储应用程序关键数据到游戏程序的存储设备中是指：游戏客户端模块从“应用程序关键数据池模块”接收代表应用程序关键数据的数据记录并存储到游戏程序自己所在的存储设备中；同时，应用程序关键数据在存储时要保持应用程序关键数据的原有计数幅度属性，和不同计数幅度的应用程序关键数据的数量，而不应仅仅存储应用程序关键数据的总数额。根据本发明的一个实施方式，实施时，可以直接用一组代表应用程序关键数据的数据记录来表示。

所述向应用程序关键数据池模块返还应用程序关键数据是指：根据要返还的数额计算返回时所需的应用程序关键数据的计数幅度和各计数幅度的应用程序关键数据所需数量；计算完成后，将这些应用程序关键数据的数据对象发送给“应用程序关键数据池模块”，然后从游戏程序自己所在的存储设备中删除这些应用程序关键数据的数据对象。根据本发明的一个实施方式，这一功能跟应用程序关键数据的计数幅度设计有关，当只有单一计数幅度的情况下，可以不需要此功能。

综上所述，本发明中的应用程序关键数据都带有所有者标识，并且在使用时可通过数字签名进行检查、验证，因此一个游戏使用者在游戏中获得的应用程序关键数据不能被共享给其他游戏用户使用；另外，在联线状态下由运行在服务器中的签发模块签发的应用程序关键数据可供游戏用户在离线状态下使用，避免了网络断开时因为无法访问网络资源而导致游戏无法进行的情况。

实施例一：

如图1所示，本实施例中具有服务器、移动设备两个交互终端。其中应用程序关键数据签发模块（即图1中的签发模块）设置在服务器中。移动设备中则具有应用程序关键数据池模块和游戏客户端模块。

本例中，应用程序关键数据只有“1元”这一种计数幅度；“应用程序关键数据池模块”被作为游戏程序中的一个模块实现。用于代表应用程序关键数据的数据记录设计为：<计数幅度><所有者标识><数字签名>。计数幅度字段使用1字节的整数，并且数值总是1；所有者标识字段使用32字节的字符串；对于数字签名字段，则采用先对计数幅度、所有者标识字段进行MD5运算得到数字摘要，然后用RSA私钥对所得的数字摘要进行加密，并以所得密文作为数字签名的内容。数字签名的公钥要对共享给“应用程序关键数据池模块”和“游戏客户端模块”，以便两者验证应用程序关键数据的数字签名。

运行在服务器中的应用程序关键数据签发模块可以实现为一个公开的网络服务，例如一个运行在具有公网IP的网络服务器中。它与运行在移动设备中的“应用程序关键数据池模块”之间的通讯可以采用自定义的协议。

运行在服务器中的签发模块的核心功能是响应运行在移动设备中的应用程序关键数据池模块的请求签发应用程序关键数据并发送给后者。其工作内容可参阅图3。

步骤301：接收签发请求。

本步骤中，签发模块接收从运行与移动设备的“应用程序关键数据池模块”发来的要求发放应用程序关键数据的请求消息。

步骤302：检查签发请求的有效性。

本步骤中，至少应检查所请求发放的应用程序关键数据的数量是否超过了游戏设计中容许的数量。如果签发请求无效，则应中断签发流程，并返回出错信息。

步骤303：计算所需应用程序关键数据的计数幅度和各种计数幅度的应用程序关键数据的数量。

在本实施例中，应用程序关键数据只有“1元”一种计数幅度，因此，不需计算应签发哪些计数幅度的应用程序关键数据；而要签发的应用程序关键数据的数量则等于签发请求中指定的应用程序关键数据数额。例如：签发请求中要求发放500元的应用程序关键数据，则要签发的应用程序关键数据为500个代表1元计数幅度的应用程序关键数据的数据记录。

步骤304：生成代表所签发的应用程序关键数据的数据记录。

本步骤中，要为所签发的应用程序关键数据生成数据记录。例如：要签发500个1元计数幅度的应用程序关键数据，则要生成500条代表1元应用程序关键数据的数据记录，每条记录中都包含计数幅度、所有者标识，并且要为每个数据记录填写“数字签名”字段。

步骤305：将应用程序关键数据发送给请求者。

本步骤中，签发模块将步骤304中生成的数据记录通过网络发送给运行与移动设备中的“应用程序关键数据池模块”。例如：要将500元的应用程序关键数据发送给请求者，则意味着将500条代表1元计数幅度的应用程序关键数据的数据记录发送给运行在移动设备中的“应用程序关键数据池模块”。

本实施例中，运行于移动设备中的“应用程序关键数据池模块”被实现为游戏程序中的一个内部模块。其核心功能是向运行与服务器的签发模块发送“签发请求”；存储签发模块发放的应用程序关键数据到本地存储设备中；在游戏进行中向游戏用户支付应用程序关键数据。

由于在本实施例中的应用程序关键数据池模块只为一个游戏程序服务，因此在发送签发请求时可以不包含游戏标识，而只包含所请求的应用程序关键数据的数量和游戏用户标识。当本模块接收到签发模块发送回来的代表应用程序关键数据的数据记录时，应首先检查应用程序关键数据中的所有者标识与当前的游戏用户标识是否一致，如果不一致应视为出错，如果一致则可存储到本地存储设备中。在本实施例中，代表应用程序关键数据的数据记录可以存放到一个本地文件中，称为“应用程序关键数据存储文件”，由应用程序关键数据池模块使用的应用程序关键数据存储文件也称为“应用程序关键数据池”。该文件的构成请参阅图2。

图2中的“文件标识”是一个固定的字符串，用于快速判断一个文件是否用来存放应用程序关键数据的；“数字签名”是对该文件后续内容的数字签名，可用常用的数字签名算法生成，它是一个固定长度二进制字节数据；“操作序号”是一个数值，可以用8字节的整数表示，它代表本地应用程序关键数据池被用于支付应用程序关键数据的次数；“应用程序关键数据数量”字段是一个整数，代表后续的“应用程序关键数据信息记录”的个数；“应用程序关键数据信息记录”则是代表应用程序关键数据的数据记录，文件中可以存放多个应用程序关键数据信息记录。

图4是本发明中应用程序关键数据的支付环节的流程图。支付过程参阅图4。

步骤401：接收支付请求。

本实施例中，应用程序关键数据池模块是游戏程序内部的一个模块，因此支付请求可以方便从程序内部获得。支付请求中至少应包含要支付给游戏用户的应用程序关键数据数额。另外，也可以包含游戏用户的标识信息。

步骤402：检查支付能力。

本步骤中要检查应用程序关键数据池中剩余的应用程序关键数据的数额是否足以完成这次支付。如果数量不足，则要提示游戏用户无法完成支付，并中断支付流程。

步骤403：计算所需计数幅度和数量。

本步骤负责计算这次支付所需的应用程序关键数据的计数幅度和各种计数幅度的应用程序关键数据的数量。在本实施例中，所有应用程序关键数据的计数幅度只有“1元”的这一种，因此只要应用程序关键数据总额够用就总是可以完成支付的。

步骤404：支付。

本步骤中，代表所需支付的应用程序关键数据的数据记录将从“应用程序关键数据池模块”的应用程序关键数据存储文件中被提取出来，并发送到游戏程序中存放用户应用程序关键数据的存储文件中；随后将这些应用程序关键数据记录从应用程序关键数据池模块的应用程序关键数据存储文件中删除；删除后，应将应用程序关键数据存储文件中的“操作序号”字段的数值加1，然后再重新计算并修改“数字签名”字段。本步骤中被删除的应用程序关键数据记录可以保留为空白以便以后存放新签发的应用程序关键数据。另外，文件中的操作序号需要另外保存一份，以便以后检查应用程序关键数据存储文件的有效性时使用。这里所述的应用程序关键数据存储文件的有效性指：文件标识应正确，数字签名应正确，操作序号要与本模块存放的操作序号的副本的数值一致。

本发明中的“游戏客户端模块”是作为运行在移动设备中的游戏程序的模块存在的。它主要完成存储用户应用程序关键数据、发送支付请求、接收支付的功能，另外也提供操作界面供游戏用户指定要签发的应用程序关键数据的数额。

存储游戏用户的应用程序关键数据的方法可以采用与“应用程序关键数据池模块”相同的存储方法，即：采用一个文件来存放代表应用程序关键数据的数据记录。

游戏客户端模块在发送支付请求时，应至少提供所需支付的应用程序关键数据的数额。另外可以包含游戏用户的标识信息。该模块在接收支付时，要将接收到的代表应用程序关键数据的数据记录存放到游戏用户的应用程序关键数据存储文件中，同时要更新该文件中的操作序号和数字签名字段。另外，需要将操作序号另外保存一份，以便以后检查该文件的有效性时使用。这里所述的应用程序关键数据存储文件的有效性指：文件标识应正确，数字签名应正确，操作序号要与本模块保存的操作序号副本的数值一致。

游戏客户端模块还应提供一个操作界面供游戏用户指定需要签发的应用程序关键数据的数额。这个请求将被发送给应用程序关键数据池模块，并由后者组成一个签发请求发送到运行在服务器上的签发模块。此界面应该网络连接有效的情况下使用。

实施例二：

本实施例介绍了一个比实施例一更为复杂的实施方案。

如图1所示，本实施例中具有服务器、移动设备两个交互终端。其中签发模块设置在服务器中。移动设备中则具有应用程序关键数据池模块和游戏客户端模块。

本例中，应用程序关键数据有“1元、10元、100元”这三种计数幅度；“应用程序关键数据池模块”实现为一个独立的程序，它与“游戏客户端模块”的通讯采用进程间通讯方式。用于代表应用程序关键数据的数据记录设计为：<游戏标识><计数幅度><所有者标识><数字签名>。游戏标识字段使用32字节的字符串；计数幅度字段使用1字节的整数；所有者标识字段使用32字节的字符串；对于数字签名字段，则采用先对计数幅度、所有者标识字段进行MD5运算得到数字摘要，然后用RSA私钥对所得的数字摘要进行加密，并以所得密文作为数字签名的内容。数字签名的公钥要对共享给“应用程序关键数据池模块”和“游戏客户端模块”，以便两者验证应用程序关键数据的数字签名。

运行在服务器中的应用程序关键数据签发模块可以实现为一个公开的网络服务，例如一个运行在具有公网IP的网络服务器中。它与运行在移动设备中的“应用程序关键数据池模块”之间的通讯可以采用自定义的协议。

运行在服务器中的签发模块的核心功能是响应运行在移动设备中的应用程序关键数据池模块的请求签发应用程序关键数据并发送给后者。其工作内容可参阅图3。

步骤301：接收签发请求。

本步骤中，签发模块接收从运行与移动设备的“应用程序关键数据池模块”发来的要求发放应用程序关键数据的请求消息。

步骤302：检查签发请求的有效性。

本步骤中，至少应检查所请求发放的应用程序关键数据的数量是否超过了游戏设计中容许的数量。如果签发请求无效，则应中断签发流程，并返回出错信息。

步骤303：计算所需应用程序关键数据的计数幅度和各种计数幅度的应用程序关键数据的数量。

在本实施例中，应用程序关键数据有“1元、10元、100元”三种计数幅度，因此，需要计算应签发哪些计数幅度的应用程序关键数据及各种计数幅度的应用程序关键数据需要多少数量。为了使应用程序关键数据的支付比较容易，应尽量使所签发的应用程序关键数据能够组成从1元到所需数额之间的所有以1元为单位的数额。例如：签发请求中要求发放500元的应用程序关键数据，则可签发4个100元的，9个10元的，10个1元的应用程序关键数据，这样在使用时就可以根据需要组成以1元为单位的，1到500元之间的任一数额。为方便起见，可以规定单次签发的最大限额，比如10000元；然后可以预先准备一个表用来存放各种计数幅度的应用程序关键数据的分配方案，比如：这个表中可以预先存放10元，100元，1000元，10000元的情况下各种计数幅度的应用程序关键数据的分配方案，参照此表即可计算出最大限额的范围内，对于任一数额，各种计数幅度的应用程序关键数据的组成方案。例如：5320元的分配方案可以是5个1000元的方案加上3个100元的方案加上2个10元方案的汇总。

步骤304：生成代表所签发的应用程序关键数据的数据记录。

本步骤中，要为所签发的应用程序关键数据生成数据记录。例如：要签发4个100元的，9个10元的，10个1元的应用程序关键数据，则要生成4条代表100元应用程序关键数据的数据记录、9条代表10应用程序关键数据的数据记录、10条代表1元应用程序关键数据的数据记录。每条记录中都包含计数幅度、所有者标识、游戏标识，并且要为每个数据记录填写“数字签名”字段。

步骤305：将应用程序关键数据发送给请求者。

本步骤中，签发模块将步骤304中生成的代表1个或多个应用程序关键数据的数据记录通过网络发送给运行与移动设备中的“应用程序关键数据池模块”。

本实施例中，运行于移动设备中的“应用程序关键数据池模块”要向运行于服务器的签发模块发送“签发请求”；存储签发模块发放的应用程序关键数据到本地存储设备中；并随着游戏的进行向游戏用户支付应用程序关键数据。

由于在本实施例中的应用程序关键数据池模块是作为一个独立的进行来实现的，它同时为多个游戏程序服务，因此在发送签发请求时需要包含游戏标识。当本模块接收到签发模块发送回来的代表应用程序关键数据的数据记录时，应首先检查应用程序关键数据中的游戏标识是否与发出签发请求的游戏匹配，如果不匹配则视为出错；然后应检查应用程序关键数据中的所有者标识与当前的游戏用户标识是否一致，如果不一致应视为出错，如果一致则可存储到本地存储设备中。在本实施例中，代表应用程序关键数据的数据记录可以存放到一个本地文件中，称为“应用程序关键数据存储文件”，可以用游戏标识来作为应用程序关键数据存储文件的文件名，并可借此区分不同游戏的应用程序关键数据的存放位置。由应用程序关键数据池模块使用的应用程序关键数据存储文件也称为“应用程序关键数据池”。该文件的构成请参阅图2。

图2中的“文件标识”是一个固定的字符串，用于快速判断一个文件是否用来存放应用程序关键数据的；“数字签名”是对该文件后续内容的数字签名，可用常用的数字签名算法生成，它是一个固定长度二进制字节数据；“操作序号”是一个数值，可以用8字节的整数表示，它代表本地应用程序关键数据池被用于支付应用程序关键数据的次数；“应用程序关键数据数量”字段是一个整数，代表后续的“应用程序关键数据信息记录”的个数；“应用程序关键数据信息记录”则是代表应用程序关键数据的数据记录，文件中可以存放多个应用程序关键数据信息记录。

图5是本实施例中应用程序关键数据的支付环节的流程图。应用程序关键数据池模块的支付功能可参阅该图。

步骤501：接收支付请求。

本实施例中，应用程序关键数据池模块是一个独立的程序，它可同时为多个游戏服务，因此支付请求应至少应包含游戏标识、要支付给游戏用户的应用程序关键数据数额和游戏用户的标识信息。

步骤502：检查支付能力。

本步骤中要根据支付请求中的游戏标识确定该游戏的应用程序关键数据存储文件的文件名，然后检查本地应用程序关键数据池中剩余的应用程序关键数据的数额是否足以完成这次支付。如果数量不足，则要提示游戏用户无法完成支付，并中断支付流程。

步骤503：计算所需计数幅度和数量。

本步骤负责计算这次支付所需的应用程序关键数据的计数幅度和各种计数幅度的应用程序关键数据的数量。具体计算方法类似于本实施例中对于签发流程步骤303的说明，此处不再赘述。

步骤504：判断能否完成支付。

本步骤根据步骤503的计算结果，对比存放在本地存储设备中的应用程序关键数据的储存情况，判断所需的各种计数幅度的应用程序关键数据的数量是否够用。如果够用则执行步骤507完成支付；如果不够用，则转到步骤505，请求游戏客户端模块预先提供一些具有不同计数幅度的应用程序关键数据。

步骤505：请求游戏程序提供零钱具有不同计数幅度的应用程序关键数据。

本步骤向位于游戏程序中的游戏客户端模块发送提取具有不同计数幅度的应用程序关键数据的请求，要求游戏程序预先提供一些具有不同计数幅度的应用程序关键数据以便完成支付。出现这种情况的原因是：某些情况下，特定计数幅度的应用程序关键数据的数量不足。而按照签发模块的设计可知（参阅本实施例签发模块的步骤303），所有应用程序关键数据放在一起时总是可以组合出1元到合计数额之间的所有以1元为单位的数额的。因此，这种情况下，只要游戏客户端模块预先提供一些具有不同计数幅度的应用程序关键数据，本模块就可以计算出完成支付的可行方案。

步骤506：接收游戏程序提供的零钱。

本步骤中，本模块接收从游戏程序发来的代表一定量应用程序关键数据的数据记录，并将这些记录存放在本模块的应用程序关键数据存储文件中。然后转向步骤503，重新计算要完成支付所需的各种计数幅度的应用程序关键数据的数量。需要注意的是：这次支付中应包含步骤505中从游戏程序那里获得的“零钱”。

步骤507：支付。

本步骤中，代表所需支付的应用程序关键数据的数据记录将从“应用程序关键数据池模块”的应用程序关键数据存储文件中被提取出来，并发送到游戏程序中存放用户应用程序关键数据的存储文件中；随后将这些应用程序关键数据记录从应用程序关键数据池模块的应用程序关键数据存储文件中删除；删除后，应将应用程序关键数据存储文件中的“操作序号”字段的数值加1，然后再重新计算并修改“数字签名”字段。本步骤中被删除的应用程序关键数据记录可以保留为空白以便以后存放新签发的应用程序关键数据。另外，文件中的操作序号需要另外保存一份，以便以后检查应用程序关键数据存储文件的有效性时使用。这里所述的应用程序关键数据存储文件的有效性指文件标识应正确，数字签名应正确，操作序号要与本模块存放的操作序号的副本的数值一致。

本发明中的“游戏客户端模块”是作为运行在移动设备中的游戏程序的模块存在的。它主要完成存储用户应用程序关键数据、发送支付请求、接收支付的功能，另外也要提供一个操作界面供游戏用户指定要签发的应用程序关键数据的数额。

存储游戏用户的应用程序关键数据的方法可以采用与“应用程序关键数据池模块”相同的存储方法，即：采用一个文件来存放代表应用程序关键数据的数据记录。

游戏客户端模块在发送支付请求时，应至少提供游戏标识、所需支付的应用程序关键数据的数额和游戏用户的标识信息。该模块在接收支付时，要将接收到的代表应用程序关键数据的数据记录存放到游戏用户的应用程序关键数据存储文件中，同时要更新该文件中的操作序号和数字签名字段。另外，需要将操作序号另外保存一份，以便以后检查该文件的有效性时使用。这里所述的应用程序关键数据存储文件的有效性指文件标识应正确，数字签名应正确，操作序号要与本模块保存的操作序号副本的数值一致。

游戏客户端模块还提供一个操作界面供游戏用户指定需要签发的应用程序关键数据的数额。这个请求将被发送给应用程序关键数据池模块，并由后者组成一个签发请求发送到运行在服务器上的签发模块。此界面需在网络连接有效的情况下使用。

值得注意的是，作为本发明的实施例，其中涉及的具体应用程序为游戏应用程序，应用关键数据是游戏应用程序中的计数数值，但是本领域的技术人员完全能够理解，在不脱离本发明的实质范围的情况下，本发明的方法和系统完全能够应用到其它类型的应用程序中，而且应用关键数据也不一定是类似于虚拟游戏币这样的计数数值，而可以是其它类型的数据。因此，上述实施例仅起到说明和示例性的作用，并不能简单地将本发明限定成仅用于游戏应用程序及其虚拟游戏币的控制方法和系统。任何对应用程序和关键数据的修改、替换、增删的方式，都不脱离本发明的保护范围。

Claims (8)

1. 一种在移动设备中对应用程序关键数据进行离线控制的系统，所述系统包括服务器和移动设备客户端，其特征在于，

所述服务器中包括应用程序关键数据签发单元，其中，

所述应用程序关键数据签发单元用于将应用程序关键数据签发到所述移动设备中；

所述移动设备客户端中包括应用程序关键数据池单元和应用程序客户端单元；其中，

应用程序关键数据池单元，用于转发用户要求所述服务器签发应用程序关键数据的请求，接收所述服务器签发的应用程序关键数据，在所述移动设备客户端的本地存储设备中存储所述应用程序关键数据，以及在离线状态下将所述应用程序关键数据发放给所述应用程序客户端单元；

应用程序客户端单元，用于向用户提供操作界面以请求所述服务器签发应用程序关键数据，向应用程序关键数据池单元传送请求支付所获得的应用程序关键数据的消息，从应用程序关键数据池单元接收所获得的应用程序关键数据并存储在所述移动设备客户端的本地存储设备中。

2. 根据权利要求1所述的系统，其特征在于，所述应用程序关键数据池单元将代表所述应用程序关键数据的数据记录存储在本地文件或数据库中。

3. 根据权利要求2所述的系统，其特征在于，所述数据记录还保存数字签名和操作序列号。

4. 根据权利要求1所述的系统，其特征在于，所述应用程序客户端单元向所述应用程序关键数据池单元传送应用程序关键数据。

5. 一种在移动设备中对应用程序关键数据进行离线控制的方法，所述方法用于服务器和移动设备客户端构成的系统，其特征在于，

所述服务器中包括应用程序关键数据签发单元， 

所述移动设备客户端中包括应用程序关键数据池单元和应用程序客户端单元；所述方法包括步骤：

用户通过所述应用程序客户端单元提供的操作界面向应用程序关键数据池单元发出应用程序关键数据的请求；

所述应用程序关键数据池单元接收所述请求并检查其有效性；

如果有效，则所述应用程序关键数据池单元将所述请求转发到所述应用程序关键数据签发单元；

所述应用程序关键数据签发单元将应用程序关键数据传送到所述应用程序关键数据池单元。

6. 根据权利要求5所述的方法，其特征在于，所述应用程序关键数据池单元将代表所述应用程序关键数据的数据记录存储在本地文件或数据库中。

7. 根据权利要求6所述的方法，其特征在于，所述数据记录还保存数字签名和操作序列号。

8. 根据权利要求5所述的方法，其特征在于，所述应用程序客户端单元向所述应用程序关键数据池单元传送应用程序关键数据。

Images