Mechanism for intelligent service layer to request abstract services

Abstract

Systems and methods are described herein for enabling management of service layer operations consisting of multiple basic operations and for offloading the burden of performing such multi-step operations from requesting entities to service layer automation. Request Abstraction Services (RAS) for autonomously performing such multi-step operations are described herein. Methods and apparatus are also described herein for a service layer framework for integrating generic and functional user interfaces as services managed by the SL on behalf of the requesting entity.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 667,858, filed on May 7, 2018, and U.S. Provisional Patent Application No. 62 / 751,075, filed on October 26, 2018, which are hereby incorporated by reference in their entirety. Background Art

[0003] The Internet of Things (IoT) is an emerging technology in which everyday objects such as household appliances, motor vehicles, consumer electronic devices, personal mobile devices, environmental sensors, etc. can be connected to networks such as the Internet and can be remotely managed and controlled. The diversity of such IoT-connected devices can allow more creative and smarter uses, which improve the lives of users by providing more convenience and automation. In order to manage a large number of IoT devices, a service layer architecture is defined and standardized. In addition, over the past few decades, the user interface (UI) has evolved significantly, from ordinary displays and keyboards to mice, touch screens, tactile devices, etc. Gradually, more and more sensors have been added to consumer devices to determine the user's actions, such as analyzing gestures, detecting eye movements, interpreting directions, speed, etc. More and more methods of providing feedback are also being developed in countless audio, tactile or visual forms. Although complex machines (such as general-purpose computers) have the processing power and demand for complex interactions, these demands and capabilities may be reduced in the world of the Internet of Things (IoT). Therefore, there is a need to enhance the integration of common user interfaces in the IOT machine-to-machine (M2) service layer (SL).

[0004] Figure 1 is a diagram of an example protocol stack 100 that supports an M2M / IoT service layer. From a protocol stack perspective, a middleware service layer is typically layered on top of an existing network protocol stack and provides value-added services to client applications and other services. Therefore, the service layer is often categorized as a "middleware" service layer. For example, Figure 1 A service layer 102 is shown located between the IP networking stack and the applications. Figure 1 As shown in the example of FIG. 1 , in addition to the service layer 102, the protocol stack 100 may include an application layer 101, an application protocol layer 103 (e.g., HTTP, OCAP, or MQTT), a transport protocol layer 104 (e.g., TCP or UDP), a network protocol layer 105 (e.g., IPv4 or IPv6), and an access network protocol layer 106 (e.g., Ethernet, cellular, Wi-Fi). The service layer 102 instance can be deployed on various network nodes (gateways and servers) and can provide value-added services to network applications, device applications, and the network nodes themselves.

[0005] The M2M / IoT service layer is an example of a type of middleware service layer 102 that is specifically designed to provide value-added services for M2M / IoT type devices, applications, and data. Some industry standard bodies (e.g., oneM2M, OCF, ETSI M2M, and OMA LWM2M) have been developing the M2M / IoT service layer to address the challenges associated with integrating M2M / IoT type devices and applications into deployments such as the Internet / Web and cellular, enterprise, and home networks.

[0006] The M2M service layer may provide applications and devices with access to a set of M2M-centric capabilities supported by the service layer, which may include, but are not limited to, the following examples: security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities may be made available to applications via an application programming interface (API), which utilizes message formats, resource structures, and resource representations supported by the M2M service layer.

[0007] Figure 2 is a diagram of an example M2M / IoT deployment 200. From a deployment perspective, an M2M / IoT SL can be deployed on various types of network nodes, including, for example, servers, gateways, and devices, such as Figure 2 shown. Figure 2 The system shows an M2M / IoT application 201, an M2M / IoT server 202 executing an M2M / IoT SL 203, an M2M / IoT gateway 204 executing an M2M / IoT SL 205 connected to an M2M / IoT device 209, and an M2M / IoT device 207 executing an M2M / IoT SL 207.

[0008] The oneM2M standard defines the M2M / IoT SL. The purpose of the SL is to provide “horizontal” services that can be utilized by different “vertical” IoT systems and applications (such as e-Health, fleet management and smart homes). Figure 3 is a diagram of an example oneM2M architecture 300. The architecture 300 of the oneM2M SL may include a public service entity (CSE) that may support four reference points. The Mca reference point may interact with an application entity (AE). The Mcc reference point may interface with another CSE within the same service provider domain, and the Mcc' reference point may interface with another CSE within a different service provider domain. The Mcn reference point may interface with an underlying network service entity (NSE). The NSE may provide underlying network services such as device management, location services, and device triggering to the CSE. Figure 3As shown in the example of FIG. 3 , in a field domain 301, AE 310 interfaces with Mca reference point 330 and Mca reference point 332. CSE 311 interfaces with Mcc reference point 333, which interfaces with CSE 321 in infrastructure domain 302. NSE 312 interfaces with Mcn reference point 331. In infrastructure domain 302, AE 320 interfaces with Mca reference point 334. CSE 321 interfaces with Mcc' reference point 336 to reach the infrastructure domain of another service provider 323. NSE 322 interfaces with Mcn reference point 335.

[0009] CSE may include multiple logical functions referred to as Common Services Functions (CSFs). CSFs include but are not limited to discovery and data management & repository.

[0010] Figure 4 is a schematic diagram of an example set of CSFs 400 supported in oneM2M. The service layer is functionally enabled by CSFs. A set of CSFs can be instantiated as a set of public service entities (CSEs) 401, such as Figure 4 Examples of CSFs and their functions may include the following:

[0011] Application and service layer management CSF 402: can provide management of AE and CSE.

[0012] Discovery CSF 403: Information about applications and services can be searched based on some filtering criteria.

[0013] Registration CSF 404: can provide the AE (or other remote CSE) with the function of registering with the CSE. This can allow the AE (or remote CSE) to use the services of the CSE.

[0014] Communication management / transfer processing CSF 405: can provide communication with other CSEs, AEs and NSEs. The CSF can decide when and which communication connection to use for delivering communication, and buffer communication requests if necessary and allowed so that the communication requests can be forwarded at a later time.

[0015] Group Management CSF 406: may provide processing of group-related requests and enable the M2M system to support, for example, bulk operations on multiple devices, applications, and the like.

[0016] Security CSF 407: can provide security functions for the service layer, such as access control, including identification, authentication and authorization.

[0017] Data Management and Repository CSF 408: may provide data storage and brokering functions (eg, collecting data for aggregation, reformatting data, and storing data for analysis and semantic processing).

[0018] Location CSF 409: may provide functionality that enables AE to obtain geographic location information.

[0019] Service Charging and Accounting CSF 410: can provide charging functions for the service layer.

[0020] Device Management CSF 411: can provide management of device capabilities on M2M gateways and M2M devices.

[0021] Network Service Exposure, Service Execution and Triggering CSF 412: can manage the communication with the underlying network to access network service functions.

[0022] Subscription and Notification CSF 413: May provide functionality that allows one to subscribe to an event and be notified when that event occurs.

[0023] Figure 4 A Group Management CSF 419 and a Semantic CSF 420 are also shown.

[0024] The oneM2M architecture may provide CSE 401 to interface with other entities including but not limited to: AE 417; other CSEs; and Network Service Entity (NSE) 418 (ie, underlying network) via Mca reference point 414, Mcc (and Mcc') reference point 415, and Mcn reference point 416.

[0025] The interaction between the requester and the service layer can be based on RESTful principles in which atomic operations can be performed on resources maintained at the service layer. A resource or service layer resource can be a uniquely addressable object (i.e., a data structure) containing information (e.g., data) and can be hosted by the M2M / IoT service layer. Resources can be accessed via a uniform resource identifier or URI. The atomic operations themselves can be stateless, meaning that the communication between the requester and the service layer is self-contained within a specific request. A request can include a self-describing message that includes the method of the operation, the URI, and some data or metadata that may be used by the resource.

[0026] The following definitions are useful when describing SL. Although the following definitions are described for M2M / IoT systems, they may apply to any such similar systems.

[0027] The M2M / IoT Service Layer (SL) can be a software middleware layer that supports value-added services for M2M / IoT applications and devices through a set of application programming interfaces (APIs) and underlying networking interfaces. The SL can include a set of M2M / IoT services that can be used by devices, applications, and users. The SL can also host resources.

[0028] An M2M / IoT application may be a software entity that registers with the M2M / IoT service layer and performs application-specific functions related to a specific M2M / IoT use case, such as, for example, eHealth, smart energy, or home automation.

[0029] An M2M / IoT entity may be an M2M / IoT application or an M2M / IoT device or a user of an M2M / IoT application or an M2M / IoT device.

[0030] An M2M / IoT service may be a software entity that provides capabilities (eg, data management, security, device management) to an M2M / IoT entity.

[0031] The service layer entity may be an M2M / IoT entity registered and / or registered with the M2M / IoT service layer. Examples may include an M2M / IoT application or an instance of the M2M / IoT service layer.

[0032] A service layer device may be an entity that is registered with the M2M / IoT service layer and may host one or more applications.

[0033] A service layer primitive may be a message that uses a service layer API to access data or services provided by the service layer. A service layer request and a service layer response are examples of service layer primitives.

[0034] A service layer request may be an operation issued by a service layer entity to a service layer resource.

[0035] M2M / IoT service layer registration may be an act of an M2M / IoT service layer entity registering with the M2M / IoT service layer.

[0036] An M2M / IoT registrant may be an M2M / IoT entity such as, for example, an application, a sensor, a device and / or other M2M / IoT service layer that registers with or uses the M2M / IoT service layer.

[0037] The M2M / IoT service platform may be a platform deployed by an M2M / IoT service provider that may optionally host an M2M / IoT service layer.

[0038] The M2M / IoT service provider may be a stakeholder (eg, a company) responsible for the deployment and management of the M2M / IoT service platform.

[0039] An M2M / IoT service subscriber may be a stakeholder (eg, a person) who establishes a subscription (ie, registers) with an M2M / IoT service provider to access and use its M2M / IoT services.

[0040] M2M / IoT service registration may be an act of an M2M / IoT service subscriber establishing a service subscription with an M2M / IoT service provider and registering its devices, applications, data, and authorized users using the service provider's platform.

[0041] The M2M / IoT user may be an authorized entity associated with an M2M / IoT service subscriber. The M2M / IoT service subscriber may grant specified privileges to a specified M2M / IoT user to access specified devices, applications, data, and services via the M2M / IoT service provider's platform.

[0042] As described herein, persistence may refer to the storage of data in a computer system beyond the operations that created the data. Such data may remain in the computer system until deleted or damaged. Pre-persistence may refer to the process performed before the data is stored. Post-persistence may refer to the process performed after the data is stored.

[0043] Metadata may be data that provides information about other data.

[0044] The oneM2M architecture is a distributed architecture and supports the deployment of M2M / IoT services in a distributed manner across the following types of nodes: Application Service Node (ASN); Application Dedicated Node (ADN); Middle Node (MN); Infrastructure Node (IN); and Non-oneM2M Node (NoDN).

[0045] An ASN is a node that includes one CSE and includes at least one application entity (AE). In an example embodiment, the ASN may reside in an IoT device.

[0046] An ADN is a node that includes at least one AE and may not include a CSE. In an example embodiment, an application-specific node may reside in a constrained IoT device.

[0047] A MN is a node that includes a CSE and includes zero or more AEs. In an example embodiment, the MN may reside in an IoT gateway.

[0048] An IN is a node that includes a CSE and includes zero or more AEs. A CSE in an IN may include CSE functionality that is not applicable to other node types. In an example embodiment, an IN may reside in an IoT service infrastructure.

[0049] A non-oneM2M node is a node that may not include a oneM2M entity (neither an AE nor a CSE). Such a node may represent a device that is attached to the oneM2M system for interworking purposes (including management).

[0050] Figure 5 is a configuration diagram that interconnects the various entities supported within the oneM2M system 500. The system 500 may include multiple IoT servers (also referred to herein as CSEs) that may be interconnected and may manage multiple IoT devices. The term IoT server as used herein may refer to a cloud server, an edge gateway, or a home gateway (i.e., any entity that provides IoT services within an IoT system). The architecture may be divided into two main domains: the infrastructure domain 501 and the field domain 502. The infrastructure domain 501 may include a cloud server that serves as the main controller of the system 500, which Figure 5 In the expression Figure 5 The field domain may include field-deployed IoT servers located in various locations, including but not limited to factories, office buildings, or homes. These servers are located in Figure 5 504a in the intermediate node 504b and MN-CSE 505a in the intermediate node 505b. The field domain 502 may also include mobile IoT servers running on mobile devices such as, for example, service trucks or mobile phones. These mobile devices are in Figure 5 The IoT device is represented as ASN-CSE 506a in ASN 506b and ASN-CSE 507a in ASN 507b. Figure 5 denoted as ADN 508a and 508b and NoDN 509a, 509c, 509d, 509f and 509g, each of which communicates with one of the CSEs in the system. Summary of the invention

[0051] Some service layer operations are basic in nature and may be related to each other. However, such operations are usually performed in a piecemeal manner, requiring the active participation of the requesting entity (i.e., application or user). Even when requesting to perform batch operations, the requesting entity may be required to collect a large amount of information before initiating the batch processing, and the additional required information may not be collected until the later stage of the processing. Again, this requires the active participation of the requesting entity. During each step of the processing, manually performing relevant service layer operations and extracting relevant data to burden the requester is not an effective and scalable method. Similarly, over the past few decades, various user interfaces have evolved significantly, from ordinary displays and keyboards to mice, touch screens, tactile devices, etc. More and more sensors have been added to consumer devices to determine what the user is trying to do, such as analyzing gestures, detecting eye movements, interpreting directions, speed, etc. More and more methods of providing feedback are also being developed in countless audio, tactile or visual forms, etc. Although complex machines (such as general-purpose computers) have the processing power and demand for complex interactions, these demands and capabilities may be reduced in the world of the Internet of Things (IoT). Many devices perform well using a few basic interactions; thus, a person can use only a few very simple interactions with the same device for a variety of purposes, as long as they know which function needs to be performed. Similarly, the same simple interactions can be used for a variety of devices, for example, a sliding scale is the basic input required for the volume function of a stereo, the temperature setting of a washing machine, the zoom in a camera, etc.

[0052] This article describes systems and methods for managing service layer operations consisting of multiple basic operations and offloading the burden of performing these multi-step operations from requesting entities to service layer automation. This article describes a request abstraction service (RAS service) for autonomously performing such multi-step operations. Also described herein are methods and devices for a service layer framework that integrates general and functional user interfaces into services managed by the SL on behalf of the requesting entity. These user interfaces, referred to as "interactors" in this article, process user interactions and generate general and functional events that are converted into input / output. Also described herein are methods and devices for defining an interactive context management (ICM) service that evaluates contexts and maintains corresponding context states. The ICM service uses context states to evaluate events based on user interactions and provides mappings between them and application-specific events. The ICM can be configured with templates and policies related to interactors, such as an interactor library. The requesting entity can query and discover the capabilities related to interactors provided by the SL by discovering the interactor library or individual templates. According to the methods and devices described herein, an application can provide information about its own capabilities related to interactors. In addition, the ICM can be configured with rules and parameters that enable the ICM to monitor the SL and maintain and switch contextual states accordingly. The ICM can instantiate interactors on behalf of applications so that there is a common understanding of user interactions in the system and their functions and correspondence with application operations. The process of associating applications and interactors can allow multiple interactors to be used in the system based on context.

[0053] This summary is provided to introduce some concepts in a simplified form, which are further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all disadvantages mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to promote a more robust understanding of the present application, reference is now made to the accompanying drawings, in which like elements are represented by like reference numerals. These drawings should not be construed as limiting the present application, but are merely exemplary.

[0055] Figure 1 An example protocol stack is illustrated having a service layer between an application protocol and an application;

[0056] Figure 2 illustrates a sample M2M / IoT deployment;

[0057] Figure 3 illustrates an example oneM2M service layer architecture;

[0058] Figure 4 illustrates an example CSF currently defined by oneM2M;

[0059] Figure 5 illustrates an example configuration supported by oneM2M;

[0060] Figure 6 illustrates an example of basic service layer operation;

[0061] Figure 7 illustrates example components of a smart request abstraction service (RAS);

[0062] Figure 8 illustrates an example sequence diagram for processing an abstract request;

[0063] Fig. 9 illustrates an example sequence diagram for adding context information to a RAS;

[0064] Fig.10 illustrates an example sequence diagram for requesting context information via RAS;

[0065] Fig.11 illustrates an example call flow of interaction between components of the RAS and the service layer;

[0066] Fig.12 illustrates an example sequence diagram for reusing an abstract request;

[0067] Fig.13 An example Common Services Entity (CSE) implementing RAS functionality is illustrated;

[0068] Fig.14 illustrates an example graphical user interface (GUI);

[0069] Fig.15 is a diagram of an example oneM2M service layer supporting an initial set of Common Service Functions (CSFs);

[0070] Fig.16 is a diagram of an example home control platform that integrates multiple devices and appliances;

[0071] Fig.17 is a diagram of an example system depicting signaling between interactors, user interactions, Ix-events, Ax-events, and SL ICMs according to one embodiment;

[0072] FIG18A is a diagram of another example system depicting signaling between interactors, user interactions, Ix-events, Ax-events, and SL ICM;

[0073] 18B is a diagram of a system that implements a conventional example using a UI of an embedded application;

[0074] FIG19A is an example of a user interface style for an interactor;

[0075] FIG19B is an example of another user interface style for another interactor;

[0076] FIG19C is an example of another user interface style for another interactor;

[0077] Fig. 20 is a diagram of an example system in which a SL provides an application with the ability to use two different interactors depending on the context, according to one embodiment, which may be used in conjunction with any of the embodiments described herein;

[0078] Fig.21 is a diagram of an example interactor state machine according to another embodiment that may be used in conjunction with any of the embodiments described herein;

[0079] Fig. 22 is a diagram of an example process for use in ICM, according to one embodiment, which may be used in conjunction with any of the embodiments described herein;

[0080] Fig.23 is a diagram of an example process for converting user interactions into interactor events, according to one embodiment, which may be used in conjunction with any of the embodiments described herein; and

[0081] Fig.24A is a system diagram of an example machine-to-machine (M2M) or Internet of Things (IoT) communication system in which one or more disclosed embodiments may be implemented;

[0082] Fig. 24B Yes, you can Fig.24A A system diagram of an example architecture used within an M2M / IoT communication system is shown;

[0083] Fig.24C Yes, you can Fig.24A A system diagram of an example M2M / IoT terminal or gateway device used within the illustrated communication system; and

[0084] Fig.24D It can be implemented Fig.24A A block diagram of an example computing system that illustrates aspects of a communication system. DETAILED DESCRIPTION

[0085] Described herein are systems and methods for enabling management of service layer operations consisting of multiple elementary operations and for offloading the burden of performing these multi-step operations from requesting entities to service layer automation.

[0086] The following is a list of acronyms related to service level technology that may appear in the above description. Unless otherwise specified, the acronyms used in this article refer to the corresponding terms listed below.

[0087] ADN Application Dedicated Nodes

[0088] AE Application Entity

[0089] API Application Programming Interface

[0090] ASE Automated Service Registration

[0091] Apps

[0092] ASE-C Automated Service Registration Client

[0093] ASE-S Automated Service Registration Server

[0094] ASN Application Service Node

[0095] CRUD Create, Retrieve, Update, Delete

[0096] CSE Public Service Entity

[0097] CSF Public Service Function

[0098] IN Infrastructure Network

[0099] IoT

[0100] IP Internet Protocol

[0101] M2M Machine to Machine

[0102] MN intermediate node

[0103] NoDN Non-oneM2M Node

[0104] PoA Access Point

[0105] RAS Request Abstract Service

[0106] REST Representational State Transfer

[0107] ROA Resource Oriented Architecture

[0108] SL Service Layer

[0109] URI Uniform Resource Identifier

[0110] In an M2M / IoT (hereinafter referred to as "IoT") deployment, certain service layer operations may involve or follow the processing of multiple basic operations. Such basic operations may be related to each other. For example, a resource discovery request may be followed by a request to create an access control policy for each discovered resource or to update the expiration time of those resources.

[0111] Conventionally, processing of such basic operations may require continuous participation of the requesting entity, although the same or related basic operations may be performed each time the requesting entity requests a service layer operation. The continuous participation of the requesting entity may be burdensome to the requesting entity in many ways.

[0112] Consider a use case regarding processing in a smart factory. Figure 6 An example method 600 for basic service layer operations is illustrated. A requesting entity or "requestor" 602 (e.g., a user or application) can perform one or more basic operations with the service layer 601 to grant access rights to a new visitor. For this use case, assume that a financial analyst is accessing a smart factory of a manufacturing company to access IoT technologies employed within the company. The requestor 602 can first create an access control policy (ACP) for the analyst so that the analyst can be granted access to the smart factory. This process is performed by Figure 6 611, 612, and 613. Requester 602 may save the resource identifier of the resource created in step 4 for future use. Requester 602 may also discover the door lock of the west wing of the factory that the analyst is touring, such as Figure 6 As shown in steps 615, 616 and 617 of . At step 618, the requester 602 can parse the received discovery response message and can select the URI of the door lock found from the discovery request. For the selected door lock, the requester 602 can use the resource identifier saved in step 614 to update the appropriate access control policy attribute (e.g., acpID attribute). Steps 619, 620 and 621 can be performed for each door lock selected in step 618.

[0113] The Smart Factory use case describes the interdependencies of the basic operations. For example, the acpID update performed in steps 619, 620, and 621 may require the resource identifier saved in step 4 and the door lock list found in step 618. In addition, the number of results found in step 618 may change the number of repetitions of steps 619, 620, and 621. Due to this dependency, it may not be possible to Figure 6The call flow and other similar call flows generate batch requests. Batch requests or batch request generation may require the requester to provide information for the request before executing the batch request. In the smart factory use case, the required information is available only after executing steps 611 and 615. Not all information required for step 619 is available before issuing the request for step 611. Therefore, the call flow described in the use case cannot be used as a batch request.

[0114] Figure 6 Another burden on the requester of a basic but related request is illustrated. As shown in the processing at steps 613, 614, 617 and 618, the requester may be tasked with extracting the data returned in the response. Figure 6 In this use case, the requester must save the resource ID extracted in step 614 for future use in later steps. In addition, the resource discovery results parsed in step 618 may be large and may require the requester to save the URI for subsequent update operations. The requester may also have to make a large number of requests or a large batch request that includes the saved information from steps 614 and 618. In this use case, the requester must manually perform the Figure 6 The service layer requests are highlighted at steps 619, 620 and 621 of FIG.

[0115] A service layer may be in place to perform such operations to relieve the requester of having to perform the operations manually. The service layer has the ability to process the information provided in the response and use it as input for another request. The basic operations may be necessary operations that can be performed routinely within the service layer and are simply used for service layer processing. Service layer architectures (such as oneM2M) lack the ability for requesters to specify abstract requests that will result in the execution of multiple sequences of basic operations.

[0116] The capabilities and example embodiments described herein may provide solutions to the above problems and other problems. Systems and methods for managing service layer operations consisting of multiple basic operations and offloading the burden of performing these multi-step operations from requesting entities to service layer automation are described. A request abstraction service (RAS) for autonomously performing such multi-step operations is described herein.

[0117] The RAS may be able to accept and interpret higher abstract requests at the service layer and perform basic operations inferred from or associated with the request. The RAS may be able to relieve the requester from having to manually perform multiple basic operations. For common operations that may be cumbersome for the requester to perform manually, the service layer may support such basic operations. For example, as described above, the requester may need to parse and extract data from the request and use such data in future requests. The basic operations of parsing and extracting data may be supported by one or more service layers. The RAS may be used to perform the parsing and extraction of data and also perform the resulting operations within the service layer.

[0118] The RAS may manage the services provided by the service layer. The RAS may provide one or more processing functions, such as the following processing functions.

[0119] The RAS may define one or more methods by which a requester may communicate a higher-level abstract request to the service layer. A structure may be defined for the abstract request that may utilize semantics or certain word structures that are more appropriate for issuing commands. Such a word structure may simplify the operation of requesting an abstract service.

[0120] RAS may define one or more mechanisms to dynamically process abstract requests. Such mechanisms may provide decomposition of abstract requests, classification of elements of requests, association of request elements with SL operations, and / or determination of context information from requests.

[0121] RAS can generate one or more application programming interfaces (APIs) that call service layer operations. As part of this generation, an intelligent API generator can decompose abstract requests and use the output of the above mechanism to generate APIs that, when called, perform service layer operations to achieve the desired results of the abstract requests.

[0122] The RAS may define one or more mechanisms for sequencing service layer operations to execute the generated API. An operation sequencer may interact with the service layer to perform multiple operations to complete an abstract request. Requesting an abstract service may return a status to the requester and may include a list of service layer actions and / or resources that were operated to complete the abstract request.

[0123] The RAS may define one or more methods to enable a requestor to dynamically provide context information to the RAS. Such methods may use an abstract request to provide context information to a requesting abstract service. The context information may be stored in one or more components of the RAS to improve the reasoning capabilities of the RAS. Alternatively or additionally, the RAS may prompt the requestor to (1) define certain contexts that the RAS cannot resolve, or (2) prompt the requestor when it determines that context is missing from an abstract request.

[0124] The RAS may define one or more methods by which an abstract request may be reused. Such methods may include saving an existing abstract request as a resource and identifying the resource in a new abstract request while specifying new context information that overrides the existing context information.

[0125] The RAS may define a structured format in which an abstract request may be made to the service layer. The structured format may use language constructs and may include at least three main components: a command predicate, one or more command objects, and one or more command contexts. It should be appreciated that the term "predicate" is used to refer to the predicate verb of an abstract request, which may specify a requested service layer operation. The structure of an abstract request may be defined as follows:<Command_Predicate> {(one or more) modifier(s) Command_Object} {(one or more) modifier(s) Command_Context}.

[0126] Command_Predicate can refer to a service layer operation.

[0127] Command_Object(s) may represent one or more subjects / objects implied by the request.

[0128] Command_Context(s) may represent one or more contexts of the request. The context may refer to the number of resources to be operated on, the type and identifier / name of the resource to be operated on, the duration applicable to the request, and the desired location applicable to the request.

[0129] In addition, the abstract request may include one or more modifiers to further describe (one or more) Command_Object and / or (one or more) Command_Context. Such modifiers may describe quantities, add filtering criteria, or make service layer operations related to the request.

[0130] Although the abstract request may be structured as defined above, the abstract request may take any other form capable of conveying the same or similar information.For example, the abstract request may include a request message or other data structure including information associated with the parameters defined above.

[0131] Example abstract requests that can be created using the defined abstract request structure include at least the following: "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"; "Update firmware for all sensors with version 1.3d but not for sensors with version 1.3a"; "Give <guest>access to room 123 and to swimming pool and to fitness center"; and "Group all street lights between 1st and 10th streets".

[0132] SL requesters can issue abstract requests via various interfaces that the request abstract service can provide. Abstract requests can be sent programmatically to the public interface of the service layer as request messages for defined URIs. Another method for sending abstract requests can be implemented via one or more graphical user interfaces provided by the service layer, such as a web interface that can be used via a network such as the Internet, a tablet or a phone.

[0133] The RAS can decompose the received abstract request into its components. The RAS can also determine the SL operations to be performed. The RAS can also interact with the service layer to perform the SL operations and complete the abstract request. Various components of the RAS can be defined.

[0134] Figure 7 Components of an example RAS 700 are shown. The RAS 700 can perform a logical analysis 704 of an abstract request 703 to classify the individual words of the request. A keyword detection component 702 and a context derivation component 705 can collect information about the abstract request 703. Such information can be used by an API generator 706 to generate requests to be executed by a service layer. An operation sequencer 707 can interface with a service layer 708 to perform operations that implement the abstract request and return a status or output 709 to the requester.

[0135] Figure 8 An example sequence diagram for processing an abstract request 800 is shown. Note that Figure 8 , RAS 801 is shown as being separated from service layer 802; however, RAS 801 may also be integrated as a part of service layer 802 or be co-located with service layer 802.

[0136] At step 811, the requester 803 may issue or send an abstract request to the service layer 802. An example of an abstract request for the smart factory use case described above may include issuing the following command: "Give <analyst>"Give <analyst> access to all doors in the west wing for only today."

[0137] At step 812, the service layer 802 may receive and process the request. The SL 802 may perform message validation and may also authenticate and / or authorize the requester. Other SL-centric processing may also be performed. The service layer 802 may also structure the abstract request in the manner described above or in any other suitable manner.

[0138] At step 813, service layer 802 may send the abstract request to RAS 801 for further processing.

[0139] At step 814, RAS 801 can perform a logical analysis on the abstract request to determine the underlying terms of the abstract request. RAS 801 can extract and separate such terms. These terms can be converted into service layer operations in subsequent steps of the call flow. As part of the logical analysis, one or more words and / or word groups can be classified into their respective classifications, as described herein.

[0140] At step 815, the RAS 801 may send the classified words and word groups to a keyword detection unit, which may associate SL operations with the words. Additionally, if such relationships are available, request link relationships may be created to sort requests together and generate the desired output. For example, the output of a resource discovery request may be linked to the input of the request to create an access control policy for the discovered resources. For the smart factory use case, an access control policy may be created for a door located in the west wing of the smart factory.

[0141] At step 816, the logical analysis output may also be used to determine context about the abstract request. The smart API generator may use such context to determine an advantageous way to sequence the SL operations to be performed. Context such as the number of resources, identifiers and names, duration, and expected location may be determined and used in smart API generation.

[0142] Steps 817 and 818 may be performed when an element of the abstract request is not identified and / or context information (eg, location or time information) is missing in the abstract request.

[0143] At step 817 , the RAS 801 may prompt the requester via the SL to provide the context or context information under consideration.

[0144] At step 818, requester 803 may respond with a recognizable context definition. Note that if more than one context cannot be determined from the multiple elements of the abstract request and / or if additional context information (e.g., location, time) is missing, then there may be multiple iterations of steps 817 and 818. For example, the abstract request "Give <analyst>"access to all doors in the west wing" can be determined to be missing a time component required to create an access control policy. When creating an access control policy, the RAS can prompt the requester for the duration that applies to the access control policy. For cases where the requested context is optional, the requester can provide a value in the response message, or can deny the request and have the service layer assign a default value. If no context is provided for a mandatory element, the RAS can generate an error, abort the operation, and jump to step 11.

[0145] At step 819, the smart API generator can determine how to sort the SL operations. The smart API generator can also determine the input parameters required for each request (if any). The smart API generator can perform this determination by using the results of the logical analysis, keyword detection, and context derivation components determined from steps 4-6, as well as the information provided by the requester in step 8. The smart API generator can link the SL operations together to generate the desired output. However, it is noted that the operation of the smart API generator may be limited by the ability of the service layer to construct the API. For service layers that do not support flexible APIs, the smart API generator may be limited to executing the functions of the available APIs and performing post-processing to generate the desired results. For service layers that can support flexible APIs or advanced operations of RAS, additional operations are also possible, for example, the output of a SL operation can be forwarded to the input of another SL operation.

[0146] At step 820, the smart API generator can interact with the service layer 802 to execute the operations generated in the previous steps. The operation sequencer can be used to manage the interaction with the service layer. There may be multiple interactions between the operation sequencer and the service layer. In the case where the RAS is integrated with the SL 802, the interaction can occur inside the service layer 802.

[0147] At step 821, the result of step 820 can be returned to the requester 803 in an appropriate state. Such a result can be sent from the RAS to the requester via the service layer in a response message. The response message can also include an indication of which actions were performed and one or more results associated with those actions. If the operation of step 10 is successful, then the appropriate service layer resources may have been created. In those cases, a list of SL resource URIs that were created, updated, or deleted can be sent to the requester. If the operation in step 10 is unsuccessful, then the RAS can provide detailed information on the sequence of operations and at which point the failure occurred.

[0148] The requester can use the RAS interface to provide context input for processing abstract requests. Figure 8 Such an example utilization is shown in steps 817 and 818 of . Individual requests to provide context data may also be given separately as independent abstract requests, and such context data may be stored by the RAS for processing future requests. For example, the RAS may store the context data as a rule of a policy or in a lookup table of a context derivation component. The context input may also include new words that may be added to a keyword detector to identify associated SL operations. The new context information may then be used and referenced in future abstract requests. For example, context information about the location of the west wing of a smart factory may be provided to the RAS during initial deployment. Geofence data may be used to establish the boundaries of a smart factory, and the western portion of the smart factory may be defined as one or more locations within the geofenced area. The requester may also provide the coordinates of a GPS device to the RAS to define the area covered by the west wing of the smart factory. Such interaction with the RAS may be performed using abstract requests as described herein, where such requests may add context information to the RAS instead of requesting the RAS to perform one or more operations on the SL. For example, the abstract request "Define the area for the west wing to be <geofencedata>"Define the area of ​​the west wing as <geofence data> in the context derivation component" can be used to configure the geo-fence area of ​​the west wing of the smart factory.

[0149] The requester may also provide context information for the words that may allow the RAS to recognize those words when used in future abstract requests. Such context information may be stored in a context derivation component to identify words for which associations or references to SL resources or parameters may be inferred. For example, in addition to the geo-fence data provided to "west wing", the word "west wing" may also be classified as a location. Classifying a word as a location may indicate a need to utilize location services within the SL. Similarly, various time formats may be defined in a context derivation component that may be associated with a time function, such as hours: minutes: seconds (hh:mm:ss). Other context information may be provided to the RAS to improve detection of context information.

[0150] A requester may issue abstract requests to the RAS at a higher level of abstraction than that described in the existing SL architecture. Such requests may use language constructs that may be used to infer the execution of SL operations on behalf of the requester. Because these abstract requests may be used to direct the actions to be performed by the service layer, commands may be issued utilizing only a subset of the language constructs.

[0151] The abstract request in text format may be routed to a logical analysis component to separate the words in the request. The resulting words may be classified into appropriate word categories (e.g., parts of speech), such as nouns, verbs, adjectives, adverbs, prepositions, conjunctions, etc. Such classification may be performed for each word separately.

[0152] The logical analyzer can perform additional types of classification based on sentence structures such as clauses and phrases. For this type of classification, groups of words can be combined to form clauses or phrases. The logical analyzer can determine how such groups of words are formed to detect and tag appropriate groups of words. For example, a phrase can be a group of related words that can start with a preposition and can end with a noun, while a clause can be a group of related words that contains both a subject and a verb. Using such definitions, the logical analyzer can group words into categories. Table 1 shows the words that are classified by the logical analyzer for the example abstract request "Give <analyst>Example of a classification performed by "Give <analyst> access to all doors in the west wing for only today".

[0153]

[0154]

[0155] Table 1 - Examples of logical analysis classification types

[0156] Keyword detection and association components can determine the appropriate service layer operations inferred from the abstract request. Because the request is given at a higher level of abstraction, there may be implicit references to multiple SL operations that may not be obvious at initial observation. For example, the abstract request "Give <analyst>"access to all doors in the west wing for only today" may imply that multiple SL operations are required to execute the abstract request—there is a requirement to discover resources and to create and / or update resources. To implement such requirements, a keyword detector can be programmed to recognize keywords that can be associated with service layer operations. Table 2 shows examples of words that a keyword detector can recognize and associate with SL operations. Note that the words "Associate" and "Define" are used for abstract requests that update the context in the request abstract service rather than perform an SL operation. By using such words, additional words can be added to the RAS to support a wider vocabulary set that requesters can leverage in future abstract requests.

[0157]

[0158] Table 2 - Examples of keyword associations with SL operations

[0159] Using the classification provided by keyword association and logical analysis, the keyword detector may be able to determine the potential SL interactions required to perform the abstract request. The classification of verbs can determine the SL operations that may be required, such as resource discovery, performing CRUD operations on resources, enabling or disabling functions, etc. The classification of nouns can determine the SL entities, resources, attributes, or metadata to be operated on. The keyword detector can first identify the clauses reported by the logical analysis to locate the verbs that can be used to determine one or more appropriate SL operations for the abstract request. The keyword detector can then locate the nouns to identify the service layer entities to which the verbs can be applied and annotate them as "objects". Objects can be further classified as primary objects or secondary objects - primary objects can be objects found in clauses, while secondary objects can be objects found in phrases. In some cases, primary objects may not yet exist in the service layer because they may be objects considered by the abstract request, while secondary objects can be assumed to already exist in the service layer. Table 3 shows an example of keyword classification for the above example abstract request.

[0160]

[0161]

[0162] Table 3 - Keyword classification examples

[0163] After performing keyword classification, the keyword detector can perform an evaluation to determine the subject and predicate of the abstract request. The subject and predicate can typically be found in a clause. The identification of the subject and predicate can allow the intelligent API generator to generate SL operations associated with the desired operation and for the desired subject. For example, data identified as a subject can be used to perform access control checks, become part of the filtering criteria in a resource discovery request, or become the value of a resource attribute. The identification of the predicate can be used to identify the underlying SL operations that form the basis of the abstract request.

[0164] A context inference component may be responsible for examining descriptive words that can infer associations between operations and resources. Such a component may focus on word categories for prepositions and conjunctions. These word categories can infer relationships between nouns and provide clues about how service layer operations are grouped together. A context inference component may also examine word categories for adjectives and adverbs to determine properties such as quantity, time, location, and so on.

[0165] To enable some level of inference, contextual inference words may be configured in the request abstraction service to indicate relationships and / or sequences of operations when used in an abstract request. Table 4 shows some example words that may be used to obtain the context of words in an abstract request. For example, the presence of the word "before" may refer to the order in which SL operations are performed at or compared to a certain date or time. The inferred context may also depend on the proximity of other words in the abstract request. The abstract request "delete all subscription resources before 09 / 07 / 2018 andowned by<user_name> (delete all subscription resources owned by <username> before September 7, 2018)" shows that after "before" is a term that resembles a date; therefore, the RAS can determine that a comparison with that date is needed. As previously described, additional terms can be added to the request abstraction service to enable the RAS to better identify contextual relationships and / or ordering of operations. Such terms can be evaluated for potential links between the noun and the phrase that follows it. In some cases, the order of operations can be inferred; in other cases, operations can be combined or checked against each other.

[0166]

[0167]

[0168] Table 4 - Examples of context-derived words

[0169] The context derivation component can perform an initial pass of the abstract request to determine potential relationships or orderings implied by the abstract request. Using the logical analysis output, the context derivation component can create a matrix between the entries contained within the clauses and between the entries in the phrases in the abstract request. Table 5 shows an example matrix associated with the words in the example abstract request above. Within the clause, the matrix shows that "Give" and " <analyst>" with "Give" and "Access". Potential links are indicated in Table 5 by an "X" marked in the cells of the columns under the contextual relationship matrix. Each column of the matrix can indicate a separate relationship. In the first column, there is a potential link between "Give" and "Access". <analyst>” has an “X” and, therefore, they are potentially related. The cells associated with “Give” and “Access” each have an “X” in the second column, indicating that they may also be related. Similarly, the matrix shows that “Access” may be related to every phrase found in the abstract request. To accomplish this, the context inference component may be programmed using guidance about language construction to identify subject-predicate pairs, predicate-object pairs, and prepositional phrase relationships with adjacent nouns.

[0170]

[0171] Table 5 - Example of context matrix

[0172] The context inference component can also perform another evaluation to determine one or more inferences of phrases in the clause to nouns. Classifications can include objects, locations, and times associated with specific nouns. Profiles of words in each of these classifications can be provided to the RAS to make this determination. The RAS can also use knowledge of prepositions to help determine inferences of phrases. For example, a prepositional phrase beginning with "at" can infer a location, while a phrase beginning with "during" can infer a time. Table 6 shows an example of phrase inferences for the above abstract request.

[0173]

[0174] Table 6 - Phrase inference examples

[0175] The context derivation component may also check the logical analysis output for descriptive words that may be used as qualifiers in service layer operations. Such a check may include the identification of adjectives and adverbs that may be used as search criteria in SL operations. Table 7 shows some examples of qualifiers that may be assigned during such a check.

[0176]

[0177] Table 7 - Qualifier detection example

[0178] As described above, context can be dynamically added by sending an independent abstract request to the RAS using keywords such as "Define" or "Associate". Other keywords can also be specified to indicate context updates in the RAS. Such keywords can be stored in a profile or lookup table used by the context derivation component to add context to the abstract request. Keywords can be added using the same abstract request structure as described above. For example, the abstract request "Associate locks to doors in the context derivation component" can link locks to doors and add this association to the context derivation component. Other examples may include "Define west as a location in the context derivation component" or "Define 20180425T160632 as a unit of time".

[0179] Fig. 9 An example call flow 900 is shown where a requester makes an abstract request to add context information to a RAS. Note that the abstract request uses the word "Define" to indicate that the request is for the addition or update of context information in the RAS 901, rather than a request to initiate an SL 902 operation.

[0180] At step 911, requester 903 may issue an abstract request "Define west wing as<geofence_area> in context derivation component (Define the West Wing as <geo-fence area> in the context derivation component)". This request follows the general abstract request structure definition described in this document, but uses the command predicate "define" to indicate that this is a context update rather than a request for one or more SL 902 operations. Therefore, the abstract request may only update information managed within the requesting abstract service and may not perform SL 902 operations.

[0181] Can be similar to Figure 8 Steps 812-815 are used to execute steps 912 to 915.

[0182] At step 916, since the command verb is set to "define", the context derivation component can determine that this is a request to add or update context information in RAS 901. The abstract request from step 911 specifies the target as the context derivation component. However, other RAS components may also be specified and will also be updated in the appropriate component.

[0183] At step 917, with the help of the service layer, RAS 901 may return an appropriate response to the requester indicating the status of the update.

[0184] In another example, if the RAS does not recognize a word, the request abstraction service may prompt the requester to provide contextual information.

[0185] Fig.10 An example call flow 1000 is shown in which the RAS does not recognize the term "entryways" and prompts the requester to define such a term. The abstract request in this example is: "Give <analyst>access to all entryways in the west wing for only today". Here, the word "entryways" has been replaced by Fig. 9 The previous word "doors" used in the abstract request.

[0186] At step 1011, requester 1001 may issue an abstract request, "Give <analyst>"Give <analyst> access to all entryways in the west wing for only today."

[0187] Can be similar to Figure 8 Steps 812-816 are used to execute steps 1012 to 1016.

[0188] At step 1017, in this case, the RAS 1001 may not recognize the term "entryways" and may not be able to determine the appropriate context. Therefore, the RAS 1001 may prompt the requester 1003 to define the term "entryways" with the help of the service layer 1002.

[0189] At step 1018, in response, requester 1003 may return an abstract request "Associate entrywayswith doors." The request uses the keyword "Associate," and therefore, RAS 1001 may determine that the abstract request may apply to an update of contextual information. RAS 1001 may then add the context that "entryways" may be associated with "doors," which may already be associated with "locks." Therefore, RAS 1001 may be able to proceed with processing the request.

[0190] Can be similar to Figure 8 Steps 819-821 are used to execute steps 1019 to 1021.

[0191] The classification performed by the logical analysis, keyword detection, and context derivation components can be routed as input to the intelligent API generation component. The determinations made by the aforementioned components can be combined to generate appropriate service layer operations that can achieve the desired results of the abstract request. As shown in Table 8, before deriving the results, the intelligent API generation can perform a decomposition of the abstract request. This decomposition can include separating the predicates, subjects, objects, locations, and / or time information found in the abstract request.

[0192]

[0193]

[0194] Table 8 - Abstract request decomposition example

[0195] Using the decomposition of the abstract request and the input classification, the intelligent API generator may be able to generate corresponding SL operations, as shown in Table 9. For the identified subjects and / or objects, a resource discovery request may be made to check one or more resources associated with those subjects and / or objects at the SL or otherwise available to the SL. If the one or more resources do not exist, then the intelligent API generator may generate SL operations to create such resources. If a time modifier is present in the abstract request, then the expiration time of such resources may be set using the time modifier. Note that resources may be created for the subjects and primary objects to which the abstract request applies. It may be assumed that other secondary objects in the abstract request already exist and may have resources associated with them.

[0196]

[0197]

[0198] Table 9 - Smart API generation example

[0199] As specified by the contextual relationship matrix, location and time modifiers may be applied to an object. The values ​​of the respective modifiers may be provided by location and time services, respectively. Such services may be services provided by a service layer that may be called to provide values ​​indicating the corresponding terms. For example, "west" may provide directions to the approximate location of a factory, and "onlytoday" may define a duration that expires at the end of the day. The corresponding service(s) provide appropriate values ​​that may be used when performing predicate operations.

[0200] The predicate operation may be performed after the completion of a previous operation, such as those listed in Table 9 for the above example abstract request. The functionality of the predicate operation may depend on the results of the previous operation. For example, if the primary object exists at the SL, the operation may be an update operation (i.e., updating the primary object); if the primary object does not exist at the SL, the predicate operation may be a create operation (i.e., creating the primary object). Information about the sequence of operations may be sent to the operation sequencer to interact with the service layer. If there is a service at the SL that supports such functionality, the information may be provided to the service with the aid of the SL operation list.

[0201] After generating the API for the appropriate service layer operation, the intelligent API generator can send information to the operation sequencer to sequence or structure the operation. The operations can be sequenced by using a sequence table. An example sequence table using the above-mentioned abstract request is shown in Table 10, which shows the sequence of operations that the RAS can create to satisfy the SL operation of the abstract request. The request can be structured so that retrieval operations and resource discovery operations can be performed before executing a create or update request. The request at the end of the sequence can be a request specified by a predicate operation, such as those in Table 9 regarding the example abstract request. Requests that may require multiple interactions with the service layer may have an indication of "N" in the "Multiplicity" column of the operation sequence table, as shown in Table 10. The "Success" and "Failure" columns of the sequence table can be the status that the RAS uses to proceed from one request to another.

[0202]

[0203]

[0204] Table 10 - Example of SL operation sorting table

[0205] When the operation sequencer encounters "end" in the operation sequence table, the interaction with the service layer can be terminated and a status code can be returned to the requester. For example, an operation sequencer that receives a successful response for operation 8 can indicate that the abstract request was successfully executed. However, if the response fails, then the abstract request may not have been successfully executed. In addition, if a failure response is received for operations 1, 2, 4, 5, and / or 7, then the operation sequencer can quickly exit and the associated error can be reported to the requester to indicate where the failure occurred. For example, when in operation #4, a failure response is received, then the abstract request may not have been successfully executed. <analyst>When creating a resource, if the service layer returns a failure response, the operation sequencer can stop the operation and return an error status to the requester. The request abstraction service can also include the status of the previous request in the operation sequence. Note that if resources are created or updated and the operation sequencer has to abort the operation due to a failure response, the RAS can undo the changes made to these resources and / or delete the resources. Undoing changes can be achieved by supporting this feature within the service layer or via services that handle such operations.

[0206] Fig.11 An example sequence of operations 1100 that may be performed by the operation sequencer for the request sequence shown in Table 10 is shown. Note that Fig.11 The sequence of operations shown in assumes that all requests are executed successfully.

[0207] At step 1111, the requester 1103 may issue an abstract request "Give <analyst>"Give <analyst> access to all doors in the west wing for only today."

[0208] Can be similar to Figure 8 Steps 812-813 are used to execute steps 1112 to 1113.

[0209] At step 1114, Figure 8 Steps 814-819 of RAS 1101 are similarly executed without regard to Figure 8 Steps 817-818 when the RAS 1101 prompts the user to provide additional context. The operation sequencer operates in Fig.11 The sequence follows the sequence of Table 10, which can be <acp>Create resources together <analyst>resources. You can then use the newly created <acp>The acpID attribute associated with each lock discovered from step e4 is updated with the ID of the resource.

[0210] At step 1115, RAS 1101 may return an appropriate response to requester 1103 indicating that the abstract request was successfully executed with the help of service layer 1102. In addition, RAS may provide which SL 1102 operation was performed (i.e., created the abstract request). <analyst>and <acp>resources, and updates the status of the acpID of the locked resource).

[0211] After successfully executing an abstract request, a resource representation may be created so that the abstract request may be reused or executed again at a later time. The created resource may include a virtual "ras" resource that is added as a subresource that the requester may target in order to reuse the abstract request. Note that another name may be used instead of "ras" to represent the virtual resource. In order to reuse the saved abstract request, the requester may target the "ras" virtual resource and may provide a new abstract request indicating changes that may need to be made to the original abstract request. For example, the RAS may receive a request to modify a command context or object for an abstract request, and the RAS may modify the generated API set to include the modified command context or object instead of the original command context or object. The request abstract service may then process the new abstract request using the contents of the original abstract request and the replacement context obtained from the new abstract request.

[0212] Fig.12 An example sequence diagram for reusing an abstract request 1200 is illustrated. Fig.12 In the abstract request "Give <analyst>access to all doors in the west wing for only today". The abstract request has been saved as an absReq1 resource, and the service layer has automatically created a virtual resource "ras" as a child resource of absReq1. Additionally or alternatively, a virtual resource may not be necessary to reuse an abstract request, and the abstract request resource may be directly targeted by the requester. Requester 1203 wishes to reuse absReq1, but with a different user ID than was previously used. Furthermore, requester 1203 wishes to replace "analyst" with "visitor" and grant the new user access to the same area of ​​the smart factory. Requester 1203 may even select another area of ​​the factory and provide that information in a new abstract request. Fig.12 The details of the calling process are as follows.

[0213] At step 1211, the requester 1203 may attempt to reuse absReq1 and the target URI / absReq1 / ras. As described above, in an example embodiment, the requester may directly target the resource absReq1 instead of the virtual resource "ras". In the request, the requester may include a new abstract request "absReq1". <visitor>replace <analyst>”.

[0214] Can be similar to Figure 8 However, instead of sending a new abstract request to the RAS 1201, the original abstract request stored in absReq1 may be sent to the RAS together with the new context information provided in step 1.

[0215] At step 1214, RAS 1201 may process the request using the abstract request stored in absReq1 and may also process the request from the new abstract request "absReq2". <visitor>replace <analyst>" replaces the original context with the context obtained in " <analyst>" can be replaced with a new context" <visitor>". The operation sequencer can then use the context" <visitor>Execute steps e1-e7. Service layer operations may result in the creation of new resources <visitor>and <acp2>, and the lock resource can be updated using "acpID2".

[0216] At step 1215, RAS 1201 may return an appropriate response to requester 1203 indicating that the abstract request was successfully executed with the help of service layer 1202. In addition, RAS may provide information on which SL operation was executed (i.e., the SL was created). <visitor>and <acp2>Resources, and the status of the acpID2) of the lock resource is updated.

[0217] Example oneM2M embodiments of the introduced request abstraction service functionality are described herein. The example embodiments describe one or more possible implementations of the RAS.

[0218] Example oneM2M embodiments may include <absreq>The definition of resources, SL initiator can <absreq>The example oneM2M embodiment may also include a process for processing such an abstract request.

[0219] Fig.13 is a diagram of an example oneM2M service layer supporting the RAS CSF 1300. Fig.13 In the example of , the CSFs may include the following: application and service layer management CSF 1302; discovery CSF 1303; registration CSF 1304; communication management / delivery processing CSF 1305; group management CSF 1306; security CSF 1307; data management and repository CSF 1308; location CSF 1309; service charging and billing CSF 1310; device management CSF 1311; network service exposure, service execution and triggering CSF 1312; subscription and notification CSF 1313; group management CSF 1319; and semantic CSF 1320. Fig.13 The example also shows the CSE 1301 interfacing with other entities via Mca reference point 1314, Mcc (and Mcc') reference point 1315, and Mcn reference point 1316, including but not limited to: AE 1317; other CSEs; and NSE 1318 (ie, underlying network).

[0220] like Fig.13 As shown, the RAS CSF 1321 can be implemented as a new CSF that implements the RAS functionality as described herein. The RAS functionality can also be implemented as a capability of the existing oneM2M CSF. RAS can be used within the CSE to interact with other CSFs and perform operations to complete abstract requests.

[0221] In the oneM2M embodiment, <absreq>Resources can provide a mechanism for the initiator to specify an abstract request to the CSE. An abstract request can include at least three parts: cmdPredicate, cmdObjects, and cmdContexts. The cmdPredicate can include a description of the high-level operation that the initiator wants to perform. The cmdObject can include one or more identifiers of the CSE resources that the cmdPredicate may affect. The cmdContext can include context information applicable to the abstract request. The context information can include one or more of location, time, or quantity applicable to the desired operation. Table 11 shows <absreq>An example of resource-specific properties for a resource.

[0222]

[0223] Table 11: Example oneM2M <absreq>Resource attributes

[0224] Table 12 shows <absreq>An example creation process for a resource. Such a process may include the creation process defined by oneM2M, with the addition of <absreq>Processing of resource-specific attributes of a resource. Processing at the recipient CSE may include the mechanisms described herein for handling abstract requests. The procedures for update, retrieval and deletion may respectively include corresponding procedures of methods such as those defined by oneM2M.

[0225]

[0226]

[0227] Table 12: Create Operation <absreq>process

[0228] To enable reuse <absreq>Resources, you can create virtual resources <ras>As <absreq>The initiator can use the sub-resources stored in <absreq>The new abstract request may include new context information, which may replace <absreq>existing context information in absReq2. For example, the initiator can target the following URI, / cse01 / absReq2 / ras, to reuse the abstract request stored in absReq2. In the new abstract request, the initiator can specify "Replace user1 (user1) with user2 (user2)". If the original abstract request is "Give user1 access to all mgmtObjresources", then RAS can process the new abstract request as "Give user2 access to all mgmtObj resources" after performing the replacement. Additionally or alternatively, a new abstract request can be provided in the request parameters, and the request targets the resource to be reused. <absreq>Resource, for example, / cse01 / absReq2.

[0229] Fig.14 An example user interface 1400 for inputting an abstract request that the service layer may provide to a user is shown. The user interface may be implemented to help the user configure and input an abstract request. The user interface may be titled "Enter your request:" and may display a target URI where the abstract request will be created. Fig.14 , the name of the hosting CSE is "cse01" 1401. The format of the abstract request can be displayed on the main part of the user interface under the headings "Command Predicate" 1402, "(One or more) Command Objects" 1403, and / or "(One or more) Command Contexts" 1404. Below each heading may be a corresponding dialog box with a down arrow to allow the user to select an identifiable entry for each heading. When the down arrow is pressed, another window can open to display a menu of selectable entries. The user can then scroll through the entries and select the entry of interest. The user can also enter a new entry. Below the "(One or more) Command Objects" and "(One or more) Command Contexts" headings may be additional dialog boxes that allow the user to add more entries to the selection menu. The user can select the + symbol to enter another entry for the associated heading. On the left side of these dialog boxes may be options for specifying one or more modifiers to group abstract expression attributes together into an abstract request. At the bottom are two buttons that allow the user to either send the abstract request or cancel submitting the abstract request. After the user presses the Send button 1405, the request abstract service can begin processing and execute Figure 8 The RAS process shown in . The user can also cancel the process via cancel button 1406.

[0230] Also described herein are methods and apparatus for a service layer framework for integrating common and functional user interfaces as services managed by the SL on behalf of the requesting entity. The following is a list of definitions of terms as used herein for this aspect of the disclosure:

[0231] Host: An entity that hosts various resources.

[0232] M2M services: M2M-oriented capabilities provided to applications usually through application programming interfaces (APIs).

[0233] M2M Service Node: A network node that hosts a service layer that supports one or more M2M services for M2M communications.

[0234] Initiator: An entity that creates a request and transmits it to another entity (ie, to a recipient).

[0235] Receiver: An entity that receives a request from another entity (ie, from the initiator).

[0236] Registrar: A service node where an application or another service node is registered.

[0237] Registrant: An entity that registers with a service node (ie, registrar) to obtain its services.

[0238] RESTful: Systems, operations, etc. designed based on the REST (Representational State Transfer) principles. Create, Read, Update, and Delete (CRUD) operations are examples of RESTful operations.

[0239] User Interface: Any general purpose interface through which a person or machine interacts with a computer system, electronic device, or machine. The interface can be mechanical / graphical / sensory, etc. in nature. If the UI is graphical / visual in nature, then it is referred to herein as a Graphical User Interface (GUI). If an interface is specified between a person and a machine, then it is referred to as a Human-Machine Interface (HMI).

[0240] Fig.15 is another diagram of an example oneM2M service layer that supports an initial set of Common Service Functions (CSFs) 1500. The purpose and goal of oneM2M is to develop technical specifications that address the need for a common M2M service layer that can be easily embedded in a variety of hardware and software platforms and that can be relied upon to connect a wide variety of devices in the field with M2M application servers worldwide.

[0241] like Fig.15 As shown in the example of , the oneM2M service layer can support a set of CSFs (i.e., service capabilities). The instantiation of one or more specific types of CSF sets can be referred to as a public service entity (CSE) 1501 (i.e., service layer), which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). The public functions exposed by CSE1501 may include, but are not limited to, addressing and identification 1510, data management and repository 1511, location 1512, security 1513, communication management / delivery processing 1514, registration 1515, group management 1516, device management 1517, subscription notification 1518, service charging and billing 1519, discovery 1520, and network service exposure / service execution and triggering 1521.

[0242] These common functions may be exposed via the Mca reference point 1504, the Mcc reference point 1505, and the Mcn reference point 1506. The Mca reference point 1504 may specify the communication flow between the application entity (AE) 1502 and the CSE 1501, while the Mcc reference point 1505 may specify the communication flow between two CSEs 1501 in the same M2M service provider domain. Communication across the Mca reference point 1504 and the Mcc reference point 1505 may be performed via paired request / response messages, where each request may perform a specific RESTful operation (e.g., CRUD) on a resource hosted on the target CSE 1501. The Mcc reference point 1505 may be used between CSEs 1501 located in the infrastructure domains of different M2M SPs. The Mcn reference point 1506 may be used between the CSE 1501 and the underlying network service entity (NSE) 1503 for services other than transport and connectivity. A specific CSE 1501 implementation may not support Fig.15 Each of the functions shown in the examples, but a complete implementation would include Fig.15 All features shown in .

[0243] According to the oneM2M RESTful architecture, CSF can be represented as a collection of resources. A resource can be a uniquely addressable entity in the architecture that has a representation that can be manipulated via RESTful methods such as CRUD. These resources can be made addressable using a Uniform Resource Identifier (URI). Resources can contain child resources and attributes. A child resource can be a resource that has a containment relationship with a parent resource. A parent resource representation can contain references to its child resources. The lifecycle of a child resource may be limited by the lifecycle of the parent resource. Each resource can support a collection of "attributes" that store information about the resource.

[0244] Over the past few decades, various types of user interfaces have evolved significantly, from ordinary displays and keyboards to mice, touch screens, tactile devices, etc. More and more sensors have been added to consumer devices to determine what the user is trying to do, such as analyzing gestures, detecting eye movements, interpreting direction, speed, etc. More and more methods of providing feedback have also been developed in a myriad of audio, tactile or visual forms. While complex machines (such as general-purpose computers) have the processing power and demand for complex interactions, in the world of the Internet of Things (IoT), these demands and capabilities may be reduced. Many devices can perform well using multiple basic interactions; therefore, as long as one knows which function needs to be performed, a person can use only a few very simple interactions with the same device for various purposes. Similarly, the same simple interactions can be used for a variety of devices, for example, a slider is the basic input required for the volume function of a stereo, the temperature setting of a washing machine, the zoom of a camera, etc.

[0245] The output provided by a machine or device also has a basic function associated with it. For example, displaying a number is the basic function of a temperature monitor in a nuclear power plant, which is the same basic function as a monitor that indicates the pressure in a water tank or the humidity in a room. For example, a refrigerator that indicates that it is open can provide an audible alarm that provides the same function (i.e., an alarm) as a flashing LED that indicates that the battery is low. In some cases, the expression of these alarms may be more suitable for both vision and hearing.

[0246] One of the reasons for the evolution of complex user interfaces, especially graphical user interfaces, is to clarify to human users which input to provide or which output to give, and to make the interaction easy, accessible, and enjoyable.

[0247] Fig.16 is a diagram of an example home control platform 1600 that integrates various devices and appliances. Many consumer devices host multiple independent applications, more than one of which obtains and interprets input from the same sensor. The platform 1600 can have presence sensors for lighting, temperature and humidity control in a room, and for security in the immediate vicinity of the room. The platform 1600 can also allow an elderly or disabled person (person U1) 1601 in a wheelchair to have the ability to use a single wearable button device to turn on / off various devices around the home. Fig.16 In the example of FIG, a wearable button can be worn by person U1 1601, and in some rooms (e.g., kitchen, bathroom, porch), it can be used to turn on specific lights 1603. When the button is worn by person U1 1601 in a home office, it can be used to answer business calls via the platform speaker / microphone 1604, and when the button is worn by another person U2 1602 in the kitchen or living room, it is used to start the platform stereo 1605.

[0248] In another example, a pointing device with a button can be used to point to and control a device integrated with the platform. Different applications may have the task of independently interpreting the same input from the same wearable device. The platform may already have information (e.g., presence sensor input for security, lighting, and environmental control) to determine (based on predetermined rules) what the context of the input it receives from the button is (i.e., who is wearing it and what room or area they are in).

[0249] A service layer (SL) platform that is capable of processing information from several sources is generally in a very good position to use information available from new sensors and technologies (e.g., for analyzing gestures, directions, etc.) and use this available information as context for user interactions (e.g., input received from a user device). Assuming a platform with such capabilities, the methods and apparatus described herein can use the information available at the service layer to interpret human interactions in a reliable manner that simplifies the user interface of an application and is consistent between applications. The methods and apparatus described herein can alleviate some of the complexities associated with creating a user interface for each application, so that multiple applications can rely on a common library of interactions and a common set of interpretations. The methods and apparatus described herein can implement scenarios in which a limited number of defined interactions can be used for multiple needs / applications.

[0250] For example, once the correspondence between a given interaction and device operation is understood, the methods and apparatus described herein can enable user interactions to be provided differently based on the context of the situation. For example, a workstation with multiple users may have different preferences: the first user may prefer a rotary knob for a dimmer, while the second user may prefer a slider. To provide this simple feature, the dimmer may need to download multiple application instances, application settings may need to be switched back and forth between users, or a user-aware application may be required to implement an otherwise very simple tool. Alternatively, such a simple device may rely on the platform to instantiate its user interface and provide optimizations such as user-aware customization along the way.

[0251] The methods and apparatus described herein may enable value-added services based on SL context changes to enhance the user interaction experience with little to no user input while retaining UI functional aspects. For example, if a hearing-impaired person is visiting, a home control platform may be set up for all applications at once so that visual alerts are given instead of auditory alerts. A more sophisticated implementation may change the alert from audio to visual when noise levels above a certain level are detected. While some applications may offer such customization, the methods and apparatus described herein may avoid configuring each device individually.

[0252] Methods and apparatus for a service layer framework are described herein, which are used to integrate common and functional user interfaces into services managed by SL on behalf of applications. These user interfaces, referred to herein as interactors, process user interactions and generate common and functional events, which are converted into input / output of applications. The methods and apparatus described herein define an interactive context management (ICM) service that evaluates contexts and maintains corresponding context states. The ICM service uses context states to evaluate events based on user interactions and provides mappings between them and application-specific events. The ICM can be configured with templates and policies related to interactors, such as interactor libraries. Applications and other service layers can query and discover interactor-related capabilities provided by SL by discovering interactor libraries or individual templates. According to the methods and apparatus described herein, applications can provide information about their own interactor-related capabilities. In addition, the ICM can be configured with rules and parameters that enable the ICM to monitor the SL and maintain and switch context states accordingly. The ICM can instantiate interactors on behalf of applications so that there is a common understanding of user interactions and their functions and the corresponding relationship with application operations in the system. The process of associating applications with interactors may allow multiple interactors to be used in the system depending on the context.

[0253] This document describes a process in which an interactor can register with a service layer ICM so that the ICM can use its services and associate with an application. This process is particularly useful when the interactor functionality is deployed on a device that is different from the device / platform with the ICM functionality. In addition, user interactions received or generated by the interactor can be converted into events managed by the ICM, which can provide functional input or output to the application. The conversion process between SL events and end-user interactions via the ICM and the interactor can allow context-based processing of user interactions.

[0254] As used herein, user interaction is a physical interaction that includes real-time communications exchanged between software and a user via a dedicated interface referred to herein as a user interface (UI). Examples of user interactions include received inputs, including but not limited to the following: input via mouse clicks, voice input, output beeps, etc. As used herein, references to UI primarily address human interactions with devices or machines; however, the methods and apparatus described herein may be applied to other types of interactions. The contextual information at the UI at the time of user interaction is referred to herein as UIx-context. UIx-context may include, for example, the coordinates of a mouse pointer for a mouse click, the loudness of a voice input, etc.

[0255] As referred to herein, an interaction context (Ix-context) may include any information based on which user interactions and SL events may be evaluated. In the SL architecture, the Ix-context may include any parameter or data set available at the SL (which may be provided to the SL by any application or SL entity), and may include the UIx-context or certain aspects / parameters also contained in the UIx-context. The Ix-context may also be derived by the SL, for example, based on previous SL or interaction context states, UIx-context, history, semantic information, etc. For example, an interaction context state may be created based on any one or any combination of the following SL parameters: time of day, location of the user, and noise level provided by sensors.

[0256] As referred to herein, an Interactor (Ix) may include generic UI software that processes physical inputs and generates generic and functional Interactor events (Ix-Events). Ix-Events may be evaluated in an Interaction Context to be converted into SL actions or events (Ax-Events) that are produced or consumed by specific applications. The receiving application is in turn programmed to provide specific functionality related to the Ix-Events. Typically, the Interactor may communicate with SL entities (via Ix-Events) while the UI communicates with applications in a SL architecture.

[0257] In the SL architecture, the Interactor can be implemented as a SL entity (e.g., integrated with the ICM or standalone) that handles physical user interactions and interworks these interactions with one or more devices (or applications). This interworking is provided via device / application level interfaces represented as resources (in this case hosted by the SL).

[0258] Interactors can be used for any interaction, including but not limited to on / off, text input / output, gestures (2D or 3D), audio alerts, etc. Complex interactors can be defined to map multiple Ax-events to a single Ix-event. For example, a single gesture can be used to provide commands to two originally uncoordinated devices, such as muting a stereo and turning off a light. Similarly, composite interactors can be used to receive multiple types of input, such as verbal commands combined with touch buttons to determine the final application-specific Ax-event. Although the examples and embodiments described herein refer to example functionality provided via simple / atomic interactors, the same concepts described herein can apply to simple and complex interactors. Similarly, the same concepts can be applied to interactors designed to provide output rather than input interactions.

[0259] As referred to herein, an interactor event (Ix-event) may include an atomic, generic, and functionally defined event that may be generated or consumed by software with UI functionality (e.g., an interactor) based on physical user interactions. Ix-events may be generic in the sense that Ix-events are not specific to a single application. Ix-events may be functionally defined in the sense that, unlike user interactions defined by physical characteristics (e.g., a finger swipe on a touchpad), Ix-events may be defined by basic functional aspects (e.g., on / off).

[0260] As referred to herein, application-specific interactor events (Ax-events) may include SL events generated or consumed by an application (ie, app), which may be converted into user interactions by the SL and software having UI functionality (eg, interactor).

[0261] The following is an example of the functional representation of an Ix-event and the difference between a user interaction and the corresponding Ix-event and Ax-event:

[0262] Mouse click on "on / off" button (physical user interaction) vs. on / off (Ix-event generated by physical user interaction) vs. light "on / off" (Ax-event for light switch application); and

[0263] Sound (physical user interaction) vs. alarm (Ix-event based on which the sound is generated) vs. refrigerator alarm (Ax-event generated by the refrigerator control application).

[0264] As referred to herein, an Interaction Context Management (ICM) service may be an entity that evaluates the Ix-Context in the SL and uses Ix-Events and Ax-Events to implement conversion of user interactions into application functions and state changes using the Ix-Context.

[0265] Fig.17 is a diagram of an example system 1700 depicting signaling between interactors, user interactions, Ix-events, Ax-events, and SL ICMs, according to one embodiment. Fig.17 In the example of , the interactor instance 1703 can receive information such as received input indicating user interaction context information (UIx-context) 1710. The received input can be based on physical user interaction 1711. The interactor instance 1703 can process the UIx-context 1710 information and can generate general and functional interactor events (Ix-events). The interactor instance 1703 can communicate with the SL ICM 1702 via Ix-events 1712, and the SLICM 1702 can store the interaction context (Ix-context) 1713 in a database. As described above, the Ix-context can include multiple parameters or data available at the SL (which can be provided to the SL by any application or SL entity), and can include the UIx-context 1710 or certain aspects / parameters that can be included in the UIx-context 1710. As described above, the Ix-event 1712 communicated with the SL ICM 1702 can be evaluated within the Ix-context to be converted into a SL action or event (Ax-event) for application production / consumption. The SL ICM 1702 may communicate with the application 1701 via Ax-events 1714 .

[0266] FIG18A is a diagram of another example system 1800 depicting signaling between interactors, user interactions, Ix-events, Ax-events, and SL ICMs. In the example of FIG18 , an interactor 1801 may receive information such as received physical user interactions 1810. The interactor 1801 may communicate with an ICM 1804 at a SL 1805 via an Ix-event 1811. The ICM 1804 may communicate with an application 1802 via an Ax-event 1812 and with an application 1803 via an Ax-event 1813. The SL 1805 may also communicate with an application 1802 via other SL messaging 1814 and with an application 1803 via other SL messaging 1815. The SL 1805 may also communicate with other service layers 1806 via SL messaging.

[0267] FIG. 18B is a diagram of a system that implements a conventional example using a UI of an embedded application. Figure 4 18A) enables a single interactor (i.e., UI) to be used for more than one application. However, as shown in the example of FIG. 18B, the conventional paradigm uses a UI embedded in an application 1851 to handle physical user interactions 1850, which can communicate with SL 1853 via SL messaging 1852. SL 1853 can also communicate with other service layers 1855 via SL messaging 1854.

[0268] The following terms may be used herein to distinguish between application functionality using an interactor-based paradigm in the system of FIG. 18A and application functionality using an application-embedded UI using a conventional paradigm in the system of FIG. 18B .

[0269] UI-Application: has embedded user interaction functionality and application logic with functionality and state changes directly linked to user interaction; and

[0270] Application: Application logic with functions and state changes linked to application specific Interactor events (Ax-Events), which can be converted into user interactions by SL and Interactor.

[0271] Figures 19A-19C are examples 1900 of different UI styles for different interactors. In this example, an application can be provided for a simple light switch, and a UI service from a SL can be provided for the application via different interactors. Referring to Figure 19A, user interaction can initially be provided by sliding a virtual on / off button 1901 that changes the state of the light. User interaction can also be provided in different ways, such as in the example of Figure 19B, where user interaction is provided via a click button 1902 on the screen. User interaction can also be provided as in the example of Figure 19C, where user interaction is provided via a right mouse button click 1903. In the example 1900 of Figures 19A-19C, either multiple UI-applications need to be used, or the UI-application settings need to be switched back and forth. Otherwise, the UI-application needs to be implemented as a context-aware application (e.g., by the user using login or fingerprint analysis to switch contexts) to implement an originally very basic device (a simple light switch in this example). Moreover, even context-aware UI-applications are limited to a predefined set of context definitions compared to the information-rich service layer.

[0272] Fig. 20 is a diagram of an example system 2000 in which the SL provides applications with the ability to use two different interactors depending on the context, which can be used in conjunction with any of the embodiments described herein, according to one embodiment. Fig. 20 The example system uses the above described (and Figure 4 18A) so that multiple interactors can perform the same operation at the application level (Ax-events) using different physical user interactions. Fig. 20 , the interactor 2001 may receive information such as received physical user interactions 2010. The interactor 2001 may communicate with the ICM 2004 at the SL 2005 via Ix-events 2012 based on the context 2017, which may trigger the ICM 2004 to communicate with the application 2003 via Ax-events 2014. The interactor 2002 may receive information such as received physical user interactions 2011. The interactor 2002 may communicate with the ICM 2004 at the SL 2005 via Ix-events 2013 based on the context 2016, which may also trigger the ICM 2004 to communicate with the application 2003 via Ax-events 2014. The SL 2005 may also communicate with the application 2003 via other SL messaging 2015, and the SL 2005 may also communicate with other service layers 2006 via SL messaging 2018.

[0273] This article is aimed at the above-described (and Fig.17 18A and 20) can implement the use of interactor templates (Ix-templates). Interactor templates (also referred to herein as templates or Ix-templates) can include basic and general descriptions of interactor functionality that can be used to instantiate one or more interactors.

[0274] A group of interactors generated based on the same template is said to have the same functional type, which can be indicated by the element ixTemplateFunctionalType. The functional type is related to the supported ix-event types specified in the ixTemplateEvents element.

[0275] Templates can also specify (via the initializeDefaults element) default values ​​to be applied when resources associated with the Interactor are first created. Templates can also specify (via the ixInstantiationSettingsDefaults element) parameters to be used when the Interactor UI is first run (i.e., at instantiation time). Instantiation settings (e.g., colors, position of graphics) can be used, for example, to create various user experiences, and can also be provided at the time of the instantiation request.

[0276] Table 13 below includes descriptions of example elements of the template.

[0277]

[0278]

[0279]

[0280] Table 13 Interactor template

[0281] The methods and apparatus described herein may include the ICM as described above, and the ICM may be an independent service or implemented as a sub-service of the IoT service layer. The ICM may be hosted on various types of network nodes, such as IoT servers, IoT gateways, and IoT devices, and may be instantiated with different levels of functionality depending on the node.

[0282] The ICM can evaluate the interaction context by monitoring a set of parameters based on which it defines the context, which can consist of any information provided to the SL by the application or derived by the SL. The examples and embodiments described herein assume that context changes occur between discrete multi-dimensional states (cxStates) and that context changes are performed using comparisons of context parameters to thresholds or previous states of user interaction. Under this assumption, the ICM can maintain a list of cxStates with parameters as described in Table 14 below. However, these concepts may also apply when the interaction context is evaluated in other ways (e.g., using rules, algorithms, conditions, etc.) and changed over time. The following describes how to pre-supply the ICM with rules for evaluating the interaction context and determining the cxState for switching.

[0283]

[0284]

[0285] Table 14 Context state list (cxList)

[0286] The ICM can manage the correspondence between user interactions and application operations by creating associations between Ix-events and Ax-events for each cxState using resources associated with the interactor, as described below. To create and manage these resources, the ICM can be pre-provisioned with Ix-templates and can receive interactor information from the application.

[0287] In the above about Fig.16 In the described home control platform, the platform ICM can be supplied with an "on / off" interactor template that can be used with any device that can provide such an input (such as a button). Devices such as controllable room lights or stereos can register with the platform and provide information about the interactors they may use, including an "on / off" button. The ICM can also provide a GUI that allows users to create rules for context switching, for example, based on user identity and location. For each context, the ICM can create a correspondence between the on / off input and the control action. The following describes how the ICM is pre-supplied with Ix-templates, how applications provide information about possible interactor associations, how the ICM uses these dedicated resources to maintain the correspondence, and how the ICM further maintains the association between the interactor and the application based on the changing interaction context.

[0288] Given its role in maintaining information about Ix-templates, interactors, and associated applications, ICM can be used to discover or publish information about available templates and interactors, as well as information about Ix-events, which in turn provides valuable information about all user interactions.

[0289] The ICM may use resources associated with the Interactor to provide its functionality. For example, Table 3 below includes information associated with the Interactor Instance (ixInstance) that the ICM may use to provide its functionality using the above concepts and information elements. For a RESTful environment, Table 15 provides the structure of the ixInstance SL resource.

[0290]

[0291]

[0292]

[0293] Table 15 ixInstance

[0294] As used herein, the words Interactor and Interactor Instance may be used interchangeably. The addition of Instance may be used to emphasize that the Interactor is a specific copy of the software running at a specific time. Thus, depending on the situation, an Interactor may refer to a general software that may result in multiple instantiations or an Interactor Instance.

[0295] Fig.21 is a diagram of an example interactor state machine 2100 according to another embodiment that can be used in conjunction with any of the embodiments described herein. The process of creating and initially populating resources that support interactor functionality is referred to herein as interactor registration. Fig.21 , the interactor may be programmed to start 2101 in an unregistered state 2102, and after an interactor registration process 2103, it may transition to a registered (idle) state 2104. The interactor registration process 2103 may cause the following resources to be created and initialized:

[0296] ixInstance resource, which can be used for overall interactor instance management;

[0297] One or more resources based on the ixEventResourceDescription of the Interactor template to enable communication between the SL (ICM) and the Interactor; and

[0298] A resource based on the Interactor template's ixInstantiationResourceDescription that can be used by the ICM to trigger an Interactor instantiation.

[0299] The processing of the UI software running the interactor is referred to as interactor instantiation in this article. Instantiation trigger 2105 can convert the interactor to instantiation (activity) state 2106, in which it can process the physical user interaction to / from Ix-event. For example, the interactor instantiation for the on / off button on the touch screen can include the process of creating button graphics and processing the tap as a physical user interaction. For example, the interactor can only process one user interaction, and then after the instantiation timeout 2108, the interactor can return to registered (idle) state 2104, in which they need to be re-triggered in order to process the physical user interaction. Interaction timeout 2107 (or the maximum number of physical user interactions, etc.) can be specified so that after processing each physical user interaction, the interactor repeatedly returns to the active state. When reaching the interaction timeout 2107 (or the maximum number of repetitions performed), the interactor can be converted to idle mode. ixInstantiationSettings can capture parameters such as timer values, number of repetitions, etc. in the SL, as well as other settings that affect the Interactor state machine and the way physical user interactions are handled in the Instantiated (Active) state 2106. The Interactor deregistration process 2109 can include the processing of deleting resources that support the Interactor's functionality. After deregistration, an idle Interactor can return to the Unregistered state 2102, and it can reach the End state 2110 after a timeout.

[0300] Some Interactors may rely on the ICM to create and initialize Interactor support resources, and thus perform Interactor registration on its behalf. In other examples, Interactors may be programmed to actively discover ICM functionality, and then register themselves. For example, an Interactor may discover the ICM using a mechanism similar to that used by applications to discover and register with the SL.

[0301] Fig. 22 is a diagram of an example process 2200 for use in ICM, according to one embodiment, which may be used in conjunction with any of the embodiments described herein. Fig. 22 Each step of process 2200 in the embodiment of the present invention may be performed in an order different from that shown, in parallel with each other, or simultaneously with each other. Fig. 22 The example provides an overview of the actions performed by the ICM that result in an interactor being deployed, accompanying user interactions (e.g., predetermined inputs based on physical interactions) being associated with a given application, and the ICM continuing to monitor context and enable changes to user interaction processing based on those context changes.

[0302] This article describes Fig. 22 Functional stages of an example process of. Stage A (Setup) 2204 may include stages during which the ICM is configured with a plurality of templates (i.e., a library of interactors) to enable identification of interactors and / or to enable instantiation of interactors. During stage A (Setup) 2204, the ICM may also be configured to be able to switch contexts based on available information. Also during stage A (Setup) 2204, registered applications may provide information about the type of interactors they use by identifying corresponding templates. At the end of stage A (Setup) 2204, available at the ICM are: one or more template resources (or alLibrary); a list of Cx-states on which the ICM switches states; and application registration information enhanced with information about which application operations (Ax-events) may be triggered via interactors and corresponding templates.

[0303] Phase B (initialization / registration) 2205 may include the following phases, during which the deployment of the interactor is prepared and the resources that support its functionality are created and initialized, i.e., the interactor registration as described above may be performed. The SL ICM may register the interactor on behalf of the application. Alternatively, the interactor may register itself at the SL ICM. Initialization of necessary parameters with default / initial values ​​may be based on interactor templates, local policies, or signaling (e.g., CRUD operations). At the end of Phase B (initialization / registration) 2205, the ICM may have newly created resources and information corresponding to the Ix element set in ixInstance.

[0304] Phase C (association and instantiation) 2206 may include the following phases during which the resources representing and supporting the interactor functionality provide a means to create a list of associations for each interactor instance. Each association may map a Cx-state to an Ax-event and an Ix-event. Interactor instantiation is performed so that at the end of this phase the interactor can begin processing user interactions and converting Ix-events to and from Ax-events.

[0305] Phase D (Context Management) 2207 may include the following phases: During this phase, the ICM continuously evaluates the SL context based on the current rules and changes the context. The ICM repeats phase D 2207 indefinitely and may result in repeating phase C 2206 and changing the association between the Interactor instance and the application. If the rules are dynamically updated, the ICM may update its definition of Cx-states and the evaluation follows the current rules. The ICM may use the association to continuously communicate with the application and the Interactor by converting user interactions into Ix-events (and vice versa).

[0306] Phase E (Deregistration) 2208 may include a phase when the interactor deregistration process is performed, which may delete resources supporting interactor functions at SLICM. Phase E (Deregistration) 2208 may end with the interactor in a deregistered state, however, ICM services may continue.

[0307] refer to Fig. 22 , during phase A (setup) 2204, templates may be supplied to the SL ICM 2202 (step 2210). The SLICM may store interactor templates that may be created or installed in a variety of ways. Each template provides a general description of interactor functionality, based on which multiple interactor instances may be created. The template may provide information about which resources need to be created for the interactor instance and initialization default values. At the end of step 2210, one or more ixTemplates may be available at the SL ICM 2202. The SL ICM 2202 may also maintain a template library that may be discovered (e.g., by an application in order to select or indicate a specific template for instantiation of an interactor). During phase A (setup) 2204, the SL ICM 2202 may receive settings that describe an interactor template, which may be accomplished using a variety of methods:

[0308] A collection of templates can be pre-provisioned prior to deployment. At that time, the parameters detailed in Table 1 can be configured for each template available at the SL.

[0309] Templates are provided via the device management (DM) process. For example, the entire template database can be provided via download. These updates can also occur at other stages besides stage A (setup) 2204.

[0310] The application may provide the template, for example, at registration time. For example, an application (i.e., app) that interfaces with a sensor or actuator may be installed on different devices hosting the ICM. The corresponding template creation or installation may be part of the application installation. This template provisioning method may require the addition of a registration message to be able to carry the template parameters as described in Table 1. Alternatively or additionally, other dedicated messages may be defined to provide or register templates to the ICM.

[0311] SL ICM 2202 may be provided with context change rules (cxRules) (step 2211), which may be used to determine a set of context states. These cxRules may be provided in a variety of ways. Once a set of context states (Cx-State) is determined, SL ICM 2202 may use them to change the way in which user interactions (via interactors) are associated with applications. At the end of step 2211, a cxList may be created and populated at SL ICM 2202, and may be updated by repeating step 2211 throughout the life cycle of SL ICM 2202. This information also corresponds to a set of Cx elements in ixInstance. In order for SL ICM 2202 to evaluate the interaction context and determine when a context change occurs, it may be provided with multiple context switching rules. Assuming the use of discrete multidimensional states as described above, the ICM may maintain a list of Cx-states derived from these rules using parameters as described in Table 2.

[0312] Methods for providing rules to the SL ICM 2202 and deriving a Cx-state set include but are not limited to the following methods:

[0313] The SL ICM 2202 may be pre-provisioned with cxRules or cxStateDescr / cxStateID prior to deployment to populate the cxList as described in Table 2;

[0314] DM Updates: cxRules or cxStateDescr / cxStateIDs used to populate cxList may be provided via the DM process. For example, the entire cxList may be provided via download. These updates may also occur at other stages besides Stage A (Setup) 2204; and

[0315] Direct User Input. The context provisioning method may use a dedicated user interface that may be disclosed, enabling the user to provide parameters as described in Table 2.

[0316] The following examples describe a direct user input method, but once the rules are logically and programmatically developed, they can be provided via pre-provisioning, DM updates, etc.

[0317] For the above reference Fig.16 The SL ICM 2202 can reside on a home platform for the use case of an elderly or disabled person in a wheelchair using a single wearable button device to turn on / off various devices around the room. In this example, the platform can be used to interact with lights and devices around the home (including universal wearable buttons). In this example, the platform also has some positioning capabilities for other functions (e.g., temperature control). For example, the platform's positioning capabilities can be based on presence sensors in the room, or can be based on using the user's smart watch to track his / her location within the room. The platform can expose a GUI, for example on a tablet or other device configured for wireless or wired communication, based on the following steps:

[0318] The GUI can request which device (e.g., a wearable button) to use as the "contextual user interaction device" (i.e., on which to instantiate the interactor). The GUI can provide a list of available devices that can be used in this manner, along with information about their capabilities. The user can select the wearable button. If the device capabilities are more complex, for example, including a trackpad and buttons, the GUI can request which function (button) of the device to use in a contextual manner.

[0319] The GUI may request which devices to control, and may again present a list of suitable devices. For example, a selection of a light may be received from the user.

[0320] The SL ICM 2202 may be able to receive information indicating the position / location of a user in a room. Methods for determining context changes are described herein. For example, there may be two context switching rules: "by room" or "by proximity". The first rule is one in which switching context depends on the room in which the presence sensor(s) indicate the user is located. The second rule is one in which the context is switched when the user approaches a device such as a different controllable light (which may or may not be in the same room).

[0321] At the end of this process, the SL ICM 2202 may be supplied with cxRules "per room". The SL ICM 2202 may then use its local information to create multiple Cx-States, each with a cxStateDescr of the form (user, userValue) && (userLocation, locValue), etc., and each with its own cxStateID, which may be, for example, as shown below:

[0322] cxList[0] / cxStateID=A

[0323] cxList[0] / cxStateDescr=(user, U1)&&(user location, kitchen or bathroom or bedroom or living room)

[0324] cxList[1] / cxStateID=B

[0325] cxList[1] / cxStateDescr = (User, U1) && (UserLocation, HomeOffice)

[0326] cxList[2] / cxStateID=C

[0327] cxList[2] / cxStateDescr = (user, U2) && (user location, kitchen or living room)

[0328] In the example of a pointing device with buttons, the SL ICM 2202 can implement context changes based on rules rather than discrete multi-dimensional states (cxState). However, the SL ICM 2202 can create Cx-States (each with a separate cxStateID) based on directional sensor inputs that match the controllable device. As the interactive Ix-context changes with the direction of the pointer, the interactive Ix-context can be continuously evaluated, and the Cx-state can be changed to the cxStateID of the device whose position matches the trajectory.

[0329] The context rule provisioning of step 2211 may be performed or repeated throughout other stages of the process 2200, effectively updating the definition(s) of the context state(s) upon which the SL ICM 2202 provides its services.

[0330] An application (such as application 2201) can register with SL ICM 2202 (step 2212), and SL ICM 2202 can provide information about the interactors to be used. When application 2201 registers, it can inform SL ICM 2202 which operations (Ax-events) can be triggered via the interactors, and which templates can be used for each of the corresponding interactors. All information provided by application 2201 at registration can be provided or updated alternatively via CRUD operations or new messages (e.g., interactor-use-indications) after registration. After step 2212, in addition to the application registration information, SL ICM 2202 also has information corresponding to the set of Ax elements in ixInstance.

[0331] The information provided when the application is registered can be used by the SL ICM 2202 to understand the ICM services that the application 2201 may request from the SL during its life cycle. This information (e.g., the information listed in Table 4) can enhance the existing application registration information, so it can be stored with the application registration. For example, this information can include the following information for each application:

[0332] A list of actions (Ax - Events) that can be triggered via the Interactor.

[0333] A list of templates that can be used for each corresponding interactor. This can be provided by referencing templates that exist at the SL ICM 2202, or by providing new templates. If new templates are provided, the SL ICM 2202 can store them similar to the templates provided in step 2210 (e.g., in a template library) and referenced by the enhanced application registration information.

[0334] Description of the Ax-Event for discovery purposes. For example, this information can be used to discover all interactors for voice control on a home platform, but some may be gesture-based, some may use on / off click buttons, etc.

[0335] Settings to use when instantiating the corresponding interactor. This information can be used similarly to the template's ixInstantiationSettingsDefaults, but can supersede those settings if it is provided in a more dynamic way on a per-application basis.

[0336] Information provided by the application at registration time may alternatively be provided or updated by the application after registration via CRUD operation(s) or other messages (eg, interactor-use-indications).

[0337]

[0338] Table 16 Parameters for enhanced App registration or for new interactor-use-indication messages

[0339] In preparation for step 2212, the application may use a resource discovery process or assumptions about the capabilities of the SL ICM 2202. For example:

[0340] The first application (e.g., application 2201) may assume that the templates to use (e.g., templates X and Y) are known / available at SL ICM 2202 and may provide a minimal amount of information, such as template IDs (ixTemplateIDList). If any templates are unknown, the first application may receive an error message in the response. This information may be provided by the first application at registration time, such as Fig. 22 In this case, the registration information will be enhanced to include this information. Alternatively, a dedicated interactor-use-indication message with ixTemplateIDList can be used.

[0341] The second application may discover templates known / available at the SL ICM 2202 (e.g., by discovering a template library) and may then select templates X and Y based on their capabilities. Assuming the discovery process is used, a dedicated message Interactor-Use-Indication with ixTemplateIDList information may be sent by the second application to the SL ICM 2202.

[0342] A third application may provide a complete description of the templates X and Y themselves and the ixInstantiationSettings. This approach may be particularly useful for introducing new templates that have not been pre-provisioned in step 2210. The application may send a dedicated message Interactor-Usage-Indication to the SL ICM 2202, which contains an ixTemplateDefintionList with a complete list of template definitions as shown in Table 13.

[0343] To populate ixInstantiationSettings, the application may use default values ​​or local policies. This element may also not be present, in which case a template or local policy at the SL ICM 2202 may be used.

[0344] Assume that the application registration process results in a RESTful environment in at least one application-specific resource created at the SL. For example, in oneM2M, a resource corresponding to the application 2201 may be created at registration. <ae1>Therefore, the information in Table 16 can be used to enhance this resource.

[0345] In a RESTful architecture, the information provided via the interactor-use-indication messages may be provided via CRUD operations on resources containing the information detailed in Table 16. For example, in oneM2M, <ae>Resource type enhancements can then be used not only to register options, but also to <ae>The UPDATE operation of a resource is implemented by the interactor-use-indication message.

[0346] Step 2212 may be performed during other stages of the process 2200, effectively updating the supported Ax-event information of an application (eg, application 2201).

[0347] During Phase B (Initialization / Registration) 2205, resources representing the Interactor and resources supporting the Interactor functionality may be created and initialized. Creation of resources is accompanied by initialization of necessary parameters with default / initial values, which may also be based on (one or more) Interactor templates, local policies, or explicit signaling (e.g., CRUD operations). At the end of Phase B 2205, in addition to the newly created resources, the SL ICM 2202 also has information corresponding to the Ix element set in the ixInstance.

[0348] SL ICM 2202 may register a new interactor instance on behalf of application 2201 (step 2213). Step 2213 may be performed by SL ICM 2202 and may be triggered by registration of application 2201 or an explicit request from application 2201 (e.g., via an interactor-use-indication message, i.e., triggered by completion of step 2212). Parameter initialization may be based on existing information, e.g., an interactor template or local policy. Step 2213 may result in the creation and initialization of interactor-related resources that support the functionality of the new interactor instance. The newly created resources may be populated with default values ​​as specified in initializeDefaults of the template, or may be based on local policies available at SL ICM 2202.

[0349] For example, the following resources may be created and initialized during step 2213:

[0350] An ixInstanceX1 resource, which may be a resource used by the SL ICM 2202 to perform overall management of the Ix-event to Ax-event correspondence of an interactor instance.

[0351] One or more resources based on ixEventResourceDescription: Resources that can be used by the SL ICM 2202 to enable communication (IxEvent) between the SL ICM 2202 and the Interactor 2203 based on physical user interactions. Once the SL ICM 2202 creates these resources, they can be linked to ixInstanceX1 using ixInteractResList. For example, if the template's ixInteractionResourceDescription specifies that two containers are required, then container X1 and container X2 can be created and linked to the Interactor 2203 via entries in the ixInteractResList attribute.

[0352] A resource based on ixInstantiationResourceDescription: The SL ICM 2202 can use this resource to trigger the instantiation of the Interactor 2203. Once the SL ICM 2202 has created this resource, it can link it to ixInstanceX1 using ixInstantiationTrigger. For example, if the template's ixInstantiationResourceDescription specifies that <mgmtcmd>, then an instatiationTriggerX1 of the mgmtCmd resource type may be created and instatiationTriggerX1 may be linked to the interactor 2203 via the ixInstantiationTrigger attribute.

[0353] An alternative to performing the interactor registration after the application 2201 is registered is similar to the above, but a trigger message "interactor-request" (see Table 17 below) from the application 2201 may be used. Other embodiments may use other events or notifications as triggers, but the process 2200 may still include interactor support resource creation and filling resource parameters with default values.

[0354]

[0355] Table 17 Interactor-Request Message

[0356] Alternatively, rather than SL ICM 2202 registering a new interactor instance on behalf of application 2201 as in step 2213, interactor 2203 may register itself with SL ICM 2202 (step 2214). Step 2214 may be performed by an interactor residing on a device different from the SL device in order to register or announce itself. As described above, step 2214 may result in any resources associated with the interactor being created and initialized at the SL, but in contrast to step 2213, resource creation and initialization is triggered by the interactor (e.g., interactor 2203).

[0357] This alternative may be used, for example, when the Interactor functionality is deployed on a device other than the ICM-capable device / platform. The SL discovery and registration process may be used for this purpose.

[0358] When the Interactor 2203 has access to information indicating the capabilities of the SL ICM 2202, it can be programmed to create and initialize its own supporting resources. During step 2214, the following resources can be created by the Interactor 2203 at the SL and hosted by the ICM (e.g., SL ICM 2202):

[0359] An ixInstanceX1 resource for overall interactor management

[0360] One or more resources based on ixEventResourceDescription to enable communication (IxEvent) between SL ICM 2202 and Interactor 2203. Once Interactor 2203 has created these resources, they can be linked to ixInstanceX1 using ixInteractResList.

[0361] A resource based on ixInstantiationResourceDescription that is used by the SL ICM 2202 to trigger the instantiation of the Interactor 2203. Once the SL ICM 2202 creates this resource, it can be linked to ixInstanceX1 using ixInstantiationTrigger. For example, if the template's ixInstantiationResourceDescription specifies that <mgmtcmd>, then an instatiationTriggerX1 of the mgmtCmd resource type may be created and instatiationTriggerX1 may be linked to the interactor 2203 via the ixInstantiationTrigger attribute.

[0362] The method of populating newly created resources with default values ​​may be specified in initializeDefaults of the template, or may be based on local policies available at the SL ICM 2202 .

[0363] During phase C (association and instantiation) 2206, the interactor 2203 may be associated with the application 2201 (step 2215). The resources representing and supporting the functionality of the interactor 2203 may provide a means to create an association list for each interactor instance. Each association may map a Cx-state to an Ax-event and an Ix-event.

[0364] This association between the Interactor 2203, Application 2201 and Template may be performed using related resources (e.g., ixInstanceX1, AE1 and TemplateX, respectively). Maintaining this association is part of the functionality provided by the SL ICM 2202 and enables, for example:

[0365] (1) Use a single UI (e.g., based on template X) to provide user interaction to multiple applications respectively (as exemplified in the deployment of the multi-function button described above with respect to step 2211). In this case, a single ixInstance may have an assocList with the following elements:

[0366] [Cx element set]:

[0367] assocList[i].cxStateIDAssoc = cxList[i].cxStateID in cxList (as described above).

[0368] [Ix element set] derived from a single template X and repeated for all elements. This element set includes:

[0369] ixEventResList

[0370] ixInstantiationTrigger

[0371] ixInstantiationSettings

[0372] [Ax element set] for each element derived from the registration of different applications, see step 2212 and Table 16. The element list may include:

[0373] axAssocApp

[0374] axEventOperation

[0375] axEventActionDescriptor

[0376] (2) Using multiple UIs to provide user interaction to a single application, as illustrated in the above example, to change the interface depending on the user. In this case, a single ixInstance can have an assocList with the following elements:

[0377] [Cx element set]:

[0378] assocList[i].cxStateIDAssoc = cxList[i].cxStateID in cxList (as described above).

[0379] [Ix element set] for each element derived from a different template. This element set may include:

[0380] ixEventResList

[0381] ixInstantiationTrigger

[0382] ixInstantiationSettings

[0383] [Ax element set] derived from the registration of a single application (see step 2212 and Table 4) and repeated for all elements. This element list may include:

[0384] axAssocApp

[0385] axEventOperation

[0386] axEventActionDescriptor

[0387] Next, if the user changes the example cxList of cState, then:

[0388] cxList[0] / cxStateID=A

[0389] cxList[0] / cxStateDescr=(user, Alice)

[0390] cxList[1] / cxStateID=B

[0391] cxList[1] / cxStateDescr=(User, Bob), and so on.

[0392] (3) Publishing and discovering information about available templates. For example, this can be used by applications or interactors to discover ICM capabilities, and conventional discovery methods can be used for individual template resources or template libraries.

[0393] (4) Enables batch changes of UI styles (as illustrated in the example above where the auditory alert for a hearing-impaired visitor is changed to a visual alert). In this case, a new entry can be added to the cxList upon user request, such as during a person's visit. Discovery can then be performed against the template library and templates can be found using interactMethod and / or interactEnvironment that indicate audio and visual alerts. Each discovered audio template can have an ixInstanceList, which can enable quick discovery of the targeted ixInstance. For all of these ixInstances, a new assocList entry is created, and cxStateIDAssoc is equal to the newly created cxStateID for the context of the visit time. In these entries, the [Ax element set] can remain unchanged, while the [Ix element set] can be created based on different visual alert templates.

[0394] (5) Enables value-added ICM services such as dynamic changes to UI instantiation settings (as illustrated in the example above where an auditory alarm is changed to a visual alarm when the ICM detects a noise level above a certain level). This scenario can be implemented similarly to the above scenario, except that the ICM can create new entries for the cxList using advanced capabilities such as machine learning, predictive analytics, etc.

[0395] In process 2200, the initial link between the interactor 2203 and the application 2201 resources has been completed at stage B (initialization / registration) 2205. If repeated 2215, the link can be updated by the application using an "interactor-request" message to create a new association or update an existing association.

[0396] The following is an example of associating InteractorX1, App1, and TemplateX by populating the associated resources (e.g., ixInstanceX1, AE1, and TemplateX, respectively):

[0397] ixInstanceX1 / ixTemplate=ixTemplateX

[0398] ixInstanceX1 / assocList[n] / axAssocApp=AE1:

[0399] as well as

[0400] ixTemplateX / ixInstanceList=ixInstanceX1,…

[0401] as well as

[0402] AE1 / aeIxInstanceList=ixInstanceX1…

[0403] The other parameters of the assocList of ixInstanceX1 may be populated as previously detailed, e.g., crntAssocIndex, cxStateID, and ixEventActionDescr of defaultsDefaults based on a template or local policy, ixInstantiationSettings based on an interactor-use-indication or a registration message, etc. Similarly, ixEventResList may be populated with links to resources created based on the ixEventResourceDescription of the template. The SL ICM 2202 may maintain a crntAssocIndex that points to an entry in the assocList corresponding to the current context.

[0404] The actions taken in step 2215 may differ depending on the iteration. For example, the initial configuration of associations may be performed immediately after the initial interactor is instantiated. If this operation is performed after further context changes, it may result in associations being updated or suspended, or one or all associations being deleted (without deleting the interactor, etc.).

[0405] The interactor 2203 may then be instantiated (step 2216). Interactor instantiation is performed, which is the process of running the interactor's UI software. When step 2216 is performed for the first time after phase A (setup) 2204 and phase B (initialization / registration) 2205, the software of the interactor 2203 may be triggered to run based on the newly created interactor and initial association. When step 2216 is performed after further context changes, the UI of the interactor 2203 may be triggered to run with the updated association.

[0406] This results in Interactor 2203 processing user interactions and Ix-events exchanged with the associated application (eg, application 2201) via SL ICM 2202. Triggers may be performed by the entity that created the associated resource (ie, either the application (eg, application 2201) or SL ICM 2202).

[0407] The SL ICM 2202 may evaluate the SL context and convert the user interactions into IxEvents (step 2217). The SL ICM may continuously evaluate the context based on the Ix-C rules provided to the SL ICM 2202 during Phase A (Setup) 2204. If the rules are dynamically updated, the SL ICM 2202 may update the definition of its Cx-states and the evaluation follows the current rules. The SL ICM 2202 may continuously communicate with the application and the interactor using associations by converting the user interactions into IxEvents (and vice versa). During step 2217, the SL ICM 2202 may also communicate with the interactor to convert the user interactions into IxEvents at the application or from IxEvents at the application into user interactions, as shown above.

[0408] If the context changes, then the SL ICM 2202 may proceed to step 2215 (change association), otherwise proceed to step 2217 (keep evaluating). The ICM may maintain a context-based interaction management state machine. If the context changes such that the interactor requires a different association (step 2218), then go to step 2206 during Phase C (association and instantiation), otherwise continue evaluating (go to step 2217). To update the association, the SL ICM 2202 may align the crntAssocIndex of the ixInstance with the assocList index with the corresponding context state (cxStateIDAssoc).

[0409] An Interactor deregistration process may then occur, which deletes resources supporting Interactor 2203 functionality at the SL ICM 2202 (step 2219). This phase may end with the Interactor in a "deregistered" state, but ICM services continue.

[0410] Fig.23 is a diagram of an example process 2300 for converting user interactions into interactor events, according to one embodiment, which can be used in conjunction with any of the embodiments described herein. Fig.23 The example of describes the use of an association between an interactor 2303 and an application 2301 to process received input user interactions (output and complex interactions can be processed similarly to this example). Fig.23 , user interaction may occur and may be processed by the interactor 2303 (step 2310). The interactor 2303 may provide events to the SL ICM 2302 based on the input user interaction, and the event may include some information generated by the user interaction (step 2311). For example, for a mouse click, the event may capture / include the position of the mouse on the screen. In a RESTful architecture, this step may be implemented by using resources associated with the interactor at the SL (e.g., entries in ixEventResList). For example, in the above-mentioned initialization / registration phase, the corresponding resource ixInstanceX1 has been created using the corresponding entry in ixEventResList (e.g., containerX1). In this step, user interaction may cause the interactor 2303 to update container X1.

[0411] SL ICM 2302 may send a corresponding IxEvent to application 2301, and may include information about the SL context in addition to the UI context, which is part of the added value of using ICM (step 2312). In this way, application 2301 may not only be notified that the user clicked the mouse, but also obtain other information about the SL context when the click occurred.

[0412] In some embodiments, the event processed by the interactor 2301 in step 2311 may be directly mapped to an IxEvent, so it is forwarded to the application 2301 by the SL ICM 2302. This implementation may provide optimization, but may forgo the added value of providing the application with the SL context associated with the user interaction. With this optimization, the ICM may provide services by switching associations between the interactor and the application based on context switching.

[0413] This type of functionality can allow for context-sensitive interpretation of user actions, not just context-sensitive instantiation of interactors. An example is that of the implementation described above, where the home control platform detects high noise levels, or knows this from the high stereo volume settings. The cxRules could specify: "Store the alarm and repeat it periodically with changed settings (ixInstantiationSettings) or type (association) until it is acknowledged". When the ICM receives an output IxEvent, it can know from its functional description that it is an alarm, and can know from the associated interactor whether it is audio, visual, etc. After an unacknowledged audio alarm, the alarm can be repeated with a different volume, timbre, etc. If the ambient noise is too high, then it can create a new Cx-State for the current environment, and a new visual interactor (flashing LED) associates that Cx-State with the IxEvent. The alarm can then be repeated in a form that is more likely to be acknowledged. While this deployment may be more suitable for platforms using machine learning and predictive analytics, it can use the same basic ICM and interactor functionality as described in this article.

[0414] The ICM functions and processes described herein may be implemented using oneM2M resources, such as by being implemented as an ICM CSF that resides in a CSE and exposes its services to an AE. The interactor introduced above may also be implemented as one or more CSFs. The interactor may be implemented in the same CSF as the ICM, or may be implemented in a separate (one or more) CSFs. The interactor may also be implemented as an AE or IPE. An application may also be implemented as an AE.

[0415] For example, Fig. 22 The process 2200 can be mapped into oneM2M as follows:

[0416] Step 2210 can be accomplished by introducing a new resource type <ixtemplate>The content can be provided using pre-provisioned DM operations in oneM2M or existing RESTful procedures.

[0417] Step 2211 can be done by using the new resource type <cxlist>The resource content may be provided using the GUI and existing RESTful processes in oneM2M as described in Phase A (Setup) 2204. Unless cxList is exposed to other entities, this type of resource may not be defined, but the resource functionality may still be provided locally in the service layer in an implementation-specific manner.

[0418] The Interactor-Use-Indication Message step 2213 can be implemented by introducing new resource types in oneM2M <ixinstance>This step may also result in the creation of existing oneM2M resources of other types as specified in ixEventResourceDescription (e.g. <container> ， <flexcontainer>).

[0419] Step 2215 may be performed via the existing RESTful UPDATE procedure in oneM2M for attributes such as ixID, appIdentifier, ixTemplateID, ixInstantiationSettings, ixEventOperation, cxStateIDAssoc, etc. <ixinstance> 、 <ae>and <ixtemplate>Alternatively, it can be implemented with an Interactor-Request message providing these parameters to the ICM, where the corresponding resource is updated.

[0420] Step 2216 may be implemented as a process that creates a new instantiation of a given software application or process.

[0421] Step 2217 may be implemented as an existing RESTful process in oneM2M, as shown below:

[0422] Interactors can provide input and ICM relay output by performing RESTful operations on resources related to the Interactor based on ixEventResourceDescription (of existing oneM2M type);

[0423] ICM and applications use the resources specified in ixEventOperation (of the existing oneM2M type);

[0424] <ixtemplate>A resource may represent a single interactor template and may be specified as described in Table 18 below. <ixtemplatelibrary>A resource may contain a collection of templates that may be discovered (eg, by an application) in order to select or indicate a particular template to be used for instantiation of an interactor.

[0425]

[0426]

[0427] Table 18 New <ixtemplate>Properties of resource types

[0428] <ixtemplatelibrary>A resource can contain the following sub-resources.

[0429]

[0430] Table 19 <ixtemplatelibrary>Subresources of a resource type

[0431] <cxstate>A resource may contain information required to define the contextual state of the ICM. <cxlist>Resources can contain all the information used by the ICM in monitoring and managing Cx-State transitions. <cxstate>A list of resources.

[0432] <cxlist>A resource may contain the following sub-resources listed in Table 8 below.

[0433]

[0434] Table 20 <cxlist>Subresources of a resource type <cxstate>A resource may contain the following attributes listed in Table 21 below.

[0435]

[0436] Table 21 New <cxstate>Resource Type

[0437] The following is an example implementation of context state (cxStateDescr) based on attribute matching conditions of resources in SL. Other implementations can be envisioned. For example, a state change may occur when the ICM receives a specific notification or at a specific time of day, etc.

[0438] In this example, the parameter set represented in the cxStateDescr attribute consists of a 4-tuple (contextResourceIDs, cxStateCriteria, timeWindowType, timeWindowSize), the parameters of which are shown in the following Table 22. The cxStateDescr attribute may contain at least one tuple.

[0439]

[0440] Table 22: Parameters in the cxStateDescr 4-tuple

[0441]

[0442] Table 23: cxStateCriteria conditions

[0443] The rules when multiple conditions can be used together are as follows:

[0444] Different conditional tags can use "AND / OR" logical operations based on the specified conditionOperation;

[0445] The same conditional tags can use the "OR" logical operation.

[0446] Resource Type <ixassociation>Includes the corresponding interactor instance <ixinstance>Subresources of resource. For interactors (such as those provided by <ixinstance>Indicated), each <ixassociation>An association between a Cx-state (as represented by cxStateID) and an AE (as represented by axAssocApp) may be represented.

[0447]

[0448]

[0449] Table 24 <ixassociation>Properties of resource types

[0450] <ixinstance>A resource type may represent an Interactor instance and may include information about all Cx-states (via child <ixassociation>Resources), the Interactor can change its association with the AE based on this information.

[0451] <ixinstance>A resource may contain the sub-resources listed in Table 25 below.

[0452]

[0453] Table 25 <ixinstance>Subresources of a resource type

[0454]

[0455]

[0456] Table 26 New <ixinstance>Properties of resource types

[0457] This article describes the resource types <ae>The properties of the and interactor-use-indicate the parameters of the message. <ae>Resources can represent information about application entities registered with the SL. Table 27 and Table 28 describe the enhanced functions. <ae>New elements of a resource type (i.e., subresources and attributes).

[0458]

[0459] Table 27 <ae>New subresource of resource type

[0460]

[0461]

[0462] Table 28 Addendum <ae>Resource Type Properties

[0463] New in the table above <ae>The difference between the resource type attribute list and the content of the interactor-use-indication message in Table 16 is ixTemplateDefintionList, because it is assumed that all templates are stored in <ixtemplatelibrary>In and only in <ae>The oneM2M implementation referenced in the resource. Other implementations may choose to store the template as <ixtemplate>resource, <ae>A new subresource of a resource type.

[0464] In a RESTful environment such as oneM2M, and given the above <ae>Resource definitions can be assumed to use <ae>The UPDATE operation of these new attributes of the resource type implements the interactor-use-indication message. If you want to use the ixTemplateDefintionList of the interactor-use-indication message to provide new templates, you can use the <ixtemplatelibrary>Additional UPDATE operations.

[0465] The following is an example embodiment of a service layer framework for integrating common and functional user interfaces as services managed by the SL on behalf of the requesting entity:

[0466] 1. An apparatus comprising a processor, a memory, and a communication circuit system, the apparatus being connected to a network via its communication circuit system, the apparatus further comprising computer executable instructions stored in the memory of the apparatus, the computer executable instructions, when executed by the processor of the apparatus, causing the apparatus to perform operations comprising:

[0467] receiving first information indicating a plurality of context switching rules;

[0468] receiving second information indicating a plurality of operations, each operation of the plurality of operations being configured to be triggered based on at least one physical interaction; and

[0469] A mapping between each triggered operation and a signal generated by at least one of the first type of service layer entities based on the at least one physical layer interaction is determined based on the context switching rules.

[0470] 2. The apparatus of embodiment 1, wherein the mapping changes in response to updated context switching rules.

[0471] 3. The apparatus of embodiment 1, further comprising computer executable instructions stored in a memory of the apparatus, the computer executable instructions, when executed by a processor of the apparatus, causing the apparatus to perform further operations comprising:

[0472] At least one application registration message is received.

[0473] 4. The apparatus of embodiment 3, wherein the second information is provided together with the at least one application registration message.

[0474] 5. The apparatus of embodiment 3, wherein the at least one application registration message is received from at least one application.

[0475] 6. The apparatus of embodiment 1, further comprising computer executable instructions stored in a memory of the apparatus, the computer executable instructions, when executed by a processor of the apparatus, causing the apparatus to perform further operations comprising:

[0476] A message including a plurality of templates is received, wherein each template includes functional information associated with each signal generated by a service layer entity of the first type, wherein the second information indicates at least one template corresponding to each operation.

[0477] 7. The apparatus of embodiment 6, further comprising computer executable instructions stored in the memory of the apparatus, the computer executable instructions, when executed by the processor of the apparatus, causing the apparatus to perform further operations comprising:

[0478] Each service layer entity is instantiated, and each service layer entity generates a signal conforming to at least one template based on the mapping.

[0479] 8. The apparatus of embodiment 1, further comprising computer executable instructions stored in a memory of the apparatus, the computer executable instructions, when executed by a processor of the apparatus, causing the apparatus to perform further operations comprising:

[0480] A service layer registration message is received from at least one service layer entity of the first type.

[0481] 9. The apparatus of embodiment 8, wherein the service layer registration message is received from a plurality of service layer entities.

[0482] 10. The apparatus of embodiment 1, further comprising computer executable instructions stored in a memory of the apparatus, the computer executable instructions, when executed by a processor of the apparatus, causing the apparatus to perform further operations comprising:

[0483] receiving at least one application registration message;

[0484] receiving a message including a plurality of templates, wherein each template includes functional information associated with each signal generated by a service layer entity of the first type, wherein the second information indicates at least one template corresponding to each operation; and

[0485] Each service layer entity is identified based on the received at least one application registration message and the at least one template.

[0486] 11. The apparatus of embodiment 1, wherein the updated mapping causes at least one physical interaction to trigger different actions based on the context.

[0487] 12. The apparatus of embodiment 1, wherein the updated mapping causes at least one operation to be triggered by at least one different physical interaction based on the context.

[0488] 13. The apparatus of embodiment 1, further comprising computer executable instructions stored in a memory of the apparatus, the computer executable instructions, when executed by a processor of the apparatus, causing the apparatus to perform further operations comprising:

[0489] detecting a service layer signal indicating that at least a first physical interaction was performed; and

[0490] A signal is sent to one of the plurality of operations via the at least one service layer entity based on the mapping.

[0491] 14. The apparatus of embodiment 1, wherein the at least one physical interaction comprises communications exchanged between the software and the user via a user interface.

[0492] 15. The apparatus of embodiment 14, wherein the communication is a mouse input, a voice input, an audio input, or a click input.

[0493] 16. The apparatus of embodiment 1, wherein the first information, the second information, the registration message, and the mapping are stored in a database.

[0494] 17. The apparatus of embodiment 1, wherein the first information is received via a network.

[0495] 18. The apparatus of embodiment 1, wherein the second information is received via a network.

[0496] 19. The apparatus of embodiment 1, wherein the apparatus is a wireless communication device.

[0497] 20. The apparatus of embodiment 1, wherein the apparatus is a computing device.

[0498] 21. The device of embodiment 1, wherein the device is a smart phone.

[0499] 22. The device of embodiment 1, wherein the device is a gateway.

[0500] 23. A method performed by the apparatus of any one of embodiments 1 to 22.

[0501] Fig.24A is a diagram of an exemplary machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. In general, M2M technology provides building blocks for IoT / WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of IoT / WoT and IoT / WoT service layer, etc. Figure 2 , 5 , 6, 8-12 and 19A-19C, any of the client, proxy or server devices shown in any of them comprises a node of a communication system, such as Fig.24A - The nodes shown in D.

[0502] The service layer can be a functional layer within a network service architecture. The service layer is usually located above the application protocol layer (such as HTTP, CoAP or MQTT) and provides value-added services for client applications. The service layer also provides an interface to the core network located at the lower resource layer (such as, for example, the control layer and the transport / access layer). The service layer supports multiple categories of (service) capabilities or functions, including service definition, service runtime enablement, policy management, access control and service clustering. Recently, several industry standard organizations (e.g., oneM2M) have been developing the M2M service layer to address the challenges associated with integrating M2M-type devices and applications into deployments such as the Internet / web, cellular, enterprise and home networks. The M2M service layer can provide applications and / or various devices with access to the above-mentioned capabilities or function sets or sets supported by the service layer, and the service layer can be referred to as CSE or SCL. Some examples include, but are not limited to, security, billing, data management, device management, discovery, provisioning and connectivity management, which can be used by various applications in common. These capabilities or functions are made available to the various applications by using the message format, resource structure, and resource representation API defined by the M2M service layer. A CSE or SCL is a functional entity that can be implemented by hardware or software, and provides (service) capabilities or functions (i.e., functional interfaces between such functional entities) exposed to various applications or devices so that they can use such capabilities or functions.

[0503] like Fig.24A As shown in , the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, optical fiber, ISDN, PLC, etc.) or a wireless network (e.g., WLAN, cellular, etc.) or a network of heterogeneous networks. For example, the communication network 12 may include multiple access networks that provide content such as voice, data, video, messaging, broadcast, etc. to multiple users. For example, the communication network 12 may adopt one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), etc. In addition, for example, the communication network 12 may include other networks, such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a converged personal network, a satellite network, a home network, or an enterprise network.

[0504] like Fig.24A As shown in , the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of the end-to-end M2M deployment, and the field domain refers to the regional network usually behind the M2M gateway. Both the field domain and the infrastructure domain may include various different nodes of the network (e.g., servers, gateways, devices, etc.). For example, the field domain may include an M2M gateway 14 and a device 18. It will be appreciated that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M / IoT / WoT communication system 10 as desired. Each of the M2M gateway devices 14 and the M2M devices 18 is configured to send and receive signals via the communication network 12 or a direct radio link using a communication circuit system. The M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLC) to communicate either through an operator network such as the communication network 12 or through a direct radio link. For example, the M2M devices 18 may collect data and send data to the M2M applications 20 or other M2M devices 18 via the communication network 12 or a direct radio link. The M2M devices 18 may also receive data from the M2M applications 20 or the M2M devices 18. In addition, data and signals may be sent to and received from the M2M applications 20 via the M2M service layer 22, as described below. The M2M devices 18 and the gateway 14 may communicate via various networks, including cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio links, and wired lines. Exemplary M2M devices include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors, and other actuator-based devices, security devices, and smart sockets.

[0505] refer to Fig. 24B , the M2M service layer 22 shown in the field domain provides services for the M2M applications 20, the M2M gateways 14 and the M2M devices 18, and the communication network 12. It will be understood that the M2M service layer 22 can communicate with any number of M2M applications, M2M gateways 14, M2M devices 18, and communication networks 12 as desired. The M2M service layer 22 can be implemented by one or more nodes of the network, which can include servers, computers, devices, etc. The M2M service layer 22 provides service capabilities applicable to the M2M devices 18, the M2M gateways 14, and the M2M applications 20. The functions of the M2M service layer 22 can be implemented in various ways, such as as a web server, in a cellular core network, in the cloud, etc.

[0506] Similar to the M2M service layer 22 shown, there is an M2M service layer 22' in the infrastructure domain. The M2M service layer 22' provides services for the M2M applications 20' and the underlying communication network 12 in the infrastructure domain. The M2M service layer 22' also provides services for the M2M gateways 14 and M2M devices 18 in the field domain. It will be understood that the M2M service layer 22' can communicate with any number of M2M applications, M2M gateways, and M2M devices. The M2M service layer 22' can interact with the service layers of different service providers. The M2M service layer 22' can be implemented by one or more nodes of a network, which network nodes may include servers, computers, devices, virtual machines (e.g., cloud computing / storage farms, etc.), etc.

[0507] Also refer to Fig. 24B , the M2M service layers 22 and 22' provide a core set of service delivery capabilities that can be fully utilized by different applications and verticals. These service capabilities enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service / device discovery, etc. Basically, these service capabilities relieve the application of the burden of implementing these functions, thereby simplifying application development and reducing costs and time to market. The service layers 22 and 22' also enable the M2M applications 20 and 20' to communicate in association with the services provided by the service layers 22 and 22' over various networks (such as the network 12).

[0508] The M2M applications 20 and 20' may include applications in various industries, such as, but not limited to, transportation, health and wellness, connected home, energy management, asset tracking, and security and monitoring. As mentioned above, the M2M service layer running between the devices, gateways, servers, and other nodes of the system supports functions such as, for example, data collection, device management, security, billing, location tracking / geofencing, device / service discovery, and legacy system integration, and provides these functions as services to the M2M applications 20 and 20'.

[0509] Generally speaking, such as Fig. 24B The service layer 22 and 22' shown in the service layer 22 and 22' such as the service layer defines a software middleware layer, which supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. The service layer of ETSI M2M is called the service capability layer (SCL). The SCL can be implemented in various different nodes of the ETSI M2M architecture. For example, an instance of the service layer can be implemented in an M2M device (where it is called a device SCL (DSCL)), in a gateway (where it is called a gateway SCL (GSCL)) and / or in a network node (where it is called a network SCL (NSCL)). The oneM2M service layer supports a set of public service functions (CSFs) (i.e., service capabilities). The instantiation of a set of one or more specific types of CSFs is called a public service entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). The third generation partnership project (3GPP) has also defined an architecture for machine type communication (MTC). In that architecture, the service layer and the service capabilities it provides are implemented as part of a service capability server (SCS). Whether implemented in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a service capability server (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of the network, an instance of the service layer can be implemented as a logical entity (e.g., software, computer executable instructions, etc.) that is executed on one or more independent nodes (including servers, computers, and other computing devices or nodes) in the network or as part of one or more existing nodes. As an example, an instance of the service layer or its components can be implemented in a network having the following Fig.24C or Fig.24D The general architecture shown in FIG. 1 is implemented in the form of software running on a network node (eg, server, computer, gateway, device, etc.).

[0510] Additionally, the methods and functions described herein may be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) to access services.

[0511] Fig.24C is a block diagram of an example hardware / software architecture for a node of a network such as Figure 2 , 5 , 6, 8-12 and 19A-19C shown in the client, server or agent, which can be used as such as Fig.24A and 24B The M2M server, gateway, device or other node operation in the M2M network shown in FIG. Fig.24C As shown in FIG. 1 , node 30 may include a processor 32, non-removable memory 44, removable memory 46, speaker / microphone 38, keyboard 40, display, touchpad and / or indicator 42, power supply 48, global positioning system (GPS) chipset 50, and other peripherals 52. Node 30 may also include communication circuitry such as transceiver 34 and transmit / receive element 36. It will be appreciated that node 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the functionality described herein, for example, with reference to FIG. Figure 6-23 Described method related.

[0512] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. In general, the processor 32 may execute computer executable instructions stored in a memory (e.g., memory 44 and / or memory 46) of the node to perform various desired functions of the node. For example, the processor 32 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the node 30 to operate in a wireless or wired environment. The processor 32 may run application layer programs (e.g., a browser) and / or radio access layer (RAN) programs and / or other communication programs. For example, the processor 32 may also perform security operations such as authentication, security key negotiation, and / or encryption operations, such as at the access layer and / or application layer.

[0513] like Fig.24C As shown in FIG. 1 , processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit / receive element 36). By executing computer-executable instructions, processor 32 can control the communication circuitry so that node 30 communicates with other nodes via a network connected thereto. In particular, processor 32 can control the communication circuitry so as to perform the sending and receiving steps described herein and in the claims (e.g., in Figure 6-23 ). Fig.24C The processor 32 and transceiver 34 are depicted as separate components, but it will be appreciated that the processor 32 and transceiver 34 may be integrated together in an electronic package or chip.

[0514] The sending / receiving element 36 can be configured to send signals to other nodes or receive signals from other nodes, and the nodes include M2M servers, gateways, equipment, etc. For example, in an embodiment, the sending / receiving element 36 can be an antenna configured to send and / or receive RF signals. The sending / receiving element 36 can support various networks and air interfaces, such as WLAN, WPAN, cellular, etc. In an embodiment, the sending / receiving element 36 can be a transmitter / detector configured to, for example, send and / or receive IR, UV or visible light signals. In another embodiment, the sending / receiving element 36 can be configured to send and receive both RF and optical signals. It will be appreciated that the sending / receiving element 36 can be configured to send and / or receive any combination of wireless or wired signals.

[0515] Furthermore, although the transmit / receive element 36 is Fig.24C 30 is depicted as a single element, but the node 30 may include any number of transmit / receive elements 36. More specifically, the node 30 may employ MIMO technology. Therefore, in an embodiment, the node 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for sending and receiving wireless signals.

[0516] The transceiver 34 may be configured to modulate signals to be transmitted by the transmit / receive element 36 and demodulate signals received by the transmit / receive element 36. As described above, the node 30 may have multi-mode capabilities. Thus, for example, the transceiver 34 may include multiple transceivers for enabling the node 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0517] The processor 32 can access information from any type of suitable memory (such as non-removable memory 44 and / or removable memory 46) and store data therein. For example, the processor 32 can store session context in its memory, as described above. The non-removable memory 44 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 32 can access information from a memory physically located on the node 30 (such as on a server or a home computer) and store data therein. The processor 32 may be configured to control a lighting pattern, an image, or a color on a display or indicator 42. In one embodiment, the display / indicator 42 may present a graphical user interface shown and described herein.

[0518] Processor 32 may receive power from power source 48 and may be configured to distribute and / or control power to other components in node 30. Power source 48 may be any suitable device for powering node 30. For example, power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0519] Processor 32 may also be coupled to a GPS chipset 50 that is configured to provide location information (eg, longitude and latitude) regarding the current location of node 30. It will be appreciated that node 30 may acquire location information via any suitable location determination method while remaining consistent with an embodiment.

[0520] The processor 32 may also be coupled to other peripherals 52, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 52 may include various sensors, such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, sensors, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, and more.

[0521] Node 30 may be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or electronic health equipment, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes), etc. Node 30 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces (such as an interconnect interface that may include one of peripheral devices 52).

[0522] Fig.24D is a block diagram of an exemplary computing system 90, which may also be used to implement one or more nodes of a network, such as Figure 2 , 5 , 6, 8-12 and 19A-19C shown in the client, server or agent, which can be used as an M2M server, gateway, device or other node in the M2M network, such as Fig.24A and 24B The nodes shown in .

[0523] The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, wherever or by whatever means such software is stored or accessed. Such computer-readable instructions may be executed within a processor such as a central processing unit (CPU) 91 to cause the computing system 90 to operate. In many known workstations, servers, and personal computers, the central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may include multiple processors. A coprocessor 81 is an optional processor distinct from the main CPU 91 that performs additional functions or assists the CPU 91. The CPU 91 and / or the coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for E2E M2M service layer sessions, such as receiving session credentials or authenticating based on session credentials.

[0524] In operation, the CPU 91 retrieves, decodes and executes instructions, and transmits information to and from other resources via the computer's main data transfer path, the system bus 80. Such a system bus connects the components in the computing system 90 and defines the medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0525] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set up, it cannot access memory within the virtual address space of another process.

[0526] In addition, the computing system 90 may include a peripheral device controller 83 , which is responsible for transmitting instructions from the CPU 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0527] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86. In conjunction with the computer executable instructions executed by the CPU 91, the display 86 may generate and operate the graphical user interface shown and described herein.

[0528] Additionally, computing system 90 may include communications circuitry such as, for example, network adapter 97, which may be used to connect computing system 90 to an external communications network, such as Figures 24A-24D The network 12 enables the computing system 90 to communicate with other nodes of the network. The communication circuit system can be used to perform the present invention (for example, in Figure 6-23 The sending and receiving steps described in the claims) and claims.

[0529] It should be understood that any or all of the systems, methods, and processes described herein may be implemented in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium, which, when executed by a machine (such as an apparatus of an M2M network, including, for example, an M2M server, gateway, device, etc.), performs and / or implements the systems, methods, and processes described herein. Specifically, any of the above steps, operations, or functions may be implemented in the form of such computer executable instructions. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transient (i.e., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and can be accessed by a computer.

[0530] It should be understood that the execution Figure 6-23 The entities of the steps shown, such as IoT devices, IoT servers, IoT gateways, IoT service layers, RAS, IoT applications, oneM2M devices, non-oneM2M devices, oneM2M IPE, AE, CSE, RAS CSF, IoT user equipment, UE, etc., may be logical entities that may be implemented in the form of software (i.e., computer executable instructions) stored in an apparatus or computer system (such as a computer system) configured for wireless and / or network communications. Fig.24C or Fig.24D The method is stored in the memory of the device or computer system shown in FIG. 1 and executed on the processor of the device or computer system. That is, Figure 6-23 The method(s) shown may be implemented in the form of software (ie, computer executable instructions) stored in a device such as a Fig.24C or Fig.24D The computer executable instructions, when executed by the processor of the device, execute Figure 6-23 It should also be understood that Figure 6-23 The functions shown may be implemented as a set of virtualized network functions. The network functions do not necessarily have to communicate directly, but they may communicate via forwarding or routing functions. It should also be understood that Figure 6-23 Any of the sending and receiving steps shown may be performed by the communication circuitry of the device under the control of a processor of the device and computer-executable instructions (eg, software) executed thereon.

[0531] This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any combined methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. These other examples are intended to be within the scope of the claims if they have elements that do not differ from the literal language of the claims, or if they include equivalent elements that are insubstantially different from the literal language of the claims.< / ixtemplatelibrary> < / ae> < / ae> < / ae> < / ixtemplate> < / ae> < / ixtemplatelibrary> < / ae> < / ae> < / ae> < / ae> < / ae> < / ae> < / ixinstance> < / ixinstance> < / ixinstance> < / ixassociation> < / ixinstance> < / ixassociation> < / ixassociation> < / ixinstance> < / ixinstance> < / ixassociation> < / cxstate> < / cxstate> < / cxlist> < / cxlist> < / cxstate> < / cxlist> < / cxstate> < / ixtemplatelibrary> < / ixtemplatelibrary> < / ixtemplate> < / ixtemplatelibrary> < / ixtemplate> < / ixtemplate> < / ae> < / ixinstance> < / flexcontainer> < / container> < / ixinstance> < / cxlist> < / ixtemplate> < / mgmtcmd> < / mgmtcmd> < / ae> < / ae> < / absreq> < / absreq> < / absreq> < / absreq> < / ras> < / absreq> < / absreq> < / absreq> < / absreq> < / absreq> < / absreq> < / absreq> < / absreq> < / absreq> < / visitor> < / visitor> < / visitor> < / visitor> < / analyst> < / analyst> < / visitor> < / analyst> < / visitor> < / analyst> < / acp> < / analyst> < / acp> < / analyst> < / acp> < / analyst> < / analyst> < / analyst> < / analyst> < / analyst> < / analyst> < / analyst> < / analyst> < / geofencedata> < / analyst> < / analyst> < / guest>

Claims

1. A device comprising a processor, a memory, and a communication circuit system, the device being connected to a network via its communication circuit system, the device further comprising computer executable instructions stored in the memory of the device, the computer executable instructions, when executed by the processor of the device, causing the device to perform operations comprising: receiving an abstract request from a requesting entity, the abstract request comprising a command predicate, one or more command objects, and one or more command contexts; Inferring a sequence of one or more service layer operations to be performed based on the decomposition of the abstract request; executing, at the service layer, the sequence of service layer operations; as well as One or more status codes and a sequence of service layer operations performed are sent to the requesting entity.

2. The apparatus of claim 1, wherein the abstract request comprises a service layer request message.

3. The apparatus of claim 1 , further comprising computer executable instructions stored in a memory of the apparatus, the computer executable instructions, when executed by a processor of the apparatus, causing the apparatus to perform further operations comprising: Prior to determining the sequence of the service layer operations, the abstract request is analyzed to determine the command predicate, the one or more command objects, and the one or more command contexts.

4. The apparatus of claim 1 , further comprising computer executable instructions stored in a memory of the apparatus, the computer executable instructions, when executed by a processor of the apparatus, causing the apparatus to perform further operations comprising: Determining that a keyword exists in the abstract request; determining that a service layer operation is associated with the keyword; and The service layer operation is added to the sequence of service layer operations to be performed.

5. The apparatus of claim 1 , further comprising computer executable instructions stored in a memory of the apparatus, the computer executable instructions, when executed by a processor of the apparatus, causing the apparatus to perform further operations comprising: classifying the words of the abstract request as nouns; and Based on the noun classification, a service layer entity associated with the word is determined.

6. The apparatus of claim 1 , wherein determining a sequence of service layer operations to be performed comprises: classifying words of the abstract request as verbs; as well as Based on the verb classification, a service layer operation associated with the word is determined.

7. The apparatus of claim 1, wherein the instructions further cause the service layer entity to: A service layer resource representing the abstract request is created, wherein the service layer resource includes a command verb, one or more command objects, and context information.

8. The apparatus of claim 7, wherein the instructions further cause the service layer entity to: receiving a second abstract request for the service layer resource, wherein the second abstract request includes second context information for replacing the context information; and The abstract request is processed using the second context information.

9. The apparatus of claim 1, wherein the abstract request comprises a text string.

10. The apparatus of claim 1, wherein the one or more command contexts contain context information for use in future abstract requests. The apparatus of claim 10 , wherein the context information comprises words and definitions associated with the words.

12. The apparatus of claim 10, wherein the context information comprises a term and a service layer operation associated with the term.

13. A method for requesting an abstract service, comprising: receiving an abstract request from a requesting entity, the abstract request comprising a command predicate, one or more command objects, and one or more command contexts; Inferring a sequence of one or more service layer operations to be performed based on the decomposition of the abstract request; Generate a service layer application program interface API set based on the command predicate, the one or more command objects and the one or more command contexts, wherein the service layer API set calls a sequence of the one or more service layer operations; Execute the generated API set; as well as A status indicating completion of the abstract request is returned to the requesting entity.

14. The method of claim 13, further comprising: determining that a first command context of the one or more command contexts is not recognized; as well as The requesting entity is prompted to define the command context.

15. The method of claim 13, further comprising: A resource of the abstract request is created to store the command predicate, the one or more command objects, and the one or more command contexts.

16. The method of claim 15, further comprising: receiving a request for the resource; as well as Execute the generated API set.

17. The method of claim 15, further comprising: receiving a second abstract request, wherein the second abstract request is for the resource and includes one or more changes to be made to the abstract request; as well as Based on the one or more changes, resources of the abstract request are modified.

18. The method of claim 13, further comprising: The generated API set is sorted before being executed.

19. The method of claim 13, wherein the generated API set is ordered such that retrieval and discovery operations are performed before creation or update operations.

20. A non-transitory computer-readable storage medium storing computer-readable instructions that, when executed by a processor of a computing device, cause the computing device to perform operations comprising: receiving, at a service layer, an abstract request from a requesting entity, the abstract request comprising a command predicate, one or more command objects, and one or more command contexts; Inferring a set of service layer operations to be performed based on the decomposition of the abstract request; executing the generated set of operations at the service layer; as well as A list and status of executed service layer operations is returned to the requesting entity.

21. The non-transitory computer-readable storage medium of claim 20, further storing computer-readable instructions that, when executed by a processor of the computing device, cause the computing device to perform operations further comprising: determining that a first command context of the one or more command contexts is not recognized; and The requesting entity is prompted to define the command context.

22. The non-transitory computer-readable storage medium of claim 20, wherein a command context in the one or more command contexts comprises: The number of resources to be operated on, the identifier and name of the resource to be operated on, the duration, and the desired location.

23. The non-transitory computer-readable storage medium of claim 20, further storing computer-readable instructions that, when executed by a processor of the computing device, cause the computing device to perform operations further comprising: receiving a request to modify a first command context of the one or more command contexts; and Based on the modified first command context, the generated service layer operation set is modified.

24. The non-transitory computer-readable storage medium of claim 20, further storing computer-readable instructions that, when executed by a processor of the computing device, cause the computing device to perform operations further comprising: receiving a request to modify a first command object of the one or more command objects; and Based on the modified first command object, the generated service layer operation set is modified.

Images