CN107395583A - 基于自然语言实现不同应用之间通信的方法及装置 - Google Patents
基于自然语言实现不同应用之间通信的方法及装置 Download PDFInfo
- Publication number
- CN107395583A CN107395583A CN201710576455.1A CN201710576455A CN107395583A CN 107395583 A CN107395583 A CN 107395583A CN 201710576455 A CN201710576455 A CN 201710576455A CN 107395583 A CN107395583 A CN 107395583A
- Authority
- CN
- China
- Prior art keywords
- application
- natural language
- target information
- message
- supported
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/30—Semantic analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
Abstract
本发明实施例中，提出一种基于自然语言实现不同应用之间通信的方法：第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，并根据目标信息中的全部或者部分信息向第二应用发送消息；在该方案中，利用自然语言来获取与通信协议相关的目标信息，由于自然语言的通用性高，因此，即使第一应用未预先存储与第二应用所支持的通信协议相关的目标信息，也可以通过自然语言来获取与第二应用所支持的通信协议相关的目标信息，后续可以采用得到的目标信息来与第二应用通信，因此，可以解决现有技术中未预先存储相关应用的协议就无法与该类应用进行通信的缺陷，扩大了应用场景的范围。
Description
技术领域
本发明涉及通信技术领域，尤其涉及一种基于自然语言实现不同应用之间通信的方法及装置。
背景技术
随着科技的发展，应用程序的种类也越来越多，在很多情况下会遇到需要通过不同的应用之间进行数据传输的问题。目前常见的应用之间的数据传输方法主要包括如下几种：
一种为：通过一虚拟容器分别与两个不同的应用建立数据传输接口，然后第一应用中的数据通过对应的第一数据传输接口传入虚拟容器中，虚拟容器再通过与第二应用对应的第二数据传输接口将上述数据传到第二应用中。虽然该方案可以实现两个不同的应用间的数据传输，但是该方案需要预先建立虚拟容器的数据传输接口，如果没有预先建立，或者不知道应用与虚拟容器之间的接口，则无法实现两个不同的应用之间的数据传输；
另一种为：两个不同的应用在进行通信之前，第一应用先发起握手，该握手包括第一应用(主应用)的唯一标识符和用于标记和/或证明响应请求的第一随机数，第二应用可以利用已证明的第一应用的列表来核对所述唯一标识符，以验证第一应用。如果得到了验证，则第二应用利用所述第一随机数和第二随机数进行响应，其中，第二随机数可以标记和/或证明由第一应用发送的数据请求。但是该方案中如果两个不同的应用预先不知道该交互流程的相关信息，则两个应用之间也是无法进行数据传输的；
再一种为：两个不同的应用之间要进行数据传输时，将第一应用的数据传输格式转换成第二应用的数据传输格式，从而实现两个不同的应用之间的数据传输，但是这种方案中第一应用需要预先知道第二应用的数据传输格式，否则，二者之间仍然无法进行数据传输。
综上所述，现有的不同应用之间的通信传输方法依赖于要预先获取一些相关信息的基础上才能实现，否则无法实现不同应用之间的通信。
发明内容
鉴于上述问题，提出了本发明，以便提供一种克服上述问题或者至少部分地解决上述问题的一种不同应用之间通信的方法及装置，用于解决现有技术中存在的如果预先没有获取一些相关信息，则无法实现不同应用之间通信的缺陷。
依据本发明的第一方面，提供了一种基于自然语言实现不同应用之间通信的方法，包括：
第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息；
所述第一应用根据所述目标信息中的全部或者部分信息向所述第二应用发送消息。
在一个实施方式中，根据本发明的上述实施方式所述的方法，所述第一应用和所述第二应用均位于第一设备；或者
所述第一应用位于第一设备，所述第二应用位于第二设备。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用基于自然语言向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用接收所述第二应用返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述请求消息中携带指示协议标识；
所述第一应用接收所述第二应用返回的响应消息，包括：
所述第一应用接收所述第二应用根据所述指示协议标识返回的响应消息。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用接收所述第二应用基于自然语言返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用基于广播消息来获取所述第二应用发送的所述目标信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，第一应用向第二应用发送请求消息，包括：
所述第一应用接收用户发送的指令信息；
所述第一应用获得所述指令信息的语义分析结果；
所述第一应用确定与所述语义分析结果对应的请求消息，并将所述请求消息发送至所述第二应用。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述目标信息包括协议标识和/或协议定义信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述协议定义信息包括消息传输接口定义信息、消息的格式信息和信令流程信息中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述消息的格式信息包括数字编码格式；
其中，所述数字编码格式包括所述第二应用所能接收的数据的字段、长度、取值范围、数据类型中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述协议标识能够用表征信息来表征；
其中，所述表征信息包括所述第二应用的标识ID、所述第二应用的类型、所述第二应用的版本号和与所述第二应用相关的互联网协议IP地址、相关关键词中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述第一应用根据所述目标信息中的全部或者部分信息向所述第二应用发送消息，包括：
所述第一应用根据所述表征信息确定所述表征信息所对应的协议；
采用确定的协议向所述第二应用发送消息。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述第一应用根据所述表征信息确定所述表征信息所对应的协议，包括：
所述第一应用通过第三应用获取对应的协议信息；
其中，所述第三应用为互联网服务器、搜索引擎、自然语言交互引擎中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述第一应用根据所述目标信息中的全部或者部分信息向所述第二应用发送消息，包括：
所述第一应用判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议是否相匹配；
如果所述第一应用判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议相匹配，直接采用所述目标信息对应的协议向所述第二应用发送消息；
否则，所述第一应用返回基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息的步骤。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述自然语言为语音和/或文本。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述自然语言为文本时，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用基于图像获取模块获取以二维码、图像、文字标志中的至少一种形式程序的所述目标信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的方法，所述自然语言为语音时，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用基于超声波获取所述目标信息。
依据本发明的第二方面，提供了一种基于自然语言实现不同应用之间通信的装置，包括：
第一应用中的获取单元，用于基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息；
所述第一应用中的发送单元，用于根据所述目标信息中的全部或者部分信息向所述第二应用发送消息。
在一个实施方式中，根据本发明的上述实施方式所述的装置，所述第一应用和所述第二应用均位于第一设备；或者
所述第一应用位于第一设备，所述第二应用位于第二设备。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述发送单元还用于，基于自然语言向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用中的获取单元基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
接收所述第二应用返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述请求消息中携带指示协议标识；
所述获取单元接收所述第二应用返回的响应消息，包括：
接收所述第二应用根据所述指示协议标识返回的响应消息。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述发送单元还用于，向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用中的获取单元基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
接收所述第二应用基于自然语言返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述第一应用中的获取单元通过第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
基于广播消息来获取所述第二应用发送的所述目标信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述装置还包括接收单元和处理单元，其中：
所述接收单元，用于接收用户发送的指令信息；
所述处理单元，用于获得所述指令信息的语义分析结果；
所述发送单元向第二应用发送请求消息，包括：
确定与所述语义分析结果对应的请求消息，并将所述请求消息发送至所述第二应用。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述目标信息包括协议标识和/或协议定义信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述协议定义信息包括消息传输接口定义信息、消息的格式信息和信令流程信息中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述消息的格式信息包括数字编码格式；
其中，所述数字编码格式包括所述第二应用所能接收的数据的字段、长度、取值范围、数据类型中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述协议标识能够用表征信息来表征；
其中，所述表征信息包括所述第二应用的标识ID、所述第二应用的类型、所述第二应用的版本号和与所述第二应用相关的互联网协议IP地址、相关关键词中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述第一应用中的发送单元根据所述目标信息中的全部或者部分信息向所述第二应用发送消息，包括：
根据所述表征信息确定所述表征信息所对应的协议；
采用确定的协议向所述第二应用发送消息。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述发送单元根据所述表征信息确定所述表征信息所对应的协议，包括：
通过第三应用获取对应的协议信息；
其中，所述第三应用为互联网服务器、搜索引擎、自然语言交互引擎中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述第一应用中的发送单元根据所述目标信息中的全部或者部分信息向所述第二应用发送消息，包括：
判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议是否相匹配；
如果判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议相匹配，直接采用所述目标信息对应的协议向所述第二应用发送消息；
否则，返回基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息的步骤。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述自然语言为语音和/或文本。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述自然语言为文本时，所述第一应用中的获取单元基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
基于图像获取模块获取以二维码、图像、文字标志中的至少一种形式程序的所述目标信息。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述自然语言为语音时，所述第一应用中的获取单元基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
基于超声波获取所述目标信息。
依据本发明的第四方面，提供了一种基于自然语言实现不同应用之间通信的装置，包括：
第二应用中的接收单元，用于接收第一应用基于自然语言发送的请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；第二应用中的发送单元，用于向所述第一应用发送响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息；或者
所述第二应用中的接收单元，用于所述第二应用接收第一应用发送的请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；所述第二应用中的发送单元，用于基于自然语言向所述第一应用发送响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
在一个实施方式中，根据本发明的上述实施方式所述的装置，所述第一应用和所述第二应用均位于第一设备；或者
所述第一应用位于第一设备，所述第二应用位于第二设备。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述请求消息中携带指示协议标识；
所述第二应用中的发送单元向所述第一应用发送响应消息，包括：
所述第二应用中的发送单元根据所述指示协议标识向所述第一应用返回响应消息。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述目标信息包括协议标识和/或协议定义。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述协议定义信息包括消息传输接口定义信息、消息的格式信息和信令流程信息中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述消息的格式信息包括数字编码格式；
其中，所述数字编码格式包括所述第二应用所能接收的数据的字段、长度、取值范围、数据类型中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，协议标识能够用表征信息来表征；
其中，所述表征信息包括所述第二应用的标识ID、所述第二应用的类型、所述第二应用的版本号和与所述第二应用相关的互联网协议IP地址、相关关键词中的至少一种。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述第二应用中的发送单元在所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议不匹配时，继续向所述第一应用发送响应消息。
在一些实施方式中，根据本发明的上述任一实施方式所述的装置，所述自然语言为语音和/或文本。
依据本发明的第三方面，还提供一种电子设备，包括：
存储器以及一个或多个处理器；
其中，所述存储器与所述一个或多个处理器通信连接，所述存储器中存储有可被所述一个或多个处理器执行的指令，所述指令被所述一个或多个处理器执行，以使所述一个或多个处理器能够实现如上所述的方法。
在该方案中，利用自然语言来获取与通信协议相关的目标信息，由于自然语言的通用性高，因此，即使第一应用没有预先存储与第二应用所支持的通信协议相关的目标信息，也可以通过自然语言来获取与第二应用所支持的通信协议相关的目标信息，后续可以采用得到的目标信息来与第二应用通信，因此，可以解决现有技术中没有预先存储相关应用的协议就无法与该类应用进行通信的缺陷，扩大了应用场景的范围。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1是根据本发明的实施例提出的基于自然语言实现不同应用之间通信的一种流程图；
图2A是根据本发明的实施例提出的基于自然语言实现不同应用之间通信的另一种流程图；
图2B是根据本发明的实施例提出的基于自然语言实现不同应用之间通信的另一种流程图；
图3是根据本发明的实施例提出的基于自然语言实现不同应用之间通信的装置的示意图；
图4是根据本发明的实施例提出的基于自然语言实现不同应用之间通信的装置的另一种示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
下面先对本申请中可能涉及到的技术术语进行简单描述。
通信协议，是一种区别于自然语言形式进行通信的协议，包括通信双方定义的消息格式(包括消息编码格式，比如00001-表示关闭电视)、信令流程、消息信道定义(比如TCP(Transmission Control Protocol，传输控制协议)端口号等)，但是这些内容都是预先设定的。具体到本申请当中，通信协议还可以包括应用之间交互的消息的格式定义、应用之间消息交互的流程，也包括这些消息在物理层、传输层的数据格式和交互流程。
接口信息有时会等同于通信协议，可以替换使用，但是两者还是有区别的，例如，接口信息还可以包括硬件电气接口，这是不可协商的部分，通信协议则更多体现可协商性，因此，通信协议中一般不包括硬件电气接口信息。其中，接口信息包括接口类型、接口的定义和接口说明书等。
接口类型(以太接口、USB(Universal Serial Bus，通用串行总线)接口等)，一般包括硬件电气接口定义，以及基于该硬件接口上的消息定义、信令流程、设备行为等。对于预先设定的接口，一般由对应的通信协议支持，比如以太网接口，有对应的以太网协议。
接口的定义：包括硬件接口和协议接口，包括上述消息定义、信令流程、设备行为等。消息定义可以包括消息的数字编码格式。
接口说明书(也可叫做协议说明书)：包括消息定义、信令流程、设备行为等内容，可以与自然语言形式、表格、图表等任意形式呈现。
信令流程指的是双方交换的消息次序(procedure)。
数字编码格式指的是将信息数字化表示的方式，属于协议中可以约定的内容。比如，一个电视的“打开控制指令”可以用一个4bit的二进制来表示，如b0001，而这个4bit的二进制数据b0001由可以采用一定的信源编码或信道编码进行编码的方式就叫做数字编码格式，包括压缩。
下面对本发明实施例中所涉及到的应用之间的通信进行简单介绍。
Android手机的应用之间的通信：
使用handler传递消息
大家可以把handler想象成主线程(UI线程)的一个子线程，它可以给主线程(UI线程)发送数据从而更新主线程(UI线程)的UI与逻辑，handler是一个子线程所以它的耗时操作不会阻塞主线程，大家都知道在Android的开发中如果代码中某个地方阻塞主线程超过5秒的话，系统会提示ANR(系统提示强制关闭)，所以在耗时操作上我们可以考虑开启一个子线程避免ANR。handler会向主线程发送消息，以队列的形式排列着配合等待主线程更新UI逻辑，等等。
如，利用handler传递消息来更新主线程的UI显示内容，点击按钮后每过一秒通过handler发送消息更新UI线程显示的时间，直到显示时间更新到10然后结束这个线程。
下面对实际应用中客户端和服务器之间的通信进行简单介绍。
服务器中每个应用会有一个UPD(User Datagram Protocol，用户数据报协议)端口号或TCP(Transmission Control Protocol，传输控制协议)端口号，服务器的IP地址一般是固定不变的，客户端事先可以知道IP地址和UPD/TCP端口号。比如微信服务器端，为微信应用分配了一个IP地址，比如20.22.119.10，TCP端口号为10000。客户端将需要发送给服务器的消息按照TCP报文的格式，发送到IP地址为20.22.119.10的服务器的TCP端口10000，服务器中有一应用持续侦听发送到该端口的数据，并将数据发送到微信应用。这样，建立起了客户端与微信服务器端之间的初始通信。
图1示意性地示出了根据本发明实施方式的一种基于自然语言实现不同应用之间通信的方法10，包括：
步骤100：第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息；
步骤110：所述第一应用根据所述目标信息中的全部或者部分信息向所述第二应用发送消息。
本发明实施例中所说的自然语言实际上指的是对于接收方是非预设内容的自然语言，而不是固定内容的自然语言形式。其中，非预设内容的自然语言意味着接收方需要进行语义分析；而预设内容的自然语言，接收方直接进行字符串匹配即可。例如，在非预设内容的自然语言的情况下，“今天好热”，或者“今天温度好高”，或者“今天快晒死了”，虽然内容不同，但是含义实质上时相同的，用任何一种表达方式都可以。又例如，在非预设内容的自然语言的情况下，“当前温度”和“现在温度”，虽然表达形式不同，但是语义是相同的，采用任何一种表述也都可以。
本发明实施例中，自然语言的表达方式有多种，例如，可以是语音形式，或者也可以是文本形式(如通过IP(Internet Protocol，网络协议)网络广播)，语音形式和文本形式都可以采用超声波的方式。其中，文本具体可以为图片文字或者二维码形式呈现出来的文字，语音形式可以是音乐，当然，还可能有其他形式，在此不做具体限定。
当然，第一应用也可以通过FTP下载协议定义说明书。
本发明实施例中，可选地，所述第一应用和所述第二应用均位于第一设备；或者
所述第一应用位于第一设备，所述第二应用位于第二设备。
本发明实施例中，可选地，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用基于自然语言向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用接收所述第二应用返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
也就是说第一应用给第二应用发送请求消息的时候采用自然语言，但是，第二应用向第一应用返回响应消息的形式不做具体限定，可以采用自然语言的形式，或者也可以第一应用指定的协议，例如，所述请求消息中携带指示协议标识；
此时，可选地，所述第一应用接收所述第二应用返回的响应消息，包括：
所述第一应用接收所述第二应用根据所述指示协议标识返回的响应消息。
当然，第二应用向第一应用返回响应消息也可以采用其他形式，在此不做具体限定。
前面描述的是第一应用向第二应用发送消息采用自然语言，但是第二应用向第一应用发送消息的形式不做具体限定，本发明实施例中，也可以是第二应用向第一应用发送消息采用自然语言，但是第一应用向第二应用发送消息的形式不做具体限定。
因此，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用接收所述第二应用基于自然语言返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
本发明实施例中，请求消息可以为用于直接请求与通信协议相关信息的消息，比如：第一应用向第二应用以自然语言形式发送用于询问与通信协议相关信息的消息，第二应用随后向第一应用回复与通信协议相关信息。
或者请求消息也可以是用于间接的或隐含请求与通信协议相关信息的消息，只要触发第二应用给第一应用返回包含目标信息的消息即可，比如：第一应用以自然语言形式向第二应用发送用户名和密码(隐含方式)，第二应用随后向第一应用回复与通信协议相关信息(隐含响应)。
前面描述的是请求消息的直接的方式，或者隐含的、间接的方式，同理，响应也可以是直接针对第一应用的明确的信息请求的响应，也可以是隐含的、间接的响应。在此不再进行详述。
本发明实施例中，可以使用发送广播与接收广播的机制，来实现对Android系统中的两个完全没关系的应用之间的通信，例如应用A发送了一个广播，应用B接收到然后执行相关操作，这样可以实现相互的通讯。
本发明实施例中，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息时，可选地，可以采用如下方式：
所述第一应用基于广播消息来获取所述第二应用发送的所述目标信息。
可选地，广播消息为应用之间的广播消息。
下面以android为例对同一设备内部不同应用之间的广播进行简单介绍。
Android广播分为两个方面：广播发送者和广播接收者，通常情况下，BroadcastReceiver指的是广播接收者(广播接收器)。广播作为Android组件间的通信方式，可以使用的场景至少包括如下几种：
1.同一应用内部的同一组件内的消息通信(单个或多个线程之间)；
2.同一应用内部的不同组件之间的消息通信(单个进程)；
3.同一应用具有多个进程的不同组件之间的消息通信；
4.不同应用之间的组件之间消息通信；
5.Android系统在特定情况下与应用之间的消息通信。
从实现原理看上，Android中的广播使用了观察者模式，基于消息的发布/订阅事件模型。具体实现流程要点粗略概括如下：
1.广播接收者(BroadcastReceiver)通过Binder机制向AMS(Activity ManagerService)进行注册；
2.广播发送者通过Binder机制向AMS发送广播消息；
3.AMS查找符合相应条件(IntentFilter/Permission等)的广播接收者，将广播消息发送到查找到的广播接收者(一般情况下是Activity)相应的消息循环队列中；
4.消息循环执行拿到此广播消息，回调广播接收者中的onReceive()方法。
对于不同的广播消息的类型，以及不同的广播接收者的注册方式，具体实现上会有细微不同，但总体流程大致如上。由此看来，广播发送者和广播接收者分别属于观察者模式中的消息发布和订阅两端，AMS属于中间的处理中心。
跨设备的应用之间，如果不知道目的应用处于哪个设备上运行，源应用可以采用网络广播方式传输相关信息。比如，将广播消息的目的IP(Internet Protocol，互联网协议)地址设定为广播地址255.255.255.255，那么在网络上的其它设备都可以接收到这个广播消息了。
本发明实施例中，第一应用向第二应用发送请求消息的方式有多种，可选地，可以采用如下方式：
所述第一应用接收用户发送的指令信息；
所述第一应用获得所述指令信息的语义分析结果；
所述第一应用确定与所述语义分析结果对应的请求消息，并将所述请求消息发送至所述第二应用。
其中，所述第一应用获得所述指令信息的语义分析结果时，可以对指令信息进行语义分析，得到语义分析结果；当然，也可以为通过云端设备或者服务器进行语义分析后，再将语义分析结果返回给第一应用，在此不做具体限定。
前面描述的是第一应用获得指令信息的语义分析结果，当然，要获得其他基于自然语言形式的消息的语义分析结果的方法与获得所述指令信息的语义分析结果的方法类似，在此不再进行详述。
由于第一应用向第二应用发送请求消息的方式可以为采用自然语言，也可以不采用自然语言，因此，上述具体实现方式既可以适用第一应用采用自然语言向第二应用发送请求消息的方式，也可以适用第一应用采用其他方式向第二应用发送请求消息的方式，在此不做具体限定。
上述方式具体可以采用如下形式实现：
所述第一应用接收用户发送的指令信息，并将所述指令信息转化为格式化数据；
对所述格式化数据进行归一化处理得到所述指令信息的语义分析结果；
并确定与所述语义分析结果对应的请求消息，并将所述请求消息发送至所述第二应用。
本发明实施例中，第一应用发送的请求消息是基于自然语言的，第二应用返回的响应消息也可以是基于自然语言的，在此不做具体限定。
例如，第一应用和第二应用为两个独立开发的社交软件，要同步它们的好友列表，但互相不知道对方的数字传输格式，此时，第一应用可以以自然语言的形式询问第二应用，比如“你的好友列表数据是怎样进行数字编码的？”，第二应用接收到此自然语言形式的消息，并经过语义解析之后，将自己的数字编码方式以自然语言的方式传给第一应用，如“列表以二进制编码的格式来传输，一共是五个字节(40bit)的长度,其中第一个字节表示姓氏，后面的三个字节表示名字(若名字只占一个字节，则后面的16bit以全零序列来表示)，最后一个字节表示性别。”，然后，第二应用可以将每个字节对应的二进制序列列表以文本的形式发送给第一应用。第一应用接收后进行语义解析，得到第二应用的数字编码格式，双方就可以直接以统一的数字编码方式进行高效的数据传输。比如要将第一应用中的张三的男生的信息传输到第二应用中，则可以发送一串二进制序列即可。
本发明实施例中，可选地，所述目标信息包括协议标识和/或协议定义信息，当然，还可以包括其他信息，在此不做具体限定。
本发明实施例中，可选地，所述协议定义信息包括消息传输接口定义信息、消息的格式信息和信令流程信息中的至少一种，当然，还可以包括其他信息，在此不做具体限定。数据传输接口包括物理层电气特性定义(比如传输电压大小、信号功率大小、总线类型，时钟频率等)、物理层数据读取时序(比如数据读写时序、占空比规定等)、传输层协议(比如信道编码、传输校验机制、重传机制等)、网络层传输协议(比如IP地址、UDP(User DatagramProtocol，用户数据报协议)或TCP端口号等)。
下面以获取好友信息的信令流程为例对信令流程进行描述：
步骤1：第一应用发出list_req消息；
当需要获取好友列表时，第一应用发出list_req消息；
步骤2：第二应用接收到list_req消息之后，发出list_data。
若第二应用在1s范围内未接收到list_data，则第一应用重新发送list_req消息。
上述只是以获取好友信息的信令流程为例进行说明，但是并不限定于此。
本发明实施例中，可选地，所述消息的格式信息包括数字编码格式；
其中，所述数字编码格式包括所述第二应用所能接收的数据的字段(filed)、长度(length)、取值范围(range)、数据类型(type)中的至少一种。其中，消息的格式信息还可以包括压缩格式。
数字编码格式可以是表格的形式，如表1、2所示的示例。
表1数字编码格式
| 字段 | 类型 | 长度 | 取值范围 | 补充信息 |
| 好友列表数据(list_data) | 字符串型 | 40比特 | -40到60 | 以IP/UDP(port＝10001)的方式承载 |
表2数字编码格式
| 字段 | 类型 | 长度 | 取值范围 | 补充信息 |
| 好友列表请求(list_req) | 整型 | 1比特 | 0，1 | 以IP/UDP(port＝10001)的方式承载 |
表2的取值范围项中，0表示不再需要好友列表数据；1表示需要接收好友列表数据。
其中，可选地，表格可以是图片形式，或者也可以是富文本形式的文档，在此不做具体限定。
本发明实施例中，可选地，所述协议标识能够用表征信息来表征；
其中，所述表征信息包括所述第二应用的标识ID(Identification，标识)、所述第二应用的类型、所述第二应用的版本号(如mi6)和与所述第二应用相关的互联网协议IP地址、相关关键词(比如“DLNA”)中的至少一种。
此时，所述第一应用根据所述目标信息中的全部或者部分信息向所述第二应用发送消息，包括：
所述第一应用根据所述表征信息确定所述表征信息所对应的协议；
采用确定的协议向所述第二应用发送消息。
下面对第二应用的ID进行示例：
如应用在操作系统中有一个进程或多个ID，又例如，Android应用都有一个独特的应用ID。
其中，第二应用相关的IP地址，可以是指第二应用运行所在的服务器的IP地址、第二应用运行所在的网站的IP地址或第二应用运行所在的计算机的IP地址，其中，IP地址可以是以域名的形式体现出来的网站地址(如www.mqpat.com)。
本发明实施例中，可选地，所述第一应用根据所述表征信息确定所述表征信息所对应的协议，包括：
所述第一应用通过第三设备获取对应的协议信息；
其中，所述第三设备为互联网服务器、搜索引擎、自然语言交互引擎中的至少一种。
例如，第一应用获得通过服务器以自然语言方式反馈的其自身设备ID，第一应用以该ID为关键词，通过互联网搜索引擎下载得到第二应用支持的协议定义。总之，获取协议定义的方式不限。在第一应用中写入一个代码段，作为自然语言生成模块，当其与第二应用要进行通信时，则第一应用首先生成关于询问关于第二应用接口定义和数据传输格式的自然语言(比如语音或文本)有关的信息，并发出；关于其接口类型/数据传输格式的信息，可以是询问第二应用的类型、软硬件版本号，生产厂商等，也可以是对直接询问接口定义/说明书，在此不做具体限定。
在实际应用中，第二应用反馈回来的所能够支持的数字编码格式与第一应用所能够支持的数字编码格式可能不统一，此时，二者之间可以进行协商，因此，本发明实施例中，可选地，所述第一应用根据所述目标信息中的全部或者部分信息向所述第二应用发送消息，包括：
所述第一应用判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议是否相匹配；
如果所述第一应用判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议相匹配，直接采用所述目标信息对应的协议向所述第二应用发送消息；
否则，所述第一应用返回基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息的步骤。
例如，第一应用和第二应用为两个独立开发的社交软件，要同步它们的好友列表，但互相不知道对方的数字传输格式，此时，第一应用可以以自然语言的形式询问第二应用，比如“你的好友列表数据是怎样进行数字编码的？”，第二应用接收到此自然语言形式的消息，并经过语义解析之后，将自己的数字编码方式以自然语言的方式传给第一应用，第一应用接收到第二应用的数字传输格式之后，以二进制编码的形式高速率地向第二应用发送好友列表信息，发现有些人的名字是五个字，还需要增加一个字的长度来传输其名字，那么可以向第二应用发送“-传输名字可以增加一个字的长度吗？”，第二应用接收该消息并检测自身数据格式定义之后发现可以更改，则向第一应用发送“可以！”。然后第一应用增加一个字的长度(8bit)用来传送名字，若没有，则编码为全零，从而二者就协商了一种新的数字编码方式，采用协商得到的数字编码方式来进行通信。
需要说明的是，如果第一应用返回获取与第二应用所能够支持的至少一种通信协议相关的目标信息的步骤之后，如果所述第一应用判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议不相匹配的话，可以再继续获取，直至匹配为止，在此不做具体限定。
本发明实施例中，第二应用在接收到请求消息之后，可能无法理解第一应用发送的请求消息，此时，第一应用和第二应用可以反复进行沟通，直至第二应用能够解析出第一应用发送的请求消息，因此，本发明实施例中，第一应用向第二应用发送请求消息之后，接收所述响应消息之前，所述方法还包括：
若所述第二应用无法理解所述请求消息，所述第一应用继续与第二应用进行沟通，直至所述第二应用能够解析所述请求消息。其中，在具体实施过程中，可以采用如下方式：
若所述第二应用无法理解所述请求消息，所述第一应用继续向所述第二应用发送请求消息，直至所述第二应用能够理解所述请求消息。
前面描述的是第二应用无法理解第一应用的请求消息，当然，也可能存在第一应用无法理解第二应用发送的响应消息，此时，第一应用也可以和第二应用反复沟通，直至第一应用能够解析出响应消息，因此，本发明实施例中，所述第一应用接收所述第二应用返回的响应消息之后，向所述第二应用发送消息之前，进一步的，所述方法还包括：
若所述第一应用无法理解所述响应消息，所述第一应用继续与所述第二应用进行沟通，直至第一应用能够解析出第二应用发送的响应消息。在具体实施过程中，可以采用如下方式：
若所述第一应用无法理解所述响应消息，所述第一应用继续接收所述第二应用发送的响应消息，直至所述第一应用能够理解所述响应消息。
本发明实施例中，所述自然语言为文本时，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息时，可选地，可以采用如下方式：
所述第一应用基于图像获取模块获取以二维码、图像、文字标志中的至少一种形式程序的所述目标信息。如，第一应用获得通过二维码扫描获得一个URL(UniformResource Locator，统一资源定位符)地址，通过该地址可以下载到与第二应用进行交互的与至少一种通信协议相关的信息。
图像获取模块可以为照相机，或者也可以为图像码扫描仪。优选地，所述第一应用基于图像获取模块获取以二维码、图像、文字标志中的至少一种形式程序的所述目标信息应用在第一应用处于第一设备，第二应用处于第二设备的场景下。同一设备内不同应用之间的交互可以通过共享内存、程序间消息传输队列等方式实现。
所述自然语言为语音时，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息时，可选地，可以采用如下方式：
所述第一应用基于超声波获取所述目标信息。优选地，这种方式应用在第一应用处于第一设备，第二应用处于第二设备的场景下。
在该方案中，利用自然语言来获取与通信协议相关的目标信息，由于自然语言的通用性高，因此，即使第一应用没有预先存储与第二应用所支持的通信协议相关的目标信息，也可以通过自然语言来获取与第二应用所支持的通信协议相关的目标信息，后续可以采用得到的目标信息来与第二应用通信，因此，可以解决现有技术中没有预先存储相关应用的协议就无法与该类应用进行通信的缺陷，扩大了应用场景的范围。
进一步的，由于在获取目标信息后，可以采用协议中规定的数字编码格式传输消息，而采用数字编码格式传输数据的效率较高，因此，本发明实施例提出的方法还可以提高传输效率。
参阅图2A所示，本发明实施例中，还提出一种基于自然语言实现不同应用之间通信的方法，包括：
方法20A：步骤200A：第二应用接收第一应用基于自然语言发送的请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；步骤210A：向所述第一应用发送响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息；或者
方法20B：步骤200B：所述第二应用接收第一应用发送的请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；步骤210B：基于自然语言向所述第一应用发送响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
本发明实施例中所说的自然语言实际上指的是对于接收方是非预设内容的自然语言，而不是固定内容的自然语言形式。其中，非预设内容的自然语言意味着接收方需要进行语义分析；而预设内容的自然语言，接收方直接进行字符串匹配即可。例如，在非预设内容的自然语言的情况下，“今天好热”，或者“今天温度好高”，或者“今天快晒死了”，虽然内容不同，但是含义实质上时相同的，用任何一种表达方式都可以。又例如，在非预设内容的自然语言的情况下，“当前温度”和“现在温度”，虽然表达形式不同，但是语义是相同的，采用任何一种表述也都可以。
本发明实施例中，自然语言的表达方式有多种，例如，可以是语音形式，或者也可以是文本形式(如通过IP网络广播)，语音形式和文本形式都可以采用超声波的方式。其中，文本具体可以为图片文字或者二维码形式呈现出来的文字，语音形式可以是音乐，当然，还可能有其他形式，在此不做具体限定。
需要说明的是，第二应用在接收到第一应用基于自然语言发送的请求消息后，需要获得请求消息的语义分析结果，其中，获得请求消息的语义分析结果时，可以对请求消息进行语义分析，得到语义分析结果；或者，也可以为通过云端应用或者服务器进行语义分析后，再将语义分析结果返回给第二应用，当然，还可以有其他方式，在此不做具体限定。
前面描述的是第二应用获得请求消息的语义分析结果，当然，要获得其他基于自然语言形式的消息的语义分析结果的方法与获得所述请求消息的语义分析结果的方法类似，在此不再进行详述。
本发明实施例中，所述第一应用和所述第二应用均位于第一设备；或者
所述第一应用位于第一设备，所述第二应用位于第二设备。
本发明实施例中，可选地，所述请求消息中携带指示协议标识；
所述第二应用向所述第一应用发送响应消息，包括：
所述第二应用根据所述指示协议标识向所述第一应用返回响应消息。
本发明实施例中，可选地，所述目标信息包括协议标识和/或协议定义。
本发明实施例中，可选地，所述协议定义信息包括消息传输接口定义信息、消息的格式信息和信令流程信息中的至少一种。
数据传输接口包括物理层电气特性定义(比如传输电压大小、信号功率大小、总线类型，时钟频率等)、物理层数据读取时序(比如数据读写时序、占空比规定等)、传输层协议(比如信道编码、传输校验机制、重传机制等)、网络层传输协议(比如IP地址、UDP或TCP端口号等)。
下面以获取好友信息的信令流程为例对信令流程进行描述：
步骤1：第一应用发出list_req消息；
当需要获取好友列表时，第一应用发出list_req消息；
步骤2：第二应用接收到list_req消息之后，发出list_data。
若第二应用在1s范围内未接收到list_data，则第一应用重新发送list_req消息。
上述只是以获取好友信息的信令流程为例进行说明，但是并不限定于此。
本发明实施例中，可选地，所述消息的格式信息包括数字编码格式；
其中，所述数字编码格式包括所述第二应用所能接收的数据的字段、长度、取值范围、数据类型中的至少一种。其中，消息的格式信息还可以包括压缩格式。
数字编码格式可以是表格的形式，如表1、2所示的示例。其中，可选地，表格可以是图片形式，或者也可以是富文本形式的文档，在此不做具体限定。
本发明实施例中，可选地，协议标识能够用表征信息来表征；
其中，所述表征信息包括所述第二应用的标识ID、所述第二应用的类型、所述第二应用的版本号和与所述第二应用相关的互联网协议IP地址、相关关键词中的至少一种。
在实际应用中，第二应用反馈回来的所能够支持的数字编码格式与第一应用所能够支持的数字编码格式可能不统一，此时，二者之间可以进行协商，因此，本发明实施例中，可选地，所述第二应用向所述第一应用发送响应消息之后，所述方法还包括：
如果所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议不匹配，所述第二应用继续向所述第一应用发送响应消息。
本发明实施例中，第二应用在接收到请求消息之后，可能无法理解第一应用发送的请求消息，此时，第一应用和第二应用可以反复进行沟通，直至第二应用能够解析出第一应用发送的请求消息，因此，本发明实施例中，若所述第二应用无法理解所述请求消息，所述第二应用继续与所述第一应用进行沟通。
前面描述的是第二应用无法理解第一应用的请求消息，当然，也可能存在第一应用无法理解第二应用发送的响应消息，此时，第一应用也可以和第二应用反复沟通，直至第一应用能够解析出响应消息，因此，本发明实施例中，若所述第一应用无法理解所述响应消息，所述第二应用继续与所述第一应用进行沟通。
在该方案中，利用自然语言来获取与通信协议相关的目标信息，由于自然语言的通用性高，因此，即使第一应用没有预先存储与第二应用所支持的通信协议相关的目标信息，也可以通过自然语言来获取与第二应用所支持的通信协议相关的目标信息，后续可以采用得到的目标信息来与第二应用通信，因此，可以解决现有技术中没有预先存储相关应用的协议就无法与该类应用进行通信的缺陷，扩大了应用场景的范围。
进一步的，由于在获取目标信息后，可以采用协议中规定的数字编码格式传输消息，而采用数字编码格式传输数据的效率较高，因此，本发明实施例提出的方法还可以提高传输效率。
参阅图3所示，本发明实施例还提出一种基于自然语言实现不同应用之间通信的装置30，包括：
第一应用中的获取单元300，用于基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息；
所述第一应用中的发送单元310，用于根据所述目标信息中的全部或者部分信息向所述第二应用发送消息。
本发明实施例中所说的自然语言实际上指的是对于接收方是非预设内容的自然语言，而不是固定内容的自然语言形式。其中，非预设内容的自然语言意味着接收方需要进行语义分析；而预设内容的自然语言，接收方直接进行字符串匹配即可。例如，在非预设内容的自然语言的情况下，“今天好热”，或者“今天温度好高”，或者“今天快晒死了”，虽然内容不同，但是含义实质上时相同的，用任何一种表达方式都可以。又例如，在非预设内容的自然语言的情况下，“当前温度”和“现在温度”，虽然表达形式不同，但是语义是相同的，采用任何一种表述也都可以。
本发明实施例中，自然语言的表达方式有多种，例如，可以是语音形式，或者也可以是文本形式(如通过IP网络广播)，语音形式和文本形式都可以采用超声波的方式。其中，文本具体可以为图片文字或者二维码形式呈现出来的文字，语音形式可以是音乐，当然，还可能有其他形式，在此不做具体限定。
当然，第一应用也可以通过FTP下载协议定义说明书。
本发明实施例中，可选地，所述第一应用和所述第二应用均位于第一设备；或者
所述第一应用位于第一设备，所述第二应用位于第二设备。
本发明实施例中，可选地，所述发送单元310还用于，基于自然语言向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用中的获取单元300基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
接收所述第二应用返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
也就是说第一应用给第二应用发送请求消息的时候采用自然语言，但是，第二应用向第一应用返回响应消息的形式不做具体限定，可以采用自然语言的形式，或者也可以第一应用指定的协议，例如，所述请求消息中携带指示协议标识；
所述获取单元300接收所述第二应用返回的响应消息，包括：
接收所述第二应用根据所述指示协议标识返回的响应消息。
当然，第二应用向第一应用返回响应消息也可以采用其他形式，在此不做具体限定。
前面描述的是第一应用向第二应用发送消息采用自然语言，但是第二应用向第一应用发送消息的形式不做具体限定，本发明实施例中，也可以是第二应用向第一应用发送消息采用自然语言，但是第一应用向第二应用发送消息的形式不做具体限定。
因此，所述发送单元310还用于，向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用中的获取单元300基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
接收所述第二应用基于自然语言返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
本发明实施例中，请求消息可以为用于直接请求与通信协议相关信息的消息，比如：第一应用向第二应用以自然语言形式发送用于询问与通信协议相关信息的消息，第二应用随后向第一应用回复与通信协议相关信息。
或者请求消息也可以是用于间接的或隐含请求与通信协议相关信息的消息，只要触发第二应用给第一应用返回包含目标信息的消息即可，比如：第一应用以自然语言形式向第二应用发送用户名和密码(隐含方式)，第二应用随后向第一应用回复与通信协议相关信息(隐含响应)。
前面描述的是请求消息的直接的方式，或者隐含的、间接的方式，同理，响应也可以是直接针对第一应用的明确的信息请求的响应，也可以是隐含的、间接的响应。在此不再进行详述。
本发明实施例中，可以使用发送广播与接收广播的机制，来实现对Android系统中的两个完全没关系的应用之间的通信，例如应用A发送了一个广播，应用B接收到然后执行相关操作，这样可以实现相互的通讯。
本发明实施例中，所述第一应用中的获取单元300通过第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
基于广播消息来获取所述第二应用发送的所述目标信息。
本发明实施例中，所述装置还包括接收单元320和处理单元330，其中：
所述接收单元320，用于接收用户发送的指令信息；
所述处理单元330，用于获得所述指令信息的语义分析结果；
所述发送单元310向第二应用发送请求消息，包括：
确定与所述语义分析结果对应的请求消息，并将所述请求消息发送至所述第二应用。
其中，所述第一应用获得所述指令信息的语义分析结果时，可以对指令信息进行语义分析，得到语义分析结果；当然，也可以为通过云端设备或者服务器进行语义分析后，再将语义分析结果返回给第一应用，在此不做具体限定。
前面描述的是第一应用获得指令信息的语义分析结果，当然，要获得其他基于自然语言形式的消息的语义分析结果的方法与获得所述指令信息的语义分析结果的方法类似，在此不再进行详述。
由于第一应用向第二应用发送请求消息的方式可以为采用自然语言，也可以不采用自然语言，因此，上述具体实现方式既可以适用第一应用采用自然语言向第二应用发送请求消息的方式，也可以适用第一应用采用其他方式向第二应用发送请求消息的方式，在此不做具体限定。
上述方式具体可以采用如下形式实现：
所述第一应用接收用户发送的指令信息，并将所述指令信息转化为格式化数据；
对所述格式化数据进行归一化处理得到所述指令信息的语义分析结果；
并确定与所述语义分析结果对应的请求消息，并将所述请求消息发送至所述第二应用。
本发明实施例中，第一应用发送的请求消息是基于自然语言的，第二应用返回的响应消息也可以是基于自然语言的，在此不做具体限定。
例如，第一应用和第二应用为两个独立开发的社交软件，要同步它们的好友列表，但互相不知道对方的数字传输格式，此时，第一应用可以以自然语言的形式询问第二应用，比如“你的好友列表数据是怎样进行数字编码的？”，第二应用接收到此自然语言形式的消息，并经过语义解析之后，将自己的数字编码方式以自然语言的方式传给第一应用，如“列表以二进制编码的格式来传输，一共是五个字节(40bit)的长度,其中第一个字节表示姓氏，后面的三个字节表示名字(若名字只占一个字节，则后面的16bit以全零序列来表示)，最后一个字节表示性别。”，然后，第二应用可以将每个字节对应的二进制序列列表以文本的形式发送给第一应用。第一应用接收后进行语义解析，得到第二应用的数字编码格式，双方就可以直接以统一的数字编码方式进行高效的数据传输。比如要将第一应用中的张三的男生的信息传输到第二应用中，则可以发送一串二进制序列即可。
本发明实施例中，可选地，所述目标信息包括协议标识和/或协议定义信息。
本发明实施例中，可选地，所述协议定义信息包括消息传输接口定义信息、消息的格式信息和信令流程信息中的至少一种。当然，还可以包括其他信息，在此不做具体限定。数据传输接口包括物理层电气特性定义(比如传输电压大小、信号功率大小、总线类型，时钟频率等)、物理层数据读取时序(比如数据读写时序、占空比规定等)、传输层协议(比如信道编码、传输校验机制、重传机制等)、网络层传输协议(比如IP地址、UDP或TCP端口号等)。
下面以获取好友信息的信令流程为例对信令流程进行描述：
步骤1：第一应用发出list_req消息；
当需要获取好友列表时，第一应用发出list_req消息；
步骤2：第二应用接收到list_req消息之后，发出list_data。
若第二应用在1s范围内未接收到list_data，则第一应用重新发送list_req消息。
上述只是以获取好友信息的信令流程为例进行说明，但是并不限定于此。
本发明实施例中，可选地，所述消息的格式信息包括数字编码格式；
其中，所述数字编码格式包括所述第二应用所能接收的数据的字段、长度、取值范围、数据类型中的至少一种。消息的格式信息还可以包括压缩格式。
数字编码格式可以是表格的形式，如表1、2所示的示例。其中，可选地，表格可以是图片形式，或者也可以是富文本形式的文档，在此不做具体限定。
本发明实施例中，可选地所述协议标识能够用表征信息来表征；
其中，所述表征信息包括所述第二应用的标识ID、所述第二应用的类型、所述第二应用的版本号和与所述第二应用相关的互联网协议IP地址、相关关键词中的至少一种。
其中，第二应用相关的IP地址，可以是指第二应用运行所在的服务器的IP地址、第二应用运行所在的网站的IP地址或第二应用运行所在的计算机的IP地址，其中，IP地址可以是以域名的形式体现出来的网站地址(如www.mqpat.com)。
本发明实施例中，可选地，所述第一应用中的发送单元310根据所述目标信息中的全部或者部分信息向所述第二应用发送消息，包括：
根据所述表征信息确定所述表征信息所对应的协议；
采用确定的协议向所述第二应用发送消息。
本发明实施例中，可选地，所述发送单元310根据所述表征信息确定所述表征信息所对应的协议，包括：
通过第三应用获取对应的协议信息；
其中，所述第三应用为互联网服务器、搜索引擎、自然语言交互引擎中的至少一种。
例如，第一应用获得通过服务器以自然语言方式反馈的其自身设备ID，第一应用以该ID为关键词，通过互联网搜索引擎下载得到第二应用支持的协议定义。总之，获取协议定义的方式不限。在第一应用中写入一个代码段，作为自然语言生成模块，当其与第二应用要进行通信时，则第一应用首先生成关于询问关于第二应用接口定义和数据传输格式的自然语言(比如语音或文本)有关的信息，并发出；关于其接口类型/数据传输格式的信息，可以是询问第二应用的类型、软硬件版本号，生产厂商等，也可以是对直接询问接口定义/说明书，在此不做具体限定。
在实际应用中，第二应用反馈回来的所能够支持的数字编码格式与第一应用所能够支持的数字编码格式可能不统一，此时，二者之间可以进行协商，因此，本发明实施例中，可选地，所述第一应用中的发送单元310根据所述目标信息中的全部或者部分信息向所述第二应用发送消息，包括：
判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议是否相匹配；
如果判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议相匹配，直接采用所述目标信息对应的协议向所述第二应用发送消息；
否则，返回基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息的步骤。
例如，第一应用和第二应用为两个独立开发的社交软件，要同步它们的好友列表，但互相不知道对方的数字传输格式，此时，第一应用可以以自然语言的形式询问第二应用，比如“你的好友列表数据是怎样进行数字编码的？”，第二应用接收到此自然语言形式的消息，并经过语义解析之后，将自己的数字编码方式以自然语言的方式传给第一应用，第一应用接收到第二应用的数字传输格式之后，以二进制编码的形式高速率地向第二应用发送好友列表信息，发现有些人的名字是五个字，还需要增加一个字的长度来传输其名字，那么可以向第二应用发送“-传输名字可以增加一个字的长度吗？”，第二应用接收该消息并检测自身数据格式定义之后发现可以更改，则向第一应用发送“可以！”。然后第一应用增加一个字的长度(8bit)用来传送名字，若没有，则编码为全零，从而二者就协商了一种新的数字编码方式，采用协商得到的数字编码方式来进行通信。
需要说明的是，如果第一应用返回获取与第二应用所能够支持的至少一种通信协议相关的目标信息的步骤之后，如果所述第一应用判断所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议不相匹配的话，可以再继续获取，直至匹配为止，在此不做具体限定。
本发明实施例中，第二应用在接收到请求消息之后，可能无法理解第一应用发送的请求消息，此时，第一应用和第二应用可以反复进行沟通，直至第二应用能够解析出第一应用发送的请求消息，因此，本发明实施例中，第一应用向第二应用发送请求消息之后，接收所述响应消息之前，所述方法还包括：
若所述第二应用无法理解所述请求消息，所述第一应用继续与第二应用进行沟通，直至所述第二应用能够解析所述请求消息。其中，在具体实施过程中，可以采用如下方式：
若所述第二应用无法理解所述请求消息，所述第一应用继续向所述第二应用发送请求消息，直至所述第二应用能够理解所述请求消息。
前面描述的是第二应用无法理解第一应用的请求消息，当然，也可能存在第一应用无法理解第二应用发送的响应消息，此时，第一应用也可以和第二应用反复沟通，直至第一应用能够解析出响应消息，因此，本发明实施例中，所述第一应用接收所述第二应用返回的响应消息之后，向所述第二应用发送消息之前，进一步的，所述方法还包括：
若所述第一应用无法理解所述响应消息，所述第一应用继续与所述第二应用进行沟通，直至第一应用能够解析出第二应用发送的响应消息。在具体实施过程中，可以采用如下方式：
若所述第一应用无法理解所述响应消息，所述第一应用继续接收所述第二应用发送的响应消息，直至所述第一应用能够理解所述响应消息。
本发明实施例中，可选地，所述自然语言为文本时，所述第一应用中的获取单元300基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
基于图像获取模块获取以二维码、图像、文字标志中的至少一种形式程序的所述目标信息。如，第一应用获得通过二维码扫描获得一个URL地址，通过该地址可以下载到与第二应用进行交互的与至少一种通信协议相关的信息。
图像获取模块可以为照相机，或者也可以为图像码扫描仪。优选地，所述第一应用基于图像获取模块获取以二维码、图像、文字标志中的至少一种形式程序的所述目标信息应用在第一应用处于第一设备，第二应用处于第二设备的场景下。同一设备内不同应用之间的交互可以通过共享内存、程序间消息传输队列等方式实现。
本发明实施例中，所述自然语言为语音时，所述第一应用中的获取单元300基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
基于超声波获取所述目标信息。优选地，这种方式应用在第一应用处于第一设备，第二应用处于第二设备的场景下。
在该方案中，利用自然语言来获取与通信协议相关的目标信息，由于自然语言的通用性高，因此，即使第一应用没有预先存储与第二应用所支持的通信协议相关的目标信息，也可以通过自然语言来获取与第二应用所支持的通信协议相关的目标信息，后续可以采用得到的目标信息来与第二应用通信，因此，可以解决现有技术中没有预先存储相关应用的协议就无法与该类应用进行通信的缺陷，扩大了应用场景的范围。
进一步的，由于在获取目标信息后，可以采用协议中规定的数字编码格式传输消息，而采用数字编码格式传输数据的效率较高，因此，本发明实施例提出的方法还可以提高传输效率。
参阅图4所示，本发明实施例中，还提出一种基于自然语言实现不同应用之间通信的装置40，包括：
第二应用中的接收单元400，用于接收第一应用基于自然语言发送的请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；第二应用中的发送单元410，用于向所述第一应用发送响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息；或者
所述第二应用中的接收单元400，用于所述第二应用接收第一应用发送的请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；所述第二应用中的发送单元410，用于基于自然语言向所述第一应用发送响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
本发明实施例中所说的自然语言实际上指的是对于接收方是非预设内容的自然语言，而不是固定内容的自然语言形式。其中，非预设内容的自然语言意味着接收方需要进行语义分析；而预设内容的自然语言，接收方直接进行字符串匹配即可。例如，在非预设内容的自然语言的情况下，“今天好热”，或者“今天温度好高”，或者“今天快晒死了”，虽然内容不同，但是含义实质上时相同的，用任何一种表达方式都可以。又例如，在非预设内容的自然语言的情况下，“当前温度”和“现在温度”，虽然表达形式不同，但是语义是相同的，采用任何一种表述也都可以。
本发明实施例中，自然语言的表达方式有多种，例如，可以是语音形式，或者也可以是文本形式(如通过IP网络广播)，语音形式和文本形式都可以采用超声波的方式。其中，文本具体可以为图片文字或者二维码形式呈现出来的文字，语音形式可以是音乐，当然，还可能有其他形式，在此不做具体限定。
需要说明的是，第二应用在接收到第一应用基于自然语言发送的请求消息后，需要获得请求消息的语义分析结果，其中，获得请求消息的语义分析结果时，可以对请求消息进行语义分析，得到语义分析结果；或者，也可以为通过云端应用或者服务器进行语义分析后，再将语义分析结果返回给第二应用，当然，还可以有其他方式，在此不做具体限定。
前面描述的是第二应用获得请求消息的语义分析结果，当然，要获得其他基于自然语言形式的消息的语义分析结果的方法与获得所述请求消息的语义分析结果的方法类似，在此不再进行详述。
本发明实施例中，可选地，所述第一应用和所述第二应用均位于第一设备；或者
所述第一应用位于第一设备，所述第二应用位于第二设备。
本发明实施例中，可选地，所述请求消息中携带指示协议标识；
所述第二应用中的发送单元410向所述第一应用发送响应消息，包括：
所述第二应用中的发送单元410根据所述指示协议标识向所述第一应用返回响应消息。
本发明实施例中，可选地，所述目标信息包括协议标识和/或协议定义。
本发明实施例中，可选地，所述协议定义信息包括消息传输接口定义信息、消息的格式信息和信令流程信息中的至少一种。
本发明实施例中，所述消息的格式信息包括数字编码格式；
其中，所述数字编码格式包括所述第二应用所能接收的数据的字段、长度、取值范围、数据类型中的至少一种。其中，消息的格式信息还可以包括压缩格式。
数字编码格式可以是表格的形式，如表1、2所示的示例。其中，可选地，表格可以是图片形式，或者也可以是富文本形式的文档，在此不做具体限定。
本发明实施例中，可选地，协议标识能够用表征信息来表征；
其中，所述表征信息包括所述第二应用的标识ID、所述第二应用的类型、所述第二应用的版本号和与所述第二应用相关的互联网协议IP地址、相关关键词中的至少一种。
在实际应用中，第二应用反馈回来的所能够支持的数字编码格式与第一应用所能够支持的数字编码格式可能不统一，此时，二者之间可以进行协商，因此，本发明实施例中，可选地，所述第二应用中的发送单元410在所述第二应用所支持的至少一种协议和所述第一应用所支持的至少一种协议不匹配时，继续向所述第一应用发送响应消息。
本发明实施例中，第二应用在接收到请求消息之后，可能无法理解第一应用发送的请求消息，此时，第一应用和第二应用可以反复进行沟通，直至第二应用能够解析出第一应用发送的请求消息，因此，本发明实施例中，若所述第二应用无法理解所述请求消息，所述第二应用继续与所述第一应用进行沟通。
前面描述的是第二应用无法理解第一应用的请求消息，当然，也可能存在第一应用无法理解第二应用发送的响应消息，此时，第一应用也可以和第二应用反复沟通，直至第一应用能够解析出响应消息，因此，本发明实施例中，若所述第一应用无法理解所述响应消息，所述第二应用继续与所述第一应用进行沟通。
在该方案中，利用自然语言来获取与通信协议相关的目标信息，由于自然语言的通用性高，因此，即使第一应用没有预先存储与第二应用所支持的通信协议相关的目标信息，也可以通过自然语言来获取与第二应用所支持的通信协议相关的目标信息，后续可以采用得到的目标信息来与第二应用通信，因此，可以解决现有技术中没有预先存储相关应用的协议就无法与该类应用进行通信的缺陷，扩大了应用场景的范围。
进一步的，由于在获取目标信息后，可以采用协议中规定的数字编码格式传输消息，而采用数字编码格式传输数据的效率较高，因此，本发明实施例提出的方法还可以提高传输效率。
在此提供的方法和装置不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
本领域那些技术人员可以理解，可以对实施例中的装置中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个装置中。可以把实施例中的若干模块组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者模块中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个装置实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的装置中的一些或者全部模块的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
Claims (10)
1.一种基于自然语言实现不同应用之间通信的方法，其特征在于，包括：
第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息；
所述第一应用根据所述目标信息中的全部或者部分信息向所述第二应用发送消息。
2.如权利要求1所述的方法，其特征在于，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用基于自然语言向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用接收所述第二应用返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
3.如权利要求1或2所述的方法，其特征在于，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用接收所述第二应用基于自然语言返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
4.如权利要求1或2所述的方法，其特征在于，第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
所述第一应用基于广播消息来获取所述第二应用发送的所述目标信息。
5.如权利要求1或2所述的方法，其特征在于，第一应用向第二应用发送请求消息，包括：
所述第一应用接收用户发送的指令信息；
所述第一应用获得所述指令信息的语义分析结果；
所述第一应用确定与所述语义分析结果对应的请求消息，并将所述请求消息发送至所述第二应用。
6.一种基于自然语言实现不同应用之间通信的装置，其特征在于，包括：
第一应用中的获取单元，用于基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息；
所述第一应用中的发送单元，用于根据所述目标信息中的全部或者部分信息向所述第二应用发送消息。
7.如权利要求6所述的装置，其特征在于，所述发送单元还用于，基于自然语言向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用中的获取单元基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
接收所述第二应用返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
8.如权利要求6或7所述的装置，其特征在于，所述发送单元还用于，向第二应用发送请求消息，所述请求消息用于请求与所述第二应用所能够支持的通信协议相关的目标信息；
所述第一应用中的获取单元基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
接收所述第二应用基于自然语言返回的响应消息，所述响应消息中携带与所述第二应用所能够支持的至少一种通信协议相关的目标信息。
9.如权利要求6或7所述的装置，其特征在于，所述第一应用中的获取单元通过第一应用基于自然语言获取与第二应用所能够支持的至少一种通信协议相关的目标信息，包括：
基于广播消息来获取所述第二应用发送的所述目标信息。
10.一种电子设备，包括：
存储器以及一个或多个处理器；
其中，所述存储器与所述一个或多个处理器通信连接，所述存储器中存储有可被所述一个或多个处理器执行的指令，所述指令被所述一个或多个处理器执行，以使所述一个或多个处理器能够实现如权利要求1-5中任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710576455.1A CN107395583B (zh) | 2017-07-14 | 2017-07-14 | 基于自然语言实现不同应用之间通信的方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710576455.1A CN107395583B (zh) | 2017-07-14 | 2017-07-14 | 基于自然语言实现不同应用之间通信的方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107395583A true CN107395583A (zh) | 2017-11-24 |
| CN107395583B CN107395583B (zh) | 2020-09-04 |
Family
ID=60340741
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710576455.1A Active CN107395583B (zh) | 2017-07-14 | 2017-07-14 | 基于自然语言实现不同应用之间通信的方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107395583B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110085234A (zh) * | 2019-04-29 | 2019-08-02 | 苏州狗尾草智能科技有限公司 | 接入自动语音识别系统 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104113529A (zh) * | 2014-06-23 | 2014-10-22 | 胡栋 | 一种基于自然语言理解的物联网与社交网络融合的方法和系统 |
| CN105471686A (zh) * | 2015-12-26 | 2016-04-06 | 腾讯科技（深圳）有限公司 | 终端控制方法、装置及系统 |
| CN106325095A (zh) * | 2016-10-25 | 2017-01-11 | 广州华睿电子科技有限公司 | 一种智能语音管家机器人系统 |
| CN106375535A (zh) * | 2015-07-20 | 2017-02-01 | 中兴通讯股份有限公司 | 联系人信息同步方法和装置 |
| CN106547208A (zh) * | 2015-09-16 | 2017-03-29 | 北京北信源软件股份有限公司 | 一种新型智能家居控制系统及控制方法 |
-
2017
- 2017-07-14 CN CN201710576455.1A patent/CN107395583B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104113529A (zh) * | 2014-06-23 | 2014-10-22 | 胡栋 | 一种基于自然语言理解的物联网与社交网络融合的方法和系统 |
| CN106375535A (zh) * | 2015-07-20 | 2017-02-01 | 中兴通讯股份有限公司 | 联系人信息同步方法和装置 |
| CN106547208A (zh) * | 2015-09-16 | 2017-03-29 | 北京北信源软件股份有限公司 | 一种新型智能家居控制系统及控制方法 |
| CN105471686A (zh) * | 2015-12-26 | 2016-04-06 | 腾讯科技（深圳）有限公司 | 终端控制方法、装置及系统 |
| CN106325095A (zh) * | 2016-10-25 | 2017-01-11 | 广州华睿电子科技有限公司 | 一种智能语音管家机器人系统 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110085234A (zh) * | 2019-04-29 | 2019-08-02 | 苏州狗尾草智能科技有限公司 | 接入自动语音识别系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107395583B (zh) | 2020-09-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10257142B2 (en) | Message delivery in a message system | |
| CN107612909B (zh) | 关于物联网设备的信息交互方法、装置及设备 | |
| CN106790676B (zh) | 订阅通知的实现方法和装置 | |
| KR101770320B1 (ko) | 경량 iot 정보 모델 | |
| US11108761B2 (en) | Method, apparatus and system for remote control of intelligent device | |
| CN112995348A (zh) | 物联网设备的控制方法、装置、系统 | |
| CN105812315B (zh) | 基于用户登陆账号的多终端消息传输方法及装置 | |
| CN111026982A (zh) | 智能合约处理方法、计算机设备及存储介质 | |
| CN108156210A (zh) | 目标资源的获取方法和装置 | |
| CN103139761B (zh) | 一种信息实时展示的方法和移动通讯终端 | |
| WO2017174026A1 (zh) | 一种客户端连接方法及系统 | |
| CN106899500B (zh) | 一种跨虚拟可扩展局域网的报文处理方法及装置 | |
| CN104348848B (zh) | 管理图片的方法、终端设备和服务器 | |
| CN102404616B (zh) | 基于数字电视网络进行数据云推送的方法及系统 | |
| CN113489811A (zh) | IPv6流量处理方法、装置、电子设备及计算机可读存储介质 | |
| CN107370731A (zh) | 基于自然语言实现不同应用之间通信的方法及装置 | |
| KR102094041B1 (ko) | IoT 단말 간 실시간으로 자율적인 상호작용을 위한 RDF 그래프 기반의 Semantic 엔진을 구비한 시스템 | |
| CN108880923A (zh) | 应用于应用服务器的监控操作请求的方法和装置 | |
| CN107395583A (zh) | 基于自然语言实现不同应用之间通信的方法及装置 | |
| CN112929257A (zh) | 多场景消息发送方法、装置、服务器以及存储介质 | |
| CN109005250B (zh) | 用于访问服务端的方法和装置 | |
| CN105263127B (zh) | 短信通讯方法和装置 | |
| US10263892B2 (en) | Compression method and system for user friendly address in mesh networking | |
| CN107580084B (zh) | 一种获取数据包真实源ip地址的方法和装置 | |
| Gajewski et al. | Identification and access to objects and services in the IoT environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |