CA3166102C

CA3166102C - Smart device monitoring method and apparatus

Info

Publication number: CA3166102C
Application number: CA3166102A
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: 2024-03-19
Anticipated expiration: 2040-08-28
Also published as: CN111200538B; CA3166102A1; WO2021128915A1; CA3177668A1; CA3177668C; CN111200538A

Abstract

Provided are a smart device monitoring method and apparatus, which relate to the technical field of terminal device management and which can provide unified management and monitoring services for a smart device used in various chain O2O stores. The method comprises: a server is in heartbeat connection with a smart device, used for receiving a heartbeat packet comprising device information, service information, and/or health information sent by the smart device; the server storing the service information and/or health information in a database on the basis of the device information, and synchronizing the reported data of the smart device; the server returning a heartbeat response to the smart device, maintaining its heartbeat connection; on the basis of the heartbeat connection relationship, service information, and/or health information, performing status monitoring and/or operation management of the smart device. The apparatus applies the smart device monitoring method.

Description

SMART DEVICE MONITORING METHOD AND APPARATUS
BACKGROUND OF THE INVENTION
Technical Field [0001] The present invention relates to management of terminal 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 2022-06-27 to receive from the smart device a heartbeat packet containing device information, service information and/or health information;

[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 Client and a software development kit SDK, and providing the server with a device manager DM;

[0012] initializing SDK using the client, 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 TTL, 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.

Date Regue/Date Received 2022-06-27

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

[0019] every time the client of the smart device generates a transaction order, recording the transaction order by calling an event tracking interface of SDK through Client; 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 2022-06-27 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 2022-06-27 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 2022-06-27

[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 2022-06-27 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 Client 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:
,,,,f Arly_wipmchifm,,,,mkiiiiiiiiimmollopp.onniminemmaiiilunkNammou iiim ifitilfillfi 11111111rAW Ilnillff 11V Ziwoia 10(Ill I 1 Lid I icld 1)c,c1 iption Rciii,111, , 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 2022-06-27 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 [11 Lid IILid iptom iiiiioo Rom] k Store ID No. The unique Identification of the store Mandatory State The state information Optional Area The area information 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 2022-06-27 configuring its intranet interface so that DM can actively perform inspection

[0057] c) Device State Information icld I icILI I )c,.st iption Rcm,111, 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 Information II "
ICIll 11)11011 RCincii 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 2022-06-27 II

DC',C111)t 1011 RCI11,111\
Store ID No. The unique Identification of the store Mandatory State The state information Mandatory Region The region information 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 Client 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 2022-06-27 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 the client Client. 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 2022-06-27 by the client 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 Client. In the event of a failed heartbeat, the software development kit SDK
pushes a heartbeat failure notification to the client Client, 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 Client; 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 case, it is determined that the smart device is offline or has been turned off.

Date Regue/Date Received 2022-06-27

[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; 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 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 Client. 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 Client.

[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 this end, the present embodiment provides two reconnection mechanisms. The first one Date Regue/Date Received 2022-06-27 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 Client. 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 Client.
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 normal 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 information 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 terms.

[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 operational health information of his/her device through a socket or an API, making Date Regue/Date Received 2022-06-27 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 information, 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.

[0083] As compared to the prior art, the disclosed apparatus for monitoring a smart device as Date Regue/Date Received 2022-06-27 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 2022-06-27

Claims

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 server receives the heartbeat packet from a software development kit (SDK) in the smart device;
a data sinking unit, at the server, configured to data 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, at the server, configured to return a heartbeat response to the smart device, to maintain the heartbeat connection therebetween, wherein the SDK
analyzes a response message to extract a heartbeat parameter (TTL); and 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.

2. The apparatus of claim 1, wherein the heartbeat connection between the server and the smart device comprises:
providing the smart device with a client and the software development kit (SDK);
providing the server with a device manager (DM);
initializing the software development kit using the client;
sending a login message from the software development kit to the device manager to request for registration;
from the device manager, returning the response message to the software development kit based on the login message; and Date Recue/Date Received 2023-12-07 at the software development kit, analyzing the response message to extract the heartbeat parameter, wherein heartbeat relationship is established between the software development kit and the device manager.

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:
at 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.

5. The apparatus of claim 4, wherein count of transactions in the heartbeat cycle is counted comprises:
every time the client of the smart device generates a transaction order, recording the transaction order by calling an event tracking interface of the software development kit through the client; 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:

Date Recue/Date Received 2023-12-07 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.

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 data 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.

Date Recue/Date Received 2023-12-07

12. The apparatus of any one of claims 1 to 11, 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.

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.

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 1-1L.

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.

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 a corresponding error description, wherein the error code and the corresponding error description are carried by the heartbeat packet sent to the device manager.
Date Recue/Date Received 2023-12-07

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:
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; 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 if an event of 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.

26. The apparatus of any one of claims 1 to 25, where if 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.

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

Date Recue/Date Received 2023-12-07

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 server receives the heartbeat packet from a software development kit in the smart device;
at the server, data 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, wherein the SDK analyzes a response message to extract a heartbeat parameter (T1t); and monitoring the smart device and/or managing operation thereof based on the heartbeat connection, the service information, and/or the health information.

31. The system of claim 30, wherein the heartbeat connection between the server and the smart device comprises:
providing the smart device with a client and the software development kit (SDK);
providing the server with a device manager (DM);
initializing the software development kit using the client;
sending a login message from the software development kit to the device manager to request for registration;
from the device manager, returning the response message to the software development kit based on the login message; and Date Recue/Date Received 2023-12-07 at the software development kit, analyzing the response message to extract the heartbeat parameter, wherein heartbeat relationship is established between the software development kit and the device manager.

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:
at 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.

34. The system of claim 33, wherein count of transactions in the heartbeat cycle is counted comprises:
every time the client of the smart device generates a transaction order, recording the transaction order by calling an event tracking interface of the software development kit through the client; 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:

Date Recue/Date Received 2023-12-07 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.

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 data 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.

Date Recue/Date Received 2023-12-07

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.

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.

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 lit.

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.

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 a corresponding error description, wherein the error code and the corresponding error description are canied by the heartbeat packet sent to the device manager.
Date Recue/Date Received 2023-12-07

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 socket;
the information is transmitted in by calling a relevant interface at the software development kit after inspection performed by the client; 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 if an event of 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.

55. The system of any one of claims 30 to 54, where if 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.

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

Date Recue/Date Received 2023-12-07

58. The system of any one of claims 30 to 57, wherein retry attempts are made until the 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 server receives the heartbeat packet from a software development kit in the smart device;
at the server, data 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, wherein the SDK analyzes a response message to extract a heartbeat parameter (TIL); and monitoring the smart device and/or managing operation thereof based on the heartbeat connection, the service information, and/or the health information.

60. The method of claim 59, wherein the heartbeat connection between the server and the smart device comprises:
providing the smart device with a client and the software development kit (SDK);
providing the server with a device manager (DM);
initializing the software development kit using the client;
sending a login message from the software development kit to the device manager to request for registration;
from the device manager, returning the response message to the software development kit based on the login message; and Date Recue/Date Received 2023-12-07 at the software development kit, analyzing the response message to extract the heartbeat parameter, wherein heartbeat relationship is established between the software development kit and the device manager.

61. The method of claim 60, 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.

62. The method of any one of claims 60 and 61, further comprises:
at 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.

63. The method of claim 62, wherein count of transactions in the heartbeat cycle is counted comprises:
every time the client of the smart device generates a transaction order, recording the transaction order by calling an event tracking interface of the software development kit through the client; 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:

Date Recue/Date Received 2023-12-07 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.

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 data 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.

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.

Date Recue/Date Received 2023-12-07

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 heartbeat packet to the DM based on the TTL on a periodic basis an completed without calling SDK interface by the client.

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 1-1t.

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.

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 a corresponding error description, wherein the error code and the corresponding error description are canied by the heartbeat packet sent to the device manager.
Date Recue/Date Received 2023-12-07

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;
the information is transmitted in by calling a relevant interface at the software development kit after inspection performed by the client; 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 if an event of 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.

84. The method of any one of claims 59 to 83, where if 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.

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

Date Recue/Date Received 2023-12-07

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 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 information and/or health information, wherein the server receives the heartbeat packet from a software development kit in the smart device;
at the server, data 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, wherein the SDK analyzes a response message to extract a heartbeat parameter (TTL); and monitor the smart device and/or manage operation thereof based on the heartbeat connection, the service information, and/or the health information.

89. The memory of claim 88, wherein the heartbeat connection between the server and the smart device comprises:
providing the smart device with a client and the software development kit (SDK);
providing the server with a device manager (DM);
initializing the software development kit using the client;
sending a login message from the software development kit to the device manager to request for registration;
from the device manager, returning the response message to the software development kit based on the login message; and Date Recue/Date Received 2023-12-07 at the software development kit, analyzing the response message to extract the heartbeat parameter, wherein heartbeat relationship is established between the software development kit and the device manager.

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:
at 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.

92. The memory of claim 91, wherein count of transactions in the heartbeat cycle is counted comprises:
every time the client of the smart device generates a transaction order, recording the transaction order by calling an event tracking interface of the software development kit through the client; 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:

Date Recue/Date Received 2023-12-07 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.

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 data 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 pluraiity, 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.

Date Recue/Date Received 2023-12-07

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 heartbeat packet to the DM based on the TTL on a periodic basis an completed without calling SDK interface by the client.

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 1-1L.

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.

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 a corresponding error description, wherein the enor code and the corresponding error description are carried by the heartbeat packet sent to the device manager.
Date Recue/Date Received 2023-12-07

108. The memory of any one of claims 88 to 107, 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;
the information is transmitted in by calling a relevant interface at the software development kit after inspection performed by the client; 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 if an event of 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.

113. The memory of any one of claims 88 to 112, where if 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.

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

Date Recue/Date Received 2023-12-07

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 heartbeats.

Date Recue/Date Received 2023-12-07