SMART DEVICE MONITORING METHOD AND APPARATUS

PROCEDE ET APPAREIL DE SURVEILLANCE DE DISPOSITIF INTELLIGENT

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

French Abstract

L'invention concerne un procédé et un appareil de surveillance de dispositif intelligent, qui se rapportent au domaine technique de la gestion de dispositifs terminaux et qui peuvent fournir des services de gestion et de surveillance unifiés pour un dispositif intelligent utilisé dans diverses chaînes de magasins O2O. Le procédé comprend les étapes suivantes : un serveur est en connexion de battement de cur avec un dispositif intelligent, utilisé pour recevoir un paquet de battement de cur comprenant des informations de dispositif, des informations de service et/ou des informations de santé envoyées par le dispositif intelligent ; le serveur stocke les informations de service et/ou les informations de santé dans une base de données sur la base des informations de dispositif, et synchronise les données rapportées du dispositif intelligent ; le serveur renvoie une réponse de battement de cur au dispositif intelligent, maintenant sa connexion de battement de cur ; sur la base de la relation de connexion de battement de cur, d'informations de service et/ou d'informations de santé, la réalisation d'une surveillance d'état et/ou d'une gestion de fonctionnement du dispositif intelligent. L'appareil applique le procédé de surveillance de dispositif intelligent.

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

Description

CA 03166102 2022-06-27
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
1
Date Regue/Date Received 2022-06-27

CA 03166102 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.
2
Date Regue/Date Received 2022-06-27

CA 03166102 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
3
Date Regue/Date Received 2022-06-27

CA 03166102 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
4
Date Regue/Date Received 2022-06-27

CA 03166102 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

CA 03166102 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,
6
Date Regue/Date Received 2022-06-27

CA 03166102 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
7
Date Regue/Date Received 2022-06-27

CA 03166102 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,
8
Date Regue/Date Received 2022-06-27

CA 03166102 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
9
Date Regue/Date Received 2022-06-27

CA 03166102 2022-06-27
II
41111
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

CA 03166102 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
11
Date Regue/Date Received 2022-06-27

CA 03166102 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.
12
Date Regue/Date Received 2022-06-27

CA 03166102 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
13
Date Regue/Date Received 2022-06-27

CA 03166102 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
14
Date Regue/Date Received 2022-06-27

CA 03166102 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

CA 03166102 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.
16
Date Regue/Date Received 2022-06-27

Representative Drawing