一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

语音交互方法、设备、系统及存储介质与流程

2021-06-25 13:17:00 来源:中国专利 TAG:交互 语音 公开 方法 设备


1.本公开涉及语音交互领域,特别是涉及一种语音交互方法、设备、系统及存储介质。


背景技术:

[0002]“aiot”即“ai iot”,是人工智能技术与物联网在实际应用中的落地融合。目前,aiot作为各大传统行业智能化升级的最佳通道,已经成为物联网发展的必然趋势。
[0003]
随着语音交互技术的发展,以智能音箱为代表的语音交互设备逐渐走进人们的生活。语音交互设备作为aiot的连接中枢,正在释放巨大的潜力。在语音交互设备作为aiot的连接中枢连接其他设备(如物联网设备)时,如何使得语音交互设备端的用户能够成功及时地感知到语音交互设备所连接的其他设备端的事件信息,是目前亟需解决的一个问题。


技术实现要素:

[0004]
本公开的一个目的在于,提供一种能够使得语音交互设备端的用户能够成功及时地感知到语音交互设备所连接的其他设备端的事件信息的语音交互方案。
[0005]
根据本公开的第一个方面,提出了一种语音交互方法,适于语音交互设备执行,包括:响应于接收到第一设备发送的事件信息,判断所述第一设备是否为所述语音交互设备关联的设备;在所述第一设备不是所述语音交互设备关联的设备的情况下,将所述事件信息上传到服务器,以便所述服务器将所述事件信息发送给对应的语音交互设备,并且/或者在所述第一设备是所述语音交互设备关联的设备的情况下,输出音频数据。
[0006]
可选地,该方法还包括:响应于接收到第一设备发送的事件信息,向所述第一设备发送确认信息,其中,所述事件信息是由所述第一设备向组播地址范围内的语音交互设备发送的。
[0007]
可选地,所述输出音频数据的步骤包括:输出与所述事件信息所表征的事件相对应的音频数据。
[0008]
可选地,输出与所述事件信息所表征的事件相对应的音频数据的步骤包括:检查本地是否存在与所述事件信息所表征的事件相对应的音频数据;在本地存在与所述事件信息所表征的事件相对应的音频数据的情况下,播放所述音频数据,并且/或者在本地不存在与所述事件信息所表征的事件相对应的铃声的情况下,在线播放所述音频数据。
[0009]
可选地,该方法还包括:在在线播放所述音频数据之后,下载所述音频数据。
[0010]
可选地,该方法还包括:维护第一信息,所述第一信息包括与所述语音交互设备关联的第一设备的设备标识及其第一音频数据配置信息,所述第一音频数据配置信息包括一个或多个对应于预定事件的音频数据的统一资源定位符。
[0011]
可选地,该方法还包括:接收服务器下发的第二信息,所述第二信息包括一个或多个第一设备的设备标识、所述第一设备的功能使能位以及所述第一设备的第二音频数据配置信息,所述功能使能位用于表征所述第一设备的预定功能是否生效,所述第二音频数据
配置信息包括一个或多个对应于预定事件的音频数据的统一资源定位符;基于所述第二信息,对所述第一信息进行更新。
[0012]
可选地,基于所述第二信息对所述第一信息进行更新的步骤包括:在所述第二信息中的第一设备的功能使能位为使失效的情况下,将所述第一信息中的该第一设备的设备标识及其第一音频数据配置信息删除;在所述第二信息中的第一设备的功能使能位为使生效的情况下,将该第一设备的设备标识及其第二音频数据配置信息添加到所述第一信息中,或者基于该第一设备的第二音频数据配置信息更新该第一设备的第一音频数据配置信息。
[0013]
可选地,所述输出音频数据的步骤包括:将所述事件信息上传到服务器;接收所述服务器下发的所述第一设备的第三音频数据,所述第三音频数据包括与所述事件信息所表征的事件相对应的音频数据的统一资源定位符;以及在本地存在与所述统一资源定位符对应的音频数据的情况下,播放所述音频数据,并且/或者在本地不存在与所述事件信息所表征的事件相对应的音频数据的情况下,基于所述统一资源定位符在线播放所述音频数据。
[0014]
根据本公开的第二个方面,还提出了一种语音交互方法,适于智能音箱执行,包括:响应于接收到无线按钮发送的用于表征用户针对所述无线按钮的触控操作的事件信息,判断所述无线按钮是否为所述智能音箱关联的设备;在所述无线按钮不是所述智能音箱关联的设备的情况下,将所述事件信息上传到服务器,以便所述服务器将所述事件信息发送给对应的智能音箱,并且/或者在所述无线按钮是所述语音交互设备关联的设备的情况下,输出与所述事件信息所表征的触控操作相对应的铃声。
[0015]
根据本公开的第三个方面,还提出了一种语音交互方法,适于第一设备执行,包括:向组播地址范围内的语音交互设备发送事件信息;响应于接收到来自所述语音交互设备的确认信息,不再发送所述事件信息,并且/或者响应于超过预定时长未接收到来自所述语音交互设备的确认信息,再次向所述组播地址范围内的语音交互设备发送所述事件信息。
[0016]
可选地,所述第一设备为无线按钮,所述语音交互设备为智能音箱,所述事件信息用于表征用户针对所述无线按钮的触控操作。
[0017]
根据本公开的第四个方面,还提出了一种语音交互方法,适于服务器执行,包括:响应于接收到语音交互设备发送的来自与所述语音交互设备不关联的第一设备的事件信息,将所述事件信息发送给与所述第一设备相关联的语音交互设备,所述事件信息是由所述第一设备向组播地址范围内的语音交互设备发送的。
[0018]
可选地,该方法还包括:将所述事件信息所表征的事件相对应的音频数据的统一资源定位符发送给与所述第一设备相关联的语音交互设备。
[0019]
可选地,该方法还包括:响应于接收到语音交互设备发送的来自与所述语音交互设备关联的第一设备的事件信息,将所述事件信息所表征的事件相对应的音频数据的统一资源定位符发送给该语音交互设备。
[0020]
可选地,该方法还包括:向语音交互设备发送第二信息,所述第二信息包括与所述语音交互设备关联的第一设备的设备标识、所述第一设备的功能使能位以及所述第一设备的第二音频数据配置信息,所述功能使能位用于表征所述第一设备的预定功能是否生效,所述第二音频数据配置信息包括一个或多个对应于预定事件的音频数据的统一资源定位
符。
[0021]
可选地,所述第一设备为无线按钮,所述语音交互设备为智能音箱,所述事件信息用于表征用户针对所述无线按钮的触控操作。
[0022]
根据本公开的第五个方面,还提出了一种语音交互方法,包括:在同一位置或同一位置附近设置多个无线按钮,每个所述无线按钮对应至少一个语音交互设备,不同按钮所对应的语音交互设备位于不同房间;所述无线按钮响应于用户的触控操作,向组播地址范围内的语音交互设备发送事件信息;响应于接收到来自所述语音交互设备的确认信息,不再发送所述事件信息,并且/或者响应于超过预定时长未接收到来自所述语音交互设备的确认信息,再次向所述组播地址范围内的语音交互设备发送所述事件信息。
[0023]
根据本公开的第六个方面,还提出了一种语音交互方法,包括:设置多个无线按钮,每个所述无线按钮对应至少一个语音交互设备,不同按钮所对应的语音交互设备属于不同用户;所述无线按钮响应于用户的触控操作,向组播地址范围内的语音交互设备发送事件信息;响应于接收到来自所述语音交互设备的确认信息,不再发送所述事件信息,并且/或者响应于超过预定时长未接收到来自所述语音交互设备的确认信息,再次向所述组播地址范围内的语音交互设备发送所述事件信息。
[0024]
根据本公开的第七个方面,还提出了一种语音交互方法,包括:在餐桌上设置至少一个无线按钮,所述无线按钮与一个或多个语音交互设备相关联;所述无线按钮响应于用户的触控操作,向组播地址范围内的语音交互设备发送事件信息;响应于接收到来自所述语音交互设备的确认信息,不再发送所述事件信息,并且/或者响应于超过预定时长未接收到来自所述语音交互设备的确认信息,再次向所述组播地址范围内的语音交互设备发送所述事件信息。
[0025]
根据本公开的第八个方面,还提出了一种语音交互设备,包括:接收模块;判断模块,用于响应于所述接收模块接收到第一设备发送的事件信息,判断所述第一设备是否为所述语音交互设备关联的设备;发送模块,用于在所述第一设备不是所述语音交互设备关联的设备的情况下,将所述事件信息上传到服务器,以便所述服务器将所述事件信息发送给对应的语音交互设备,和/或输出模块,用于在所述第一设备是所述语音交互设备关联的设备的情况下,输出音频数据。
[0026]
根据本公开的第九个方面,还提出了一种智能音箱,包括:接收模块;判断模块,用于响应于所述接收模块接收到无线按钮发送的用于表征用户针对所述无线按钮的触控操作的事件信息,判断所述无线按钮是否为所述智能音箱关联的设备;发送模块,用于在所述无线按钮不是所述智能音箱关联的设备的情况下,将所述事件信息上传到服务器,以便所述服务器将所述事件信息发送给对应的智能音箱,和/或输出模块,用于在所述无线按钮是所述语音交互设备关联的设备的情况下,输出与所述事件信息所表征的触控操作相对应的铃声。
[0027]
根据本公开的第十个方面,还提出了一种第一设备,包括:接收模块;发送模块,用于向组播地址范围内的语音交互设备发送事件信息,响应于所述接收模块接收到来自所述语音交互设备的确认信息,所述发送模块不再发送所述事件信息,并且/或者响应于所述接收模块超过预定时长未接收到来自所述语音交互设备的确认信息,所述发送模块再次向所述组播地址范围内的语音交互设备发送所述事件信息。
[0028]
根据本公开的第十一个方面,还提出了一种无线按钮,包括:接收模块;发送模块,用于响应于用户针对所述无线按钮的触控操作,向组播地址范围内的智能音箱发送用于表征所述触控操作的事件信息,响应于所述接收模块接收到来自所述智能音箱的确认信息,所述发送模块不再发送所述事件信息,并且/或者响应于所述接收模块超过预定时长未接收到来自所述智能音箱的确认信息,所述发送模块再次向所述组播地址范围内的智能音箱发送所述事件信息。
[0029]
根据本公开的第十二个方面,还提出了一种服务器,包括:接收模块;发送模块,用于响应于所述接收模块接收到语音交互设备发送的来自与所述语音交互设备不关联的第一设备的事件信息,将所述事件信息发送给与所述第一设备相关联的语音交互设备,其中所述事件信息是由所述第一设备向组播地址范围内的语音交互设备发送的。
[0030]
根据本公开的第十三个方面,还提出了一种语音交互系统,包括:一个或多个语音交互设备、一个或多个第一设备以及服务器,所述第一设备向组播地址范围内的智能音箱发送事件信息,所述语音交互设备响应于接收到所述事件信息,向所述第一设备发送确认信息,并判断所述第一设备是否为所述语音交互设备关联的设备,在所述第一设备不是所述语音交互设备关联的设备的情况下,将所述事件信息上传到服务器,所述服务器将所述事件信息发送给对应的语音交互设备,并且/或者在所述第一设备是所述语音交互设备关联的设备的情况下,输出音频数据。
[0031]
根据本公开的第十四个方面,还提出了一种计算设备,包括:处理器;以及存储器,其上存储有可执行代码,当可执行代码被处理器执行时,使处理器执行如本公开第一个方面至第七个方面中任何一个方面述及的方法。
[0032]
根据本公开的第十五个方面,还提出了一种非暂时性机器可读存储介质,其上存储有可执行代码,当可执行代码被电子设备的处理器执行时,使处理器执行如本公开第一个方面至第七个方面中任何一个方面述及的方法。
[0033]
在本公开的示例性实施例中,第一设备可以使用组播的方式向组播地址范围内的语音交互设备发送事件信息。语音交互设备在接收到来自不是与其关联的第一设备的事件信息的情况下,可以将事件信息上传到服务器,由服务器将事件信息转发给对应的语音交互设备,由此可以提高第一设备发送的事件信息被其关联的语音交互设备接收到的成功率。
附图说明
[0034]
通过结合附图对本公开示例性实施方式进行更详细的描述,本公开的上述以及其它目的、特征和优势将变得更加明显,其中,在本公开示例性实施方式中,相同的参考标号通常代表相同部件。
[0035]
图1示出了根据本公开一实施例的语音交互系统的结构示意图。
[0036]
图2示出了根据本公开一实施例的的语音交互系统的工作流程示意图。
[0037]
图3示出了无线按钮和智能音箱间的绑定关系示意图。
[0038]
图4示出了根据本公开一实施例的按钮和音箱间的工作流程示意图。
[0039]
图5示出了本公开应用于合租场景下的原理示意图。
[0040]
图6示出了本公开应用于点餐场景下的原理示意图。
[0041]
图7示出了根据本公开一实施例的语音交互设备的结构示意图。
[0042]
图8示出了根据本公开一实施例的智能音箱的结构示意图。
[0043]
图9示出了根据本公开一实施例的第一设备的结构示意图。
[0044]
图10示出了根据本公开一实施例的无线按钮的结构示意图。
[0045]
图11示出了根据本公开一实施例的服务器的结构示意图。
[0046]
图12示出了根据本公开一实施例的计算设备的结构示意图。
具体实施方式
[0047]
下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式,然而应该理解,可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。
[0048]
图1示出了根据本公开一实施例的语音交互系统的结构示意图。
[0049]
如图1所示,语音交互系统10包括一个或多个语音交互设备100、一个或多个第一设备200以及服务器300。
[0050]
语音交互设备100是指能够提供语音交互功能的终端设备,如可以是但不限于智能音箱。
[0051]
服务器300是指与语音交互设备100对应的服务端,用于与语音交互设备100交互数据。
[0052]
第一设备200可以是但不限于无线按钮、智能插座、智能开关、智能灯泡、智能遥控等物联网设备。本公开中使用的“第一”、“第二”等用语仅用于进行区分描述,并不用于限定先后顺序、主次等级、重要程度等。
[0053]
第一设备200能够与语音交互设备100绑定(也即关联)。第一设备200与语音交互设备100进行绑定的具体实现方式,不是本公开的侧重点,此处仅做示例性说明。作为示例,可以利用手机、ipad等设备上运行的app关联语音交互设备100,并可以在该app中为语音交互设备100添加一个或多个第一设备200,以将第一设备200与语音交互设备100关联。
[0054]
第一设备200可以用于实现特定功能,并向语音交互设备100发送事件信息,然后通过与其关联的语音交互设备100的音频输出功能使得语音交互设备100端的用户能够感知到该事件信息所表征的事件,以便用户在需要的情况下执行后续相应的处理操作。
[0055]
事件信息所表征的事件可以是指需要用户知晓或处理的事件。事件信息所表征的事件的具体类别与第一设备200提供的功能相关。例如,第一设备200可以是指用于充当门铃的无线按钮,事件信息所表征的事件可以是指访客针对无线按钮执行的触控操作(如短按、长按、短时间内的多次按等等),也即按门铃事件。再例如,第一设备200也可以是智能插座,事件信息所表征的事件可以是指智能插座的开启事件或关闭事件。
[0056]
语音交互设备100在接收到其关联的第一设备200发送的事件信息后,可以以音频播放的形式向用户通知该事件信息所表征的事件,以便于用户能够及时感知该事件。
[0057]
然而在实际应用中,第一设备200和其关联的语音交互设备100间的距离可能较远,第一设备200的信号发射范围以及语音交互设备100的信号接收范围有限,并且语音交互设备100和与其绑定的第一设备200之间还存在着墙壁等遮挡因素,使得第一设备200发
送的事件信息不一定能被语音交互设备100成功接收到。
[0058]
针对于此,本公开提出,第一设备200可以使用组播的方式向组播地址范围内的语音交互设备100发送事件信息。语音交互设备100在接收到来自不是与其关联的第一设备的事件信息的情况下,可以将事件信息上传到服务器300,由服务器300将事件信息转发给对应的语音交互设备,由此可以提高第一设备200发送的事件信息被其关联的语音交互设备成功接收到的概率(即成功率)。
[0059]
下面结合图2就本公开的语音交互系统的工作流程做进一步说明。
[0060]
图2示出了根据本公开的语音交互系统的工作流程示意图。
[0061]
第一设备端执行的操作
[0062]
第一设备200可以执行步骤s210,向组播地址范围内的语音交互设备发送(也即广播)事件信息。
[0063]
此处述及的组播地址可以包括多个语音交互设备的地址,并且这多个语音交互设备不仅可以包括与第一设备200关联的语音交互设备,还可以包括与第一设备200不关联的语音交互设备。
[0064]
换言之,在多语音交互设备场景下,对于没有与第一设备200绑定的语音交互设备,第一设备200也可以向其发送事件信息,以使得第一设备200发送的事件信息能够尽可能地被场景中存在的语音交互设备接收到。
[0065]
第一设备200与语音交互设备100间可以基于物联网实现通信。关于第一设备200与语音交互设备100间的通信的具体实现方式以及组播传输的实现原理,本公开不再赘述。
[0066]
语音交互设备100可以被配置为,响应于接收到第一设备发送的事件信息,向第一设备200返回用于表征已经接收到事件信息的确认信息。确认信息也即针对接收到的事件信息的应答信息,关于确认信息的具体内容,本公开不做限定,例如确认信息可以是一个空包。
[0067]
第一设备200响应于接收到确认信息,可以执行步骤s220,不再发送事件信息,也即不再重传事件信息。
[0068]
第一设备200如果超过预定时长未接收到确认信息,则可以再次执行步骤s210,重新发送事件信息。
[0069]
在具有多个语音交互设备100的应用场景中,所有语音交互设备100可以默认都订阅了第一设备200的组播地址,在第一设备200使用组播地址广播事件信息的过程中,只要有一个语音交互设备100接收到事件信息,第一设备200就不再重传事件信息,由此可以降低第一设备200的功耗。
[0070]
相比之下,如果第一设备采用单播地址的传输方式,那么则可能因为第一设备200所绑定的语音交互设备100距离较远,导致语音交互设备100接收不到事件信息,同时因为距离远,语音交互设备100也无法回复确认信息给第一设备200,使得第一设备200会持续较长时间执行事件信息的重传,对第一设备200的整机功耗也不利。
[0071]
语音交互设备端执行的操作
[0072]
响应于接收到第一设备发送的事件信息,语音交互设备100可以执行步骤s105和步骤s110,关于步骤s105和步骤s110间的先后执行顺序,本公开不做限定。
[0073]
在步骤s105,向第一设备200发送确认信息。关于确认信息可以参见上文相关描
述,此处不再赘述。
[0074]
在步骤s110,判断发送事件信息的第一设备是否为语音交互设备关联的设备。
[0075]
语音交互设备100端可以存储其关联的第一设备的设备标识,设备标识可以是指但不限于设备识别码、设备地址。第一设备200发送的事件信息中也可以包括第一设备200的设备标识。语音交互设备100可以将事件信息中的设备标识与其存储的设备标识进行比对,以判断发送事件信息的第一设备200是否为语音交互设备100关联的设备。
[0076]
在第一设备200不是语音交互设备100关联的设备的情况下,语音交互设备100可以执行步骤s120,将事件信息上传到服务器300,以便服务器300将事件信息发送给对应的语音交互设备。由此可以提高第一设备发送的事件信息到达对应的语音交互设备的成功率。
[0077]
在第一设备200是语音交互设备100关联的设备的情况下,语音交互设备100可以执行步骤s130,输出音频数据。
[0078]
如上文所述,本公开述及的事件信息所表征的事件可以是指需要语音交互设备100端的用户知晓或处理的事件。因此语音交互设备100可以通过输出音频数据的方式,使用户感知到事件信息所表征的事件。其中语音交互设备100输出的音频数据可以是语音数据,也可以是非语音数据。
[0079]
以第一设备200为用于充当门铃的无线按钮为例,语音交互设备100(如智能音箱)在接收到来自其关联的第一设备200发送的用于表征门铃被按的事件信息的情况下,语音交互设备100可以以语音播放的形式输出诸如“主人,有客人敲门”、“主人快看看门外是谁”等内容的提示语音,也可以输出预先为无线按钮配置的诸如“滴答滴答滴~”的铃声。另外,语音交互设备100还可以输出诸如“主人,有客来访,是否开门”的用于提示用户做出指令的提示语音。
[0080]
以第一设备200为安装在孩子屋内的智能插座为例,智能插座可以与位于家长屋内的语音交互设备100(如智能音箱)绑定,智能插座可以被配置为响应于开关状态切换事件(即由开启状态切换为关闭状态的事件,或由关闭状态切换为开启状态的事件)发送用于表征状态切换事件的事件信息,语音交互设备100在接收到来自其关联的智能插座发送的事件信息后,可以以语音播放的形式输出诸如“您孩子屋里的智能插座被打开了”、“您孩子屋里的智能插座被关闭了”等内容的提示语音;另外语音交互设备100也可以输出非语音形式的提示音,以表征智能插座的开关状态切换事件,其中不同状态的切换事件可以对应不同的提示音,例如由开启到关闭状态的提示音可以是节奏较为平缓的“滴答滴答滴~”,由关闭到开启状态的提示音可以是节奏较为紧凑的“滴滴滴~”。
[0081]
第一设备200可以发送多种事件的事件信息,针对不同事件的事件信息,语音交互设备100可以输出不同的音频数据。也即,语音交互设备100可以输出与事件信息所表征的事件相对应的音频数据。
[0082]
语音交互设备100在接收到其关联的第一设备的事件信息后,可以检查本地是否存在与事件信息所表征的事件相对应的音频数据,在本地存在与事件信息所表征的事件相对应的音频数据的情况下,可以直接播放音频数据,并且/或者在本地不存在与事件信息所表征的事件相对应的铃声的情况下,可以在线播放音频数据。可选地,在在线播放音频数据之后,还可以下载音频数据,如可以在随机延迟一段时间后下载音频数据,如此在后续需要
播放该音频数据时,可以直接本地播放,提高音频播放速度。
[0083]
为了使得语音交互设备100能够确定需要输出何种音频数据,语音交互设备100还可以针对其关联的第一设备维护第一音频数据配置信息,第一音频数据配置信息包括一个或多个对应于预定事件的音频数据的统一资源定位符(url),其中url是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示,是互联网上标准资源的地址。例如,针对语音交互设备100关联的某个第一设备维护的第一音频数据配置信息的形式可以是{第一设备的设备标识,对应事件1的音频数据的url,对应事件2的音频数据的url,对应事件3的音频数据的url
……
}。
[0084]
用户可以对第一设备200的事件所对应的音频数据进行动态配置,确定每种事件所对应的音频数据。例如,用户可以利用手机、ipad等设备上运行的app,对第一设备200的音频数据进行配置,以确定每种事件所对应的音频数据。
[0085]
在用户配置完成后,服务器300可以将第一设备200的设备标识及其音频数据配置信息下发给第一设备200所关联的语音交互设备100,以便语音交互设备100对其维护的音频数据配置信息进行更新。
[0086]
作为示例,语音交互设备100可以维护第一信息,第一信息包括与语音交互设备100关联的第一设备的设备标识及其第一音频数据配置信息。其中设备标识、第一音频数据配置信息可以是从服务器300获取的,也可以是通过其他方式获取的。
[0087]
语音交互设备100可以接收服务器下发的第二信息,第二信息包括一个或多个第一设备的设备标识、第一设备的功能使能位以及第一设备的第二音频数据配置信息,功能使能位用于表征第一设备的预定功能是否生效,第二音频数据配置信息包括一个或多个对应于预定事件的音频数据的统一资源定位符。例如,第二信息的形式可以是{第一设备的设备标识,功能使能位,对应事件1的音频数据的url,对应事件2的音频数据的url,对应事件3的音频数据的url
……
}。
[0088]
语音交互设备100可以基于第二信息,对第一信息进行更新。
[0089]
在第二信息中的第一设备的功能使能位为使失效(disabled)的情况下,可以表示第一设备与语音交互设备解绑,也可以表示第一设备的某项功能与语音交互设备解绑,此时语音交互设备100可以将第一信息中的该第一设备的设备标识及其第一音频数据配置信息删除。
[0090]
在第二信息中的第一设备的功能使能位为使生效的情况下,可以表示第一设备与语音交互设备绑定,或者也可以表示第一设备的某项功能与语音交互设备绑定,此时在第一信息中没有该第一设备的音频数据配置信息的情况下,语音交互设备100可以将该第一设备的设备标识及其第二音频数据配置信息添加到第一信息中,或者在第一信息中存在该第一设备的音频数据配置信息的情况下,语音交互设备100可以基于该第一设备的第二音频数据配置信息更新该第一设备的第一音频数据配置信息。
[0091]
在本公开的一个实施例中,语音交互设备100在首次接收到其关联的第一设备发送的事件信息时,虽然语音交互设备100中可能存储有第一设备的第一音频数据配置信息,但是音频数据还未下载到本地缓存中,无法本地播放。因此语音交互设备100可以将事件信息上传到服务器,接收服务器下发的第一设备的第三音频数据,第三音频数据包括与事件信息所表征的事件相对应的音频数据的统一资源定位符,以再次确认事件信息所表征的事
件相对应的音频数据的统一资源定位符。然后可以再次判断本地是否存在与该统一资源定位符对应的音频数据。在本地存在与统一资源定位符对应的音频数据的情况下,播放音频数据,并且/或者在本地不存在与事件信息所表征的事件相对应的音频数据的情况下,基于统一资源定位符在线播放音频数据。
[0092]
服务器端执行的操作
[0093]
服务器300可以接收语音交互设备100发送的事件信息。
[0094]
在该事件信息是来自与语音交互设备100不关联的第一设备的情况下,服务器300可以将该事件信息发送给与第一设备相关联的语音交互设备。可选地,服务器300还可以将事件信息所表征的事件相对应的音频数据的统一资源定位符发送给与第一设备相关联的语音交互设备。
[0095]
在该事件信息是来自与语音交互设备100关联的第一设备的情况下,服务器300可以将该事件信息所表征的事件相对应的音频数据的统一资源定位符发送给该语音交互设备。
[0096]
服务器300可以向语音交互设备发送第二信息,第二信息包括与语音交互设备关联的第一设备的设备标识、第一设备的功能使能位以及第一设备的第二音频数据配置信息,功能使能位用于表征第一设备的预定功能是否生效,第二音频数据配置信息包括一个或多个对应于预定事件的音频数据的统一资源定位符。其中,服务器300可以响应于响应于用户的将第一设备与语音交互设备进行关联或解除关联的操作,或者响应于用户的对第一设备的事件所对应的音频数据进行修改的操作,向语音交互设备发送第二信息。
[0097]
在本公开中,单个语音交互设备100可以关联多个第一设备200,单个第一设备200也可以关联多个语音交互设备100。并且同一第一设备200在关联不同语音交互设备时,可以针对不同语音交互设备定制不同的音频数据配置信息。
[0098]
应用场景一
[0099]
下面以上文述及的第一设备200为充当门铃的无线按钮,语音交互设备100为智能音箱为例做进一步示例性说明。
[0100]
图3示出了无线按钮和智能音箱间的绑定关系示意图。
[0101]
如图3所示,本公开可以满足“多个智能音箱”同时绑定“多个无线按钮”的应用场景。例如无线按钮1可以同时绑定“一楼的音箱a”和“二楼的音箱b”,这样用户按下无线按钮1时,一楼的音箱a和二楼的音箱b可以同时响起铃声,满足不同音箱位置的用户都知悉门铃按键事件。
[0102]
此外音箱c也可以同时绑定“无线按钮#1”和“无线按钮2”,这样用户只需要按下“无线按钮#1”或者“无线按钮#2”,音箱c都可以播放铃声,满足不同按钮位置的用户都可以按门铃通知音箱播放铃声的需求。
[0103]
图4示出了根据本公开一实施例的按钮和音箱间的工作流程示意图。其中,图4示出的云端可以视为智能音箱的云服务中心。
[0104]
本实施例中按钮和音箱间的工作流程如下。
[0105]
1.音箱a和按钮1绑定。关于音箱和按钮的绑定方式,不是本公开的侧重点,此处不再赘述。例如用户可以通过与音箱关联的智能设备(如手机)上的app来绑定一个或多个按钮,如可以在一个应用界面上为音箱配置一个或多个按钮。
[0106]
2.云端给音箱a下发<按钮1,铃声url>的绑定信息,其中绑定信息可以包含{按钮1地址,门铃功能使能位,按键短按的铃声url,按键长按的铃声url
……
}。
[0107]
由此可以从音箱a的维度获取a下的所有<按钮,铃声url>的绑定信息,其中绑定信息格式如下{{按钮1地址,门铃功能使能位,按键短按的铃声url,按键长按的铃声url..}{按钮2地址,门铃功能使能位,按键短按的铃声url,按键长按的铃声url..}{按钮3地址,门铃功能使能位,按键短按的铃声url,按键长按的铃声url..}
……
}该绑定信息的设定不仅可以满足1个音箱对应多个按钮的应用场景,而且每个按钮在绑定不同音箱时,铃声url也可以定制。这种设计是4拓扑图中“多个智能音箱”同时绑定“多个无线按钮”的应用场景的基础。
[0108]
3.音箱b和按钮2绑定。
[0109]
4.云端给音箱b下发<按钮2,铃声url>的绑定信息,其中绑定信息可以包含{按钮2地址,门铃功能使能位,按键短按的铃声url,按键长按的铃声url
……
}。
[0110]
5.音箱a和按钮n绑定。
[0111]
6.云端给音箱a下发<按钮n,铃声url>的绑定信息,其中绑定信息可以包含{按钮n地址,门铃功能使能位,按键短按的铃声url,按键长按的铃声url
……
}。
[0112]
7.按钮1或者按钮n通过组播地址广播按键信息给周围所有的音箱,任何一个音箱收到该按键信息都会回复response信息(即上文述及的确认信息)给按钮。按钮成功收到音箱的response信息之后则停止重发该按键信息。
[0113]
在多个音箱的应用场景中,按钮组播上报的方案中只要周围订阅了该组播地址的任何一个音箱都可以收到该按键信息(音箱可以默认都订阅了按钮的组播地址),这样可以大幅提高按钮的按键信息的成功达成率。
[0114]
另外因为按钮采用组播地址的广播方式,因此多个音箱都可能回复response信息给按钮,此时按钮只要收到任何一个音箱回复的response,则停止重复发送按键信息,可以节约按钮的功耗。
[0115]
相比之下按钮如果采用单播地址的方式,那么则可能因为按钮的绑定音箱距离较远,收不到按键信息导致门铃不播放的问题,同时因为音箱距离远音箱也无法回复response信息给按钮,因此按钮会持续较长时间的按键信息重传,对按钮的整机功耗也不利。
[0116]
8.音箱a第一次收到按钮1的按键信息,虽然音箱a有<按钮1,铃声url>的绑定信息,但是铃声url还没有下载到本地缓存中,无法本地播放。因此音箱a上报按键信息给云端再次请求再次确认按钮1该按键信息对应的铃声url。
[0117]
9.云端给音箱a下发按钮1按键信息对应的铃声url。音箱a收到url时,再次确认url的铃声是否缓存到本地。如果已经缓存到本地,则直接播放,否则先播放线上url的铃声,之后随机等待若干时间后开始从url下载铃声音频到本地。当音箱a再次收到按钮1的按键信息时,回到第7步,直接从本地铃声音频文件快速播放。
[0118]
10.按钮2通过组播地址广播按键信息给周围所有的音箱,音箱a收到按钮2的按键信息。
[0119]
11.因为音箱a并不是按钮2的绑定音箱,因此音箱a的白名单中并没有<按钮2,铃声url>的绑定信息,因此音箱a直接透传按钮2的按键信息给云端。
[0120]
12.云端下发按钮2的按键信息以及铃声url给绑定音箱音箱b。音箱b判断按钮2确实在本地白名单中,再次判断本地是否已经缓存了该铃声音频文件,如果是,则直接本地快速播放。否则先播放线上url的铃声,之后随机等待若干时间后开始从url下载铃声音频到本地。当音箱b再次收到按钮2的按键信息时,直接从本地铃声音频文件快速播放。如果音箱b通过“云端下发”(按钮2->音箱a->云端转发->音箱b),以及“本地接收”(按钮2->音箱b),两条链路收到了按钮2的相同按键信息,那么音箱b可以进行去重处理,如可以根据接收时间进行去重。
[0121]
可以重复以上“新的按钮配对过程”或者“已配对的按钮按键播放铃声过程”。
[0122]
14.响应于用户在音箱对应的手机app中“解绑”按钮1,或者“取消按钮1的门铃功能”,云端可以推送<按钮1,铃声url>的绑定信息给音箱a,其中绑定信息可以包含{按钮1地址,门铃功能使能位“disabled”}。音箱a将按钮1从白名单中删除。
[0123]
15.音箱再次收到按钮1的按键信息时,因为本地白名单中没有按钮1的信息,则直接转发按键信息1给云端,满足“门铃之外”的功能需求。
[0124]
16.音箱b重启,再次联网成功。
[0125]
17.云端下发音箱b绑定的所有<按钮,铃声url>信息。音箱b更新本地白名单,重新获得本地快速播放铃声的能力。
[0126]
在本实施例中,云端给音箱a下发<按钮1,铃声url>的绑定信息时,音箱可以不立即开始下载铃声url的音频文件,而可以在第9步中,音箱收到按钮的按键信息之后才会下载音频文件。这么做的原因主要是避免用户在手机音箱app测连续误触发“修改铃声url”的动作,那么音箱可能会收到多次不同的<按钮1,铃声url>信息,从而开始多份url音频文件的下载。这不仅仅浪费了音箱端的网络带宽,而且下载下来的音频文件也许并不是用户最终选定的铃声音频,也浪费音箱的内存空间。
[0127]
在第9步中,音箱a收到铃声url后,并没有立即开始下载url的音频文件,而是在播放完url铃声再等待一个随机的时间(例如:2s random(0,1)的时间)之后才开始下载url音频文件。这么做主要是因为播放器在播放url音频时也需要通过网络缓存云端url的音频数据到内存中,此时如果再次并行的开启一个新的网络下载请求,那么会加剧网络的堵塞,导致播放器播放url铃声的延迟时间加长。因此我们选择在播放器的url播放结束之后再随机等待一段时间下载,成功的避开了网络拥堵,对网络带宽的复用率也更高。
[0128]
并且第9步中,因为音箱成功的将云端铃声url的音频文件缓存到了本地,所以音箱再次收到按钮的按键信息时,可以立即从本地播放铃声,避免了和云端的二次交互,也节省了播放器再次下载url播放带来的延迟体验。同时也支持音箱离线时的铃声播放需求。
[0129]
在第11步中,音箱a收到按钮2的按键信息时,因为白名单中没有按钮2的信息(因为用户没有将按钮2和音箱a绑定),直接转发按键信息给云端,再由云端转发按键信息给绑定的音箱b。该方案通过白名单和按钮组播地方相结合的方案,极大的提高了按钮按键信息的成功达成率。
[0130]
上述步骤2中,当音箱a收到云端下发的<按钮1,铃声url>的绑定信息时,也可以选择随机等待一段时间后下载铃声url的音频文件到本地,这样做的好处是第8步中,音箱第一次收到按钮1的按键信息时,即可立即从本地缓存中播放铃声了,从而满足用户在app中修改铃声后,音箱第一次收到的按钮按键信息也满足本地快速播放的需求。
[0131]
音箱会缓存云端的铃声url音频文件到本地,因此音箱在收到按钮按键信息时可以立即从本地播放铃声音频,这样用户几乎体验不到“按下按钮”到听到铃声之间的延迟,用户体验会比较好。因为云端的url音频文件缓存到本地,因此即使音箱在断网的情况下,也可以播放门铃铃声,达到离线响应按钮按键的需求。
[0132]
综上,本实施例可以实现智能音箱所连接的物联网设备的iot铃声本地快速播放。
[0133]
应用场景二
[0134]
本公开还可以应用于合租场景,为同一套房子中不同房间的租户提供门铃服务。具体来说,可以在同一位置或同一位置附近(如屋门外侧)设置多个无线按钮。每个无线按钮对应至少一个语音交互设备(如音箱),不同按钮所对应的语音交互设备位于不同房间。不同房间可以对应不同租户。由此,可以将无线按钮与租户绑定,无线按钮可以视为租户的门铃。
[0135]
可以用特定标记标识无线按钮所关联的房间号或者租户,例如可以在无线按钮上粘贴用于标识无线按钮所关联的房间号或者租户的贴纸。
[0136]
访客(如快递人员)可以通过对期望访问的租户所对应的无线按钮执行触控操作,促使对应房间内的语音交互设备输出相应的音频数据(如门铃声或提示语),以在不影响其他租户的前提下,告知目标租户。
[0137]
关于无线按钮、语音交互设备可以执行的操作可以参见上文相关描述,此处不再赘述。
[0138]
图5示出了本公开应用于合租场景下的原理示意图。
[0139]
如图5所示,房间1、房间2以及房间3可以是同一套房子中的不同卧室。不同房间可以住有不同租户。无线按钮1与租户a音箱绑定,无线按钮2与租户b音箱绑定,无线按钮3与租户c音箱绑定。无线按钮1、无线按钮2以及无线按钮3可以设置在房子的屋门外。
[0140]
以访客是为租户a提供配送服务的快递人员为例,快递人员可以按压与租户a对应的无线按钮1,无线按钮1可以以组播的方式向房间1、房间2以及房间3内的音箱发送门铃事件。
[0141]
音箱在接收到门铃事件后,可以判断门铃事件是否是其关联的无线按钮发送的。如果是,则输出音频数据,如果不是则将事件信息上传到服务器,以便服务器将事件信息发送给对应的音箱。
[0142]
由此,在不影响租户b、租户c的前提下,租户a可以感知到门铃事件。
[0143]
应用场景三
[0144]
与合租场景类似,本公开还可以应用于办公场景。可以设置多个无线按钮,每个无线按钮对应至少一个语音交互设备,不同按钮所对应的语音交互设备属于不同用户。即每个用户可以对应一个无线按钮。
[0145]
可以用特定标记标识无线按钮所关联的用户(如工作人员)。例如可以在无线按钮上粘贴用于标识无线按钮所关联的工作人员的代号的贴纸。
[0146]
多个无线按钮可以统一设置在某块区域。如此在需要和某员工沟通时,可以通过对期望沟通的员工所对应的无线按钮执行触控操作,促使对应员工的语音交互设备输出相应的音频数据(如震动、铃声或提示语),以告知该员工。
[0147]
关于无线按钮、语音交互设备可以执行的操作可以参见上文相关描述,此处不再
赘述。
[0148]
应用场景四
[0149]
本公开还可以应用于点餐场景,为就餐人员提供点餐服务。
[0150]
图6示出了本公开应用于点餐场景下的原理示意图。
[0151]
如图6所示,可以在每个餐桌上设置至少一个无线按钮,无线按钮与一个或多个语音交互设备相关联。其中,语音交互设备是指餐厅服务人员所使用的设备。
[0152]
就餐人员可以通过对餐桌上的无线按钮执行触控操作,促使服务人员所使用的语音交互设备输出相应的音频数据(如提示语),以呼叫服务人员进行点餐。
[0153]
关于无线按钮、语音交互设备可以执行的操作可以参见上文相关描述,此处不再赘述。
[0154]
图7示出了根据本公开一个实施例的语音交互设备的结构示意图。其中,语音交互设备的功能模块可以由实现本公开原理的硬件、软件或硬件和软件的结合来实现。本领域技术人员可以理解的是,图7所描述的功能模块可以组合起来或者划分成子模块,从而实现上述发明的原理。因此,本文的描述可以支持对本文描述的功能模块的任何可能的组合、或者划分、或者更进一步的限定。
[0155]
下面就语音交互设备可以具有的功能模块以及各功能模块可以执行的操作做简要说明,对于其中涉及的细节部分可以参见上文相关描述,这里不再赘述。
[0156]
如图7所示,语音交互设备500包括接收模块510、判断模块520、发送模块530和/或输出模块540。
[0157]
判断模块520用于响应于接收模块510接收到第一设备发送的事件信息,判断第一设备是否为语音交互设备关联的设备。
[0158]
发送模块530用于在第一设备不是语音交互设备关联的设备的情况下,将事件信息上传到服务器,以便服务器将事件信息发送给对应的语音交互设备。响应于接收到第一设备发送的事件信息,发送模块530还可以向第一设备发送确认信息,其中,事件信息可以是由第一设备向组播地址范围内的语音交互设备发送的。
[0159]
输出模块540用于在第一设备是语音交互设备关联的设备的情况下,输出音频数据。输出模块540可以输出与所述事件信息所表征的事件相对应的音频数据。
[0160]
输出模块540可以检查本地是否存在与所述事件信息所表征的事件相对应的音频数据,在本地存在与所述事件信息所表征的事件相对应的音频数据的情况下,播放所述音频数据,并且/或者在本地不存在与所述事件信息所表征的事件相对应的铃声的情况下,在线播放所述音频数据。
[0161]
语音交互设备500还可以包括下载模块,用于在在线播放所述音频数据之后,下载所述音频数据。
[0162]
语音交互设备500还可以包括为维护模块,用于维护第一信息,所述第一信息包括与所述语音交互设备关联的第一设备的设备标识及其第一音频数据配置信息,所述第一音频数据配置信息包括一个或多个对应于预定事件的音频数据的统一资源定位符。
[0163]
接收模块510还可以接收服务器下发的第二信息,所述第二信息包括一个或多个第一设备的设备标识、所述第一设备的功能使能位以及所述第一设备的第二音频数据配置信息,所述功能使能位用于表征所述第一设备的预定功能是否生效,所述第二音频数据配
置信息包括一个或多个对应于预定事件的音频数据的统一资源定位符;
[0164]
维护模块可以基于第二信息,对第一信息进行更新。其中在第二信息中的第一设备的功能使能位为使失效的情况下,维护模块将第一信息中的该第一设备的设备标识及其第一音频数据配置信息删除;在第二信息中的第一设备的功能使能位为使生效的情况下,维护模块将该第一设备的设备标识及其第二音频数据配置信息添加到第一信息中,或者基于该第一设备的第二音频数据配置信息更新该第一设备的第一音频数据配置信息。
[0165]
作为示例,在首次接收到语音交互设备关联的第一设备发送的事件信息后,可以由发送模块530将事件信息上传到服务器,由接收模块510接收服务器下发的第一设备的第三音频数据,第三音频数据包括与事件信息所表征的事件相对应的音频数据的统一资源定位符;输出模块540可以在本地存在与统一资源定位符对应的音频数据的情况下,播放音频数据,并且/或者在本地不存在与事件信息所表征的事件相对应的音频数据的情况下,基于统一资源定位符在线播放音频数据。
[0166]
图8示出了根据本公开一个实施例的智能音箱的结构示意图。其中,智能音箱的功能模块可以由实现本公开原理的硬件、软件或硬件和软件的结合来实现。本领域技术人员可以理解的是,图8所描述的功能模块可以组合起来或者划分成子模块,从而实现上述发明的原理。因此,本文的描述可以支持对本文描述的功能模块的任何可能的组合、或者划分、或者更进一步的限定。
[0167]
下面就智能音箱可以具有的功能模块以及各功能模块可以执行的操作做简要说明,对于其中涉及的细节部分可以参见上文相关描述,这里不再赘述。
[0168]
参见图8,智能音箱600包括接收模块610、判断模块620、发送模块630和/或输出模块640。
[0169]
判断模块620用于响应于接收模块610接收到无线按钮发送的用于表征用户针对无线按钮的触控操作的事件信息,判断无线按钮是否为智能音箱关联的设备。
[0170]
发送模块630用于在无线按钮不是智能音箱关联的设备的情况下,将事件信息上传到服务器,以便服务器将事件信息发送给对应的智能音箱。
[0171]
输出模块640用于在无线按钮是语音交互设备关联的设备的情况下,输出与事件信息所表征的触控操作相对应的铃声。其中触控操作可以包括但不限于短按、长按、短时间内多次按等等。
[0172]
关于智能音箱600可以执行的操作细节,可以参见上文相关描述,此处不再赘述。
[0173]
图9示出了根据本公开一个实施例的第一设备的结构示意图。其中,第一设备的功能模块可以由实现本公开原理的硬件、软件或硬件和软件的结合来实现。本领域技术人员可以理解的是,图9所描述的功能模块可以组合起来或者划分成子模块,从而实现上述发明的原理。因此,本文的描述可以支持对本文描述的功能模块的任何可能的组合、或者划分、或者更进一步的限定。
[0174]
下面就第一设备可以具有的功能模块以及各功能模块可以执行的操作做简要说明,对于其中涉及的细节部分可以参见上文相关描述,这里不再赘述。
[0175]
参见图9,第一设备700包括接收模块710和发送模块720。
[0176]
发送模块720用于向组播地址范围内的语音交互设备发送事件信息。
[0177]
响应于接收模块710接收到来自语音交互设备的确认信息,发送模块720不再发送
事件信息,并且/或者响应于接收模块710超过预定时长未接收到来自语音交互设备的确认信息,发送模块720再次向组播地址范围内的语音交互设备发送事件信息。
[0178]
图10示出了根据本公开一个实施例的无线按钮的结构示意图。其中,无线按钮的功能模块可以由实现本公开原理的硬件、软件或硬件和软件的结合来实现。本领域技术人员可以理解的是,图10所描述的功能模块可以组合起来或者划分成子模块,从而实现上述发明的原理。因此,本文的描述可以支持对本文描述的功能模块的任何可能的组合、或者划分、或者更进一步的限定。
[0179]
下面就无线按钮可以具有的功能模块以及各功能模块可以执行的操作做简要说明,对于其中涉及的细节部分可以参见上文相关描述,这里不再赘述。
[0180]
参见图10,无线按钮800包括接收模块810和发送模块820。
[0181]
发送模块820用于响应于用户针对无线按钮的触控操作,向组播地址范围内的智能音箱发送用于表征触控操作的事件信息。
[0182]
响应于接收模块810接收到来自智能音箱的确认信息,发送模块820不再发送事件信息,并且/或者响应于接收模块810超过预定时长未接收到来自智能音箱的确认信息,发送模块820再次向组播地址范围内的智能音箱发送事件信息。
[0183]
图11示出了根据本公开一个实施例的服务器的结构示意图。其中,服务器的功能模块可以由实现本公开原理的硬件、软件或硬件和软件的结合来实现。本领域技术人员可以理解的是,图11所描述的功能模块可以组合起来或者划分成子模块,从而实现上述发明的原理。因此,本文的描述可以支持对本文描述的功能模块的任何可能的组合、或者划分、或者更进一步的限定。
[0184]
下面就服务器可以具有的功能模块以及各功能模块可以执行的操作做简要说明,对于其中涉及的细节部分可以参见上文相关描述,这里不再赘述。
[0185]
参见图11,服务器900包括接收模块910和发送模块920。
[0186]
发送模块920用于响应于接收模块910接收到语音交互设备发送的来自与语音交互设备不关联的第一设备的事件信息,将事件信息发送给与第一设备相关联的语音交互设备,其中事件信息是由第一设备向组播地址范围内的语音交互设备发送的。可选地,发送模块920还可以将事件信息所表征的事件相对应的音频数据的统一资源定位符发送给与第一设备相关联的语音交互设备。
[0187]
发送模块920还可以响应于接收模块910接收到语音交互设备发送的来自与语音交互设备关联的第一设备的事件信息,将事件信息所表征的事件相对应的音频数据的统一资源定位符发送给该语音交互设备。
[0188]
发送模块920还可以向语音交互设备发送第二信息,第二信息包括与语音交互设备关联的第一设备的设备标识、第一设备的功能使能位以及第一设备的第二音频数据配置信息,功能使能位用于表征第一设备的预定功能是否生效,第二音频数据配置信息包括一个或多个对应于预定事件的音频数据的统一资源定位符。
[0189]
可选地,第一设备可以为无线按钮,语音交互设备可以为智能音箱,事件信息用于表征用户针对无线按钮的触控操作。
[0190]
图12示出了根据本发明一实施例可用于实现上述语音交互方法的计算设备的结构示意图。
[0191]
参见图12,计算设备1000包括存储器1010和处理器1020。
[0192]
处理器1020可以是一个多核的处理器,也可以包含多个处理器。在一些实施例中,处理器1020可以包含一个通用的主处理器以及一个或多个特殊的协处理器,例如图形处理器(gpu)、数字信号处理器(dsp)等等。在一些实施例中,处理器1020可以使用定制的电路实现,例如特定用途集成电路(asic,application specific integrated circuit)或者现场可编程逻辑门阵列(fpga,field programmable gate arrays)。
[0193]
存储器1010可以包括各种类型的存储单元,例如系统内存、只读存储器(rom),和永久存储装置。其中,rom可以存储处理器1020或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中,永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中,永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备,例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外,存储器1010可以包括任意计算机可读存储媒介的组合,包括各种类型的半导体存储芯片(dram,sram,sdram,闪存,可编程只读存储器),磁盘和/或光盘也可以采用。在一些实施方式中,存储器1010可以包括可读和/或写的可移除的存储设备,例如激光唱片(cd)、只读数字多功能光盘(例如dvd-rom,双层dvd-rom)、只读蓝光光盘、超密度光盘、闪存卡(例如sd卡、min sd卡、micro-sd卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。
[0194]
存储器1010上存储有可执行代码,当可执行代码被处理器1020处理时,可以使处理器1020执行上文述及的语音交互方法。
[0195]
上文中已经参考附图详细描述了根据本发明的语音交互方法、语音交互系统、语音交互设备、智能音箱、第一设备、无线按钮以及服务器。
[0196]
此外,根据本发明的方法还可以实现为一种计算机程序或计算机程序产品,该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。
[0197]
或者,本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质),其上存储有可执行代码(或计算机程序、或计算机指令代码),当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时,使所述处理器执行根据本发明的上述方法的各个步骤。
[0198]
本领域技术人员还将明白的是,结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。
[0199]
附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作
的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
[0200]
以上已经描述了本发明的各实施例,上述说明是示例性的,并非穷尽性的,并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择,旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进,或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文章

  • 日榜
  • 周榜
  • 月榜