CN113378042A - 基于空调的点餐方法、装置和智能空调 - Google Patents

Abstract

本申请涉及智能电器技术领域，公开一种基于空调的点餐方法。该技术空调的点餐方法包括：获得空调的设定温度以及与用户关联的地域属性；在总菜单中确定与设定温度以及地域属性相对应的预选菜单；展示预选菜单；响应于用户交互操作，在预选菜单中确定与用户交互操作相对应的选定餐品。采用该基于空调的点餐方法确定的预选菜单更具有针对性，使用户容易点到需求的餐品。本申请还公开一种基于空调的点餐装置和智能空调。

Description

基于空调的点餐方法、装置和智能空调

技术领域

本申请涉及智能电器技术领域，例如涉及一种基于空调的点餐方法、装置和智能空调。

背景技术

目前，空调基本属于酒店客房的必备电器，大多数的空调仅具备基本的制冷或制热模式，例如，空调可通过遥控器等接收入住客房的用户设置的设定温度，之后计算设定温度与实际室内温度的差值，通过运行制冷模式或制热模式，将实际室内温度调节至设定温度。

在酒店客房中，点餐场景属于一个常见的场景，入住客房的用户可通过联系服务人员实现点餐，或者，通过手机软件(Application，APP)实现点餐。如果入住客房的用户通过联系服务人员点餐，则需要大量的酒店服务人员，便于为多个客房的用户提供点餐服务；如果用户通过手机APP点餐，则用户需要先了解酒店的点餐过程以及酒店中可提供的餐品，之后再进行选择，这提高了点餐的复杂度，不利于用户的使用体验。

在一些现有技术中，可通过空调实现点餐，例如，空调可获得用户的图像信息，并通过图像信息确定出用户的工作状态以及用户的位置信息，并根据现有的餐品、用户工作状态和位置信息的匹配关系，向点餐设备推送菜品。例如，在用户点餐时，记录用户的工作状态、位置信息与菜品的对应关系，并保存至数据库，在下一次用户点餐时，根据已经记录的工作状态、位置信息与菜品的对应关系，向点餐设备推送与下一次用户的工作状态和位置信息相对应的菜品。

这样，可将酒店中的必备电器以及酒店的常见场景相结合，减少通过服务人员点餐的程序，有利于减少酒店的人工成本；并且，可实现一定的智能化，减少了点餐的复杂度，提高了用户的使用体验。

在实现本公开实施例的过程中，发现相关技术中至少存在如下问题：

在酒店场景中，用户有可能是第一次入住该客房，或者，用户前后多次入住客房的季节不同，这种情况下，基于已经记录的历史数据向点餐设备推送餐品，推荐餐品的针对性较差，不容易使用户方便地点到需求的餐品。

发明内容

为了对披露的实施例的一些方面有基本的理解，下面给出了简单的概括。所述概括不是泛泛评述，也不是要确定关键/重要组成元素或描绘这些实施例的保护范围，而是作为后面的详细说明的序言。

本公开实施例提供了一种基于空调的点餐方法、装置和智能空调，以解决现有技术推荐餐品的针对性较差的技术问题。

在一些实施例中，基于空调的点餐方法包括：获得空调的设定温度以及与用户关联的地域属性；在总菜单中确定与所述设定温度以及所述地域属性相对应的预选菜单；展示所述预选菜单；响应于用户交互操作，在所述预选菜单中确定与所述用户交互操作相对应的选定餐品。

可选地，在总菜单中确定与所述设定温度以及所述地域属性相对应的预选菜单，包括：在所述总菜单中确定与所述地域属性相对应的第一菜系中的餐品，以及与所述地域属性不对应的第二菜系中的餐品；在预设温度区间中，确定所述设定温度所在的当前温度区间；在设定天数内，获得所述总菜单中每个餐品在所述当前温度区间内的下单次数；根据每个餐品的下单次数与餐品所属菜系对应的系数的乘积，确定所述预选菜单；其中，所述第一菜系中的餐品对应的第一系数，大于所述第二菜系中餐品对应的第二系数。

可选地，所述下单次数与餐品所属菜系对应的系数的乘积，包括：在所述总菜单中的第一餐品属于所述第一菜系的情况下，获得所述第一餐品的下单次数与所述第一系数的第一乘积；在所述总菜单中的第二餐品属于所述第二菜系的情况下，获得所述第二餐品的下单次数与所述第二系数的第二乘积。

可选地，根据每个所述下单次数与餐品所属菜系对应的系数的乘积，确定所述预选菜单，包括：在所述总菜单中确定乘积最大的多个餐品为所述预选菜单。

可选地，获得所述总菜单中每个餐品在所述当前温度区间内的下单次数，包括：在第一天数内，获得所述总菜单中每个餐品在所述当前温度区间内的第一下单次数；在第二天数内，获得所述总菜单中每个餐品在所述当前温度区间内的第二下单次数；根据所述第一下单次数和所述第二下单次数的加权平均值或加权和，确定所述下单次数；其中，所述第一天数大于所述第二天数，所述第一下单次数的权重小于所述第二下单次数的权重。

可选地，获得所述总菜单中每个餐品在所述当前温度区间内的下单次数，还包括：在第三天数内，获得所述总菜单中每个餐品在所述当前温度区间内的第三下单次数。

可选地，根据所述第一下单次数和所述第二下单次数的加权平均值或加权和，确定所述下单次数，包括：根据所述第一下单次数、所述第二下单次数和所述第三下单次数的加权平均值或加权和，确定所述下单次数；

其中，所述第三天数小于所述第二天数，所述第三下单次数的权重，大于所述第二下单次数的权重，且，所述第三下单次数的权重与所述第三下单次数正相关。

可选地，响应于用户交互操作，包括：响应于用户的手势操作，并获得与所述用户的手势操作相对应的指令，所述指令与所述选定餐品相对应；或者，响应于用户的语音交互，并获得与所述用户的语音交互相对应的指令，所述指令与所述选定餐品相对应。

在一些实施例中，基于空调的点餐装置包括：获得模块、筛选模块、展示模块和交互模块，其中，所述获得模块被配置为获得空调的设定温度以及与用户关联的地域属性；所述筛选模块被配置为在总菜单中确定与所述设定温度以及所述地域属性相对应的预选菜单；所述展示模块被配置为展示所述预选菜单；所述交互模块被配置为响应于用户交互操作，在所述预选菜单中确定与所述用户交互操作相对应的选定餐品。

在一些实施例中，基于空调的点餐装置包括处理器和存储有程序指令的存储器，所述处理器被配置为在执行所述程序指令时，执行前述实施例提供的基于空调的点餐方法。

在一些实施例中，智能空调包括前述实施例提供的基于空调的点餐装置。

本公开实施例提供的基于空调的点餐方法、装置和智能空调，可以实现以下技术效果：

通常情况下，设定温度的高低，可以用来表示用户的制冷需求或者制热需求，以及制冷需求的强弱或者制热需求的强弱，例如，通常情况下，如果设定温度高于26℃，则表示用户具有制热需求，并且，设定温度与26℃的差值越大，用户的制热需求越强；如果设定温度低于26℃，则表示用户均有制冷需求，并且，设定温度与26℃的差值越大，用户的制冷需求越强。另外，不同地域的用户习惯的口味以及所需的餐品类型往往是不同的，例如经典的八大菜系。通过设定温度与地域属性确定预选菜单，更符合用户的制热需求、制冷需求，以及口味需求，这样确定的预选菜单更具有针对性，使用户容易点到需求的餐品。

以上的总体描述和下文中的描述仅是示例性和解释性的，不用于限制本申请。

附图说明

一个或一个以上实施例通过与之对应的附图进行示例性说明，这些示例性说明和附图并不构成对实施例的限定，附图中具有相同参考数字标号的元件视为类似的元件，并且其中：

图1是本公开实施例提供的基于空调的点餐方法的实施环境的示意图；

图2是公开实施例提供的一种基于空调的点餐方法的示意图；

图3是本公开实施例提供的一种基于空调的点餐装置的示意图；

图4是本公开实施例提供的一种基于空调的点餐装置的示意图。

具体实施方式

为了能够更加详尽地了解本公开实施例的特点与技术内容，下面结合附图对本公开实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本公开实施例。在以下的技术描述中，为方便解释起见，通过多个细节以提供对所披露实施例的充分理解。然而，在没有这些细节的情况下，一个或一个以上实施例仍然可以实施。在其它情况下，为简化附图，熟知的结构和装置可以简化展示。

本公开实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开实施例的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。

除非另有说明，术语“多个”表示两个或两个以上。

本公开实施例中，字符“/”表示前后对象是一种“或”的关系。例如，A/B表示：A或B。

术语“和/或”是一种描述对象的关联关系，表示可以存在三种关系。例如，A和/或B，表示：A或B，或，A和B这三种关系。

图1是本公开实施例提供的基于空调的点餐方法的实施环境的示意图。该实施环境中可包括多个房间11(客房)，每个房间11彼此独立，即，房间11与房间11之间隔热，一个房间11的室内温度不会影响到其他房间11内的室内温度，每个房间11的设置有智能空调12，并且智能空调12具备点餐功能。

每个智能空调12独立编号，其编号用于表示该智能空调12所在的房间11，以便于在点餐后，准确送餐。

该智能空调12通过与用户交互的方式实现点餐，其交互方式可以是语音交互，或者，手势交互，或者，通过操作面板的交互。

图2是公开实施例提供的一种基于空调的点餐方法的示意图。该基于空调的点餐方法可在图1中所示的智能空调中执行，也可在智能空调的控制终端执行，例如遥控器或者设置在房间墙壁上的操作面板，也可在服务器中执行，例如酒店内设置的云平台。

结合图2所示，基于空调的点餐方法包括：

S201、获得空调的设定温度以及与用户关联的地域属性。

在用户通过遥控器或设置在房间墙壁上的操作面板设置了设定温度后，存储该设定温度，在需要获得空调的设定温度时，即可在已存储的数据中读取该设定温度。

可通过语音交互，识别用户口音，进而获得与用户关联的地域属性；或者，通过语音播报或者显示界面显示相关地域选项，响应于用户的语音指令，或者，手势指令，或者操作指令，在上述相关地域选项中确定与用户关联的地域属性。即，用户手动选择地域属性。

S202、在总菜单中确定与设定温度以及地域属性相对应的预选菜单。

通常情况下，设定温度的高低，可以用来表示用户的制冷需求或者制热需求，以及制冷需求的强弱或者制热需求的强弱，例如，通常情况下，如果设定温度高于26℃，则表示用户具有制热需求，并且，设定温度与26℃的差值越大，用户的制热需求越强；如果设定温度低于26℃，则表示用户均有制冷需求，并且，设定温度与26℃的差值越大，用户的制冷需求越强。

例如，在用户具有制热需求的情况下，可以向预选菜单中添加热饮、热汤类、火锅等温度保持时间较长的餐品，在用户具有制冷需求的情况下，可以向预选菜单中添加冷饮、烧烤、凉菜等清爽系列菜品。

在设定温度高于26℃的情况下，可以将大于26℃的温度区间划分为三个温度区间：第一温度区间、第二温度区间和第三温度区间，其中，第一温度区间的上限值小于第二温度区间的下限值，第二温度区间的上限值小于第三温度区间的下限值。如果设定温度在第一温度区间内，则可将热饮添加入预选菜单中；如果设定温度在第二温度区间内，则可将热汤类餐品添加入预选菜单中；如果设定温度在第三温度区间内，则将火锅添加入预选菜单中。热饮类餐品的温度保持时间短于热汤类餐品的温度保持时间，热汤类餐品的温度保持时间短于火锅的温度保持时间。

上述列举的预选菜单中的餐品，仅为示例性说明设定温度与餐品的对应关系，本领域技术人员还可依据实际情况(当地饮食习惯)确定其他的符合当前饮食习惯的设定温度与餐品的对应关系。

可在数据库中预存设定温度、地域属性以及预选菜单的对应关系，在获得设定温度和地域属性后，即可在数据库获得与设定温度以及地域属性相对应的预选菜单。

或者，在总菜单中确定与设定温度以及地域属性相对应的预选菜单，可包括：在总菜单中确定与地域属性相对应的第一菜系中的餐品，以及与地域属性不对应的第二菜系中的餐品；在预设温度区间中，确定设定温度所在的当前温度区间；在设定天数内，获得总菜单中每个餐品在当前温度区间内的下单次数；根据每个餐品的下单次数与餐品所属菜系对应的系数的乘积，确定预选菜单；其中，第一菜系中的餐品对应的第一系数，大于第二菜系中餐品对应的第二系数。

可在数据库中预存地域属性及其对应的菜系中的餐品，在获得地域属性后，即可在数据库获得与地域属性相关联的菜系中的餐品。这里以经典的八大菜系中部分菜系为例为例，示例性说明地域与菜系的关系，例如，在地域属性为山东的情况下，该地域属性对应的菜系为鲁菜，鲁菜中可包括：锅贴、水饺、碳素煎饼等；在地域属性为四川的情况下，该地域属性对应的菜系为川菜，川菜中可包括宫保鸡丁、回锅肉、鱼香肉丝等。这里仅以八大菜系中部分内容做示例性说明，本领域技术人员在实施该方法时，可依据当地的饮食习惯，适应性的确定菜系与地域的对应关系，这里不再一一赘述。

上述预设温度区间内包括多个温度区间，例如，预设温度区间内可包括[14℃，16℃)、[16℃，18℃)、[18℃，20℃)、[20℃，22℃)、[22℃，24℃)、[24℃，26℃)、[26℃，28℃)、[28℃，30℃]；或者，每1℃的温度跨度为一个温度区间等。本实施例中的预设温度区间仅为示例性说明温度区间的含义，不对预设温度区间构成具体限定，本领域技术人员可根据实际情况，确定合适的预设温度区间。

例如，设定温度为23℃，则该设定温度23℃所在的当前温度区间为[22℃，24℃)。

上述设定天数可以是一周、半个月、一个月、一个季度或更多天数。

例如设定温度为23℃，则在过去设定天数内，获得每个餐品在当前温度范围内[22℃，24℃)的下单次数。

在一些具体应用场景中，设定时长为一周，设定温度为23℃，第一天在当前温度范围内[22℃，24℃)，特定餐品的下单数量为15单；第二天在同样温度范围内，特定餐品的下单次数为10单；第三天在同样温度范围内，特定餐品的下单次数为11单；第四天在同样温度范围内，特定餐品的下单次数为16单；第五天在同样温度范围内，特定餐品的下单次数为17单；第六天在同样温度范围内，特定餐品的下单次数为18单；第七天在同样温度范围内，特定餐品的下单次数为20单；则设定时长内，该特定餐品在当前温度区间内且当前时间段内的下单次数为：15+10+11+16+17+18+20＝107单。本实施例仅为示例性说明前述步骤，不对前述步骤构成限定，本领域技术人员可根据实际情况，选择合适的设定时长，进而确定下单次数。

前述第一菜系是与地域属性对应的菜系，例如鲁菜与山东对应，川菜与四川对应，上述第二菜系是与地域属性不对应的菜系，例如鲁菜与四川不对应，川菜与山东不对应。

这样，这样在预选菜单中，不仅仅包括与地域属性对应的餐品，还包括与地域属性不对应的餐品，并且，由于第一系数大于第二系数，导致可以选入预选菜单中的与地域属性不对应的餐品的下单次数，必然是比较大，也即，这样选入的预选菜单中的与地域属性不对应的餐品，是受用户欢迎程度较高的。这样一来，不仅可照顾用户的地域口味需求，还可以避免漏掉比较受欢迎的其他菜系的餐品。

上述第一系数和第二系数可以这样设置，先将第二系数设置为1，第一系数设置为1.5以上。通常情况下，上述第一系数和第二系数均为小于1的数值，例如，还可以先将第一系数设置为1，第二系数设置为0.5以下。当然，这里的第一系数和第二系数的设置方式，仅是示例性说明，不对第一系数和第二系数的具体数值构成限定，本领域技术人员可根据实际情况或领域内的取值习惯，确定第一系数和第二系数的具体数值。

可选地，下单次数与餐品所属菜系对应的系数的乘积，包括：在总菜单中的第一餐品属于第一菜系的情况下，获得第一餐品的下单次数与第一系数的第一乘积；在总菜单中的第二餐品属于第二菜系的情况下，获得第二餐品的下单次数与第二系数的第二乘积。

可选地，根据每个餐品的下单次数与餐品所属菜系对应的系数的乘积，确定预选菜单，包括：在总菜单中确定乘积最大的多个餐品为预选菜单。

采用上述技术方案之后，即可在设定天数内，获得总菜单中获得每个餐品对应的下单次数及其系数的乘积，之后将总菜单中的多个餐品，按照乘积由大到小的顺序排序，取乘积最大的两个、三个、四个、五个或更多个餐品作为预选菜单。

采用上述技术方案确定的预选菜单，不仅照顾了用户地域化的口味，还可兼顾特别受欢迎的其他菜系的餐品，使用户不容易遗漏美食，提高了用户的使用体验。

可选地，获得总菜单中每个餐品在当前温度区间内的下单次数，包括：在第一天数内，获得总菜单中每个餐品在当前温度区间内的第一下单次数；在第二天数内，获得总菜单中每个餐品在当前温度区间内的第二下单次数；根据第一下单次数和第二下单次数的加权平均值或加权和，确定下单次数；其中，第一天数大于第二天数，第一下单次数的权重小于第二下单次数的权重。

这里的第一天数，可以是一个月、一个季度、半年或更长时间，第一下单次数用于表示总菜单中每个餐品总的受欢迎程度；这里的第二天数可以是两周、三周或一个月，第二下单次数用于表示总菜单中每个餐品的季节性的受欢迎程度，例如不同蔬菜或水果在不同时间成熟，在一种蔬菜或水果成熟的季节，该一种蔬菜或水果比较受欢迎。

可以将第一下单次数和第二下单次数的加权平均值或加权和，确定为每个餐品的下单次数。

在上述技术方案中，使第一下单次数的权重小于第二下单次数的权重，便于推荐符合时令的菜品。

在确定上述权重的过程中，可以将第二下单次数的权重确定为1，再确定一小于1的数值，例如0.5或0.6，为第一下单次数的权重。或者，在上述步骤之后，将第一下单次数的权重和第二下单次数的权重做归一化处理，这样便于计算第一下单次数和第二下单次数的加权平均值。

可选地，获得总菜单中每个餐品在当前温度区间内的下单次数，还包括：在第三天数内，获得总菜单中每个餐品在当前温度区间内的第三下单次数；

根据第一下单次数和第二下单次数的加权平均值或加权和，确定下单次数，包括：根据第一下单次数、第二下单次数和第三下单次数的加权平均值或加权和，确定下单次数；

其中，第三天数小于第二天数，第三下单次数的权重，大于第二下单次数的权重，且，第三下单次数的权重与第三下单次数正相关。

这里的第三天数可以是两天、三天、四天或五天。在现有技术中，网络可以在最大程度上提高某款餐品的知名度，即“网红”食品。通过设置第三天数，并且使第三天数对应对第三下单次数的权重最大，便于向用户推荐网红食品。网红食品具有时效性短的特点，使第三下单次数的权重与第三下单次数正相关，可在最短的时间内使网红食品的排序上升，便于向用户推荐网红食品。另外，第三天数最小(第三天数小于第二天数，第三天数小于第二天数)，如果一款食品不是网红食品，其短期内的下单量不会激增，按照前述方式的第三下单次数的权重，对第一下单次数、第二下单次数和第三下单次数的加权平均值或加权和的影响也较小。

可将第二下单次数的权重设置为1，在此基础上，再确定第一下单次数的权重，和第三下单次数的权重，这样即可计算第一下单次数、第二下单系数和第三下单次数的加权平均值或加权和。或者，在上述确定的权重的基础上，再将第一下单次数的权重、第二下单次数的权重和第三下单次数的权重做归一化处理，这样便于计算第一下单次数、第二下单次数和第三下单次数的加权平均值。

可以将第一下单次数、第二下单次数和第三下单次数的加权平均值或加权和，确定为每个餐品的下单次数。

S203、展示预选菜单。

可通过展示画面的形式，展示该预选菜单，例如展示该预选菜单中的每个餐品的名称和图片；或者，可通过语音播报的形式展示该预选菜单，例如依次播报该预选菜单中的餐品。

S204、响应于用户交互操作，在预选菜单中确定与用户交互操作相对应的选定餐品。

在用户通过手势点餐时，响应于用户交互操作，可包括：响应于用户的手势操作，并获得与用户的手势操作相对应的指令，该指令与选定餐品相对应，即，该指令用于在预选菜单中确定出选定餐品。

或者，在用户通过语音交互的当时进行点餐时，响应于用户交互操作，可包括：响应于用户的语音交互，并获得与用户的语音交互相对应的指令，该指令与选定餐品相对应，即，该指令用于在预选菜单中确定出选定餐品。

在确定出选定餐品后，可再将选定餐品发送至酒店的后厨，后厨人员接收到该选定餐品后，开始制作该选定餐品。在制作好之后，在根据该选定餐品对应的空调的编号，确定出与编号相对应的房间，并由服务人员将该餐品送至用户所在的房间。

通常情况下，设定温度的高低，可以用来表示用户的制冷需求或者制热需求，以及制冷需求的强弱或者制热需求的强弱，例如，通常情况下，如果设定温度高于26℃，则表示用户具有制热需求，并且，设定温度与26℃的差值越大，用户的制热需求越强；如果设定温度低于26℃，则表示用户均有制冷需求，并且，设定温度与26℃的差值越大，用户的制冷需求越强。另外，不同地域的用户习惯的口味以及所需的餐品类型往往是不同的，例如经典的八大菜系。通过设定温度与地域属性确定预选菜单，更符合用户的制热需求、制冷需求，以及口味需求，这样确定的预选菜单更具有针对性，使用户容易点到需求的餐品。

另外，在一些应用场景中，基于空调的点餐方法还包括：在与空调关联的显示装置中展示选定餐品的制作现场。

这样可以使用户实时观察餐品的制作过程，便于用户了解餐品的完成度，以及，使用户了解到该餐品是安全的(餐品原材料以及制作流程符合卫生要求)，使用户可更放心地用餐。

图3是本公开实施例提供的一种基于空调的点餐装置的示意图。该点餐装置可以是以软件、硬件或者软硬结合的形式实现的。结合图3所示，基于空调的点餐装置包括：获得模块31、筛选模块32、展示模块33和交互模块34，其中，获得模块31被配置为获得空调的设定温度以及与用户关联的地域属性；筛选模块32被配置为在总菜单中确定与设定温度以及地域属性相对应的预选菜单；展示模块33被配置为展示预选菜单；交互模块34被配置为响应于用户交互操作，在预选菜单中确定与用户交互操作相对应的选定餐品。

本公开实施例中的基于空调的点餐装置与前述实施例中的基于空调的点餐方法一一对应，前述实施例中对点餐方法中名词、步骤的限定、解释，通用适于对该基于空调的点餐装置中的名词、步骤的限定、解释，本领域技术人员参照前述实施例中相关内容即可，这里不再一一赘述。

通常情况下，设定温度的高低，可以用来表示用户的制冷需求或者制热需求，以及制冷需求的强弱或者制热需求的强弱，例如，通常情况下，如果设定温度高于26℃，则表示用户具有制热需求，并且，设定温度与26℃的差值越大，用户的制热需求越强；如果设定温度低于26℃，则表示用户均有制冷需求，并且，设定温度与26℃的差值越大，用户的制冷需求越强。另外，不同地域的用户习惯的口味以及所需的餐品类型往往是不同的，例如经典的八大菜系。通过设定温度与地域属性确定预选菜单，更符合用户的制热需求、制冷需求，以及口味需求，这样确定的预选菜单更具有针对性，使用户容易点到需求的餐品。

在一些实施例中，基于空调的点餐装置包括处理器和存储有程序指令的存储器，处理器被配置为在执行程序指令时，执行前述实施例提供的基于空调的点餐方法。

图4是本公开实施例提供的一种基于空调的点餐装置的示意图。结合图4所示，基于空调的点餐装置包括：

处理器(processor)41和存储器(memory)42，还可以包括通信接口(Communication Interface)43和总线44。其中，处理器41、通信接口43、存储器42可以通过总线44完成相互间的通信。通信接口43可以用于信息传输。处理器41可以调用存储器42中的逻辑指令，以执行前述实施例提供的基于空调的点餐方法。

此外，上述的存储器42中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

存储器42作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序，如本公开实施例中的方法对应的程序指令/模块。处理器41通过运行存储在存储器42中的软件程序、指令以及模块，从而执行功能应用以及数据处理，即实现上述方法实施例中的方法。

存储器42可包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序；存储数据区可存储根据终端设备的使用所创建的数据等。此外，存储器42可以包括高速随机存取存储器，还可以包括非易失性存储器。

本公开实施例提供了一种智能空调，包含前述实施例提供的基于空调的点餐装置。

本公开实施例提供了一种计算机可读存储介质，存储有计算机可执行指令，计算机可执行指令设置为执行前述实施例提供的基于空调的点餐方法。

本公开实施例提供了一种计算机程序产品，计算机程序产品包括存储在计算机可读存储介质上的计算机程序，计算机程序包括程序指令，当程序指令被计算机执行时，使计算机执行前述实施例提供的基于空调的点餐方法。

上述的计算机可读存储介质可以是暂态计算机可读存储介质，也可以是非暂态计算机可读存储介质。

本公开实施例的技术方案可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括一个或一个以上指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开实施例中方法的全部或部分步骤。而前述的存储介质可以是非暂态存储介质，包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机读取存储器(Random Access Memory，RAM)、磁碟或者光盘等多种可以存储程序代码的介质，也可以是暂态存储介质。

以上描述和附图充分地示出了本公开的实施例，以使本领域的技术人员能够实践它们。其他实施例可以包括结构的、逻辑的、电气的、过程的以及其他的改变。实施例仅代表可能的变化。除非明确要求，否则单独的部件和功能是可选的，并且操作的顺序可以变化。一些实施例的部分和特征可以被包括在或替换其他实施例的部分和特征。而且，本申请中使用的用词仅用于描述实施例并且不用于限制权利要求。如在实施例以及权利要求的描述中使用的，除非上下文清楚地表明，否则单数形式的“一个”(a)、“一个”(an)和“所述”(the)旨在同样包括复数形式。另外，当用于本申请中时，术语“包括”(comprise)及其变型“包括”(comprises)和/或包括(comprising)等指陈述的特征、整体、步骤、操作、元素，和/或组件的存在，但不排除一个或一个以上其它特征、整体、步骤、操作、元素、组件和/或这些的分组的存在或添加。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法或者设备中还存在另外的相同要素。本文中，每个实施例重点说明的可以是与其他实施例的不同之处，各个实施例之间相同相似部分可以互相参见。对于实施例公开的方法、产品等而言，如果其与实施例公开的方法部分相对应，那么相关之处可以参见方法部分的描述。

本领域技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，可以取决于技术方案的特定应用和设计约束条件。技术人员可以对每个特定的应用来使用不同方法以实现所描述的功能，但是这种实现不应认为超出本公开实施例的范围。技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本文所披露的实施例中，所揭露的方法、产品(包括但不限于装置、设备等)，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，可以仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例。另外，在本公开实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

Claims (10)

1.一种基于空调的点餐方法，其特征在于，包括：

获得空调的设定温度以及与用户关联的地域属性；

在总菜单中确定与所述设定温度以及所述地域属性相对应的预选菜单；

展示所述预选菜单；

响应于用户交互操作，在所述预选菜单中确定与所述用户交互操作相对应的选定餐品。

2.根据权利要求1所述的方法，其特征在于，在总菜单中确定与所述设定温度以及所述地域属性相对应的预选菜单，包括：

在所述总菜单中确定与所述地域属性相对应的第一菜系中的餐品，以及与所述地域属性不对应的第二菜系中的餐品；

在预设温度区间中，确定所述设定温度所在的当前温度区间；

在设定天数内，获得所述总菜单中每个餐品在所述当前温度区间内的下单次数；

根据每个餐品的下单次数与餐品所属菜系对应的系数的乘积，确定所述预选菜单；

其中，所述第一菜系中的餐品对应的第一系数，大于所述第二菜系中餐品对应的第二系数。

3.根据权利要求2所述的方法，其特征在于，所述下单次数与餐品所属菜系对应的系数的乘积，包括：

在所述总菜单中的第一餐品属于所述第一菜系的情况下，获得所述第一餐品的下单次数与所述第一系数的第一乘积；

在所述总菜单中的第二餐品属于所述第二菜系的情况下，获得所述第二餐品的下单次数与所述第二系数的第二乘积。

4.根据权利要求2所述的方法，其特征在于，根据每个所述下单次数与餐品所属菜系对应的系数的乘积，确定所述预选菜单，包括：

在所述总菜单中确定乘积最大的多个餐品为所述预选菜单。

5.根据权利要求2所述的方法，其特征在于，获得所述总菜单中每个餐品在所述当前温度区间内的下单次数，包括：

在第一天数内，获得所述总菜单中每个餐品在所述当前温度区间内的第一下单次数；

在第二天数内，获得所述总菜单中每个餐品在所述当前温度区间内的第二下单次数；

根据所述第一下单次数和所述第二下单次数的加权平均值或加权和，确定所述下单次数；

其中，所述第一天数大于所述第二天数，所述第一下单次数的权重小于所述第二下单次数的权重。

6.根据权利要求5所述的方法，其特征在于，

获得所述总菜单中每个餐品在所述当前温度区间内的下单次数，还包括：在第三天数内，获得所述总菜单中每个餐品在所述当前温度区间内的第三下单次数；

根据所述第一下单次数和所述第二下单次数的加权平均值或加权和，确定所述下单次数，包括：根据所述第一下单次数、所述第二下单次数和所述第三下单次数的加权平均值或加权和，确定所述下单次数；

其中，所述第三天数小于所述第二天数，所述第三下单次数的权重，大于所述第二下单次数的权重，且，所述第三下单次数的权重与所述第三下单次数正相关。

7.根据权利要求1至6任一项所述的方法，其特征在于，响应于用户交互操作，包括：

响应于用户的手势操作，并获得与所述用户的手势操作相对应的指令，所述指令与所述选定餐品相对应；或者，

响应于用户的语音交互，并获得与所述用户的语音交互相对应的指令，所述指令与所述选定餐品相对应。

8.一种基于空调的点餐装置，其特征在于，包括：

获得模块，被配置为获得空调的设定温度以及与用户关联的地域属性；

筛选模块，被配置为在总菜单中确定与所述设定温度以及所述地域属性相对应的预选菜单；

展示模块，被配置为展示所述预选菜单；

交互模块，被配置为响应于用户交互操作，在所述预选菜单中确定与所述用户交互操作相对应的选定餐品。

9.一种基于空调的点餐装置，包括处理器和存储有程序指令的存储器，其特征在于，所述处理器被配置为在执行所述程序指令时，执行如权利要求1至7任一项所述的基于空调的点餐方法。

10.一种智能空调，其特征在于，包括如权利要求8或9所述的基于空调的点餐装置。

Images