Convida Wireless, LLC

Methods, devices, and systems are disclosed for an M2M Interest Function. An M2M Interest Function may receive requests from users to publish the users' personal interests in particular data identify relationships and patterns in the data. Associated data may then be stored in a single best location for such data based on various criteria rather than on separate M2M Gateways or M2M Servers. This location may be provided to users interested in such data. Relationship and association data may be provided to M2M gateways.

Current discovery mechanisms lack capabilities, such as capabilities related to permissions associated with a given registrant for example. In an example embodiment, a registrant of a service layer can communicate with a network node that hosts the service layer. The network node may receive a discovery request for a resource from the registrant. The discovery may request include various context. For example, the context of the discovery request may be indicative of an operation that the registrant intends to perform on the resource, a role that the registrant intends to assume if the registrant accesses the resource, a location in which the registrant intends to access the resource, or a subscription plan that the registrant intends to use if the registrant accesses the resource. Based on the context of the discovery request, the network node may determine whether one or more resources at the service layer satisfy the discovery request.

A labeled data generation service provides an Internet-of-Things (IoT) system with a capability whereby users may configure how the system gathers, processes, and generates labeled data instances by: collecting and processing the data into a format required by supervised learning algorithms; generating expected outputs from data available in the IoT system; supporting the linking of collected inputs with generated expected outputs; forming labeled data instances; cleaning the labeled data set appropriately; sending the labeled data set to target nodes; and/or communicating with target nodes regarding improving the data processing and labeling processes, as required.

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.

An extensible policy-based service layer dynamic authorization framework can allow a service layer to determine whether or not to grant or deny a registrant access to a resource or service hosted by the service layer for which the registrant currently lacks the proper privileges to access. This method can also enable a service layer to dynamically update its statically configured authorization privileges (by leveraging its dynamic authorization results) such that future requests from the same registrant and to the same resource and service do not require dynamic authorization to be performed.

Methods, systems, and devices may support capabilities of user equipment which may be part of an application programming interface (API) exposure system or deployment, such as common API framework (CAPIF).

Systems and methods are introduced to enable cross-domain discovery. Systems and methods are also introduced to create representations of resources and information discovered from cross-domain discovery.

Methods, devices, and systems for migration or sharing of existing M2M service layer sessions are disclosed. In one embodiment, a Session Migration and Sharing Function (SMSF) performs the migration or sharing of a M2M service layer session. Various forms of service layer session context may be used to enable the migration and sharing of M2M service layer sessions.

Systems and methods are described to automate managing of relationships between IoT entities (e.g., devices, apps, users) and offloading the burden of managing these relationships from users. A Relationship Management Service (RM Service) is described herein for the autonomous establishment, modification, and tear-down of relationships between IoT entities.

A lightweight and extensible information model for machine-to-machine systems is disclosed. A service layer information management architecture uses three categories of atomic objects, subjects, actions, and descriptions. Information for use within the model is built using the atomic information objects. Application programming interfaces are used to perform operations and information processing by different nodes. Common service functions are used in the model as instances of a generic common service information model.