CN102713892A

CN102713892A - 用于全局目录服务的***和方法

Info

Publication number: CN102713892A
Application number: CN2010800605818A
Authority: CN
Inventors: A·D·伊巴斯克; E·R·G·杰森; V·G·巴雷斯; J·L·L·洛桑托斯
Original assignee: Smart Hub Pte Ltd
Current assignee: Smart Hub Pte Ltd
Priority date: 2010-01-04
Filing date: 2010-12-15
Publication date: 2012-10-03
Anticipated expiration: 2030-12-15
Also published as: US9846858B2; EP2521977A4; SG182362A1; UA106108C2; KR20120128611A; MY159442A; CA2782005A1; RU2576495C2; ZA201204972B; TW201140483A; WO2011081603A1; CA2782005C; EP2521977A1; JP5574554B2; TWI511064B; MX2012007573A; AU2010337430B2; KR101566233B1; SG172508A1; AU2010337430A1

Abstract

本申请公开了一种用于促进在网络用户之间传输联系信息的***和方法，所述***包括：耦合到所述网络的至少一个服务器；耦合到所述服务器的至少一个数据库；耦合到所述网络的多个用户终端，其中，每个用户的终端配置为：响应于用户的请求，向所述服务器发送与所述用户相关联的联系信息；其中，所述请求使得所述用户的终端将所述联系信息编译到具有一个或多个文字字段的电子商务卡对象中，并且将所述电子商务卡的一个或多个文字字段映射到包含在电子商务卡对象中的一个或多个对象属性，并且向所述服务器发送所述电子商务卡对象，以便保存在所述数据库中。

Description

用于全局目录服务的***和方法

技术领域

本发明涉及在网络用户之间的联系信息的设定。特别是（但是不排除其它），本发明涉及用于使用电子商务卡对象的全局目录服务的***和方法。

背景技术

电子商务卡的使用最初是由Versit联盟（Versit Consortium）于1995年提出的，并且随后由互联网邮件联盟（Internet Mail Consortium，IMC）着手研究。IMC至今已经制定出了针对电子商务卡的很多标准（比如如，vCard或hCard），其中，最新的标准是开放标准vCard v3.0。vCard v3.0是根据两个互联网工程任务组（Internet Engineering Task Force，IETF）文件（即，根据请求评议（Request for Comments，RFC）2425（MIME Content-Typefor Directory Information）以及根据RFC 2426（MIME Directory Profile））来定义的。如这些标准中所定义的，vCard和hCard两者都可以包括：元数据、语义信息、图形和图像，以及甚至音频或视频剪辑。如这些标准中所定义的，因此，vCard和hCard都仅仅是被动信息元素。

在标题为“Method for Management of vCards”的欧洲专利申请EP1589730中讨论了vCard的使用的一个示例。EP 1589730是针对一种用于在移动终端上创建vCard并且在移动终端和其它设备之间交换所述vCard的方法。根据EP 1589730的方法，通过将MIME类型的vCard数据***JPEG头部，从而将vCard作为图像数据保存在JPEG文件中。

在Beaton等人的标题为“Electronic Business Cards”的美国专利No.6442263中，讨论了一种用于为通信设备提供电子商务卡的方法。根据Beaton的方法，商务卡是使用CLID信息来创建的，在电话网络的用户之间传输，并且用来自动地发起呼叫。

在Feldhahn的美国专利No.7246099中公开了采用vCard平台的另一种***。Feldhahn允许人们在他人的联系软件中保持当前的联系信息，而不必将更新后的联系信息分别通知接收人员或者向该人员手动地重新发送。针对个人的静态联系信息是保存在中央服务器上的，并且被分配了全局唯一ID。所述静态联系信息包括动态链路，该动态链路含有创建者的全局唯一ID，所述联系信息的接收者可以使用该全局唯一ID来检索更新后的联系信息。

Desai的美国专利No.5493015描述了一种电子商务卡***，其提供了精简并且便携的***，用来从商务卡读取并且保存商务卡数据，所述商务卡具有保存在该商务卡上的计算机可读存储介质上的计算机可读数据。该电子商务卡***使用了连接到计算机控制***的读取器。该电子商务卡***还向被该电子商务卡***所接受的商务卡数据提供组织和操作能力。

虽然诸如vCard或hCard之类的电子商务卡可以在很多应用中使用，但是电子商务卡的功能目前受到一些限制。扩展这些商务卡的功能从而使它们包括功能、脚本、以及可操作元素，将是明显有利的。本发明试图解决现有的电子商务卡标准和实施的这类限制。

发明内容

相应地，在本发明的一个方面中，提供了一种在多个网络用户之间传输联系信息的方法，所述方法包括下列步骤：

在用户终端处将所述联系信息编译到具有一个或多个文字字段的电子商务卡中；

向目录注册所述电子商务卡，其中，所述注册电子商务卡的步骤进一步包括：

通过将所述电子商务卡的文字字段映射到包含在所述电子商务卡

对象中的一个或多个对象属性，来将所述电子商务卡封装到所述电子商务卡对象；

向目录发送所述电子商务卡对象；以及

将所述电子商务卡对象保存在数据库中；

在所述目录处接收来自用户的一组搜索参数；

向所述数据库搜索与所述搜索参数相匹配的电子商务卡对象；

向所述用户提供电子商务卡对象的列表；

在所述目录处接收来自所述用户的针对来自所提供的电子商务卡对象的列表中的一个电子商务卡对象的请求；

向所述用户转发所请求的电子商务卡对象。

适宜地，每种电子商务卡对象都包括属性和方法。方法是用于操作属性、使用属性或者执行某种其它功能的功能或例行程序。所述电子商务卡对象还可以包括一个或多个可操作的元素。这些元素可以包括：用于启动本地设备应用程序、启动应用程序或服务的脚本、和/或发起基于web界面或基于wap界面的脚本。所述电子商务卡对象可以包括：元数据、语义信息、图形、图像、以及甚至音频或视频剪辑。

在本发明的一个实施例中，所述电子商务卡对象可以是指向多个电子商务卡对象的指针或者是多个电子商务卡对象的掩码，使得作为指向多个电子商务卡对象的指针的针对所述电子商务卡对象的任何用户操作，实际上是分别对这些多个电子商务卡对象中的每个电子商务卡对象的相同操作。

优选地，所述网络是移动通信网络、IP网络或者诸如此类的网络。

注册的步骤可以进一步包括：确认一组用户证书的步骤。所述用户证书可以是被动证书或主动证书或者两者的结合。被动证书可以包括但不限于：请求方的移动电话号码、和/或在无需该请求方主动知晓或者参与的情况下能够通过SIM认证从该请求方获得并且认证的任何这类信息。主动证书包括但不应当限于：PIN、密码、和/或一方必须明确提供的任何这类信息。

适宜地，搜索参数可以是一组关键词。在这种情况下，接收的步骤可以包括：在使用所述关键词开始合适的数据库查询之前，对所接收到的关键词进行解析。

所述提供电子商务卡对象的列表的步骤可以包括：根据现有的商业规则，对查询的结果进行分类和/或过滤的步骤。这些规则可以包括但不限于：赋给对象的已验证状态的相对权重、作为对象属性的已确认的关系、关键词匹配精度的级别、信息的新近程度、布尔运算，如果有的话，以及其它要考虑的因素。

所述方法可以进一步包括：允许用户或者任何已授权方更新或者删除所述电子商务卡对象的任何属性的步骤。适宜地，所述对电子商务卡对象的属性进行更新的步骤可以通过多个用户界面执行，包括但不限于：web或wap界面、局部应用、或者使用了电子邮件、SMS、MMS、flash消息、或IP技术的菜单***。

所述方法还可以包括：接收来自用户的针对同步或下载的请求的步骤。适宜地，所述同步的步骤进一步包括：验证被请求进行同步或进行下载的电子商务卡对象是否存在；验证被请求进行同步或进行下载的电子商务卡对象的隐私或访问级别设置；如果在同步或下载之前电子商务卡对象的隐私或访问级别设置需要征得同意，则向被请求进行同步或进行下载的所述电子商务卡对象的拥有者发送可操作通知，以便允许或不允许所述请求；当允许所述同步或下载请求时，或者如果在同步或下载之前这些对象的隐私或者访问级别设置不需要征得同意时，则向所述请求用户发送所述被请求进行同步或进行下载的电子商务卡对象的同步更新或副本；以及，向所述请求方发送合适的通知。

所述方法还可以包括：对所述电子商务卡对象的内容进行验证和认证的步骤。所述验证和认证的步骤可以包括：当成功验证或认证所述电子商务卡对象中的数据时，将被请求验证的对象标记为已认证；并且向相关方发送合适的通知。可选地，所述验证和认证的步骤可以包括：通过使用现有的后付费用户数据库、使用与所述对象相关联的已验证的关系、使用概况信息、以及使用类似的或者受到预设商业规则制约的这些中的任何或全部的组合，来对置信水平评分，从而自动地执行电子商务卡对象验证；并且然后，将产生与预设阈值相比相等或者更高的置信水平的那些对象标记为已验证。

在本发明的另一个方面中，提供了一种用于促进在网络用户之间传输联系信息的***，所述***包括：

耦合到所述网络的至少一个服务器；

耦合到所述服务器的至少一个数据库；

耦合到所述网络的多个用户终端，其中，每个用户的终端配置为：响应于所述用户的请求，向所述服务器发送与用户相关联的联系信息；其中，所述请求使得所述用户的终端将所述联系信息编译到具有一个或多个文字字段的电子商务卡中，并且将所述电子商务卡的一个或多个文字字段映射到电子商务卡对象的一个或多个属性，并且向所述服务器发送所述电子商务卡对象，以便保存在所述数据库中。

用户可以通过保存在数据库中的多个电子商务卡对象来搜索和/浏览，其中，所述搜索/浏览可以通过多个用户界面来执行，包括但不限于：web或wap界面、局部应用、或者使用了电子邮件、SMS、MMS、flash消息、或IP技术的菜单***。

所述***可以允许用户或者任何已授权方更新或者删除所述电子商务卡对象的任何属性。适宜地，所述对电子商务卡对象的属性进行更新的步骤可以通过多个用户界面执行，包括但不限于：web或wap界面、局部应用、或者使用了电子邮件、SMS、MMS、flash消息、或IP技术的菜单***。

保存在数据库中的电子商务卡对象可以标记为已证实的条目。已证实的电子商务卡对象是服务器向其提供对以下情况的最低程度确认的那个电子商务卡对象：该商务卡对象中的信息包含了该商务卡对象声称所归属的个人或者单位的信息。电子商务卡的验证是基于由验证过程产生的置信水平，其包括但不限于，需要物理上存在并且提交证书、使用现有的后付费用户数据库、使用与对象相关联的已验证关系、或者受到某些商业规则制约的这些中的任何或全部的组合。除了赋给已验证的电子商务卡对象的置信水平，所述已验证状态同样也用于增大其在搜索结果中的相对权重，其中，查询具有多个精确的和/或相似的匹配。

适宜地，所述***可以实现为跨越多个网络的分布式***。在这种情况下，全局目录可以包括与多个网络中的每个网络相连接的多个计算平台，每个计算平台适用于主持、管理以及保持全局目录服务。

附图说明

为了使本发明可以被更容易地理解并且付诸实施，现在将参照描绘本发明优选实施例的附图，并且其中：

图1是描绘了根据本发明的一个实施例，用于促进在网络用户之间传输联系信息的***的原理图；

图2描绘了根据本发明的一个实施例，用于更新电子商务卡对象的过程；

图3是描绘了根据本发明的一个实施例的搜索过程的原理图；

图4是描绘了根据本发明的一个实施例的电子商务卡对象的检索的原理图；

图5是描绘了根据本发明的一个实施例，电子商务卡对象的验证和认证的过程的原理图；

图6是描绘了根据本发明的一个实施例，用于将位于移动设备上的电子商务卡对象与所检索到的卡细节同步的过程的原理图；

图7A是根据本发明的一个实施例的EBC（电子商务卡）对象的一种可能架构的概念图；

图7B是描绘了由图7A的EBC对象架构所产生的一种可能的菜单结构的原理图；

图7C是描绘了根据本发明的一个实施例，EBC对象的一种可能架构的概念图；

图7D是描绘了由图7C的EBC对象架构所产生的一种可能的菜单结构的原理图；

图8A是描绘了根据本发明的一个实施例，被指定具体上下文的EBC对象的一种可能架构的概念图；

图8B是描绘了根据本发明的一个实施例，被指定具体上下文的EBC对象的一种可能架构的概念图；

图8C是描绘了根据本发明的一个实施例，被指定具体上下文的EBC对象的一种可能架构的概念图；

图9是表示在本发明的一个实施例中所使用的服务发现过程的流程图；

图10A是根据本发明的一个实施例，被指定具体上下文的EBC对象的一种可能架构的概念图；

图10B是根据本发明的一个方面，当从第三方客户设备观察时，被指定具体上下文的EBC对象的架构的概念图；

图11是表示根据本发明的一个实施例的掩码功能的图；以及

图12是表示根据本发明的另一个实施例的掩码功能的实施的流程图。

具体实施方式

参照图1，其描绘了用于促进在多个网络用户100之间传输联系信息的***（申请人已经将其命名为全局目录）。如图所示，全局目录包括连接到数据库102的至少一个服务器101，所述数据库102包含一个或多个已注册方104的联系信息。如图所示，服务器连接到主机网络102，该主机网络向多个用户103₁、103₂、…、103_n提供多项服务，包括注册和从全局目录检索联系信息。每个用户103₁、103₂、…、103_n可以访问全局目录，以输入他们的联系信息。一旦注册，该具体用户的联系细节可以被任何其它用户103₁、103₂、…、103_n通过对该全局目录服务进行查询而检索到。各种注册和检索过程等将在下面更详细地讨论。

虽然已经从连接到单一主机网络的服务器角度对上述全局目录***进行了说明，但是本领域技术人员应当理解，全局目录也可以实现为跨越多个网络的分布式***。在这种情况下，全局目录可以包括与多个网络内的每个网络相连接的多个计算平台，每个计算平台适用于托管、管理以及维持全局目录服务。

图2描绘了根据本发明的一个实施例的注册过程200，其允许用户增加或修改包含在全局目录中的他们的联系细节。为了向全局目录注册他们的细节，用户需要将他们的联系细节以电子商务卡（EBC）的形式向全局目录服务发送（步骤201）。在发送之前，将EBC封装成对象（步骤202），下文称为EBC对象。然后，将该EBC对象向全局目录服务转发（步骤203），以便进行注册。将电子商务卡封装入电子商务卡对象，实际上是将vCard的各个字段（其仅仅是文字信息）映射到EBC对象的相关属性内的文字信息属性。此时，该映射利用了在vCard信息和EBC对象属性之间的一一对应关系，或者可能是由商业规则定义所限定的对应关系。

当收到EBC对象时（步骤204），全局目录服务开始检查EBC对象是否保存在其数据库中（步骤205）。如果在全局目录上找到该EBC对象的记录，则其开始验证用户的证书（步骤206）。所述证书可以包括下列信息中的一个或多个：请求方的移动电话号码或SIM身份或IMEI和/或在无需该请求方主动知晓或参与的情况下可以从该请求方得到的任何此类信息、PIN、密码和/或一方必须明确提供的任何此类信息。如果证书是足够的，则用包含在EBC对象中的数据来更新全局目录的数据库内的用户的先前条目（步骤207）。向用户发送成功更新的通知（步骤208）。

在数据库内没有EBC对象的记录（即，请求注册的新用户）的情况下，则全局目录服务获取该用户的证书（步骤209）。一旦全局目录服务已经抽出相关证书，全局目录随后将EBC对象保存在其数据库中。一旦EBC对象保存在全局目录中，其就开始向用户发送通知（步骤208）。这个新的条目将会被默认标记为未确认的或未验证的。

图3描绘了根据本发明的一个实施例，用于使用户能够搜索包含在全局目录中的信息的过程300。如图所示，所述搜索过程是由用户输入一组搜索参数（例如，一组关键词）而开始的（步骤301）。然后，向全局目录转发所述搜索参数（步骤302）。当接收到所述搜索参数时，全局目录服务开始向其数据库查询（步骤303）包含与所述搜索参数相匹配（步骤304）的属性的EBC对象。在数据库内存在与搜素参数相匹配的EBC对象的情况下，则目录服务根据隐私参数的规定对这些匹配的EBC对象的已分类列表进行编译（步骤305）。然后，向用户转发所述已分类列表（步骤306），以便在用户的终端上显示（步骤308）。如果根据步骤304，数据库查询303没有匹配结果，则全局目录开始向用户发送通知，指示没有找到结果（步骤307）。然后，向用户的终端显示空结果（308）。

当接收到基于步骤306的结果的已分类列表时，用户可以随后根据隐私参数的规定从全局目录检索到所期望的电子商务卡对象（步骤308）。

可以得到***支持的隐私参数提供了具体的隐私设置，其定义了来自某个人的EBC对象的信息被公众获得的程度。可以设置不同级别的信息可用性，并且限制到不同的群组，每个群组由下列因素定义：与EBC对象拥有者建立的关系、关系的程度、常用概况元素、以及可以作为呼叫群组时的基础的这类其它适当的区别。因此，向用户转发的EBC对象可以因用户不同而不同，取决于所采用的隐私控制的不同级别，例如，用户可以属于一受信任的EBC对象拥有者群组，因此，将向这类用户转发的EBC对象将包含如下信息属性和方法：这些信息属性和方法对于来自另一群组的另一用户而言是不可用的。

考虑到信息技术中的目前趋势，一个人可以具有不同的电话号码、不同的电子邮件地址、或者类似的信息。这样的多种信息可以构成不同EBC对象配置（所述不同EBC对象配置提供了具体用户的隐私设置或者偏好）的基础，但是所有这些信息涉及单个人。在这些情况下，GD可以对所给定的EBC对象拥有者分配内部客户参考号码（CRN）。然后，该CRN用于将针对用户的具体EBC对象与相关信息即时地（on-the-fly）相关联。因此，从已经请求了相同EBC对象的两个用户的角度来看，某个人的电话号码可能是不同的，但是两个号码都将把电话呼叫连接到同一个人。

由于如上面讨论的CRN唯一地标识了EBC对象拥有者，***也使采用趣味号码成为可能。趣味号码是与EBC对象拥有者和请求该EBC对象的用户两者都相关联的号码。趣味号码是即时产生的，但是作为EBC对象拥有者和请求用户之间的唯一通信标识符（电话号码、电子邮件地址、URL等）是有效的，除非被EBC对象拥有者禁用。不同趣味号码与各个请求用户相关联，但是这样的多个趣味号码是与单个EBC对象拥有者相关联的。趣味号码采用了端到端关联，因此趣味号码是与EBC对象拥有者的CRN和请求用户的CRN两者都相关联的。这允许双方之间进行双向通讯。使用由第三方针对用户产生的趣味号码来连接到与该趣味号码相关联的EBC拥有者或者用户是不被允许的，因为该趣味号码***使用了内置式（built-in）认证机制。即，只有已经产生的趣味号码所针对的人员能够使用该趣味号码连接到另一端的与该趣味号码相关联的人员。

图4描绘了根据本发明一个实施例，用于从GD检索EBC对象的过程400的一个示例。如图所示，向用户呈现来自图3的步骤308的EBC对象的已分类列表。然后，用户在列表中选择他们希望检索的电子商务卡对象所针对的条目（步骤401）。然后，向全局目录发送所述选择，全局目录随后开始查找被分配给该EBC对象的隐私设置（步骤402）。在这种具体情形中，EBC对象被分成两个群组，即，隐私列表和公开列表。

如果基于步骤403确定被请求的EBC对象是隐私列表，则目录服务向EBC对象的拥有者发送具有可操作消息的形式的请求404（步骤405），以便准许向请求方公开包含在EBC对象中的信息。拥有者在接收到该请求后向目录服务回复响应（步骤406）。然后，目录服务判断EBC对象的拥有者是已经准许提供所请求的信息，还是拒绝了该请求（步骤407）。如果拥有者不准许提供所请求的EBC对象，则全局目录进而向请求方409发送拒绝通知（步骤408）。

在EBC对象的拥有者已经准许向请求方提供所请求的信息的情况下，目录服务进而从其数据库检索EBC对象（步骤410）。在向请求方409发送EBC对象之前（步骤412），目录服务可以将EBC对象标记为针对请求方的备份联系列表的一部分（步骤411）。如从图4可以看到，在确定了EBC对象是公开列表的情况下，也是遵循这些步骤。

参照图5，其描绘了根据本发明的一个实施例，对于保存在全局目录内的电子商务卡对象的验证和认证过程500的一种可能的配置。如图所示，全局目录配置为：向在目录中注册的每个用户发送提醒，即，每个用户具有保存在该目录内的EBC对象。根据步骤502，当接收到该提醒（步骤501）时，用户有如下选项：进行认证和确认、或者决定退出。如果用户决定退出验证过程，则该过程结束。

在用户选择进行验证过程的情况下，向用户呈现用于手动或自动验证的选项（步骤503）。如果用户选择手动验证，则用户需要物理地连接已认可的全局目录无线数据中心504（例如，移动用户的零售数据中心等），并且提供适当的文档。然后，该无线数据中心开始向全局目录发送针对该用户的认证请求（步骤505）。相比之下，选择自动认证选项，使得认证请求从用户的移动设备向全局目录直接发送（步骤506）。

当接收到认证请求（步骤507）时，全局目录开始检查发送方的证书（步骤508），来判断该请求是由无线数据中心发送的还是用户发起的（步骤509）。如果该请求是由无线数据中心发送的，则将EBC对象标记为已认证（步骤510），即，包含在EBC中的数据已经被独立地验证和认证。然后，向用户发送成功验证和认证的通知（步骤513）。

如果全局目录确定该请求是由用户发送的，则全局目录开始检查涉及EBC对象的所有可用数据（步骤511），以验证并且认证请求方的身份。所述数据可以包括，但不限于，在EBC对象和其它已认证的EBC对象之间已建立的链路和关系、包含在用户的互联网服务提供商（ISP）或移动服务提供商数据库或者其它第三方数据库（例如，社会网络中的账户信息、公用事业消费者数据库等）中的信息。如果根据判断步骤512，所得到的数据是足够的，则许可该认证请求，并且将EBC对象标记为已认证（步骤510）。然后，向用户发送成功验证和认证的通知（步骤513）。如果根据判断步骤512，可用数据对于允许全局目录对该请求方的身份进行验证和认证而言是不足够的，则向该请求方转发失败通知（步骤513）。

如从上面的讨论可知，所述验证和认证过程被设计为提供如下某个级别的置信度：包含在EBC对象中的信息是与EBC对象中所标识的具体个人或实体有关的正确信息。由于全局目录没有任何把握肯定在未认证的EBC对象中所含有的信息是准确的，所以用户所采取与包含在未认证的EBC对象中的信息有关的任何行动是由用户自己承担风险的。

图6描绘了根据本发明的一个方面，用于将移动设备上本地保存的电子商务卡对象与全局目录中的相应条目进行同步的过程的一个示例。同步过程是通过用户向全局目录发送同步请求而发起的（步骤601）。当接收到所述同步请求（步骤602）时，全局目录开始检索在用户的移动设备上保存的所有EBC对象（步骤603）。

一旦全局目录已经从移动设备检索到EBC对象的列表时，全局目录开始把所检索到的EBC对象的列表中的条目与包含在其数据库中的EBC对象进行比较。如图所示，全局目录把在所检索到的EBC对象的列表中的第一条目与保存在其数据库中的每个EBC对象进行比较（步骤604）。如果数据库中没有给定EBC对象的记录（步骤605），则EBC对象被视为手动添加的条目，并且全局目录跳过该条目（步骤607）。然后，全局目录判断在所检索到的EBC对象的列表内是否有更多的EBC对象要被检查（步骤611），并且如果是这样的，则全局目录开始对所检索到的EBC对象的列表中的下一个EBC对象进行检查（步骤604）。

如果在步骤604找到从用户的设备检索到的EBC对象的匹配记录，则全局目录将所检索到的EBC中所包含的数据与其数据库中所保存的EBC中所包含的数据进行比较（步骤606）。如果根据步骤608，包含在这些EBC对象中的每个EBC对象中的数据是相同的，则用户设备上的EBC中所包含的信息被视为最新的，并且不需要进一步的操作，并且跳过该条目（步骤609）。然后，全局目录判断在所检索到的EBC对象的列表内是否有更多的EBC对象要被检查（步骤611），并且如果是这样的，则全局目录开始对所检索到的EBC对象的列表中的下一个EBC对象进行检查（步骤604）。

在步骤608从用户设备检索到的EBC对象中所包含的数据与在全局目录中包含的EBC对象中所包含的数据不匹配的情况下，目录把从用户设备检索到的EBC中的数据视为陈旧的并且需要更新。然后，全局目录向用户发送更新，其包含向用户的设备发送更新后的EBC对象（步骤610）。当接收到该更新（步骤612）时，用户设备上保存的EBC对象中所包含的数据被通知中所包含的数据覆盖。然后，全局目录判断在所检索到的EBC对象的列表内是否有更多的EBC对象要被检查（步骤611），如果是的话，则全局目录开始对所检索到的EBC对象的列表中的下一个EBC对象进行检查（步骤604）。

针对通过全局目录检索到的EBC对象的列表中的每个条目，重复如上面详细描述的同步过程，直至从用户设备检索到的EBC对象的列表中没有条目剩下为止。在成功完全同步的结尾处，***可以设置检验点对象，从而可以递增地处理后续同步，与执行完全扫描相反。

如上面简述，EBC对象包括多个属性和方法，图7A描绘了EBC对象的一个实施例的结构的概念图。在该具体示例中，EBC对象包括：两个属性701₁、701₂，以及两种方法702₁、702₂。如上所述，这些属性是信息属性，并且可以与实体虚拟商务卡的不同文字字段相关联。在另一方面，所述方法定义了可以对EBC对象实施的操作。

为了利用EBC对象结构所提供的面向对象范式（paradigm），申请人已经开发出一种专门的菜单界面。目前大多数菜单***是面向过程的，即，菜单***设计为：反映了完成某个具体任务所需要的一系列用户操作。申请人所提出的菜单界面是以对象为中心的菜单***，其重点关注用户可以对具体对象实施哪些操作。

图7B描绘了用于说明在移动手机的上下文中的EBC对象中所保存的信息的菜单***的示例。在本例中，EBC对象是由菜单***的菜单引擎读取的，并且作为电话簿条目703向用户显示。为了将EBC对象显示为电话簿条目，菜单引擎确定分配给EBC对象的“名字属性”的数值。如图7A的示例中所示，EBC对象包含两个属性701₁、701₂。这些属性中的任一个可以被指定为名字属性。在本例中，第一属性701₁是名字属性，并且包含涉及实体名字（例如，“John Doe”）的相关信息。本例中的第二属性701₂是与该实体的电话号码相关联的。为了易于描述，与一个或多个实体联系电话号码相关联的属性在下文将被称为电话属性。

就标准电话簿条目项而言，用户可以自由选择该项以引出子菜单704。本例中的子菜单704向用户展现了与EBC对象的相关属性有关联的可用方法的选项。在本例中，方法702₁和702₂被分配具体任务“呼叫”和“汇款”。本例中的方法702₁被分配“呼叫”功能，并且这样一来，该方法与属性701₂（即，电话属性）相关联。对菜单显示器704上的呼叫进行选择，使得方法702₁从电话属性701₂检索相关的联系号码，并且向相关方发起呼叫。因此，用户一方不需要另外的菜单交互来发起呼叫。类似地，选择“汇款”选项将使得方法二702₂发起相关操作，以实现将移动用户指定的数量转移至属性701₁、701₂之一所指定的账户。

如图所示，子菜单704还包括默认菜单项，“查看细节”707。该菜单项允许对其它信息属性的数值（比如，可以是电子邮件地址、生日、以及包含在EBC对象的一个或多个属性中的类似信息）进行查看和编辑。

虽然在图7A和图7B中所示的例子使用了两个属性和方法，但是本领域技术人员应当理解，EBC对象可以包括多个属性和方法。图7C描绘了具有多个属性和方法的EBC对象的结构的概念图。如图所示，属性可以有1到n个，其中n为上限。类似地，所述方法可以有1到m个，其中m为上限。

图7D描绘了由菜单引擎针对具有图7C所示结构的EBC对象而产生的菜单。与上面讨论的示例相同，本例中的菜单引擎翻译了包含在EBC对象的名字属性中的数值，并且将信息以电话簿条目705的形式展现给用户。选择条目“John Doe”显示了包含可用方法702₁、702₂、...、702_m的列表的子菜单706。如图所示，显示成菜单项的方法仅限于适合屏幕的这些数量的方法减去一个方法。在上述示例中，尽管作为菜单项的5个方法将适合屏幕，但是只示出了与方法1到4（702₁、702₂、702₃、702₄）相对应的4个菜单项，以便让出位置给所需要的菜单项“查看细节”707。然后，菜单引擎将移动设备上的能够实现滚动的键映射到菜单项的下一个全屏（screenfull）。这可以使用方向键、内置式控制杆、或者任何针对该目的而指定的任何热键。因此，下一个全屏将用显示方法（m-4）到方法m的上一次可用的屏幕来展示方法5到方法9。

根据申请人提出的菜单***，也可以向EBC对象提供不可见属性“上下文（Context）”。所述上下文属性定义了一组与EBC对象相关联的默认属性和方法。上下文属性的使用示例在下表1中示出。在该具体例子中，提供了三种上下文类型，每种上下文具有一组默认属性和方法。

表1：针对具体上下文的默认数量的属性和方法

上下文	属性	方法
			人员	6	7
机构	4	5
			设备拥有者	6	5

本领域技术人员应当理解，上表仅仅是示意性的，而并非对每个上下文的定义的限制。其也没有对根据所提出的菜单***而能够定义的上下文的数量进行限制。

图8A、图8B和图8C中描绘了针对上述所标识的每个上下文的每个EBC对象结构的概念图。图8A描绘了针对上下文类别“人员”的一种可能的结构。根据上表1，针对该上下文的EBC对象结构包括六个属性801（包括不可见的上下文属性801₁）以及7种方法802。针对该上下文所设置的默认属性包括名字801₂和电话801₃属性，如上讨论。除了这些属性以外，EBC对象结构还包括附加属性（其包括涉及名字属性中所标识的人员的附加信息）。这些附加属性可以包括，例如，电子邮件属性801₄、网站属性801₅、博客属性801₆。属性801中的每一个可以与一种或多种方法802相关联。如图所示，根据“人员”上下文所设置的七种方法包括如下动作：发送消息802₁、呼叫802₂、访问网站802₃、阅读博客802₄、搜寻（poke）802₅、汇款802₆、以及默认的查看细节802₇。各种方法与各种属性的关联性将在下文中更详细地讨论。

图8B描绘了针对上下文类别“机构”的一种可能的EBC对象结构。如图所示，针对这具体上下文的EBC对象结构包括四个属性801和5种方法802。针对该具体上下文所设置的属性801包括：名字801₂、电话801₃、电子邮件801₄、以及不可见的上下文属性801₁。在本例中，与属性801相关联的方法802，除了包括默认的查看细节方法802₇以外，还包括的发送消息802₁和呼叫802₂，和在“人员”上下文中设置的一样。除了这些方法之外，“机构”上下文包括具体针对机构上下文的一些方法，在该具体示例中，这些上下文具体方法是“观察目录”802₈和“位置”802₉方法。如名字所建议的，“观察目录”802₈方法设置为：允许用户查看针对相关联的名字属性中所标识的机构的相关产品目录，而“位置”802₉方法提供了与相关联的名字属性中所标识的相关机构的位置有关的信息。

图8C中描绘了针于上下文“设备拥有者”的一种可能的EBC对象结构。如上表1中所规定的，设备拥有者上下文包含六个属性801和五种方法802。因此，设备拥有者上下文的关注焦点更多集中在信息属性801上，而较少集中在方法802上。如图所示，根据设备拥有者上下文而设置的信息属性801类似于根据人员上下文而设置的信息属性。在本例中，设备拥有者上下文，除了包括不可见上下文属性801₁以外，还包括：名字801₂、电话801₃、电子邮件801₄、网站801₅、以及博客801₆属性。根据该具体上下文而设置的方法802可以包括，例如，阅读备忘录802₁₀、管理金钱802₁₁、检查计划802₁₂、以及写博客802₁₃。如上面讨论的上下文的例子，设备拥有者上下文还包含默认的查看细节802方法。

从以上示例可见，每个具体的EBC对象上下文定义了一组默认的属性和方法。因此，将容易推断出：由于具体上下文具有一组默认的属性和方法，所以针对每个具体上下文的EBC对象而形成的菜单***将是相同的。然而，并不是相同上下文的所有EBC对象都将使所有的属性字段完全填充。

为了确定哪些方法是将要向所给定的EBC对象的用户显示的，菜单引擎使用了服务发现过程。本质上，菜单引擎将属性与方法的映射进行比较。服务发现过程的示例在图9中示出。如图所示，菜单引擎首先判断映射到该方法的属性是否存在（步骤901）。如果该属性不存在，则该方法被标记为不可用（步骤902），反之，如果该属性存在，则该方法被标记为可用（步骤903）。然后，菜单引擎判断是否还有针对具体EBC对象的其它方法要被检查（步骤904），如果有的话，则菜单引擎重复过程步骤901、902或903（取决于方法的可用性），直至没有其它方法要被检查为止，此时，菜单引擎产生仅包含如下菜单项的菜单：所述菜单项与标记为对于所给定的EBC对象为可用的那些方法相对应（步骤905）。

举一个例子，考虑上下文“人员”的EBC对象。根据该上下文，EBC对象包括与博客属性相映射的“阅读博客”方法。所述博客属性可以使其取值为博客URL或者为空。该取值正是菜单引擎在步骤901期间读取的用来判断该属性是否存在的数值。如果该博客属性为空，则“阅读博客”方法不作为与EBC对象相关联的菜单***的一部分。另一方面，如果有与博客属性相对应的数值，则“阅读博客”方法成为与该具体EBC对象相关联的菜单***中的菜单项。

虽然随着电话簿中的条目被手动建立，上述服务发现过程是即时地执行的，但是由此形成的菜单***并不是静态的。菜单引擎可以允许如下更新：所述更新能够改变针对具体EBC对象的菜单的外观。这些更新可以由下列事件中的任一项触发：

·来自信息拥有者的广播

·电话簿条目的共享

·与全局目录服务同步（如上所述）

来自信息拥有者的广播是在信息拥有者使用移动网络来发出属于该具体信息拥有者的EBC对象的已更新副本时发生的。信息拥有者是局限于移动设备上的如具有“设备拥有者”的上下文的EBC对象。向这些信息拥有者提供特定工具，以更新并且甚至改变或者更改与EBC对象相关联的属性和方法。与该EBC对象相关联的一组默认的属性和方法被该用户自定义撤销。在图10A所示的示例中，信息拥有者（人员A）已经编辑过他们的EBC对象的细节，使得其包括新的属性和方法。在本具体示例中，人员A已经将两个新的属性“社会网络”1001₁和“聊天”1001₂添加到不可见上下文属性801₁、名字801₂、电话801₃、电子邮件801₄、网站801₅、以及博客801₆属性的默认属性字段。同样，两种新方法（查看社会网络1002₁、和聊天1002₂）已经添加到针对设备拥有者上下文的默认方法的列表，即，阅读备忘录802₁₀、管理金钱802₁₁、检查计划802₁₂、以及写博客802₁₃。

由于本领域技术人员应当理解，虽然人员A的EBC对象在本地被视为属于“设备拥有者”上下文，但是其被其它人员的设备视为属于上下文“人员”。因此，站在人员B的设备来看，人员A的EBC对象是至少具有上面讨论的人员上下文的默认属性和方法的EBC对象。只要涉及人员B，属于人员A的EBC对象就将会保留，但没有属性“社会网络”和“聊天”，因而没有方法“查看社会网络”和“聊天”，直到最新的人员A的EBC对象出现为止，即，人员B的菜单引擎允许通过接收来自信息拥有者的广播、与人员A共享电话簿条目、或者人员B请求将他们的EBC对象的列表与全局目录服务进行同步，来进行更新（如上面关于图6的讨论）。

共享EBC对象是点对点的，而广播可以是定向广播或者简单广播。定向广播是将他的EBC对象向一群接收者同时发送，这群接收者通常选自人员A的电话簿或者任何已定义的接收者列表。在另一方面，简单广播向已定义的地理区域内的所有可能的接收者发出EBC。在这两种情况下，效果是相同的：已更新的EBC对象的接收者将有选择权，以保存该更新或者拒绝它。

如果接收者选择接受所述已更新的EBC，则菜单引擎将即时地（即，当使用如图10B所示的已更新的EBC对象时）发起菜单更新。在相同的示例中，如果接收者确定通过他的电话簿来访问已更新的EBC，则菜单引擎以通过与如图9所示相似的服务发现过程所描绘的过程非常相似的方式来更新菜单***。

除了菜单更新，菜单引擎还可以对这些方法作为菜单项展现的方式进行重新布置。针对每个EBC对象，这些方法是根据下列准则来划分等级的：

·交易成功

·交易的频率

·交易的费用

·其它商业规则

除了上述内容，根据上述服务发现过程，已经标识为不可用的方法将不再作为菜单***的一部分示出，即，不存在与引起不可用服务的方法相对应的菜单项。

这种菜单项的适应性重新布置是在多级菜单***的所有级别处进行的。因此，属于同一上下文的两个EBC对象将不具有同样的一组菜单项布置。根据设备拥有者与对象交互的方式，每个EBC对象将具有不同的菜单项布置。还包括另一个准则，使得在用户交互中尚未使用一段预设时间段的那些EBC对象，将具有基于相似上下文类别的EBC对象的常用统计数据的默认布置的菜单项。

菜单***也可以采用掩码功能，以允许用户在无需具体识别每个个体的情况下与不同个体交互。掩码功能利用了叫做“群组”上下文的上下文类别。“群组”上下文进一步划分为局部类或全局类。上下文“局部群组”的EBC对象是用作在用户设备本地保存的一群EBC对象的别名（alias）的那个EBC对象。对该别名的任何操作是对链接到该局部群组别名的所有EBC对象的操作。但是，该操作将限于那些可以在群组中完成的那些，比如发送SMS。

图11描绘了针对局部群组上下文的使用掩码功能的示例。如图所示，SMS 1101是使用局部群组别名1102来处理的。掩码功能开始向局部群组中所包含的EBC对象1103₁、1103₂、1103₃、1103₄中所标识的每个个体发送SMS。

可以类似地实现上下文“全局群组”的EBC对象。但是，“局部群组”和“全局群组”的区别是：“局部群组”是由设备拥有者通过对位于设备上的EBC对象进行掩蔽而在设备上创建的，而“全局群组”是来自全局目录服务的EBC对象（其用作指向其它EBC对象的指针）。在“局部群组”中的已掩蔽EBC对象对于设备拥有者而言是已知的，因为这些已掩蔽对象的实例是被假定为保存在设备中的，而“全局群组”中的已掩蔽EBC对象对于设备拥有者而言不是已知的。“全局群组”中的已掩蔽EBC对象是保存在目录服务数据库中的。

图12描绘了使用掩码功能来向局部或全局群组上下文中的EBC对象发送消息。如图所示，用户向群组上下文别名发送SMS（步骤1201）。然后，掩码功能开始检查该群组上下文属性是否为局部群组（步骤1202）。如果确定该群组为局部群组，则掩码功能开始读取掩蔽指针属性（其标识了包含在该群组中的所有EBC对象）（步骤1204）。然后，掩码功能开始从EBC对象的局部列表抽出EBC对象（步骤1205），并且向已抽出的EBC对象所标识的每个个体发送SMS（步骤1206）。

在该群组为全局群组的情况下，掩码功能向全局目录服务转发SMS（步骤1203）。然后，全局目录服务开始读取掩蔽指针（步骤1204），以便从其数据库中抽出相关的EBC对象（步骤1205）。一旦全局目录已经抽出包含在该群组中的EBC对象，其随后开始向已抽出的EBC对象所标识的每个个体转发SMS（步骤1206）。

应当理解，上述实施例仅仅是通过本发明的示例的方式来提供的，并且对于相关领域的技术人员而言，对本发明的进一步修改和改进明显将被视为落入本文所述的本发明的广义范围和界限之内。

Claims

1.一种用于在多个网络用户之间传输联系信息的方法，所述方法包括下列步骤：

在用户终端处将所述联系信息编译到电子商务卡中；

通过将所述电子商务卡的文字字段映射到包含在电子商务卡对象中的一个或多个属性，来将所述电子商务卡封装到所述电子商务卡对象中；

向所述目录发送所述电子商务卡对象；以及

将所述电子商务卡对象保存在数据库中；

在所述目录处接收来自用户的一组搜索参数；

向所述用户提供电子商务卡对象的列表；

在所述目录处接收来自所述用户的针对来自所提供的电子商务卡对象的列表中的电子商务卡对象的请求；以及

向所述用户转发所请求的电子商务卡对象。

2.如权利要求1所述的方法，其中，所述注册的步骤进一步包括：确认一组用户证书的步骤。

3.如权利要求2所述的方法，其中，所述用户证书包括：请求方的移动电话号码、和/或在无需所述请求方主动知晓或者参与的情况下能够从所述请求方获得的任何这类信息。

4.如权利要求2所述的方法，其中，所述用户证书包括以下至少一个：PIN、密码、和/或一方必须明确提供的任何这类信息。

5.如前述权利要求中的任一项所述的方法，其中，所述搜索参数是一组关键词。

6.如权利要求5所述的方法，其中，所述接收所述搜索参数的步骤进一步包括：在发起所述搜索之前，对所接收到的关键词进行解析的步骤。

7.如前述权利要求中的任一项所述的方法，其中，所述提供电子商务卡对象的列表的步骤进一步包括：对所述搜索结果进行分类和/或过滤的步骤。

8.如权利要求7所述的方法，其中，对所述电子商务卡对象的列表进行分类是根据下列中的一项：赋给对象的已验证状态的权重；作为对象的属性的已确认关系；关键词匹配精度的级别；信息的新近程度；或者布尔运算。

9.如前述权利要求中的任一项所述的方法，进一步包括：允许用户或者任何已授权方更新或者删除所述电子商务卡对象的所述属性中的任何一个的步骤。

10.如权利要求9所述的方法，其中，所述对电子商务卡对象的属性和/或方法进行更新的步骤是通过多个用户界面执行的。

11.如权利要求10所述的方法，其中，所述用户界面包括以下至少一个：web或者wap界面、局部应用、或者使用电子邮件、SMS、MMS、flash消息、或IP技术的菜单***。

12.如前述权利要求中的任一项所述的方法，进一步包括：接收来自用户的针对同步的请求的步骤。

13.如权利要求12所述的方法，其中，所述同步的步骤进一步包括如下步骤：

验证被请求进行同步的所述电子商务卡对象是否存在；

验证被请求进行同步的所述电子商务卡对象的隐私或者访问级别设置；

根据电子商务卡对象的所述隐私或者访问级别设置，向被请求进行同步的所述电子商务卡对象的拥有者发送可操作通知，用于允许或者不允许所述请求；

当允许所述同步请求时，向请求用户发送被请求进行同步或进行下载的所述电子商务卡对象的同步更新或者副本；以及

向所述请求方发送合适的通知。

14.如前述权利要求中的任一项所述的方法，进一步包括：对所述电子商务卡对象的内容进行验证和认证的步骤。

15.如权利要求14所述的方法，其中，所述验证和认证的步骤进一步包括下列步骤：

当成功验证或者认证电子商务卡对象中的数据时，将所述被请求进行验证的对象标记为已认证；以及

向有关方发送合适的通知。

16.如权利要求14所述的方法，其中，所述验证和认证的步骤进一步包括下列步骤：

通过置信水平评分来验证所述电子商务卡对象；以及

随后将产生与预先定义的阈值相比相等或者更大的置信水平的那些对象标记为已验证。

17.一种用于促进在网络用户之间传输联系信息的***，所述***包括：

耦合到所述网络的至少一个服务器；

耦合到所述服务器的至少一个数据库；

耦合到所述网络的多个用户终端，其中，每个用户的终端配置为：响应于用户的请求，向所述服务器发送与所述用户相关联的联系信息；其中，所述请求使得所述用户的终端将所述联系信息编译到具有一个或多个文字字段的电子商务卡对象，并且将所述电子商务卡的所述一个或多个文字字段映射到包含在电子商务卡对象中的一个或多个对象属性，并且向所述服务器发送所述电子商务卡对象，以便保存在所述数据库中。

18.如权利要求17所述的***，其中，每个用户终端包括菜单引擎，该菜单引擎适用于读取包含在所述电子商务卡对象中的每个对象属性，并且显示包含菜单项的多个菜单，所述菜单项表示能够执行的与所述电子商务卡对象所表示的联系信息有关的一个或多个功能。

19.如权利要求18所述的***，其中，为所述电子商务卡对象分配了上下文，并且所述菜单引擎适用于产生针对所分配的上下文的一组默认菜单项。

20.如权利要求19所述的***，其中，所述菜单引擎适用于响应于所述电子商务卡对象拥有者对所述电子商务卡对象的一个或多个对象属性的修改，修改针对所述上下文的所述一组默认菜单项。