CN111869186A - 智能服务层请求抽象服务的机制 - Google Patents

Abstract

本文描述了用于使由多个基本操作组成的服务层操作的管理和将执行这种多步操作的负担从请求实体卸载到服务层自动化的系统和方法。本文描述了用于自主执行此类多步操作的请求抽象服务(RAS)。本文还描述了用于服务层框架的方法和装置，该服务层框架用于将通用和功能用户界面集成为由SL代表请求实体管理的服务。

Description

智能服务层请求抽象服务的机制

相关申请的交叉引用

本申请要求于2018年5月7日提交的美国临时专利申请No.62/667,858和2018年10月26日提交的美国临时专利申请No.62/751,075的权益，这些专利申请在此通过引用整体并入本文。

背景技术

物联网(IoT)是一种新兴技术，其中诸如家用电器、机动车辆、消费者电子设备、个人移动设备、环境传感器等日常对象可以连接到诸如因特网之类的网络，并且可以进行远程管理和控制。此类IoT连接设备的多样性可以允许更具创意和更智能的用途，其通过提供更多的便利性和自动化来改善用户的生活。为了管理大量的IoT设备，定义并标准化了服务层架构。此外，在过去的几十年中，用户界面(UI)发生了显著的演进，从普通的显示器和键盘到鼠标、触摸屏、触觉设备等。逐渐地，越来越多的传感器已被添加到消费者设备中来确定用户的动作，诸如分析手势、检测眼睛移动、解释方向、速度等。越来越多的提供反馈的方法也以无数的音频、触觉或视觉形式等被开发。虽然复杂的机器(诸如，通用计算机之类)具有对复杂交互的处理能力和需求，但是在物联网(IoT)世界中，这些需求和能力可能都会降低。因此，需要在IOT机器对机器(M2)服务层(SL)中增强通用用户界面的集成。

图1是支持M2M/IoT服务层的示例协议栈100的图。从协议栈的角度来看，中间件服务层通常层叠在现有网络协议栈之上，并为客户端应用以及其它服务提供增值服务。因此，服务层通常被归类为“中间件”服务层。例如，图1示出了位于IP联网栈和应用之间的服务层102。如图1的示例所示，除了服务层102之外，该协议栈100可以包括应用层101、应用协议层103(例如，HTTP、OCAP或MQTT)、传输协议层104(例如，TCP或UDP)、网络协议层105(例如，IPv4或IPv6)以及接入网络协议层106(例如，以太网、蜂窝、Wi-Fi)。服务层102实例可以被部署在各种网络节点(网关和服务器)上，并且可以向网络应用、设备应用以及向网络节点自身提供增值服务。

M2M/IoT服务层是一种类型的中间件服务层102的示例，该中间件服务层102专门旨在为M2M/IoT类型的设备、应用和数据提供增值服务。一些行业标准体(例如，oneM2M、OCF、ETSI M2M和OMA LWM2M)已经在开发M2M/IoT服务层，以解决与将M2M/IoT类型的设备和应用集成到诸如因特网/Web和蜂窝、企业和家庭网络之类的部署中相关联的挑战。

M2M服务层可以向应用和设备提供对服务层所支持的以M2M为中心的能力的集合的访问，该能力可以包括但不限于以下示例：安全性、收费、数据管理、设备管理、发现、供应和连接性管理。可以经由应用编程接口(API)使这些能力对应用可用，应用编程接口利用由M2M服务层支持的消息格式、资源结构和资源表示。

图2是示例M2M/IoT部署200的图。从部署的角度来看，M2M/IoT SL可以被部署在各种类型的网络节点上，包括例如服务器、网关和设备，如图2所示。图2的系统示出了M2M/IoT应用201、执行M2M/IoT SL 203的M2M/IoT服务器202、执行连接到M2M/IoT设备209的M2M/IoT SL 205的M2M/IoT网关204，以及执行M2M/IoT SL 207的M2M/IoT设备207。

oneM2M标准定义了M2M/IoT SL。SL的目的是提供可以被不同的“垂直”IoT系统和应用(诸如电子卫生(e-Health)、车队管理和智能家居之类)利用的“水平”服务。图3是示例oneM2M架构300的图。oneM2M SL的架构300可以包括可以支持四个参考点的公共服务实体(CSE)。Mca参考点可以与应用实体(AE)交互。Mcc参考点可以与同一服务提供商域内的另一个CSE接口，并且Mcc'参考点可以与不同服务提供商域内的另一个CSE接口。Mcn参考点可以与底层网络服务实体(NSE)接口。NSE可以向CSE提供底层网络服务，诸如设备管理、位置服务和设备触发之类。如图3的示例所示，在现场域(field domain)301中，AE 310与Mca参考点330和Mca参考点332接口。CSE 311与Mcc参考点333接口，Mcc参考点333与基础设施域302中的CSE 321接口。NSE 312与Mcn参考点331接口。在基础设施域302中，AE 320与Mca参考点334接口。CSE 321与Mcc'参考点336接口以到达另一个服务提供商323的基础设施域。NSE322与Mcn参考点335接口。

CSE可以包括被称为公共服务功能(CSF)的多个逻辑功能。CSF包括但不限于发现和数据管理&储存库。

图4是oneM2M中支持的示例CSF 400集合的示意图。服务层在功能上由CSF启用。一组CSF可以被实例化为一组公共服务实体(CSE)401，如图4所示。CSF及其功能的示例可以包括以下内容：

应用和服务层管理CSF 402：可以提供AE和CSE的管理。

发现CSF 403：可以基于一些过滤标准来搜索关于应用和服务的信息。

注册CSF 404：可以为AE(或其它远程CSE)提供向CSE注册的功能。这可以允许AE(或远程CSE)使用CSE的服务。

通信管理/传递处理CSF 405：可以提供与其它CSE、AE和NSE的通信。该CSF可以决定在什么时间和哪个通信连接用于传递通信，并且在必要和允许的情况下，缓冲通信请求，以便可以在以后的时间转发通信请求。

组管理CSF 406：可以提供与组相关的请求的处理，并使M2M系统能够支持例如对多个设备、应用等的批量(bulk)操作。

安全CSF 407：可以为服务层提供安全功能，诸如访问控制，包括标识、认证和授权。

数据管理和储存库CSF 408：可以提供数据存储和中介功能(例如，收集数据以进行聚合、重新格式化数据以及存储数据以进行分析和语义处理)。

位置CSF 409：可以提供使AE能够获得地理位置信息的功能。

服务收费和计费CSF 410：可以为服务层提供收费功能。

设备管理CSF 411：可以提供M2M网关和M2M设备上的设备能力的管理。

网络服务公开、服务执行和触发CSF 412：可以管理与底层网络的通信以访问网络服务功能。

订阅和通知CSF 413：可以提供允许订阅事件并在该事件发生时得到通知的功能。

图4还示出了组管理CSF 419和语义CSF 420。

oneM2M架构可以提供CSE 401以通过Mca参考点414、Mcc(和Mcc')参考点415和Mcn参考点416与其它实体接口，其它实体包括但不限于：AE 417；其它CSE；以及网络服务实体(NSE)418(即，底层网络)。

请求者与服务层之间的交互可以基于其中可以针对在服务层维护的资源执行原子操作的RESTful原理。资源或服务层资源可以是包含信息(例如，数据)的唯一可寻址对象(即，数据结构)，并且可以由M2M/IoT服务层托管。可以经由统一资源标识符或URI访问资源。原子操作本身可以是无状态的，这意味着请求者与服务层之间的通信是在特定请求内自包含的。请求可以包括自描述消息，该自描述消息包括操作的方法、URI以及可能由资源使用的一些数据或元数据。

在描述SL时，以下定义是有用的。虽然针对M2M/IoT系统描述了以下定义，但是它们可以适用于任何此类类似系统。

M2M/IoT服务层(SL)可以是软件中间件层，其通过应用编程接口(API)集合和底层联网接口支持用于M2M/IoT应用和设备的增值服务。SL可以包括可以由设备、应用和用户使用的M2M/IoT服务的集合。SL也可以托管资源。

M2M/IoT应用可以是注册到M2M/IoT服务层并执行与特定M2M/IoT用例(诸如例如eHealth、智能能源或家庭自动化之类)相关的特定于应用的功能的软件实体。

M2M/IoT实体可以是M2M/IoT应用或M2M/IoT设备或M2M/IoT应用或M2M/IoT设备的用户。

M2M/IoT服务可以是向M2M/IoT实体提供能力(例如，数据管理、安全性、设备管理)的软件实体。

服务层实体可以是登记和/或注册到M2M/IoT服务层的M2M/IoT实体。示例可以包括M2M/IoT应用或M2M/IoT服务层的实例。

服务层设备可以是注册到M2M/IoT服务层并且可以托管一个或多个应用的实体。

服务层原语(Primitive)可以是使用服务层API来访问由服务层提供的数据或服务的消息。服务层请求和服务层响应是服务层原语的示例。

服务层请求可以是由服务层实体发布的针对服务层资源的操作。

M2M/IoT服务层注册可以是M2M/IoT服务层实体向M2M/IoT服务层注册的行为(act)。

M2M/IoT注册者可以是向M2M/IoT服务层注册或使用M2M/IoT服务层的M2M/IoT实体，诸如例如应用、传感器、设备和/或其它M2M/IoT服务层之类。

M2M/IoT服务平台可以是由M2M/IoT服务提供商部署的可以可选地托管M2M/IoT服务层的平台。

M2M/IoT服务提供商可以是负责M2M/IoT服务平台的部署和管理的利益相关者(例如，公司)。

M2M/IoT服务订户可以是与M2M/IoT服务提供商建立订阅(即，登记)以访问和使用其M2M/IoT服务的利益相关者(例如，人)。

M2M/IoT服务登记可以是M2M/IoT服务订户与M2M/IoT服务提供商建立服务订阅并利用服务提供商的平台登记其设备、应用、数据和授权用户的行为。

M2M/IoT用户可以是与M2M/IoT服务订户相关联的授权实体。M2M/IoT服务订户可以向指定的M2M/IoT用户授予指定的特权，以经由M2M/IoT服务提供商的平台访问指定的设备、应用、数据和服务。

如本文所描述的，持久化可以指超出创建数据的操作在计算机系统中存储数据。此类数据可以保留在计算机系统中，直到被删除或受到损坏。预持久化可以指在存储数据之前执行的过程。后持久化可以指在存储数据之后执行的过程。

元数据可以是提供关于其它数据的信息的数据。

oneM2M架构是分布式架构，并且支持跨以下类型的节点以分布式方式部署M2M/IoT服务：应用服务节点(ASN)；应用专用节点(ADN)；中间节点(MN)；基础设施节点(IN)；以及非oneM2M节点(NoDN)。

ASN是包括一个CSE并且包括至少一个应用实体(AE)的节点。在示例实施例中，ASN可以驻留在IoT设备中。

ADN是包括至少一个AE并且可以不包括CSE的节点。在示例实施例中，应用专用节点可以驻留在受约束的IoT设备中。

MN是包括CSE并且包括零个或更多个AE的节点。在示例实施例中，MN可以驻留在IoT网关中。

IN是包括CSE并且包括零个或更多个AE的节点。IN中的CSE可以包括不适用于其它节点类型的CSE功能。在示例实施例中，IN可以驻留在IoT服务基础设施中。

非oneM2M节点是可以不包括oneM2M实体(既不包括AE也不包括CSE)的节点。此类节点可以表示出于互通目的(包括管理)而附接到oneM2M系统的设备。

图5是将oneM2M系统500内支持的各种实体互连的配置图。系统500可以包括可以互连并且可以管理多个IoT设备的多个IoT服务器(在本文中也被称为CSE)。本文使用的术语IoT服务器可以指云服务器、边缘网关或家庭网关(即，在IoT系统内提供IoT服务的任何实体)。该架构可以被划分为两个主要域：基础设施域501和现场域502。基础设施域501可以包括用作系统500的主控制器的云服务器，其在图5中表示为图5中的基础设施节点503b中的IN-CSE 503a。现场域可以包括位于各种位置的现场部署的IoT服务器，这些位置包括但不限于工厂、办公楼或家庭。这些服务器在图5中被表示为中间节点504b中的MN-CSE 504a和中间节点505b中的MN-CSE 505a。现场域502还可以包括运行在诸如例如服务卡车或移动电话之类的移动设备上的移动IoT服务器。这些移动设备在图5中被表示为ASN 506b中的ASN-CSE 506a和ASN 507b中的ASN-CSE 507a。IoT设备在图5中被表示为ADN 508a和508b以及NoDN 509a、509c、509d、509f和509g，其中每个节点都与系统中的CSE之一通信。

发明内容

某些服务层操作本质上是基本的，并且可能彼此相关。但是，这样的操作通常以零碎的方式执行，需要请求实体(即，应用或用户)的主动参与。即使在请求执行批量操作时，也可能需要请求实体在发起批量处理之前收集大量信息，并且可能直到处理的后期才能收集到附加的所需信息。再次，这需要请求实体的主动参与。在处理的每个步骤期间，手动执行相关服务层操作并提取相关数据而给请求者增加负担并非是有效且可扩展的方法。同样，在过去的几十年中，各种用户界面已发生了显著的演进，从普通的显示器和键盘到鼠标、触摸屏、触觉设备等。越来越多的传感器已被添加到消费者设备中来确定用户正在试图做什么，诸如分析手势、检测眼睛移动、解释方向、速度等。越来越多的提供反馈的方法也以无数的音频、触觉或视觉形式等被开发。虽然复杂的机器(诸如通用计算机之类)具有对复杂交互的处理能力和需求，但是在物联网(IoT)世界中，这些需求和能力可能都会降低。许多设备使用若干基本交互就可以很好地执行；因此，只要知道需要执行哪个功能，人就可以出于各种目的只使用一些与同一设备非常简单的交互。类似地，可以将相同的简单交互用于各种设备，例如，滑尺(sliding scale)是立体声的音量功能、洗衣机的温度设置、相机中的变焦等所需的基本输入。

本文描述了用于使由多个基本操作组成的服务层操作的管理和将执行这些多步操作的负担从请求实体卸载到服务层自动化的系统和方法。本文描述了用于自主执行此类多步操作的请求抽象服务(RAS服务)。本文中还描述了用于服务层框架的方法和装置，该服务层框架用于将通用和功能用户界面集成为由SL代表请求实体管理的服务。在本文中被称为“交互器”的这些用户界面处理用户交互，并产生通用和功能事件，这些事件被转换成输入/输出。本文中还描述了定义交互上下文管理(ICM)服务的方法和装置，该服务评估上下文并维护对应的上下文状态。ICM服务使用上下文状态来评估基于用户交互的事件并提供它们与特定于应用的事件之间的映射。ICM可以被配置有与交互器相关的模板和策略，例如交互器库。请求实体可以通过发现交互器库或各个模板来查询和发现由SL提供的与交互器相关的能力。根据本文描述的方法和装置，应用可以提供关于其自身与交互器相关的能力的信息。此外，ICM可以被配置有规则和参数，这些规则和参数使ICM能够监视SL并相应地维护和切换上下文状态。ICM可以代表应用实例化交互器，使得对系统中的用户交互及其功能和与应用操作的对应关系有共同的理解。关联应用和交互器的处理可以允许在系统中根据上下文使用多个交互器。

提供本发明内容是为了以简化的形式介绍一些概念，这些概念将在下面的具体实施方式中进一步描述。本发明内容不旨在识别所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中提到的任何或所有缺点的限制。

附图说明

为了促进对本申请的更稳健的理解，现在参考附图，在附图中，相同的元件用相同的附图标记表示。这些附图不应被解释为限制本申请，而仅是示例性的。

图1图示了示例协议栈，该示例协议栈在应用协议和应用之间具有服务层；

图2图示了示例M2M/IoT部署；

图3图示了示例oneM2M服务层架构；

图4图示了由oneM2M当前定义的示例CSF；

图5图示了由oneM2M支持的示例配置；

图6图示了基本服务层操作的示例；

图7图示了智能请求抽象服务(RAS)的示例部件；

图8图示了用于处理抽象请求的示例序列图；

图9图示了用于将上下文信息添加到RAS的示例序列图；

图10图示了用于通过RAS请求上下文信息的示例序列图；

图11图示了RAS的部件与服务层之间的交互的示例调用流程；

图12图示了用于重用抽象请求的示例序列图；

图13图示了实现RAS功能的示例公共服务实体(CSE)；

图14图示了示例图形用户界面(GUI)；

图15是支持初始公共服务功能(CSF)集合的示例oneM2M服务层的图；

图16是集成多种设备和家电的示例家庭控制平台的图；

图17是根据一个实施例的描绘交互器、用户交互、Ix-事件、Ax-事件和SL ICM之间的信令的示例系统的图；

图18A是描绘交互器、用户交互、Ix-事件、Ax-事件和SL ICM之间的信令的另一个示例系统的图；

图18B是使用嵌入式应用的UI来实现常规范例的系统的图；

图19A是用于一个交互器的一个用户界面样式的示例；

图19B是用于另一个交互器的另一个用户界面样式的示例；

图19C是用于另一个交互器的另一个用户界面样式的示例；

图20是根据一个实施例的、可以与本文描述的任何实施例结合使用的示例系统的图，在该系统中，SL根据上下文向应用提供使用两个不同的交互器的能力；

图21是根据另一个实施例的、可以与本文描述的任何实施例结合使用的示例交互器状态机的图；

图22是根据一个实施例的、可以与本文描述的任何实施例结合使用的用于在ICM中使用的示例过程的图；

图23是根据一个实施例的、可以与本文描述的任何实施例结合使用的用于将用户交互转换成交互器事件的示例过程的图；以及

图24A是其中可以实现一个或多个公开的实施例的示例机器对机器(M2M)或物联网(IoT)通信系统的系统图；

图24B是可以在图24A所示的M2M/IoT通信系统内使用的示例架构的系统图；

图24C是可以在图24A所示的通信系统内使用的示例M2M/IoT终端或网关设备的系统图；以及

图24D是其中可以实施图24A的通信系统的各方面的示例计算系统的框图。

具体实施方式

本文描述了用于使由多个基本操作组成的服务层操作的管理和将执行这些多步操作的负担从请求实体卸载到服务层自动化的系统和方法。

以下是与可能在以上描述中出现的服务级别技术相关的首字母缩写词的列表。除非另有说明，否则本文中使用的首字母缩写词是指下面列出的对应术语。

ADN 应用专用节点

AE 应用实体

API 应用编程接口

ASE 自动化服务登记

App 应用

ASE-C 自动化服务登记客户端

ASE-S 自动化服务登记服务器

ASN 应用服务节点

CRUD 创建、检索、更新、删除

CSE 公共服务实体

CSF 公共服务功能

IN 基础设施网络

IoT 物联网

IP 因特网协议

M2M 机器对机器

MN 中间节点

NoDN 非oneM2M节点

PoA 访问点

RAS 请求抽象服务

REST 代表性国家转移

ROA 资源定向架构

SL 服务层

URI 统一资源标识符

在M2M/IoT(在下文中称为“IoT”)部署中，某些服务层操作可能涉及或跟随多个基本操作的处理。这样的基本操作可能彼此相关。例如，资源发现请求可能跟随针对每个发现的资源创建访问控制策略或更新那些资源的到期时间的请求。

传统上，这样的基本操作的处理可能需要请求实体的持续参与，尽管每次请求实体请求服务层操作时，都可能执行相同或相关的基本操作。请求实体的持续参与在许多方面可能给请求实体带来负担。

考虑关于智能工厂中的处理的用例。图6图示了用于基本服务层操作的示例方法600。请求实体或“请求者”602(例如，用户或应用)可以与服务层601执行一个或多个基本操作，以向新访问者授予访问权限。对于此用例，假设财务分析人员正在访问制造公司的智能工厂，以访问公司内部采用的IoT技术。请求者602可以首先为分析人员创建访问控制策略(ACP)，使得可以向分析人员授予进入智能工厂的权限。该处理由图6的步骤611、612和613示出。请求者602可以在步骤4中保存所创建的资源的资源标识符以供将来使用。请求者602还可能发现分析人员正在游览的工厂西翼的门锁，如图6的步骤615、616和617所示。在步骤618处，请求者602可以解析接收到的发现响应消息，并且可以选择从发现请求中找到的门锁的URI。对于所选择的门锁，请求者602可以使用在步骤614中保存的资源标识符来更新适当的访问控制策略属性(例如，acpID属性)。可以针对在步骤618中选择的每个门锁执行步骤619、620和621。

智能工厂用例描述了基本操作的相互依赖性。例如，在步骤619、620和621中执行的acpID更新可能需要步骤4中保存的资源标识符和步骤618中发现的门锁列表。此外，在步骤618中发现的结果的数量可以改变步骤619、620和621的重复次数。由于这种依赖性，可能无法为图6的调用流程和其它类似的调用流程生成批(batch)请求。批请求或批量请求生成可能需要请求者在执行批量请求之前为请求提供信息。在智能工厂用例中，仅在执行步骤611和615之后，所需信息才可用。在发出步骤611请求之前，并非步骤619所需的所有信息都可用。因此，用例中描述的调用流程无法用作批量请求。

图6图示了基本但相关请求的请求者的另一个负担。如步骤613、614、617和618处的处理所示，请求者可能负担有提取响应中返回的数据的任务。在图6中，请求者必须保存在步骤614中提取的资源ID，以供将来在后面的步骤中使用。另外，在步骤618中解析的资源发现结果可能较大，并且可能需要请求者保存用于随后的更新操作的URI。请求者可能还必须做出大量请求或一个大批量请求，其中包含来自步骤614和618的已保存信息。在该用例中，请求者必须手动执行在图6的步骤619、620和621处突出显示的服务层请求。

服务层可以就位以执行这样的操作来减轻请求者手动执行操作的麻烦。服务层具有处理响应中提供的信息并将其用作另一个请求的输入的能力。基本操作可能是可以在服务层内例行执行并且简单地用于服务层处理的必要操作。服务层架构(诸如oneM2M之类)缺乏请求者指定抽象请求的能力，该抽象请求将导致多个基本操作序列的执行。

本文描述的能力和示例实施例可以提供上述问题及其它问题的解决方案。描述了用于使由多个基本操作组成的服务层操作的管理和将执行这些多步骤操作的负担从请求实体卸载到服务层自动化的系统和方法。本文描述了用于自主执行这种多步操作的请求抽象服务(RAS)。

RAS可以能够在服务层接受并解释更高的抽象请求，并执行由该请求推断或与其相关联的基本操作。RAS可以能够使请求者免于手动执行多个基本操作。对于请求者手动执行可能很麻烦的公共操作，服务层可以支持这样的基本操作。例如，如上所述，请求者可能需要从请求中解析和提取数据，并在将来的请求中使用此类数据。解析和提取数据的基本操作可以由一个或多个服务层支持。可以使RAS可以用于执行数据的解析和提取，并且还可以在服务层内执行作为结果的操作。

RAS可以管理由服务层提供的服务。RAS可以提供一个或多个处理功能，例如以下的处理功能。

RAS可以定义请求者可以通过其将更高级别的抽象请求传送到服务层的一种或多种方法。可以为抽象请求定义结构，该结构可以利用语义或某些单词结构，更适合于发出命令。这样的单词结构可以简化请求抽象服务的操作。

RAS可以定义一种或多种机制来动态地处理抽象请求。这样的机制可以提供抽象请求的分解、请求的元素的分类、请求元素与SL操作的关联和/或从请求中确定上下文信息。

RAS可以生成对服务层操作进行调用的一个或多个应用编程接口(API)。作为这种生成的一部分，智能API生成器可以分解抽象请求，并使用上述机制的输出来生成API，这些API在被调用时执行服务层操作以实现抽象请求的期望结果。

RAS可以定义用于服务层操作排序以执行所生成的API的一种或多种机制。操作排序器(sequencer)可以与服务层交互以执行多个操作来完成抽象请求。请求抽象服务可以将状态返回给请求者，并且可以包括为完成抽象请求而进行操作的服务层动作和/或资源的列表。

RAS可以定义一种或多种方法以使请求者能够向RAS动态提供上下文信息。这样的方法可以使用抽象请求来向请求抽象服务提供上下文信息。可以将上下文信息保存在RAS的一个或多个部件中，以提高RAS的推理能力。替代地或附加地，RAS可以提示请求者(1)定义RAS不能解决的某些上下文，或者(2)在确定抽象请求中缺少上下文时提示请求者。

RAS可以定义一种或多种方法，通过该方法可以重用抽象请求。这样的方法可以包括将现有的抽象请求保存为资源，并在指定用于覆盖现有上下文信息的新上下文信息的同时，在新的抽象请求中识别该资源。

RAS可以定义一种结构化格式，在该结构化格式中可以向服务层做出抽象请求。结构化格式可以使用语言构造，并且可以包括至少三个主要部件：命令谓词(commandpredicate)、一个或多个命令对象(command object)以及一个或多个命令上下文(commandcontext)。应该认识到的是，术语“谓词”用于参考抽象请求的谓词动词，其可以指定所请求的服务层操作。抽象请求的结构可以定义如下：<Command_Predicate>{(一个或多个)修饰词(一个或多个)Command_Object}{(一个或多个)修饰词(一个或多个)Command_Context}。

Command_Predicate可以指服务层操作。

(一个或多个)Command_Object可以表示由请求隐含的一个或多个主题/对象。

(一个或多个)Command_Context可以表示请求的一个或多个上下文。上下文可以指要对其进行操作的资源的数量、要对其进行操作的资源的类型和标识符/名称、适用于请求的持续时间以及适用于请求的期望位置。

另外，抽象请求中可以包括一个或多个修饰词(modifier)，以进一步描述(一个或多个)Command_Object和/或(一个或多个)Command_Context。这样的修饰词可以描述数量、添加过滤标准或使服务层操作与请求相关。

虽然可以如上所定义的那样结构化抽象请求，但是抽象请求可以采用能够传达相同或相似信息的任何其它形式。例如，抽象请求可以包括请求消息或其它数据结构，该请求消息或其它数据结构包括与以上所定义的参数相关联的信息。

可以使用定义的抽象请求结构创建的示例抽象请求至少包括以下内容：“Turnoff all lights on the second floor and lock all outside doors(关闭第二层的所有灯并锁上所有外门)”；“Turn on the water valve in the lab and close it in 15minutes(打开实验室中的水阀并在15分钟时将其关闭)”；“Update firmware for allsensors with version 1.3d but not for sensors with version 1.3a(更新所有版本为1.3d的传感器的固件，但不更新版本为1.3a的传感器的固件)”；“Give<guest>access toroom 123 and to swimming pool and to fitness center(给予<客人>对123室、游泳池和健身中心的访问权)”；以及“Group all street lights between 1st and 10thstreets(将第1条至第10条街道之间的所有街灯分组)”。

SL请求者可以经由请求抽象服务可以提供的各种接口来发出抽象请求。抽象请求可以通过编程方式作为针对已定义URI的请求消息发送到服务层的公开接口。用于发送抽象请求的另一种方法可以经由服务层提供的一个或多个图形用户界面来实现，诸如可经由诸如因特网、平板电脑或电话之类的网络使用的web界面。

RAS可以将接收到的抽象请求分解成各个部分。RAS还可以确定要执行的SL操作。RAS还可以与服务层交互以执行SL操作并完成抽象请求。可以定义RAS的各种部件。

图7示出了示例RAS 700的部件。RAS 700可以执行抽象请求703的逻辑分析704以对请求的各个单词进行分类。关键词检测部件702和上下文推导部件705可以收集关于抽象请求703的信息。这样的信息可以被API生成器706用来生成要由服务层执行的请求。操作排序器707可以与服务层708接口以执行实现抽象请求并向请求者返回状态或输出709的操作。

图8图示了用于处理抽象请求800的示例序列图。注意在图8中，RAS 801被示出为与服务层802分离；但是，RAS 801也可以被集成为服务层802的一部分或者与服务层802位于同一位置。

在步骤811处，请求者803可以向服务层802发出或发送抽象请求。上面描述的智能工厂用例的抽象请求的示例可以包括发出以下命令：“Give<analyst>access to alldoors in the west wing for only today(仅在今天给予<分析人员>对西翼的所有门的访问权)”。

在步骤812处，服务层802可以接收并处理请求。SL 802可以执行消息验证，并且还可以认证和/或授权请求者。也可以执行其它以SL为中心的处理。服务层802还可以以上述方式或以任何其它合适的方式来结构化抽象请求。

在步骤813处，服务层802可以将抽象请求发送到RAS 801以进行进一步处理。

在步骤814处，RAS 801可以对抽象请求执行逻辑分析以确定抽象请求的底层词语。RAS 801可以提取并分离这样的词语。这些词语可以在调用流程的后续步骤中被转换成服务层操作。作为逻辑分析的一部分，可以将一个或多个单词和/或单词组分类为它们各自的分类，如本文所描述的。

在步骤815处，RAS 801可以将分类的单词和单词组发送到关键词检测单元，该关键词检测单元可以将SL操作与单词相关联。另外，如果这样的关系可用，那么可以创建请求链接关系，以将请求排序在一起并生成期望的输出。例如，资源发现请求的输出可以链接到请求的输入，以创建用于发现的资源的访问控制策略。对于智能工厂用例，可以为位于智能工厂西翼的门创建访问控制策略。

在步骤816处，逻辑分析输出还可以用于确定关于抽象请求的上下文。智能API生成器可以使用此类上下文来确定对要执行的SL操作进行排序的有利方式。可以确定并在智能API生成中使用诸如资源的数量、标识符和名称、持续时间以及期望位置之类的上下文。

步骤817和818可以在抽象请求的元素未被识别和/或抽象请求中缺少上下文信息(例如，位置或时间信息)时被执行。

在步骤817处，RAS 801可以经由SL提示请求者提供所考虑的上下文或上下文信息。

在步骤818处，请求者803可以用可识别的上下文定义来响应。注意的是，如果不能从抽象请求的多个元素中确定一个以上的上下文和/或如果缺少附加的上下文信息(例如，位置，时间)，那么可能存在步骤817和818的多次迭代。例如，抽象请求“Give<analyst>access to all doors in the west wing(给予<分析人员>对西翼的所有门的访问权)”可以被确定为缺少创建访问控制策略所需的时间部件。当创建访问控制策略时，RAS可以提示请求者应用于访问控制策略的持续时间。对于所请求的上下文是可选的情况，请求者可以在响应消息中提供值，或者可以拒绝请求并让服务层分配默认值。如果没有为强制性元素提供上下文，那么RAS可以生成错误、中止操作以及跳至步骤11。

在步骤819处，智能API生成器可以确定如何对SL操作进行排序。智能API生成器还可以确定每个请求所需的输入参数(如果存在的话)。智能API生成器可以通过使用从步骤4-6确定的逻辑分析、关键词检测和上下文推导部件的结果，以及由请求者在步骤8中提供的信息来执行这种确定。智能API生成器可以将SL操作链接在一起以生成期望的输出。但是，注意的是，智能API生成器的操作可能会受到服务层关于API构造的能力的限制。对于不支持灵活API的服务层，智能API生成器可能仅限于执行可用API的功能以及执行后处理以生成期望的结果。对于可以支持灵活API或RAS的高级操作的服务层，附加的操作也是可能的，例如，SL操作的输出可以被转发到另一个SL操作的输入。

在步骤820处，智能API生成器可以与服务层802交互以执行在先前步骤中生成的操作。操作排序器可以用于管理与服务层的交互。操作排序器和服务层之间可能存在多个交互。在RAS与SL 802集成的情况下，交互可以在服务层802内部发生。

在步骤821处，步骤820的结果可以以适当的状态返回给请求者803。这样的结果可以在响应消息中经由服务层从RAS发送到请求者。响应消息还可以包括对执行了哪些动作以及与那些动作相关联的一个或多个结果的指示。如果步骤10的操作成功，那么可能已经创建适当的服务层资源。在那些情况下，可以将创建、更新或删除的SL资源URI的列表发送给请求者。如果步骤10中的操作不成功，那么RAS可以提供操作的序列以及在哪一点处发生故障的详细信息。

请求者可以利用RAS的接口来提供用于处理抽象请求的上下文输入。在图8的步骤817和818中示出了这样的示例利用。提供上下文数据的各个请求也可以作为独立的抽象请求单独给出，并且此类上下文数据可以由RAS存储以用于处理将来的请求。例如，RAS可以将上下文数据存储为策略的规则或存储在上下文推导部件的查找表中。上下文输入还可以包括可以被添加到关键词检测器以识别相关联的SL操作的新词语。然后可以在将来的抽象请求中使用和引用新的上下文信息。例如，可以在初始部署期间将关于智能工厂西翼位置的上下文信息提供给RAS。可以使用地理围栏数据来建立智能工厂的边界，并且可以将智能工厂的西部部分定义为地理围栏区域内的一个或多个位置。请求者还可以向RAS提供GPS设备的坐标，以定义智能工厂的西翼所覆盖的区域。可以使用如本文描述的抽象请求来执行与RAS的这种交互，其中此类请求可以向RAS添加上下文信息，而不是请求RAS在SL上执行一个或多个操作。例如，抽象请求“Define the area for the west wing to be<geofencedata>in the context derivation component(在上下文推导部件中将西翼的区域定义为<地理围栏数据>)”可以用于配置智能工厂西翼的地理围栏区域。

请求者还可以提供词语的上下文信息，这些上下文信息当将来的抽象请求中使用那些词语时可以允许RAS识别这些词语。这样的上下文信息可以存储在上下文推导部件中以识别可以推断出对SL资源或参数的关联或引用的单词。例如，除了提供给“west wing(西翼)”的地理围栏数据之外，词语“west wing”也可以被归类为位置。将词语归类为位置可以指示需要利用SL内的位置服务。类似地，可以在可以与时间函数相关联的上下文推导部件中定义各种时间格式，诸如小时:分钟:秒(hh:mm:ss)。可以将其它上下文信息提供给RAS，以改善对上下文信息的检测。

请求者可以以比现有SL架构中描述的抽象级别更高的抽象级别向RAS发出抽象请求。这样的请求可以使用可以用于代表请求者推断SL操作的执行的语言构造。因为这些抽象请求可以用于指导服务层要执行的动作，因此可以仅利用语言构造的子集来发出命令。

文本格式的抽象请求可以被路由到逻辑分析部件以分离请求中的单词。可以将结果得到的单词分类为适当的单词类别(例如，词性)，诸如名词、动词、形容词、副词、介词、连词等。可以对每个单词分别进行这样的分类。

逻辑分析器可以基于诸如子句和短语之类的句子结构执行附加类型的分类。对于此类分类，可以将单词组组合以形成子句或短语。逻辑分析器可以确定如何形成这样的单词组以检测和标记适当的单词组。例如，短语可以是一组可以以介词开头并且可以以名词结尾的相关单词，而子句可以是一组既包含主语又包含动词的相关单词。使用这样的定义，逻辑分析器可以将单词分组为分类。表1示出了由逻辑分析器针对示例抽象请求“Give<analyst>access to all doors in the west wing for only today(仅在今天给予<分析人员>对西翼的所有门的访问权)”执行的分类示例。

表1-逻辑分析分类类型示例

关键词检测和相关联部件可以确定由抽象请求推断出的适当的服务层操作。因为请求是在更高的抽象级别给出的，因此可能存在对多个SL操作的隐含引用，这些隐含引用在最初观察时可能并不明显。例如，抽象请求“Give<analyst>access to all doors inthe west wing for only today(仅在今天给予<分析人员>对西翼的所有门的访问权)”可能暗示执行抽象请求需要多个SL操作—存在对发现资源和创建和/或更新资源的要求。为了实现这样的要求，可以将关键词检测器编程为识别可以与服务层操作相关联的关键词。表2示出了关键词检测器可以识别并与SL操作相关联的单词的示例。注意的是，词语“Associate(关联)”和“Define(定义)”用于抽象请求，这些抽象请求在请求抽象服务中更新上下文，而不是执行SL操作。通过使用此类词语，可以将附加的单词添加到RAS，以支持请求者在将来的抽象请求中可以利用的更广泛的词汇集。

表2-与SL操作的关键词关联示例

使用关键词关联和逻辑分析所提供的分类，关键词检测器可以能够确定执行抽象请求所需的潜在SL交互。动词的分类可以确定可能需要的SL操作，诸如资源发现、对资源执行CRUD操作、启用或禁用功能等。名词分类可以确定要对其进行操作的SL实体、资源、属性或元数据。关键词检测器可以首先识别由逻辑分析报告的子句以定位可以用于确定抽象请求的一个或多个适当的SL操作的动词。然后，关键词检测器可以定位名词以识别动词可以应用于的服务层实体，并将其注释为“对象(object)”。对象可以被进一步分类为主要对象或次要对象—主要对象可以是在子句中找到的对象，而次要对象可以是在短语中找到的对象。在一些情况下，主要对象可能还不存在于服务层中，因为它们可能是抽象请求所考虑的对象，而次要对象可以被假定为已存在于服务层中。表3示出了上述示例抽象请求的关键词分类的示例。

表3-关键词分类示例

在执行关键词分类之后，关键词检测器可以执行评估以确定抽象请求的主语和谓词。主语和谓词通常可以在子句中找到。主语和谓词的识别可以允许智能API生成器生成与期望操作相关联并针对期望主语的SL操作。例如，被识别为主语的数据可以用于执行访问控制检查、成为资源发现请求中过滤标准的一部分，或者成为资源属性的值。谓词的识别可以用于识别构成抽象请求的基础的底层SL操作。

上下文推导部件可以负责检查可以推断操作和资源之间的关联的描述性词语。这样的部件可以集中于介词和连词的单词分类。这些单词类别可以推断名词之间的关系，并提供有关如何将服务层操作组合在一起的线索。上下文推导部件还可以检查形容词和副词的单词分类，以确定诸如数量、时间、位置等属性。

为了实现某种级别的推断，可以在请求抽象服务中配置上下文推导词语，以指示在抽象请求中使用时的关系和/或操作序列。表4示出了一些可以用于获取抽象请求中单词的上下文的示例词语。例如，词语“before”的存在可以指在某个日期或时间或与某个日期或时间进行比较来执行SL操作的顺序。推导的上下文还可以取决于抽象请求中其它词语的接近程度。抽象请求“delete all subscription resources before 09/07/2018 andowned by<user_name>(删除在2018年9月7日之前并由<用户名>拥有的所有订阅资源)”显示，在“before”之后是类似于日期的词语；因此，RAS可以确定需要与该日期进行比较。如前所述，可以将附加的词语添加到请求抽象服务，以使RAS更好地识别上下文关系和/或操作排序。可以针对名词和其后附带短语之间的潜在链接评估此类词语。在一些情况下，可以推断出操作的顺序；在其它情况下，操作可以被组合或针对彼此进行检查。

表4-上下文推导词语示例

上下文推导部件可以执行抽象请求的初始传递，以确定抽象请求所隐含的潜在关系或排序顺序。使用逻辑分析输出，上下文推导部件可以在子句内包含的条目之间以及抽象请求中的短语中的条目之间创建矩阵。表5示出了与上述示例抽象请求中的单词相关的示例矩阵。在子句内，矩阵示出了“Give”和“<analyst>”与“Give”和“Access”之间的潜在链接。潜在链接在表5中用在上下文关系矩阵下的列的单元格中标记的“X”指示。矩阵的每一列可以指示单独的关系。在第一列中，与“Give”和“<analyst>”相关联的单元格具有“X”，并且因此，它们潜在地相关。与“Give”和“Access”相关联的单元格在第二列中各自有“X”，指示它们也可以是相关的。类似地，矩阵显示“Access”可以与抽象请求中找到的每个短语相关。为了实现这一点，可以使用关于语言构造的指南对上下文推导部件进行编程，以识别主语-谓词配对、谓词-宾语配对，以及与相邻名词的介词短语关系。

表5-上下文关系矩阵示例

上下文推导部件还可以执行另一个评估，以确定子句中短语到名词的一个或多个推断。分类可以包括与特定名词相关的对象、位置和时间。可以将这些分类中的每一个的词语的简档提供给RAS以做出该确定。RAS还可以使用介词的知识来帮助确定短语的推断。例如，以“at”开头的介词短语可以推断位置，而以“during”开头的短语可以推断时间。表6示出了上述抽象请求的短语推断的示例。

表6-短语推断示例

上下文推导部件还可以检查逻辑分析输出中的描述性词语，这些描述性词语可以用作服务层操作中的限定词。这样的检查可以包括在SL操作中可以用作搜索标准的形容词和副词的识别。表7示出了可以在这种检查期间分配的限定词的一些示例。

表7-限定词检测示例

如上所述，可以通过使用诸如“Define”或“Associate”之类的关键词向RAS发送独立的抽象请求来动态添加上下文。还可以指定其它关键词来指示RAS中的上下文更新。此类关键词可以存储在上下文推导部件用来将上下文添加到抽象请求的简档或查找表中。可以使用与上述相同的抽象请求结构来添加关键词。例如，抽象请求“Associate locks todoors in the context derivation component(在上下文推导部件中将锁与门关联”可以将锁链接到门并将此关联添加到上下文推导部件中。其它示例可以包括“Define west asa location in the context derivation component(将西方定义为上下文推导部件中的位置)”或“Define 20180425T160632 as a unit of time(将20180425T160632定义为时间单位)”。

图9示出了示例调用流程900，其中请求者做出抽象请求以将上下文信息添加到RAS。注意的是，抽象请求使用词语“Define”来指示该请求针对的是RAS 901中上下文信息的添加或更新，而不是针对发起SL 902操作的请求。

在步骤911处，请求者903可以发出抽象请求“Define west wing as<geofence_area>in context derivation component(在上下文推导部件中将西翼定义为<地理围栏区域>)”。该请求遵循本文描述的通用抽象请求结构定义，但是使用命令谓词“define”来指示这是上下文更新，而不是对一个或多个SL 902操作的请求。因此，抽象请求可以仅更新在请求抽象服务内管理的信息，并且可以不执行SL 902操作。

可以类似于图8的步骤812-815来执行步骤912至915。

在步骤916处，由于命令谓词被设置为“define”，因此上下文推导部件可以确定这是在RAS 901中添加或更新上下文信息的请求。来自步骤911的抽象请求将目标指定为上下文推导部件。但是，还可以指定其它RAS部件，并且还将在适当的部件中进行更新。

在步骤917处，在服务层的帮助下，RAS 901可以向请求者返回指示更新状态的适当响应。

在另一个示例中，如果RAS无法识别某个词语，那么请求抽象服务可以提示请求者提供上下文信息。

图10示出了示例调用流程1000，其中RAS没有识别词语“entryways(入口)”，并且提示请求者定义这样的词语。本示例中的抽象请求是：“Give<analyst>access to allentryways in the west wing for only today(仅在今天给予<分析人员>对西翼中的所有入口的访问权)”。这里，词语“entryways”已替代图9的抽象请求中使用的先前词语“doors(门)”。

在步骤1011处，请求者1001可以发出抽象请求，“Give<analyst>access to allentryways in the west wing for only today(仅在今天给予<分析人员>对西翼中的所有入口的访问权)”。

可以类似于图8的步骤812-816来执行步骤1012至1016。

在步骤1017处，在这种情况下，RAS 1001可能无法识别词语“entryways”，并且可能无法确定适当的上下文。因此，RAS 1001可以在服务层1002的帮助下提示请求者1003来定义词语“entryways”。

在步骤1018处，作为响应，请求者1003可以返回抽象请求“Associate entrywayswith doors(将入口与门相关联)”。该请求使用关键词“Associate”，并且因此，RAS 1001可以确定该抽象请求可以应用于上下文信息的更新。然后，RAS 1001可以添加上下文，即“entryways”可以与“doors”相关联，该“doors”可能已经与“locks”相关联。因此，RAS 1001可以能够继续处理该请求。

可以类似于图8的步骤819-821来执行步骤1019至1021。

可以将通过逻辑分析、关键词检测和上下文推导部件执行的分类作为输入路由到智能API生成部件。可以将由前述部件做出的确定组合在一起以生成可以实现抽象请求的期望结果的适当的服务层操作。如表8中所示，在得出结果之前，智能API生成可以执行抽象请求的分解。这种分解可以包括分离在抽象请求中找到的谓词、主语、对象、位置和/或时间信息。

表8-抽象请求分解示例

使用抽象请求的分解和输入分类，智能API生成器可以能够生成对应的SL操作，如表9中所示。对于识别出的主语和/或对象，可以做出资源发现请求以检查与SL处的那些主语和/或对象相关联的或以其它方式对SL可用的一个或多个资源。如果该一个或多个资源不存在，那么智能API生成器可以生成SL操作以创建此类资源。如果抽象请求中存在时间修饰词，那么可以使用时间修饰词设置此类资源的到期时间。注意的是，可以为抽象请求所适用的主语和主要对象创建资源。可以假定抽象请求中的其它次要对象已经存在，并且可能具有与之相关联的资源。

表9-智能API生成示例

如上下文关系矩阵所指定的，可以将位置和时间修饰词应用于对象。修饰词各自的值可以分别由位置和时间服务提供。这样的服务可以是由服务层提供的可以被调用以提供指示对应词语的值的服务。例如，“west”可以提供工厂的大致位置的方向，并且“onlytoday”可以定义在一天结束时到期的持续时间。对应的(一个或多个)服务提供执行谓词操作时可以使用的适当值。

谓词操作可以在完成先前操作后被执行，先前操作是诸如表9中列出的针对上述示例抽象请求的那些操作。谓词操作的功能可以取决于先前操作的结果。例如，如果SL处存在主要对象，那么操作可以是更新操作(即，更新主要对象)；如果SL处不存在主要对象，那么谓词操作可以是创建操作(即，创建主要对象)。关于操作序列的信息可以被发送到操作排序器以与服务层交互。如果在SL处有支持这种功能的服务，那么可以借助SL操作列表将信息提供给该服务。

在为适当的服务层操作生成API之后，智能API生成器可以将信息发送到操作排序器以对操作进行排序或结构化。可以通过使用排序表来对操作进行排序。表10中示出了使用上述抽象请求的示例排序表，该表示出了RAS可以创建以满足抽象请求的SL操作的操作顺序。请求可以被结构化，使得可以在执行创建或更新请求之前执行检索操作和资源发现操作。序列末尾的请求可以是由谓词操作指定的请求，诸如表9中关于示例抽象请求的那些请求。可能需要与服务层进行多次交互的请求在操作排序表的“多重性”列中可能具有“N”的指示，如表10中所示。排序表的“成功”和“失败”列可以是RAS用于从一个请求进行到另一个请求的状态。

表10-SL操作排序表示例

当操作排序器在操作排序表中遇到“结束”时，与服务层的交互可以终止，并且状态码可以返回给请求者。例如，接收到针对操作8的成功响应的操作排序器可以表示抽象请求已成功执行。但是，如果响应失败，那么抽象请求可能未成功执行。此外，如果接收到针对操作1、2、4、5和/或7的失败响应，那么操作排序器可以迅速退出并且可以将相关联的错误报告给请求者，以指示失败发生的位置。例如，当在操作#4中为<analyst>创建资源时，如果服务层返回失败响应，那么操作排序器可以停止操作并将错误状态返回给请求者。请求抽象服务还可以在操作序列中包括先前请求的状态。注意的是，如果资源被创建或更新，并且操作排序器由于响应失败而不得不中止操作，那么RAS可以撤消对这些资源所做的更改和/或删除资源。可以通过在服务层内支持该特征或经由处理此类操作的服务来实现更改的撤消。

图11示出了可以由操作排序器针对表10中所示的请求序列执行的示例操作序列1100。注意的是，图11中所示的操作序列假定所有请求都被成功执行。

在步骤1111处，请求者1103可以发出抽象请求“Give<analyst>access to alldoors in the west wing for only today(仅在今天给予<分析人员>对西翼的所有门的访问权)”。

可以类似于图8的步骤812-813来执行步骤1112至1113。

在步骤1114处，可以与图8的步骤814-819类似地执行RAS1101内的处理，而无需考虑图8的当RAS 1101提示用户提供附加上下文时的步骤817-818。操作排序器的操作在图11中明确地示出为步骤e1-e7。该序列遵循表10的序列，其中可以与<acp>资源一起创建<analyst>资源。然后，可以使用新创建的<acp>资源的ID来更新与从步骤e4发现的每个锁相关联的acpID属性。

在步骤1115处，RAS 1101可以在服务层1102的帮助下向请求者1103返回指示抽象请求被成功执行的适当响应。另外，RAS可以提供执行了哪个SL 1102操作(即，创建了<analyst>和<acp>资源，以及更新了锁资源的acpID)的状态。

在成功执行抽象请求之后，可以创建资源表示，使得可以在以后的时间重用或再次执行抽象请求。创建的资源可以包括虚拟的“ras”资源，该虚拟的“ras”资源被添加为请求者可以针对以便重用抽象请求的子资源。注意的是，可以使用另一个名称代替“ras”来表示虚拟资源。为了重用保存的抽象请求，请求者可以针对“ras”虚拟资源，并且可以提供新的抽象请求，该新的抽象请求指示可能需要根据原始抽象请求进行的更改。例如，RAS可以接收修改抽象请求的命令上下文或对象的请求，并且RAS可以修改生成的API集合以包括修改后的命令上下文或对象，而不是原始命令上下文或对象。然后，请求抽象服务可以使用原始抽象请求的内容以及从新抽象请求获得的替换上下文来处理新的抽象请求。

图12图示了用于重用抽象请求1200的示例序列图。在图12中，重用了抽象请求“Give<analyst>access to all doors in the west wing for only today(仅在今天给予<分析人员>对西翼的所有门的访问权)”。该抽象请求已被保存为absReq1资源，并且服务层已自动将虚拟资源“ras”创建为absReq1的子资源。附加地或替代地，虚拟资源对于重用抽象请求可能不是必需的，并且抽象请求资源可以直接由请求者作为目标。请求者1203希望重用absReq1，但要使用与以前使用的用户ID不同的用户ID。此外，请求者1203希望用“visitor(访问者)”代替“analyst”，并准予新用户访问智能工厂的相同区域。请求者1203甚至可以选择工厂的另一个区域，并在新的抽象请求中提供该信息。图12的调用流程的细节如下。

在步骤1211处，请求者1203可以尝试重用absReq1和目标URI/absReq1/ras。如上所述，在示例实施例中，请求者可以直接针对资源absReq1而不是虚拟资源“ras”。在请求中，请求者可以包括新的抽象请求“用<visitor>替换<analyst>”。

可以类似于图8的步骤812-813来执行步骤1212至1213。但是，代替将新的抽象请求发送到RAS 1201，可以将保存在absReq1中的原始抽象请求与在步骤1中提供的新上下文信息一起发送到RAS。

在步骤1214处，RAS 1201可以使用absReq1中保存的抽象请求来处理该请求，并且可以将从新的抽象请求“用<visitor>替换<analyst>”中获得的上下文替换原始上下文。对“<analyst>”的引用可以替换为新的上下文“<visitor>”。然后，操作排序器可以使用上下文“<visitor>”执行步骤e1-e7。服务层操作可能导致创建新的资源<visitor>和<acp2>，并且可以使用“acpID2”更新锁资源。

在步骤1215处，RAS 1201可以在服务层1202的帮助下向请求者1203返回指示抽象请求被成功执行的适当响应。另外，RAS可以提供执行了哪个SL操作(即，创建了<visitor>和<acp2>资源，以及更新了锁资源的acpID2)的状态。

本文描述了所引入的请求抽象服务功能的示例oneM2M实施例。示例实施例描述了RAS的一种或多种可能的实现。

示例oneM2M实施例可以包括<absReq>资源的定义，SL发起方可以以<absReq>资源为目标来发起向智能请求抽象服务发送抽象请求。示例oneM2M实施例还可以包括处理这样的抽象请求的过程。

图13是支持RAS CSF 1300的示例oneM2M服务层的图。在图13的示例中，CSF可以包括以下内容：应用和服务层管理CSF 1302；发现CSF 1303；注册CSF 1304；通信管理/传递处理CSF 1305；组管理CSF 1306；安全CSF 1307；数据管理和储存库CSF 1308；位置CSF 1309；服务收费和计费CSF 1310；设备管理CSF 1311；网络服务公开、服务执行和触发CSF 1312；订阅和通知CSF 1313；组管理CSF 1319；以及语义CSF 1320。图13的示例还示出了通过Mca参考点1314、Mcc(和Mcc')参考点1315和Mcn参考点1316与其它实体接口的CSE 1301，其它实体包括但不限于：AE 1317；其它CSE；以及NSE 1318(即，底层网络)。

如图13所示，可以将RAS CSF 1321实施为实现如本文描述的RAS功能的新CSF。RAS功能也可以被实现为现有oneM2M CSF的能力。可以在CSE内使用RAS以与其它CSF交互并执行操作来完成抽象请求。

在oneM2M实施例中，<absReq>资源可以为发起方提供向CSE指定抽象请求的机制。抽象请求可以包括至少三个部分：cmdPredicate、cmdObjects和cmdContexts。cmdPredicate可以包括对发起方想要执行的高级操作的描述。cmdObject可以包括cmdPredicate可能影响的CSE资源的一个或多个标识符。cmdContext可以包括适用于抽象请求的上下文信息。上下文信息可以包括适用于期望操作的位置、时间或数量中的一个或多个。表11示出了<absReq>资源的特定于资源的属性的示例。

表11：示例oneM2M<absReq>资源属性

表12中示出了<absReq>资源的示例创建过程。这样的过程可以包括由oneM2M定义的创建过程，并添加了对<absReq>资源的特定于资源的属性的处理。接收方CSE处的处理可以包括本文描述的用于处理抽象请求的机制。更新、检索和删除的过程可以分别包括如由oneM2M定义的那些方法的对应过程。

表12：经由Create(创建)操作的<absReq>过程

为了使得能够重用<absReq>资源，可以创建虚拟资源<ras>作为<absReq>资源的子资源。发起方可以针对这样的虚拟资源，以使用保存在<absReq>中的原始抽象请求的内容来发起新的抽象请求。新的抽象请求可以包括新的上下文信息，该新的上下文信息可以替换<absReq>中的现有上下文信息。例如，发起方可以针对以下URI，/cse01/absReq2/ras，以重用保存在absReq2中的抽象请求。在新的抽象请求中，发起方可以指定“用用户2(user2)替换用户1(user1)”。如果原始抽象请求是“Give user1 access to all mgmtObjresources(给予用户1对所有mgmtObj资源的访问权)”，那么RAS在执行替换之后可以将新的抽象请求处理为“Give user2 access to all mgmtObj resources(给予用户2对所有mgmtObj资源的访问权)”。附加地或可替代地，可以在请求参数中提供新的抽象请求，同时该请求针对要重用的<absReq>资源，例如，/cse01/absReq2。

图14示出了服务层可以提供给用户的用于输入抽象请求的示例用户界面1400。用户界面可以被实现为帮助用户配置和输入抽象请求。用户界面的标题为“输入您的请求：”，并且可以显示将在其中创建抽象请求的目标URI。在图14中，托管CSE的名称为“cse01”1401。抽象请求的格式可以在用户界面的主要部分上以标题“命令谓词”1402、“(一个或多个)命令对象”1403和/或“(一个或多个)命令上下文”1404来显示。在每个标题下方可以是带有向下箭头的相应对话框，以允许用户为每个标题选择可识别的条目。在按下向下箭头时，可以打开另一个窗口以显示可选择条目的菜单。然后，用户可以滚动条目，并且可以选择感兴趣的条目。用户也可以输入新条目。在“(一个或多个)命令对象”和“(一个或多个)命令上下文”标题下方可以是附加的对话框，这些对话框可以允许用户向选择菜单添加更多条目。用户可以选择+符号，以输入相关联标题的另一个条目。这些对话框的左侧可以是用于指定一个或多个修饰词以将抽象表达式属性组合在一起成为一个抽象请求的选项。在底部是两个按钮，它们可以允许用户或者发送抽象请求或者取消提交抽象请求。在用户按下发送按钮1405之后，请求抽象服务可以开始处理并执行图8中所示的RAS过程。用户还可以经由取消按钮1406来取消该处理。

本文还描述了用于服务层框架的方法和装置，该服务层框架用于将通用和功能用户界面集成为由SL代表请求实体管理的服务。以下是如本文中用于本公开的该方面的词语的定义的列表：

主机：托管各种资源的实体。

M2M服务：通常通过应用程序接口(API)提供给应用的面向M2M的能力。

M2M服务节点：托管服务层的网络节点，该服务层支持用于M2M通信的一个或多个M2M服务。

发起方：创建请求并将其传输给另一个实体(即，给接收方)的实体。

接收方：从另一个实体(即，从发起方)接收请求的实体。

注册器：其中应用或另一个服务节点已注册的服务节点。

注册者：注册到服务节点(即，注册器)以获取其服务的实体。

RESTful：基于REST(代表性状态转移)原理设计的系统、操作等。创建、读取、更新和删除(CRUD)操作是RESTful操作的示例。

用户界面：人或机器通过其与计算机系统、电子设备或机器进行交互的任何通用界面。该界面本质上可以是机械/图形/感官等。如果UI本质上是图形/视觉的，那么其在本文中被称为图形用户界面(GUI)。如果在人和机器之间指定接口，那么它被称为人机界面(HMI)。

图15是另一个示例oneM2M服务层的图，该oneM2M服务层支持初始公共服务功能(CSF)集合1500。oneM2M的目的和目标是制定解决对公共M2M服务层的需求的技术规范，该公共M2M服务层可以被轻松地嵌入在各种硬件和软件平台内，并且可以依靠该公共M2M服务层将现场中各种各样的设备与全球范围的M2M应用服务器连接起来。

如图15的示例所示，oneM2M服务层可以支持CSF集合(即，服务能力)。一个或多个特定类型的CSF集合的实例化可以被称为公共服务实体(CSE)1501(即，服务层)，其可以被托管在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上。CSE1501公开的公共功能可以包括但不限于寻址和标识1510、数据管理和储存库1511、位置1512、安全性1513、通信管理/传递处理1514、注册1515、组管理1516、设备管理1517、订阅通知1518、服务收费和计费1519、发现1520，以及网络服务公开/服务执行和触发1521。

这些公共功能可以经由Mca参考点1504、Mcc参考点1505和Mcn参考点1506公开。Mca参考点1504可以指定应用实体(AE)1502与CSE 1501之间的通信流程，而Mcc参考点1505可以指定同一M2M服务提供商域中两个CSE 1501之间的通信流程。可以经由成对的请求/响应消息来进行跨Mca参考点1504和Mcc参考点1505的通信，其中每个请求可以对目标CSE1501上托管的资源执行特定的RESTful操作(例如，CRUD)。Mcc参考点1505可以在位于不同M2M SP的基础设施域中的CSE 1501之间使用。Mcn参考点1506可以在CSE 1501与基础网络服务实体(NSE)1503之间用于除传输和连接性之外的服务。特定的CSE 1501实现可以不支持图15的示例中所示的每个功能，但完整的实现将包括图15中所示的所有功能。

根据oneM2M RESTful架构，CSF可以被表示为资源集合。资源可以是架构中唯一可寻址的实体，其具有可经由诸如CRUD之类的RESTful方法进行操纵的表示形式。可以使用统一资源标识符(URI)使这些资源可寻址。资源可以包含子资源和属性。子资源可以是与父资源具有包含关系的资源。父资源表示形式可以包含对其子资源的引用。子资源的生命周期可能受父资源的生命周期限制。每个资源都可以支持存储关于资源的信息的“属性”集合。

在过去的几十年中，各种类型的用户界面发生了显著的演进，从普通的显示器和键盘到鼠标、触摸屏、触觉设备等。越来越多的传感器已被添加到消费者设备中来确定用户正在尝试做的事情，诸如分析手势、检测眼睛移动、解释方向、速度等。越来越多的提供反馈的方法也以无数的音频、触觉或视觉形式等被开发。虽然复杂的机器(诸如，通用计算机之类)具有对复杂交互的处理能力和需求，但是在物联网(IoT)世界中，这些需求和能力可能都会降低。许多设备可以使用多个基础交互来良好地执行；因此，只要知道需要执行哪个功能，人就可以出于各种目的只使用一些与同一设备非常简单的交互。类似地，可以将相同的简单交互用于各种设备，例如,滑尺是立体声的音量功能、洗衣机的温度设置、相机的变焦等所需的基本输入。

机器或设备提供的输出也具有与其相关联的基本功能。例如，显示数字是核电站中温度监控器的基本功能，它与水箱中的压力或指示房间中的湿度的监视器的基本功能相同。例如，指示其打开的冰箱可以提供听觉警报，该听觉警报提供与指示电池电量不足的闪烁LED相同的功能(即，警报)。在一些情况下，这些警报的表达可能更适合视觉和听觉二者。

复杂的用户界面，特别是图形用户界面演进的原因之一是向人类用户阐明提供哪个输入或提供哪个输出，以及使交互变得容易、可访问和令人愉悦。

图16是集成各种设备和电器的示例家庭控制平台1600的图。许多消费者设备托管多个独立的应用，其中不止一个应用从同一个传感器获取并解释输入。平台1600可以具有存在传感器，该存在传感器用于房间中的照明、温度和湿度控制以及用于房间临近环境的安全性。平台1600还可以允许轮椅中的老年人或残疾人(人U1)1601具有使用单个可穿戴按钮设备来打开/关闭家庭周围各种设备的能力。在图16的示例中，可穿戴按钮可以由人U11601穿戴，并且在一些房间(例如，厨房、浴室、门廊)中，它可以用于打开特定的灯1603。当按钮由家庭办公室内的人U1 1601穿戴时，它可以用于经由平台扬声器/麦克风应答商务电话1604，并且当按钮由厨房或客厅中的另一个人U2 1602穿戴时，它用于启动平台立体声1605。

在另一个示例中，具有按钮的定点设备可以用于指向集成平台的设备并对其进行控制。不同的应用可以具有独立解释来自同一可穿戴设备的相同输入的任务。平台可能已经具有信息(例如，用于安全性、照明和环境控制的存在传感器输入)，用于(基于预定规则)确定它从按钮接收到的输入的上下文是什么(即，谁正在穿戴它以及它们在哪个房间或区域中)。

能够处理来自几个来源的信息的服务层(SL)平台通常处于非常好的位置，以使用可从新传感器和技术获得的信息(例如，用于分析手势、方向等)，并将该可用信息用作用于用户交互的上下文(例如，从用户设备接收到的输入)。假设具有这样的能力的平台，本文描述的方法和装置可以使用服务层处可用的信息来以简化应用的用户界面并且在应用之间一致的可靠方式来解释人类交互。本文描述的方法和装置可以减轻与为每个应用创建用户界面相关的一些复杂性，因此多个应用可以依赖于公共的交互库和公共的解释集。本文描述的方法和装置可以实现其中可以将有限数量的定义的交互用于多种需求/应用的场景。

例如，当理解了给定交互和设备操作之间的对应关系后，本文描述的方法和装置可以使得能够基于情况上下文来不同地提供用户交互。例如，具有多个用户的工作站可以具有不同的首选项：第一个用户可能偏好旋转按钮用于调光器，而第二个用户可能偏好滑块。为了提供这种简单的特征，调光器可能需要下载多个应用实例、应用设置可能需要在用户之间来回切换，或者可能需要具有用户感知的应用来实现原本非常简单的工具。替代地，这种简单的设备可以依赖于平台来实例化其用户界面，并一路提供诸如用户感知定制之类的优化。

本文描述的方法和装置可以使得能够进行基于SL上下文改变的增值服务，以在几乎没有用户的输入的情况下增强用户交互体验，同时保留UI功能方面。例如，如果有听力障碍的人正在访问，那么可以一次为所有应用建立家庭控制平台，使得给出视觉警报而不是听觉警报。当检测到噪声级别高于特定级别时，更复杂的实现可以将警报从音频改变为视觉。虽然一些应用可以提供这样的定制，但是本文描述的方法和装置可以避免单独地配置每个设备。

本文描述了用于服务层框架的方法和装置，该服务层框架用于将通用和功能用户界面集成为由SL代表应用管理的服务。在本文中被称为交互器的这些用户界面处理用户交互，并产生通用和功能事件，这些事件被转换成应用的输入/输出。本文描述的方法和装置定义了交互上下文管理(ICM)服务，该服务评估上下文并维持对应的上下文状态。ICM服务使用上下文状态来评估基于用户交互的事件，并提供它们与特定于应用的事件之间的映射。ICM可以被配置有与交互器相关的模板和策略，例如，交互器库。应用和其它服务层可以通过发现交互器库或各个模板来查询和发现由SL提供的与交互器相关的能力。根据本文描述的方法和装置，应用可以提供关于其自身的与交互器相关的能力的信息。此外，ICM可以被配置有规则和参数，这些规则和参数使ICM能够监视SL并相应地维护和切换上下文状态。ICM可以代表应用实例化交互器，使得对用户交互及其功能和与系统中应用操作的对应关系有共同的理解。将应用和交互器关联的处理可以允许在系统中根据上下文使用多个交互器。

本文描述了其中交互器可以向服务层ICM注册，以使ICM使用其服务并与应用相关联的过程。当交互器功能被部署在不同于具有ICM功能的设备/平台的设备上时，该过程特别有用。此外，由交互器接收或产生的用户交互可以被转换成由ICM管理的事件，该ICM可以向应用提供功能输入或输出。SL事件与最终用户交互之间经由ICM和交互器的转换处理可以允许对用户交互进行根据上下文的处理。

如本文所使用的，用户交互是物理交互，其包括经由在本文中被称为用户界面(UI)的专用界面在软件和用户之间交换的实时通信。用户交互的示例包括接收到的输入，包括但不限于以下各项：经由鼠标点击的输入、语音输入、输出蜂鸣声等。如本文所使用的，对UI的引用主要解决与设备或机器的人类交互；但是，本文描述的方法和装置可应用于其它类型的交互。在用户交互时在UI处的上下文信息在本文中被称为UIx-上下文。UIx-上下文可以包括例如用于鼠标点击的鼠标指针的坐标、语音输入的响度等。

如本文所引用的，交互上下文(Ix-上下文)可以包括可以基于其评估用户交互和SL事件的任何信息。在SL架构中，Ix-上下文可以包括在SL处可用的任何参数或数据集(其可以由任何应用或SL实体提供给SL)，并且可以包括UIx-上下文或也包含在UIx-上下文中的某些方面/参数。Ix-上下文也可以由SL推导，例如，基于先前的SL或交互上下文状态、UIx-上下文、历史、语义信息等进行推导。例如，可以基于以下SL参数中的任何一个或任意组合来创建交互上下文状态：一天中的时间、用户的位置，以及由传感器提供的噪音级别。

如本文所引用的，交互器(Ix)可以包括通用UI软件，该软件处理物理输入并产生通用和功能性交互器事件(Ix-事件)。可以在交互上下文中评估Ix-事件，以转换成由特定应用产生或消费的SL动作或事件(Ax-事件)。接收应用进而被编程为提供与Ix-事件相关的特定功能。通常，UI在SL架构中与应用通信时，交互器可以与SL实体(经由Ix-事件)通信。

在SL架构中，交互器可以被实现为SL实体(例如，与ICM集成在一起或独立)，其处理物理用户交互并将这些交互与一个或多个设备(或应用)互通(interwork)。该互通经由表示为资源的(在该情况下由SL托管的)设备/应用级别接口提供。

交互器可以用于任何交互，包括但不限于开/关、文本输入/输出、手势(2D或3D)、音频警报等。可以定义复杂的交互器以将多个Ax-事件映射到单个Ix-事件。例如，单个手势可以用于向两个原本不协调的设备提供命令，诸如使立体声静音和使灯关闭。类似地，复合交互器可以用于接收多种类型的输入，诸如与触摸按钮组合的口头命令，以确定最终的特定于应用的Ax-事件。虽然本文描述的示例和实施例是指经由简单/原子交互器提供的示例功能，但是本文描述的相同概念可以适用于简单和复杂的交互器。类似地，相同的概念可以应用于设计为提供输出而不是输入交互的交互器。

如本文所引用的，交互器事件(Ix-事件)可以包括原子、通用和功能上定义的事件，该事件可以由具有UI功能的软件(例如，交互器)基于物理用户交互产生或消耗。在Ix-事件不专用于单个应用的意义上，Ix-事件可以是通用的。在不同于由物理特性(例如，在触摸板上的手指轻扫)定义的用户交互，Ix-事件可以由基本功能方面(例如，开/关)定义的意义上，Ix-事件可以在功能上被定义。

如本文所引用的，特定于应用的交互器事件(Ax-事件)可以包括由应用(即，app)产生或消耗的SL事件，其可以由SL和具有UI功能(例如，交互器)的软件转换成用户交互。

以下是Ix-事件的功能表征以及用户交互与对应的Ix-事件和Ax-事件之间的差异的示例：

鼠标单击“开/关”按钮(物理用户交互)vs.开/关(由物理用户交互产生的Ix-事件)vs.灯“开/关”(针对灯开关应用的Ax-事件”)；以及

声音(物理用户交互)vs.警报(基于其产生声音的Ix-事件)vs.冰箱警报(由冰箱控制应用产生的Ax-事件)。

如本文所引用的，交互上下文管理(ICM)服务可以是评估SL中的Ix-上下文并使用Ix-事件和Ax-事件来使用Ix-上下文实现将用户交互转换成应用功能和状态改变的实体。

图17是根据一个实施例的描绘交互器、用户交互、Ix-事件、Ax-事件和SL ICM之间的信令的示例系统1700的图。在图17的示例中，交互器实例1703可以接收诸如指示用户交互上下文信息(UIx-上下文)1710的接收到的输入之类的信息。接收到的输入可以基于物理用户交互1711。交互器实例1703可以处理UIx-上下文1710信息，并且可以产生通用和功能性交互器事件(Ix-事件)。交互器实例1703可以经由Ix-事件1712与SL ICM 1702通信，SLICM 1702可以将交互上下文(Ix-上下文)1713存储在数据库中。如上所述，Ix-上下文可以包括在SL处可用的多个参数或数据(其可以由任何应用或SL实体提供给SL)，并且可以包括UIx-上下文1710或可以包含在UIx-上下文1710中的某些方面/参数。如上所述，可以在Ix-上下文内评估与SL ICM 1702通信的Ix-事件1712，以转换成SL动作或事件(Ax-事件)，以供应用生产/消费。SL ICM 1702可以经由Ax-事件1714与应用1701通信。

图18A是描绘交互器、用户交互、Ix-事件、Ax-事件和SL ICM之间的信令的另一个示例系统1800的图。在图18的示例中，交互器1801可以接收诸如接收到的物理用户交互1810之类的信息。交互器1801可以经由Ix-事件1811与SL 1805处的ICM 1804通信。ICM1804可以经由Ax-事件1812与应用1802通信以及经由Ax-事件1813与应用1803通信。SL1805还可以经由其它SL消息传递1814与应用1802通信以及经由其它SL消息传递1815与应用1803通信。SL 1805还可以经由SL消息传递与其它服务层1806通信。

图18B是使用嵌入式应用的UI实现常规范例的系统的图。上面描述的(并在图4和图18A中描绘的)交互器范例使得能够将单个交互器(即，UI)用于一个以上的应用。但是，如图18B的示例中所示，常规范例使用嵌入在应用1851中的UI处理物理用户交互1850，该应用1851可以经由SL消息传递1852与SL 1853通信。SL 1853还可以经由SL消息传递1854与其它服务层1855通信。

在本文中可以使用以下词语来区分图18A的系统中使用基于交互器的范例的应用功能和图18B的系统中使用常规范例的使用应用嵌入式UI的应用功能。

UI-应用：具有嵌入式用户交互功能以及具有直接链接到用户交互的功能和状态改变的应用逻辑；以及

应用：具有链接到特定于应用的交互器事件(Ax-事件)的功能和状态改变的应用逻辑，其可以由SL和交互器转换成用户交互。

图19A-19C是用于不同交互器的不同UI样式的示例1900。在这个示例中，可以为简单的灯开关提供应用，并且可以经由不同的交互器为应用提供来自SL的UI服务。参考图19A，初始地可以通过滑动改变灯的状态的虚拟开/关按钮1901来提供用户交互。还可以以不同的方式提供用户交互，诸如在图19B的示例中，其中经由屏幕上的点击按钮1902提供用户交互。还可以如图19C的示例中那样提供用户交互，其中经由右鼠标键单击1903来提供用户交互。在图19A-19C的示例1900中，或者需要使用多个UI-应用，或者需要来回切换UI-应用设置。否则，UI-应用需要实现为上下文感知应用(例如，通过用户使用登录或指纹分析来切换上下文)来实现原本非常基本的设备(在这个示例中为简单的灯开关)。而且，与信息丰富的服务层相比，即使上下文感知的UI-应用也仅限于预定义的上下文定义集合。

图20是根据一个实施例的示例系统2000的图，其中SL取决于上下文向应用提供使用两种不同交互器的能力，这可以与本文描述的任何实施例结合使用。图20的示例系统使用上面描述的(并在图4和图18A中描绘的)交互器范例，使得多个交互器可以使用不同的物理用户交互来在应用级别(Ax-事件)执行相同的操作。参考图20，交互器2001可以接收诸如接收到的物理用户交互2010之类的信息。交互器2001可以基于上下文2017经由Ix-事件2012与SL 2005处的ICM 2004通信，这可以触发ICM 2004经由Ax-事件2014与应用2003通信。交互器2002可以接收诸如接收到的物理用户交互2011之类的信息。交互器2002可以基于上下文2016经由Ix-事件2013与SL 2005处的ICM 2004通信，这也可以触发ICM 2004经由Ax-事件2014与应用2003通信。SL 2005还可以经由其它SL消息传递2015与应用2003通信，并且SL 2005也可以经由SL消息传递2018与其它服务层2006通信。

本文针对上面描述的(并在图17、图18A和20中描绘的)交互器范例的方法和装置可以实现交互器模板(Ix-模板)的使用。交互器模板(在本文中也被称为模板或Ix-模板)可以包括交互器功能的基本和通用描述，其可以用于实例化一个或多个交互器。

基于相同模板生成的一组交互器被称为具有相同的功能类型，该功能类型可以由元素ixTemplateFunctionalType指示。功能类型与所支持的在ixTemplateEvents元素中指定的Ix-事件类型相关。

模板还可以(经由initializeDefaults元素)指定在首次创建与交互器相关联的资源时要应用的默认值。模板还可以(经由ixInstantiationSettingsDefaults元素)指定要在交互器UI首次运行时(即，在实例化时)使用的参数。实例化设置(例如，颜色、图形的位置)可以用于例如创建各种用户体验，并且还可以在实例化请求时被提供。

下面的表13包括模板的示例元素的描述。

表13交互器模板

本文描述的方法和装置可以包括如上所述的ICM，并且ICM可以是独立服务或被实现为IoT服务层的子服务。ICM可以托管在各种类型的网络节点上，诸如IoT服务器、IoT网关和IoT设备之类，并且可以根据节点以不同级别的功能实例化。

ICM可以通过监视基于其定义上下文的参数集来评估交互上下文，该参数集可以由应用提供给SL或由SL推导的任何信息组成。本文描述的示例和实施例假定上下文变化发生在离散的多维状态(cxState)之间，并且使用上下文参数与阈值或用户交互的先前状态的比较来执行上下文变化。在此假设下，ICM可以维护具有如下面的表14中所描述的参数的cxState列表。但是，当以其它方式(例如，使用规则、算法、条件等)对交互上下文进行评估并随时间进行更改时，这些概念也可能适用。下面描述如何为ICM预先供给用于评估交互上下文和确定用于切换的cxState的规则。

表14上下文状态列表(cxList)

ICM可以通过使用与交互器相关联的资源为每个cxState创建Ix-事件和Ax-事件之间的关联来管理用户交互和应用操作之间的对应关系，如下面所描述的。为了创建和管理这些资源，可以向ICM预先供给Ix-模板，并且可以从应用接收交互器信息。

在以上关于图16所描述的家庭控制平台中，可以为平台ICM供给“开/关”交互器模板，该交互器模板可以与可以提供这种输入(诸如按钮之类)的任何设备一起使用。诸如可控房间灯或立体声之类的设备可以向平台注册，并提供关于它们可能使用的交互器的信息，其中包括“开/关”按钮。ICM还可提供GUI，该GUI允许用户例如基于用户身份和位置来创建用于上下文切换的规则。对于每个上下文，ICM可以在开/关输入和控制动作之间创建对应关系。下面描述如何向ICM预先供给Ix-模板、应用如何提供关于可能的交互器关联的信息、ICM如何使用这些专用资源维护对应关系以及ICM如何根据不断变化的交互上下文进一步维护交互器与应用之间的关联。

鉴于其在维护关于Ix-模板、交互器和相关联的应用的信息中的作用，ICM可以用于发现或发布关于可用模板和交互器的信息，以及关于Ix-事件的信息，这些信息又提供关于所有用户交互的有价值的信息。

ICM可以使用与交互器相关的资源来提供其功能。例如，下面的表3包括与ICM可以使用以便使用上述概念和信息元素提供其功能的交互器实例(ixInstance)相关的信息。对于RESTful环境，表15提供了ixInstance SL资源的结构。

表15 ixIns tance

如本文所使用的，词语交互器和交互器实例可以互换使用。实例的添加可以用于强调交互器作为在特定时间运行的软件的特定副本。因此，取决于情况，交互器可以指可能导致多个实例化的通用软件或一个交互器实例。

图21是根据另一个实施例的可以与本文描述的任何实施例结合使用的示例交互器状态机2100的图。创建和初始填充支持交互器功能的资源的处理在本文中被称为交互器注册。参考图21，可以将交互器编程为在未注册状态2102中启动2101，并且在交互器注册过程2103之后，它可以转换成已注册(空闲)状态2104。交互器注册过程2103可以导致以下资源被创建和初始化：

ixInstance资源，其可以用于总体交互器实例管理；

基于交互器模板的ixEventResourceDescription以实现SL(ICM)与交互器之间的通信的一个或多个资源；以及

基于交互器模板的ixInstantiationResourceDescription的资源，其可以由ICM使用以触发交互器实例化。

运行交互器的UI软件的处理在本文中被称为交互器实例化。实例化触发器2105可以将交互器转换到实例化(活动)状态2106，在实例化状态中，它可以处理去往/来自Ix-事件的物理用户交互。例如，用于触摸屏上的开/关按钮的交互器实例化可以包括创建按钮图形和将轻击作为物理用户交互进行处理的处理。例如，交互器可以仅处理一个用户交互，然后在实例化超时2108之后，该交互器可以返回到已注册(空闲)状态2104，在该状态中，它们需要被重新触发以便处理物理用户交互。可以指定交互超时2107(或最大数量的物理用户交互等)，使得在处理每个物理用户交互之后，交互器重复返回活动状态。当达到交互超时2107(或执行的最大重复次数)时，交互器可以转换到空闲模式。ixInstantiationSettings可以在SL中捕获诸如计时器值、重复次数等的参数，以及影响交互器状态机以及在实例化(活动)的状态2106中处理物理用户交互的方式的其它设置。交互器注销过程2109可以包括删除支持交互器功能的资源的处理。在注销之后，空闲的交互器可以返回到未注册状态2102，并且它可以在超时之后到达结束状态2110。

一些交互器可以依靠ICM来创建和初始化交互器支持资源，并因此代表其执行交互器注册。在其它示例中，可以对交互器进行编程以主动发现ICM功能，并然后注册自己。例如，交互器可以使用类似于应用用来发现和向SL注册的机制来发现ICM。

图22是根据一个实施例的、可以与本文描述的任何实施例结合使用的用于在ICM中使用的示例过程2200的图。虽然单独示出和描述了图22中的过程2200的每个步骤，但是可以以与所示出的顺序不同的顺序、彼此并行或彼此同时执行多个步骤。图22的示例提供了由ICM执行的动作的概览，这些动作导致交互器被部署、伴随的用户交互(例如，基于物理交互的预定输入)与给定的应用相关联，以及ICM继续监视上下文并基于这些上下文改变使得能够改变用户交互处理。

本文描述了图22的示例过程的功能阶段。阶段A(设置)2204可以包括以下阶段，在该阶段期间，ICM被配置有多个模板(即，交互器的库)，以使得能够识别交互器和/或使得交互器能够实例化。在阶段A(设置)2204期间，ICM还可以被配置为能够基于可用信息切换上下文。同样在阶段A(设置)2204期间，注册的应用可以通过识别对应的模板来提供关于其使用的交互器的类型的信息。在阶段A(设置)2204结束时，在ICM处可获得：一个或更多模板资源(或alLibrary)；ICM切换状态所基于的Cx-状态列表；利用如下信息增强的应用注册信息，该信息关于可以经由交互器和对应的模板触发哪些应用操作(Ax-事件)。

阶段B(初始化/注册)2205可以包括以下阶段，在该阶段期间，准备交互器的部署，并创建和初始化支持其功能的资源，即，可以执行如上所述的交互器注册。SL ICM可以代表应用注册交互器。替代地，交互器可以在SL ICM处注册自己。具有默认/初始值的必要参数的初始化可以基于交互器模板、本地策略或信令(例如，CRUD操作)。在阶段B(初始化/注册)2205结束时，ICM可以具有新创建的资源以及与ixInstance中Ix元素集对应的信息。

阶段C(关联和实例化)2206可以包括以下阶段，在该阶段期间，表示和支持交互器功能的资源提供为每个交互器实例创建关联列表的手段。每个关联可以将Cx-状态映射到Ax-事件和Ix-事件。执行交互器实例化，因此在该阶段结束时，交互器可以开始处理用户交互并将Ix-事件转换成Ax-事件或从Ax-事件转换成Ix-事件。

阶段D(上下文管理)2207可以包括以下阶段：在该阶段期间，ICM基于当前的规则不断评估SL上下文，并更改上下文。ICM无限地重复阶段D 2207，并可能导致重复阶段C2206和更改交互器实例与应用之间的关联。如果规则是动态更新的，那么ICM可以更新其Cx-状态的定义，并且评估遵循当前的规则。ICM可以通过将用户交互转换成Ix-事件(反之亦然)来使用关联与应用和交互器进行不断地通信。

阶段E(注销)2208可以包括执行交互器注销过程时的阶段，该阶段可以删除SLICM处支持交互器功能的资源。阶段E(注销)2208可以以交互器处于注销状态而结束，但是，ICM服务可以继续。

参考图22，在阶段A(设置)2204期间，可以向SL ICM 2202供给模板(步骤2210)。SLICM可以存储可以以多种方式创建或安装的交互器模板。每个模板都提供交互器功能的通用描述，基于该描述，可以创建多个交互器实例。模板可以提供关于需要为交互器实例和初始化默认值创建哪些资源的信息。在步骤2210结束时，SL ICM2202处可能有一个或多个ixTemplate可用。SL ICM 2202还可以维护模板库，该模板库可以被发现(例如，通过应用以便选择或指示用于交互器实例化的特定模板)。在阶段A(设置)2204期间，SL ICM 2202可以接收描述交互器模板的设置，这可以使用多种方法来完成：

可以在部署之前预先供给模板集合。那时，可以为SL处可用的每个模板配置表1中详述的参数。

经由设备管理(DM)过程提供模板。例如，可以经由下载来提供整个模板数据库。这些更新同样也可以在除阶段A(设置)2204以外的其它阶段发生。

应用可以例如在注册时提供模板。例如，可以将与传感器或致动器接口的应用(即，app)安装在托管ICM的不同设备上。对应的模板创建或安装可以是应用安装的一部分。这种模板供给方法可能需要增加注册消息，以便能够携带如表1中所述的模板参数。替代地或附加地，可以定义向ICM提供或注册模板的其它专用消息。

SL ICM 2202可以被提供有上下文改变规则(cxRules)(步骤2211)，其可以用于确定上下文状态集合。这些cxRules可以以多种方式提供。一旦确定了上下文状态(Cx-State)集合，SL ICM 2202便可以使用它们来更改用户交互(经由交互器)与应用相关联的方式。在步骤2211结束时，可以在SL ICM 2202处创建并填充cxList，并且可以通过在整个SL ICM2202生命周期中重复步骤2211来对其进行更新。该信息还对应于ixInstance中Cx元素集。为了使SL ICM 2202评估交互上下文并确定何时发生上下文改变，可以为它提供多个上下文切换规则。假设如上所述使用离散的多维状态，ICM可以使用如表2中描述的参数维护从这些规则推导的Cx-状态列表。

为SL ICM 2202提供规则并得出Cx-状态集合的方法包括但不限于以下方法：

SL ICM 2202可以在部署之前预先供给有cxRules或cxStateDescr/cxStateID，以填充如表2中介绍的cxList；

DM更新：可以经由DM过程提供用于填充cxList的cxRules或cxStateDescr/cxStateID。例如，可以经由下载来提供整个cxList。这些更新同样也可以在除阶段A(设置)2204以外的其它阶段发生；以及

直接用户输入。该上下文供给方法可以使用可以公开的专用用户界面，使得用户能够提供如表2中所述的参数。

以下示例描述了直接用户输入方法，但是一旦以逻辑和程序方式制定了规则，就可以经由预先供给、DM更新等来提供它们。

对于如上面参考图16所述的轮椅中的老年人或残疾人使用单个可穿戴按钮设备打开/关闭房间周围的各种设备的用例，SL ICM 2202可以驻留在家庭平台上。在这个示例中，该平台可以用于与家庭周围的灯和设备(包括通用的可穿戴按钮)进行交互。在这个示例中，平台还具有一些用于其它功能(例如，温度控制)的定位能力。例如，平台的定位能力可以基于房间中的存在传感器，或者可以基于使用用户的智能手表来跟踪他/她在房间内的定位。该平台可以基于以下步骤例如在平板电脑或其它配置用于无线或有线通信的设备上公开GUI：

GUI可以请求将哪个设备(例如，可穿戴按钮)用作“上下文用户交互设备”(即，在其上实例化交互器)。GUI可以提供可以以该方式使用的可用设备的列表，以及关于其能力的信息。用户可以选择可穿戴按钮。如果设备能力更复杂，例如，包括触控板和按钮，那么GUI可以请求要以上下文方式使用设备的哪个功能(按钮)。

GUI可以请求要控制哪些设备，并且可以再次呈现合适设备的列表。例如，可以接收来自用户的对灯的选择。

SL ICM 2202可以能够接收指示用户在房间中的位置/地点的信息。本文描述了用于确定上下文改变的方法。例如，可能有两个上下文切换规则：“按房间”或“按接近度”。第一个规则是其中切换上下文取决于(一个或多个)存在传感器指示用户所位于的房间的规则。第二个规则是其中当用户接近诸如不同的可控灯之类的设备(其可能在同一房间，也可能不在同一房间)时上下文被切换的规则。

在该处理结束时，SL ICM 2202可以供给有“按房间”的cxRules。然后，SL ICM2202可以使用其本地信息来创建多个Cx-状态，每个Cx-状态具有形式为(用户，userValue)&&(用户地点，locValue)等的cxStateDescr，并且每个Cx-状态都具有其自己的cxStateID，这可以例如如下所示：

cxList[0]/cxStateID＝A

cxList[0]/cxStateDescr＝(用户，U1)&&(用户地点，厨房或浴室或卧室或客厅)

cxList[1]/cxStateID＝B

cxList[1]/cxStateDescr＝(用户，U1)&&(用户地点，家庭办公室)

cxList[2]/cxStateID＝C

cxList[2]/cxStateDescr＝(用户，U2)&&(用户地点，厨房或客厅)

在具有按钮的指示设备的示例中，SL ICM 2202可以基于规则而不是基于离散的多维状态(cxState)实现上下文改变。但是，SL ICM 2202可以基于与可控设备匹配的方向传感器输入来创建Cx-状态(每个具有单独的cxStateID)。当交互Ix-上下文随指针的方向改变时，可以连续评估交互Ix-上下文，并且Cx-状态可以改变为其位置与轨迹匹配的设备的cxStateID。

步骤2211的上下文规则供给可以贯穿该过程2200的其它阶段执行或重复，从而有效地更新SL ICM 2202提供其服务所基于的(一个或多个)上下文状态的(一个或多个)定义。

应用(诸如应用2201)可以向SL ICM 2202注册(步骤2212)，SL ICM 2202可以提供关于要使用的交互器的信息。当应用2201注册时，它可以通知SL ICM 2202哪些操作(Ax-事件)可以经由交互器触发，以及哪些模板可以用于对应的交互器中的每个交互器。可以在注册之后经由CRUD操作或新消息(例如，交互器-使用-指示)来替代地提供或更新由应用2201在注册时提供的所有信息。在步骤2212之后，除了应用注册信息之外，SL ICM 2202还具有与ixInstance中的Ax元素集对应的信息。

应用注册时提供的信息可以由SL ICM 2202使用，以了解应用2201在其生命周期期间可能向SL请求的ICM服务。该信息(例如，表4中列出的信息)可以增强现有的应用注册信息，因此可以将其与应用注册一起存储。例如，该信息可以包括用于每个应用的以下信息：

可以经由交互器触发的操作(Ax-事件)列表。

可以用于每个对应的交互器的模板的列表。这可以通过引用SL ICM 2202处存在的模板来提供，或者通过提供新的模板来提供。如果提供新的模板，那么SL ICM 2202可以类似于步骤2210中提供的模板(例如，在模板库中)存储它们，并由增强型应用注册信息引用。

用于发现目的的Ax-事件的描述。例如，该信息可以用于发现用于家庭平台上的声音控制的所有交互器，但是有些可能是基于手势的，有些可能使用打开/关闭点击按钮等。

实例化对应的交互器时要使用的设置。该信息可以类似于模板的ixInstantiationSettingsDefaults来使用，但是如果它是基于每个应用以更动态的方式提供的，那么它可以取代那些设置。

注册时由应用提供的信息可以替代地在注册后由应用经由(一个或多个)CRUD操作或其它消息(例如，交互器-使用-指示)来提供或更新。

表16用于增强的App注册或用于新的交互器-使用-指示消息的参数

在准备步骤2212时，应用可以使用资源发现过程或有关SL ICM 2202能力的假设。例如：

第一应用(例如，应用2201)可以假定模板使用(例如，模板X和Y)在SL ICM 2202处是已知的/可用的，并且可以提供最小量的信息，诸如模板ID(ixTemplateIDList)之类。如果未知任何模板，那么第一应用可以在响应中接收到错误消息。该信息可以由第一应用在注册时提供，如图22中所示，在这种情况下，注册信息将得到增强以包括该信息。替代地，可以使用带有ixTemplateIDList的专用交互器-使用-指示消息。

第二应用可以发现在SL ICM 2202处已知/可用的模板(例如，通过发现模板库)，然后可以基于其能力选择模板X和Y。假定使用发现过程，那么带有ixTemplateIDList信息的专用消息交互器-使用-指示可以由第二应用发送到SL ICM 2202。

第三应用可以提供模板X和Y本身以及ixInstantiationSettings的完整描述。该方法对于引入尚未在步骤2210中预先供给的新模板可能特别有用。应用可以将专用消息交互器-使用-指示发送到SL ICM 2202，该SL ICM 2202包含具有如表13中所示的完整的模板定义列表的ixTemplateDefintionList。

为了填充ixInstantiationSettings，应用可以使用默认值或本地策略。该元素也可能不存在，在这种情况下，可以使用SL ICM 2202处的模板或本地策略。

假定应用注册过程导致在SL处创建的至少一个应用专用资源中的RESTful环境，例如，在oneM2M中，可以在注册时创建与应用2201对应的<AE1>资源。因此，可以使用表16中的信息来增强该资源。

在RESTful架构中，可以经由对包含表16中详述的信息的资源的CRUD操作来提供经由交互器-使用-指示消息提供的信息。例如，在oneM2M中，<AE>资源类型增强然后不仅可以用于注册选项，还可以用于经由针对<AE>资源的UPDATE操作来实现交互器-使用-指示消息。

可以在该过程2200的其它阶段期间执行步骤2212，从而有效地更新应用(例如，应用2201)的所支持的Ax-事件信息。

在阶段B(初始化/注册)2205期间，可以创建和初始化表示交互器的资源和支持交互器功能的资源。资源的创建伴随有具有默认/初始值的必要参数的初始化，其也可以基于(一个或多个)交互器模板、本地策略或显式信令(例如，CRUD操作)。在阶段B 2205结束时，除了新创建的资源之外，SL ICM 2202还具有与ixInstance中的Ix元素集对应的信息。

SL ICM 2202可以代表应用2201注册新的交互器实例(步骤2213)。步骤2213可以由SL ICM 2202执行，并且可以由应用2201的注册或来自应用2201的显式请求来触发(例如，经由交互器-使用-指示消息，即，通过步骤2212的完成来触发)。参数初始化可以基于现有信息，例如，交互器模板或本地策略。步骤2213可以导致支持新的交互器实例的功能的交互器相关资源的创建和初始化。新创建的资源可以用如在模板的initializeDefaults中指定的默认值来填充，或者可以基于在SL ICM 2202处可用的本地策略。

例如，可以在步骤2213期间创建和初始化以下资源：

一个ixInstanceX1资源，它可以是由SL ICM 2202用于对交互器实例的Ix-事件到Ax-事件对应关系进行总体管理的资源。

基于ixEventResourceDescription的一个或多个资源：可以由SL ICM 2202使用，以基于物理用户交互来使得能够进行SL ICM 2202与交互器2203之间的通信(IxEvent)的资源。一旦SL ICM 2202创建了这些资源，就可以使用ixInteractResList将它们链接到ixInstanceX1。例如，如果模板的ixInteractionResourceDescription指定需要两个容器，那么可以经由ixInteractResList属性中的条目创建容器X1和容器X2并将其链接到交互器2203。

一个基于ixInstantiationResourceDescription的资源：SL ICM 2202可以使用该资源来触发交互器2203的实例化。一旦SL ICM 2202创建了该资源，就可以使用ixInstantiationTrigger将其链接到ixInstanceX1。例如，如果模板的ixInstantiationResourceDescription指定需要<mgmtCmd>，那么可以创建mgmtCmd资源类型的instatiationTriggerX1，并经由ixInstantiationTrigger属性将instatiationTriggerX1链接到交互器2203。

在应用2201注册之后执行交互器注册的替代方案与上面的类似，但是可以使用来自应用2201的触发消息“交互器-请求”(参见下面的表17)。其它实施方式可以使用其它事件或通知作为触发器，但是过程2200仍可以包括交互器支持资源创建以及使用默认值填充资源参数。

表17交互器-请求消息

替代地，不是如步骤2213那样，SL ICM 2202可以代表应用2201注册新的交互器实例，而是交互器2203可以向SL ICM 2202注册自身(步骤2214)。可以由驻留在与SL设备不同的设备上的交互器执行步骤2214，以便注册或通告自己。如上所述，步骤2214可以导致在SL处创建和初始化与交互器相关的任何资源，但是与步骤2213相比，资源创建和初始化由交互器(例如，交互器2203)触发。

例如，当交互器功能被部署在不同于具有ICM功能的设备/平台的设备上时，可以使用该替代方案。SL发现和注册过程可以用于该目的。

当交互器2203可以访问指示SL ICM 2202的能力的信息时，可以对其进行编程以创建和初始化其自身的支持资源。在步骤2214期间，以下资源可以由SL处的交互器2203创建并由ICM(例如，SL ICM 2202)托管：

一个用于总体交互器管理的ixInstanceX1资源

基于ixEventResourceDescription的一个或多个资源以使得能够进行SL ICM2202与交互器2203之间的通信(IxEvent)。一旦交互器2203创建了这些资源，就可以使用ixInteractResList将它们链接到ixInstanceX1。

一个基于ixInstantiationResourceDescription的由SL ICM 2202使用以触发交互器2203的实例化的资源。一旦SL ICM 2202创建该资源，就可以使用ixInstantiationTrigger将其链接到ixInstanceX1。例如，如果模板的ixInstantiationResourceDescription指定可以使用<mgmtCmd>，那么可以创建mgmtCmd资源类型的instatiationTriggerX1，并经由ixInstantiationTrigger属性将instatiationTriggerX1链接到交互器2203。

用默认值填充新创建的资源的方法可以在模板的initializeDefaults中指定，或者可以基于SL ICM 2202处可用的本地策略。

在阶段C(关联和实例化)2206期间，可以将交互器2203与应用2201相关联(步骤2215)。表示和支持交互器2203的功能的资源可以提供为每个交互器实例创建关联列表的手段。每个关联可以将Cx-状态映射到Ax-事件和Ix-事件。

可以使用相关资源(例如，分别为ixInstanceX1、AE1和TemplateX)执行交互器2203、应用2201和模板之间的这种关联。维护该关联是SL ICM 2202提供的功能的一部分，并启用例如：

(1)使用单个UI(例如，基于模板X)来分别向多个应用提供用户交互(如以上关于步骤2211所述的多功能按钮的部署中所例示的)。在这种情况下，单个ixInstance可以具有assocList，其具有如下元素：

[Cx元素集]：

assocList[i].cxStateIDAssoc＝cxList中的cxList[i].cxStateID(如上所述)。

从单个模板X推导并且对于所有元素重复的[Ix元素集]。该元素集包括：

ixEventResList

ixInstantiationTrigger

ixInstantiationSettings

用于从不同应用的注册推导的每个元素的[Ax元素集]，参见步骤2212和表16。该元素列表可以包括：

axAssocApp

axEventOperation

axEventActionDescr

(2)使用多个UI向单个应用提供用户交互，如上述示例中所例示的，用于取决于用户而改变界面。在这种情况下，单个ixInstance可以具有assocList，其具有如下元素：

[Cx元素集]：

assocList[i].cxStateIDAssoc＝cxList中的cxList[i].cxStateID(如上所述)。

用于从不同模板推导的每个元素的[Ix元素集]。该元素集可以包括：

ixEventResList

ixInstantiationTrigger

ixInstantiationSettings

从单个应用的注册推导的(参见步骤2212和表4)并对所有元素重复的[Ax元素集]。该元素列表可以包括：

axAssocApp

axEventOperation

axEventActionDescr

下面，如果用户改变了cState的示例cxList，那么：

cxList[0]/cxStateID＝A

cxList[0]/cxStateDescr＝(用户，Alice)

cxList[1]/cxStateID＝B

cxList[1]/cxStateDescr＝(用户，Bob)，等等。

(3)发布和发现关于可用模板的信息。例如，这可以由应用或交互器用来发现ICM能力，并且可以对于各个模板资源或模板库使用常规的发现方法。

(4)使得能够进行UI样式的批量更改(如以上对于听觉障碍的访客听觉警报被更改为视觉警报的示例中所例示的)。在这种情况下，在用户请求时，例如在人访问期间，可以将新条目添加到cxList。然后，可以针对模板库执行发现并使用指示音频和视觉警报的interactMethod和/或interactEnvironment查找模板。每个发现的音频模板都可以具有ixInstanceList，它可以使得能够快速发现所针对的ixInstance。对于所有这些ixInstance，创建新的assocList条目，并且cxStateIDAssoc等于新创建的针对访问时间的上下文的cxStateID。在这些条目中，[Ax元素集]可以保持不变，而[Ix元素集]可以基于不同的视觉警报模板来创建。

(5)使得能够进行增值ICM服务，诸如UI实例化设置的动态改变之类(如以上当ICM检测到噪声级别高于特定级别时，听觉警报被改变为视觉警报的示例中所例示的)。除了ICM可以使用高级功能(诸如机器学习、预测分析等)为cxList创建新条目外，可以与上述情况类似地实现这种情况。

在过程2200中，交互器2203与应用2201资源之间的初始链接已在阶段B(初始化/注册)2205处完成。如果重复2215，那么可以由应用使用“交互器-请求”消息来创建新的关联或更新现有的关联来更新链接。

以下是通过填充相关联的资源(例如，分别为ixInstanceX1、AE1和TemplateX)来关联交互器X1、App1和模板X的示例：

ixInstanceX1/ixTemplate＝ixTemplateX

ixInstanceX1/assocList[n]/axAssocApp＝AE1:

以及

ixTemplateX/ixInstanceList＝ixInstanceX1，…

以及

AE1/aeIxInstanceList＝ixInstanceX1…

ixInstanceX1的assocList的其它参数可以按照之前的详细说明进行填充，例如，基于模板或本地策略的defaultsDefaults的crntAssocIndex、cxStateID和ixEventActionDescr，根据交互器-使用-指示或注册消息的ixInstantiationSettings，等等。类似地，ixEventResList可以用指向基于模板的ixEventResourceDescription创建的资源的链接来填充。SL ICM 2202可以维持crntAssocIndex，该crntAssocIndex指向与当前上下文对应的assocList中的条目。

在步骤2215中采取的动作可以取决于迭代而不同。例如，在初始交互器实例化之后，可以立即执行关联的初始配置。如果在进一步的上下文改变之后执行该操作，那么可能导致关联被更新或暂停，或者一个或所有关联被删除(不删除交互器等)。

然后可以实例化交互器2203(步骤2216)。执行交互器实例化，这是运行交互器的UI软件的处理。当在阶段A(设置)2204和阶段B(初始化/注册)2205之后第一次执行步骤2216时，可以触发交互器2203的软件以基于新创建的交互器和初始关联来运行。当在进一步的上下文改变之后执行步骤2216时，交互器2203的UI可以被触发以与更新的关联一起运行。

这导致交互器2203处理经由SL ICM 2202与关联的应用(例如，应用2201)交换的用户交互和Ix-事件。触发可以由创建相关联资源的实体(即，或者应用(例如，应用2201)或者SL ICM 2202)来执行。

SL ICM 2202可以评估SL上下文并将用户交互转换成IxEvent(步骤2217)。SL ICM可以基于在阶段A(设置)2204期间提供给SL ICM 2202的Ix-C规则连续评估上下文。如果规则是动态更新的，那么SL ICM 2202可以更新其Cx-状态的定义，并且评估遵循当前规则。SLICM 2202可以通过将用户交互转换成IxEvent(反之亦然)来使用关联与应用和交互器连续通信。在步骤2217期间，SL ICM 2202还可以与交互器通信，从而将用户交互转换成应用处的IxEvent或从应用处的IxEvent转换成用户交互，如以上所示出的。

如果上下文改变，那么SL ICm 2202可以进行到步骤2215(改变关联)，否则进行到步骤2217(保持评估)。ICM可以维护基于上下文的交互管理状态机。如果上下文改变使得交互器需要不同的关联(步骤2218)，那么在阶段C期间(关联和实例化)转到步骤2206，否则继续进行评估(转到步骤2217)。为了更新关联，SL ICM 2202可以将ixInstance的crntAssocIndex与具有对应上下文状态(cxStateIDAssoc)的assocList索引对齐。

然后可以发生交互器注销过程，该过程在SL ICM 2202处删除支持交互器2203功能的资源(步骤2219)。该阶段可以以“已注销”状态的交互器结束，但是ICM服务继续。

图23是根据一个实施例的可以与本文描述的任何实施例结合使用的用于将用户交互转换成交互器事件的示例过程2300的图。图23的示例描述了使用交互器2303和应用2301之间的关联来处理接收到的输入用户交互(输出和复杂交互可以与该示例中类似地被处理)。参考图23，用户交互可以发生并且可以由交互器2303处理(步骤2310)。交互器2303可以基于输入的用户交互向SL ICM 2302提供事件，并且该事件可以包括一些用户交互生成的信息(步骤2311)。例如，对于鼠标单击，事件可以捕获/包括鼠标在屏幕上的位置。在RESTful架构中，可以通过使用SL处与交互器相关联的资源(例如，ixEventResList中的条目)来实现该步骤。例如，在上述初始化/注册阶段，已经用在ixEventResList中对应的条目(例如，containerX1)创建了对应的资源ixInstanceX1。在这个步骤中，用户交互可以导致交互器2303更新容器X1。

SL ICM 2302可以向应用2301发送对应的IxEvent，并且可以包括除UI上下文之外的关于SL上下文的信息，该信息是使用ICM的增值的一部分(步骤2312)。这样，不仅可以向应用2301通知用户单击了鼠标，而且还可以在单击发生时获得关于SL上下文的其它信息。

在一些实施例中，在步骤2311中由交互器2301处理的事件可以直接映射到IxEvent，因此它由SL ICM 2302转发给应用2301。该实施方式可以提供优化，但是可能放弃向应用提供与用户交互相关联的SL上下文的增值。通过这种优化，ICM可以通过基于上下文切换在交互器和应用之间切换关联来提供服务。

这种类型的功能可以允许对用户动作的上下文相关的解释，而不仅是交互器的上下文相关的实例化。示例是上面介绍的实施方式的示例，那里的家庭控制平台检测到高噪音级别，或者从高立体声音量设置中知道这一点。cxRules可以指定：“存储警报并使用改变的设置(ixInstantiationSettings)或类型(关联)定期重复警报，直到被确认为止”。当ICM接收到输出IxEvent时，它可以从其功能描述中知道它是警报，并且可以从相关联的交互器知道它是否是音频、视觉等。在未确认的音频警报之后，可以用不同的音量、音色等重复该警报。如果环境噪声过高，那么它可以为当前环境创建新的Cx-状态，并且新的视觉交互器(闪烁的LED)将该Cx-状态与IxEvent相关联。然后可以以更可能被确认的形式重复警报。虽然这种部署可能更适合使用机器学习和预测分析的平台，但它可以使用与本文描述相同的基本ICM和交互器功能。

本文描述的ICM功能和过程可以使用oneM2M资源来实现，诸如通过被实现为驻留在CSE中并向AE公开其服务的ICM CSF。上面介绍的交互器也可以被实现为一个或多个CSF。交互器可以在与ICM相同的CSF中实现，或者可以在单独的(一个或多个)CSF中实现。交互器也可以被实现为AE或IPE。应用也可以被实现为AE。

例如，图22的过程2200可以如下被映射到oneM2M中：

步骤2210可以通过引入新的资源类型<ixTemplate>来实现。可以使用oneM2M中的预线供给的DM操作或现有的RESTful过程来提供内容。

步骤2211可以通过新的资源类型<cxList>来实现。可以使用如在阶段A(设置)2204中描述的GUI和oneM2M中现有的RESTful过程来提供资源内容。除非cxList被公开给其它实体，否则可以不定义这种类型的资源，但是仍然可以在服务层中以特定于实现的方式在本地提供资源功能。

交互器-使用-指示消息步骤2213可以通过在oneM2M中引入新的资源类型<ixInstance>和现有的RESTful CREATE过程来实现。该步骤还可能导致创建如在ixEventResourceDescription中指定类型的其它类型的现有oneM2M资源(例如，<container>，<flexContainer>)。

步骤2215可以经由oneM2M中现有的RESTful UPDATE过程在针对诸如ixID，appIdentifier，ixTemplateID，ixInstantiationSettings，ixEventOperation，cxStateIDAssoc之类的属性的类型<ixInstance>、<AE>和<ixTemplate>的资源上实现。替代地，它可以用向ICM提供这些参数的交互器-请求消息来实现，其中对应的资源被更新。

步骤2216可以被实现为创建给定软件应用或处理的新实例化的处理。

步骤2217可以被实现为oneM2M中现有的RESTful过程，如下所示：

交互器可以通过基于(现有oneM2M类型的)ixEventResourceDescription在与交互器相关的资源上执行RESTful操作来提供输入和ICM中继输出；

ICM和应用使用在(现有oneM2M类型)的ixEventOperation中指定的资源；

<ixTemplate>资源可以表示单个交互器模板，并且可以如下面的表18中所述那样被指定。<ixTemplateLibrary>资源可以包含可以被发现(例如，由应用)以便选择或指示将用于交互器实例化的特定模板的模板集合。

表18新的<ixTemplate>资源类型的属性

<ixTemplateLibrary>资源可以包含以下子资源。

表19<ixTemplateLibrary>资源类型的子资源

<cxState>资源可以包含定义ICM的上下文状态所需的信息。<cxList>资源可以包含ICM在监视和管理Cx-State转换中使用的所有<cxState>资源的列表。

<cxList>资源可以包含下面的表8中列出的以下子资源。

表20<cxList>资源类型的子资源<cxState>资源可以包含下面的表21中列出的以下属性。

表21新的<cxState>资源类型

以下是基于SL中资源的属性匹配条件的上下文状态(cxStateDescr)的示例实现。可以设想其它实现。例如，当ICM接收到特定的通知时或在一天中的特定时间时，等等，可能会发生状态改变。

在这个示例中，cxStateDescr属性中表示的参数集由4元组(contextResourceIDs，cxStateCriteria，timeWindowType，timeWindowSize)组成，其参数在下面的表22中示出。cxStateDescr属性可以包含至少一个元组。

表22：cxStateDescr 4元组中的参数

表23：cxStateCriteria条件

当多个条件可以一起使用时的规则如下：

不同的条件标签可以基于指定的conditionOperation使用“AND/OR”逻辑操作；

相同的条件标签可以使用“OR”逻辑操作。

资源类型<ixAssociation>包括与交互器实例对应的<ixInstance>资源的子资源。对于交互器(如由<ixInstance>表示的)，每个<ixAssociation>可以表示Cx-状态(如由cxStateID表示的)和AE(如由axAssocApp表示的)之间的关联。

表24<ixAssociation>资源类型的属性

<ixInstance>资源类型可以表示交互器实例，并且可以包括关于所有Cx-状态的信息(经由子<ixAssociation>资源)，交互器可以基于该信息来改变与AE的关联。

<ixInstance>资源可以包含下面的表25中列出的子资源。

表25<ixInstance>资源类型的子资源

表26新的<ixInstance>资源类型的属性

本文描述了资源类型<AE>的属性和交互器-使用-指示消息的参数。<AE>资源可以表示关于注册到SL的应用实体的信息。表27和表28描述了用于增强功能的<AE>资源类型的新元素(即，子资源和属性)。

表27<AE>资源类型的新子资源

表28附加<AE>资源类型属性

上表中的新<AE>资源类型属性列表与表16中的交互器-使用-指示消息的内容之间的区别是ixTemplateDefintionList，因为这里假定其中所有模板被存储在<ixTemplateLibrary>中并且仅在<AE>资源中被引用的oneM2M实现。其它实现可以选择将模板存储为<ixTemplate>资源，<AE>资源类型的新子资源。

在诸如oneM2M之类的RESTful环境中，并且给定上面的<AE>资源定义，可以假定使用针对<AE>资源类型的这些新属性的UPDATE操作来实现交互器-使用-指示消息。如果要使用交互器-使用-指示消息的ixTemplateDefintionList提供新模板，那么可以使用针对<ixTemplateLibrary>的附加UPDATE操作。

以下是服务层框架的示例实施例，用于将通用和功能用户界面集成为由SL代表请求实体管理的服务：

1.一种包括处理器、存储器和通信电路系统的装置，该装置经由其通信电路系统连接到网络，该装置还包括存储在该装置的存储器中的计算机可执行指令，该计算机可执行指令在由该装置的处理器执行时使该装置执行包括以下的操作：

接收指示多个上下文切换规则的第一信息；

接收指示多个操作的第二信息，所述多个操作中的每个操作被配置为基于至少一个物理交互而被触发；以及

基于上下文切换规则确定在每个触发的操作和由第一类型的服务层实体中的至少一个基于所述至少一个物理层交互产生的信号之间的映射。

2.实施例1所述的装置，其中所述映射响应于更新后的上下文切换规则而改变。

3.实施例1所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，该计算机可执行指令在由该装置的处理器执行时，使该装置执行包括以下的进一步的操作：

接收至少一个应用注册消息。

4.实施例3所述的装置，其中第二信息与所述至少一个应用注册消息一起被提供。

5.实施例3所述的装置，其中从至少一个应用接收所述至少一个应用注册消息。

6.实施例1所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，该计算机可执行指令在由该装置的处理器执行时，使该装置执行包括以下的进一步的操作：

接收包括多个模板的消息，其中每个模板包括与由第一类型的服务层实体产生的每个信号相关联的功能信息，其中第二信息指示与每个操作对应的至少一个模板。

7.实施例6所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，该计算机可执行指令在由该装置的处理器执行时，使该装置执行包括以下的进一步的操作：

实例化每个服务层实体，每个服务层实体基于映射来产生符合至少一个模板的信号。

8.实施例1所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，该计算机可执行指令在由该装置的处理器执行时，使该装置执行包括以下的进一步的操作：

从第一类型的至少一个服务层实体接收服务层注册消息。

9.实施例8所述的装置，其中服务层注册消息是从多个服务层实体接收的。

10.实施例1所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，该计算机可执行指令在由该装置的处理器执行时，使该装置执行包括以下的进一步的操作：

接收至少一个应用注册消息；

接收包括多个模板的消息，其中每个模板包括与由第一类型的服务层实体产生的每个信号相关联的功能信息，其中第二信息指示与每个操作对应的至少一个模板；以及

基于接收到的至少一个应用注册消息和至少一个模板来识别每个服务层实体。

11.实施例1所述的装置，其中更新后的映射基于上下文导致至少一个物理交互触发不同操作。

12.实施例1所述的装置，其中更新后的映射基于上下文导致至少一个操作由不同的至少一个物理交互触发。

13.实施例1所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，该计算机可执行指令在由该装置的处理器执行时，使该装置执行包括以下的进一步的操作：

检测指示执行了至少第一物理交互的服务层信号；以及

基于映射经由至少一个服务层实体向多个操作中的一个操作发送信号。

14.实施例1所述的装置，其中所述至少一个物理交互包括经由用户界面在软件与用户之间交换的通信。

15.实施例14所述的装置，其中所述通信是鼠标输入、语音输入、音频输入或点击输入。

16.实施例1所述的装置，其中第一信息、第二信息、注册消息和映射被存储在数据库中。

17.实施例1所述的装置，其中第一信息是经由网络接收的。

18.实施例1所述的装置，其中第二信息是经由网络接收的。

19.实施例1所述的装置，其中该装置是无线通信设备。

20.实施例1所述的装置，其中该装置是计算设备。

21.实施例1所述的装置，其中该装置是智能电话。

22.实施例1所述的装置，其中该装置是网关。

23.由实施例1至22中任何一个实施例中所述的装置执行的方法。

图24A是其中可以实现一个或多个公开的实施例的示例性机器到机器(M2M)、物联网(IoT)或Web物联网(WoT)通信系统10的图。一般而言，M2M技术为IoT/WoT提供构建块，并且任何M2M设备、M2M网关、M2M服务器或M2M服务平台可以是IoT/WoT以及IoT/WoT服务层等的部件或节点。图2、5、6、8-12和19A-19C中任何一个中所示的客户端、代理或服务器设备中的任何一个都包括通信系统的节点，诸如图24A-D中所示的节点。

服务层可以是网络服务架构内的功能层。服务层通常位于应用协议层(诸如HTTP、CoAP或MQTT之类)之上，并为客户端应用提供增值服务。服务层还提供到位于较低资源层(诸如例如控制层和运输/接入层之类)的核心网络的接口。服务层支持多种类别的(服务)能力或功能，包括服务定义、服务运行时启用、策略管理、访问控制和服务聚类。最近，若干行业标准组织(例如，oneM2M)一直在开发M2M服务层，以解决与将M2M类型的设备和应用集成到诸如因特网/web、蜂窝、企业和家庭网络的部署中相关联的挑战。M2M服务层可以为应用和/或各种设备提供对由服务层支持的上面提到的能力或功能集合或集的访问，服务层可以被称为CSE或SCL。一些示例包括但不限于安全性、计费、数据管理、设备管理、发现、供应以及连接性管理，这些能力或功能可以被各种应用共同使用。经由使用由M2M服务层定义的消息格式、资源结构和资源表示的API，使这些能力或功能能够用于所述各种应用。CSE或SCL是可以由硬件或软件实现的功能实体，并且提供暴露于各种应用或设备的(服务)能力或功能(即，这种功能实体之间的功能接口)，以便它们使用此类能力或功能。

如图24A中所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或者异构网络的网络。例如，通信网络12可以包括向多个用户提供诸如语音、数据、视频、消息传递、广播等内容的多个接入网络。例如，通信网络12可以采用一种或多种信道接入方法，诸如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。另外，例如，通信网络12可以包括其它网络，诸如核心网、因特网、传感器网络、工业控制网络、个域网、融合个人网络、卫星网络、家庭网络或企业网络之类。

如图24A中所示，M2M/IoT/WoT通信系统10可以包括基础设施域和现场(field)域。基础设施域是指端到端M2M部署的网络侧，并且现场域是指通常在M2M网关后面的区域网络。现场域和基础设施域都可以包括网络的各种不同节点(例如，服务器、网关、设备等)。例如，现场域可以包括M2M网关14和设备18。将认识到的是，根据期望，任何数量的M2M网关设备14和M2M设备18可以包括在M2M/IoT/WoT通信系统10中。M2M网关设备14和M2M设备18中的每一个被配置为使用通信电路系统经由通信网络12或直接无线电链路发送和接收信号。M2M网关14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)或者通过诸如通信网络12之类的运营商网络或者通过直接无线电链路进行通信。例如，M2M设备18可以收集数据并经由通信网络12或直接无线电链路向M2M应用20或其它M2M设备18发送数据。M2M设备18还可以从M2M应用20或M2M设备18接收数据。另外，数据和信号可以经由M2M服务层22被发送到M2M应用20和从M2M应用20接收，如下所述。M2M设备18和网关14可以经由各种网络进行通信，包括蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线线路。示例性M2M设备包括但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、联网汽车、智能仪表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门以及其它基于致动器的设备、安全设备和智能插座。

参考图24B，现场域中所示的M2M服务层22为M2M应用20、M2M网关14和M2M设备18以及通信网络12提供服务。将理解的是，M2M服务层22可以根据期望与任何数量的M2M应用、M2M网关14、M2M设备18和通信网络12通信。M2M服务层22可以由网络的一个或多个节点来实现，这些网络节点可以包括服务器、计算机、设备等。M2M服务层22提供适用于M2M设备18、M2M网关14和M2M应用20的服务能力。M2M服务层22的功能可以以各种方式实现，例如作为web服务器、在蜂窝核心网中、在云中等等。

类似于所示的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和底层通信网络12提供服务。M2M服务层22'还为现场域中的M2M网关14和M2M设备18提供服务。将理解的是，M2M服务层22'可以与任何数量的M2M应用、M2M网关和M2M设备通信。M2M服务层22'可以与不同的服务提供商的服务层交互。M2M服务层22'可以由网络的一个或多个节点来实现，所述网络节点可以包括服务器、计算机、设备、虚拟机(例如，云计算/存储场等)等。

还参考图24B，M2M服务层22和22'提供不同应用和行业(vertical)可以充分利用的核心服务递送能力集。这些服务能力使M2M应用20和20'能够与设备交互并执行诸如数据收集、数据分析、设备管理、安全性、计费、服务/设备发现等功能。基本上，这些服务能力免除了应用实现这些功能的负担，从而简化了应用开发并减少了成本和上市时间。服务层22和22'还使M2M应用20和20'能够通过各种网络(诸如网络12)与服务层22和22'提供的服务相关联地进行通信。

M2M应用20和20'可以包括各种行业中的应用，诸如但不限于运输、健康和保健、联网家庭、能源管理、资产跟踪以及安全性和监控。如上面所提到的，在系统的设备、网关、服务器和其它节点之间运行的M2M服务层支持诸如例如数据收集、设备管理、安全性、计费、位置跟踪/地理围栏、设备/服务发现以及传统系统集成之类的功能，并将这些功能作为服务提供给M2M应用20和20'。

一般而言，诸如图24B中所示的服务层22和22'之类的服务层定义软件中间件层，该软件中间件层通过应用编程接口(API)和底层联网接口的集合来支持增值服务能力。ETSI M2M和oneM2M架构都定义了服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以在ETSI M2M架构的各种不同节点中实现。例如，服务层的实例可以在M2M设备中实现(其中它被称为设备SCL(DSCL))、在网关中实现(其中它被称为网关SCL(GSCL))和/或在网络节点中实现(其中它被称为网络SCL(NSCL))。oneM2M服务层支持公共服务功能(CSF)的集合(即，服务能力)。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，其可以托管在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上。第三代合作伙伴计划(3GPP)还已经定义了用于机器类型通信(MTC)的架构。在那种架构中，服务层及其提供的服务能力是作为服务能力服务器(SCS)的一部分实现的。无论是在ETSI M2M架构的DSCL、GSCL或NSCL中实施，在3GPP MTC架构的服务能力服务器(SCS)中实施，在oneM2M架构的CSF或CSE中实施，还是在网络的某个其它节点中实施，服务层的实例都可以被实现为或者在网络中的一个或多个独立节点(包括服务器、计算机以及其它计算设备或节点)上执行或者作为一个或多个现有节点的一部分执行的逻辑实体(例如，软件、计算机可执行指令等)。作为示例，服务层或其部件的实例可以以在具有下述图24C或图24D中所示的一般架构的网络节点(例如，服务器、计算机、网关、设备等)上运行的软件的形式实现。

另外，本文描述的方法和功能可以被实现为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问服务的M2M网络的一部分。

图24C是网络的节点的示例硬件/软件架构的框图，所述节点是诸如图2、5、6、8-12和19A-19C中所示的客户端、服务器或代理之一，其可以作为诸如图24A和24B中所示的M2M网络中的M2M服务器、网关、设备或其它节点操作。如图24C中所示，节点30可以包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、键盘40、显示器、触摸板和/或指示器42、电源48、全球定位系统(GPS)芯片组50和其它外围设备52。节点30还可以包括通信电路系统，诸如收发器34和发送/接收元件36。将认识到的是，节点30可以包括前述元件的任意子组合，同时保持与实施例一致。这个节点可以是实现本文描述的功能的节点，例如，与参考图6-23描述的方法相关。

处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。一般而言，处理器32可以执行存储在节点的存储器(例如，存储器44和/或存储器46)中的计算机可执行指令，以便执行节点的各种所需功能。例如，处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理和/或使节点30能够在无线或有线环境中操作的任何其它功能。处理器32可以运行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或其它通信程序。例如，处理器32还可以执行安全操作，诸如认证、安全密钥协商和/或加密操作之类，诸如在接入层和/或应用层处。

如图24C中所示，处理器32耦合到其通信电路系统(例如，收发器34和发送/接收元件36)。通过执行计算机可执行指令，处理器32可以控制通信电路系统，以便使节点30经由与其连接的网络与其它节点通信。特别地，处理器32可以控制通信电路系统，以便执行本文和权利要求中描述的发送和接收步骤(例如，在图6-23中)。虽然图24C将处理器32和收发器34描绘为分开的部件，但是将认识到的是，处理器32和收发器34可以一起集成在电子包或芯片中。

发送/接收元件36可以被配置为向其它节点发送信号或从其它节点接收信号，所述节点包括M2M服务器、网关、设备等。例如，在实施例中，发送/接收元件36可以是被配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。在实施例中，发送/接收元件36可以是被配置为例如发送和/或接收IR、UV或可见光信号的发射器/检测器。在又一个实施例中，发送/接收元件36可以被配置为发送和接收RF和光信号两者。将认识到的是，发送/接收元件36可以被配置为发送和/或接收无线或有线信号的任意组合。

此外，虽然发送/接收元件36在图24C中被描绘为单个元件，但是节点30可以包括任何数量的发送/接收元件36。更具体而言，节点30可以采用MIMO技术。因此，在实施例中，节点30可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。

收发器34可以被配置为调制将由发送/接收元件36发送的信号并且解调由发送/接收元件36接收的信号。如上所述，节点30可以具有多模式能力。因此，例如，收发器34可以包括多个收发器，用于使节点30能够经由多个RAT(诸如UTRA和IEEE 802.11之类)进行通信。

处理器32可以从任何类型的合适存储器(诸如不可移除存储器44和/或可移除存储器46)访问信息，并将数据存储在其中。例如，处理器32可以在其存储器中存储会话上下文，如上所述。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘，或任何其它类型的存储器存储设备。可移除存储器46可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其它实施例中，处理器32可以从物理地位于节点30上(诸如在服务器或家用计算机上)的存储器访问信息，并将数据存储在其中。处理器32可以被配置为控制显示器或指示器42上的照明图案、图像或颜色。在一个实施例中，显示器/指示器42可以呈现本文所示和描述的图形用户接口。

处理器32可以从电源48接收电力，并且可以被配置为向节点30中的其它部件分配和/或控制电力。电源48可以是用于为节点30供电的任何合适的设备。例如，电源48可以包括一个或多个干电池(例如，镍镉(NiCd)、镍-锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。

处理器32还可以耦合到GPS芯片组50，GPS芯片组50被配置为提供关于节点30的当前位置的位置信息(例如，经度和纬度)。将认识到的是，节点30可以通过任何合适的位置确定方法获取位置信息，同时保持与实施例一致。

处理器32还可以耦合到其它外围设备52，外围设备52可以包括提供附加特征、功能和/或有线或无线连接性的一个或多个软件和/或硬件模块。例如，外围设备52可以包括各种传感器，诸如加速度计、生物测定(例如，指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其它互连接口、振动设备、电视收发器、免提耳机、

模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、因特网浏览器等等。

节点30可以在其它装置或设备中实施，诸如传感器、消费电子产品、可穿戴设备(诸如智能手表或智能服装)、医疗或电子卫生设备、机器人、工业装备、无人机、车辆(诸如小汽车、卡车、火车或飞机)之类。节点30可以经由一个或多个互连接口(诸如可以包括外围设备52之一的互连接口)连接到这种装置或设备的其它部件、模块或系统。

图24D是示例性计算系统90的框图，该计算机系统90还可以用于实现网络的一个或多个节点，诸如图2、5、6、8-12和19A-19C中所示的客户端、服务器或代理，其可以作为M2M网络中的M2M服务器、网关、设备或其它节点操作，诸如图24A和24B中所示的节点。

计算系统90可以包括计算机或服务器，并且可以主要由计算机可读指令控制，计算机可读指令可以是软件的形式，无论在何处，或者通过任何方式存储或访问这样的软件。这种计算机可读指令可以在诸如中央处理单元(CPU)91之类的处理器内执行，以使计算系统90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单芯片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，其执行附加功能或辅助CPU 91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于E2E M2M服务层会话的系统和方法相关的数据，诸如接收会话凭证或基于会话凭证进行认证。

在操作中，CPU 91提取、解码并执行指令，并经由计算机的主数据传输路径，系统总线80，向其它资源传送信息和从其它资源传送信息。这种系统总线连接计算系统90中的部件并定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线，以及用于发送中断和用于操作系统总线的控制线。这种系统总线80的示例是PCI(外围部件互连)总线。

耦合到系统总线80的存储器包括随机存取存储器(RAM)82和只读存储器(ROM)93。这种存储器包括允许存储和检索信息的电路系统。ROM 93一般包含不能被容易地修改的存储数据。存储在RAM 82中的数据可以由CPU 91或其它硬件设备读取或改变。对RAM 82和/或ROM 93的访问可以由存储器控制器92控制。存储器控制器92可以提供地址翻译功能，该地址翻译功能在执行指令时将虚拟地址翻译成物理地址。存储器控制器92还可以提供存储器保护功能，该存储器保护功能隔离系统内的进程并将系统进程与用户进程隔离。因此，以第一模式运行的程序只可以访问由其自己的进程虚拟地址空间映射的存储器；除非已设置进程之间的存储器共享，否则它无法访问另一个进程的虚拟地址空间内的存储器。

此外，计算系统90可以包含外围设备控制器83，其负责将来自CPU 91的指令传送到外围设备，诸如打印机94、键盘84、鼠标95和磁盘驱动器85之类。

由显示控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸面板来实现。显示控制器96包括生成发送到显示器86的视频信号所需的电子部件。结合由CPU 91执行的计算机可执行指令，显示器86可以生成并操作本文所示和描述的图形用户接口。

另外，计算系统90可以包含通信电路系统，诸如例如网络适配器97，其可以用于将计算系统90连接到外部通信网络，诸如图24A-24D的网络12，以使计算系统90能够与网络的其它节点通信。单独或与CPU 91组合，通信电路系统可以用于执行本文(例如，在图6-23中)和权利要求中描述的发送和接收步骤。

应该理解的是，本文描述的任何或所有系统、方法和处理都可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式实施，所述指令在由机器(诸如M2M网络的装置，包括例如M2M服务器、网关、设备等)执行时执行和/或实现本文描述的系统、方法和处理。具体而言，上述任何步骤、操作或功能可以以这种计算机可执行指令的形式实现。计算机可读存储介质包括以用于存储信息的任何非瞬态(即，有形或物理)方法或技术实现的易失性和非易失性、可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术，CD-ROM、数字通用盘(DVD)或其它光盘存储装置，磁带盒、磁带、磁盘存储装置或其它磁存储设备，或者可以用于存储期望信息并且可由计算机访问的任何其它有形或物理介质。

应该理解的是，执行图6-23所示步骤的实体，诸如IoT设备、IoT服务器、IoT网关、IoT服务层、RAS、IoT应用、oneM2M设备、非oneM2M设备、oneM2M IPE、AE、CSE、RAS CSF、IoT用户设备、UE等可以是可以以软件(即，计算机可执行指令)的形式实现的逻辑实体，该软件被存储在被配置用于无线和/或网络通信的装置或计算机系统(诸如图24C或图24D中所示的装置或计算机系统)的存储器中并在该装置或计算机系统的处理器上执行。即，图6-23所示的(一个或多个)方法可以以软件(即，计算机可执行指令)的形式来实现，该软件被存储在装置(诸如图24C或图24D所示的装置或计算机系统)的存储器中，该计算机可执行指令在由装置的处理器执行时，执行图6-23所示的步骤。还应该理解的是，图6-23所示的功能可以被实现为虚拟化网络功能集合。网络功能不一定必须直接通信，而是它们可以经由转发或路由功能进行通信。还应该理解的是，图6-23所示的任何发送和接收步骤都可以在该装置的处理器及其执行的计算机可执行指令(例如，软件)的控制下，由该装置的通信电路系统执行。

本书面描述使用示例来公开本发明，包括最佳模式，并且还使任何本领域技术人员能够实践本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括本领域技术人员想到的其它示例。如果这些其它示例具有与权利要求的字面语言没有不同的元素，或者如果它们包括与权利要求的字面语言无实质差别的等效元素，那么这些其它示例意图在权利要求的范围内。

Claims (24)

1.一种包括处理器、存储器和通信电路系统的装置，所述装置经由其通信电路系统连接到网络，所述装置还包括存储在所述装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时，使所述装置执行包括以下的操作：

从请求实体接收抽象请求，所述抽象请求包括命令谓词、一个或多个命令对象和一个或多个命令上下文；

基于所述抽象请求，确定要执行的一个或多个服务层操作的序列；

在所述服务层处执行所述服务层操作的序列；以及

向所述请求实体发送一个或多个状态码和已执行的服务层操作的序列。

2.如权利要求1所述的装置，其中所述抽象请求包括服务层请求消息。

3.如权利要求1所述的装置，还包括存储在所述装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时，使所述装置执行包括以下的进一步的操作：

在确定所述服务层操作的序列之前，分析所述抽象请求，以确定所述命令谓词、所述一个或多个命令对象和所述一个或多个命令上下文。

4.如权利要求1所述的装置，还包括存储在所述装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时，使所述装置执行包括以下的进一步的操作：

确定所述抽象请求中存在关键词；

确定服务层操作与所述关键词相关联；以及

将所述服务层操作添加到要执行的服务层操作的序列。

5.如权利要求1所述的装置，还包括存储在所述装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时，使所述装置执行包括以下的进一步的操作：

将所述抽象请求的单词分类为名词；以及

基于名词分类，确定与所述单词相关联的服务层实体。

6.如权利要求1所述的装置，其中确定要执行的服务层操作的序列包括：

将所述抽象请求的单词分类为动词；以及

基于动词分类，确定与所述单词相关联的服务层操作。

7.如权利要求1所述的装置，其中所述指令还使所述服务层实体：

创建表示所述抽象请求的服务层资源，其中所述服务层资源包括命令谓词、一个或多个命令对象和上下文信息。

8.如权利要求7所述的装置，其中所述指令还使所述服务层实体：

接收针对所述服务层资源的第二抽象请求，其中所述第二抽象请求包括用于替换所述上下文信息的第二上下文信息；以及

使用所述第二上下文信息处理所述抽象请求。

9.如权利要求1所述的装置，其中所述抽象请求包括文本串。

10.如权利要求1所述的装置，其中所述一个或多个命令上下文包含用于在将来的抽象请求中使用的上下文信息。

11.如权利要求10所述的装置，其中所述上下文信息包括词语和与所述词语相关联的定义。

12.如权利要求10所述的装置，其中所述上下文信息包括词语和与所述词语相关联的服务层操作。

13.一种方法，包括：

从请求实体接收抽象请求，所述抽象请求包括命令谓词、一个或多个命令对象和一个或多个命令上下文；

基于所述命令谓词、所述一个或多个命令对象和所述一个或多个命令上下文，来生成服务层应用程序接口API集合，其中所述服务层API集合对服务层操作进行调用；

执行生成的API集合；以及

向所述请求实体返回指示所述抽象请求完成的状态。

14.如权利要求13所述的方法，还包括：

确定所述一个或多个命令上下文中的第一命令上下文未被识别；以及

提示所述请求实体对所述命令上下文进行定义。

15.如权利要求13所述的方法，还包括：

创建所述抽象请求的资源来存储所述命令谓词、所述一个或多个命令对象和所述一个或多个命令上下文。

16.如权利要求15所述的方法，还包括：

接收针对所述资源的请求；以及

执行生成的API集合。

17.如权利要求15所述的方法，还包括：

接收第二抽象请求，其中所述第二抽象请求针对所述资源，并且包括要对所述抽象请求进行的一个或多个改变；以及

基于所述一个或多个改变，修改所述抽象请求的资源。

18.如权利要求13所述的方法，还包括：

在执行生成的API集合之前，对生成的API集合进行排序。

19.如权利要求13所述的方法，其中对生成的API集合进行排序，使得在创建或更新操作之前执行检索和发现操作。

20.一种存储计算机可读指令的非暂态计算机可读存储介质，所述计算机可读指令在由计算设备的处理器执行时使所述计算设备执行包括以下的操作：

在服务层处从请求实体接收抽象请求，所述抽象请求包括命令谓词、一个或多个命令对象和一个或多个命令上下文；

基于所述命令谓词、所述一个或多个命令对象和所述一个或多个命令上下文，生成服务层操作集合；

在所述服务层处执行生成的操作集合；以及

向所述请求实体返回已执行的服务层操作的列表和状态。

21.如权利要求20所述的非暂态计算机可读存储介质，还存储计算机可读指令，所述计算机可读指令在由所述计算设备的处理器执行时使所述计算设备执行还包括以下的操作：

确定所述一个或多个命令上下文中的第一命令上下文未被识别；以及

提示所述请求实体对所述命令上下文进行定义。

22.如权利要求20所述的非暂态计算机可读存储介质，其中所述一个或多个命令上下文中的命令上下文包括：要对其进行操作的资源的数量、要对其进行操作的资源的标识符和名称、持续时间和期望位置。

23.如权利要求20所述的非暂态计算机可读存储介质，还存储计算机可读指令，所述计算机可读指令在由所述计算设备的处理器执行时使所述计算设备执行还包括以下的操作：

接收修改所述一个或多个命令上下文中的第一命令上下文的请求；以及

基于修改后的第一命令上下文，修改生成的服务层操作集合。

24.如权利要求20所述的非暂态计算机可读存储介质，还存储计算机可读指令，所述计算机可读指令在由所述计算设备的处理器执行时使所述计算设备执行还包括以下的操作：

接收修改所述一个或多个命令对象中的第一命令对象的请求；以及

基于修改后的第一命令对象，修改生成的服务层操作集合。

Images