专利名称：用于在基于网络的地址簿系统中集中多个联系人信息源的系统和方法
技术领域：
本公开总体涉及使用融合地址簿的通信设备、系统和方法。更具体地，本公开涉及在融合地址簿系统中搜索多个联系人信息源。
背景技术：
在电子设备(例如，智能电话、PDA、便携式计算机等)上执行的电子地址簿应用对于建立和维持人与人之间的关系来说是有用的。典型的地址簿应用被配置为访问在执行地址簿应用的设备上本地存储的或者远程存储(例如，在服务器、数据库或者其他网络单元上)的联系人项。每个联系人项包括联系人信息，例如姓名、物理地址、电子邮件地址、电话号码、个人识别号码、即时消息标识符等等。相应地，联系人项使得设备的用户可以联系与该联系人项相关联的其他个体，或以其他方式与之通信。在服务领域和移动设备方面日益增长的创新创建了很多对联系人信息进行组织和管理的方式。此外，存在用于管理联系人信息和联系人项的很多不同类型的联系人管理/ 地址簿应用、相关的数据格式和协议。虽然设备用户享受着与联系人管理相关(vis-0-vis) 的各种选择，当前可用的选项造成了在不同的地址簿应用和联系人信息源之间的互操作性问题。换言之，在设备上缺乏关于地址簿应用的统一和一致的用户体验，特别是针对设备用户期待的易于使用和个人计算机(PC)类型的功能的的无线移动设备来说。标准组织(开放移动联盟(OMA)融合地址簿(CAB)、开放移动终端平台(OMTP)和互联网工程任务组(IETF))正在进行通过提供公共地址簿系统来提高互操作性和用户体验的若干行动。关于OMA CAB (此后也将其称为CAB使能器(Enabler))，联系人搜索是一种如下所述的功能CAB使能器意在提供搜索联系人信息或者联系人项的机制。CAB使能器的用户能够从主机CAB系统、远程CAB系统和/或服务提供商可提供的外部源(例如，黄页TM(YelloW Pages ),411目录协助等)搜索联系人信息。通过搜索操作可获得的联系人信息可以受到 CAB用户的授权规则(例如，基于订购，由用户定义的联系人视图来限制联系人信息)和服务提供商的策略的支配。一种提议的提供联系人搜索功能的方式使用在设备和基于网络的系统(例如， CAB)之间的简单HTTP接口，该接口负责将CAB用户的搜索请求发往基于网络的地址簿 (NAB)系统。使用简单的HTTP接口以一般方式提供了关键词搜索。此外，HTTP接口还提供了将XQuery嵌入到搜索请求中的机制。虽然所提出的包括前述HTTP接口的解决方案方便了联系人搜索功能，用于搜索多个外部联系人信息源(例如，包括基于非XCAP/XDM的数据源)，且可选地对来自多个源的搜索结果进行集中的新的融合地址簿功能可以是本领域中有用的进步。
发明内容
图1是示出了常规地址簿系统的框图；图2是图1所示的地址簿服务器的示例功能模块的框图；图3是示出了另一常规地址簿系统的框图；图4示出了用于搜索多个外部联系人信息源的示例图；图5示出了用于搜索XDM类型和非XDM类型的联系人信息源的不例图；图6是示出了搜索多个联系人信息源的示例方法的流程图；图7是示出了搜索多个联系人信息源的另一示例方法的流程图；图8示出了在外部数据源和可用于进行搜索的标准XML数据格式之间的示例数据映射。
具体实施例方式本公开提供了用于在基于网络的地址簿(NAB)系统(例如，如由OMA CAB定义的架构)中搜索多个联系人信息源的方法和系统。更具体地，本公开提供了用于使得用户除了搜索XML数据管理(XDM)类型的源(例如，个人联系人卡(PCC)XDM服务器、地址簿)(DM 服务器等)之外，还可以搜索外部源(例如，用于联系人项和/或联系人信息的非XDM类型的源)的系统和方法。虽然本文中将该系统称为“基于网络”的地址簿系统，该系统的用户所使用的一个或多个设备也可以包括本地存储的联系人项和/或联系人信息。即，设备可以在固定的或者可移除的存储器(例如，SIM卡、SD卡、闪存等)中包括联系人项和/或联系人信息。现在转向附图，对示例系统和方法进行描述。图1示出了示例地址簿系统100。如图所示，使用网络侧110和设备侧120来配置系统100。网络侧110和设备侧120都可以包括如图所示出的一个或多个实体、组件或模块， 该实体、组件或模块可被实现为硬件、软件或者硬件和软件的结合。可以将设备侧120部分地配置为在可以使用公共地址簿的任何适当的设备1 上。示例设备包括无线通信设备， 例如，蜂窝电话、个人数字助理、双向寻呼机、智能电话、便携式计算机或者其他这种包括处理模块(例如，微处理器、CPU等)、存储模块(例如，RAM、ROM或者其他存储器)和通信模块(例如，无线收发信机等)的设备。可以将设备侧120至少部分地配置为在有线设备上， 例如个人计算机、膝上型计算机、机顶盒等等。虽然没有在图1中示出，可以将一个或多个设备侧组件(例如，地址簿客户端12 备选地实现为网络侧110的一部分。设备侧120包括地址簿(例如，CAB)客户端122。地址簿客户端122与地址簿服务器140通信，将在其后对地址簿服务器140进行描述。将地址簿客户端122和地址簿服务器140相连的接口 1 在网络侧110和设备侧120之间传输通信，例如，通知、订购、搜索、 共享和导入等。可以使用超文本传输协议(HTTP)来实现在地址簿客户端122和地址簿服务器140之间的接口 1 的底层协议。此外，协议的主体和有效负荷可以包含传送请求所必需的语法。然而，接口 1 上携带的通信可以具有包括SIP类型的消息在内的各种格式和协议。设备侧120的另一功能框是开放移动联盟(OMA)数据同步(DS)客户端124。可以将OMADS客户端IM配置为与地址簿客户端122协作，以在设备侧120和网络侧100之间同步用户的个人联系人信息和地址簿数据。即，OMADS客户端IM可以协助被称作联系人同步的OMACAB功能。可以使用OMA数据同步(DS)服务器130来实现联系人同步功能，OMA 数据同步(DS)服务器130被配置为经由OMA DS-I接口 132和OMA DS-2接口 1；34与OMA DS客户端IM通信，或者与OMADS客户端IM协作。在一个实施例中，用于同步的底层协议可以是HTTP或无线应用协议(WAP)推送。 可以使用OMADS所定义的通知消息框架，作为用于向CAB用户(CAB用户可以是使用具有客户端122的设备1 的个人)通知CAB信息的机制。例如，在通知中可以使用导致由联系人订购所产生的联系人信息的更新，用户的个人联系人卡信息、CAB状态等中的改变。还可以通过其他机制传递通知，例如，短消息服务(SMS)、多媒体消息服务(MMS)、电子邮件、即时消息、SIP 订购(Subscribe)/通知(Notify)(例如，根据 IETF RFC 3^5)、SIP 推送(PUSH) (例如，根据 0MA〃 Push Architecture, “ 0MA-AD-Push_V2· 2)等。如图1进一步示出的，系统100的网络侧110还包括地址簿存储器142、XDM使能器144(例如，OMA XDM规范所指定的)以及可以与地址簿服务器140接口的辅助架构。如图所示，辅助架构可以包括传统地址簿系统150、外部使能器160(例如，由用于消息收发、 存在性等的OMA所定义的客户端-服务器类型的架构)以及远程地址簿服务器170。本地地址簿存储器可以存在(例如，在设备侧120作为数据库或者设备126的存储器中的其他数据结构)。这种本地地址簿存储器可以包括在网络侧110中存储的联系人项或联系人信息的拷贝。可以将本地存储的联系人与网络存储的联系人同步。此外，本地地址簿存储器可以包括一个或多个传统的、专有的或者基于标准的本地地址簿等。此外，可以将一个或多个公司(例如，基于企业)地址簿存储在本地地址簿存储器中。可以是例如如下情况由于缺少凭证，不能从网络侧110对一个或多个公司地址簿进行访问和搜索。参考图2，地址簿服务器200(可以与图1的地址簿服务器140类似或不同)可以包括向地址簿系统100提供由OMA CAB定义的功能的一个或多个模块，OMA CAB定义的功能包括联系人搜索、联系人共享、联系人订购等。地址簿服务器200可以是具有处理模块的硬件设备(例如，服务器计算机)，该处理模块执行用于提供前述功能的地址簿服务器软件、固件或者指令。虽然图2中将模块210-270示出为被配置作为地址簿服务器200的一部分，然而一个或多个模块210-270可以被配置在系统100中的其他位置。现在将详细描述模块210-270。用户账户管理器和认证代理模块210 该模块负责管理用户认证和账户信息，包括用户首选项和定制方面，例如与仅从服务器向客户端(例如，客户端122)同步部分地址簿数据、接收/不接收通知等相关的配置。通知功能模块220 使用该模块向客户端(例如，客户端122)通知所订购的联系人中的更新。该功能可以使用DS通知框架或者其他机制，例如，电子邮件、SMS、即时消息 (IM)、SIP订购/通知等。XML文档管理客户端(XDMC)模块270 该模块负责与XML文档管理服务器(XDMS)模块协作，以用于地址簿数据的管理(例如，访问和处理)。该地址簿数据可以是存储在个人联系人卡(PCC)XDM服务器(例如，图1中的框146)中的或者与PCC XDM服务器相关联的信息，以及存储在地址簿XDM服务器(例如，图1中的框148)中的或者与地址簿XDM服务器相关联的信息。为此，XDMC模块270可以与联系人搜索功能模块250或者互动模块沈0 通信或者协作。如图2进一步示出的，使用联系人订购功能模块230、联系人共享功能模块M0、以及互动功能模块260将地址簿服务器200配置为执行关于CAB的功能，分别包括联系人订购、联系人共享和与传统地址簿通信。再次参考图1，网络侧110还包括XML文档管理(XDM)使能器144。XDM使能器144 包括个人联系人卡(PCC) XML文档管理服务器(XDMS) 146，PCC XDMS 146可以包括系统100 的PCC。此外，XDM使能器144包括地址簿XDMS 148，地址簿XDMS 148可以包括联系人项或者对系统100的联系人项的链接/引用。可以将图1中示出的地址簿存储器142配置为对网络上的各个用户的地址簿进行存储的服务器或者数据库。使用设备上的地址簿客户端122，可以对该存储器160进行访问、修改、同步等。因为附加的地址簿服务器可以在其他网络域中提供(host)或者由其他网络运营商所提供，网络侧110上的另一组件可以是远程地址簿服务器170。远程地址簿服务器接口可以允许在一个或多个网络域中的可信地址簿系统之间的互动。网络侧110的另一组件可以是基于网络的传统地址簿系统150。传统地址簿系统是可能已经存在的地址簿系统。例如，Facebook 、Outlook 、Yahoo ！""联系人等可能已经存在于网络侧上。这些传统系统用于管理个人联系人和地址簿信息，且它们是基于网络的。现在转向图3，提供了另一示例地址簿系统300。如图所示，使用网络侧310和设备侧320来配置系统300。可以将设备侧320至少部分地配置在可能使用公共地址簿的任何适当的设备321上。示例设备包括无线通信设备，例如，蜂窝电话、个人数字助理、双向寻呼机、智能电话、便携式计算机或者其他这种设备。可以将设备侧320至少部分地配置为在有线设备上，例如个人计算机、膝上型计算机等等。备选地，可以将一个或多个设备侧组件 (例如，CAB客户端322)实现为网络侧310的一部分。如果将设备侧组件实现为网络中的地址簿系统客户端的一部分，则可以使用在设备和设备侧组件之间的接口来配置该系统。在将客户端配置在网络中的实现中，可以对使用一个或多个协议(该协议对设备和基于网络的客户端之间的这种接口进行了定义)的通道进行优化，以减少请求的冗长，并降低与特定协议(例如，SIP订购/通知)相关联的开销。这种优化可以提高设备的电池寿命。如果存在通道选择，设备上的代理(例如，通道选择代理或机制)和所述基于网络的客户端/ 设备侧组件可以提供协商通道的手段。在设备侧320和网络侧310之间还可以存在不同的通道。类似地，如果存在通道选择，设备侧320上的组件和网络侧310上的组件可以提供协商通道的手段。简单HTTP接口是通道的示例。设备320包括地址簿(例如，CAB)客户端322、数据同步(DS)客户端324以及 XML文档管理客户端(XDMC) 326。如图所示，地址簿客户端322可以经由DS客户端3 和 0MA_DS接口与地址簿服务器340通信。此外，地址簿客户端322可以通过作为服务器340的代理的XDM使能器344与地址簿服务器340通信。在这种情况下，客户端322可以通过接口 XDM-l、XDM-3、XDM-5和XDM-7中的一个或多个，经由XDMC 326和XDMS 346与服务器 340通信。参考图3，XDM使能器344可以提供搜索联系人源的功能。XDM使能器344提供基于受限XQuery的接口 XDM-5，以搜索存储在XDMS346中或者可以被XDMS 346访问的XML文档。由W3C定义的XQuery是搜索XML文档的标准机制。特别地，使用接口 XDM-5和)(DM-7来执行联系人搜索功能，其中，在XDM-5上向XDM 使能器344发送客户端请求，以及，XDM使能器344使用XDM-7来与互动功能模块342通信，以在外部目录或者源上搜索。在XDM使能器344的搜索代理处，对来自内部(例如，CAB XDMS346)和外部源/目录(例如，使用互动功能模块342)的结果进行集中。虽然前述系统和方法对于搜索存储在内部数据存储器(例如，CABXDMS)中的信息是有用的，然而其不提供将搜索请求寻址到外部目录(例如，第三方网络目录，如黄页TM、 411目录协助等)并管理来自这些外部目录的数据(即，假设可操作外部目录来识别来自地址簿系统的搜索请求)的方式。XQuery是用于在XML文档上进行搜索的强大的解决方案。然而，为了在例如查询多个联系人信息源的背景中让XQuery工作良好，XQuery请求者(例如，客户端或者例如 web服务的其他任何实体)应该知道目标源所使用的数据格式。此外，XQuery请求者应该知道是否可以将从源返回的数据表达为XML形式。在一些情况下，要求将来自目标源的数据表达为XML形式用于Xquery的目的，可能不是高效的或者是困难的。本文中，提供了针对联系人信息或者联系人项而搜索多个源(例如，包括CAB服务器和由服务提供商所提供的外部目录，该CAB服务器具有根据CAB用户的一般性公共信息以及根据搜索用户的“朋友”的私有信息)的方法。在一个情况下，“朋友”可以使得不同的联系人细节为具有公共特性(例如，限制严格的俱乐部的成员)的请求者可获得。在另一情况下，基于请求者的凭证，“朋友”可以使得不同的联系人细节为请求者可获得。在又一情况下，“朋友”可以使得与在之前可获得的过去的联系人细节相比，可获得不同的联系人细节。可以存储访问联系人细节的权利，或者已经存储了实际的联系人细节本身，或者朋友使得可以使用另一机制访问不同的联系人细节。在本系统和方法的一个实施例中，使用其他资源所必需附着的标准XML文档。在另一实施例中，使用以标准XML文档作为目标的基于HTTP的接口。在又一实施例中，本系统和方法维持选择公共信息的拷贝以及指向该资源的指针或URI。被选择以用于本地维持的信息可以是基于试探法(heuristics)的。可以有规律地对选择公共信息的这些拷贝进行更新。从在搜索字符串中使用的关键词或者在例如HTTP接口上提供的基于XQuery的搜索请求到地址数据的映射，可以是基于试探法的，其中，可以通过以下方式，根据用户来维持试探法使得搜索操作更有效；或者如果将多种语言混合到搜索字符串中，结果从用户的角度看仍是所期望的。在一些实施例中，可以基于一些特性对结果排序和/或过滤。例如，可以基于诸如到用户位置的距离来对地址排序。在另一示例中，可以将朋友的地址信息提升到地址列表中最显著的点(例如，列表的顶部)。 可以将具有多个电话号码的用户的地址项放置为使得可以将“网络中”的地址项提升到其他的较不期望的联系人备选以上。虽然OMA CAB文档指定了四种功能，但是提供本公开以主要关注联系人搜索功能。具体地，本公开提供了用于支持搜索外部目录(例如，黄页 ，411目录协助等)的系统和方法。通过将标准的地址簿搜索格式定义为将搜索寻址到外部目录，可以基于标准的XQuery 请求和/或关键词字符串机制来执行搜索外部目录。虽然本文所示意和描述的示例是关于基于互联网协议(IP)的协议(例如，HTTP)提供的，并不意味着本公开被限制为基于IP 协议的协议。事实上，在其他实施例中，可以代之使用诸如SIP或者专有协议之类的协议。 此外，虽然在此示意和描述的示例是关于可扩展标记语言(XML)提供的，并不意味着本公开被限制为XML。事实上，可以使用其他语言，例如，广义标记语言(GML)、超文本标记语言 (HTML)、可扩展超文本标记语言(XHTML)等。当使用XML语言时，还会将相关的MIME类型和XML模式(schema)定义为用于通过传输协议(例如，HTTP)传输XML文档或者片段。这样的一种用于请求的协议方法是HTTP POST。地址簿使能器(例如，OMA所指定的CAB架构)提供搜索联系人信息的机制。其意在向公共的地址簿用户提供从主机公共地址簿系统、远程公共地址簿系统和/或服务提供商可提供的外部数据库(例如，黄页TM)内搜索联系人信息。可用于搜索操作的联系人信息受到公共地址簿用户的授权规则和服务提供商的策略的支配。现在参考图4，关于高级系统/架构图对示例搜索方法进行了描述。如图4所示， 搜索客户端/请求者410(例如，图1中示出的客户端122)经由接口 415向应用服务器420 做出请求。应用服务器420可以是例如图1中示出的地址簿服务器140或者图3中示出的被配置为地址簿服务器340的代理的XDM使能器344。搜索请求可以包括XQuery和/或关键词字符串表达式，其基于由应用服务器420(例如，由应用服务器内的互动功能或者联系人搜索功能提供的(host))所定义的标准XML搜索数据格式。在之后将参考图5描述的备选的实现中，该标准格式还可以由搜索代理所提供，该搜索代理可以担当所有搜索请求的中心点以及搜索结果的集中，然后将该搜索结果的集中发送回客户端。应用服务器420的标准XML格式可以与应用服务器420所使用的或者可以通过其他方式访问的数据源430兼容。数据源/目录430可以包括以下一项或者多项PCC XDMS, 地址簿XDMS、以及外部数据源。标准XML格式可以将数据源的本地格式和标准搜索格式之间的数据变换过程最小化，从而促进了实质上无损的数据变换。可以将应用服务器至少部分地实施或配置为地址簿服务器和/或XDM使能器，或者实施或配置在地址簿服务器和/ 或XDM使能器上。图4中示出的接口 425定义或者方便了应用服务器420(例如，互动功能、 或联系人搜索功能、或者XDM使能器中的搜索代理)和数据源/目录430之间的交互。数据源/目录430中包括的外部目录与应用服务器420之间的交互可以基于提供外部目录的实体(例如，服务提供商)所支持的公共接口或者API。为了使得数据可以被来自搜索请求者的Xquery访问，将来自外部源的数据变换为应用服务器中定义的标准XML搜索格式。在一个实例中，在搜索请求之前，可以对来自外部源的数据进行预先格式化或者变换(例如，以非实时的方式)为标准搜索格式。在又一个实例中，通过定义外部目录的本地数据格式与标准搜索格式之间的一个或多个映射，可以实时(或接近实时)地执行对来自外部源的数据的格式化或者变换。在这种情况下，可能需要基于该映射将原始的Xquery请求(即，从搜索客户端/请求者410到应用服务器420)实时(或者接近实时)地转换为外部目录特定的查询。在特定的实现中，数据的实时或者接近实时的格式化或变换可以更加有效，因为其向操作和/或维持外部目录的第三方搜索提供商提供了更大的灵活性。例如， 与对来自外部目录的所有数据进行变换相反，提供在标准XML格式和外部目录所使用本地格式之间的映射便足够了。现在转向图5，描述了另一示例搜索方法。如图5中所示，搜索客户端/请求者 510(例如，图1中示出的客户端122)经由接口 515向应用服务器520 (例如，图1中示出的地址簿服务器140)做出请求。搜索请求可以包括基于应用服务器520所定义或者使用的标准XML搜索数据格式的Xquery和/或关键词字符串表达式。如图5中所示，应用服务器520包括搜索代理522和XDMS 524，XDMS 5 提供(host)标准搜索XML格式并可进行操作以应用标准搜索XML格式。XDMS 5M与前述的CAB XDMS 346 (图3)可以相似或者不同。XDMS 5 可以通过双向的方式应用标准搜索XML格式。亦即，XDMS 5 可以1)将接收到的Xquery (来自搜索客户端/请求者510)映射到向外的外部源特定的查询；以及2)将从外部源接收到的结果映射到标准格式，可以通过其来搜索和/或将其报告回客户端510。 XDMS 5 可以是逻辑功能。此外，XDMS 5 可以是独立的组件，或者可以由应用服务器内的互动功能模块(例如，图2的框260或图3的框342)或联系人搜索功能(例如，图2的框250)所提供。可以将搜索代理522配置为搜索请求的中心点以及搜索结果的集中，然后将搜索结果的集中发送回客户端。当应用服务器520接收到搜索请求时，搜索代理522可以将请求直接中继到兼容的数据源530，该兼容的数据源530是内部的、可信的或者已知的，以在不需要执行重新格式化或变换的情况下正确地解释和响应搜索请求。如图所示，兼容的数据源530可以包括 PCC XDMS 532和地址簿XDMS 534，然而，可以提供其他联系人信息/数据源。在搜索请求包括对“不兼容”(即，没有被配置来接受、解释和/或响应XML格式的请求或返回XML格式的数据的数据或联系人信息源)的外部或第三方数据源/目录536的查询的情况下，搜索代理522可以与XDMS 5M协作(例如，由互动功能所提供)以与数据源/目录536通信。XDMS 524可以执行外部或第三方数据源536的本地格式和标准的XML搜索格式之间的数据变换过程，从而促进实质上无损的数据变换。可以由应用服务器内的变换功能来执行该变换过程(例如，图4的框420或图5的框520)。此外，可以由地址簿服务器内的互动功能、联系人搜索功能或其两者来进行该变换，该地址簿服务器可以利用由提供外部目录的外部搜索数据系统所提供的接口或API。在执行对从外部源536接收到的数据进行数据变换或重新格式化之后，XDMS 5M可以向搜索代理522发送已变换/重新格式化的数据，然后，搜索代理522可以集中来自各个联系人信息源(例如，所示出的源532、534、536) 的数据。在变换或重新格式化并可选地执行集中之后，搜索代理522可以向客户端510报告搜索请求/查询的结果。为了让地址簿客户端执行地址簿服务器以及其他联系人信息源的联系人搜索，从设备侧向网络侧传输请求。各种请求可能已为本领域技术人员所知，两个示例包括了简单的关键词搜索和复杂的XQuery搜索。简单的关键词搜索模型允许地址簿用户通过利用简单的关键词来查询网络地址簿。典型的搜索请求格式是<ContactSearch><------------------搜索请求或响应的数据放在这里
</ContactSearch>使用简单的关键词的示例搜索请求是
<ContactSearch> 〈Request〉
〈Keyword maxResults="50">example〈/Keyword〉 <dataSource>yellowpages.com</dataSource> 〈/Request〉
</ContactSearch>基于XQuery的XML格式的示例搜索请求是
<ContactSearch> 〈Request〉
<XQuery maxResults="50">
<-…搜索请求的具有CDATA格式的XQuery URI放在这里 </XQuery>
<dataSource>yellowpages.com</dataSource> 〈/Request〉 </ContactSearch>在以上的示例中，〈Contact karch>是搜索文档的根节点，对于从客户端到服务器的搜索请求和从服务器回到客户端的搜索响应来说是公共的。〈Contactkarch〉元可以包含〈Request〉或者〈Response〉元。〈Request〉是包含具有XML格式的搜索请求数据的容器元。请求(Request)元可以包含〈Keyword〉元或者<XQuery>元。〈Keyword〉是携带实际搜索数据的元。换言之，通过该参数来描述搜索来自网络地址簿系统的元的关键词。该元的数据类型是“字符串”。该元可以包含属性 “caseSensitive”，其指示是否应该以区分大小写的方式来进行搜索。类型是布尔型，具有以下枚举值{" true"，〃 false" }。在一个实施例中，默认值是“false”。此外，该元可以包括属性“maxResults”，其定义了可以返回的最大结果数目，并且其是整型的。如果没有指定该属性，可以使用默认值。在以上的示例中，将最大结果定义为50，指示在搜索停止的点处，最多可以返回50个结果，丢弃或忽略剩余的响应。〈XQuery〉是携带符合W3C Xquery格式的搜索请求数据的元。使用该元来查询基于网络的地址簿系统，以进行具有特定准则的复杂查询。该元包含属性“maxResults”，其指示针对XQuery搜索所应该返回的最大结果数目。备选地，该属性可以具有默认值(例如， 10个结果)。类型是“整型”。在还对本地地址簿存储器或另一(例如，公司或企业)地址簿存储器中的至少一个进行搜索并发现匹配的情况下，可以将该匹配并入接收到的结果中，作为对XQuery搜索请求的响应(或者其他通道的搜索请求响应)的一部分。如果将要呈现给搜索用户或组件的maxresults，即最大的结果数目，(在下文中，将要呈现给搜索用户或组件的最大结果数目也称为maxresults)设置为一个值，并且本地匹配的数目和作为XQuery搜索请求的响应(或者其他通道的搜索请求响应)而返回的匹配的数目之和高于maxresults，则需要特别考虑如何处理为数众多的结果。或者呈现匹配的总数，或者呈现匹配的总数没有超过 maxresults的值。如果呈现出没有超过maxresults的值，XQuery或者其他通道的搜索请求可以指示初始的最大数目或者第一响应中所期望的结果。后续的XQuery搜索请求响应可以包含maxresults数目的结果。在另一实施例中，设备侧组件并入搜索结果，并仅呈现 maxresults 个匹配。〈dataSource〉是指示或者定义(内部和/或外部)数据源的元，其中，该数据源应该被应用搜索请求。相应地，dataSource元是用于启用对多个联系人信息源进行搜索并 (至少部分地)集中来自这些联系人信息源的匹配数据的一个特征。数据源(data Source) 元可以指派或者定义一个或多个数据源(例如，多个XDMS、AUID或者多个外部目录)，以用于联系人信息搜索操作。dataSource元可以指示应该被包括在搜索中的数据源。备选地， dataSource元之后的文本字符串也可以表示要从搜索中被排除的数据源。以上关键词搜索中的单词“example”指示了正被搜索的关键词。从而，例如，如果用户正在搜索DalIas内的所有联系人(或者具有至DalIas的链接或引用)，那么关键词搜索可以基于单词“Dallas”。为此，可以向地址簿客户端反馈与Dallas相关的结果的列表。 作为搜索请求的结果，在客户端处从应用服务器接收响应。来自应用服务器的结果或响应将产生可能结果的列表或者其他数据结构。示例响应是
<ContactSearch> <Response>
〈Result userId="x@example.com">X</Result>
<dataSource>yellowpages.com</dataSource> 〈Result userId="y@example.com">Y</Result> <dataSource>PCCXDMS</dataSource> 〈/Response〉 </ContactSearch>其中，〈Response〉是容器元，包含从服务器回到客户端的搜索请求结果。响应 (response)元可以包含一个或多个〈Result〉元。〈Result〉是包含基于搜索请求的单一结果的元。对于多个结果，由服务器产生结果(Result)元的序列。该元包含‘‘userld”属性，其指示结果中的联系人的唯一的标识符。 该结果还可以包括〈dataSource〉元。〈dataSource〉是指示返回搜索结果的数据源的元。可以使用数据源信息来允许用户进入外部搜索提供商的域中，以进行进一步的交互。
13
在一些实例中，可以将服务器配置为对响应中的结果(Result)元排序。例如，与没有匹配附加属性的人的联系人信息相比，可以在响应中更早地呈现还与某些附加属性相匹配的人的联系人信息(例如，地址)。例如，具有相同故乡或者在故乡的相同区域或相邻的邮编中的人/资源，在搜索用户的地址簿中被发现与具有在公共地址簿中发现的相同名字的人/资源不符的人/资源可以在匹配列表中接收到不同的或者优选的项位置(例如， 更高对更低，或者相反)。由于可以返回有限数目的结果元(例如，根据默认的或者指定的maxResults元)， 可以由客户端，或者备选地，网络中执行搜索的单元(例如，应用服务器)执行某种排序/ 过滤。过滤可以使用默认值，例如，故乡、其他的共享属性。然而，搜索请求还可以包括一些用于过滤的值。此外，可以利用用户简档/首选项来对所返回的搜索数据进行排序/过滤，该用户简档/偏好例如可以存储在地址簿服务器的一部分(例如，图2的用户账户/简档210)或者XDM使能器(例如，图1的框144)的一部分(例如，用户首选项XDMS)中。此夕卜，可以设置这种过滤值的优先级。用户简档/优先级的默认设置对于每个用户可以是不同的，并且可以通过试探法来确定(例如，基于过去的搜索请求)。现在参考图6，提供了用于描述搜索多个联系人信息源(例如，所示出的源606和 608)的示例方法的示例消息收发图。在图6中，针对对应的应用服务器604(例如，可以与服务器140、340 (与XDM使能器344协同)、420和520类似的地址簿服务器)，可以已经对搜索客户端602(可以与客户端122、322、410和510相似或者不同)进行了认证和授权。此夕卜，针对对应的地址簿服务器，可以已经对XDMS (其可以被包括在与应用服务器520类似的应用服务器604中)进行了认证和授权。如图6中的箭头610所示，客户端602向应用服务器604发送针对联系人信息或者联系人项的搜索请求。可以意识到在一些实例中，可以根据图1中所示意的示例架构，将箭头610所指示的搜索请求通信或者消息直接发送到地址簿服务器。然而，在其他实例中， 可以将箭头610所指示的搜索请求通信或者消息间接发送到地址簿服务器。即，可以根据图3中示意的示例架构，将搜索请求通信或消息定向至XDMS(担当地址簿服务器的代理)， 其后，XDMS可以将该搜索请求通信或消息发送或者中继到地址簿服务器。不管哪个实体接收到搜索请求，响应于接收搜索请求，应用服务器604可以实质上同时将由箭头620和640 所指示的搜索请求分别发送到应用服务器数据源608(例如，PCC XDMS、地址簿XDMS)和外部数据源606。基于所发送的搜索请求620、640，应用服务器604接收搜索响应630和650。 将响应630从应用服务器数据源608返回到应用服务器604，而将响应650从外部数据源 606返回到应用服务器604。可以意识到，当外部数据源606不提供标准的或者所期望的 XML格式的数据时，响应650的接收可以涉及实时的或者接近实时的数据变换。如通信箭头 660所示，应用服务器可以集中来自各个源606和608的搜索响应，以组成可以将搜索结果合并的响应。如通信箭头670所示，应用服务器604向客户端602发送(例如，经由图4的接口 415或图5的接口 515)包括搜索结果的响应。可以意识到，可以在由箭头660所指示的对结果进行集中之前、之后或期间，对来自各个源的结果进行排序/过滤。现在参考图7，提供了用于描述搜索多个联系人信息源的另一示例方法的另一消息收发图。在图7的图中，应该意识到，以非实时的方式执行对外部数据源的搜索请求。即， 来自外部数据源/目录706的数据被应用服务器704所接收到，被变换、映射到标准格式，或者在来自客户端702的搜索请求之前被处理和存储。这样，防止或者实质上最小化了可能由于对来自外部联系人信息/数据源的数据重新格式化/数据变换所产生的响应延迟。如图7中的箭头710所示，在应用服务器704从客户端702接收搜索请求之前，从外部数据源706接收到具有非标准的或未期望(例如，非XML)格式的数据。通过在搜索请求之前从外部数据源706接收数据，应用服务器704可以将数据变换为标准或者所期望的 XML搜索格式，该格式符合也由应用服务器数据源708(例如，PCC XDMS、地址簿XDMS等)所使用的格式/类型，以使得来自搜索客户端702或请求者的Xquery可以轻易地并且快速地访问来自各个源的数据。如前所述，可以使用外部目录的本地数据格式与标准搜索格式之间的映射，对数据进行变换。可以使用的XML格式的示例标准搜索格式是
< Kml version^1' 1, 0Ε > <cont.act>
<fir 3/ 1 :-· i.Ilc.iine >
>tSm_ ；JK / la:-]IIame>
<i\ddre ;> O OCC ex出 φ二e s:.丄eet, example city”.</adciress> <；.；1^ ■ c^a"ρ I c . com</,> <tc. >! 1 1 1 : 1 ； </tc >
<q ea 丄 ο r:- a " ι ο r. -P S / wire 丄 ess cell coordinates < / ge ο I oc a t i on >
sρ I ayMamc> Γ·.‘.Γ,. cc</d" sp : ayh\3mc> CdJ s ρ: ay I 二 agc> : macs ο 丨</ cJ Gp - Y - agc >
<orq Lin丄 2d:丄οιι> <..{r:.pn:\y X</orqmiiza t._an>
</contact>虽然前述的XML涉及基本的或者典型的可以被包括在标准搜索格式中的联系人信息/属性，其他XML标准搜索格式可以包括附加的联系人信息/属性。例如，标准搜索格式可以是或者可以使用由PCC或者地址簿联系人项的联系人项所使用的相同XML格式或者 XML格式的子集。在应用服务器中使用标准格式将允许客户端执行从客户端对这种格式的 Xquery请求，并且还将允许外部或者第三方的联系人信息/数据提供商(例如，黄页TM等) 将其本地数据变换为标准格式，从而使得响应于客户端的搜索请求，让其数据更易于访问、 搜索和使用。现在参考图8，示意了第一数据结构格式(由外部数据源输出)和第二数据结构格式(可以在搜索请求之前存储并对其进行搜索)之间的示例数据变换/映射。如图8中所示，将外部数据源配置为提供具有第一数据结构820的联系人数据或信息(例如，vCard格式等)。第一数据结构820包括联系人名称；组织、地址、电话号码(语音和传真)、电子邮件地址(工作和个人)；以及网站(例如，URL)。然而，外部数据源可以提供具有不同数据或不同排序/配置的数据的数据格式。例如，来自另一外部数据源的第一数据结构可以包括更少或者附加的信息字段。如图进一步示出的，第二数据结构840包括姓、名、电话号码、地址、网站(URL)、地理位置、显示名称、组织以及电子邮件地址。第二数据结构840可以是前述XML格式的示例标准搜索格式。如图8中所示，映射830可以识别第一数据结构820的信息字段(例如，通过关键词或数据格式)，并使用第一数据结构820的信息来填充第二数据结构840的字段。例如， 如图8中所示，使用映射830来填充第二数据结构840的姓和名字段，映射830可以从第一数据结构820的姓名字段解析出姓和名。可以使用类似或者不同的技术来填充第二数据结构840的其他字段。
再次转向图7，如箭头720所指示的，客户端702向应用服务器704发送针对联系人信息或者联系人项的搜索请求。可以意识到在一些实例中，可以根据图1中所示意的示例架构，将箭头720所指示的搜索请求通信或者消息直接发送到地址簿服务器。然而，在其他实例中，可以将箭头720所指示的搜索请求通信或者消息间接发送到地址簿服务器。艮口， 可以根据图3中示意的示例架构，将搜索请求通信或消息定向至XDMS(担当地址簿服务器的代理)，其后，XDMS可以将该搜索请求通信或消息发送或者中继到地址簿服务器。不管哪个实体接收到搜索请求，响应于接收搜索请求，应用服务器704可以将箭头730所指示的搜索请求发送到应用服务器数据源708(例如，PCC XDMS、地址簿XDMQ。基于所发送的搜索请求730，应用服务器704从应用服务器数据源708接收搜索响应740。如通信箭头750 所示，应用服务器750可以对来自各个源706和708的搜索响应进行集中，以组成将来自源 706,708的搜索结果进行合并的响应。如通信箭头760所示，应用服务器向客户端702发送(例如，经由图4的接口 415或图5的接口 515)包括搜索结果的响应。可以意识到，可以在箭头750所指示的对结果进行集中之前、之后或期间，对来自各个源的结果进行排序/ 过滤ο本文描述了各个实施例。然而，这些实施例是非限制性的，并出于说明性的目的而提供。由此，应该意识到，除非在本文中指示或者很清楚地与上下文相抵触，本公开意在覆盖权利要求中所陈述的主题的所有修改和等效。
权利要求
1.一种由地址簿架构的服务器所执行的搜索联系人信息的方法，所述方法包括从与所述服务器相关联的客户端或者代理接收联系人搜索请求，所述联系人搜索请求指定针对联系人信息所要搜索的目录，所述目录在所述地址簿架构的外部；以及将所述联系人搜索请求转换为外部搜索请求，所述外部搜索请求具有由该外部目录支持的格式。
2.根据权利要求1所述的方法，其中，所述联系人搜索请求包括XML元〈dataSource〉， 所述XML元〈dataSource〉用于识别针对联系人信息所要搜索的目录。
3.根据权利要求1所述的方法，还包括在所述转换之后，向所述外部目录发送所述外部搜索请求； 接收响应，所述响应包括与所述外部搜索请求相关的结果；以及将所述结果发送给所述客户端或者所述代理。
4.根据权利要求3所述的方法，其中，所述响应还包括XML元〈dataSource〉，所述XML 元〈dataSource〉用于识别与所述结果相关联的目录。
5.根据权利要求1所述的方法，其中，搜索请求指定针对联系人信息所要搜索的第一外部目录和第二外部目录，以及，所述转换包括将所述联系人搜索请求转换为第一外部搜索请求，所述第一外部搜索请求具有由所述第一外部目录支持的第一格式；将所述联系人搜索请求转换为第二外部搜索请求，所述第二外部搜索请求具有由所述第二外部目录支持的第二格式；以及将所述第一外部搜索请求和所述第二外部搜索请求发送给所述第一外部目录和所述第二外部目录。
6.根据权利要求5所述的方法，还包括从所述第一外部目录接收第一响应，所述第一响应包括与所述第一外部搜索请求相关的第一结果；从所述第二外部目录接收第二响应，所述第二响应包括与所述第二外部搜索请求相关的第二结果；以及集中所述第一结果和所述第二结果。
7.根据权利要求6所述的方法，还包括根据特性或属性，对所述第一结果和所述第二结果中的至少一个进行排序、分类或过滤之一。
8.根据权利要求1所述的方法，其中，所述联系人搜索请求具有XQuery格式，且基于标准XML格式。
9.根据权利要求8所述的方法，其中，由所述地址簿架构的互动功能来提供所述标准 XML格式。
10.根据权利要求8所述的方法，其中，所述标准XML格式是以下之一 由所述地址簿架构管理的个人联系人卡或地址簿的联系人项的格式；以及由所述地址簿架构管理的个人联系人卡或地址簿的联系人项的格式的子集。
11.根据权利要求1所述的方法，其中，所述地址簿架构、所述服务器、所述客户端和所述代理符合开放移动联盟(OMA)融合地址簿(CAB)规范。
12.一种由地址簿架构的客户端所执行的搜索联系人信息的方法，所述方法包括创建联系人搜索请求，所述联系人搜索请求指定针对联系人信息所要搜索的目录，所述目录在所述地址簿架构的外部；以及向与所述客户端相关联的服务器或者代理发送所述联系人搜索请求， 其中，所述联系人搜索请求使得所述服务器将所述联系人搜索请求转换为外部搜索请求，所述外部搜索请求具有由该外部目录支持的格式。
13.根据权利要求12所述的方法，其中，所述联系人搜索请求包括XML元 〈dataSource〉，所述XML元〈dataSource〉用于识别针对联系人信息所要搜索的目录。
14.根据权利要求12所述的方法，还包括从所述服务器或所述代理接收响应，所述响应包括与所述联系人搜索请求相关的结果。
15.根据权利要求14所述的方法，其中，所述响应还包括XML元〈dataSource〉，所述 XML元〈dataSource〉用于识别与所述结果相关联的目录。
16.根据权利要求12所述的方法，其中，搜索请求指定针对联系人信息所要搜索的第一外部目录和第二外部目录，以及，所述联系人搜索请求使得所述服务器将所述联系人搜索请求转换为第一外部搜索请求，所述第一外部搜索请求具有由所述第一外部目录支持的第一格式；将所述联系人搜索请求转换为第二外部搜索请求，所述第二外部搜索请求具有由所述第二外部目录支持的第二格式；以及将所述第一外部搜索请求和所述第二外部搜索请求发送给所述第一外部目录和所述第二外部目录。
17.根据权利要求16所述的方法，其中，所述联系人搜索请求还使得所述服务器从所述第一外部目录接收第一响应，所述第一响应包括与所述第一外部搜索请求相关的第一结果；从所述第二外部目录接收第二响应，所述第二响应包括与所述第二外部搜索请求相关的第二结果；以及将所述第一结果和所述第二结果集中，以发送至所述客户端。
18.根据权利要求17所述的方法，其中，所述联系人搜索请求还使得所述服务器对所述第一结果、所述第二结果以及所述第一结果和所述第二结果的集中列表中的至少一个进行排序。
19.根据权利要求12所述的方法，其中，所述联系人搜索请求具有XQuery格式，并基于标准XML格式。
20.根据权利要求19所述的方法，其中，由所述地址簿架构的互动功能来提供所述标准XML格式。
21.根据权利要求19所述的方法，其中，所述标准XML格式是以下之一 由所述地址簿架构管理的个人联系人卡或地址簿的联系人项的格式；以及由所述地址簿架构管理的个人联系人卡或地址簿的联系人项的格式的子集。
22.根据权利要求12所述的方法，其中，所述地址簿架构、所述服务器、所述客户端和所述代理符合开放移动联盟(OMA)融合地址簿(CAB)规范。
23.一种搜索联系人信息的方法，所述方法包括使地址簿服务器的互动功能适于查询不支持标准XML格式的第二外部目录，所述互动功能能够被操作为将联系人信息从第一外部目录导入融合地址簿存储器；以及使用所述互动功能，将来自地址簿客户端的基于所述标准XML格式的联系人搜索请求转换为具有由所述第二外部目录支持的格式的外部搜索请求。
24.根据权利要求23所述的方法，还包括配置所述互动功能，以集中来自多个外部目录的结果。
25.根据权利要求23所述的方法，其中，所述联系人搜索请求包括XML元 〈dataSource〉，所述XML元〈dataSource〉用于识别针对联系人信息所要搜索的第二目录。
26.根据权利要求23所述的方法，其中，所述联系人搜索请求具有XQuery格式。
27.根据权利要求23所述的方法，其中，所述标准XML格式是以下之一所述融合地址簿存储器中的个人联系人卡或地址簿的联系人项的格式；以及所述融合地址簿存储器中的个人联系人卡或地址簿的联系人项的格式的子集。
28.根据权利要求23所述的方法，其中，所述互动功能、所述融合地址簿存储器、所述地址簿服务器和所述地址簿客户端符合开放移动联盟(OMA)融合地址簿(CAB)规范。
29.根据权利要求23所述的方法，其中，所述互动功能被配置为从所述第二外部目录接收数据，并变换所述数据以进行与所述联系人搜索请求相关的搜索。
30.根据权利要求四所述的方法，其中，所述互动功能被配置为在接收到所述联系人搜索请求时，或者在接收到所述联系人搜索请求之前，对来自第二外部目录的数据进行变换。
全文摘要
本发明提供用于对在包括客户端和服务器在内的地址簿架构之外的至少一个目录进行搜索的方法。在一个实施例中，客户端可以发送指定了不支持标准搜索格式的外部目录的联系人搜索请求，该请求使得服务器将该请求转换为具有由所述外部目录支持的另一格式的外部搜索请求。在另一实施例中，当该请求指定了不支持标准搜索格式的外部目录时，服务器可以对从客户端接收到的联系人搜索请求进行转换。在又一实施例中，地址簿服务器的互动功能适于查询不支持标准搜索格式的外部目录，可操作该互动功能以将联系人信息从传统地址簿存储器导入到融合地址簿存储器中。
文档编号G06F17/30GK102576361SQ201080006518
公开日2012年7月11日 申请日期2010年2月2日 优先权日2009年2月5日
发明者简·亨德里克·卢卡斯·贝克, 苏雷什·奇图里 申请人:捷讯研究有限公司