CN107957884B - Method for electronically obtaining instruction commands for an electronic device - Google Patents

Abstract

The present invention relates to a method for electronically obtaining instruction commands for an electronic device. The present invention provides a method and system that enables interoperability between internet capable devices and online applications without the need to previously agree on device standard formats between manufacturers and applications as is conventional. The application can connect, control and activate the newly added device at runtime.

Description

Method for electronically obtaining instruction commands for an electronic device

Technical Field

The present invention relates to a method for electronically obtaining instruction commands for an electronic device, and in particular, to a method and system for enabling a cloud-based application to automatically integrate network function sensors during runtime.

Background

Physical objects and people may be equipped with networked sensors to connect to cloud-based computing systems (applications) that track and/or motivate (act) the performance, environmental information, and location of objects, and may track health conditions. This correlation is the so-called Internet of Things (Internet of Things) or IoT and is growing rapidly.

It is estimated that more than 90 million devices in the world, including computers, tablets, and smart phones, are connected to the internet. According to an estimate of 2 months in 2013, the number is expected to grow to the range of 500 to 1 trillion devices in the next decade. But all technical issues are not yet in place to support this growth rate. Device manufacturers need to agree on standards or application providers need to have a way to learn and adapt to each sensor protocol. IoT applications will require additional capabilities to build and maintain integrated systems until such interoperability between devices and cloud-based computing systems is widely available.

IoT devices may be of various types including the following: medical pendants, smart watches, LED lights, industrial machines covering the field of health care, wearable devices, home automation devices (e.g., appliances), smart phones, computers, energy grid systems, and even automobiles. These IoT devices generate data in a form that is processed by a data analysis system in the application, resulting in logical information to direct further actions in a local or remote manner. However, the data analysis system in the cloud cannot interpolate all the dataforms generated by each IoT device at that time. To do this, the manufacturer would need to agree on the standard and share the language that would enable interoperability between IoT devices and applications.

There are broad standards in other technologies. For example, digital imaging and communications in medicine, DICOM, is a standard in the medical imaging industry. DICOM includes file formats and communication protocols. As long as the manufacturers comply with the DICOM standard, medical images produced by these manufacturers can be displayed for diagnosis, processing, storage, printing, and transmission in hospitals and healthcare facilities worldwide. Given this wide range of IoT device categories, from soil moisture monitors to motion detectors to heartbeat meters, the standard formats and protocols to achieve full interoperability of IoT devices are not an easy task. Not to mention that the cost of IoT devices must be reduced to the point where widespread use can be incurred.

These and other problems of the prior art have not been noted or solved by those skilled in the art prior to the invention of the present application. Clearly, for at least the above reasons, the need to provide a global standard for all IoT devices is important. The present invention addresses these and other issues by providing a system and method that reduces the integration processes that have to be understood in order to control and incentivize devices, applications, for any given IoT device command instructions and data formats.

Disclosure of Invention

An improved system and method are disclosed herein that avoid the drawbacks of prior systems and methods while providing additional structural and operational advantages.

The present invention introduces a system (dictionary-like online computing system server) to connect IoT devices and their online applications at runtime so that the applications can control and activate the IoT devices without knowing their command structure and data format. The system reduces the integration process that has to be understood for controlling and activating these devices, applications for IoT device command instructions and data formats.

In one aspect, the system enables manufacturers to enter format and status definitions of the manufacturers' IoT devices and Unique Identifiers (UIDs) of the IoT devices when publishing the devices. The system builds a library of scheduling commands that can be ordered by UID.

On the other hand, the system uses a web service to obtain a hypertext transfer protocol (HTTP) get (get) request from an internet-based application that places the UID of the device instruction set. The UID is used by the system to retrieve the functions of the device's instruction set as well as the data format and/or parameters. The web service of the system then replies to the HTTP transfer (post) request with the complete device command function interface and parameter structure as an extended markup language (XML)/JavaScript object notation (JSON) package. Applications are required to use these functions with the UID to obtain data and send control signals to the IoT devices via the system. In addition, the system makes the application completely transparent to IoT device upgrades and replacements.

The system creates a set of functions with generic interfaces based on the type of device, to summarize commands and their parameter sets based on the lot device data format and status entered by the manufacturer, and builds the set as a library of functions in the system. After receiving an application HTTP get request via a web service, the function name and parameter definitions and their containers (APIs) are encapsulated as XML/JSON format loaded into the application with an HTTP transfer request. This approach is used to isolate applications from known IoT device commands and their structure. At the same time, the system enables applications to effectively interoperate IoT devices to build their solutions by automatically adapting to new devices without modifying the software. The system may be extended to various types of IoT devices and their applications.

According to another aspect of the invention, a method for electronically obtaining an instruction command for an electronic device, comprises the steps of: creating an accessible database for storing information relating to a plurality of electronic devices; registering a new electronic device manufactured, comprising the steps of: assigning a unique ID code to the manufactured new electronic device; correlating the assigned unique ID code with an instruction command for the new electronic device being manufactured; and storing the instruction commands and unique ID codes for the manufactured new electronic devices in the accessible database; receiving an electronic request for an instruction command from an entity of an unknown electronic device, wherein the electronic request includes an ID code of the unknown electronic device; verifying the received ID code for the unknown electronic device against the assigned unique ID code stored in the accessible database to create an identifying electronic device; and releasing an instruction command from the accessible database relating to an ID code for the identified electronic device to the entity.

These and other aspects and objects of the present invention will become more readily apparent to those of ordinary skill in the art upon reading the following detailed description in conjunction with the accompanying drawings.

Drawings

For the purpose of facilitating an understanding of the subject matter sought to be protected, the following is illustrated in the drawings and examples thereof by making the following checks: the subject matter sought to be protected, its construction and operation, and many of its advantages should be readily understood and appreciated, when considered in connection with the following description.

Fig. 1 is a flow diagram illustrating a first step of a workflow (i.e., registering a new IoT device). Fig. 1 is a manufacturer registration process for a new IoT device prior to release. Since new IoT devices may adopt various classes and device types, the system provides a user interface to handle domain information (model class), IoT device type (data structure) to create data formats according to rules. The system creates a library of functions to wrap the commands and their parameters. The system maintains a library of functions and builds the library of functions into a database that can be sorted by UID/URI.

Fig. 2 is a command structure block, and is a block diagram showing the structure of each command of the IoT device.

Fig. 3 illustrates how an internet-based application uses the system to adapt to a registered unknown IoT device, and how the application automatically adapts to an unknown IoT device without directly connecting with the manufacturer of the IoT device through the use of the system.

Fig. 4 is an architecture implementing the concept, and shows a schematic diagram of an embodiment of an architecture implementing the concept.

Fig. 5 shows the contents of the HTTP "get" request, and shows the contents of the HTTP "get" request from the application to the system. The application web service makes an HTTP "get" request to the system along with the UID. The system is required to provide a function pointer to the control command for a particular IoT device. The system extracts the UID and registers the application. The system uses the UID to retrieve the functions for the IoT devices and their command format XML files that can learn the command details.

Fig. 6 shows the contents of an HTTP transfer request, and shows the contents of an HTTP "transfer" request from the system to the application. The system web service makes an HTTP transfer request to the application after receiving the request. The system web service provides the function points of the required commands and their parameters. The system web service also includes a command format structure that the application programmatically extracts and constructs function calls.

XML, and shows the command definition of XML-format.

Detailed Description

While this invention is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail at least one preferred embodiment of the invention with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and is not intended to limit the broad aspect of the invention to any of the specific embodiments illustrated.

Referring to fig. 2, the IoT device preferably includes each of the following features:

1. embedded software version-which represents the specific characteristics of the IoT device and the date of market. The system needs to be assigned to possibly different function libraries.

2. Unique Identification (UID) -which is the ID of the IoT device. The UID must be unique in general. The UID may combine our input with the device's manufacturing serial number.

3. Method of encryption-which represents an encrypted format such as 32-bit or 128-bit encryption.

4. Command verification-it provides a way to self-verify the correctness of a command by adding the hexadecimal values of the command.

5. Date (MM: DD: YYYY) -which represents the date on which the command was issued.

6. Time (HH: MM: SS) -which represents the time at which the command is issued.

7. Time zone-it represents a uniform standard time region in which the device is located.

8. Type of device-considering the category, the type of device may be a "watch", "sphygmomanometer" or "pedometer".

9. The device is reserved-it leaves a container for manufacturing use.

10. Command type-it represents different commands provided by the device. Two main categories are terminal-to-server commands and server-to-terminal commands.

11. Parameters-which represent the number of parameters in the command and the size of each parameter (such as 4 bytes or 128 bytes).

The integration and use of a new IoT device is described below with reference to fig. 3:

1. the manufacturer registers a new IoT device in the system before it is brought to market (the registration process is shown in fig. 1);

2. after successfully registering a new device, the manufacturer places a return UID into the device. The new device is ready to be plugged into the internet for use;

the IoT device is purchased by a solution provider that combines the IoT device and the application to provide a solution to the customer;

4. the manufacturer issues a Unique Identification (UID) of the IoT device to the solution provider;

5. the solution provider sends the UID to the application provider. The application can provide the UID to its system via the management software interface. Since no integration has been done previously, the application lists the unknown device internally;

6. the application may use a generic API to control and activate the device through the UID, or apply an HTTP "get" request to the system to get the function point and parameter configuration (see fig. 5);

7. the system will sort within its database by using the UID. The system returns a function pointer matching the parameter settings using an HTTP "transfer" request;

8. the application completes the integration for the new IoT device (see fig. 6);

9. cloud-based applications can now acquire data of the device and incentivize accordingly.

Referring to FIG. 4, the architecture that implements the concept includes the following components:

1. data communication server-it communicates with application platforms and IoT devices on the network. It obtains manufacturing input command information to convert each command into a function that summarizes the command and isolates the device command from the calling party. The server communicates with the application using HTTP get/transmit requests so that the application can use the function to call the IoT device instead of using IoT device commands via the system.

2. Database server-which is a storage unit that stores a library of command formats and command functions (each version of device and each manufacture). The functions may be ordered by UID. And uploading each function to a data communication server for execution.

A web server that provides a web page for manufacturing to enter an IoT device command structure. Feedback is also provided for manufacturing to verify the entered information and commands.

Automatic processing and interpretation of IoT devices with applications requires seamless access and processing across applications and IoT devices. The automatic processing and interpretation includes a generic data format and exchange protocols to provide and describe IoT device data and instruction formats to understand and know how applications are used at runtime. Instead of requiring each IoT device provider to follow standards for data formats and exchange protocols that understand applications, the system provides a mechanism to obtain IoT device data. The mechanism systematically evaluates aspects of the IoT devices: source provider, device class, environment-specific information associated with IoT devices, functional information of IoT devices, logic status, all possible combinations of commands according to data and instruction formats. The organization also considers the diversity of data types, device types, and potential providers within the IoT domain. The system then builds a library of functions to summarize the commands and parameters. These functions can control the target device and obtain data from the device, using the UID of each IoT device on the network. Within the function, the system will deploy a web service to obtain HTTP get requests from applications as XML/JSON format including IoT devices UID. According to the request, the system transmits the request using HTTP to return an XML/JSON formatted file in which the function pointer, the definition of the parameters, and the keeper are placed. The application may use the same HTTP get request method to pass the function pointer with parameters to the system when calling a function call. The system gets the request and calls the function. The feedback from the IoT devices, including the return status and control data, is encapsulated by the system as an XML/JSON file format and uses HTTP transfer requests for the application. The system may provide the application with a library of functions having a generic API that represents the type of device so that the application is completely transparent to different manufacturing devices.

The steps are described in detail in the following sections.

Type class

IoT devices are applicable to, but not limited to, the following categories.

□ home automation-monitoring and controlling lights, safety, temperature and appliances;

□ smart phones and computers-global location, connectivity, data transfer, and applications;

□ wearable electronic device-Apple watch, smart wristband;

□ health care-diagnostic camera system, remote patient monitor, medical pendant, blood pressure monitor with internet function, etc.;

□ Security and Surveillance cameras-web cameras, Canary, and Piper;

□ office and warehouse-printers, HVAC;

□ Industrial machine-sensor detects deteriorated underground concrete water pipes;

□ energy system-smart meter, smart grid, renewable energy system;

□ cars-connected vehicles and intelligent transportation;

□ retail industry-smart payments (using cell phones to make payments), inventory management, smart vending machines;

□ Environment-weather monitoring (temperature, humidity, pressure, etc.), air quality, noise pollution, fire detection, and flood detection;

□ logistics industry-transportation monitoring, vehicle tracking, ship monitoring, and remote vehicle diagnostics;

□ agriculture-intelligent irrigation system for monitoring soil moisture, greenhouse control.

Model categories are used to distinguish these regions.

Data structure

As described in table 1 below, IoT devices provide monitoring and incentives.

TABLE 1

The data structure is used to characterize the IoT device type.

Command structure format

Each IoT device manufacturer is expected to manufacture its devices following an industry standard that is the NEMA standard. For example, a rule is a criterion (independent of its motion detection system) that indicates whether an active or passive motion sensor is present (as defined by the type of device described above) in a system with an active sensor and a system with a passive sensor. The motion sensor includes two sets of command structures: 1) a terminal-to-server command structure; and 2) a server-to-terminal command structure. As shown in Table 2 below, the command structure typically includes version, UID, method of encryption, checksum, date, time zone, type of device, command type, command parameters. The command type includes two different command structures (terminal/server) and a list of commands such as:

[Version，UID，Encryption，Checksum，Date，Time，Time Zone，Type of Devices，Port/IMEI，Command Code，Param1，Param2，…]

based on the command codes, the system can generate a list of commands based on all possible command codes with other elements in the command structure confirmed; such as a device online request after each power-on, a response of the server to the device's request, etc.

Based on the following table, the actual command may look like the following:

[V1.0.0，a1d83kdeio3fg33k，1，abcd，07/21/2015，10：15：33，0800，1，T1，13912345678，V1.0]

note that:

□ type of device: is assigned 1, representing a "watch"

□ Param 1: terminal IMEI code

□ Param 2: version of embedded driver for watch

TABLE 2

Manufacturer input

Based on the model class, data structure, and command structure format, the system provides a manufacturer interface application. The application directs the manufacturer to enter all the required information so that the application can build the command configuration file of fig. 7 as XML. Hereby, the system is able to generate all possible commands from the command code.

In the case of registering a new IoT device in the system (by the manufacturer), the system first identifies a specific domain application of the IoT device from the model class, obtains a data structure by IoT device type, and then builds a data format based on the inputs and rules. The system places the data format in a cloud database managed by the system. The global ordering index for this data format, also referred to as a URI, may be ordered by the UID embedded in each IoT device. The manufacturer can use the UID or URI to pull the data format of the target IoT device immediately from the system to verify through a function call as part of the registration process.

Application integration and invocation

In the case where a new IoT device with a UID is assigned to an application, the application may obtain the data format of the IoT device from the system as meaning to find the unknown command format using the dictionary. The application may invoke the IoT device at runtime via a dictionary with appropriate data formats and parameters, command codes. It is assumed that the application is an internet-based application deployed in conjunction with a class of web services that enables communication with other computers and/or devices on a network via a common data format and protocols such as XML, JSON, and HTTP. The detailed steps illustrated are as follows:

1. the application receives the new IoT device via the UID. The application then uses the HTTP get request to extract the IoT device data format, command structure, and parameters from the system.

2. The system receives the request and retrieves the data format, command structure, and parameters from its database according to the UID.

3. The system uses HTTP transfer requests to send the required data format, command structure and parameter package back to the application as XML/JSON files.

4. The application extracts the command code, format and parameter layout in the XML received from the system. Based on the role of the new IoT device in the solution provided by the application, the application makes a function call to the system via an HTTP get request, where the function is a file of command codes and parameters encapsulated in XML/JSON format.

5. The system obtains a request from the application to invoke a particular IoT device command associated with the application's assigned parameters via the XML/JSON file. The command may control the IoT device or query the information in the field. Control status and/or information will be returned by the system and packaged as an XML/JSON format. The system sends the results to the application using an HTTP transfer request.

6. The application receives a call return value that may be a status of an IoT device, a command return value, and data. This information will be integrated in the solution.

The system may utilize a generic API to provide a library of functions summarizing steps 1-6 described above, depending on the device type. The system makes the application completely independent of the device to be controlled and activated. The system gives the application the ability to automatically adapt to new IoT devices as long as the type of IoT device, such as the one used for temperature, is registered.

The matters set forth in the foregoing description and accompanying drawings are offered by way of illustration only and not as a limitation. While particular embodiments have been shown and described, it will be appreciated by those skilled in the art that changes and modifications may be made without departing from the applicant's contribution in its broader aspects. The actual scope of the protection sought is intended to be defined in the following claims, when viewed in their proper perspective based on the prior art.

Claims (13)

1. A method for electronically obtaining an instruction command for an electronic device, comprising the steps of:

creating an accessible database for storing information relating to a plurality of electronic devices;

registering a new electronic device manufactured, comprising the steps of:

assigning a unique ID code to the manufactured new electronic device;

correlating the assigned unique ID code with an instruction command for the new electronic device being manufactured; and

storing instruction commands and unique ID codes for new electronic devices manufactured in the accessible database;

receiving an electronic request for an instruction command from an entity of an unknown electronic device, wherein the electronic request includes an ID code of the unknown electronic device;

verifying the received ID code for the unknown electronic device against the assigned unique ID code stored in the accessible database to create an identified electronic device; and

releasing an instruction command from the accessible database associated with the ID code for the identified electronic device to the entity.

2. The method of claim 1, wherein the accessible database is a cloud-based database.

3. The method of claim 1, wherein the step of registering further comprises the steps of: information about the device type, data format and command structure of the new electronic device manufactured is stored.

4. The method of claim 1, wherein the information is stored in a computer-readable format.

5. The method of claim 1, further comprising the steps of: feedback is provided to the manufacturer of the new electronic device being registered.

6. The method of claim 1, wherein the step of receiving an electronic request comprises the steps of: the web service is used to communicate with the online application through a single point access interface via an HTTP get request.

7. The method of claim 6, wherein the step of releasing the command comprises the steps of: a transfer request using HTTP via a web service is made for a device on a network.

8. The method of claim 6, further comprising the steps of: a function library having a set of generic programming interfaces, a set of APIs, is built in the accessible database, wherein the set of APIs is capable of controlling and energizing remote electronic devices independent of the manufacturer.

9. The method of claim 1, further comprising the steps of: accessing the accessible database to:

(1) providing an information management and retrieval server serving as a dictionary, and communicating with an online application through a single point access interface using a web service via an HTTP get request capable of directly accessing and retrieving a specific instruction set of a new device in a server of a system and using a transfer request of HTTP via the web service for a device on a network to control and activate the device; and

(2) building a function library, wherein the function library provides the online application with a set of common programming interfaces (APIs) embedded in the application, such that the online application can control and activate a remote electronic device independent of a manufacturer using the set of APIs.

10. The method of claim 1, further comprising the steps of: the qualification of the manufacturer of the manufactured new electronic device is verified.

11. The method of claim 8, further comprising the steps of: confirming that the unique ID code is unique within various fields and industries enables the generic API to use the unique ID code to access the correct instruction command via an appropriate HTTP get request.

12. The method of claim 1, further comprising the steps of: the identified electronic device is removed from the system.

13. The method of claim 1, further comprising the steps of: status information relating to the identified electronic device in service is obtained.

Images