HK1261859B - Communication data recovery method, device and equipment - Google Patents

Description

Method, device and equipment for recovering communication data

Technical Field

The present application relates to the field of computer technology, and in particular to a method, device, and equipment for recovering communication data.

Background Art

With the development and popularization of information technology, more and more users communicate and interact with each other through instant messaging (IM), such as using various IM applications, iMessage, etc.

In some application scenarios, such as when a user changes a terminal device (e.g., a mobile phone) or formats the terminal device used by the user, the user may lose access to recent chat history. For this reason, instant messaging service providers usually provide chat history recovery services.

Specifically, in the prior art, user chat records are usually backed up on the server side. If the chat records need to be restored, the data can be retrieved from the server side. With this approach, as the number of users increases, the amount of chat records stored on the server side also grows exponentially, increasing the resource consumption of the server side.

Based on the existing technology, a communication data recovery method that is more conducive to reducing server consumption is needed.

Summary of the Invention

The embodiments of this specification provide a communication data recovery method, apparatus, and device to solve the problem of high server consumption during the current instant messaging data recovery process.

The embodiments of this specification adopt the following technical solutions:

On the first user side, an embodiment of this specification provides a method for recovering communication data, including:

Send a communication data recovery request to the server;

Receiving a recoverable contact list fed back by the server, wherein the recoverable contact list includes some or all contacts of the first user;

determining one or more second users according to the restorable contact list, and notifying the server;

Receive and use the communication data of the second user fed back by the server, wherein the communication data of the second user is obtained after the server establishes a communication connection with the second user.

On the server side, the embodiment of this specification also provides a method for recovering communication data, including:

receiving a communication data recovery request sent by a first user;

sending a pre-recorded list of recoverable contacts of the first user to the first user according to the communication data recovery request; wherein the list of recoverable contacts includes some or all of the contacts of the first user;

determining the recoverable contact selected by the first user as the second user;

Acquire the communication data stored by the second user and send it to the first user.

Correspondingly, on the first user side, the embodiment of this specification further provides a communication data recovery device, including:

Request sending module, sending communication data recovery request to the server;

a list receiving module, receiving a recoverable contact list fed back by the server, wherein the recoverable contact list includes some or all contacts of the first user;

a user determination module, configured to determine one or more second users based on the restorable contact list and notify the server;

The data recovery module receives and uses the communication data of the second user fed back by the server, wherein the communication data of the second user is obtained after the server communicates with the second user.

On the server side, the embodiment of this specification further provides a communication data recovery device, including:

a request receiving module for receiving a communication data recovery request sent by a first user;

a list feedback module, which sends a pre-recorded list of recoverable contacts of the first user to the first user according to the communication data recovery request; wherein the recoverable contact list includes some or all of the contacts of the first user;

A selection processing module determines the recoverable contact selected by the first user as the second user;

The data processing module obtains the communication data stored by the second user and sends it to the first user.

Correspondingly, on the first user side, an embodiment of this specification further provides a communication data recovery device, including: a processor and a memory, wherein:

The memory stores a recovery program for communication data;

The processor calls a communication data recovery program stored in the memory and executes:

Send a communication data recovery request to the server;

Receiving a recoverable contact list fed back by the server, wherein the recoverable contact list includes some or all contacts of the first user;

determining one or more second users according to the restorable contact list, and notifying the server;

Receive and use the communication data of the second user fed back by the server, wherein the communication data of the second user is obtained after the server establishes a communication connection with the second user.

On the server side, an embodiment of this specification further provides a communication data recovery device, including: a processor and a memory, wherein:

The memory stores a recovery program for communication data;

The processor calls a communication data recovery program stored in the memory and executes:

receiving a communication data recovery request sent by a first user;

sending a pre-recorded list of recoverable contacts of the first user to the first user according to the communication data recovery request; wherein the list of recoverable contacts includes some or all of the contacts of the first user;

determining the recoverable contact selected by the first user as the second user;

Acquire the communication data stored by the second user and send it to the first user.

At least one of the above technical solutions adopted in the embodiments of this specification can achieve the following beneficial effects:

A first user who needs to restore communication data can send a request to the server and obtain a list of recoverable contacts provided by the server. Based on this, the first user can then identify one or more second users from the list of recoverable contacts, depending on actual application needs, in order to restore communication data between the first and second users. The server can then retrieve the communication data stored by the second users and provide it back to the first user, allowing the communication data between the first and second users to be restored.

That is to say, when the first user uses a terminal without chat records for instant messaging, the first user can actively select the contact communication data that needs to be restored, and at the same time, the communication data of some contacts can be not restored, which is conducive to improving the user experience and can reduce the consumption of communication traffic to a certain extent.

In addition, for the server, since the communication data can be stored locally on the terminal used by the user, the storage volume of the communication data in the server can be reduced as much as possible, which is conducive to reducing the server's resource consumption and data maintenance costs.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

FIG1 is a schematic diagram of the architecture of the communication data recovery method provided in an embodiment of this specification;

FIG2 is a schematic diagram of a recovery process based on communication data on a first user side according to an embodiment of the present disclosure;

FIG3 is a schematic diagram of a server-side communication data recovery process according to an embodiment of the present disclosure;

FIG4 is a schematic diagram of a communication data recovery process in actual application according to an embodiment of this specification;

FIG5 is a schematic diagram of the structure of a device for recovering communication data based on a first user side according to an embodiment of the present disclosure;

FIG6 is a schematic diagram of the structure of a communication data recovery device based on the server side provided in an embodiment of this specification.

DETAILED DESCRIPTION

To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

In actual applications, communication data such as chat logs is not only backed up on the server but also stored locally on the user's terminal. Therefore, with respect to the communication data recovery method provided in the embodiments of this specification, when a user needs to recover communication data, they can retrieve the saved communication data from other users' terminals, thereby minimizing the communication data stored on the server.

To implement the above merchant-based service push method, the architecture shown in FIG1 may be adopted.

In FIG1 , the server can provide instant messaging services for users. The server can be composed of a single server, a clustered server, or a distributed server, etc., which is not specifically limited here.

The first user in Figure 1 can be considered as the user who needs to recover communication data. Generally speaking, the following situations may cause users to need to recover communication data:

In the first scenario, a user changes their device and conducts instant messaging on the new device for the first time. In this case, the new device has never stored the user's communication data, so communication data recovery is required. The terminal change mentioned here can include scenarios where the user updates their device (such as a new phone) or where the user uses the same instant messaging account to log in on multiple devices.

In the second case, the terminal used by the user has been formatted, resulting in the deletion of the previously saved communication data, so the communication data needs to be restored.

The second user in FIG1 can be considered as a user who provides communication data to the first user. Generally speaking, the second user is an instant messaging contact or friend of the first user.

It should be noted that in one or more embodiments of this specification, users can perform instant messaging by installing and running an instant messaging application on a terminal, or by using the instant messaging function built into the terminal. Therefore, with respect to the architecture shown in FIG1 , the first user or second user mentioned can be understood to include individual users, the terminal devices used by the users, the accounts used by the users, and so on. This should not constitute a limitation of this application.

In one or more embodiments of this specification, the communication data mainly refers to the chat records in instant messaging. In other words, the text, pictures, audio or video data sent by the user during the instant messaging process can be considered to be covered by the communication data.

Based on the architecture described in FIG1 , the technical solutions provided in the embodiments of this specification will be described in detail below.

On the first user side, an embodiment of this specification provides a method for recovering communication data, as shown in FIG2 , which specifically includes the following steps:

Step S201: Send a communication data recovery request to the server.

In the aforementioned situation, if the first user has not yet obtained the chat records with other contacts, then the first user may send a communication data recovery request to the server.

As a possible approach, the terminal used by the user (or the instant messaging application installed on the terminal) has a chat history detection function. If it is detected that no chat history is stored locally, a corresponding communication data recovery request can be automatically sent to the server.

As another possible manner, the user may actively instruct the terminal (or the instant messaging application running on the terminal) to send a communication data recovery request to the server through a corresponding option or control.

It is understandable that the communication data recovery request should at least carry the user information of the first user, such as user ID, account name, etc., which is not specifically limited here.

Step S203: Receive a recoverable contact list fed back by the server, wherein the recoverable contact list includes some or all of the first user's contacts.

In the embodiment of the present specification, the server may generate the recoverable contact list based on the first user's address book contacts (the generation process of the list will be described later), and send the list to the first user based on the first user's request.

Step S205: determining one or more second users according to the restorable contact list, and notifying the server.

The first user can select the contacts whose communication data need to be restored according to the actual application needs, and can restore the communication data of one or some recoverable contacts, or restore the communication data of all recoverable contacts in the list. Of course, this should not constitute a limitation of the present application.

In the embodiments of this specification, the selected recoverable contact can be considered the second user, and accordingly, the first user will notify the server. Regarding the process of notifying the server, the selected recoverable contact can also be notified to the server via a request. It is understood that this notification should at least include the identifier of the first user (e.g., the first user's account name) and the identifier of the second user (e.g., the second user's account name).

Step S207: receiving and using the communication data of the second user fed back by the server, wherein the communication data of the second user is obtained after the server establishes a communication connection with the second user.

In the embodiments of this specification, the chat history between the first user and the restorable contact is not stored on a server, but rather on the device used by the restorable contact. Based on this, the server can communicate with the second user, obtain the second user's stored communication data, and send it to the first user. Thus, the first user can restore the chat history after receiving the communication data with the second user.

As can be seen from the above, a first user who needs to restore communication data can send a request to the server and obtain a list of recoverable contacts provided by the server. Based on this, the first user can then determine one or more second users from the list of recoverable contacts based on actual application needs in order to restore communication data between the first user and the second user. In this way, the server can obtain the communication data stored by the second user and finally feedback it to the first user, thereby restoring the communication data between the first user and the second user.

That is to say, when the first user uses a terminal without chat records for instant messaging, the first user can actively select the contact communication data that needs to be restored, and at the same time, the communication data of some contacts can be not restored, which is conducive to improving the user experience and can reduce the consumption of communication traffic to a certain extent.

For the method shown in FIG2 , the execution subject can generally be the client of the instant messaging application running on the terminal. Of course, in some cases, it can also be the terminal used by the first user itself, and this is not specifically limited here. In the embodiments of this specification, the scenario in which the execution subject is the instant messaging application client is mainly described. It should be understood that the specific execution method steps are also applicable to the scenario in which the execution subject is the terminal itself.

In addition, in the above method, after the first user receives the recoverable contact list fed back by the server, the IM client may automatically select the corresponding second user, or the user may actively select the corresponding second user.

Specifically, as a feasible implementation in this specification, corresponding rules are set in the IM client to select one or more recoverable contacts as the second user after receiving the recoverable contact list.

The rule set here may be: in the case of non-4G network/WiFi network, only the recoverable contact corresponding to the chat window currently opened by the user is determined as the second user (other recoverable contacts in the recoverable contact list are not selected at this time).

The set rule may also be: in the case of a 4G network/WiFi network, all the recoverable contacts in the recoverable contact list are regarded as the second user.

Alternatively, the set rule may be: according to social intimacy (mainly referring to the number of times messages were sent to each other during previous instant messaging processes), the recoverable contacts whose social intimacy exceeds a set threshold are selected as the second users.

Of course, the above rules can be specifically set according to the needs of actual application. The above is merely an illustrative example and should not constitute a limitation of this application.

As another feasible implementation in the present specification, after receiving the list of recoverable contacts, the IM client may directly display the list to the user, receive the user's selection operation for one or more recoverable contacts in the list, and use the recoverable contacts selected by the user as the second user.

Afterward, the first user sends a notification to the server to obtain the communication data provided by the server. In a practical application scenario, the first user can typically send the identification information of the second users whose communication data needs to be recovered to the server one by one. If the server fails to obtain the communication data of a second user, the first user sends the identification information of the next second user to the server. And so on, until all second users have been traversed.

The above description is based on the first user side. On the server side, an embodiment of this specification provides a method for recovering communication data, as shown in FIG3 , which specifically includes the following steps:

Step S301: receiving a communication data recovery request sent by a first user.

The process of sending the communication data recovery request can refer to the above content and will not be described in detail here.

Step S303: According to the communication data recovery request, a pre-recorded list of recoverable contacts of the first user is sent to the first user, wherein the list of recoverable contacts includes some or all of the contacts of the first user.

In the embodiments of this specification, the restorable contact list may be generated by a server. In some embodiments, the server may treat all contacts in the first user's address book as restorable contacts to generate the restorable contact list. Of course, in other embodiments, due to cost, data volume, and other considerations, only a portion of the contacts in the first user's address book may be treated as restorable contacts to generate the restorable contact list.

As for the above two methods, which method to adopt will be determined according to the needs of actual application and does not constitute a limitation to this application.

It is understandable that, in order to minimize the communication data stored in the server, the recoverable contact list generated by the server generally only contains identification data such as the contact's ID or account name, rather than the communication data.

Combining the above steps S301 and S303, it can be seen that when the first user initiates a request to restore communication data, the server does not directly send the communication data to the first user for restoration, but instead sends a list of recoverable contacts to the first user, allowing the first user to select the chat records of the contacts that need to be restored based on the list of recoverable contacts.

Step S305: Determine the recoverable contact selected by the first user as the second user.

As mentioned above, after receiving the list of recoverable contacts, the first user can select one or more recoverable contacts in the list. Then, based on the first user's selection, the server can determine the user (i.e., the second user) for whom the first user needs to restore communication data.

Step S307: Acquire the communication data stored in the recoverable contact and send it to the first user.

In the embodiments of this specification, the server itself does not store (or stores as little as possible) communication data between users. Such communication data is usually stored in the terminals used by the users. Therefore, once the server determines the second user selected by the first user for whom communication data recovery is required, the server can obtain the communication data stored by the second user through the communication connection with the second user. The obtained communication data is then sent to the first user.

Of course, when the server obtains the communication data stored by the second user, it can obtain the communication data from the second user according to the second user identification information sent by the first user one by one, or it can concurrently obtain the communication data of each second user at the same time according to the request of the first user.

Regarding the method shown in FIG. 3 , it should be noted that the process for generating the recoverable contact list may be as follows: the server obtains all contacts of the first user, determines a specified number of contacts from the obtained contacts, obtains identification information of the determined contacts, and generates the recoverable contact list based on the identification information. The identification information includes at least a contact ID or an account name.

All contacts mentioned above include: friends of the first user, contacts in the social groups that the first user has joined, and contacts with whom the first user has not established a friend relationship.

Generally speaking, the server can filter out some contacts based on the social intimacy between the first user and each contact to generate the aforementioned recoverable contact list. If cost and data volume are not considered, all contacts of the first user can also be generated into a recoverable contact list.

At this point, the actual execution process of the above method in the embodiment of this specification can be shown in Figure 4, which specifically includes the following steps:

Step S401: The first user sends a communication data recovery request to the server.

Step S403: The server sends the pre-generated list of recoverable contacts of the first user to the first user.

The restorable contact list includes some or all of the first user's contacts.

Step S405: The first user determines one or more second users based on the restorable contact list and notifies the server.

Step S407: The server monitors whether the second user is online according to the second user selected by the first user.

Step S409: When the second user is online, the server obtains the communication data between the second user and the first user stored by the second user.

Step S411: The server sends the acquired communication data to the first user.

Step S413: The first user uses the communication data sent by the server to perform recovery.

In summary, instant messaging data between users is distributed and stored on each user's terminal device. This replaces centralized server storage with terminal storage, significantly reducing server storage costs. To restore communication data, a user can request the server to retrieve the corresponding communication data locally from another user's terminal and forward it to the requesting user, thus restoring the communication data.

Of course, in some special practical application scenarios, the first user and the second user can directly transmit communication data in a point-to-point manner without the need for server-side transfer.

The above is a method for recovering communication data provided by the embodiment of this specification. Based on the same idea, the embodiment of this specification also provides a corresponding device for recovering communication data.

Specifically, on the first user side, the communication data recovery device provided in the embodiment of this specification is shown in FIG5 , and the device includes:

Request sending module 501, sending a communication data recovery request to the server;

A list receiving module 502 receives a recoverable contact list fed back by the server, wherein the recoverable contact list includes some or all contacts of the first user;

A user determination module 503 determines one or more second users according to the restorable contact list and notifies the server;

The data recovery module 504 receives and uses the communication data of the second user fed back by the server, wherein the communication data of the second user is obtained after the server communicates with the second user.

Furthermore, the user determination module 503 determines a network status of a network used by the first user, and determines one or more contacts in the restorable contact list as the second user according to the network status and a preset restoration rule.

The user determination module 503 receives a selection operation on a recoverable contact in the recoverable contact list, and determines one or more contacts as a second user according to the selection operation.

The restorable contact list includes identification information of the restorable contacts. Based on this, the user determination module 503 determines one or more identification information and uses the contacts corresponding to the identification information as the second user.

The identification information at least includes: a contact ID or an account name.

The user determination module 503 sends communication data acquisition requests to the server one by one according to the determined second users.

The user determination module 503 sends a request for obtaining the communication data of the next second user to the server if the communication data fed back by the server is not received, until all second users are traversed.

Based on the device shown in FIG5 , in actual application, it can be implemented by a physical device (such as a terminal device). Specifically, the device includes a processor and a memory, wherein:

The memory stores a recovery program for communication data;

The processor calls a communication data recovery program stored in the memory and executes:

Send a communication data recovery request to the server;

Receiving a recoverable contact list fed back by the server, wherein the recoverable contact list includes some or all contacts of the first user;

determining one or more second users according to the restorable contact list, and notifying the server;

Receive and use the communication data of the second user fed back by the server, wherein the communication data of the second user is obtained after the server establishes a communication connection with the second user.

On the server side, the embodiment of this specification further provides a communication data recovery device, as shown in FIG6 , the device includes:

The request receiving module 601 receives a communication data recovery request sent by a first user;

A list feedback module 602 sends a pre-recorded list of recoverable contacts of the first user to the first user according to the communication data recovery request; wherein the recoverable contact list includes some or all of the contacts of the first user;

The selection processing module 603 determines the recoverable contact selected by the first user as the second user;

The data processing module 604 obtains the communication data stored by the second user and sends it to the first user.

Furthermore, the apparatus further includes: a list generating module 605, which obtains all contacts of the first user, determines a specified number of contacts from all the obtained contacts, obtains identification information of the determined contacts, and generates the recoverable contact list based on the identification information;

The said all contacts include: friends of the first user, contacts in the social group that the first user has joined, and contacts with whom the first user has not established a friend relationship.

The identification information includes at least: a contact ID or an account name.

The list generation module 605 determines the interaction intimacy between the first user and each contact within a set historical time period, and determines, based on the interaction intimacy, contacts whose interaction intimacy exceeds a set threshold among all the acquired contacts.

The list generating module 605 determines all the acquired contacts as contacts required for generating a list of recoverable contacts.

The data processing module 604 determines the online status of the second user, and when it is determined that the second user is online, establishes a communication connection with the second user and obtains the communication data stored by the second user.

The apparatus further includes a notification module 606 , which returns a failure notification to the first user if the server fails to obtain the communication data stored by the second user.

Based on the apparatus shown in FIG6 , in actual applications, it can be implemented by a physical device (such as a terminal device/server). Specifically, the device includes a processor and a memory, wherein:

The memory stores a recovery program for communication data;

The processor calls a communication data recovery program stored in the memory and executes:

receiving a communication data recovery request sent by a first user;

sending a pre-recorded list of recoverable contacts of the first user to the first user according to the communication data recovery request; wherein the list of recoverable contacts includes some or all of the contacts of the first user;

determining the recoverable contact selected by the first user as the second user;

Acquire the communication data stored by the second user and send it to the first user.

The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the device, equipment, and media embodiments are generally similar to the method embodiments, so their descriptions are relatively simple. For relevant parts, refer to the descriptions of the method embodiments and will not be repeated here.

Thus far, specific embodiments of the present subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing may be advantageous.

In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and/or hardware.

It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present invention is described with reference to the flowcharts and/or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of processes and/or boxes in the flowchart and/or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included within the scope of the claims of the present application.

Claims (26)

1. A method for recovering communication data, comprising: Receive a communication data recovery request sent by the first user; the communication data recovery request is automatically generated by the first user's terminal after detecting that no chat history is stored locally; Based on the communication data recovery request, a pre-recorded list of recoverable contacts for the first user is sent to the first user; wherein, the list of recoverable contacts contains some or all of the first user's contacts; the all contacts include: the first user's friends, contacts in social groups that the first user has joined, and contacts who have not established a friend relationship with the first user; the list of recoverable contacts is generated by the server based on a subset of contacts filtered according to the social intimacy between the first user and each contact; the list of recoverable contacts includes the contact's ID or account name; the communication data between the first user and the recoverable contacts is stored on the terminal used by the recoverable contacts; The recoverable contact selected by the first user is identified as the second user; the social intimacy between the second user and the first user exceeds a set threshold. The communication data stored by the second user is obtained and sent to the first user; the communication data of the second user is obtained by the server after establishing a communication connection with the second user. The step of determining the recoverable contact selected by the first user as the second user specifically includes: The recoverable contact corresponding to the chat window currently opened by the first user is identified as the second user; Alternatively, determine the social intimacy level and identify recoverable contacts whose social intimacy level exceeds a set threshold as second users. 2. The method as described in claim 1, wherein the recoverable contact list is generated by the following method: The server retrieves all contacts of the first user; From all the contacts obtained, identify a specified number of contacts and obtain the identification information of the identified contacts; The list of recoverable contacts is generated based on the identification information; The identification information includes at least: contact ID or account name. 3. The method as described in claim 2, wherein determining a specified number of contacts from all obtained contacts specifically includes: Determine the level of interaction intimacy between the first user and each contact within a set historical time period; Based on the interaction intimacy, among all the contacts obtained, those whose interaction intimacy exceeds a set threshold are identified. 4. The method as described in claim 2, wherein determining a specified number of contacts from all obtained contacts specifically includes: All the contacts obtained are selected as the contacts needed to generate the recoverable contact list. 5. The method as described in claim 1, wherein obtaining the communication data stored by the second user specifically includes: Determine the online status of the second user; When it is determined that the second user is online, a communication connection is established with the second user, and the communication data stored by the second user is obtained. 6. The method of claim 1, further comprising: If the server does not obtain the communication data stored by the second user, it returns a failure notification to the first user. 7. A method for recovering communication data, comprising: Send a communication data recovery request to the server; the communication data recovery request is automatically generated by the first user's terminal after detecting that no chat history is stored locally; The system receives a list of recoverable contacts from the server. This list includes some or all of the first user's contacts. All contacts include: the first user's friends, contacts in social groups the first user has joined, and contacts with whom the first user has not established a friendship relationship. The recoverable contact list is generated based on a subset of contacts selected by the server according to the social intimacy between the first user and each contact. The list includes the contact's ID or account name. Communication data between the first user and the recoverable contacts is stored on the terminal used by the recoverable contacts. One or more second users are identified based on the list of recoverable contacts, and the server is notified; the social intimacy between the second user and the first user exceeds a set threshold. The server receives and uses the communication data of the second user fed back by the server, wherein the communication data of the second user is obtained by the server after establishing a communication connection with the second user; The step of determining one or more second users based on the list of recoverable contacts specifically includes: The recoverable contact corresponding to the chat window currently opened by the first user is identified as the second user; Alternatively, determine the social intimacy level and identify recoverable contacts whose social intimacy level exceeds a set threshold as second users. 8. The method of claim 7, wherein determining one or more second users based on the recoverable contact list, specifically includes: Determine the network status of the network used by the first user; Based on the network status and preset recovery rules, one or more contacts are selected as second users from the list of recoverable contacts. 9. The method of claim 7, wherein determining one or more second users based on the recoverable contact list, specifically includes: Receive a selection operation for a recoverable contact in the recoverable contact list; Based on the selection operation, one or more contacts are selected as the second user. 10. The method as described in claim 8 or 9, wherein the list of recoverable contacts includes identification information of recoverable contacts; Designate one or more contacts as secondary users, specifically including: Determine one or more of the identification information, and designate the contact person corresponding to the identification information as the second user; The identification information includes at least: contact ID or account name. 11. The method of claim 10, wherein notifying the server specifically includes: Based on the identified second user, requests to obtain communication data are sent to the server one by one. 12. The method of claim 11, further comprising: If no communication data is received from the server, a request to obtain the communication data of the next second user is sent to the server, and this process continues until all second users have been traversed. 13. A communication data recovery device, comprising: The request receiving module receives a communication data recovery request sent by the first user; the communication data recovery request is automatically generated by the first user's terminal after detecting that no chat history is stored locally. The list feedback module, based on the communication data recovery request, sends a pre-recorded list of recoverable contacts for the first user to the first user; wherein, the list of recoverable contacts contains some or all of the first user's contacts; the all contacts include: the first user's friends, contacts in social groups joined by the first user, and contacts with whom the first user has not established a friend relationship; the list of recoverable contacts is generated by the server based on a subset of contacts filtered according to the social intimacy between the first user and each contact; the list of recoverable contacts includes the contact's ID or account name; the communication data between the first user and the recoverable contacts is stored on the terminal used by the recoverable contacts; The selection processing module determines the recoverable contact selected by the first user as the second user; the social intimacy between the second user and the first user exceeds a set threshold. The data processing module acquires the communication data stored by the second user and sends it to the first user; the communication data of the second user is obtained by the server after establishing a communication connection with the second user. The selection processing module is specifically used for: The recoverable contact corresponding to the chat window currently opened by the first user is identified as the second user; Alternatively, determine the social intimacy level and identify recoverable contacts whose social intimacy level exceeds a set threshold as second users. 14. The apparatus of claim 13, further comprising: a list generation module, for acquiring all contacts of a first user, determining a specified number of contacts from the acquired contacts, acquiring identification information of the determined contacts, and generating the recoverable contact list based on the identification information; The identification information includes at least: contact ID or account name. 15. The apparatus of claim 14, wherein the list generation module determines the interaction intimacy between the first user and each contact within a set historical time period, and determines, based on the interaction intimacy, contacts whose interaction intimacy exceeds a set threshold among all the acquired contacts. 16. The apparatus of claim 14, wherein the list generation module determines all the acquired contacts as those required to generate the recoverable contact list. 17. The apparatus of claim 13, wherein the data processing module determines the online status of the second user, and when the second user is determined to be online, establishes a communication connection with the second user and acquires the communication data stored by the second user. 18. The apparatus of claim 13, further comprising: a notification module, wherein if the server fails to obtain the communication data stored by the second user, it returns a failure notification to the first user. 19. A communication data recovery device, comprising: The request sending module sends a communication data recovery request to the server; the communication data recovery request is automatically generated by the first user's terminal after detecting that no chat history is stored locally. The list receiving module receives a list of recoverable contacts from the server. This list includes some or all of the first user's contacts. All contacts include: the first user's friends, contacts in social groups the first user has joined, and contacts with whom the first user has not established a friend relationship. The recoverable contact list is generated based on a subset of contacts selected by the server according to the social intimacy between the first user and each contact. The list includes the contact's ID or account name. Communication data between the first user and the recoverable contacts is stored on the terminal used by the recoverable contacts. The user identification module identifies one or more second users based on the list of recoverable contacts and notifies the server; the social intimacy between the second user and the first user exceeds a set threshold. The data recovery module receives and uses the communication data of the second user fed back by the server, wherein the communication data of the second user is obtained by the server after establishing a communication connection with the second user; The user determination module is specifically used for: The recoverable contact corresponding to the chat window currently opened by the first user is identified as the second user; Alternatively, determine the social intimacy level and identify recoverable contacts whose social intimacy level exceeds a set threshold as second users. 20. The apparatus of claim 19, wherein the user determination module determines the network status of the network used by the first user, and determines one or more contacts as the second user in the list of recoverable contacts based on the network status and a preset recovery rule. 21. The apparatus of claim 19, wherein the user determination module receives a selection operation for a recoverable contact in the recoverable contact list, and determines one or more contacts as a second user based on the selection operation. 22. The apparatus of claim 20 or 21, wherein the list of recoverable contacts includes identification information of recoverable contacts; The user determination module determines one or more of the identification information and designates the contact person corresponding to the identification information as the second user. The identification information includes at least: contact ID or account name. 23. The apparatus of claim 22, wherein the user determination module sends a request to obtain communication data to the server one by one, based on the determined second user. 24. The apparatus of claim 19, wherein if the user determination module does not receive communication data from the server, it sends a request to the server to obtain the communication data of the next second user, until all second users have been traversed. 25. A communication data recovery device, comprising: a processor and a memory, wherein: The memory stores the communication data recovery program; The processor calls the communication data recovery program stored in the memory and executes it: Receive a communication data recovery request sent by the first user; the communication data recovery request is automatically generated by the first user's terminal after detecting that no chat history is stored locally; Based on the communication data recovery request, a pre-recorded list of recoverable contacts for the first user is sent to the first user; wherein, the list of recoverable contacts contains some or all of the first user's contacts; the all contacts include: the first user's friends, contacts in social groups that the first user has joined, and contacts who have not established a friend relationship with the first user; the list of recoverable contacts is generated by the server based on a subset of contacts filtered according to the social intimacy between the first user and each contact; the list of recoverable contacts includes the contact's ID or account name; the communication data between the first user and the recoverable contacts is stored on the terminal used by the recoverable contacts; The recoverable contact selected by the first user is identified as the second user; the social intimacy between the second user and the first user exceeds a set threshold. The communication data stored by the second user is obtained and sent to the first user; the communication data of the second user is obtained by the server after establishing a communication connection with the second user. The step of determining the recoverable contact selected by the first user as the second user specifically includes: The recoverable contact corresponding to the chat window currently opened by the first user is identified as the second user; Alternatively, determine the social intimacy level and identify recoverable contacts whose social intimacy level exceeds a set threshold as second users. 26. A communication data recovery device, comprising: a processor and a memory, wherein: The memory stores the communication data recovery program; The processor calls the communication data recovery program stored in the memory and executes it: Send a communication data recovery request to the server; the communication data recovery request is automatically generated by the first user's terminal after detecting that no chat history is stored locally; The system receives a list of recoverable contacts from the server. This list includes some or all of the first user's contacts. All contacts include: the first user's friends, contacts in social groups the first user has joined, and contacts with whom the first user has not established a friendship relationship. The recoverable contact list is generated based on a subset of contacts selected by the server according to the social intimacy between the first user and each contact. The list includes the contact's ID or account name. Communication data between the first user and the recoverable contacts is stored on the terminal used by the recoverable contacts. One or more second users are identified based on the list of recoverable contacts, and the server is notified; the social intimacy between the second user and the first user exceeds a set threshold. The server receives and uses the communication data of the second user fed back by the server, wherein the communication data of the second user is obtained by the server after establishing a communication connection with the second user; The step of determining one or more second users based on the list of recoverable contacts specifically includes: The recoverable contact corresponding to the chat window currently opened by the first user is identified as the second user; Alternatively, determine the social intimacy level and identify recoverable contacts whose social intimacy level exceeds a set threshold as second users.