Abstract: Methods and apparatuses are described herein for an automated product management (APM) service. An apparatus may receive from a second apparatus, at least one first request to enroll a third apparatus with a service layer associated with the second apparatus. The apparatus may send a second request to verify authenticity of the third apparatus and to generate a customized firmware or software for the third apparatus. The apparatus may send a third request to configure the third apparatus based on consent of a user of the third apparatus. The apparatus may send a response indicating whether the third apparatus has been enrolled with the service layer. The apparatus may receive a fourth request to diagnose or troubleshoot the third apparatus and a fifth request comprising information and the consent and requesting the fourth apparatus to perform at least one operation on the third apparatus.

Abstract: A set of point-of-contact information including a service level identifier, an address, a list of interfaces, and a set of interface selection preferences for each of several entities may be used to facilitate communications among the entities by selecting a preferred interface in accordance with the set. Interface preferences may also be derived from a set of policies. The preferred interface may be resolved in accordance with the preferences of multiple entities. Messages may include an interface type parameter to be used for forwarding of the message, and message forwarding may be resolved in accordance with the parameter and the messages.

Abstract: Systems and methods are described herein to automate managing of service layer operations comprised of multiple elementary operations and offloading the burden of performing such multi-step operations from a requesting entity to the service layer. A Request Abstraction Service (RAS) is described herein for the autonomous execution of such multi-step operations. Methods and apparatuses 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 requesting entities.

Abstract: A batch of CRUD operations can be coupled with the resource discovery operation and directly conducted on the matched resources, without initiating new CRUD requests. New functionality at the Originator and Receiver can differentiate the resources for which criteria matching is applied from the resources included in the discovery/filtering results. Enhanced functionality at the Originator and Receiver can combine discovery with RESTful operations targeting a resource set different than but related the discovered resources. Other enhancements may be used to request discovery of resources in a specified relationship to those matching a filter, or to request group formation based on the result.

Abstract: Internet of Things (IoT) configurable event and action sequencing mechanisms for interconnecting various IoT events together to achieve an event and action sequencing process that may efficiently enable complex uses of the data available in IoT systems.

Abstract: An Authorization Verification Service (AVS) is disclosed that may be provided by an IoT/M2M service layer to registrants of the service layer for Dynamic Context Aware Authorization. The AVS may allow the IoT/M2M service layer entities to define dynamic limits for authorizing access to services or data. The limits may be set, for example, in terms of the number of allowed accesses. When an IoT/M2M registrant makes a request for data or services for which it has dynamic context aware authorization, the AVS may maintain records of the remaining accesses available.

Abstract: Disclosed are methods and systems for Semantics Node functions which provide semantics support in machine-to-machine systems. In an example, a Semantic node may manage semantics resources capable of being discovered, retrieved, or validated by other devices. In another example, the Semantics Node may be discovered by other nodes, and semantics resources may be discovered with subscription mechanisms.

Abstract: A service layer may be configured to offload requests and responses on behalf of IoT applications in order to reduce congestion and/or overhead on underlying networks, applications and devices. The service layer may be enabled with the capability to script and generate IoT application requests such that the requests can be initiated by the service layer without the IoT application having to re-issue the same request repeatedly (e.g., to periodically retrieve a sensor reading). This scripting may be initiated by request originators. The service layer may support the capability to monitor and detect repetitive request patterns and initiate the scripting itself. This scripting functionality may enable the service layer to perform operations on behalf of IoT applications. As a result, the messaging overhead on IoT applications and devices as well as underlying networks can be minimized.

Abstract: Systems and methods are described herein to automate managing of service layer operations comprised of multiple elementary operations and offloading the burden of performing such multi-step operations from a requesting entity to the service layer. A Request Abstraction Service (RAS) is described herein for the autonomous execution of such multi-step operations. Methods and apparatuses 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 requesting entities.

Abstract: Methods, system, and apparatuses may support end-to-end (E2E) quality of service (QoS) through the use of service layer (SL) sessions. For example, an application can communicate with a targeted device based on application specified schedule, latency, jitter, error rate, throughput, level of security, and cost requirements.

Abstract: Internet of Things (IoT) configurable event and action sequencing mechanisms for interconnecting various IoT events together to achieve an event and action sequencing process that may efficiently enable complex uses of the data available in IoT systems.

Abstract: A registrar entity, such as a service layer gateway, obtains the service capabilities requirements or preferences of a new registree entity, such as an application, and only accepts a registration of the registree if the registrar has sufficient remaining service capacities to meet the service capabilities requirements or preferences of the registree entity while ensuring that the provision of support to existing registree entities is not impacted. If the registrar lacks the capabilities to satisfy the requirements or preferences, it may contact a server to identify another registrar which has the capabilities. Updates to requirements or preference may originate at any node, e.g., at a user equipment device or a service.

Abstract: An M2M Service Layer is expanded to access the services of third parties and exchange data with these third parties. The M2M Service Layer is then able to act as a proxy between M2M Devices and the third party services. The M2M Service Layer is able to present a single/consistent interface, or API, to the M2M Device and hide the details of the third party service provider from the M2M Device.

Abstract: Systems and methods are described herein to automate managing of service layer operations comprised of multiple elementary operations and offloading the burden of performing such multi-step operations from a requesting entity to the service layer. A Request Abstraction Service (RAS) is described herein for the autonomous execution of such multi-step operations. Methods and apparatuses 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 requesting entities.

Abstract: IoT service layer capabilities may be employed to automate and simplify the service enrollment process for IoT service subscribers/enrollees. These capabilities enable virtualization of a service subscriber and the physical IoT devices, applications, data and authorized users of the subscriber into a software profile that is representative of the subscriber. Once virtualized, a service subscriber may then delegate the complexities and burden of service enrollment to an automated IoT service enrollment software function.

Abstract: An apparatus can monitor interactions between IoT devices and IoT applications. Based on the monitoring, the apparatus may identify an interaction between a given IoT device and a given IoT application that can be adjusted. In an example, the apparatus may generate a recommendation or instruction in response to identifying the interaction. A first instruction may indicate a change in behavior for one of the IoT device or the IoT application. The apparatus may send the instruction to the one of the IoT device or the IoT application, for example, so as to cause the one of the IoT device or the IoT application to change the respective behavior, thereby adjusting the interaction between the IoT device and the IoT application.

Abstract: Enhancements to the device management functionality within service layer architecture of a Gateway node are described. The SL application registration procedure can be enhanced for devices in support of device management. Functionality can be added to the service layer to initiate automated request notification for DM purposes. Lightweight SL Transport Protocol bindings can support sending multiple DM commands called DM Action Scripts with a specific focus on the Constrained Application Protocol (CoAP) Protocol.

Abstract: Methods, systems, and devices may be used to support freshness-based processing of requests. Freshness-based processing may involve the service layer examining the age of stored content (e.g., resource representation) that it hosts and determining whether it is fresh enough to satisfy a retrieve or discovery request with a specified freshness requirement. If not fresh, the service layer can contact an application to refresh the content. In addition, freshness-based processing can also involve the service layer examining the semantic state of a command oriented update request to determine whether its state is fresh or not with respect to prior commands processed by the service layer. For example, the service layer may compare stored content associated with controlling a particular application (e.g. door is locked) and against the semantic content of an update request (e.g., unlock door) to determine whether it is the same (e.g., stale) or not (e.g., fresh).

Abstract: Methods, system, and apparatuses may support end-to-end (E2E) quality of service (QoS) through the use of service layer (SL) sessions. For example, an application can communicate with a targeted device based on application specified schedule, latency, jitter, error rate, throughput, level of security, and cost requirements.

Abstract: Profile based services and content can assist with the backward and forward compatibility of conventional service layers or the like. Using a profile to manage content and access to services offered may reduce the overhead or processing associated with providing those value added services by service layers.