CA3177668C

CA3177668C - Smart device monitoring method and apparatus

Info

Publication number: CA3177668C
Application number: CA3177668A
Authority: CA
Inventors: Duojun RONG
Original assignee: 10353744 Canada Ltd
Current assignee: 10353744 Canada Ltd
Priority date: 2019-12-25
Filing date: 2020-08-28
Publication date: 2023-08-29
Anticipated expiration: 2040-08-28
Also published as: CN111200538A; CA3166102A1; CA3166102C; WO2021128915A1; CN111200538B; CA3177668A1

Abstract

A method and an apparatus for monitoring a smart device relate to the technical field of terminal device management, and provide centralized management and monitoring services for smart devices used in chained 020 stores. The method includes: providing a heartbeat connection between a server and the smart device, for the server to receive from the smart device a heartbeat packet containing device information, service information and/or health information; at the server, sinking the service information and/or the health information based on the device information, and synchronizing reported data of the smart device; sending a heartbeat response from the server to the smart device, so as to maintain the heartbeat connection therebetween; and monitoring the smart device and/or managing operation thereof based on the heartbeat connection, the service information, and/or the health information. The apparatus is applied with the method.

Description

SMART DEVICE MONITORING METHOD AND APPARATUS
BACKGROUND OF THE INVENTION
Technical Field [0001] The present invention relates to management of teaninal devices, and more particularly to a method and an apparatus for monitoring a smart device.
Description of Related Art

[0002] At present, in the field of 020 business, the common practice is that vendors provide inspection and monitoring services for their respective devices. These services basically are local management and monitoring services. For example, one store can only monitor and manage their local devices from the same brand using management software specific to the brand and installed locally in their terminal.

[0003] With the rapid development of 020 offline business, the number of chained 020 stores has increased sharply in recent years. Since, different 020 stores may use smart devices (e.g., cash registers) from different manufacturers or suppliers, it is difficult to centralize management and monitoring smart devices across chained 020 stores of the same group.
SUMMARY OF THE INVENTION

[0004] The objective of the present invention is to provide a method and an apparatus for monitoring a smart device, which provide centralized management and monitoring services for smart devices across chained 020 stores.

[0005] To achieve the foregoing objective, in a first aspect, the present invention provides a method for monitoring a smart device, comprising:

[0006] providing a heartbeat connection between a server and the smart device, for the server Date Regue/Date Received 2023-05-02 to receive from the smart device a heartbeat packet containing device information, service information and/or health infounation;

[0007] at the server, sinking the service information and/or the health information based on the device information, and synchronizing reported data of the smart device;

[0008] sending a heartbeat response from the server to the smart device, so as to maintain the heartbeat connection therebetween; and

[0009] monitoring the smart device and/or managing operation thereof based on the heartbeat connection, the service information, and/or the health information.

[0010] Preferably, the heartbeat connection between the server and the smart device is provided by:

[0011] providing the smart device with a client terminal and a software development kit SDK, and providing the server with a device manager DM;

[0012] initializing SDK using the client terminal, and sending a login message from SDK to DM to request for registration; and

[0013] from DM, returning a response message to SDK based on the login message, and at SDK, analyzing the response message to extract a heartbeat parameter TTL, so that the heartbeat relationship is established between SDK and DM.

[0014] More preferably, the response message carries latest configuration data in addition to TT'L, and the latest configuration data are used to refresh a local configuration at SDK.

[0015] Further, before the step of at the server, sinking the service information and/or the health information based on the device information, and synchronizing reported data of the smart device, the method further comprises:

[0016] at SDK, automatically initiating a heartbeat request to DM as a heartbeat packet based on TTL, in which the device information includes a device serial number, and the service information includes a count of transactions in a heartbeat cycle, and the health information includes an error code and a corresponding error description; and

[0017] when it failed to establish the heartbeat relationship between the software development kit and DM, at the software development kit, actively sending a failure notification to the client terminal.

Date Regue/Date Received 2023-05-02

[0018] Preferably, the count of transactions in a said heartbeat cycle is counted through:

[0019] When each transaction is generated by the client terminal, recording the transaction order by calling an event tracking interface of SDK; and

[0020] at SDK, summing up the transaction orders recorded in one heartbeat cycle so as to obtain the count of transactions in the current heartbeat cycle.

[0021] Preferably, after the step of at the server, sinking the service information and/or the health information based on the device information, and synchronizing reported data of the smart device, the method further comprises:

[0022] providing a united subscription service interface at DM, allowing a monitoring platform to acquire the service information and/or the health information from DM and information about the failure notification from SDK related to the heartbeat connection through the subscription service interface.

[0023] Preferably, the step of sending a heartbeat response from the server to the smart device, so as to maintain the heartbeat connection therebetween comprises:

[0024] after the smart device successfully sinks reported data in the present heartbeat packet, at DM, actively notifying the monitoring platform;

[0025] at DM, returning the response message carrying the latest configuration data and TTL
to SDK; and

[0026] according to TTL, sending heartbeat packets regularly from the smart device to DM, so as to maintain the heartbeat connection.

[0027] More preferably, the smart device is provided in plurality, and each said smart device is in communication connection with the server, while each said smart device is a cash register.

[0028] As compared to the prior art, the method for monitoring a smart device present invention provides the following beneficial effects:

[0029] In the method for monitoring a smart device of the present invention, many smart devices each has heartbeat connection relationship with a server, so that every smart device can continuously send heartbeat packets to the server. After receiving such a heartbeat packet, the server identifies the relevant smart device based on the device Date Regue/Date Received 2023-05-02 information and stores the corresponding service information and/or health information, thereby synchronizing reported data of the smart devices. In addition, after successful storage, the server sends a heartbeat response for acknowledging the reported data back to the smart device timely, and the continuous heartbeat connection between the server and the smart device is then established. When any of the heartbeat connections fails, it indicates that the corresponding smart device is offline. In this way, state monitoring of all the smart devices can be achieved. Furthermore, since the server keeps the service information and/or health information continuously sent by each of these smart devices, it is able to aggregate and analyze the service information and/or the health information of the individual smart devices, thereby realizing remote management of these mart devices.

[0030] Another aspect of the present invention provides an apparatus for monitoring a smart device, which is applied with the method as described above. The apparatus comprises:

[0031] a receiving unit, for providing a heartbeat connection between a server and the smart device, for the server to receive from the smart device a heartbeat packet containing device information, service information and/or health information;

[0032] a sinking unit, at the server, for sinking the service information and/or the health information based on the device information, and synchronizing reported data of the smart device;

[0033] a returning unit, for the server to return a heartbeat response to the smart device, so as to maintain the heartbeat connection therebetween; and

[0034] a monitoring unit, for monitoring the smart device and/or managing operation thereof based on the heartbeat connection, the service information, and/or the health information.

[0035] As compared to the prior art, the disclosed apparatus for monitoring a smart device provides beneficial effects that are similar to those provided by the disclosed method as enumerated above, and thus no repetitions are made herein.

[0036] A third aspect of the present invention provides a computer-readable storage medium, which stores a computer program. When run by a processor, the computer program Date Regue/Date Received 2023-05-02 executes the steps of the method for monitoring smart services as describe previously.

[0037] As compared to the prior art, the disclosed computer-readable storage medium provides beneficial effects that are similar to those provided by the disclosed method as enumerated above, and thus no repetitions are made herein.
BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings are provided herein for better understanding of the present invention and form a part of this disclosure. The illustrative embodiments and their descriptions are for explaining the present invention and by no means form any improper limitation to the present invention, wherein:

[0039] FIG. 1 is a flowchart of a method for monitoring smart devices of the first embodiment of the present invention;

[0040] FIG. 2 is a schematic graph illustrating interaction between a smart device with a server for registration according to the first embodiment;

[0041] FIG. 3 is a schematic graph illustrating interaction between the smart device and the server for continuous heartbeat connection according to the first embodiment;

[0042] FIG. 4 is a schematic graph illustrating interaction between the smart device and the server for acquiring information of failure of the smart device according to the first embodiment;

[0043] FIG. 5 is a schematic graph illustrating interaction between the smart device and the server for the server to acquire offline information of the smart device according to the first embodiment;

[0044] FIG. 6 is a schematic graph illustrating interaction between the smart device and the server for the smart device to report transaction data according to the first embodiment;
and

[0045] FIG. 7 is a schematic graph illustrating interaction between the smart device and the server for the smart device to reestablish connection according to the first embodiment.
DETAILED DESCRIPTION OF THE INVENTION
Date Regue/Date Received 2023-05-02

[0046] To make the foregoing objectives, features, and advantages of the present invention clearer and more understandable, the following description will be directed to some embodiments as depicted in the accompanying drawings to detail the technical schemes disclosed in these embodiments. It is, however, to be understood that the embodiments referred herein are only a part of all possible embodiments and thus not exhaustive.
Based on the embodiments of the present invention, all the other embodiments can be conceived without creative labor by people of ordinary skill in the art, and all these and other embodiments shall be encompassed in the scope of the present invention.

[0047] Embodiment 1

[0048] Referring to FIG. 1, the present embodiment provides a method for monitoring a smart device, which comprises:

[0049] providing a heartbeat connection between a server and the smart device, for the server to receive from the smart device a heartbeat packet containing device information, service information and/or health information; at the server, sinking the service information and/or the health information based on the device information, and synchronizing reported data of the smart device; sending a heartbeat response from the server to the smart device, so as to maintain the heartbeat connection therebetween; and monitoring the smart device and/or managing operation thereof based on the heartbeat connection, the service information, and/or the health information.

[0050] In the method for monitoring a smart device of the present embodiment, many smart devices each has heartbeat connection relationship with a server, so that every smart device can continuously send heartbeat packets to the server. After receiving such a heartbeat packet, the server identifies the relevant smart device based on the device information and stores the corresponding service information and/or health information, thereby synchronizing reported data of the smart devices. In addition, after successful storage, the server sends a heartbeat response for acknowledging the reported data back to the smart device timely, and the continuous heartbeat connection relationship between the server and the smart device is then established. When any of the heartbeat connections fails, it indicates that the corresponding smart device is offline. In this way, Date Regue/Date Received 2023-05-02 state monitoring of all the smart devices can be achieved. Furthermore, since the server keeps the service information and/or health information continuously sent by each of these smart devices, it is able to aggregate and analyze the service information and/or the health information of the individual smart devices, thereby realizing remote management of these mart devices.

[0051] In the present embodiment, the heartbeat connection between the server and the smart device is provided by: providing the smart device with a client terminal and a software development kit SDK, and providing the server with a device manager DM;
initializing SDK using Client, and sending a login message from SDK to DM to request for registration; and from DM, returning a response message to SDK based on the login message, and at SDK, analyzing the response message to extract a heartbeat parameter TTL, so that the heartbeat relationship is established between SDK and DM. The response message carries latest configuration data in addition to TTL, and the latest configuration data are used to refresh a local configuration at SDK_

[0052] In practical implementations, after the smart devices are powered and go online, data of the smart devices, such as the device information, the service information, and the health information are collected from their clients for SDK to convert into a predetermined data format and register at the device manager DM of the server, so as to maintain the heartbeat connection between SDK and the device manager DM. In the event of any failure of heartbeat connection, it indicates that the corresponding smart device is offline.

[0053] For example: the device manager DM may provide the following functions:

[0054] 1. Management of metadata of smart terminal devices:

[0055] a) Device Model:
smig m mow ,,, 111111111EN1fll ,II
Model Field Field Descnpliou Remark Type The description of the business name of the Mandatory device, e.g., CCT, Android POS, robot arm, etc.
Vendor The information about the supplier provided by Mandatory the device Date Regue/Date Received 2023-05-02 Model The model information of the device, having to Mandatory be unique Version No. The version number of the system Optional Model Description The description about the role, the features, or Mandatory other information of the device

[0056] b) Device Basic Information rick1 In um"Fick' ik,ciipLion 111 Rom'ik Store ID No. The unique Identification of the store Mandatory State The state information Optional Area The area infoimation Optional Region The region information Optional Branch The branch information Optional Serial Number The serial number +app name of the device, Mandatory having to be unique, for identifying the device, the windows-mac-address Type The type from the Model Table Mandatory Vendor The vendor from the Model Table Mandatory Model The model from the Model Table Mandatory Model Description The model description from the Model Table Mandatory Device Name The name of the device, custom Mandatory Version No. The version number of the software Mandatory Active Downward Supporting active downward inspection of DM Optional Inspection or not, negative at default Monitoring IP Where the device does not allow SDK insertion, Optional but provides interface for health inspection, configuring its intranet IP so that DM can actively perform inspection Monitoring Interface Where the device does not allow SDK insertion, Optional but provides interface for health inspection, Date Regue/Date Received 2023-05-02 configuring its intranet interface so that DM can actively perfoim inspection

[0057] c) Device State Information ¨
Field Field Dewy] )tion Remark 011111W111 MEI MEI llllu1 III 101 1111111111 MAI
MIME Ell111111 1111111111 Device Name The device name from the Model Table Mandatory Serial Number The serial number of the device Mandatory Store ID No. The unique Identification of the store Mandatory Report Time/Date The time and the date on which a heartbeat is Mandatory reported Use Frequency The number of times of use in the current Optional heartbeat cycle Current State of The state of charge in the current heartbeat cycle Optional Charge Staff ID The staff ID of the staff member who is Optional conducting current operation

[0058] d) Device Use Infoimation , Field Field Description Remark Device Name The device name from the Model Table Mandatory Serial Number The serial number of the device Mandatory Store ID No. The unique Identification of the store Mandatory Report Time/Date The time and the date on which a heartbeat is Mandatory reported Use Frequency The number of times of use in the current Optional heartbeat cycle Current State of The state of charge in the current heartbeat cycle Optional Charge Staff ID The staff ID of the staff member who is Optional conducting current operation

[0059] e) Query Criteria Date Regue/Date Received 2023-05-02 11111111 WINIMET TTU I, Field Held Description Remark Store ID No. The unique Identification of the store Mandatory State The state information Mandatory Region The region infonnation Mandatory Province The province information Mandatory Branch The branch information Mandatory serial number The serial number of the device Mandatory Type The type from the Model Table Mandatory Vendor The vendor from the Model Table Mandatory Model The model from the Model Table Mandatory Model Description The model description from the Model Table Mandatory Device Name The device name from the Model Table Mandatory Version No. The version no. of the software Mandatory Device Status The current status of the device Mandatory Last Heartbeat Time The time of the last successful heartbeat Mandatory Continuous Online The duration from the previous login to the Optional Duration previous successful heartbeat Use Frequency The use frequency in the cycle for which the Optional query is made to, specifically the number of times of transaction

[0060] Referring to FIG. 2, for easy understanding, the process of registration described previously is now further explained with reference to an example.

[0061] After startup, the client terminal first initializes the software development kit SDK, and a store clerk enters a passport to send a login message, or the request body of the first heartbeat packet, to the device manager DM to request for registration. The device manager DM (i.e., a device management platform) receives the login message and then sends a response message, or the request body of the first response message, back to the software development kit SDK. The software development kit SDK receives and Date Regue/Date Received 2023-05-02 analyzes to check whether the response message contains the latest configuration data.
If yes, it refreshes the local configuration of the software development kit SDK
accordingly; otherwise, the existing local configuration of SDK remains. Then the heartbeat parameter TTL is used as a general heartbeat parameter, and a notification of establishment of heartbeat connection is sent back to client terminal. In general, the heartbeat packet issued for the first heartbeat only contains device information, such as Store ID No., the serial number of the device, and Device Name. The device information is sent in by Client through initialization interface of the software development kit SDK.

[0062] In the embodiment, before the server sinks the service information and/or the health information based on the device information and synchronizes the reported data of the smart device, the method further comprises:

[0063] at the software development kit SDK, based on the heartbeat parameter TTL, automatically initiating a heartbeat request to the device manager DM in the form of a heartbeat packet, wherein the device information includes the serial number of the device. The service information includes the number of times of transaction in the heartbeat cycle and the currently remaining charge in the smart device. The health information includes error codes and corresponding error descriptions. When it failed to establish the heartbeat relationship between the software development kit and DM, a failure notification is sent back to Client.

[0064] In practical implementations, as shown in FIG. 3, after connection between SDK and the device manager DM is established, the software development kit SDK
automatically sends a heartbeat packet to the device manager DM based on the heartbeat parameter TTL on a periodic basis. This process can be done without calling any SDK interface by Client. The device information in the heartbeat packet includes the serial number of the device and the heartbeat parameter TTL. The service information includes the number of times of transaction in the heartbeat cycle and the currently remaining charge in the smart device. The health information includes error codes and corresponding error descriptions. The serial number of the device is sent in Date Regue/Date Received 2023-05-02 by the client terminal through the initialization interface of the software development kit SDK. The heartbeat parameter TTL is acquired from the response sent from the login interface or the heartbeat interface of the device manager DM to the software development kit SDK. In addition to the heartbeat parameter TTL, the latest configuration data are also sent back with the response from the login interface or the heartbeat interface of the device manager DM, so that the software development kit SDK after receiving the response message, can analyze and cache the latest configuration data, and store the heartbeat parameter TTL as the general heartbeat parameter for sending a response to the client terminal. In the event of a failed heartbeat, the software development kit SDK pushes a heartbeat failure notification to the client terminal, so s to warn the user timely.

[0065] In addition, referring to FIG. 4, since the smart device is provided with an interface for inspecting error information at its driving level, and the software development kit SDK
has built-in capability for error inspection, if the smart device has an error during heartbeats, when initiating a heartbeat, the software development kit SDK
first calls the inspection interface at the driving level to acquire an error code and its corresponding error description. Then they are carried by the heartbeat packet sent to the device manager DM. It is to be noted that the inspection interface driven by the device adopts a private protocol and supports docking through the following ways: 1. The information is acquired by accessing the local port at the smart device through a socket;
2. The information is transmitted in by calling a relevant interface at the software development kit SDK after inspection performed by the client terminal; and 3. The information is transmitted in from the error interface of the software development kit SDK, including an Error Code parameter and an Error Info parameter.

[0066] Referring to FIG. 5, the step of monitoring whether a smart device is offline is achieved through: if the software development kit SDK has not sent a heartbeat packet to the device manager DM by the end of the TTL cycle, the device manager DM regularly check whether a heartbeat of the smart device can be normally received according to TTL. If not, it means that the heartbeat of the smart device is with a timeout. In this Date Regue/Date Received 2023-05-02 case, it is determined that the smart device is offline or has been turned off.

[0067] Optionally, the server is in connection and communication to multiple smart devices, respectively. Each of the smart devices is a cash register. In the present embodiment, the count of transactions in a said heartbeat cycle is counted through:

[0068] every time Client of the smart device generates a transaction order, recording the transaction order by calling an event tracking interface of the software development kit SDK through the client terminal; and at SDK, summing up the transaction orders recorded in one heartbeat cycle so as to obtain the count of transactions in the current heartbeat cycle.

[0069] In practical implementations, referring to FIG. 6, for every transaction order generated by the smart device, the client terminal calls the event tracking interface from the software development kit SDK to record the order. The order is recorded through setting a bury point in a non-reentrant functional key path of the transaction. Every time the non-reentrant function makes a call, one is added to the count of transactions.
Therein, the non-reentrant function may be transmitted through the client terminal. The software development kit SDK makes the heartbeat packet carry the count of transaction accumulated in the present heartbeat cycle so that the count is reported to the heartbeat interface of the device manager DM. The device manager DM
analyzes and sinks the reported data before sending a heartbeat response and notifying the monitoring platform. The software development kit SDK after receiving the response message, empties the count of transactions accumulated in the previous TTL
cycle, and analyzes the latest configuration data in the returned heartbeat. Afterward, and the newly acquired TTL is stored as a general heartbeat parameter and a notification about this is sent to the client terminal.

[0070] Further, referring to FIG. 7, the software development kit SDK and the device manager DM maintain a synchronized state therebetween by means of heartbeats. In the event of network jitter or interruption, server breakdown, or power outage, the maintained heartbeat connection breaks. At this time, for preventing consequences of a signaling storm, it is necessary to resume heartbeats as soon as possible through reconnection. To Date Regue/Date Received 2023-05-02 this end, the present embodiment provides two reconnection mechanisms. The first one is emergency retry and the second one is backend retry. Therein, an emergency retry strategy may be distributed by the device manager DM actively in response to registration of a user, or may be returned with a response message after a successful heartbeat, or may be transmitted directly by the client terminal. After the present heartbeat fails, a retry heartbeat request may be sent until the number of failed retry attempts exceeds a threshold. A backend retry strategy may be distributed by the device manager DM actively in response to registration of a user, or may be returned with a response message after a successful heartbeat, or may be directly transmitted by the client terminal. After the present heartbeat fails, the interval between heartbeat requests is redefined. Generally, the interval is such set that it is slightly shorter than a normal heartbeat cycle, such as 5000ms. The attempts are made until the device manager DM
sends back a heartbeat response that indicates successful restoration of heartbeats. Now the nomial heartbeat connection relationship is reestablished.

[0071] It is understandable that in the present embodiment, state monitoring and/or operation management for a smart device based on the heartbeat connection, the service information and/or the health information is achieved through the following process.

[0072] With the service information and/or the health information generated by all smart devices in a given period of time stored in the server, the service infolination generated by a smart device in any time period (the count of transactions) can be called through the monitoring platform, and the use state of the device can be learned therefrom.
Similarly, the health information generated by the smart device in the time period can be called for analysis that measure the health of the device, so that an operation management scheme specific to the device can be made according to the usage and health of the device.

[0073] To sum up, the present embodiment is more advantageous than the prior art in the following tei

[0074] As to functionality, the prior-art solutions mainly rely on health interfaces provided by vendors exclusively for their respective smart devices, and only allow a user to get Date Regue/Date Received 2023-05-02 operational health information of his/her device through a socket or an API, making them functionally limited. Differently, the present embodiment can not only inspect health information but also accumulate and analyze business data device of connected devices, making it rich in functionality.

[0075] As to data, since data dimensions are conventionally specific to device vendors and not united, centralized maintenance is basically impossible. By contrast, the present embodiment uses the device manager DM to define the metadata specification for device management. Then with the standard specifications of the software development kit SDK and the API interface, the software development kit SDK is adaptive to data structures of different types of devices and converts them into a consistent, standard data format before reporting the data to the device manager DM, thereby achieving united management of data;

[0076] As to scalability, opposite to the prior-art solutions that are limited in terms of scalability, the present embodiment theoretically can be scaled up infinitely.

[0077] Embodiment 2

[0078] The present embodiment provides an apparatus for monitoring a smart device, which comprises:

[0079] a receiving unit, for providing a heartbeat connection between a server and the smart device, for the server to receive from the smart device a heartbeat packet containing device infomiation, service information and/or health information;

[0080] a sinking unit, at the server, for sinking the service information and/or the health information based on the device information, and synchronizing reported data of the smart device;

[0081] a returning unit, for the server to return a heartbeat response to the smart device, so as to maintain the heartbeat connection therebetween; and

[0082] a monitoring unit, for monitoring the smart device and/or managing operation thereof based on the heartbeat connection, the service information, and/or the health information.
Date Regue/Date Received 2023-05-02

[0083] As compared to the prior art, the disclosed apparatus for monitoring a smart device as disclosed in the present embodiment provides beneficial effects that are similar to those provided by the disclosed method as enumerated above, and thus no repetitions are made herein.

[0084] Embodiment 3

[0085] The present embodiment provides a computer-readable storage medium, which stores a computer program. When the computer program is run by a processor, it executes the steps of the method for monitoring a smart device as described above.

[0086] As compared to the prior art, the disclosed computer-readable storage medium provides beneficial effects that are similar to those provided by the disclosed device monitoring method as enumerated above, and thus no repetitions are made herein.

[0087] As will be appreciated by people of ordinary skill in the art, implementation of all or a part of the steps of the method of the present invention as described previously may be realized by having a program instruct related hardware components. The program may be stored in a computer-readable storage medium, and the program is about performing the individual steps of the methods described in the foregoing embodiments.
The storage medium may be a ROM/RAM, a hard drive, an optical disk, a memory card or the like.

[0088] The present invention has been described with reference to the preferred embodiments and it is understood that the embodiments are not intended to limit the scope of the present invention. Moreover, as the contents disclosed herein should be readily understood and can be implemented by a person skilled in the art, all equivalent changes or modifications which do not depart from the concept of the present invention should be encompassed by the appended claims. Hence, the scope of the present invention shall only be defined by the appended claims.

Date Regue/Date Received 2023-05-02

Claims

1. An apparatus comprising:
a receiving unit, configured to provide a heartbeat connection between a server and a smart device, for the server to receive from the smart device a heartbeat packet containing device information, service information and/or health information;
wherein the heartbeat connection between the server and the smart device comprises:
providing the smart device with a client terminal and a software development kit (SDK);
providing the server with a device manager (DM);
initializing the software development kit using the client terminal;
sending a login message from the software development kit to the device manager to request for registration;
from the device manager, returning a response message to the software development kit based on the login message; and the software development kit, analyzing the response message to extract a heartbeat parameter (rn,), wherein heartbeat relationship is established between the software development kit and the device manager, wherein the SDK
automatically sends the heartbeat packet to the DM based on the heartbeat parameter.

2. The apparatus of claim 1, further comprises:
a sinking unit, at the server, configured to sink the service information and/or the health information based on the device information, and synchronize reported data of the smart device;
a returning unit, configured the server to return a heartbeat response to the smart device, to maintain the heartbeat connection therebetween; and Date Regue/Date Received 2023-05-02 a monitoring unit, configured to monitor the smart device and/or managing operation based on the heartbeat connection, the service information, and/or the health information.

3. The apparatus of claim 2, wherein the response message carries latest configuration data in addition to the heartbeat parameter, wherein the latest configuration data refreshes a local configuration at the software development kit.

4. The apparatus of any one of claims 2 and 3, further comprises:
the software development kit, automatically initiating a heartbeat request as a heartbeat packet to the device manager based on the heartbeat parameter, wherein the device information includes a device serial number, wherein the service information includes a count of transactions in a heartbeat cycle, and wherein the health information includes an error code and a corresponding error description; and wherein the software development kit fails to establish the heartbeat relationship between the software development kit and the device manager, at the software development kit, actively sending a failure notification to the client terminal.

5. The apparatus of claim 4, wherein the count of transactions in the heartbeat cycle is counted comprises:
the client terminal of the smart device generates a transaction order, recording the transaction order by calling an event tracking interface of the software development kit; and at the software development kit, summing up the transaction orders recorded in one heartbeat cycle to obtain the count of transactions in current heartbeat cycle.

6. The apparatus of claim 5, further comprises:
providing a united subscription service interface at the device manager, allowing a monitoring platform to acquire the service information and/or the health information from the device manager and information about the failure notification from the Date Regue/Date Received 2023-05-02 software development kit related to the heartbeat connection through the united subscription service interface.

7. The apparatus of claim 5, wherein sending the heartbeat response from the server to the smart device, to maintain the heartbeat connection therebetween comprises:
after the smart device successfully sinks reported data in the heartbeat packet, at the device manager, actively notifying a monitoring platform;
at the device manager, returning the response message carrying the latest configuration data and the heartbeat parameter to the software development kit; and according to the heartbeat parameter, sending heartbeat packets regularly from the smart device to the device manager, to maintain the heartbeat connection.

8. The apparatus of claim 1, wherein the smart device is provided in plurality, and each smart device is in communication connection with the server, while each smart device is a cash register.

9. The apparatus of any one of claims 1 to 8, wherein any of the heartbeat connection fails, the corresponding smart device is offline.

10. The apparatus of any one of claims 1 to 9, wherein the smart devices are powered and go online, data of the smart devices, including the device information, the service information, and the health information are collected from their clients for SDK to convert into a predetermined data format and register at the device manager DM
of the server.

11. The apparatus of any one of claims 1 to 10, wherein the SDK receives and analyzes to check the response message contains the latest configuration data, wherein yes, the SDK refreshes the local configuration of the software development kit SDK
accordingly, wherein no, existing local configuration of SDK remains.

12. The apparatus of any one of claims 1 to 11, wherein the heartbeat packet issued for the first heartbeat only contains device infoimation including store ID No., the serial Date Regue/Date Received 2023-05-02 number of the device, and device name.

13. The apparatus of any one of claims 1 to 12, wherein the SDK
automatically sends the heartbeat packet to the DM based on the TTL on a periodic basis an completed without calling SDK interface by the client terminal.

14. The apparatus of any one of claims 1 to 13, wherein the device information in the heartbeat packet includes the device serial number and the heartbeat parameter TTL.

15. The apparatus of any one of claims 1 to 14, wherein the service information includes number of times of transaction in the heartbeat cycle and remaining charge in the smart device.

16. The apparatus of any one of claims 1 to 15, wherein the heartbeat parameter TTL and the latest configuration data are sent with response from a login interface or heartbeat interface of the device manager DM.

17. The apparatus of any one of claims 1 to 16, wherein in the event of a failed heartbeat, the software development kit pushes a heartbeat failure notification to the client terminal.

18. The apparatus of any one of claims 1 to 17, wherein the smart device is provided with an interface for inspecting error information at a driving level.

19. The apparatus of any one of claims 1 to 18, wherein the software development kit has built-in capability for error inspection.

20. The apparatus of any one of claims 1 to 19, wherein the smart device has an error during heartbeats, when initiating a heartbeat, the software development kit first calls inspection interface at the driving level to acquire the error code and its corresponding error description, wherein the error code and its corresponding error description are carried by the heartbeat packet sent to the device manager.

21. The apparatus of any one of claims 1 to 20, wherein the inspection interface driven by the smart device adopts a private protocol and supports docking comprises:
Date Regue/Date Received 2023-05-02 the information is acquired by accessing a local port at the smart device through a socket;
the information is transmitted in by calling a relevant interface at the software development kit after inspection performed by the client terminal; and the information is transmitted in from an error interface of the software development kit, including an Error Code parameter and an Error Info parameter.

22. The apparatus of any one of claims 1 to 21, wherein the transaction order is recorded through setting a bury point in a non-reentrant functional key path of the transaction.

23. The apparatus of any one of claims 1 to 22, wherein network jitter or interruption, server breakdown, or power outage occurs, the heartbeat connection breaks.

24. The apparatus of any one of claims 1 to 23, wherein for preventing consequences of a signaling storm, there are two reconnection mechanisms including an emergency retry and a backend retry.

25. The apparatus of any one of claims 1 to 24, wherein an emergency retry strategy is distributed by the device manager actively in response to registration of a user, or returned with the response message after the heartbeat, or is transmitted directly by the client terminal.

26. The apparatus of any one of claims 1 to 25, wherein the heartbeat fails, a retry heartbeat request is sent until number of failed retry attempts exceeds a threshold.

27. The apparatus of any one of claims 1 to 26, wherein the backend retry is distributed by the device manager actively in response to registration of the user, or is returned with the response message after the heartbeat, or is directly transmitted by the client terminal.

28. The apparatus of any one of claims 1 to 27, wherein the heartbeat fails, interval between heartbeat requests is redefined, wherein the interval is set slightly shorter than a normal heartbeat cycle.

Date Regue/Date Received 2023-05-02

29. The apparatus of any one of claims 1 to 28, wherein retry attempts are made until the device manager sends back the heartbeat response indicates successful restoration of heartbeats.

30. A system comprising:
providing a heartbeat connection between a server and a smart device, for the server to receive from the smart device a heartbeat packet containing device information, service information and/or health information;
wherein the heartbeat connection between the server and the smart device comprises:
providing the smart device with a client terminal and a software development kit (SDK);
providing the server with a device manager (DM);
initializing the software development kit using the client terminal;
sending a login message from the software development kit to the device manager to request for registration;
from the device manager, returning a response message to the software development kit based on the login message; and the software development kit, analyzing the response message to extract a heartbeat parameter (T1t), wherein heartbeat relationship is established between the software development kit and the device manager, wherein the SDK
automatically sends the heartbeat packet to the DM based on the TTL.

31. The system of claim 30, further comprises:
at the server, sinking the service information and/or the health information based on the device information, and synchronizing reported data of the smart device;
sending a heartbeat response from the server to the smart device, to maintain the heartbeat connection therebetween; and Date Regue/Date Received 2023-05-02 monitoring the smart device and/or managing operation thereof based on the heartbeat connection, the service information, and/or the health information.

32. The system of claim 31, wherein the response message carries latest configuration data in addition to the heartbeat parameter, wherein the latest configuration data refreshes a local configuration at the software development kit.

33. The system of any one of claims 31 and 32, further comprises:
the software development kit, automatically initiating a heartbeat request as a heartbeat packet to the device manager based on the heartbeat parameter, wherein the device information includes a device serial number, wherein the service information includes a count of transactions in a heartbeat cycle, and wherein the health information includes an error code and a corresponding error description; and wherein the software development kit fails to establish the heartbeat relationship between the software development kit and the device manager, at the software development kit, actively sending a failure notification to the client terminal.

34. The system of claim 33, wherein the count of transactions in the heartbeat cycle is counted comprises:
the client terminal of the smart device generates a transaction order, recording the transaction order by calling an event tacking interface of the software development kit; and at the software development kit, summing up the transaction orders recorded in one heartbeat cycle to obtain the count of transactions in current heartbeat cycle.

35. The system of claim 34, further comprises:
providing a united subscription service interface at the device manager, allowing a monitoring platform to acquire the service information and/or the health information from the device manager and information about the failure notification from the software development kit related to the heartbeat connection through the united Date Regue/Date Received 2023-05-02 subscription service interface.

36. The system of claim 34, wherein sending the heartbeat response from the server to the smart device, to maintain the heartbeat connection therebetween comprises:
after the smart device successfully sinks reported data in the heartbeat packet, at the device manager, actively notifying a monitoring platform;
at the device manager, returning the response message carrying the latest configuration data and the heartbeat parameter to the software development kit; and according to the heartbeat parameter, sending heartbeat packets regularly from the smart device to the device manager, to maintain the heartbeat connection.

37. The system of claim 30, wherein the smart device is provided in plurality, and each smart device is in communication connection with the server, while each smart device is a cash register.

38. The system of any one of claims 30 to 37, wherein any of the heartbeat connection fails, the corresponding smart device is offline.

39. The system of any one of claims 30 to 38, wherein the smart devices are powered and go online, data of the smart devices, including the device information, the service information, and the health information are collected from their clients for SDK to convert into a predetermined data format and register at the device manager DM
of the server.

40. The system of any one of claims 30 to 39, wherein the SDK receives and analyzes to check the response message contains the latest configuration data, wherein yes, the SDK refreshes the local configuration of the software development kit SDK
accordingly, wherein no, existing local configuration of SDK remains.

41. The system of any one of claims 30 to 40, wherein the heartbeat packet issued for the first heartbeat only contains device information including store ID No., the serial number of the device, and device name.

Date Regue/Date Received 2023-05-02

42. The system of any one of claims 30 to 41, wherein the SDK automatically sends the heartbeat packet to the DM based on the TTL on a periodic basis an completed without calling SDK interface by the client terminal.

43. The system of any one of claims 30 to 42, wherein the device information in the heartbeat packet includes the device serial number and the heartbeat parameter TTL.

44. The system of any one of claims 30 to 43, wherein the service information includes number of times of transaction in the heartbeat cycle and remaining charge in the smart device.

45. The system of any one of claims 30 to 44, wherein the heartbeat parameter TTL and the latest configuration data are sent with response from a login interface or heartbeat interface of the device manager DM.

46. The system of any one of claims 30 to 45, wherein in the event of a failed heartbeat, the software development kit pushes a heartbeat failure notification to the client terminal.

47. The system of any one of claims 30 to 46, wherein the smart device is provided with an interface for inspecting error information at a driving level.

48. The system of any one of claims 30 to 47, wherein the software development kit has built-in capability for error inspection.

49. The system of any one of claims 30 to 48, wherein the smart device has an error during heartbeats, when initiating a heartbeat, the software development kit first calls inspection interface at the driving level to acquire the error code and its corresponding error description, wherein the error code and its corresponding error description are carried by the heartbeat packet sent to the device manager.

50. The system of any one of claims 30 to 49, wherein the inspection interface driven by the smart device adopts a private protocol and supports docking comprises:
the information is acquired by accessing a local port at the smart device through a Date Regue/Date Received 2023-05-02 socket;
the information is transmitted in by calling a relevant interface at the software development kit after inspection performed by the client terminal; and the information is transmitted in from an error interface of the software development kit, including an Error Code parameter and an Error Info parameter.

51. The system of any one of claims 30 to 50, wherein the transaction order is recorded through setting a bury point in a non-reentrant functional key path of the transaction.

52. The system of any one of claims 30 to 51, wherein network jitter or interruption, server breakdown, or power outage occurs, the heartbeat connection breaks.

53. The system of any one of claims 30 to 52, wherein for preventing consequences of a signaling storm, there are two reconnection mechanisms including an emergency retry and a backend retry.

54. The system of any one of claims 30 to 53, wherein an emergency retry strategy is distributed by the device manager actively in response to registration of a user, or returned with the response message after the heartbeat, or is transmitted directly by the client terminal.

55. The system of any one of claims 30 to 54, wherein the heartbeat fails, a retry heartbeat request is sent until number of failed retry attempts exceeds a threshold.

56. The system of any one of claims 30 to 55, wherein the backend retry is distributed by the device manager actively in response to registration of the user, or is returned with the response message after the heartbeat, or is directly transmitted by the client terminal.

57. The system of any one of claims 30 to 56, wherein the heartbeat fails, interval between heartbeat requests is redefined, wherein the interval is set slightly shorter than a normal heartbeat cycle.

58. The system of any one of claims 30 to 57, wherein retry attempts are made until the Date Regue/Date Received 2023-05-02 device manager sends back the heartbeat response indicates successful restoration of heartbeats.

59. A method comprising:
providing a heartbeat connection between a server and a smart device, for the server to receive from the smart device a heartbeat packet containing device information, service information and/or health information;
wherein the heartbeat connection between the server and the smart device comprises:
providing the smart device with a client terminal and a software development kit (SDK);
providing the server with a device manager (DM);
initializing the software development kit using the client terminal;
sending a login message from the software development kit to the device manager to request for registration;
from the device manager, returning a response message to the software development kit based on the login message; and the software development kit, analyzing the response message to extract a heartbeat parameter (T11), wherein heartbeat relationship is established between the software development kit and the device manager, wherein the SDK
automatically sends the heartbeat packet to the DM based on the TTL.

60. The method of claim 59, further comprises:
at the server, sinking the service information and/or the health information based on the device information, and synchronizing reported data of the smart device;
sending a heartbeat response from the server to the smart device, to maintain the heartbeat connection therebetween; and monitoring the smart device and/or managing operation thereof based on the heartbeat Date Regue/Date Received 2023-05-02 connection, the service information, and/or the health information.

61. The method of claim 60, wherein the response message canies latest configuration data in addition to the heartbeat parameter, wherein the latest configuration data refreshes a local configuration at the software development kit.

62. The method of any one of claims 60 and 61, further comprises:
the software development kit, automatically initiating a heartbeat request as a heartbeat packet to the device manager based on the heartbeat parameter, wherein the device information includes a device serial number, wherein the service information includes a count of transactions in a heartbeat cycle, and wherein the health information includes an error code and a corresponding error description; and wherein the software development kit fails to establish the heartbeat relationship between the software development kit and the device manager, at the software development kit, actively sending a failure notification to the client terminal.

63. The method of claim 62, wherein the count of transactions in the heartbeat cycle is counted comprises:
the client terminal of the smart device generates a transaction order, recording the transaction order by calling an event tracking interface of the software development kit; and at the software development kit, summing up the transaction orders recorded in one heartbeat cycle to obtain the count of transactions in current heartbeat cycle.

64. The method of claim 63, further comprises:
providing a united subscription service interface at the device manager, allowing a monitoring platform to acquire the service information and/or the health information from the device manager and information about the failure notification from the software development kit related to the heartbeat connection through the united subscription service interface.

Date Regue/Date Received 2023-05-02

65. The method of claim 63, wherein sending the heartbeat response from the server to the smart device, to maintain the heartbeat connection therebetween comprises:
after the smart device successfully sinks reported data in the heartbeat packet, at the device manager, actively notifying a monitoring platfolin;
at the device manager, returning the response message carrying the latest configuration data and the heartbeat parameter to the software development kit; and according to the heartbeat parameter, sending heartbeat packets regularly from the smart device to the device manager, to maintain the heartbeat connection.

66. The method of claim 59, wherein the smart device is provided in plurality, and each smart device is in communication connection with the server, while each smart device is a cash register.

67. The method of any one of claims 59 to 66, wherein any of the heartbeat connection fails, the corresponding smart device is offline.

68. The method of any one of claims 59 to 67, wherein the smart devices are powered and go online, data of the smart devices, including the device information, the service information, and the health information are collected from their clients for SDK to convert into a predetermined data format and register at the device manager DM
of the server.

69. The method of any one of claims 59 to 68, wherein the SDK receives and analyzes to check the response message contains the latest configuration data, wherein yes, the SDK refreshes the local configuration of the software development kit SDK
accordingly, wherein no, existing local configuration of SDK remains.

70. The method of any one of claims 59 to 69, wherein the heartbeat packet issued for the first heartbeat only contains device information including store ID No., the serial number of the device, and device name.

71. The method of any one of claims 59 to 70, wherein the SDK automatically sends the Date Regue/Date Received 2023-05-02 heartbeat packet to the DM based on the TTL on a periodic basis an completed without calling SDK interface by the client terminal.

72. The method of any one of claims 59 to 71, wherein the device information in the heartbeat packet includes the device serial number and the heartbeat parameter TTL.

73. The method of any one of claims 59 to 72, wherein the service information includes number of times of transaction in the heartbeat cycle and remaining charge in the smart device.

74. The method of any one of claims 59 to 73, wherein the heartbeat parameter TTL
and the latest configuration data are sent with response from a login interface or heartbeat interface of the device manager DM.

75. The method of any one of claims 59 to 74, wherein in the event of a failed heartbeat, the software development kit pushes a heartbeat failure notification to the client terminal.

76. The method of any one of claims 59 to 75, wherein the smart device is provided with an interface for inspecting error information at a driving level.

77. The method of any one of claims 59 to 76, wherein the software development kit has built-in capability for error inspection.

78. The method of any one of claims 59 to 77, wherein the smart device has an error during heartbeats, when initiating a heartbeat, the software development kit first calls inspection interface at the driving level to acquire the error code and its corresponding error description, wherein the error code and its corresponding error description are carried by the heartbeat packet sent to the device manager.

79. The method of any one of claims 59 to 78, wherein the inspection interface driven by the smart device adopts a private protocol and supports docking comprises:
the information is acquired by accessing a local port at the smart device through a socket;
Date Regue/Date Received 2023-05-02 the information is transmitted in by calling a relevant interface at the software development kit after inspection performed by the client terminal; and the information is transmitted in from an error interface of the software development kit, including an Error Code parameter and an Error Info parameter.

80. The method of any one of claims 59 to 79, wherein the transaction order is recorded through setting a bury point in a non-reentrant functional key path of the transaction.

81. The method of any one of claims 59 to 80, wherein network jitter or interruption, server breakdown, or power outage occurs, the heartbeat connection breaks.

82. The method of any one of claims 59 to 81, wherein for preventing consequences of a signaling storm, there are two reconnection mechanisms including an emergency retry and a backend retry.

83. The method of any one of claims 59 to 82, wherein an emergency retry strategy is distributed by the device manager actively in response to registration of a user, or returned with the response message after the heartbeat, or is transmitted directly by the client terminal.

84. The method of any one of claims 59 to 83, wherein the heartbeat fails, a retry heartbeat request is sent until number of failed retry attempts exceeds a threshold.

85. The method of any one of claims 59 to 84, wherein the backend retry is distributed by the device manager actively in response to registration of the user, or is returned with the response message after the heartbeat, or is directly transmitted by the client terminal.

86. The method of any one of claims 59 to 85, wherein the heartbeat fails, interval between heartbeat requests is redefined, wherein the interval is set slightly shorter than a normal heartbeat cycle.

87. The method of any one of claims 59 to 86, wherein retry attempts are made until the device manager sends back the heartbeat response indicates successful restoration of Date Regue/Date Received 2023-05-02 heartbeats.

88. A computer readable physical memory having stored thereon a computer program executed by a computer configured to:
provide a heartbeat connection between a server and a smart device, for the server to receive from the smart device a heartbeat packet containing device information, service infoimation and/or health information;
wherein the heartbeat connection between the server and the smart device comprises:
providing the smart device with a client terminal and a software development kit (SDK);
providing the server with a device manager (DM);
initializing the software development kit using the client terminal;
sending a login message from the software development kit to the device manager to request for registration;
from the device manager, returning a response message to the software development kit based on the login message; and the software development kit, analyzing the response message to extract a heartbeat parameter (T11), wherein heartbeat relationship is established between the software development kit and the device manager, wherein the SDK
automatically sends the heartbeat packet to the DM based on the TTL.

89. The memory of claim 88, further comprises:
at the server, sink the service information and/or the health information based on the device information, and synchronize reported data of the smart device;
send a heartbeat response from the server to the smart device, to maintain the heartbeat connection therebetween; and monitor the smart device and/or manage operation thereof based on the heartbeat Date Regue/Date Received 2023-05-02 connection, the service information, and/or the health information.

90. The memory of claim 89, wherein the response message carries latest configuration data in addition to the heartbeat parameter, wherein the latest configuration data refreshes a local configuration at the software development kit.

91. The memory of any one of claims 89 and 90, further comprises:
the software development kit, automatically initiating a heartbeat request as a heartbeat packet to the device manager based on the heartbeat parameter, wherein the device information includes a device serial number, wherein the service information includes a count of transactions in a heartbeat cycle, and wherein the health information includes an error code and a corresponding error description; and wherein the software development kit fails to establish the heartbeat relationship between the software development kit and the device manager, at the software development kit, actively sending a failure notification to the client terminal.

92. The memory of claim 91, wherein the count of transactions in the heartbeat cycle is counted comprises:
the client terminal of the smart device generates a transaction order, recording the transaction order by calling an event tracking interface of the software development kit; and at the software development kit, summing up the transaction orders recorded in one heartbeat cycle to obtain the count of transactions in current heartbeat cycle.

93. The memory of claim 92, further comprises:
providing a united subscription service interface at the device manager, allowing a monitoring platform to acquire the service information and/or the health information from the device manager and information about the failure notification from the software development kit related to the heartbeat connection through the united subscription service interface.

Date Regue/Date Received 2023-05-02

94. The memory of claim 92, wherein sending the heartbeat response from the server to the smart device, to maintain the heartbeat connection therebetween comprises:
after the smart device successfully sinks reported data in the heartbeat packet, at the device manager, actively notifying a monitoring platform;
at the device manager, returning the response message carrying the latest configuration data and the heartbeat parameter to the software development kit; and according to the heartbeat parameter, sending heartbeat packets regularly from the smart device to the device manager, to maintain the heartbeat connection.

95. The memory of claim 88, wherein the smart device is provided in plurality, and each smart device is in communication connection with the server, while each smart device is a cash register.

96. The memory of any one of claims 88 to 95, wherein any of the heartbeat connection fails, the corresponding smart device is offline.

97. The memory of any one of claims 88 to 96, wherein the smart devices are powered and go online, data of the smart devices, including the device information, the service information, and the health information are collected from their clients for SDK to convert into a predetermined data format and register at the device manager DM
of the server.

98. The memory of any one of claims 88 to 97, wherein the SDK receives and analyzes to check the response message contains the latest configuration data, wherein yes, the SDK refreshes the local configuration of the software development kit SDK
accordingly, wherein no, existing local configuration of SDK remains.

99. The memory of any one of claims 88 to 98, wherein the heartbeat packet issued for the first heartbeat only contains device information including store ID No., the serial number of the device, and device name.

100. The memory of any one of claims 88 to 99, wherein the SDK automatically sends the Date Regue/Date Received 2023-05-02 heartbeat packet to the DM based on the TTL on a periodic basis an completed without calling SDK interface by the client terminal.

101. The memory of any one of claims 88 to 100, wherein the device information in the heartbeat packet includes the device serial number and the heartbeat parameter TTL.

102. The memory of any one of claims 88 to 101, wherein the service information includes number of times of transaction in the heartbeat cycle and remaining charge in the smart device.

103. The memory of any one of claims 88 to 102, wherein the heartbeat parameter TTL
and the latest configuration data are sent with response from a login interface or heartbeat interface of the device manager DM.

104. The memory of any one of claims 88 to 103, wherein in the event of a failed heartbeat, the software development kit pushes a heartbeat failure notification to the client terminal.

105. The memory of any one of claims 88 to 104, wherein the smart device is provided with an interface for inspecting error information at a driving level.

106. The memory of any one of claims 88 to 105, wherein the software development kit has built-in capability for error inspection.

107. The memory of any one of claims 88 to 106, wherein the smart device has an error during heartbeats, when initiating a heartbeat, the software development kit first calls inspection interface at the driving level to acquire the error code and its corresponding error description, wherein the error code and its corresponding error description are carried by the heartbeat packet sent to the device manager.

108. The memory of any one of claims 88 to 106, wherein the inspection interface driven by the smart device adopts a private protocol and supports docking comprises:
the information is acquired by accessing a local port at the smart device through a socket;
Date Regue/Date Received 2023-05-02 the information is transmitted in by calling a relevant interface at the software development kit after inspection performed by the client terminal; and the information is transmitted in from an error interface of the software development kit, including an Error Code parameter and an Error Info parameter.

109. The memory of any one of claims 88 to 108, wherein the transaction order is recorded through setting a bury point in a non-reentrant functional key path of the transaction.

110. The memory of any one of claims 88 to 109, wherein network jitter or interruption, server breakdown, or power outage occurs, the heartbeat connection breaks.

111. The memory of any one of claims 88 to 110, wherein for preventing consequences of a signaling storm, there are two reconnection mechanisms including an emergency retry and a backend retry.

112. The memory of any one of claims 88 to 111, wherein an emergency retry strategy is distributed by the device manager actively in response to registration of a user, or returned with the response message after the heartbeat, or is transmitted directly by the client terminal.

113. The memory of any one of claims 88 to 112, wherein the heartbeat fails, a retry heartbeat request is sent until number of failed retry attempts exceeds a threshold.

114. The memory of any one of claims 88 to 113, wherein the backend retry is distributed by the device manager actively in response to registration of the user, or is returned with the response message after the heartbeat, or is directly transmitted by the client terminal.

115. The memory of any one of claims 88 to 114, wherein the heartbeat fails, interval between heartbeat requests is redefined, wherein the interval is set slightly shorter than a normal heartbeat cycle.

116. The memory of any one of claims 88 to 115, wherein retry attempts are made until the device manager sends back the heartbeat response indicates successful restoration of Date Regue/Date Received 2023-05-02 heartbeats.

Date Recue/Date Received 2023-05-02