[0001] 本发明属于计费通道系统领域，具体涉及智能化计费运营系统及运营方法。

[0002] SDK的英文全名是：software development kit，翻译成中文的意思就是“软件开发工具包”。通俗一点的理解，是指由第三方服务商提供的实现软件产品某项功能的工具
包。一般以集合API和文档、范例、工具的形式出现。通常SDK是由专业性质的公司提供专业
服务的集合，比如提供安卓开发工具、或者基于硬件开发的服务等。也有针对某项软件功能
的SDK，如推送技术、图像识别技术、移动支付技术等，同时资源优势类的公司也提供资源共
享的SDK，如一些广告SDK提供盈利渠道，分发SDK提供产品下载渠道。

[0003] SP计费方式是指软件应用内容提供商通过和Service provider服务提供商(SP提供商)合作，接入SP提供商提供的接口，从而使用SP的计费能力，通常SP拥有多种向用户收
费的能力，如通过手机短信计费、WAP点击计费或者第三方计费等方式。SP计费方式具有可
按周期、按次使用应用的小额付费、计费的颗粒度更细、用户接受率更高等优势，进而使得
SP计费方式成为一种覆盖范围广，高效的移动应用软件付费方法。

[0004] 传统的SP计费方式的流程是，SP提供商提供多个可用的SP计费通道，SP计费通道指的是SP提供商提供给用户的一种计费途径，包括但不限于：点播短彩信、包月短彩信、
WAP、IVR等，用户在使用软件时发送计费请求，SP提供商依据不同的计费请求，在众多的计
费通道中选择适配所述计费请求的计费通道，依据合适的计费通道从运营商方扣费给软件
应用内容提供商，进而完成移动应用软件使用的计费。

[0005] 现有的每个计费通道对应特定的计费标准，而多个计费通道的计费条件无法进行统一配置，导致大量计费通道堆积，引起计费通道的管理数据冗余。由于计费通道过多，导
致后续在利用计费通道计费时需要分通道对账，进而消耗对账人员大量不必要的时间进行
数据核对，加大对账人员的工作量。

[0006] 综上所述，现有技术中SP计费通道数据冗杂得不到有效的管理，进而导致服务商不论是在分配计费通道还是对账计费通道时，都需要遍历计费通道，而引起运营上的诸多
问题。当下整个中国的支付生态颇为复杂，各种支付平台，渠道，市场百花齐放。虽然能推动
国内移动互联网的发展，但是同时也让移动支付平台更加碎片化，这意味着，移动应用开发
者面对的不再只是接入一家支付平台时遇到的困难，他们对“集成”各类支付平台的需求更
高，更需要一个统一实现接入、开发、运维和管理的系统，让自己从这些琐事中抽身出来。

[0038] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于
本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的
范围。

[0039] 本领域技术人员应理解的是，在本发明的揭露中，术语“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”“内”、“外”等指示的方位或位置关系是基于附图所示的方位或位置关系，其仅是为了便于描述本发明和简化描述，而不是指
示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此上述术
语不能理解为对本发明的限制。

[0040] 可以理解的是，术语“一”应理解为“至少一”或“一个或多个”，即在一个实施例中，一个元件的数量可以为一个，而在另外的实施例中，该元件的数量可以为多个，术语“一”不能理解为对数量的限制。

[0041] SP计费方式，通俗来讲就是用户在使用应用服务商提供的服务时，通过用户端发送计费请求至Service prodiver提供商(以下简称SP提供商)，通过SP提供商作为中介商在
运营商和应用服务商之间实现收费的一种收费方式。SP计费方式的基本流程就是应用服务
商首先从SP提供商那边获取一个或多个可用的计费通道，其中所述计费通道指的就是SP提
供商分配的一种计费途径，包括但不限于：一次短信，二次短信，一次验证码，二次验证码，
联网，纯指令形式等各种组合形式，每个计费通道对应特定的计费标准。随后，当用户端选
用特定的服务项时，发送计费请求给SP提供商,SP提供商通过所述计费请求匹配合适的计
费通道，并根据计费通道从运营商扣除相应的费用给应用服务商，从而实现消费扣费的方
法。

[0042] 如图1所示，本实施例所描述的智能化计费运营系统，适用于快速接入应用程序，通过SP提供商的计费通道实现高效的计费能力，包括：

[0043] SDK客户端，嵌入所述应用程序中，发出计费请求，接收所述SP提供商的验证信息，向所述SP提供商发送指令；

[0044] 计费接口平台，获取所述计费请求，及从所述SDK客户端获取计费数据，向所述SDK客户端返回计费结果；

[0045] 计费代码池，整合有至少一所述SP提供商的至少一计费通道；

[0046] 计费服务平台，根据所述计费数据在所述计费代码池中筛选出最优的计费通道，所述计费代码池以所述最优的计费通道向所述SP提供商发起所述计费请求，接收来自所述
SP提供商返回的计费结果；

[0047] 自动预警平台，根据所述计费数据及所述计费结果，得出所述计费通道的计费效率结果，依据所述计费效率结果自动上下线计费通道和进行省份屏蔽；同时采用邮件的方
式，以不同的优先级标注，通知运营人员计费通道情况(包括计费效率、上下线和省份屏蔽
的操作)，从而节省大量的运营成本和时间。对于计费效率低的计费通道，将其从所述的计
费代码池中剔除，或是将新的符合要求的计费通道添加到所述计费代码池中，根据各个计
费通道在各个省份的计费效率，将某一计费通道计费效率低的省份屏蔽。

[0048] 所述智能化计费运营系统进一步包括SDK管控平台，对所述计费代码池配置、维护，以及根据所述计费通道的运营数据对所述计费通道进行优先级调整，所述运营数据包
括但不限于省份开通情况，计费通道、分省的计费转化率，计费用户群分省情况以及计费通
道结算比率的高低，另外所述SDK管控平台通过运营人员人工预干预结合运营数据的方式
获取计费通道排序权重，一般而言，当计费通道的运营数据越好，则表示该计费通道的等级
越高，权重越高，反之则低。精细化运营，用户上下限，日月限制等条件的统一限制。

[0049] 所述SP提供商发送验证信息或扣费通知给所述SDK客户端，所述SDK客户端提交指令给所述SP提供商的指定端口，所述指定端口与所述最优的计费通道相匹配，所述指令包
括计费需要发送的短信内容，具体而言，指定端口是短信内容发送的目的端口号。

[0050] 所述计费请求包括但不限于功能码、计费点、用户IP、手机串号和时间戳。

[0051] 所述计费数据包括但不限于运营商，省份，用户上下限。

[0052] 所述订单主要是记录用户计费请求和计费数据，所述任务主要记录选定的计费通道数据。

[0053] 所述SP提供商包括运营商，如移动、电信和联通。

[0054] 所述智能化计费运营系统进一步包括缓存处理服务中心，所述计费接口平台、计费服务平台、计费代码池均是通过所述缓存处理服务中心与所述SDK管控平台、所述数据中
心通信连接，传递数据。

[0055] 在网络领域中，数据接口主要是客户端请求服务端的入口，数据接口被应用于接收/响应来自客户端的请求数据，在一些情况下，数据接口对请求数据进行简单的处理，由
于数据接口的存在使得网络数据可在多个应用端之间发生交互，而正是网络数据的交互最
终搭建完整的网络体系。

[0056] 一般而言，在网络数据的传输过程中，请求数据通过平台设定的接口进入对应的业务模块，所述业务模块对请求数据进行响应处理。所述业务模块包括但不限于计费初始
化，版本更新，用户计费，计费结果通知等内容，不同的业务模块实现不同的功能，多个请求
数据对应多个业务模块，以实现不同功能的请求。

[0057] 现有技术的数据接入方法是多个请求数据对应多个业务模块，在这些请求数据的数据接入过程中，多个请求数据通过设定的通信协议接入不同的数据接口，其中这些数据
接口是平台针对每个单独的业务模块开放的一个唯一的访问地址，由此不同的请求数据通
过不同的访问地址进入不同的接口从而进入特定的业务模块中。换言之，每个业务模块对
应一个单独的数据接口，这些数据接口针对每个业务模块提供单独的访问地址，请求数据
以此方式匹配到对应的业务模块，然而现有技术的数据接口接入/响应数据的方式存在一
些弊端。数据接口繁多难管理。从而导致接口扩展性差。就是说，每个数据接口的局限性过
大，一旦需要更改或者增删业务模块的话，就需要相对应地更改或增删数据接口，不仅仅导
致数据接口的管理变得很麻烦，另外占据很多平台资源。降低数据接入效率。在现有技术的
数据接入方法中，所述请求数据需要在多个数据接口提供的访问地址中寻找到适配的数据
接口，进而加大了服务器的工作量，也降低了数据接入效率。难以实现对请求数据的安全保
护。现有技术的数据接入方法中请求数据从多个数据接口进入平台，很难针对请求数据进
行逐一单个的加密解密，进而造成数据和服务安全隐患。

[0058] 所述计费接口平台作为一个统一的数据接口接入平台，采用同一通信协议，使多类型的计费请求和计费数据通过统一的数据接口接入平台，极大程度地节约了数据接口的
资源，降低服务器的服务压力，所述计费请求和计费数据构成请求数据，具体是通过如下方
法实现：

[0059] S1：重构请求数据，形成共同参数以及特有参数，添加功能码至所述请求数据，所述功能码对应至少一业务模块；

[0060] S2：依据所述共同参数设置统一接口，其中所述统一接口允许包括所述共同参数的请求数据进入；

[0061] 以及S3：获取所述功能码，匹配所述功能码与对应的业务模块。共同参数比如像是(手机型号、手机品牌、手机串号、联网类型、客户端IP等)，其中所述特有参数TS包括计费
点、用户IP、客户端插件版本、手机品牌、手机agent等。在一些实施例中，所述请求数据以
JSON数据格式存在，以POST方式提交。在一些实施例中，所述功能码对应所述业务模块的所
述特征参数形成。

[0062] 所述计费代码池包括整合模块、交互模块和请求模块，所述整合模块整合至少一所述SP提供商的至少一计费通道，引入计费代码概念，所述整合模块将计费通道分类整理，
依据归类标准归类至少一计费通道，被归类的计费通道形成计费代码，根据所述计费请求
和计费数据，匹配符合的计费代码，从所述计费代码匹配并调度符合所述计费请求和计费
数据的计费通道，基于计费代码归类计费通道，达到统一配置同类计费通道的目的，所述归
类标准被实施为所述计费通道的计费实现方式，其中所述计费实现方式包括一次短信，多
次短信，一次验证码，多次验证码，联网，纯指令形式其中一种或其组合。保留原有计费通道
的条件限制和作用，并在计费代码中维护该计费代码的基础信息，如代码标志，所属SP，结
算方式，结算比例等，达到控制该计费代码下所有计费通道的目的，同时也可以对计费通道
进行特殊设置，起到精确计费代码和计费通道精确化运营的目的，数据上可以直接通过计
费代码来进行统计分析，对账等。所述交互模块从所述SP提供商获取计费信息并反馈给所
述计费服务平台，所述计费信息包括但不限于指令和指定端口，所述请求模块以所述最优
的计费通道向所述SP提供商发起所述计费请求。

[0063] 所述计费服务平台包括筛选模块，所述筛选模块整理分析所述计费数据，所述计费数据包括运营商，省份，用户信息、计费通道金额，计费代码等级、计费通道权重的一种或
其组合，进而筛选模块根据上述信息选择最优的计费通道。

[0064] 所述计费服务平台进一步包括反馈模块，所述反馈模块接收所述SP提供商返回的计费结果，并将所述计费结果通过所述计费接口平台反馈给所述SDK客户端。

[0065] 所述智能化计费运营系统进一步包括对账平台，统一维护对账单、开票、快递、开户行、到付款等系列的对账信息存储在对账平台，相关人员在该平台通过权限可以快速查
找，核对，落实，提高工作效率。

[0066] 所述智能化计费运营系统进一步包括数据中心，用于存储计费请求、计费数据、计费信息，订单、任务，计费结果。

[0067] 所述应用程序为移动终端的移动应用程序，如智能手机软件。

[0068] 所述计费代码池将各大运营商计费通道整合在一起，统一管理，分配，调优，通过配置对SP提供商进行交互，获取计费信息反馈给计费服务平台；所述SP提供商将返回计费
结果给所述计费服务平台，所述计费结果包括是否计费成功的信息。

[0069] 所述计费服务平台将所述计费接口平台获取的计费数据进行整理，运用算法对所述计费代码池进行筛选最优的计费通道，将所述计费信息反馈给SDK客户端，达到计费目
的，同时持久化订单数据，以及接收SP提供商的计费同步信息，即计费结果。

[0070] 所述计费接口平台主要是服务于所述sdk客户端，进行交互通信协议，所述客户端SDK通过统一的且HPPT协议下的所述计费接口平台，将所述计费请求和计费数据传输过来，
为所述计费服务平台判断运营商、省份、用户上下限、用户每日/每月能够计费成功的金额、
代码每日/每月的计费成功的总额度做准备，也为筛选计费通道计费做准备。

[0071] 本发明不局限于上述最佳实施方式，任何人在本发明的启示下都可得出其他各种形式的产品，但不论在其形状或结构上作任何变化，凡是具有与本申请相同或相近似的技
术方案，均落在本发明的保护范围之内。