A method and system for making emergency calls using a hardware payment device

Abstract

The present invention provides a method and system for emergency rescue using a hardware payment device, including: a first hardware payment device detects whether a rescue event is triggered, and when it is detected that a rescue event is triggered, generates a rescue smart contract and a first signed data packet obtained by signing; the rescue smart contract and the first signed data packet are sent outwardly by broadcasting; a second hardware payment device verifies the signature and displays the rescue smart contract; when it is detected that a rescue confirmation button is triggered, rescue response information is generated, signed to obtain a second signed data packet and sent to a background server; the background server verifies the rescue response information, generates a third signed data packet, and sends it to a bank server; the second hardware payment device receives a ban release instruction corresponding to a payment voucher to be signed sent by the bank server, and uses the ban release instruction to remove the unavailable mark of the payment voucher to be signed, and obtains an available payment voucher to be signed.

Description

Technical Field

[0001] The present invention relates to the field of electronic technology, and in particular to a method and system for emergency assistance using a hardware payment device. Background Art

[0002] As the aging of the population in my country becomes increasingly serious, more and more elderly people choose to live alone or live in nursing homes and other elderly care service places. However, since it is difficult for the elderly to actively call for help in time when they have a sudden illness, they often miss the treatment opportunity due to the inability to provide timely rescue. Therefore, how to design a method for calling for help or a portable device so that the person calling for help can use the portable device to complete the call for help simply and timely, and the potential rescuer can receive the help information in time through the portable device is a technical problem that needs to be solved in this field. Summary of the invention

[0003] The present invention aims to solve one or more of the above problems.

[0004] The main purpose of the present invention is to provide a method for emergency rescue using a hardware payment device, including: a first hardware payment device detects whether a rescue event is triggered; when it is detected that a rescue event is triggered, the first hardware payment device determines the emergency situation corresponding to the rescue event according to a preset rule, generates a rescue smart contract and a first signature data packet obtained by signing the rescue smart contract according to the emergency situation, wherein the rescue smart contract includes rescue information and a payment voucher to be signed, and the payment voucher to be signed contains an unavailable mark, and the unavailable mark makes the payment voucher to be signed in an unavailable state; the first hardware payment device sends the rescue smart contract and the first signature data packet to the outside by broadcasting; the second hardware payment device receives the rescue smart contract and the first signature data packet, verifies the rescue smart contract using the first signature data packet, and displays the rescue smart contract after the verification is passed; the second hardware payment device detects whether a rescue confirmation button is triggered, and when it is detected that the rescue confirmation button is triggered, the second hardware payment device stores the rescue smart contract; the second hardware payment device generates rescue response information, and responds to the rescue response information The second signature data packet is signed to obtain the second signature data packet, and the rescue response information and the second signature data packet are sent to the background server, wherein the rescue response information includes the rescue information and the rescuer information, and the rescuer information includes the ID information of the holder of the second hardware payment device; after receiving the rescue response information and the second signature data packet, the background server uses the second signature data packet to verify the rescue response information, obtains the rescue response information after the verification, obtains the acceptance information according to the rescue response information, signs the acceptance information to generate a third signature data packet, and sends the acceptance information and the third signature data packet to the bank server, wherein the acceptance information includes the rescue response information and the acceptance status record, and the acceptance status record is obtained according to the rescue information and the rescuer information; the second hardware payment device receives the unblocking instruction corresponding to the payment voucher to be signed sent by the bank server, and uses the unblocking instruction to remove the unavailable mark of the payment voucher to be signed to obtain an available payment voucher to be signed, wherein the unblocking instruction is generated by the bank server according to the acceptance information after receiving the acceptance information and the third signature data packet and verifying the third signature data packet.

[0005] In addition, before or after the second hardware payment device sends the rescue response information and the second signature data packet to the background server, the method also includes: the second hardware payment device sends the rescue response information and the second signature data packet to the first hardware payment device; the first hardware payment device uses the second signature data packet to verify the rescue response information, and saves the rescue response information after the verification is passed.

[0006] In addition, after the first hardware payment device saves the rescue response information, the method further includes: the first hardware payment device sending a rescue response confirmation message to the bank server, where the rescue response confirmation message at least includes a rescue smart contract, the rescue response information, and a second signature data packet.

[0007] In addition, the background server sending the acceptance information and the third signature data packet to the bank server includes: the background server directly sending the acceptance information and the third signature data packet to the bank server; or, the background server sending the acceptance information and the third signature data packet to the second payment device, and the second payment device sending the acceptance information and the third signature data packet to the bank server.

[0008] In addition, the distress message at least includes the following information: personal information of the holder of the first hardware payment device, the location, the content of the rescue, the amount of the payment voucher to be signed, and the digital certificate of the first hardware payment device.

[0009] Another main purpose of the present invention is to provide a system for emergency rescue using a hardware payment device, including a first hardware payment device, a second hardware payment device and a background server; wherein the first hardware payment device is used to detect whether a rescue event is triggered; when a rescue event is detected to be triggered, the emergency situation corresponding to the rescue event is determined according to preset rules, and a rescue smart contract and a first signature data packet obtained by signing the rescue smart contract are generated according to the emergency situation, wherein the rescue smart contract includes rescue information and a payment voucher to be signed, and the payment voucher to be signed contains an unavailable mark, and the unavailable mark makes the payment voucher to be signed in an unavailable state; the rescue smart contract and the first signature data packet are sent outwardly by broadcasting; the second hardware payment device is used to receive the rescue smart contract and the first signature data packet, use the first signature data packet to verify the rescue smart contract, and display the rescue smart contract after the verification is passed; detect whether a rescue confirmation button is triggered, and when it is detected that the rescue confirmation button is triggered, store the rescue smart contract; generate rescue response information, and sign the rescue response information to obtain The second signature data packet sends the rescue response information and the second signature data packet to the background server, wherein the rescue response information includes the rescue information and the rescuer information, and the rescuer information includes the ID information of the holder of the second hardware payment device; the background server is used to verify the rescue response information with the second signature data packet after receiving the rescue response information and the second signature data packet, obtain the rescue response information after the verification, obtain the acceptance information according to the rescue response information, sign the acceptance information to generate a third signature data packet, and send the acceptance information and the third signature data packet to the bank server, wherein the acceptance information includes the rescue response information and the acceptance status record, and the acceptance status record is obtained according to the rescue information and the rescuer information; the second hardware payment device is also used to receive the unblocking instruction corresponding to the payment voucher to be signed sent by the bank server, use the unblocking instruction to remove the unavailable mark of the payment voucher to be signed, and obtain an available payment voucher to be signed, wherein the unblocking instruction is generated by the bank server according to the acceptance information after receiving the acceptance information and the third signature data packet and verifying the third signature data packet.

[0010] In addition, before or after the second hardware payment device is used to send the rescue response information and the second signature data packet to the background server, it also includes: the second hardware payment device is also used to send the rescue response information and the second signature data packet to the first hardware payment device; the first hardware payment device is also used to verify the rescue response information using the second signature data packet, and save the rescue response information after the verification is passed.

[0011] In addition, after the first hardware payment device is used to save the rescue response information, it further includes: the first hardware payment device is further used to send a rescue response confirmation message to the bank server, where the rescue response confirmation message at least includes a rescue smart contract, a rescue response information, and a second signature data packet.

[0012] In addition, for the background server to send the acceptance information and the third signature data packet to the bank server, it includes: the background server is used to directly send the acceptance information and the third signature data packet to the bank server; or, the background server is used to send the acceptance information and the third signature data packet to the second payment device, and the second payment device is further used to send the acceptance information and the third signature data packet to the bank server.

[0013] In addition, the rescue information at least includes the following information: personal information of the holder of the first hardware payment device, the location, the content of the rescue, the amount of the payment voucher to be signed, and the digital certificate of the first hardware payment device.

[0014] As can be seen from the technical solutions provided by the present invention above, the present invention provides a method and a system for emergency rescue using a hardware payment device in this embodiment, which can enable the person in distress to conveniently and quickly send a rescue message and rescue reward through the hardware payment device, simplifies the rescue and rescue process, and is beneficial for the person in distress to obtain rescue quickly. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0016] Figure 1 It is a flowchart of a method for emergency rescue using a hardware payment device provided in Embodiment 1 of the present invention;

[0017] Figure 2 It is a schematic structural diagram of a system for emergency rescue using a hardware payment device provided in Embodiment 2 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0019] In the description of the present invention, it should be understood that the orientation or positional relationships indicated by the terms "center", "longitudinal", "transverse", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc. are based on the orientation or positional relationships shown in the drawings. These are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation of the present invention. In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance, quantity or position.

[0020] In the description of the present invention, it should be noted that unless otherwise clearly specified and limited, the terms "installed", "connected", "connected to" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium, and it can be the communication inside two elements. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0021] The embodiments of the present invention will be further described in detail below with reference to the drawings.

[0022] Embodiment 1

[0023] This embodiment provides a method for making an emergency call using a hardware payment device, as Figure 1 shown, including:

[0024] Step S101, the first hardware payment device detects whether a distress event is triggered.

[0025] Specifically, the first hardware payment device is a small electronic device that can be carried or worn on the body. It has at least functions such as payment, identity credential, and communication, and is built-in with a security chip. In a specific implementation manner, the distress event can be triggered at least in the following ways: A dedicated preset button or button combination for making a distress call can be set on the first payment device. Once it is detected that the preset button or button combination is pressed, it is determined that a distress event has occurred. In addition, buttons with different functions such as calling for an ambulance and calling for emergency medical services can also be set; or, a voice monitoring module can be provided on the first payment device, and a voice command for making a distress call is preset in advance. When it is detected that the preset voice command is received, it is determined that a distress event has occurred; or, a module for monitoring the physical sign values of the holder of the first hardware payment device, such as pulse and blood oxygen value, can also be set on the first payment device. Once it is detected that the preset physical sign value of the holder of the first hardware payment device (i.e., the person in distress) reaches a preset threshold, it is determined that a distress event has occurred.

[0026] Step S102: When it is detected that a distress event is triggered, the first hardware payment device determines the emergency corresponding to the distress event according to a preset rule, generates a distress smart contract and a first signature data packet obtained by signing the distress smart contract. The distress smart contract includes distress information and a payment voucher to be signed, and the payment voucher to be signed contains an unavailable identifier, which makes the payment voucher to be signed in an unavailable state.

[0027] Specifically, the first hardware payment device determines the emergency situation where the holder is located according to the triggered distress event. For example, when it is determined that the holder is in an emergency situation where medical assistance is needed, the first hardware device obtains the distress information according to this emergency situation. The distress information may include specific content that the wearer needs help. In an optional implementation, the distress information may at least include the following information: personal information of the holder of the first hardware payment device (such as gender, age, etc.), the geographical location, the content of assistance, the amount of the payment voucher to be signed, and the digital certificate of the first hardware payment device. To ensure the non-repudiation of the distress information sent outwards, a signature data packet for the distress smart contract is also generated while generating the distress smart contract. The signature data packet can determine the identity of the first hardware payment device that sends out the distress smart contract, preventing the distress sender from retracting and repudiating after sending out the distress information, and ensuring the rights and interests of the rescuer. In addition, to prevent the rescuer from not implementing the rescue behavior after receiving the payment voucher to be signed, an unavailable identifier is set in the payment voucher to be signed. Before this identifier is lifted, the payment voucher to be signed cannot be used, ensuring the rights and interests of the distress sender.

[0028] Step S103: The first hardware payment device sends out the distress smart contract and the first signature data packet by broadcasting.

[0029] Specifically, the first hardware payment device has a communication function, and a long-distance communication or short-distance communication module can be built in to broadcast for help. In an optional implementation, the first hardware payment device can broadcast and send the distress smart contract and the signature data packet through narrowband Internet of Things; or, the first hardware payment device can broadcast and send the distress smart contract and the signature data packet through Bluetooth transmission. Through narrowband Internet of Things and Bluetooth data transmission, on the one hand, data can be transmitted quickly, and on the other hand, the distress seeker can be accurately located. Of course, the present invention can also be broadcast and sent through other wireless transmission methods as long as the broadcast requirements can be met, which will not be elaborated here.

[0030] Step S104: The second hardware payment device receives the distress smart contract and the first signature data packet, verifies the signature of the distress smart contract using the first signature data packet, and displays the distress smart contract after the signature verification passes.

[0031] Specifically, the second hardware payment device is a small electronic device that can be carried or worn with at least functions such as receiving payments and communication, and has a security chip built in. After receiving the distress smart contract and signature data packet broadcast by the first hardware device and confirming the reliability of the distress smart contract through signature verification, the second hardware payment device displays the information of the distress smart contract to the holder of the second hardware payment device (i.e., the rescuer). In an optional implementation, personal information of the person in distress (such as gender, age, etc.), location, content of the distress (e.g., being sent to XXX Hospital), etc. can be displayed. The holder of the second hardware payment device can judge whether to respond to the distress by himself / herself.

[0032] Step S105: The second hardware payment device detects whether the confirmation assistance button is triggered. When it detects that the confirmation assistance button is triggered, the second hardware payment device stores the distress smart contract.

[0033] Specifically, when the holder of the second hardware payment device decides to respond to the distress, he / she can respond by pressing the button of the second hardware payment device, store the distress smart contract, and then carry out the rescue behavior.

[0034] Step S106: The second hardware payment device generates a rescue response message, signs the rescue response message to obtain a second signature data packet, and sends the rescue response message and the second signature data packet to the background server. Among them, the rescue response message includes the distress information and the rescuer information, and the rescuer information includes the ID information of the holder of the second hardware payment device.

[0035] Specifically, the second hardware payment device generates a rescue response message and sends it to the background server, facilitating the background server to timely follow up and supervise whether the current distress has received a response and the rescue situation.

[0036] Step S107: After receiving the rescue response message and the second signature data packet, the background server uses the second signature data packet to verify the signature of the rescue response message. After the signature verification passes, it obtains the rescue response message, obtains the acceptance information according to the rescue response message, signs the acceptance information to generate a third signature data packet, and sends the acceptance information and the third signature data packet to the bank server. Among them, the acceptance information includes the rescue response message and the acceptance situation record, and the acceptance situation record is obtained according to the distress information and the rescuer information.

[0037] In an optional implementation, the background server can be the server of a hospital or a third-party server that establishes the distress system. It supervises the rescue situation, generates a third signature data packet after obtaining the rescue response message to prove that the rescue behavior has been completed, and notifies the bank server.

[0038] Step S108, the second hardware payment device receives the unblocking instruction corresponding to the payment voucher to be signed sent by the bank server, and uses the unblocking instruction to remove the unavailable mark of the payment voucher to be signed to obtain an available payment voucher to be signed, wherein the unblocking instruction is generated by the bank server according to the acceptance information after receiving the acceptance information and the third signature data packet and verifying the third signature data packet.

[0039] Specifically, after the rescuer completes the rescue and the backend server sends the relevant information to the backend server, the backend server confirms whether the rescue is indeed completed based on the rescue completion information and the content of the rescue smart contract after receiving the rescue completion information. If it is indeed completed, the backend server sends the unblocking instruction corresponding to the payment voucher to be signed to the bank server so that the rescuer can obtain the available payment voucher to be signed.

[0040] In an optional embodiment of the present invention, before or after the second hardware payment device sends the rescue response information and the second signature data packet to the backend server, the method further includes: the second hardware payment device sends the rescue response information and the second signature data packet to the first hardware payment device; the first hardware payment device verifies the rescue response information using the second signature data packet, and saves the rescue response information after the verification is passed. In this optional embodiment, the second hardware payment device sends the rescue response information and the second signature data packet to the first hardware payment device, which facilitates the first hardware payment device to understand whether the rescue smart contract has received a response, thereby improving the rescue efficiency.

[0041] In an optional embodiment of the present invention, after the first hardware payment device saves the rescue response information, the method further includes: the first hardware payment device sends a rescue response confirmation message to the bank server, wherein the rescue response confirmation message includes at least a rescue smart contract, rescue response information, and a second signature data packet. In this optional embodiment, the first hardware payment device sends the rescue response confirmation message to the bank server, and the rescuer confirms the rescue behavior of the rescuer, which facilitates the bank server to complete subsequent operations.

[0042] In an optional embodiment of the present invention, after the first hardware payment device saves the rescue response information, the method further includes: the first hardware payment device sends a confirmation response message to the second hardware payment device. In this optional embodiment, the first hardware payment device sends a confirmation response message to the second hardware payment device, indicating that the rescuer has received the relevant information sent by the rescuer and is waiting for rescue, thereby improving the rescue experience.

[0043] In an alternative embodiment of the present invention, the background server sending the acceptance information and the third signed data packet to the bank server includes: the background server directly sending the acceptance information and the third signed data packet to the bank server; or, the background server sending the acceptance information and the third signed data packet to the second payment device, and the second payment device sending the acceptance information and the third signed data packet to the bank server.

[0044] In an alternative embodiment of the present invention, the triggering of the distress event includes at least one of the following: detecting that a preset key or key combination is pressed; or, receiving a preset voice command; or, detecting that a preset physical sign value of the holder of the first hardware payment device reaches a preset threshold.

[0045] In an alternative embodiment of the present invention, the distress information includes at least the following information: personal information of the holder of the first hardware payment device, geographical location, rescue content, amount of the payment voucher to be signed, and digital certificate of the first hardware payment device. In this alternative embodiment, when the distress information contains the above content, it is convenient for the rescuer to comprehensively understand the information of the person in distress, judge whether rescue can be carried out, and improve the rescue efficiency.

[0046] Through the method of using a hardware payment device for emergency rescue in this embodiment, the person in distress can conveniently and quickly send distress information and rescue rewards through the hardware payment device, simplifying the processes of distress and rescue, and facilitating the person in distress to obtain rescue quickly.

[0047] Embodiment 2

[0048] This embodiment further provides a system 200 for using a hardware payment device for emergency rescue, as Figure 2 shown. This system is used to execute the method in Embodiment 1. The related operations of this system and each device in Embodiment 1 are in one-to-one correspondence. The same parts will not be described in detail here and will only be briefly described. In an alternative embodiment of this embodiment, the specific operations executed by each device in the emergency rescue system 200 can refer to Embodiment 1.

[0049] As shown in FIG. 2, this system 200 includes a first hardware payment device 201, a second hardware payment device 202, and a background server 203; wherein,

[0050] The first hardware payment device 201 is used to detect whether a distress event is triggered; when detecting that a distress event is triggered, it determines the emergency situation corresponding to the distress event according to a preset rule, generates a distress smart contract and a first signature data packet obtained by signing the distress smart contract, wherein the distress smart contract includes a distress message and a payment voucher to be signed, and the payment voucher to be signed contains an unavailable identifier, and the unavailable identifier makes the payment voucher to be signed in an unavailable state; and sends the distress smart contract and the first signature data packet outward by broadcasting.

[0051] The second hardware payment device 202 is used to receive the distress smart contract and the first signature data packet, verify the signature of the distress smart contract by using the first signature data packet, and display the distress smart contract after the signature verification passes; detect whether a confirmation assistance button is triggered, and when detecting that the confirmation assistance button is triggered, store the distress smart contract; generate a rescue response message, sign the rescue response message to obtain a second signature data packet, and send the rescue response message and the second signature data packet to the background server 203, wherein the rescue response message includes a distress message and a rescuer information, and the rescuer information includes the ID information of the holder of the second hardware payment device.

[0052] The background server 203 is used to, after receiving the rescue response message and the second signature data packet, verify the signature of the rescue response message by using the second signature data packet, obtain the rescue response message after the signature verification passes, obtain acceptance information according to the rescue response message, sign the acceptance information to generate a third signature data packet, and send the acceptance information and the third signature data packet outward to the bank server, wherein the acceptance information includes the rescue response message and an acceptance situation record, and the acceptance situation record is obtained according to the distress message and the rescuer information.

[0053] The second hardware payment device 202 is further used to receive a release instruction corresponding to the payment voucher to be signed sent by the bank server, and release the unavailable identifier of the payment voucher to be signed by using the release instruction to obtain an available payment voucher to be signed, wherein the release instruction is generated by the bank server according to the acceptance information after receiving the acceptance information and the third signature data packet and passing the verification of the third signature data packet.

[0054] In an alternative implementation manner of this embodiment, before or after the second hardware payment device 202 sends the rescue response message and the second signature data packet to the background server 203: the second hardware payment device 202 is further used to send the rescue response message and the second signature data packet to the first hardware payment device 201; the first hardware payment device 201 is further used to verify the signature of the rescue response message by using the second signature data packet, and save the rescue response message after the signature verification passes.

[0055] In an alternative implementation of this embodiment, after the first hardware payment device 201 saves the rescue response information: the first hardware payment device 201 is further configured to send a rescue response confirmation message to the bank server, where the rescue response confirmation message at least includes a rescue smart contract, a rescue response information, and a second signature data packet.

[0056] In an alternative implementation of this embodiment, the background server 203 is configured to send the acceptance information and the third signature data packet to the bank server, including: the background server 203 is further configured to directly send the acceptance information and the third signature data packet to the bank server; or the background server 203 is further configured to send the acceptance information and the third signature data packet to the second payment device 202, and the second payment device 202 is further configured to send the acceptance information and the third signature data packet to the bank server 203.

[0057] In an alternative implementation of this embodiment, the distress information at least includes the following information: personal information of the holder of the first hardware payment device, the geographical location, the rescue content, the amount of the payment voucher to be signed, and the digital certificate of the first hardware payment device.

[0058] Through the system for emergency rescue using a hardware payment device in this embodiment, the rescuer can conveniently and quickly send distress information and rescue rewards through the hardware payment device, simplifying the distress and rescue processes and facilitating the rescuer to obtain rescue quickly.

[0059] Any process or method description in a flowchart or otherwise described herein can be understood to represent a module, segment, or portion of code including one or more executable instructions for implementing a specific logical function or process. The scope of the preferred embodiments of the present invention includes additional implementations, where functions may be executed in a substantially simultaneous manner or in a reverse order according to the involved functions, rather than in the order shown or discussed, which should be understood by those skilled in the technical field to which the embodiments of the present invention belong.

[0060] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, any one or a combination of the following well-known technologies in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0061] Those of ordinary skill in the art can understand that all or part of the steps carried out in implementing the method of the above embodiments can be completed by a program instructing related hardware. The said program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiments.

[0062] In addition, in each of the embodiments of the present invention, the functional units can be integrated into a processing module, or each unit can exist physically alone, or two or more units can be integrated into one module. The above integrated module can be implemented in the form of hardware or in the form of a software functional module. When the above integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0063] The above-mentioned storage medium can be a read-only memory, a magnetic disk, an optical disc, etc.

[0064] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc. means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples.

[0065] Although the embodiments of the present invention have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for making an emergency call using a hardware payment device, characterized in that, include: The first hardware payment device detects whether a distress event is triggered; When it is detected that the distress event is triggered, the first hardware payment device determines the emergency situation corresponding to the distress event according to a preset rule, generates a distress smart contract and a first signed data packet obtained by signing the distress smart contract according to the emergency situation, wherein the distress smart contract includes distress information and a payment voucher to be signed, and the payment voucher to be signed includes an unavailable flag, and the unavailable flag makes the payment voucher to be signed in an unavailable state; The first hardware payment device sends the help-seeking smart contract and the first signed data packet to the outside by broadcasting; The second hardware payment device receives the emergency smart contract and the first signature data packet, verifies the emergency smart contract using the first signature data packet, and displays the emergency smart contract after the verification passes; The second hardware payment device detects whether a rescue confirmation button is triggered. When the rescue confirmation button is detected to be triggered, the second hardware payment device stores the rescue smart contract; The second hardware payment device generates rescue response information, signs the rescue response information to obtain a second signature data packet, and sends the rescue response information and the second signature data packet to the backend server, wherein the rescue response information includes the distress message and rescuer information, and the rescuer information includes the ID information of the holder of the second hardware payment device; After receiving the rescue response information and the second signature data packet, the backend server uses the second signature data packet to verify the rescue response information, obtains the rescue response information after the verification, obtains acceptance information according to the rescue response information, signs the acceptance information to generate a third signature data packet, and sends the acceptance information and the third signature data packet to the bank server, wherein the acceptance information includes the rescue response information and an acceptance status record, and the acceptance status record is obtained according to the rescue information and the rescuer information; The second hardware payment device receives a ban release instruction corresponding to the payment voucher to be signed sent by the bank server, and uses the ban release instruction to remove the unavailable mark of the payment voucher to be signed to obtain an available payment voucher to be signed, wherein the ban release instruction is generated by the bank server according to the acceptance information after receiving the acceptance information and the third signature data packet and verifying the third signature data packet.

2. The method according to claim 1, characterized in that Before or after the second hardware payment device sends the rescue response information and the second signature data packet to the backend server, the method further includes: The second hardware payment device sends the rescue response information and the second signature data packet to the first hardware payment device; The first hardware payment device verifies the rescue response information using the second signature data packet, and saves the rescue response information after the verification is passed.

3. The method according to claim 2, characterized in that, After the first hardware payment device saves the rescue response information, the method further includes: The first hardware payment device sends a distress response confirmation message to the bank server, where the distress response confirmation message at least includes the distress smart contract, the rescue response message, and the second signature data packet.

4. The method according to claim 1, wherein The back-end server sending the acceptance information and the third signature data packet to the bank server includes: The back-end server directly sends the acceptance information and the third signature data packet to the bank server; or The back-end server sends the acceptance information and the third signature data packet to the second hardware payment device, and the second hardware payment device sends the acceptance information and the third signature data packet to the bank server.

5. The method according to claim 1, characterized in that, The distress message at least includes the following information: Personal information of the holder of the first hardware payment device, the geographical location, the rescue content, the amount of the payment voucher to be signed, and the digital certificate of the first hardware payment device.

6. A system for emergency rescue using a hardware payment device, characterized in that, It includes a first hardware payment device, a second hardware payment device, and a back-end server; where The first hardware payment device is used to detect whether a distress event is triggered; when it detects that a distress event is triggered, it judges the emergency corresponding to the distress event according to a preset rule, generates a distress smart contract according to the emergency, and obtains a first signature data packet by signing the distress smart contract, where the distress smart contract includes a distress message and a payment voucher to be signed, and the payment voucher to be signed contains an unavailable identifier, and the unavailable identifier makes the payment voucher to be signed in an unavailable state; the distress smart contract and the first signature data packet are sent out by broadcasting; The second hardware payment device is used to receive the distress smart contract and the first signature data packet, verify the signature of the distress smart contract using the first signature data packet, and display the distress smart contract after the signature verification passes; detect whether a confirmation rescue button is triggered, and when it detects that the confirmation rescue button is triggered, store the distress smart contract; generate a rescue response message, sign the rescue response message to obtain a second signature data packet, and send the rescue response message and the second signature data packet to the back-end server, where the rescue response message includes the distress message and the rescuer information, and the rescuer information includes the ID information of the holder of the second hardware payment device; The back-end server is used to, after receiving the rescue response message and the second signature data packet, verify the signature of the rescue response message using the second signature data packet, obtain the rescue response message after the signature verification passes, obtain acceptance information according to the rescue response message, sign the acceptance information to generate a third signature data packet, and send the acceptance information and the third signature data packet to the bank server, where the acceptance information includes the rescue response message and an acceptance situation record, and the acceptance situation record is obtained according to the distress message and the rescuer information; The second hardware payment device is also used to receive a ban release instruction corresponding to the payment voucher to be signed sent by the bank server, and use the ban release instruction to remove the unavailable mark of the payment voucher to be signed to obtain an available payment voucher to be signed, wherein the ban release instruction is generated by the bank server according to the acceptance information after receiving the acceptance information and the third signature data packet and verifying the third signature data packet.

7. The system according to claim 6, wherein The second hardware payment device, before or after sending the rescue response information and the second signature data packet to the backend server, further includes: The second hardware payment device is further used to send the rescue response information and the second signature data packet to the first hardware payment device; The first hardware payment device is further used to verify the rescue response information using the second signature data packet, and save the rescue response information after the verification is passed.

8. The system according to claim 7, characterized in that After the first hardware payment device is used to save the rescue response information, it also includes: The first hardware payment device is further used to send a rescue response confirmation message to the bank server, wherein the rescue response confirmation message at least includes the rescue smart contract, the rescue response information and the second signed data packet.

9. The system according to claim 6, wherein The backend server, for sending the acceptance information and the third signature data packet to the bank server, comprises: The backend server is used to send the acceptance information and the third signature data packet directly to the bank server; or The backend server is used to send the acceptance information and the third signature data packet to the second hardware payment device, and the second hardware payment device is also used to send the acceptance information and the third signature data packet to the bank server.

10. The system according to claim 6, characterized in that, The distress message includes at least the following information: The personal information, geographical location, rescue content, amount of the payment voucher to be signed and the digital certificate of the first hardware payment device holder.

Images