具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
本申请实施例中,智能终端指的是具有多媒体功能的设备,该设备可以支持音频、视频、数据等至少一方面的功能,还可以具有触摸屏,传感器、摄像头等各种硬件设备。该智能终端可以包括智能冰箱、智能烤箱等智能厨电设备,智能手机、平板电脑、可穿戴设备等移动终端,以及台式电脑、笔记本电脑等个人计算机设备,还可以包括智能音响以及带有音响等输出设备的其他智能设备。
本申请实施例提供了一种数据交互方法,可以应用于数据交互系统中,如物联网的数据交互系统中,在物联网设备间进行数据交互,提高设备资源利用率。如图1A所示为本申请实施例的一种数据交互示意图,包括智能终端A、B、C和服务器S,假设A为第一用户的发送端,A可以为第一用户关联的第一智能厨电设备,也可以为第一用户关联的手机等其他设备,可以根据第一智能厨电设备的设备状态和第一用户的需求信息生成邀约请求,将邀约请求发送给服务器S,智能终端B、C可以作为接收端,服务器S根据该邀约请求确定B为可以接收邀约请求的接收端,而C不能够接收邀约请求,则将邀约请求发送给B,B对该邀约请求进行提示,若第二用户同意接受该邀约请求,可以对B进行触发,B根据该触发生成响应信息反馈给服务器S,服务器S将响应信息发送给A。其中,若有多个第二用户反馈响应信息,则A可以从多个响应信息中进行选择。本实施例以各用户的智能终端为基础通过服务器进行交互,不但能够提高设备软、硬件资源的利用率,还可以为用户提供便利,实现数据交互、分享。
例如图1B所示的一种示例场景下,第一用户的发送端可以生成针对约大厨、约饭、蹭饭、拼饭以及租空间的邀约,然后发布给服务器,通过服务器决策发送给至少一个接收端,该接收端的第二用户可以触发生成响应,从而实现邀约和响应的交互。
其中,约大厨场景指的是找人帮忙做饭的场景,具体可以通过服务器转发约大厨的邀约请求,并且该请求中可以携带所需制作的菜品名称以及需要的物品等参数,通过响应信息选择可以制作的厨师等第二用户,从而能够帮助不会做饭,或者不会制作某些饭菜的用户,提高生活的便利性。
约饭场景指的是预约提供饭菜的场景,具体可以通过服务器转发约饭的邀约请求,并且该请求中可以携带所需制作的菜品名称,或者提供一定人数饭菜、以及饭菜的条件等参数,通过响应信息选择提供饭菜等的第二用户,从而在用户约好朋友一起聚会等情况下,由附近的邻居等提供相应的饭菜,节省用户的时间。
蹭饭场景指的是找其他有饭菜的用户一起吃饭的场景,具体可以通过服务器转发蹭饭的邀约请求,该邀约请求可以携带想要吃的饭菜种类等参数,通过响应信息选择提供饭菜的用户,从而和其他人一起吃饭,并且能够增进邻里的关系。
拼饭场景指的是找其他人一起吃饭的场景,其中拼饭可以和蹭饭对应,具体可以通过服务器转发拼饭的邀约请求,该邀约请求可以携带具有的饭菜种类等参数,通过响应信息选择想要一起吃饭的用户,从而和其他人一起吃饭,并且能够增进邻里的关系,且避免食物浪费。
租空间场景指的是租用其他人的智能厨电设备的储藏空间的场景,具体可以通过服务器转发租空间的邀约请求,该邀约请求可以携带所需空间的数量、种类,以及需储藏的物品等参数,通过响应信息获取具有空间的用户,从而避免物品损坏,且能够合理利用各用户的智能厨电设备的储藏空间。
通过上述各种场景可以基于用户的各种需求执行交互,从而便于用户获取/提供所需的各种内容,在提供设备利用率的基础上还能够增进用户间交互,提高各用户和设备间的粘性。上述仅是一种示例场景的举例,实际处理中还可以应用于各种用户交互场景下,本申请实施例对此不作限定。
其中,由于设备间数据交互涉及对物品、用户以及空间的需求,因此还可以按照地域对设备进行划分,例如按照城市、区、县等行政区域划分一级或多级设备子区域,又如按照设备的位置所属社区划分一个或多个子区域,从而服务器控制请求和响应在子区域将交互。
本申请实施例中,由发送端发出邀约请求,由服务器决策对应的接收端并转发邀约请求,然后服务器将全部或部分接收端反馈的响应信息发送给接收端。其中,发送端/接收端可以是对应用户关联的设备中的一个,用户关联的设备可以是智能移动终端、智能厨电设备、智能音箱等上述各种智能终端;发送端/接收端还可以是对应用户关联的设备的操作系统、安装的APP等。
具体可以采用如下方法步骤:
参照图2,示出了本申请的一种数据交互方法实施例的步骤流程图,具体可以包括如下步骤:
步骤202,发送端生成邀约请求,所述邀约请求根据第一智能厨电设备的设备状态和第一用户的需求信息生成。
步骤204,发送端将所述邀约请求发送给服务器。
步骤206,服务器根据所述邀约请求确定接收端,将所述邀约请求发送给接收端。
步骤208,服务器接收所述响应信息,将所述响应信息发送给所述发送端,所述响应信息根据对所述邀约请求的触发生成。
本实施例中,服务器在发送端和接收端之间进行数据交互,其中,所述发送端包括:第一用户关联的设备,即第一用户关联的第一智能终端,如第一移动终端、第一厨电设备等,发送端还可以是第一用户关联的设备的操作系统、安装的APP等;接收端包括第二用户关联的设备,如第二智能终端中的第二移动终端、第二厨电设备等,接收端还可以是第二用户关联的设备的操作系统、安装的APP等。
第一厨电设备能够识别出设备状态,例如为冰箱等储藏设备时能够识别出存储的物品以及存储量等存储状态,又如为烤箱、微波炉等烹饪设备时能够识别出物品制作过程的设备状态,根据该设备状态可以确定第一用户的需求信息,第一用户还可以将需求信息输入到第一用户关联的设备中,从而采用设备状态和需求信息生成邀约请求。该邀约请求中可以包括需求信息,还可以包括对于接收者的限制条件,该限制条件可以通过标签表征。发送端将邀约请求发送给服务器,服务器可以决策将邀约请求发送给哪些接收端,对该邀约请求进行解析获取需求信息,并且可以从邀约请求中获取标签,或者根据需求信息等确定标签,根据标签确定接收端,然后将邀约请求发送给接收端。接收端可以对响应信息进行提示,第二用户确定接受该邀约时可以触发生成响应信息,然后将响应信息发送给服务器,服务器将至少到的至少一个响应信息反馈给发送端,发送端可以进一步确定是否接受该响应。
例如图1B的示例场景应用中租空间的场景,第一用户关联的第一厨电设备为冰箱A,第一用户购买了比较多的菜品,但冰箱A没有足够的存储空间,可以生成需要空间的邀约请求发送给服务器,服务器根据该邀约请求确定一个第二用户关联的冰箱B,以及另一个第二用户关联的手机C为接收端,可以将邀约请发送给B、C,冰箱B、C提示该邀约请求,并且B通过识别自身的设备状态确定具有足够的存储空间也一并进行提示,B对应第二用户通过触发生成响应信息并反馈给服务器,服务器将该响应信息发送冰箱A,在A接受该响应信息后可以将物品寄存在冰箱B中。
综上,发送端根据第一智能厨电设备的设备状态和第一用户的需求信息生成邀约请求,然后将邀约请求发送给服务器,该发送端包括:第一用户关联的设备,所述第一用户关联的设备包括第一智能厨电设备,服务器进行接收端的决策,即根据邀约请求确定推送的接收端,将邀约请求发送给相应的接收端,该接收端包括第二用户关联的设备,根据对所述邀约请求的触发生成响应信息反馈服务器,服务器将响应信息发送给所述发送端,从而通过服务器执行不同用户间的数据交互,并且能够有效地利用第一用户和第二用户的设备资源,提高资源利用率。
本实施例中,可以对智能厨电设备中的储藏设备(如智能冰箱、智能冷藏柜等)存储的物品进行识别,从而得到相应的设备状态,对存储的物品进行管理。智能厨电设备中烹饪设备可以依据制作流程信息进行物品制作,因此在制作物品的过程中也可以确定制作的设备状态,例如制作的步骤、时间等,从而对制作过程进行管理、控制。
本申请一个可选实施例中,对存储的物品进行识别确定物品信息,根据所述物品信息确定物品的设备状态。储藏设备可以对输入进行识别即对智能储藏设备中的物品进行识别,例如存储的物品名称、物品的数量,以及取出物品后剩余物品的数量等。从而确定存入以及取出的物品得到物品信息,通过对物品信息的分析可以确定物品的设备状态,其中,储藏设备可以采用多种不同的方式自动识别存储的物品,如图3所示,识别物品的方式包括以下至少一种:清单录入方式、语音录入方式、射频识别方式、图像识别方式、扫码录入方式。从而通过上述方式可以对智能储藏设备中的物品进行识别、需求分析、推荐、获取等一系列操作,便于对物品进行管理。可以上述至少一种方式进行物品信息的识别,其中各种方式的识别步骤如下:
储藏设备可以对存储的物品进行识别根据该物品信息可以确定物品的设备状态。
1)采用清单录入方式对存储的物品进行识别,确定物品信息的步骤包括:根据接收确认确定业务凭据信息,从所述业务凭据信息中识别存储的物品以及获取量,生成对应的物品信息。
用户在获取物品时通常具有业务凭据信息,该业务凭据信息包括获取物品的凭证数据即物品清单,例如网上购物的订单,线下购物的收据等,通过接收确认可以确定已经获取到物品,可以获取该接收确认对应的业务凭据信息,业务凭据信息中包括购买的每个物品以及相应的数量、价格等,通过对业务凭据信息的分析可以从该业务凭据信息中识别出存储的物品,以及获取量即物品的数量,在储藏设备的物品信息中记录该物品以及获取量。其中,业务凭据信息中部分物品可能是不放置到储藏设备中的,因此还可以预设物品类型等信息,识别出物品后根据物品类型确定是否需要存储,确定存储的物品以及获取量。其中,对于网上的业务凭据信息,可以通过摄像头等方式拍摄业务凭据信息的图像,通过对图像中文字的识别确定存储的物品以及获取量。
其中,随着网络技术的发展,越来越多的用户在网上进行购物从而可以直接配送到指定地址,使得物品的获取非常便捷。以智能冰箱中食物等物品的获取为例,可以预先在智能冰箱的操作系统中将智能冰箱的标识和用户在各购物网站注册的用户信息进行绑定,从而获取该用户在各网站的业务凭据信息即网络购物的订单等信息,该业务凭据信息包括根据所述业务请求在网站上生成的订单信息,当然其他方式生成的订单信息。基于接收确认确定接收到物品,可以获取该接收确认对应的订单信息,然后从该订单信息中识别接收的物品。例如识别出需要冰箱存储的物品,例如可以先从订单信息中识别出物品,然后对物品进行分类分析,例如分为肉类、果蔬、坚果、米粮等,预先确定出需要冰箱存储的物品类别,从而确定出订单信息中需要冰箱存储的物品,再确定该物品的数量即获取量。本申请实施例中,该获取量包括物品的各种数量信息,如重量和/或物品个数等,从而能够通过对业务凭据信息的识别从清单中录入物品和获取量得到物品信息。
2)采用语音录入方式对存储的物品进行识别,确定物品信息的步骤包括:接收语音数据,对所述语音数据进行识别确定存储的物品以及存储量,生成对应的物品信息。
用户除了在网上购买之外,也可以从其他渠道获取物品如在实体店购买,在未绑定的网站购买,朋友赠送等,储藏设备上可以配置麦克风等音频输入设备,通过音频输入设备采集用户的音频数据,当然也可以从其他智能设备如智能手机等获取用户录入的音频数据。然后对音频数据进行识别,例如将音频数据识别为对应的文本数据,再进行文本分析,通过分词等处理操作确定存储的物品以及存储量。本申请实施例对语音识别方法不作限定,可以根据实际需求确定。从语音数据中识别出存储的物品以及存储量,将物品和存储量添加到物品信息中。通过语音数据也可以识别出用户取出的物品及数量,从而确定储藏设备中存储的物品以及存储量,更新物品信息。
储藏设备可以配置显示器用于显示各种信息,如存储的物品、推荐信息、设备状态等,储藏设备还可以配置设备控制按钮,当显示器为触摸屏显示器时,控制按钮可以配置于触摸屏显示器的显示界面中,控制按钮也可以配置于显示器外部,该控制按钮用于对储藏设备进行控制,例如控制设备温度、亮度等设备状态,控制按钮可以包括音频按钮,通过触发音频按钮可以录制音频数据。
3)采用射频识别方式对存储的物品进行识别,确定物品信息的步骤包括:对物品上的电子标签进行射频识别,确定存储的物品以及存储量生成对应的物品信息。
本申请实施例中,还可以采用射频识别(Radio Frequency Identification,RFID)方式进行识别,可以在储藏设备中配置RFID阅读器等射频识别装置,用户可以将物品的相关信息如名称、存储量等写入电子标签等数据载体中,在存储物品时可以在物品上贴上电子标签等数据载体。在将物品存储到储藏设备时,储藏设备采用读出装置通过无线电讯号识别电子标签并读取其写入的数据,即可以获取物品的名称确定存储的物品,并获取对应的存储量,将物品以及存储量存储到物品信息中。其中,电子标签可以安装在物品外包装等位置,可以由用户自行配置电子标签的数据,可以由购物点配置电子标签的数据,本申请实施例对此不作限定。并且,在物品减少时也可以对电子标签等数据载体中的数据进行更新,从而通过RFID阅读器识别物品的减少,更新物品信息。RFID阅读器等射频识别装置可以配置于储藏设备外部,也可以配置于储藏设备内部。
4)采用图像识别方式对存储的物品进行识别,确定物品信息的步骤包括:采用摄像头拍摄存储物品的图片数据,对所述图片数据进行识别确定存储的物品以及存储量,生成对应的物品信息。
储藏设备还可以配置有摄像头等图像采集设备,可以采用所述储藏设备内置的摄像头拍摄储藏室内部的图片,确定存储物品的图片数据,然后对图片数据进行图像识别处理,识别储藏设备中存储的物品,以及储藏量,该存储量可以是物品的个数,也可以是识别标签上标识的重量等,将物品和存储量添加到物品信息中。因此在存入或取出物品后,可以拍摄储藏设备内部的图片数据,通过图片识别确定存入(或取出)物品及数量,从而对物品信息进行更新。储藏设备可以配置一个或多个摄像头等图像采集设备,具体可以配置于储藏设备内部,例如可以配置于储藏设备的顶部,也可以配置于侧面如设备门上。
5)采用扫码录入方式对存储的物品进行识别,确定物品信息的步骤包括:对存储的物品对应的标识码进行扫描,确定存储的物品以及存储量生成对应的物品信息。
储藏设备还可以配置有扫码器等扫描输入设备,通过扫描输入设备采用扫码录入方式对存储的物品进行识别。其中扫描的标识码至少包括:二维码、条形码。对于条形码可以采用条码识读设备对存储的物品上的条形码进行扫描,从该条形码中识别存储的物品;对于二维码可以通过摄像头等设备拍摄图像并识别,确定存储的物品以及存储量等信息,将物品以及存储量添加到物品信息中。在取出物品时也可以通过扫描确定取出的物品,以及获取量等信息从而对物品信息进行更新。其中,扫码器等扫描输入设备可以依据需求配置。例如配置于储藏设备的内部或外部。
6)热力感应方式
储藏设备还可以根据热力感应方式识别物品,即可以在储藏设备中配置热力感应设备,该热力感应设备采集物品的热量数据,其中,当物品增多时相应辐射的热量也会增减,而物品减少时辐射的热量会减少,以你根据该热量数据确定存入或取出物品,结合其他识别方式可以对物品信息进行更新。
例如对于智能冰箱、智能冷藏柜等具有制冷功能的储藏设备,物品厨电设备一段时间后温度会降低相应热量辐射也会减少,在刚放入物品时刚放入的物品通常热量较高因此会检测到热量突然增多,而后热量会逐渐降低到一定水平;而在取出物品后物品热量相应也会突然出现减少的变化,因此通过热量数据的变化可以确定物品增多或减少。
本实施例还可以采用其他方式录入物品信息,例如用户自行将物品信息输入智能冰箱等,对于物品信息的录入方式未一一列举,不应理解为是对本申请的限制。
对于上述各中识别方式,在实际处理中可以通过多种方式结合来进行物品识别,提供识别的准确性。例如通过热力感应方式识别出当前物品发生变化(增多或减少),而后通过图像识别方式拍摄图片确定发生变化的物品,从而更新物品信息。其中,用户存放物品通常具有一定的规律,因此采用图像识别方式时可以将连续拍摄的图片数据进行比较,根据变化确定增多(或减少)的物品以及数量等信息,还可以在每次开启储藏设备后均拍摄图片确定物品的变化。
又如通过清单录入方式、扫码录入方式通常是对存入物品进行检测,则可以结合语音录入方式、图像识别方式等确定取出的物品,从而对物品变化进行检测,更新物品信息并能够基于该物品信息确定变化信息。
又如用户可以在增加或减少物品时对应修改电子标签中的数据,使得RFID阅读器可以识别物品的变化,更新物品信息,在该过程中可以结合上述其他方式确定存储、取出的物品,保证数据的准确性。
本申请一个可选实施例中,当采用射频识别方式、语音录入方式或扫码录入方式时,获取所述存储的物品的生产日期,将所述生产日期记录到所述物品信息中。条形码、二维码等可以标出物品的生产国、制造厂家、商品名称、生产日期、等许多信息,电子标签中也可以存储物品的生产国、制造厂家、生产日期等各种信息,因此在采用射频识别方式或扫码录入方式时,还可以获取物品的生产日期,将所述生产日期记录到所述物品信息中。当然采用语音录入等方式使,用户也可以读入生产日期等数据,从而识别出生产日期添加到物品信息中。
本申请另一个可选实施例中,当采用清单录入方式、语音录入方式或图像识别方式时,将所述存储的物品的储存日期记录到所述物品信息中。存储物品后智能冰箱采用清单录入方式、语音录入方式或图像识别方式录入物品信息时,还可以将录入的日期作为物品的储存日期,将储存日期记录到所述物品信息中。
从而储藏设备可以通过上述一种或多种方式结合识别存储的物品得到物品信息,该物品信息可以存储物品的名称、数量、时间等各种信息,还可以在存储或取出的过程中调整物品信息。然后可以基于物品信息确定储藏设备的存储状态。
本申请实施例的数据交互系统包括:服务器、发送端和接收端,其中,用户关联的设备既可以作为发送端也可以作为接收端,当发起邀约时该用户为第一用户,当能够接收或准备接收邀约时用户为第二用户。
参照图4,示出了本申请实施例中基于交互网络的交互示意图。
4.02、发送端根据第一智能厨电设备的设备状态和第一用户的需求信息生成邀约请求。
4.04、将所述邀约请求发送给服务器。
4.06、服务器对所述邀约请求进行解析确定至少一个标签,根据所述标签确定至少一个接收端。
4.08、服务器将邀约请求发送给接收端。
4.10、接收端在所述第二用户关联的设备上显示第二界面,在所述第二界面上显示所述邀约请求的提示信息。
4.12、接收端依据触发生成响应信息。
4.14、接收端将响应信息发送给服务器。
4.16、服务器将响应信息发送给发送端。
4.18、服务器根据接收端的确认,反馈地址信息。
第一厨电设备可以识别设备状态并确定需求信息,然后根据所述设备状态和需求信息生成邀约请求,所述需求信息包括以下至少一种:物品需求信息、用户需求信息、储藏空间需求信息,将该邀约请求发送到服务器中。服务器可以根据邀约请求确定标签,通过标签确定接收端,然后将邀约请求发送给接收端。接收端可以根据自身状态确定是否对邀约请求进行提示。其中,可以确定所述第二厨电设备的空闲时间,根据所述空闲时间确定所述第二厨电设备处于工作状态时进行提示,其中,为了不影响厨电设备的正常运行,该工作状态可以是软件工作状态,如第二厨电设备配置的操作系统的工作状态,而硬件还是正常运行。然后在确定提示时在第二界面中显示该邀约请求,根据对所述需求信息的触发生成对应的响应信息。将所述响应信息发送给服务器,服务器再将响应信息反馈给发送端。由于发送端和接收端的交互通常会涉及到物品等内容的交互,因此本实施例在确认该邀约和响应完成匹配后,还可以向发送端反馈接收端的第二地址信息,和/或,向接收端反馈发送端的第一地址信息,从而实现线下物品的交互。
本实施例以服务器侧处理为例,用户可以预先在服务器中注册并关联设备,从而服务器可以对数据的交互进行管理控制。
本申请一个可选实施例中,服务器接收用户的注册请求,根据所述注册请求注册所述用户对应的账户,其中,所述用户包括第一用户和第二用户。服务器可以接收用户的注册请求,根据该注册请求为用户配置唯一的用户标识(User Identity),并配置该User ID对应的账户。
还包括基于账户打通设备即为账户配置关联设备,具体包括:确定所述用户关联的至少一个设备,分别将所述设备与所述用户的账户绑定,其中,所述设备包括:移动终端和/或智能厨电设备。用户可以采用需要关联的设备登录该账户,从而发送设备ID给服务器,服务器将该设备ID与该用户的账户绑定,从而设置该用户关联的设备。该账户还可以包括用户名、地址、用户等级、积分、资金等信息。
参照图5,示出了本申请另一种数据交出方法中服务器侧实施例的步骤流程图。
步骤502,服务器接收发送端发送的邀约请求。
服务器接收发送端根据第一智能厨电设备的设备状态,和第一用户的需求信息生成的邀约请求,所述发送端包括:第一用户关联的设备,所述第一用户关联的设备包括第一智能厨电设备。
本申请一个可选实施例中,服务器根据智能厨电设备的设备状态分析需求信息,根据所述需求信息对用户关联的设备进行提示。服务器还可以收集智能厨电设备上报的设备状态,以及收集智能厨电设备的历史行为信息,然后依据设备状态和历史行为信息分析需求信息。例如图1B的示例场景中拼饭场景下,某一用户经常在周六时发出找人一起吃饭的邀约请求,在周六时可以分析出用户具有找人吃饭的需求信息;又如图1B的示例场景中租空间场景下,某一用户的冰箱已经满了,但是收集到用户又购买了许多需要放入冰箱的食物等物品,可以分析出用户具有需要冰箱空间的需求信息。然后将需求信息发送给用户关联的设备,然后在该用户关联的设备上对该需求信息进行提示,提示用户可以发出邀约获取所需的内容。
步骤504,服务器对所述邀约请求进行解析确定至少一个标签,根据所述标签确定至少一个接收端。
步骤506,服务器将所述邀约请求发送给接收端。
服务器在接收到邀约请求后,会决策推送该邀约请求的接收端即第二用户关联的设备。服务器可以对邀约请求进行解析,通过解析获取携带的标签或分析匹配的标签,然后依据标签确定至少一个接收端,向给接收端发送邀约请求。其中,所述标签包括以下至少一种:物品类别标签、位置范围标签、邀约类型标签、用户关联标签、数量标签、用户属性标签、来源标签、接收类别标签。
本实施例中通过标签描述类别特征:物品类别标签包括所需物品的标签,例如需要食物时可以为海鲜类、水果类等;位置范围标签包括所需设备的位置范围,例如第一用户和第二用户在同一个城市、同一个小区,或者在2km范围内等;邀约类型标签包括邀约的类别,例如需要储藏空间、需要别人帮忙做饭,需要找人蹭饭、拼饭等;用户关联标签包括用户的关联关系,例如好友关系、家庭成员关系、邻居关系等;数量标签包括所需物品数量、用户数量、空间数量等;用户属性标签包括用户感兴趣的组类等,可以是用户自定义的标签;来源标签包括发布邀约请求的来源,例如APP、论坛等;接收类别标签可以为用户设定的接收类别,例如用户仅接收海鲜类的邀约。
本申请实施例中,每个用户可以对应配置各种标签,可以设置多种维度的标签,如上述的物品维度的物品类别标签,位置纬度的位置范围标签,用户维度的用户关联标签、用户属性标签,以及设备维度的接收类别标签等,不同标签可以属于一个或多个维度。为了便于对标签进行匹配,可以确定每个标签的用户集合,从而依据标签对应用户集合查找用户以及接收端。
本申请一个可选实施例中,对所述邀约请求进行解析确定至少一个标签,包括:从所述邀约请求中解析出携带的至少一个标签;和/或,从所述邀约请求中解析出需求信息,根据所述需求信息匹配至少一个标签。发送端在生成邀约请求时可以携带所需的标签,从而服务器能够直接从邀约请求中解析出携带的至少一个标签;服务器也可以从邀约请求中解析出需求信息,然后对需求信息进行匹配,匹配出至少一个标签,从而确定决策接收端的标签信息。本实施例中,所述需求信息包括以下至少一种:物品需求信息、用户需求信息、储藏空间需求信息。
其中,根据所述标签确定至少一个接收端,包括:分别确定各标签对应的用户集合,确定各用户集合均存在的第二用户,将所述第二用户关联的设备作为接收端。确定每个标签对应的用户集合,即具有一个标签时将该用户集合中第二用户关联的设备作为接收端,当存在多个标签时查找各用户集合均存在的第二用户,将所述第二用户关联的设备作为接收端。
步骤508,服务器接收响应信息,将所述响应信息发送给所述发送端。
步骤510,服务器向接收端和/或发送端反馈地址信息。
服务器将响应信息反馈给发送端后,发送端可以确定接受的响应信息并反馈相应的第一确认信息,然后服务器可以向接收端和/或发送端反馈地址信息。其中,向接收端和/或发送端反馈地址信息包括:获取所述第一用户的第一地址信息,将所述第一地址信息发送给所述接收端;和/或,获取所述第二用户的第二地址信息,将所述第二地址信息发送给所述发送端。当需要发送端的第一地址信息时,服务器可以从第一确认信息中获取第一地址信息,也可以依据第一用户的账户查找第一地址信息,然后将所述第一地址信息发送给所述接收端。当需要接收端的第二地址信息时,可以从接收端反馈的第二确认信息中获取第二地址信息,也可以依据第二用户的账户查找第二地址信息。
其中,确定地址信息的步骤包括以下至少一种:将用户的IP地址和所述用户的账户中的地址信息进行匹配,确定发送的地址信息;从用户的确认信息中获取地址信息。在确定第一用户、第二用户的地址信息时,可以从该用户反馈的邀约请求、响应信息或确认信息的IP地址来匹配位置区域,然后将该位置区域和该用户账户中的地址信息进行匹配,确定所需发送的地址信息,从而准确的确定地址信息。
本申请一个可选实施例中,根据第一确认信息生成业务凭据信息反馈给所述发送端;接收所述发送端根据所述业务凭据信息生成的支取请求,在第一用户的第一账户和第二用户的第二账户之间执行读写操作。服务器在提供物品、用户等交互过程中,该交互过程可以是等价交换的过程,例如用户之间可以进行积分、费用等的支取,因此,还可以根据邀约、响应确定业务凭据信息,业务凭据信息可以为订单信息等,因此该业务凭据信息中可以包括获取的物品、获取量、配送的地址信息,以及时间信息、订单号等。例如,发送端邀约请求中可以给出支付的积分、费用等,服务器根据该邀约请求,在接收到第一确认信息后生成该业务凭据信息。然后将业务凭据信息发送给发送端,发送端根据所述业务凭据信息生成支取请求,服务器根据该支取请求在第一用户的第一账户和第二用户的第二账户之间执行读写操作,读、写的支付数据是等价交换的价值数据,例如支付的积分值、支付费用等。即可以从第一账户取出相应的支付数据,然后在第二账户写入相应的支付数据;也可以在第二账户取出相应的支付数据后写入第一账户中。例如在第一账户和第二账户直接执行扣款、转账等业务,因此还可以获取授权信息,将所述授权信息添加到所述支取请求中,所述授权信息用于授权不输入密码的读写操作。
本申请另一个可选实施例中,根据所述邀约请求在第一用户的第一账户中添加第一积分信息;以及,根据所述响应信息在对应第二用户的第二账户中添加第二积分信息。各用户对应账户在交互网络中执行各种操作均可以获取相应的积分奖励,因此可以根据邀约请求获取积分值,例如10积分,将该积分值添加到第一账户的第一积分信息中。以及,依据响应信息确定积分值,将积分值添加到第二账户的第二积分信息中。
对于发送端侧操作:
参照图6,示出了本申请的另一种数据交互方法中发送端侧实施例的步骤流程图,具体可以包括如下步骤:
步骤602,发送端确定第一智能厨电设备的设备状态和第一用户的需求信息。
步骤604,发送端在所述第一用户关联的设备上显示第一界面,所述第一界面展示所述需求信息。
步骤606,发送端确定至少一个标签。
步骤608,发送端根据对所述第一界面的触发,采用需求信息和标签添加生成邀约请求。
需求信息可以由第一用户输入,也可以获取所述第一智能厨电设备的设备状态,根据所述设备状态确定所述第一用户的需求信息。即第一智能厨电设备识别出设备状态,然后依据该设备状态确定第一用户的需求信息,例如,第一用户的冰箱已经满了,但是识别出第一用户又购买了许多需要放入冰箱的食物等物品,可以分析出第一用户具有需要冰箱空间的需求信息。然后将需求信息显示在第一用户关联的设备上,提示用户可以发出邀约获取所需的内容。
可以在所述第一用户关联的设备上显示第一界面,所述第一界面展示所述需求信息,该第一界面用于展示需求信息,还可以包括对需求信息进行编辑的编辑控件,通过该编辑控件包括需求编辑控件对需求信息进行增加、删除、修改等编辑操作。用户还可以设置标签来指定接收端,因此该第一界面还可以包括标签编辑控件,采用该标签编辑控件编辑标签,其中,在触发标签编辑控件后可以让用户输入具体标签,也可以提供不同类别和层级的标签给用户选择,从而得到所需标签。在第一界面中完成对需求信息和标签的编辑后,可以触发该第一界面从而采用需求信息和标签添加生成邀约请求。
所述需求信息包括以下至少一种:物品需求信息、用户需求信息、储藏空间需求信息。本申请实施例中,根据所述设备状态确定所述第一用户的需求信息,包括以下至少一种步骤:
S1,确定物品的获取量,并根据所述设备状态确定所述第一厨电设备的第一剩余空间信息;当所述物品的获取量大于所述第一剩余空间信息时,根据所述获取量生成储藏空间需求信息。
S2、获取所述第一用户的物品需求条件;根据所述设备状态确定第一厨电设备不满足所述物品需求条件时,根据所述物品需求条件生成物品需求信息。
S3、根据所述设备状态确定配方信息;根据所述配方信息生成用户需求信息,和/或,生成获取所述制作方的用户需求信息。
其中,S1具体如下:
本实施例中,第一邀约请求可以是针对厨电设备中存储空间的邀约请求。用户可以通过各种渠道获取物品,可以确定所获取物品的获取量,然后根据第一厨电设备的设备状态确定其未存储物品的第一剩余空间信息。将获取量和第一剩余空间信息进行比较,若获取量不大于第一剩余空间信息,则可以采用第一厨电设备存储该物品,若获取量大于第一剩余空间信息,第一厨电设备无法存储所有的物品,可以根据该获取量生成储藏空间需求信息。其中,可以将获取的物品可以一部分存储到第一厨电设备,另一部分存储到第二厨电设备,则将获取量减去存储量得到需求量,采用需求量生成储藏空间需求信息;也可以将物品全部存储到第二厨电设备中,则该获取量作为需求量,采用需求量生成储藏空间需求信息,当然可以将要存储的物品及其数量作为需求量生成储藏需求空间信息。采用所述储藏空间需求信息生成第一邀约请求。
例如图1B中的租空间场景:厨电设备为冰箱,用户a家今天来了客人,买了很多的菜,自己家的冰箱空间不够,不能将菜全部放入,但是,夏季大部分菜不放入冰箱就不新鲜,甚至可能出现腐烂等问题,因此用户a发起了租空间的请求到社区,即a家的冰箱可以作为第一厨电设备基于生成储藏空间需求信息,采用储藏空间需求信息生成第一邀约请求,将第一邀约请求上传给服务器。服务器确定用户b关联的设备为接收端,例如用户b的冰箱作为接收端接收邀约请求,用户b在家使用冰箱即该冰箱的操作系统处于工作状态,可以对该邀约请求进行显示,b自己平时也不做饭也不常用冰箱,根据冰箱的设备状态确定可以存储时,可以接收该邀约即将冰箱短暂的租给a,则生成相应的响应信息并反馈。
S2具体如下:
物品需求条件可以包括多种不同的需求条件。
一种方式是:根据用户数量确定物品需求量,并根据所述设备状态确定物品存储量;当所述存储量小于所述物品需求量时,根据所述用户数量和物品需求量生成物品需求信息;采用所述物品需求信息生成第二邀约请求。第二邀约请求是获取指定物品的邀约请求。确定用户数量,该用户数量是一起对物品进行处理的用户数量,如3个、5个等,根据该用户数量确定所需的物品以及物品需求量。获取第一厨电设备的设备状态,根据该设备状态确定存储的物品以及相应的存储量,将存储量与物品需求量进行比较,当存储量小于物品需求量时,确定没有足够该用户数量的物品,可以根据该用户数量和物品需求量生成物品需求信息,采用所述物品需求信息生成第二邀约请求。
本申请一个可选实施例中,所述根据用户数量和物品需求量生成物品需求信息,包括:根据所述用户数量和物品需求量确定至少一个配方信息,将所述配方信息作为物品需求信息。在确定物品需求信息时,可以根据用户数量以及所确定的物品需求量确定至少一个配方信息,其中,对所述物品进行匹配、物品组合可以确定配方,根据该配方可以生成配方信息,配方信息可以包括配方名称、配方所需的物品以及制作过程等,本实施例中可以将配方名称作为配方信息,将该配方信息作为物品需求信息,通过第二邀约请求来获取配发名称对应的组合物品。
例如图1B中的约饭场景:厨电设备为冰箱,用户a家今天来了3位客人,但用户a的冰箱中没有足够的食物提供5个人(用户a家和客人的总和)食用,可以确定5个菜品名称(其中,菜谱即配方,菜品名称即配方名称)以及2斤米饭等生成物品需求信息,再生成对应的第二邀约请求发布到交互网络中。交互网络将该邀约请求分享给网络中的状态信息满足预设条件的第二厨电设备,如用户b的冰箱,用户b的冰箱对该第二邀约请求进行显示,在接收到用户b的触发后可以生成响应信息并反馈。
另一种方式:获取用户的物品需求条件;当根据所述设备状态确定第一厨电设备不满足所述物品需求条件时,根据所述物品需求条件生成物品需求信息;采用所述物品需求信息生成第三邀约请求。第三邀约请求包括用户针对需要物品的相关条件,例如对于物品或组合物品的需求以及需求量等,可以由用户触发生成,也可以基于厨电设备所收集的用户习惯信息生成,根据该物品需求条件与厨电设备的设备状态进行比较,例如,确定厨电设备是否存储有该物品,是否能够得到该组合物品等,当根据设备状态确定第一厨电设备不满足所述物品需求条件时,可以根据物品需求条件生成物品需求信息,再采用所述物品需求信息生成第三邀约请求。本申请一个可选实施例中,该物品需求条件可以包括针对配方的需求条件,即可以确定出用户所需的至少一个配方信息,根据该配方信息生成物品需求条件。
例如图1B中的蹭饭的场景:厨电设备为冰箱,用户a中午时不想做饭,平时也很少做饭,因此其冰箱中存储食物很少,在确定出用户a想吃的菜品和主食生成物品需求条件后,确定冰箱的设备状态不能够制作相关菜品,即不满足物品需求条件,可以生成需求该菜品和主食的第三邀约请求,将第三邀约请求发送到交互网络中,用户b冰箱的状态信息满足预设条件,能够接收并显示该第三邀约请求,用户b中午刚好要作这些菜品和主食,可以生成响应信息反馈给用户a,用户a可以在用户b家吃午饭。
S3具体如下:
一种方式:依据所述存储状态确定配方信息,依据所述配方信息生成用户需求信息;采用所述用户需求信息生成第四邀约请求。第四邀约请求是针对指定物品邀请用户、物品的邀约请求。第一厨电设备还可以对存储的物品进行组合确定配方信息,例如智能冰箱根据物品生成菜谱推荐给用户。即根据物品的设备状态确定存储的物品以及存储量等信息,然后对物品进行组合生成配方信息,其中可以以部分物品为主要原料确定配方信息,该配方信息还可以结合用户的习惯生成。确定配方信息后用户可以制作,但是有时根据该配方信息可能会制作出比较多个的组合物品,可以对该组合物品进行分享,因此可以确定需要分享的分享用户数,根据该配方信息确定分享用户数生成用户需求信息,采用所述用户需求信息生成第四邀约请求。
本申请一个可选实施例中确定需求信息的步骤还包括,S4,根据所述配方信息确定所述第一厨电设备中缺少的物品以及需求量,根据所述缺少的物品以及需求量生成物品需求信息。所述配方信息至少包括多个物品的描述信息,所述配方信息所包含的多个物品中可以全部、部分为存储的物品,当然也可以都是未存储的物品。即该配方信息中记录有需要的物品,物品的需求量以及物品组合信息等,其中可以根据配方信息确定缺少的物品,缺少的物品包括未存储的物品和/或存储量不足的物品。即有部分是未存储的物品,或者厨电设备中储量不足的物品,因此可以确定缺少的物品以及需求量,采用缺少的物品以及需求量生成物品需求信息,将物品需求信息添加到第四邀约请求中,以向邀请的用户请求获取相应缺少的物品。
例如图1B中的拼饭的场景:厨电设备为冰箱,用户a难以抉择要制作的物品,或者在想做某些物品时不知道原材料以及做法时,可以在智能冰箱上搜索菜谱,智能冰箱根据存储的物品生成菜谱,即以存储的物品为基础确定可以制作的菜品得到相应的菜谱,并确定缺少的物品,根据该菜谱确定缺少的物品生成物品需求信息。并且根据所制作菜品的数量等确定分享用户数生成用户需求信息,根据该用户需求信息和物品需求信息生成第四邀约请求。将第四邀约请求发送到交互网络中,状态信息满足预设条件的冰箱可以接收该邀约请求,可以根据设备状态确定是否具有缺少的物品以及存储量是否够需求量等,并且可以根据用户b触发生成响应信息。用户a和b相约确定菜谱并一起吃饭,可以在a家制作,也可以在b家制作。
另一种方式:根据所述设备状态确定配方信息;当确定需要所述配方信息的制作方时,生成获取所述制作方的用户需求信息;采用所述用户需求信息生成第五邀约请求。第五邀约请求是针对制作组合物品的用户的邀约请求。与上述类似第一厨电设备根据设备状态确定配方信息,可以对该配方信息进行显示,虽然该第一厨电设备能够显示配方信息对应组合物品的制作过程,但是用户可能仍然无法制作该组合物品,则可以确定需要所述配方信息的制作方,相应生成获取所述制作方的用户需求信息,用所述用户需求信息生成第五邀约请求。上述过程中,若根据设备状态确定配方信息对应缺少的物品以及需求量,也可以根据所述缺少的物品以及需求量生成物品需求信息,将物品需求信息添加到第五邀约请求中。
例如图1B中的约大厨的场景:厨电设备为冰箱,用户a确定想要吃某些菜品,如鱼香肉丝、水煮鱼等,虽然冰箱可以显示制作菜品的原材料和制作过程,但是用户a仍然不会制作,则可以要请求其他用户如厨师等制作,可以生成邀约菜品制作方的第五邀约请求,并且可以确定制作该菜品时冰箱中缺少的物品和数量,添加到第五邀约请求,将第五邀约请求发布到交互网络中,状态信息满足预设条件的冰箱可以接收该邀约请求,能够制作该物品的用户可能触发冰箱生成响应信息,也可以根据设备状态确定是否具有缺少的物品以及存储量是否够需求量等。
本实施例中还可以显示所述配方信息中的物品制作过程,其中,所述配方信息至少包括:图文配方信息或视频配方信息,基于该配方信息可以制作相应的物品,即采用配方信息显示物品制作过程,可以通过图文方式显示,也可以通过视频显示物品制作过程。当配方信息为菜谱时,在对菜谱中物品(即原材料)都准备完成后,智能冰箱还可以显示所述菜谱中的菜品制作过程。即在智能冰箱的显示器上显示菜谱中菜品的制作过程,例如没有原材料如何处理,如切丝、切条,腌制等,根据该制作过程一步步对物品进行处理从而制作相应的菜品。其中,所述菜谱至少包括:图文菜谱、视频菜谱。即智能冰箱可以通过图文的形式显示菜谱,确定每一步的制作过程,也可以通过视频的形式显示菜谱,播放每一步的制作过程,从而辅助用户制作菜品。
上述各类邀约请求可以根据厨电设备的状态确定需求信息来生成,实际处理中也可以根据用户的触发确定相应的需求信息并生成对应类型的邀约请求,本申请实施例对此不作限定。
步骤610,发送端发送所述邀约请求给服务器。
步骤612,发送端接收服务器反馈的响应信息。
步骤614,发送端根据响应信息获取地址信息。
在生成各类邀约请求后,可以发送该邀约请求到服务器。并且,可以从服务器中接收响应信息,由于需要获取物品或者用户,因此还可以根据该响应信息获取地址信息。该地址信息可以是获取接收端的第二地址信息,也可以将发送端的第一地址信息告知服务器等。
对于本端第一地址的告知一种方式是:根据所述响应信息获取本端的第一地址信息,根据所述第一地址信息生成第一确认信息发送给服务器。即当第一用户关联的设备的邀约请求需要获取物品或用户到本地时,可以通过触发所述响应信息,获取本端的第一地址信息,该第一地址信息即第一用户关联的设备如第一厨电设备所在的地址信息,采用该第一地址信息生成第一确认信息,通过服务器反馈给第二用户,使得第二用户关联的设备能够显示该地址,从而提供相应的物品或用户到该第一地址信息,例如上述第二、第四、第五邀约请求就可以将自身的第一地址信息发送给第二用户。还可以由服务器匹配第一地址信息直接告知第二用户关联的设备。
对于接收端的第二地址的一种方式获取是:根据所述响应信息生成第二确认信息,将所述第二确认信息发送给服务器;接收所述服务器反馈的应答信息,从所述应答信息中获取接收端的第二地址信息。即当第一用户关联的设备的邀约请求是需要到对端获取物品或提供物品给对端时,可以触发所述响应信息生成第二确认信息,将第二确认信息发送到服务器中反馈第二用户告知服务器和第二用户,该第一用户同意该响应信息,服务器可以匹配或者从第二用户可以获取其第二地址信息,该第二地址信息即第二用户关联的设备如第二厨电设备所在的地址信息,采用第二地址信息生成应答信息,服务器将应答信息发送给第一用户关联的设备,第一用户关联的设备可以从所述应答信息中获取对端的第二地址信息,从而到对端获取物品或提供物品给对端,例如上述第一、第三邀约请求就可以获取第二地址信息。
通过交互通信可以获取所需的地址信息,从而通过确定用户或物品所需的地址信息,在需要的时间内用户到达该地址,或者物品送到该地址。
本申请一个可选实施例中,接收业务凭据信息,根据业务凭据信息生成支取请求,将所述支取请求发送给服务器;其中,所述支取请求用于在第一用户的第一账户和第二用户的第二账户之间执行读写操作。物品、用户等交互过程中,该交互过程可以是等价交换的过程,例如用户之间可以进行积分、费用等的支取,因此,还可以根据邀约、响应确定业务凭据信息,业务凭据信息可以为订单信息等,因此该业务凭据信息中可以包括获取的物品、获取量、配送的地址信息,以及时间信息、订单号等。例如,发送端邀约请求中可以给出支付的积分、费用等,服务器根据该邀约请求,在接收到第一确认信息后生成该业务凭据信息。然后将业务凭据信息发送给发送端,发送端根据所述业务凭据信息生成支取请求,服务器根据该支取请求在第一用户的第一账户和第二用户的第二账户之间执行读写操作,读、写的支付数据是等价交换的价值数据,例如支付的积分值、支付费用等。即可以从第一账户取出相应的支付数据,然后在第二账户写入相应的支付数据;也可以在第二账户取出相应的支付数据后写入第一账户中。
本申请另一个可选实施例中,根据所述积分信息确定用户等级;和/或,根据所述积分信息生成替换请求,将所述替换请求发送到服务器以获取相应的物品。账户的积分信息可以用户评价用户等级,不同等级的用户可以具有不同的用户权限,例如二级以上用户才能发送邀约请求等。积分还可以用于兑换物品,即交互网络可以提供一些免费或部分免费的物品,用户可以仅使用积分或者使用积分+费用获取相应的物品,在选定某一物品后,在积分信息满足该物品的需求后,可以根据积分信息生成替换请求,将所述替换请求发送到所述交互网络,网络从对应账户的积分信息支取相应的费用,然后将物品提供到该替换请求所要求的地址。
本申请实施例中,还包括向服务器上传第一用户描述信息,以使服务器根据所述第一用户描述信息设置所述第一用户对应的标签。即用户在注册以及后续与服务器交互的过程中,可以向服务器上传第一用户描述信息,该第一用户描述信息用于描述第一用户的特征,例如用户的地址、兴趣以及行为数据等,从而分析出用户第一用户对应的标签。
对于发送端侧操作:
参照图7,示出了本申请的另一种数据交互方法中发送端实施例步骤流程图,具体可以包括如下步骤:
步骤702,接收端从服务器接收邀约请求。
步骤704,通过对所述邀约请求的解析获取对应的需求信息,根据所述需求信息生成对应的提示信息。
步骤706,在所述第二用户关联的设备上显示第二界面,在所述第二界面上显示所述邀约请求的提示信息。
接收端从服务器接收邀约请求,然后可以对邀约请求进行解析,从邀约请求中获取需求信息,该需求信息包括以下至少一种:物品需求信息、用户需求信息、储藏空间需求信息,采用需求信息生成提示信息,然后在所述第二用户关联的设备上显示第二界面,在所述第二界面上显示所述邀约请求的提示信息。该提示信息可以简单提示用户的需求,例如用户要租空间等,提示有租空间请求,在用户感兴趣触发后再显示详细内容,例如要放置的物品、放置时间、支付的费用等,也可以直接显示相应的提示信息,提示该需求信息所需的各种内容。
其中,在第二用户关联的设备有时会处于非工作状态,则此种状态下可以不进行提示,因此所述对所述邀约请求进行提示,可以包括:获取所述第二用户关联的设备的状态信息。当所述状态信息满足预设条件,在第二用户关联的设备中对所述约请求进行提示。具体的:确定所述第二用户关联的设备的空闲时间,根据所述空闲时间确定状态信息,其中,所述空闲时间根据当前时间和关闭时间的差值确定,所述状态信息包括工作状态和休眠状态,所述预设条件包括设备处于工作状态。本申请实施例中可以通过邀约请求提供物品、用户以及获取物品等,可以确定第二用户关联的设备的工作状态或休眠状态,来确定是否接收邀约请求。用户可以开启冰箱等厨电设备获取物品,在获取物品后关闭厨电设备,因此在每次关闭厨电设备时可以记录该关闭时间,并将该关闭时间作为最后关闭时间,下一次关闭时采用下一次记录时间对该最后关闭时间进行更新,从而根据当前时间和该最后关闭时间的差值确定空闲时间,若空闲时间小于空闲阈值则可以确定第二厨电设备处于工作状态,该空闲阈值为未使用厨电设备的时间阈值,例如3小时、节假日。当然也可以设定空闲时间,例如周末为空闲时间且满足时间阈值,则在周末时第二厨电设备处于工作状态,可以确定状态信息满足预设条件。
一个可选实施例中,通过对所述邀约请求的解析获取对应的需求信息,根据所述需求信息生成对应的提示信息,包括:对所述邀约请求进行解析,获取对应的储藏空间需求信息;根据所述第二用户关联的第二厨电设备的设备状态确定第二剩余空间信息;当所述第二剩余空间信息大于所述储藏空间需求信息时,生成对应的提示信息。
针对第一邀约请求,可以对该第一邀约请求进行解析,获取对应的储藏空间需求信息,根据储藏空间需求信息确定对于空间的需求量。然后获取第二厨电设备中物品的设备状态,根据该设备状态确定第二厨电设备中的第二剩余空间信息。判断第二剩余空间信息是否大于需求量,若大于该需求量即第二剩余空间信息大于所述储藏空间需求信息,可以生成提示信息。例如厨电设备为冰箱,有些用户平时很少做饭也不常用冰箱,因此建立冰箱剩余空间比较大,在接收到该第一邀约请求并确定满足需求量之后,可以生成响应信息,租借自家的冰箱给有需要的用户。
步骤708,接收所述第二页面反馈的触发指示,根据所述触发指示生成响应信息。
所述触发指示用于指示接受所述邀约请求,针对第一到第五邀约请求可以解析出需求信息生成对应提示信息显示在第二页面中,第二用户确定接收邀约请求后可以触发第二界面生成触发指示,依据该触发指示生成响应信息。
其中,将所述第二厨电设备的设备状态与所述配方信息进行比较,确定缺少的物品,所述缺少的物品包括未存储的物品和/或存储量不足的物品;根据所述缺少的物品和对应待获取量生成业务请求,以请求获取物品。上述各类型邀约请求中可以携带物品需求信息,物品需求信息中可以包括配方信息,例如配方名称、配方所需物品等。第二厨电设备还可以将设备状态和配方信息进行匹配,确定该是否存储有配方信息中需要的物品,以及存储量是否充足等,即可以确定配方中需要而第二厨电设备中缺少的物品,所述缺少的物品包括未存储的物品和/或存储量不足的物品,即有部分是未存储的物品,或者厨电设备中储量不足的物品,该未存储的物品可以作为待获取物品,然后根据该配方信息和设备状态确定待获取量,将待获取物品和待获取量生成业务请求,以请求获取物品,即向提供方发送该业务请求,提供方可以根据该业务请求配置物品并配送,因此该业务请求可以携带地址信息,包括第一地址信息或第二地址信息。例如厨电设备为冰箱,用户可以接收其他用户对于某些菜品的需求,或者与其他用户一起做饭,帮助其他用户做饭等,对于要做的饭菜等可能部分菜谱中的菜品缺少,需要响应用户提供,因此,该响应用户的冰箱还可以根据菜谱和冰箱的设备状态,即以存储的物品为基础确定菜谱中缺少的物品,即菜谱中需要到智能冰箱当前没有的物品,根据所需的物品以及物品的购买数量生成业务请求,以请求获取物品。
步骤710,接收端将所述响应信息发送给服务器。
步骤712,接收端获取地址信息。
由于对于物品以及用户等邀约中,可能需要第一用户的第一地址信息和/或第二用户的第二地址信息。一种获取第一地址信息的方式:从服务器中获取发送端的第一地址信息,该第一地址信息可以由服务器匹配确定,也可以是服务器从第一确认信息中获取对端的第一地址信息后转发的。
另一种告知第二地址信息的方式:获取本端的第二地址信息,将所述第二地址信息添加到应答信息中反馈给服务器。即当第一用户的邀约请求是需要到对端获取物品或提供物品给对端时,可以触发所述响应信息生成第二确认信息,将第二确认信息发送到交互网络中反馈第二用户,告知第二用户该第一用户同意该响应信息,第二用户可以获取自身的第二地址信息,该第二地址信息即第二用户所在的第二地址信息,采用第二地址信息生成应答信息,将应答信息发送到服务器中转发给第一厨电设备,还可以由服务器匹配第二用户的第二地址信息直接反馈给第一用户。
本申请实施例中,物品、用户等交互过程中,该交互过程可以是等价交换的过程,例如用户之间可以进行积分、费用等的支取,因此,还可以根据邀约、响应确定业务凭据信息,业务凭据信息可以为订单信息等,因此该业务凭据信息中可以包括获取的物品、获取量、配送的地址信息,以及时间信息、订单号等。例如,发送端邀约请求中可以给出支付的积分、费用等,服务器根据该邀约请求,在接收到第一确认信息后生成该业务凭据信息。然后将业务凭据信息发送给发送端,发送端根据所述业务凭据信息生成支取请求,服务器根据该支取请求在第一用户的第一账户和第二用户的第二账户之间执行读写操作,读、写的支付数据是等价交换的价值数据,例如支付的积分值、支付费用等。即可以从第一账户取出相应的支付数据,然后在第二账户写入相应的支付数据;也可以在第二账户取出相应的支付数据后写入第一账户中。
一个可选实施例中,根据所述积分信息确定用户等级;和/或,根据所述积分信息生成替换请求,将所述替换请求发送到所述交互网络,以获取相应的物品。本申请实施例中,各厨电设备对应账户的用户在交互网络中执行各种操作均可以获取相应的积分奖励,因此可以根据对邀约请求的响应信息获取积分值,例如10积分,将该积分值添加到第一账户的积分信息中,若用户接收该响应信息即发送确认信息,也可以获取响应的积分值。账户的积分信息可以用户评价用户等级,不同等级的用户可以具有不同的用户权限,例如二级以上用户才能发送邀约请求等。积分还可以用于兑换物品,即交互网络可以提供一些免费或部分免费的物品,用户可以仅使用积分或者使用积分+费用获取相应的物品,在选定某一物品后,在积分信息满足该物品的需求后,可以根据积分信息生成替换请求,将所述替换请求发送到所述交互网络,网络从对应账户的积分信息支取相应的费用,然后将物品提供到该替换请求所要求的地址。服务器对于费用、积分等添加或扣除到对应账户后,可以给该账户对应用户关联的设备发送提示信息。
本实施例中,向服务器上传第二用户描述信息,以使服务器根据所述第二用户描述信息设置搜书第二用户对应的标签。即用户在注册以及后续与服务器交互的过程中,可以向服务器上传第二用户描述信息,该第二用户描述信息用于描述第二用户的特征,例如用户的地址、兴趣以及行为数据等,从而分析出用户第二用户对应的标签。
从而通过服务器在用户的不同设备间进行数据传输,用户可以直接采用移动终端、厨电设备等的操作系统进行交互,无需增加额外的硬件设备。上述实施例已经以智能冰箱等厨电设备为例论述,实际上该数据交互也可以应用于智能家居等设备中,从而在物联网中实现各种设备的交互。
本申请另一个示例中,智能终端以智能衣柜为例,物品包括衣物、鞋帽、饰品等,可以通过识别确定用户放置物品,并确定物品状态,如各季节衣物的数量、经常穿的衣物等。例如在夏季来临时,用户A将家中冬季的衣物、鞋帽等物品打包准备收藏起来,但是家中的第一智能衣柜储藏空间不足,可以确定空间的需求量生成储藏空间需求信息,采用储藏空间需求信息生成第一邀约请求,将第一邀约请求发布到服务器,服务器确定用户B为第二用户,向用户B发送邀约请求。用户B家中只有一个人,第二智能衣柜具有较大的存储空间,用户B的智能衣柜可以接收并显示该第一邀约请求,确定第二智能衣柜的空间满足该需求量,可以生成响应信息并通过服务器反馈给第一智能衣柜,从而帮助用户A存储衣物等物品。
此外,在用户根据衣物搭配方案(配方信息)确定需要的衣物,以及需要与其他用户交换衣物,或者捐赠旧衣时,均可以生成相应类别的邀约请求,将相应类别的邀约请求发布到交互网络中,从而与其他用户进行交互,使得不同用户可以交换衣物,获取需要的旧衣物等,例如幼儿成长较快,衣物可能穿了几次就小了,可以将这些衣物说明以及照片等信息配置成邀约请求,从而其他需要的用户可以根据该邀约请求生成响应信息,从而可以获取响应的衣物,能够提高衣物的利用率并且减少浪费。物联网中的用户也可以通过邀约请求和响应信息相约整理家中旧衣,将旧衣收集到一个用户家中后通过邮寄等方式一起捐赠。
上述管理方法还可以应用到各种场景中,例如应用于医院的药物厨电设备中,通过识别、分析等确定医院缺少的药品、医疗器械等得到相应的物品需求信息生成邀约请求,将邀约请求发布到交互网络中,从其他医院调取急需的物品,例如血液等。对各种智能终端的数据交互方法和场景未一一列举,不应理解为是对本申请实施例的限制。
需要说明的是,对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请实施例并不受所描述的动作顺序的限制,因为根据本申请实施例,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本申请实施例所必须的。
在上述实施例的基础上,本实施例还公开了一种数据交互系统,如图8所示,该数据交互系统中包括服务器10、发送端20和接收端30。
其中,发送端20,用于生成邀约请求,将所述邀约请求发送给服务器,所述邀约请求根据第一智能厨电设备的设备状态和第一用户的需求信息生成,所述发送端包括:第一用户关联的设备,所述第一用户关联的设备包括第一智能厨电设备。
服务器10,用于根据所述邀约请求确定接收端,将所述邀约请求发送给接收端,所述接收端包括第二用户关联的设备;接收所述响应信息,将所述响应信息发送给所述发送端,所述响应信息根据对所述邀约请求的触发生成。
接收端30,用于接收服务器10发送的邀约请求,通过对所述邀约请求的触发生成响应信息,将响应信息发送给服务器10。
本实施例的数据交互装置,应用于服务器中,参照图9,示出了本申请一种数据交互装置实施例的结构框图,具体可以包括如下模块:
第一接收模块902,用于接收发送端发送的邀约请求,所述邀约请求根据第一智能厨电设备的设备状态和第一用户的需求信息生成,所述发送端包括:第一用户关联的设备,所述第一用户关联的设备包括第一智能厨电设备;以及,接收响应信息,所述响应信息根据对所述邀约请求的触发生成。
分发决策模块904,用于根据所述邀约请求确定接收端,所述接收端包括第二用户关联的设备。
第一发送模块906,用于将所述邀约请求发送给接收端;以及,将所述响应信息发送给所述发送端。
其中,还包括:
注册模块,用于接收用户的注册请求,根据所述注册请求注册所述用户对应的账户,其中,所述用户包括第一用户和第二用户。
所述分发决策模块,用于对所述邀约请求进行解析确定至少一个标签,根据所述标签确定至少一个接收端。
所述分发决策模块,用于从所述邀约请求中解析出携带的至少一个标签;和/或,从所述邀约请求中解析出需求信息,根据所述需求信息匹配至少一个标签。
其中,所述标签包括以下至少一种:物品类别标签、位置范围标签、邀约类型标签、用户关联标签、数量标签、用户属性标签、来源标签、接收类别标签。所述需求信息包括以下至少一种:物品需求信息、用户需求信息、储藏空间需求信息。
所述分发决策模块,用于分别确定各标签对应的用户集合,确定各用户集合均存在的第二用户,将所述第二用户关联的设备作为接收端。
还包括:
设备关联模块,用于确定所述用户关联的至少一个设备,分别将所述设备与所述用户的账户绑定,其中,所述设备包括:移动终端和/或智能厨电设备。
需求提示模块,用于根据智能厨电设备的设备状态分析需求信息,根据所述需求信息对用户关联的设备进行提示。
第一反馈模块,用于获取所述第一用户的第一地址信息,将所述第一地址信息发送给所述接收端;和/或,获取所述第二用户的第二地址信息,将所述第二地址信息发送给所述发送端。
第一反馈模块,用于将用户的IP地址和所述用户的账户中的地址信息进行匹配,确定发送的地址信息;从用户的确认信息中获取地址信息。
账户读写模块,用于根据第一确认信息生成业务凭据信息反馈给所述发送端;接收所述发送端根据所述业务凭据信息生成的支取请求,在第一用户的第一账户和第二用户的第二账户之间执行读写操作。
账户读写模块,用于根据所述邀约请求在第一用户的第一账户中添加第一积分信息;以及,根据所述响应信息在对应第二用户的第二账户中添加第二积分信息。
本实施例的数据交互装置,应用于发送端中,参照图10,示出了本申请另一种数据交互装置实施例的结构框图,具体可以包括如下模块:
需求确定模块1002,用于确定第一智能厨电设备的设备状态和第一用户的需求信息,其中,所述发送端包括:第一用户关联的设备,所述第一用户关联的设备包括第一厨房设备。
请求生成模块1004,用于对所述需求信息的触发生成邀约请求。
第二发送模块1006,用于将所述邀约请求发送给服务器。
第二接收模块1008,用于接收服务器反馈的响应信息。
其中,所述需求确定模块,用于获取所述第一智能厨电设备的设备状态,根据所述设备状态确定所述第一用户的需求信息。其中,所述需求信息包括以下至少一种:物品需求信息、用户需求信息、储藏空间需求信息。
所述需求确定模块,用于确定物品的获取量,并根据所述设备状态确定所述第一厨电设备的第一剩余空间信息;当所述物品的获取量大于所述第一剩余空间信息时,根据所述获取量生成储藏空间需求信息。
所述需求确定模块,用于获取所述第一用户的物品需求条件;根据所述设备状态确定第一厨电设备不满足所述物品需求条件时,根据所述物品需求条件生成物品需求信息。
所述需求确定模块,用于根据所述设备状态确定配方信息;根据所述配方信息生成用户需求信息,和/或,生成获取所述制作方的用户需求信息。
所述需求确定模块,还用于根据所述配方信息确定所述第一厨电设备中缺少的物品以及需求量,根据所述缺少的物品以及需求量生成物品需求信息。
请求生成模块,还用于确定至少一个标签,将所述标签添加到所述邀约请求中。所述标签包括以下至少一种:物品类别标签、位置范围标签、邀约类型标签、用户关联标签、数量标签、用户属性标签、来源标签、接收类别标签。
还包括:显示模块,用于在所述第一用户关联的设备上显示第一界面,所述第一界面展示所述需求信息。请求生成模块,用于根据对所述第一界面的触发生成邀约请求。所述第一界面包括编辑控价,所述编辑控件包括需求编辑控件和标签编辑控件。
第一地址确定模块,用于根据所述响应信息获取本端的第一地址信息,根据所述第一地址信息生成第一确认信息发送给服务器。根据所述响应信息生成第二确认信息,将所述第二确认信息发送给服务器;接收所述服务器反馈的应答信息,从所述应答信息中获取接收端的第二地址信息。
支取模块,用于接收业务凭据信息,根据业务凭据信息生成支取请求,将所述支取请求发送给服务器;其中,所述支取请求用于在第一用户的第一账户和第二用户的第二账户之间执行读写操作。
第一识别模块,用于对存储的物品进行识别确定物品信息,根据所述物品信息确定物品的设备状态,其中,物品的识别方式包括以下至少一种:清单录入方式、语音录入方式、射频识别方式、图像识别方式、扫码录入方式。
第一交互模块,用于根据所述积分信息确定用户等级;和/或,根据所述积分信息生成替换请求,将所述替换请求发送到服务器以获取相应的物品。
所述第二发送模块,还用于向服务器上传第一用户描述信息,以使服务器根据所述第一用户描述信息设置所述第一用户对应的标签。
本申请实施例还提供了一种数据交互装置,应用于接收端。
参照图11,示出了本申请又一种数据交互装置实施例的结构框图,具体可以包括如下模块:
第三接收模块1102,用于从服务器接收邀约请求,所述邀约请求根据对需求信息的触发生成,所述接收端包括第二用户关联的设备。
提示响应模块1104,用于对所述邀约请求进行提示,根据对所述邀约请求的触发生成响应信息。
第三发送模块1106,用于将所述响应信息发送给服务器,以通过所述服务器反馈给发送端,所述发送端包括:第一用户关联的设备。
提示响应模块1104,用于获取所述第二用户关联的设备的状态信息;当所述状态信息满足预设条件,在第二用户关联的设备中对所述约请求进行提示。
提示响应模块1104,用于确定所述第二用户关联的设备的空闲时间,根据所述空闲时间确定状态信息,其中,所述空闲时间根据当前时间和关闭时间的差值确定,所述状态信息包括工作状态和休眠状态,所述预设条件包括设备处于工作状态。
提示响应模块1104,用于在所述第二用户关联的设备上显示第二界面,在所述第二界面上显示所述邀约请求的提示信息。
提示响应模块1104,还用于通过对所述邀约请求的解析获取对应的需求信息,根据所述需求信息生成对应的提示信息。其中,所述需求信息包括以下至少一种:物品需求信息、用户需求信息、储藏空间需求信息。
提示响应模块1104,用于对所述邀约请求进行解析,获取对应的储藏空间需求信息;根据所述第二用户关联的第二厨电设备的设备状态确定第二剩余空间信息;当所述第二剩余空间信息大于所述储藏空间需求信息时,生成对应的提示信息。
提示响应模块1104,用于接收所述第二页面反馈的触发指示,根据所述触发指示生成响应信息,所述触发指示用于指示接受所述邀约请求。
获取模块,用于根据所述需求信息中的物品需求信息确定配方信息;将所述第二厨电设备的设备状态与所述配方信息进行比较,确定缺少的物品,所述缺少的物品包括未存储的物品和/或存储量不足的物品;根据所述缺少的物品和对应待获取量生成业务请求,以请求获取物品。
第二地址确定模块,用于从服务器获取发送端的第一地址信息;和/或,获取本端的第二地址信息,将所述第二地址信息添加到应答信息中反馈给服务器。
第二识别模块,用于对存储的物品进行识别确定物品信息,根据所述物品信息确定物品的设备状态,其中,物品的识别方式包括以下至少一种:清单录入方式、语音录入方式、射频识别方式、图像识别方式、扫码录入方式。
第二交互模块,用于根据所述积分信息确定用户等级;和/或,根据所述积分信息生成替换请求,将所述替换请求发送到所述交互网络,以获取相应的物品。
第三发送模块,还用于向服务器上传第二用户描述信息,以使服务器根据所述第二用户描述信息设置搜书第二用户对应的标签;其中,所述标签包括以下至少一种:物品类别标签、位置范围标签、邀约类型标签、用户关联标签、数量标签、用户属性标签、来源标签、接收类别标签。
综上所述,发送端根据第一智能厨电设备的设备状态和第一用户的需求信息生成邀约请求,然后将邀约请求发送给服务器,该发送端包括:第一用户关联的设备,所述第一用户关联的设备包括第一智能厨电设备,服务器进行接收端的决策,即根据邀约请求确定推送的接收端,将邀约请求发送给相应的接收端,该接收端包括第二用户关联的设备,根据对所述邀约请求的触发生成响应信息反馈服务器,服务器将响应信息发送给所述发送端,从而通过服务器执行不同用户间的数据交互,并且能够有效地利用第一用户和第二用户的设备资源,提高资源利用率。
本申请实施例还提供了一种非易失性可读存储介质,该存储介质中存储有一个或多个模块(programs),该一个或多个模块被应用在终端设备时,可以使得该终端设备执行本申请实施例中各方法步骤的指令(instructions)。
图12为本申请一实施例提供的计算设备的硬件结构示意图,该计算设备包括服务器和智能终端,该智能终端采用上述实施例所述的各种智能终端,包括第一用户关联的设备和第二用户关联的设备。如图12所示,该计算设备可以包括输入设备60、处理器61、输出设备62、存储器63和至少一个通信总线64。通信总线64用于实现元件之间的通信连接。存储器63可能包含高速RAM存储器,也可能还包括非易失性存储NVM,例如至少一个磁盘存储器,存储器63中可以存储各种程序,用于完成各种处理功能以及实现本实施例的方法步骤。
可选的,上述处理器61例如可以为中央处理器(Central Processing Unit,简称CPU)、应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现,该处理器61通过有线或无线连接耦合到上述输入设备60和输出设备62。
可选的,上述输入设备60可以包括多种输入设备,例如可以包括面向用户的用户接口、面向设备的设备接口、软件的可编程接口、摄像头、扫码器、触摸屏、音频输入设备、射频阅读器、热力感应设备中至少一种。可选的,该面向设备的设备接口可以是用于设备与设备之间进行数据传输的有线接口、还可以是用于设备与设备之间进行数据传输的硬件插入接口(例如USB接口、串口等);可选的,该面向用户的用户接口例如可以是面向用户的控制按键、用于接收语音输入的语音输入设备以及用户接收用户触摸输入的触摸感知设备(例如具有触摸感应功能的触摸屏、触控板等);可选的,上述软件的可编程接口例如可以是供用户编辑或者修改程序的入口,例如芯片的输入引脚接口或者输入接口等;可选的,上述收发信机可以是具有通信功能的射频收发芯片、基带处理芯片以及收发天线等。麦克风等音频输入设备可以接收语音数据,射频阅读器等可以通过RFID方式对电子标签进行识别,摄像头等图像采集设备可以拍摄图像识别二维码等,扫码器等扫描输入设备可以扫描条形码等。输出设备62包括显示器、音响等输出设备。所述显示器用于在显示界面显示提示信息、物品需求信息等。
在本实施例中,该计算设备的处理器包括用于执行上述识别确定模块、历史行为确定模块、需求确定模块、配方生成模块、请求生成模块、请求发送模块、显示模块的装置,具体功能和技术效果参照上述实施例即可,此处不再赘述。
图13为本申请另一实施例提供的计算设备的硬件结构示意图。图13是对图12在实现过程中的一个具体的实施例,例如可以为智能终端等。如图14所示,本实施例的计算设备包括处理器71以及存储器72。
处理器71执行存储器72所存放的计算机程序代码,实现上述实施例中图1至图7的数据交互方法。
存储器72被配置为存储各种类型的数据以支持在计算设备的操作。这些数据的示例包括用于在计算设备上操作的任何应用程序或方法的指令,例如信息,图片,视频等。存储器72可能包含随机存取存储器(random access memory,简称RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。
可选地,处理器71设置在处理组件70中。该计算设备还可以包括:通信组件73,电源组件74,多媒体组件75,音频组件76,输入/输出接口77,物品识别设备78。
处理组件70通常控制计算设备的整体操作。处理组件70可以包括一个或多个处理器71来执行指令,以完成上述图1至图7方法的全部或部分步骤。此外,处理组件70可以包括一个或多个模块,便于处理组件70和其他组件之间的交互。例如,处理组件70可以包括多媒体模块,以方便多媒体组件75和处理组件70之间的交互。
电源组件74为计算设备的各种组件提供电力。电源组件74可以包括电源管理系统,一个或多个电源,及其他与为计算设备生成、管理和分配电力相关联的组件。
多媒体组件75包括在计算设备和用户之间的提供一个输出接口的显示屏。在一些实施例中,显示屏可以包括液晶显示器(LCD)和触摸面板(TP)。如果显示屏包括触摸面板,显示屏可以被实现为触摸屏,以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界,而且还检测与所述触摸或滑动操作相关的持续时间和压力。多媒体组件75在确定用户和计算设备的距离满足第一阈值时,对所述推送信息进行提示。
音频组件76被配置为输出和/或输入音频信号。例如,音频组件76包括一个麦克风(MIC),当计算设备处于操作模式,如语音识别模式时,麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器72或经由通信组件73发送。在一些实施例中,音频组件76还包括一个扬声器,用于输出音频信号。
输入/输出接口77为处理组件70和外围接口模块之间提供接口,上述外围接口模块可以是点击轮,按钮等。这些按钮可包括但不限于:音量按钮、启动按钮和锁定按钮。
物品识别设备78包括一个或多个传感器,用于为计算设备提供各个方面的状态评估。例如,物品识别设备78可以检测到计算设备的打开/关闭状态,组件的相对定位,用户与计算设备接触的存在或不存在。物品识别设备78可以包括接近传感器,被配置用来在没有任何的物理接触时检测附近物体的存在,包括检测用户与计算设备间的距离。在一些实施例中,该物品识别设备78还可以包括摄像头、扫码器、触摸屏、音频输入设备、射频阅读器、热力感应设备中至少一种,从而物品识别设备78对所述智能计算设备中存储的物品进行识别。例如,物品识别设备78对音频组件76录入的语音数据进行识别,确定物品信息。
通信组件73被配置为便于计算设备和其他设备之间有线或无线方式的通信。计算设备可以接入基于通信标准的无线网络,如WiFi,2G或3G,或它们的组合。在一个实施例中,该计算设备中可以包括SIM卡插槽,该SIM卡插槽用于插入SIM卡,使得计算设备可以登录GPRS网络,通过互联网与服务器建立通信。
由上可知,在图13实施例中所涉及的通信组件73、音频组件76以及输入/输出接口77、物品识别设备78均可以作为图13实施例中的输入设备的实现方式。
其中,物品识别设备,对所述智能计算设备中存储的物品进行识别。可以通过上述图3对应的方法。
本申请实施例提供了一种服务器,处理器、通信组件;所述处理器,根据所述邀约请求确定接收端,所述邀约请求根据第一智能厨电设备的设备状态和第一用户的需求信息生成,所述发送端包括:第一用户关联的设备,所述第一用户关联的设备包括第一智能厨电设备;所述通信组件,耦合至所述处理器,接收发送端发送的邀约请求,将所述邀约请求发送给接收端,所述接收端包括第二用户关联的设备;以及,接收响应信息,将所述响应信息发送给所述发送端,所述响应信息根据对所述邀约请求的触发生成。
本申请实施例还提供了一种智能终端,包括:处理器、通信组件;作为发送端时,所述处理器,确定与第一厨房设备相关的需求信息,根据对所述需求信息的触发生成邀约请求,其中,所述发送端包括:第一用户关联的设备,所述第一用户关联的设备包括第一厨房设备;所述通信组件,耦合至所述处理器,将所述邀约请求发送给服务器;接收服务器反馈的响应信息。
作为接收端时,所述处理器,对邀约请求进行提示,根据对所述邀约请求的触发生成响应信息,所述邀约请求根据对需求信息的触发生成,所述接收端包括第二用户关联的设备;所述通信组件,耦合至所述处理器,从服务器接收邀约请求,将所述响应信息发送给服务器,以通过所述服务器反馈给发送端,所述发送端包括:第一用户关联的设备。
以智能冰箱作为智能终端为例,智能冰箱作为发送端时包括:处理器、通信组件;所述处理器,确定需求信息,根据对所述需求信息的触发生成邀约请求;所述通信组件,耦合至所述处理器,将所述邀约请求发送给服务器;接收服务器反馈的响应信息。
智能冰箱作为接收端时包括:处理器、通信组件;所述处理器,对邀约请求进行提示,根据对所述邀约请求的触发生成响应信息,所述邀约请求根据对需求信息的触发生成;所述通信组件,耦合至所述处理器,从服务器接收邀约请求,将所述响应信息发送给服务器,以通过所述服务器反馈。
本申请实施例还提供一种用于智能厨电设备的操作系统,如应用到智能冰箱、智能烤箱等厨电设备中,如图14所示,该操作系统包括:识别控制单元1402、管理单元1404和通信单元1406。
一个可选实施例中,作为发送端该操作系统中各单元如下:
识别控制单元1402,控制物品识别设备对智能厨电设备中存储的物品进行识别,以确定物品的设备状态。
管理单元1404,确定与第一厨房设备相关的需求信息,发送端根据对所述需求信息的触发生成邀约请求,其中,所述发送端包括:第一用户关联的设备,所述第一用户关联的设备包括第一厨房设备。
通信单元1406,将所述邀约请求发送给服务器;发送端接收服务器反馈的响应信息。
另一个可选实施例中,作为接收端该操作系统中各单元如下:
识别控制单元1402,控制物品识别设备对智能厨电设备中存储的物品进行识别,以确定物品的设备状态。
管理单元1404,对所述邀约请求进行提示,根据对所述邀约请求的触发生成响应信息,所述邀约请求根据对需求信息的触发生成,所述接收端包括第二用户关联的设备。
通信单元1406,接收端从服务器接收邀约请求;以及,将所述响应信息发送给服务器,以通过所述服务器反馈给发送端,所述发送端包括:第一用户关联的设备。
该操作系统具体处理过程与上述方法实施例类似,因此不再赘述。
本实施例提供的计算设备,可用于执行上述方法实施例中的各步骤,其实现原理和技术效果与上述实施例类似,本实施例此处不再赘述。
对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白,本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此,本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中,所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性厨电设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非持续性的电脑可读媒体(transitory media),如调制的数据信号和载波。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上,使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种数据交互方法、一种物品管理装置、一种智能厨电设备和一种用于智能厨电设备的操作系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,根据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。