CN105741119A - 一种业务实现方法和装置 - Google Patents

Abstract

本申请提供一种业务实现方法和装置。所述方法包括：接收业务提供方终端发送的用户身份信息；根据所述用户身份信息判断是否持有针对用户账号的操作权限；如果持有针对用户账号的操作权限，则在接收到业务提供方终端发送的业务操作请求后，基于所述用户账号完成所述业务操作。本申请服务端可以在持有针对用户账号的操作权限时，基于所述用户账号自动完成用户与业务提供方之间的业务操作，在整个过程中，对于用户而言，突破网络限制，无需用户进行线上操作即可快速实现业务流程，大大提升用户的使用体验。

Description

一种业务实现方法和装置

技术领域

本申请涉及通信技术领域，尤其涉及一种业务实现方法和装置。

背景技术

随着终端技术和互联网的快速发展，用户可以通过终端完成越来越多的业务操作，比如：可以通过终端中装载的购物软件购买物品，可以通过终端中装载的支付软件进行付款操作等。相关技术中，用户在通过终端进行业务操作的前提是终端已处于连网状态，当网络信号较差，或者终端所处地区没有网络覆盖时，将无法实现相关业务，影响用户的使用体验。

发明内容

有鉴于此，本申请提供一种业务实现方法和装置。

具体地，本申请是通过如下技术方案实现的：

一种业务实现方法，应用在服务端，所述方法包括：

接收业务提供方终端发送的用户身份信息；

根据所述用户身份信息判断是否持有针对用户账号的操作权限；

如果持有针对用户账号的操作权限，则在接收到业务提供方终端发送的业务操作请求后，基于所述用户账号完成所述业务操作。

可选的，所述方法还包括：

如果未持有针对用户账号的操作权限，则发送授权申请给所述业务提供方终端，以供所述业务提供方终端将所述授权申请发送给用户终端；

在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限；

其中，所述用户终端基于所述用户账号登录服务端。

可选的，所述方法还包括：

如果未持有针对用户账号的操作权限，则发送授权申请给基于所述用户账号登录的用户终端；

在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限。

可选的，所述方法还包括：

在未持有针对用户账号的操作权限时，基于所述用户账号的历史业务信息判断所述用户账号是否满足预设的信用基准；

如果所述用户账号满足所述预设的信用基准，则执行发送授权申请的流程。

可选的，所述业务提供方为收款方，所述业务操作请求为收款请求，所述操作权限为支付权限，所述业务操作为支付操作。

一种业务实现装置，应用在服务端，所述装置包括：

信息接收单元，接收业务提供方终端发送的用户身份信息；

权限确认单元，根据所述用户身份信息判断是否持有针对用户账号的操作权限；

业务执行单元，如果持有针对用户账号的操作权限，则在接收到业务提供方终端发送的业务操作请求后，基于所述用户账号完成所述业务操作。

可选的，所述装置还包括：

第一申请单元，如果未持有针对用户账号的操作权限，则发送授权申请给所述业务提供方终端，以供所述业务提供方终端将所述授权申请发送给用户终端；

第一授权单元，在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限；

其中，所述用户终端基于所述用户账号登录服务端。

可选的，所述装置还包括：

第二申请单元，如果未持有针对用户账号的操作权限，则发送授权申请给基于所述用户账号登录的用户终端；

第二授权单元，在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限。

可选的，所述装置还包括：

信用判断单元，在未持有针对用户账号的操作权限时，基于所述用户账号的历史业务信息判断所述用户账号是否满足预设的信用基准，在所述用户账号满足所述预设的信用基准时，通知第一申请单元或第二授权单元执行发送授权申请的流程。

可选的，所述业务提供方为收款方，所述业务操作请求为收款请求，所述操作权限为支付权限，所述业务操作为支付操作。

由以上描述可以看出，本申请服务端可以在持有针对用户账号的操作权限时，基于所述用户账号自动完成用户与业务提供方之间的业务操作，在整个过程中，对于用户而言，突破网络限制，无需用户进行线上操作即可快速实现业务流程，大大提升了用户的使用体验。

附图说明

图1是本申请一示例性实施例示出的一种业务实现的应用场景示意图。

图2是本申请一示例性实施例示出的一种业务实现方法的流程示意图。

图3是本申请一示例性实施例示出的另一种业务实现方法的流程示意图。

图4是本申请一示例性实施例示出的一种用于业务实现装置的一结构示意图。

图5是本申请一示例性实施例示出的一种业务实现装置的结构框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1是本申请一示例性实施例示出的一种业务实现的应用场景示意图。

请参考图1，图1示出的应用场景包括用户、业务提供方以及服务端。在本申请中，所述业务提供方可以包括向用户提供业务的单位或者个人，所述业务提供方可以通过终端10接入网络与服务端进行通信，比如：与服务端部署的服务器20进行通信。其中，所述终端10可以包括：手机、平板电脑、PDA(PersonalDigitalAssistant，掌上电脑)、PC机等智能设备，所述业务提供方可以通过终端10中装载的应用程序(Application，APP)与服务器20进行通信。

图2是本申请一示例性实施例示出的一种业务实现方法的流程示意图。

请参考图2，本申请提供一种业务实现方法，所述业务实现方法可以应用在图1所示服务端，下面以应用在服务端提供的服务器20中为例进行描述，所述方法包括有以下步骤：

步骤201，接收业务提供方终端发送的用户身份信息。

在本实施例中，所述用户身份信息通常由用户在线下与业务提供方进行业务往来时提供给业务提供方，所述用户身份信息可以包括：身份证号、护照号等能够识别用户身份的信息。

在本实施例中，业务提供方可以通过终端10将所述用户提供的用户身份信息发送给服务器20。

步骤202，根据所述用户身份信息判断是否持有针对用户账号的操作权限。

基于前述步骤201，服务器20在接收到业务提供方通过终端10发送的用户身份信息后，可以根据所述用户身份信息确定所述用户身份信息绑定的用户账号，然后判断是否持有针对所述用户账号的操作权限。

在本实施例中，所述针对所述用户账号的操作权限可以包括：支付操作、购物操作等，所述操作权限可以由用户预先授予，比如：服务器20可以向用户提供解释所述操作权限的具体条款，用户在同意后可以授权服务器20持有针对其用户账号的操作权限。

步骤203，如果持有针对用户账号的操作权限，则在接收到业务提供方终端发送的业务操作请求后，基于所述用户账号完成所述业务操作。

基于前述步骤202的判断结果，如果服务器20确认已持有针对用户账号的操作权限，则业务提供方可以将其与用户进行下线业务往来的业务操作请求通过终端10发送给服务器20，服务器20可以基于用户账号自动完成所述业务操作，无需用户处理。其中，所述业务操作包括：支付操作、购买操作等。

由以上描述可以看出，本申请服务端可以在持有针对用户账号的操作权限时，基于所述用户账号自动完成用户与业务提供方之间的业务操作，在整个过程中，对于用户而言，突破网络限制，无需用户进行线上操作即可快速实现业务流程，大大提升了用户的使用体验。

下面结合具体的线下场景来描述本申请的实现过程。

仍以图1所示的应用场景为例，假设所述业务提供方为酒店，所述服务端为第三方支付平台，用户为要在酒店入住的客人，则终端10通常为酒店前台服务人员为客人办理入住登记的电脑，服务器20通常为第三方支付平台部署的服务器。

在本实施例中，请参考图3的处理过程，用户在酒店前台办理入住登记时，需要将自己的身份证件提供给前台的服务人员，以身份证为例，用户将自己的身份证提供给前台的服务人员，服务人员可以通过扫描所述身份证获取用户身份信息，所述用户身份信息通常包括：用户姓名、用户照片、用户家庭地址、用户的身份证号等。这里的身份证件除了实体身份证件外，还可以是电子化的身份证件，本申请对此不作特殊限制。

在本实施例中，前台的服务人员可以通过终端10中装载的第三方支付平台提供的客户端软件，将所述用户身份信息发送给服务器20。服务器20在接收到所述用户身份信息后，可以确定所述用户身份信息绑定的用户账号，比如：可以确定用户的身份证号绑定的用户账号。当所述身份证号码未绑定任何用户账号时，服务器20可以在返回未绑定用户账号的消息给终端10后结束后续流程，用户需要按照传统的方式缴纳押金、房款。

当所述身份证号码绑定有用户账号时，服务器20在确定用户账号后，可以判断是否持有针对所述用户账号的支付权限，比如：用户是否已经同意第三方支付平台在用户退房后自动支付房款的相关条款，在本申请中，可以将第三方支付平台在用户退房后自动支付房款的简称为“信用住”。当服务器20确定持有针对所述用户账号的支付权限时，可以向终端10返回确认成功的消息。前台的服务人员可以询问用户是否愿意采用“信用住”的付款方式支付房款，当用户未选择“信用住”的支付方式时，用户需要按照传统的方式缴纳押金、房款。当用户选择“信用住”的支付方式时，服务人员可以将本次订单标记为“信用住”订单，无需向用户收取任何押金和房款，即可让用户入住酒店。

在本实施例中，当用户退房时，前台的服务人员可以打印用户本次入住的消费账单，所述消费账单中可以包括房费以及其他消费，比如：餐费、会议费等。用户签字确认消费无误后即可退房离店。

在本实施例中，前台的服务人员可以在用户签字确认消费账单后，通过终端10将所述消费账单发送给服务器20，服务器20在接收到所述消费账单后，可以基于用户身份信息绑定的用户账号进行扣款操作，并将所扣的款项支付给酒店。

由以上描述可以看出，采用本申请提供的支付方案，对用户而言，用户在入住酒店时无需缴纳押金和房款，避免资金占用，同时用户也无需进行任何线上操作，突破网络限制。对于酒店而言，节省服务人员收取押金、房款等繁琐手续，避免了过多的人工操作，提高办理入住的效率，进而提升用户体验。

可选的，在上述场景中，当服务器20确定未持有针对用户账号的支付权限时，可以基于所述用户账号的历史业务信息判断所述用户账号是否满足预设的信用基准，当所述用户账号满足所述预设的信用基准时，可以发送授权申请给用户，用户可以在授予服务器20上述支付权限后，在本次入住时采用“信用住”的支付方式。

在本实施例中，所述历史业务信息可以包括：信用卡还款情况、违约情况等，所述信用基准可以由开发人员进行设置，较为简单的，开发人员可以将所述信用基准设置为某数值范围。服务器20可以在获取到所述历史业务信息后，量化各历史业务信息，然后基于量化后的历史业务信息，计算用户账号的信用评分，并判断所述信用评分是否满足所述信用基准，当所述信用评分满足所述信用基准时，可以确定用户的信用情况较好，执行发送授权申请的流程。当所述信用评分不满足所述信用基准时，可以确定用户的信用情况尚未达到“信用住”的标准，发送无法使用“信用住”的消息给终端10，用户需要按照传统的方式缴纳押金、房款。当然，依据相关技术，也可以采用其他的方式确定用户的信用，进而确定是否发送授权申请给用户，本申请对此不再一一赘述。

在本实施例中，服务器20可以采用以下两种方式发送授权申请给用户：

第一种方式：服务器20发送授权申请给业务提供方终端，即服务器20发送授权申请给业务提供方的终端10。其中，所述授权申请中通常包括有：开通“信用住”的相关条款。较为简单地，服务器20可以生成包括有所述授权申请的二维码，然后将所述二维码发送给业务提供方的终端10。业务提供方的终端10在接收到所述二维码后，前台的服务人员可以将所述二维码展示给用户，用户可以使用已登录服务端的用户终端(如用户自己的手机)扫描所述二维码，用户终端可以将所述二维码中携带的“信用住”的相关条款展示给用户，用户阅读同意后，可以选择确认的选项，用户终端进而可以向服务器20发送允许授权指令。服务器20在接收到所述允许授权指令后，可以将用户账号标记为已开通“信用住”的账号，并确定持有针对用户账号的支付权限。在完成上述操作后，用户就可以在本次入住时采用“信用住”的付款方式，无需缴纳押金和房款。在本实施例中，上述用户终端为基于所述用户账号登录服务端的终端设备，所述用户终端可以包括：手机、平板电脑等，本申请对此不作特殊限制。

第二种方式，服务器20发送授权申请给基于所述用户账号登录的用户终端。在本实施例中，服务器20可以根据所述用户账号，将所述授权申请推送给已基于所述用户账号登录的用户终端。所述用户终端在接收到所述授权申请后，可以将所述授权申请展示给用户，用户阅读同意后，可以选择确认的选项，用户终端进而可以向服务器20发送允许授权指令。参照第一种方式，服务器20在接收到所述允许授权指令后，可以将用户账号标记为已开通“信用住”的账号，并确定持有针对用户账号的支付权限，服务器20还可以向终端10发送确认采用“信用住”的方式付款的消息等，本申请在此不再一一赘述。

可以理解的是，本申请提供的业务实现方案并不局限于上述酒店入住、支付房款的应用场景。本申请公开的上述业务提供方也可以为其他收款方，比如：餐馆、商铺等，业务操作请求也可以为其他收款请求，比如：收取餐费的请求等，本申请对此不作特殊限制。

与前述业务实现方法的实施例相对应，本申请还提供了业务实现装置的实施例。

本申请业务实现装置的实施例可以应用在服务端上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务端的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请业务实现装置所在服务端的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的服务端通常根据该服务端的实际功能，还可以包括其他硬件，对此不再赘述。

图5是本申请一示例性实施例示出的一种业务实现装置的结构框图。

请参考图5，所述业务实现装置400可以应用在前述图4所示的服务端中，包括有：信息接收单元401、权限确认单元402、业务执行单元403、第一申请单元404、第一授权单元405、第二申请单元406、第二授权单元407以及信用判断单元408。

其中，所述信息接收单元401，接收业务提供方终端发送的用户身份信息；

所述权限确认单元402，根据所述用户身份信息判断是否持有针对用户账号的操作权限；

所述业务执行单元403，如果持有针对用户账号的操作权限，则在接收到业务提供方终端发送的业务操作请求后，基于所述用户账号完成所述业务操作。

所述第一申请单元404，如果未持有针对用户账号的操作权限，则发送授权申请给所述业务提供方终端，以供所述业务提供方终端将所述授权申请发送给用户终端；

所述第一授权单元405，在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限；

其中，所述用户终端基于所述用户账号登录服务端。

所述第二申请单元406，如果未持有针对用户账号的操作权限，则发送授权申请给基于所述用户账号登录的用户终端；

所述第二授权单元407，在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限。

所述信用判断单元408，在未持有针对用户账号的操作权限时，基于所述用户账号的历史业务信息判断所述用户账号是否满足预设的信用基准，在所述用户账号满足所述预设的信用基准时，通知第一申请单元或第二授权单元执行发送授权申请的流程。

可选的，所述业务提供方为收款方，所述业务操作请求为收款请求，所述操作权限为支付权限，所述业务操作为支付操作。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种业务实现方法，应用在服务端，其特征在于，所述方法包括：

接收业务提供方终端发送的用户身份信息；

根据所述用户身份信息判断是否持有针对用户账号的操作权限；

如果持有针对用户账号的操作权限，则在接收到业务提供方终端发送的业务操作请求后，基于所述用户账号完成所述业务操作。

2.根据权利要求1所述的方法，其特征在在于，所述方法还包括：

如果未持有针对用户账号的操作权限，则发送授权申请给所述业务提供方终端，以供所述业务提供方终端将所述授权申请发送给用户终端；

在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限；

其中，所述用户终端基于所述用户账号登录服务端。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

如果未持有针对用户账号的操作权限，则发送授权申请给基于所述用户账号登录的用户终端；

在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限。

4.根据权利要求2或3所述的方法，其特征在于，所述方法还包括：

在未持有针对用户账号的操作权限时，基于所述用户账号的历史业务信息判断所述用户账号是否满足预设的信用基准；

如果所述用户账号满足所述预设的信用基准，则执行发送授权申请的流程。

5.根据权利要求1所述的方法，其特征在于，

所述业务提供方为收款方，所述业务操作请求为收款请求，所述操作权限为支付权限，所述业务操作为支付操作。

6.一种业务实现装置，应用在服务端，其特征在于，所述装置包括：

信息接收单元，接收业务提供方终端发送的用户身份信息；

权限确认单元，根据所述用户身份信息判断是否持有针对用户账号的操作权限；

业务执行单元，如果持有针对用户账号的操作权限，则在接收到业务提供方终端发送的业务操作请求后，基于所述用户账号完成所述业务操作。

7.根据权利要求6所述的装置，其特征在在于，所述装置还包括：

第一申请单元，如果未持有针对用户账号的操作权限，则发送授权申请给所述业务提供方终端，以供所述业务提供方终端将所述授权申请发送给用户终端；

第一授权单元，在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限；

其中，所述用户终端基于所述用户账号登录服务端。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第二申请单元，如果未持有针对用户账号的操作权限，则发送授权申请给基于所述用户账号登录的用户终端；

第二授权单元，在接收到所述用户终端发送的允许授权指令后，确定持有针对用户账号的操作权限。

9.根据权利要求7或8所述的装置，其特征在于，所述装置还包括：

信用判断单元，在未持有针对用户账号的操作权限时，基于所述用户账号的历史业务信息判断所述用户账号是否满足预设的信用基准，在所述用户账号满足所述预设的信用基准时，通知第一申请单元或第二授权单元执行发送授权申请的流程。

10.根据权利要求9所述的装置，其特征在于，

所述业务提供方为收款方，所述业务操作请求为收款请求，所述操作权限为支付权限，所述业务操作为支付操作。