实时获取电子码的方法、开放平台及系统的制作方法
【专利摘要】本发明涉及一种实时获取电子码的方法、开放平台及系统，该方法包括：开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向第三方应用服务器发送通知消息；通过第二接口接收第三方应用服务器根据通知消息返回的订单核实请求；当确定订单核实请求合法时，向第三方应用服务器返回验证成功消息；接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，并将电子码提供给预设的用户终端。由此解决了现有技术中，第三方应用服务器必须以手动方式预先向开放平台内导入一定批量的电子码所导致的操作繁琐等问题。
【专利说明】实时获取电子码的方法、开放平台及系统
【技术领域】
[0001]本发明涉及网络通信【技术领域】，具体涉及一种实时获取电子码的方法、开放平台及系统。
【背景技术】
[0002]开放平台能够将其提供的各类服务封装成一系列计算机易识别的数据接口，第三方开发者直接调用这些开放的数据接口就可以享用开放平台的相应服务，这些开放的数据接口也叫做Open API，提供这些Open API的平台本身就被称为开放平台。
[0003]利用第三方应用服务器提供的电子码向用户提供电子码的推送服务是目前开放平台的一个典型应用。在这种应用场景中，第三方应用服务器需要提供可以流通的电子码，并将提供的电子码通过开放平台推送给需要该电子码的用户终端。图1示出了上述应用场景的示意图。如图1所示，为了实现电子码在开放平台上的流通，第三方应用开发者(即操作上述第三方应用服务器的操作人员)需要事先将欲在该开放平台上流通的电子码以手动方式导入该开放平台内。具体的导入流程如图2所示，首先，第三方应用开发者需要生成一个用于存储电子码的序列号文件；然后登录到开放平台提供的导入后台，在该导入后台上提交该第三方应用开发者的信息，并上传之前生成的序列号文件；最后，确认上传结果，以实现电子码的最终导入。在导入电子码之后，开放平台就可以基于导入的电子码向用户提供电子码的推送服务。图1中还示出了电子码的找回功能，该功能与本发明关系不大，此处暂不介绍。
[0004]由此可见，利用现有的开放平台实现电子码的流通之前，必须先将电子码导入到该平台内。但是，上述手动导入电子码的操作方式非常繁琐，需要耗费大量的人力成本。而且，在手动导入电子码时，通常是一次性向开放平台内导入一定批量的电子码以供流通。这样，开放平台还需要为这些预先导入的电子码预付一定的费用，因此，开放平台还将承担预付成本的损失风险。
【发明内容】
[0005]鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的实时获取电子码的方法、开放平台及系统。
[0006]依据本发明的一个方面，提供了一种实时获取电子码的方法，包括:开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向第三方应用服务器发送通知消息；通过第二接口接收第三方应用服务器根据通知消息返回的订单核实请求；当确定订单核实请求合法时，向第三方应用服务器返回验证成功消息；接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，并将电子码提供给预设的用户终端。
[0007]依据本发明的另一方面，提供了一种实时获取电子码的开放平台，包括:第一通信模块，适于接收第三方应用服务器发送的前端支付请求；第一接口模块，适于向第三方应用服务器发送通知消息；第二接口模块，适于接收第三方应用服务器根据通知消息返回的订单核实请求；验证模块，适于确定订单核实请求是否合法；第二通信模块，适于在订单核实请求合法时向第三方应用服务器返回验证成功消息，并接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，将电子码提供给预设的用户终端。
[0008]依据本发明的另一方面，提供了一种实时获取电子码的系统，包括上述的开放平台，一个或多个用户终端及一个或多个第三方应用服务器。
[0009]在本发明提供的实时获取电子码的方法、开放平台及系统中，为第三方应用服务器提供了两个开放的接口(第一接口和第二接口)，通过这两个接口，能够实现开放平台与第三方应用服务器之间的实时数据交互，从而使开放平台能够在每次接收到第三方应用服务器发送的前端支付请求后，向第三方应用服务器发送通知消息，接收及验证第三方应用服务器返回的订单核实请求，并在验证通过后向第三方应用服务器返回验证成功消息，最后接收第三方应用服务器据此返回的电子码。通过上述方式能够实现开放平台与第三方应用服务器之间的双向验证机制，能够提高开放平台与第三方应用服务器之间的数据传输的安全性。在安全性得到保障的前提下，第三方应用服务器可以在每次接收到用户发送的与电子码相关的前端支付请求之后，实时地向开放平台发送所需的电子码。由此解决了现有技术中，第三方应用服务器必须以手动方式预先向开放平台内导入一定批量的电子码所导致的操作繁琐等问题。
[0010]上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的【具体实施方式】。
【专利附图】
【附图说明】
[0011]通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中:
[0012]图1示出了现有技术中的第三方应用开发者向开放平台导入电子码时的场景示意图；
[0013]图2示出了现有技术中的第三方应用开发者向开放平台导入电子码时的方法流程图；
[0014]图3示出了本发明一个实施例提供的实时获取电子码的方法的流程图；
[0015]图4示出了本发明另一实施例提供的实时获取电子码的方法的流程图；
[0016]图5示出了本发明实施例提供的实时获取电子码的开放平台的结构图；
[0017]图6示出了本发明实施例提供的实时获取电子码的系统的结构图。
【具体实施方式】
[0018]下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。[0019]本发明实施例提供了一种实时获取电子码的方法、开放平台及系统，用以解决现有技术中第三方应用服务器必须以手动方式预先向开放平台内导入一定批量的电子码所导致的操作繁琐等问题。
[0020]图3示出了本发明实施例提供的实时获取电子码的方法的流程图。如图3所示，该方法起始于步骤S101，在步骤SlOl中，开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向第三方应用服务器发送通知消息。其中，第一接口可以通过预设的第一回调函数、第一函数指针或第一 URL地址来实现。
[0021]接下来，在步骤S102中，开放平台通过第二接口接收第三方应用服务器根据通知消息返回的订单核实请求。其中，第二接口同样可以通过预设的第二回调函数、第二函数指针或第二 URL地址来实现。
[0022]然后，在步骤S103中，开放平台确定上述的订单核实请求是否合法，并在确定其合法时向第三方应用服务器返回验证成功消息。
[0023]最后，在步骤S104中，开放平台接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，并将该电子码提供给预设的用户终端。
[0024]可选地，为了提高数据传输的安全性，上述步骤SlOl中发送的通知消息中进一步包含前端支付请求的相关信息，且这些相关信息通过预设的数字签名算法进行签名。相应地，第三方应用服务器收到该通知消息后，先通过预设的签名验证算法对该通知消息进行验证，再根据验证通过后得到的相关信息返回订单核实请求。其中，第三方应用服务器根据验证通过后得到的相关信息返回订单核实请求的步骤进一步包括:首先获取相关信息中包含的待验证参数，然后通过预设的数字签名算法对待验证参数进行签名，最后将签名后的待验证参数封装在订单核实请求中即可。相应地，在步骤S103中，开放平台通过下述方式验证订单核实请求是否合法:首先，开放平台通过预设的签名验证算法对订单核实请求进行验证，得到其中的待验证参数；然后，如果得到的待验证参数合法，则可以确定该订单核实请求合法。
[0025]通过上面的方式就可以实现开放平台与第三方应用服务器之间的双向验证，从而既可以防止有人冒充开放平台来欺骗第三方应用服务器向其发送电子码，也可以防止有人冒充第三方应用服务器向开放平台传输恶意数据。另外，为了进一步确保电子码在向开放平台发送的过程中不被篡改或截获，还可以由第三方应用服务器进一步对电子码进行加密。为此，本实施例中的方法还可以包括如下细节:当开放平台与第三方应用服务器之间通过第一类数据传输协议(例如安全性较高的HTTPS协议等)进行通信时，第三方应用服务器返回的电子码是没有加密的电子码，则开放平台直接将电子码提供给预设的用户终端即可，这样可以在网络安全性高的情况下简化传输环节的操作；当开放平台与第三方应用服务器之间通过第二类数据传输协议(例如安全性较低的HTTP协议等)进行通信时，第三方应用服务器返回的电子码是经过加密的电子码，则开放平台对电子码进行解密之后再将电子码提供给预设的用户终端，这样可以在网络安全性低的情况下提高传输安全性，并防止数据在网络应用层以下的层级被盗取。
[0026]通过上述方式能够实现开放平台与第三方应用服务器之间的双向验证机制，能够提高开放平台与第三方应用服务器之间的数据传输的安全性。在安全性得到保障的前提下，第三方应用服务器可以在每次接收到用户发送的与电子码相关的前端支付请求之后，实时地向开放平台发送所需的电子码。由此解决了现有技术中，第三方应用服务器必须以手动方式预先向开放平台内导入一定批量的电子码所导致的操作繁琐等问题。
[0027]在本发明的另一实施例中，以用户阅读付费小说的应用场景为例，对本发明提供的实时获取电子码的方法进行详细介绍。其中，本实施例中的第三方应用服务器是向用户提供付费小说的服务器，该服务器提供的电子码用于激活小说的特定章节，以便使用户能够对这些章节进行阅读。图4示出了本实施例提供的实时获取电子码的方法流程图。如图4所示，该方法包括以下步骤:
[0028]步骤S201:用户终端向第三方应用服务器发送激活请求。
[0029]通常情况下，本步骤在用户希望阅读电子小说的付费章节时被触发。例如，当用户通过电脑等用户终端浏览完小说的概要性提示内容后，希望进一步阅读该小说的剩余章节时，需要用户先通过电子码对这些章节进行激活。为此，用户可以通过点击用户终端浏览器上显示的“立即激活”等字样的按钮来发送上述的激活请求。
[0030]通常情况下，该激活请求中会包含例如用户帐号、小说名称以及章节号等信息。为此，当用户点击“立即激活”的按钮之后，浏览器页面可以先跳转到购买激活码的相应页面，在该页面上显示有“快速购买”和“登录购买”两个选项，如果用户点击“快速购买”的选项，则需要用户填写订单信息，包括:应用名称(如电子小说)、产品单价(如阅读一节小说的阅读费用)、产品数量(如小说的章节数)、用户联系方式(如手机号码和/或电子邮箱等)等；如果用户点击“登录购买”的选项，则需要用户先输入用户帐号和密码等登录信息之后再填写相应的订单信息。由此可见，在上述过程中，浏览器可以获取到该激活请求的相关信息，并将这些相关信息写入该激活请求中。另外，在上述过程中，还可以进一步包括用户通过支付宝等支付方式为电子码支付费用的环节，该环节可通过现有的各种支付方式实现。
[0031]步骤S202:第三方应用服务器收到用户终端发来的激活请求后，向开放平台发送前端支付请求。
[0032]第三方应用服务器首先解析该激活请求，获取到激活请求中包含的用户帐号、小说名称以及章节号等信息；然后，根据这些信息构造前端支付请求，并将该前端支付请求发送给开放平台。
[0033]步骤S203:开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向第三方应用服务器发送通知消息。
[0034]具体地，开放平台对前端支付请求进行解析，得到其中包含的用户帐号、小说名称以及章节号等信息，然后，根据这些信息构造通知消息，并通过第一接口将通知消息发送给第三方应用服务器。其中，第一接口可以通过预设的回调函数、函数指针或URL地址等多种方式来实现。例如，该第一接口可以是开放平台预先设置好的Open API，第三方应用服务器在最初接入开放平台时，通过加载包含第一接口在内的Open API来实现与开放平台的对接。因此，在本步骤中，开放平台直接调用该第一接口就可以向第三方应用服务器发送通知消息。
[0035]在通知消息中需要包含一些需要第三方应用服务器确认的参数信息。表I示出了通知消息中所包含的参数信息:
[0036]表I
[0037]
【权利要求】
1.一种实时获取电子码的方法，包括: 开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向所述第三方应用服务器发送通知消息； 通过第二接口接收所述第三方应用服务器根据所述通知消息返回的订单核实请求； 当确定所述订单核实请求合法时，向所述第三方应用服务器返回验证成功消息； 接收所述第三方应用服务器收到所述验证成功消息后返回的与所述订单核实请求对应的电子码，并将所述电子码提供给预设的用户终端。
2.如权利要求1所述的方法，其中，所述第一接口通过预设的第一回调函数、第一函数指针或第一 URL地址实现，所述第二接口通过预设的第二回调函数、第二函数指针或第二URL地址实现。
3.如权利要求1所述的方法，其中，所述通知消息中包含所述前端支付请求的相关信息，且所述相关信息通过预设的数字签名算法进行签名； 所述第三方应用服务器收到所述通知消息后，先通过预设的签名验证算法对所述通知消息进行验证，再根据验证通过后得到的所述相关信息返回所述订单核实请求。
4.如权利要求3所述的方法，其中，所述第三方应用服务器根据验证通过后得到的所述相关信息返回所述订单核实请求的步骤包括:获取所述相关信息中包含的待验证参数，通过所述预设的数字签名算法对所述待验证参数进行签名，将签名后的待验证参数封装在所述订单核实请求中； 所述开放平台确定所述订单核实请 求合法的步骤包括:通过预设的签名验证算法对所述订单核实请求进行验证，得到其中的待验证参数，如果所述待验证参数合法，则确定所述订单核实请求合法。
5.如权利要求1-4任一所述的方法，其中，当所述开放平台与所述第三方应用服务器之间通过第一类数据传输协议进行通信时，所述第三方应用服务器返回的电子码是没有加密的电子码，则所述开放平台直接将所述电子码提供给预设的用户终端；其中，所述第一类数据传输协议包括HTTPS协议； 当所述开放平台与所述第三方应用服务器之间通过第二类数据传输协议进行通信时，所述第三方应用服务器返回的电子码是经过加密的电子码，则所述开放平台对所述电子码进行解密之后再将所述电子码提供给预设的用户终端；其中，所述第二类数据传输协议包括HTTP协议。
6.一种实时获取电子码的开放平台，包括: 第一通信模块，适于接收第三方应用服务器发送的前端支付请求； 第一接口模块，适于向所述第三方应用服务器发送通知消息； 第二接口模块，适于接收所述第三方应用服务器根据所述通知消息返回的订单核实请求； 验证模块，适于确定所述订单核实请求是否合法； 第二通信模块，适于在所述订单核实请求合法时向所述第三方应用服务器返回验证成功消息，并接收所述第三方应用服务器收到所述验证成功消息后返回的与所述订单核实请求对应的电子码，将所述电子码提供给预设的用户终端。
7.如权利要求6所述的开放平台，其中，所述第一接口模块通过预设的第一回调函数、第一函数指针或第一 URL地址发送所述通知消息； 所述第二接口模块通过预设的第二回调函数、第二函数指针或第二 URL地址接收所述订单核实请求。
8.如权利要求6所述的开放平台，其中，所述第一接口模块发送的通知消息中包含所述前端支付请求的相关信息，且所述相关信息通过预设的数字签名算法进行签名； 所述第三方应用服务器收到所述通知消息后，先通过预设的签名验证算法对所述通知消息进行验证，再根据验证通过后得到的所述相关信息返回所述订单核实请求。
9.如权利要求8所述的开放平台，其中，所述订单核实请求中包含所述第三方应用服务器从所述相关信息中获取的待验证参数，且所述待验证参数通过预设的数字签名算法进行签名； 所述验证模块适于通过预设的签名验证算法对所述订单核实请求进行验证，得到其中的待验证参数，如果所述待验证参数合法，则确定所述订单核实请求合法。
10.一种实时获取电子码的系统，包括:如权利要求6-9任一所述的开放平台，一个或多个用户终端以及一个或多个第`三方应用服务器。
【文档编号】H04L29/08GK103561115SQ201310585149
【公开日】2014年2月5日 申请日期:2013年11月19日 优先权日:2013年11月19日
【发明者】胡聪 申请人:北京奇虎科技有限公司, 奇智软件（北京）有限公司