数据处理方法、装置、电子设备和介质与流程

1.本公开涉及计算机技术领域，可以应用于金融信息服务技术领域，更具体地涉及一种数据处理方法、装置、设备、介质和程序产品。


背景技术：

2.医保电子凭证是由医保信息平台统一签发，是基于医保基础信息库为全体参保人员生成的医保身份识别电子介质。随着对医保电子凭证大力推广，医保电子凭证逐步替换掉传统的医保实体卡介质，在线下就医过程中，通过刷医保电子凭证实现“医保支付 个账支付”。但在使用过程中，往往会遇到多次展示医保电子凭证进行医疗订单支付，窗口和患者需要多次操作，流程繁琐，加剧用户在缴费大量等待。


技术实现要素：

3.鉴于上述问题，本公开提供了数据处理方法、装置、设备、介质和程序产品，可以通过患者仅进行一次展示医保电子凭证，即可完成个人医保报销和自费现金支付，一次展码完成两种结算，能够减少窗口、用户操作步骤，节省就医时间，提升医疗订单支付效率以及就医体验性。
4.根据本公开的第一个方面，提供了一种数据处理方法，包括响应于接收到医疗机构对应的服务器发送的验证请求，所述验证请求携带医保电子凭证和医疗机构标识，确定与所述医保电子凭证对应的身份是否具有在所述医疗机构标识表示的医疗机构中进行医保混合支付的权限；在确定与所述医保电子凭证对应的身份具有所述权限的情况下，响应于接收到医疗机构对应的服务器发送的结算请求，确定医保混合支付账单，所述医保混合支付账单包括存在医保报销的第一自费账单和不存在医保报销的第二自费账单；以及响应于接收到针对所述医保混合支付账单的支付成功通知，所述支付成功通知携带支付结果信息，将所述支付结果信息发送至与所述医保电子凭证对应的客户端。
5.根据本公开实施例，所述响应于接收到医疗机构对应的服务器发送的验证请求，所述验证请求携带医保电子凭证和医疗机构标识，确定与所述医保电子凭证对应的身份是否具有在所述医疗机构标识表示的医疗机构中进行医保混合支付的权限，包括：确定所述医保电子凭证和所述医疗机构标识之间是否存在预定映射关系；以及在确定所述医保电子凭证和所述医疗机构标识之间存在预定映射关系的情况下，确定与所述医保电子凭证对应的身份具有所述权限。
6.根据本公开实施例，所述数据处理方法还包括：响应于接收到来自用户的开通医保混合支付权限的请求，对所述用户进行实名认证；以及在确定所述用户通过实名认证的情况下，响应于接收到医疗机构标识，开通所述用户在所述医疗机构标识表示的医疗机构中进行医保混合支付的权限。
7.根据本公开实施例，所述数据处理方法还包括：响应于接收到与所述医保混合支付账单对应的电子发票信息，将所述电子发票信息发送至与所述医保电子凭证对应的客户
端。
8.本公开的第二方面提供了一种数据处理装置，包括：第一确定模块，用于响应于接收到医疗机构对应的服务器发送的验证请求，所述验证请求携带医保电子凭证和医疗机构标识，确定与所述医保电子凭证对应的身份是否具有在所述医疗机构标识表示的医疗机构中进行医保混合支付的权限；第二确定模块，用于在确定与所述医保电子凭证对应的身份具有所述权限的情况下，响应于接收到医疗机构对应的服务器发送的结算请求，确定医保混合支付账单，所述医保混合支付账单包括存在医保报销的第一自费账单和不存在医保报销的第二自费账单；以及第一发送模块，用于响应于接收到针对所述医保混合支付账单的支付成功通知，所述支付成功通知携带支付结果信息，将所述支付结果信息发送至与所述医保电子凭证对应的客户端。
9.本公开的第三方面提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得一个或多个处理器执行上述数据处理方法。
10.本公开的第四方面还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述数据处理方法。
11.本公开的第五方面还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述数据处理方法。
12.本实施例提供的数据处理方法，可以通过患者仅进行一次展示医保电子凭证，即可完成个人医保报销和自费现金支付，一次展码完成两种结算，能够减少窗口、用户操作步骤，节省就医时间，提升医疗订单支付效率以及就医体验性。
附图说明
13.通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：
14.图1示意性示出了根据本公开实施例的数据处理方法、装置、设备、介质和程序产品的应用场景图；
15.图2示意性示出了根据本公开实施例的数据处理方法的流程图；
16.图3示意性示出了根据本公开实施例的数据处理装置的结构框图；以及
17.图4示意性示出了根据本公开实施例的适于实现数据处理方法的电子设备的方框图。
具体实施方式
18.以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。在本公开的技术方案中，对数据的获取、收集、存储、使用、加工、传输、提供、公开和应用等处理，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在
此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
19.在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
20.在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。
21.本公开的实施例提供了一种数据处理方法和装置，响应于接收到医疗机构对应的服务器发送的验证请求，验证请求携带医保电子凭证和医疗机构标识，确定与医保电子凭证对应的身份是否具有在医疗机构标识表示的医疗机构中进行医保混合支付的权限；在确定与医保电子凭证对应的身份具有权限的情况下，响应于接收到医疗机构对应的服务器发送的结算请求，确定医保混合支付账单，医保混合支付账单包括存在医保报销的第一自费账单和不存在医保报销的第二自费账单；以及响应于接收到针对医保混合支付账单的支付成功通知，支付成功通知携带支付结果信息，将支付结果信息发送至与医保电子凭证对应的客户端。
22.图1示意性示出了根据本公开实施例的数据处理方法、装置、设备、介质和程序产品的应用场景图。
23.如图1所示，根据该实施例的应用场景100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
24.用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
25.终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
26.服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。
27.需要说明的是，本公开实施例所提供的数据处理方法一般可以由服务器105执行。相应地，本公开实施例所提供的数据处理装置一般可以设置于服务器105中。本公开实施例所提供的数据处理方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的数据处理装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。
28.应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
29.以下将基于图1描述的场景，通过图2对公开实施例的数据处理方法进行详细描述。
30.图2示意性示出了根据本公开实施例的数据处理方法的流程图。
31.如图2所示，该实施例包括操作s210～操作s230，该数据处理方法可以通过服务器执行。
32.在本公开的技术方案中，对数据的获取、收集、存储、使用、加工、传输、提供、公开和应用等处理，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。
33.在操作s210，响应于接收到医疗机构对应的服务器发送的验证请求，验证请求携带医保电子凭证和医疗机构标识，确定与医保电子凭证对应的身份是否具有在医疗机构标识表示的医疗机构中进行医保混合支付的权限。
34.在操作s220，在确定与医保电子凭证对应的身份具有权限的情况下，响应于接收到医疗机构对应的服务器发送的结算请求，确定医保混合支付账单，医保混合支付账单包括存在医保报销的第一自费账单和不存在医保报销的第二自费账单。
35.在操作s230，响应于接收到针对医保混合支付账单的支付成功通知，支付成功通知携带支付结果信息，将支付结果信息发送至与医保电子凭证对应的客户端。
36.医保电子凭证即医保身份二维码，包括识别医保身份、医保预结算以及医保结算等服务，涉及到医保报销部分(统筹)和自费部分。
37.针对医保混合支付，医院窗口或者自助机在用户进行医保电子凭证支付相关费用时，现有的支付规则如下：s1、首先需要用户出示医保电子凭证，由医院窗口工作人员或医院自助机根据该二维码确认用户身份，识别用户信息；s2、医院窗口或自助机上传医疗明细数据，调用医保预结算接口，得出个人医保报销部分以及自费部分；s3、用户进行第一次支付，即支付自费部分的金额；s4、医院窗口或自助机收取用户自费金额后，发起医保结算业务，用户针对医保结算中产生的自费账单，进行第二次支付。可见，在此次支付结算过程中，用户进行了两次支付操作显然会给用户带来不便。同时，在此过程中，往往会遇到多次展示医保电子凭证进行医疗订单支付，相应的窗口和患者也需要多次操作，流程相对繁琐，会加剧用户缴费过程中的等待时间。
38.本实施例提供的数据处理方法，主要针对用户在线下通过医保电子凭证支付就诊费用过程中出现的医保混合支付的问题。通过用户的签约授权，为用户开通在医疗机构中进行混合支付的权限，使用户仅通过一次医保电子凭证的展码操作，即可完成通常需要两三步才能完成的混合支付，可以简化医保混合支付流程，提升支付体验。
39.用户签约授权是指，用户在开展该混合支付业务前，需要进行健康钱包签约并绑定相应的银行卡账户并对医院进行授权，授权的医院可以对用户健康钱包账户扣款操作；混合支付是指，用户在医疗支付场景中，使用医保电子凭证进行支付，涉及到医保报销以及自费部分，在医保预结算后可直接代扣自费部分，完成整个支付流程。
40.举例来说，用户在进行医保电子凭证混合支付场景时，需要事先进行指定优先扣除哪张银行卡的金额。可以通过健康钱包开立，绑定个人一张或者多张银行卡；。其中，健康钱包是指银行在医疗专属行业的二、三类账户，可绑定用户本人多张实体银行卡。用户可通过该健康钱包对不同医院进行免密代扣授权操作，具体流程可以如下：s11、用户通过二维码，或者关注医院公众号，进入到“医保混合支付签约”页面；s21、用户进行实名实人认证，
确保本人操作；s31、开立健康钱包：查询本人或者输入本人银行卡号，校验银行卡以及本人的关系，给银行卡预留手机号发送验证码，校验短信验证码，开立健康钱包并校验是否已实名；s41、用户授权并签约医院，用于在对应医院使用医保电子凭证时，自费部分免密代扣钱包中的金额。进一步的，可绑定多张银行卡并设置默认扣款银行卡；可设置扣款金额单笔限额，日累计限额；可对授权医院进行维护；可设置只扣钱包余额，或者是否联动扣绑定银行卡等。
41.通过用户针对指定目标医疗机构的签约授权，即可为该用户开通在该指定目标医疗机构进行医保混合支付的权限。以便用户在进行医疗服务过程中，通过一次展示医保电子凭证，即可完成个人医保报销和自费现金支付，一次展码完成两种结算。
42.举例来说，用户出示医保电子凭证，医疗窗口或自助机识别该医保电子凭证后，由医疗机构对应的服务器向执行数据处理方法的服务器发送验证请求，该验证请求需要携带用户的医保电子凭证和医疗机构标识。若用户已针对该与医疗机构标识对应的医疗机构进行了签约授权，则可以根据医保电子凭证和医疗机构标识之间的绑定关系，确定与医保电子凭证对应的身份具有在医疗机构标识表示的医疗机构中进行医保混合支付的权限。医院窗口或者自助机上传医疗处方明细数据，即医疗机构对应的服务器向执行数据处理方法的服务器发送结算请求，针对该医疗处方明细进行结算处理，如调用医保预结算接口，得出存在医保报销的第一自费账单和不存在医保报销的第二自费账单；针对不存在医保报销的第二自费账单发起结算，由于用户已授权并签约，即同意自费部分免密代扣，则直接调用银行系统进行自动划扣缴费；并响应于第二自费账单结算成功通知，发起医保结算业务，针对存在医保报销的第一自费账单发起结算，如调用银行系统进行自动划扣缴费；在完成医保混合支付账单的支付后，向执行数据处理方法的服务器发送支付成功通知，该支付成功通知携带支付结果信息。可以将支付结果信息发送至与医保凭证对应的客户端，例如向用户关注的公众号推送信息(支付结果信息)，用户可以在手机上查看。
43.为了更好的理解本公开，下面结合实施例进一步阐述本公开的内容，但本公开不仅仅局限于下面实施例。
44.例如，用户在就医后针对此次就医服务涉及到的医疗费用进行结算。在结算费用的过程中通过用户客户端向医疗机构的结算系统对应的客户端展示医保电子凭证。由结算系统对应的客户端在读取到该医保电子凭证后，发起验证医保电子凭证和医疗机构是否存在签约关系的请求。例如，医保电子凭证表示的用户已针对该医疗机构针对医保混合支付服务进行了签约确认，即用户允许该医疗机构在结算时，针对涉及到医保的账单和未涉及到医保的账单进行合并处理得到医保混合支付账单。
45.若对医保电子凭证和医疗机构标识进行核对后，确定就医用户和医疗机构不存在签约关系，未开通医保混合支付的权限，可以通过在结算系统对应的客户端显示医疗机构公众号二维码和引导信息，来引导就医用户关注医院公众号并开通医保混合支付的权限。
46.在用户与该医疗机构签约后，可以获取到由医疗机构上传的，针对该就医用户开具的检查表单、就诊表单、药物表单等。然后，针对多个表单中涉及到的医保结算部分就行预处理，接收来自医保系统预结算信息。针对多个表单中涉及到的不能使用医保的部分费用，确定自费费用。针对预结算信息涉及的自费费用和已确定的自费费用，生成总自费账单，即医保混合支付账单。
47.针对医保混合支付账单向用户关联的金融机构发起支付请求，由金融机构完成缴费处理。若在缴费处理过程中，确定用户关联的账户下的可支配费用不足，可以提醒用户对该账户进行充值，或采用其他支付方式支付全部费用或剩余部分费用。
48.在完成全部费用的缴纳后，生成支付成功通知，该支付成功通知包括支付结果信息，如用户关联账户的扣款明细。然后，由执行本实施例的服务器将支付结果信息推送至就医用户。
49.本实施例提供的数据处理方法，可以在使用线下医保电子凭证过程中减少医患交互步骤，简化双方支付操作流程；即通过患者仅进行一次展示医保电子凭证，即可完成个人医保报销和自费现金支付，一次展码完成两种结算，能够减少窗口、用户操作步骤，节省就医时间，提升医疗订单支付效率以及就医体验性。
50.响应于接收到医疗机构对应的服务器发送的验证请求，验证请求携带医保电子凭证和医疗机构标识，确定与医保电子凭证对应的身份是否具有在医疗机构标识表示的医疗机构中进行医保混合支付的权限，包括：确定医保电子凭证和医疗机构标识之间是否存在预定映射关系；以及在确定医保电子凭证和医疗机构标识之间存在预定映射关系的情况下，确定与医保电子凭证对应的身份具有权限。
51.举例来说，用户在针对医保混合支付进行签约授权时，会选择与身份信息绑定的医疗机构，即目标医疗机构。可通过映射关系表来维护身份信息与医疗机构之间的映射关系，该映射关系表可以包括医保电子凭证字段，可以包括医疗机构字段存储医疗机构标识，以及映射关系字段，用于确定医保电子凭证和医疗机构标识之间是否存在预定映射关系。
52.可以记录用户在签约授权时选择的目标医疗机构，生成映射关系表，该映射关系表记录了医保电子凭证和医疗机构标识之间的映射关系，从而可以查询该映射关系表来确定医保电子凭证和医疗机构标识之间是否存在预定映射关系。在在确定医保电子凭证和医疗机构标识之间存在预定映射关系的情况下，确定与医保电子凭证对应的身份具有权限，即确定与医保电子凭证对应的身份具有在医疗机构标识表示的医疗机构中进行医保混合支付的权限。
53.本实施例提供的数据处理方法，可以通过调取映射关系表来快速确定医保电子凭证和医疗机构标识之间是否存在预定映射关系；并在确定医保电子凭证和医疗机构标识之间存在预定映射关系的情况下，确定与医保电子凭证对应的身份具有权限，有利于确定用户是否已经开通在医疗机构标识表示的医疗机构中进行医保混合支付的权限。进一步的，可以在确定不具有权限的情况下，发送提示信息来协助用户开通权限，便于后续基于医保电子凭证进行支付医疗费用。
54.数据处理方法还包括：响应于接收到来自用户的开通医保混合支付权限的请求，对用户进行实名认证；以及在确定用户通过实名认证的情况下，响应于接收到医疗机构标识，开通用户在医疗机构标识表示的医疗机构中进行医保混合支付的权限。
55.举例来说，用户可以通过医院的公众号点击医保混合支付签约，向执行数据处理方法的服务器发送开通医保混合支付权限的请求；然后，响应于接收到来自用户的开通医保混合支付权限的请求，对用户进行实名认证。在确认是本人操作的情况下，确定用户通过实名认证，向用户推送医院名称供用户选择目标医疗机构，并将与目标医疗机构对应的医疗机构标识发送至执行数据处理方法的服务器，记录身份信息与医疗机构标识的映射关
系，即开通用户在医疗机构标识表示的医疗机构中进行医保混合支付的权限。
56.本实施例提供的数据处理方法，可以在开展混合支付前，开通用户在医疗机构标识表示的医疗机构中进行医保混合支付的权限，以便于用户在医疗支付场景中使用医保电子凭证进行医保混合支付。
57.数据处理方法还包括：响应于接收到与医保混合支付账单对应的电子发票信息，将电子发票信息发送至与医保电子凭证对应的客户端。
58.举例来说，在完成医保混合支付账单的支付后，向关联的电子发票系统发送申请电子发票的请求，该申请电子发票的请求携带医保混合支付账单和支付结果，由电子发票系统自动生成相应的电子发票，并发送至执行数据处理方法的服务器。可以将电子发票信息发送至与医保电子凭证对应的客户端，如公众号消息中。
59.本实施例提供的数据处理方法，可以关联电子发票，在完成医保混合支付账单的支付后，直接为用户申请电子发票，无需用户手动操作，提升用户就医体验。
60.基于上述数据处理方法，本公开还提供了一种数据处理装置。以下将结合图3对该装置进行详细描述。
61.图3示意性示出了根据本公开实施例的数据处理装置的结构框图。
62.如图3所示，该实施例的数据处理装置300包括第一确定模块310、第二确定模块320和第一发送模块330。
63.第一确定模块310，用于响应于接收到医疗机构对应的服务器发送的验证请求，所述验证请求携带医保电子凭证和医疗机构标识，确定与所述医保电子凭证对应的身份是否具有在所述医疗机构标识表示的医疗机构中进行医保混合支付的权限；第二确定模块320，用于在确定与所述医保电子凭证对应的身份具有所述权限的情况下，响应于接收到医疗机构对应的服务器发送的结算请求，确定医保混合支付账单，所述医保混合支付账单包括存在医保报销的第一自费账单和不存在医保报销的第二自费账单；以及第一发送模块330，用于响应于接收到针对所述医保混合支付账单的支付成功通知，所述支付成功通知携带支付结果信息，将所述支付结果信息发送至与所述医保电子凭证对应的客户端。
64.在一些实施例中，所述第一确定模块，用于：确定所述医保电子凭证和所述医疗机构标识之间是否存在预定映射关系；以及在确定所述医保电子凭证和所述医疗机构标识之间存在预定映射关系的情况下，确定与所述医保电子凭证对应的身份具有所述权限。
65.在一些实施例中，所述数据处理装置还包括：实名认证模块，用于响应于接收到来自用户的开通医保混合支付权限的请求，对所述用户进行实名认证；以及开通权限模块，用于在确定所述用户通过实名认证的情况下，响应于接收到医疗机构标识，开通所述用户在所述医疗机构标识表示的医疗机构中进行医保混合支付的权限。
66.在一些实施例中，所述数据处理装置还包括：第二发送模块，用于响应于接收到与所述医保混合支付账单对应的电子发票信息，将所述电子发票信息发送至与所述医保电子凭证对应的客户端。
67.根据本公开的实施例，第一确定模块310、第二确定模块320和第一发送模块330中的任意多个模块可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，第一确定模块310、第二确定模块
320和第一发送模块330中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，第一确定模块310、第二确定模块320和第一发送模块330中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
68.图4示意性示出了根据本公开实施例的适于实现数据处理方法的电子设备的方框图。
69.如图4所示，根据本公开实施例的电子设备400包括处理器401，其可以根据存储在只读存储器(rom)402中的程序或者从存储部分408加载到随机访问存储器(ram)403中的程序而执行各种适当的动作和处理。处理器401例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))等等。处理器401还可以包括用于缓存用途的板载存储器。处理器401可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
70.在ram 403中，存储有电子设备400操作所需的各种程序和数据。处理器401、rom402以及ram 403通过总线404彼此相连。处理器401通过执行rom 402和/或ram 403中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom 402和ram 403以外的一个或多个存储器中。处理器401也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
71.根据本公开的实施例，电子设备400还可以包括输入/输出(i/o)接口405，输入/输出(i/o)接口405也连接至总线404。电子设备400还可以包括连接至i/o接口405的以下部件中的一项或多项：包括键盘、鼠标等的输入部分406；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分407；包括硬盘等的存储部分408；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分409。通信部分409经由诸如因特网的网络执行通信处理。驱动器410也根据需要连接至i/o接口405。可拆卸介质411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器410上，以便于从其上读出的计算机程序根据需要被安装入存储部分408。
72.本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
73.根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom 402和/或ram 403和/或rom 402和ram 403以外的一个或多个存储器。
74.本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序
包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机系统中运行时，该程序代码用于使计算机系统实现本公开实施例所提供的数据处理方法。
75.在该计算机程序被处理器401执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。
76.在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分409被下载和安装，和/或从可拆卸介质411被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
77.在这样的实施例中，该计算机程序可以通过通信部分409从网络上被下载和安装，和/或从可拆卸介质411被安装。在该计算机程序被处理器401执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
78.根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如java，c ，python，“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
79.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
80.本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。
81.以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本
公开的范围之内。