一种智能点餐系统、方法及装置与流程

本申请涉及智能餐饮技术领域，尤其是涉及一种智能点餐系统、方法及装置。

背景技术：

目前，美食广场或商圈等地用户的用餐时间集中，在用餐时间往往会出现较大的客流量，导致用户无法及时点餐以及用餐。

上述场景下，用户需要等待较长时间排队点餐、取餐，效率较低；且因为美食广场或商圈等地各商户占地较小，排队期间容易造成点餐及取餐档口拥堵混乱等问题；在用餐人数较多的情况下，商家在餐品烹饪完成后无法及时通知用户取餐，影响用户的用餐体验。

技术实现要素：

有鉴于此，本申请的目的在于提供一种智能点餐系统、方法及装置，以避免用户排队点餐及取餐，防止出现点餐或取餐档口人群拥挤的现象，节省点餐时间，在餐品烹饪完成后能及时通知用户取餐，提高工作效率。。

第一方面，本申请实施例提供了一种智能点餐系统，包括第一用户终端、以及第二用户终端，其中：

所述第一用户终端，用于获取商家信息，根据第一用户在所述商家信息包含的餐品信息中选定的餐品信息，生成用餐订单，并将所述用餐订单发送至所述第二用户终端以及服务器；

所述第二用户终端，用于接收所述第一用户终端发送的用餐订单，并在接收到第二用户输入的烹饪完成指示后，向所述第一用户终端发送取餐指示。

结合第一方面，本申请实施例提供了第一方面的第一种可能的实施方式，其中，所述系统还包括：

第三用户终端，用于从所述服务器获取所述第二用户终端接收的用餐订单，并对所述第二用户终端接收的用餐订单中所包含的每个餐品进行统计，确定每个菜品的销售情况。

结合第一方面，本申请实施例提供了第一方面的第二种可能的实施方式，其中，所述第二用户终端还用于：

获取商家信息以及所述第二用户输入的更新指令，其中所述更新指令用于指导所述第二用户终端更新所述商家信息；

根据所述更新指令对所述商家信息进行更新；

将更新后的所述商家信息发送至所述服务器。

结合第一方面，本申请实施例提供了第一方面的第三种可能的实施方式，其中，所述第一用户终端，将所述用餐订单发送至所述第二用户终端，具体用于：

将未支付状态的用餐订单发送至所述第二用户终端。

所述第一用户终端，在将所述未支付状态的用餐订单发送至所述第二用户终端之后，还用于：

获取所述未支付状态的用餐订单所需支付的金额；

根据获取的所述金额，以及第二用户预设的支付方式，对所述未支付的用餐订单进行支付；

将所述未支付的用餐订单状态更新为已支付。

结合第一方面的第三种可能的实施方式，本申请实施例提供了第一方面的第四种可能的实施方式，其中，所述第二用户终端，在接收所述第一用户终端发送的未支付状态的用餐订单后，还用于：

接收第二用户输入的确认收款指示；

在接收到确认收款指示后，将接收的第一用户发送的未支付状态的用餐订单的状态更新为已支付。

结合第一方面的第一种可能的实施方式，本申请实施例提供了第一方面的第五种可能的实施方式，其中，所述第二用户终端，还用于:

根据第一用户对所述餐品信息中包含的餐品的选择，生成用餐订单。

结合第一方面，本申请实施例提供了第一方面的第六种可能的实施方式，其中，所述第一用户终端，还用于:

记录所述第一用户终端发送所述用餐订单的时刻；

当当前时刻距离记录的所述第一用户终端生成所述用餐订单的时刻之间的时长超过第一预设时长时，提醒第一用户取消用餐订单。

结合第一方面，本申请实施例提供了第一方面的第七种可能的实施方式，其中，所述第一用户终端，在获取商家信息之前，还用于：

判断是否可以获取用户的位置信息；

若判断结果为是，则根据获取的用户的位置信息以及每一个商家信息中包含的商家的位置信息，计算用户与所述每一个商家之间的距离，并按照所述距离对所述每一个商家信息进行排序；

若判断结果为否，则根据第一用户选定的筛选条件对每一个商家信息中包含的餐品信息进行筛选，将符合筛选条件的餐品信息所对应的商家信息确定为选定商家信息，并对所述选定商家信息按照符合筛选条件的餐品的销售情况进行排序。

第二方面，本申请实施例提供了一种智能点餐方法，包括：

第一用户终端获取商家信息；

第一用户终端根据第一用户在所述商家信息包含的餐品信息中选定的餐品信息，生成用餐订单；

第一用户终端将所述用餐订单发送至所述第二用户终端以及服务器；

第一用户终端接收取餐指示，其中所述取餐指示为第二用户终端在接收到所述第二用户输入的烹饪完成指示后，向所述第一用户终端发送的。

第三方面，本申请实施例提供了一种智能点餐装置，包括：

获取模块，用于获取商家信息；

生成模块，用于根据第一用户在所述商家信息包含的餐品信息中选定的餐品信息，生成用餐订单；

发送模块，用于将所述用餐订单发送至所述第二用户终端以及服务器；

接收模块，用于接收收取餐指示，其中所述取餐指示为第二用户终端在接收到所述第二用户输入的烹饪完成指示后，向所述第一用户终端发送的。

第四方面，本申请实施例提供了一种智能点餐方法，包括：

第二用户终端接收第一用户终端发送的未支付状态的用餐订单；

第二用户终端接收第二用户输入的确认收款指示，并将所述未支付状态的用餐订单的状态更新为已支付；

第二用户终端接收第二用户输入的烹饪完成指示；

第二用户终端在接收到第二用户输入的烹饪完成指示后，向所述第一用户终端发送取餐指示。

第五方面，本申请实施例提供了一种智能点餐装置，包括：

第一接收模块，用于接收第一用户终端发送的用餐订单；

第二接收模块，用于接收第二用户输入的烹饪完成指示；

发送模块，用于在接收到第二用户输入的烹饪完成指示后，向所述第一用户终端发送取餐指示。

第六方面，本申请实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面任一种可能的实施方式中的步骤。

第七方面，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面任一种可能的实施方式中的步骤。

本申请实施例提供的一种智能点餐系统、方法及装置，该系统第一用户终端、以及第二用户终端，其中：所述第一用户终端，用于获取商家信息，根据第一用户在所述商家信息包含的餐品信息中选定的餐品信息，生成未支付状态的用餐订单，并将所述未支付状态的用餐订单发送至所述第二用户终端；所述第二用户终端，用于接收所述第一用户终端发送的未支付状态的用餐订单以及第二用户输入的确认收款指示，并在接收到第二用户输入的确认收款指示后，将所述未支付状态的用餐订单的状态更新为已支付；在接收到第二用户输入的烹饪完成指示后，向所述第一用户终端发送取餐指示。通过上述系统，能够避免用户排队点餐及取餐，防止出现点餐或取餐档口人群拥挤的现象，节省点餐时间，在餐品烹饪完成后能及时通知用户取餐，提高工作效率。

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

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例所提供的智能点餐系统的架构示意图；

图2示出了本申请实施例所提供的智能点餐系统的交互流程示意图；

图3示出了本申请实施例所提供的应用于第一用户终端的智能点餐方法的流程示意图；

图4示出了本申请实施例所提供的智能点餐装置400的架构示意图。

图5示出了本申请实施例所提供的应用于第二用户终端的智能点餐方法的流程示意图；

图6示出了本申请实施例所提供的智能点餐装置600的架构示意图；

图7示出了本申请实施例所提供的电子设备700的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

考虑到现有美食广场或商圈点餐时，需要耗费大量时间排队点餐、取餐，且商家在烹饪好餐品后无法及时通知顾客取餐，为解决上述问题，本申请实施例提供了一种智能点餐系统、方法及装置。

首先，参见图1所示，为本申请实施例提供的一种可能的智能点餐系统的架构示意图，该智能点餐系统包括：第一用户终端、第二用户终端、第三用户终端以及服务器。其中，第一用户终端可以从服务器端获取商家信息，并根据第一用户对商家信息中包含的餐品信息的选定的餐品信息，生成未支付状态的用餐订单，并将生成的未支付状态的用餐订单发送至第二用户终端以及服务器；第二用户终端可以接收到第一用户终端发送的未支付状态的用餐订单以及第二用户输入的确认收款指示，并在接收到第二用户输入的确认收款指示后，将未支付状态的用餐订单的状态更新为已支付，以及在接收到第二用户输入的烹饪完成指令后，向第一用户终端发送取餐指示；第三用户终端可以录入商家信息，并将录入的商家信息发送至服务器，以及从服务器获取第二用户终端接收到的用餐订单，对第二用户终端接收到的用餐订单中包含的每个餐品进行统计，确定每个餐品的销售情况，或获取至少一个第二用户终端在一定时间内的用餐订单，如一个月的用餐订单，确定每个第二用户终端每一种餐品的销售情况，并相应地调整销售策略，以及对第二用户的账号进行管理；第二用户终端也可以获取商家信息，并根据第二用户输入的更新指令，更新商家信息，并将更新后的商家信息发送至服务器。服务器中所存储的用餐订单的状态根据第一用户终端生成的用餐订单状态的改变而实时改变。

下面，结合图1所示的智能点餐系统，给出具体实施例对本申请实施例提供的智能点餐方法进行详细说明。

实施例一

参见图2所示，为本申请实施例提供的智能点餐系统的交互流程示意图，包括以下步骤：

s201、第一用户终端获取商家信息。

在一种可能的实施方式中，商家信息可以由第一用户终端从服务器获取，其中，商家信息中包含但不限于商家位置信息以及餐品信息。

第一用户终端获取商家信息前可以先判断是否可以获取第一用户的位置信息，若判断结果为是，则根据获取的用户的位置信息以及每一个商家信息中包含的商家的位置信息，计算用户与每一个商家之间的距离，并按照计算出的距离对每一个商家信息进行排序。

一种可能的实施方式，预先统计所有商家的位置信息，然后按照商家的位置信息，把商家信息归属为不同的区域。获取第一用户的位置信息后，判断第一用户的所归属的区域，计算第一用户归属区域内每一个商家信息的位置信息与第一用户之间的距离。

例如获取的第一用户的位置信息为广开街23号，判断广开街23号归属a区，则计算a区中所有商家信息中商家的位置信息与第一用户的位置信息之间的距离，按照计算出的距离对第一用户终端获取的商家信息进行排序。

其中，若获取的位置信息并非属于中国，第一用户终端可以根据获取的位置信息自动判断第一用户所在国家所使用的货币，并根据汇率计算生成的用餐订单所需支付的金额。

若第一用户终端不能获取第一用户的位置信息，则可以根据第一用户选定的筛选条件对每一个商家信息中包含的餐品信息进行筛选，将符合筛选条件的餐品信息所对应的商家信息确定为选定商家信息，并对选定商家信息按照符合筛选条件的餐品的销售情况进行排序。

例如第一用户的筛选条件为麻婆豆腐，则可以将所有商家信息中的餐品信息包含麻婆豆腐的商家信息确认为选定商家信息，然后按照所有选定商家信息中麻婆豆腐的销售情况进行排序。

s202、第一用户终端根据第一用户在商家信息包含的餐品信息中选定的餐品信息，生成用餐订单。

其中，在第一用户终端生成用餐订单后，第一用户还可对用餐订单进行文字备注，如口味微辣、不要香菜等。

第一用户终端在生成用餐订单前还可以获取餐品信息中每一种餐品的价格，并在生成用餐订单后计算第一用户所需支付的金额。其中，用户可以选择用餐方式为打包带走或者在店内食用，若选择打包带走，计算用餐订单金额时，除餐品总价外还可加入第二用户预设的打包费用，将餐品总价和打包费用一起作为用餐订单金额。

一种可能的实施方式中，第一用户直接使用线上支付的方式对所需支付的金额进行支付；第二用户还可以指定线下支付的方式，第一用户可以提前办理与商家信息相关的预付卡，提前在预付卡中存入一定金额，在生成用餐订单后，可以凭借用餐订单号，使用预付卡对用餐订单进行支付。

s203、第一用户终端将用餐订单发送至第二用户终端。

其中，在本步骤中，第一用户终端可以记录将用餐订单发送给第二用户终端的时刻，在当前时刻与记录的将用餐订单发送给第二用户终端的时刻之间的时长超过第一预设时长时，提示第一用户取消用餐订单。

例如，第一预设时长为10分钟，第一用户在2018年9月6日上午7：00向第二用户终端发送了用餐订单，则第一用户在2018年9月6日上午7:10之前若未对生成的用餐订单进行支付，则提示第一用户取消订单。

一种可能的实施方式中，第一用户终端将未支付状态的用餐订单发送至第二用户终端，并在将未支付状态的用餐订单发送到第二用户终端之后，获取未支付状态订单所需支付的金额，并根据获取的金额，以及第二用户预设的支付方式，对未支付的用餐订单进行支付，最后将未支付的用餐订单状态更新为已支付。

一种可能的实施方式中，第一用户在生成用餐订单时，可以生成订单编号，第一用户可以凭借该订单编号对用餐订单支付，且在餐品烹饪完成，收到第二用户终端发送的取餐指示后，凭借该订单编号进行取餐。其中，第二用户可以根据接收到的用餐订单的先后顺序，对用餐订单上所包含的菜品进行烹饪。

s204、第二用户终端接收第一用户终端发送的用餐订单。

一种可能的实施方式中，第二用户终端接收到第一用户终端发送的用餐订单后，第二用户终端可以记录第二用户终端接收用餐订单的时刻。当当前时刻距离记录的第二用户终端接收用餐订单的时刻之间的时长超过第二预设时长时，第二用户终端可以向第一用户终端发送订单确认信息，其中，订单确认信息用于确认是否继续等待用餐订单完成。

例如，第二预设时长为30分钟，第一用户终端在2018年9月6上午11:00向第二用户终端发送了用餐订单，而第二用户终端已接收的用餐订单较多，在2018年9月6日上午11:30之前，若第二用户终端没有接收到第二用户输入的取餐指示，则第二用户终端会自动向第一用户终端发送订单确认信息，第一用户通过第一用户终端接收到订单确认信息时，可以选择继续等待订单完成或取消订单。

一种可能的实施方式中，若第一用户无法通过第一用户终端生成用餐订单，如第一用户忘带手机等情况，第一用户可以按照对餐品信息的选择，通过第二用户终端生成用餐订单；第二用户终端在生成用餐订单之后，还可以生成取餐号，然后通过外接打印机打印取餐号；在餐品烹饪完成后，第二用户可以通过喊号的方式通知第一用户取餐。

s205、第二用户终端在接收到第二用户输入的烹饪完成指示后，向第一用户终端发送取餐指示。

在本步骤中，第一用户接收到取餐指示后，可凭借订单编号领取对应餐品。

一种可能的实施方式中，第三用户可以通过第三用户终端录入商家信息，并将录入的商家信息发送至服务器，第一用户终端和第二用户终端可以从服务器获取商家信息。但若商家信息需要更新，第二用户可以通过第二用户终端对商家信息进行更新。例如若某商家信息中麻婆豆腐的价格为23元，第二用户需要将菜品价格更改为26元，则可以对第二用户终端发送更新指令，第二用户终端按照更新指令更新商家信息，并将更新后的商家信息发送给服务器。当第一终端再次从服务器获取商家信息时，即可获得更新后的商家信息。

一种可能的实施方式中，第三用户终端可以从服务器获取第二用户终端所接收的所有用餐订单，并对第二用户终端接收的每一个用餐订单中包含的每一个餐品进行统计，确定每个菜品的销售情况，以及通过获取第一用户通过第一用户终端对用餐订单中每个餐品的评分，确定每个餐品的好评情况。第二用户可以通过第二用户终端从服务器端获取每个菜品的销售情况以及好评情况，根据销售情况和好评情况调整销售策略。

一种可能的实施方式中，第三用户终端还可以从服务器获取至少一个第二用户终端的一定时间内的用餐订单，如一个月的用餐订单，确定每个第二用户终端每一种餐品的销售情况，第三用户可以根据每个第二用户终端每一种餐品的销售情况，对第二用户的餐品销售进行调整。例如学校食堂的管理人员可以作为第三用户，食堂的各个档口可以作为第二用户，食堂的管理人员可以对食堂的各个档口的各种餐品的销售情况进行统计，并可以对销量低的餐品加大优惠力度，促进消费，以及统计各个食堂档口在一定时间内的营业额，如一个月的营业额，并根据统计出的营业额，对食堂不同的档口进行不同的管理策略等。

一种可能的实施方式中，第三用户终端可以为第二用户终端配置账号的初始密码，每个账号只能绑定一个设备，例如可以绑定手机ip地址，第二用户若需要在其他设备上使用账号，则需要对于原有设备进行解绑，保障账号使用过程中的信息安全。

在另外一种可能的实施方式中，第三用户终端还可以管理第二用户终端的账号，可以添加第二用户终端的账号，也可以对第二用户终端的账号进行注销。如可以为新增的第二用户配置账号，也可对停止营业的第二用户的账号进行注销等。

实施例二

本申请实施例提供了一种智能点餐方法，参照图3所示，为一种智能点餐方法的流程示意图，该方法应用于第一用户终端，包括以下步骤：

s301、第一用户终端获取商家信息。

其中，第一用户终端，在获取商家信息之前，还用于：

判断是否可以获取用户的位置信息；

若判断结果为是，则根据获取的用户的位置信息以及每一个商家信息中包含的商家的位置信息，计算用户与所述每一个商家之间的距离，并按照所述距离对所述每一个商家信息进行排序；

若判断结果为否，则根据第一用户选定的筛选条件对每一个商家信息中包含的餐品信息进行筛选，将符合筛选条件的餐品信息所对应的商家信息确定为选定商家信息，并对所述选定商家信息按照符合筛选条件的餐品的销售情况进行排序。

s302、第一用户终端根据第一用户在商家信息包含的餐品信息中选定的餐品信息，生成用餐订单。

其中，当第一用户无法通过第一用户终端生成用餐订单时，第二用户终端还可用于根据第一用户对所述餐品信息中包含的餐品的选择，生成用餐订单。

s303、第一用户终端将用餐订单发送至第二用户终端以及服务器。

第一用户终端，在将所述用餐订单发送至所述第二用户终端，具体用于：

将未支付状态的用餐订单发送至所述第二用户终端。

第一用户终端，在将未支付状态的用餐订单发送至第二用户终端后，还用于：

获取所述未支付状态的用餐订单所需支付的金额；

根据获取的所述金额，以及第二用户预设的支付方式，对所述未支付状态的用餐订单进行支付；

将未支付状态的用餐订单的状态更新为已支付。

其中，第一用户终端，还用于:

记录所述第一用户终端发送所述用餐订单的时刻；

当当前时刻距离记录的所述第一用户终端生成所述用餐订单的时刻之间的时长超过第一预设时长时，提示第一用户取消用餐订单。

其中，服务器存储的用餐订单的状态按照第一用户终端的用餐订单的状态实时改变。

s304、第一用户终端接收取餐指示。

其中，所述取餐指示为第二用户终端在接收到所述第二用户输入的烹饪完成指示后，向所述第一用户终端发送的。

实施例三

本申请实施例提供了一种智能点餐装置，参照图4所示，为本申请实施例提供的一种智能点餐装置400的架构示意图，该装置400包括获取模块401、生成模块402、发送模块403以及接收模块404。

具体的，获取模块401，用于获取商家信息；

生成模块402，用于根据第一用户在所述商家信息包含的餐品信息中选定的餐品信息，生成用餐订单；

发送模块403，用于将所述用餐订单发送至所述第二用户终端以及服务器；

接收模块404，用于接收收取餐指示，其中所述取餐指示为第二用户终端在接收到所述第二用户输入的烹饪完成指示后，向所述第一用户终端发送的。

实施例四

本申请实施例提供了一种智能点餐方法，参照图5所示，为一种智能点餐方法的流程示意图，该方法应用于第二用户终端，包括以下步骤：

s501、第二用户终端接收第一用户终端发送的未支付状态的用餐订单；

s502、第二用户终端接收第二用户输入的确认收款指示，并将未支付状态的用餐订单的状态更新为已支付；

一种可能的实施方式中，若第一用户无法通过第一用户终端生成用餐订单，第二用户终端还可以根据第一用户对所述餐品信息中包含的餐品的选择，生成用餐订单。

s503、第二用户终端接收第二用户输入的烹饪完成指示；

s504、第二用户终端在接收到第二用户输入的烹饪完成指示后，向第一用户终端发送取餐指示。

实施例五

本申请实施例提供了一种智能点餐装置，参照图6所示，为本申请实施例提供的一种智能点餐装置600的架构示意图，该装置600包括第一接收模块601、第二接收模块602以及发送模块603。

具体的，第一接收模块601，用于接收第一用户终端发送的用餐订单；

第二接收模块602，用于接收第二用户输入的烹饪完成指示；

发送模块603，用于在接收到第二用户输入的烹饪完成指示后，向所述第一用户终端发送取餐指示。

实施例六

如图7所示，为本申请实施例五所提供的一种电子设备700的结构示意图，包括：处理器701、存储器702和总线703；

所述存储器702存储有所述处理器701可执行的机器可读指令，当电子设备700运行时，所述处理器701与所述存储器702之间通过总线703通信，所述机器可读指令被所述处理器701执行，所述处理器701在处理第一用户终端的操作时执行如下处理：

获取商家信息；

根据第一用户在所述商家信息包含的餐品信息中选定的餐品信息，生成用餐订单；

将所述用餐订单发送至所述第二用户终端以及服务器；

接收取餐指示，其中所述取餐指示为第二用户终端在接收到所述第二用户输入的烹饪完成指示后，向所述第一用户终端发送的。

另外一种可能的实施方式，所述处理器701处理第二用户终端的操作时执行如下处理：

接收第一用户终端发送的用餐订单；

接收第二用户输入的烹饪完成指示；

在接收到第二用户输入的烹饪完成指示后，向所述第一用户终端发送取餐指示。

实施例七

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述任一实施例中所述的智能点餐方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述数据共享方法的步骤，从而解决目前现有美食广场或商圈点餐时，需要耗费大量时间排队点餐、取餐，且商家在烹饪好餐品后无法及时通知顾客取餐的问题。

本申请实施例还提供一种数据共享方法的计算机程序产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行前面方法实施例中的方法，具体实现可参见方法实施例，在此不再赘述。

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

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

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

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。