CN113396571A

CN113396571A - Method and apparatus for pairing IOT devices and IOT services in a heterogeneous IOT ecosystem

Info

Publication number: CN113396571A
Application number: CN201980091238.0A
Authority: CN
Inventors: I.B.P.P.迪纳塔; G.K.尤塔马; N.拉曼; H.普拉维拉塔马; Y.拉曼
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2018-12-07
Filing date: 2019-12-09
Publication date: 2021-09-14
Also published as: EP3878164A1; EP3878164A4

Abstract

An electronic device and method are provided. End-to-end automatic interconnection of heterogeneous internet of things (IoT) systems automates both cloud-to-cloud (C2C) (primary IoT service to external IoT service) and device-to-cloud (D2C) (IoT device to IoT service) pairing processes with IoT service information available in IoT devices and services with visual and/or radio tag information.

Description

Method and apparatus for pairing IOT devices and IOT services in a heterogeneous IOT ecosystem

Technical Field

The present disclosure relates to methods and apparatus for simplifying pairing procedures of internet of things (IoT) devices and IoT services in heterogeneous IoT ecosystems. More particularly, the present disclosure relates to a pairing process that includes how a user performs cloud-to-cloud (C2C) pairing between their primary and external IoT services and how to perform device-to-cloud (D2C) pairing between their IoT devices and IoT services.

Background

There is no invention that discusses how to enable users to automate the pairing process using heterogeneous IoT devices from various vendors. Currently, the user must make a series of manual configurations of each of the IoT system entities to do a simple operation of on and off control across different vendors.

US 9,977,415 (the' 415 patent) discusses systems and methods for implementing virtual IoT hubs and devices. The' 415 patent places emphasis on how the system is dedicated to supporting multiple IoT hubs and devices. Meanwhile, the disclosure herein discloses how users can easily pair their IoT devices with IoT services (from User Interfaces (UIs), processes, and flows).

Us publication 2015-. The' 445USP places emphasis on how to create abstractions in IoT services to support many IoT devices. The disclosure herein discloses pairing steps (from UIs, processes, and flows) so that users can easily pair their IoT things with IoT services.

The above information is presented merely as background information to assist in understanding the present disclosure. No determination has been made and no statement made as to whether any of the above would likely be useful as prior art with respect to the present disclosure.

Drawings

The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings in which:

fig. 1 is a view of an IoT ecosystem supporting C2C and/or D2C pairing mechanisms in accordance with an embodiment of the present disclosure;

fig. 2A illustrates an example of a C2C pairing process from a user perspective, according to an embodiment of the present disclosure;

fig. 2B illustrates an example of the results of a C2C pairing process from a user perspective, according to an embodiment of the present disclosure;

fig. 3A illustrates an example of a D2C pairing process from a user perspective, according to an embodiment of the disclosure;

fig. 3B illustrates an example of the results of a D2C pairing process from a user perspective, according to an embodiment of the disclosure;

FIG. 3C illustrates an example of a use case of a D2C pairing process in accordance with an embodiment of the disclosure;

fig. 4A illustrates a process of flexible IoT service switching illustrating a flow of IoT applications when a user wants to switch their IoT service in accordance with an embodiment of the present disclosure;

fig. 4B illustrates the result of a process of flexible IoT service switching in accordance with an embodiment of the present disclosure;

fig. 5 illustrates a process of bulk pairing of IoT devices using APM and custom pairing steps in accordance with an embodiment of the present disclosure;

fig. 6 illustrates a sample scenario on how to use external IoT services to enhance the functionality and capabilities of IoT devices paired with a primary IoT service in accordance with an embodiment of the present disclosure;

fig. 7 illustrates the systems and data required to enable C2C pairing in an IoT ecosystem, in accordance with embodiments of the present disclosure;

fig. 8A is a flow diagram of C2C pairing between a primary IoT service and an external IoT service in accordance with an embodiment of the present disclosure;

fig. 8B is a flow diagram of a C2C unpairing process between a primary IoT service and an external IoT service in accordance with an embodiment of the present disclosure;

FIG. 9 illustrates the pairing and unpairing process of a C2C module, according to an embodiment of the disclosure;

fig. 10 illustrates a sequence diagram of a C2C pairing, according to an embodiment of the disclosure;

fig. 11 illustrates an overall mechanism on how an IoT application reads a tag in an IoT device, in accordance with an embodiment of the present disclosure;

fig. 12 is a block diagram of an IoT system to support a D2C pairing process in accordance with an embodiment of the present disclosure;

fig. 13 is a flowchart illustrating detailed processes and systems to support a device-to-cloud (D2C) IoT pairing mechanism in accordance with an embodiment of the present disclosure;

14A and 14B illustrate D2C pairing by scanning tags, FIGS. 14A and 14B showing a flow of a user interface during a D2C pairing process, according to various embodiments of the present disclosure;

fig. 15 illustrates an example of a sequence diagram for a D2C pairing, according to an embodiment of the present disclosure;

fig. 16 is a detailed sequence diagram of a D2C pairing process for unpaired external IoT services, according to an embodiment of the present disclosure;

fig. 17 is a detailed sequence diagram of a D2C pairing process for paired external IoT services, in accordance with an embodiment of the present disclosure;

fig. 18 illustrates a detailed sequence diagram of a D2C pairing process between an IoT device and a primary IoT service via a hub, in accordance with an embodiment of the present disclosure;

fig. 19 is a detailed sequence diagram of a D2C pairing process between an IoT device and a primary IoT service via a hub, according to an embodiment of the present disclosure;

fig. 20 is a block diagram illustrating an IoT information service system and hierarchy in an IoT ecosystem, in accordance with embodiments of the present disclosure;

fig. 21A is a flow diagram of obtaining IoT device information in accordance with an embodiment of the present disclosure;

fig. 21B is a flow diagram of registering IoT device information in accordance with an embodiment of the present disclosure;

fig. 22A is a block diagram of a process of registering IoT device information when tag information already exists, in accordance with an embodiment of the present disclosure;

fig. 22B is a block diagram of a process of registering IoT device information without tag information in accordance with an embodiment of the present disclosure;

fig. 22C is a block diagram of a process for obtaining IoT device information in accordance with an embodiment of the present disclosure;

fig. 23 illustrates a block diagram illustrating an APM system for D2C or C2C pairing to automate the pairing process between an IoT device and an IoT service, in accordance with an embodiment of the present disclosure;

FIG. 24 is a flow diagram of an automated pairing procedure for D2C or C2C pairing, according to an embodiment of the disclosure; and

fig. 25 is a block diagram of an electronic device according to an embodiment of the disclosure.

Throughout the drawings, the same reference numerals will be understood to refer to the same parts, components and structures.

Detailed Description

Best mode for carrying out the invention

Aspects of the present disclosure are to address at least the above-mentioned problems and/or disadvantages and to provide at least the advantages described below. Accordingly, aspects of the present disclosure will provide an end-to-end automatic interconnection of heterogeneous IoT systems that can automate both C2C (primary IoT service to external IoT service) and D2C (IoT device to IoT service) pairing processes.

Additional aspects will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the presented embodiments.

According to an aspect of the present disclosure, an electronic device or apparatus is provided. The electronic device may include: a memory configured to store one or more instructions; and at least one processor configured to execute one or more instructions to: receiving a pairing request to perform at least one of a cloud-to-cloud (C2C) pairing or a device-to-cloud (D2C) pairing; obtaining pairing information based on the pairing request, the pairing information including at least one of information about an external IoT service or information about an IoT device; generating a pairing step model based on the pairing information and the pairing request; and performing at least one of a C2C pairing between the primary IoT service and the external IoT service or a D2C pairing between the IoT service and the IoT device based on the pairing step.

According to another aspect of the disclosure, the at least one processor may be further configured to obtain a user selection of an external IoT service; an Application Program Interface (API) to conduct user authentication of the external IoT service to authorize the primary IoT service to access and use the external IoT service based on the pairing request; performing a C2C pairing procedure in the primary IoT service and the external IoT service; and an API to execute an external IoT service from the primary IoT service, wherein the pairing request includes information about the external IoT service performing cloud-to-cloud (C2C) pairing.

According to another aspect of the disclosure, the at least one processor may be further configured to obtain a user selection of an IoT device; activating a pairing state in an IoT device, wherein the IoT device can be paired with at least one of a supported IoT service or a supported IoT hub; obtaining pairing information including information about at least one IoT service selected by a user; performing a D2C pairing procedure between an IoT device and at least one IoT service; and performing at least one function of the IoT device from the at least one IoT service, wherein the pairing request includes information about the IoT device performing the device-to-cloud (D2C) pairing, and wherein the at least one IoT service supports D2C pairing with the IoT device.

According to another aspect of the disclosure, the at least one processor is further configured to obtain information of an IoT hub selected by a user of the electronic device; sending a pairing request for D2C pairing to an IoT hub based on information about the IoT hub; receiving a pairing response of the D2C pairing from the IoT hub according to the pairing request; and performing a D2C pairing procedure via the user selected IoT hub.

According to another aspect of the disclosure, the at least one processor is further configured to request the C2C module to start the C2C pairing or request the D2C module to start the D2C pairing based on execution of a pairing process, wherein the pairing process includes at least one of pairing between the IoT device and the primary IoT service, pairing between the IoT device and the paired external IoT service, pairing between the IoT device and the unpaired external IoT service, and pairing between the IoT device and the IoT service via the IoT hub.

According to another aspect of the disclosure, the pairing process may include pairing of an IoT device with an IoT service, wherein the at least one processor is further configured to request pairing with D2C of the IoT application; obtaining TAG information by scanning TAGs of IoT devices; and sending the pairing request and the TAG information to an IoT service via the IoT application.

According to another aspect of the disclosure, the pairing process may include automatic C2C pairing or automatic D2C pairing using a preset configuration, wherein the at least one processor is further configured to: generating a custom pairing step comprising a user-defined C2C or D2C pairing step; obtaining a pairing request to enable reading of the custom pairing step; and loading and executing the custom pairing step in the primary IoT service.

According to another aspect of the disclosure, the pairing process may include a flexible IoT service switch, wherein the at least one processor is further configured to obtain user selection information including device information about an IoT device selected to change from a previous IoT service and service information about an IoT service selected as a new target to be paired with the selected IoT device; unpairing a previous IoT service with an IoT device; activating a pairing state of an IoT device; and D2C pairing between the IoT device and the selected IoT service.

According to another aspect of the present disclosure, an electronic device is provided. The electronic device includes: a manager configured to receive the pairing request, manage the automatic pairing process in the sub-module and return an automatic pairing process response; a loader configured to collect data including at least one of tag information, IoT device information, IoT service information, information about user preferences, and information about custom pairing steps; a preprocessor configured to filter unnecessary data from the loader, convert the data, and parse the data for understanding by the generator; a generator configured to generate a pairing step model based on the pre-processed data from the pre-processor; and an executor configured to execute and give instructions to perform an action based on the pairing-step model from the generator.

According to another aspect of the present disclosure, the tag information may include key information for learning the identity of the device embedded in the tag of the device, which is useful for retrieving IoT device information from an IoT information service. Further, the IoT device information may include detail information including information of at least one of an identity of the IoT device, capabilities of the IoT device, a protocol of the D2C pairing, supported IoT services, and IoT device pairing steps. The IoT service information may include detail information including information about at least one of an identity of the IoT service, a capability of the IoT service, a protocol of the C2C pairing or D2C pairing, an API, supported external IoT services, security steps, and IoT service pairing steps. The information on the user preference may include information set by the user, the information including at least one of user equipment, user service, user identification, security, and network configuration.

According to another aspect of the present disclosure, a method is provided. The method comprises the following steps: obtaining a pairing request for at least one of a cloud-to-cloud (C2C) pairing or a device-to-cloud (D2C) pairing; receiving a pairing request to perform at least one of a cloud-to-cloud (C2C) pairing or a device-to-cloud (D2C) pairing; obtaining pairing information based on the pairing request, the pairing information including at least one of information about an external IoT service or information about an IoT device; generating a pairing step based on the pairing information and the pairing request; and performing at least one of a C2C pairing between the primary IoT service and the external IoT service or a D2C pairing between the IoT service and the IoT device based on the pairing step.

According to another aspect of the present disclosure, a computer program product is provided. The computer program product comprises: a non-transitory computer-readable recording medium having a plurality of instructions recorded thereon, which when executed by at least one processor, cause the at least one processor to obtain a pairing request to at least one of perform a cloud-to-cloud (C2C) pairing or a device-to-cloud (D2C) pairing; obtaining pairing information based on the pairing request, the pairing information including at least one of information about an external IoT service to be paired with the primary IoT service or information about an IoT device to be paired with the primary IoT service; generating a pairing step model based on the pairing information and the pairing request; and performing at least one of a C2C pairing process between the primary IoT service and the external IoT service or a D2C pairing process between the primary IoT service and the IoT device based on the pairing step.

According to another aspect of the present disclosure, systems and methods are provided. The systems and methods include end-to-end automatic interconnection of IoT devices and systems within a heterogeneous IoT ecosystem by automating both the cloud-to-cloud (C2C) pairing process, which is a pairing process between a primary IoT service and an external IoT service, and the device-to-cloud (D2C), which is a pairing process between an IoT device and an IoT service. The present disclosure proposes an auto-pairing mechanism that leverages IoT information services (where IoT information (including at least one of tag information, IoT device information, and IoT service information) through an auto-pairing module (APM) in which pairing steps are generated and then executed to perform pairing steps to sense and actuate available IoT devices and IoT services within an IoT ecosystem. An Automatic Pairing Module (APM) in a system may include the following entities: a manager configured to receive the pairing request, manage the APM process in the sub-module and return an APM process response to the requestor; a loader configured to collect data from a number of sources and storage devices including an IoT information service, further collect data, the data includes at least one of tag information (which includes key information for learning the identity of the device embedded in the tag of the device, which is useful for retrieving IoT device information from the IoT information service), IoT device information (details of the IoT device include ID, capability, protocol, supported IoT services, and IoT device pairing steps), IoT service information (details of the IoT device include ID, capability, protocol, API, supported external IoT services, security steps, and IoT service pairing steps), and user preferences (which are information set by the user, including information of the device, service, user, security, network configuration, custom pairing steps, and custom steps set by the user to pair C2C or D2C in a particular case); a preprocessor that can filter unnecessary data from the collected data from the loader, convert the filtered data, and parse the filtered data for understanding by the generator; a generator that can generate a pairing step model based on the pre-processed data from the pre-processor; and an executor that can execute instructions based on the pairing step model from the generator and then give instructions to corresponding modules in the IoT service to act.

The IoT information services in the system may include the following entities: a manager that will receive the request, manage the request (which includes the IoT information request or registration) and return a response to the requestor; a storage in which all IoT information including tag information, IoT device information, and IoT service information can be stored, retrieved, and managed; a parser, wherein the tag information can be parsed to retrieve the key information, and thus can be used to request IoT device information from the storage; a generator that may generate tag information based on the received IoT device information.

According to another aspect of the disclosure, the system may automate the pairing mechanism by the Automatic Pairing Mechanism (APM) further comprising the steps of: receiving a request from a user or system to pair cloud-to-cloud (C2C) or device-to-cloud (D2C); obtaining necessary information from the IoT information service and storage to the APM based on receiving the pairing request; preprocessing the acquired information based on the received pairing request to remove unused data and parsing and converting the data into data that is understandable by the generator; generating a pairing step model in the APM based on the preprocessing information and the pairing request; and executing a pairing-step model for the selected module based on the generated pairing-step model.

According to another aspect of the disclosure, the system may further include the following steps to enable a cloud-to-cloud (C2C) pairing mechanism by receiving a request from a user or system to pair C2C. The system may include the steps of: executing an APM to begin an auto-pairing process based on the pairing request; perform user authentication of the selected external IoT service to authorize the primary IoT service to access and use the API of the external IoT service; starting a pairing procedure in a primary IoT service side and a pairing procedure in an external IoT service side; and confirm the pairing procedure by calling the API of the external IoT service from the primary IoT service.

According to another aspect of the disclosure, the system may further include the following steps to enable a device-to-cloud (D2C) pairing mechanism: enabling a pairing state in the IoT device (the pairing state pairing the IoT device with the IoT service or the IoT hub device); receiving a request from a user or system to pair D2C; and selecting an IoT device that the user wants to pair with the IoT service. The APM may then request IoT device information from the IoT information service to obtain a list of supported IoT services or IoT hubs. The system may further comprise the steps of: showing, to the IoT application, a list of IoT services supported by the selected IoT device based on the IoT device information; and selecting an IoT service with which the user wants to pair with the IoT device based on the IoT device information. Next, the APM may request IoT service information from the IoT information service to obtain steps for pairing the IoT device with the selected IoT service. The system may further comprise the steps of: performing an APM to start an auto-pairing process based on the pairing request, the IoT service information, and the IoT device information; starting a pairing process between the IoT device and the IoT service; and confirming the pairing procedure by performing a function inside the IoT device according to the IoT service.

According to another aspect of the present disclosure, the system may employ an IoT information service, wherein the availability and the publicity of the IoT information service are classified into an IoT information service tier 1 (privately available and used by the IoT service) and an IoT information service tier 2 (publicly available and used by multiple IoT services).

According to another aspect of the disclosure, the system further includes the following steps to enable IoT device registration to the selected IoT information service: requesting registration of the IoT device from the IoT information service and uploading the IoT device information to complete the IoT device registration process. Additionally, at least one IoT provider may also upload existing tag information for its devices (if available). The method can comprise the following steps: generating, by a generator, tag information including key information from the uploaded IoT device information if the IoT provider does not upload the tag information during the registration process; reading and parsing the tag information by a parser to obtain key information if the IoT provider uploads the tag information during a registration process; saving the IoT device information to a storage device along with key information from the tag information; receiving a registration response including the generated tag information; and enforcing the tag information to a tag to be attached on the IoT device.

According to another aspect of the present disclosure, the system may further include the following steps to enable the IoT service to retrieve the IoT device information: requesting retrieval of IoT device information from an IoT information service; uploading tag information to an IoT information service to complete an IoT device information request; parsing the tag information to obtain key information to query IoT device information in a storage; obtaining IoT device information from a storage; and receiving IoT device information as a result of the IoT device information request.

According to an embodiment, an auto-pairing module (APM) may request a cloud-to-cloud (C2C) module and/or a device-to-cloud (D2C) module to start a pairing process according to execution of a pairing step. The pairing process between the IoT device and the IoT service may further consist of: pairing an IoT device with a primary IoT service that has completed an APM, the APM instructing a D2C module inside the primary IoT service to perform a pairing process with the IoT device; pairing between the IoT device and an external IoT service that has completed pairing of the APM, the APM instructing the C2C module inside the primary IoT service to call the API of the external IoT service, which causes the external IoT service to pair with the IoT application; pairing between the IoT device and the unpaired external IoT service completed by the APM, the APM instructing the C2C module inside the primary IoT service to start the C2C pairing between the primary IoT service and the external IoT service and then proceed with the pairing between the IoT device and the external IoT service; and pairing between the IoT device and an IoT service via the IoT hub completed by the APM, the APM to instruct the D2C module to invoke the selected IoT hub as a bridge for pairing the IoT device with a primary IoT service or to instruct the C2C module to invoke the IoT hub paired at an external IoT service as a bridge for pairing the IoT device with the external IoT service.

According to embodiments, the system may enhance the capabilities of IoT devices, auto-pairing and/or unpairing processes, and enable flexible switching between various IoT devices and services. The system may further include the following process: pairing an IoT device with an IoT service, wherein a user performs the steps of: requesting D2C pairing in the IoT application, scanning a TAG of the IoT device using a TAG reader in the smartphone or an extended TAG reader connected to the smartphone, receiving the TAG from the TAG reader or the extended TAG reader to the IoT application, and sending the pairing request and TAG information to the IoT service via the IoT application; automatically performing C2C or D2C pairing in an IoT ecosystem using a preset configuration, wherein a user performs the steps of: build a custom pairing procedure (including user defined C2C or D2C pairing steps), start the pairing C2C or D2C procedure, configure pairing request to enable reading the custom pairing steps and loading and executing the custom pairing steps to the APM in the primary IoT service that is doing the C2C or D2C pairing procedure; flexible IoT service switching between IoT devices and IoT services, wherein a user or system can perform the following steps: selecting an IoT device that the user wants to change from the paired IoT services, selecting an IoT service that the user wants to select a new target to pair with the selected IoT device, unpairing a previous IoT service that is paired with the IoT device and then enabling the pairing state of the IoT device, and performing D2C pairing between the IoT device and the selected IoT service, enhancing the functionality and capabilities of the IoT device that is paired with the primary IoT service by conducting C2C pairing between the primary IoT service and an external IoT service that is compatible with the IoT device. The system may include: obtaining a selected IoT device that a user wants to enhance its capabilities; scanning a list of compatible external IoT services for the selected IoT device based on the IoT device information; and showing the list to the IoT application. The system may include: obtaining a user that selects an external IoT service for the selected IoT device to pair with the primary IoT service; performing C2C pairing of the selected external IoT service with the primary IoT service; and updating the capabilities and functionality of the selected IoT device based on the selected external IoT service.

Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses various embodiments of the disclosure.

Modes for the invention

The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the disclosure as defined by the claims and their equivalents. It includes various specific details to assist in understanding, but these details are to be regarded as exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Moreover, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

The terms and words used in the following description and claims are not limited to the written meaning, but are used only by the inventor to enable a clear and consistent understanding of the disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of the various embodiments of the present disclosure is provided for illustration only and not for the purpose of limiting the disclosure as defined by the appended claims and their equivalents.

It is to be understood that the singular forms "a", "an" and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to a "component surface" includes reference to one or more of such surfaces.

It is noted that to the extent possible, like reference numerals have been used to represent like elements in the figures. Additionally, those of ordinary skill in the art will appreciate that the elements in the illustrations are shown for simplicity and may not necessarily be drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of aspects of the embodiments. Furthermore, one or more elements may have been represented in the figures by various symbols, and the figures may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

It is to be understood that the singular forms "a", "an" and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to a "component surface" includes reference to one or more of such surfaces. Furthermore, expressions such as "at least one of" preceding a list of elements modify the entire list of elements rather than modifying individual elements of the list. For example, the expression "at least one of a, b and c" should be understood to include only a, only b, only c, both a and b, both a and c, both b and c, or all of a, b and c.

The term "includes/comprises" and its derivatives are intended to include, but not be limited to. The term "or" is inclusive, meaning and/or. The phrases "associated with … …" and "associated therewith" and derivatives thereof may mean including, included within, connected with, interconnected with, contained within, connected to or with … …, coupled to or coupled with … …, communicable with … …, cooperative with … …, interleaved, juxtaposed, proximate to … …, bound to or with … …, having, etc.

Moreover, various functions described below may be implemented or supported by one or more computer programs, each of which may be formed from computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in suitable computer readable program code. The phrase "computer readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer readable medium" includes any type of medium capable of being accessed by a computer, such as Read Only Memory (ROM), Random Access Memory (RAM), a hard disk drive, a Compact Disc (CD), a Digital Video Disc (DVD), or any other type of memory. A "non-transitory" computer-readable medium does not include a wired, wireless, optical, or other communication link that conveys transitory electrical or other signals. Non-transitory computer readable media include media that can permanently store data and media that can store and later rewrite data, such as rewritable optical disks or erasable memory devices.

The term "unit," "manager," "engine," or "device" may refer to a unit that handles at least one function or operation and may be implemented by hardware, software, or a combination of hardware and software.

As more IoT devices are introduced into the marketplace, consumers are provided with various options to use IoT devices. The consumer's tendency to use different IoT products that suit their needs (price, features, etc.) will result in the consumer purchasing IoT products from different vendors. On the other hand, fragmentation of IoT industries such as "without global standards" will cause IoT vendors to build their own proprietary IoT services (clouds) and IoT standards for their own IoT devices. This implication would enable consumers to register multiple IoT service accounts for different IoT vendors and enable consumers to pair and manage their heterogeneous IoT devices and IoT services through themselves.

To address issues arising in heterogeneous IoT devices and IoT services, apparatus and methods may simplify the pairing process of IoT devices and services. The present disclosure will implement user authentication for C2C pairing, TAGs for D2C based pairing, apparatus and methods for obtaining device information from scanned TAGs, and apparatus and methods for performing the pairing process of C2C or D2C.

The present disclosure will bring the following advantages to the user, such as: 1) easy pairing; the present disclosure may allow for auto-pairing of IoT devices with IoT services and simply identify an IoT device using a tag-based identifier (image tag or radio tag), regardless of its vendor or standard; 2) a single application pair; the present disclosure may allow users to pair their IoT devices from different vendors using the C2C mechanism from only a single IoT application and connect the IoT devices to external IoT services rather than installing an IoT application for each IoT vendor; 3) flexible pairing; the user may enjoy the flexibility of selecting a compatible IoT service that he/she wants to connect to his/her IoT device without difficulty.

Embodiments of the disclosure herein may have two main features. First, embodiments herein will enable a seamless pairing process of IoT devices and IoT services in a heterogeneous IoT ecosystem by building an auto-pairing module (APM) that seamlessly automates the pairing process using IoT information, user preferences, and/or custom pairing steps and with an IoT information service that provides IoT device information and IoT service information for enabling the auto-pairing process. Second, embodiments herein will include cloud-to-cloud (C2C) pairing between the primary IoT service and the external IoT service and device-to-cloud (D2C) pairing between the IoT device and the IoT service, which proceeds with the C2C pairing process simply and user-friendly by pairing via the user authentication application C2C and with the D2C pairing process seamlessly and automatically via the tag (visual or radio) identifier application D2C. For seamless and automatic pairing, embodiments herein may disclose systems for storing and retrieving IoT device information based on tag information and systems that may automatically generate and perform pairing procedures based on IoT device information provided by an IoT information service.

The embodiments and their advantages are best understood by referring to fig. 1 through 25. Accordingly, it is to be understood that the embodiments of the disclosure herein are merely illustrative of the application of the principles of the disclosure. Reference herein to details of the illustrated embodiments is not intended to limit the scope of the claims, which themselves recite features regarded as essential to the disclosure.

Fig. 1 is an illustration of an IoT ecosystem supporting C2C and/or D2C pairing mechanisms in accordance with an embodiment of the disclosure.

Referring to fig. 1, the IoT ecosystem 100 can include various entities such as a primary IoT service entity 110, an external IoT service entity 120, an external IoT information service entity 130, at least one IoT device (e.g., device a142, device B144), a client device 150, an external tag reader 160, and at least one IoT vendor (e.g., IoT vendor a 172, IoT vendor B174), but the entities are not limited thereto.

The primary IoT service entity 110 according to an embodiment may act as a service integrator. The primary IoT service may be the primary IoT service of the IoT ecosystem 100. For example, the primary IoT service may include a web service. The primary IoT service entity 110 may include an internal IoT information service entity including, but not limited to, an IoT information manager, a parser, a generator, a security module, a C2C module, a D2C module, an APM, a storage module, and an IoT service API.

According to an embodiment, the external IoT service entity B120 may be a third party network service related to the IoT. Further, the external IoT information service 130 may be a web service that provides information about IoT devices and/or IoT services used for the C2C or D2C pairing process. The

IoT devices

142, 144 may be devices that may be paired with at least one IoT service and/or at least one IoT device. The

devices

142, 144 may have tags attached to enable pairing with IoT services. The client device 150 may include at least one IoT service application and/or a tag reader. The IoT application may be a front-end application that manages IoT devices and IoT services and is able to start the D2C and C2C pairing. The external tag reader 160 may add or extend the client device 150's ability to read tags in the

IoT devices

142, 144 that may be used in the pairing process of the

IoT devices

142, 144. Each of

IoT vendors

172, 174 may be developers that develop IoT devices and/or IoT services.

According to an embodiment, the primary IoT service entity 110 may be minimally connected to the network and may include at least one of the following entities: a C2C module 1101 that manages communications between the primary IoT service and at least one external IoT service; a D2C module 1103 that manages communications between IoT devices and IoT services; an Auto Pairing Module (APM)1105 that automatically generates and performs the pairing steps of D2C or C2C; a security module 1107 that manages security-related steps (internal and external) including: authentication, authorization and verification; a storage module 1109 that manages data and information related to IoT services, IoT devices, and user preferences; and an IoT service API 1111 that may provide an IoT application (i.e., a mobile application or a website) for the primary IoT service and may provide third party developers with access rights to view and manage the primary IoT service. Meanwhile, the external IoT service may be minimally connected to the network and have an API that may be used by the primary IoT service to do C2C pairing and help the IoT device pair with the external IoT device. The information about the external IoT service may be used as IoT service information stored in the IoT information service.

Referring now to fig. 1, IoT information services (e.g., internal IoT information service 1113, external IoT information service 1130) may include at least one of: an IoT information manager that may have a task of managing IoT device information and IoT service information added by at least one IoT vendor; a storage device that may have the task of storing, retrieving, and managing IoT information data; a parser that may have the task of parsing information to extract data of the IoT information manager; and a generator, which may have the task of generating IoT information (including tag information). The client device 150 may be a device capable of connecting to a network, using an IoT application, and reading tags in the IoT device. The client device 150 may include the following entities: such as a tag reader, which may have the task of reading tags in IoT devices; an IoT application that may provide a user interface to conduct the C2C and D2C pairing process, view and manage IoT services and IoT devices connected to the primary IoT service; and an external TAG reader, which may have the capability to connect to the client device 150, read TAGs in the IoT device, and send TAG information to the client device 150.

In one embodiment, an electronic device for providing end-to-end automatic interconnection of IoT devices and systems within a heterogeneous IoT ecosystem may comprise: a memory configured to store one or more instructions; and at least one processor configured to execute the one or more instructions to: obtaining a pairing request to perform at least one of a cloud-to-cloud (C2C) pairing or a device-to-cloud (D2C) pairing; obtaining pairing information based on the pairing request, the pairing information including at least one of information about an external IoT service to be paired with the primary IoT service or information about an IoT device to be paired with the IoT service; generating a pairing step model based on the pairing information and the pairing request; and performing at least one of a C2C pairing process between the primary IoT service and the external IoT service or a D2C pairing process between the IoT service and the IoT device based on the pairing step. In one embodiment, the electronic device may perform user authentication of the external IoT service based on the pairing request to authorize the primary IoT service to access and use an Application Program Interface (API) of the external IoT service, perform the C2C pairing process in the primary IoT service and the external IoT service, and perform the API of the external IoT service from the primary IoT service.

In one embodiment, an electronic device may enable a pairing state in an IoT device, wherein the IoT device may pair with at least one of a supported IoT service or a supported IoT hub, obtain pairing information including information about at least one IoT service selected by a user, perform a D2C pairing process between the IoT device and the at least one IoT service, and perform at least one function of the IoT device from the at least one IoT service.

In one embodiment, the electronic device may obtain information about the IoT hub selected by the user, send a pairing request to the IoT hub for D2C pairing based on the information about the IoT hub, and perform the D2C pairing procedure via the IoT hub selected by the user.

In one embodiment, the electronic device may request a cloud-to-cloud (C2C) module or a device-to-cloud (D2C) module to start a C2C pairing process or a D2C pairing process according to the performance of the pairing step.

In one embodiment, the electronic device may obtain tag information by scanning tags of the IoT device and send the pairing request and the tag information to the IoT service via the IoT application.

In one embodiment, the electronic device may construct custom pairing steps (including user-defined C2C or D2C pairing steps), obtain a pairing request to enable reading of the custom pairing steps, and load and execute the custom pairing steps in the primary IoT service.

In one embodiment, an electronic device may obtain user selection information including IoT device information about an IoT device selected to be changed from a previous IoT service and IoT service information about an IoT service selected to be a new target to be paired with the selected IoT device; unpairing a previous IoT service with an IoT device; enable a pairing state of an IoT device; and performing D2C pairing between the IoT device and the selected IoT service.

The APM 1105, the C2C module 1101, the D2C module 1103, the security module 1109, the internal IoT information service entity 1113 may be implemented as at least one hardware processor.

The external IoT information service entity 130 may also be implemented as at least one hardware processor.

Fig. 2A illustrates an example of a C2C pairing process from a user perspective, according to an embodiment of the disclosure.

Fig. 2B illustrates an example of the results of a C2C pairing process from a user perspective, according to an embodiment of the present disclosure.

Referring to fig. 2A through 2B, when a user wants to pair an external IoT service with a primary IoT service, a C2C pairing process between IoT services from the user perspective may be conducted. In operation 210, the user may have an IoT device connected to an external IoT service. Further, the user may want to pair the external IoT service with the primary IoT service. In operation 220, the user may select an external IoT service to be paired with the primary IoT service. In operation 230, the user may authenticate himself or herself by logging into an external IoT service authentication page. In operation 240, the primary IoT service will automatically start the pairing process with the external IoT service when the user successfully logs in to the external IoT service. After the C2C pairing process is complete, the user can now monitor and manage the IoT devices in the external IoT service from the primary IoT service, and the IoT devices will behave as if the IoT devices were paired with the primary IoT service.

For example, a user may have IoT device 1, IoT device 2, and IoT device 3, and the user wants to pair the IoT device with IoT service C, which is an external IoT service. IoT service a may be the primary IoT service. Further, the user may select IoT service C to be paired with IoT service a. A user may authenticate himself by logging into the authentication page of IoT service C with a username and password. However, the authentication method is not limited thereto. After the user successfully logs in to IoT service C, IoT service a, which is the primary IoT service, will automatically start the pairing process with IoT service C. After the C2C pairing process is complete, the user can now monitor and manage their IoT devices in external IoT services B and C from IoT service a, and the IoT devices will behave as if those IoT devices were paired with IoT service a as the primary IoT service.

Fig. 3A illustrates a D2C pairing process from a user perspective for a generic IoT pairing application, in accordance with an embodiment of the present disclosure.

Fig. 3B illustrates the results of a D2C pairing process from a user perspective for a generic IoT pairing application, in accordance with an embodiment of the present disclosure.

Referring to fig. 3A through 3B, when a user wants to pair an IoT device with an IoT service, a D2C pairing process from the user perspective for a generic IoT pairing application may be conducted. In operation 310, the user may have an IoT device with a TAG and TAG information of a TAG registered in an IoT information service. For example, the tag may include a quick response code (QR code), a Radio Frequency Identification (RFID), a barcode, and the like, but is not limited thereto. In operation 320, to begin the pairing process, the user may scan a tag on the IoT device using a tag reader from the IoT application. In operation 330, the IoT application will display a list of IoT services compatible with the scanned IoT devices, and then the user may select at least one IoT service that the user wants to connect with the IoT device. In operation 340, the system may seamlessly and automatically begin the pairing process between the IoT device and the IoT service.

Fig. 3C illustrates an example of a D2C pairing process, according to an embodiment of the disclosure.

Referring to fig. 3C, after the D2C pairing process is complete, the user may connect the IoT device to any compatible IoT service selected by the user. One example of a D2C use case is pairing a new smart car with an IoT service. As an example, a user may purchase a new car and want to pair the new car with an IoT service that the user is registered with. A user may start the engine and control the doors and windows inside the smart car via a single IoT application. Another example of a D2D use case is pairing a smart home appliance with an IoT service. As an example, any IoT smart home device of any vendor in the home may be paired with an IoT service via a single IoT application. Another example of a D2D use case is pairing a geographic location tracker with an intelligent map service. As an example, a user may pair a geographic location tracker inside a bicycle with a smart map service, and the user may track the location of the bicycle as it is progressing via a single IoT application.

Fig. 4A illustrates a process of flexible IoT service switching that illustrates the flow of IoT applications when a user wants to switch IoT services, in accordance with an embodiment of the present disclosure.

Fig. 4B illustrates the result of a process of flexible IoT service switching in accordance with an embodiment of the present disclosure.

Referring to fig. 4A through 4B, in operation 410, a user may have at least one IoT device already connected to an IoT service, whether a primary IoT service or an external IoT service. In operation 420, the user may decide to switch from the old IoT service to the new IoT service. The system may then display a list of IoT services that are compatible with the IoT device. The user may select a new IoT service from the list of IoT services. In operation 430, the system may then first begin an IoT service switching process by unpairing the IoT device with the previous IoT service and then pairing the IoT device with the new IoT service. After the process is complete, the user may monitor and manage their devices as usual with features from the new IoT service. According to embodiments, when an IoT service changes its features, price, policies, etc., the cloud may switch users to a more favorable IoT service.

Fig. 5 illustrates a process of bulk pairing of IoT devices using an Automatic Pairing Manager (APM) and custom pairing steps in accordance with an embodiment of the present disclosure.

Referring to fig. 5, embodiments herein may be used to pair IoT devices in a large-scale IoT ecosystem. In the current technology, the pairing process is done by manually searching for IoT devices and manually selecting IoT services for the IoT devices. According to embodiments herein, the process of pairing IoT devices can be easily and automatically conducted via custom pairing steps to pair a particular IoT device with a particular IoT service as predefined. As shown in fig. 5, a process of pairing a number of IoT devices with a particular IoT service is illustrated. The primary IoT service may use a custom pairing step to give the APM rules for pairing a particular IoT device with a particular IoT service. When the IoT application begins pairing IoT devices with IoT services, the APM will perform custom pairing steps and automatically select IoT services to be paired with those IoT devices.

Fig. 6 illustrates a sample scenario on how to use external IoT services to enhance the functionality and capabilities of IoT devices paired with a primary IoT service in accordance with an embodiment of the present disclosure.

Referring to fig. 6, the primary IoT service may give suggestions to users to improve the functionality and capabilities of IoT devices by allowing external IoT services to connect to the primary IoT service. As illustrated in fig. 6, if there are some IoT devices paired with the primary IoT service (such as a smart watch or a smart car), the primary IoT service will check the IoT devices based on the IoT device information and suggest some external IoT services that can be paired with the primary IoT service (e.g., a hospital service for a smart watch or a smart city service for a smart car), so the external IoT service will improve the capabilities and functionality of the paired IoT devices (e.g., a smart watch can call a ambulance or a smart car can use a best route to a hospital when a heart attack occurs). In one embodiment, external IoT services are able to not only pair with IoT devices in the D2C pair, but are also able to provide services and data to third parties using their services.

Fig. 7 illustrates the systems and data required to enable C2C pairing in an IoT ecosystem, according to an embodiment of the disclosure.

Referring to fig. 7, to enable the C2C module to communicate with the external IoT service, the primary IoT service may need to obtain authorization from the external IoT service to execute or invoke an Application Programming Interface (API) using user authentication. The process of performing or invoking user authentication of the API of the external IoT service may be referred to as a "pairing process. Further, the process of executing or calling the API of the external IoT service to unpair or remove data of the unpaired external IoT service may be referred to as a "unpairing process. As illustrated in fig. 7, the C2C module may have the capability to pair the primary IoT service with the external IoT service based on user authentication and to automatically and self-definitively pair the primary IoT service with the external IoT service via the APM.

The name and purpose of each component used to support the C2C pairing as illustrated in fig. 7 is: a primary IoT service, an external IoT service, an IoT information service, an IoT application, an API of the primary IoT service (a set of exposed programming interfaces), a security module of the primary IoT service, a storage module of the primary IoT service, a C2C module of the primary IoT service, an auto-pairing module of the primary IoT service, an API of the IoT information service, an IoT information manager of the IoT information service, a storage of the IoT information service, an API of the external IoT service, a security module of the external IoT service, a primary module of the external IoT service, and a parser of the IoT information service.

Fig. 8A is a flow diagram of C2C pairing between a primary IoT service and an external IoT service in accordance with an embodiment of the present disclosure.

Referring to fig. 8A, in operation 805, a user may select an external IoT service that the user wants to pair with a primary IoT service. In operation 810, an auto-pairing module (APM) will request IoT service information from an IoT information service to obtain information on how and where to start pairing with an external IoT service. If the required information is available, the APM may start the pairing process. In operation 815, the APM requests the security module to start a user authentication process for the external IoT service. In operation 820, after the user authenticates the external IoT service, the response (as a payload/token) from the user authentication process may be saved by the storage module used by the C2C module to execute or invoke the C2C pairing API of the external IoT service. In operation 825, the APM may request the C2C module to execute or call the pairing API of the external IoT service from the location and in the order provided by the IoT service information. In operation 830, the primary IoT service and the external IoT service have been paired with each other when the primary IoT service can access and execute the API of the external IoT service.

Fig. 8B is a flow diagram of a C2C unpairing process between a primary IoT service and an external IoT service in accordance with an embodiment of the present disclosure.

Referring to fig. 8B, in operation 855, the user may select an external IoT service that the user wants to unpaired with the primary IoT service. In operation 860, the auto-pairing module (APM) will request IoT service information from the IoT information service entity to obtain information about the step of starting unpairing with the external IoT service. Based on this information, the APM may begin the unpairing process after the required information is available. In operation 865, the APM will request the C2C module to execute or invoke the unpairing API of the selected external IoT service from the location and in the order provided by the IoT service information. In operation 870, after the selected external IoT service gives confirmation of unpairing, the auto-pairing module will request the storage module to conduct or perform housekeeping to remove unused configuration, payload, and data related to the unpaired external IoT service. In operation 875, the primary IoT service may be unpaired with the external IoT service.

Fig. 9 illustrates the pairing and unpairing process of a C2C module, according to an embodiment of the disclosure.

Referring to fig. 9, a flow diagram of a user interface for performing or making a C2C connection between a primary IoT service and an external IoT service is illustrated. In one embodiment,

operations

910, 920, 930, and 940 may conduct a pairing procedure for external IoT services. In operation 910, the user may select at least one option to perform or conduct C2C pairing in the IoT application. For example, the user may select at least one option to manage the C2C pairing. In operation 920, if the user wants to pair the external IoT service with the primary IoT service, the user may need to select an external IoT service that is not already paired with the primary IoT service. For example, the user may select an IoT service D that is not already paired with the primary IoT service. In operation 930, the IoT application may display a user authentication page for the selected external IoT service. In one embodiment, the user may enter user authentication information and press a login button. For example, the IoT application may display a user authentication page for IoT service D, and the user may enter a username and password to log in to the IoT application. However, this is only one example, and the user may log in using methods other than using a username and password. The method of authenticating the user is not limited thereto. In operation 940, if the user returns the home page of the IoT application, the user may identify or notice the change in the IoT application and system as a response to pairing the external IoT service with the primary IoT service. In one embodiment, the application may display the IoT device from the paired external IoT service.

In another embodiment,

operations

910, 950, 960, and 970 may perform a unpairing process of the external IoT service. In operation 910, the user may select at least one option to perform or conduct C2C unpairing in the IoT application. For example, the user may select at least one option to manage the C2C pairing. In operation 950, when the user wants to unpair the external IoT service from the primary IoT service, the user may select the external IoT service that is paired with the primary IoT service. For example, the user may select IoT service B that has already been paired with the primary IoT service. In operation 960, the IoT application will display a page with a button to remove the IoT service in the IoT application. Further, the user may click on a remove button to continue the unpairing process. In operation 970, if the user returns the home page of the IoT application, the user may identify or notice the change in the IoT application and system as a response to unpairing the external IoT service with the primary IoT service. In one embodiment, the IoT application may hide IoT devices that are paired with external IoT services but not with the primary IoT service.

Fig. 10 illustrates a sequence diagram of a C2C pairing process according to an embodiment of the disclosure.

Referring to fig. 10, the flow of the timing diagram may also illustrate the relevant systems, data, and processes of the C2C pairing mechanism in an IoT environment and its connections displayed on the user interface. In one embodiment, IoT application (D) may send a pairing request to apm (i) to start the pairing process between primary IoT service (a) and external IoT service (B). Further, apm (i) will request IoT service information based on the pairing request. In one embodiment, apm (i) may send an IoT service information request to IoT information service manager (K). In one embodiment, an IoT information service manager (K) may request IoT service information from an IoT information service store (L). The IoT information service store (L) may return IoT service information. Further, apm (i) may receive IoT service information from IoT information service manager (K). In one embodiment, apm (i) may request the necessary additional information (e.g., device information, customization steps, etc.) from the storage module (G). The storage module (G) may return additional information. In addition, apm (i) may begin the build and execute pairing steps. Thus, apm (i) may request a user authentication procedure via the security module (F) to the external IoT service (B). The security module (F) may request user authentication from the external IoT service api (m). In one embodiment, the external IoT service api (m) may return a user authentication form to the IoT application (D) that the user needs to fill in. Further, the IoT application (D) may send user authentication data to the external IoT service api (m). Thus, the external IoT service api (m) may start the authentication and authorization process from the authentication data. In one embodiment, the external IoT service api (m) may return a user authentication response payload (token) to the security module (F) based on the received user authentication data. Furthermore, the security module (F) may save the user authentication response payload (token) to the storage module (G). The security module (F) may send the received payload (token) to the C2C module (H). In one embodiment, apm (i) may send a pairing request to C2C module (H). The C2C module (H) will execute or call the external IoT service api (m) to start the pairing process. The external IoT service api (m) may perform or conduct the pairing step. Further, the external IoT service api (m) returns a pairing response to the C2C module (H). The C2C module (H) sends a pairing response to the apm (i). The apm (i) sends a pairing response to the IoT application (D). Next, the primary IoT service (a) may be paired with the external IoT service (B).

Fig. 11 illustrates the overall mechanism on how an IoT application reads a tag in an IoT device, in accordance with an embodiment of the present disclosure.

Referring to fig. 11, embodiments herein illustrate how a user may scan a tag on an IoT device. Using a tag (visual or radio) as an identifier of an IoT device is one of the main entities in embodiments herein that identify various heterogeneous IoT devices available on the market. The tag itself may include information that retrieves IoT device information in the IoT information service entity. To enable the pairing process to be performed or conducted between the IoT device and the IoT service, the client device may have an IoT application that sends tag information to the IoT service, a tag reader in the client device or an external tag reader device, and a network connection. For example, the TAG may include a visual TAG (e.g., QR code), a radio TAG (e.g., NFC TAG), and/or a TAG via a wearable device, camera, radio reader, and/or the like, although the TAG is not limited thereto.

Fig. 12 illustrates how an IoT system supports the D2C pairing process in accordance with an embodiment of the disclosure.

Referring to fig. 12, it is illustrated how an IoT system may support a D2C pairing process, which has the following capabilities for the D2C pairing process: reading the tag; obtaining IoT device information from the tag information; creating and executing an automatic pairing step; and pairing the IoT device with an external IoT service.

Fig. 13 is a flowchart illustrating detailed processes and systems to support a device-to-cloud (D2C) IoT pairing mechanism in accordance with embodiments of the present disclosure.

Referring to fig. 13, a user may scan tags in an IoT device. The IoT device itself must be in a paired state (a state in which the IoT device can be paired with the IoT service). There are 2 scenarios for scanning tags based on the tag reader: (1) internal tag reader: the tag reader will scan the tags in the IoT device to obtain tag information; and (2) an external tag reader: the external tag reader will scan the tags in the IoT device to obtain tag information and send the tag information to the IoT application. The tag information and the request to pair D2C may be sent by the IoT application to the primary IoT service a. The primary IoT service a will process the pairing request and tag information in an auto-pairing module (APM) to start the D2C pairing process. The device information in the IoT information service will be obtained using information from the tag information.

Referring to fig. 12 through 13, an Auto Pairing Module (APM) may request IoT device information from an IoT information service based on tag information. The APM may also request additional information, such as custom pairing steps and IoT service information, from the storage module or IoT information service. Upon receiving the IoT device information and/or additional information, the APM will generate a pairing step and perform the pairing step to execute or invoke modules within the primary IoT service. An auto-pairing module (APM) may request the C2C module or the D2C module to start the pairing process according to the execution of the pairing step. Based on the pairing steps, there may be a variety of pairing scenarios between the IoT device and the IoT service, such as: if the IoT device is paired with external IoT service B, the APM will first request or ask the C2C module to start pairing with the C2C of external IoT service B (if not already paired). If primary IoT service a is paired with external IoT service B, the APM will instruct the C2C module to begin the pairing process between the external IoT service and the IoT device; if the IoT device is directly paired with primary IoT service a, the APM will instruct the D2C module to begin the pairing step with the IoT device; if the IoT device is indirectly paired (via the hub) with the primary IoT service a, the APM may instruct the D2C module to execute or invoke the paired IoT hub to perform or conduct the pairing process with the IoT device. If the IoT device is already paired with the IoT service, the user may monitor, control, and manage the IoT device via the IoT application.

Fig. 14A and 14B illustrate D2C pairing by scanning a tab showing a flow of a user interface during a D2C pairing process, according to various embodiments of the present disclosure.

Referring to fig. 14A through 14B, in operation 1410, the user may select at least one option to add at least one new device to handle the D2C pairing. In

operations

1420 and 1430, the user needs to scan the tag attached to the IoT device. For example, in operation 1420, the user may scan a visual tag (e.g., a QR code) attached to the IoT device. For another example, in operation 1430, the user may scan for radio tags (e.g., NFC tags) attached to the IoT devices. In operation 1440, the user may select an IoT service that the user wants to connect to the IoT device. If the user selects the unpaired external IoT service, then in operation 1450, the system may establish a C2C pairing between the external IoT service and the internal IoT service. Further, the system will start D2C pairing between the external IoT service and the IoT device via the C2C module after the C2C pairing process is completed. However, if the user selects a primary IoT service or a paired external IoT service, then in operation 1460, the system may detect that an IoT device needs to connect to an IoT hub, and then the user may select an IoT hub with which the user wants to connect. In operation 1470, the user may return a home page of the IoT application. Further, the user may identify or notice the change in the IoT application and system in response to completion of the pairing process between the IoT device and the IoT service. For example, the IoT application may show the new IoT device as a result of the D2C pairing.

Referring to fig. 15-19, embodiments herein illustrate a detailed sequence diagram of the D2C pairing process. The detailed flow of the timing diagram may also illustrate the relevant systems, data, and processes of the D2C pairing mechanism in an IoT environment, and its connections on the user interface.

Fig. 15 illustrates a detailed sequence diagram of the D2C pairing process according to an embodiment of the present disclosure.

Referring to fig. 15, the flow of the timing diagram may also illustrate the relevant systems, data, and processes of the D2C pairing mechanism in an IoT environment, as well as the connection state on the user interface. In one embodiment, a user may start a pairing mode of an IoT device. A user may obtain tag information of an IoT device by scanning tags in the IoT device using an IoT application. The IoT application may send a pairing request to the APM to begin a pairing process for the IoT device. Further, the APM will request IoT device information according to the pairing request and tag information. In one embodiment, the APM may send a request for IoT device information (including tag information) to an IoT information service via an IoT information service manager. The IoT information service manager will parse the tag information in the IoT information service parser and use the parsed information to request IoT device information from the IoT information service store. The IoT information service store may return IoT device information. Further, the IoT information service manager may return the requested IoT device information to the APM. In one embodiment, the APM may request a custom pairing step from the primary IoT service store (if available). If a custom pairing step is available, the primary IoT service store may return the custom pairing step to the APM. In another embodiment, if the custom pairing step is not available, the APM provides a list of IoT services that support the selected IoT device to the IoT application and shows the list to the user. The IoT application may return the selected IoT service to the APM. In one embodiment, the APM may load several additional information (i.e., user preferences) from the primary IoT service store and/or the IoT information service to complete the requirements for building the pairing step in the APM. The APM may build and perform the pairing step. Further, the APM may instruct modules inside the primary IoT service to perform D2C pairing based on the pairing steps performed. There are 4 scenarios of D2C pairing: unpaired D2C pairing of external IoT services (fig. 16), paired D2C pairing of external IoT services (fig. 17), pairing with D2C of primary IoT services via a hub (fig. 18), and pairing directly with D2C of primary IoT services (fig. 19). Accordingly, the APM may return a pairing response to the IoT application and the IoT device paired with the selected IoT service.

Fig. 16 is a detailed sequence diagram of a D2C pairing process for unpaired external IoT services, according to an embodiment of the present disclosure.

Referring to fig. 16, the user and the system may perform a pre-pairing process as the D2C pairing shown in fig. 15. In one embodiment, the APM may instruct the C2C module in the primary IoT service to make or perform C2C pairing with the selected and unpaired external IoT service (fig. 10). After the primary IoT service and the external IoT service are paired with each other, the APM may instruct the C2C module to generate a D2C pairing request by calling the pairing API of the external IoT service to perform pairing with the IoT device. The external IoT service may begin a pairing process with the IoT device. Further, the IoT device may begin a pairing process with an external IoT service facilitated by the IoT application. IoT (IoT)The device may return a pairing response to the external IoT service. The external IoT service may return the pairing response to the primary IoT service via the C2C module. The C2C module may be a general modulePairing responseReturning to the APM. The APM can beFitting for mixing To response toSave to the primary IoT service storage. In one embodiment, the user and system may perform or conduct a post-pairing process as the D2C pairing shown in fig. 15. Next, the IoT device may be paired with an external IoT service.

Fig. 17 is a detailed sequence diagram of a D2C pairing process for paired external IoT services, in accordance with an embodiment of the present disclosure.

Referring to fig. 17, the user and system may conduct or perform a pre-pairing process as the D2C pairing shown in fig. 15. In one embodiment, the APM may instruct the C2C module in the primary IoT service to generate a D2C pairing request to perform or conduct pairing with the IoT device by calling the pairing API of the external IoT service. Thus, the external IoT service may begin the pairing process with the IoT device. Further, the IoT device may begin a pairing process with an external IoT service facilitated by the IoT application. The IoT device may return a pairing response to the external IoT service. The external IoT service may return the pairing response to the primary IoT service via the C2C module. In one embodiment, the C2C module may return a pairing response to the APM. The APM may save the pairing response to the primary IoT service store. The user and system may perform or execute a post-pairing process such as the D2C pairing shown in fig. 15. Thus, the IoT device may be paired with an external IoT service.

Fig. 18 is a detailed sequence diagram of a D2C pairing process between an IoT device and a primary IoT service via a hub, according to an embodiment of the present disclosure.

Referring to fig. 18, the user and the system may perform a pre-pairing process of D2C pairing as shown in fig. 15. In one embodiment, if the custom pairing step is not available, the APM provides a list of IoT hubs supported by the selected IoT device to the IoT application, and the APM may show the list to the user. In another embodiment, the selection of the IoT hub may be made automatically. The user may select an IoT hub for pairing from a list at the IoT application, which may return the selected IoT hub to the APM. Further, the APM may instruct the D2C module in the primary IoT service to generate a D2C pairing request to perform pairing with the IoT device by calling the pairing API of the IoT hub. In one embodiment, the IoT hub may begin a pairing process with the IoT device. The IoT device may begin a pairing process with an IoT hub assisted by the IoT application. Further, the IoT device may return the pairing response to the IoT hub, which may then return the pairing response to the primary IoT service via the D2C module. The D2C module may return a pairing response to the APM. In one embodiment, the APM may store the pairing response to the primary IoT service store. The user and system may perform a post-pairing process as the D2C pairing shown in fig. 15. Thus, the IoT device may be paired with the primary IoT service via the IoT hub.

Fig. 19 is a detailed sequence diagram of a D2C pairing process between an IoT device and a primary IoT service via a hub, according to an embodiment of the present disclosure.

Referring to fig. 19, the user and system may perform or conduct a pre-pairing process as the D2C pairing shown in fig. 15. In one embodiment, the APM may instruct the D2C module in the primary IoT service to generate a D2C pairing request. The D2C module may begin the pairing process with the IoT device. Further, the IoT device may begin the pairing process with the primary IoT service via the D2C module assisted by the IoT application. The IoT device may return the pairing response to the primary IoT service via the D2C module. The D2C module may return a pairing response to the APM. In one embodiment, the APM may store the pairing response to the primary IoT service store. The user and system may perform or conduct a post-pairing process as the D2C pairing shown in fig. 15. Thus, the IoT device may be paired with the primary IoT service.

Fig. 20 is a block diagram illustrating an IoT information service system and hierarchy in an IoT ecosystem, according to an embodiment of the present disclosure.

Referring to fig. 20, the IoT information service may be used to retrieve or store IoT device information and/or IoT service information used by a primary IoT service. The components of the IoT information service and their connections to the primary IoT service may include: an IoT information manager, which is a module for registering, retrieving and managing data inside an IoT information service; a storage module, which is a module for loading and storing tag information, IoT device information, and IoT service information; a parser, which is a module for parsing information to extract data that can be understood by the IoT information manager; a generator which is a module for generating information (including tag information from device information); and an API that is an interface to communicate with another IoT entity.

As illustrated in fig. 20, in order to make IoT device information available in an IoT information service, an IoT provider may need to register its IoT device information into the IoT information service. The steps can be divided into 2 categories: registering IoT device information for existing tag information (steps 1, 2, 3) and registering IoT devices without tag information (steps 1, 4, 5).

Fig. 21A is a flow diagram of obtaining IoT device information in accordance with an embodiment of the present disclosure.

Referring to fig. 21A, in operation 2105, a tag reader may read a tag of tag information. The tag reader may send the tag information to the IoT application. The IoT application may send the tag information to an IoT service. In operation 2110, the IoT service may request IoT device information by transmitting the tag information to the IoT information service. In operation 2115, the system may detect whether the IoT service has a tier 1IoT information service.

In one embodiment, if the IoT service has a tier 1IoT information service, the IoT information manager may request the parser to extract information of the tag information in operation 2120. The IoT device information in the storage may be requested using the information. The response from the storage device may be sent to the IoT information manager. In operation 2125, the system may check whether device information is available. If device information is available, the IoT information manager may return the IoT device information to the IoT service in operation 2130. However, if device information is not available, the IoT information manager may request the parser to extract tag information. The information may be used to request IoT device information in the storage in operation 2135. Further, a response from the storage device may be sent to the IoT information manager.

In another embodiment, if the IoT service does not have a tier 1IoT information service, the IoT information manager may request the parser to extract tag information in operation 2135. The IoT device information in the storage may be requested using the information. The response from the storage device may be sent to the IoT information manager. In operation 2130, the IoT information manager may return IoT device information to the IoT service.

Fig. 21B is a flow diagram of registering IoT device information in accordance with an embodiment of the present disclosure.

Referring to fig. 21B, in operation 2155, the IoT provider may upload its IoT device information to the IoT information service. In operation 2160, the system may check or identify whether the IoT information service already has tag information. In one embodiment, when the IoT information service already has tag information, the IoT provider may also upload the tag information to the IoT information service in operation 2165. In operation 2170, the IoT information manager may request the parser to extract the tag information. The information may be used as a key for saving the IoT device information to the storage. In operation 2185, the IoT information manager may return the tag information as a registration response.

In another embodiment, if the tag information does not exist, the IoT information manager may request the generator to generate tag information for uploading IoT device information in operation 2175. In addition, the generator may return tag information. In operation 2180, the IoT information manager may store or save the IoT device information with the key from the tag information to a storage. In operation 2185, the IoT information manager may return the tag information as a registration response.

Referring to fig. 21A through 21B, there are two hierarchies of IoT information services to provide information on IoT device information and/or IoT service information. To pair, the primary IoT service should connect with at least one IoT information service.

Fig. 22A is a block diagram of a process of registering IoT device information when tag information already exists, in accordance with an embodiment of the present disclosure.

Fig. 22B is a block diagram of a process of registering IoT device information without tag information in accordance with an embodiment of the present disclosure.

Fig. 22C is a block diagram of a process for obtaining IoT device information, in accordance with an embodiment of the present disclosure.

The hierarchical category of the IoT information service as disclosed in fig. 20 through 22C may be a hierarchy 1 called an internal IoT information service, and may be an IoT information service used internally in the IoT service. The service may generally be used to retrieve device information of the homemade device or supported external IoT services. If there are no available devices in tier 1 or if tier 1 is not available, the IoT service should go to tier 2 of the IoT information service. And tier 2, referred to as an external IoT information service, is an IoT information service that can share information with other IoT services.

Referring to fig. 20 through 22C, embodiments herein may disclose a step-by-step process for registering IoT device information for an IoT device. To perform D2C pairing, the APM may require IoT device information from an IoT information service. IoT device information may be retrieved by sending tag information to an IoT information service. The following is a step-by-step process for registering IoT device information: the IoT provider may upload its IoT device information into the IoT information service; if the IoT provider has tag information of its IoT device, the IoT provider may upload the tag information to the IoT information service via the IoT information manager; the IoT information manager may request the parser to parse the tag information and use the parsed information as key information to save the IoT device information into the storage; if the IoT provider does not have the tag information of the IoT device, the IoT information manager builds tag information for the uploaded device information with the request generator; when the IoT provider does not have the tag information of the IoT device, if the IoT information manager requests the generator to construct the tag information for the uploaded device information, the IoT information manager may request the storage to store or maintain the IoT device information and key information from the generated tag information; the IoT information manager may receive the registration response from the storage and the tag information from the generator. Further, the registration response and the tag information will be transmitted to the IoT provider via the IoT information manager.

Referring to fig. 20 through 22C, embodiments herein may disclose a step-by-step process of obtaining device information for scanned IoT devices as follows: the IoT application may scan for tags from the IoT device, and the IoT application may send tag information to the primary IoT service; the primary IoT service, via its module (i.e., APM), will request IoT device information from the IoT information service. The primary IoT service may first check whether the primary IoT service has an IoT information service (tier 1); if an IoT information service (tier 1) is available, the primary IoT service may instruct an IoT information manager (tier 1) to obtain IoT device information. The IoT information manager (tier 1) may request the parser to extract key information from the tag information. The IoT device information in the storage may be requested using the key information. The response from the storage device may be sent to the IoT information manager (tier 1). If the IoT information service (tier 1) is not available, the primary IoT service may instruct the IoT information manager (tier 2) to obtain IoT device information. The IoT information manager (tier 2) may request the parser to extract key information from the tag information, which may be used to request IoT device information in the storage. A response from the storage may be sent to the IoT information manager (tier 2); the IoT information manager may return the IoT device information to the primary IoT service.

Fig. 23 is a block diagram illustrating an APM system for D2C or C2C pairing to automate the pairing process between an IoT device and an IoT service in accordance with an embodiment of the present disclosure.

Referring to fig. 23, the APM will generate and execute a pairing step, where the model represents how the pairing process should proceed. The pairing step may include, but is not limited to, device/service configuration, pairing protocols, pairing rules, and additional information required for the pairing process. The data that can be used by the APM to generate the pairing step is: tag information, which is information on a tag; IoT device information that is information of a device including capabilities, supported protocols, and supported IoT services; IoT service information, which is information of IoT services including capabilities, pairing methods and steps, supported protocols, and supported external IoT services; user preferences, which are information set by a user including device configuration, service configuration, user configuration, and network configuration; and a self-defining pairing step, which is a self-defining step set by the user for a specific situation.

Fig. 24 is a flow diagram of an automatic pairing procedure for performing D2C or C2C pairing, according to an embodiment of the disclosure.

Referring to fig. 24, embodiments herein may illustrate a process of generating a pairing step and performing the pairing step to process a D2C or C2C pairing. The detailed process of how the APM works to automate the pairing process is: the APM may obtain a request from a user to perform pairing. The APM manager will receive the request and instruct the loader, preprocessor and APG (automatic pairing generator) sub-modules to create a pairing step based on the user's request; based on the user's request, the APM may request the loader submodule to obtain and read tag information, IoT device information, IoT service information, user preferences, and/or custom pairing steps from its respective source; based on the user request, the APM may pre-process in a pre-processor sub-module to merge several pieces of collected information, remove unnecessary data in the information and parse and convert previously processed information into data that can be understood by an Automatic Pairing Generator (APG); based on the user request, the APM will generate a pairing step via an Automatic Pairing Generator (APG). The APG will create a model from data that can be executed by an Automatic Pairing Executor (APE) (pairing step); an Automatic Pairing Executor (APE) will perform the pairing steps received from the APG. The APE will execute or call the module/service and perform the steps indicated by the pairing step. An Automatic Pairing Executor (APE) returns a response to the user via the APM manager for each pairing step execution. The manager, loader, preprocessor, generator, and executor may be implemented as at least one hardware processor. In an embodiment, the at least one hardware processor may be processor 2510.

Referring to fig. 25, electronic device 2500 may include a processor 2510, a transceiver 2520, and a memory 2530. However, all illustrated components are not required. The electronic device 2500 may be implemented with more or fewer components than illustrated in fig. 25. Further, according to another embodiment, processor 2510 and transceiver 2520, as well as memory 2530, may be implemented as a single chip. The foregoing components will now be described in detail.

Processor 2510 can include one or more processors or other processing devices that control the proposed functions, processes, and/or methods. The operations of the electronic device 2500 may be performed by the processor 2510. In one embodiment, processor 2510 can receive a pairing request to perform at least one of a cloud-to-cloud (C2C) pairing or a device-to-cloud (D2C) pairing. Further, the processor 2510 can obtain pairing information based on the pairing request, the pairing information including at least one of information about the external IoT service or information about the IoT device. The processor 2510 can generate a pairing step based on the pairing information and the pairing request, and perform at least one of C2C pairing between the primary IoT service and the external IoT service or D2C pairing between the IoT service and the IoT device based on the pairing step.

Transmitter 2520 may be connected to processor 2510 and transmit and/or receive signals. The signals may include control information and/or data. For example, transceiver 2520 may receive signals over a wireless channel and output signals to processor 2510. Transceiver 2520 may transmit the signal output from processor 2510 over a wireless channel.

The memory 2530 may store control information and/or data included in signals obtained by the electronic device 2500. Memory 2530 may be connected to processor 2510 and store at least one instruction or protocol or parameter for the proposed function, procedure, and/or method. The memory 2530 may include Read Only Memory (ROM) and/or Random Access Memory (RAM) and/or a hard disk and/or CD-ROM and/or DVD and/or other storage devices.

Embodiments of the present disclosure may be embodied as a computer-readable recording medium (e.g., a program module to be executed in a computer) including computer-readable instructions. Computer readable recording media can include any available media, volatile and nonvolatile media, and removable and non-removable media that can be accessed by a computer. Also, the computer-readable recording medium may include computer storage media and communication media. Computer storage media includes all volatile and nonvolatile, and removable and non-removable media implemented in the art to store information including computer readable instructions, data structures, program modules, or other data.

While the disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents.

Claims

1. An electronic apparatus for pairing between a device and a service, the electronic apparatus comprising:

a memory configured to store one or more instructions; and

at least one processor configured to execute the one or more instructions to:

receiving a pairing request to perform at least one of a cloud-to-cloud (C2C) pairing or a device-to-cloud (D2C) pairing,

obtaining pairing information based on the pairing request, the pairing information including at least one of information about an external Internet of things (IoT) service or information about an IoT device,

generating a pairing based on the pairing information and the pairing request, an

Performing at least one of the C2C pairing between a primary IoT service and the external IoT service or the D2C pairing between an IoT service and the IoT device based on the pairing step.

2. The electronic device of claim 1, wherein to perform at least one of the C2C pairing or the D2C pairing, the at least one processor is further configured to execute the one or more instructions to:

obtain a user selection of the external IoT service,

conducting user authentication of the external IoT service to authorize the primary IoT service to access and use an API (application program interface) of the external IoT service based on the pairing request, and performing the C2C pairing in the primary IoT service and the external IoT service and the API of the external IoT service from the primary IoT service,

wherein the pairing request includes information about an external IoT service that performed the C2C pairing.

3. The electronic device as set forth in claim 1,

wherein to perform at least one of the C2C pairing or the D2C pairing, the at least one processor is further configured to execute the one or more instructions to:

obtaining a user selection of the IoT device,

activating a pairing state in the IoT device, wherein the IoT device is to be paired with at least one of an IoT service or an IoT hub,

obtaining pairing information including information about at least one IoT service selected by a user of the electronic device,

performing the D2C pairing procedure between the IoT device and the at least one IoT service, an

Performing at least one function of the IoT device according to the at least one IoT service,

wherein the pairing request includes information about an IoT device performing the D2C pairing, an

Wherein the at least one IoT service supports pairing with the D2C of the IoT device.

4. The electronic device as set forth in claim 1,

wherein the at least one processor is further configured to request a C2C module to begin the C2C pairing or a D2C module to begin the D2C pairing based on the performing of the pairing step, and

wherein the pairing step includes at least one of a pairing step between the IoT device and the primary IoT service, a pairing step between the IoT device and a paired external IoT service, a pairing step between the IoT device and a unpaired external IoT service, or a pairing step between the IoT device and the IoT service via an IoT hub.

5. The electronic device as set forth in claim 1,

wherein the pairing step comprises a pairing step between the IoT device and the IoT service, an

Wherein the at least one processor is further configured to:

obtaining tag information by scanning tags of the IoT device, an

Sending the pairing request and the tag information to the IoT service via an IoT application.

6. The electronic device as set forth in claim 1,

wherein the pairing step comprises automatic C2C pairing or automatic D2C pairing using a preset configuration,

wherein the generating the pairing step comprises: generating a custom pairing step comprising a user-defined C2C or D2C pairing step, an

Wherein the at least one processor is further configured to:

obtaining a pairing request to enable reading of the custom pairing step, an

Loading and executing the custom pairing step in the primary IoT service.

7. The electronic device as set forth in claim 1,

wherein the pairing step includes a flexible IoT service handoff,

wherein the at least one processor is further configured to:

obtaining user selection information including IoT device information about the IoT device selected to be changed from a previous IoT service and IoT service information about the IoT service selected to be a new target to be paired with the selected IoT device, and

unpairing the previous IoT service with the IoT device, and

wherein the performing at least one of the C2C pairing or the D2C pairing comprises: activating a pairing state of the IoT device and performing the D2C pairing between the IoT device and the selected IoT service.

8. A method of an electronic device, the method comprising:

receiving a pairing request to perform at least one of a cloud-to-cloud (C2C) pairing or a device-to-cloud (D2C) pairing;

obtaining pairing information based on the pairing request, the pairing information including at least one of information about an external Internet of things (IoT) service or information about an IoT device;

9. The method of claim 8, the method further comprising:

obtaining a user selection of the external IoT service; and

perform user authentication of the external IoT service to authorize the primary IoT service to access and use an Application Program Interface (API) of the external IoT service based on the pairing request,

wherein the performing at least one of a C2C pairing or a D2C pairing comprises:

performing the C2C pairing in the primary IoT service and the external IoT service, an

The API to execute the external IoT service from the primary IoT service, an

10. The method of claim 8, the method further comprising:

obtaining a user selection of the IoT device,

enabling a pairing state in the IoT device, wherein the IoT device is capable of pairing with at least one of an IoT service or an IoT hub;

obtaining the pairing information including information about at least one IoT service selected by a user; and

performing at least one function of the IoT device from the at least one IoT service,

wherein the performing at least one of a C2C pairing or a D2C pairing comprises: performing the D2C pairing procedure between the IoT device and the at least one IoT service,

11. The method of claim 8, the method further comprising:

requesting a C2C module to begin the C2C pairing or requesting a D2C module to begin the D2C pairing based on the performance of the pairing step,

12. The method of claim 8, the method further comprising:

obtaining tag information by scanning tags of the IoT device, an

Sending the pairing request and the tag information to the IoT service via an IoT application,

wherein the pairing step comprises: pairing the IoT device with the IoT service.

13. The method of claim 8, the method further comprising:

generating a custom pairing step comprising a user-defined C2C or D2C pairing step;

obtaining a pairing request to enable reading of the custom pairing step; and

loading and executing the custom pairing step in the primary IoT service,

wherein the pairing step comprises automatic C2C pairing or automatic D2C pairing using a preset configuration.

14. The method of claim 8, the method further comprising:

obtaining user selection information including IoT device information about the IoT device selected to be changed from a previous IoT service and IoT service information about the IoT service selected to be a new target to be paired with the selected IoT device;

unpairing the previous IoT service with the IoT device;

activating a pairing state of the IoT device; and

performing the D2C pairing between the IoT device and the selected IoT service,

wherein the pairing step comprises a flexible IoT service handoff.

15. A computer program comprising code instructions for implementing a method according to any one of claims 8 to 14.