Patent Description:
The User Services Platform (USP) includes a network of USP endpoints, each including at least one of a controller and an agent, which allow applications to manipulate service elements that reflect some functionality exposed by a device. The manipulation of a service element is done through the exchange of USP messages using the USP protocol. Examples of network devices recognition and configuration are disclosed in the patent applications <CIT>, <CIT> and <CIT>.

The User Services Platform (USP) provides a mechanism for one or more agents at a USP endpoint to establish a trusted relationship with one or more controllers (Controller Trust) at other USP endpoints. Conventionally, however, the USP does not provide the ability for Internet-of-Things (IoT) service providers to offer IoT services (e.g., Home Automation, Home Security, or the like) to users/subscribers based on a particular device when the device is initially recognized by (or, alternatively, initially attached to) the service provider's network.

To provide this additional functionality, one or more example embodiments provide methods, apparatuses and/or computer-readable storage mediums for automated onboarding of services using the USP.

The scope of protection is defined in the appended claims.

Example embodiments will become more fully understood from the detailed description given herein below and the accompanying drawings, wherein like elements are represented by like reference numerals, which are given by way of illustration only and thus are not limiting of this disclosure.

Detailed illustrative embodiments are disclosed herein. However, specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments. The example embodiments may, however, be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.

Accordingly, while example embodiments are capable of various modifications and alternative forms, the embodiments are shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit example embodiments to the particular forms disclosed. Like numbers refer to like elements throughout the description of the figures.

While one or more example embodiments will be described from the perspective of controllers, agents, or other applicable electronic devices or endpoints, it will be understood that one or more example embodiments discussed herein may be performed by the one or more processors (or processing circuitry) at the applicable device or endpoint.

<FIG> is a block diagram illustrating a portion of an example User Services Platform (USP) network architecture.

As mentioned above, the USP network architecture includes a network of USP endpoints (e.g., at one or more connected devices), each of which includes at least one of a controller or an agent. An agent is a USP endpoint that exposes a service element to a controller at another connected device. A controller is a USP endpoint that manipulates service elements through an agent at another connected device. A service element is a general term referring to a set of Objects, sub-Objects, commands, events, and parameters that comprise a set of functionality that is manipulated by a controller on an agent. An agent's service elements are represented in a data model. A connected device refers to devices such as network connected customer premises equipment (CPE), consumer electronics, computing resources, or the like.

A USP endpoint can act as an agent or a controller. Controllers only send USP messages to agents, and agents only send USP messages to controllers. That is, for example, controllers communicate with agents, rather than other controllers, and agents communicate with controllers, rather than other agents. Thus, a USP endpoint in the USP platform may include both an agent and a controller such that the USP endpoint may communicate with both agents and controllers at other USP endpoint. As discussed herein, a USP endpoint may also be referred to as a USP endpoint device or a connected device.

A USP endpoint may communicate with other endpoints using one or more Message Transfer Protocols (MTP) that may or may not be secure.

A USP message refers to the contents of a USP layer communication including a message header and a message body. In addition to the information discussed herein, the message body may include, for example, a Request, Response or Error, and the message header may include elements that provide information regarding the message, such as an endpoint identifier of the sender and receiver, the message type, and message identification (Message ID) elements. A Message ID is an identifier used to associate a Response or Error with a Request.

Referring now to <FIG>, the portion of the USP network architecture includes a plurality of USP endpoints, each of which is illustrated as a separate device. The plurality of USP endpoints include: a user device <NUM>; an operations support system (OSS) service provider <NUM>; an administrative authority (also referred to as a USP administrative authority endpoint or endpoint device) <NUM>; a discovery authority (also referred to as a USP discovery authority endpoint or endpoint device) <NUM>; a home automation gateway <NUM>; and a connected device <NUM>. Each of the plurality of USP endpoints shown in <FIG> are configured to communicate and/or exchange USP messages with others of the USP endpoints either directly or indirectly via one or more networks. Although shown in <FIG> as separate connected devices, it should be understood that the plurality USP endpoints may be grouped together, and implemented on one or more computers or servers (e.g., via one or more virtual machines). Furthermore, the plurality of USP endpoints may alternatively be represented by the same USP endpoint.

In the example embodiment shown in <FIG>, the user device <NUM> includes a controller <NUM>; the administrative authority <NUM> includes an agent <NUM> and a controller <NUM>; the discovery authority <NUM> includes an agent <NUM> and a controller <NUM>; the home automation gateway <NUM> includes an agent <NUM> and a controller <NUM>; and the connected device <NUM> includes an agent <NUM>. However, it should be understood that each of the USP endpoints shown in <FIG> may act as both a controller and an agent as needed. Further, although discussed as "including," it should be understood that each of the USP endpoints may also be described as acting as at least one of an agent and a controller.

Still referring to <FIG>, the user device <NUM> may be an end user device such as a smartphone, computer, or the like, including the controller <NUM>. In one example, the user device <NUM> runs an application that enables a user/subscriber to control a service element at connected device <NUM> from within or outside of the local network to which the connected device <NUM> is attached.

The administrative authority <NUM> is a service provider management system that provides management functions similar to the TR-<NUM> Auto-Configuration Server (ACS) in order to configure and troubleshoot controllers and agents in the home network or domain. In at least one example embodiment, the administrative authority <NUM> maintains a catalog (e.g., an indexed and searchable database or repository) of services compatible with different types of IoT devices and associated information that includes the firmware or software modules required to support compatible services and/or collaborating devices. In addition, the administrative authority <NUM> orchestrates (e.g., directly or indirectly via another entity) advertisement and acceptance of a compatible service with the subscriber/user of a given connected device. The administrative authority <NUM> also orchestrates the deployment, installation and activation of compatible services on the necessary devices/hosts.

When the administrative authority <NUM> has completed the orchestration of compatible services with other collaborating devices, the administrative authority <NUM> instructs each of the collaborating devices involved with a compatible service to initiate an onboard request with any controllers that need to be involved in the compatible service. These controllers then inform the administrative authority <NUM> that the onboarding of the service and/or device has completed. In one example, the collaborating devices may include at least the home automation gateway <NUM>. However, example embodiments should not be limited to this example.

Still referring to <FIG>, the OSS service provider <NUM> is a set of one or more service provider management systems that provide management aspects to configure and troubleshoot services and network elements located within a service provider's network.

According to at least some example embodiments, the OSS service provider <NUM> interacts with the end user (e.g., via the user device <NUM>, a web portal, an application executed on an electronic device, or the like) to offer and accept offered services as well as coordinate various management systems to affect activation of the accepted services. The OSS service provider <NUM> also delegates some of the activities for setup and activation of the service to the administrative authority <NUM>.

The discovery authority <NUM> listens for newly added agents in the local network. In one example, the discovery authority <NUM> inspects the communication flows (e.g., USP Domain Name Service - Service Definition (DNS-SD) messages, Address Resolution Protocol (ARP) requests, Universal Plug and Play (UPnP), or the like) emitted from a device within the home network to determine if the communication pattern or information emitted by the device can be correlated to a catalog of known devices. If the device is recognized, then the discovery authority <NUM> informs the administrative authority <NUM> of the newly recognized device.

The discovery authority <NUM> maintains (or has access to, e.g., at the OSS service provider <NUM>) a catalog of device types provided by the service provider. This catalog may be in the form of an indexed database or repository configured to allow use of discovered and/or advertised information for newly recognized (e.g., added) device to identify the type of the device by matching the identity of the discovered device with a type of device stored in the catalog. In one example, the catalog may include an identity of an IoT device, manufacturer and manufacturer's product class (model number) of the device, and the type of IoT device.

Although the discovery authority <NUM> is shown as a separate device, example embodiments should not be limited to this example. Rather, the functionality of the discovery authority <NUM> may reside in, for example, a home gateway provided by a service provider.

The home automation gateway <NUM> is a central hub from which a home automation system is controlled through a user interface that interacts with the user device <NUM>. According to one or more example embodiments, the user interface may be provided by an application running on the user device <NUM>, such as a smartphone or other electronic device.

In the example embodiment shown in <FIG>, the OSS service provider <NUM> and the administrative authority <NUM> reside in the cloud, whereas the discovery authority <NUM>, the home automation gateway <NUM> and the connected device <NUM> reside within a local network (e.g., a local area network (LAN) or wireless LAN within a home or office). As discussed herein, the local network may also be referred to as a home network. The components residing on one or more servers in the cloud may communicate with the components residing in the local network via, for example, the Internet. The user device <NUM> may communicate with the components in the cloud and those connected to the local network via the Internet as well. Although illustrated outside the local network, the user device <NUM> may also reside within the local network. Example embodiments should not, however, be limited to the configuration of the network architecture shown in <FIG>.

Still referring to <FIG>, the connected device <NUM> may be an IoT device including one or more service elements. In one example, the connected device <NUM> may be an Internet Protocol (IP)-based camera, a smart television, a home automation or security devices (e.g., light switches, electrical outlets, thermostats, open/closed window sensors, or the like), a kitchen appliance (e.g., refrigerator), or the like.

Example operation and interaction of the USP endpoints shown in <FIG> will be discussed in more detail with regard to <FIG>.

<FIG> is a signal flow diagram illustrating an example embodiment of a method for automated onboarding of services in the USP architecture shown in <FIG>.

Referring to <FIG>, at operation S202, the agent <NUM> at the connected device <NUM> advertises its presence on the home network. In at least one example, the connected device <NUM> may advertise its presence upon initial connection to the local network.

In the example shown in <FIG>, the agent <NUM> at the connected device <NUM> advertises its presence by outputting a DNS-SD message (advertise:dns-sd;arp;neighbor-discovery), which is received by the listening controller <NUM> at the discovery authority <NUM>. The DNS-SD message includes identification information and communication protocol information for the agent <NUM> at the connected device <NUM>, which enables the controller <NUM> at the discovery authority <NUM> to identify the type of device for the connected device <NUM>. The identification information may include an identity of the connected device (or service element residing thereon), manufacturer and manufacturer's product class (model number), and the type of service element at the connected device <NUM>. In the example shown in <FIG>, the agent <NUM> at the connected device <NUM> utilizes the DNS-SD protocol to advertise its existence to the controller <NUM> at the discovery authority <NUM>. However, example embodiments should not be limited to this example. Rather, other Neighbor Discovery protocols such as ARP, IPv6 Neighbor Discovery, or the like may be used.

In response to receiving the DNS-SD message, at operation S203 the discovery authority <NUM> interrogates (e.g., searches) the catalog of devices for which services may be offered to identify whether there are services to be offered in connection with the newly discovered connected device <NUM> using the received identification information. As discussed above, the catalog of devices may be stored in an indexed and searchable database or repository.

In one example, the connected device <NUM> may be an Internet Protocol (IP)-based camera, a smart television, a home automation or security devices (e.g., light switches, electrical outlets, thermostats, open/closed window sensors, or the like), a kitchen appliance (e.g., refrigerator), or the like.

If the connected device <NUM> is not in the catalog of devices, then the process terminates. If, however, the connected device <NUM> is in the catalog of devices, then at operation S204 the agent <NUM> at the discovery authority <NUM> outputs a USP device notification message for an event (reportNewDevice!(deviceInfo)) to the controller <NUM> at the administrative authority <NUM>. The USP device notification message indicates that the discovery authority <NUM> has discovered a device that has potential (or candidate) services to be offered to the subscriber/user of the connected device <NUM>. The USP device notification message may include identification information for the connected device <NUM>. In one example, the identification information may include the manufacturer of the device, product class, serial number, agent endpoint ID, or the like.

In response to receiving the USP device notification message, at operation S206 (determineApplicableServices) the administrative authority <NUM> identifies services to be offered to a subscriber/user for the connected device <NUM>. In one example, the administrative authority <NUM> searches the catalog (e.g., an indexed and searchable database or repository) of services to identify the services compatible with the connected device <NUM>. The service or services compatible with the connected device <NUM> identified at operation S206 may also be referred to as applicable service(s).

Once having identified services to be offered to the user/subscriber, at operation S208 the administrative authority <NUM> outputs a USP service advertisement message (advertiseService) to notify the user/subscriber of the identified services. In one example, the administrative authority <NUM> may output the USP service advertisement message to the user/subscriber through one or more portals/channels (e.g., online accounts, emails, text messages, voice calls, or the like).

After notifying the user/subscriber of the identified services, when the administrative authority <NUM> receives a service acceptance message (acceptService) via the one or more portals/channels at operation S210, then at operation S212 the administrative authority <NUM> provides onboard information (provideOnboardlnfo(AdminAuthority) to the subscriber/user via the one or more portals/channels. The onboard information allows the subscriber/user to onboard the administrative authority <NUM> such that at the end of the onboarding event, the administrative authority <NUM> is able to manage the device. Onboarding may entail configuring the device with information in order for the device establish a USP communication session with the administrative authority as well as establishing the correct security context within the device for what the administrative authority <NUM> is authorized to perform. The onboard information includes information enabling the controller <NUM> at the user device <NUM> to successfully communicate with the agent <NUM> at the administrative authority <NUM>, the information needed to allow the administrative authority <NUM> to control the agent <NUM> at the connected device <NUM> and implementing the service identified at operation S206. According to at least one example embodiment, information enabling the controller <NUM> at the administrative authority <NUM> to communicate with the agent <NUM> at the connected device <NUM> includes the identity and necessary security credentials of the controller <NUM>. The controller <NUM> may also setup the security roles for the administrative authority <NUM>.

After the user/subscriber inputs the information received from the administrative authority <NUM> into the user device <NUM> at operation S214, the controller <NUM> at the user device <NUM> outputs a set of USP configuration commands to the agent <NUM> at the connected device <NUM> at operation S216. In the example shown in <FIG>, the set of USP configuration commands include: a controller configuration command (add:Device. LocalAgent. Controller(Admin Authority)) to configure the agent <NUM> with a controller entry for the controller <NUM>; a security download command (operate:Device. Download(): (AdminAuthorityCredentials)) requesting download of security credentials needed to communicate with the administrative authority to the agent <NUM>; and an onboard notification request command (operate: Device. LocalAgent. Controller. {i}SendOnboardRequest(AdminAuthority)) requesting that the agent <NUM> send an onboard request notification message (onboardRequest) to the controller <NUM> at the administrative authority <NUM>. The controller configuration command (add:Device. LocalAgent. Controller(Admin Authority)) includes information (e.g., communication protocol, security credential, security role, and the like) for the agent <NUM> to establish a USP session with the controller <NUM> at the administrative authority <NUM>. The security download command (operate:Device. Download(): (AdminAuthorityCredentials)) provides the agent <NUM> with the location of the credentials for the controller <NUM> at the administrative authority <NUM>. The onboard notification request command (operate: Device. LocalAgent. Controller. {i}SendOnboardRequest(AdminAuthority)) conveys the USP identifier of the controller <NUM> at the administrative authority <NUM>.

In response to receiving the set of USP configuration commands, at operation S218 the agent <NUM> at the connected device <NUM> outputs the USP onboard request notification message (notify:onboardRequest) to the controller <NUM> at the administrative authority <NUM>. The USP onboard request notification message informs the administrative authority <NUM> that at least the onboard notification request command has been received successfully.

At operation S220, the controller <NUM> at the administrative authority <NUM> outputs a USP software download command message (operate:Device. USPSoftwareModules. InstallDU()) to the agent <NUM> at the home automation gateway <NUM>. The USP software download command message (operate:Device. USPSoftwareModules. InstallDU()) includes the location of a software module to be downloaded (or, alternatively, acquired) and installed at the home automation gateway <NUM>. In response to receiving the USP software download command message (operate:Device. USPSoftwareModules. InstallDU()), the home automation gateway <NUM> downloads and installs software that is needed to implement the requested services (e.g., home surveillance, home automation, and the like) into the execution environment of the agent <NUM> of the connected device <NUM>.

At operation S222, the controller <NUM> at the administrative authority <NUM> outputs a set of USP home automation configuration messages to the agent <NUM> at the connected device <NUM> to allow the agent <NUM> to communicate with the controller <NUM> at the home automation gateway <NUM>. In this example, the set of USP home automation configuration messages includes: an add:Device. LocalAgent. Controller(HomeAutomation) message to configure the agent <NUM> at the connected device <NUM> with a new controller entry for the controller <NUM> at the home automation gateway <NUM>; an operate: Device. Download (): (HomeAutomationCredentials) message requesting download of the security credentials for the controller <NUM> at the home automation gateway <NUM>; and a get: Device. Certificate message to retrieve the requested security credentials of the agent <NUM>. In one example, the add:Device. LocalAgent. Controller(HomeAutomation) message includes information (e.g., communication protocol, security credentials, security roles, or the like) that allows the agent <NUM> at the connected device <NUM> to establish a USP session with the controller <NUM> at the home automation gateway <NUM>. The operate: Device. Download (): (HomeAutomationCredentials) message includes the location of the credentials for the controller <NUM> at the home automation gateway <NUM>. The get: Device. Certificate message requests return of the security credentials for the user device <NUM> that is used to identify the agent <NUM> to the controller <NUM> at the home automation gateway <NUM>.

Still referring to <FIG>, at operation S224, the controller <NUM> at the administrative authority <NUM> sends a USP message (operate:Device. Download():(DeviceCredentials)) that downloads (or, alternatively, acquires) the security credentials (also referred to herein as security information) of agent <NUM> and a USP message (add:Device. RemoteAgent(Device)) that configures the communication information for agent <NUM> to the agent <NUM> at the home automation gateway <NUM> in order for controller <NUM> to communicate with agent <NUM>. The USP message that configures a remote agent includes information (e.g., communication protocol, security credentials, or the like) for the controller <NUM> at the home automation gateway <NUM> to establish a USP session with the agent <NUM> at the connected device <NUM>.

At operation S226, the controller <NUM> at the administrative authority <NUM> outputs a USP message (operate: Device. USPSoftwareModules. SetRequestedState (ServiceApplications)) to the agent <NUM> at the home automation gateway <NUM> to activate the installed software in the execution environment of the agent <NUM> at the connected device <NUM> for the previously installed software for the services accepted by the user. In one example, this USP message (sometimes referred to herein as a USP activation/deactivation command message) includes the identifier of the software module to be activated/deactivated and the requested state action (activate or deactivate).

At operation S228, the controller <NUM> at the administrative authority <NUM> sends a USP message (operate: Device. LocalAgent. Controller. SendOnboardRequest(HomeAutomation)) to request that the agent <NUM> at the connected device <NUM> send a USP onboardRequest notification to the controller <NUM> at the home automation gateway <NUM>. In this example, the USP onboardRequest notification includes the USP identifier of the controller <NUM> at the home automation gateway <NUM>.

In response to receiving the USP message (operate: Device. LocalAgent. Controller. SendOnboardRequest(HomeAutomation)) from the controller <NUM> at the administrative authority <NUM>, at operation S230 the agent <NUM> at the connected device <NUM> sends USP onboardRequest notification (notify:onboardRequest) to the controller <NUM> at the home automation gateway <NUM>. The USP onboardRequest notification request command sent at operation S230 provides the same information as the USP onboardRequest notification request command sent in operation S228, but is sent to the controller <NUM> at the home automation gateway <NUM> instead of the controller <NUM> at the administrative authority <NUM>.

In response to the USP onboardRequest notification from the agent <NUM> at the connected device <NUM>, the agent <NUM> at the home automation gateway <NUM> outputs an event notification (notify: Device. LocalAgent. ReportOnboardedDevice!(deviceInfo)) to the controller <NUM> at the administrative authority <NUM> once the actions needed to onboard the services for the connected device <NUM> have been completed by the controller <NUM> at the home automation gateway <NUM>. The event notification may include identification information (e.g., manufacturer, product class, serial number, agent endpoint ID, or the like) for the connected device <NUM>.

Once the services (e.g., home surveillance, home automation, or the like) for the connected device <NUM> have been installed and activated at the home automation gateway <NUM>, the home automation gateway <NUM> performs the necessary functions for that service and type of device. For example, in the context of a home surveillance system, where the connected device <NUM> is an IP camera, a control session is established between the home automation gateway and the IP camera to allow control of the IP camera by the home automation gateway <NUM>. Other connections may also be established to either stream the content of the IP camera or periodically upload the content of IP camera. An alarm channel may also be established to permit the IP camera to notify the home automation gateway <NUM> of activity sensed by the IP camera. These messages and channels may use USP messages or other communication protocols (e.g., Zigbee, Internet Engineering Task Force Constrained Application Protocol (IETF CoAP), or the like) that are translated by the home automation gateway <NUM>.

<FIG> is a signal flow diagram illustrating another example embodiment of a method for automated onboarding of services in the USP architecture shown in <FIG>.

The method shown in <FIG> is an example embodiment in which pre-provisioned onboarding is utilized. In this example, the discovery functionality provided by operations S202 through S212 in <FIG> are replaced by a pre-provisioning procedure. After the pre-provisioning procedure is completed, operations S214 through S232 discussed above with regard to <FIG> are performed. Because operations S214 through S232 in <FIG> are the same as those discussed above, detailed discussion of these operations will be omitted here.

Referring to <FIG>, in this example embodiment, the user/subscriber purchases an offered service through, for example, an online service portal at the OSS service provider <NUM>, and a device associated with the purchased service is provided (e.g., shipped) to the user/subscriber. Additionally, once having completed purchase of the offered service, the OSS service provider <NUM> - rather than the administrative authority <NUM> in the method of <FIG> - outputs the USP onboard information message (provideOnboardInfo(AdminAuthority)) to the subscriber/user through an inventory provisioning system that maintains the information related to the devices that the service provider has given the subscriber to use to implement the purchased services at operation S302. The USP onboard information message is the same as the USP onboard information message discussed above with regard to S212 in <FIG>.

At operation S304, the OSS service provider <NUM> outputs a message (informNewDevice(deviceInfo)) to the administrative authority <NUM> to inform the administrative authority <NUM> that a subscriber has been provided a new device with the information necessary to establish a USP session with the agent at the device associated with the purchased service.

The method then proceeds with operations S214 through S232 discussed above with regard to <FIG>.

As described above with regard to <FIG>, once the services (e.g., home surveillance, home automation, or the like) for the connected device <NUM> have been installed and activated at the home automation gateway <NUM>, the home automation gateway <NUM> performs the necessary functions for that service and type of device.

<FIG> is a signal flow diagram illustrating yet another example embodiment of a method for automated onboarding of services in the USP architecture shown in <FIG>.

The method shown in <FIG> is an example embodiment in which zero-touch onboarding is utilized. In this example embodiment, the user/subscriber purchases an offered service through an online service portal at the OSS service provider <NUM>, and the connected device <NUM> associated with the purchased service is provided (e.g., shipped) to the user/subscriber.

When the user/subscriber connects the connected device <NUM> to the local network, at operation S402, the agent <NUM> at the connected device <NUM> advertises and/or notifies the controller <NUM> at the discovery authority <NUM>, which is listening for newly added agents, of its existence. Operation S402 is the same as operation S202 in <FIG>, and thus, a detailed discussion will be omitted.

In response to receiving the notification, at operation S404 the discovery authority <NUM> interrogates (e.g., searches) the catalog of devices for which services may be offered to identify whether there are services to be offered in connection with the connected device <NUM> using the received identification information. As discussed above, the catalog of devices may be stored in an indexed and searchable database or repository. In this example, the catalog of devices is at the OSS service provider <NUM>. Accordingly, at operation S404, the discovery authority <NUM> interrogates the catalog of devices at the OSS service provider <NUM>.

In response to the interrogation operation S404, the OSS service provider <NUM> outputs a message (provide OnboardInfo (AdminAuthority)) to the discovery authority <NUM> at operation S408. The message output at operation S408 is the same as the message output by the administrative authority <NUM> at operation S212 in <FIG>.

The agent <NUM> at the discovery authority <NUM> also outputs a USP device notification message (notify:Device. LocalAgent. ReportNewDevice!(deviceInfo)) to the controller <NUM> at the administrative authority <NUM> at operation S406. The USP device notification message notifies the administrative authority <NUM> of the connected device <NUM>, and may include identification information for the connected device <NUM>. In one example, the identification information may include the manufacturer of the home automation device, product class, serial number, agent endpoint ID, and the like.

At operation S410, the controller <NUM> at the discovery authority <NUM>, rather than the user device <NUM> at operation S216 in <FIG>, outputs the set of USP configuration commands to the agent <NUM> at the connected device <NUM>. The set of USP configuration commands output at operation S410 are the same as those output by the controller <NUM> at the user device <NUM> at operation S216 in <FIG>, and thus, further discussion is omitted.

The procedure shown in <FIG> then continues with operations S218 through S232 discussed above with regard to <FIG> to complete the zero-touch onboarding process for the connected device.

As described above with regard to <FIG> and <FIG>, once the services (e.g., home surveillance, home automation, or the like) for the connected device <NUM> have been installed and activated at the home automation gateway <NUM>, the home automation gateway <NUM> performs the necessary functions for that service and type of device.

As discussed herein, in one example, at least operations S208 through S230 may be characterized as a provisioning or onboarding operation. In another example, operations S212 through S230 may be characterized as a provisioning or onboarding operation. In yet another example, operation S232 may be included in what is considered the provisioning or onboarding operation.

One or more example embodiments provide methods, via the discovery authority, to recognize a connected device that may use various services (e.g., home automation, home security, or the like) provided by a service provider, and then inform an administrative authority of the connected device. The notification of the device from discovery authority toward the administrative authority increases the ecosystem of potential devices that may be provided services as devices such as retail devices need not have the information required to contact the administrative authority directly. One or more example embodiments also improves the efficiency for identifying newly connected devices as the administrative authority no longer needs to be contacted by the connected device to recognize the connected device. Rather, the discovery authority, which is typically located within the same network domain as the connected device, recognizes the addition of the connected device.

One or more example embodiments may also provide a method in which an endpoint device may report successful onboarding of a service for newly discovered devices. The notification that the service has been successfully onboarded completes the fulfillment process, which is missing in the current USP. In one example, the home automation gateway (or other USP endpoint) reports the successful onboarding of the service based on previous actions by the administrative authority. This may also improve the efficiency of the fulfillment process as the administrative authority need not poll the USP endpoints involved in the service; instead the USP endpoints report when they are ready to provide the service.

<FIG> depicts a high-level block diagram of a computer, computing or electronic device suitable for use in implementing, inter alia, USP endpoints, as well as other network elements and/or devices.

Referring to <FIG>, the computer <NUM> includes one or more processors <NUM> (e.g., a central processing unit (CPU) or other suitable processor(s)) and a memory <NUM> (e.g., random access memory (RAM), read only memory (ROM), and the like). The computer <NUM> also may include a cooperating module/process <NUM>. The cooperating process <NUM> may be loaded into memory <NUM> and executed by the processor <NUM> to implement functions as discussed herein and, thus, cooperating process <NUM> (including associated data structures) may be stored on a computer readable storage medium (e.g., RAM memory, magnetic or optical drive or diskette, or the like).

The computer <NUM> also may include one or more input/output devices <NUM> (e.g., a user input device (such as a keyboard, a keypad, a mouse, and the like), a user output device (such as a display, a speaker, and the like), an input port, an output port, a receiver, a transmitter, one or more storage devices (e.g., a tape drive, a floppy drive, a hard disk drive, a compact disk drive, and the like), or the like, as well as various combinations thereof).

As discussed herein, illustrative embodiments will be described with reference to acts and symbolic representations of operations (e.g., in the form of flow charts, flow diagrams, data flow diagrams, structure diagrams, block diagrams, etc.) that may be implemented as program modules or functional processes include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types and may be implemented using existing hardware at, for example, existing endpoints, clients, gateways, nodes, agents, controllers, computers, cloud based servers, web servers, proxies or proxy servers, application servers, and the like. As discussed later, such existing hardware may include, inter alia, one or more Central Processing Units (CPUs), system-on-chip (SOC) devices, digital signal processors (DSPs), application-specific-integrated-circuits, field programmable gate arrays (FPGAs) computers or the like.

As disclosed herein, the term "storage medium", "computer readable storage medium" or "non-transitory computer readable storage medium" may represent one or more devices for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other tangible machine readable mediums for storing information. The term "computer-readable medium" may include, but is not limited to, portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing or carrying instruction(s) and/or data.

Furthermore, example embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a computer readable storage medium. When implemented in software, a processor or processors will perform the necessary tasks.

A code segment may represent a procedure, function, subprogram, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc..

The terms "including" and/or "having", as used herein, are defined as comprising (i.e., open language). The term "coupled", as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. Terminology derived from the word "indicating" (e.g., "indicates" and "indication") is intended to encompass all the various techniques available for communicating or referencing the object/information being indicated. Some, but not all, examples of techniques available for communicating or referencing the object/information being indicated include the conveyance of the object/information being indicated, the conveyance of an identifier of the object/information being indicated, the conveyance of information used to generate the object/information being indicated, the conveyance of some part or portion of the object/information being indicated, the conveyance of some derivation of the object/information being indicated, and the conveyance of some symbol representing the object/information being indicated.

According to example embodiments, endpoints, clients, gateways, nodes, agents controllers, computers, cloud based servers, web servers, application servers, proxies or proxy servers, and the like, may be (or include) hardware, firmware, hardware executing software or any combination thereof. Such hardware may include one or more Central Processing Units (CPUs), system-on-chip (SOC) devices, digital signal processors (DSPs), application-specific-integrated-circuits (ASICs), field programmable gate arrays (FPGAs) computers or the like configured as special purpose machines to perform the functions described herein as well as any other well-known functions of these elements. In at least some cases, CPUs, SOCs, DSPs, ASICs and FPGAs may generally be referred to as processing circuits, processors and/or microprocessors.

The endpoints, clients, gateways, nodes, agents, controllers, computers, cloud based servers, web servers, application servers, proxies or proxy servers, and the like, may also include various interfaces including one or more transmitters/receivers connected to one or more antennas, a computer readable medium, and (optionally) a display device. The one or more interfaces may be configured to transmit/receive (wireline and/or wirelessly) data or control signals via respective data and control planes or interfaces to/from one or more network elements, such as switches, gateways, termination nodes, controllers, servers, clients, and the like.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments of the invention. However, the benefits, advantages, solutions to problems, and any element(s) that may cause or result in such benefits, advantages, or solutions, or cause such benefits, advantages, or solutions to become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims.

Claim 1:
An administrative authority endpoint device (<NUM>) for use in a User Services Platform network architecture comprising:
a memory storing computer readable instructions; and
at least one processor configured to execute the computer readable instructions to :
receive a User Services Platform device notification message identifying a connected device from a discovery authority endpoint device (<NUM>)
initiate acquisition, at a home automation gateway (<NUM>) in a local network, of a software module associated with an applicable service to be implemented by the home automation gateway in association with the connected device (<NUM>) by sending a User Services Platform software download command message to the home automation gateway (<NUM>),
initiate acquisition, at the home automation gateway (<NUM>), of security and communication information associated with the connected device (<NUM>) by sending security and communication information messages to the home automation gateway (<NUM>),
initiate activation of the software module at the home automation gateway (<NUM>) to onboard the applicable service for the connected device (<NUM>) by sending a User Services Platform activation command message to the home automation gateway (<NUM>), and
receive notification that the applicable service has been onboarded at the home automation gateway (<NUM>) from the home automation gateway (<NUM>).