一种业务数据的共享实现方法、装置、设备和介质与流程

本公开实施例涉及互联网数据处理技术，尤其涉及一种业务数据的共享实现方法、装置、设备和介质。

背景技术：

随着互联网和智能终端的发展，各种应用程序(app)增多，当一个应用程序新推出时，特别是以社交为主的应用程序，会因为用户数量少、用户分享信息少而使得应用程序的使用体验不佳，由此又导致人气更不容易聚集，恶性循环。

现有技术中存在一种解决方案，即从其他网站、应用程序等数据源链接一些广告、公开文献(如新闻等)进行转发分享，从而增加新应用程序中的信息更新量，吸引用户。

但是，公共性质的广告、文献，对以体现私人个性为主的社交类应用程序的用户来说，匹配度并不高。

技术实现要素：

本公开实施例提供一种业务数据的共享实现方法、装置、设备和介质，以实现业务数据在不同应用程序之间的共享。

第一方面，本公开实施例提供了一种业务数据的共享实现方法，包括：

第一应用服务平台通过平台间接口，向第二应用服务平台发送业务数据共享请求；

第一应用服务平台接收第二应用服务平台通过平台间接口反馈的业务数据；

第一应用服务平台，为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中；

第一应用服务平台将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送。

上述方案中，可选的是，为业务数据的所属用户建立虚拟账号包括：

第一应用服务平台从第二应用服务平台接收业务数据对应用户的用户信息；

第一应用服务平台将用户信息的账号标识直接创建为虚拟账号的账号标识，将用户信息赋值作为虚拟账号的用户信息。

上述方案中，可选的是，第一应用服务平台，为业务数据的所属用户建立虚拟账号包括：

第一应用服务平台从第二应用服务平台接收业务数据对应用户的用户信息；

第一应用服务平台根据用户信息建立关联的虚拟账号，将用户信息赋值作为虚拟账号的用户信息。

上述方案中，可选的是，虚拟账号的业务数据空间与第一应用程序的常规账号的业务数据空间保持一致存储；

虚拟账号和常规账号的用户信息区别空间存储。

上述方案中，可选的是，第一应用服务平台接收第二应用服务平台通过平台间接口反馈的业务数据之前，还包括：

第二应用服务平台通过第二应用程序客户端向用户询问是否允许进行业务共享，并获取用户的业务共享授权。

上述方案中，可选的是，还包括：

第一应用服务平台接收用户的账号注册请求或基于第二应用程序账号的授权登录请求；

如果账号注册请求或授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号的用户信息和业务数据空间与账号注册请求或授权登录请求的账号进行关联。

上述方案中，可选的是，如果账号注册请求或授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号的用户信息和业务数据空间与账号注册请求或授权登录请求的账号进行关联，包括：

如果账号注册请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号变更为第一应用程序的常规账号，并将得到的常规账号作为第一应用服务平台根据账号注册请求建立的新账号，反馈至第一应用程序客户端。

上述方案中，可选的是，如果账号注册请求或授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号的用户信息和业务数据空间与账号注册请求或授权登录请求的账号进行关联，包括：

如果授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号变更为第一应用程序的常规账号，并将得到的常规账号反馈给第一应用程序客户端。

第二方面，本公开实施例提供了一种业务数据的共享实现装置，配置于第一应用服务平台，所述装置包括：

共享请求发送模块，用于通过平台间接口，向第二应用服务平台发送业务数据共享请求；

业务数据接收模块，用于接收第二应用服务平台通过平台间接口反馈的业务数据；

虚拟账号建立模块，用于为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中；

业务数据推送模块，用于将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送。

上述方案中，可选的是，虚拟账号建立模块包括：

第一信息接收单元，用于从第二应用服务平台接收业务数据对应用户的用户信息；

第一账号创建单元，用于将用户信息的账号标识直接创建为虚拟账号的账号标识，将用户信息赋值作为虚拟账号的用户信息。

上述方案中，可选的是，虚拟账号建立模块包括：

第二信息接收单元，用于从第二应用服务平台接收业务数据对应用户的用户信息；

第二账号创建单元，用于根据用户信息建立关联的虚拟账号，将用户信息赋值作为虚拟账号的用户信息。

上述方案中，可选的是，虚拟账号的业务数据空间与第一应用程序的常规账号的业务数据空间保持一致存储；

虚拟账号和常规账号的用户信息区别空间存储。

上述方案中，可选的是，还包括：

请求接收模块，用于第一应用服务平台接收用户的账号注册请求或基于第二应用程序账号的授权登录请求；

账号关联模块，用于如果账号注册请求或授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号的用户信息和业务数据空间与账号注册请求或授权登录请求的账号进行关联。

上述方案中，可选的是，账号关联模块包括：

第一账号关联单元，用于如果账号注册请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号变更为第一应用程序的常规账号，并将得到的常规账号作为第一应用服务平台根据账号注册请求建立的新账号，反馈至第一应用程序客户端。

上述方案中，可选的是，账号关联模块包括：

第二账号关联单元，用于如果授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号变更为第一应用程序的常规账号，并将得到的常规账号反馈给第一应用程序客户端。

第三方面，本公开实施例还提供了一种计算机设备，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如本公开实施例所述的业务数据的共享实现方法。

第四方面，本公开实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如本公开实施例所述的业务数据的共享实现方法。

本公开实施例通过第一应用服务平台通过平台间接口，向第二应用服务平台发送业务数据共享请求后，接收第二应用服务平台通反馈的业务数据，为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中，并将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送，解决了现有技术受限于应用程序的用户信息管理机制，难以跨应用程序将其他应用程序用户的业务信息转移到另一应用程序中的问题，可以实现业务数据在不同应用程序之间的共享，从而可以增加新应用程序中的信息更新量，吸引用户。

附图说明

图1为本公开实施例一提供的一种业务数据的共享实现方法的流程图；

图2为本公开实施例二提供的一种业务数据的共享实现方法的流程图；

图3为本公开实施例三提供的一种业务数据的共享实现方法的流程图；

图4为本公开实施例四提供的一种业务数据的共享实现装置的结构示意图；

图5为本公开实施例五提供的一种计算机设备的结构示意图。

具体实施方式

下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本公开，而非对本公开的限定。

另外还需要说明的是，为了便于描述，附图中仅示出了与本公开相关的部分而非全部结构。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

下述各实施例中，每个实施例中同时提供了可选特征和示例，实施例中记载的各个特征可进行组合，形成多个可选方案，不应将每个编号的实施例仅视为一个技术方案。

实施例一

图1为本公开实施例一提供的一种业务数据的共享实现方法的流程图，本实施例可解决相关技术中，公共性质的广告、文献，对以体现私人个性为主的社交类应用程序的用户来说，匹配度并不高的问题。例如个人微博文章，可能用户会希望看到自己喜欢的明星所撰写的个性化微博。受限于应用程序的用户信息管理机制，难以跨应用程序将其他应用程序用户的业务信息转移到另一应用程序中，因为应用程序自身所管理的用户信息是有保密协议的，不能轻易将用户信息转移给其他应用程序，而在用户不关注新应用程序时，也难以登录成为新应用程序的用户。本实施例可适用于在不同应用程序之间共享业务数据的情况，该方法可以由业务数据的共享实现装置来执行，该装置可以采用软件和/或硬件的方式实现，一般可集成在诸如应用程序服务平台等计算机设备中。该方法具体包括如下步骤：

步骤101、第一应用服务平台通过平台间接口，向第二应用服务平台发送业务数据共享请求。

其中，第一应用服务平台可以是能够向第一应用程序客户端提供服务的服务器。第二应用服务平台可以是能够向第二应用程序客户端提供服务的服务器。第一应用程序和第二应用程序可以为安装于终端设备上的应用程序。

接口可以是双方(可能是系统、模块、服务等)之间数据交互的一个标准。平台间接口可以为第一应用服务平台与第二应用服务平台之间进行数据交互的标准。第一应用服务平台与第二应用服务平台通过平台间接口进行无线方式或有线方式的数据交互。

业务数据可以是用户在应用程序上进行业务操作所产生的相关数据。例如，业务数据可以用户在应用程序上发布的文章、照片。业务数据可以存储在应用程序对应的应用服务平台的数据库中。第二应用程序的业务数据存储在第二应用服务平台的数据库中。当第一应用程序需要共享第二应用程序的业务数据时，需要通过平台间接口，向第二应用服务平台发送业务数据共享请求。业务数据共享请求用于请求获取第二应用程序的业务数据。

步骤102、第一应用服务平台接收第二应用服务平台通过平台间接口反馈的业务数据。

其中，第二应用服务平台接收第一应用服务平台发送的业务数据共享请求后，根据业务数据共享请求从数据库中获取第二应用程序的业务数据，并通过平台间接口，向第一应用服务平台发送第二应用程序的业务数据。第一应用服务平台接收第二应用服务平台通过平台间接口反馈的业务数据。

步骤103、第一应用服务平台，为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中。

其中，第一应用服务平台，为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中。业务数据空间是服务平台上专用于存储用户的业务数据的存储空间。虚拟账号的业务数据空间用于存储与虚拟账号相关的数据。为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间，使虚拟账号与业务数据相关，从而可以通过虚拟账号对业务数据进行控制。

业务数据的所属用户为第二应用程序的用户，不是第一应用程序的用户，没有与第一应用程序的常规账号。虚拟账号与常规账号并不相同。常规账号为用户在应用程序上注册并使用的账号。常规账号包括用户信息和业务数据空间。用户信息可以为用户提交的个人信息。用户信息可以包括用户名称、用户头像等。用户可以登录账号，并通过账号在应用程序上进行业务操作。常规账号的业务数据空间用于存储用户进行业务操作所产生的业务数据。而虚拟账号为应用程序上用于管理其他应用程序共享的业务数据的账号。虚拟账号包括用户信息和业务数据空间。虚拟账号的业务数据空间用于存储其他应用程序共享的业务数据。虚拟账号的用户信息为根据业务数据的所属用户对应的用户信息生成的用户信息。无法通过虚拟账户进行登录操作。

步骤104、第一应用服务平台将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送。

其中，第一应用服务平台将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送，以使第一应用程序客户端的界面可以显示虚拟账号对应的业务数据，并显示虚拟账号的用户信息。

例如，虚拟账号对应的业务数据为用户在第二应用程序上发布的文章，虚拟账号的用户信息为文章所属用户的用户名称和用户头像。第一应用服务平台将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送。用户可以在第一应用程序客户端的界面上浏览用户在第二应用程序上发布的文章，并可以看到文章所属用户的用户名称和用户头像。

本实施例的技术方案，通过第一应用服务平台通过平台间接口，向第二应用服务平台发送业务数据共享请求后，接收第二应用服务平台通反馈的业务数据，为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中，并将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送，解决了现有技术受限于应用程序的用户信息管理机制，难以跨应用程序将其他应用程序用户的业务信息转移到另一应用程序中的问题，可以实现业务数据在不同应用程序之间的共享，从而可以增加新应用程序中的信息更新量，吸引用户。

实施例二

图2为本公开实施例二提供的一种业务数据的共享实现方法的流程图。本实施例以上述实施例中各个可选方案为基础进行具体化。在本实施例中，第一应用服务平台，为业务数据的所属用户建立虚拟账号具体包括：第一应用服务平台从第二应用服务平台接收业务数据对应用户的用户信息；第一应用服务平台将用户信息的账号标识直接创建为虚拟账号的账号标识，将用户信息赋值作为虚拟账号的用户信息。

可选的，第一应用服务平台接收第二应用服务平台通过平台间接口反馈的业务数据之前，还包括：第二应用服务平台通过应用客户端向用户询问是否允许进行业务共享，并获取用户的业务共享授权。

如图2所示，该方法具体包括如下步骤：

步骤201、第一应用服务平台通过平台间接口，向第二应用服务平台发送业务数据共享请求。

步骤202、第二应用服务平台通过第二应用程序客户端向用户询问是否允许进行业务共享，并获取用户的业务共享授权。

其中，第二应用服务平台接收第一应用服务平台发送的业务数据共享请求后，根据业务数据共享请求通过第二应用程序客户端向用户询问是否允许进行业务共享。具体的，第二应用服务平台根据业务数据共享请求调用第二应用程序客户端的界面，向业务数据的所属用户显示业务共享询问信息，并显示业务共享同意选项和业务共享拒绝选项。业务共享询问信息用于询问用户可以是否允许进行业务共享。用户通过点击业务共享同意选项或业务共享拒绝选项，输入回复信息。如果用户点击业务共享同意选项，则确定用户允许进行业务共享，获取用户的业务共享授权，继续进行下一步操作；如果用户点击业务共享拒绝选项，则确定用户不允许进行业务共享，未获取用户的业务共享授权，不再进行下一步操作。

步骤203、第一应用服务平台接收第二应用服务平台通过平台间接口反馈的业务数据。

步骤204、第一应用服务平台从第二应用服务平台接收业务数据对应用户的用户信息。

其中，第一应用服务平台通过平台间接口从第二应用服务平台接收与获取的业务数据对应用户的用户信息。用户信息可以包括用户名称、用户头像等。

步骤205、第一应用服务平台将用户信息的账号标识直接创建为虚拟账号的账号标识，将用户信息赋值作为虚拟账号的用户信息，将业务数据存储至虚拟账号的业务数据空间中。

其中，应用程序的账号有唯一对应的账号标识。账号标识用于区别每一个账号。第一应用服务平台可以根据接收的用户信息获取业务数据的所属用户对应的账号标识，将用户信息的账号标识直接创建为虚拟账号的账号标识，将用户信息赋值作为虚拟账号的用户信息，将业务数据存储至虚拟账号的业务数据空间中。

可选的，虚拟账号的业务数据空间与第一应用程序的常规账号的业务数据空间保持一致存储；虚拟账号和常规账号的用户信息区别空间存储。

其中，虚拟账号的业务数据空间与第一应用程序的常规账号的业务数据空间采用同样的存储方式对业务数据进行存储。由于虚拟账号与常规账号并不相同。用户信息可以为用户提交的个人信息。虚拟账号的用户信息为根据业务数据的所属用户对应的用户信息生成的用户信息。因此，第一应用服务平台将虚拟账号和常规账号的用户信息存储在不同的数据空间中。

步骤206、第一应用服务平台将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送。

本实施例的技术方案，通过第一应用服务平台向用户询问是否允许进行业务共享，获取用户的业务共享授权；并通过将用户信息的账号标识直接创建为虚拟账号的账号标识，将用户信息赋值作为虚拟账号的用户信息，为业务数据的所属用户建立虚拟账号，可以提高数据共享过程中的数据安全性，保护用户的隐私，可以更便捷地建立虚拟账户。

实施例三

图3为本公开实施例三提供的一种业务数据的共享实现方法的流程图。本实施例以上述实施例中各个可选方案为基础进行具体化。在本实施例中，第一应用服务平台，为业务数据的所属用户建立虚拟账号具体包括：第一应用服务平台从第二应用服务平台接收业务数据对应用户的用户信息；第一应用服务平台根据用户信息建立关联的虚拟账号，将用户信息赋值作为虚拟账号的用户信息。

可选的，以及，还包括：第一应用服务平台接收用户的账号注册请求或基于第二应用程序账号的授权登录请求时；如果账号注册请求或授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号的用户信息和业务数据空间与账号注册请求或授权登录请求的账号进行关联。

如图3所示，该方法具体包括如下步骤：

步骤301、第一应用服务平台通过平台间接口，向第二应用服务平台发送业务数据共享请求。

步骤302、第二应用服务平台通过第二应用程序客户端向用户询问是否允许进行业务共享，并获取用户的业务共享授权。

步骤303、第一应用服务平台接收第二应用服务平台通过平台间接口反馈的业务数据。

步骤304、第一应用服务平台从第二应用服务平台接收业务数据对应用户的用户信息。

步骤305、第一应用服务平台根据用户信息建立关联的虚拟账号，将用户信息赋值作为虚拟账号的用户信息，将业务数据存储至虚拟账号的业务数据空间中。

其中，第一应用服务平台根据用户信息创建虚拟账号的账号标识。创建的虚拟账号的账号标识与业务数据的所属用户对应的账号标识不同，为新的账户标识。将用户信息赋值作为虚拟账号的用户信息，将业务数据存储至虚拟账号的业务数据空间中。

步骤306、第一应用服务平台将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送。

步骤307、第一应用服务平台接收用户的账号注册请求或基于第二应用程序账号的授权登录请求。

其中，新用户在第一应用程序客户端上输入注册信息，进行账号注册时，通过第一应用程序客户端向第一应用服务平台传输账号注册请求。账号注册请求用于请求第一应用服务平台建立对应的新账号。第一应用服务平台接收新用户通过第一应用程序客户端发送的账号注册请求。

第二应用程序的用户可以选择通过第二应用程序的账号登录第一应用程序客户端。当用户在第一应用程序客户端的界面中，选择了通过第二应用程序的账号进行登录的方式时，第一应用程序客户端向第一应用服务平台传输基于第二应用程序账号的授权登录请求。授权登录请求用于第一应用程序请求通过第二应用程序的账号进行登录。第一应用服务平台接收基于第二应用程序账号的授权登录请求。

步骤308、如果账号注册请求或授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号的用户信息和业务数据空间与账号注册请求或授权登录请求的账号进行关联。

其中，第一应用服务平台接收新用户通过第一应用程序客户端发送的账号注册请求，根据账号注册请求获取账号注册请求对应的用户信息，并将账号注册请求对应的用户信息与数据库中存储的虚拟账号的用户信息进行匹配。

如果账号注册请求的用户信息与虚拟账号的用户信息匹配，表明账号注册请求的对应的用户曾经授权第一应用程序进行业务共享，在第一应用程序中有对应的虚拟账号，则将对应的虚拟账号的用户信息和业务数据空间与账号注册请求的账号进行关联。具体的，如果账号注册请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号变更为第一应用程序的常规账号，并将得到的常规账号作为第一应用服务平台根据账号注册请求建立的新账号，反馈至第一应用程序客户端。新账号的用户信息即为账号注册请求的用户信息，新账号的业务数据空间中存储着用户曾经授权第一应用程序进行业务共享的业务数据。用户可以登录新账号，并通过新账号在第一应用程序上进行业务操作。

如果账号注册请求的用户信息与虚拟账号的用户信息不匹配，表明账号注册请求的对应的用户未授权第一应用程序进行业务共享，在第一应用程序中没有对应的虚拟账号，则第一应用服务平台直接根据账号注册请求建立一个对应的新账号，反馈至第一应用程序客户端。

第一应用服务平台接收用户通过第一应用程序客户端发送的基于第二应用程序账号的授权登录请求，根据基于第二应用程序账号的授权登录请求获取授权登录请求对应的用户信息，并将基于第二应用程序账号的授权登录请求对应的用户信息与数据库中存储的虚拟账号的用户信息进行匹配。

如果授权登录请求的用户信息与虚拟账号的用户信息匹配，表明授权登录请求的对应的用户曾经授权第一应用程序进行业务共享，在第一应用程序中有对应的虚拟账号，则将对应的虚拟账号的用户信息和业务数据空间与账号注册请求的账号进行关联。具体的，如果授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号变更为第一应用程序的常规账号，并将得到的常规账号反馈给第一应用程序客户端。用户可以通过该常规账号登录第一应用程序，并在第一应用程序上进行业务操作。

如果授权登录请求的用户信息与虚拟账号的用户信息不匹配，表明授权登录请求的对应的用户未授权第一应用程序进行业务共享，在第一应用程序中没有对应的虚拟账号，则第一应用服务平台根据账号登录请求中的第二应用程序账号建立关联的第一应用程序账号，将第一应用程序账号反馈给第一应用程序客户端进行登录操作。

本实施例的技术方案，通过第一应用服务平台根据用户信息建立关联的虚拟账号；并在第一应用服务平台接收用户的账号注册请求或基于第二应用程序账号的授权登录请求与虚拟账号的用户信息匹配时，将虚拟账号的用户信息和业务数据空间与账号注册请求或授权登录请求的账号进行关联，可以通过账户标识区别业务数据的所属用户的原账户和虚拟账户，可以根据用户的数据共享历史行为提供服务，提高用户体验。

实施例四

图4为本公开实施例四提供的一种业务数据的共享实现装置的结构示意图，本实施例可适用于共享业务数据的情况。该装置可以采用软件和/或硬件的方式实现，一般可配置在诸如第一应用服务平台的计算机设备中。如图4所示，该装置具体包括：共享请求发送模块401、业务数据接收模块402、虚拟账号建立模块403和业务数据推送模块404。

其中，共享请求发送模块401，用于通过平台间接口，向第二应用服务平台发送业务数据共享请求；业务数据接收模块402，用于接收第二应用服务平台通过平台间接口反馈的业务数据；虚拟账号建立模块403，用于为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中；业务数据推送模块404，用于将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送。

本实施例的技术方案，通过第一应用服务平台通过平台间接口，向第二应用服务平台发送业务数据共享请求后，接收第二应用服务平台通反馈的业务数据，为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中，并将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送，解决了现有技术受限于应用程序的用户信息管理机制，难以跨应用程序将其他应用程序用户的业务信息转移到另一应用程序中的问题，可以实现业务数据在不同应用程序之间的共享，从而可以增加新应用程序中的信息更新量，吸引用户。

可选的，在上述技术方案中各个可选方案的基础上，虚拟账号建立模块403可以包括：

第一信息接收单元，用于从第二应用服务平台接收业务数据对应用户的用户信息；

第一账号创建单元，用于将用户信息的账号标识直接创建为虚拟账号的账号标识，将用户信息赋值作为虚拟账号的用户信息。

可选的，在上述技术方案中各个可选方案的基础上，虚拟账号建立模块403可以包括：

第二信息接收单元，用于从第二应用服务平台接收业务数据对应用户的用户信息；

第二账号创建单元，用于根据用户信息建立关联的虚拟账号，将用户信息赋值作为虚拟账号的用户信息。

可选的，在上述技术方案中各个可选方案的基础上，虚拟账号的业务数据空间与第一应用程序的常规账号的业务数据空间保持一致存储；虚拟账号和常规账号的用户信息区别空间存储。

可选的，在上述技术方案中各个可选方案的基础上，可以在第二应用服务平台中配置对应的装置，该装置可包括：授权获取模块，用于通过第二应用程序客户端向用户询问是否允许进行业务共享，并获取用户的业务共享授权。

可选的，在上述技术方案中各个可选方案的基础上，配置在第一应用服务平台的装置可以还包括：

请求接收模块，用于接收用户的账号注册请求或基于第二应用程序账号的授权登录请求时；

账号关联模块，用于如果账号注册请求或授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号的用户信息和业务数据空间与账号注册请求或授权登录请求的账号进行关联。

可选的，在上述技术方案中各个可选方案的基础上，账号关联模块可以包括：

第一账号关联单元，用于如果账号注册请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号变更为第一应用程序的常规账号，并将得到的常规账号作为第一应用服务平台根据账号注册请求建立的新账号，反馈至第一应用程序客户端。

可选的，在上述技术方案中各个可选方案的基础上，账号关联模块可以包括：

第二账号关联单元，用于如果授权登录请求的用户信息与虚拟账号的用户信息匹配，则将虚拟账号变更为第一应用程序的常规账号，并将得到的常规账号反馈给第一应用程序客户端。

本公开实施例所提供的业务数据的共享实现装置可执行本公开任意实施例所提供的业务数据的共享实现方法，具备执行方法相应的功能模块和有益效果。

实施例五

图5为本公开实施例五提供的一种计算机设备的结构示意图。图5示出了适于用来实现本公开实施方式的示例性计算机设备512的框图。图5显示的计算机设备512仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图5所示，计算机设备512以通用计算设备的形式表现。计算机设备512的组件可以包括但不限于：一个或者多个处理器或者处理单元516，系统存储器528，连接不同系统组件(包括系统存储器528和处理单元516)的总线518。

总线518表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa)总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。

计算机设备512典型地包括多种计算机系统可读介质。这些介质可以是任何能够被计算机设备512访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

系统存储器528可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)530和/或高速缓存存储器532。计算机设备512可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统534可以用于读写不可移动的、非易失性磁介质(图5未显示，通常称为“硬盘驱动器”)。尽管图5中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如cd-rom，dvd-rom或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线518相连。存储器528可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本公开各实施例的功能。

具有一组(至少一个)程序模块542的程序/实用工具540，可以存储在例如存储器528中，这样的程序模块542包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块542通常执行本公开所描述的实施例中的功能和/或方法。

计算机设备512也可以与一个或多个外部设备514(例如键盘、指向设备、显示器524等)通信，还可与一个或者多个使得用户能与该计算机设备512交互的设备通信，和/或与使得该计算机设备512能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口522进行。并且，计算机设备512还可以通过网络适配器520与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器520通过总线518与计算机设备512的其它模块通信。应当明白，尽管图5中未示出，可以结合计算机设备512使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。

处理单元516通过运行存储在系统存储器528中的程序，从而执行各种功能应用以及数据处理，例如实现本公开实施例所提供的业务数据的共享实现方法。也即，第一应用服务平台通过平台间接口，向第二应用服务平台发送业务数据共享请求；第一应用服务平台接收第二应用服务平台通过平台间接口反馈的业务数据；第一应用服务平台，为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中；第一应用服务平台将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送。

实施例六

本公开实施例六还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本公开实施例所提供的一种业务数据的共享实现方法，该方法具体可以包括：第一应用服务平台通过平台间接口，向第二应用服务平台发送业务数据共享请求；第一应用服务平台接收第二应用服务平台通过平台间接口反馈的业务数据；第一应用服务平台，为业务数据的所属用户建立虚拟账号，将业务数据存储至虚拟账号的业务数据空间中；第一应用服务平台将虚拟账号的用户信息以及虚拟账号对应的业务数据在第一应用程序客户端进行推送。

本公开实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于无线、电线、光缆、rf等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c++、ruby、go，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

注意，上述仅为本公开的较佳实施例及所运用技术原理。本领域技术人员会理解，本公开不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本公开的保护范围。因此，虽然通过以上实施例对本公开进行了较为详细的说明，但是本公开不仅仅限于以上实施例，在不脱离本公开构思的情况下，还可以包括更多其他等效实施例，而本公开的范围由所附的权利要求范围决定。