一种数据输出控制方法，及设备.pdf

本发明实施例公开了了一种存档数据输出控制方法，及设备，在第一应用平台和第二应用平台分别执行完在各自应用平台的操作以后，记录执行操作产生的存档数据，以及存档数据的数据类型；接收存档数据输出指令，并确定所述存档数据输出指令指定的数据类型；调用所述第一应用平台的查询接口以及所述第二应用平台的查询接口，获得记录的与所述数据类型对应的存档数据，然后合并输出获得的存档数据。在上述终端收到交易记录存档数据输出查看的指令以后，一并查询并获得读取了在不同支付平台应用平台的交易记录存档数据，实现多支付平台应用平台交易记录存档数据的合并输出；提高了存档数据的输出效率用户查看交易记录的效率。

权利要求书
1.  一种数据输出控制方法，其特征在于，包括：
在第一应用平台和第二应用平台分别执行完在各自应用平台的操作以 后，记录执行操作产生的存档数据，以及存档数据的数据类型；
接收存档数据输出指令，并确定所述存档数据输出指令指定的数据类型；
调用所述第一应用平台的查询接口以及所述第二应用平台的查询接口， 获得记录的与所述数据类型对应的存档数据，然后合并输出获得的存档数据。

2.  根据权利要求1所述方法，其特征在于，
所述第一应用平台执行操作产生的存档数据以及所述第二应用平台操作 产生的存档数据记录在所述第一应用平台的数据库内。

3.  根据权利要求2所述方法，其特征在于，在第一应用平台和第二应用 平台分别执行各自应用平台的操作之前，还包括：
接收通过账号登陆所述第一应用平台的登录请求，并对所述登陆请求进 行验证；在验证通过后，接收通过所述第一应用平台发起的指向所述第一应 用平台或所述第二应用平台的操作指令。

4.  根据权利要求3所述方法，其特征在于，所述记录执行操作产生的存 档数据包括：将执行操作产生的存档数据与所述账号关联，并记录与所述账 号关联的存档数据。

5.  根据权利要求4所述方法，其特征在于，若对所述登录请求验证通过， 所述调用所述第一应用平台的查询接口以及所述第二应用平台的查询接口， 获得记录的与所述数据类型对应的存档数据包括：
调用所述第一应用平台的查询接口以及所述第二应用平台的查询接口， 获得记录的与所述数据类型以及所述账号对应的存档数据。

6.  根据权利要求1至5任意一项所述方法，其特征在于，在输出获得的 存档数据之前还包括：接收数据筛选条件信息，并依据所述数据筛选条件信 息设定的条件对获得的存档数据进行筛选；
所述输出获得的存档数据包括：输出筛选得到的存档数据。

7.  根据权利要求6所述方法，其特征在于，在输出筛选得到的存档数据 之前还包括：
按照时间先后次序对筛选得到的存档数据进行排序；
所述输出筛选得到的存档数据包括：输出筛选并排序得到的存档数据。

8.  一种数据输出控制设备，其特征在于，包括：
接收单元，用于接收指向第一应用平台的操作指令；接收指向第二应用 平台的操作指令；接收存档数据输出指令；
记录单元，用于在第一应用平台和第二应用平台分别执行完在各自应用 平台的操作以后，记录执行操作产生的存档数据，以及存档数据的数据类型；
数据获取单元，用于接收存档数据输出指令，并确定所述存档数据输出 指令指定的数据类型；调用所述第一应用平台的查询接口以及所述第二应用 平台的查询接口，获得记录的与所述数据类型对应的存档数据；
数据输出单元，用于合并输出所述数据获取单元获得的存档数据。

9.  根据权利要求8所述数据输出控制设备，其特征在于，
所述记录单元，用于将所述第一应用平台执行操作产生的存档数据以及 所述第二应用平台操作产生的存档数据记录在所述第一应用平台的数据库 内。

10.  根据权利要求9所述数据输出控制设备，其特征在于，
所述接收单元，还用于在第一应用平台和第二应用平台分别执行各自应 用平台的操作之前，接收通过账号登陆所述第一应用平台的登录请求；在验 证通过后，接收通过所述第一应用平台发起的指向所述第一应用平台或所述 第二应用平台的操作指令；
所述数据输出控制设备还包括：认证单元；
所述认证单元，用于对所述接收单元接收到的登陆请求进行验证。

11.  根据权利要求10所述数据输出控制设备，其特征在于，
所述记录单元，用于将执行操作产生的存档数据与所述账号关联，并记 录与所述账号关联的存档数据。

12.  根据权利要求11所述数据输出控制设备，其特征在于，若对所述登 录请求验证通过，并且所述接收单元通过所述第一应用平台接收到存档数据 输出指令；
所述数据获取单元，用于调用所述第一应用平台的查询接口以及所述第 二应用平台的查询接口，获得记录的与所述数据类型以及所述账号对应的存 档数据。

13.  根据权利要求8至12任意一项所述数据输出控制设备，其特征在于，
所述接收单元，还用于在所述数据输出单元输出所述数据获取单元获得 的存档数据之前，接收数据筛选条件信息；所述数据输出控制设备还包括：
筛选单元，用于并依据所述接收单元接收到的所述数据筛选条件信息设 定的条件对获得的存档数据进行筛选；
所述数据输出单元，用于输出所述筛选单元筛选得到的存档数据。

14.  根据权利要求13所述数据输出控制设备，其特征在于，还包括：
排序单元，用于在所述数据输出单元输出所述筛选单元筛选得到的存档 数据之前，按照时间先后次序对筛选得到的存档数据进行排序；
所述数据输出单元，用于输出所述筛选单元筛选并且所述排序单元排序 得到的存档数据。

说明书一种数据输出控制方法,及设备
技术领域
本发明涉及通信技术领域，特别涉及一种数据的输出控制方法，及设备。
背景技术
本申请文件所涉及的数据输出控制，主要指存档数据的数据控制；存档 数据是在应用平台在执行各种操作产生的数据，这些数据会存储起来，供查 询、输出等使用。例如：交易记录就是存档数据的一种，交易记录是用来记 录交易行为的各种信息的记录信息，交易记录一般可以包含包括交易事项、 交易金额、交易时间等各种信息。
目前，交易记录在支付平台（即第三方支付的平台）完成支付后，可以 由交易系统自动完成。
第三方支付是具备一定实力和信誉保障的独立机构，采用与各大银行签 约的方式，提供与银行支付结算系统接口的交易支持平台的网络支付模式。 在“第三方支付”模式中，买方选购商品后，使用第三方支付平台提供的账户 进行货款支付，并由第三方通知卖家货款到账、要求发货；买方收到货物， 并检验商品进行确认后，就可以通知第三方付款给卖家，第三方再将款项转 至卖家账户上。第三方支付作为目前主要的网络交易手段和信用中介，最重 要的是起到了在网上商家和银行之间建立起连接，实现第三方监管和技术保 障的作用。
在缺乏有效信用体系的网络交易环境中，第三方支付模式的推出，在一 定程度上解决了网上银行支付方式不能对交易双方进行约束和监督，支付方 式比较单一；以及在整个交易过程中，货物质量、交易诚信、退换要求等方 面无法得到可靠的保证；交易欺诈广泛存在等问题。其优势体现在以下几方 面：
首先，对商家而言，通过第三方支付平台可以规避无法收到客户货款的 风险，同时能够为客户提供多样化的支付工具。尤其为无法与银行网关建立 接口的中小企业提供了便捷的支付平台。
其次，对客户而言，不但可以规避无法收到货物的风险，而且货物质量 在一定程度上也有了保障，增强客户网上交易的信心。
第三，对银行而言，通过第三方平台银行可以扩展业务范畴，同时也节 省了为大量中小企业提供网关接口的开发和维护费用。
可见，第三方支付模式有效的保障了交易各方的利益，为整个交易的顺 利进行提供支持。正是由于第三方支付上述各种优势，使得第三方支付发展 迅速，并形成了多种第三方支付的支付平台。目前第三方支付平台种类繁多， 用户也经常会使用各种支付平台进行支付，各支付平台有的会记录交易记录， 有的不会记录交易记录，若记录交易记录也仅记录自身平台完成的交易记录。 那么，在用户需要查看交易记录的时候，需要打开各种交易平台分别查看， 查看不方便，查看交易记录的效率较低。
基于以上论述，目前对于不同应用平台的存档数据，需要分别打开各应 用平台进行分别输出，输出不方便，导致存档数据的输出效率低。
发明内容
本发明实施例提供了一种存档数据输出控制方法，及设备，用于在将本 地的各种应用平台的存档数据合并输出，方便存档数据的输出，提高输出存 档数据的效率。
一种数据输出控制方法，包括：
在第一应用平台和第二应用平台分别执行完在各自应用平台的操作以 后，记录执行操作产生的存档数据，以及存档数据的数据类型；
接收存档数据输出指令，并确定所述存档数据输出指令指定的数据类型；
调用所述第一应用平台的查询接口以及所述第二应用平台的查询接口， 获得记录的与所述数据类型对应的存档数据，然后合并输出获得的存档数据。
一种数据输出控制设备，包括：
接收单元，用于接收指向第一应用平台的操作指令；接收指向第二应用 平台的操作指令；接收存档数据输出指令；
记录单元，用于在第一应用平台和第二应用平台分别执行完在各自应用 平台的操作以后，记录执行操作产生的存档数据，以及存档数据的数据类型；
数据获取单元，用于接收存档数据输出指令，并确定所述存档数据输出 指令指定的数据类型；调用所述第一应用平台的查询接口以及所述第二应用 平台的查询接口，获得记录的与所述数据类型对应的存档数据；
数据输出单元，用于合并输出所述数据获取单元获得的存档数据。
从以上技术方案可以看出，本发明实施例具有以下优点：承载在同一终 端的两个不同的应用平台（第一应用平台和第二应用平台），在各自完成操作 以后，分别记录有存档数据；在上述终端收到存档数据输出指令以后，一并 查询并获得了在不同应用平台的存档数据，实现多应用平台存档数据的合并 输出；用户可以不必分别在不同应用平台的存档数据输入数据输出指令，也 不必在多个存档数据的输出文件中查看存档数据，提高了存档数据的输出效 率。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中 所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发 明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性 的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例设备结构示意图；
图2为本发明实施例方法流程示意图；
图3为本发明实施例设备结构示意图；
图4为本发明实施例设备结构示意图；
图5为本发明实施例设备结构示意图；
图6为本发明实施例设备结构示意图；
图7为本发明实施例方法流程示意图；
图8为本发明实施例设备结构示意图；
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本 发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部份实施 例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在 没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的 范围。
如图1所示，为本发明实施例提供的数据输出控制设备，为了便于说明， 仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发 明实施例方法部分。该数据输出控制设备一般可以是终端，终端可以为包括 手机、平板电脑、PDA（Personal Digital Assistant，个人数字助理）、POS（Point  of Sales，销售终端）、车载电脑等任意终端设备，以终端为手机为例：
图1示出的是与本发明实施例提供的终端相关的手机的部分结构的框图。 参考图1，手机包括：射频（Radio Frequency，RF）电路110、存储器120、 输入单元130、显示单元140、传感器150、音频电路160、无线保真（wireless  fidelity，WiFi）模块170、处理器180、以及电源190等部件。本领域技术人 员可以理解，图1中示出的手机结构并不构成对手机的限定，可以包括比图 示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
下面结合图1对手机的各个构成部件进行具体的介绍：
RF电路110可用于收发信息或通话过程中，信号的接收和发送，特别地， 将基站的下行信息接收后，给处理器180处理；另外，将设计上行的数据发 送给基站。通常，RF电路110包括但不限于天线、至少一个放大器、收发信 机、耦合器、低噪声放大器（Low Noise Amplifier，LNA）、双工器等。此外， RF电路110还可以通过无线通信与网络和其他设备通信。上述无线通信可以 使用任一通信标准或协议，包括但不限于全球移动通讯系统（Global System  of Mobile communication，GSM）、通用分组无线服务（General Packet Radio  Service，GPRS）、码分多址（Code Division Multiple Access，CDMA）、宽带 码分多址（Wideband Code Division Multiple Access,WCDMA）、长期演进 （Long Term Evolution，LTE）、电子邮件、短消息服务（Short Messaging Service， SMS）等。
存储器120可用于存储软件程序以及模块，处理器180通过运行存储在 存储器120的软件程序以及模块，从而执行手机的各种功能应用以及数据处 理。存储器120可主要包括存储程序区和存储数据区，其中，存储程序区可 存储操作系统、至少一个功能所需的应用程序（比如声音播放功能、图像播 放功能等）等；存储数据区可存储根据手机的使用所创建的数据（比如音频 数据、电话本等）等。此外，存储器120可以包括高速随机存取存储器，还 可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他 易失性固态存储器件。
输入单元130可用于接收输入的数字或字符信息，以及产生与手机的用 户设置以及功能控制有关的键信号输入。具体地，输入单元130可包括触控 面板131以及其他输入设备132。触控面板131，也称为触摸屏，可收集用户 在其上或附近的触摸操作（比如用户使用手指、触笔等任何适合的物体或附 件在触控面板131上或在触控面板131附近的操作），并根据预先设定的程式 驱动相应的连接装置。可选的，触控面板131可包括触摸检测装置和触摸控 制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作 带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收 触摸信息，并将它转换成触点坐标，再送给处理器180，并能接收处理器180 发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面 声波等多种类型实现触控面板131。除了触控面板131，输入单元130还可以 包括其他输入设备132。具体地，其他输入设备132可以包括但不限于物理键 盘、功能键（比如音量控制按键、开关按键等）、轨迹球、鼠标、操作杆等中 的一种或多种。
显示单元140可用于显示由用户输入的信息或提供给用户的信息以及手 机的各种菜单。显示单元140可包括显示面板141，可选的，可以采用液晶显 示器（Liquid Crystal Display，LCD）、有机发光二极管（Organic Light-Emitting  Diode,OLED）等形式来配置显示面板141。进一步的，触控面板131可覆盖 显示面板141，当触控面板131检测到在其上或附近的触摸操作后，传送给处 理器180以确定触摸事件的类型，随后处理器180根据触摸事件的类型在显 示面板141上提供相应的视觉输出。虽然在图1中，触控面板131与显示面 板141是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实 施例中，可以将触控面板131与显示面板141集成而实现手机的输入和输出 功能。
手机还可包括至少一种传感器150，比如光传感器、运动传感器以及其他 传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境 光传感器可根据环境光线的明暗来调节显示面板141的亮度，接近传感器可 在手机移动到耳边时，关闭显示面板141和/或背光。作为运动传感器的一种， 加速计传感器可检测各个方向上（一般为三轴）加速度的大小，静止时可检 测出重力的大小及方向，可用于识别手机姿态的应用（比如横竖屏切换、相 关游戏、磁力计姿态校准）、振动识别相关功能（比如计步器、敲击）等;至 于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他 传感器，在此不再赘述。
音频电路160、扬声器161，传声器162可提供用户与手机之间的音频接 口。音频电路160可将接收到的音频数据转换后的电信号，传输到扬声器161， 由扬声器161转换为声音信号输出；另一方面，传声器162将收集的声音信 号转换为电信号，由音频电路160接收后转换为音频数据，再将音频数据输 出处理器180处理后，经RF电路110以发送给比如另一手机，或者将音频数 据输出至存储器120以便进一步处理。
WiFi属于短距离无线传输技术，手机通过WiFi模块170可以帮助用户收 发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联 网访问。虽然图1示出了WiFi模块170，但是可以理解的是，其并不属于手 机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。
处理器180是手机的控制中心，利用各种接口和线路连接整个手机的各 个部分，通过运行或执行存储在存储器120内的软件程序和/或模块，以及调 用存储在存储器120内的数据，执行手机的各种功能和处理数据，从而对手 机进行整体监控。可选的，处理器180可包括一个或多个处理单元；优选的， 处理器180可集成应用处理器和调制解调处理器，其中，应用处理器主要处 理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。 可以理解的是，上述调制解调处理器也可以不集成到处理器180中。
手机还包括给各个部件供电的电源190（比如电池），优选的，电源可以 通过电源管理系统与处理器180逻辑相连，从而通过电源管理系统实现管理 充电、放电、以及功耗管理等功能。
尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。
本发明实施例提供了一种存档数据处理方法，如图2所示，包括：
201：在第一应用平台和第二应用平台分别执行完在各自应用平台的操作 以后，记录执行操作产生的存档数据，以及存档数据的数据类型；
假定第一应用平台为微信支付应用平台，假定第二应用平台为IAP （In-App Purchase，在应用程序购买）支付应用平台，那么存档数据可以分别 参考表1和表2所示。应用平台有很多种，并不仅限于微信支付和IAP支付， 上述“第一”和“第二”仅是为了区分不同的应用平台，不代表其他技术含 义。上述第二应用平台可以有一个以上，也即是说在本发明实施例中并不限 于仅只有两个应用平台的存档数据。采用微信支付和IAP支付为例的具体举 例，不应理解为对本发明实施例的唯一性限定。表1和表2若不合并输出， 将会以分别输出的形式输出，例如采用两张表格分别显示。
表1微信支付存档数据示例
记录序号 收款方 交易事项 金额（元） 交易时间 交易平台 1 Abc公司 电话充值 100.00 2013/12/25 微信支付 2 腾讯 会员年费 120.00 2013/12/22 微信支付 3 易迅商店 XXX商品 530,40 2013/12/9 微信支付 4 某网店 AA商品 3.40 2013/12/5 微信支付 ... ... ... ... ... 微信支付
表2IAP支付存档数据示例
记录序号 收款方 交易事项 金额（元） 交易时间 交易平台 1 Abc公司 电话充值 50.00 2013/12/26 IAP支付 2 腾讯 游戏点卡 30.00 2013/12/15 IAP支付 3 易迅商店 XXX商品 120,60 2013/12/10 IAP支付 4 某网店 BBB商品 60.40 2013/12/10 IAP支付 ... ... ... ... ... IAP支付
可选地，本发明实施例还提供了存档数据的具体的记录存放方案，在本 实施例中，采用记录在应用程序后台的方案实现，这个应用程序可以是第一 应用平台的应用程序也可以是第二应用平台的应用程序，也可以是第三方应 用程序。除了将存档数据存放在应用程序后台以外，还可以创建一个独立的 文件来存储存档数据，因此本实施例的举例不应理解为对本发明实施例的唯 一性限定。本实施例提供的存档数据的具体的记录存放方案如下：上述第一 应用平台执行操作产生的存档数据以及上述第二应用平台操作产生的存档数 据记录在上述第一应用平台的数据库内。
由于在同一终端，仍然可能出现多人使用的情况，这种情况下将会出现 多账号在该终端登录，并使用不同的应用平台进行操作并留下存档数据，对 于单个人而言，其一般不会关心其他账号的存档数据，并且其他账号的存档 数据也通常被认为是其他账号的隐私信息，不能被所有使用该终端的用户随 意查看，因此本发明实施例提供了如下解决方案：在第一应用平台和第二应 用平台分别执行各自应用平台的操作之前，还包括：接收通过账号登陆上述 第一应用平台的登录请求，并对上述登陆请求进行验证；在验证通过后，接 收通过上述第一应用平台发起的指向上述第一应用平台或上述第二应用平台 的操作指令。
以上方案，在支付请求的发起过程就开始通过登录应用程序，例如使用 微信账户登录微信的方式，完成对支付请求的流程控制，从而为存档数据与 账号（对应用户）的关联提供条件。基于支付请求的发起与账号进行了关联， 那么可以在存档数据的记录过程中，留下关于存档数据对应的账号的信息， 那么具体方案如下：上述记录执行操作产生的存档数据包括：将执行操作产 生的存档数据与上述账号关联，并记录与上述账号关联的存档数据。
基于以上使用了关于账号与存档数据的关联，那么上述表1和表2分别 可以进一步使用表3和表4进行记录，具体如下：
表3微信支付存档数据示例


表4IAP支付存档数据示例

202：接收存档数据输出指令，并确定上述存档数据输出指令指定的数据 类型；
在本步骤中，若终端被严格限制为单个人使用的情况，可以是一个单纯 的存档数据输出指令不附带诸如账号信息等其他信息。若终端被多人使用或 者多账号使用，那么这个输出指令可以基于前面关于应用程序的说明中，通 过应用程序来接收上述存档数据输出指令。
203：调用上述第一应用平台的查询接口以及上述第二应用平台的查询接 口，获得记录的与上述数据类型对应的存档数据，然后合并输出获得的存档 数据。
以上实现输出获得的存档数据的具体输出方式，可以是显示、可以是打 印，可以是以邮件的方式发送给指定邮箱，具体的输出方式可能多种多样， 本发明实施例对存档数据的输出方式不予限定。
在本发明实施例中，承载在同一终端的两个不同的应用平台（第一应用 平台和第二应用平台），在各自完成操作以后，分别记录有存档数据；在上述 终端收到存档数据输出指令以后，一并查询并获得了在不同应用平台的存档 数据，实现多应用平台存档数据的合并输出；用户可以不必分别在不同应用 平台的存档数据输入数据输出指令，也不必在多个存档数据的输出文件中查 看存档数据，提高了存档数据的输出效率。
基于前述举例，以表1表2为例，在本实施例中输出的存档数据可以如 下表5所示，如下：
表5合并输出的存档数据示例
记录序号 收款方 交易事项 金额（元） 交易时间 交易平台 1 Abc公司 电话充值 100.00 2013/12/25 微信支付 2 腾讯 会员年费 120.00 2013/12/22 微信支付 3 易迅商店 XXX商品 530,40 2013/12/9 微信支付 4 某网店 AA商品 3.40 2013/12/5 微信支付 5 Abc公司 电话充值 50.00 2013/12/26 IAP支付 6 腾讯 游戏点卡 30.00 2013/12/15 IAP支付 7 易迅商店 XXX商品 120,60 2013/12/10 IAP支付 8 某网店 BBB商品 60.40 2013/12/10 IAP支付 ... ... ... ... ... IAP支付
基于前述举例，以表3表4为例，在本实施例中输出的存档数据可以如 下表6所示，如下：
表6合并输出的存档数据示例


由于在同一终端，仍然可能出现多人使用的情况，这种情况下将会出现 多账号在该终端登录，并使用不同的应用平台进行操作并留下存档数据，对 于用户（对应账号）而言，其一般不会关心其他用户的存档数据，并且其他 用户的存档数据也通常被认为是其他用户的隐私信息，不能被所有使用该终 端的用户随意查看，因此本发明实施例提供了如下解决方案：可选地，若对 上述登录请求验证通过，上述调用上述第一应用平台的查询接口以及上述第 二应用平台的查询接口，获得记录的与上述数据类型对应的存档数据包括： 调用上述第一应用平台的查询接口以及上述第二应用平台的查询接口，获得 记录的与上述数据类型以及上述账号对应的存档数据。
基于前述举例，以表3表4为例，假定登录应用程序的账号是张三，那 么在本实施例中输出的存档数据可以如下表7所示，如下：
表7合并输出的存档数据示例


有时候存档数据可能会非常多，对于用户而言，可能并不需要关心所有 的存档数据。例如，用户可能仅需要知道最近三个月、一个月或者最近三天 的存档数据，或者用户仅仅需要知道交易额在多少以上的交易额，或者，用 户仅需要知道交易事项中的某个种类，或者用户仅需要知道收款方是某特定 方的存档数据等等。基于这样的需求，本发明实施例提供了进一步的解决方 案，具体如下：进一步地，在输出获得的存档数据之前还包括：接收数据筛 选条件信息，并依据上述数据筛选条件信息设定的条件对获得的存档数据进 行筛选；上述输出获得的存档数据包括：输出筛选得到的存档数据。
基于前述举例，以表3表4为例，假定登录应用程序的账号是张三，数 据筛选条件是金额在100元以上，那么在本实施例中输出的存档数据可以如 下表8所示，如下：
表8合并输出的存档数据示例


由于存档数据来源于不同的应用平台，即使在各应用平台的记录均按照 时间进行了排序，在整合时仍然有可能出现如表8所示的时间混乱的情况， 通常用户会有按照时间先后次序输出存档数据的需求，本发明实施例所称的 时间先后次序可以是按照交易发生的时间在先的排序靠前的原则排序，也可 以按照交易发送的时间在后的排序靠前进行排序（即倒序排序），具体采用哪 种时间先后次序排序本发明实施例不予限定。本发明实施例为了解决来自不 同应用平台的存档数据在合并后时间顺序可能混乱的技术问题，提出了如下 解决方案：进一步地，在输出筛选得到的存档数据之前还包括：按照时间先 后次序对筛选得到的存档数据进行排序；上述输出筛选得到的存档数据包括： 输出筛选并排序得到的存档数据。
基于前述举例，以表3表4为例，假定登录应用程序的账号是张三，数 据筛选条件是金额在100元以上，并设定按照交易时间进行倒序排序，那么 在本实施例中输出的存档数据可以如下表9所示，如下：
表9合并输出的存档数据示例


本发明实施例还提供了一种数据输出控制设备，如图2所示，包括：
接收单元301，用于接收指向第一应用平台的操作指令；接收指向第二应 用平台的操作指令；接收存档数据输出指令；
记录单元302，用于在上述第一应用平台完成支付功能后，记录上述第一 应用平台的存档数据；在上述第二应用平台完成支付功能后，记录上述第二 应用平台的存档数据；
数据获取单元303，用于在上述接收单元301接收到存档数据输出指令后， 读取上述第一应用平台的存档数据以及上述第二应用平台的存档数据；
数据输出单元304，用于输出上述数据获取单元303获得的存档数据。
在本实施例中，可以假定第一应用平台为微信支付应用平台，假定第二 应用平台为IAP（In-App Purchase，在应用程序购买）支付应用平台，那么存 档数据可以分别参考表1和表2所示。应用平台有很多种，并不仅限于微信 支付和IAP支付，上述“第一”和“第二”仅是为了区分不同的应用平台， 不代表其他技术含义。上述第二应用平台可以有一个以上，也即是说在本发 明实施例中并不限于仅只有两个应用平台的存档数据。采用微信支付和IAP 支付为例的具体举例，不应理解为对本发明实施例的唯一性限定。以上实现 输出获得的存档数据的具体输出方式，可以是显示、可以是打印，可以是以 邮件的方式发送给指定邮箱，具体的输出方式可能多种多样，本发明实施例 对存档数据的输出方式不予限定。
在本发明实施例中，承载在同一终端的两个不同的应用平台（第一应用 平台和第二应用平台），在各自完成操作以后，分别记录有存档数据；在上述 终端收到存档数据输出指令以后，一并查询并获得了在不同应用平台的存档 数据，实现多应用平台存档数据的合并输出；用户可以不必分别在不同应用 平台的存档数据输入数据输出指令，也不必在多个存档数据的输出文件中查 看存档数据，提高了存档数据的输出效率。
基于前述举例，以表1表2为例，在本实施例中输出的存档数据可以如 表5所示；基于前述举例，以表3表4为例，在本实施例中输出的存档数据 可以如表6所示。
可选地，本发明实施例还提供了存档数据的具体的记录存放方案，在本 实施例中，采用记录在应用程序后台的方案实现，这个应用程序可以是第一 应用平台的应用程序也可以是第二应用平台的应用程序，也可以是第三方应 用程序。除了将存档数据存放在应用程序后台以外，还可以创建一个独立的 文件来存储存档数据，因此本实施例的举例不应理解为对本发明实施例的唯 一性限定。本实施例提供的存档数据的具体的记录存放方案如下：上述记录 单元302，用于将上述第一应用平台执行操作产生的存档数据以及上述第二应 用平台操作产生的存档数据记录在上述第一应用平台的数据库内。
由于在同一终端，仍然可能出现多人使用的情况，这种情况下将会出现 多账号在该终端登录，并使用不同的应用平台进行操作并留下存档数据，对 于单个人而言，其一般不会关心其他账号的存档数据，并且其他账号的存档 数据也通常被认为是其他账号的隐私信息，不能被所有使用该终端的用户随 意查看，因此本发明实施例提供了如下解决方案：进一步地，如图4所示， 上述接收单元301，还用于在第一应用平台和第二应用平台分别执行各自应用 平台的操作之前，接收通过账号登陆上述第一应用平台的登录请求；在验证 通过后，接收通过上述第一应用平台发起的指向上述第一应用平台或上述第 二应用平台的操作指令；
上述数据输出控制设备还包括：认证单元401；
上述认证单元401，用于对上述接收单元301接收到的登陆请求进行验证。
以上方案，在支付请求的发起过程就开始通过登录应用程序，例如使用 微信账户登录微信的方式，完成对支付请求的流程控制，从而为存档数据与 账号（对应用户）的关联提供条件。基于支付请求的发起与账号进行了关联， 那么可以在存档数据的记录过程中，留下关于存档数据对应的账号的信息， 那么具体方案如下：可选地，上述记录单元302，用于将执行操作产生的存档 数据与上述账号关联，并记录与上述账号关联的存档数据。
基于以上使用了关于账号与存档数据的关联，那么上述表1和表2分别 可以进一步使用表3和表4进行记录。
由于在同一终端，仍然可能出现多人使用的情况，这种情况下将会出现 多账号在该终端登录，并使用不同的应用平台进行操作并留下存档数据，对 于用户（对应账号）而言，其一般不会关心其他用户的存档数据，并且其他 用户的存档数据也通常被认为是其他用户的隐私信息，不能被所有使用该终 端的用户随意查看，因此本发明实施例提供了如下解决方案：可选地，若对 上述登录请求验证通过，并且上述接收单元301通过上述第一应用平台接收 到存档数据输出指令；
上述数据获取单元303，用于调用上述第一应用平台的查询接口以及上述 第二应用平台的查询接口，获得记录的与上述数据类型以及上述账号对应的 存档数据。
基于前述举例，以表3表4为例，假定登录第一应用平台的账号是张三， 那么在本实施例中输出的存档数据可以如表7所示。
有时候存档数据可能会非常多，对于用户而言，可能并不需要关心所有 的存档数据。例如，用户可能仅需要知道最近三个月、一个月或者最近三天 的存档数据，或者用户仅仅需要知道交易额在多少以上的交易额，或者，用 户仅需要知道交易事项中的某个种类，或者用户仅需要知道收款方是某特定 方的存档数据等等。基于这样的需求，本发明实施例提供了进一步的解决方 案，具体如下：进一步地，如图5所示，上述接收单元301，还用于在上述数 据输出单元304输出上述数据获取单元303获得的存档数据之前还包括：接 收数据筛选条件信息；上述数据输出控制设备还包括：
筛选单元501，用于并依据上述接收单元301接收到的上述数据筛选条件 信息设定的条件对获得的存档数据进行筛选；
上述数据输出单元304，用于输出上述筛选单元501筛选得到的存档数据。
基于前述举例，以表3表4为例，假定登录第一应用平台的账号是张三， 数据筛选条件是金额在100元以上，那么在本实施例中输出的存档数据可以 如表8所示。
由于存档数据来源于不同的应用平台，即使在各应用平台的记录均按照 时间进行了排序，在整合时仍然有可能出现如表8所示的时间混乱的情况， 通常用户会有按照时间先后次序输出存档数据的需求，本发明实施例所称的 时间先后次序可以是按照交易发生的时间在先的排序靠前的原则排序，也可 以按照交易发送的时间在后的排序靠前进行排序（即倒序排序），具体采用哪 种时间先后次序排序本发明实施例不予限定。本发明实施例为了解决来自不 同应用平台的存档数据在合并后时间顺序可能混乱的技术问题，提出了如下 解决方案：进一步地，如图6所示，上述数据输出控制设备，还包括：
排序单元601，用于在上述数据输出单元304输出上述筛选单元501筛选 得到的存档数据之前，按照时间先后次序对筛选得到的存档数据进行排序；
上述数据输出单元304，用于输出上述筛选单元501筛选并且上述排序单 元601排序得到的存档数据。
基于前述举例，以表3表4为例，假定登录第一应用平台的账号是张三， 数据筛选条件是金额在100元以上，并设定按照交易时间进行倒序排序，那 么在本实施例中输出的存档数据可以如表9所示。
基于以上实施例的实现方案举例，本发明实施例给出了一个可选实现方 案举例，假定第一应用平台为微信支付，第二应用平台为IAP支付，用户使 用微信账号登录，并通过登录的微信发起查看交易记录的请求为例进行说明。 如图7所示，包括：
701：接收用户输入的微信账号密码，并对账号密码进行认证，若认证通 过则登录上述账号。
702：接收用户发起的微信支付请求，调用微信支付执行支付流程，在完 成支付后，将微信支付的交易记录存储在微信支付后台；接收用户发起的IAP 支付，并调用IAP支付执行支付流程，在完成支付后，将IAP支付的交易记 录存储在微信IAP支付后台系统；
703：接收用户发送的交易记录查看指令；上述记录查看指令包含筛选条 件；
704：获取当前微信账号，使用上述微信账号以及上述筛选条件对存储在 微信支付后台以及微信IAP支付后台系统中的交易记录进行检索，得到交易 记录；
705：将检索得到的交易记录按照时间先后次序进行排序，并显示。
在本发明实施例中，承载在同一终端的两个不同的支付平台（第一支付 平台和第二支付平台），在各自完成支付以后，分别记录有交易记录；在上述 终端收到交易记录查看的指令以后，一并读取了在不同支付平台的交易记录， 实现多支付平台交易记录的合并输出；用户可以不必分别查看在不同支付平 台的交易记录，也不必在多个交易记录的输出文件中查看交易记录，可以方 便交易记录的查看，提高用户查看交易记录的效率。
本发明实施例还提供了另一种数据输出控制设备，如图8所示，包括： 接收器801、发射器802、处理器803以及存储器804；
其中上述处理器803，用于在第一应用平台和第二应用平台分别执行完在 各自应用平台的操作以后，记录执行操作产生的存档数据，以及存档数据的 数据类型；接收存档数据输出指令，并确定上述存档数据输出指令指定的数 据类型；调用上述第一应用平台的查询接口以及上述第二应用平台的查询接 口，获得记录的与上述数据类型对应的存档数据，然后合并输出获得的存档 数据。
在本发明实施例中，承载在同一终端的两个不同的应用平台（第一应用 平台和第二应用平台），在各自完成操作以后，分别记录有存档数据；在上述 终端收到存档数据输出指令以后，一并查询并获得了在不同应用平台的存档 数据，实现多应用平台存档数据的合并输出；用户可以不必分别在不同应用 平台的存档数据输入数据输出指令，也不必在多个存档数据的输出文件中查 看存档数据，提高了存档数据的输出效率。
基于前述举例，以表1表2为例，在本实施例中输出的存档数据可以如 表5所示；基于前述举例，以表3表4为例，在本实施例中输出的存档数据 可以如表6所示。
可选地，本发明实施例还提供了存档数据的具体的记录存放方案，在本 实施例中，采用记录在应用程序后台的方案实现，这个应用程序可以是第一 应用平台的应用程序也可以是第二应用平台的应用程序，也可以是第三方应 用程序。除了将存档数据存放在应用程序后台以外，还可以创建一个独立的 文件来存储存档数据，因此本实施例的举例不应理解为对本发明实施例的唯 一性限定。本实施例提供的存档数据的具体的记录存放方案如下：上述处理 器803，用于将上述第一应用平台执行操作产生的存档数据以及上述第二应用 平台操作产生的存档数据记录在上述第一应用平台的数据库内。
由于在同一终端，仍然可能出现多人使用的情况，这种情况下将会出现 多账号在该终端登录，并使用不同的应用平台进行操作并留下存档数据，对 于单个人而言，其一般不会关心其他账号的存档数据，并且其他账号的存档 数据也通常被认为是其他账号的隐私信息，不能被所有使用该终端的用户随 意查看，因此本发明实施例提供了如下解决方案：进一步地，上述处理器803， 还用于在第一应用平台和第二应用平台分别执行各自应用平台的操作之前， 接收通过账号登陆上述第一应用平台的登录请求，并对上述登陆请求进行验 证；在验证通过后，接收通过上述第一应用平台发起的指向上述第一应用平 台或上述第二应用平台的操作指令。
以上方案，在支付请求的发起过程就开始通过登录第一应用平台，例如 使用微信账户登录微信的方式，完成对支付请求的流程控制，从而为存档数 据与账号（对应用户）的关联提供条件。基于支付请求的发起与账号进行了 关联，那么可以在存档数据的记录过程中，留下关于存档数据对应的账号的 信息，那么具体方案如下：可选地，上述处理器803，用于将执行操作产生的 存档数据与上述账号关联，并记录与上述账号关联的存档数据。。
基于以上使用了关于账号与存档数据的关联，那么上述表1和表2分别 可以进一步使用表3和表4进行记录。
由于在同一终端，仍然可能出现多人使用的情况，这种情况下将会出现 多账号在该终端登录，并使用不同的应用平台进行操作并留下存档数据，对 于用户（对应账号）而言，其一般不会关心其他用户的存档数据，并且其他 用户的存档数据也通常被认为是其他用户的隐私信息，不能被所有使用该终 端的用户随意查看，因此本发明实施例提供了如下解决方案：可选地，若对 上述登录请求验证通过，并且通过上述第一应用平台接收到存档数据输出指 令，则上述处理器803，用于调用上述第一应用平台的查询接口以及上述第二 应用平台的查询接口，获得记录的与上述数据类型以及上述账号对应的存档 数据。
基于前述举例，以表3表4为例，假定登录第一应用平台的账号是张三， 那么在本实施例中输出的存档数据可以如表7所示。
有时候存档数据可能会非常多，对于用户而言，可能并不需要关心所有 的存档数据。例如，用户可能仅需要知道最近三个月、一个月或者最近三天 的存档数据，或者用户仅仅需要知道交易额在多少以上的交易额，或者，用 户仅需要知道交易事项中的某个种类，或者用户仅需要知道收款方是某特定 方的存档数据等等。基于这样的需求，本发明实施例提供了进一步的解决方 案，具体如下：进一步地，上述处理器803，还用于在输出获得的存档数据之 前，接收数据筛选条件信息，并依据上述数据筛选条件信息设定的条件对获 得的存档数据进行筛选；上述输出获得的存档数据包括：输出筛选得到的存 档数据。
基于前述举例，以表3表4为例，假定登录第一应用平台的账号是张三， 数据筛选条件是金额在100元以上，那么在本实施例中输出的存档数据可以 如表8所示。
由于存档数据来源于不同的应用平台，即使在各应用平台的记录均按照 时间进行了排序，在整合时仍然有可能出现如表8所示的时间混乱的情况， 通常用户会有按照时间先后次序输出存档数据的需求，本发明实施例所称的 时间先后次序可以是按照交易发生的时间在先的排序靠前的原则排序，也可 以按照交易发送的时间在后的排序靠前进行排序（即倒序排序），具体采用哪 种时间先后次序排序本发明实施例不予限定。本发明实施例为了解决来自不 同应用平台的存档数据在合并后时间顺序可能混乱的技术问题，提出了如下 解决方案：进一步地，上述处理器803，还用于在输出筛选得到的存档数据之 前，按照时间先后次序对筛选得到的存档数据进行排序；上述输出筛选得到 的存档数据包括：输出筛选并排序得到的存档数据。
基于前述举例，以表3表4为例，假定登录第一应用平台的账号是张三， 数据筛选条件是金额在100元以上，并设定按照交易时间进行倒序排序，那 么在本实施例中输出的存档数据可以如表9所示。
如图1所示的终端，在本发明实施例中，该终端所包括的处理器180还 具有以下功能：上述处理器180，用于在第一应用平台和第二应用平台分别执 行完在各自应用平台的操作以后，记录执行操作产生的存档数据，以及存档 数据的数据类型；接收存档数据输出指令，并确定上述存档数据输出指令指 定的数据类型；调用上述第一应用平台的查询接口以及上述第二应用平台的 查询接口，获得记录的与上述数据类型对应的存档数据，然后合并输出获得 的存档数据。
在本发明实施例中，承载在同一终端的两个不同的应用平台（第一应用 平台和第二应用平台），在各自完成操作以后，分别记录有存档数据；在上述 终端收到存档数据输出指令以后，一并查询并获得了在不同应用平台的存档 数据，实现多应用平台存档数据的合并输出；用户可以不必分别在不同应用 平台的存档数据输入数据输出指令，也不必在多个存档数据的输出文件中查 看存档数据，提高了存档数据的输出效率。
基于前述举例，以表1表2为例，在本实施例中输出的存档数据可以如 表5所示；基于前述举例，以表3表4为例，在本实施例中输出的存档数据 可以如表6所示。
可选地，本发明实施例还提供了存档数据的具体的记录存放方案，在本 实施例中，采用记录在应用程序后台的方案实现，这个应用程序可以是第一 应用平台的应用程序也可以是第二应用平台的应用程序，也可以是第三方应 用程序。除了将存档数据存放在应用程序后台以外，还可以创建一个独立的 文件来存储存档数据，因此本实施例的举例不应理解为对本发明实施例的唯 一性限定。本实施例提供的存档数据的具体的记录存放方案如下：上述处理 器180，用于将上述第一应用平台执行操作产生的存档数据以及上述第二应用 平台操作产生的存档数据记录在上述第一应用平台的数据库内。
由于在同一终端，仍然可能出现多人使用的情况，这种情况下将会出现 多账号在该终端登录，并使用不同的应用平台进行操作并留下存档数据，对 于单个人而言，其一般不会关心其他账号的存档数据，并且其他账号的存档 数据也通常被认为是其他账号的隐私信息，不能被所有使用该终端的用户随 意查看，因此本发明实施例提供了如下解决方案：进一步地，上述处理器180， 还用于在第一应用平台和第二应用平台分别执行各自应用平台的操作之前， 接收通过账号登陆上述第一应用平台的登录请求，并对上述登陆请求进行验 证；在验证通过后，接收通过上述第一应用平台发起的指向上述第一应用平 台或上述第二应用平台的操作指令。
以上方案，在支付请求的发起过程就开始通过登录第一应用平台，例如 使用微信账户登录微信的方式，完成对支付请求的流程控制，从而为存档数 据与账号（对应用户）的关联提供条件。基于支付请求的发起与账号进行了 关联，那么可以在存档数据的记录过程中，留下关于存档数据对应的账号的 信息，那么具体方案如下：可选地，上述处理器180，用于将执行操作产生的 存档数据与上述账号关联，并记录与上述账号关联的存档数据。
基于以上使用了关于账号与存档数据的关联，那么上述表1和表2分别 可以进一步使用表3和表4进行记录。
由于在同一终端，仍然可能出现多人使用的情况，这种情况下将会出现 多账号在该终端登录，并使用不同的应用平台进行操作并留下存档数据，对 于用户（对应账号）而言，其一般不会关心其他用户的存档数据，并且其他 用户的存档数据也通常被认为是其他用户的隐私信息，不能被所有使用该终 端的用户随意查看，因此本发明实施例提供了如下解决方案：可选地，若对 上述登录请求验证通过，并且通过上述第一应用平台接收到存档数据输出指 令，则上述处理器180，用于调用上述第一应用平台的查询接口以及上述第二 应用平台的查询接口，获得记录的与上述数据类型以及上述账号对应的存档 数据。
基于前述举例，以表3表4为例，假定登录第一应用平台的账号是张三， 那么在本实施例中输出的存档数据可以如表7所示。
有时候存档数据可能会非常多，对于用户而言，可能并不需要关心所有 的存档数据。例如，用户可能仅需要知道最近三个月、一个月或者最近三天 的存档数据，或者用户仅仅需要知道交易额在多少以上的交易额，或者，用 户仅需要知道交易事项中的某个种类，或者用户仅需要知道收款方是某特定 方的存档数据等等。基于这样的需求，本发明实施例提供了进一步的解决方 案，具体如下：进一步地，上述处理器180，还用于在输出获得的存档数据之 前，接收数据筛选条件信息，并依据上述数据筛选条件信息设定的条件对获 得的存档数据进行筛选；上述输出获得的存档数据包括：输出筛选得到的存 档数据。
基于前述举例，以表3表4为例，假定登录第一应用平台的账号是张三， 数据筛选条件是金额在100元以上，那么在本实施例中输出的存档数据可以 如表8所示。
由于存档数据来源于不同的应用平台，即使在各应用平台的记录均按照 时间进行了排序，在整合时仍然有可能出现如表8所示的时间混乱的情况， 通常用户会有按照时间先后次序输出存档数据的需求，本发明实施例所称的 时间先后次序可以是按照交易发生的时间在先的排序靠前的原则排序，也可 以按照交易发送的时间在后的排序靠前进行排序（即倒序排序），具体采用哪 种时间先后次序排序本发明实施例不予限定。本发明实施例为了解决来自不 同应用平台的存档数据在合并后时间顺序可能混乱的技术问题，提出了如下 解决方案：进一步地，上述处理器180，还用于在输出筛选得到的存档数据之 前，按照时间先后次序对筛选得到的存档数据进行排序；上述输出筛选得到 的存档数据包括：输出筛选并排序得到的存档数据。
基于前述举例，以表3表4为例，假定登录第一应用平台的账号是张三， 数据筛选条件是金额在100元以上，并设定按照交易时间进行倒序排序，那 么在本实施例中输出的存档数据可以如表9所示。
值得注意的是，上述设备实施例中，所包括的各个单元只是按照功能逻 辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可； 另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发 明的保护范围。
另外，本领域普通技术人员可以理解实现上述各方法实施例中的全部或 部分步骤是可以通过程序来指令相关的硬件完成，相应的程序可以存储于一 种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或 光盘等。
以上仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于 此，任何熟悉本技术领域的技术人员在本发明实施例揭露的技术范围内，可 轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明 的保护范围应该以权利要求的保护范围为准。