CN115660685A - 一种业务处理方法、装置和系统 - Google Patents

Abstract

本申请公开一种业务处理方法、装置和系统，获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，用户数据获取请求用于指示获得用户电子凭证对应的数据中与目标前端业务系统相关的部分，从服务端集合中确定与用户数据获取请求匹配的目标服务端，服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合，从目标服务端获取与用户数据获取请求匹配的目标数据，将目标数据反馈至目标前端业务系统，以便其根据获得的目标数据执行对应的业务处理，本申请可实现为用户提供基于电子凭证的值机、托运、安检、登机、商业多场景全流程通关业务办理，解决了旅客乘机过程中多次出示实体凭证和登机牌，降低其出行效率的问题。

Description

一种业务处理方法、装置和系统

技术领域

本申请属于航空信息技术领域，尤其涉及一种业务处理方法、装置和系统。

背景技术

现如今，人们出远门会优先选择搭乘飞机。搭乘飞机涉及到乘客办理登机这一过程，实体凭证作为乘客的身份证明在这个过程中至关重要。乘客需要通过出示实体凭证办理值机、托运、安检、登机一系列的业务，比如：乘客需要使用实体身份凭证办理托运，打印登机牌，在安检环节展示实体身份凭证和登机牌进行身份信息确认、航班信息确认，在登机环节展示登机牌或实体身份凭证进行登机。在整个乘机环节中需要多次出示实体凭证和登机牌，浪费乘客的时间，降低乘客的出行效率。

发明内容

有鉴于此，本申请提供一种业务处理方法、装置和系统，以用于解决在人们选择搭乘飞机出行时在乘客办理登机过程中需要多次出示实体凭证和登机牌，浪费乘客时间，降低乘客出行效率的问题。

为实现解决上述问题，本申请提供如下技术方案：

一种业务处理方法，包括：

获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，所述用户数据获取请求用于指示获得所述用户电子凭证对应的数据中与所述目标前端业务系统相关的部分；

从服务端集合中确定与所述用户数据获取请求匹配的目标服务端；所述服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合；

从所述目标服务端获取与所述用户数据获取请求匹配的目标数据；

将所述目标数据反馈至所述目标前端业务系统，以便所述目标前端业务系统根据获得的目标数据执行对应的业务处理。

一种业务处理装置，包括：

第一获取单元，用于获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，所述用户数据获取请求用于指示获得所述用户电子凭证对应的数据中与所述目标前端业务系统相关的部分；

目标服务端确定单元，用于从服务端集合中确定与所述用户数据获取请求匹配的目标服务端；所述服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合；

第二获取单元，用于从所述目标服务端获取与所述用户数据获取请求匹配的目标数据；

目标数据反馈单元，用于将所述目标数据反馈至所述目标前端业务系统，以便所述目标前端业务系统根据获得的目标用户数据执行对应的业务处理。

一种业务处理系统，包括：

客户端、前端业务系统、通用解码服务端和用于提供数据服务的服务端；

其中，所述前端业务系统至少用于采集客户端的用户电子凭证，并基于采集的用户电子凭证向所述通用解码服务端发起用户数据获取请求；

通用解码服务端，通过执行如上文任一项所述的方法，向发起用户数据获取请求的目标前端业务系统反馈对应的目标数据，以便所述目标前端业务系统根据获得的目标数据执行对应的业务处理。

由以上方案可知，本申请公开的业务处理方法、装置和系统，获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，用户数据获取请求用于指示获得用户电子凭证对应的数据中与目标前端业务系统相关的部分，从服务端集合中确定与用户数据获取请求匹配的目标服务端，服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合，从目标服务端获取与用户数据获取请求匹配的目标数据，将目标数据反馈至目标前端业务系统，以便目标前端业务系统根据获得的目标数据执行对应的业务处理，可见，本申请中，基于用户的电子凭证即可完成不同前端业务系统所需的业务办理，无需用户在不同业务场景进行身份证、登机牌等的出示，可实现为用户提供基于电子凭证的多业务场景全流程的通关业务办理，解决了旅客乘机等应用中在各个环节多次出示实体凭证和登机牌，浪费乘客时间，降低乘客出行效率的问题。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1是本申请提供的业务处理方法的一种流程示意图；

图2是本申请提供的业务处理方法的另一种流程示意图；

图3是本申请提供的业务处理方法的一种应用场景示例图；

图4是本申请提供的基于本申请方法实现的一示例性通关业务服务系统的系统结构图；

图5是本申请提供的基于本申请方法的一种示例性业务流程图；

图6是本申请提供的业务处理装置的组成结构图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本申请公开一种业务处理方法、装置和系统，用于针对对应多业务场景的全业务流程，比如对应安检、行李托运、值机、登机、离港等多个业务场景的旅客乘机全流程等，通过提供基于电子凭证的全流程通关服务业务服务来支持更好的办理业务，节省时间，提高业务办理的效率。

本申请实施例将主要以旅客乘机全流程为例进行方案说明。

参见图1所示的业务处理方法流程图，本申请提供的业务处理方法包括以下处理流程：

步骤101、获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，所述用户数据获取请求用于指示获得所述用户电子凭证对应的数据中与所述目标前端业务系统相关的部分。

以旅客乘机场景为例，前端业务系统具体可以为值机电脑、安检电脑、登机电脑、自助值机设备、自主登机设备、智慧航显设备等不同业务场景的前端业务终端上运行的业务系统。

电子凭证也叫电子证书，电子证书可视为网上身份证，用于网上核实持有人身份。电子凭证可确保数据在电子传送过程中的完整性和保密性，以及保障在有关电子交易完成后，确认双方曾进行交易。目前来说，作为电子凭证的发展，条码的应用已经走进了电子凭证的领域。二维码由于其方便、信息量大、安全、抗损毁、抗污损，走进大家的视野中并广泛应用在各个行业。

本申请实施例中，在旅客出行时，使用电子凭证代替旅客实体身份凭证和登机牌来办理值机、托运、登机、自助、安检、贵宾办理、智慧航显等全流程通关业务。

需要说明，在已知技术中，存在电子凭证在民航出行领域的相关应用，但已知技术中的电子凭证仅能代替实体身份凭证进行身份信息确认，旅客仍需出示登机牌才能办理相关业务。比如旅客需要使用身份凭证办理值机托运，打印登机牌；在安检环节展示身份凭证和登机牌进行身份确认、航班信息确认；在登机环节展示登机牌或身份凭证进行登机等等，导致在整个登机环节中需要旅客多次出示身份凭证和登机牌，为乘机全流程的不同业务办理带来了不便。

针对已知技术中电子凭证未与民航旅客通关业务环节深度融合，不能做到真正的简化旅客乘机时所需的业务流程步骤的问题。本申请通过提出一通用解码服务，并基于该通用解码服务提供面向不同类型电子凭证及不同业务场景的统一通关服务来更好的办理业务。本申请实施例具体通过将电子凭证与移动互联网、加密通信、人脸识别、活体检测、公安认证等技术相结合，为旅客提供统一的平台服务，在电子凭证基础上融合了乘机全流程同业务所需的基于注册认证授权的信息（身份信息和/或业务信息）提取、验证、输出等功能，使旅客在乘机全流程中享受一码在手，畅行无忧的全流程自助出行体验。

本申请方法的处理逻辑具体应用在通用解码服务端，通过在通用解码服务端执行本申请方法的处理逻辑，使得为旅客提供基于电子凭证的乘机全流程业务办理服务。

电子凭证具有不同的类别，比如民航临时乘机证明、EID(electronic Identity,公民网络电子身份标识)等。

电子凭证的获取途径多种多样，比如用户可以通过在民航公安局、或民航提供的客户端app上进行身份注册与电子凭证申请，获得此类机构生成的用于指征用户身份的电子凭证。

示例性的，当旅客需要乘机时，在办理值机、托运、登机、自助、安检、贵宾办理、智慧航显等业务时，每个环节可出示其提前获取的电子凭证来表明其身份，比如从手机等移动终端调出二维码等形式的电子凭证进行出示。值机、托运、登机等前端业务终端可通过外设扫描设备对电子凭证进行信息扫描，得到对应的电子凭证码值，比如二维码码值，电子凭证码值用于唯一标识用户的身份，并且不包括用户姓名、身份证号等敏感信息。

这些前端业务系统通过外设设备采集用户的电子凭证码值之后生成并向通用解码服务端发起用户数据获取请求，生成的用户数据请求根据各前端业务系统实际对应业务场景的不同而不同，用户数据请求用于指示获得所述用户电子凭证对应的数据中与所述目标前端业务系统相关的部分。

具体的，用户数据获取请求是根据扫描结果信息以及业务场景相关信息组装生成的请求，该请求可以包括但不限于电子凭证码值、扫描设备号、扫描设备类型、扫描使用场景等信息。其中，扫描设备类型代表着本扫描设备属于哪个前端业务系统，比如值机业务系统、预安检业务系统、安检业务系统、离港业务系统、登机业务系统等。扫描使用场景体现的是该扫描设备具体在哪个业务场景下使用，比如预安检、安检、值机、登机等。

示例性的，自助值机和自助托运前端业务系统在识别到电子凭证时调用通用解码服务，根据自助设备上的扫描设备获取的电子凭证信息，请求通用解码服务，以通过请求通用解码服务来获取该电子凭证对应的旅客姓名、身份证号等身份信息，以便于为后续自助值机或自助行李托运等业务提供所需身份数据。

安检前端业务系统在识别到电子凭证时调用通用解码服务，根据自助设备上的扫描设备获取的电子凭证信息，请求通用解码服务，以请求获取该电子凭证对应的旅客姓名、证件号、注册人脸照片等身份信息，以及航班日期、航班号等业务数据，以便为后续的安检业务办理提供所需的身份数据及业务数据。后续，安检前端业务系统可通过现场采集旅客过检人脸照片，与电子凭证的注册人脸照片进行比对，并在身份信息、航班信息确认无误后，过检放行。

步骤102、从服务端集合中确定与所述用户数据获取请求匹配的目标服务端；所述服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合。

本申请实施例预先提供多个服务端，包括至少一个用于提供用户身份信息的服务端，以及至少一个用于提供业务数据的服务端，其中，用于提供用户身份信息的服务端可以包括但不限于民航公安局、民航等所提供的用户身份数据系统/服务器形成的服务端，用于提供业务数据的服务端包括旅客乘机全流程所需的不同业务数据的数据服务系统/服务器形成的服务端。

相应在形成的服务端集合中，包括用于提供用户身份信息的服务端集合、以及用于提供业务数据的服务端集合，通过提供的服务端集合使得为通用解码服务端提供所需的数据支撑。

通用解码服务端在接收到业务前端系统的用户数据获取请求后，解析该请求，并根据解析结果确定用户电子凭证的凭证类型和目标服务端对应的业务场景。

之后，通用解码服务端从用于提供用户身份数据的服务端集合中确定与用户电子凭证的凭证类型匹配的服务端，得到第一目标服务端。

其中，通用解码服务端具体可根据电子凭证码值识别其所对应的凭证类型，电子凭证的凭证类型可以是但不限于民航临时乘机证明、EID等不同类型，相应可根据电子凭证的凭证类型确定民航的用户身份系统或者公安局用户身份系统等作为第一目标服务端。

除此之外，通用解码服务端还可以从用于提供业务数据的服务端集合中确定与解析出的业务场景匹配的服务端，得到第二目标服务端。例如，根据业务场景的不同，具体确定出航班数据系统的服务器或者安检信息系统的服务器作为第二目标服务端等。

需要说明，实际应用中，某些业务场景可能仅需提供所需的用户身份数据即可完成业务处理，也即此类业务场景无需业务数据的获取，相应可跳过确定与解析出的业务场景匹配的服务端的步骤（或者，也可视该步骤确定出的第二目标服务端为空）。

步骤103、从所述目标服务端获取与所述用户数据获取请求匹配的目标数据。

之后，通用解码服务端进一步从第一目标服务端获取用户的身份数据，如用户姓名、身份证号、注册的人脸数据等，以及从第二目标服务端获取用户在对应业务场景下所需的业务数据，如航班号、航班日期等。

需要说明，在有些业务场景中的第二目标服务端可能为空，以至于从第二目标服务端获取所述用户在所述业务场景下所需的业务数据也为空。原因是该业务场景中不需要业务数据，仅需要用户身份信息。

示例性的，在登机和值机环节，离港值机和登机的业务系统只需要其对应的目标服务端返回旅客的姓名、证件号，即可完成后续的值机或登机服务，所以在该情况下，通用解码服务端解析用户数据请求之后仅需从服务端集合中确定与电子凭证类型对应的用于提供用户身份数据的服务端，并从该服务端获取用户的姓名、身份证号、注册的人脸数据等身份数据即可。从而，获得的目标数据至少包括用户身份数据，在一些业务场景中，目标数据还包括与所处业务场景对应的业务数据。

步骤104、将所述目标数据反馈至所述目标前端业务系统，以便所述目标前端业务系统根据获得的目标数据执行对应的业务处理。

在从相应服务端获得与用户数据获取请求匹配的目标数据后，通用解码服务端将目标数据反馈至目标前端业务系统，目标前端业务系统将接收到的目标数据进行解密后进行业务处理。

其中，优选的，目标数据是加密状态，以确保信息传输过程中用户敏感数据的安全性。综上所述，本申请公开的业务处理方法，获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，用户数据获取请求用于指示获得用户电子凭证对应的数据中与目标前端业务系统相关的部分，从服务端集合中确定与用户数据获取请求匹配的目标服务端，服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合，从目标服务端获取与用户数据获取请求匹配的目标数据，将目标数据反馈至目标前端业务系统，以便目标前端业务系统根据获得的目标数据执行对应的业务处理，可见，本申请中，基于用户的电子凭证即可完成不同前端业务所需的业务办理，无需用户在不同业务场景进行身份证、登机牌等的出示，可实现为用户提供基于电子凭证的多业务场景全流程的通关业务办理，解决了旅客乘机等应用中在各个环节多次出示实体凭证和登机牌，浪费乘客时间，降低乘客出行效率的问题。

可选的，在一实施例中，参见图2，本申请提供的业务处理方法，在获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求之前，还可以包括以下处理：

步骤201、确定目标前端业务系统的身份是否合法。若合法，则触发步骤101。

即，通用解码服务端首先验证目标前端业务系统的身份是否合法，在合法基础上，才为目标前端业务系统提供对应的服务，验证步骤如下：

步骤1）通用解码服务端获得目标前端业务系统发送的连接请求。

具体的，在目标前端业务系统向通用解码服务端发起用户数据获取请求之前，首先会向通用解码服务端发起通讯请求，响应于该请求，在通用解码服务端触发对目标前端业务系统的验证。

步骤2）通用解码服务端确定所述连接请求中是否包含目标身份信息。

其中，目标身份信息可以但不限于包括通用解码服务端的账号/密码，目标前端业务系统通过提前获得通用解码服务端的账号/密码等身份信息才能向通用解码服务端进行解码请求，如果没有通用解码服务端的账号/密码等身份信息或者所提供的账号/密码错误，通用解码服务端会认为该目标前端业务系统的身份不合法。

步骤3）若连接请求中包含所述目标身份信息，通用解码服务端基于所述目标身份信息确定目标动态验证信息，并将所述目标动态验证信息发送至所述目标前端业务系统。

若连接请求中包含目标身份信息，通用解码服务端基于该目标身份信息确定目标动态验证信息，并将目标动态验证信息发送至目标前端业务系统。其中，目标动态验证信息可以是前端业务系统通过预先分配好的账号和密码换取的Token（令牌），在后续请求数据交互中，目标前端业务系统可以根据协议在报文中header中，按照token类型+空格+token值的格式要求添加对应的令牌信息，并将组装的报文作为反馈信息反馈至通用解码服务端。

步骤4）通用解码服务端获取所述目标前端业务系统的反馈信息，确定所述反馈信息中是否包含所述目标动态验证信息。

步骤5）若包含所述目标动态验证信息且所述目标动态验证信息当前未失效，确定所述目标前端业务系统的身份合法，并建立与所述目标前端业务系统间的连接。

通用解码服务端进一步验证目标前端业务系统反馈的报文，若其中包含所需的目标动态验证信息（如令牌信息）且该目标动态验证信息当前未失效，则判定目标前端业务系统的身份合法。

相反，如果通用解码服务端获得的目标前端业务系统发来的连接请求中不包括目标身份信息，则该目标前端业务系统的身份不合法。即通用解码服务端没有识别到目标前端业务系统提前获取的通用解码服务端的账号和密码，所以该目标业务系统的身份不合法。

或者，在目标前端业务系统包含目标身份信息前提下，若其向通用解码服务端的反馈信息（即基于token组装的报文）中，目标动态信息不存在或者失效，通用解码服务端同样会判定目标前端业务系统的身份不合法。

如果目标前端业务系统身份合法，则建立与目标前端业务系统间的通信连接，以基于该连接进一步执行步骤101及其后续流程，获得目标前端业务系统基于采集的电子凭证发起的用户数据获取请求，并根据请求内容返回业务所需身份信息和航班信息。否则，若不合法，则拒绝建立与目标前端业务系统间的通信连接，不再执行步骤101及其后续流程。

以下提供一身份验证的具体示例：

首先，通用解码服务模块会验证请求主体的连接请求是否合法，即通过预先分配好的账号和密码换取Token，在后续请求数据交互时，要求前端业务系统在请求报文header中，按照Bearer+空格+token值的格式要求添加令牌信息。如果Token失效或不合法，则判定该请求主体即发起请求的前端业务系统的身份不合法，需要重新获取Token进行认证。

若请求主体的身份合法，通用解码服务模块与请求主体建立连接，之后，通用解码服务模块可基于所建立连接为请求主体提供所需的数据服务（用户身份数据、业务数据）；若请求主体的身份不合法，则不与请求主体建立连接。

综上所述，本实施例在上一实施例的基础上增加了验证目标前端业务系统身份是否合法的步骤。通用解码服务端获取目标前端业务系统发送的连接请求，确定所述连接请求中是否包含目标身份信息，若连接请求中包含目标身份信息，通用解码服务端基于所述目标身份信息确定目标动态验证信息，并将所述目标动态验证信息发送至所述目标前端业务系统，通用解码服务端获取所述目标前端业务系统的反馈信息，确定所述反馈信息中是否包含所述目标动态验证信息，若包含所述目标动态验证信息且所述目标动态验证信息当前未失效，确定所述目标前端业务系统的身份合法，并建立与所述目标前端业务系统间的连接。通用解码服务端在确定目标前端业务系统身份合法的基础上，才为其提供对应的服务，让旅客在安全保密的环境中得到全流程自助出行体验。

可选的，以旅客乘机全流程为例，提供本申请方法的一应用场景示例，参见图3。

该应用场景如图3所示，该场景包括移动手机、业务终端、通用解码服务端三部分。

其中，业务终端可以包括值机柜台（如值机电脑）、安检柜台（如安检电脑）、登机柜台（如登机电脑）、自助值机设备（对应图3中的“自助值机”，如自助值机电脑）、自助托运登机设备（对应图3中的“自助托运”），以及诸如智慧航显设备等其他系统前端。业务终端集成有电子凭证识别程序及业务办理系统，并可以通过通讯网路与通用解码服务端连接，以用于提供电子凭证采集、识别、与通用解码服务端的交互及业务办理等功能。通用解码服务端支持在物理机和虚拟机上部署，可以是独立服务器或集群式部署。移动手机是电子凭证的展示载体，安装有APP客户端或小程序。

示例性的，旅客可预先通过移动手机注册与提交身份信息，并通过活体检测采集注册旅客的人脸图像，相关信息通过无线网络提交至服务器端验证存储，并向旅客反馈对应的电子凭证，如代表其电子身份的二维码。旅客到达机场之后，在值机、托运、安检、登机等流程中的业务终端上出示电子凭证，各业务终端识别出该电子凭证后向通用解码服务端发起连接请求，以请求通讯，通用解码服务端收到来自该业务终端发送的连接请求之后，先判断该业务终端（或其所对应的前端业务系统）的身份是否合法，如果合法，通用解码服务模块与请求主体中的识别程序建立连接，并基于所建立连接为请求主体提供业务办理所需的数据服务。可选的，前端业务系统还能用于采集用户的非电子凭证形式的身份信息，即能够对现有基于实体身份证件的业务办理进行兼容，前端业务系统在采集到用户的身份信息时，识别身份信息的信息类型，响应于识别的信息类型为用户电子凭证，触发向通用解码服务端发起用户数据获取请求的处理，反之，如果识别出信息类型为实体身份证件的类型，则直接将识别出的身份信息（如姓名、身份证号）提供给业务处理流程进行业务处理。

可选的，参见图4，进一步提供了本示例中对应于图3所示场景的通关业务服务系统的系统结构图。

如图4所示，该系统的组成结构包括如下几个模块：

通用解码服务模块、离港前端适配模块、自助设备前端适配模块、安检平台模块、通用接口模块。

通用解码服务模块实现获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，用户数据获取请求用于指示获得所述用户电子凭证对应的数据中与所述目标前端业务系统相关的部分。

通用解码服务模块从服务端集合中确定与所述用户数据获取请求匹配的目标服务端；所述服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合，从所述目标服务端获取与所述用户数据获取请求匹配的目标数据，将所述目标数据反馈至所述目标前端业务系统，以便所述目标前端业务系统根据获得的目标数据执行对应的业务处理。

离港前端适配模块为离港旅客提供离港业务办理。

自助设备前端适配模块为旅客提供自助值机、自助登机等自助业务办理。

安检平台模块为旅客提供安检流程中的业务办理。

通用接口模块，用于实现其它需要支持电子凭证的业务系统与服务器的连接，支持业务系统终端粒度进行升级优化，实施风险可控。

如图5是本申请实施例针对旅客乘机全流程，进一步提供的一种示例性业务处理流程图，其主要包括四个步骤：

离港前端/自助前端/安检前端适配模块识别电子凭证；

向通用解码服务发起电子凭证验证；

若鉴别请求主体合法，则根据请求内容返回业务所需身份信息和航班信息；

离港前端/自助前端/安检前端根据获得的信息办理业务。

其中，离港前端/自助前端/安检前端适配模块识别电子凭证：业务终端上配备电子凭证识别设备，通过软件驱动进行控制。当电子凭证识别设备扫描到电子凭证码值时，会启动识别程序。

向通用解码服务发起电子凭证验证：识别程序对扫描到的码值进行内容甄别，若判定为常规登机牌码值内容，则交由业务应用系统处理，若判定为电子凭证时会连接通用解码服务模块请求通讯。

若鉴别请求主体合法，则根据请求内容返回业务所需身份信息和航班信息：首先，通用解码服务模块会验证该请求是否合法，即通过预先分配好的账号和密码换取Token，并要求请求主体在后续请求数据交互时，需要在请求报文header中，按照token类型（Bearer）+空格+token值的格式要求添加令牌信息。如果Token失效或不合法，则判定该请求主体不合法，需要识别程序重新获取Token进行认证。若请求主体身份合法，通用解码服务模块与识别程序建立连接，识别程序通过HTTP请求将电子凭证识别设备编号、电子凭证数据流、设备类型、使用场景、需要返回数据信息发送给通用解码服务模块，通用解码服务模块根据不同的电子凭证类别向不同服务端解密并返回响应状态、详细数据。其中，根据业务需求，对于离港平台/自助平台，返回的详细数据包括电子凭证识别设备编号、姓名（加密）、身份证件号（加密）。对于安检平台来说，返回的详细数据包括电子凭证识别设备编号、姓名（加密）、身份证件号（加密）、人脸图片、航班号、航班日期等，其中人脸图片以BASE64格式传输。

离港前端/自助前端/安检前端根据获得的信息办理业务；在数据传输过程中，对核心隐私数据采取相应加密算法如SM4进行加密处理，业务终端在获取通用解码服务模块返回的详细数据后，根据预先分配的密钥进行解密，获取对应的真正数据，之后即可按照原业务办理流程为旅客办理业务。

需要说明，附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

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

对于上述的业务处理方法，本申请还提供了一种业务处理装置，该装置的组成结构如图6所示。

第一获取单元10，用于获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，所述用户数据获取请求用于指示获得所述用户电子凭证对应的数据中与所述目标前端业务系统相关的部分；

目标服务端确定单元20，用于从服务端集合中确定与所述用户数据获取请求匹配的目标服务端；所述服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合；

第二获取单元30，用于从所述目标服务端获取与所述用户数据获取请求匹配的目标数据；

目标数据反馈单元40，用于将所述目标数据反馈至所述目标前端业务系统，以便所述目标前端业务系统根据获得的目标数据执行对应的业务处理。

在一实施方式中，目标服务端确定单元20，具体用于：

解析所述用户数据获取请求，根据解析结果确定用户电子凭证的凭证类型和目标服务端对应的业务场景；

从用于提供用户身份数据的服务端集合中确定与所述用户电子凭证的凭证类型匹配的服务端，得到第一目标服务端；

从用于提供业务数据的服务端集合中确定与所述业务场景匹配的服务端，得到第二目标服务端。

在一实施方式中，目标服务端确定单元20，在从所述目标服务端获取与所述用户数据获取请求匹配的目标数据时，具体用于：

从所述第一目标服务端获取所述用户电子凭证所指示用户的身份数据；

从所述第二目标服务端获取所述用户电子凭证所指示用户在所述业务场景下所需的业务数据。

在一实施方式中，目标数据反馈单元40，具体用于：

将加密的目标数据反馈至所述目标前端业务系统。

在一实施方式中，目标前端业务系统，包括：

旅客乘机全流程涉及的多种不同业务场景下的前端业务系统。

在一实施方式中，上述装置还包括：

身份确定单元，用于：确定所述目标前端业务系统的身份是否合法；

若合法，触发所述获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求的步骤。

在一实施方式中，身份确定单元，具体用于：

获得目标前端业务系统发送的连接请求；

确定所述连接请求中是否包含目标身份信息；

若包含所述目标身份信息，基于所述目标身份信息确定目标动态验证信息，并将所述目标动态验证信息发送至所述目标前端业务系统；

获得所述目标前端业务系统的反馈信息，确定所述反馈信息中是否包含所述目标动态验证信息；

若包含所述目标动态验证信息且所述目标动态验证信息当前未失效，确定所述目标前端业务系统的身份合法，并建立与所述目标前端业务系统间的连接。

描述于本公开实施例中所涉及到的单元/模块可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元/模块的名称在某种情况下并不构成对该单元本身的限定，例如，第一获取单元还可以被描述为“获取至少两个网际协议地址的单元”。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列（FPGA）、专用集成电路（ASIC）、专用标准产品（ASSP）、片上系统（SOC）、复杂可编程逻辑设备（CPLD）等等。

另外，本申请实施例还提供一种业务处理系统，包括：

客户端、前端业务系统、通用解码服务端和用于提供数据服务的服务端；

其中，所述前端业务系统至少用于采集客户端的用户电子凭证，并基于采集的用户电子凭证向所述通用解码服务端发起用户数据获取请求；

通用解码服务端，通过执行如上文任一项所述的方法，向发起用户数据获取请求的目标前端业务系统反馈对应的目标数据，以便所述目标前端业务系统根据获得的目标数据执行对应的业务处理。

其中，前端业务系统还能用于采集用户的非电子凭证形式的身份信息。

前端业务系统在采集到用户的身份信息时，还可以识别身份信息的信息类型，响应于识别的信息类型为用户电子凭证，触发向通用解码服务端发起用户数据获取请求的处理。

需要说明，尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的（但不限于）具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (11)

1.一种业务处理方法，其特征在于，包括：

获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，所述用户数据获取请求用于指示获得所述用户电子凭证对应的数据中与所述目标前端业务系统相关的部分；

从服务端集合中确定与所述用户数据获取请求匹配的目标服务端；所述服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合；

从所述目标服务端获取与所述用户数据获取请求匹配的目标数据；

将所述目标数据反馈至所述目标前端业务系统，以便所述目标前端业务系统根据获得的目标数据执行对应的业务处理。

2.根据权利要求1所述的方法，其特征在于，所述从服务端集合中确定与所述用户数据获取请求匹配的目标服务端，包括：

解析所述用户数据获取请求，根据解析结果确定用户电子凭证的凭证类型和目标服务端对应的业务场景；

从用于提供用户身份数据的服务端集合中确定与所述用户电子凭证的凭证类型匹配的服务端，得到第一目标服务端；

从用于提供业务数据的服务端集合中确定与所述业务场景匹配的服务端，得到第二目标服务端。

3.根据权利要求2所述的方法，其特征在于，所述从所述目标服务端获取与所述用户数据获取请求匹配的目标数据，包括：

从所述第一目标服务端获取所述用户电子凭证所指示用户的身份数据；

从所述第二目标服务端获取所述用户电子凭证所指示用户在所述业务场景下所需的业务数据。

4.根据权利要求1所述的方法，其特征在于，在获取所述用户数据获取请求之前，还包括：

确定所述目标前端业务系统的身份是否合法；

若合法，触发所述获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求的步骤。

5.根据权利要求4所述的方法，其特征在于，所述确定所述目标前端业务系统的身份是否合法，包括：

获得目标前端业务系统发送的连接请求；

确定所述连接请求中是否包含目标身份信息；

若包含所述目标身份信息，基于所述目标身份信息确定目标动态验证信息，并将所述目标动态验证信息发送至所述目标前端业务系统；

获得所述目标前端业务系统的反馈信息，确定所述反馈信息中是否包含所述目标动态验证信息；

若包含所述目标动态验证信息且所述目标动态验证信息当前未失效，确定所述目标前端业务系统的身份合法，并建立与所述目标前端业务系统间的连接。

6.根据权利要求4所述的方法，其特征在于，所述用户数据获取请求，包括：

在确定所述目标前端业务系统的身份合法的基础上，获取的已加密的用户数据请求。

7.根据权利要求1所述的方法，其特征在于，所述将所述目标数据反馈至所述目标前端业务系统，包括：

将加密的目标数据反馈至所述目标前端业务系统。

8.根据权利要求1所述的方法，其特征在于，所述目标前端业务系统，包括：

旅客乘机全流程涉及的多种不同业务场景下的前端业务系统。

9.一种业务处理装置，其特征在于，包括：

第一获取单元，用于获取目标前端业务系统根据采集的用户电子凭证所发起的用户数据获取请求，所述用户数据获取请求用于指示获得所述用户电子凭证对应的数据中与所述目标前端业务系统相关的部分；

目标服务端确定单元，用于从服务端集合中确定与所述用户数据获取请求匹配的目标服务端；所述服务端集合为不同业务系统和用户身份数据系统对应的服务端形成的集合；

第二获取单元，用于从所述目标服务端获取与所述用户数据获取请求匹配的目标数据；

目标数据反馈单元，用于将所述目标数据反馈至所述目标前端业务系统，以便所述目标前端业务系统根据获得的目标用户数据执行对应的业务处理。

10.一种业务处理系统，其特征在于，包括：

客户端、前端业务系统、通用解码服务端和用于提供数据服务的服务端；

其中，所述前端业务系统至少用于采集客户端的用户电子凭证，并基于采集的用户电子凭证向所述通用解码服务端发起用户数据获取请求；

通用解码服务端，通过执行如权利要求1-8任一项所述的方法，向发起用户数据获取请求的目标前端业务系统反馈对应的目标数据，以便所述目标前端业务系统根据获得的目标数据执行对应的业务处理。

11.根据权利要求10所述的系统，其特征在于：

所述前端业务系统还能用于采集用户的非电子凭证形式的身份信息；

所述前端业务系统在采集到用户的身份信息时，识别身份信息的信息类型，响应于识别的信息类型为用户电子凭证，触发向通用解码服务端发起用户数据获取请求的处理。

Images