Note : Les revendications sont présentées dans la langue officielle dans laquelle elles ont été soumises.
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
17
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:
18
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.
19
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.
21
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
22
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:
23
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.
24
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.
26
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
27
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:
28
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.
29
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.
31
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
32
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:
33
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.
34
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.
36
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.
37
Date Recue/Date Received 2023-12-07