虚拟设备创建方法、系统及装置
技术领域
本发明涉及一种智能家居应用技术领域,尤指一种虚拟设备创建方法、系统及装置。
背景技术
智能家居应用场景中,某些用户需求仅依靠单一家电设备已无法满足,需要对若干家电设备的相关功能进行组合。为了便于管理和控制,引入了虚拟设备的概念,即根据用户需求,在控制平台上构建集成了多个家电设备相关功能的虚拟设备形态(以软件形式存在),向用户提供服务。虚拟设备一般可以由物理设备或抽象设备构建而成的,物理设备、抽象设备和虚拟设备是物联网领域国际标准组织oneM2M中提出的3种设备类型,其中:
物理设备:现实中真实存在的设备形态。
抽象设备:物理设备接入oneM2M平台时,平台将其抽象成若干基本功能单元,称为抽象设备。抽象设备只具有一般属性,屏蔽了设备的底层网络技术和物理形态。
虚拟设备:oneM2M平台从已有设备(包括抽象设备、虚拟设备)中选取相关设备,通过语义组合(mash-up)产生虚拟设备,以提供新的服务。虚拟设备不是实际存在的,而是以软件形式存在于oneM2M平台中。
图1给出了oneM2M平台支持的三种设备类型。如图1所示,虚拟设备温度显示设备由抽象设备温度传感器和显示器虚拟构建而成,其中温度传感器和显示器分别是从物理设备空调和电视中抽象出来的抽象设备。
现有的虚拟设备构建方式,是由云平台根据用户需求,基于语义组合技术自动选取所需的家电设备及功能,进行语义组合(mash-up)构建而成的。以用户在家中查询空气污染指数(Air Pollution Index,API)为例,oneM2M平台语义引擎将已有家电的部分功能,如二氧化碳(CO2)探测、挥发性有机化合物(Volatile Organic Compounds,VOC)监测等,组合成为新资源——空气污染监测设备,满足用户的查询需求。具体过程如下:
用户向oneM2M平台发送语义查询请求,如家里的API是多少;oneM2M平台根据用户查询,确定其语义描述,如确定API包括CO2浓度和VOC浓度;oneM2M平台查询与上述语义描述有关的成员资源(抽象设备和/或已生成的虚拟设备),创建虚拟设备,与相应的成员资源及其对应的物理设备建立关联,并从对应的物理设备处查询数据,将查询结果返回用户。
现有的虚拟设备构建方式,是由云平台根据用户需求,自主选取所需的家电设备及功能,进行语义组合(mash-up),该过程中用户无法参与,没有机会选择用于构建虚拟设备的家电设备。因此,云平台通过控制虚拟设备,向用户提供服务时,可能会涉及用户在当时环境下不希望使用的家电设备,即所构建的虚拟设备有时候构建出的虚拟设备中可能包含用户不想使用的家电设备,创建的虚拟设备不能很好体现用户的创建要求,不能很好地满足用户需求,用户对创建的虚拟设备的满意度比较低,创建的虚拟设备的使用效果可能也会比较差。
发明内容
有鉴于此,本发明的一个目的是提供一种虚拟设备创建方法、系统及装置,用于解决现有技术中虚拟设备创建过程中,用户不能参与,创建的虚拟设备不能很好体现用户的创建要求,从而不能很好地满足用户需求的问题。为了对披露的实施例的一些方面有一个基本的理解,下面给出了简单的概括。该概括部分不是泛泛评述,也不是要确定关键/重要组成元素或描绘这些实施例的保护范围。其唯一目的是用简单的形式呈现一些概念,以此作为后面的详细说明的序言。
本发明实施例提供一种虚拟设备创建方法,包括:
接收客户端发送的服务调用请求;
根据所述服务调用请求查询创建虚拟设备所需要的成员设备,生成虚拟设备拓扑图;
将生成的所述虚拟设备拓扑图发送给所述客户端;
接收所述客户端返回的修订后的虚拟设备拓扑图,根据所述修订后的虚拟设备拓扑图创建虚拟设备。
在一些可选的实施例中,所述根据所述服务调用请求查询创建虚拟设备所需要的成员设备,生成虚拟设备拓扑图,包括:
根据所述服务调用请求中包括的服务需求信息,查询创建虚拟设备所需要的成员设备,并获取所述成员设备对应的物理设备;所述成员设备包括抽象设备和/或已生成的虚拟设备;
生成包括成员设备对应的物理设备信息和用户修订字段的虚拟设备拓扑图。
在一些可选的实施例中,所述接收客户端返回的修订后的虚拟设备拓扑图,包括:
接收所述客户端通过所述用户修订字段对虚拟设备拓扑图进行修订后返回的修订后的虚拟设备拓扑图。
在一些可选的实施例中,根据所述修订后的虚拟设备拓扑图创建虚拟设备之前,还包括:
将修订后的虚拟设备拓扑图与生成的虚拟设备拓扑图进行比对,确定修订后的虚拟设备拓扑图的完整性。
在一些可选的实施例中,生成的虚拟设备拓扑图中还包括下列信息中的至少一种:服务描述信息和服务触发条件。
本发明实施例还提供一种虚拟设备创建服务器,包括:
接收模块,用于接收客户端发送的服务调用请求,以及接收所述客户端返回的修订后的虚拟设备拓扑图;
生成模块,用于根据所述服务调用请求查询创建虚拟设备所需要的成员设备,生成虚拟设备拓扑图;
发送模块,用于将生成的所述虚拟设备拓扑图发送给所述客户端;
创建模块,用于根据所述修订后的虚拟设备拓扑图创建虚拟设备。
在一些可选的实施例中,所述生成模块,具体用于:
根据所述服务调用请求中包括的服务需求信息,查询创建虚拟设备所需要的成员设备,并获取成员设备对应的物理设备;所述成员设备包括抽象设备和/或已生成的虚拟设备;
生成包括成员设备对应的物理设备信息和用户修订字段的虚拟设备拓扑图。
在一些可选的实施例中,所述接收模块,具体用于:
接收所述客户端通过所述用户修订字段对虚拟设备拓扑图进行修订后返回的修订后的虚拟设备拓扑图。
在一些可选的实施例中,所述创建模块,还用于:
根据所述修订后的虚拟设备拓扑图创建虚拟设备之前,将修订后的虚拟设备拓扑图与生成的虚拟设备拓扑图进行比对,确定修订后的虚拟设备拓扑图的完整性。
本发明实施例还提供一种虚拟设备创建客户端,包括:
发送模块,用于发送的服务调用请求给虚拟设备创建服务器,以及发送修订后的虚拟设备拓扑图给虚拟设备创建服务器;
接收模块,用于接收虚拟设备创建服务器发送的虚拟设备拓扑图,所述虚拟设备拓扑图是虚拟设备创建服务器根据所述服务调用请求查询创建虚拟设备所需要的成员设备后生成的;
修订模块,用于对接收到的虚拟设备拓扑图进行修订。
在一些可选的实施例中,所述接收模块,具体用于:
接收虚拟设备创建服务器发送的包括成员设备信息和用户修订字段的虚拟设备拓扑图;相应的,
所述修订模块,具体用于通过虚拟设备拓扑图中包括的用户修订字段对虚拟设备拓扑图进行修订。
本发明实施例还提供一种虚拟设备创建系统,包括:上述的虚拟设备创建服务器、上述的客户端和至少一个物理设备;其中,虚拟设备创建服务器根据服务调用请求查询到的成员设备为抽象设备和/或已生成的虚拟设备,并可以获取到成员设备对应的物理设备。
本发明实施例提供的虚拟设备创建方法、系统及装置,在创建过程中能够与用户进行交互,并允许用户修改和调整创建要求,以及修改和调整创建虚拟设备所需要的成员设备,从而实现根据用户要求实时调整创建虚拟设备所需要的成员设备,从而更好的很好体现用户的创建要求,更好的满足用户的创建需求,提高虚拟设备的创建满意度和创建出的虚拟设备的使用效果。
为了上述以及相关的目的,一个或多个实施例包括后面将详细说明并在权利要求中特别指出的特征。下面的说明以及附图详细说明某些示例性方面,并且其指示的仅仅是各个实施例的原则可以利用的各种方式中的一些方式。其它的益处和新颖性特征将随着下面的详细说明结合附图考虑而变得明显,所公开的实施例是要包括所有这些方面以及它们的等同。
附图说明
附图用来提供对本发明的进一步理解,并且构成说明书的一部分,与本发明的实施例一起用于解释本发明,并不构成对本发明的限制。在附图中:
图1为现有技术中oneM2M平台支持的三种设备类型示意图;
图2为本发明实施例一中虚拟设备创建方法的流程图;
图3为本发明实施例一中虚拟设备拓扑图的示例图;
图4为本发明实施例二中虚拟设备创建方法的流程图;
图5为本发明实施例二中生成的虚拟设备拓扑图的示例图;
图6为本发明实施例二中修订后的虚拟设备拓扑图的示例图;
图7为本发明实施例中虚拟设备创建系统的结构示意图;
图8为本发明实施例中虚拟设备创建服务器的结构示意图;
图9为本发明实施例中客户端的结构示意图。
具体实施方式
以下描述和附图充分地示出本发明的具体实施方案,以使本领域的技术人员能够实践它们。其他实施方案可以包括结构的、逻辑的、电气的、过程的以及其他的改变。实施例仅代表可能的变化。除非明确要求,否则单独的组件和功能是可选的,并且操作的顺序可以变化。一些实施方案的部分和特征可以被包括在或替换其他实施方案的部分和特征。本发明的实施方案的范围包括权利要求书的整个范围,以及权利要求书的所有可获得的等同物。在本文中,本发明的这些实施方案可以被单独地或总地用术语“发明”来表示,这仅仅是为了方便,并且如果事实上公开了超过一个的发明,不是要自动地限制该应用的范围为任何单个发明或发明构思。
为了解决现有技术中虚拟设备创建过程中,用户不能参与虚拟设备的创建,创建的虚拟设备不能很好体现用户的创建要求的问题,本发明实施例提供一种虚拟设备创建方法,该方法在虚拟设备创建过程中允许用户参与,调整和修改创建要求,以及调整和修改所使用的抽象设备和物理设备,从而能够更好的体现用户需求,创建出更符合用户需求的虚拟设备,该方法是一种用户可定制的虚拟设备创建方法。
实施例一
本发明实施例一提供的虚拟设备创建方法,其流程如图2所示,包括如下步骤:
步骤S201:虚拟设备创建服务器接收客户端发送的服务调用请求。
当用户需要调用某一服务时,客户端向虚拟设备创建服务器发送一个服务调用请求,发送的服务调用请求中包括服务需求信息。
虚拟设备创建服务器接收到服务调用请求后,可以获取到服务需求信息,这里的服务需求可以是用户所需要的服务的业务逻辑、也可以是用户的服务要求、或者是其它虚拟创建服务器能够解读的表现形式。
步骤S202:虚拟设备创建服务器根据接收到的服务调用请求,查询创建虚拟设备所需要的成员设备,生成虚拟设备拓扑图。
虚拟设备创建服务器根据服务调用请求中包括的服务需求信息,查询创建虚拟设备所需要的成员设备,并获取成员设备对应的物理设备,生成包括成员设备对应的物理设备信息和用户修订字段的虚拟设备拓扑图;其中,成员设备包括抽象设备和/或已生成的虚拟设备。拓扑图还能够表明各成员设备或者各成员设备对应的物理设备之间的依存关系。
虚拟设备创建服务器对接收到服务调用请求进行解析,获取其中包括的用户服务需求信息,根据解析出的服务需求信息,查询创建虚拟设备所需要的成员设备,并获取所述成员设备对应的物理设备。其中,成员设备可以是抽象设备也可以是已生成的虚拟设备。
生成的虚拟设备拓扑图中包括成员设备对应的物理设备信息和用户修订字段,优选的,生成的虚拟设备拓扑图中还包括服务描述信息和服务触发条件等。
虚拟设备拓扑图,用于描述虚拟设备各成员设备之间的依存关系。如图3为生成的虚拟设备拓扑图的一个示例图,其中:
每个方框对应于一种服务,图3中示例了五种服务,服务描述信息为服务名,分别是Service-1、Service-2、Service-3、Service-4、Service-5。
每种服务的属性包括该服务对应的物理设备,服务触发条件,以及为用户修改预留的“用户修订”字段。图3中示例的五种服务涉及到的物理设备信息通过设备名Device-1、Device-2、Device-3、Device-4、Device-5分别表示。其服务触发条件和用户修订字段在图3中示例为未定义,实际应用中可以根据应用情况定义。
箭头及标注(notes)表示物理设备间的依存关系——箭头尾部物理设备是否存在,是箭头指向的物理设备存在的前提。以图3为例,若物理设备Device-3从虚拟设备组成方案中被删除,则依存成员设备Device-3存在的成员设备Device-5也将一同被删除。
步骤S203:虚拟设备创建服务器将生成的虚拟设备拓扑图推送给客户端。
虚拟设备创建服务器将虚拟设备拓扑图发送给客户端,以便客户端能够参与修订。
步骤S204:虚拟设备创建服务器接收客户端返回的修订后的虚拟设备拓扑图。
客户端接收到虚拟设备拓扑图,根据具体情况,对虚拟设备拓扑图进行修订、调整,例如:改变某个成员设备,删除某个成员设备对应的物理设备、限定某个成员设备对应的物理设备的使用时间、修改某个成员设备对应的物理设备的启动条件等。客户端可以通过虚拟设备拓扑图中的用户修订字段对虚拟设备拓扑图进行修订。
此时,虚拟设备创建服务器接收客户端通过用户修订字段对虚拟设备拓扑图进行修订后返回的修订后的虚拟设备拓扑图。
步骤S205:虚拟设备创建服务器根据修订后的虚拟设备拓扑图,创建虚拟设备。
虚拟设备创建服务器根据修订后的虚拟设备拓扑图创建虚拟设备,从而可以体现用户对虚拟设备创建的修改和调整意见,使用户能够参与到虚拟设备的创建过程中来,随时对虚拟设备的创建进行修订和调整。
优选的,虚拟设备创建服务器根据修订后的虚拟设备拓扑图创建虚拟设备之前,还可以包括:将修订后的虚拟设备拓扑图与生成的虚拟设备拓扑图进行比对,确定修订后的虚拟设备拓扑图的完整性。
实施例二
本发明实施例二提供的虚拟设备创建方法,其流程如图4所示,包括如下步骤:
步骤S401:客户端向虚拟设备创建服务器发送服务调用请求。
以“室内空气智能净化”服务为例,“室内空气智能净化”服务的业务逻辑为:当室内空气污染指数(API)超过API门限值(APIthreshold)时,启动空气净化服务;同时,为了加速空气污染物挥发,当室内温度(TEMP)低于温度门限值(Tthreshold)时启动制热服务,当室内湿度(HUMID)低于湿度门限值(Hthreshold)时启动加湿服务。
客户端将用户提出的“室内空气智能净化”服务调用请求发送给虚拟设备创建服务器,虚拟设备创建服务器可以是云平台或其他形式的服务器端。“室内空气智能净化”服务调用请求中包含上述“室内空气智能净化”服务需求信息:可以是服务要求、业务逻辑等各种服务需求中的至少一种。
步骤S402:虚拟设备创建服务器根据服务调用请求,查询创建虚拟设备所需要的成员设备,确定其对应的物理设备。
虚拟设备创建服务器对接收到的服务调用请求进行解析,可以通过包括的语义引擎进行解析,查询能够用于满足用户需求的成员设备,包括抽象设备和已生成的虚拟设备中至少一种,并进一步确定其对应的物理设备。
例如:创建虚拟设备所需要的成员设备的查询结果如表1所示。其中,室内空气智能净化所需的服务有空气净化、制热、加湿,以及为了判断室内温湿度是否超过预设的温湿度门限值,还需要引入温湿度监测服务。
表1成员设备查询结果
步骤S403:虚拟设备创建服务器根据查询结果,生成虚拟设备拓扑图。虚拟设备创建服务器根据查询结果构建虚拟设备组成方案,得到虚拟设备拓扑图。
虚拟设备创建服务器获取到成员设备对应的物理设备后,生成“室内空气智能净化”虚拟设备组成方案,以及图5所示的“室内空气智能净化”虚拟设备拓扑图。图5中标注表明,只有当温湿度监测设备存在并提供温度TEMP及湿度HUMID数据时,制热服务及加湿服务才可能被触发。此时,并不实际创建虚拟设备。
如图5所示的,虚拟设备拓扑图中包括的服务有四种:对应的服务描述信息分别为服务名:空气净化、温湿度监测、制热、加湿。其中:
空气净化服务对应的物理设备的设备名为空气净化器,触发条件为API>APIthreshold,用户修订字段未定义。
温湿度监测服务对应的物理成员设备的设备名为温湿度监测设备,无需触发条件,用户修订字段未定义。
制热服务对应的物理设备的设备名为空调,触发条件为TEMP>Tthreshold,用户修订字段未定义。
加湿服务对应的物理设备的设备名为加湿器,触发条件为HUMID>Hthreshold,用户修订字段未定义。
其中,成员设备对应的物理设备空调和加湿器依赖于成员设备对应的物理设备温湿度监测设备存在。
步骤S404:虚拟设备创建服务器将生成的虚拟设备拓扑图推送给客户端。
虚拟设备创建服务器将生成的“室内空气智能净化”原始版的虚拟设备拓扑图推送给客户端。
步骤S405:客户端接收到虚拟设备拓扑图后,对虚拟设备拓扑图进行修订。
客户端可以向用户提供修改功能,用户通过填写用户修订字段,对虚拟设备组成方案进行修改。如,若用户不希望加湿器参与服务,则可在加湿服务的用户修订字段填写“删除”;此外,用户还可为成员设备对应的物理设备设置运行时间等限制条件,如在空气净化服务的用户修订字段填写“运行时间9:00~16:00”。用户修改完成后的“室内空气智能净化”虚拟设备拓扑图如图6所示。
如图6所示修改后的虚拟设备拓扑图中,在空气净化服务框中的用户修订字段增加了运行时间9:00~16:00,在加湿服务框中的用户修订字段增加了删除指示。
步骤S406:客户端将修订后的虚拟设备拓扑图发送给虚拟设备创建服务器。
步骤S407:虚拟设备创建服务器接收到修订后的虚拟设备拓扑图后,检测修订后的虚拟设备拓扑图的完整性。
虚拟设备创建服务器将修订后的虚拟设备拓扑图与初始生成的虚拟设备拓扑图进行对比,检验修订后的虚拟设备拓扑图的完整性。
步骤S408:当确定修订后的虚拟设备拓扑图完整时,根据修订后的虚拟设备拓扑图创建虚拟设备。
虚拟设备创建服务器解析修订后的虚拟设备拓扑图中的用户修订字段,并根据修订后的虚拟设备拓扑图创建虚拟设备。
沿用上边的例子,虚拟设备创建服务器根据修订后的虚拟设备拓扑图创建包括空气净化器、温湿度监测设备、空调三个成员设备的虚拟设备。
步骤S409:虚拟设备创建服务器控制各成员设备对应的物理设备,向用户提供所需服务。
虚拟设备创建服务器创建虚拟设备后,虚拟设备可以向用户提供服务。控制空气净化器、温湿度监测设备、空调等各成员设备对应的物理设备,向用户提供所需的服务。
步骤S410:虚拟设备创建服务器向客户端反馈服务调用结果。
基于同一发明构思,本发明实施例还提供一种虚拟设备创建系统,该系统的结构如图7所示,包括:虚拟设备创建服务器701、客户端702和至少一个物理设备703;其中,虚拟设备创建服务器701根据服务调用请求查询到的成员设备为抽象设备和/或已生成的虚拟设备,并可以获取到成员设备对应的物理设备703。
虚拟设备创建服务器701,用于接收客户端发送的服务调用请求,以及接收客户端返回的修订后的虚拟设备拓扑图;根据服务调用请求查询创建虚拟设备所需要的成员设备,生成虚拟设备拓扑图;将生成的虚拟设备拓扑图发送给客户端;根据修订后的虚拟设备拓扑图创建虚拟设备。
客户端702,用于发送的服务调用请求给虚拟设备创建服务器;接收虚拟设备创建服务器发送的虚拟设备拓扑图,其中,虚拟设备拓扑图是虚拟设备创建服务器根据所述服务调用请求查询创建虚拟设备所需要的成员设备后生成的;对接收到的虚拟设备拓扑图进行修订,发送修订后的虚拟设备拓扑图给虚拟设备创建服务器。
虚拟设备创建服务器701的结构如图8所示,包括:接收模块801、生成模块802、发送模块803和创建模块804。
接收模块801,用于接收客户端发送的服务调用请求,以及接收客户端返回的修订后的虚拟设备拓扑图。
生成模块802,用于根据服务调用请求查询创建虚拟设备所需要的成员设备,生成虚拟设备拓扑图。
发送模块803,用于将生成的虚拟设备拓扑图发送给客户端。
创建模块804,用于根据修订后的虚拟设备拓扑图创建虚拟设备。
优选的,上述生成模块802,具体用于根据服务调用请求中包括的服务需求信息,查询创建虚拟设备所需要的成员设备,并获取成员设备对应的物理设备,其中,成员设备包括抽象设备和/或已生成的虚拟设备;生成包括成员设备对应的物理设备信息和用户修订字段的虚拟设备拓扑图。
优选的,上述接收模块801,具体用于接收客户端通过用户修订字段对虚拟设备拓扑图进行修订后返回的修订后的虚拟设备拓扑图。
优选的,上述创建模块804,还用于根据修订后的虚拟设备拓扑图创建虚拟设备之前,将修订后的虚拟设备拓扑图与生成的虚拟设备拓扑图进行比对,确定修订后的虚拟设备拓扑图的完整性。
客户端702的结构如图9所示,包括:发送模块901、接收模块902和修订模块903。
发送模块901,用于发送的服务调用请求给虚拟设备创建服务器,以及发送修订后的虚拟设备拓扑图给虚拟设备创建服务器。
接收模块902,用于接收虚拟设备创建服务器发送的虚拟设备拓扑图,其中,虚拟设备拓扑图是虚拟设备创建服务器根据服务调用请求查询创建虚拟设备所需要的成员设备后生成的。
修订模块903,用于对接收到的虚拟设备拓扑图进行修订。
优选的,上述接收模块902,具体用于接收虚拟设备创建服务器发送的包括成员设备信息和用户修订字段的虚拟设备拓扑图;相应的,
修订模块903,具体用于通过虚拟设备拓扑图中包括的用户修订字段对虚拟设备拓扑图进行修订。
本发明实施例提供的虚拟设备创建方法,是一种用户可定制的虚拟设备创建方法,服务器端在根据用户需求创建虚拟设备之前,首先生成虚拟设备的构建方案,推荐给用户;用户根据个人意愿,对该方案进行修改裁剪,用户修改完成后,反馈给服务器端;服务器端根据用户反馈结果中的修改后的设备组成方案,创建虚拟设备,为不同用户提供定制化的智能家居服务。
该方法对虚拟设备创建方案进行了改进,在服务器端和用户的客户端之间增加了对虚拟设备组成方案进行交互修改的环节,便于用户进行修改,具体的通过一种表示虚拟设备各成员设备之间依存关系的虚拟设备拓扑图来实现交互修改,便于用户了解虚拟设备的组成方案,并对虚拟设备组成方案进行修改。
该方法允许用户参与虚拟设备的决策及创建过程,更利于为不同用户提供差异化的定制服务,可显著提高智能家居服务的友好程度,进一步改善用户体验效果。
除非另外具体陈述,术语比如处理、计算、运算、确定、显示等等可以指一个或更多个处理或者计算系统、或类似设备的动作和/或过程,所述动作和/或过程将表示为处理系统的寄存器或存储器内的物理(如电子)量的数据操作和转换成为类似地表示为处理系统的存储器、寄存器或者其他此类信息存储、发射或者显示设备内的物理量的其他数据。信息和信号可以使用多种不同的技术和方法中的任何一种来表示。例如,在贯穿上面的描述中提及的数据、指令、命令、信息、信号、比特、符号和码片可以用电压、电流、电磁波、磁场或粒子、光场或粒子或者其任意组合来表示。
应该明白,公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好,应该理解,过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素,并且不是要限于所述的特定顺序或层次。
在上述的详细描述中,各种特征一起组合在单个的实施方案中,以简化本公开。不应该将这种公开方法解释为反映了这样的意图,即,所要求保护的主题的实施方案需要清楚地在每个权利要求中所陈述的特征更多的特征。相反,如所附的权利要求书所反映的那样,本发明处于比所公开的单个实施方案的全部特征少的状态。因此,所附的权利要求书特此清楚地被并入详细描述中,其中每项权利要求独自作为本发明单独的优选实施方案。
本领域技术人员还应当理解,结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性,上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件,取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用,以变通的方式实现所描述的功能,但是,这种实现决策不应解释为背离本公开的保护范围。
结合本文的实施例所描述的方法或者算法的步骤可直接体现为硬件、由处理器执行的软件模块或其组合。软件模块可以位于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质连接至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。该ASIC可以位于用户终端中。当然,处理器和存储介质也可以作为分立组件存在于用户终端中。
对于软件实现,本申请中描述的技术可用执行本申请所述功能的模块(例如,过程、函数等)来实现。这些软件代码可以存储在存储器单元并由处理器执行。存储器单元可以实现在处理器内,也可以实现在处理器外,在后一种情况下,它经由各种手段以通信方式耦合到处理器,这些都是本领域中所公知的。
上文的描述包括一个或多个实施例的举例。当然,为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的,但是本领域普通技术人员应该认识到,各个实施例可以做进一步的组合和排列。因此,本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外,就说明书或权利要求书中使用的术语“包含”,该词的涵盖方式类似于术语“包括”,就如同“包括,”在权利要求中用作衔接词所解释的那样。此外,使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。
最后应当说明的是,以上实施例仅用以说明本发明的技术方案而非限制,本领域的普通技术人员应当理解,可以对本发明的技术方案进行修改或者等同替换,而不脱离本发明技术方案的精神范围,其均应涵盖在本发明的权利要求范围当中。