一种业务执行方法及装置

技术领域

本申请涉及信息技术领域，尤其涉及一种业务执行方法及装置。

背景技术

在现代社会中，随着互联网技术的发展，网络中信息呈现爆炸式的增长。而如何利用网络中的海量信息，便成为人们重点关注的问题。

以信息的创造方进行分类，信息可以大致分为两类：用户原创内容(UserGenerated Content，UGC)以及职业生产内容(Occupationally Generated Content，OGC)。通常提供信息的网站(如，视频网站、网络社区、博客、微博等等)的服务器，既可接收信息提供方发布的UGC，也可通过内部创造或者外部购入的方式接收OGC，一并作为提供给信息获取方的信息。

而在现有技术中，提供信息的网站为了提高网站的流量，通常需要更丰富的信息以吸引用户。为了吸引信息提供方发布更多信息，网站通常会以有偿的方式向信息获取方提供信息，并在接收到信息获取方支付的金额后，将该金额支付给信息提供方。在现有技术中，网站通常采用获取即收费方式有偿提供信息。

其过程如图1所示，其中，服务器中存储有信息提供方发布的信息，具体包括以下步骤：

S102：服务器接收信息获取方发送的针对该信息的获取请求，其中，该获取请求包含该信息获取方的账户标识；

S104：根据预先存储的该信息对应的金额支付方式，确定获取该信息的支付金额；

S106：根据该账户标识以及确定出的该支付金额，向该信息获取方发起支付业务；

S108：当确定该支付业务执行成功后，将该信息返回该信息获取方，并将该支付金额支付给该信息提供方。

另外，网站还需要保证发布的信息的质量，以提高客户保持率。而一方面由于UGC是信息提供方自行发布的，所以其质量参差不齐。另一方面，由于网络延时、网络故障等问题，信息获取方可能无法接收到信息或者接收到的信息不完整。

可见，在现有技术中存在信息获取方在支付金额之后，却得到低质量的信息的情况。所以，需要一种新的业务执行方式，来保证信息获取方的用户体验。

发明内容

本申请实施例提供一种业务执行方法，用于解决现有技术中信息获取方在对信息进行支付后，获得低质量的信息，导致信息获取方用户体验差的问题。

本申请实施例提供一种业务执行装置，用于解决现有技术中信息获取方在对信息进行支付后，获得低质量的信息，导致信息获取方用户体验差的问题。

本申请实施例采用下述技术方案：

一种业务执行方法，服务器中存储有信息提供方发布的信息，所述方法包括：

服务器接收信息获取方发送的针对所述信息的获取请求；

向所述信息获取方返回所述信息；

接收所述信息获取方返回的答复结果，当答复结果为确认时，将所述信息获取方的资源分配给所述信息提供方，当答复结果为否认时，不分配所述信息获取方的资源。

一种业务执行方法，包括：

信息获取方向服务器发送针对信息提供方发布的信息的获取请求；

接收所述服务器返回的所述信息；

向所述服务器发送答复结果，以使所述服务器根据所述答复结果，确定是否将所述信息获取方的资源分配所述信息提供方

一种业务执行装置，包括：

存储模块，存储有信息提供方发布的信息；

接收模块，接收信息获取方发送的针对所述信息的获取请求；

发送模块，向所述信息获取方返回所述信息；

分配模块，接收所述信息获取方返回的答复结果，当答复结果为确认时，将所述信息获取方的资源分配给所述信息提供方，当答复结果为否认时，不分配所述信息获取方的资源。

一种业务执行装置，包括：

第一发送模块，向服务器发送针对信息提供方发布的信息的获取请求；

接收模块，接收所述服务器返回的所述信息；

第二发送模块，向所述服务器发送答复结果，以使所述服务器根据所述答复结果，确定是否将所述业务执行装置的资源分配给所述信息提供方。

一种服务器，所述服务器中存储有信息提供方发布的信息，所述服务器包括：一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

所述服务器接收信息获取方发送的针对所述信息的获取请求；

向所述信息获取方返回所述信息；

接收所述信息获取方返回的答复结果，当答复结果为确认时，将所述信息获取方的资源分配给所述信息提供方，当答复结果为否认时，不分配所述信息获取方的资源。

一种终端，包括：一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

向服务器发送针对信息提供方发布的信息的获取请求；

接收所述服务器返回的所述信息；

向所述服务器发送答复结果，以使所述服务器根据所述答复结果，确定是否将所述终端的资源分配给所述信息提供方。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

首先，服务器中存储有信息提供方发布的信息，当接收到信息获取方发送的针对该信息的获取请求时，可先向信息获取方返回该信息，之后在接收到信息获取方返回的答复结果时，若答复结果为确认，则将信息获取方的资源分配给信息提供方，若答复结果为否认，则不分配信息获取方的资源。可见通过本申请提供的方法，可先向信息获取方发送信息，并在后续接收到信息获取方发送的答复结果为确认时，再将信息获取方的资源分配给信息提供方，使得可由信息获取方选择是否对获取信息进行支付，避免了信息获取方为获取到的低质量信息进行支付的弊端，提高了用户体验。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为提供有偿信息的过程；

图2为本申请实施例提供的一种业务执行过程；

图3为本申请实施例提供的信息与资源分配方式的对应关系示意图；

图4为本申请实施例提供的一种业务执行过程；

图5为本申请实施例提供的答复页面的示意图；

图6为本申请实施例提供的一种业务执行装置的结构示意图；

图7为本申请实施例提供的一种业务执行装置的结构示意图；

图8为本申请实施例提供的一种服务器的结构示意图；

图9本申请实施例提供的一种终端的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图2为本申请实施例提供的一种业务执行过程，具体可包括以下步骤：

S202：服务器接收信息获取方发送的针对所述信息的获取请求。

在本申请实施例中，所述的服务器为提供信息的网站的服务器(如，社交网站的服务器)，该信息可以是UGC或者OGC，本申请对此不作具体限定。该网站可以视作是中间平台，一方面为信息提供方提供发布信息的平台，另一方面为信息获取方提供获取信息的平台。则在该网站的服务器中可存储有信息提供方发布的信息，以便当信息获取方需要获取该信息时，提供给该信息获取方。

其中，该信息为有偿提供的信息，即，信息获取方在获取该信息时需要使用一定的资源作为报酬(如，支付相应的资源或虚拟货币等)。于是，服务器在接收信息提供方发布的信息时，还可接收该信息提供方发送的该信息对应资源分配方式，则服务器中还可以存储该信息以及该信息对应的资源分配方式。或者，当该信息提供方未提供资源分配方式时，可由服务器确定该信息的资源分配方式，并存储(例如，将默认的资源分配方式作为该信息的资源分配方式并存储)。

另外，由于该信息可以是UGC而UGC的类型有很多，不同类型的UGC的资源分配方式可以不完全相同，当该信息提供方未提供UGC对应的资源分配方式时，服务器可在接收到UGC时，先确定该UGC的种类，再根据预设的UGC类型与资源分配方式的对应关系，确定该UGC的资源分配方式。其中，预设的UGC类型与资源分配方式的对应关系的示意图可如图3所示。

在图3中可见，在本申请中UGC的类型可包括：文字、图片、视频、音频等等。资源分配方式可包括如：计费周期、计费价格等等。当然，由于在现有技术对如何确定有偿提供的信息的资源分配方式已经有较为成熟的方法，所以本申请可以采用与现有技术相同的方式，确定接收到的信息对应的资源分配方式，本申请对此不做具体限定。

进一步地，服务器在接收到该信息提供方发布的信息后，可将该信息存储在与该服务器对应的数据库中，并通过该服务器提供给信息获取方。具体该信息是存储在该服务器中，还是存储在与该服务器对应的数据库中，本申请并不做具体限定。

在本申请实施例中，服务器可接收信息获取方发送的针对信息的获取请求。其中，信息获取方可以是视为是请求获取信息的用户，或者该用户使用的终端。

例如，对于任一用户，若该用户向服务器提供了UGC，则该用户可视为是发布信息的信息提供方，当该用户向该服务器发送针对一个或多个信息的获取请求时，则该用户可视为是信息获取方。

更进一步地，通常为了方便信息提供方以及服务器对发布的信息进行管理(如，将发布的信息撤回)，信息提供方可还通过在服务器中注册的账户向服务器发送信息，以使服务器将该信息发布在该服务器对应网站上。而当信息获取方请求获取的信息为有偿提供的信息时，信息获取方也需要在服务器中注册账户，以便通过该账户提供一定的资源作为报酬。于是，在本申请实施例中，该获取请求中还可包含信息获取方的账户标识。

需要说明的是，该服务器可以是单独的一台设备，或者由多台设备组成的系统，信息获取方可通过终端向服务器发送获取请求，信息提供方也可通过终端向服务器发送UGC，该终端可以是手机、平板电脑、个人电脑等设备，本申请对此不做具体限定。

S204：向所述信息获取方返回所述信息。

在本申请实施例中，服务器在接收到信息获取方的获取请求后，服务器便可以先根据该获取请求，确定请求获取的信息，并且，即使该信息为有偿提供的信息，服务器也可先将该信息返回该信息获取方。并再后续步骤中根据信息获取方返回的答复信息再确定是否获取信息获取方的资源，并分配给该信息的信息提供方。

S206：接收所述信息获取方返回的答复结果，当答复结果为确认时，将所述信息获取方的资源分配给所述信息提供方，当答复结果为否认时，不分配所述信息获取方的资源。

在本申请实施例中，由于服务器先向信息获取方返回了信息，所以服务器需要等待信息获取方返回答复结果，以根据该答复结果，确定是否将该信息获取方的资源分配给信息提供方。

其中，资源可以是金额，则资源分配方式可为金额支付方式，于是服务器可根据该信息对应的金额支付方式确定的支付金额。为方便描述，后续以金额以及金额支付方式为例进行说明，即，资源可视为是金额，资源分配方式可视为金额支付方式。另外，该答复结果可以是由该信息获取方自行选择后，发送至服务器的。并且，该答复结果包含两种：确认和否认。即，确认进行支付以及拒绝进行支付。

具体的，当服务器接收到息获取方返回的答复结果为确认时，服务器可以将信息获取方的资源分配给信息提供方。由于在步骤S202中，服务器在接收到信息提供方发布的信息时，可以确定与该信息对应的金额支付方式，所以服务器可根据存储的该信息对应的金额支付方式，确定支付金额(即，获取该信息需要支付的金额)，并且根据该支付金额向信息获取方发送支付信息，以使得信息获取方在接收到该支付信息后，向该服务器支付相应的支付金额，则服务器还可获取信息获取方提供的支付金额，并将该支付金额支付该信息提供方。

其中，该信息获取方向服务器支付相应的支付金额可以与现有技术中进行支付业务的过程一致，本申请对此不做具体限定。例如，该支付信息可以是与该支付金额对应的收银台地址链接，则信息获取方在接收到该收银台地址链接后，可跳转至与该支付金额对应的收银台页面，并进行支付业务。

当服务器接收到信息获取方返回的答复结果为否认时，服务器可以不分配获取方的资源。即，服务器可以不向信息获取方发送支付信息，从而不收取信息获取方的金额。可见，若信息获取方获取的信息的质量未达到要求时，即使该信息为有偿提供的信息，信息获取方也可拒绝支付相应的支付金额。从而避免了现有技术中，信息获取方支付了支付金额后，却收到了低质量的信息的情况。同时，另一方面信息提供方也无法通过提供大量的低质量信息，骗取信息获取方的支付金额。使得信息提供方需要提供较高质量的信息时，才可获取信息获取方的支付金额。

另外，由于存在信息获取方获取信息后，没有向服务器返回答复信息的情况(如，由于网络故障、设备故障或者信息获取方忘记答复)，所以当服务器确定向信息获取方发送信息后，等待接收该信息获取方返回的答复结果的时长超过预设时间时，确定接收到信息获取方返回的确认的答复结果，或者确定接收到信息获取方返回的否认的答复结果，并根据该答复结果执行后续操作。即，当超过预设时间后，若还未收到信息获取方的答复结果，则默认该信息获取方返回了确认或者否认的答复信息。

具体的，默认该信息获取方返回了确认的答复信息，还是否认的答复信息可根据需要进行设置，本申请对此不做具体限定。

例如，当向信息获取方发送信息后，等待接收该信息获取方返回的答复结果的时长超过预设时间时，服务器可以根据历史记录中该信息的发送次数以及支付次数(即，针对该信息，服务器接收到确认的答复结果的次数)，确定该信息的支付次数与发送次数的比例，当该比例超过预设值时(如，80％)，确定该答复结果为确认，否则反之。即，当获取该信息的信息获取方中超过预设比例的信息获取方都返回了确认的答复结果时，在向信息获取方发送信息的时长超过预设时间时，确定收到了该信息获取方返回的确认的该答复结果。当然，该预设值可根据需要进行设置。

进一步地，在本申请实施例中，为了避免信息获取方在接收到支付信息后，未能完成支付业务的情况出现，服务器在向信息获取方发送信息之前还可以先根据存储的信息对应的金额支付方式，确定支付金额，并冻结该信息获取方的支付金额，并在后续接收到信息获取方返回的确认的答复信息时，将冻结的支付金额支付给信息提供方。

具体的，服务器可以采用与现有技术中资金冻结方法相同的方法，冻结信息获取方的支付金额，本申请对此不作限定。例如，可以由服务器先从信息获取方的账户中获取支付金额，并暂存在预设账户中，在接收到确认的答复信息时，从该预设账户中将冻结的支付金额支付给信息提供方。或者，也可以是服务器向信息获取方的账户对应的第三方机构(如，银行)发送冻结请求，冻结信息获取方的账户中的支付金额，在接收到确认的答复信息时，向该第三方机构发送转账信息，使第三方机构将信息获取方账户中冻结的支付金额支付给信息提供方。

通过图2所示的业务执行过程，服务器中存储有信息提供方发布的信息。当服务器接收到信息获取方发送的针对该信息的获取请求时，可先根据获取请求确定该信息，将该信息返回信息获取方。并在接收信息获取方返回的答复结果后，根据该答复结果确定是否将信息获取方的资源分配至信息提供方。使得信息获取方可在确定获取的信息符合其需求时，再返回确认的答复结果。可见，通过本申请实施例提供的方法，信息获取方可自行确定是否对获取的信息进行支付。减少了信息获取方为获取到的低质量信息进行支付的概率，提高了信息获取方的用户体验。

另外，在本申请实施例中为了保证业务执行过程中的安全性，以及数据传输过程中的完整性。服务器可以对发送至信息获取方的网络资源进行加密。并且，信息获取方在向服务器发送答复结果时，也可以进行加密。

具体的，信息获取方在服务器中注册账户时，可创建其账户对应的密钥对，并将该密钥对中的公钥发送至服务器进行存储。则服务器可存储信息获取方的账户标识与该公钥的对应关系。则当信息获取方向服务器发送答复结果时，可以通过该密钥对的私钥对答复结果进行签名。使得服务器可在接收到信息获取方发送的答复结果时，根据预先存储的信息获取方的公钥对签名进行验签。并且，当验签通过后，确定信息获取方的答复结果。并且，在本申请实施例中，信息获取方在发送获取请求时，也可以通过该密钥对的私钥对获取请求进行签名，则服务器也可在接收到的信息获取方发送的获取请求时对该获取请求进行验签。也就是说，信息获取方在与服务器进行通讯时均可进行签名，以使服务器进行验签，本申请不再一一列举。

另外，通常为了保证密钥对的安全性，防止由于密钥对泄露导致安全隐患，所以密钥对通常仅存储于创建密钥对的终端中。所以，在本申请实施例中，可由信息获取方的第一终端创建并存储该信息获取方的标识对应的密钥对，并由第一终端发送该公钥至服务器。则服务器中可存储有信息获取方的标识、公钥以及第一终端的设备标识之间的对应关系。

进一步地，由于信息获取方可以在多个设备上登录(即，第一终端可以有多个)，而不同设备之间若共享同一个密钥对则可能导致密钥对泄露，所以信息获取方可在登录的每个设备上创建对应的密钥对，并将公钥发送至服务器。即，信息获取方的标识可对应多个密钥对，于是，在服务器中可存储多个与该信息获取方账户标识对应的公钥。同时，由于密钥对仅存储在创建密钥对的设备中，所以不同的设备中存储的对应同一个信息获取方的标识的密钥对不同。于是，服务器在接收第一终端发送的公钥时，可记录该第一终端的标识，即设备的标识。则服务器中可存储信息获取方的标识、公钥以及设备的标识之间的对应关系。如表1所示。

表1

通过表1所示的对应关系，可见服务器中存储有账户标识A1以及账户标识B1。同一个信息获取方的标识可对应多个公钥，并且每个公钥对应一个设备的标识。则服务器在接收信息获取方发送的获取请求时，可先确定发送请求的设备的标识以及信息获取方的标识。之后可根据存储的设备的标识以及信息获取方的标识的对应关系，对发送请求的设备的标识进行验证。并且，当验证通过后再执行后续步骤。

另外，当验证不通过时，可以确定信息获取方尚未在该设备上创建密钥对，则服务器还可以通知该信息获取方创建密钥对并返回对应的公钥。

当然，上述验证过程可视为一种身份验证过程，并且可在步骤S204向信息获取方返回信息之前进行上述验证过程。需要说明的是，上述验证过程可仅验证信息获取方的账户标识与设备的标识之间的对应关系，而无需根据公钥进行验证，也就是说信息获取方发送的获取请求中也可以不携带签名。则在步骤S204向信息获取方返回信息时，可采用与信息获取方的账户标识与设备的标识均对应的公钥对该信息进行加密，再返回该信息获取方。

另外，在本申请实施例中，为了避免恶意的信息提供方上传低质量的UGC，影响网站提供的网络资源的整体质量。服务器在接收信息提供方上传的信息时，还可冻结信息提供方提供的与该信息对应的保证金额。即，信息提供方还可支付保证金，以保证上传的UGC的质量。

于是，当在步骤S206中，服务器接收到信息获取方发送的答复结果为否认时，服务器可将冻结的保证金额支付给信息获取方，或者，将冻结的保证金额支付给预设账户。即，可视为扣除信息提供方的保证金额。

进一步地，为了避免信息获取方恶意发送否认的答复结果，恶意拒绝对获取的信息进行支付。服务器可周期性的对信息获取方发送否认的答复结果的次数进行累计。并且当接收到信息获取方否认的答复结果时，先判断该信息获取方在当前周期内累计发送否认的答复结果的次数是否超过预设的阈值，若是，则判断该信息获取方为恶意用户，并将冻结的信息获取方的支付金额支付给信息提供方，若否，则根据答复结果执行后续操作。即，在每个累计周期内，任一信息获取方都有发送否认的答复结果的上限。从而避免信息获取方恶意发送否认的答复结果。

更进一步地，在确定信息获取方是否是恶意发送否认的答复结果时，也可根据接收到的针对该信息的否认的答复结果的次数与该信息的发送次数的比例，判断所述比例是否超过预设比例，若是，则确定该信息的质量过低，不将信息获取方的支付金额支付给信息提供方，若否，则将信息获取方的支付金额支付给信息提供方。其中，该预设比例可以根据需要进行设置。

当然，也可采用与现有技术中用户信用计算方法类似的方法，对于每个信息获取方的信用积分进行计算，并仅对信用积分高于预设阈值的用户发送的获取请求进行响应，等等。本申请并不限制采用何种方式规避信息获取方恶意发送拒收信息带来的风险。

需要说明的是，本申请实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤S202和步骤S204的执行主体可以为设备1，步骤S206的执行主体可以为设备2；又比如，步骤S202的执行主体可以为设备1，步骤S204和步骤S206的执行主体可以为设备2；等等。因此，已经对本主题的特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作可以按照不同的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序，以实现期望的结果。在某些实施方式中，多任务处理和并行处理可以是有利的。

基于图2所示业务执行方法，本申请实施例还对应提供一种信息获取方的业务执行过程，如，图4所示。

图4为本申请实施例提供的一种业务执行过程，具体包括以下步骤：

S302：信息获取方向服务器发送针对信息提供方发布的信息的获取请求；

S304：接收所述服务器返回的所述信息；

S306：向所述服务器发送答复结果，以使所述服务器根据所述答复结果，确定是否将所述信息获取方的资源分配给所述信息提供方。

在本申请实施例中，该业务执行过程为与图2所示的业务执行过程对应的，信息获取方执行的业务执行过程，具体过程可如图2所示的过程对应，本申请对此不再赘述。

其中，在步骤S306中，信息获取方可在接收到服务器返回的信息后，再向服务器发送答复结果。具体的，信息获取方可以通过访问服务器，获取答复页面，并通过选择向所述服务器发送答复结果。其中，该答复页面可如图5所示。可见，在答复页面中标明了是对信息A进行答复“是否对信息A进行支付”，且包含确认支付以及拒绝支付的按键，信息获取方可通过对按键的操作，向服务器返回答复结果。

基于图2所示业务执行方法，本申请实施例还对应提供一种业务执行装置的结构示意图，如图6所示。

图6为本申请实施例提供的一种业务执行装置的结构示意图，所述装置包括：

存储模块402，存储有信息提供方发布的信息；

接收模块404，接收信息获取方发送的针对所述信息的获取请求；

发送模块406，向所述信息获取方返回所述信息；

分配模块408，接收所述信息获取方返回的答复结果，当答复结果为确认时，将所述信息获取方的资源分配给所述信息提供方，当答复结果为否认时，不分配所述信息获取方的资源。

所述信息为用户原创内容UGC或者职业生产内容OGC，所述资源为金额。

所述存储模块402，接收所述信息提供方发布的信息以及所述信息对应的金额支付方式，并存储，或者所述存储模块402确定接收到的所述信息对应的金额支付方式并存储。

所述分配模块408，根据存储的所述信息对应的金额支付方式，确定支付金额，根据支付金额向所述信息获取方发送支付信息，获取所述信息获取方根据所述支付信息提供的所述支付金额，并将所述支付金额支付给所述信息提供方。

所述分配模块408，分配所述信息获取方的资源之前，根据存储的所述信息对应的金额支付方式，确定支付金额，冻结所述信息获取方的所述支付金额，所述分配模块408，分配所述信息获取方的资源时，将冻结的所述支付金额支付给所述信息提供方。

所述发送模块406，根据预先存储的所述信息获取方的公钥，对所述信息进行加密后返回所述信息获取方。

所述发送模块406，确定所述信息获取方的设备标识以及账户标识，根据已注册的账户标识与设备标识的对应关系，对所述信息获取方进行身份验证，当身份验证通过时，向所述信息获取方返回所述信息。

所述分配模块408，接收所述信息获取方返回的经过签名的答复结果，根据预先存储的所述信息获取方的公钥对所述签名进行验签，以确定所述答复结果。

所述分配模块408，向所述信息获取方发送所述信息后，在预设时间内未收到所述信息获取方返回的答复结果，确定接收到所述信息获取方返回确认的答复结果，或，向所述信息获取方发送所述信息后，在预设时间内未收到所述信息获取方返回的答复结果，确定接收到所述信息获取方返回否认的答复结果。

所述存储模块402，接收所述信息提供方发布的信息，以及冻结所述信息提供方提供的与所述信息对应的保证金额，所述分配模块408，当答复结果为否认时，将冻结的所述保证金额支付给所述信息获取方，或者，将冻结的所述保证金额支付给预设账户。

具体的，所述业务执行装置可位于提供信息的网站的服务器中，该服务器可以是单独的一台设备或者由多台设备组成的系统，如，分布式系统。

基于图4所示业务执行方法，本申请实施例还对应提供一种信息获取方的业务执行装置的结构示意图，如图7所示。

图7为本申请实施例提供的一种业务执行装置的结构示意图，所述装置包括：

第一发送模块502，向服务器发送针对信息提供方发布的信息的获取请求；

接收模块504，接收所述服务器返回的所述信息；

第二发送模块506，向所述服务器发送答复结果，以使所述服务器根据所述答复结果，确定是否将所述业务执行装置的资源分配给所述信息提供方。

所述业务执行装置可位于信息获取方的终端中，该终端可以是手机、平板电脑、个人电脑等设备。

基于图2所示业务执行方法，本申请实施例还对应提供一种服务器，如图8所示。该服务器中存储有信息提供方发布的信息，所述服务器包括：一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

所述服务器接收信息获取方发送的针对所述信息的获取请求；

向所述信息获取方返回所述信息；

接收所述信息获取方返回的答复结果，当答复结果为确认时，将所述信息获取方的资源分配给所述信息提供方，当答复结果为否认时，不分配所述信息获取方的资源。

基于图4所示业务执行方法，本申请实施例还对应提供一种终端，如图9所示。该终端包括：一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：

向服务器发送针对信息提供方发布的信息的获取请求；

接收所述服务器返回的所述信息；

向所述服务器发送答复结果，以使所述服务器根据所述答复结果，确定是否将所述终端的资源分配给所述信息提供方。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。