一种线上洽谈签约方法、装置、计算机设备及存储介质

技术领域

本发明涉及信息服务技术领域，可用于金融领域，尤其涉及一种线上洽谈签约方法、装置、计算机设备及存储介质。

背景技术

近年来，由于的持续影响，线下的洽谈签约活动难以为继，需要转为纯线上或线上与线下相结合的方式。在原有的线下洽谈过程中，相当重要的一个环节就是现场签约环节，达成合作意向的双方企业签署合约，并在活动现场合影留念，来记录下此次的洽谈成果，同时也能激发其他企业的洽谈热情，吸引更多企业进行签约。

但线上洽谈签约的方式，也称为“云签约”，面临的问题主要有难以确定签约的发起方，可能有单方发送邀请，双方发送邀请，服务人员发送邀请等多种情况，需要分别处理；并且，洽谈过程中难以对洽谈双方的签约意向以及签约状态进行跟踪记录，从而难以及时获得洽谈结果和洽谈匹配的成功率。

有鉴于此，本文旨在提供一种线上洽谈签约方法、装置、计算机设备及存储介质。

发明内容

针对现有技术的上述问题，本文的目的在于，提供一种线上洽谈签约方法、装置、计算机设备及存储介质，以解决现有技术中难以对签约状态进行记录，以及难以根据签约发起方的不同对签约进行不同处理的问题。

本文的具体技术方案如下：

第一方面，本发明实施例提供一种线上洽谈签约方法，方法包括：

接收签约请求，所述签约请求中携带有请求发起方的身份信息和被请求方的身份信息；

根据所述请求发起方的身份信息和被请求方的身份信息，判断所述请求发起方是否为参与线上洽谈签约的第一用户，以及所述被请求方是否为参与线上洽谈签约的第二用户；

若是，将所述签约请求转发至所述被请求方，并将表征签约状态的状态机中的签约状态由未签约变更为单方意向签约；

响应于被请求方对所述签约请求的同意操作，将所述签约状态由单方意向签约变更为双方意向签约；或，响应于被请求方对所述签约请求的拒绝操作，维持所述签约状态为单方意向签约。

进一步地，当响应于被请求方对所述签约请求的同意操作，将所述签约状态由单方意向签约变更为双方意向签约后，所述方法还包括：

将所述请求发起方的洽谈页面和所述被请求方的洽谈页面跳转至签约页面，并将所述签约状态由双方意向签约变更为签约中。

具体地，所述方法还包括：

根据所述请求发起方的身份信息和被请求方的身份信息，判断所述请求发起方是否为线上洽谈签约的服务方，以及判断所述被请求方是否为参与线上洽谈签约的第一用户和第二用户；

若是，则将所述签约请求转发至第一用户和第二用户；

判断第一用户和第二用户是否均对所述签约请求进行了同意操作；

若是，则响应于第一用户和第二用户对所述签约请求的同意操作，将所述签约状态由未签约变更为双方意向签约。

进一步地，所述方法还包括：

若第一用户和第二用户中有且仅有一方对所述签约请求进行了同意操作，则响应于有且仅有一方对所述签约请求的同意操作，将所述签约状态由未签约变更为单方意向签约；

若第一用户和第二用户均未对所述签约请求进行同意操作，则维持所述签约状态为未签约。

优选地，将所述签约请求转发至所述被请求方之后，所述方法还包括：

等待时长为第一预设值的一段时间；

判断在该时长为第一预设值的一段时间结束时，所述被请求方是否对所述签约请求进行应答操作，所述应答操作包括同意操作和拒绝操作；

若所述被请求方未对所述签约请求进行应答操作，则判定所述被请求方拒绝所述请求发起方的签约请求；

若被请求方对所述签约请求进行了应答操作，则根据所述应答操作执行相应动作。

进一步地，所述方法还包括：

判断在接收到第一用户对第二用户的签约请求后，在时长为第二预设值的一段时间内是否接收到第二用户对第一用户的签约请求；

若是，则将所述签约状态由未签约变更为双方意向签约。

第二方面，本文提供一种线上洽谈签约装置，包括：

接收模块，用于接收签约请求，所述签约请求中携带有请求发起方的身份信息和被请求方的身份信息；

判断模块，用于根据所述请求发起方的身份信息和被请求方的身份信息，判断所述请求发起方是否为参与线上洽谈签约的第一用户，以及所述被请求方是否为参与线上洽谈签约的第二用户；

转发与变更模块，用于当请求发起方为参与线上洽谈签约的第一用户且被请求方为参与线上洽谈签约的第二用户时，将所述签约请求转发至所述被请求方，并将表征签约状态的状态机中的签约状态由未签约变更为单方意向签约；

响应模块，用于响应于被请求方对所述签约请求的同意操作，将所述签约状态由单方意向签约变更为双方意向签约；或用于响应于被请求方对所述签约请求的拒绝操作，维持所述签约状态为单方意向签约。

第三方面，本文提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述技术方案提供的方法。

第四方面，本文还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述技术方案提供的方法。

第五方面，本文还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述技术方案提供的方法。

采用上述技术方案，本文提供的一种线上洽谈签约方法、装置、计算机设备及存储介质，能够根据不同的发起方对签约进程进行跟踪；并通过记录下的洽谈签约过程中签约双方的签约状态对洽谈签约的成功率进行统计；还可以通过签约状态中对参与双方签约意愿的分析，为后续洽谈签约活动组织提供指导依据。

为让本文的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1为本文实施例中提供的一种线上洽谈签约方法的步骤示意图；

图2为本文实施例中状态机中签约状态流转过程示意图；

图3为本文实施例中另一种线上洽谈签约方法的步骤示意图；

图4为本文实施例中提供的一种线上洽谈签约装置的结构示意图；

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

附图符号说明：

410、接收模块；

420、判断模块；

430、转发与变更模块；

440、响应模块；

502、计算机设备；

504、处理器；

506、存储器；

508、驱动机构；

510、输入/输出模块；

512、输入设备；

514、输出设备；

516、呈现设备；

518、图形用户接口；

520、网络接口；

522、通信链路；

524、通信总线。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

需要说明的是，本文的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

线上洽谈签约，也称为“云签约”，现有的线上洽谈签约方法存在的问题主要有：难以确定签约过程的发起方，对于一方客户向另一方客户发送的邀请、双方客户互相发送的邀请以及服务人员向双方客户发送的邀请等多种不同发起情况难以进行区分处理；并且，难以对洽谈双方的签约意向以及签约状态进行跟踪记录，从而难以及时获得洽谈结果和洽谈匹配的成功率。

为了解决上述问题，本文实施例提供了一种线上洽谈签约方法、装置、计算机设备及存储介质。需要说明的是，本文提供的一种线上洽谈签约方法、装置、计算机设备及存储介质可用于金融领域，也可用于除金融领域之外的任意领域，本文对线上洽谈签约方法、装置、计算机设备及存储介质的应用领域不做限定。图1是本文实施例提供的一种线上洽谈签约方法的步骤示意图，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。具体的，所述方可应用于服务器侧，如图1所示，所述方法可以包括：

S110：接收签约请求，所述签约请求中携带有请求发起方的身份信息和被请求方的身份信息。

S120：根据所述请求发起方的身份信息和被请求方的身份信息，判断所述请求发起方是否为参与线上洽谈签约的第一用户，以及所述被请求方是否为参与线上洽谈签约的第二用户。

进一步地，对请求发起方的身份信息进行记录。

S130：若是，将所述签约请求转发至所述被请求方，并将表征签约状态的状态机中的签约状态由未签约变更为单方意向签约。

当线上洽谈签约的参与者是第一用户和第二用户，且第一用户向第二用户发起了签约请求时，此时已表明第一用户自身同意了洽谈签约，因此，将状态机中的签约状态从未签约(即洽谈签约参与双方均未同意签约的状态)变更流转为单方意向签约(即表征参与方中有一方有签约意向的状态)。并将签约请求转发给被请求方，也即是第二用户。需要说明的是，本说明书实施例中，所述签约请求的接收和转发可基于 Websocket协议实现，Websocket协议可支持在用户端和服务器之间进行交互式通信会话。且其在客户端和服务器之间交还数据时，用于协议控制的数据包头部相对较小，控制开销和延时均可大幅减少，可以更快速、更高效率获取信息，提高用户体验。

S140：响应于被请求方对所述签约请求的同意操作，将所述签约状态由单方意向签约变更为双方意向签约；或，响应于被请求方对所述签约请求的拒绝操作，维持所述签约状态为单方意向签约。

在第一用户已同意洽谈签约的前提下，此时只需考虑第二用户是否同意了该签约请求，当第二用户同意了签约请求进行了同意操作(具体可以是第二用户在其客户端上点击了同意签约按钮等)时，即参与双方均同意了签约，则服务器响应于第二用户的同意操作，将状态机中的签约状态从单方意向签约变更为双方意向签约；当二用户拒绝了签约请求进行了拒绝操作(具体可以是第二用户在其客户端上点击了拒绝签约按钮等)时，服务器响应于第二用户的拒绝操作，使状态机中的签约状态仍单方意向签约，即参与者只有一方(第一用户)同意了签约请求。需要说明的是，状态机中记录的签约状态是关联有第一用户与第二用户的，比如，对于单方意向签约进一步记录有同意签约的一方的信息。

本说明书实施例中，所述状态机中签约状态的变更可由服务器定时轮询相应接口来获取洽谈签约的参与者是否发送签约请求或是否接受签约请求，以变更流程状态机中的签约状态。

本说明书实施例提供的一种线上洽谈签约方法，通过状态机记录下洽谈签约参与方在洽谈签约过程中详细的签约状态，有利于对洽谈签约的成功率进行统计；还可以通过记录有签约请求发起方的信息，可用于对参与双方签约意愿的分析，并为后续洽谈签约活动组织的指导依据，例如，如何确定一场线上洽谈签约的参与双方。

需要说明的是，由于本说明书实施例提供的一种线上洽谈签约方法，完整记录了洽谈双方的签约状态，因此，签约状态还可以用于当洽谈签约的参与方因网络问题或其他问题中断了洽谈时快速回归到线上洽谈签约活动中的指引标记。例如，参与洽谈签约的其中一方意外中断了当前的洽谈签约，且此时状态机中记录的签约状态为单方意向签约，则当该参与方重新进入洽谈流程时，可根据此时状态机中的签约状态从单方意向签约的进度继续后续的洽谈，而无需从参与双方初始进入洽谈的未签约状态开始。也就是说，通过状态机中对签约状态的流转进行记录，不仅可以对洽谈签约双方的洽谈结果进行记录，还可以提高业务流程的闭环性，提高用户洽谈签约时的参与体验。

进一步地，当响应于被请求方对所述签约请求的同意操作，将所述签约状态由单方意向签约变更为双方意向签约后，所述方法还可以包括：

将所述请求发起方的洽谈页面和所述被请求方的洽谈页面跳转至签约页面，并将所述签约状态由双方意向签约变更为签约中。

即当第一用户和第二用户均同意了洽谈签约时，可分别将第一用户和第二用户的客户端从洽谈页面跳转至签约页面，以促成签约的完成。

需要说明的是，当第一用户和第二用户的客户端跳转至签约页面时，洽谈页面可以呈缩小的状态(例如，签约文件展示在用户客户端的左侧，洽谈页面缩小并位于右侧)，并不会中断，也就是说在签约时，第一用户和第二用户仍可以通过洽谈页面听见和/或看见对方，从而获知对方是否完成签约，以及满足双方在签约过程中交流的需要。

如图2所示，为状态机中签约状态流转过程示意图，当洽谈签约的双方均通过签约页面完成签约后，所述状态机中的签约状态还可以进一步地从签约中流转至签约完成。还可以将第一用户和第二用户的客户端从签约页面跳转回洽谈页面。并且，服务器还可以进一步将完成签约的签约文件下载或者发送到用户指定邮箱，供用户保存、记录。

需要说明的是，当用户进入签约界面后，还可以取消签约，则状态机中的签约状态又会从签约中变更回单方意向签约或未签约。对于签约双方曾达成过双方意向签约又未能成功签约的情况，状态机中保存有完整的签约状态的流转记录，以便于后续调研未能成功签约的缘由，以及用于后续对线上洽谈签约参与双方的推荐。

在一些其他可行的实施例中，线上洽谈签约除第一用户和第二用户外，还可以有主持人、翻译人员等服务方，则如图3所示，所述方法还可以包括：

S310：根据所述请求发起方的身份信息和被请求方的身份信息，判断所述请求发起方是否为线上洽谈签约的服务方，以及判断所述被请求方是否为参与线上洽谈签约的第一用户和第二用户。

S320：若是，则将所述签约请求转发至第一用户和第二用户。

也就是说，在一些可行应用的场景中，服务方可向参与洽谈签约的第一用户和第二用户发起签约请求，以起到加快签约进程、促成签约的效果，则此时服务器将服务方发起的签约请求转发至第一用户和第二用户，此时，状态机中的签约状态为未签约。

S330：判断第一用户和第二用户是否均对所述签约请求进行了同意操作。

则此时需分别判断第一用户和第二用户是否同意所述签约请求。

S340：若是，则响应于第一用户和第二用户对所述签约请求的同意操作，将所述签约状态由未签约变更为双方意向签约。

也就是说，当且仅当参与洽谈签约的双方用户均同意了签约请求进行了同意操作时，状态机中的签约状态才会从未签约变更为双方意向签约。

可以理解的，所述方法还可以包括：

若第一用户和第二用户中有且仅有一方对所述签约请求进行了同意操作，则响应于有且仅有一方对所述签约请求的同意操作，将所述签约状态由未签约变更为单方意向签约；

若第一用户和第二用户均未对所述签约请求进行同意操作，则维持所述签约状态为未签约。

从而，本说明书实施例提供的线上洽谈签约方法，不论签约请求的发起方是参与洽谈签约的其中一方还是洽谈签约的服务方，都可以顺利的推进签约进程并准确的记录洽谈签约中的签约状态，可满足不同签约场景的需求，应用广泛；并通过签约状态，可实现对洽谈签约的成功率进行统计。

在一些优选的实施例中，将所述签约请求转发至所述被请求方之后，包括签约请求的发起方是参与洽谈签约的其中一方，被请求方是参与洽谈签约的另一方的情况；也包括签约请求的发起方是洽谈签约的服务方，被请求方是参与洽谈签约的双方用户的情况，此时，所述方法还可以包括：

等待时长为第一预设值的一段时间；

判断在该时长为第一预设值的一段时间结束时，所述被请求方是否对所述签约请求进行应答操作，所述应答操作包括同意操作和拒绝操作；

若所述被请求方未对所述签约请求进行应答操作，则判定所述被请求方拒绝所述请求发起方的签约请求。

若被请求方对所述签约请求进行了应答操作，则根据所述应答操作执行相应动作。

示例性的，第一预设值可以设置为10分钟。则判断在被请求方接收到请求发起方的签约请求后的这10分钟内，被请求方是否同意了该签约请求或是否拒绝了该签约请求，还是未对该签约请求作出应答。

当在这10分钟结束时，被请求方若未对签约请求进行应答操作，则可以默认为被请求方不同意该签约请求，也就是拒绝了该签约请求。当发起方是参与洽谈签约的其中一方(比如第一用户时)，被请求方(即为第二用户)默认拒绝了第一用户的签约请求，则此时状态机中对应的签约状态应为单方意向签约。当签约请求的发起方是洽谈签约的服务方，被请求方是参与洽谈签约的用户(第一用户和第二用户)，则进一步地，若第一用户和第二用户均默认拒绝了服务方发起的签约请求，则此时状态机中对应的签约状态应为未签约；若第一用户和第二用户中有一方默认拒绝了服务方发起的签约请求，则还需根据另一方对签约请求的具体响应类型确定状态机中的签约状态。

也就是说，本说明书实施例中，通过设置时长为第一预设值的一段时间，使得被请求方对发起方的签约请求有“再考虑一下”的时间，避免被请求方在冲动下贸然选择做出不符合本意的响应举动；同时，被签约方可以通过在这时长为第一预设值的一段时间内不做出应答操作来婉转的表达自身不同意与请求方签约的意愿，更能体现人情关怀，避免冲突纠纷。

在一些优选的实施例中，所述方法还可以包括：

判断在接收到第一用户对第二用户的签约请求后，在时长为第二预设值的一段时间内是否接收到第二用户对第一用户的签约请求；

若是，则将所述签约状态由未签约变更为双方意向签约。

示例性的，第二预设值可以设置为10秒，当第一用户向第二用户发送签约请求的10秒内，第二用户也向第一用户发送了签约请求，则第二用户将收到第一用户发起的签约请求，第一用户也将接受到第二用户发起的签约请求。也就是说，参与洽谈签约的双方用户均有较大意愿与对方达成合作，并几乎在同一时刻向对方发起了合作请求，此时，可无需在状态机中将签约状态从未签约经单方意向签约流转至双方意向签约，而直接从未签约直接变更为双方意向签约，并可跳过双方用户对签约请求的应答操作直接将其客户端的洽谈页面跳转至签约页面。

需要说明的是，当第二用户拒绝第一用户的签约邀请后或第二用户默认拒绝第一用户的签约邀请后(洽谈签约未结束的前提下)，第一用户可以再次发起签约请求，当然，第二用户也可以向第一用户发起签约请求，可避免第二用户误操作拒绝按钮导致拒绝了签约请求的情况，可起到提高签约成功率的作用。

需要说明的是，本说明书实施例提供的线上洽谈签约方法，还可以扩展到洽谈签约的参与方不只有第一用户和第二用户的情况，即一场洽谈签约可以有更多的参与方，例如，可将业务类型相同或相近、经营类目相同或相近的多个用户划分到同一场线上洽谈签约中。

示例性的，第一用户、第二用户、第三用户和第四用户被划分至同一场线上洽谈签约活动中，则其中任意一个用户可发起对其他任意一个或多个用户的签约请求，任意一个用户也可接受其他一个或多个用户发起的签约请求。例如，第一用户可以分别向第二用户和第四用户发起签约请求，也可以收到第二用户和第三用户向其发起的签约请求。具体地，在第二用户和第四用户均同意了第一用户发起的签约请求后，可根据第二用户和第四用户对签约请求的同意操作的执行时间，依次进行签约。例如，第二用户在第四用户前先同意了与第一用户的签约请求，则服务器可先执行将第一用户和第二用户的洽谈页面跳转至签约页面的操作以使第一用户与第二用户完成签约；再执行将第一用户和第四用户的洽谈页面跳转至签约页面的操作。则状态机中不仅记录有该场线上洽谈签约的签约状态，还记录有签约状态对应的用户信息，例如，记录的“双方意向签约”是对应、关联于第一用户与第二用户的。

进一步地，当记录有洽谈签约的签约状态后，还可以根据签约状态指导洽谈签约活动的组织，例如，可以采用如下方法：

获取用户的历史洽谈签约的签约状态；

获取用户的历史洽谈签约中签约状态为签约成功时对应的对方用户；

获取对方用户的用户信息；

根据对方用户的用户信息，向用户推荐洽谈签约的对方。

用户历史洽谈签约的签约状态包括该用户在以往历次洽谈签约中是否发起了签约请求、是否同意了其他洽谈签约参与方发起的签约请求、是否同意了签约请求后又取消了签约请求等等，当然也包括了该用户在历次洽谈签约中是否与对方用户(即该用户和该对方用户是同一场线上洽谈签约的参与双方)签约成功。

当该用户与对方用户在某次洽谈签约中签约成功时，可以理解为该对方用户与该用户的需求存在匹配关系，从而，对于与该对方用户相同或相似的其他用户，有极大的可能性能够与该用户能够达成合作。因此，可在该对方用户的基础上为该用户推荐下一次线上洽谈签约的对象。

本说明书实施例中，对方用户的用户信息可以包括该对方用户的身份信息(可用于验证该用户是否存在不良行为，例如，是否存在不良信贷记录、是否存在账户冻结情况、是否被列入限制交易名单内等等，从而可降低交易风险)，还包括该对方用户的所属行业、所属领域、业务类型、经营项目、经营产品、所在地区等等。需要说明的是，本说明书实施例中，所述用户信息的获取、存储、使用、处理等均符合国家法律法规的相关规定。

根据对方用户的用户信息，筛选参与线上洽谈签约的所有用户，选择与对方用户在各用户信息维度匹配度最高的一个或多个，向用户进行推荐，可提高洽谈签约的成功率。

当然了，在一些可行的实施例中，还可以获取用户的历史洽谈签约中签约状态为未签约成功时对应的对方用户，作为反向推荐，即避免此类用户在后续的洽谈签约活动中与用户作为参与双方参与到同一场线上洽谈签约中。例如，该用户曾经拒绝过某一对方用户发起的签约请求，则在后续洽谈签约活动中，可避免该用户再次碰到与该对方用户相同或相似的洽谈对象。

如图4所示，本说明书实施例还提供一种线上洽谈签约装置，包括：

接收模块410，用于接收签约请求，所述签约请求中携带有请求发起方的身份信息和被请求方的身份信息；

判断模块420，用于根据所述请求发起方的身份信息和被请求方的身份信息，判断所述请求发起方是否为参与线上洽谈签约的第一用户，以及所述被请求方是否为参与线上洽谈签约的第二用户；

转发与变更模块430，用于当请求发起方为参与线上洽谈签约的第一用户且被请求方为参与线上洽谈签约的第二用户时，将所述签约请求转发至所述被请求方，并将表征签约状态的状态机中的签约状态由未签约变更为单方意向签约；

响应模块440，用于响应于被请求方对所述签约请求的同意操作，将所述签约状态由单方意向签约变更为双方意向签约；或用于响应于被请求方对所述签约请求的拒绝操作，维持所述签约状态为单方意向签约。

通过本说明书实施例提供的装置所取得的有益效果和上述方法所取得的有益效果相一致，此处不再赘述。

如图5所示，为本文实施例提供的一种计算机设备，本说明书实施例中所述的线上洽谈签约装置即可为所述计算机设备以实现本说明书实施例提供的上述线上洽谈签约方法。所述计算机设备502可以包括一个或多个处理器504，诸如一个或多个中央处理单元(CPU)，每个处理单元可以实现一个或多个硬件线程。计算机设备502 还可以包括任何存储器506，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器506可以包括以下任一项或多种组合：任何类型的 RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备502的固定或可移除部件。在一种情况下，当处理器504执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备502可以执行相关联指令的任一操作。计算机设备502还包括用于与任何存储器交互的一个或多个驱动机构508，诸如硬盘驱动机构、光盘驱动机构等。

计算机设备502还可以包括输入/输出模块510(I/O)，其用于接收各种输入(经由输入设备512)和用于提供各种输出(经由输出设备514)。一个具体输出机构可以包括呈现设备516和相关联的图形用户接口(GUI)518。在其他实施例中，还可以不包括输入/输出模块510(I/O)、输入设备512以及输出设备514，仅作为网络中的一台计算机设备。计算机设备502还可以包括一个或多个网络接口520，其用于经由一个或多个通信链路522与其他设备交换数据。一个或多个通信总线524将上文所描述的部件耦合在一起。

通信链路522可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路522可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。

对应于图1和图3中所示的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。

本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图1和图3中所示的方法。

本文实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如图1和图3中所示的方法。

应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。

还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A 和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。

另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。