CN101764851A - 提供在线通讯录回收站的方法和机制 - Google Patents

Abstract

本发明提供在线通讯录回收站的方法和机制。一服务器为注册用户管理有由联系条目形成的通讯录。当注册用户从自己的列表中删除一联系条目，所述服务器不把删除的联系条目即刻删除而是把删除的联系条目存储到一个特制的区域作为一个删除的联系条目，虽然通讯录不再包含所述删除的联系条目，但是注册用户可以从所述特制的区域寻回所述的删除联系条目。一个联系条目的删除可以发生在注册用户用的装置(比如，手机)也可以直接发生在服务器上。

Description

提供在线通讯录回收站的方法和机制

技术领域

本发明涉及通讯领域，尤其涉及来自不同信息源的个人联系信息的同步方法和系统，还涉及让注册用户通过短消息建立私人日志和通过短消息的方法向其他联系人报道自己在做什么或关心什么的机制。在此方法和系统的基础上，还可以实现各种有效的服务包括拼车，电子邮件挂号传递，根据关系类别的电子邀请以及注册用户之间的商品货物交换和买卖。

背景技术

据统计平均每个年轻人大约有四个电子邮件帐号，这些电子邮件帐号可能包括一个工作电子邮件帐号、一个网络提供商(比如中国电信)提供的住宅电子邮件帐号、几个通用网站(比如Yahoo，Hotmail和Gmail)免费电子邮件帐号。每个电子邮件帐号的建立可能有各自不同的目的，所述工作电子邮件帐号可能经常用来与工作上的同事通信，所述住宅电子邮件帐号可能用来与朋友和家人通信，而其它电子邮件帐号可能用于各种非正式的的通信。每个电子邮件帐号都有自己的通讯录(其也可以被称作地址薄)以方便用户在给他人发送电子邮件时不用拼写整个地址。但是，不管用户拥有多少个电子邮件帐号，每个电子邮件帐号的通讯录都是独立管理的。如果一个用户正好由于在外地出差而不能访问工作电子邮件帐号，那么他可以通过其它电子邮件帐号(比如Yahoo邮件)与同事联系，然而前提是他必须记得住这个同事的电子邮件地址。

微软的Outlook和Outlook Express是现在最流行的电子邮件应用软件，它们可以用来接收来自不同电子邮件帐号的电子邮件。如果用一个Outlook或Outlook Express来管理了多个电子邮件帐号，那么它可提供这些电子邮件帐号的一个整合通讯录。然而，所述Outlook或Outlook Express需要在个人电脑上运行，当用户远离所述个人电脑时，访问所述联合通讯录就会非常困难。

同样的，许多人不只拥有一个便携式装置，所述便携式装置包括手机、个人数字助理(PDA)等。在手机上可为用户创建一个通讯录(也可称为地址薄)以记录联系人的电话号码。当有电话打进来后，用户可根据所述手机上的来电显示号码来更新通讯录，而用户需要做的只是输入该来电号码的联系人名字。类似的，PDA上也创建有通讯录，用于记录通过该装置来联系的其他人的联系信息。

这样就出现一个问题，个人联系信息被分散存储在几个装置或帐号上。当一个用户需要通过手机来联系某人时，必须使用平时与这个人联系的手机，否则该用户可能没办法找到这个人的电话号码。同样，如果一个用户需要通过电子邮件来与某人联系时，必须使用平时与这个人联系的电子邮件帐号，否则该用户也可能没办法找到这个人的电子邮件地址，除非该用户记得或打电话给这个人询问。

科技发展使人们可通过不同装置/工具以不同方式来与他人进行联系。然而，从某种角度来说，由于不同装置/工具间缺乏配合协作，科技反而使我们的生活复杂化了。此外，手机常常会丢失，随之丢失的还有手机中的地址薄，这样地址薄中的联系人就有可能再也没法联系到了。因此，亟待提出一种使我们被科技复杂化了的生活变简单的解决方案，以使一个人可以在任何时刻、任何地方都能查询问到个人联系信息，即使某联系人已经更新了联系信息。为进一步方便各联系人之间的通讯，还需要提出一种保证各联系人间实时、安全以及经常通讯的技术方案。

发明内容

本发明所要解决的技术问题是提供在服务器上的一个回收站，用于储存被用户删除的联系人条目。由于用户可以在服务器上或者自己用的装置(比如：手机和)上删除一个或者多个联系人，用回收站来储存这些删除的联系人便于用户恢复可能删除错的联系人。为了达到以上目的，根据本发明的一方面，本发明提供了一种联系信息管理方法，其特征在于，所述方法包括：

一服务器为一个注册用户维护有由联系条目形成的通讯录，每个联系条目记录有所述注册用户的一个联系人的简介，所述简介包括有所述联系人的姓名和联系方式；如果所述联系人也是所述服务器的注册用户，在所述联系人对自己的联系条目做了一个更新后，所述更新立即反映到所有把所述联系人列为自己联系人的通讯录中，

当所述注册用户从自己的列表中删除一联系条目，所述服务器不把要求删除的联系条目删除而是把要求删除的联系条目存储到一个特制的区域作为一个删除的联系条目，虽然所述通讯录不再包含所述删除的联系条目，但是所述注册用户可以从所述特制的区域寻回所述的删除联系条目，但是在所述特制的区域中的所述删除的联系条目不会再得到相应的联系人的更新同时所述相应的联系人也得不到注册用户的任何更新；

接收来自信息源的数据，所述数据包括通讯录中已有的联系条目的部分内容或列表中没有的联系条目的部分内容；

将所述数据并入所述联系条目中，以更新相应联系条目的部分内容或添加新的联系条目；

将更新的联系条目发回所述信息源，此时所述信息源上具有所述联系条目的最新版本，其中所述信息源包括电子邮件应用工具、网络邮箱工具、手机、个人电脑和/或个人数据助理；

所述数据进一步包括从所述通讯录中已经删除的联系条目，所述服务器在收到所述数据后，更新所述通讯录并把已经删除的联系条目存储到所述特制的区域，当所述注册用户需要时，所述已经删除的联系条目可以从所述特制的区域寻回，从而所述通讯录中包括从所述信息源那里已经删除的联系条目；

在与所述信息源下一个同步后，所述信息源又包含了所述已经删除的联系条目，造成所述信息源删除所述删除的联系条目；

所述更新包括电话号码和电子邮件地址的变更，这样所述注册用户可一直与所述联系人保持联系；

所述方法进一步包括：

允许所述注册用户通过电话或服务器发送字数有限的短消息；其中，

将所述短消息公开发布，以至于其他注册用户可对所述短消息进行回复或评论；或将所述短消息保密发布，以至于只有所述注册用户能看到、评论或编辑所述短信；

所述注册用户具有自己的简介，所述注册用户可以设定跟一个联系人的关系层次来决定所述联系人能看到自己多少简介信息；

所述方法进一步包括：

在所述联系条目列表更新或下载至手机上时，自动在联系条目列表中插入一个默认联系条目，所述默认联系条目包括一个电话号码，用户可通过手机法短消息至所述电话号码。

根据本发明的另一方面，本发明提供了一种联系信息管理系统，其特征在于，所述系统包括：

服务器，用来为一个注册用户管理包括多个联系条目的通讯录，每个联系条目记录有所述注册用户的一个联系人的简介，所述简介包括有所述联系人的姓名和联系方式；

储存区域，当所述注册用户删除一联系条目，所述服务器联不把删除的联系条目删除而是把所述删除的联系条目存储到所述储存区域，虽然所述通讯录不再包含所述删除的联系条目，但是用户可以从所述储存区域复原所述删除的联系条目

能获得一些联系条目的部分信息的至少一个信息源，其用来与所述服务器进行同步，通过将来自所述信息源的数据并入所述联系条目中来更新所述联系条目，所述数据包括列表中已有的联系条目的部分内容或列表中没有的联系条目的部分内容；

其中，所述信息源也存储了一份更新的联系条目，此时所述信息源上具有所述联系条目的最新版本，其中所述信息源包括电子邮件应用工具、网络邮箱工具、手机、个人电脑和/或个人数据助理；

所述数据进一步包括从所述通讯录中已经删除的联系条目，所述服务器在收到所述数据后，更新所述通讯录并把已经删除的联系条目存储到所述特制的区域，当所述注册用户需要时，所述已经删除的联系条目可以从所述特制的区域寻回，从而所述通讯录中包括从所述信息源那里已经删除的联系条目.

这样在本发明提出的技术放案中，提供在线通讯录回收站的方法和机制。一服务器为注册用户管理有由联系条目形成的通讯录。当注册用户从自己的列表中删除一联系条目，所述服务器不把删除的联系条目即刻删除而是把删除的联系条目存储到一个特制的区域作为一个删除的联系条目，虽然通讯录不再包含所述删除的联系条目，但是注册用户可以从所述特制的区域寻回所述的删除联系条目。一个联系条目的删除可以发生在注册用户用的装置(比如，手机)也可以直接发生在服务器上。

附图说明

图1A示出了本发明在一个具体实施例中的系统架构；

图1B示出了本发明中个人信息同步的一个具体实施例，其中服务器与四个终端装置进行同步；

图2A示出了本发明中一个具体实施例中的整合来自从不同信息源的部分联系信息的流程或方法；

图2B示出了本发明中一个具体实施例中的装置中的通讯录格式不同于服务器中的通讯录格式的情况，此时将装置中的记录条目的所有数据都传送至服务器上；

图3A示出了一个注册用户在服务器中的通讯录中的联系列表的一个具体实施例；

图3B示出了本发明中一个具体实施例中的服务器接收和发布短消息的流程或方法；

图3C示出了本发明中一个具体实施例中的拼车邀请描述；

图3D示出了本发明中一个具体实施例中的匹配拼车邀请和拼车请求的流程或方法；

图3E示出了本发明中一个具体实施例中的一个拼车示例，其中张三发布了一个拼车请求，李四发布了一个拼车邀请；

图4A示出了本发明中的一个具体实施例中的电子邮件证明传递系统的架构图；

图4B示出了本发明中的一个具体实施例中的一封电子邮件的证明传递的流程或方法；

图5A示出了阻挡来自被删除联系人的电子邮件，短信或电话呼叫的一个示例的架构图；

图5B显示出了保护用户的隐私的一个示例的架构图；和

图5C显示一个可以用于图5B的对应表。

具体实施方式

下面结合附图对本发明的具体实施方式进行说明。

图1A示出本发明在一个具体实施例中的系统架构图。服务器20用来为注册用户管理联系信息列表，其提供的其它服务将在下文描述。数据库30用来存储所述服务器20管理的所述联系信息列表和其它相关数据。一个注册用户的联系信息列表中通常包括一系列的联系人(也可以形象的称之为联系圈)，这样一个联系圈有多个联系人条目。其中的部分或所有联系人也可是服务器20的注册用户。所述联系信息列表中的一个联系人条目记载有该联系人的简介(也可以称之为简档)，所述联系人简介包括该联系人的姓名和联系方式，所述联系方式可以是电子邮件地址、手机号码和/或即时通讯ID等。在本发明中的系统中通过合适的设置(通过同一数据库)，在一个用户更新了其简介内容时，通过所述服务器20将该用户列为联系人的用户可自动接收到所述更新数据，数据更新可在用户知情或不知情的情况下进行。比如，用户可以通过某个击键来需求系统更新他的联系人的任何变更或者系统在一联系人更新了其某些内容(比如电话号码等)告知用户。需要说明的是，除非另有声明外，所述联系信息列表在这里还可被称作通讯录、地址薄、联系列表或联系人列表等；所述联系人可以广义的理解为联系对象，其既可以是真实的人，比如家人或朋友等，也可以是虚拟的人，比如某某公司、某某单位或某联系设备等；所述每个联系人在通讯录中都体现为一个记录条目(也可称之为条目、联系条目或联系人条目等)。

在一个具体实施例中，所述数据库30可以是所述服务器的一部分，也可以是分布于不同电脑装置上，还可以是设置于服务器20的远端。终端装置10、12和14表示可与服务器20通讯的多个装置，这些终端装置包括但不限于接入网络的手机、PDA和电脑。用户可以使用任一终端装置与所述服务器20通讯，进而实现在服务器20上为该用户维持的通讯录的同步、管理和下载。

所述服务器20可用来与注册用户使用的装置通讯，以同步所述装置本地存储的通讯录。如图1B所示，所述注册用户可能使用微软Outlook 102(电子邮件应用软件)来接收与工作相关的电子邮件，使用网络邮箱104(比如，Yahoo的电子邮箱)来接收与个人相关的电子邮件，使用工作手机106来进行与工作相关的电话通讯，使用私人手机108来进行与家人或朋友之间的电话通讯。通过向所述服务器20注册一个帐号110，所述用户可以使每个电子邮件工具或装置102、104、106、108(可以被统称为装置或终端装置)与所述服务器20保持同步。

所述帐号110包括分别来自装置102、104、106和108的联系信息。举例来说，注册用户可能使用任何一个装置102、104、106或108与一个名叫“张三”的联系人进行联系。这样，每个装置102、104、106或108只保存有“张三”的部分联系信息。由于张三可能在其用的邮件设置中输入一些信息，比如Outlook 102可能保存“张三”的部分简介信息。所述部分简介信息可能包括头衔、公司名字、公司地址、公司电子邮件地址、电话和传真号码等。由于所述注册用户可能与张三沟通一些工作以外的事情，所述网络邮箱104可能保存有张三的私人邮件地址。同样的，由于经常用工作手机106与张三沟通工作上的事情，因此在工作手机106上可能记录有张三的工作电话。此外，由于可能用私人手机108接听过张三从家中打来的电话，因此在私人手机108上可能记录有张三的家庭电话。换言之，每个装置102、104、106或108分别保存有张三部分或零碎的联系信息。

每个装置102、104、106或108可以用来与所述服务器保持同步，将包含有部分联系信息的本地通讯录上传至服务器20。所述服务器20整合和处理所有部分联系信息，用户需要时可以加入一些用户输入信息(比如哪里相遇这个联系人，该联系人的教育背景等)以在服务器20上的该注册用户的远端通讯录(相对于装置中的本地通讯录来说，服务器20中的通讯录可被称为远端通讯录)中形成一个关于相应联系人的完整记录条目112。这样的远端通讯录可以下载至任一装置102、104、106或108上以更新或补充本地原始的部分联系信息。

图2A示出了整合来自从不同信息源的部分联系信息的流程或方法200。所述信息源包括但不限于电脑(比如笔记本电脑)、手机(比如GPRS或3G手机)和个人数字助理PDA(比如Blackberry或iPhone)。所述方法200可以实现为一种软件或软硬件的结合。为了便于理解所述方法200，可以结合参考图1A和图1B。

假设用户“张三”已在服务器(比如图1A中的服务器20)上建立了一个帐号，比如用一个电子邮件地址来做使用名。此用户可以利用任何电脑通过数据网络(有线的或无线的)来访问所述服务器以创建他自己的简介。所述简介可包括他的名字、他的其他电子邮件地址、他的即时通讯ID(比如QQ号、MSN号)、他的各种电话号码等。根据需要，所述简介还可包括他的头衔、他的公司名称和地址以及他的公司所能提供的产品/服务。所述简介还可包括他的教育背景(学位、学校和专业)和他的部分或所有联系人感兴趣的相关数据。在一实例中，所述简介还可包括他爱好(比如：乒乓球，电影)和希望得到的商品(比如：小汽车和休假旅行)。

与这个帐号交往的是一系列联系人或记录条目，即张三的联系人。经由所述服务器的连接，张三的记录条目被加到他联系人的联系圈中。同样，他联系人的记录条目也加到张三的联系圈中。这样张三就拥有了自己的不断更新的联系圈。每一个联系人都具有与前述张三帐号的简介相似的简介。所述联系人的简介在开始时可能不完整，但可以随着时间的推移由张三或相应的联系人自己进行更新。张三与所述联系人的简介就逐渐完善。如果张三换了手机并更换了新的电话号码，他不需要去一一打电话给每个联系人，他只需要在其个人简介中用新电话号码替换掉原电话号码，那些将他列为联系人的用户就可以在自己的通讯录中找到张三的新电话号码。实际上将他列为联系人的用户不一定知道张三已经更新了电话号码(因为用数据库来存储全体注册用户的记录条目，一个记录条目中的任何数据域改变都会直接影响到访问所述记录条目的结果)。

当然，如果张三不愿意与其某一联系人保持联系，他可以将这个人从其联系信息列表中删除。这样被删除的联系人将不能得到张三的新电话号码。以下会进一步讲倒被删除的联系人不是从系统中即刻删除。根据一实例，被删除的联系人首先放到回收箱，以便张三也许想寻回被删除的联系人，以便恢复相互联系。本发明的其中一个优点、好处或目的在于所述服务器20使所有用户可以与他们希望联系的人永远保持联系。

根据用户的实际应用，用户自己可以更新通讯录中的某一联系人中的某些简介内容，必须指出，某一联系人或条目中有许多区域(也可称之为数据域，内容栏等，即条目中的某些内容，比如姓氏、名字都可以成为一个区域或内容栏)，不是所有的区域都可以让其他用户改变或更新。比如联系人的注册的电子邮件地址是不可以让别人变更的，但是有许多区域是可以让其他用户填补的。举例来说，对于一个经营通讯设备的联系人，虽然该联系人并没有提供此类信息，所述用户可以将这一信息加入该联系人的简介中，以在将来需要通讯设备时方便用户自己搜索或者跟该联系人联系。

假设是为一个名叫李四的联系人建立的简介。如果李四也是所述服务器的注册用户，所述简介可以由李四自己来更新。在一个实施例中，李四无论何时更新了自己的包括联系方式(比如电话号码的变更)在内的简介，由李四发起的更新则立即反映到张三的通讯录中。由张三编辑的其通讯录中的关于李四内容可以由李四更新。在一实例中，李四提供的信息有优先权，将会取代原来内容。然而，如果李四不在某内容栏填写任何内容，那么由张三编辑的这个区域内容则保持原样。

所述注册用户“张三”可能有几个装置与一联系人联系。如上所述，一些装置中仅记录电子邮件地址，其它则仅记录电话号码。请参阅图2A所示，在步骤202产生一个同步请求。所述同步请求可以由所述每个装置自动或手动产生，也可以由服务器自动或手动产生。当使用一个装置时，所述装置可以根据身份验证信息(比如用户名和密码)与服务器建立通讯，并进一步检测所述服务器上是否有更新。同样的，如果用户在某一时刻更新了一装置上的本地通讯录，当用户利用该装置登录至所述服务器后，所述用户可以使服务器与该装置保持同步。一般只有在互连网可用时才执行所述同步请求。相应的，在步骤204需要检测所述是否有互连网络。

假设互联网可用，所述方法200转入步骤206去获取本地时间。所述本地时间可根据收到的数据获得，所述本地时间是所述收到的数据的创建或更新时间，所述收到的数据就是指通讯录的各记录条目。在比较收到的数据和已经存在服务器上的数据时，所述本地时间用于确定哪些数据是最新的。

在步骤208中，将所述收到的数据的本地时间转换为标准时间(比如格林威治标准时间)。由于地球上有那么多时区，只有采用同样时间标准来确定数据的新旧才更加准确、有效。举例来说，一位商人打算从北京到旧金山去旅行，离开北京机场前的北京时间是1月1日上午11点，他将其PDA与服务器同步了一次以更新一个联系人的电子邮件地址，他到达旧金山机场后，他接收到同一联系人的一个更新的电子邮件地址。假设旧金山的当地时间比北京时间靠后15个小时，他到达旧金山机场的时间为太平洋时间1月1日上午8点半。当都以格林威治标准时间为参考时，所述服务器会断定所述第二次的更新数据事实上是最新的。而如果不进行时间转换，所述服务器则可能得出相反的错误结论。需要注意的是，一些装置可能已经使用格林威治标准时间来存储各种记录，此时步骤206的作用则变成认证所述本地时间是格林威治标准时间，步骤208则不需要了。

在步骤210中，比较所述收到的记录条目与已有的记录条目以判断如何更新。当一个收到的记录条目与所述已存在的联系列表中的对应记录条目相同或相似时，所述方法200转入步骤212执行合并。举例来说，一个接收到的记录条目的英语名字为“Mike Doe”，而已存在的联系列表中的一个记录条目的名字为“M.Doe”，可以执行一验证步骤(未示出)以保证这两个记录条目对应同一个联系人。所述验证步骤在一个示例中可以是验证简介中的其他信息，比如已存在的联系列表中的对应记录条目中的电子邮件地址是否与收到的记录条目的电子邮件地址相同，也可以验证其它数据(比如电话号码)来验证两个记录条目是否对应同一个联系人。如果验证步骤结论是两个记录条目对应同一个联系人，这两个记录条目合并。所述方法200从步骤212转入步骤216以更新整个联系列表。

当接收到的记录条目与已存在的联系列表中的任何一个都不相同或相似时，这意味着所述记录条目对应一个新的联系人。所述方法200进入步骤214以在联系列表中增加一个新记录条目。同步请求的结果是：用户用的装置和服务器都拥有了注册用户的通讯录的最新版本。张三无论何时需要查找一个联系人的联系信息，他都可以登录到服务器上找到他想要的，他总是能得到通讯录的最新版本。同样的，张三也可以使用与服务器同步的各个装置，所述装置可以从服务器上下载完整的联系列表或联系列表的更新部分。张三从所述装置中可以获得其需要的联系人的最新联系方式。

据统计将近60％的手机用户每年都要更换一次手机(比如，手机更新，错过手机)。在有些地区(如美国)有一些手机标准并不支持SIM卡。在换了一个没有SIM卡的手机后，除非付费给经销商以请求其将旧手机中的电话号码导入新手机中(有时也可能由于接口问题而不能实现)，否则旧手机中的所有电话号码都会丢失。许多GSM手机支持可存储电话号码的SIM卡，然而在手机丢失后所有的电话号码也随之丢失。这样，许多人就可能由于丢去了电话号码而与他们的同事或朋友永远失去联系。在本发明中，用户只需要在新手机上通过GPRS、3G或其它无线网络登所述服务器上的帐号。在建立了通讯后，他/她的新手机就可以从服务器上下载最新的联系列表。从一个角度来说，本发明解决了联系列表因手机更换，丢失或坏掉而丢失联系信息的问题。

图2B示出了装置中的本地通讯录格式不同于服务器上的远端通讯录格式的情况。一个装置中的本地通讯录的记录条目与另一个装置中的本地通讯录的记录条目可能具有不同内容栏。举例来说，微软Outlook具有经理姓名和助手姓名的内容栏，而微软Outlook Express则没有上述内容栏，但却有网络电话号码等这些Outlook没有的内容栏。除了来自两个不同装置的相同记录条目在内容栏不同外，服务器中的记录条目的内容栏也可能与装置中的相同记录条目的内容栏有所不同。

如图2B所示的一个实施例中，多个装置具有多个记录条目格式220。一个对应或映射表222用来在一个装置的记录条目格式220与服务器的记录条目格式之间建立桥梁。在执行同步程序时，执行映射程序以将所述记录条目格式220侧的数据映射到服务器中定义的相应内容栏上。通常，所述服务器的记录条目的内容栏包括比如名字、姓氏、电子邮件地址等基本内容栏。这些基本内容栏226是可显示的，它们中的大部分是可编辑的或可更新的。对于服务器不需要的来自装置的那些额外内容栏，可以用服务器中的隐藏内容栏228来存储。这些隐藏内容栏228在服务器上是不能看到的或用户不能编辑的。

举例来说，一个Outlook装置具有两个内容栏“经理姓名”和“助手姓名”，它们在服务器的对应记录条目中是不使用的。当所述装置第一次与服务器同步时，Outlook的记录条目中的所有数据都被传送至服务器中，其中只有所述基本内容栏中的数据被加载或更新至服务器的相应记录条目中，其它内容栏中的数据，比如“经理姓名”和“助手姓名”被保存在隐藏内容栏内。将所述装置中的一个记录条目中的所有数据都进行传输的一个好处在于可使同步的实现比较简单，这样在执行同步程序时就不需要从不同的装置内挑选不同的数据。同样的，当服务器中的一个记录条目的更新需要同步到本地装置的相应记录条目时，该联系人的整个记录条目(包括隐藏内容栏中的数据，)都被传送至本地装置上用来取代过时的记录条目。在另一个不同的实施例中，可以只传送更新数据以更新对应的记录条目。

图3A示出了一个注册用户在服务器中的通讯录中的联系列表300的一个示例。所述联系列表300显示了三个记录条目或联系人，每个记录条目或联系人包括一个照片或卡通图片302、联系人的简要说明304、状态描述306、关系分类308、用于个人事务或服务器服务的访问图标310、312、314，和318。必须指出图3A只是一个例子，任何有这个方面技术背景的人阅读本发明文件，可以做各种不同的修改，引导出各种各样的版本，但是都可以包含本发明的某些或全部的特性。所以图3A中的各种安排位置，比如图标310、312、314，和318，按照需要可以随便安置。同样简要说明304、状态描述306、关系分类308的内容可以做相应的改变。

有些用户不愿上传个人相片，由此可以用一个卡通图片。为了使卡通图片能反映一个联系人的性别，在一个实例中，卡通图片的加入是取决于用户的性别(假定用户愿意提供性别，如果不提供，加入的卡通图片可以是一个没有性别的人影)。如果是男的，加入到图片302就是一个男性卡通图。如果是女的，加入到图片302就是一个女性卡通图。当然，如果用户是一个未成年的，小孩的卡通图也可以加入。

点击所述照片或卡通图302，简要说明304的姓名或其他地点，将会显示出该联系人的包括所有其它信息的简介，注册用户可以编辑部分或全部所述简介。所述状态描述306用来让该联系人告诉其他人自己正在干什么或关心什么，这样系统提供了一种机制可以让该联系人发起一个简要主题以供他人评论或跟贴。在一个实施例中，可以用手机的短消息来填写所述状态描述306。所述服务器为所有注册用户提供一个号码，所述注册用户可以通过这个号码发送短消息给服务器。服务器可以通过注册的手机号码来对他们进行身份验证，身份验证通过后服务器才发布他们的短消息。

在一个实施例中，为了方便用户发送这样的短信，当一个用户与服务器达成协议后，将一个风格或格式与联系人相似的记录条目316自动加入通讯录或联系列表中。所述记录条目316包括一个表示服务器(比如www.mingoe.com)提供服务的图标，所述记录条目316可以用服务器的名称来命名。另外，可以在所述记录条目316的名称后加入一句标语。在一个实施例中，当这样的记录条目同步到手机中后，所述记录条目显示为一个联系人，用户很容易就能浏览到该联系人并点击它以发送短信。这个实施例说明本发明的系统可以任何时候根据需要添加记录条目来方便用户并能更新记录条目内的信息。

图3B显示了接收和发布短消息的流程或方法320。所述方法320可以实现为一种软件或软硬件的结合。在一个实施例中，在本发明的系统中提供有一个短信调制解调器，所述短信调制解调器有一个电话号码，所述短信调制解调器可以通过移动通讯基础设置接收或发送信息。所述短信调节解调器与服务器连接以将收到的短消息以及相应的电话号码传送到服务器，这样服务器就接收到了发自所述电话号码的短消息。在另一个实施例中，本发明的系统直接与移动通讯服务商合作(比如，美国的AT&T和中国移动)，用户发出的短消息可以直接从移动通讯服务商通过一个渠道(比如互联网)接入本发明的系统。

在步骤322，所述方法320检测是否收到短消息，并只有在收到短消息后才继续向下进行。在步骤324，所述服务器确定这个短消息是否是来自注册用户的。在具体实现时，所述服务器可以接收非注册用户的短消息，也可以不接收非注册用户的短消息。在一个实施例中，在接收到短消息后，可在数据库中查找发出所述短消息的电话号码以判断所述短消息是否是注册用户发来的。如果没有找到对应的注册用户，则将收到的短消息丢弃或者建议非注册用户上服务器注册，之后所述方法320返回步骤322等待下一条短消息。在另一个实施中，所述发送者可以预先设置何人可以得到和阅读他的私人日志。

现在假设收到的短消息确实是来自注册用户，所述方法320将进入步骤326去判断所述收到的短消息是作为私人日志的还是公开发布的。假设所述收到的短消息是作为公开发布的，所述方法320转入步骤328，根据电话号码提取发送者的身份识别信息ID(Identifier)，所述身份识别信息可以是其他人识别该用户的姓氏、名字或昵称。在步骤330，公开发布所述短消息并可以允许他人对该短消息进行评论或跟贴。举例来说，一个注册用户到达了北京，发送一条公开发布的短消息“我到北京了，将会在这里逗留6天”到服务器。假设这个注册用户在北京有一些联系人，在公开发布了这样的短消息后，在北京的这些联系人知道所述注册用户在北京后可能会与他联系，还可以通过手机或服务器发短消息评论说“欢迎到北京来”。随后，所述方法320转入步骤332，更新所述用户的记录内容，尤其是让所述用户知道他的短消息有多少评论或跟贴，所述用户还可以对所述评论进行再次评论或跟贴。另外根据用户的短消息发表来源，每条短消息的公布可以显示其来源，比如“来自手机”，“手机发表”或“网络发表”

在步骤326，当判定所述短消息是私人日志用途时，所述方法320进入334步骤。本发明的一个特点、优点或目的在于允许注册用户利用短消息发送私人日志。举例来说，一个用户旅行到某一个地方，可能希望写下他所看到的或想到的，此时使用记事本和笔记本电脑可能都不是很方便，所述用户可以通过手机轻松的编写短消息并将其发送到他的私人日志中。利用手机发送短消息给自己还可有其他私人用途，比如设立备忘录/提醒录和记录旅行路线等等。当接收的短消息是私人日志用途时，在步骤334，所述短消息将被作为该发送者的私人日志(其他联系人看不到)。之后，所述发送者可能会看到一系列具有时间戳的短消息，还可能进一步对其中某条短消息进行评论或批注，甚至可以输出到其他文档文件修改。所述方法320进入步骤332去更新这个用户的记录内容，尤其是可以为该用户显示他自己发了多少条短消息并做了多少评论或批注。

请再次参考图3A，一个联系人“李四”被分为商业联系人和同学联系人，这样的关系等级分类用于定义该联系人可以看到的用户的简介中的哪些信息。在一个实施例中，用户可以在所述服务器上设置其与各联系人的关系等级。所述用户可以让相应的联系人看到他的部分或全部简介信息，也可以不让相应的联系人看到任何其他简介信息。在一实施例中，一些定为“秘友”关系等级的联系人只能看到用户简介中的姓名和电话号码信息。另一些定为“普通”或“商业”关系等级的联系人可能能看到用户简介中的所有信息。

在一个实施例中，所述系统提供事先定义了的几个关系等级，包括普通、商业、同学、家人和秘友。其中，普通联系人可能可以看到用户简介的大部分信息以便发展和利用各种机会，而秘友(比如异性朋友)联系人只能看到用户简介中的部分信息以给此注册用户必要的个人隐私。在另一个实施例中，所述系统允许注册用户为他自己的关系等级命名。举例来说，一个用户可能定义了一个“大学”关系，归为“大学”关系中的联系人可以看到该用户简介中的特定部分的所有细节，比如教育背景和大学中值得纪念的活动等。对于用户来说，本发明的其中一个优点在于这样的分类有助于用户对自己联系人进行相应的管理，并且各类联系人将看到自己的简介中的不同内容。在一个实施例中，利用关系等级可以统一给联系圈内的联系人发出电子邀请来参加某个活动。这样，用户不需要一一通知想邀请的联系人，而只需要确定需要向哪个关系级别的联系人圈发送电子邀请。举例来说，张三打算开一个生日宴会，并且只希望家庭成员参加，他需要做的就是给“家人”组的所有联系人发送电子邀请。

再次参考图3A，所述图标310表示联系人“李四”发出了一个拼车邀请，“李四”的所有联系人都可能看到这个拼车邀请。在一个实施例中，点击所述图标310后就可以看到一个如图3C所示的拼车描述340。所述拼车描述显示李四给她的联系人发出了在上下班高峰时间的一个拼车邀请。如图3C所示，所述拼车描述340包括她的车况信息、路线信息和拼车时间。所述拼车描述340只有李四的联系人能看到，这样李四就可以与自己认识的人一起拼车，能与一个认识的人拼车当然是好的选择。

在一个实施例中，一个类似图标(未示出)可以表示一个拼车请求，点击所述图标将被链接到一个拼车请求描述，所述拼车请求描述包括拼车时间和拼车路线。所有联系人不但可以看到用户发布的拼车邀请/请求，还可以看到该发布用户的部分或全部简介信息，这样所述服务器提供了一个平台，让愿意拼车的用户在这个平台上快速、安全的找到合适的拼车人选。

在另一个实施例中，所述服务器基于注册用户发布的拼车信息进行拼车邀请和拼车请求的匹配。图3D示出了匹配拼车邀请和拼车请求的流程或方法350。所述方法350可以实现为一种软件或软硬件的结合。在步骤352有拼车邀请和在步骤354有拼车请求的情况下才启动所述方法350。在步骤356，所述方法350判断所述拼车请求和拼车邀请是否仅针对联系人。一些注册用户更希望与认识的人拼车，如果是这样的话，服务器仅允许在相互的联系人间匹配。在一些情况下，仅在联系人间匹配拼车请求和拼车邀请成功率会很低。

图3E示出了一个拼车示例，其中张三发布了一个拼车请求，李四发布了一个拼车邀请。李四的联系人中并没有人对她的拼车邀请感兴趣或符合她的拼车邀请。同样，张三的联系人中也没有人对他的拼车请求感兴趣或符合他的拼车请求。两者都愿意在各自的联系圈372、374之外进行匹配。之后所述方法350进入步骤358，服务器扫描所有的发布的拼车邀请/请求并进行匹配。当张三的拼车请求与李四的拼车邀请可以在多个关键词上匹配时，所述方法350进入步骤360，所述服务器发送给双方相互的链接，让对方可以看到自己的部分或全部简介。如果张三和李四都感觉比较满意，他们可以与对方通讯，并通过邀请将对方加入自己的联系圈372、374。如果张三和李四都感觉不满意，那么系统将继续为张三和李四进行拼车匹配。

另一个图标312表示这个联系人有一些东西出售或交换。作为为注册用户提供的一种服务，所述服务器可以提供一个平台让用户在联系圈内或所有注册用户间出售或交换东西。当需要交换一些东西时，最好与认识的人进行交换。当可以与不认识的人进行东西交换时，服务器还可以在所有注册用户间进行搜索匹配。

另外一个图标314表示为注册用户保留的系统信息，所述信息包括通过服务器跟踪的电子邮件的回执。由于各种原因(比如网络崩溃)，发出去的电子邮件可能到达不了目的地。有时即使一封电子邮件确实已被送到了接收者处，但仍不能据此主张说所述电子邮件已经被收到，接收者可以说没有收到过，电子邮件的发送者并没有办法去考证。

图4A示出了电子邮件挂号或证明传递系统400的一个示例的架构图。在现有技术中，从一终端装置402发出的电子邮件是由电子邮件服务器(未示出)转发至另一个终端装置的。与现有技术不同的是，在电子邮件的传递路径中增加有图1A所示的服务器20，所述邮件服务器仍然存在于电子邮件的传递路径中。如下文所述，所述服务器20可提供一封电子邮件从发送者(比如，终端装置402)到接收者(比如，终端装置404)的证明传递。

所述终端装置402包括客户端模块406和通讯录408。假设所述终端装置402上运行有电子邮件工具，比如微软Outlook。所述客户端模块406可以是一个插件模块，并在Outlook运行时同时运行。所述电子邮件工具包括有通讯录408，所述通讯录408定期通过客户端模块406与所述服务器20进行同步。所述终端装置404包括与终端装置402类似的部分。

在一个实施例中，在同步程序时，所述客户端模块406或410提取其内的本地通讯录的更新数据或所有数据，并将它们发送到服务器20，同时接收来自服务器20的远端通讯录的更新数据或所有数据。所述服务器20包括联系信息数据库414、回执数据库416和电子邮件处理器418。

在操作过程中，当一个终端装置402的用户决定发起一封发送至所述终端装置404的电子邮件的证明传递时，所述用户可以点击一个可激活客户端模块406中的一个电子邮件证明传递功能(比如通过一个图标)，这样所述电子邮件将被封装后传送到服务器20，而不是直接通过电子邮件服务器传送到终端装置404。正常电子邮件的传递是直接通过电子邮件服务器传送到终端装置404。由于所述电子邮件被封装后改道，这样所述电子邮件通过电子邮件服务器被传送至所述终端装置404前，还需要所述服务器20对所述电子邮件进行登记。

当所述电子邮件最终到了所述终端装置404后，所述客户端模块410将会记录一个或多个下述参数：所述电子邮件的送达时间、接收所述电子邮件的终端装置404的IP地址和所述电子邮件的阅读时间。其它记录参数可包括电子邮件的数据量及打开所述电子邮件的应用软件等。这些传递证明可以在特定时间或下一次同步时是被传输至服务器20。在一个实施例中，可将所述传递证明存储为系统消息，所述发送者可在任何时候提取所述传递证明以察看所述电子邮件的接收状态。

图4B示出了一封电子邮件的挂号或证明传递的流程或方法430。所述方法可以实现为一种软件或软硬件的结合。在一个实施例中，结合参考图4A更容易理解所述方法430。在步骤432，等待一个证明传递请求。在用户(发送者)打算发送一封电子邮件时，可以提出所述证明传递请求。举例来说，在微软Outlook上加载有一个图标，当点击这个图标后，可以使所述客户端模块406启动所述证明传递的功能。

假设服务器20的注册用户已经请求了发送至接收者的一封特定邮件的证明传递。在步骤434，所述客户端模块406通过查找所述通讯录408来验证所述接收者是否是发送者的一个联系人。如果接收者或接收者的电子邮件地址不是发送者的一个联系人，所述方法430进入步骤435，提醒所述发送者说对于该接收者的证明传递是不能执行的。如果接收者加入服务器20成为注册用户并是发送者的联系人之一，需求的证明传递就可以执行。在一个实施例中，所述发送者可以电子邀请所述接收者向服务器20注册并成为自己的一个联系人。

现在假设所述接收者是通讯录408中的一个联系人。所述方法430进入步骤436，将所述电子邮件封装起来，使所述电子邮件首先改道至服务器20。在一个实施例中，可在所述电子邮件的地址前加入服务器20的地址。举例来说，所述服务器20的地址为proof@mingoe.com，所述电子邮件本来需要寄到的地址为lisi@yahoo.com，为了使电子邮件改道，所述电子邮件地址修改为proof@mingoe.com，所述电子邮件的原始地址lisi@yahoo.com被封装入所述发送至proof@mingoe.com的电子邮件内。在一个实施例中，在所述电子邮件在Outlook中正在发送时，执行所述电子邮件地址更改。换句话说，所述电子邮件的改道对于发送者来说是不知道的。另一个种办法是，所述中转电子邮件地址proof@mingoe.com可能显示为“To：proof@mingoe.com[lisi@yahoo.com]”以清楚的提醒所述发送者该电子邮件将被改道做证明传递。

所述电子邮件到了服务器20后，在步骤437，所述服务器20验证所述电子邮件是否确实来自注册用户，是否符合证明传递条件(比如，帐户是否有足够的点或资金)。如果所述发送者不是注册用户或所述电子邮件不符合证明传递的条件，将会通知所述发送者。假设所述发送者是注册用户并符合证明传递条件，所述服务器20给所述电子邮件进行登记。这有点模仿在邮局中邮寄挂号信。

所述方法430转入步骤438，提取出原始电子邮件地址，将所述电子邮件发送至它的目的地。在一个实施例中，此时所述电子邮件附加了一个标记。在所述电子邮件被传送至一个接收者用于接收电子邮件的终端装置后，所述电子邮件中的标记驱动所述终端装置中的相应客户端模块的相应机能记录所述电子邮件收到时间和当前使用终端装置的IP地址。在所述电子邮件被打开后，还需要记录所述电子邮件的阅读时间及打开所述电子邮件的工具。举例来说，所述电子邮件可能是在Outlook、Outlook Express或其他工具被开打的，比如用Hotmail看所述电子邮件了或者Adobe打开了附件。所述客户端模块储存所述回执，定期的或在下一次同步时将所述回执传送给服务器20。

在步骤440，所述服务器检测来自所述终端装置的所述回执是否收到。当收到这样回执时，将所述回执储存在系统上或者转发给发送者作为传递证明。所述方法430提供了一种在服务器上的两个用户间的有效的邮件证明传递方案。

根据一个实例，本发明为每一用户提供一个建立“黑名单”的装置.黑名单的意思是在黑名单上的联系人是一个用户不愿再联系的联系人。当一个用户不想再与其中一个联系人联系，该用户可以把该联系人从通讯录上移到自己建立的黑名单上。这样该联系人发出的电子邮件，短信或电话呼叫可以被有效地阻挡。

图5A显示出了阻挡来自被删除联系人的电子邮件，短信或电话呼叫的一个示例的架构图500。假设被删除联系人使用终端502(比例，计算机或手机)试图与所述用户联系，所述用户用的是另一个终端504。尽管终端504没有办法拒绝来自终端502的电子邮件，短信或电话呼叫，但是根据本发明设计的一个客户端模块510会根据所述黑名单上的被删除联系人来阻挡电子邮件，短信或电话呼叫或删除收到的电子邮件和短信。如图所示，终端504设置一个黑名单514，客户端模块510会根据黑名单514来执行阻挡或删除功能。这里需要指出终端502具有像终端504一样的客户端模块506，也有可能有一个黑名单(没显示)。需要指出的是终端502和终端504上所显示的邮件应用软件508和512(比如Outlook)可以用其他应用软件来代替负责接送短信或接打电话。

根据一个实例，本发明可以用来保护用户的隐私。现在许多电话机都有来电显示(察看打电话者的身份)。差不多所有的电子邮件应用软件和器件都显示发电子邮件的原作(谁写的和用的电子邮件地址)。有时一用户不希望显示出某人的真实身份(比如其他人可能查看他的手机或电子邮件)。本发明提供了一个机制让用户修饰或掩盖原作的真实身分。图5B显示出了保护用户的隐私的一个示例的架构图520。比如，一注册用户“张三”有一联系人“李四”。张三进入自己的帐户后，立定了一个对应表把“李四”对应到“王五”。图5C显示一个对应表520。对应表520使得李四所有的标识转变为事先定义好的标识。比如，李四的姓名修饰为王五，李四的电子邮件地址修饰为王五的电子邮件地址，相应的电话号码修饰为另一个号码。取决一实施的方法，修饰过来的电子邮件地址或电话号码可以是虚构的也可以是真的，其目的之一是希望“偷看”该用户的电子邮件或手机的人不会对该用户有各种可能的猜疑。

在一实施中，对应表520是嵌入到客户端模块510。当用户在同步他的客户终端时(比如，手机或者电脑)，带有对应表520的客户端模块510或者对应表520和客户端模块510下载到所述客户终端。在另一个实施中，张三通过下载的客户端模块510在本地建立对应表520，在下一个同步时，对应表520上载到服务器上张三的帐户中。

在操作中，李四用lisi@abc.com寄发一电子邮件给张三。当所述的电子邮件到了张三用的终端后，客户端模块510根据对应表520查明所述的电子邮件是否需要修饰。如果所述的电子邮件的原作没有列在对应表520，所述的电子邮件就不会被修饰。假设所述的电子邮件的原作是列在对应表520，所述的电子邮件就会被拦截施行相应修饰。产生的显示效果是所述电子邮件的原作使wangwu@yahoo.com

同样，如果李四用自己的手机给张三送短信或打电话。客户端模块510激活拦截收到的短信或电话呼叫。根据对应表520修饰其来电的电话号码。产生的显示效果是所述短信或电话是从王五那里来的。

如果张三有意回所述短信或电话，根据一实施，客户端模块510拦截张三回复的短信或回电并用真实的号码替换修饰的号码，这样所述回复的短信或回电就能顺利继续下去。根据另一个实施，当张三回复短信或回电时，客户端模块510不激活来处理所述回信或回电。所述修饰的号码(或者修改的电子邮件致词)实际是另一个指定身份。比如，所用的修饰号码021-63052236是一个实际的号码，同样wangwu@yahoo.com是一个可以工作的电子邮件账户。其目的之一只是希望“偷看”张三的电子邮件或手机的人不会对该用户有各种可能的猜疑，从而保护张三的隐私。

以上所述仅为本发明的各种较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种联系信息管理方法，其特征在于，所述方法包括：

一服务器为一个注册用户维护有由联系条目形成的通讯录，每个联系条目记录有所述注册用户的一个联系人的简介，所述简介包括有所述联系人的姓名和联系方式；如果所述联系人也是所述服务器的注册用户，在所述联系人对自己的联系条目做了一个更新后，所述更新立即反映到所有把所述联系人列为自己联系人的通讯录中，

当所述注册用户从自己的列表中删除一联系条目，所述服务器不把要求删除的联系条目删除而是把要求删除的联系条目存储到一个特制的区域作为一个删除的联系条目，虽然所述通讯录不再包含所述删除的联系条目，但是所述注册用户可以从所述特制的区域寻回所述的删除联系条目，但是在所述特制的区域中的所述删除的联系条目不会再得到相应的联系人的更新同时所述相应的联系人也得不到注册用户的任何更新。

2.如权利要求1所述的联系信息管理方法，其特征在于：

接收来自信息源的数据，所述数据包括通讯录中已有的联系条目的部分内容或列表中没有的联系条目的部分内容；

将所述数据并入所述联系条目中，以更新相应联系条目的部分内容或添加新的联系条目；

将更新的联系条目发回所述信息源，此时所述信息源上具有所述联系条目的最新版本，其中所述信息源包括电子邮件应用工具、网络邮箱工具、手机、个人电脑和/或个人数据助理。

3.如权利要求1或者2所述的联系信息管理方法，其特征在于：

所述数据进一步包括从所述通讯录中已经删除的联系条目，所述服务器在收到所述数据后，更新所述通讯录并把已经删除的联系条目存储到所述特制的区域，当所述注册用户需要时，所述已经删除的联系条目可以从所述特制的区域寻回，从而所述通讯录中包括从所述信息源那里已经删除的联系条目。

4.如权利要求2所述的联系信息管理方法，其特征在于：在与所述信息源下一个同步后，所述信息源又包含了所述已经删除的联系条目，造成所述信息源删除所述删除的联系条目。

5.如权利要求2所述的联系信息管理方法，其特征在于，所述更新包括电话号码和电子邮件地址的变更，这样所述注册用户可一直与所述联系人保持联系。

6.如权利要求1所述的联系信息管理方法，其特征在于，所述方法进一步包括：

允许所述注册用户通过电话或服务器发送字数有限的短消息；其中，

将所述短消息公开发布，以至于其他注册用户可对所述短消息进行回复或评论；或将所述短消息保密发布，以至于只有所述注册用户能看到、评论或编辑所述短信。

7.如权利要求1所述的联系信息管理方法，其特征在于，所述注册用户具有自己的简介，所述注册用户可以设定跟一个联系人的关系层次来决定所述联系人能看到自己多少简介信息。

8.如权利要求1或7所述的联系信息管理方法，其特征在于，所述方法进一步包括：

在所述联系条目列表更新或下载至手机上时，自动在联系条目列表中插入一个默认联系条目，所述默认联系条目包括一个电话号码，用户可通过手机法短消息至所述电话号码。

9.一种联系信息管理系统，其特征在于，所述系统包括：

服务器，用来为一个注册用户管理包括多个联系条目的通讯录，每个联系条目记录有所述注册用户的一个联系人的简介，所述简介包括有所述联系人的姓名和联系方式；

储存区域，当所述注册用户删除一联系条目，所述服务器联不把删除的联系条目删除而是把所述删除的联系条目存储到所述储存区域，虽然所述通讯录不再包含所述删除的联系条目，但是用户可以从所述储存区域复原所述删除的联系条目

能获得一些联系条目的部分信息的至少一个信息源，其用来与所述服务器进行同步，通过将来自所述信息源的数据并入所述联系条目中来更新所述联系条目，所述数据包括列表中已有的联系条目的部分内容或列表中没有的联系条目的部分内容；

其中，所述信息源也存储了一份更新的联系条目，此时所述信息源上具有所述联系条目的最新版本，其中所述信息源包括电子邮件应用工具、网络邮箱工具、手机、个人电脑和/或个人数据助理。

10.如权利要求9所述的联系信息管理系统，其特征在于，所述数据进一步包括从所述通讯录中已经删除的联系条目，所述服务器在收到所述数据后，更新所述通讯录并把已经删除的联系条目存储到所述特制的区域，当所述注册用户需要时，所述已经删除的联系条目可以从所述特制的区域寻回，从而所述通讯录中包括从所述信息源那里已经删除的联系条目。

Images