一种车载业务信息的处理方法、装置及电子设备与流程

1.本技术涉及信息处理的技术领域，具体而言，涉及一种车载业务信息的处理方法、装置及电子设备。


背景技术：

2.随着汽车的智能化水平提高，车内中控搭载的业务功能也逐渐增多。如数字车钥匙：将汽车及所属信息加载到用户手机或其他移动设备，用户通过nfc等通讯手段控制汽车执行开车门、启动发动机等操作。另外，车载支付业务功能也逐渐兴起，例如在车内购买音乐套餐、支付充电费用等。
3.目前车载端对业务信息进行处理时，预先配置过程比较复杂。车主将车借予其他人使用时，需要事先在车内关联对应使用者的账户或另外更换账户，否则预先绑定的账户容易出现被其他人消费等情况；或者，使用者支付业务时需要通过移动设备对车内中控屏显示的二维码扫码执行支付操作。以上方式通常比较繁琐且安全性较低，给用户或车主带来使用上的不便。


技术实现要素：

4.本技术的目的在于提供一种车载业务信息的处理方法、装置、电子设备与存储介质，在提升车载业务操作的便捷性同时增强了安全性，提升了用户的使用体验。
5.本技术的实施例是这样实现的：
6.本技术实施例第一方面提供了一种车载业务信息的处理方法，该方法应用于移动端，该方法包括：与车载端双向认证成功后，与车载端创建安全通道；在通过安全通道接收到车载端发送的业务指令之后，基于业务指令携带的业务数据确认是否生成待验证界面信息；若生成待验证界面信息，显示待验证界面信息，并在接收到对待验证界面信息的回复指令时，将对应的回复信息发送至车载端；若无需生成待验证界面信息，直接生成确认指令并通过安全通道发送至车载端。
7.于一实施例中，基于业务指令携带的业务数据确认是否生成待验证界面信息，包括：基于业务数据包括的支付金额，确认是否超过预设支付阈值；根据支付金额是否超过预设支付阈值，确认是否生成待验证界面信息。
8.于一实施例中，根据支付金额是否超过预设支付阈值，确认是否生成待验证界面信息，包括：若超过预设支付阈值，则生成待验证界面信息；若未超过预设支付阈值，则无需生成待验证界面信息。
9.于一实施例中，在基于业务指令携带的业务数据确认是否生成待验证界面信息之后，方法还包括：若生成待验证界面信息，向车载端发送待验证指令，以使车载端以预设频率持续发送最近一条业务指令直至接收到回复信息。
10.于一实施例中，在接收到对待验证界面信息的回复指令时，将对应的回复信息发送至车载端，包括：若回复指令为验证通过，基于业务指令携带的业务数据生成回复信息并
标记为通过，将已标记的回复信息发送至车载端。
11.于一实施例中，在与车载端创建安全通道之后，方法还包括：基于接收到的默认支付指令，将数字钥匙程序与默认支付指令对应的支付程序通过调用的接口关联。
12.于一实施例中，在基于业务指令携带的业务数据确认是否生成待验证界面信息之前，还包括：通过数字钥匙程序对业务指令解密，以使支付程序通过接口获得业务指令所携带的业务数据。
13.本技术实施例第二方面提供了一种车载业务信息的处理装置，该装置包括创建模块、确认模块、显示模块以及生成模块。其中，创建模块用于与车载端双向认证成功后，与车载端创建安全通道；确认模块用于在通过安全通道接收到车载端发送的业务指令之后，基于业务指令携带的业务数据确认是否生成待验证界面信息；显示模块用于若生成待验证界面信息，显示待验证界面信息，并在接收到对待验证界面信息的回复指令时，将对应的回复信息发送至车载端；生成模块用于若无需生成待验证界面信息，直接生成确认指令并通过安全通道发送至车载端。
14.于一实施例中，确认模块还用于：基于业务数据包括的支付金额，确认是否超过预设支付阈值；根据支付金额是否超过预设支付阈值，确认是否生成待验证界面信息。
15.于一实施例中，确认模块还用于：若超过预设支付阈值，则生成待验证界面信息；若未超过预设支付阈值，则无需生成待验证界面信息。
16.于一实施例中，车载业务信息的处理装置还包括：发送模块，用于若生成待验证界面信息，向车载端发送待验证指令，以使车载端以预设频率持续发送最近一条业务指令直至接收到回复信息。
17.于一实施例中，显示模块还用于：若回复指令为验证通过，基于业务指令携带的业务数据生成回复信息并标记为通过，将已标记的回复信息发送至车载端。
18.于一实施例中，车载业务信息的处理装置还包括：关联模块，用于基于接收到的默认支付指令，将数字钥匙程序与默认支付指令对应的支付程序通过调用的接口关联。
19.于一实施例中，车载业务信息的处理装置还包括:解密模块，用于通过数字钥匙程序对业务指令解密，以使支付程序通过接口获得业务指令所携带的业务数据。
20.本技术实施例第三方面提供了一种电子设备，电子设备包括：处理器和用于存储处理器可执行指令的存储器；其中，处理器被配置用以执行本技术实施例第一方面及其任一实施例的车载业务信息的处理方法。
21.本技术实施例第四方面提供了一种计算机可读存储介质，存储介质存储有计算机程序。计算机程序可由处理器执行，以完成本技术实施例第一方面及其任一实施例的车载业务信息的处理方法。
22.本技术与现有技术相比的有益效果是：
23.本技术能够解决因汽车使用者不同，用户在对车载业务进行付费等操作过程中步骤繁琐、安全性差的问题。本技术通过用户与汽车双向认证成功后，建立业务信息传输的安全通道，并在接收到业务信息后进行分析以及对应处理的方法，实现了用户通过数字钥匙即可直接匹配车载业务与用户信息的操作。用户使用过程便捷、安全，提升了用户的使用体验。
附图说明
24.为了更清楚地说明本技术实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
25.图1为本技术一实施例提供的车载业务信息的处理方法的应用场景示意图；
26.图2为本技术一实施例提供的电子设备的结构示意图；
27.图3为本技术一实施例提供的车载业务信息的处理方法的流程示意图；
28.图4为本技术一实施例提供的车载业务信息的处理方法的流程示意图；
29.图5为本技术一实施例提供的车载业务信息的处理装置的结构示意图。
30.附图标记：1-电子设备；100-移动端；110-ese安全芯片；120-用户显示界面；10-存储器；11-总线；12-处理器；200-车载端；210-车载系统；300-业务端；400-服务端；600-车载业务信息的处理装置；610-创建模块；620-确认模块；630-显示模块；640-生成模块；650-发送模块；660-关联模块；670-解密模块。
具体实施方式
31.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。
32.相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本技术的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
33.下面将结合附图对本技术的技术方案进行清楚、完整地描述。
34.请参见图1，图1为本技术一实施例提供的车载业务信息的处理方法的应用场景示意图。如图1所示，该应用场景包括移动端100、车载端200、业务端300以及服务端400。移动端100可以是个人电脑、平板电脑、智能手机等。业务端300或服务端400可以是服务器或服务器集群。本技术中，移动端100可以执行本技术实施例提供的车载业务信息的处理方法并从车载端200获取数据，为表述方便，本技术实施例以移动端100作为执行主体展开描述。
35.于本技术应用场景中，用户移动端100内搭载ese安全芯片110，以使芯片加载的数字钥匙程序与车载端200建立双向认证关系并开启车门后建立业务信息传输的安全通道，用户在车内通过车载系统210中控显示屏下单某项业务时，车载端200会基于用户下单的业务请求业务端300响应相关数据，并在获取相应数据后，将相关业务数据加密并发送至用户持有的移动端100，支付程序通过接口获得数字钥匙程序解密获取的业务数据后，对业务数据进一步判断，确认是否需要用户在移动端100进一步验证业务数据，然后移动端100将回复信息发送至车载端200，以使业务端300基于车载端200发送的回复数据通过服务端400扣款。
36.请参见图2，图2为本技术一实施例提供的电子设备1的结构示意图，该电子设备1可以作为上述移动端100、车载端200、业务端300以及服务端400。如图2所示，电子设备1包括至少一个处理器12和存储器10，图2中以一个处理器12为例。处理器12和存储器10通过总线11连接，存储器10存储有可被至少一个处理器12执行的指令，指令被至少一处理器12执行，以使至少一个处理器12执行如下述实施例中的车载业务信息的处理方法。
37.请参见图3，图3为本技术一实施例提供的车载业务信息的处理方法的流程示意图。如图3所示，该方法包括：
38.s410：与车载端200双向认证成功后，与车载端200创建安全通道。
39.在该步骤中，用户持有的移动端100通过移动端100内数字钥匙程序，实现与车载端200的双向认证，以打开车门或启动发动机，此时移动端100内数字钥匙程序与车载端200的车载系统210会建立一个安全通道，以供后续用户在车内使用车载端200某项业务服务时，车载端200与移动端100之间传输业务数据。
40.s420：在通过安全通道接收到车载端200发送的业务指令之后，基于业务指令携带的业务数据确认是否生成待验证界面信息。
41.用户在车载端200搭载的中控显示屏上点击某项业务时，车载端200会自动生成相关业务信息，或者通过网络向业务端300请求获取业务相关数据。车载端200基于已经自动生成或者获取到的业务数据进行加密得到业务指令，将业务指令通过安全通道发送至移动端100。移动端100接收到业务指令进行解密，并基于解密获得的业务数据，确认是否生成待验证界面信息，其中，待验证界面信息是指需要用户在移动端100用户显示界面上对应确认的信息。
42.s430:若生成待验证界面信息，显示待验证界面信息，并在接收到对待验证界面信息的回复指令时，将对应的回复信息发送至车载端200。
43.移动端100基于业务数据生成待验证界面信息后，会在用户显示界面120上显示待验证界面信息。用户在用户显示界面120上点击或输入待验证信息对应的回复指令后，移动端100将回复指令对应的回复信息加密并通过安全通道发送至车载端200。
44.s440:若无需生成待验证界面信息，直接生成确认指令并通过安全通道发送至车载端200。
45.移动端100基于业务数据确认无需生成待验证界面信息，直接生成默认的确认指令并进行加密后，通过安全通道发送给车载端200，以使车载端200基于确认指令解密后，将确认指令所携带的信息发送至业务端300，以完成用户需要的业务服务。
46.请参见图4，图4为本技术一实施例提供的车载业务信息的处理方法的流程示意图。如图4所示，车载业务信息的处理方法包括：
47.s510:与车载端200双向认证成功后，与车载端200创建安全通道。
48.于一实施例中，用户持有的移动端100基于内置ese安全芯片110存储的数字钥匙程序打开车门或启动发动机，并且用户连接车辆以实现下述实施例中的车载业务服务。其中，车载端200和数字钥匙所在的移动端100完成双向的认证，并且建立了安全通道以供用户在车内使用某项业务服务时，车载端200与移动端100之间传输业务数据。
49.数字钥匙是指在手机或可穿戴设备等移动端100内，ese安全芯片110存储的相关数据，以供移动端100与车载端200通过数字钥匙程序完成双向认证以及后续的业务服务，数字钥匙包括车辆认证该钥匙的信息，例如：车辆的标识、钥匙的标识、认证的密钥信息(可以是对称、非对称算法)等。在用户使用数字钥匙程序开车门时，移动端100会和车载端200进行双向认证并建立一个安全通道。数字钥匙的通讯方式包括但不限于ble(蓝牙通讯)或nfc(近场通讯)。若通讯方式为nfc，那么在用户开门后移动端100与车载端200的连接会重置，车载系统210还需要一个nfc reader(nfc虚拟读卡器)，以使用户在需要车载端200再次
提供车载业务服务时，将移动端100放置在nfc reader(nfc虚拟读卡器)上与车载端200重新建立连接。如果使用蓝牙通讯，则移动端100与车载端200的连接可以一直保持。
50.数字钥匙配对可以参考公开的规范如ccc digital key规范或其他的车企私有标准的规范。本技术对数字钥匙配对的要求为：可以为建立安全通道提供条件且可通过数字钥匙程序实现后续转发业务信息等相关功能。
51.s520:基于接收到的默认支付指令，将数字钥匙程序与默认支付指令对应的支付程序通过调用的接口关联。
52.在用户持有的移动端100通过数字钥匙程序与车载端200双向认证后，车载端200直接基于已存储的认证信息向对应的用户提供业务服务，且在业务服务为付费项目时针对用户信息正确扣费，这需要对移动端100预先配置以使移动端100内的支付程序与数字钥匙程序通过调用的接口关联。
53.默认支付指令是指在移动端100与车载端200完成双向认证，由用户预先在用户显示界面120选择一个默认使用的支付程序后，对应生成的信息。ese安全芯片110接收到默认支付指令所携带的具体支付信息以后将其存储，并作为用户使用车载业务付费时的支付实例。该支付实例可以在无需用户再次验证业务信息时作为默认的支付方式，也可以作为需要用户验证业务信息时的默认支付方式，上述过程称为支付程序个人化配置的过程，该个人化流程与普通的支付程序绑定过程基本一致。
54.用户也可以暂不选择待用户验证业务信息时的默认支付方式，移动端100内ese安全芯片110预先存储多个关联支付程序的aid(应用标识)，待实际支付需要用户验证业务信息时，在用户显示界面120显示，再由用户选择具体的应用程序。
55.移动端100内存储的应用程序之间可以通过共享接口对象的方式进行信息通信，由于支付程序和数字钥匙程序的供应方一般不是同一个业务实体，因此需要它们所属的业务实体达成合作关系。如果支付程序是需要进行认证的，那么还需要通过apdu(应用协议数据单元)将需要的认证信息配置到数字钥匙程序对应的应用实例中，数字钥匙程序在调用支付程序接口之前需要做一个认证过程，认证过程使用对称密钥体系或非对称密钥体系，或其他自定义的认证方法。
56.为实现上述流程，需要预先对车载应用进行配置，在现有的支付程序基础上提供不同程序间调用的接口，让具体接口与相关程序的非接触功能保持一致，这样可以在不改变支付程序交易逻辑的情况下实现车载的无感支付。另外，移动端100需要预先增加在安全通道中数字钥匙程序透传(或称为转发)业务信息apdu(应用协议数据单元)的能力，用以传输业务数据。车载端200与业务端300需要一起实现支付程序的交易逻辑，以针对移动端100不同的支付程序适配不同的支付逻辑，如：实现pboc交易逻辑、支付宝程序交易逻辑等。
57.完成上述配置及关联后，车载端200就可以通过配置完成的车载应用向对应的用户提供业务服务，车载应用内包含数字钥匙程序与支付程序，以使用户使用对应车辆时为相应的业务服务付款。
58.s530:接收到车载端200发送的业务指令之后，通过数字钥匙程序对业务指令解密，以使支付程序通过接口获得业务指令所携带的业务数据。
59.在移动端100与车载端200认证完成并建立了安全通道后，当用户在车载端200搭载的中控使用界面下单某项业务服务时，车载端200可以基于自身存储信息生成对应的业
务数据；也可以向业务端300请求响应用户的相关业务订单信息后(业务端300可能还需要向相关服务端400申请支付数据后一并发送给车载端200)，接收到相关业务响应数据。车载端200将业务数据加密转换为apdu(应用协议数据单元)模式的业务指令后，通过安全通道发给移动端100加载的数字钥匙程序，数字钥匙程序将业务指令解密得到业务指令所携带的业务数据，并通过接口转发给支付程序。
60.于一实施例中，车载端200在接收到下单指令时，可以基于预设的车载端200安全策略确认是否对移动端100执行业务服务的扣费操作。安全策略可以根据用户的需求配置为距离安全策略，如：车载端200根据车内的定位技术，如uwb(超宽带通信)技术、ble(蓝牙)技术、nfc(近场通讯)技术或gps定位等，预设当前数字钥匙所在的移动端100只有在车内、或与车载端200距离小于预设距离阈值时才能发起支付，否则就不做支付，以实现近距离用户的无感支付。
61.s540:基于业务指令携带的业务数据确认是否生成待验证界面信息。
62.移动端100还会根据用户的需求预先配置支付安全策略，例如，预先设置一个支付阈值，在支付程序接收到的业务数据包括的支付金额低于支付阈值时，无需用户再次验证或确认即可进行无感支付，而在支付金额高于支付阈值时需要用户在移动端100的用户显示界面120上进行再次确认或相关身份信息的验证。
63.在该步骤中，支付程序获得业务指令携带的业务数据以后，基于业务数据包括的业务支付金额进行判断，确认是否超过预设支付阈值；进而根据业务支付金额是否超过预设支付阈值，确认是否生成待验证界面信息。具体为：若支付金额超过预设支付阈值，则生成待验证界面信息以供用户后续在对应移动端100的用户显示界面120上进行支付信息确认或用户身份验证；若支付金额未超过预设支付阈值，则移动端100支付程序无需生成待验证界面信息。
64.s550:若生成待验证界面信息，显示待验证界面信息，并向车载端200发送待验证指令，以使车载端200以预设频率持续发送最近一条业务指令直至接收到回复信息。
65.若业务支付金额超过预设支付阈值，支付程序需要生成待验证界面信息(例如hci-人机交互信息)，以显示在移动端100的用户显示界面120上，供用户确认支付信息或验证用户信息。支付程序可以先给数字钥匙程序返回一个待用户确认的消息作为待验证指令，并由数字钥匙程序转发给车载端200，车载端200接收到待验证指令后，定时向移动端100的数字钥匙程序以预设频率持续发送最近一条业务指令，直至接收到对应的回复信息时才停止自动发送。
66.s551:若无需生成待验证界面信息，直接生成确认指令并通过安全通道发送至车载端200。
67.若支付金额未超过预设支付阈值，则移动端100支付程序无需生成待验证界面信息，支付程序基于已存储的业务数据直接生成对应的确认指令，确认指令中可以包括用户的账户信息，支付方式，业务名称、支付金额及直接支付许可等针对该项业务服务扣费的相关数据。支付程序通过接口将确认指令发送至数字钥匙程序，以使数字钥匙程序基于确认指令加密后发送至车载端200的业务系统，并由车载端200业务系统解密后，通过网络接口发送至对应的业务端300，由业务端300连接对应的服务端400支付渠道，对用户进行相关业务服务的扣费操作。
68.s560:若回复指令为验证通过，基于业务指令携带的业务数据生成回复信息并标记为通过，将已标记的回复信息发送至车载端200。
69.若用户在移动端100的用户显示界面120上确认可以支付，或验证用户信息通过，支付程序基于上述验证或确认信息，以及业务指令携带的业务数据生成回复信息，回复信息中包括针对业务服务对用户扣费的相关数据以及用户许可扣费的标识数据，即该回复信息为已标记通过的回复信息。上述标识数据关联交易金额和交易计数器，且移动端100以及车载端200内设有对应的安全机制防止篡改盗刷等恶意操作。
70.支付程序通过接口将回复信息发送至数字钥匙程序，以使数字钥匙程序基于回复信息加密后发送至车载端200的业务系统，并由车载端200系统解密后，通过网络接口发送至对应的业务端300，并由业务端300连接对应的服务端400支付渠道，对用户执行相关业务服务的扣费操作。
71.上述扣费操作完成后，车载端200与移动端100接收响应消息确认业务交易处理完成，对应的用户允许扣费相关标识数据需要被清空。
72.s561:若回复指令为验证不通过，基于业务指令携带的业务数据生成回复信息并标记为不通过，将已标记的回复信息发送至车载端200。
73.若用户在移动端100的用户显示界面120上拒绝支付，或验证用户信息未通过，支付程序基于上述信息，以及业务指令携带的业务数据生成回复信息，回复信息中包括针对业务服务对用户扣费的相关数据以及拒绝扣费的标识数据，即该回复信息为已标记不通过的回复信息。
74.支付程序通过接口将回复信息发送至数字钥匙程序，以使数字钥匙程序基于回复信息加密后发送至车载端200的业务系统，并由车载端200业务系统解密后，基于未通过的回复信息生成提示扣费失败的信息，并显示在车载端200的中控使用界面上，以提示用户扣费失败。车载端200还可以直接将未通过的回复信息发送至业务端300，由业务端确认中止该项业务服务及相关扣费操作。
75.上述实施例均基于ese安全芯片110实现业务服务的安全支付。于本技术其他实施例中，可以使用tee(可信执行环境)来执行车载业务信息的处理方法，运行于tee(可信执行环境)内不同的ta(可信应用程序)之间的通讯由ta(可信应用程序)自行实现。上述实施例中关联数字钥匙程序和支付程序之间的接口以传输数据的方式，也可以由上层应用程序的转发替代。
76.于本技术实施例中，车主无需事先在车载端200录入用户的支付信息才能支付用户在车载端200下单的业务，数字钥匙和车载端200进行了双向认证，并建立了安全通道，安全性非常高；本技术可以通过车载端200的距离安全策略和移动端的支付安全策略做到无感支付；当车换人使用后，业务服务扣费操作对应当前使用人的账户资金，不会扣其他关联账户的资金，没有错扣的风险，在支付金额超出预设阈值时还会提醒用户确认；移动端100例如用户手机(可穿戴设备)无需联网也可以执行上述操作。本技术实施例中，用户使用移动端对车载业务支付过程便捷安全，提升了用户的使用体验。
77.请参见图5，图5为本技术一实施例提供的车载业务信息的处理装置600的结构示意图。如图5所示，该装置包括：创建模块610、确认模块620、显示模块630以及生成模块640。
78.其中，创建模块610用于与车载端200双向认证成功后，与车载端200创建安全通
道；确认模块620用于在通过安全通道接收到车载端200发送的业务指令之后，基于业务指令携带的业务数据确认是否生成待验证界面信息；显示模块630用于若生成待验证界面信息，显示待验证界面信息，并在接收到对待验证界面信息的回复指令时，将对应的回复信息发送至车载端200；生成模块640用于若无需生成待验证界面信息，直接生成确认指令并通过安全通道发送至车载端200。
79.确认模块620还用于：基于业务数据包括的支付金额，确认是否超过预设支付阈值；根据支付金额是否超过预设支付阈值，确认是否生成待验证界面信息。
80.确认模块620还用于：若超过预设支付阈值，则生成待验证界面信息；若未超过预设支付阈值，则无需生成待验证界面信息。
81.车载业务信息的处理装置600还包括：发送模块650，用于若生成待验证界面信息，向车载端200发送待验证指令，以使车载端200以预设频率持续发送最近一条业务指令直至接收到回复信息。
82.显示模块630还用于：若回复指令为验证通过，基于业务指令携带的业务数据生成回复信息并标记为通过，将已标记的回复信息发送至车载端200。
83.车载业务信息的处理装置600还包括：关联模块660，用于基于接收到的默认支付指令，将数字钥匙程序与默认支付指令对应的支付程序通过调用的接口关联。
84.车载业务信息的处理装置600还包括:解密模块670，用于通过数字钥匙程序对业务指令解密，以使支付程序通过接口获得业务指令所携带的业务数据。
85.上述装置中各个模块的功能和作用的实现过程，具体详见上述车载业务信息的处理方法中对应步骤的实现过程，在此不再赘述。
86.在本技术所提供的几个实施例中，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本技术的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依据所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
87.另外，在本技术各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
88.本技术实施例提供了一种计算机可读存储介质，存储介质存储有计算机程序。计算机程序可由处理器12执行，以完成车载业务信息的处理方法。
89.功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例方法的全部或部分步骤。而前述的
存储介质包括：u盘、移动硬盘、只读存储器10(rom，read-only memory)、随机存取存储器10(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
90.以上所述仅为本技术的优选实施例而已，并不用于限制本技术，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。