Communication method for rescue and related apparatus

Abstract

Provided are a communication method for rescue and a related device, the method comprising: a rescue terminal sending a request message to a server, the request message comprising a query condition required to be met by a person in distress for which a query is requested, the rescue terminal being a terminal of a first rescue team participating in rescue; and the server sending a response message to the rescue terminal, the response message comprising information of a person in distress meeting the query condition, that is, even if the server does not distribute information of a person in distress to the first rescue team, the first rescue team can request to query the information of the person in distress through the rescue terminal, which is conducive to improving the flexibility of communication in the rescue process.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to communication methods and related devices for rescue operations. Background Technology

[0002] In real life, communication between devices becomes increasingly difficult without a network. For example, during large-scale disasters (such as floods, earthquakes, and fires), terminals within the affected area may be without a network, in which case satellite communication plays a crucial role.

[0003] Currently, rescue organizations' servers can receive distress messages from individuals via satellite. Furthermore, based on the location of each rescue team, the information is distributed to those teams, enabling them to conduct rescue operations. However, throughout the entire rescue process, rescue teams can only passively receive the assigned information from those seeking help, resulting in limited communication flexibility. Summary of the Invention

[0004] This application provides communication methods and related devices for rescue operations, with the aim of improving the flexibility of communication during rescue operations.

[0005] In a first aspect, this application provides a communication method for rescue operations. This method can be executed by a server, or by a component (such as a chip, chip system, etc.) configured in the server, or by a logic module or software capable of implementing all or part of the server's functions. This application does not limit the scope of this method.

[0006] For example, the method includes: receiving a request message from a rescue terminal, the request message including query conditions that the person in distress requests to meet, wherein the rescue terminal is the terminal of the first rescue team participating in the rescue; and sending a response message to the rescue terminal, the response message including information about the person in distress who meets the query conditions.

[0007] In the above technical solution, the server receives a request message from the rescue terminal. The request message includes the query conditions that the person in distress needs to meet. In response to the request, the server sends the information of the person in distress who meets the query conditions. In other words, the rescue terminal can actively request the server to query the information of the person in distress. That is to say, even if the server does not distribute the information of the person in distress to the first rescue team, the first rescue team can still request to query the information of the person in distress through the rescue terminal, which is conducive to improving the flexibility of communication during the rescue process.

[0008] On the other hand, the request message includes the query conditions that the person in distress must meet to be queried. Therefore, the rescue team can flexibly adjust the query conditions according to its needs, that is, flexibly adjust what conditions the information of the person in distress must meet to improve the flexibility of the rescue process. For example, the rescue team can request information of the person in distress who is close to its location or request information of the person who reported the distress message earlier.

[0009] On the other hand, in this application, the distress terminal can actively request information about the person in distress from the server. This makes it easier to involve the power of ordinary people in the actual rescue process. For example, ordinary people can also request information about the person in distress from the server through the terminal and then rescue them. In this way, not only can professional rescue teams participate in the rescue, but non-professional rescue teams composed of ordinary people can also participate in the rescue, greatly increasing the number of people involved in the rescue and thus helping to improve the efficiency of the rescue.

[0010] In conjunction with the first aspect, in some possible implementations of the first aspect, the above method further includes: receiving a distress message from a distress terminal, which is the terminal of the first person in distress, and the distress message includes information about the first person in distress; saving the information about the first person in distress and one or more of the following information: the reporting time of the distress message, the number of times the information about the first person in distress has been queried, or the rescue status of the first person in distress, including not being rescued or not being successfully rescued.

[0011] The first person to request help can be any one of them. The server can receive and save information from any person requesting help, so that it can be provided to the rescue terminal when needed.

[0012] The server can also save one or more of the following: the time the distress message was reported, the number of times the information of the first person in distress was queried, or the rescue status of the first person in distress.

[0013] The identifier for the first person to call for help can identify that person.

[0014] The reporting time of a distress message can be the time when the server receives the distress message, which can be used to determine the approximate time when the first person seeking help was injured. Alternatively, the reporting time can be the time when the distress terminal sends the distress message; this time can be included in the distress message. It's understood that the time difference between when the distress terminal sends the distress message and when the server receives it is small and can be ignored.

[0015] The rescue status of the first person in distress can be used to determine their current situation, such as whether they have not been rescued or have not been successfully rescued.

[0016] Optionally, the information of the first person to seek help may include the location of the first person to seek help and one or more of the following: the identification of the first person to seek help, the injured part of the first person to seek help, or the disaster category of the first person to seek help.

[0017] The identifier of the first person in distress can be their name, the identifier of the terminal they are using, etc., and this application does not limit this. It is understood that since it is not important who the first person in distress is, as long as it is known that there is someone in need of rescue at this location, the information of the first person in distress may not include their identifier.

[0018] In conjunction with the first aspect, in some possible implementations of the first aspect, the above method further includes: sending a first instruction message to the distress terminal, the first instruction message being used to indicate one or more of the following: whether the distress message has been queried, the location information of at least one rescue team participating in the rescue, the contact information of at least one rescue team, the location information of other distress personnel besides the first distress person, or the contact information of other distress personnel.

[0019] Sending the above information to the distress terminal can alleviate the anxiety of the person seeking help and help them save themselves. For example, the first person seeking help can contact the rescue team or other people seeking help.

[0020] In conjunction with the first aspect, in some possible implementations of the first aspect, the first person in distress meets the query conditions, and the method further includes: receiving a second instruction message from a rescue terminal, the second instruction message instructing the first person in distress to begin being rescued; and updating the rescue status of the first person in distress to be being rescued according to the second instruction message.

[0021] If the first person in distress meets the query criteria, that is, the server feeds back the information of the first person in distress to the rescue terminal, the server can receive a second instruction message from the rescue terminal to indicate whether the first person in distress has started to be rescued, so as to facilitate timely updates of their rescue status, and thus facilitate subsequent determination of the status of the first person in distress by the server or the rescue terminal.

[0022] In conjunction with the first aspect, in some possible implementations of the first aspect, the first person in distress meets the query conditions, and the above method further includes: receiving a third instruction message from the rescue terminal, the third instruction message indicating that the first person in distress has been successfully rescued; and updating the rescue status of the first person in distress to be successfully rescued according to the third instruction message.

[0023] The server can also receive a second indication message from the rescue terminal to indicate whether the first person in distress has been successfully rescued, thus facilitating timely updates to their rescue status.

[0024] In conjunction with the first aspect, in some possible implementations of the first aspect, receiving the request message from the rescue terminal includes: receiving the request message from the rescue terminal via satellite; sending a response message to the rescue terminal includes: sending a response message to the rescue terminal via satellite. That is, the rescue terminal and the server can communicate via satellite (such as the BeiDou satellite system).

[0025] Secondly, this application provides a communication method for rescue operations. This method can be executed by a rescue terminal, or by a component (such as a chip, chip system, etc.) configured in the rescue terminal, or by a logic module or software capable of implementing all or part of the functions of the rescue terminal. This application does not limit the scope of this method.

[0026] Among them, the rescue terminal is the terminal of the first rescue team participating in the rescue.

[0027] For example, the method includes: sending a request message to a server, the request message including query conditions that the person in distress requests to be queried must meet; and receiving a response message from the server, the response message including information about the person in distress who meets the query conditions.

[0028] In the above technical solution, the rescue terminal can actively request the server to query the information of the person in distress. That is to say, even if the server does not distribute the information of the person in distress to the first rescue team, the first rescue team can still request the information of the person in distress through the rescue terminal, which helps to improve the flexibility of communication during the rescue process.

[0029] On the other hand, the request message includes the query conditions that the person in distress must meet to be retrieved. Therefore, the rescue team can flexibly adjust the query conditions according to its needs, that is, flexibly adjust what conditions the person in distress must meet to retrieve information, which helps to improve the flexibility of the rescue process. For example, the rescue team can request information from people in distress who are relatively close to its location or from people who reported their distress messages earlier.

[0030] On the other hand, in this application, the distress terminal can actively request information about the person in distress from the server. This makes it easier to involve the power of ordinary people in the actual rescue process. For example, ordinary people can also request information about the person in distress from the server through the terminal and then rescue them. In this way, not only can professional rescue teams participate in the rescue, but non-professional rescue teams composed of ordinary people can also participate in the rescue, greatly increasing the number of people involved in the rescue and thus helping to improve the efficiency of the rescue.

[0031] In conjunction with the second aspect, in some possible implementations of the second aspect, the distressed persons who meet the query conditions include the first distressed person, and the above method further includes: sending a second instruction message to the server, the second instruction message instructing the first distressed person to begin rescue.

[0032] Assuming that the first person in distress is among those who meet the query criteria, the first rescue team begins to rescue the first person in distress. The first rescue team can then send a second instruction message to the server via the rescue terminal, indicating that the first person in distress has begun to be rescued, which facilitates the server updating the rescue status of the first person in distress.

[0033] In conjunction with the second aspect, in some possible implementations of the second aspect, the distressed persons who meet the query conditions include the first distressed person, and the above method also includes: sending a third instruction message to the server, the third instruction message indicating that the first distressed person has been successfully rescued.

[0034] Assuming that the first person in distress is among those who meet the query criteria, after the first rescue team successfully rescues the first person in distress, it can send a third indication message to the server through the rescue terminal, indicating that the first person in distress has been successfully rescued. This will facilitate the server in updating the rescue status of the first person in distress.

[0035] In conjunction with the second aspect, in some possible implementations of the second aspect, sending a request message to the server includes: sending the request message to the server via satellite; receiving a response message from the server includes: receiving a response message from the server via satellite.

[0036] In combination with the first and second aspects, in some possible implementations, the query conditions include the location range of the person requesting the query and / or the time range during which the person requesting the query reported the distress message.

[0037] In other words, the request message can include the location range of people in distress that you are requesting to query, and / or the time range of people in distress that you are requesting to query. This allows the rescue team to adjust flexibly according to its needs. For example, the location range of rescue teams in different locations may be different, and the rescue team can request to query people in distress near its own location.

[0038] In conjunction with the first and second aspects, in some possible implementations, the aforementioned first rescue team is any one of at least one rescue team participating in the rescue, and the aforementioned response message also includes the location information and / or contact information of other rescue teams besides the first rescue team among the at least one rescue team.

[0039] By providing the location information and / or contact details of other rescue teams to the rescue terminal, the first rescue team can coordinate with other rescue teams based on their location information and / or contact details, thereby improving rescue efficiency and saving more lives. For example, the first rescue team can use the location information of other rescue teams to determine which rescue teams are closer and then coordinate with them. Alternatively, the first rescue team can directly contact other rescue teams using their contact information to request their assistance. Through coordinated rescue efforts, rescue efficiency can be greatly improved.

[0040] In conjunction with the first and second aspects, in some possible implementations, the above request message may also include a type identifier for the first rescue team, which identifies the type of the first rescue team as either a professional rescue team or a non-professional rescue team.

[0041] Professional rescue teams are composed of professional rescuers (or career rescuers); in other words, all rescuers in professional rescue teams are professionals in their field. Non-professional rescue teams, for example, can be composed of ordinary citizens. This application does not limit the number of members in either professional or non-professional rescue teams. For example, a non-professional rescue team can include only one ordinary citizen.

[0042] It can be seen that by requesting and querying information about people in distress through the rescue terminal, not only professional rescue teams can carry out rescue operations, but non-professional rescue teams (such as ordinary people) can also query information about people in distress through the terminal and then provide rescue, which greatly expands the composition of the rescue team, increases the number of rescuers, and thus helps to improve rescue efficiency.

[0043] Combining the first and second aspects, in some possible implementations, the rescue terminal is a terminal located within the disaster area.

[0044] Limiting rescue terminals to those within the disaster-stricken area can significantly reduce server load. Imagine if all terminals could request information about those seeking help; the number of requests the server would receive would increase dramatically, putting immense pressure on it. Therefore, allowing the server to accept requests only from terminals within the disaster-stricken area helps reduce server stress.

[0045] Combining the first and second aspects, in some possible implementations, each person in distress who meets the query conditions is assigned a priority, and the priority of each person in distress is determined based on the time when each person in distress reported the distress message.

[0046] Each person in distress who meets the search criteria has a priority level, which allows the rescue team to prioritize and rescue them accordingly. For example, the longer a person reports their distress message, the higher their priority level. The rescue team can prioritize rescuing people with higher priority levels, which helps to avoid people waiting for rescue for too long or being unable to receive timely treatment, thus helping to save more lives.

[0047] Thirdly, this application provides a communication method for rescue, which can be executed by a distress terminal, or by a component (such as a chip, chip system, etc.) configured in the distress terminal, or by a logic module or software capable of implementing all or part of the functions of the distress terminal. This application does not limit the scope of the method.

[0048] Among them, the distress terminal is the terminal of the person seeking help.

[0049] For example, the method includes: sending a distress message to a server, the distress message including information of the person in distress; receiving a first instruction message from the server, the first instruction message indicating one or more of the following: whether the distress message has been queried, the location information of at least one rescue team involved in the rescue, the contact information of at least one rescue team, the location information of other persons in distress besides the aforementioned person in distress, or the contact information of other persons in distress.

[0050] In the above technical solution, the person in distress can report a distress message to the server through a distress terminal to request rescue. The distress terminal can also receive a first instruction message to obtain one or more of the following information: whether the distress message has been queried, the location information of at least one rescue team involved in the rescue, the contact information of at least one rescue team, the location information of other people in distress besides the person in distress, or the contact information of other people in distress. By obtaining the above information, the person in distress can alleviate their anxiety and is more likely to take self-rescue measures. For example, the person in distress can contact the rescue team or other people in distress.

[0051] Optionally, the information of the person seeking help may include the location of the person seeking help and one or more of the following: the identification of the person seeking help, the injured part of the person seeking help, or the disaster category of the person seeking help.

[0052] Fourthly, this application provides another communication method for rescue operations. This method can be executed by a server, or by a component (such as a chip, chip system, etc.) configured in the server, or by a logic module or software capable of implementing all or part of the server's functions. This application does not limit this method.

[0053] For example, the method includes: receiving a distress message from a distress terminal, the distress terminal being the terminal of a person in distress, the distress message including information about the person in distress; sending a fourth instruction message to a rescue terminal, the rescue terminal being the terminal of a first rescue team, the first rescue team being any one of at least one rescue team participating in the rescue, the fourth instruction message being used to indicate the information of the person in distress and the location information and / or contact information of other rescue teams besides the first rescue team.

[0054] In the above technical solution, the server can not only send information about the person in distress to the rescue terminal, but also send the location information and / or contact details of other rescue teams besides the primary rescue team. This helps the primary rescue team to coordinate with other rescue teams based on their location information and / or contact details, thereby improving rescue efficiency and saving more lives. For example, the primary rescue team can use the location information of other rescue teams to determine which rescue teams are closer and then coordinate their rescue efforts. Alternatively, the primary rescue team can directly contact other rescue teams using their contact information to request their assistance. Through coordinated rescue efforts, rescue efficiency can be greatly improved.

[0055] In conjunction with the fourth aspect, in some possible implementations of the fourth aspect, the above method further includes: sending a first instruction message to the distress terminal, the first instruction message including one or more of the following: whether the distress message has been distributed to a rescue team, the location information of at least one rescue team participating in the rescue, the contact information of at least one rescue team, the location information of other distress personnel besides the aforementioned distress personnel, or the contact information of other distress personnel.

[0056] Sending the above information to the distress terminal can alleviate the distressed person's anxiety and help them to save themselves. For example, the distressed person can contact the rescue team or other distressed persons.

[0057] Fifthly, this application provides another communication method for rescue, which can be executed by a distress terminal, or by a component (such as a chip, chip system, etc.) configured in the distress terminal, or by a logic module or software capable of implementing all or part of the functions of the distress terminal. This application does not limit this.

[0058] Among them, the distress terminal is the terminal of any person in distress.

[0059] For example, the method includes: sending a distress message to a server, the distress message including information of the person in distress; receiving a first indication message from the server, the first indication message indicating one or more of the following: whether the distress message has been distributed to a rescue team, the location information of at least one rescue team involved in the rescue, the contact information of at least one rescue team, the location information of other persons in distress besides the aforementioned person in distress, or the contact information of other persons in distress.

[0060] In the above technical solution, the person in distress can report a distress message to the server through a distress terminal to request rescue. The distress terminal can also receive a first instruction message to obtain one or more of the following information: whether the distress message has been distributed, the location information of at least one rescue team involved in the rescue, the contact information of at least one rescue team, the location information of other people in distress besides the person in distress, or the contact information of other people in distress. By obtaining the above information, the person in distress can alleviate their anxiety and is more likely to take self-rescue measures. For example, the person in distress can contact the rescue team or other people in distress.

[0061] Sixthly, this application provides a communication method for rescue operations. This method can be executed by a rescue terminal, or by a component (such as a chip, chip system, etc.) configured in the rescue terminal, or by a logic module or software capable of implementing all or part of the functions of the rescue terminal. This application does not limit the scope of this method.

[0062] Among them, the rescue terminal is the terminal of the first rescue team participating in the rescue, and the first rescue team is any one of at least one rescue team participating in the rescue.

[0063] For example, the method includes: receiving a fourth instruction message from a server, the fourth instruction message being used to indicate information about the person in distress and the location information and / or contact information of other rescue teams besides the first rescue team; and displaying the information about the person in distress and the location information and / or contact information of other rescue teams besides the first rescue team.

[0064] In the aforementioned technical solution, the instruction message sent by the server to the rescue terminal includes not only the information of the person in distress assigned to it, but also the location information and / or contact details of other rescue teams. This facilitates the first rescue team in coordinating with other rescue teams based on their location information and / or contact details, thereby improving rescue efficiency and saving more lives. For example, the first rescue team can use the location information of other rescue teams to determine which teams are closer and then coordinate their rescue efforts. Alternatively, the first rescue team can directly contact other rescue teams using their contact information to request their assistance. Through coordinated rescue efforts, rescue efficiency can be significantly improved.

[0065] In a seventh aspect, this application provides a communication apparatus capable of implementing the communication methods for rescue described in the first to sixth aspects and any possible implementations of the first to sixth aspects. The apparatus includes corresponding units for performing the described methods. The units included in the apparatus can be implemented in software and / or hardware.

[0066] Eighthly, this application provides a communication device including a processor for executing the communication method for rescue described in the first to sixth aspects and any possible implementation thereof.

[0067] Optionally, the apparatus may further include a memory for storing instructions and data. The memory is coupled to the processor, which, when executing the instructions stored in the memory, can implement the methods described in the foregoing aspects.

[0068] Optionally, the device may further include a communication interface for communicating with other devices. For example, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

[0069] Ninthly, this application provides a chip system including at least one processor for supporting the implementation of the functions involved in the first to sixth aspects and any possible implementation of the first to sixth aspects, such as receiving or processing data and / or information involved in the above methods.

[0070] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0071] The chip system can consist of chips or include chips and other discrete components.

[0072] In a tenth aspect, this application provides a computer-readable storage medium including a computer program that, when run on a computer, causes the computer to implement the methods described in the first to sixth aspects and any possible implementation of the first to sixth aspects.

[0073] In the eleventh aspect, this application provides a computer program product comprising: a computer program (also referred to as code or instructions) that, when the computer program is run, causes a computer to perform the methods described in the first to sixth aspects and any possible implementation thereof.

[0074] In a twelfth aspect, this application provides a communication system for rescue operations, including a rescue terminal and a server. The server is configured to implement the communication method for rescue operations described in the first aspect and any possible implementation thereof, or to implement the communication method for rescue operations described in the fourth aspect and any possible implementation thereof; the rescue terminal is configured to implement the communication method for rescue operations described in the second aspect and any possible implementation thereof, or to implement the communication method for rescue operations described in the sixth aspect and any possible implementation thereof.

[0075] Optionally, the communication system further includes a distress terminal, which is used to implement the communication method for rescue as described in the third aspect and any possible implementation of the third aspect, or to implement the communication method for rescue as described in the fifth aspect and any possible implementation of the fifth aspect.

[0076] It should be understood that aspects seven to twelfth of this application correspond to the technical solutions of aspects one to six of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0077] Figure 1 This is a schematic diagram of the hardware structure of the terminal provided in the embodiments of this application;

[0078] Figure 2 This is a structural block diagram of the software and hardware of the terminal provided in the embodiments of this application;

[0079] Figure 3 This is a schematic diagram of the architecture of a communication system applicable to the methods provided in the embodiments of this application;

[0080] Figure 4 This is a schematic diagram of the interaction process between various devices in the communication system provided in the embodiments of this application;

[0081] Figure 5 This is a schematic flowchart of a communication method for rescue provided in an embodiment of this application;

[0082] Figure 6 This is a schematic flowchart of another communication method for rescue provided in the embodiments of this application. Detailed Implementation

[0083] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0084] To facilitate understanding of the embodiments of this application, the following description is provided first:

[0085] First, in this application, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. For example, the first instruction message and the second instruction message are only used to distinguish different instruction messages and do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0086] Second, in this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates an "or" relationship between the preceding and following related objects, but it does not exclude the possibility of indicating an "and" relationship; the specific meaning can be understood in context. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c; a and b; a and c; b and c; or a and b and c. Here, a, b, and c can be single or multiple.

[0087] Third, in this application, "when," "if," and "if" all refer to the device making a corresponding action under certain objective circumstances, and are not time-limited, nor do they require the device to make a judgment when it is implemented, nor do they imply any other limitations.

[0088] Fourth, in this application, "send" and "receive" indicate the direction of signal transmission.

[0089] For example, "the rescue terminal sends a request message to the server" can be understood as the destination of the request message being the server and the source being the rescue terminal. In this application, the rescue terminal sending a request message to the server includes the rescue terminal sending a request message to the server via satellite. Specifically, the rescue terminal sends a request message to the satellite, the satellite sends the request message to the ground station, and the ground station sends the request message to the server.

[0090] For example, "the rescue terminal receives a response message from the server" can be understood as the source of the response message being the server and the destination being the rescue terminal. The rescue terminal receiving the response message from the server includes the rescue terminal receiving the response message from the server via satellite. Specifically, the server sends the response message to the ground station, the ground station sends the response message to the satellite, and the satellite sends the response message to the rescue terminal.

[0091] It is understandable that a message may undergo necessary processing, such as encoding and modulation, before being sent from the source to the destination. Similarly, the destination, upon receiving a message from the source, may also perform corresponding processing, such as decoding and demodulation, to interpret the valid information from the source. Similar expressions in this application can be understood in a similar way and will not be elaborated further.

[0092] Furthermore, this application does not limit the type of satellite. For example, the satellite can be a BeiDou satellite.

[0093] Fifth, the tables in the embodiments of this application are merely examples. The values ​​of the information in each table are only examples and can be configured to other values; this application is not limited thereto. The tables do not limit the scope of protection of this application. For example, appropriate modifications and adjustments can be made based on the tables described above, such as splitting, merging, etc. Furthermore, the parameter names shown in the headings of each table can also use other names understandable to the communication device, and the values ​​or representations of the parameters can also be other values ​​or representations understandable to the communication device. Moreover, in the implementation of the above tables, other data structures can also be used, such as arrays, queues, containers, stacks, linear lists, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables, or hash tables, etc.

[0094] Sixth, the term "storage" in this application may refer to storage in one or more storage devices.

[0095] For example, in this application, the server may store the information of the person in distress included in the distress message and one or more of the following: the reporting time of the distress message, the number of times the information of the person in distress has been queried, or the rescue status of the person in distress, wherein the rescue status indicates that the person has not been rescued or has not been successfully rescued.

[0096] The aforementioned one or more memories can be separate installations or integrated into the encoder, decoder, processor, or device. Alternatively, some memories can be separate installations, while others can be integrated into the decoder, processor, or device. The type of memory can be any form of storage medium, and this application is not limited to this.

[0097] Seventh, in this application, all user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0098] Eighth, in this application, the terms "rescue terminal" and "rescue terminal" are merely names used to distinguish between the terminal of the person in distress and the terminal of the rescuer, and may be other names. Furthermore, "rescue terminal" and "rescue terminal" can be any type of terminal; they can be the same type or different types of terminals. This application does not impose any limitations in this regard. For example, both "rescue terminal" and "rescue terminal" can be mobile phones.

[0099] The terminal may also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal equipment, wireless communication equipment, user agent, or user device, etc., and the embodiments of this application do not limit it in this way.

[0100] In this application embodiment, the types of terminals include, but are not limited to: mobile phones, tablets, computers with wireless transceiver capabilities (such as laptops, PDAs, etc.), mobile internet devices (MIDs), virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical care, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, and 5G (5th generation) wireless communication devices. Terminals in 5G networks or future public land mobile networks (PLMNs), laptop computers, machine-type communication (MTC) terminals, etc.

[0101] Furthermore, a terminal can also be a terminal in an Internet of Things (IoT) system. IoT is an important component of future information technology development. Its main technical characteristic is connecting objects to networks via communication technologies, thereby realizing an intelligent network that enables human-machine interaction and machine-to-machine interaction. IoT technology can achieve massive connectivity, deep coverage, and low terminal power consumption through technologies such as narrowband (NB).

[0102] Figure 1 This is a schematic diagram of the hardware structure of the terminal 100 provided in the embodiments of this application. The following will be combined with... Figure 1 Describe in detail the possible hardware structure of the terminal.

[0103] The terminal 100 includes a processor 101, a transceiver 102, a memory 103, an antenna 104, a power supply 105, an input unit 106, a display unit 107, an audio circuit 108, a camera 109, a sensor 110, and a wireless fidelity (Wi-Fi) module 111, etc. The audio circuit 108 may include a speaker 108a, a microphone 108b, etc.

[0104] The processor 101 may include one or more processing units, such as an application processor (AP), a microcontroller unit (MCU), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0105] The memory 103 can be used to store computer executable program code, which includes instructions. The processor 101 executes various functional applications and data processing of the terminal 100 by running the instructions stored in the memory 103. The memory 103 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc. The data storage area may store data created during the use of the terminal 100 (such as audio data, phone book, etc.). In addition, the memory 103 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0106] The processor 101, transceiver 102 and memory 103 can communicate with each other through internal connection channels to transmit control and / or data signals. The processor 101 is used to call and run the computer program stored in the memory 103 to control the transceiver 102 to send and receive signals.

[0107] Antenna 104 is used to transmit the data or signaling output by transceiver 102. Power supply 105 is used to provide power to various devices or circuits in terminal 100.

[0108] The input unit 106 is used to receive content input by the user.

[0109] For example, in this application, when terminal 100 is a rescue terminal, input unit 106 can receive query conditions input by rescuers, thereby facilitating the generation of a request message by the rescue terminal, which carries the query conditions. When terminal 100 is a distress call terminal, input unit 106 can be used to receive information input by distress callers, such as the injured part of the body.

[0110] It should be understood that users can input via voice or manually. Therefore, the input unit 106 can be used to receive content input by the user's voice or content input manually by the user. This application does not limit this.

[0111] The display unit 107 can be used to display text, images, videos, etc.

[0112] In this application, when terminal 100 is a rescue terminal, display unit 107 can be used to display relevant information about the person in distress. For example, it can display the location distribution of the person in distress and the reporting time of the distress message in the form of a map, or it can display the location distribution of the person in distress and the reporting time of the distress message in the form of text. This application does not limit the display format. When terminal 100 is a distress terminal, display unit 107 can be used to display the location of the rescue team, contact information, and information about other people in distress.

[0113] It is understood that the structure illustrated in this application does not constitute a specific limitation on terminal 100. In other embodiments, terminal 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0114] Figure 2 This is a structural block diagram of the software and hardware of the terminal provided in the embodiments of this application. For example, Figure 2 For example, it could be a structural diagram of the software and hardware of a mobile phone.

[0115] like Figure 2 As shown, the layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0116] The application layer can include a series of application packages. For example... Figure 2 As shown, the application layer can include lock screen applications, desktop applications, etc. Desktop applications may further include, for example, calendar, maps, music, SMS, calls, gallery, smart home, etc.

[0117] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions. For example... Figure 2As shown, the application framework layer may include Input Manager Service (IMS), Display Policy Service, Power Manager Service (PMS), Display Manager Service (DMS), Activity Management Service, Resource Management Service, Content Service, View System, Telephone Management Service, Notification Management Service, Window Management Service, Process Management Service, Drawing Service, etc. Figure 2 (Only a portion of the services are shown in this application; this application does not limit the specific services included.)

[0118] The window management service manages window programs. The content service stores and retrieves data, making it accessible to applications. The telephone management service provides communication functionality, such as managing call status (connection, termination, etc.). The notification management service allows applications to display notifications in the status bar, conveying informative messages that disappear automatically after a short pause without user interaction. The drawing service draws the interface; for example, it converts application layouts and resources into a format recognizable by the kernel-level display service. The drawing service then sends the drawn interface to the kernel-level display service for display. For simplicity, the functions of each service are not listed here.

[0119] The Android runtime can include core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0120] The core library can consist of two parts: one part is the functionalities that the Java language needs to call, and the other part is the core library of the Android system.

[0121] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0122] The system library can include multiple functional modules. For example: status monitoring service, surface manager, media libraries, 3D graphics processing library (e.g., OpenGLES), 2D graphics engine (e.g., SGL), etc.

[0123] The kernel layer is the layer between hardware and software. The kernel layer includes at least power management services, sensor services (also known as sensor drivers), display services (also known as display drivers), camera drivers, and audio drivers. This application's embodiments do not impose any limitations on this.

[0124] Still Figure 2 As shown, the system libraries and kernel layer below the application framework layer can be referred to as the underlying system. The underlying system includes the underlying display system that provides display services; for example, the underlying display system includes the display driver in the kernel layer and the surface manager in the system library.

[0125] Below the underlying system is the hardware, which provides the foundation for software operation. For example... Figure 2 As shown, the hardware of this terminal may include, but is not limited to, a power button, sensors, a display screen, a fingerprint sensor, and a camera.

[0126] It should be understood that Figure 1 and Figure 2 The terminal structure shown is merely an example and should not be construed as limiting the embodiments of this application.

[0127] In real life, communication between devices becomes increasingly difficult without a network. For example, during large-scale disasters (such as floods, earthquakes, and fires), terminals within the affected area may be without a network, in which case satellite communication plays a crucial role.

[0128] Currently, rescue organizations' servers can receive distress messages carrying the information of those in need via satellite. Furthermore, based on the location of each rescue team, the information is distributed to those teams, enabling them to conduct rescue operations. Throughout the rescue process, rescue teams can only passively receive the information assigned to them, resulting in limited communication flexibility.

[0129] To address the aforementioned issues, this application provides a communication method for rescue operations. The rescue terminal can proactively request information about the person in distress from the server. In other words, even if the server does not distribute the information about the person in distress to the first rescue team, the first rescue team can still request and query the information about the person in distress through the rescue terminal, which helps to improve the flexibility of communication during the rescue process.

[0130] To facilitate understanding of the communication method for rescue provided in the embodiments of this application, the system architecture of the method provided in the embodiments of this application will be described below. It is understood that the system architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application and does not constitute a limitation on the technical solutions provided in the embodiments of this application.

[0131] Figure 3This is a schematic diagram of the architecture of a communication system applicable to the methods provided in the embodiments of this application.

[0132] like Figure 3 As shown, the communication system includes a rescue terminal and a server, which can communicate with each other via satellite (such as the BeiDou Navigation Satellite System). More specifically, the rescue terminal can send messages to the satellite, which then forwards the messages to a ground station, which in turn forwards them to the server. Conversely, the server can send messages to the ground station, which then forwards them to the satellite, which in turn forwards them to the rescue terminal. The satellite can amplify and frequency-convert the received signals before forwarding them, without requiring further signal processing. It is clear that in this application, the communication between the rescue terminal and the server is not point-to-point, but rather achieved via satellite.

[0133] Optionally, the communication system also includes a distress terminal, which can communicate with the server via satellite (such as the BeiDou satellite system). The communication process is similar to that between the rescue terminal and the server. Details will not be provided here.

[0134] Understandable. Figure 3 The communication system shown is merely an example and should not be construed as limiting the scope of the embodiments in this application. For example, Figure 3 The diagram only shows one rescue terminal and one distress signal terminal, but in practical applications, it can include many more rescue terminals and distress signal terminals. For example, Figure 3 Only one server is shown in the document, but in practical applications, it can be a single physical device or a server cluster composed of multiple physical devices. This application does not limit this.

[0135] Figure 4 This is a schematic diagram illustrating the interaction process between devices in a communication system provided in this application embodiment. The following will be combined with... Figure 4 The communication method for rescue provided in the embodiments of this application will be briefly described.

[0136] In step 401, N distress terminals send distress messages.

[0137] Where N is a positive integer. Each of the N distress terminals can send a distress message, which includes information about the person in distress. For example, a distress terminal can send a distress message to a satellite, which includes the information about the person in distress. Accordingly, the satellite receives the distress message from the distress terminal.

[0138] Optionally, the information of the person seeking help in the distress message may include the location of the person seeking help and one or more of the following: the identification of the person seeking help, the injured part of the person seeking help, or the disaster category of the person seeking help.

[0139] In step 402, the satellite sends a distress message to the server via the ground station.

[0140] For example, after receiving a distress message, the satellite sends it to a ground station, which then forwards it to a server. The server then receives the distress message. Furthermore, the server can also store it in its memory.

[0141] In step 403, the rescue terminal sends a request message.

[0142] The request message is used to request information about the person in distress.

[0143] For example, the rescue terminal sends a request message to a satellite, the satellite forwards the request message to a ground station, and the ground station forwards the request message to a server. The request message includes the query conditions that the person in distress must meet to be queried.

[0144] In step 404, the server returns information about the distressed individuals who meet the query criteria via satellite.

[0145] For example, the server sends information about people in distress who meet the query criteria to the ground station, the ground station sends the information to the satellite, and the satellite sends the information to the rescue terminal.

[0146] In step 405, the rescue terminal receives information returned by the server.

[0147] The rescue terminal receives information returned by the server via satellite; that is, the rescue terminal receives information from the server relayed by the satellite.

[0148] Figure 4 The interaction process between the rescue terminal, the distress terminal, and the server has only been briefly described. The following will describe the interaction process in detail with reference to the accompanying drawings. It should be understood that the embodiments shown below describe the method from the perspective of the interaction between the rescue terminal, the distress terminal, and the server, but should not constitute any limitation on the subject executing the method. The method provided in this application can be executed as long as a program containing the code of the method provided in the embodiments of this application is run. For example, the rescue terminal can be replaced with a component configured in the rescue terminal (e.g., a chip, a chip system, etc.), or other functional modules capable of calling and executing programs; the server can also be replaced with a component configured in the server (e.g., a chip, a chip system, etc.), or other functional modules capable of calling and executing programs; and the distress terminal can also be replaced with a component configured in the distress terminal (e.g., a chip, a chip system, etc.), or other functional modules capable of calling and executing programs. This application does not limit this aspect.

[0149] Figure 5This is a schematic flowchart of a communication method 500 for rescue provided in an embodiment of this application. The various steps in method 500 are described in detail below.

[0150] In step 510, the rescue terminal sends a request message to the server, which includes query conditions. Correspondingly, the server receives the request message from the rescue terminal.

[0151] The rescue terminal is the terminal of the first rescue team participating in the rescue. The first rescue team can be any one of at least one rescue team participating in the rescue. The above request message includes the query conditions that the person in distress must meet to be queried.

[0152] One possible implementation is that the rescue terminal sends a request message to the server via satellite. More specifically, the rescue terminal sends a request message to the satellite, the satellite forwards the request message to the ground station, and the ground station forwards the request message to the server.

[0153] Optionally, the above query conditions include the location range of the person requesting assistance and / or the time range of the time range during which the person requesting assistance reported the distress message.

[0154] One possible design is that the query conditions include the location range of the person in distress, i.e., the range of locations the first rescue team wants to query. The location can be represented by latitude and longitude. For example, the query conditions include longitude, latitude, and a radius r, where the location range is a circle with the location represented by the longitude and latitude as its center and r as its radius. For instance, longitude 108.2635, latitude 33.1632, and r = 3 kilometers indicate a query for people in distress within a 3-kilometer radius of the location (108.2635, 33.1632). The location with longitude 108.2635 and latitude 33.1632 could be the location of the rescue terminal, i.e., the location of the first rescue team.

[0155] Another possible design is that the query criteria include the time range within which the distress callers reported their distress messages; that is, the query requests information on the time range within which distress calls were reported. The time range could be two days, one day, half a day, etc. For example, the query criteria could include distress callers whose distress calls were reported within one day of the current time.

[0156] Another possible design is that the above query conditions include the location range of the person requesting help and the time range of the time the person requested help reported the distress message. For example, the query conditions are: people within 3 kilometers of the location (108.2635, 33.1632) who reported the distress message within one day from the current time.

[0157] It is understood that the above query conditions are merely examples and should not constitute any limitation on this application. In practical applications, query conditions can also be other conditions, such as the injured part being the leg, head, or arm. Another example is that the person seeking help is an elderly person, a child, or a young person. Furthermore, in addition to location and time ranges, query conditions can also include rescue status, such as requesting to query for people whose rescue status is "not yet rescued" or "not successfully rescued." These are just a few examples; further examples will not be listed here.

[0158] It's understandable that if the query criteria include requests for rescuers whose rescue status is "not rescued" or "not successfully rescued," then the server will not return information about rescuers who have been successfully rescued or are currently being rescued to the rescue terminal. If the query criteria do not include the rescue status of the requested rescuer, one possible design is that the server disregards the rescue status and only returns information to the rescue terminal if the rescuer meets other query criteria. Another possible design is that the server can preset a condition, such as requiring the information returned to the rescue terminal to be information about rescuers who meet the query criteria and whose rescue status is "not successfully rescued" or "not successfully rescued." In this case, the server will not return information about rescuers who have been successfully rescued or are currently being rescued to the rescue terminal.

[0159] Table 1 shows an example of the content included in a request message. As shown in Table 1, a request message includes: instructions (e.g., instruction 1 indicates that the message is a request message, instruction 2 indicates that the message is a report of rescue situation), longitude 108.2635, latitude 33.1632, radius 3 kilometers, and time range (e.g., one day).

[0160] Table 1

[0161] instruction longitude latitude radius Time range 1 108.2635 33.1632 3 kilometers 1 day

[0162] Optionally, the request message may also include a type identifier for the first rescue team. This type identifier identifies the type of the first rescue team, which may be a professional rescue team or a non-professional rescue team. A professional rescue team consists of professional rescue personnel (or, more accurately, skilled rescuers). A non-professional rescue team may, for example, be a team composed of ordinary citizens. Regardless of whether the team is professional or non-professional, this application does not limit the number of members. For example, a non-professional rescue team may consist of only one ordinary citizen.

[0163] In other words, the request message can also indicate whether the rescue terminal belongs to a professional rescue team or a rescue team spontaneously formed by ordinary citizens. This makes it easier for the server to determine the source of the request message. On the one hand, the server can determine the information carried in the response message based on the type of rescue team (for example, if it is a professional rescue team, the response message will carry more information). On the other hand, it can also distinguish what type of rescue team is providing treatment to the person in distress.

[0164] Optionally, the rescue terminal is a terminal located within the disaster area. To reduce the load on the server, the server can be configured to only accept request messages from terminals within the disaster area, and may not accept request messages from terminals located outside the disaster area.

[0165] In step 520, the server sends a response message to the rescue terminal, which includes information about the people in distress who meet the query criteria. The rescue terminal then receives the response message.

[0166] One possible implementation is that the server sends a response message to the ground station, the ground station sends the response message to the satellite, and the satellite sends the response message to the rescue terminal.

[0167] Information on people in distress that meets the query criteria may include one or more of the following: the location of the person in distress, the injured part of the body, the time the distress message was reported, the number of times the information of the person in distress has been queried, the rescue status of the person in distress (such as whether they are being rescued and / or whether the rescue was successful), and the type of disaster (such as earthquake, flood or mudslide).

[0168] For example, if person 1 in distress meets the query criteria, the response message will include person 1's location (e.g., longitude 109.2635, latitude 32.1632), the injured part of person 1 (e.g., leg), the time the distress message was reported (e.g., 3 PM on April 12, 2023), the number of times person 1's information has been queried (e.g., 0 times), and the rescue status of person 1 (e.g., not yet rescued). If the rescue status is "successfully rescued" or "being rescued," the first rescue team can ignore the information of that person in distress based on the rescue status and rescue other people in distress.

[0169] It is understood that the information of those seeking help that meets the query criteria described above is merely an example. In practical applications, the response message may include more or less information about those seeking help that meets the query criteria, and this application does not limit this. For example, the information of those seeking help that meets the query criteria may also include the priority of each person seeking help.

[0170] Each person in distress who meets the query criteria has a priority level, which can be determined based on the time when the distress message was submitted.

[0171] For example, each person in distress who meets the query criteria has a priority level. The earlier the distress message is reported, the higher the priority. The rescue team can then rescue the people in distress according to their priority. For instance, if the people in distress who meet the query criteria include: person 1, person 2, person 3, and person 4, with priorities of 1, 3, 4, and 2 respectively, then the rescue order could be: person 3, person 2, person 4, and person 1.

[0172] It should be noted that in this application, the priority can be determined by either the server or the rescue terminal. When the server determines the priority, the information of each person seeking help in the response message it sends can include the priority of that person. When the rescue terminal determines the priority, it can determine the priority of each person seeking help based on the time when they reported their distress message in the response message after receiving it.

[0173] Optionally, the response message may also include the location information and / or contact details of other rescue teams besides the first rescue team. In other words, for a particular rescue team A, the response message it receives may also include the location information and / or contact details of other rescue teams besides rescue team A (such as rescue team B).

[0174] Location information can be represented, for example, by latitude and longitude coordinates. Contact information can be, for example, a telephone number.

[0175] One possible design is that the response message also includes the location information of other rescue teams besides the first rescue team. For example, when rescue team A's rescue terminal receives the response message, in addition to including information about the people in distress who meet the query criteria, the response message may also include the location information of rescue team B, such as rescue team B, with longitude 109.2635 and latitude 34.1632.

[0176] Another possible design is that the response message also includes contact information for other rescue teams besides the first rescue team. For example, when rescue team A's terminal receives the response message, in addition to information about the person in distress who meets the query criteria, the message may also include contact information for rescue team B, such as the contact number "XXXX".

[0177] Another possible design is that the response message also includes the location information and contact details of other rescue teams besides the first rescue team. For example, when rescue team A's rescue terminal receives the response message, in addition to information about the person in distress who meets the query criteria, the message may also include the location information and contact details of rescue team B, such as rescue team B, longitude 109.2635, latitude 34.1632, and contact number "XXXX".

[0178] Optionally, method 500 may further include step 530: the distress terminal sends a distress message to the server, the distress message including information about the person in distress. Accordingly, the server receives the distress message.

[0179] Communication between the distress terminal and the server is achieved via satellite. For example, the distress terminal sends a distress message to the satellite, the satellite forwards the distress message to the ground station, and the ground station forwards the distress message to the server.

[0180] Optionally, the information reported by the distress terminal may include the distressed person's location and one or more of the following: injured body part, disaster type (such as earthquake, flood, or mudslide), or the distressed person's identification. It is understood that the above information is merely illustrative; in practical applications, distress messages may include more or less information about the distressed person, and this application does not limit this.

[0181] It is understandable that the location of a person seeking help can help rescue teams quickly locate them; therefore, the information about the person seeking help in a distress message can include their location. Information such as the injured area, the type of disaster (e.g., earthquake, flood, or mudslide), and the person's identification are optional. The identification can be the person's name, the identifier of the terminal used, etc., and this application does not limit this. It is also understandable that since the identity of the person seeking help is not important, as long as it is known that someone at this location needs rescue, the information about the person seeking help may not include their identification.

[0182] For example, distress terminal 1 sends a distress message to the server, wherein distress terminal 1 is the terminal of distress person 1, and the distress message includes the identifier of distress person 1, the location of distress person 1, the injured part (e.g., leg), the type of disaster (e.g., earthquake), etc. Disaster person 1 is an example of the first distress person.

[0183] It is easy to understand that after receiving information from each person seeking help, the server stores it. The stored information includes, but is not limited to, a sequence number (each person seeking help has a unique sequence number), the person's identifier, location, injured area, time the distress message was reported, number of queries to the person's information, rescue status (e.g., not rescued and / or unsuccessfully rescued), and disaster type (e.g., earthquake, flood, or mudslide). In practical applications, the server may store more or less information; this application does not limit this.

[0184] The number of queries for the information of the person in distress can be accumulated based on queries from different rescue teams. For example, taking person A in distress as an example, if rescue team A requests to query the information of person A in distress, and person A in distress meets the query conditions, then the query count is incremented by 1. If rescue team B then requests to query the information of person A in distress, and person A in distress also meets the query conditions of rescue team B, then the query count is incremented by 1 again.

[0185] Table 2 is an example of the content stored by the server for a specific person in distress according to an embodiment of this application. As shown in Table 2, the stored content includes: the identifier of the person in distress 1 (e.g., Zhang San), the disaster category (e.g., earthquake = 1, flood = 2 or mudslide = 3), longitude 108.2635, latitude 33.1632, injured part (e.g., leg), number of queries (e.g., 0), reporting time (e.g., 3 PM on February 14, 2023), whether they are being rescued (e.g., no), and whether they have been successfully rescued (e.g., no). It may also include a sequence number for sorting multiple people in distress.

[0186] Table 2

[0187]

[0188] Optionally, method 500 further includes step 540: the server sends a first instruction message to the distress terminal (such as the terminal of the first person in distress). Accordingly, the distress terminal receives the first instruction message. The first instruction message indicates one or more of the following: whether the distress message has been queried, the location information of at least one rescue team, the contact information of at least one rescue team, the location information of other persons in distress besides the first person in distress, or the contact information of other persons in distress.

[0189] The server can indicate to the distress terminal whether its distress message has been queried (i.e., whether its distress message has been noticed by rescue teams), the location information of the rescue teams (such as the location information of the rescue teams that have noticed its distress message and / or the location information of other rescue teams), and the contact information of the rescue teams (such as the contact phone numbers of the rescue teams that have noticed its distress message and / or the contact phone numbers of other rescue teams). The server can also indicate to the distress terminal the location information and / or the contact information of other people seeking help. It can be understood that indicating the above information to the distress terminal by the server helps to alleviate the anxiety of the people seeking help and helps them to take self-rescue measures (such as actively contacting rescue teams and other people seeking help).

[0190] Optionally, method 500 further includes step 550: the rescue terminal sends a second instruction message to the server. Correspondingly, the server receives the second instruction message from the rescue terminal. The second instruction message instructs the first person in distress to begin rescue.

[0191] Taking the first person in distress as an example, if the first person in distress meets the query criteria, the rescue terminal receives the information of the first person in distress from the server. If the first rescue team begins to rescue the first person in distress, the first rescue team can send a second instruction message to the server through the rescue terminal to start the rescue. This second instruction message includes, for example, the identifier of the first person in distress, and an identifier indicating that the first person in distress has begun to be rescued (e.g., 1 for starting rescue, 0 for not being rescued).

[0192] If the first person in distress begins to be rescued, the server can also update the rescue status of the first person in distress to "being rescued" based on the second instruction message.

[0193] Optionally, method 500 further includes step 560: the rescue terminal sends a third indication message to the server. Correspondingly, a third indication message is received from the rescue terminal. The third indication message indicates that the first person in distress has been successfully rescued.

[0194] Taking the first person in distress as an example, if the first person in distress meets the query criteria, the rescue terminal receives the information about that person from the server. If the first rescue team successfully rescues that person, the first rescue team can send a third indication message to the server through the rescue terminal to indicate that the rescue was successful. For example, in response to the first rescue team clicking "Report Rescue Status" and selecting "Rescued Successfully," the rescue terminal sends a third indication message to the server, indicating that the first person in distress has been successfully rescued. The third indication message may include the identifier of the first person in distress, as well as an indicator indicating that the first person in distress has been successfully rescued (e.g., 1 for successful rescue, 0 for unsuccessful rescue).

[0195] If the first person in distress is successfully rescued, the server can also update the rescue status of the first person in distress to "successfully rescued" based on the third instruction message.

[0196] Based on the above technical solution, the rescue terminal can proactively request information about people in distress from the server. This means that even if the server hasn't distributed information about people in distress to the first rescue team, the team can still request such information through the rescue terminal, improving communication flexibility during the rescue process. Furthermore, the request message includes the query conditions that the requested people in distress must meet. Therefore, the rescue team can flexibly adjust the query conditions according to needs, i.e., flexibly adjust what conditions must be met to query information about people in distress, further enhancing the flexibility of the rescue operation. For example, the rescue team can request information about people in distress who are relatively close to their location or those who reported their distress messages earlier. Moreover, the fact that the rescue terminal can proactively request information from the server facilitates the involvement of ordinary citizens during the rescue process. Ordinary citizens can also use the terminal to request information about people in distress from the server and then provide assistance. In this way, not only professional rescue teams can participate, but non-professional rescue teams composed of ordinary citizens can also participate, significantly increasing the number of participants and thus improving rescue efficiency.

[0197] This application also provides another communication method for rescue operations. The server can receive distress messages from individuals in distress and then send a fourth instruction message to the rescue terminal, indicating the information of the person in distress and the location and / or contact information of other rescue teams. This facilitates coordinated rescue efforts between teams. For example, a rescue team can contact other rescue teams using their contact information to coordinate the rescue.

[0198] Figure 6 This is a schematic flowchart of another communication method 600 for rescue provided in this application embodiment. The various steps in method 600 are described in detail below.

[0199] In step 610, the distress terminal sends a distress message to the server, which includes information about the person seeking help. Correspondingly, the server receives the distress message from the distress terminal.

[0200] The server and the distress signal terminal can communicate via satellite. For details, please refer to [link / document / reference needed]. Figure 5 Related descriptions.

[0201] The aforementioned distress terminal can be the terminal of any one of the multiple distress callers (such as the terminal of the first distress caller). It is understood that other distress callers can also send distress messages to the server through their distress terminals.

[0202] The information of the person seeking help in a distress message includes their location and one or more of the following: the location of their injury, the type of disaster (e.g., earthquake, flood, or mudslide), and identification of the person seeking help. It is understood that the above information is merely illustrative; in practical applications, distress messages may include more or less information about the person seeking help, and this application does not limit this. A more detailed description can be found in [link to relevant documentation]. Figure 5 .

[0203] After receiving distress messages from various distress terminals, the server can store them to facilitate the dispatch of appropriate rescue teams. The content stored by the server includes, but is not limited to: sequence number, identifier of the person in distress, location of the person in distress, injured body part, time of reporting the distress message, rescue status of the person in distress (e.g., not rescued or unsuccessful rescue), and disaster type (e.g., earthquake, flood, or mudslide). More details can be found in Table 2. It should be understood that the content stored by the server may include more or less information, and this application does not limit this.

[0204] In step 620, the server sends a fourth instruction message to the rescue terminal, which includes information about the person in distress and the location and / or contact information of other rescue teams. Accordingly, the rescue terminal receives the fourth instruction message.

[0205] The aforementioned rescue terminal can be the terminal of the first rescue team participating in the rescue, which is any one of at least one rescue team participating in the rescue. The fourth instruction message includes information about the person in distress assigned to the first rescue team, the location information and / or contact information of other rescue teams besides the first rescue team.

[0206] The server and the rescue terminal communicate via satellite. For a more detailed explanation of the interaction process, please refer to [link / reference needed]. Figure 5 Related descriptions.

[0207] For example, if the server stores information about persons seeking help 1, 2, 3, and 4, and the rescue teams involved in the rescue include Rescue Team 1 and Rescue Team 2, then the server can assign persons seeking help 1 through 4 to Rescue Team 1 and Rescue Team 2 for rescue. For instance, the server can assign based on the location of the rescue teams; if persons seeking help 1 and 2 are closer to Rescue Team 1, then persons seeking help 1 and 2 will be assigned to Rescue Team 1 for rescue.

[0208] The information about the person seeking help in the fourth instruction message includes, but is not limited to: the person's location, injured area, time the distress message was reported, rescue status (e.g., not yet rescued or rescue unsuccessful), type of disaster (e.g., earthquake, flood, or mudslide), and whether the distress message has been distributed. It is understood that the above information is merely illustrative; in practical applications, the information about the person seeking help in the fourth instruction message may include more or less content, and this application does not limit this.

[0209] The location and / or contact information of other rescue teams in the fourth directive message is helpful for coordinated rescue efforts between teams. For a more detailed description of the location and contact information of other rescue teams, please refer to [link to relevant documentation]. Figure 5 The relevant explanation.

[0210] Optionally, method 600 further includes step 630: the server sends a first instruction message to the distress terminal (such as the terminal of the first distressed person). Accordingly, the distress terminal receives the first instruction message. The first instruction message indicates one or more of the following: whether a distress message has been distributed, the location information of at least one rescue team participating in the rescue, the contact information of at least one rescue team participating in the rescue, the location information of other distressed persons besides the first distressed person, or the contact information of other distressed persons. A description of step 630 can be found in step 540, and will not be repeated here.

[0211] Optionally, method 600 further includes step 640: the rescue terminal sends a second instruction message to the server. Correspondingly, the server receives the second instruction message from the rescue terminal. The second instruction message instructs the first person in distress to begin rescue. A description of step 640 can be found in step 550, and will not be repeated here.

[0212] Optionally, method 600 further includes step 650: the rescue terminal sends a third indication message to the server. Correspondingly, a third indication message is received from the rescue terminal. The third indication message indicates that the first person in distress has been successfully rescued. A description of step 650 can be found in step 560, and will not be repeated here.

[0213] Based on the above technical solution, the server can not only send information about people in distress to the rescue terminal, but also send the location information and / or contact details of other rescue teams besides the primary rescue team. This helps the primary rescue team coordinate with other rescue teams based on their location information and / or contact details, thereby improving rescue efficiency and saving more lives. For example, the primary rescue team can use the location information of other rescue teams to determine which teams are closer and coordinate accordingly. Alternatively, the primary rescue team can directly contact other rescue teams using their contact information to request their assistance. Through coordinated rescue efforts, rescue efficiency can be greatly improved.

[0214] Optionally, in Figure 4 , Figure 5 and Figure 6 In the illustrated embodiment, after receiving one or more of the following information, the rescue terminal can display it through the user interface: information of the person in distress, location information of other rescue teams, and contact information.

[0215] For example, the rescue terminal can display the above information in the form of a map. For instance, the rescue terminal can display the location of each person in distress on the map, and above their location, it can also display the reporting time of their distress message, the injured part of their body, etc. As another example, the rescue terminal can display the location of other rescue teams on the map, and above their location, it can also display the contact information of those rescue teams.

[0216] It should be understood that the above display method is merely an example and should not constitute any limitation on the embodiments of this application. For example, in practical applications, it can also be displayed in the form of text (such as in a table).

[0217] Understandable. Figure 5 and Figure 6 The illustrated embodiments can be used in combination or separately. For example, during a rescue operation, the server can proactively distribute information about people in distress and the location and / or contact information of other rescue teams. The server can also respond to requests from rescue terminals and send information about people in distress who meet the query criteria to the rescue terminals. Additionally, Figure 5 The illustrated embodiments can also be used in conjunction with known technologies. For example, the server can proactively distribute information about people in distress, or the server can respond to requests from rescue terminals and send information about people in distress that meet the query criteria to the rescue terminals. This application does not limit this application.

[0218] This application also provides a communication device that can achieve... Figure 4 , Figure 5 or Figure 6The illustrated embodiment describes a method performed by a rescue terminal, server, or distress terminal. The apparatus includes corresponding units for performing the described method. These units can be implemented in software and / or hardware.

[0219] This application also provides a communication device, which includes a memory and a processor. The memory stores a computer program, and the processor calls and executes the computer program to enable the device to perform... Figure 4 , Figure 5 or Figure 6 The method executed by the rescue terminal, distress terminal, or server in the illustrated embodiment.

[0220] This application also provides a communication system for rescue operations, including the rescue terminal and server as described above.

[0221] Optionally, the communication system also includes a distress terminal.

[0222] This application also provides a chip system, the chip system including at least one processor for implementing the above. Figure 4 , Figure 5 or Figure 6 The functions involved in the methods described in the illustrated embodiments include, for example, receiving or processing the data and / or information involved in the above methods.

[0223] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0224] The chip system can consist of chips or include chips and other discrete components.

[0225] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions) that, when executed by a processor, causes the above... Figure 4 , Figure 5 or Figure 6 The method described in the illustrated embodiment is performed.

[0226] This application also provides a computer program product, the computer program product comprising: a computer program (also referred to as code or instructions), which, when executed, causes a computer to perform... Figure 4 , Figure 5 or Figure 6 The method described in the illustrated embodiment.

[0227] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuitry in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0228] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0229] The terms "unit," "module," etc., used in this specification can be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. In the embodiments of this application, "unit" and "module" have the same meaning and can be used interchangeably.

[0230] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interface; the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.

[0231] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. A computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs), or semiconductor media (e.g., solid-state drives, SSDs), etc.

[0232] If the functions provided in the embodiments of this application are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0233] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method for rescue operations, characterized in that, include: The system receives a request message from a rescue terminal. The request message is used to request information about a person in distress. The request message includes query conditions that the person in distress must meet, including the location range of the person in distress and / or the time range within which the person in distress reported the distress message. The rescue terminal is the terminal of the first rescue team participating in the rescue. The first rescue team is any one of at least one rescue team participating in the rescue. A response message is sent to the rescue terminal. The response message includes information about the person in distress who meets the query conditions, as well as the location information and / or contact information of other rescue teams besides the first rescue team among the at least one rescue team.

2. The method as described in claim 1, characterized in that, The request message also includes a type identifier for the first rescue team, which identifies the type of the first rescue team, either a professional rescue team or a non-professional rescue team.

3. The method as described in claim 1 or 2, characterized in that, The rescue terminal is located within the disaster area.

4. The method as described in claim 1 or 2, characterized in that, The method further includes: Receive a distress message from a distress terminal, wherein the distress terminal is the terminal of the first person in distress, and the distress message includes information about the first person in distress; Save the information of the first person in distress and one or more of the following: the reporting time of the distress message, the number of times the information of the first person in distress has been queried, or the rescue status of the first person in distress, wherein the rescue status indicates that the person has not been rescued or the rescue was unsuccessful.

5. The method as described in claim 4, characterized in that, The information of the first person seeking help includes the location of the first person seeking help and one or more of the following: the identification of the first person seeking help, the injured part of the first person seeking help, or the disaster category of the first person seeking help.

6. The method as described in claim 4, characterized in that, The method further includes: Send a first instruction message to the distress terminal. The first instruction message is used to indicate one or more of the following: whether the distress message has been queried, the location information of at least one rescue team participating in the rescue, the contact information of the at least one rescue team, the location information of other distress personnel besides the first distress person, or the contact information of the other distress personnel.

7. The method as described in claim 4, characterized in that, The first person seeking help meets the query criteria, and the method further includes: Receive a second instruction message from the rescue terminal, the second instruction message instructing the first person in distress to begin rescue; According to the second instruction message, the rescue status of the first person in distress is updated to "being rescued".

8. The method as described in claim 4, characterized in that, The first person seeking help meets the query criteria, and the method further includes: Receive a third indication message from the rescue terminal, the third indication message indicating that the first person in distress has been successfully rescued; According to the third instruction message, the rescue status of the first person in distress is updated to "successfully rescued".

9. The method according to any one of claims 1-2 and 5-8, characterized in that, Each person in distress who meets the query conditions has a priority level, which is determined by the time when each person in distress reported their distress message.

10. The method according to any one of claims 1-2 and 5-8, characterized in that, The receiving of the request message from the rescue terminal includes: Receive request messages from the rescue terminal via satellite; Sending a response message to the rescue terminal includes: The satellite sends a response message to the rescue terminal.

11. A communication method for rescue operations, characterized in that, The method is applied to a rescue terminal, which is the terminal of the first rescue team participating in the rescue, and the first rescue team is any one of at least one rescue team participating in the rescue; the method includes: Send a request message to the server. The request message is used to request information about the person in distress. The request message includes the query conditions that the person in distress needs to meet. The query conditions include the location range of the person in distress and / or the time range of the time when the person in distress reported the distress message. Receive a response message from the server, the response message including information of the person in distress who meets the query conditions, and the location information and / or contact information of other rescue teams besides the first rescue team among the at least one rescue team.

12. The method as described in claim 11, characterized in that, The request message also includes a type identifier for the first rescue team, which identifies the type of the first rescue team, either a professional rescue team or a non-professional rescue team.

13. The method as described in claim 11 or 12, characterized in that, The rescue terminal is located within the disaster area.

14. The method as described in claim 11 or 12, characterized in that, The distress callers who meet the query criteria include the first distress caller, and the method further includes: A second instruction message is sent to the server, which instructs the first person in distress to begin rescue.

15. The method as described in claim 11 or 12, characterized in that, The distress callers who meet the query criteria include the first distress caller, and the method further includes: A third instruction message is sent to the server, indicating that the first person in distress has been successfully rescued.

16. The method as described in claim 11 or 12, characterized in that, Each person in distress who meets the query conditions has a priority level, which is determined by the time when each person in distress reported their distress message.

17. The method as described in claim 11 or 12, characterized in that, Sending a request message to the server includes: The request message is sent to the server via satellite; Receiving a response message from the server includes: The satellite receives response messages from the server.

18. A communication method for rescue operations, characterized in that, Applied to a distress signal terminal, wherein the distress signal terminal is a terminal used by a person seeking help, the method includes: Send a distress message to the server, the distress message including information about the person seeking help; Receive a first indication message from the server, the first indication message being used to indicate one or more of the following: whether the distress message has been queried, the location information of at least one rescue team involved in the rescue, the contact information of the at least one rescue team, the location information of other distress persons besides the distress person, or the contact information of the other distress persons; The server is configured to receive a request message from a rescue terminal, the request message being used to query relevant information about a person in distress. The request message includes query conditions that the person in distress must meet, including the location range of the person in distress and / or the time range within which the person in distress reported the distress message. The rescue terminal is the terminal of the first rescue team participating in the rescue. The first rescue team is any one of at least one rescue team participating in the rescue. The server then sends a response message to the rescue terminal, the response message including information about the person in distress who meets the query conditions, as well as the location information and / or contact information of other rescue teams besides the first rescue team among the at least one rescue team.

19. The method as described in claim 18, characterized in that, The information of the person seeking help includes the location of the person seeking help and one or more of the following: the identification of the person seeking help, the injured part of the person seeking help, or the disaster category of the person seeking help.

20. A communication system for rescue operations, characterized in that, It includes a server and a rescue terminal, the server being configured to perform the method as described in any one of claims 1 to 10, and the rescue terminal being configured to perform the method as described in any one of claims 11 to 17.

21. The communication system as described in claim 20, characterized in that, It also includes a distress terminal, which is used to perform the method as described in claim 18 or 19.

22. A communication device, characterized in that, The device includes a processor for executing program code to cause the apparatus to implement the method as claimed in any one of claims 1 to 10, or to implement the method as claimed in any one of claims 11 to 17, or to implement the method as claimed in claim 18 or 19.

23. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions that, when executed by a computer, implement the method as described in any one of claims 1 to 10, or the method as described in any one of claims 11 to 17, or the method as described in claim 18 or 19.

24. A computer program product, characterized in that, The computer program product includes instructions that, when executed by a computer, implement the method as claimed in any one of claims 1 to 10, or implement the method as claimed in any one of claims 11 to 17, or implement the method as claimed in claim 18 or 19.

Images