CN114024926A - 一种通讯数据的恢复方法、装置及设备 - Google Patents

Abstract

本说明书实施例公开了一种通讯数据的恢复方法、装置及设备。对于需要恢复通讯数据的第一用户而言，可以向服务器发出请求，并获得由服务器提供的可恢复联系人列表。在此基础上，第一用户可以根据实际应用的需要，根据可恢复联系人列表确定一个或多个第二用户，以便恢复第一用户与第二用户之间的通讯数据，这样一来，服务器便可以获取由第二用户所存储的通讯数据，最后反馈给第一用户，以恢复与第二用户之间的通讯数据。

Description

一种通讯数据的恢复方法、装置及设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种通讯数据的恢复方法、装置及设备。

背景技术

随着信息技术的发展和普及，越来越多的用户通过即时通讯(InstantMessaging，IM)的方式实现彼此间的交流互动，如：采用各类IM应用、iMessage等进行通讯。

在某些应用场景下，如：用户更换了终端设备(如：手机)，或者用户使用的终端设备进行了格式化等场景，可能导致用户无法获知近期的聊天记录。为此，即时通讯服务商通常会提供聊天记录的恢复服务。

具体地，在现有技术中，用户的聊天记录通常会在服务端进行备份，那么，若需要恢复聊天记录时，则可以从服务端获取数据。对于该方式而言，随着用户量的增长，存储在服务端的聊天记录的数据量也呈现指数级增长，增加服务端的资源消耗。

基于现有技术，需要一种更为有利于降低服务端消耗的通讯数据恢复方式。

发明内容

本说明书实施例提供一种通讯数据的恢复方法、装置及设备，用以解决目前的即时通讯数据恢复过程中服务端的消耗较高的问题。

本说明书实施例采用下述技术方案：

在第一用户侧，本说明书实施例提供一种通讯数据的恢复方法，包括：

向服务器发送通讯数据恢复请求；

接收服务器反馈的可恢复联系人列表，其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

根据所述可恢复联系人列表确定一个或多个第二用户，并通知所述服务器；

接收并使用所述服务器反馈的所述第二用户的通讯数据，其中，所述第二用户的通讯数据由所述服务器与所述第二用户进行通信连接后获得。

在服务器侧，本说明书实施例还提供一种通讯数据的恢复方法，包括：

接收由第一用户发出的通讯数据恢复请求；

根据所述通讯数据恢复请求，将预先记录的、该第一用户的可恢复联系人列表发送给所述第一用户；其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

确定所述第一用户所选择的可恢复联系人，作为第二用户；

获取所述第二用户所存储的通讯数据，发送给所述第一用户。

对应地，在第一用户侧，本说明书实施例还提供一种通讯数据的恢复装置，包括：

请求发送模块，向服务器发送通讯数据恢复请求；

列表接收模块，接收服务器反馈的可恢复联系人列表，其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

用户确定模块，根据所述可恢复联系人列表确定一个或多个第二用户，并通知所述服务器；

数据恢复模块，接收并使用所述服务器反馈的所述第二用户的通讯数据，其中，所述第二用户的通讯数据由所述服务器与所述第二用户进行通信连接后获得。

在服务器侧，本说明书实施例还提供一种通讯数据的恢复装置，包括：

请求接收模块，接收由第一用户发出的通讯数据恢复请求；

列表反馈模块，根据所述通讯数据恢复请求，将预先记录的、该第一用户的可恢复联系人列表发送给所述第一用户；其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

选择处理模块，确定所述第一用户所选择的可恢复联系人，作为第二用户；

数据处理模块，获取所述第二用户所存储的通讯数据，发送给所述第一用户。

对应地，在第一用户侧，本说明书实施例还提供一种通讯数据的恢复设备，包括：处理器、存储器，其中：

所述存储器，存储通讯数据的恢复程序；

所述处理器，调用存储器中存储的通讯数据的恢复程序，并执行：

向服务器发送通讯数据恢复请求；

接收服务器反馈的可恢复联系人列表，其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

根据所述可恢复联系人列表确定一个或多个第二用户，并通知所述服务器；

接收并使用所述服务器反馈的所述第二用户的通讯数据，其中，所述第二用户的通讯数据由所述服务器与所述第二用户进行通信连接后获得。

在服务器侧，本说明书实施例还提供一种通讯数据的恢复设备，包括：处理器、存储器，其中：

所述存储器，存储通讯数据的恢复程序；

所述处理器，调用存储器中存储的通讯数据的恢复程序，并执行：

接收由第一用户发出的通讯数据恢复请求；

根据所述通讯数据恢复请求，将预先记录的、该第一用户的可恢复联系人列表发送给所述第一用户；其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

确定所述第一用户所选择的可恢复联系人，作为第二用户；

获取所述第二用户所存储的通讯数据，发送给所述第一用户。

本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：

对于需要恢复通讯数据的第一用户而言，可以向服务器发出请求，并获得由服务器提供的可恢复联系人列表。在此基础上，第一用户可以根据实际应用的需要，根据可恢复联系人列表确定一个或多个第二用户，以便恢复第一用户与第二用户之间的通讯数据，这样一来，服务器便可以获取由第二用户所存储的通讯数据，最后反馈给第一用户，以恢复与第二用户之间的通讯数据。

也就是说，当第一用户使用没有聊天记录的终端进行即时通讯时，第一用户可主动选择所需恢复的联系人通讯数据，同时对于部分联系人的通讯数据可以不选择进行恢复，有利于提升用户体验，并且能够在一定程度减少通信流量的消耗。

此外，对于服务器而言，由于通讯数据可存储在用户所使用的终端本地，那么，服务器中便可以尽可能地减少通讯数据的存储量，有利于减少服务器的资源消耗及数据维护成本。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本说明书实施例提供的通讯数据的恢复方法所基于的架构示意图；

图2为本说明书实施例提供的基于第一用户侧的通讯数据的恢复过程示意图；

图3为本说明书实施例提供的基于服务器侧的通讯数据的恢复过程示意图；

图4为本说明书实施例提供的在实际应用时通讯数据的恢复过程示意图；

图5为本说明书实施例提供的基于第一用户侧的通讯数据的恢复装置结构示意图；

图6为本说明书实施例提供的基于服务器侧的通讯数据的恢复装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在实际应用中，对于诸如聊天记录等通讯数据，除了备份于服务端之外，也会存储在用户所使用的终端本地。那么，对于本说明书实施例中提供的通讯数据的恢复方法而言，当某一用户需要恢复通讯数据时，可以从其他用户的终端中获取其保存的通讯数据，便可尽量减少服务端所存储的通讯数据。

为实现上述基于商户的业务推送方法，可以采用如图1所示的架构。

在图1中，服务端可为用户提供即时通讯服务，该服务端可由单一服务器、集群式服务器或分布式服务器等构成，这里不进行具体限定。

图1中的第一用户，可认为是需要进行通讯数据恢复的用户。一般来说，以下情况可能会造成用户需要进行通讯数据恢复：

情况一，用户更换了终端，并首次在该更换后的终端上进行即时通讯，该情况下，更换后的终端上从未存储该用户的通讯数据，故需要进行通讯数据的恢复。这里所提及的更换终端，既可以包括用户更新其使用的终端(如：更换新手机)的场景，也可以包括用户使用同一即时通讯账号进行多设备登录的场景。

情况二，用户所使用的终端进行了格式化处理，导致原先保存的通讯数据被清除，故需要进行通讯数据的恢复。

图1中的第二用户，可认为是向第一用户提供通讯数据的用户，一般来说，第二用户是第一用户的即时通讯的联系人或好友。

需要说明的是，在本说明书的一个或多个实施例中，用户可以通过安装运行在终端上的即时通讯应用进行即时通讯，也可以使用终端自带的即时通讯功能进行即时通讯。所以，针对图1所示的架构，所述的第一用户或第二用户，可理解为涵盖了用户个人以及用户所使用的终端设备、用户所使用的账户等。这里并不应该构成对本申请的限定。

在本说明书的一个或多个实施例中，所述的通讯数据，主要是指即时通讯中的聊天记录，换言之，在用户进行即时通讯过程中所发送的文本、图片、音频或视频等数据，均可认为是所述的通讯数据所涵盖的范围。

基于上述如图1所述的架构，以下将详细说明本说明书实施例中所提供的技术方案。

在第一用户侧，本说明书实施例中提供一种通讯数据的恢复方法，如图2所示，具体包括以下步骤：

步骤S201：向服务器发送通讯数据恢复请求。

在前述的情况下，第一用户暂未获得与其他联系人的聊天记录，那么，便可以向服务器发出通讯数据恢复请求。

作为一种可能的方式，用户所使用的终端(或安装于该终端上的即时通讯应用)，具有聊天记录的检测功能，若检测到本地并未存储有聊天记录，则可自动向服务器发送相应的通讯数据恢复请求。

作为另一种可能的方式，用户可以主动通过相应的选项或控件，指示终端(或运行于该终端上的即时通讯应用)向服务器发出通讯数据恢复请求。

可以理解的是，所述的通讯数据恢复请求中至少应携带有该第一用户的用户信息，如：用户ID、账户名等，这里不进行具体限定。

步骤S203：接收服务器反馈的可恢复联系人列表。其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人。

在本说明书实施例中，服务器可基于第一用户的通讯录联系人，生成所述的可恢复联系人列表(该列表的生成过程在后续将进行说明)，并基于第一用户的请求，发送给该第一用户。

步骤S205：根据所述可恢复联系人列表确定一个或多个第二用户，并通知所述服务器。

第一用户可以根据实际应用的需要，选择所需恢复通讯数据的联系人，既可以恢复某一或某些可恢复联系人的通讯数据，也可以恢复列表中所有可恢复联系人的通讯数据。当然，这里并不应构成对本申请的限定。

在本说明书实施例中，对于选定的可恢复联系人，可看作是第二用户，相应地，第一用户将通知服务器。对于通知服务器的过程而言，也同样可采用请求的方式将选定的可恢复联系人通知服务器。可以理解地，此次通知至少应携带第一用户的标识(如：第一用户的账户名)以及第二用户的标识(如：第二用户的账户名)。

步骤S207：接收并使用所述服务器反馈的所述第二用户的通讯数据，其中，所述第二用户的通讯数据由所述服务器与所述第二用户进行通信连接后获得。

在本说明书实施例中，第一用户与可恢复联系人之间的聊天记录并非存储在服务器上，而是存储在可恢复联系人所使用的终端上。基于此，服务器可以与第二用户进行通信，由此获得第二用户存储的通讯数据，并发送给第一用户。从而，第一用户便可以在接收到了与第二用户之间的通讯数据后，恢复聊天记录。

通过以上内容可知，对于需要恢复通讯数据的第一用户而言，可以向服务器发出请求，并获得由服务器提供的可恢复联系人列表。在此基础上，第一用户可以根据实际应用的需要，根据可恢复联系人列表确定一个或多个第二用户，以便恢复第一用户与第二用户之间的通讯数据，这样一来，服务器便可以获取由第二用户所存储的通讯数据，最后反馈给第一用户，以恢复与第二用户之间的通讯数据。

也就是说，当第一用户使用没有聊天记录的终端进行即时通讯时，第一用户可主动选择所需恢复的联系人通讯数据，同时对于部分联系人的通讯数据可以不选择进行恢复，有利于提升用户体验，并且能够在一定程度减少通信流量的消耗。

对于前述如图2所示的方法，其执行主体通常可以是运行在终端上的即时通讯应用的客户端，当然，在某些情况下也可以是第一用户所使用的终端本身，这里并不作具体限定。在本说明书实施例中，主要以执行主体是即时通讯应用客户端的场景进行说明，应理解，其具体执行方法步骤，同样适用于执行主体为终端自身的场景。

此外，上述方法中当第一用户接收到服务器所反馈的可恢复联系人列表后，可由IM客户端自动选择相应的第二用户，也可由用户主动选择相应的第二用户。

具体地，作为本说明书中一种可行的实施方式，IM客户端中设置有相应的规则，用以在接收到可恢复联系人列表后，自行选择一个或多个可恢复联系人作为第二用户。

这里所设置的规则可以是：非4G网络/WiFi网络的情况下，仅将用户当前打开的聊天窗口所对应的可恢复联系人，确定为第二用户(此时并不选择可恢复联系人列表中的其他可恢复联系人)。

设置的规则还可以是：在4G网络/WiFi网络的情况下，将可恢复联系人列表中的所有可恢复联系人均作为第二用户。

或者，设置的规则又可以是：按照社交亲密度(主要指在以往的即时通讯过程中，相互发消息的次数)，将社交亲密度超过设定阈值的可恢复联系人作为第二用户。

当然，以上规则具体可以根据实际应用的需要进行设置，以上仅仅是一种说明举例，并不应构成对本申请的限定。

作为本说明书中另一种可行的实施方式，IM客户端在接收到可恢复联系人列表后，可将该列表直接展示给用户，并接收用户在该列表中针对一个或多个可恢复联系人的选择操作，将用户所选择的可恢复联系人作为第二用户。

此后，第一用户会向服务器发出通知，以便获得由服务器提供的通讯数据。在一种实际应用场景下，第一用户通常可以逐个将所需进行通讯数据恢复的第二用户的标识信息发送给服务器。如果服务器未能获取到某个第二用户的通讯数据，则第一用户会将下一个第二用户的标识信息发送给服务器。以此类推，直至遍历所有的第二用户。

以上是基于第一用户侧的描述说明，而在服务端侧，本说明书实施例中提供一种通讯数据的恢复方法，如图3所述，具体包括以下步骤：

步骤S301：接收由第一用户发出的通讯数据恢复请求。

通讯数据恢复请求的发送过程可以参考前述内容，这里不再过多赘述。

步骤S303：根据所述通讯数据恢复请求，将预先记录的、该第一用户的可恢复联系人列表发送给所述第一用户。其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人。

在本说明书实施例中，所述的可恢复联系人列表，可由服务器生成。在一些实施方式中，服务器可将第一用户通讯录中的全部联系人，均作为可恢复联系人，生成可恢复联系人列表。当然，在另一些实施方式中，出于成本、数据量等方面的考虑，可以只将第一用户通讯录中的一部分联系人，作为可恢复联系人，生成可恢复联系人列表。

对于以上两种方式而言，至于采用何种方式，具体将根据实际应用的需要所确定，这里并不构成对本申请的限定。

可以理解的是，为了尽可能地减少服务器所存储的通讯数据，由服务器所生成的可恢复联系人列表中一般仅包含联系人的ID或账户名等标识性数据，而非通讯数据。

结合上述S301及S303两个步骤可知，当第一用户发起恢复通讯数据的请求后，服务器并非直接将通讯数据发送给第一用户以便其进行恢复，而是将可恢复联系人列表发送给第一用户，使得第一用户根据可恢复联系人列表选择需要恢复的联系人聊天记录。

步骤S305：确定所述第一用户所选择的可恢复联系人，作为第二用户。

如前所述，第一用户在接收到可恢复联系人列表后，可以在该列表中选定一个或多个可恢复联系人，那么，服务器便可以基于第一用户的选择，确定第一用户所需恢复通讯数据的用户(即，第二用户)。

步骤S307：获取所述可恢复联系人所存储的通讯数据，发送给所述第一用户。

在本说明书实施例中，服务器自身并不存储(或者尽可能不存储)用户之间的通讯数据，该通讯数据通常存储在用户所使用的终端中，因此，一旦服务器确定了第一用户所选择的、需要进行通讯数据恢复的第二用户，则该服务器便可以通过与第二用户之间的通信连接，获取第二用户存储的通讯数据。之后再将获取的通讯数据发送给第一用户。

当然，服务器获取第二用户所存储的通讯数据时，既可以根据第一用户逐个发送的第二用户标识信息向第二用户获取通讯数据，也可以根据第一用的请求，并发式地同时获取各个第二用户的通讯数据。

对于如图3所示的方法，需要说明的是，对于可恢复联系人列表的生成过程，可以为：服务器获取第一用户的全部联系人，在获取到的全部联系人中，确定指定数量的联系人，并获取确定出的联系人的标识信息，根据所述标识信息生成所述可恢复联系人列表。其中，所述标识信息至少包括：联系人ID或账户名。

以上内容中所提及的全部联系人，包括：所述第一用户的好友，第一用户所加入到的社交群组中的联系人，以及与所述第一用户并未建立好友关系的联系人。

一般来说，服务器可以根据第一用户与各个联系人之间的社交亲密度，筛选出部分联系人，以便生成前述的可恢复联系人列表。如果不考虑成本及数据量，也可以将第一用户的全部联系人生成可恢复联系人列表。

至此，本说明书实施例中的上述方法的实际执行过程可如图4所示，具体包括以下步骤：

步骤S401：第一用户向服务器发送通讯数据恢复请求。

步骤S403：服务器将预先生成的、该第一用户的可恢复联系人列表发送给所述第一用户。

其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人。

步骤S405：第一用户基于所述可恢复联系人列表，确定一个或多个第二用户，并通知所述服务器。

步骤S407：服务器根据第一用户所选定的第二用户，监测第二用户是否在线。

步骤S409：当第二用户在线时，服务器获取第二用户存储的该第二用户与第一用户之间的通讯数据。

步骤S411：服务器将获取的通讯数据发送给第一用户。

步骤S413：第一用户使用服务器发送的通讯数据进行恢复。

综上所述，用户间的即时通讯数据分布式地存储在各个用户所使用的终端设备中，利用终端存储空间取代了服务端的集中式存储，极大降低了服务端的存储成本。在恢复通讯数据时，用户可以请求服务端从其他用户的终端本地获取到相应的通讯数据，并转发给发出请求的用户，从而实现通讯数据的恢复。

当然，在一些特殊的实际应用场景中，第一用户和第二用户之间可以采用点对点的方式直接传输通讯数据，而无需服务端中转。

以上为本说明书实施例提供的通讯数据的恢复方法，基于同样的思路，本说明书实施例还提供相应的通讯数据的恢复装置。

具体而言，在第一用户侧，本说明书实施例中所提供的通讯数据的恢复装置如图5所示，所述装置包括：

请求发送模块501，向服务器发送通讯数据恢复请求；

列表接收模块502，接收服务器反馈的可恢复联系人列表，其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

用户确定模块503，根据所述可恢复联系人列表确定一个或多个第二用户，并通知所述服务器；

数据恢复模块504，接收并使用所述服务器反馈的所述第二用户的通讯数据，其中，所述第二用户的通讯数据由所述服务器与所述第二用户进行通信连接后获得。

进一步地，所述用户确定模块503，确定第一用户所使用网络的网络状态，根据所述网络状态以及预设的恢复规则，在所述可恢复联系人列表中，确定一个或多个联系人作为第二用户。

所述用户确定模块503，接收针对所述可恢复联系人列表中的可恢复联系人的选择操作，根据所述选择操作，确定一个或多个联系人作为第二用户。

所述可恢复联系人列表中包含可恢复联系人的标识信息，基于此，所述用户确定模块503，确定一个或多个所述标识信息，将所述标识信息对应的联系人作为第二用户。

其中，所述标识信息至少包括：联系人ID或账户名。

所述用户确定模块503，根据确定出的第二用户，逐个向所述服务器发送通讯数据的获取请求。

所述用户确定模块503，若未接收到所述服务器反馈的通讯数据，则向所述服务器发送下一第二用户的通讯数据的获取请求，直到遍历所有的第二用户为止。

基于图5所示的装置，在实际应用中可由实体的设备(如：终端设备)所实现，具体而言，该设备包括：处理器、存储器，其中，

所述存储器，存储通讯数据的恢复程序；

所述处理器，调用存储器中存储的通讯数据的恢复程序，并执行：

向服务器发送通讯数据恢复请求；

接收服务器反馈的可恢复联系人列表，其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

根据所述可恢复联系人列表确定一个或多个第二用户，并通知所述服务器；

接收并使用所述服务器反馈的所述第二用户的通讯数据，其中，所述第二用户的通讯数据由所述服务器与所述第二用户进行通信连接后获得。

在服务器侧，本说明书实施例还提供一种通讯数据的恢复装置，如图6所示，所述装置包括：

请求接收模块601，接收由第一用户发出的通讯数据恢复请求；

列表反馈模块602，根据所述通讯数据恢复请求，将预先记录的、该第一用户的可恢复联系人列表发送给所述第一用户；其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

选择处理模块603，确定所述第一用户所选择的可恢复联系人，作为第二用户；

数据处理模块604，获取所述第二用户所存储的通讯数据，发送给所述第一用户。

进一步地，所述装置还包括：列表生成模块605，获取第一用户的全部联系人，在获取到的全部联系人中，确定指定数量的联系人，并获取确定出的联系人的标识信息，根据所述标识信息生成所述可恢复联系人列表；

其中，所述全部联系人，包括：所述第一用户的好友，第一用户所加入到的社交群组中的联系人，以及与所述第一用户并未建立好友关系的联系人。

所述标识信息至少包括：联系人ID或账户名。

所述列表生成模块605，确定在设定历史时间段内第一用户与各联系人之间的交互亲密度，根据所述交互亲密度，在获取到的全部联系人中，确定所述交互亲密度超过设定阈值的联系人。

所述列表生成模块605，将获取到的全部联系人均确定为生成可恢复联系人列表所需的联系人。

所述数据处理模块604，确定所述第二用户的在线状态，当确定所述第二用户在线时，建立与所述第二用户的通信连接，并获取所述第二用户存储的通讯数据。

所述装置还包括：通知模块606，若服务器并未获取到所述第二用户存储的通讯数据，则向所述第一用户返回失败通知。

基于图6所示的装置，在实际应用中可由实体的设备(如：终端设备/服务器)所实现，具体而言，该设备包括：处理器、存储器，其中，

所述存储器，存储通讯数据的恢复程序；

所述处理器，调用存储器中存储的通讯数据的恢复程序，并执行：

接收由第一用户发出的通讯数据恢复请求；

根据所述通讯数据恢复请求，将预先记录的、该第一用户的可恢复联系人列表发送给所述第一用户；其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

确定所述第一用户所选择的可恢复联系人，作为第二用户；

获取所述第二用户所存储的通讯数据，发送给所述第一用户。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和介质类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可，这里就不再一一赘述。

至此，已经对本主题的特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作可以按照不同的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序，以实现期望的结果。在某些实施方式中，多任务处理和并行处理可以是有利的。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (21)

1.一种通讯数据的恢复方法，包括：

接收第一用户的通讯数据恢复请求；所述通讯数据恢复请求中至少携带有所述第一用户的用户信息；

根据所述通讯数据恢复请求，将所述第一用户的可恢复联系人列表发送给所述第一用户；其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

确定所述第一用户所选择的可恢复联系人，作为第二用户；

获取所述第二用户所存储的通讯数据，发送给所述第一用户。

2.根据权利要求1所述的方法，所述通讯数据恢复请求是所述第一用户的终端检测到本地未存储有聊天记录后而自动生成的请求。

3.根据权利要求1所述的方法，所述全部联系人，包括：所述第一用户的好友，第一用户所加入到的社交群组中的联系人，以及与所述第一用户并未建立好友关系的联系人；所述可恢复联系人列表是基于服务器根据所述第一用户与各个联系人之间的社交亲密度筛选出的部分联系人而生成的；所述可恢复联系人列表中包括联系人的ID或账户名；所述第一用户与所述可恢复联系人之间的通讯数据存储在所述可恢复联系人所使用的终端上。

4.根据权利要求1所述的方法，所述第二用户与所述第一用户之间的社交亲密度超过设定阈值。

5.根据权利要求1所述的方法，所述第二用户的通讯数据由所述服务器与所述第二用户进行通信连接后获得。

6.根据权利要求1所述的方法，所述确定所述第一用户所选择的可恢复联系人，作为第二用户，具体包括：

将所述第一用户当前打开的聊天窗口所对应的可恢复联系人确定为第二用户；

或者，确定社交亲密度，并将所述社交亲密度超过设定阈值的可恢复联系人确定为第二用户。

7.如权利要求1所述的方法，通过以下方法生成所述可恢复联系人列表：

服务器获取第一用户的全部联系人；

在获取到的全部联系人中，确定指定数量的联系人，并获取确定出的联系人的标识信息；

根据所述标识信息生成所述可恢复联系人列表；

所述标识信息至少包括：联系人ID或账户名。

8.如权利要求7所述的方法，在获取到的全部联系人中，确定指定数量的联系人，具体包括：

确定在设定历史时间段内第一用户与各联系人之间的交互亲密度；

根据所述交互亲密度，在获取到的全部联系人中，确定所述交互亲密度超过设定阈值的联系人。

9.如权利要求7所述的方法，在获取到的全部联系人中，确定指定数量的联系人，具体包括：

将获取到的全部联系人均确定为生成可恢复联系人列表所需的联系人。

10.如权利要求1所述的方法，获取所述第二用户所存储的通讯数据，具体包括：

确定所述第二用户的在线状态；

当确定所述第二用户在线时，建立与所述第二用户的通信连接，并获取所述第二用户存储的通讯数据。

11.如权利要求1所述的方法，所述方法还包括：

若服务器并未获取到所述第二用户存储的通讯数据，则向所述第一用户返回失败通知。

12.一种通讯数据的恢复方法，包括：

向服务器发送通讯数据恢复请求；所述通讯数据恢复请求中至少携带有所述第一用户的用户信息；

接收服务器反馈的可恢复联系人列表，其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

根据所述可恢复联系人列表确定一个或多个第二用户；

接收并使用所述服务器反馈的所述第二用户的通讯数据。

13.如权利要求12所述的方法，根据所述可恢复联系人列表确定一个或多个第二用户，具体包括：

确定第一用户所使用网络的网络状态；

根据所述网络状态以及预设的恢复规则，在所述可恢复联系人列表中，确定一个或多个联系人作为第二用户。

14.如权利要求12所述的方法，根据所述可恢复联系人列表确定一个或多个第二用户，具体包括：

接收针对所述可恢复联系人列表中的可恢复联系人的选择操作；

根据所述选择操作，确定一个或多个联系人作为第二用户。

15.如权利要求13或14所述的方法，所述可恢复联系人列表中包含可恢复联系人的标识信息；

确定一个或多个联系人作为第二用户，具体包括：

确定一个或多个所述标识信息，将所述标识信息对应的联系人作为第二用户；

其中，所述标识信息至少包括：联系人ID或账户名。

16.如权利要求15所述的方法，通知所述服务器，具体包括：

根据确定出的第二用户，逐个向所述服务器发送通讯数据的获取请求。

17.如权利要求16所述的方法，所述方法还包括：

若未接收到所述服务器反馈的通讯数据，则向所述服务器发送下一第二用户的通讯数据的获取请求，直到遍历所有的第二用户为止。

18.一种通讯数据的恢复装置，包括：

请求接收模块，接收第一用户的通讯数据恢复请求；所述通讯数据恢复请求中至少携带有所述第一用户的用户信息；列表反馈模块，根据所述通讯数据恢复请求，将所述第一用户的可恢复联系人列表发送给所述第一用户；其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

选择处理模块，确定所述第一用户所选择的可恢复联系人，作为第二用户；

数据处理模块，获取所述第二用户所存储的通讯数据，发送给所述第一用户。

19.一种通讯数据的恢复装置，包括：

请求发送模块，向服务器发送通讯数据恢复请求；所述通讯数据恢复请求中至少携带有所述第一用户的用户信息；

列表接收模块，接收服务器反馈的可恢复联系人列表，其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；用户确定模块，根据所述可恢复联系人列表确定一个或多个第二用户；

数据恢复模块，接收并使用所述服务器反馈的所述第二用户的通讯数据。

20.一种通讯数据的恢复设备，包括：处理器、存储器，其中：

所述存储器，存储通讯数据的恢复程序；

所述处理器，调用存储器中存储的通讯数据的恢复程序，并执行：

接收第一用户的通讯数据恢复请求；所述通讯数据恢复请求中至少携带有所述第一用户的用户信息；

根据所述通讯数据恢复请求，将所述第一用户的可恢复联系人列表发送给所述第一用户；其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；

确定所述第一用户所选择的可恢复联系人，作为第二用户；

获取所述第二用户所存储的通讯数据，发送给所述第一用户；所述第二用户的通讯数据由所述服务器与所述第二用户进行通信连接后获得；

所述确定所述第一用户所选择的可恢复联系人，作为第二用户，具体包括：

将所述第一用户当前打开的聊天窗口所对应的可恢复联系人确定为第二用户；

或者，确定社交亲密度，并将所述社交亲密度超过设定阈值的可恢复联系人确定为第二用户。

21.一种通讯数据的恢复设备，包括：处理器、存储器，其中：

所述存储器，存储通讯数据的恢复程序；

所述处理器，调用存储器中存储的通讯数据的恢复程序，并执行：

向服务器发送通讯数据恢复请求；所述通讯数据恢复请求中至少携带有所述第一用户的用户信息；

接收服务器反馈的可恢复联系人列表，其中，所述可恢复联系人列表中包含第一用户的部分或全部联系人；根据所述可恢复联系人列表确定一个或多个第二用户；

接收并使用所述服务器反馈的所述第二用户的通讯数据。

Images