桌位状态信息处理方法、装置及系统与流程

本申请涉及餐饮信息处理技术领域，特别是涉及桌位状态信息处理方法、装置及系统。

背景技术：

在餐饮行业高速发展的同时，原材料成本升高、劳动力成本提升、租金成本上涨、管理人才匮乏、成本控制困难等多方面问题日益凸显，传统的管理、经营模式遭遇严峻挑战。如何迅速由传统的“粗放式、模糊式、经验式经营”向“精细化、流程化、规模化经营”转型，成为整个餐饮行业需要面对的问题。于是，餐饮管理系统便应运而生了，该系统是服务于餐馆的日常管理的，为了满足餐饮业发展，科学管理餐馆管理、提高效率的管理系统，通常能够帮助餐饮业提高服务质量、工作效率、准备的考评员工绩效，掌握消费者信息，及时协调处理缺货情况，等等。

例如，现有的餐饮管理系统能够提供的功能还比较有限，通常仅仅是解决了纸质工作流程的问题，或者部分标准的人工问题，例如，菜谱更新，扫码下单，送单到后厨，供应链的关系维护，采购清单的维护等。但是，对于人与人之间的沟通成本的问题，现有技术中并没有得到很好的解决。例如，在存在用户排位的情况下，排位区负责进行用户引导的服务员，需要依赖于用餐区其他的服务员通过对讲机等设备向其传达的信息，才能够获知是否有桌位空出等信息，进而据此对用户进行引导。但是，这种方式的实现效率比较低，并且依赖于用餐区的服务员及时发现各桌位的情况，以及及时向其他岗位上的服务员进行通知。

因此，如何通过餐饮管理系统进一步提升餐厅的服务质量，降低服务员与服务员之间的沟通成本，成为需要本领域技术人员解决的技术问题。

技术实现要素：

本申请提供了桌位状态信息处理方法、装置及系统，可以节省服务员与服务员之间的沟通成本，降低对服务员能力及素质的依赖，提升餐厅整体上的服务效能。

本申请提供了如下方案：

一种桌位状态信息处理系统，其特征在于，包括：

信息采集子系统，部署于餐厅用餐区，用于对所述用餐区中的各桌位进行图像采集；

服务器，用于根据各桌位的图像采集信息，确定各桌位的状态变化信息，并提供对应的通知信息。

一种桌位状态信息处理方法，包括：

通过餐厅用餐区部署的信息采集子系统对所述用餐区中的各桌位进行图像采集；

根据各桌位的图像采集信息，确定各桌位的状态变化信息；

根据所述桌位的状态变化信息，提供对应的通知信息。

一种桌位状态信息处理装置，包括：

桌位图像采集单元，用于通过餐厅用餐区部署的信息采集子系统对所述用餐区中的各桌位进行图像采集；

桌位状态变化信息确定单元，用于根据各桌位的图像采集信息，确定各桌位的状态变化信息；

通知单元，用于根据所述桌位的状态变化信息，提供对应的通知信息。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

通过餐厅用餐区部署的信息采集子系统对所述用餐区中的各桌位进行图像采集；

根据各桌位的图像采集信息，确定各桌位的状态变化信息；

根据所述桌位的状态变化信息，提供对应的通知信息。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例提供的餐饮信息处理系统，能够通过信息采集子系统获知具体桌位上的信息，从而根据各桌位的图像采集信息，确定各桌位的状态变化信息，并提供对应的通知信息，从而可以节省服务员与服务员之间的沟通成本，降低对服务员能力及素质的依赖，提升餐厅整体上的服务效能。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1-1、1-2是本申请实施例提供的应用场景及系统布局示意图；

图2是本申请实施例提供的第一系统的示意图；

图3是本申请实施例提供的菜品加工制作流程示意图；

图4是本申请实施例提供的等位区大屏互动示意图；

图5是本申请实施例提供的送餐机器人设备系统示意图；

图6是本申请实施例提供的第一方法的流程图；

图7是本申请实施例提供的第二方法的流程图；

图8是本申请实施例提供的第三方法的流程图；

图9是本申请实施例提供的第四方法的流程图；

图10是本申请实施例提供的第五方法的流程图；

图11是本申请实施例提供的第六方法的流程图；

图12是本申请实施例提供的第二系统的示意图；

图13是本申请实施例提供的第七方法的流程图；

图14是本申请实施例提供的第一装置的示意图；

图15是本申请实施例提供的第二装置的示意图；

图16是本申请实施例提供的第三装置的示意图；

图17是本申请实施例提供的第四装置的示意图；

图18是本申请实施例提供的第五装置的示意图；

图19是本申请实施例提供的第六装置的示意图；

图20是本申请实施例提供的第七装置的示意图；

图21是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

本申请发明人在实现本申请的过程中发现，对于消费者用户而言，在传统的餐厅进行就餐过程中经常出现的情况至少包括：到达餐厅时，需要向服务器询问当前是否有可用桌位，如果当前没有可用桌位，则需要排号等位，在等位过程中，如果需要提前点餐，则通常只能在服务员提供的纸质菜单上进行选择。如果有可用桌位，则在服务员引导下到达目标桌位，通常，这种桌位是由服务员进行指定，或者，用户也可以在服务员引导的过程中进行选择。在到达具体的桌位后进行点餐的过程中，如果自己没有足够的点餐经验，则可能需要请服务员帮助进行推荐；在点餐完毕后，等待上菜的过程中，如果发现有些菜品上菜比较慢，则可能还需要招呼服务员进行询问当前的进度，或者帮忙催促，如果不能及时得到解决，则可能会导致用户爆发出不满情绪，等等。总之，在整个过程中，用户经常需要不断的从服务员处获得帮助，以至于用户实际感受到的餐厅服务质量很大程度上依赖于服务员的数量以及素质。

针对上述各种问题，在本申请实施例中，提供了软硬件一体化的餐饮管理系统。例如，在硬件方面，可以在餐厅门口等位区部署显示屏，用于展示一些互动游戏信息、营销信息等。在餐厅用餐区还可以部署摄像头等信息采集设备，可以用于对具体桌位的状态变化信息进行采集，对具体桌位用餐人数进行采集，对进入餐厅的用户进行人脸图像采集，等等。再者，还可以提供送餐机器人，实现机器人送餐，等等。

在软件层面，首先可以提供作为信息中心的服务器端程序，该服务器端可以用于接收各种信息，包括用户具体的订单信息，图像采集设备采集到的信息，等等，另外还可以实现对用户点餐过程中的信息推荐，对菜品制作进度信息的透出，对用户可能出现的情绪爆发点的预估，对具体桌位状态的自动识别，对相关服务人员的信息自动推送，等等。另外，还可以提供消费者用户的第一客户端，通过该第一客户端，用户可以完成预约，在本申请实施例中，预约过程中还可以向用户提供餐厅的桌位布局以及具体用餐时间段内的桌位状态信息，用户可以对自己所需的桌位进行预约，还可以通过第一客户端实现具体的点餐等操作。另外，该系统内还可以为餐厅服务员提供第二客户端，主要用于接收服务器提供的一些推送信息，其中，服务器推送的信息具体可以包括推送具体桌位状态的信息到负责清洁桌位的服务员，或者负责排队排位引导的服务器等等，推送订单信息或者菜品制作超时提醒信息等到后厨调度员，推送用户情绪爆发点信息到负责情绪安抚的服务员，等等。

具体实现时，参见图1-1及1-2，其示出了一种具体实施方式下的场景图，其中，图1-1主要涉及餐厅前方用餐区的硬件部署情况，而图1-2主要涉及餐厅后方加工制作区的硬件部署情况。从图中可以看出，其中可以包括服务器，以及餐厅内的无线wifi设备①，蓝牙采集设备②，pad等终端设备③，摄像头④，扫码枪⑤，以及tv大屏⑥。

总之，通过上述软硬件一体化的管理系统，可以更好的实现信息自动化，降低对用户与服务人员之间交流的依赖，使得消费者用户可以获得更快更全面的信息，也可以提升餐厅的服务效能，提升餐厅服务员的信息效率，节省餐厅人力成本。

具体实现时，本申请实施例所提供的系统具体可以涉及多个餐饮服务阶段的改进，各项改进可以单独存在，也可以相互融合等等。下面分别进行介绍。

实施例一

该实施例一主要从如何降低消费者用户在用餐过程可能出现的不满意情绪的概率角度出发，提供了一种餐饮信息处理系统，参见图2，该系统具体可以包括：

信息采集子系统201，用于部署在餐厅的用餐区，对所述用餐区内有用户就座的目标桌位进行信息采集；

所述服务器202，用于根据所述信息采集子系统的信息采集结果，确定目标桌位对应的菜品相关情况信息，并根据所述菜品相关情况信息对该目标桌位进行用户情绪预估。

其中，具体在对用户情绪进行预估时，由于用户的情绪是否爆发可能与桌位的具体菜品消耗情况等相关，例如，如果某些用餐人员需要赶时间，则用餐速度较快，对上菜时间间隔的要求也会更高，而对于用餐速度较慢的用户，则证明其不赶时间，其对上菜时间间隔的要求也会比较低，也即，即使上菜时间间隔较长，也不容易造成这种用户的情绪爆发。因此，在本申请实施例中，主要可以通过对目标桌位上的菜品相关信息进行统计，来实现对用户情绪的预估。其中，所谓的菜品相关情况包括两种，一种是在菜品上桌之前，意味着桌位上没有可供消耗的菜品，因此，可以根据所述菜品情况采集结果，确定所述目标桌位关联的已下单时间信息，此时，可以根据所述已下单时间信息，对该目标桌位进行用户情绪预估。另一种是在已经有菜品上桌之后，用户开始进行用餐，期间的用餐速度对应着菜品消耗速度，用户速度越快，菜品消耗的速度越快，等等。也即，根据所述菜品情况采集结果，确定所述目标桌位关联的用户对已上桌菜品的消耗速度情况，以及剩余菜量信息，根据所述消耗速度以及所述剩余菜量信息，对该目标桌位进行用户情绪预估。

其中，为了能够获得具体桌位上用户的菜品相关情况信息，该系统中可以通过餐厅用餐区部署的信息采集子系统，对所述用餐区具体桌位的进行信息采集。具体的，在一种实现方式下，该信息采集子系统具体可以是摄像头等图像采集子系统，通过对具体桌位进行图像采集，则服务器便可以通过对采集到的图像进行图像分析的方式，获得具体桌位的用户菜品相关情况，其中可以包括桌位上剩余菜量的多少，用户的用餐速度的快慢等，都可以通过图像分析等方式进行确定。

另外，还可以根据所述菜品情况采集结果，获得所述目标桌位各菜品的上菜时间间隔信息，此时，可以根据所述消耗速度，所述剩余菜量信息以及上菜时间间隔信息，对该目标桌位进行用户情绪预估。另外，服务器还可以获得所述目标桌位的菜品制作进度信息，此时，可以根据所述制作进度信息以及所述菜品相关情况信息，对该目标桌位进行用户情绪预估。其中，具体在对用户情绪进行预估时，可以预先设置具体的算法，在该算法中，输入的数据可以是具体桌位对应的菜品制作进度信息(具体可以量化为所述具体桌位的上菜时间间隔信息，每道菜的制作时间信息，当前菜预计的上桌时间信息，当前时刻距离上一菜品的上桌时刻的时间间隔信息，等等)，以及该桌位的菜品相关情况(具体可以量化为桌位上菜品剩余量，用餐速度，等等)，输出的数据则可以为用户的情绪爆发指数等，通过该指数的高低，确定出用户是否即将爆发出不良情绪，等等。

其中，为了能够获得所述菜品制作进度信息，还可以在餐厅的加工制作区，设置“打盒员”岗位(当然，也可以有其他的称呼)。该“打盒员”的职责主要是对加工制作区的工作进行调度。例如，“打盒员”可以操作一个pad等终端设备，其中可以安装有第二客户端，例如，如图3所示，在一种具体的实现方式下，加工制作区的具体工作流程可以为：

1.服务器可以接收用户通过第一客户端提交的点餐信息，并生成订单信息；

2.服务器将具体订单信息推送至该“打盒员”的第二客户端。

3.“打盒员”根据当前加工制作区的状态，选择要处理的菜品，并通知给切配员。

4.切配员根据“打盒员”的指示，进行菜品原材料的制作，并在制作好后通知给“打盒员”。

5.“打盒员”可以根据切配员回传的相应菜品的制作进度信息更新为切配完毕，并且可以回传给服务器。另外，还可以根据掌勺厨师的忙闲状态等情况，将切配号的菜与装菜的容器一起传给厨师进行菜品制作。

6.厨师在制作好成品的菜品后进行装盘，并将装有成品的容器以及制作完成的信息传回给“打盒员”。

7.“打盒员”根据厨师处收到回传的容器后，可以将对应菜品的制作进度信息更新为制作完成，并提交到服务器，使得服务器获知具体菜品的制作进度信息。服务器在收到具体菜品制作完成的消息后，还可以通知传菜员对应的第二客户端；

8.传菜员则可以将制作好的菜品送到对应的桌位。

需要说明的是，上述流程中各个岗位上的服务员，包括打盒员，切配员，传菜员等，可以是具体的人工，或者还可以通过机器人等设备来坚守各个具体岗位。

可见，通过上述方式，使得服务器可以掌握具体菜品的加工制作进度信息，进而，还可以将这种具体加工制作信息透出给消费者用户，使得消费者用户可以直观的获知具体菜品的制作进度信息，使其对具体上菜的时间等产生合理的心理预期，降低其由于感觉等待时间过长而产生不良情绪。另外，由于消费者用户在等待过程中，可以直接通过第一客户端查看到菜品的制作进度信息，因此，不必通过询问服务员也可以获知相关的信息，降低了消费者用户与服务员之间的交流成本。

当然，这里需要说明的是，由于同时在餐厅中就餐的人数可能会很多，因此，加工制作区同时收到的订单数量通常也会比较多，尤其是在集中用餐的时间段。这就涉及到菜品制作顺序的调配问题。在前述例子中，可以由“打盒员”充当加工制作区调度员的角色，可以根据自身经验等实现调度，包括安排菜品的加工制作顺序，等等。

其中，如前文所述，所述制作进度信息包括菜品的状态信息，所述状态信息包括制作中状态，以及制作已完成状态，等等。其中，当所述菜品处于制作中状态时，所述服务器还可以对所述菜品的上菜时间进行预估，此时，提供给所述第一客户端的所述制作进度信息还可以包括所述预估的上菜时间信息。其中，具体在对菜品上菜时间进行预估时，可以考虑多方面的因素，例如，该菜品之前等待制作的菜品的数量，各菜品制作平均所需的时间，等等。通过这种预估的上菜时间信息，使得消费者用户可以更直观的获得具体的加工制作进度信息。当然，在前述方式中，服务器可以将菜品的加工制作进度信息推送给第一客户端，而在其他情况下，所述服务器还可以用于接收到所述第一客户端的查询请求时，将该第一客户端关联订单中的菜品制作进度信息返回给所述第一客户端。也即，用户也可以通过第一客户端主动向服务器发起具体菜品的制作进度查询请求，服务器可以做出响应。

通过上述方式，可以使得用户能够对具体所点菜品的制作进度信息有所了解，但是，在实际应用中，尤其是在用餐高峰时间段内，仍然可能会出现用户等待时间较长等情况，以至于可能导致用户爆发出一些焦急的情绪，等等。在现有技术中，当菜品迟迟未上，已经超出用户所能容忍的时间的情况下，只能招呼服务员帮忙去后厨进行问询。但是，经常会出现由于服务员太忙，无法及时听到用户的诉求，或者，无法及时赶到后厨进行询问等情况，另外，即使进行了询问，后厨也可能因为过于忙乱，而无暇顾及用户的诉求，等等。而在本申请实施例中，针对这种情况，服务器还可以通过一些信息对用户情绪进行预估，一旦发现某桌位的用户可能会出现情绪爆发的情况，可以通知相关岗位上的服务员到该桌位进行安抚，还可以向加工制作区发送超时提醒信息，或者提示其优先处理该桌位的菜品，等等。这样，无需用户主动招呼服务员，便可以在其情绪即将爆发之际，有服务员过来对其进行安抚，另外，通过系统消息提醒的方式进行提示，相对于服务员的口头提醒而言，也更为有效，更容易引起加工制作区相关人员的注意，等等。

另外，如前文所述，所述服务器还可以用于：如果所述用户情绪预估结果达到预置的阈值，则将该目标桌位的标识信息以及关联的用户情绪预估信息提供给相关职责的服务员用户对应的第二客户端。或者，如果所述用户情绪预估结果达到预置的阈值，则还可以通知所述加工制作区对应的第二客户端加快对该桌位关联菜品的制作进度。

通过上述对用户情绪爆发点的预估，可以及时安排相关的服务员对用户情绪进行安抚，还可以及时通知加工制作区加快对应桌位相关菜品的制作进度，等等。总之，使得用户在即将爆发出不良情绪之前可以及时得到缓解，并且，在此过程中，不需要用户主动联系服务员，也不需要服务员联系加工制作人员，等等，因此，效率更高，也是的用户获得更好的体验。

除了在点餐完成以及用餐过程中为用户提供相应的服务，在具体实现时，还可以在预约、等位、点餐等环节，为消费者用户提供更好更全面的服务。其中，在预约环节，所述服务器还可以用于，接收到对所述餐厅的桌位预约请求时，提供所述餐厅的桌位三维布局信息，以及各桌位在对应预约时间段内的状态信息。此时，所述第一客户端还可以用于，对所述三维布局信息以及所述状态信息进行展示，并提供用于对可选桌位进行选择的操作选项，并将桌位选择结果提交到服务器。

也就是说，在本申请实施例中，用户在提前进行预约时，除了可以对具体的用餐时间等进行选择，还可以对具体的桌位进行选择，并且，在选择桌位时，可以为用户提供三维的桌位布局信息，也即，使得用户可以直观的观看到具体桌位在餐厅中的布局，哪些桌位靠窗，哪些桌位有卡座，等等，这样，使得用户可以更好的进行桌位选择。当然，在进行预约的过程中，可以限制为在同一用餐时段内，同一桌位只能被同一个用户进行预约，因此，当某桌位被某用户进行预约后，该桌位该用餐时段对应的状态信息便成为已预约状态，其他用户不能再对该桌位进行预约，除非修改用餐时段，等等。

另外，在进行预约的过程中，除了可以选择桌位，还可以对具体的菜品进行选择，此时，所述服务器还可以用于，接收通过所述第一客户端提交的预约点餐信息，并根据预约点餐信息生成订单；在用户到店并通过该第一客户端接收到桌位标识扫码结果后，将该桌位标识与该订单信息进行关联，并推送到所述餐厅加工制作区的第二客户端。也就是说，在用户进行预约的过程中，便可以通过第一客户端将餐厅内具体可选择的菜品信息进行提供，并且，用户可以进行预约点餐。之后，服务器可以生成对应的订单，但是，由于在用户具体进入餐厅之前，都有可能会取消订单，因此，可以在用户到达餐厅之后，以该用户对其预约的桌位关联的图形码等进行扫码这一动作为准，来确定用户确实要进行用餐，此时，再将具体的订单信息发给加工制作区，进行菜品的加工制作。另外，在实际应用中，也可以在用户到达餐厅之前就进行菜品的加工制作，该服务可以作为可选项提供给用户，用户如果选择该服务，则还可以要求用户支付一定的定金等，当然，还可以与用户的信用记录等情况相关联，如果用户的信用分数高于某值，可以免定金使用该服务，如果低于该阈值，则需要支付订单，并且，信用分数越低，需要支付的定金金额越高，等等。

通过上述在预约过程中提供的三维的桌位布局信息，使得用户可以更直观的进行桌位的预约选择，提升系统的服务能力。

另外，对于未预先进行预约的用户，在到达餐厅后，可能会出现需要排队等位的情况，而在现有技术中，如果用户在等位的过程中需要提前进行点餐，只能在餐厅提供的纸质点餐单上进行选择或者填写。而在本申请实施例中，还用户还可以通过第一客户端提前进行点餐，具体实现时，用户可以通过具体的第一客户端对餐厅门口等位置提供的图形码等进行扫码的方式，发起提前点餐。此时，第一客户端中可以展示出餐品详情页，用户还可以对所需要的服务类型进行选择，例如，堂食或打包带走等。之后，用户便可以对菜品进行选择，服务器可以对选择的菜品进行记录，并生成相应的订单。在用户被排位引导后，可以在服务员引导等方式下到达其中一桌位，之后，可以对该桌位上预先设置的图形码进行扫码，此时，服务器便可以将该桌位号与该用户之前生成的订单进行关联，并推送给加工制作区进行加工制作。也就是说，所述服务器还可以用于，接收在排队等位过程中通过所述第一客户端提交的点餐结果信息，并根据点餐结果信息生成订单；在通过该第一客户端接收到桌位标识扫码结果后，将该桌位标识与该订单信息进行关联，并推送到所述餐厅加工制作区的第二客户端。

需要说明的是，在具体实现时，可以支持多人将提前点餐的订单关联到同一桌位上。也就是说，可以多人共用同一桌位，服务器在记录桌位号与订单之间的关联关系时，同一桌位号可以关联多个订单，即使多个订单同时处于未结账状态。

另外，还可以在等位区设置显示屏，用于展示互动信息，例如，包括互动游戏等。用户可以通过所述第一客户端加入到与显示屏之间的互动中，也即，第一客户端还可以用于根据所述显示屏中显示的互动信息进行互动；所述服务器还可以用于，向所述第一客户端返回互动结果。

例如，参见图4，在一种具体的实现方式下，可以通过显示屏(tv大屏)初始化一个预置容量的“房间”(容纳30至50人，等等)，用户可以使用其第一客户端对显示屏上提供的图形码进行扫码等方式进入到互动房间中，通过多人对决寻宝等方式，获得最终的互动结果，通过服务器实现显示屏与各个参与互动的用户的第一客户端之间的数据同步。其中，所述互动结果可以包括所获得的与所述餐厅相关的消费权益信息，例如，优惠券，现金券，折扣券，满减，等等。

通过这种方式，一方面可以帮助用户打发等位过程中的空闲时间，避免等待的过程中过于枯燥，另外，还可以吸引线下客源，引导用户进行相关第一客户端的下载，提高第一客户端的装机量。再者，还可以使得餐厅的营销信息更直接的触达用户，无需再通过其他的手段对其营销信息进行宣传。

在用户进入用餐区到具体的桌位就座时，还可以及时通知相关的服务员前来服务，实现服务前置，而无需等到用户招呼服务员之后再来进行上茶水等服务。为了达到该目的，信息采集子系统还可以用于，对所述用餐区具体桌位的新用户就座信息进行采集；其中，具体实现时，该信息采集子系统同样可以是摄像头系统等。通过信息采集的方式，使得服务器可以获知某个桌位是否有新用户就座，进而，该服务器还可以用于，将所述新用户就座的通知消息以及关联的桌位标识信息推送给服务员用户的第二客户端。这样，对应岗位上的服务员便可以主动到达该桌位，进行倒茶水或者辅助点餐等服务。

此外，在点餐过程中，用户可能经常会出现不知道该如何选择，或者想要快速完成点餐等情况，而与服务员之间的交流效率通常比较低，服务员推荐的菜品主观性也比较大。为此，在本申请实施例中，所述服务器还可以用于，接收到所述第一客户端提交的点餐请求时，提供点餐推荐信息。也即，服务器可以根据用户的需求向用户推荐可点的菜品组合。具体实现时，为了达到上述目的，服务器还可以预先对餐厅内各种菜品进行打标，例如，具体的标签可以包括菜品所属的类别(热菜，凉菜，荤菜，素菜，汤品，甜品，主食，等)，口味(偏甜，麻辣，酸辣，等等)，适合的场合(同学聚会，老人寿宴，生日，等等)适合的用餐人数，等等。另外，为了更准确的进行推荐，还可以预先制定菜品组合规则，这种组合规则还可以与具体的用餐人数相关，例如，首先根据用餐人数确定菜品组合中的菜品数量，另外，还可以确定具体菜品组合中的类别，例如，如果用餐人数为两人，则推荐的菜品组合中可以包括一荤一素一汤，如果用餐人数是4人，则推荐的菜品组合中可以包括两荤两素一汤，等等。在进行了上述准备工作后，服务器只需要获知具体的用餐人数，以及所喜欢的口味或者所需的场合等信息，便可以比较准确的推荐出具体的菜品组合。其中，关于用餐人数信息，可以由用户通过第一客户端界面中提供的输入框进行填写，或者，另一种方式下，由于用餐区部署有摄像头等信息采集子系统，因此，也可以通过该子系统自动采集具体桌位关联的用餐人数信息，而无需用户手动进行填写。而关于具体所需要的口味，或者用餐的场合等，则可以在第一客户端的界面中提供多种可选的选项，用户可以从中选择自己所需的口味和/或场合，并提交到服务器，这样，服务器便可以根据所述用餐场合和/或口味偏好信息，以及预先为各菜品添加的标签信息提供点餐推荐信息。或者，如前文所述，为了更准确的进行推荐，系统中还可以包括信息采集子系统，部署于餐厅的用餐区，用于对所述用餐区具体桌位有新用户就座时，具体桌位关联的用户人数信息进行采集，此时，所述服务器提供的点餐推荐信息还与所述用户人数信息相关。

当然，在实际应用中，同一用户在不同用餐过程中用餐的口味等方面可能会具有一致性，例如，某用户喜欢偏辣口味，则每次点菜都以偏辣口味的菜为主。因此，所述服务器提供的点餐推荐信息还可以与用户的历史点餐记录信息相关。也就，具体实现时，除了考虑当前用户的人数，场合等信息，还可以结合用户的历史点餐记录信息进行综合的推荐。在完成点餐之后，便可以将相关的订单以及关联的桌位号等信息推送至加工制作区进行制作。

除了为消费者用户提供各种服务，降低其与服务员之间的交流成本，在本申请实施例中，还可以通过服务器，为餐厅内的服务员提供各种信息，降低服务员与服务员之间的交流成本。例如，具体的，服务器还可以实时识别各桌位的状态变化信息，并将相关的通知信息推送至对应岗位上的服务员。例如，在餐厅内用餐人数较多，等位区存在等位用户的情况下，在现有技术中，通常是由用餐区的服务员在发现某桌位的客人用餐完毕，并已经清洁完毕之后，通过对讲机等设备，通知等位区负责排位引导的服务员对下一位用户进行排位引导。而在本申请实施例中，服务器可以自动发现上述桌位的状态变化信息，然后，自动通知等位区相关的服务员即可，因此，不再依赖于服务员与服务员之间的口头交流。

具体的，为了使得服务器能够实时获得并更新桌位的状态变化信息，信息采集子系统还可以用于，对所述用餐区中的各桌位进行图像采集；所述服务器还可以用于，通过检测各桌位的图像采集信息，确定各桌位的状态变化信息。其中，该信息采集子系统具体也可以是摄像头等图像采集系统，具体实现时，可以复用前述各种服务中的信息采集子系统。当然，在该方案中，为了使得桌位状态识别结果更为精确，具体可以是在餐厅的顶部部署俯视角度摄像头，从而可以更清楚的监控具体桌位的用餐状态及人员流动情况。避免因为用户自主进入用餐区，或者主动换桌时引起的状态更新不及时等情况发生。

具体实现时，各桌位的初始状态为可选状态，所述服务器具体可以用于，如果检测到目标桌位有新用户就座，则将所述目标桌位切换为已占用状态；此时，如果用户发生了换桌的情况，并且在该目标桌位在之后预置时间段内无人就座，则可以将该桌位切换回可选状态。如果检测到目标桌位关联的图形码被扫码，则将所述目标桌位切换为点餐中状态；如果检测到所述目标桌位关联的订单被推送到加工制作区的第二客户端，则将所述目标桌位切换为用餐中状态。

另外，如果目标桌位关联的订单切换为已结账状态，且所述目标桌位在预置时间段内无人就座，则还可以将所述目标桌位切换为待清洁状态，并通知给负责清洁的服务员用户关联的第二客户端。

如果目标桌位已完成清洁工作，则将所述目标桌位切换为可选状态，并在存在等位用户的情况下，将该目标桌位的状态更新信息通知给负责排位引导的服务员用户关联的第二客户端。

通过上述方式，可以实现精准的桌位状态变更，并且还可以与排号系统相关联，提升前台排号引导人员的工作效率。另外，还可以根据当前用户就座时间点与整个就餐过程中的时间消耗，实现服务员前置服务，节省了用户与服务员、服务员与服务员之间的沟通成本。

另外，本申请实施例还可以在用餐区提供人脸识别服务，可以将识别出的用户身份信息以及关联的非隐私信息，提供给相关的服务员，使得服务员可以根据用户的具体情况提供相应的服务。另外，还可以实现人脸支付，等等。在这种情况下，该系统中同样可以包括信息采集子系统，部署于餐厅的用餐区，用于对进入所述用餐区的用户进行人脸图像信息采集；此时，所述服务器还可以用于，通过所述人脸图像信息识别用户身份信息，以及关联的非隐私信息，并提供给相关服务员的第二客户端。

在实际应用中，在本申请实施例中所涉及的餐厅中，用户除了可以在餐厅内堂食，或者到餐厅打包带走，还可以实现在线点餐，相应的，该系统中还可以配备送餐机器人设备，用于将菜品配送至订单中指定的地址。具体实现时，如果餐厅关联有酒店，也即，除了可以提供餐饮服务，还可以提供关联的住宿服务，则入住酒店的用户可以在线点餐，并要求配送至指定的房间。或者，送餐机器人也可以实现在一定区域范围内的餐厅/酒店外的送餐，例如，在一些大型办公园区内或者附近开设相应的餐厅，送餐机器人可以将具体的餐品送至园区内指定的办公楼、楼层、房间号，等等。另外，在需要送餐的订单数量较多的情况下，参见图5，服务器还可以根据订单的数量、送餐地址、每单预计的使用容积等进行订单合并，然后，系统进行调度，当有可用机器人时，将菜品放入机器人箱体内，由同一送餐机器人对合并后的各个订单进行配送。配送过程中，用户可以通过第一客户端实时查看机器人所在的位置，送到之后，可以通过扫码或者人工输入验证码等方式进行身份认证核销。

总之，通过本申请实施例提供的餐饮信息处理系统，能够通过信息采集子系统采集用餐区已经有用户就座的目标桌位上的信息，并根据这种信息采集结果确定目标桌位对应的菜品相关情况信息，并根据所述菜品相关情况信息对该目标桌位进行用户情绪预，进而可以通知相关的服务员前来安抚，或者，通知加工制作区优先制作对应桌位的菜品，等等，从而可以节省用户与服务员之间的沟通成本，降低对服务员能力及素质的依赖，提升餐厅整体上的服务效能。

实施例二

该实施例二是与实施例一相对应的，从服务器的角度，提供了一种餐饮信息处理方法，参见图6，该方法具体可以包括：

s601：根据部署于餐厅用餐区的信息采集子系统，获得对所述用餐区内有用户就座的目标桌位的信息采集结果；

s602：根据所述信息采集结果，确定所述目标桌位对应的菜品相关情况信息；

s603：根据所述菜品相关情况信息对该目标桌位进行用户情绪预估。

其中，具体实现时，可以在所述目标桌位的菜品上桌之前，根据所述菜品情况采集结果，确定所述目标桌位关联的已下单时间信息，此时，可以根据所述已下单时间信息，对该目标桌位进行用户情绪预估。或者，在所述目标桌位有菜品上桌之后，根据所述菜品情况采集结果，确定所述目标桌位关联的用户对已上桌菜品的消耗速度情况，以及剩余菜量信息，此时，可以根据所述消耗速度以及所述剩余菜量信息，对该目标桌位进行用户情绪预估。另外，还可以根据所述菜品情况采集结果，获得所述目标桌位各菜品的上菜时间间隔信息，这样，可以根据所述消耗速度，所述剩余菜量信息以及上菜时间间隔信息，对该目标桌位进行用户情绪预估。另外，还可以获得所述目标桌位的菜品制作进度信息，此时，可以根据所述制作进度信息以及所述菜品相关情况信息，对该目标桌位进行用户情绪预估。

具体实现时，如果所述用户情绪预估结果达到预置的阈值，则还可以将该目标桌位的标识信息以及关联的用户情绪预估信息提供给相关职责的服务员用户对应的第二客户端。或者，还可以通知所述加工制作区对应的第二客户端加快对该桌位关联菜品的制作进度。

另外，服务器还可以确定所述目标桌位关联菜品的制作进度信息，并将所述菜品的制作进度信息推送到所述目标桌位关联订单对应的第一客户端。其中，当所述菜品处于制作中状态时，还可以对所述目标桌位关联未上桌菜品的上菜时间进行预估，并推送到所述目标桌位关联订单对应的第一客户端。具体在对所述菜品的上菜时间进行预估时，可以有多种方式，例如，一种方式下，可以首先确定待制作的菜品队列信息；然后，根据队列中排在所述菜品之前的菜品数量，以及各菜品的平均制作时间信息，对该菜品的上菜时间进行预估。

在实际应用中，服务器在获知所述菜品制作完成的信息时，还可以将该信息通知给传菜员用户对应的第二客户端。

另外，接收到对所述餐厅的桌位预约请求时，还可以提供所述餐厅的桌位三维布局信息，以及各桌位在对应预约时间段内的状态信息。

接收在排队等位过程中还可以通过第一客户端提交的点餐结果信息，并根据点餐结果信息生成订单；在通过该第一客户端接收到桌位标识扫码结果后，将该桌位标识与该订单信息进行关联，并推送到所述餐厅加工制作区的第二客户端。

再者，还可以通过所述信息采集子系统，对所述用餐区具体桌位的新用户就座信息进行采集，将所述新用户就座的通知消息以及关联的桌位标识信息推送给服务员用户的第二客户端。

另外，服务器还可以在接收到第一客户端提交的点餐请求时，提供点餐推荐信息。

其中，具体在提供点餐推荐信息时，可以根据第一客户端提交的用餐场合和/或口味偏好信息，以及预先为各菜品添加的标签信息提供点餐推荐信息。

或者，还可以确定用餐人数信息；根据用餐人数对应的菜品数量以及菜品种类组合规则信息，提供点餐推荐信息。

再者，还可以根据用户的历史点餐记录信息，提供所述点餐推荐信息。

另外，服务器还可以通过所述信息采集子系统对所述用餐区中的各桌位进行图像采集；通过检测各桌位的图像采集信息，确定各桌位的状态变化信息。

其中，各桌位的初始状态为可选状态；具体在确定各桌位的状态变化信息时，如果检测到目标桌位有新用户就座，则将所述目标桌位切换为已占用状态；如果检测到目标桌位关联的图形码被扫码，则将所述目标桌位切换为点餐中状态；如果检测到所述目标桌位关联的订单被推送到加工制作区的第二客户端，则将所述目标桌位切换为用餐中状态。

另外，如果目标桌位关联的订单切换为已结账状态，且所述目标桌位在预置时间段内无人就座，则将所述目标桌位切换为待清洁状态，并通知给负责清洁的服务员用户关联的第二客户端。如果目标桌位已完成清洁工作，则将所述目标桌位切换为可选状态，并在存在等位用户的情况下，将该目标桌位的状态更新信息通知给负责排位引导的服务员用户关联的第二客户端。

服务器还可以通过所述信息采集子系统对进入所述用餐区的用户进行人脸图像信息采集；然后，通过所述人脸图像信息识别用户身份信息，以及关联的非隐私信息，并提供给相关服务员的第二客户端。

再者，服务器还可以通过餐厅等位区的显示屏输出互动信息；接收到第一客户端的互动请求时，向所述第一客户端返回互动结果。其中，所述互动结果包括所获得的与所述餐厅相关的消费权益信息。

另外，对于一些线上用户的订单，通常会要求将具体所点的菜品配送至指定的地址，此时，在本申请实施例中，可以通过送餐机器人设备来实现对菜品的配送。具体的，服务器还可以针对线上用户的订单，对所述餐厅内的送餐机器人设备进行调度，以便通过所述送餐机器人设备将所述订单关联的菜品配送至指定的地址。其中，具体实现时，还可以根据所述线上用户订单对应的送餐时间信息，地理位置之间的距离信息，以及各订单关联的菜品所需占用空间的信息，对所述线上用户的订单合并，将合并的订单分配到同一个送餐机器人设备进行配送。其中，关于各菜品所需占用的空间信息可以是预先保存在服务器中，另外，服务器中还可以包括送餐机器人设备的容积等信息，这样，在进行订单合并时，可以以具体的菜品所需占用的空间以及所述容积信息为依据进行合并，避免出现送餐机器人设备中无法容纳下各个订单中的菜品等情况出现。另外，在具体实现时，所述送餐机器人设备可以带有定位装置，这样，服务器可以将送餐机器人设备在配送途中的位置和/或途径的路线信息提供给所述线上用户的订单对应的第一客户端。

实施例三

该实施例三也是与实施例一相对应的，从第二客户端的角度，提供了一种餐饮信息提供方法，其中，所述第二客户端可以是提供给餐厅的服务员的客户端，具体的，参见图7，该方法具体可以包括：

s701：接收服务器推送的目标桌位的标识信息以及关联的用户情绪预估信息，其中，所述用户情绪预估信息是根据所述目标桌位关联的菜品相关情况信息进行确定的；

s702：根据所述目标桌位的标识信息以及关联的用户情绪预估信息提供提示信息，以用于提示对应的服务员对所述目标桌位的用户进行安抚，或加快对所述目标桌位关联菜品的制作进度。

关于上述实施例二以及实施例三中的具体实现，因此，相关的具体实现可以参见前述实施例一中的记载，这里不再赘述。

如前文所述，在具体实现时，关于本申请实施例提供的各个环节上的改进点，也可以独立存在，下面分别进行介绍。

实施例四

该实施例四是针对预约的过程，从服务器的角度提供了一种餐饮信息预约处理方法，参见图8，该方法具体可以包括：

s801：接收通过第一客户端提交的对指定餐厅进行桌位预约的请求；

s802：提供所述餐厅的桌位三维布局信息，以及各桌位在对应预约时间段内的状态信息；

s803：根据桌位选择结果以及关联的预约时间段信息生成预约订单。

具体实现时，服务器还可以接收通过所述第一客户端提交的预约点餐结果信息，并将所述预约点餐结果信息加入到所述预约订单中。之后，在通过该第一客户端接收到桌位标识扫码结果后，将该桌位标识与该订单信息进行关联，并推送到所述餐厅加工制作区的第二客户端。

实施例五

该实施例五是与实施例四相对应的，从第一客户端的角度，提供了一种餐饮信息预约处理方法，参见图9，该方法具体可以包括：

s901：提供用于进行桌位预约的第一操作选项；

s902：通过所述第一操作选项接收到桌位预约请求后，展示对应餐厅的桌位三维布局信息，以及各桌位在对应预约时间段内的状态信息；

s903：将桌位选择结果信息提交到服务器，以用于生成预约订单。

具体实现时，第一客户端还可以提供用于进行预约点餐的第二操作选项，通过所述第二操作选项接收到点餐预约请求后，提供对应餐厅的可选菜品信息，并将点餐结果信息提交到服务器，以用于添加到所述预约订单中。

通过上述实施例四、五，可以使得用户在进行提前预约桌位的过程中，能够直观的了解到餐厅的三维桌位布局信息，从而可以根据自己的需求，选择更合适的桌位进行预约，可以提升用户的体验。

实施例六

该实施例九主要从点餐过程中的信息推荐角度，提供了一种餐饮信息推荐方法，参见图10，该方法主要从服务器角度进行介绍，该方法具体可以包括：

s1001：提供餐厅关联的菜品信息数据库，所述数据库中保存有菜品关联的标签信息，所述标签信息包括各菜品所适合的用餐场合信息和/或口味信息；

s1002：接收第一客户端提交的点餐请求，所述请求中携带有用餐场合信息和/或口味偏好信息；

s1003：至少根据所述用餐场合和/或口味偏好信息，以及各菜品对应的所述标签信息，提供点餐推荐信息。

具体实现时，所述数据库中还可以保存有不同用餐人数对应的菜品数量以及菜品种类组合规则信息。此时，还可以确定所述第一客户端关联桌位的用餐人数信息，然后，具体在提供点餐推荐信息时，可以根据所述用餐人数信息，以及所述用餐场合和/或口味偏好信息，提供点餐推荐信息。

其中，具体在确定所述第一客户端关联桌位的用餐人数信息时，可以根据所述点餐请求中携带的信息确定所述用餐人数信息。或者，还可以通过餐厅用餐区部署的信息采集子系统对所述关联桌位进行信息采集，并根据采集结果确定所述用餐人数信息。

实施例七

该实施例七是与实施例六相对应的，从第一客户端的角度，提供了一种餐饮信息推荐方法，参见图11，该方法具体可以包括：

s1101：提供点餐界面，并在所述界面中提供用于选择用餐场合和/或口味偏好信息的第一操作选项；

s1102：通过所述第一操作选项接收到用餐场合和/或口味偏好信息后，提供点餐推荐信息，所述点餐推荐信息是至少根据所述用餐场合和/或口味偏好信息，以及各菜品对应的标签信息确定的。

通过实施例六、七，能够在用户点餐的过程中，为用户提供推荐的菜品或者菜品组合等，从而使得用户在需要提供点餐帮助的情况下，能够直接通过系统获得相关的推荐信息，而无需依赖于与服务员的沟通，因此，同样可以降低与服务员之间的沟通成本，降低对服务员能力及素质的依赖。

实施例八

该实施例八主要提供了一种桌位状态信息处理系统，参见图12，该系统具体可以包括：

信息采集子系统1201，部署于餐厅用餐区，用于对所述用餐区中的各桌位进行图像采集；

服务器1202，用于根据各桌位的图像采集信息，确定各桌位的状态变化信息，并提供对应的通知信息。

具体实现时，各桌位的初始状态为可选状态，此时，所述服务器具体可以用于：

如果检测到目标桌位有新用户就座，则将所述目标桌位切换为已占用状态；

如果检测到目标桌位关联的图形码被扫码，则将所述目标桌位切换为点餐中状态；

如果检测到所述目标桌位关联的订单被推送到加工制作区的第二客户端，则将所述目标桌位切换为用餐中状态。

另外，所述服务器具体可以用于：

如果目标桌位关联的订单切换为已结账状态，且所述目标桌位在预置时间段内无人就座，则将所述目标桌位切换为待清洁状态，并通知给负责清洁的服务员用户关联的第二客户端。

如果目标桌位已完成清洁工作，则将所述目标桌位切换为可选状态，并在存在等位用户的情况下，将该目标桌位的状态更新信息通知给负责排位引导的服务员用户关联的第二客户端。

具体实现时，所述信息采集子系统中可以包括摄像头，所述摄像头部署于所述餐厅顶部，拍摄角度为俯视角度。

实施例九

该实施例九是与实施例八相对应的，从服务器的角度，提供了一种桌位状态信息处理方法，参见图13，该方法具体可以包括：

s1301：通过餐厅用餐区部署的信息采集子系统对所述用餐区中的各桌位进行图像采集；

s1302：根据各桌位的图像采集信息，确定各桌位的状态变化信息；

s1303：根据所述桌位的状态变化信息，提供对应的通知信息。

具体实现时，如果检测到目标桌位有新用户就座，则可以将所述目标桌位切换为已占用状态。如果检测到目标桌位关联的图形码被扫码，则将所述目标桌位切换为点餐中状态。如果检测到所述目标桌位关联的订单被推送到加工制作区的第二客户端，则可以将所述目标桌位切换为用餐中状态。

如果目标桌位关联的订单切换为已结账状态，且所述目标桌位在预置时间段内无人就座，则可以将所述目标桌位切换为待清洁状态；具体在提供对应的通知信息时，可以将所述待清洁状态信息通知给负责清洁的服务员用户关联的第二客户端。

如果目标桌位已完成清洁工作，则将所述目标桌位切换为可选状态；具体在提供对应的通知信息时，可以在存在等位用户的情况下，将该目标桌位的状态更新信息通知给负责排位引导的服务员用户关联的第二客户端。

通过上述实施例八、九，系统能够实时发现桌位的状态变化情况，并对桌位信息进行更新，另外还可以通知给相关的客户端，这样，可以使得餐厅服务员能够更快捷的获知具体桌位的状态变化情况，而无需通过对讲机等进行通知，因此，可以降低服务员与服务员之间的沟通成本。

需要说明的是，上述实施例二至实施例九的各方案之间还可以相互进行组合，具体的实现细节可以参见前述实施例一中的记载，这里不再赘述。

与实施例二相对应，本申请实施例还提供了一种餐饮信息处理装置，参见图14，该装置具体可以包括：

信息采集结果获得单元1401，用于根据部署于餐厅用餐区的信息采集子系统，获得对所述用餐区内有用户就座的目标桌位的信息采集结果

菜品相关情况信息确定单元1402，用于根据所述信息采集结果，确定所述目标桌位对应的菜品相关情况信息

情绪预估单元1403，用于根据所述菜品相关情况信息对该目标桌位进行用户情绪预估。

具体实现时，所述菜品相关情况信息确定单元具体可以用于：

在所述目标桌位的菜品上桌之前，根据所述菜品情况采集结果，确定所述目标桌位关联的已下单时间信息；

此时，所述情绪预估单元具体可以用于：

根据所述已下单时间信息，对该目标桌位进行用户情绪预估。

或者，所述菜品相关情况信息确定单元具体可以用于：

在所述目标桌位有菜品上桌之后，根据所述菜品情况采集结果，确定所述目标桌位关联的用户对已上桌菜品的消耗速度情况，以及剩余菜量信息；

此时，所述情绪预估单元具体可以用于：

根据所述消耗速度以及所述剩余菜量信息，对该目标桌位进行用户情绪预估。

具体实现时，所述菜品相关情况信息确定单元还可以用于：

根据所述菜品情况采集结果，获得所述目标桌位各菜品的上菜时间间隔信息；

此时，所述情绪预估单元具体可以用于：

根据所述消耗速度，所述剩余菜量信息以及上菜时间间隔信息，对该目标桌位进行用户情绪预估。

另外，该装置还可以包括：

菜品制作进度信息获得单元，用于获得所述目标桌位的菜品制作进度信息；

此时，所述情绪预估单元具体可以用于：

根据所述制作进度信息以及所述菜品相关情况信息，对该目标桌位进行用户情绪预估。

具体实现时，所述装置还可以包括：

情绪预估信息提供单元，用于如果所述用户情绪预估结果达到预置的阈值，则将该目标桌位的标识信息以及关联的用户情绪预估信息提供给相关职责的服务员用户对应的第二客户端。

加速通知单元，用于如果所述用户情绪预估结果达到预置的阈值，则通知所述加工制作区对应的第二客户端加快对该桌位关联菜品的制作进度。

另外，该装置还可以包括：

进度信息提供单元，用于确定所述目标桌位关联菜品的制作进度信息，并将所述菜品的制作进度信息推送到所述目标桌位关联订单对应的第一客户端。

其中，当所述菜品处于制作中状态时，所述装置还包括：

上菜时间预估单元，用于对所述目标桌位关联未上桌菜品的上菜时间进行预估，并推送到所述目标桌位关联订单对应的第一客户端。

具体的，所述上菜时间预估单元具体可以包括：

队列确定子单元，用于确定待制作的菜品队列信息；

预估子单元，用于根据队列中排在所述菜品之前的菜品数量，以及各菜品的平均制作时间信息，对该菜品的上菜时间进行预估。

另外，该装置还可以包括：

制作完成信息通知单元，用于获知所述菜品制作完成的信息时，将该信息通知给传菜员用户对应的第二客户端。

三维布局信息提供单元，用于接收到对所述餐厅的桌位预约请求时，提供所述餐厅的桌位三维布局信息，以及各桌位在对应预约时间段内的状态信息。

点餐结果接收单元，用于接收在排队等位过程中通过第一客户端提交的点餐结果信息，并根据点餐结果信息生成订单；

信息关联单元，用于在通过该第一客户端接收到桌位标识扫码结果后，将该桌位标识与该订单信息进行关联，并推送到所述餐厅加工制作区的第二客户端。

再者，该装置还可以包括：

新用户就座信息采集单元，用于通过所述信息采集子系统，对所述用餐区具体桌位的新用户就座信息进行采集；

新用户就座信息通知单元，用于将所述新用户就座的通知消息以及关联的桌位标识信息推送给服务员用户的第二客户端。

点餐推荐单元，用于接收到第一客户端提交的点餐请求时，提供点餐推荐信息。

具体的，所述点餐推荐单元可以用于：

根据第一客户端提交的用餐场合和/或口味偏好信息，以及预先为各菜品添加的标签信息提供点餐推荐信息。

或者，所述点餐推荐单元可以用于：

确定用餐人数信息；

根据用餐人数对应的菜品数量以及菜品种类组合规则信息，提供点餐推荐信息。

另外，所述点餐推荐单元还可以用于：

根据用户的历史点餐记录信息，提供所述点餐推荐信息。

该装置还可以包括：

桌位图像采集单元，用于通过所述信息采集子系统对所述用餐区中的各桌位进行图像采集；

桌位状态变化信息确定单元，用于根据各桌位的图像采集信息，确定各桌位的状态变化信息，并提供对应的通知信息。

其中，各桌位的初始状态为可选状态；

所述桌位状态变化信息确定单元具体可以用于：

如果检测到目标桌位有新用户就座，则将所述目标桌位切换为已占用状态；

如果检测到目标桌位关联的图形码被扫码，则将所述目标桌位切换为点餐中状态；

如果检测到所述目标桌位关联的订单被推送到加工制作区的第二客户端，则将所述目标桌位切换为用餐中状态。

另外，所述桌位状态变化信息确定单元也可以用于：

如果目标桌位关联的订单切换为已结账状态，且所述目标桌位在预置时间段内无人就座，则将所述目标桌位切换为待清洁状态，并通知给负责清洁的服务员用户关联的第二客户端。

或者，如果目标桌位已完成清洁工作，则将所述目标桌位切换为可选状态，并在存在等位用户的情况下，将该目标桌位的状态更新信息通知给负责排位引导的服务员用户关联的第二客户端。

另外，该装置还可以包括：

人脸图像采集单元，用于通过所述信息采集子系统对进入所述用餐区的用户进行人脸图像信息采集；

身份信息提供单元，用于通过所述人脸图像信息识别用户身份信息，以及关联的非隐私信息，并提供给相关服务员的第二客户端。

互动信息输出单元，用于通过餐厅等位区的显示屏输出互动信息；

互动结果提供单元，用于接收到第一客户端的互动请求时，向所述第一客户端返回互动结果。

其中，所述互动结果包括所获得的与所述餐厅相关的消费权益信息。

调度单元，用于针对线上用户的订单，对所述餐厅内的送餐机器人设备进行调度，以便通过所述送餐机器人设备将所述订单关联的菜品配送至指定的地址。

具体的，所述调度单元可以用于：

根据所述线上用户订单对应的送餐时间信息，地理位置之间的距离信息，以及各订单关联的菜品所需占用空间的信息，对所述线上用户的订单合并；

将合并的订单分配到同一个送餐机器人设备进行配送。

另外，还可以包括：

配送信息提供单元，用于将送餐机器人设备在配送途中的位置和/或途径的路线信息提供给所述线上用户的订单对应的第一客户端。

与实施例三相对应，本申请实施例还提供了一种餐饮信息提供装置，参见图15，该装置可以包括：

情绪预估信息接收单元1501，用于接收服务器推送的目标桌位的标识信息以及关联的用户情绪预估信息，其中，所述用户情绪预估信息是根据所述目标桌位关联菜品的制作进度信息以及菜品消耗情况进行确定的；

提示信息提供单元1502，用于根据所述目标桌位的标识信息以及关联的用户情绪预估信息提供提示信息，以用于提示对应的服务员对所述目标桌位的用户进行安抚，或加快对所述目标桌位关联菜品的制作进度。

与实施例四相对应，本申请实施例还提供了一种餐饮信息预约处理装置，参见图16，该装置可以包括：

预约请求接收单元1601，用于接收通过第一客户端提交的对指定餐厅进行桌位预约的请求；

三维布局信息提供单元1602，用于提供所述餐厅的桌位三维布局信息，以及各桌位在对应预约时间段内的状态信息；

预约订单生成单元1603，用于根据桌位选择结果以及关联的预约时间段信息生成预约订单。

具体实现时，该装置还可以包括：

预约点餐信息接收单元，用于接收通过所述第一客户端提交的预约点餐结果信息；

信息添加单元，用于将所述预约点餐结果信息加入到所述预约订单中；

信息关联单元，用于在通过该第一客户端接收到桌位标识扫码结果后，将该桌位标识与该订单信息进行关联，并推送到所述餐厅加工制作区的第二客户端。

与实施例五相对应，本申请实施例还提供了一种餐饮信息预约处理装置，参见图17，包括：

第一操作选项提供单元1701，用于提供用于进行桌位预约的第一操作选项；

桌位信息展示单元1702，用于通过所述第一操作选项接收到桌位预约请求后，展示对应餐厅的桌位三维布局信息，以及各桌位在对应预约时间段内的状态信息；

信息提交单元1703，用于将桌位选择结果信息提交到服务器，以用于生成预约订单。

具体实现时，该装置还可以包括：

第二操作选项提供单元，用于提供用于进行预约点餐的第二操作选项；

菜品信息提供单元，用于通过所述第二操作选项接收到点餐预约请求后，提供对应餐厅的可选菜品信息；

点餐结果信息提交单元，用于将点餐结果信息提交到服务器，以用于添加到所述预约订单中。

与实施例六相对应，本申请实施例还提供了一种餐饮信息推荐装置，参见图18，该装置可以包括：

菜品信息数据库提供单元1801，用于提供餐厅关联的菜品信息数据库，所述数据库中保存有菜品关联的标签信息，所述标签信息包括各菜品所适合的用餐场合信息和/或口味信息；

点餐请求接收单元1802，用于接收第一客户端提交的点餐请求，所述请求中携带有用餐场合信息和/或口味偏好信息；

点餐推荐信息提供单元1803，用于至少根据所述用餐场合和/或口味偏好信息，以及各菜品对应的所述标签信息，提供点餐推荐信息。

其中，所述数据库中还保存有不同用餐人数对应的菜品数量以及菜品种类组合规则信息；

所述装置还可以包括：

用餐人员确定单元，用于确定所述第一客户端关联桌位的用餐人数信息；

所述点餐推荐信息提供单元具体可以用于：

根据所述用餐人数信息，以及所述用餐场合和/或口味偏好信息，提供点餐推荐信息。

其中，所述用餐人员确定单元具体可以用于：

根据所述点餐请求中携带的信息确定所述用餐人数信息。

或者，所述用餐人员确定单元也可以用于：

通过餐厅用餐区部署的信息采集子系统对所述关联桌位进行信息采集，并根据采集结果确定所述用餐人数信息。

与实施例七相对应，本申请实施例还提供了一种餐饮信息推荐装置，参见图19，该装置具体可以包括：

点餐界面提供单元1901，用于提供点餐界面，并在所述界面中提供用于选择用餐场合和/或口味偏好信息的第一操作选项；

点餐信息提供单元1902，用于通过所述第一操作选项接收到用餐场合和/或口味偏好信息后，提供点餐推荐信息，所述点餐推荐信息是至少根据所述用餐场合和/或口味偏好信息，以及各菜品对应的标签信息确定的。

与实施例八相对应，本申请实施例还提供了一种桌位状态信息处理装置，参见图20，该装置可以包括：

桌位图像采集单元2001，用于通过餐厅用餐区部署的信息采集子系统对所述用餐区中的各桌位进行图像采集；

桌位状态变化信息确定单元2002，用于根据各桌位的图像采集信息，确定各桌位的状态变化信息；

通知单元2003，用于根据所述桌位的状态变化信息，提供对应的通知信息。

具体的，所述桌位状态变化信息确定单元具体可以用于：

如果检测到目标桌位有新用户就座，则将所述目标桌位切换为已占用状态。

或者，如果检测到目标桌位关联的图形码被扫码，则将所述目标桌位切换为点餐中状态。

或者，如果检测到所述目标桌位关联的订单被推送到加工制作区的第二客户端，则将所述目标桌位切换为用餐中状态。

或者，如果目标桌位关联的订单切换为已结账状态，且所述目标桌位在预置时间段内无人就座，则将所述目标桌位切换为待清洁状态；

具体的，所述通知单元具体可以用于：

将所述待清洁状态信息通知给负责清洁的服务员用户关联的第二客户端。

另外，所述桌位状态变化信息确定单元具体可以用于：

如果目标桌位已完成清洁工作，则将所述目标桌位切换为可选状态；

所述通知单元具体可以用于：

在存在等位用户的情况下，将该目标桌位的状态更新信息通知给负责排位引导的服务员用户关联的第二客户端

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收服务器推送的目标桌位的标识信息以及关联的用户情绪预估信息，其中，所述用户情绪预估信息是根据所述目标桌位关联的菜品相关情况信息进行确定的；

根据所述目标桌位的标识信息以及关联的用户情绪预估信息提供提示信息，以用于提示对应的服务员对所述目标桌位的用户进行安抚，或加快对所述目标桌位关联菜品的制作进度。

另外还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

通过餐厅用餐区部署的信息采集子系统对所述用餐区中的各桌位进行图像采集；

根据各桌位的图像采集信息，确定各桌位的状态变化信息；

根据所述桌位的状态变化信息，提供对应的通知信息。

其中，图21示例性的展示出了电子设备的架构，例如，设备2100可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。

参照图21，设备2100可以包括以下一个或多个组件：处理组件2102，存储器2104，电源组件2106，多媒体组件2108，音频组件2110，输入/输出(i/o)的接口2112，传感器组件2114，以及通信组件2116。

处理组件2102通常控制设备2100的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件2102可以包括一个或多个处理器2120来执行指令，以完成本公开技术方案提供的视频播放方法中的当满足预设条件时，生成流量压缩请求，并发送给服务器，其中所述流量压缩请求中记录有用于触发服务器获取目标关注区域的信息，所述流量压缩请求用于请求服务器优先保证目标关注区域内视频内容的码率；根据服务器返回的码流文件播放所述码流文件对应的视频内容，其中所述码流文件为服务器根据所述流量压缩请求对所述目标关注区域之外的视频内容进行码率压缩处理得到的视频文件的全部或部分步骤。此外，处理组件2102可以包括一个或多个模块，便于处理组件2102和其他组件之间的交互。例如，处理部件2102可以包括多媒体模块，以方便多媒体组件2108和处理组件2102之间的交互。

存储器2104被配置为存储各种类型的数据以支持在设备2100的操作。这些数据的示例包括用于在设备2100上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器2104可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。

电源组件2106为设备2100的各种组件提供电力。电源组件2106可以包括电源管理系统，一个或多个电源，及其他与为设备2100生成、管理和分配电力相关联的组件。

多媒体组件2108包括在设备2100和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件2108包括一个前置摄像头和/或后置摄像头。当设备2100处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件2110被配置为输出和/或输入音频信号。例如，音频组件2110包括一个麦克风(mic)，当设备2100处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器2104或经由通信组件2116发送。在一些实施例中，音频组件2110还包括一个扬声器，用于输出音频信号。

i/o接口2112为处理组件2102和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件2114包括一个或多个传感器，用于为设备2100提供各个方面的状态评估。例如，传感器组件2114可以检测到设备2100的打开/关闭状态，组件的相对定位，例如所述组件为设备2100的显示器和小键盘，传感器组件2114还可以检测设备2100或设备2100一个组件的位置改变，用户与设备2100接触的存在或不存在，设备2100方位或加速/减速和设备2100的温度变化。传感器组件2114可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件2114还可以包括光传感器，如cmos或ccd图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件2114还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件2116被配置为便于设备2100和其他设备之间有线或无线方式的通信。设备2100可以接入基于通信标准的无线网络，如wifi，2g或3g，或它们的组合。在一个示例性实施例中，通信部件2116经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信部件2116还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。

在示例性实施例中，设备2100可以被一个或多个应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器2104，上述指令可由设备2100的处理器2120执行以完成本公开技术方案提供的视频播放方法中的当满足预设条件时，生成流量压缩请求，并发送给服务器，其中所述流量压缩请求中记录有用于触发服务器获取目标关注区域的信息，所述流量压缩请求用于请求服务器优先保证目标关注区域内视频内容的码率；根据服务器返回的码流文件播放所述码流文件对应的视频内容，其中所述码流文件为服务器根据所述流量压缩请求对所述目标关注区域之外的视频内容进行码率压缩处理得到的视频文件。例如，所述非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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