WO2019129271A1

WO2019129271A1 - Method for electronic device authentication and firmware update, and electronic device

Info

Publication number: WO2019129271A1
Application number: PCT/CN2018/125488
Authority: WO
Inventors: Zhongjie WU; Xia Wang; Mingshuai WANG; Jinxiang Shen
Original assignee: Sengled Co., Ltd.
Priority date: 2017-12-29
Filing date: 2018-12-29
Publication date: 2019-07-04
Also published as: CN108199877A; CN108199877B

Abstract

The present disclosure provides a method and a device for electronic device authentication and firmware update. The method includes: when an electronic device initializes, if custom model information is configured in token data, writing the custom model information in the token data into a model attribute value, the token data being stored in an independent storage medium; and sending an authentication request including the model attribute value to an authentication system, such that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication.

Description

METHOD FOR ELECTRONIC DEVICE AUTHENTICATION AND FIRMWARE UPDATE, AND ELECTRONIC DEVICE

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the priority to Chinese Patent Application No. 201711474619.6, filed on December 29, 2017, the entire content of which is incorporated herein by reference.

FIELD OF THE TECHNOLOGY

The present disclosure relates to the field of Internet of Things (IoT) technology. More specifically, the present disclosure relates to a method for electronic device authentication and firmware update, and an electronic device.

BACKGROUND

In an IoT communication protocol such as Zigbee, a device needs to be verified/certified by an authentication system to determine its model identifier and corresponding firmware name. Different model identifiers correspond to different firmware names. The verified device can, according to Over the Air (OTA) specifications under the communication protocol framework, download data to update the corresponding firmware.

In existing technologies, an authentication system needs to determine an actual model identifier of the device according to a model attribute value configured in the device, thereby determining the corresponding firmware name. That is, for devices with different model identifiers, the authentication system needs to perform separate authentications to determine the corresponding different firmware names, and the corresponding devices are upgraded with different firmware.

However, model identifiers of devices are not given based on their basic functions, whereas firmware is provided and matched with different functions. The existing authentication method only uses an actual model identifier of the device as a searching index for authentication, which lacks flexibility to adapt to the various functional possibilities of different devices.

SUMMARY

One aspect of the present disclosure provides an authentication method. The method includes: when an electronic device initializes, if custom model information is configured in token data, writing the custom model information in the token data into a model attribute value. The token data is stored in an independent storage medium. The method also includes sending an authentication request including the model attribute value to an authentication system, such that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication.

Optionally, the custom model information of at least two electronic devices are the same, the at least two electronic devices having different model identifiers.

Optionally, the at least two electronic devices have same or similar functions.

Optionally, the electronic device is a Zigbee device; and the authentication system is a Zigbee authentication system.

Optionally, the method also includes: when the electronic device initializes, if no custom model information is configured in the token data, or if the token data does not exist, writing default model information into the model attribute value.

Optionally, the method also includes: determining that the electronic device is reset to factory settings or has completed firmware update before the electronic device initializes.

Optionally, the method also includes: storing the custom model information into the independent storage medium using a communication serial port or a wireless communication module.

Optionally, the method also includes: when the authentication is completed, performing firmware update using an Over-the-Air (OTA) standard defined by the authentication system.

Another aspect of the present disclosure provides an electronic device including a first writing module and a transmission module. The first writing module is configured to: when the electronic device initializes, if custom model information is configured in token data, write the custom model information in the token data into a model attribute value, the token data being stored in an independent storage medium. The transmission module configured to send an authentication request including the model attribute value to an authentication system, such that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication.

Optionally, the electronic device further includes a second writing module configured to: when the electronic device initializes, if no custom model information is configured in the token data, or if the token data does not exist, write default model information into the model attribute value.

Optionally, the electronic device further includes an update module configured to: when the authentication is completed, perform firmware update using an Over-the-Air (OTA) standard defined by the authentication system.

Optionally, the electronic device further includes the electronic device is a Zigbee device; and the authentication system is a Zigbee authentication system.

In the disclosed electronic device and the disclosed authentication and firmware update method, when the electronic device initializes, if custom model information is configured in the token data, the custom model information in the token data is written into the model attribute value, and an authentication request including the model attribute value is sent to the authentication system, so that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication. The authentication of the device can be accomplished based on customized information, and is no longer limited to the actual model identifier of the device, which increases flexibility of the authentication process.

By writing and using the custom model information, devices having different model identifiers and different firmware names, but same or similar functions (e.g., functions that implemented by same firmware) can be configured with same custom model information. That is, same custom model information can be shared by devices having different model identifiers but same firmware. Thus, the problem of heavy maintenance burden caused by using different model identifiers and firmware names separately can be avoided. It also avoids repeated authentication charges for different firmware names.

In addition, since the token data is stored in a separate storage medium and is not written in the general code section (e.g., operation code) of the electronic device, the custom model information configured in the token data is not lost or changed due to the firmware change of the electronic device or the factory reset of the electronic device. In addition, the model attribute value can be maintained as the same as the custom model information whenever the device is powered on and initialized.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions to be taken in conjunction with the accompanying drawings. The accompanying drawings in the following description show merely some embodiments of the present invention, and a person of ordinary skill in the art may still derive other drawings from these accompanying drawings without creative efforts.

FIG. 1 is a schematic illustrating an application scenario of an electronic device authentication and firmware update process according to an embodiment of the present disclosure;

FIG. 2 is a flowchart of an electronic device authentication process according to an embodiment of the present disclosure;

FIG. 3 is a flowchart of another electronic device authentication process according to an embodiment of the present disclosure;

FIG. 4 is a schematic of an electronic device according to an embodiment of the present disclosure;

FIG. 5 is a schematic of another electronic device according to an embodiment of the present disclosure; and

FIG. 6 is a schematic of a computing terminal according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

Hereinafter, aspects, features, and embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that such description is exemplary only but is not intended to limit the scope of the present disclosure. In addition, it will be understood by those skilled in the art that various modifications in form and details may be made therein without departing from the spirit and scope of the present disclosure.

Features and aspects of the present disclosure will become apparent with reference to the accompanying drawings and non-limiting examples describing various preferred embodiments of the present disclosure.

It will also be appreciated that although the present disclosure has been described with reference to some specific examples, equivalents of the present disclosure can be achieved by those skilled in the art. These equivalents having features claimed in the present disclosure should fall within the scope of protection defined hereinafter.

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that such description is exemplary only but is not intended to limit the scope of the present disclosure. In addition, in the following description, descriptions of well-known structures and techniques are omitted to avoid unnecessarily obscuring the concepts of the present disclosure. Therefore, specific structural and functional details disclosed herein are not intended to be limiting, but are merely used as a basis of the claims to teach those skilled in the art to use the present disclosure in various combinations.

The terms used herein is for the purpose of describing particular embodiments only but is not intended to limit the present disclosure. The words "first" , "second" , "third" , "fourth" , etc. (if present) in the present disclosure, claims, and the accompanying drawings are used to distinguish similar objects without indicating a specific order or sequence. It is to be understood that the data so used may be interchanged as appropriate, such that the embodiments of the present disclosure described herein can be implemented, for example, in a sequence other than those illustrated or described herein. The words “a” , “an” and “the” as used herein should also cover the meanings of “a plurality of” and “a variety of” , unless the context clearly dictates otherwise. In addition, the terms “comprising” , “including” , “containing” and the like as used herein indicate the presence of the features, steps, operations and/or components, but do not preclude the presence or addition of one or more other features, steps, operations or components.

The phrases “in an embodiment” , “in another embodiment” , “in another embodiment” , or “in other embodiments” may refer to the same or different embodiments accordingly to the present disclosure.

FIG. 1 is a schematic illustrating an application scenario of an electronic device authentication and firmware update process according to an embodiment of the present disclosure. Referring to FIG. 1, the application scenario may include an authentication system 1 and one or more electronic devices 2. The electronic device 2 and the authentication system 1 may be connected directly or indirectly. Their connection can be realized in any suitable communication means.

Using Zigbee as an example for this application scenario, the electronic device 2 may be any device that includes a Zigbee communication circuit. Further, the electronic device may be configured to support data download using OTA (Over-the-Air) downloading technology.

OTA downloading technology, or OTA technology, can be understood as a technology for remotely managing data and applications in a subscriber identification module (SIM) card through an air interface of mobile communication (such as GSM or CDMA) . The air interface can be implemented by WAP, GPRS, CDMA1X and short message technology. The application of OTA technology enables mobile communications to be used for providing not only voice and data services, but also new service downloads and/or service updates.

ZigBee protocol uses the physical layer (PHY) and media medium access layer (MAC) defined by IEEE 802.15.4, and defines the network layer (NWK) and the application layer (APL) . The ZigBee Alliance proposes an OTA specification based on the framework of the original protocol. Firmware upgrade/update can be implemented by using such OTA specification. It can be understood that the disclosed embodiments and their alternatives are applicable in the firmware update under the OTA specification.

The authentication system 1 is a system used for device authentication, such as an authentication system compatible with the OTA specification defined by the Zigbee Alliance. The authentication system 1 can be any suitable device, device collection, server, server collection, and the like.

FIG. 2 is a flowchart of an electronic device authentication process according to an embodiment of the present disclosure. The electronic device authentication process may be performed by an electronic device 2 and/or the authentication system 1. As shown in FIG. 2, the electronic device authentication process may include the following.

At S11, the electronic device starts an initialization process.

The initialization process can be any proper initialization routine in the field. For example, initialization process can include: when the electronic device is used for the first time, is reset, or adds a new user for the first time, certain parameters are instantiated, initialized, and/or configured (e.g., assigned with specific values based on a preprogramed routine) . Before the initialization process, the parameters may have no specific content or values. Such parameters can be directed to a user of the electronic device or to the electronic device itself. The parameters may include information characterizing the model of the electronic device. That is, model information of the electronic device may be initialized during the initialization process of the electronic device.

The initialization process can occur at any time after the production of the hardware and software of the electronic device is completed, such as, when a user first turns on the electronic device, when a user performs factory reset on the electronic device, and/or after a firmware update of the electronic device is completed.

At S12: whether custom model information is configured in token data is determined.

Token data can be understood as a record data generated in any proper format. The token data can be configured to include custom model information.

Custom model information can be understood as any suitable information arbitrarily defined by the manufacturer. The manufacturer can configure the custom model information for the electronic device before it leaves the factory. Due to its customization nature, the custom model information can include any information and is not limited to only the actual model identifier of the electronic device. Accordingly, the flexibility of the disclosed authentication method is improved by the configuration of the customized model information.

The token data may be stored in an independent storage medium instead of a storage medium directed to store functional codes and/or user data of the electronic device. In other words, the token data is separately stored in the independent storage medium, for example, a flash memory. Therefore, the system resetting or firmware change of the electronic device does not cause any change to the token data.

The independent storage medium refers to a storage medium separately configured from the main memory of the electronic device. The main memory of the electronic device is configured to store system code, firmware code, usage data, etc. In other words, contents of the independent storage medium does not directly change along with the operation, the initialization or other changes occurred to the electronic device. The independent storage medium may be a flash memory.

If the result of the determination is positive (S12: YES) , that is, if the custom model information is configured in the token data, step S13 is implemented: the custom model information in the token data is written into a model attribute value.

The model attribute value can be understood as a type of attribute value in a data structure defined by a communication protocol. The electronic device needs to assign/specify the model attribute value during the initialization process, in other words, the electronic device needs to perform initialization on the model attribute value. In some embodiments, the process of value assignment or initialization includes: writing the custom model information into the model attribute value. That is, the custom model information is assigned to or used as the model attribute value.

The above steps S11 to S13 can be described as: when the electronic device initializes, if the custom model information is configured in the token data, the custom model information in the token data is written into the model attribute value.

At S14: an authentication request including the model attribute value is sent to the authentication system, so that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication.

When the authentication of the electronic device is completed, the electronic device can perform an update of the firmware according to the over-the-air (OTA) specification determined by the authentication system.

The process of performing the firmware update by using the over-the-air (OTA) specification can be understood by referring to any suitable update process in the field, and the present invention may not be changed. Therefore, any firmware update scheme based on the OTA specification in the field can be applied to the schemes involved in the disclosed embodiment and its alternative embodiments.

In the disclosed electronic device authentication process, when the electronic device initializes, if custom model information is configured in the token data, the custom model information in the token data is written into the model attribute value, and an authentication request including the model attribute value is sent to the authentication system, so that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication. In some embodiments, the model identifier of the electronic device determined by the authentication system may not be the actual model identifier of the electronic device, and the firmware name corresponding to the model identifier determined by the authentication system may not be the actual firmware name of the electronic device. However, the firmware codes corresponding to the model identifier determined by the authentication system must be the same as the actual firmware codes of the electronic device. In other words, as long as the model attribute value reflects correct firmware codes of the electronic device, the electronic device can be authenticated and the firmware update can be successfully performed. The authentication of the device can be accomplished based on customized information, and is no longer limited to the actual model identifier of the device, which increases flexibility of the authentication process.

By writing and using the custom model information, devices having different model identifiers but same or similar functions (e.g., functions that implemented by same firmware) can be configured with same custom model information. That is, same custom model information can be shared by devices having different model identifiers but same firmware. In some embodiments, the electronic devices having different model identifiers but same firmware may be LED lighting devices having different model identifiers but same operating system directed for smart light control. For example, a first LED lighting device may have a first model identifier and a corresponding first firmware name (e.g., image type A) , and a second LED lighting device may have a second model identifier and a corresponding second firmware name (e.g., image type B) . The first firmware and the second firmware are configured to accomplish same functions. By configuring the custom model information of both LED lighting device using the first model identifier, the authentication system may determine the first model identifier and the first firmware name as the model identifier and the firmware name of the second LED lighting device, and authentication of the second LED lighting device can be completed without registering the second firmware again, since actual codes in the second firmware is substantially the same as that in the first firmware. Thus, the problem of heavy maintenance burden caused by using different firmware names (e.g., image type A and image type B) separately can be avoided. It also avoids repeated charges for different firmware authentications.

FIG. 3 is a flowchart of an electronic device authentication process according to an embodiment of the present disclosure. The electronic device authentication process may be performed by an electronic device 2 and/or the authentication system 1. As shown in FIG. 3, the electronic device authentication process may include the following.

At S21, the electronic device starts an initialization process. For example, the electronic device is powered on and starts initializing its operating system.

In some embodiments, before S21, the process may further include: determining that the electronic device is reset to factory settings or has completed a firmware update.

At S22: whether custom model information is configured in token data is determined.

The independent storage medium refers to a storage medium separately configured from the main memory of the electronic device. The main memory of the electronic device is configured to store system code, firmware code, usage data, etc. In other words, contents of the independent storage medium does not directly change along with the operation, the initialization or other changes occurred to the electronic device. The independent storage medium may be a separate flash memory. Therefore, when the electronic device is offline to restore the factory settings or updating firmware, contents in the token data cannot be changed. Once the token data is assigned, its value is always valid unless the entire independent storage medium is erased.

In some embodiments, the code for configuring the token data may include the following:

----------------------------------------------------------------------------------------------------------------

typedef int8u tokenType_model_identifier [33] ;

#define CREATOR_ModelfromUart_TYPE (0x000B)

DEFINE_BASIC_TOKEN (ModelfromUart_TYPE, tokenType_model_identifier, {12, 'N', 'U' , 'L', 'L', '_', 'S ', 'E', 'N', 'G', 'L ', 'E', 'D', 0, } )

If the result of the determination is positive (S22: YES) , that is, if the custom model information is configured in the token data, step S23 is implemented: the custom model information in the token data is written into a model attribute value.

If the result of the determination is negative (S22: No) , that is, if no custom model information is configured in the token data, or if the token data does not exist, step S24 is implemented: default model information is written into a model attribute value.

In some embodiments, the custom model information can be written to the independent storage medium using a communication serial port or a wireless communication module. For example, the token data can be configured with the custom model information by using a serial command (e.g., through the communication serial port) or a wireless command (e.g., through the wireless communication module) before leaving the manufacturing factory.

In some embodiments, the custom model information may not be available to the electronic device during the initialization process of the electronic device initializes, for example, when an error occurs to the separate storage medium storing the token data (e.g., due to device failure or connection failure) , or when the token data is not successfully configured in the manufacturing factory, or if the separate storage medium is erased, or when wrong custom model information is configured in the token data. At this time, the default model information may be used as the model attribute value. The default model information may be any default information stored in any storage medium of the electronic device. The default model information may not be stored in a separate storage medium and may be stored in the same storage medium as other codes of the electronic device. If the custom model information is not found, or if the token data does not exist, the default model information can be used for the model attribute value. The default model information may include the actual model identifier indicating the actual type of the electronic device. In some embodiments, the default model information may be found in the codes of the firmware of the electronic device.

In one embodiment, the custom model information of at least two different types of electronic devices are the same. Specifically, functions of the at least two different types of electronic devices are the same or similar. In other words, the firmware used to implement the functions of the at least two different types of electronic devices are the same or similar. Accordingly, electronic devices of different models can share the same custom model information, that is, share the same firmware, thereby avoiding the problem of heavy maintenance burden caused by using different firmware names separately, and avoiding repeated charges for multiple firmware authentication.

The following is an example of eight different types of electronic devices sharing the same custom model information (i.e., sharing the same firmware) . The logic and part of the code can be as follows.

Provided that there are eight different types of devices with the same basic functions denoted as device0, device1, ... device7, which need to be authenticated by the Zigbee Alliance authentication system. The descriptions after double slashes “//” are explanations of the previous code. The actual model information can be as follows:

PGM char device0 [] = {7, 'E', '2', 'K', '-', 'C', 'B', 'A ', 0, 0} ;

PGM char device1 [] = {7, 'E', '2', 'L', '-', 'C', 'B', 'A ', 0, 0} ;

PGM char device2 [] = {7, 'E', '2', 'Q', '-', 'C', 'B', 'A ', 0, 0} ;

PGM char device3 [] = {7, 'E', '2', 'M', '-', 'C', 'B', 'A ', 0, 0} ;

PGM char device4 [] = {9, 'E', '2', 'K', '-', 'C', 'B', 'A ', '-', 'N', 0, 0} ;

PGM char device5 [] = {9, 'E', '2', 'L', '-', 'C', 'B', 'A ', '-', 'N', 0, 0} ;

PGM char device6 [] = {9, 'E', '2', 'Q', '-', 'C', 'B', 'A ', '-', 'N', 0, 0} ;

PGM char device7 [] = {9, 'E', '2', 'M', '-', 'C', 'B', 'A ', '-', 'N', 0, 0} ; //In a character array representing the actual model information, the first element represents the length of the actual model identifier, characters of the actual model identifier starts at the second element, and the last two elements 0 indicates the end of the actual model identifier.

In the production test before the electronic device leaves the factory, the custom model information in the token data can be configured in each device through a customized wireless command or serial command. In some embodiments, the custom model information may be configured as any one of the actual model identifier of the eight devices. The example code is as follows:

data_buf=receive_from_uart () ; //Saving the custom model information (e.g. received from a serial port) into a data buffer.

halCommonSetToken (TOKEN_ModelfromUart_TYPE, (unsigned char *) &data_buf [4] ) ; //Configuring the token data using the received custom model information saved in the data buffer.

SetTheModelIdentifierType () ; //Setting the custom model information as the model identifier of the electronic device.

Example code for the initialization process (e.g., retrieving the token data) and for determining whether the token data is configured with the custom model information and assigning/writing the model attribute value under different conditions is as follows.

----------------------------------------------------------------------------------------------------------------voidSetTheModelIdentifierType (void)

{

halCommonGetToken (data_buf, TOKEN_ModelfromUart_TYPE) ; //Retrieving the token data from the separate storage medium and saving the token data in a data buffer, the content of the token data being the custom model information.

if ( (strcmp (data_buf, device0) ==0)

|| (strcmp (data_buf, device1) ==0)

|| (strcmp (data_buf, device2) ==0)

|| (strcmp (data_buf, device3) ==0)

|| (strcmp (data_buf, device4) ==0)

|| (strcmp (data_buf, device5) ==0)

|| (strcmp (data_buf, device6) ==0)

|| (strcmp (data_buf, device7) ==0)

) //When the custom model information in the token data is the same as at least one model identifier of the eight devices, perform the following.

{

emberAfWriteServerAttribute (emberAfPrimaryEndpoint () ,

ZCL_BASIC_CLUSTER_ID,

ZCL_MODEL_IDENTIFIER_ATTRIBUTE_ID,

data_buf,

ZCL_CHAR_STRING_ATTRIBUTE_TYPE) ; //Writing the custom model information into the model attribute value.

emberAfGuaranteedPrint ( "resume model\r\n" ) ; //Printing a message indicating that the custom model information is successfully written into the model attribute value.

}

else //When the token data is not configured or does not match any model identifier of the eight devices, perform the following.

{

halCommonSetToken (TOKEN_ModelfromUart_TYPE, (void*) device0) ; //Setting the token data using the actual device model identifier of device0 if the electronic device executing the code is device 0; in other words, if the electronic device executing the code is device1, the last variable of this function should be device1.

halCommonGetToken (data_buf, TOKEN_ModelfromUart_TYPE) ; //Retrieving the token data, the actual device model identifier of device0 is used as the default model information.

emberAfWriteServerAttribute (emberAfPrimaryEndpoint () ,

ZCL_BASIC_CLUSTER_ID,

ZCL_MODEL_IDENTIFIER_ATTRIBUTE_ID,

data_buf,

ZCL_CHAR_STRING_ATTRIBUTE_TYPE) ; //Writing the default model information into the model attribute value

emberAfGuaranteedPrint ( " reset model\r\n" ) ; //Printing a message indicating that the default model information is successfully written into the model attribute value.

}

} //End

It can be understood that each firmware of the eight devices may include the same codes, such as the above example codes. In some embodiments, slight modification may also be included based on the actual device.

At S25: an authentication request including the model attribute value is sent to the authentication system, so that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication.

In the disclosed electronic device authentication process, when the electronic device initializes, if custom model information is configured in the token data, the custom model information in the token data is written into the model attribute value, and an authentication request including the model attribute value is sent to the authentication system, so that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication. The authentication of the device can be accomplished based on customized information, and is no longer limited to the actual model identifier of the device, which increases flexibility of the authentication process.

By writing and using the custom model information, devices having different model identifiers but same or similar functions (e.g., functions that implemented by same firmware) can be configured with same custom model information. That is, same custom model information can be shared by devices having different model identifiers but same firmware. Thus, the problem of heavy maintenance burden caused by using different firmware names separately can be avoided. It also avoids repeated charges for different firmware authentications.

In addition, since the token data is stored in a separate storage medium and is not written in the code, the custom model information configured in the token data is not lost or changed due to the firmware change of the electronic device or the factory reset of the electronic device. In addition, the model attribute value can be maintained as the same as the custom model information whenever the device is powered on and initialized.

In some embodiments, the disclosed process further includes an electronic device firmware update method. The electronic device firmware update method includes: after the authentication using any of the above described electronic device authentication processes is completed, performing firmware update based OTA specifications/protocols.

FIG. 4 is a schematic of an electronic device according to an embodiment of the present disclosure. As shown in FIG. 4, the electronic device may include a first writing module 301 and a transmission module 302.

The first writing module 301 may be configured to: when the electronic device initializes, if custom model information is configured in token data, write the custom model information in the token data into a model attribute value. The token data is stored in an independent storage medium.

The transmission module 302 is configured to: send an authentication request including the model attribute value to an authentication system, so that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication.

In the disclosed electronic device, when the electronic device initializes, if custom model information is configured in the token data, the custom model information in the token data is written into the model attribute value, and an authentication request including the model attribute value is sent to the authentication system, so that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication. The authentication of the electronic device can be accomplished based on customized information, and is no longer limited to the actual model identifier of the device, which increases flexibility of the authentication process.

FIG. 5 is a schematic of another electronic device according to an embodiment of the present disclosure. As shown in FIG. 5, the electronic device may include a first writing module 401 and a transmission module 403.

The first writing module 401 may be configured to: when the electronic device initializes, if custom model information is configured in token data, write the custom model information in the token data into a model attribute value. The token data is stored in an independent storage medium.

The transmission module 403 is configured to: send an authentication request including the model attribute value to an authentication system, so that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication.

Optionally, the custom model information of at least two electronic devices are the same. The at least two electronic devices have different model identifiers.

Optionally, the at least two electronic devices have same or similar functions.

Optionally, the electronic device is a Zigbee device. The authentication system is a Zigbee authentication system.

Optionally, the electronic device further includes a second writing module 402 configured to: if no custom model information is configured in the token data, or if the token data does not exist, write default model information into the model attribute value.

Optionally, the electronic device further includes a determination module configured to: determine that the electronic device is reset to the factory settings or has completed firmware update before starting the initialization process. In other words, the initialization process of the electronic device begins after the electronic device is reset to the factory settings or has completed firmware update.

Optionally, the custom model information is recorded/written into the independent storage medium using a communication serial port or a wireless communication module.

Optionally, the electronic device further includes an update module 404 configured to: perform firmware update based on OTA standards.

FIG. 6 is a schematic of a computing terminal according to an embodiment of the present disclosure. The computing terminal may implement the electronic device disclosed in embodiments consistent with FIGS. 1-5. The computing terminal may also implement the authentication system disclosed in embodiments consistent with FIGS. 1-3. The computing terminal may implement the process disclosed in embodiments consistent with FIGS. 2-3. As shown in FIG. 6, the computing terminal includes: a processor 51 and a memory 52.

The memory 52 is configured to store executable instructions. The memory 52 may include one or more storage medium. In some embodiments, the memory 52 includes a flash memory.

The processor 51 is configured to execute the executable instructions stored in the memory to implement various steps in the method involved in the foregoing embodiments. Details can be found in related description in the foregoing embodiments.

The memory 52 can be either a stand-alone memory or integrated with the processor 51.

When the memory 52 is a device independent from the processor 51, the computing terminal 50 may further include: a bus 53 configured to connect the memory 52 and the processor 51.

In some embodiments, the memory 52 may include a first storage medium storing token data and a second storage medium storing executable instructions. The first storage medium is independent from the second storage medium. The processor 51 may be configured to execute the executable instructions stored in the second storage medium. For example, one of the executable instructions may cause the processor 51 to read contents of the token data from the first storage medium and use the token data in executing other executable instructions to implement device authentication. In some embodiments, the first storage medium stands alone from the processor 51 and is connected to the processor 51 through the bus 53, and the second storage medium is integrated in the processor 51.

The present disclosure further provides a computer readable storage medium. The readable storage medium stores a computer program. When at least one processor of the electronic device executes the computer program, the computer program cause the at least one processor to perform an authentication and firmware upgrade process in the various embodiments described above.

The embodiment also provides a program product, the program product comprising a computer program, the computer program being stored in a computer readable storage medium. At least one processor of the electronic device can read the computer program from the readable storage medium, and the at least one processor executes the computer program such that the electronic device performs the authentication method and firmware upgrade method of the electronic device involved in the various embodiments described above.

Those skilled in the art may clearly understand that, for ease and concision of the descriptions, the aforementioned processing method may be applied to the related electronic devices, and the related details may refer to corresponding descriptions in the disclosed embodiments, which are not repeated herein.

The embodiments in this specification are described in a progressive manner, each embodiment emphasizes a difference from the other embodiments, and the identical or similar parts between the embodiments may be made reference to each other. Since the apparatuses disclosed in the embodiments are corresponding to the methods disclosed in the embodiments, the description of the apparatuses is simple and relevant parts may be made reference to the description of the methods.

Persons skilled in the art may further realize that, units and steps of algorithms according to the description of the embodiments disclosed by the present disclosure can be implemented by electronic hardware, computer software, or a combination of the two. In order to describe interchangeability of hardware and software clearly, compositions and steps of the embodiments are generally described according to functions in the forgoing description. Whether these functions are executed by hardware or software depends upon specific applications and design constraints of the technical solutions. Persons skilled in the art may use different methods for each specific application to implement the described functions, and such implementation should not be construed as a departure from the scope of the present disclosure.

The steps of the methods or algorithms described in the embodiments of the present disclosure may be directly implemented by hardware, software modules executed by the processor, or a combination of both. The software module can be placed in a random access memory (RAM) , memory, read only memory (ROM) , electrically programmable ROM, electrically erasable and programmable ROM, register, hard disk, mobile disk, CD-ROM, or any other form of storage medium known to the technical domain.

It will be understood by those skilled in the art that the features described in the respective embodiments and/or claims of the present disclosure can be combined in various ways, even if such combinations are not explicitly described in the present disclosure. In particular, without departing from the spirit and teaching of the present disclosure, the features described in the respective embodiments and/or claims can be combined in various ways. All of these combinations fall within the scope of the present disclosure.

While the present disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various modifications in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the appended claims and their equivalents. Therefore, the scope of the present disclosure should not be limited to the above-described embodiments but should be determined by not only the appended claims but also the equivalents thereof.

It should be noted that the description of the foregoing embodiments of the electronic device may be similar to that of the foregoing method embodiments, and the device embodiments have the same beneficial effects as those of the method embodiments. Therefore, details may not be described herein again. For technical details not disclosed in the embodiments of the electronic device of the present disclosure, those skilled in the art may understand according to the method embodiments of the present disclosure.

In the several embodiments provided in the present disclosure, it should be understood that the disclosed device and method may be realized in other manners. The device embodiments described above are merely exemplary. All functional modules or units in the embodiments of the present disclosure may all be integrated in one processing unit, or each unit may be used as a single unit. Two or more units may be integrated in one. The above integrated unit can either be implemented in the form of hardware, or in the form of hardware combined with software functional units.

Persons of ordinary skill in the art should understand that, all or a part of steps of implementing the foregoing method embodiments may be implemented by related hardware of a computer instruction program. The instruction program may be stored in a computer-readable storage medium, and when executed, a processor executes the steps of the above method embodiments as stated above. The foregoing storage medium may include various types of storage media, such as a removable storage device, a read only memory (ROM) , a random-access memory (RAM) , a magnetic disk, or any media that stores program code.

Alternatively, when the above-mentioned integrated units of the present disclosure are implemented in the form of a software functional module being sold or used as an independent product, the integrated unit may also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions provided by the embodiments of the present disclosure essentially or partially may be embodied in the form of a software product stored in a storage medium. The storage medium stores instructions which are executed by a computer device (which may be a personal computer, a server, a network device, or the like) to realize all or a part of the embodiments of the present disclosure. The above-mentioned storage medium may include various media capable of storing program codes, such as a removable storage device, a read only memory (ROM) , a random-access memory (RAM) , a magnetic disk, or an optical disk.

Logic when implemented in software, can be written in an appropriate language such as but not limited to C#or C++, and can be stored on or transmitted through a computer-readable storage medium (e.g., that is not a transitory signal) such as a random access memory (RAM) , read-only memory (ROM) , electrically erasable programmable read-only memory (EEPROM) , compact disk read-only memory (CD-ROM) or other optical disk storage such as digital versatile disc (DVD) , magnetic disk storage or other magnetic storage devices including removable thumb drives, etc.

The foregoing descriptions are merely embodiments of the present disclosure, and the protection scope of the present disclosure is not limited thereto. The scope that anyone skilled in the art may easily conceive changes and substitutions within the technical scope disclosed in the present disclosure that should be covered by the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the scope of the claims as listed in the following.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure provided herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the claims.

Claims

An authentication method, comprising:

when an electronic device initializes, if custom model information is configured in token data, writing the custom model information in the token data into a model attribute value, the token data being stored in an independent storage medium; and

sending an authentication request including the model attribute value to an authentication system, such that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication.
The method according to claim 1, wherein: the custom model information of at least two electronic devices are the same, the at least two electronic devices having different model identifiers.
The method according to claim 2, wherein: the at least two electronic devices have same or similar functions.
The method according to claim 1, wherein: the electronic device is a Zigbee device; and the authentication system is a Zigbee authentication system.
The method according to claim 1, further comprising:

when the electronic device initializes, if no custom model information is configured in the token data, or if the token data does not exist, writing default model information into the model attribute value.
The method according to claim 1, further comprising:

determining that the electronic device is reset to factory settings or has completed firmware update before the electronic device initializes.
The method according to claim 1, further comprising:

storing the custom model information into the independent storage medium using a communication serial port or a wireless communication module.
The method according to claim 1, further comprising:

when the authentication is completed, performing firmware update using an Over-the-Air (OTA) standard defined by the authentication system.
An electronic device, comprising:

a first writing module configured to: when the electronic device initializes, if custom model information is configured in token data, write the custom model information in the token data into a model attribute value, the token data being stored in an independent storage medium; and

a transmission module configured to send an authentication request including the model attribute value to an authentication system, such that the authentication system determines a model identifier and a firmware name corresponding to the model attribute value as the model identifier and the firmware name of the electronic device to complete authentication.
The electronic device according to claim 9, further comprising:

a second writing module configured to: when the electronic device initializes, if no custom model information is configured in the token data, or if the token data does not exist, write default model information into the model attribute value.
The electronic device according to claim 9, further comprising:

an update module configured to: when the authentication is completed, perform firmware update using an Over-the-Air (OTA) standard defined by the authentication system.
The electronic device according to claim 9, wherein: the electronic device is a Zigbee device; and the authentication system is a Zigbee authentication system.