Patent Description:
Accordingly, there is a need for improved M2M/IoT product management techniques.

<CIT> discusses automatic provisioning of services to network-connected devices. <CIT> discusses automatic provisioning of IoT devices.

Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

Methods and apparatuses are described herein for a service layer (SL) capability to assist device users and manufacturers in the maintenance and management of their loT devices. The methods and apparatuses described herein enable device users to keep their devices online, fully functional and secure without having to interact directly with each manufacturer. The methods and apparatuses described herein enable device manufacturers to obtain device information and to fix defects of deployed devices without direct interaction with each user.

APM Service enabled device enrollment and registration procedures are described herein. A manufacturer registration procedure is described herein for a manufacturer to enable its products to be deployed within the SL. An enhanced SL enrollment procedure is described herein to enable a SL user to use its Point of Contact Device/Application to keep their devices fully compatible and securely connected, which will prevent security threats for the user and other devices in the system. An enhanced SL registration procedure is described herein to enable an loT device manufacturer to obtain the current deployment and configuration information about its devices deployed in the field without direct interaction with individual device users. An APM Service enabled automated troubleshooting procedure is described herein to enable loT device users to have their devices troubleshooted automatically by the manufacturer when they encounter an error. An APM Service enabled automated SL recall procedure is described herein to enable loT manufacturers to indirectly contact and notify the users of devices deployed in the field and remotely fix firmware or software defects of deployed devices without direct interaction with individual device users.

The following is a list of abbreviations of terms as used herein:.

The following is a list of definitions of terms as used herein:.

An M2M/IoT Service Layer (SL) comprises technology targeted towards providing value-added services for M2M/IoT devices and applications. M2M/IoT SLs are being developed to address the challenges associated with the integration of M2M/IoT devices and applications into deployments with the Internet/Web, cellular networks, enterprise networks, and home network networks.

An M2M/IoT SL may provide applications and devices access to a collection of M2M/IoT capabilities. Examples include but are not limited to security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities are made available to applications via APIs, which make use of message formats, resource structures, and resource representations supported by the M2M/IoT SL.

<FIG> is a diagram of an example protocol stack <NUM> supporting an M2M/IoT service layer. From a protocol stack perspective, middleware service layers are typically layered on top of existing network protocol stacks and provide value added services to client applications as well as other services. Hence, service layers are often categorized as "middleware" service layers. For example, <FIG> shows a service layer <NUM> located in between application protocols <NUM> and applications <NUM>. As shown in the example of <FIG>, the protocol stack <NUM> may include an applications layer <NUM>, application protocols layer <NUM> (e.g. HTTP, COAP, MQTT), transport protocols layer <NUM> (e.g. TCP or UDP), network protocols layer <NUM> (e.g. IPv4 or IPv6) and access network protocols layer <NUM> (e.g. Ethernet, Cellular, Wi-Fi) in addition to the service layer <NUM>. Service layer <NUM> instances may be deployed on various network nodes (gateways and servers) and may provide value-added services to network applications, device applications, and to the network nodes themselves.

The oneM2M standard defines a M2M/IoT SL. The purpose of the SL is to provide "horizontal" services that can be utilized by different "vertical" M2M/IoT systems and applications, such as e-Health, fleet management, and smart homes.

<FIG> is a diagram of an example oneM2M architecture <NUM>. The architecture <NUM> of the oneM2M SL may comprise a Common Service Entity (CSE) that may support four reference points. The Mca reference point may interface with the 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 in a different service provider domain. The Mcn reference point may interface with the underlying network service entity (NSE). An NSE may provide underlying network services to the CSEs, such as device management, location services and device triggering. As shown in the example of <FIG>, in the field domain <NUM>, AE <NUM> interfaces with the Mca reference point <NUM> and Mca reference point <NUM>. CSE <NUM> interfaces with Mcc reference point <NUM>, which interfaces with CSE <NUM> in the infrastructure domain <NUM>. NSE <NUM> interfaces with Mcn reference point <NUM>. In the infrastructure domain <NUM>, AE <NUM> interfaces with the Mca reference point <NUM>. CSE <NUM> interfaces with Mcc' reference point <NUM> to the infrastructure domain of another service provider <NUM>. NSE <NUM> interfaces with Mcn reference point <NUM>.

A CSE may comprise multiple logical functions referred to as Common Service Functions (CSFs). CSFs include but are not limited to discovery and data management & repository.

<FIG> is a diagram of an example set of common service functions (CSF) <NUM> supported in oneM2M. The service layer is enabled functionally by CSFs. A group of CSFs may be instantiated as a group on Common Services Entities (CSEs) <NUM> as shown in <FIG>. Examples of CSFs and their functionality may include the following:.

The oneM2M architecture may provide for a CSE <NUM> to interface through the Mca reference point <NUM>, Mcc (and Mcc') reference point <NUM>, and Mcn reference point <NUM> to other entities including but not limited to: a AEs <NUM>; other CSEs; and a Network Service Entity (NSE) <NUM> (i.e. the underlying network).

The oneM2M architecture is a distributed architecture and supports deploying M2M/IoT services in a distributed manner across the following types of Nodes:.

<FIG> is a diagram of an example distributive IoT system <NUM> such as oneM2M, which may have a distributed architecture. The possible configurations of interconnecting the various entities supported within the oneM2M system are illustrated in <FIG>. The system may comprise a plurality of IoT servers (also referred to herein as CSEs) that may be interconnected and may manage a plurality of IoT devices. The term IoT servers used herein may refer to cloud servers, edge gateways, or home gateways (i.e. any entity that offers IoT services within an IoT system). The architecture may be divided into two main domains: the infrastructure domain <NUM> and field domain <NUM>. The infrastructure domain <NUM> may comprise cloud servers that serve as the main master controller of the system <NUM>, which is represented in <FIG> as IN-CSE 403a in the Infrastructure Node 403b in <FIG>. The field domain may comprise field deployed IoT servers located in various locations including but not limited to a factory, an office building, or a home. These servers are represented in <FIG> as MN-CSE 404a in Middle Node 404b and MN-CSE 405a in Middle Node 405b. The field domain <NUM> may also comprise mobile IoT servers running on mobile devices such as, for example, service trucks or mobile phones. These mobile devices are represented in <FIG> as ASN-CSE 406a in ASN 406b and ASN-CSE 407a in ASN 407b. IoT devices are represented in <FIG> as ADNs 408a and 408b and NoDNs 409a, 409c, 409d, 409f, and <NUM> with each node communicating to one of the CSEs in the system.

oneM2M service layer registration is described herein. An AE on an ASN, an MN or an IN may perform registration locally with the corresponding CSE in order to use M2M/IoT services offered by that CSE. An AE on an ADN may perform registration with the CSE on an MN or an IN in order to use M2M/IoT services offered by that CSE. An IN-AE may perform registration with the corresponding CSE on an IN in order to use M2M/IoT services offered by that IN CSE.

The CSE on an ASN may perform registration with the CSE in the MN in order to be able to use M2M/IoT Services offered by the CSE in the MN. As a result of successful ASN-CSE registration with the MN-CSE, the CSEs on the ASN and the MN may establish a relationship allowing them to exchange information.

The CSE on an MN may perform registration with the CSE of another MN in order to be able to use M2M/IoT Services offered by the CSE in the other MN. As a result of successful MN-CSE registration with the other MN-CSE, the CSEs on the MNs may establish a relationship allowing them to exchange information.

The CSE on an ASN or on an MN may perform registration with the CSE in the IN in order to be able to use M2M/IoT Services offered by the CSE in the IN. As a result of successful ASN/MN registration with the IN-CSE, the CSEs on ASN/MN and IN may establish a relationship allowing them to exchange information.

In the above described cases, the AE or CSE performing the registration may be referred to as a registree AE or registree CSE. The CSE on which the AE/CSE is registering to may be referred to as the registrar CSE.

Following a successful registration of an AE to a CSE, the AE may be able to access, assuming access privilege is granted, the resources in all the CSEs that are potential targets of the request from the Registrar CSE. The following are some registration rules used in some systems:.

There is an explosive growth of IoT protocols, service providers and manufacturers in M2M/IoT ecosystems. A manufacturer may make IoT devices that support multiple loT standards and service providers, but the manufacturer may not have the capability to provide M2M/IoT service to users who purchase and use the device. On the other hand, a service provider may provide IoT services using one or multiple loT standards and may allow its user to use devices that are made by multiple manufacturers, but the service provider may not have the capability to design and make IoT devices. The fragmentation of IoT ecosystems as described above brings numerous challenges for IoT users, service providers and manufacturers.

One challenge is that an IoT user usually has little knowledge about IoT protocols and devices. When a user wants to purchase a smart home device from a seller that is not his IoT service provider, the user may not know whether the device can be fully compatible with the services offered by his IoT service provider. In another example, when the user encounters an error while using the device, the service provider cannot provide diagnosis troubleshooting services since it did not design or build the device. The user has to contact the manufacturer and then solve the problem by themselves.

Another challenge is that for an IoT manufacturer, the manufacturer loses the control and contact to a device that it makes once the device is sold to a distributor. For example, the manufacturer does not know who is using the device unless the user manually registers the product by itself via the Internet or via the post mail service. Moreover, the manufacturer may not know the present information about its products, for example, whether a product is in use or not. When the manufacturer finds a defect in the software or hardware of a particular product model, the manufacturer cannot easily notify the current users or remotely fix the defect automatically.

For an IoT service provider, when a user attempts to enroll a new IoT device that is manufactured by a third-party manufacturer, the service provider has limited knowledge about the device, and may not be able to provide the best service for the user. For example, the service provider cannot check the authenticity of the device in terms of whether the device is hacked, which may result in security threats for the user and other devices in the system. In another example, the device may be pre-installed with software or firmware that may not be fully compatible or support all features provided by the service provider's system.

There is an explosive growth of IoT deployments comprising various combinations of IoT devices built and sold by different manufacturers. For example, with the average home having increasing numbers of smart devices sold by different manufacturers, it is becoming increasingly difficult for the average home user to manage and maintain their smart home deployment. A home user may lack the due diligence and technical savviness to directly interface with device manufacturers to keep up with the proper maintenance upgrades (e.g. firmware upgrades, security patches, etc.) needed for proper and secure operation of each of its devices. Likewise, it is not uncommon for a manufacturer of IoT devices to lack the capability and expertise to maintain its customers IoT devices on their behalf. IoT Service Providers are well positioned to assist device users and manufacturers in the maintenance and management of their IoT devices.

Methods and apparatuses are described herein for a service layer capability, which may be referred to herein as an automated product management (APM) service, to provide enhanced services for IoT device users and manufacturers.

For IoT device users, the APM may provide service capabilities including but not limited to the following, for IoT device users to keep their devices online, fully functional and secure without having to interact directly with each individual device manufacturer:.

For an IoT device manufacturer, the APM service may provide capabilities including but not limited to the following:.

Methods and apparatuses are described herein or an SL APM function to provide enhanced services for an IoT device user by proxying the management of the IoT device user's products on behalf of device manufacturers and device users. In one example, enrollment requests may be received from one or more IoT SL users to enroll their devices with a service provider's service layer. For each request, enrollment information such as make, model, and user's point-of-contact address for each device, may be stored within the service provider's service layer. A request may be sent to the manufacturer of the product including the user's requirements and the user's consent for the manufacturer to check/verify the authenticity of the product, and generating a customized firmware or software for the user's product. A request, may be sent, to configure the device based on the user's requirement and consent. A response may be sent, to the IoT SL user, indicating whether they can enroll a product or whether their device is ready to use. A request may be sent from an IoT SL user to diagnose or troubleshoot its device. A request may be sent to the corresponding device manufacturer providing necessary information and the user's consent and asking the manufacturer to perform operations on the device.

In another embodiment, a SL APM function may provide enhanced services for an IoT device manufacturer by proxying the management of IoT device user's products on behalf of device manufacturers and device users. A manufacturer registration request may be received that comprises information associated with products that the manufacturer requests the SL to assist in managing. The information may include but is not limited to make and model, ranges of device identifiers and firmware/software images. A request may be sent to a manufacturer associated with the product information associated with a new device that registers with the SL. A request may be received from a manufacturer to perform a specified operation (e.g. update the firmware) on a type of product. The request may comprise information such as product make and model and one or more desired operations to be performed on the product by the service layer. Enrollment information stored within the service layer may be accessed to determine which devices match the make and model specified by the manufacturer's request. A request may be sent to a user's point-of-contact address of each matching device asking for the user's consent to perform the specified operation. A response may be received from the user that grants or denies the manufacturer's request. Requests may be sent to perform specified operations on the subset of devices whose consent was obtained from device users. Responses may be received from devices regarding the status of whether an operation was successfully performed or not on the devices. One or more responses may be sent to a device manufacturer containing status information of the devices that an operation was successfully or unsuccessfully performed upon. The status information such as manufacturer device identifiers or the reason of the failure may be included.

The APM service described herein may provide enhanced services for IoT device users and manufacturers. The APM Service may provide capabilities for IoT device users to keep their devices online, fully functional, and secure without having to interact directly with each individual device manufacturer. The APM Service may also provide capabilities for IoT device manufacturers to obtain device information and to fix defects of a deployed device without direct interaction with individual device users.

<FIG> (described hereinafter) illustrate various embodiments associated with the framework for an APM service. In these figures, various steps or operations are shown being performed by one or more nodes, apparatuses, devices, servers, functions, or networks. For example, the apparatuses may operate singly or in combination with each other to effect the methods described herein. As used herein, the terms apparatus, network apparatus, node, server, device, entity, network function, and network node may be used interchangeably. It is understood that the nodes, devices, servers, functions, or networks illustrated in these figures may represent logical entities in a communication network and may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of, and executing on a processor of, a node of such network, which may comprise one of the architectures illustrated in <FIG> or <FIG> described below. That is, the methods illustrated in <FIG> may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of a network node, such as, for example, the node or computer system illustrated in <FIG> or <FIG>, which may store computer-executable instructions, when executed by a processor of the node, that perform the steps illustrated in the figures and described herein. It is also understood that any transmitting and receiving steps illustrated in these figures may be performed by communication circuitry (e.g., circuitry <NUM> or <NUM> of <FIG> and <FIG>, respectively) of the node under control of the processor of the node and the computer-executable instructions (e.g., software) that it executes. It is further understood that the nodes, devices, and functions described herein may be implemented as virtualized network functions.

<FIG> is a diagram of a high-level example method <NUM> performed by an APM service, which may be used in any of the embodiments described herein. An APM service <NUM> may be deployed as a function within an IoT service layer <NUM> that is hosted on an IoT service layer Node <NUM>, e.g. IoT Server, Gateway, Fog Node, Edge Node, as shown in <FIG>. The APM Service <NUM> may also be deployed as its own independent service as well (not shown in <FIG>). An APM service enabled SL enrollment and registration procedures is described herein. Next an APM Service enabled manufacturer registration procedure is described. During the manufacturer registration procedure, the SL may create resources to store information associated with the manufacturer, e.g. a list of products and features made by the manufacturer that may be deployed within the system, the parameter for generating customized software and/or firmware, SL subscription information of deployed devices and SL interface to check device authenticity, diagnose and troubleshoot.

Referring to <FIG>, an IoT manufacturer <NUM> may perform registration and resource creation with an IoT service layer node <NUM> in the IoT service layer <NUM> providing an APM service <NUM> (step <NUM>). An IoT user's point of contact (PoC) <NUM> via the IoT service layer <NUM> and loT entity <NUM> may perform enhanced SL enrollment and registration comprising product registration, authentication, and configuration (step <NUM>). SL automated troubleshooting services may be performed (step <NUM>). SL automated manufacturer recall services (step <NUM>).

The APM Service enabled device enrolment and registration procedures described herein may enable a SL user to use a PoC, which are the devices/applications employed by users to interact with SL to keep their devices fully compatible and securely connected and that do not introduce security threats for the user and other devices in the system. The procedures may also enable an IoT device manufacturer to obtain the current deployment and configuration information about its devices deployed in the field without direct interaction with individual device users. In addition, an APM Service enabled automated troubleshooting procedure described herein may enable IoT device users to have their devices troubleshooted automatically by the manufacturer when they encounter an error. In addition, an APM Service enabled automated SL recall procedure described herein may enable IoT manufacturers to indirectly contact and notify the users of devices deployed in the field and remotely fix firmware or software defects of deployed devices without direct interaction with individual device users.

Several APM Service enabled SL enrollment and registration procedures are described herein. First, a manufacturer registration procedure is proposed for a manufacturer to enable its products to be deployed within the SL. During the manufacturer registration procedure, the SL may create resources to store information associated with the manufacturer, e.g. a list of products and features made by the manufacturer that may be deployed within the system, the parameters for generating customized software and/or firmware, SL subscription information of deployed devices, and SL interface information for verifying device authenticity and troubleshooting devices. Second, an enhanced SL enrolment procedure is proposed to enable a SL user to use its Point of Contact, which are the devices or applications that a user may use to interact with SL, to keep their devices fully compatible and securely connected, which may prevent security threats for the user and other devices in the system. Third, an enhanced SL registration procedure is proposed to enable an IoT device manufacturer to obtain the current deployment and configuration information about its devices deployed in the field without direct interaction with individual device users.

<FIG> is a diagram of an example APM Service enabled manufacturer registration procedure <NUM> for a manufacturer to enable its products to be deployed within the SL in accordance with one embodiment, which may be used in combination with any of the embodiments described herein. During the manufacturer registration procedure, the SL may create resources to store information associated with the manufacturer, e.g., a list of products and features made by the manufacturer that may be deployed within the system, the parameters for generating customized software and/or firmware, SL subscription information about deployed devices, and SL interfaces for device authenticity verification and troubleshooting.

Referring to <FIG>, an IoT manufacturer application <NUM> may send a manufacturer registration request to the IoT SL <NUM>, hosted on an IoT service layer node (e.g. IoT Server, Gateway, Fog Node, Edge Node), that has deployed an APM service <NUM> as a function with the IoT SL <NUM>, the request may comprise information as listed in Table <NUM> below (step <NUM>). The IoT SL <NUM> may create resources associated with the manufacturer that comprise information as shown in Table <NUM> (step <NUM>). The IoT SL <NUM> may assign a SL ID to the manufacturer if the manufacturer ID is not included in the request. The IoT SL <NUM> may send a manufacturer registration response to the IoT manufacturer application <NUM> to confirm that the resources are created (step <NUM>).

After the registration, the manufacturer may also create a subscription to receive information about deployed devices that it produced. The SL may then create a resource subscription for the manufacturer to send it notifications, which may comprise information about devices that it produced that may be enrolled and registered to the system. The deployed device information may include the SL ID of the device, the model number, and the serial number of the device when it is shipped from the manufacturer.

<FIG> is a diagram of an APM Service enabled SL enrollment procedure <NUM> in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The procedure <NUM> of <FIG> may enable a SL user to use its PoC to enroll a new device and determine whether the device is fully compatible, securely connected, and its authenticity is verified, which may help prevent security threats for the user and other devices in the system. The procedure <NUM> of <FIG> also may enable a SL user to know whether a device can be deployed to fulfill the requirements.

Referring to <FIG>, the IoT manufacturer <NUM> may have registered its products with, for example service layer A <NUM> deploying an APM service <NUM> and service layer B <NUM> deploying APM service <NUM>, using the method described above (step <NUM>).

The SL user (i.e., user's PoC <NUM>) may send a request to its SL (i.e. SL A <NUM>) to enroll a new device to fulfill their requirement, e.g. the required SL protocol and features such as notification, data repository, device management, etc (step <NUM>). The request may comprise information as shown in Table <NUM>. The user may obtain the information in Table <NUM> from the printed text or QR code on IoT device <NUM>, device package and/or device description found on manufacturer's website. This information may be shared with the SL using the user's PoC. The user may also obtain the information by communicating to the IoT device <NUM> using the user's PoC <NUM>. The user may also provide its consent to allow the SL to communicate and share information about the user and/or IoT device <NUM> with the device manufacturer on the user's behalf. This consent information may specify a list of information that the SL is allowed or not allowed to share with the manufacturer.

SL A <NUM> may extract information from the enrollment request (step <NUM>). If the manufacturer has registered to SL A <NUM>, SL A <NUM> may check the APM resource in Table <NUM> that is associated with the manufacturer name in the request. Otherwise, SL A <NUM> may conditionally send a request to the IoT manufacturer <NUM> if given proper consent by the user. The request may be sent via the manufacturer interface to trigger the manufacturer registration procedure as described above. The request may comprise the SL protocol, e.g. oneM2M, which SL A <NUM> may have employed. If only product model information and required features are provided along with manufacturer name, SL A <NUM> may check the supported products and supported features in the APM resource associated with the manufacturer, and may send an SL device enrollment response to the User's PoC <NUM> about whether the IoT device <NUM> can support the SL features that the user required as shown in step <NUM>. Otherwise, SL A <NUM> may send a SL Device checkup request to the manufacturer to make sure the IoT device <NUM> to be enrolled is fully compatible, securely connected and authentic, which may prevent security threats for the user and other devices in the system as described in step <NUM>.

SL A <NUM> may send a SL Device checkup request to the manufacturer (step <NUM>). The request may comprise a serial number and network address of the IoT device <NUM>, required SL features that the IoT device <NUM> is required to support ,and other information listed in Table <NUM> below.

The IoT manufacturer <NUM> may extract information from the request (step <NUM>). Based on the serial number contained in the request and product management information stored at the manufacturer as shown in Table <NUM>, if the manufacturer finds the IoT device <NUM> has enrolled and registered with another SL, e.g. SL B <NUM>, the manufacturer may send a request to report this information to SL B <NUM> in step <NUM>. In the request, the manufacturer may include the information listed in Table <NUM> and may indicate that the IoT device <NUM> plans to enroll and register with another SL. Otherwise, the IoT manufacturer <NUM> may start a device checkup procedure as described in step <NUM>.

SL B <NUM> may check and/or update the SL enrollment information associated with the loT device <NUM>, and SL B <NUM> may send a response back to the manufacturer (step <NUM>). In the response, SL B <NUM> may indicate whether to allow the IoT device <NUM> to enroll in another SL. If SL B <NUM> allows the IoT device <NUM> to enroll in another SL, it may remove information associated with the IoT device <NUM> after the IoT device <NUM> is enrolled in SL A <NUM>. In an alternative, SL B <NUM> may indicate in the response it has notified the previous user, and/or obtain the consent whether the IoT device <NUM> is allowed to enroll in another SL.

If the IoT device <NUM> did not enroll and register with another SL, or SL B allowed the IoT device <NUM> to enroll in another SL, the IoT manufacturer <NUM> may starts a device checkup procedure (step <NUM>). The IoT manufacturer <NUM> may generate a software or firmware for the IoT device <NUM> based on required features and the protocol that SL A <NUM> uses, and then may update the software and/or firmware on the IoT device <NUM> to make sure the IoT device <NUM> is fully compatible, securely connected, and authenticated as described in steps <NUM> and <NUM>. Before the update, the IoT manufacturer <NUM> may also send a request to retrieve the software and/or firmware information to decide whether a software and/or firmware update is required. Alternatively, the IoT manufacturer <NUM> may perform the software and/or firmware update of the IoT device <NUM> indirectly via functionality supported within SL A <NUM> and/or SL B <NUM>.

The IoT manufacturer <NUM> may send a request to check or update information on the IoT device <NUM>, e.g. software and firmware (step <NUM>). Alternatively, the manufacturer may perform this check indirectly via functionality supported within SL A <NUM> and/or SL B <NUM>.

The IoT device <NUM> may send a response with device information and/or the confirmation of device update (step <NUM>). Alternatively, the IoT device <NUM> may send this information via functionality supported within SL A <NUM> and/or SL B <NUM>.

The IoT manufacturer <NUM> may send a SL Device checkup response to SL A <NUM> indicating whether the IoT device <NUM> can be enrolled in SL A <NUM> and is fully compatible and is authentic and securely connected with SL A <NUM> (step <NUM>).

SL A <NUM> may send a SL device enrollment response to the user PoC <NUM> indicating whether the enrollment is successful or the IoT device <NUM> can be enrolled to fulfill the requirements (step <NUM>).

<FIG> is a diagram of an enhanced APM Service enabled SL registration procedure <NUM> in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The procedure <NUM> of <FIG> may enable an IoT device manufacturer to obtain the current deployment and configuration information about its devices deployed in the field without direct interaction with individual device users.

Referring to <FIG>, the IoT Device <NUM> may send a device registration request to the IoT SL <NUM> deploying an APM service <NUM>, the request may comprise the Uniform Resource Identifier (URI) of the manufacturer's interface, manufacturer name, model, product serial number, or version of software or firmware (step <NUM>).

The IoT SL <NUM> may receive the device registration request and may process the request (step <NUM>). The IoT SL <NUM> may check the SL enrollment information associated with the loT device <NUM> as listed in Table <NUM>. The IoT SL <NUM> may update the device in the deployed devices in the APM resource associated with the IoT manufacturer <NUM>. Based on the IoT manufacturer's <NUM> resource subscription and the user's consent about information to share with the manufacture during the device enrollment, the SL may send a notification to the IoT manufacturer <NUM> comprising the information as listed in Table <NUM>.

The IoT SL <NUM> may send a notification to the manufacturer comprising the information as listed in Table <NUM> (step <NUM>).

The IoT manufacturer <NUM> may adds and/or update the product management information associated with the device (step <NUM>).

The IoT manufacturer <NUM> may send a response to SL to confirm the update about product management information (step <NUM>).

The IoT SL <NUM> may send a device registration response to the IoT device <NUM> to confirm the SL registration (step <NUM>).

The manufacturer may also do a device checkup as requested by the IoT SL <NUM> to make sure that the device is fully compatible, securely connected and authentic as described above.

<FIG> is a diagram of an APM Service Enabled SL Troubleshooting Service procedure <NUM> in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The procedure <NUM> of <FIG> may enable IoT device users to have their devices troubleshooted automatically by the manufacturer when they encounter an error. In the procedure <NUM>, when an IoT device user finds a device that is not working properly, they may use another SL device or application to send a troubleshooting request to the SL. The SL may also detect a problem with the IoT device. The SL may then conditionally obtain information from the device and may send this information to the manufacturer of the device on behalf of a user if the user has given its consent to the SL to do so. The SL may also grant access rights to the manufacturer to troubleshoot the device directly if the user has given its consent to do so. After the manufacturer may resolve the problem on the SL device, the SL may restore SL settings of the device, and then may notify the user the problem on the device is solved.

Referring to <FIG>, the user <NUM> (e.g., the user's PoC) may send a SL troubleshooting request to the IoT SL <NUM> deploying an APM service <NUM> to report a problem of the IoT device <NUM> (step <NUM>). The request may comprise the SL ID and/or the name of the IoT device <NUM>. The request may also comprise the error information, e.g. error code, shown on the IoT device <NUM>. The request may also comprise user consent information comprising information the IoT SL <NUM> may share with the manufacturer on behalf of the user <NUM>.

The IoT SL <NUM> may obtain the manufacturer and product information associated with the faulty IoT device <NUM> from Table <NUM> (step <NUM>). Based on the troubleshooting interface, the IoT SL <NUM> may then send a request to the faulty IoT device <NUM> to obtain information, device setting and troubleshooting information from the IoT device <NUM> if proper consent has been given by the user <NUM>. The request may also update the access control on the IoT device <NUM> to grant the IoT manufacturer <NUM> the access to troubleshoot the IoT device <NUM>. The access may be granted for a specified time period or may be only given for a specified type of operation.

The faulty IoT device <NUM> may send a response comprising the device settings and troubleshooting information (step <NUM>). The IoT device <NUM> may also confirm that the access control policy is updated, which allows the IoT manufacturer <NUM> to troubleshoot the IoT device <NUM> directly.

The IoT SL <NUM> may send a troubleshoot request to the IoT manufacturer <NUM> (step <NUM>). The request may comprise the troubleshooting information of the IoT device <NUM>, e.g. the error code, and the network address of the IoT device <NUM>.

Based on the troubleshooting information provided in the request, the IoT manufacturer <NUM> may start a device troubleshooting process, which for example, may comprise the manufacturer requesting the information about status of each component on the IoT device <NUM> (step <NUM>). In another example, the manufacturer may update the software and/or firmware on the IoT device <NUM>. The IoT manufacturer <NUM> may perform these operations by directly interacting with the IoT device <NUM>. Alternatively, the IoT manufacturer <NUM> may perform these interactions indirectly via the IoT SL <NUM> using the SL device management capabilities.

The IoT device <NUM> may send a response to the IoT manufacturer <NUM> about detailed troubleshooting information and confirm that the software and/or firmware update (step <NUM>). Alternatively, the device may relay this information back to the IoT manufacturer <NUM> via the IoT SL <NUM>.

Based on the response, the IoT manufacturer <NUM> may obtain the reason of the faulty device and fix the problem if possible, and the IoT manufacturer <NUM> may then send the troubleshoot response to the IoT SL <NUM> (step <NUM>). The troubleshoot response may include information about the reason of the problem, whether the problem is solved, and how the problem is solved or can be solved. For example, the IoT manufacturer <NUM> may suggest the user to push a button on the device or mail the product back to get a replacement. In another example, the manufacturer may indicate the problem has been solved via programing a new version of software or firmware.

In the case that manufacturer re-programs the software or firmware, the IoT SL <NUM> may initiate a procedure to restore the SL settings on the device (step <NUM>). For example, this procedure may comprise configuring the device based on the user's SL profile. The IoT SL <NUM> may also revoke the access control rights of the manufacturer now that the issue on the device has been resolved.

The IoT device <NUM> may send a response to the IoT SL <NUM> to confirm the settings and access control update (step <NUM>).

The IoT SL <NUM> may send a SL troubleshooting response to the user's PoC <NUM> notifying the user whether the problem is solved or how to solve the problem (step <NUM>).

<FIG> is a diagram of an APM service enabled SL recall service procedure <NUM> in accordance with another embodiment, which may be used in combination with any of the embodiments described herein. The procedure <NUM> of <FIG> may enable IoT manufacturers to indirectly contact and notify the users of devices deployed in the field and to remotely fix a firmware or software defect of deployed devices without direct interaction with individual device users. In the procedure, when the manufacturer detects a defect in its product, e.g. security loophole, the manufacturer may check the Product Management Information stored in Table <NUM> and find devices that have the defect, and may send a SL recall request to the SL of the device. When the SL receives the request, the SL may contact and notify the user of the device about the problem. Based on the user's SL settings and/or consent, the SL may grant the access control of the device to the manufacturer. The manufacturer may then remotely update the firmware of software. Alternatively, the manufacturer may leverage device management capabilities of the SL to initiate device management operations on the device to fix the issue. The manufacturer may indicate in the SL recall request that the defects in the product cannot be fixed or a product may be no longer supported. In this scenario, the SL may disable these devices in the system and notify the user of the device about the problem.

Referring to <FIG>, the IoT manufacturer <NUM> may send a SL manufacturer recall request comprising the information about devices that are affected by the recall (step <NUM>). The information may include but is not limited to: product serial number, product model number, software version and/or firmware version. In the recall request, the IoT manufacturer <NUM> may also propose the method for the recall. For example, if the recall is due to a hardware defect, the IoT manufacturer <NUM> may request the IoT SL <NUM> deploying an APM service <NUM> to deliver the recall notification to the user of the device, such that the user is aware of the problem and obtain a replacement device via mail or go to an authorized dealer. In another example, if the recall is due to a software and/or firmware problem, the IoT manufacturer <NUM> may request the IoT SL <NUM> to obtain the users' consent and update the software and/or firmware. In yet another example, the IoT manufacturer <NUM> may notify the SL about safety issues such that the SL can isolate the device or restrain the access control right of the device.

Based on the information in the request, the IoT SL <NUM> may obtain the affected devices by checking information stored in Table <NUM>, and the IoT SL <NUM> may then obtain the user information associated with the devices (step <NUM>). If the user has given the consent for the IoT SL <NUM> to handle any device recalls automatically, the IoT SL <NUM> can skip to step <NUM> to initiate the IoT SL <NUM> recall. Otherwise, the loT SL <NUM> may send a SL manufacturer recall notification to the PoC of the user <NUM>, who is using the device, to obtain the consent as described in step <NUM> to step <NUM>.

The IoT SL <NUM> may send a SL manufacturer recall notification to the PoC of the user <NUM> who is using the device (step <NUM>).

Based on the user's setting or response, the user's PoC <NUM> may interact with the user to obtain user's permission for the recall service, or approve the recall request on behalf of the user based on the user's setting (step <NUM>).

The user's PoC <NUM> may send a SL manufacturer recall notification response to confirm the delivery of the notification and indicates whether to approve the recall request (step <NUM>).

The IoT SL <NUM> may send a request to the IoT device <NUM> to obtain device settings and update the access control on the device to grant the manufacturer access to do the recalled service (step <NUM>). The access may be granted for a specified time period or may be only given for a specified type of operation.

The IoT device <NUM> may send a response comprising its device setting information (step <NUM>). The device may also confirm the access control policy is updated, which allows the manufacturer to program the device directly.

The IoT SL <NUM> may send a SL manufacturer recall response request to the manufacturer (step <NUM>). The request may comprise information about how to access the device, e.g. the network address of the device.

The IoT manufacturer <NUM> may start a device update procedure to update the device, e.g. updating software and firmware (step <NUM>).

The IoT device <NUM> may send a response to confirm the software and/or firmware update (step <NUM>).

The IoT manufacturer <NUM> may send a SL manufacturer recall completion message to notify the IoT SL <NUM> whether the recall service is completed (step <NUM>). The message may also include the information about the recall service, e.g. the new version number of software and/or firmware.

In the case that manufacturer re-programs the software or firmware, the IoT SL <NUM> may initiate a procedure to restore the SL setting on the IoT device <NUM> obtained from step <NUM> (step <NUM>). For example, this procedure may comprise configuring the device based on the user's SL profile. The IoT manufacturer <NUM> may also revoke the access control rights of the IoT manufacturer <NUM>. Based on the information in the SL manufacturer recall completion message, the IoT SL <NUM> may also update the information about the IoT device <NUM> and notify the user <NUM> for the completion of the recall service. If the IoT manufacturer <NUM> fails to complete the recall, IoT SL <NUM> can notify the user <NUM> about the problem such that the user <NUM> can obtain a replacement device via mail or go to an authorized dealer. At the same time, the IoT SL <NUM> can isolate the IoT device <NUM> or restrain the access control right of the IoT device <NUM>.

The IoT device <NUM> may send a response to the IoT SL <NUM> to confirm the setting and access control update (step <NUM>).

The IoT SL <NUM> may send a response to the IoT manufacturer <NUM> to confirm the receiving of the SL manufacturer recall completion message (step <NUM>).

oneM2M resource-oriented architecture (ROA) embodiments are described herein. oneM2M defines the capabilities supported by the oneM2M Service Layer. The oneM2M Service Layer may be instantiated as a CSE that comprises a set of CSFs. In one embodiment, the APM service described herein may be realized as a new CSF as shown in <FIG>. CSEs may communicate via the Mcc and Mcc' reference points to manage registration. AEs may communicate via the Mca reference point to manage registration.

<FIG> is a diagram of an example oneM2M service layer that supports a data brokerage CSF <NUM>. In the example of <FIG>, the CSFs may include the following: Application and Service Layer Management CSF <NUM>; Discovery CSF <NUM>; Registration CSF <NUM>; Communication Management/Delivery Handling CSF <NUM>; Group Management CSF <NUM>; Security CSF <NUM>; Data Management and Repository CSF <NUM>; Location CSF <NUM>; Service Charging & Accounting CSF <NUM>; Device Management CSF <NUM>; Network Service Exposure, Service Execution and Triggering CSF <NUM>; and Subscription and Notification CSF <NUM>. The example of <FIG> also shows a CSE <NUM> to interface through the Mca reference point <NUM>, Mcc (and Mcc') reference point <NUM>, and Mcn reference point <NUM> to other entities including but not limited to: an AE <NUM>; other CSEs; and an NSE <NUM> (i.e. the underlying network).

An Automated Product Management CSF <NUM> may be implemented as a CSF as shown in the example of <FIG>. This CSF may be hosted on various types of service layer nodes, such as IoT gateways and servers, and it may provide automated product services using resources hosted on that CSE <NUM>.

To support an APM service, new resources and attributes are proposed. In a oneM2M embodiment, the APM CSF can support a APM resource such as a <manufacturerManagment> resource. A <manufacturerManagment> resource can be a child resource of <remoteCSE> and <AE>. The <manufacturerManagment> resource may comprise the resource specific attributes specified in Table <NUM> below. The < manufacturerManagment > resource may contain the child resources specified in Table <NUM> below.

A new <supportedProducts> resource is introduced under <manufacturerManagment> resource to store information about products made by the manufacturer that can be deployed in SL and that the manufacturer is requesting that the SL help it manage. The < supportedProducts > resource may comprise the resource specific attributes specified in Table <NUM> below.

The new attributes of <serviceSubscribedNode> are proposed as highlighted in Table <NUM> below.

<FIG> is a diagram of an example user interface <NUM> that may be added to a M2M/IoT Server or on a user application to display product management information.

<FIG> is a diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system <NUM> in which one or more disclosed embodiments may be implemented. Generally, M2M technologies provide building blocks for the IoT/WoT, and any M2M device, M2M gateway or M2M service platform may be a component of the IoT/WoT as well as an IoT/WoT service layer, etc. Any of the devices, functions, nodes, or networks illustrated in any of <FIG> may comprise a node of a communication system such as the one illustrated in <FIG>.

As shown in <FIG>, the M2M/IoT/WoT communication system <NUM> includes a communication network <NUM>. The communication network <NUM> may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network <NUM> may comprise multiple access networks that provide content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network <NUM> may employ 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), and the like. Further, the communication network <NUM> may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

As shown in <FIG>, the M2M/ IoT/WoT communication system <NUM> may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain and Infrastructure Domain may both comprise a variety of different nodes (e.g., servers, gateways, devices, of the network. For example, the Field Domain may include M2M gateways <NUM> and terminal devices <NUM>. It will be appreciated that any number of M2M gateway devices <NUM> and M2M terminal devices <NUM> may be included in the M2M/ IoT/WoT communication system <NUM> as desired. Each of the M2M gateway devices <NUM> and M2M terminal devices <NUM> are configured to transmit and receive signals via the communication network <NUM> or direct radio link. A M2M gateway device <NUM> allows wireless M2M devices (e.g. cellular and non-cellular) as well as fixed network M2M devices (e.g., PLC) to communicate either through operator networks, such as the communication network <NUM> or direct radio link. For example, the M2M devices <NUM> may collect data and send the data, via the communication network <NUM> or direct radio link, to an M2M application <NUM> or M2M devices <NUM>. The M2M devices <NUM> may also receive data from the M2M application <NUM> or an M2M device <NUM>. Further, data and signals may be sent to and received from the M2M application <NUM> via an M2M service layer <NUM>, as described below. M2M devices <NUM> and gateways <NUM> may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio link, and wireline for example. 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 outlets.

Referring to <FIG>, the illustrated M2M service layer <NUM> in the field domain provides services for the M2M application <NUM>, M2M gateway devices <NUM>, and M2M terminal devices <NUM> and the communication network <NUM>. It will be understood that the M2M service layer <NUM> may communicate with any number of M2M applications, M2M gateway devices <NUM>, M2M terminal devices <NUM>, and communication networks <NUM> as desired. The M2M service layer <NUM> may be implemented by one or more servers, computers, or the like. The M2M service layer <NUM> provides service capabilities that apply to M2M terminal devices <NUM>, M2M gateway devices <NUM> and M2M applications <NUM>. The functions of the M2M service layer <NUM> may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc..

Similar to the illustrated M2M service layer <NUM>, there is the M2M service layer <NUM>' in the Infrastructure Domain. M2M service layer <NUM>' provides services for the M2M application <NUM>' and the underlying communication network <NUM>' in the infrastructure domain. M2M service layer <NUM>' also provides services for the M2M gateway devices <NUM> and M2M terminal devices <NUM> in the field domain. It will be understood that the M2M service layer <NUM>' may communicate with any number of M2M applications, M2M gateway devices and M2M terminal devices. The M2M service layer <NUM>' may interact with a service layer by a different service provider. The M2M service layer <NUM>' may be implemented by one or more servers, computers, virtual machines (e.g., cloud/compute/storage farms, etc.) or the like.

Still referring to <FIG>, the M2M service layer <NUM> and <NUM>' provide a core set of service delivery capabilities that diverse applications and verticals can leverage. These service capabilities enable M2M applications <NUM> and <NUM>' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service/device discovery, etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The service layer <NUM> and <NUM>' also enables M2M applications <NUM> and <NUM>' to communicate through various networks <NUM> and <NUM>' in connection with the services that the service layer <NUM> and <NUM>' provide.

The M2M applications <NUM> and <NUM>' may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, and other servers of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications <NUM> and <NUM>'.

Generally, a service layer (SL), such as the service layers <NUM> and <NUM>' illustrated in <FIG> and <FIG>, defines a software middleware layer that 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. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the service layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e. service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE), which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, the service layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied 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 a network, an instance of the service layer may be implemented in a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a service layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device, or the like) having the general architecture illustrated in <FIG> or <FIG> described below.

Further, the methods and functionalities 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, such as the above-described Network and Application Management Service for example.

<FIG> is a block diagram of an example hardware/software architecture of a node of a network, such as one of the nodes, devices, functions, or networks illustrated in <FIG>, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in <FIG> and <FIG>. As shown in <FIG>, the node <NUM> may include a processor <NUM>, a transceiver <NUM>, a transmit/receive element <NUM>, a speaker/microphone <NUM>, a keypad <NUM>, a display/touchpad <NUM>, non-removable memory <NUM>, removable memory <NUM>, a power source <NUM>, a global positioning system (GPS) chipset <NUM>, and other peripherals <NUM>. The node <NUM> may also include communication circuitry, such as a transceiver <NUM> and a transmit/receive element <NUM>. It will be appreciated that the node <NUM> may include any subcombination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the notifications and triggers related thereto described herein.

The processor <NUM> may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the node <NUM> to operate in a wireless environment. The processor <NUM> may perform application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or communications. The processor <NUM> may perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access-layer and/or application layer for example.

As shown in <FIG>, the processor <NUM> is coupled to its communication circuitry (e.g., transceiver <NUM> and transmit/receive element <NUM>). The processor <NUM>, through the execution of computer executable instructions, may control the communication circuitry in order to cause the node <NUM> to communicate with other nodes via the network to which it is connected. In particular, the processor <NUM> may control the communication circuitry in order to perform the transmitting and receiving steps described herein (e.g., in <FIG>) and in the claims.

The transmit/receive element <NUM> may be configured to transmit signals to, or receive signals from, other nodes, including M2M servers, gateways, devices, and the like. For example, in an embodiment, the transmit/receive element <NUM> may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element <NUM> may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. It will be appreciated that the transmit/receive element <NUM> may be configured to transmit and/or receive any combination of wireless or wired signals.

In addition, although the transmit/receive element <NUM> is depicted in <FIG> as a single element, the node <NUM> may include any number of transmit/receive elements <NUM>. More specifically, the node <NUM> may employ MIMO technology. Thus, in an embodiment, the node <NUM> may include two or more transmit/receive elements <NUM> (e.g., multiple antennas) for transmitting and receiving wireless signals.

As noted above, the node <NUM> may have multi-mode capabilities. Thus, the transceiver <NUM> may include multiple transceivers for enabling the node <NUM> to communicate via multiple RATs, such as UTRA and IEEE <NUM>, for example.

The processor <NUM> may access information from, and store data in, any type of suitable memory, such as the non-removable memory <NUM> and/or the removable memory <NUM>. In other embodiments, the processor <NUM> may access information from, and store data in, memory that is not physically located on the node <NUM>, such as on a server or a home computer. The processor <NUM> may be configured to control lighting patterns, images, or colors on the display or indicators <NUM> to reflect the status of a node or configure a node (e.g., nodes in <FIG>), and in particular underlying networks, applications, or other services in communication with the UE. The processor <NUM> may receive power from the power source <NUM>, and may be configured to distribute and/or control the power to the other components in the node <NUM>. The power source <NUM> may be any suitable device for powering the node <NUM>.

The processor <NUM> may also be coupled to the GPS chipset <NUM>, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the node <NUM>. It will be appreciated that the node <NUM> may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

The processor <NUM> may further be coupled to other peripherals <NUM>, 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 <NUM> may include various sensors such as an accelerometer, biometrics (e.g., fingerprint) sensors, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect devices, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

<FIG> is a block diagram of an exemplary computing system <NUM> which may also be used to implement one or more nodes of a network, such as nodes, devices, functions, or networks illustrated in <FIG>, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in <FIG> and <FIG>. Computing system <NUM> may comprise 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 central processing unit (CPU) <NUM> to cause computing system <NUM> to do work. In many known workstations, servers, and personal computers, central processing unit <NUM> is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit <NUM> may comprise multiple processors. Coprocessor <NUM> is an optional processor, distinct from main CPU <NUM>, which performs additional functions or assists CPU <NUM>. CPU <NUM> and/or coprocessor <NUM> may receive, generate, and process data related to the disclosed systems and methods for security protection.

In operation, CPU <NUM> fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus <NUM>. Such a system bus connects the components in computing system <NUM> and defines the medium for data exchange. System bus <NUM> typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus <NUM> is the PCI (Peripheral Component Interconnect) bus.

Memory devices coupled to system bus <NUM> include random access memory (RAM) <NUM> and read only memory (ROM) <NUM>. Such memories include circuitry that allows information to be stored and retrieved. ROMs <NUM> generally contain stored data that cannot easily be modified. Data stored in RAM <NUM> can be read or changed by CPU <NUM> or other hardware devices. Access to RAM <NUM> and/or ROM <NUM> may be controlled by memory controller <NUM>. Memory controller <NUM> may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller <NUM> may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

In addition, computing system <NUM> may contain peripherals controller <NUM> responsible for communicating instructions from CPU <NUM> to peripherals, such as printer <NUM>, keyboard <NUM>, mouse <NUM>, and disk drive <NUM>.

Display <NUM>, which is controlled by display controller <NUM>, is used to display visual output generated by computing system <NUM>. Such visual output may include text, graphics, animated graphics, and video. Display <NUM> may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller <NUM> includes electronic components required to generate a video signal that is sent to display <NUM>.

Further, computing system <NUM> may contain communication circuitry, such as for example a network adaptor <NUM> that may be used to connect computing system <NUM> to an external communications network, such as network <NUM> of <FIG> and <FIG>, to enable the computing system <NUM> to communicate with other nodes of the network. The communication circuitry, alone or in combination with the CPU <NUM>, may be used to perform the transmitting and receiving steps described herein (e.g., in <FIG>) and in the claims.

In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity.

Claim 1:
An apparatus comprising a processor, a memory, and communication circuitry, the apparatus being connected to a network via its communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to perform operations comprising:
receiving (<NUM>), from a second apparatus, at least one first request to enroll one or more third apparatuses with a service layer associated with the second apparatus, the service layer supporting service capabilities through a set of Application Programming Interfaces, APIs, wherein the at least one first request comprises user consent information specifying information associated with the one or more third apparatuses that the apparatus is allowed to share with a fourth apparatus;
determining, based on the user consent information provided in the at least one first request, a consent of a user of the one or more third apparatuses to share allowed information with the fourth apparatus associated with a manufacturer of the one or more third apparatuses;
sending (<NUM>), to the fourth apparatus and based on the determined consent, a second request for the fourth apparatus to verify authenticity of the one or more third apparatuses and to generate a customized firmware or software for the one or more third apparatuses, the customized firmware or software enabling the one or more third apparatuses to support one or more service layer features of the service layer associated with the second apparatus;
sending (<NUM>), as instructed by the fourth apparatus, to the one or more third apparatuses, a third request to configure the one or more third apparatuses with the generated customized firmware or software to make sure the devices are authenticated; receiving (<NUM>), from the fourth apparatus, a first response indicating that the one or more third apparatuses are authentic; and
sending (<NUM>), to the second apparatus, a response indicating whether the one or more third apparatuses have been enrolled with the service layer.