Patent Application
20100198854
The present disclosure relates generally to communications devices, systems and methods employing a converged address book. More particularly, the present disclosure relates to searching multiple contact information sources in a converged address book system.
Electronic address book applications that execute on electronic devices (e.g., smartphones, PDAs, portable computers, etc.) are useful for establishing and maintaining relationships between people. A typical address book application is configured to access contact entries that are stored locally on the device executing the address book application or remotely (e.g., on a server, database or other network element). Each contact entry includes contact information such as, for example, a name, physical address, email address, telephone number, personal identification number, instant messaging identifier, among others. Accordingly, the contact entries enable a user of the device to contact or otherwise communicate with other individuals associated with the contact entries.
Growing innovation across services domain and mobile devices creates a number of ways to organize and manage contact information. Additionally, many different types of contact management/address book applications, associated data formats and protocols to manage the contact information and entries exist. While device users enjoy a variety of choices vis-a-vis contact management, the presently available options cause interoperability issues across differing address book applications and contact information sources. In other words, there is a lack of unified and consistent user experience across devices with regard to address book applications, particularly for wireless mobile devices where device users expect ease of use and personal computer (PC) type functionality.
Several activities are under way by standards organizations such as the Open Mobile Alliance (OMA) Converged Address Book (CAB), Open Mobile Terminal Platform (OMTP) and Internet Engineering Task Force (IETF) to improve interoperability and user experience by providing a common address book system. With regard to OMA CAB (also referred to hereinafter as the CAB Enabler), Contact Search is one functionality as follows:
The CAB Enabler aims to provide a mechanism to search for Contact information or Contract entries. Users of the CAB Enabler are able to search for the contact information from within the host CAB system, remote CAB system and/or external sources(s) made available by the service provider (e.g., Yellow Pages™, 411 directory assistance, etc.). The contact information made available for search operation may be subject to CAB user's authorization rules (e.g., contact information being limited by a user-defined contact view based on subscription) and service provider's policy.
One proposed way of providing contact search functionality uses a simple HTTP interface between the device and the network-based system (such as CAB) which is responsible for carrying the CAB User's search request towards the Network-based Address Book (NAB) system. Using a simple HTTP interface provides a keyword search in a generic fashion. Furthermore, the HTTP interface also provides a mechanism to embed an XQuery into the search request.
Although proposed solutions including the foregoing-mentioned HTTP interface facilitate contact search functionality, a new converged address book functionality for searching multiple external contact information sources (e.g. including non-XCAP/XDM based data sources) and, optionally aggregating the search results from the multiple sources would be a useful development in the art.
The present disclosure provides a method and system for searching multiple contact information sources in a network-based address book (NAB) system (e.g., an architecture defined by OMA CAB). More particularly, the present disclosure provides systems and methods for enabling users to search external sources (e.g. non-XDM type sources for contact entries and/or contact information), in addition to XML data management (XDM) type sources (e.g., a personal contact card (PCC) XDM server, an address book XDM server, and the like) as well as. Although the system is referred to herein as a “network-based” address book system, one or more devices, which are employed by users of the system, may also include contact entries and/or contact information stored locally. That is, devices may include contact entries and/or contact information in fixed or removable memory, e.g. SIM card, SD card, flash memory, etc. Turning now to the Figures, example systems and methods are described.
Device side 120 includes an Address Book (e.g., CAB) client 122. Address Book client 122 communicates with the Address Book Server 140, which will be described hereinafter. The interface 128 linking the address book client 122 and the address book server 140 carries communications such as notify, subscribe, search, share, and import, among others, between the network side 110 and the device side 120.
The underlying protocol for the interface 128 between address book client 122 and address book server 140 may be implemented using HyperText Transfer Protocol (HTTP). Furthermore, the body or the payload of the protocol may contain the necessary syntax to convey the requests. However, the communications carried on interface 128 may be of various formats and protocols including SIP type messages.
A further functional block on device side 120 is the Open Mobile Alliance (OMA) Data Synchronization (DS) Client 124. The OMA DS Client 124 may be configured to cooperate with the address book client 122 for synchronizing a user's personal contact information and address book data between the device side 120 and the network side 100. That is, the OMA DS Client 124 may facilitate OMA CAB functionality known as Contact Synchronization. Contact Synchronization functionality may be implemented using an OMA Data Synchronization (DS) server 130 which is configured to communicate or otherwise cooperate with OMA DS Client 124 via OMA DS-1 interface 132 and OMA DS-2 interface 134.
In one embodiment the underlying protocol used for synchronization can be HTTP or Wireless Application Protocol (WAP) PUSH. The notification message framework defined by OMA DS may be used as a mechanism for the notification of CAB information to the CAB user (the CAB user being an individual employing the device 126 with client 122). For example, updates to contact information resulting from contact subscriptions, changes in a user's personal contact card information, CAB status, among others, may be used in the notification. Notifications may also be delivered through other mechanisms such as Short Message Service (SMS), Multimedia Message Service (MMS), email, instant messaging, SIP Subscribe/Notify (e.g., per IETF RFC 3265), SIP PUSH (e.g., per OMA “Push Architecture,” OMA-AD-Push-V2.2), among others.
As further shown in
Referring to
User account manager and authentication agent module 210: this module is responsible for managing user authentication and account information including user preferences and custom aspects, such as configuration to synchronize only partial address book data from the server to the client (e.g., client 122), receive/not receive notifications, among others.
A notification function module 220: this module is used to notify the client (e.g., client 122) of updates in a subscribed contact. This function may use the DS notification framework or other mechanisms such as email, SMS, Instant Messaging (IM), SIP Subscribe/Notify, among others.
XML Document Management Client (XDMC) module 270: this module is responsible for cooperating with an XML Document Management Server (XDMS) module for management (e.g., accessing and processing) of address book data. This address book data could be information stored in or associated with a personal contact card (PCC) XDM server (e.g., block 146 of
As further shown in
Referring again to
The Address Book Storage 142 shown in
A further component on the network side 110 may be remote address book server(s) 170 since additional address book servers may be hosted in other network domains or by other network operators. The remote address book server interface may permit interworking between trusted address book systems in one or more network domains.
A further component on network side 110 may be network based legacy address book systems 150. Legacy address book systems are address book systems that may already exist. For example, Facebook™, Outlook™, Yahoo!™ contacts, among others, may already exist on the network side. These legacy systems are used to manage personal contact and address book information and are network based.
Turning now to
Device side 320 includes an Address Book (e.g., CAB) client 322, a Data Synchronization (DS) client 324 and an XML Document Management client (XDMC) 326. As shown, the address book client 322 may communicate with the address book server 340 via DS client 324 and the OMA_DS interface. Additionally, the address book client 322 may communicate with the address book server 340 through XDM enabler 344 acting as proxy for the server 340. In this case, the client 322 may communicate with the server 340 via XDMC 326 and XDMS 346 through one or more of interfaces XDM-1, XDM-3, XDM-5 and XDM-7.
With reference to
Specifically, the interfaces XDM-5 and XDM-7 are used to perform the Contact Search function, wherein the client request is carried over XDM-5 to the XDM Enabler 344 and wherein XDM-7 is used by the XDM Enabler 344 to communicate with the interworking functional module 342 for searching across external directories or sources. The results from the internal (e.g., CAB XDMS 346) and external sources/directories (e.g., using the interworking functional module 342) are aggregated at the search proxy in the XDM enabler 344.
Although the foregoing-described systems and methods are useful for searching information stored in internal data stores (e.g., CAB XDMS), they do not provide a way to address search requests towards external directories (e.g., a third party network directory such as Yellow Pages™, 411 directory assistance, etc.) and manage data from those external directories (i.e., provided that the external directories are operable to recognize a search request from the address book system).
XQuery is a powerful solution for searching across XML documents. However, in order for XQuery to work well in, for example, the context of querying multiple contact information sources, the XQuery requestor (e.g., the client or any other entity such as a web service) should be aware of the data format used by the destination source. Furthermore, the XQuery requestor should be aware if the data returned from the source can be expressed in XML. In some instances it may not be efficient or it may be difficult to require that the data from the destination source(s) can be expressed in XML for the purposes of XQuery.
Herein, a method is provided for searching multiple resources (e.g., including a CAB server which has general public information per CAB user as well as private information per “friend” of the search user, and external directories provided by the service providers) for contact information or contact entries. In one case a “friend” can make different contact details available to requestors that have properties in common (e.g., member of an exclusive club). In yet another case a “friend” can make different contact details available to requestors based on the requestor's credentials. Still further, a “friend” may made different contact details available compared to contact details previously made available in the past. The right to access contact details may be stored or the actual contact details themselves have been stored or a friend enables access to different contact details using another mechanism. In one embodiment of the present system and method a standard XML document to which other resources must adhere is employed. In another embodiment, HTTP-based interfaces targeted at the standard XML document are employed. In yet another embodiment the present system and method maintains copies of select public information as well as pointers or URIs towards the source. The information selected for maintaining locally may be based on heuristics. These copies of select public information may be regularly updated. The mapping of keywords used in search strings or XQuery-based search request offered over, for example, an HTTP interface to address data can be heuristic based wherein the heuristics may be maintained per user in such a way that search operations become more efficient or in such a way that if multiple languages are mixed in the search string, results are still desirable from a user's perspective. In some embodiments, results may be sorted and/or filtered based on some characteristics. For example, addresses can be sorted based on properties such as distance to the location of the user. In another example, the address information of friends can be promoted to the most visible spot in a list (e.g., top of a list) with addresses. Address entries of a user with multiple phone numbers can be placed such that “in network” address entries are promoted more than other, less desirable contact alternatives.
Although OMA CAB documentation specifies four functionalities, the present disclosure is provided for focusing primarily on the Contact Search functionality. In particular, the present disclosure provides a system and method for supporting searching of external directories (e.g., Yellow Pages™, 411 directory assistance, etc.). Searching external directories may be performed based on standard XQuery request and/or a keyword string mechanism by defining a standard address book search format to address the search toward the external directories. While the illustrated and described examples herein are provided with regard to Internet protocol (IP) based protocols (e.g., HTTP), the present disclosure is not meant to be limited as such. Indeed, in other embodiments a protocol such as SIP or proprietary protocols could instead be used. Furthermore, while the illustrated and described examples herein are provided with regard to extensible markup language (XML), the present disclosure in not meant to be limited as such. Indeed, other languages may be employed such as generalized markup language (GML), hypertext markup language (HTML), extensible hypertext markup language (XHTML), etc.
When XML is used, an associated MIME type and XML schema will also be defined for transporting XML documents or fragments over transport protocols such as HTTP. One such protocol method for requests is HTTP POST.
The address book enabler (e.g., the CAB architecture as specified by OMA) provides a mechanism to search for contact information. It aims to provide the common address book users to search for the contact information from within the host common address book system, remote common address book system and/or external databases made available by a service provider such as, for example, Yellow Pages™. The contact information made available for search operations is subject to a common address book user's authorization rules and a service provider's policies.
Referring now to
The standard XML format of the application server 420 may be compatible with data sources 430 that are employed by or otherwise accessible to the application server 420. Data sources/directories 430 may include one or more of the following: PCC XDMS; Address book XDMS; and external data sources. The standard XML format may minimize the data conversion procedures between the native format of the data sources and the standard search format, thereby facilitating substantially lossless data conversion. The application server may be embodied or configured at least partially as or on an address book server and/or an XDM enabler. The interface 425 shown in
The interaction between the external directories included in the data sources/directories 430 and the application server 420 may be based on the public interfaces or APIs supported by the entities (e.g., service providers) hosting the external directories. Data from the external sources is converted to the standard XML search format defined in the application server in order to make the data accessible to the Xquery from the search requestor. In one instance, the data from the external sources may be pre-formatted or converted (e.g., in a non-real time fashion) to the standard search format prior to the search request. In yet another instance, formatting or converting of the data from the external sources may be performed in real (or near-real) time by defining one or more mappings between the native data format of the external directories and the standard search format. In such case, the original Xquery request (i.e., from the search client/requestor 410 to the application server 420) may need to be translated to an external directory-specific query in real (or near-real) time based on the mappings. In certain implementations, the real or near-real time formatting or converting of data may be more efficient since it offers more flexibility for third party search providers that operate and/or maintain the external directories. For example, instead of converting all data from an external directory it may be sufficient to provide a mapping between the standard XML format and a native format used by an external directory.
Turning now to
When the search request is received by the application server 520, the search proxy 522 may relay the request directly to compatible data sources 530 that are internal, trusted or otherwise known to properly interpret and respond to the search request without needing to perform reformatting or conversions. As shown, the compatible data sources 530 may include the PCC XDMS 532 and the Address Book XDMS 534, however other contact information/data sources may be provided. In cases when the search request includes a query of an external or third-party data source/directory 536 that is “incompatible” (i.e., a data or contact information source that is not configured to accept, interpret and/or respond to XML-format requests or otherwise return XML-format data), the search proxy 522 may cooperate with an XDMS 524 (e.g. hosted by the Interworking function) to communicate with the data source/directory 536.
The XDMS 524 may perform data conversion procedures between the native format of the external or third-party data sources 536 and the standard XML search format, thereby facilitating substantially lossless data conversion. This process of conversion may be performed by a conversion function within the application server (e.g., block 420 of
In order for an address book client to perform a contact search of the address book server as well as other contact information sources, a request is communicated from the device side to the network side. Various requests would be known to those in the art, and two examples include a simple keyword search and a complex XQuery search.
A simple keyword search model allows the address book user to query a network address book by utilizing simple keywords. A typical search request format is:
An example search request using simple keyword(s) is:
An example search request in XML format based on XQuery is:
In the above examples, <Contact Search> is the root node of the search document which is common to both the search request from the client to the server and the search response back from the server to the client. A <ContactSearch> element can contain either a <Request> or a <Response> element.
<Request> is a container element which contains the search request data in XML. The Request element can contain either the <Keyword> element or the <XQuery> element.
<Keyword> is the element that carries the actual search data. In other words, the keyword to search elements from the network address book system is described by this parameter. The data type of this element is a “String.” This element may contain an attribute ‘caseSensitive’ which indicates whether the search should be conducted in a case-sensitive manner or note. The type is a boolean with the following enumerands {“true”, “false”}. In one embodiment the default value is “false”. Additionally, this element may include an attribute “maxResults” which defines the maximum number of results that can be returned and is of type integer. If no such attribute is specified, a default value may be used. In the example above, the maximum result is defined as 50 indicating that at most fifty results can be returned at which point the search cuts off, discards or ignores the remaining response.
<XQuery> is the element that carries the search request data that is conforming to W3C XQuery. This element is used to query the network-based address book system for complex queries with specific criteria. This element contains an attribute ‘maxResults’ which indicates the max number of results that should be returned for the XQuery search. Alternatively, there can be a default value for this attribute (e.g., 10 results). The type is an ‘Integer.’
In case at least one of a local address book storage or another (e.g., corporate or enterprise) address book storage is also searched and matches are found, the matches may be integrated in the results received as part of the XQuery search request's response (or other channel's search request response). If maxresults or the maximum number of results to be presented to the searching user or component (her forwards, the maximum number of results to be presented to the searching user or component is also known as maxresults) is set to a value, and the sum of the number of local matches and the number of the matches returned as XQuery search request's response (or other channel's search request response) is higher than the maxresults, special consideration of how to handle the voluminous results may be needed. Either the total number of matches is presented or no more than the value of maxresults. If no more than the value of maxresults is presented, either the XQuery or other channel's search request may indicate the initial maximum number or results expected in a first response. Subsequent XQuery search request responses may contain maxresults number of results. In another embodiment, the device side components integrate search results and take of presenting only maxresults matches.
The <dataSource> is an element that indicates or otherwise defines the (internal and/or external) data source(s) to which the search request should be applied. Accordingly, the dataSource element is one feature for enabling searching of multiple contact information sources and aggregating the (at least partially) matching data therefrom. The data Source element may designate or define one or more data sources (e.g., multiple XDMSs, AUIDs or multiple external directories) for the contact information searching operation. The dataSource element may indicate a data source that should be included in the search. Alternatively, a text string following the dataSource element can also represent data source(s) are to be excluded from the search.
The word “example” in the keyword search above indicates the keyword that is being searched. Thus, for example, if the user was searching for all contacts within Dallas (or with a link or reference to Dallas) then the keyword search could be based on the word “Dallas”. To this end a list of results vis-a-vis Dallas could be returned to the address book client.
As a result of the search request, a response is received at the client from the application server. The result or the response from the application server would yield a list or other data structure of possible results. An example response is:
Where <Response> is a container element which contains the results from the search request from the server back to the client. The response element can contain one or more <Result> elements.
<Result> is an element that contains a single result based on the search request. For multiple results, a sequence of Result elements is generated by the server. This element contains the “userId” attribute, which indicates a unique identifier for the contact in the result. The result can further include a <dataSource> element.
<dataSource> is an element that indicates the data source from which the search result is returned. The data source information can be used to allow the user navigate into the external search provider's domain for further interactions.
In some instances the server may be configured to order the Result elements in the response. For example, contact information (e.g., addresses) of people that also match some additional property or properties may be presented earlier in the response compared with contact information of people that do not match the additional property or properties. For example, people/resources that have the same home town or in the same area or adjacent postal code of the home town, people/resources that are found in the searching user's address book as opposed to people/resources with the same name found in public address books may receive a different or preferred entry position in the list (e.g., higher versus lower, or vice versa) of matches.
Since a limited number of Result elements may returned (e.g., according to a default or a specified maxResults element) some ordering/filtering may be performed by, for example, the client or alternatively the element in the network (e.g., the application server) that performs the search. The filtering can employ default values such as home town, other shared properties. However, the search request could also include some values for the filter. Furthermore, user profile/preferences which may be stored in, for example, a portion of the address book server such as user account/profile 210 (
Referring now to
As shown by arrow 610 in
Referring now to
As shown by arrow 710 in
Although the foregoing XML relates to basic or typical contact information/properties that can be included in a standard search format, other XML standard search formats may include additional contact information/properties. For example, the standard search format may be or employ the same XML format or a subset of the XML format used by the PCC or a contact entry of the address book contact entry. Employing a standard format in the application server will allow the client to perform an Xquery request from the client towards such format and will also allow external or third-party contact information/data providers (e.g., Yellow Pages™, etc.) to convert their native data to a standard format, thereby making their data more readily accessible, searchable and usable in response to clients' search requests.
Referring now to
As shown in
Turning again to
Various embodiments are described herein. However, these embodiments are non-restrictive and provided for illustrative purposes. As such, it should be appreciated that the present disclosure is intended to cover all modifications and equivalents of the subject matter recited in the claims unless otherwise indicated herein or otherwise clearly contradicted by context.
This patent application claims the benefit of U.S. Provisional Patent Application No. 61/150,208 filed Feb. 5, 2009.
| Number | Date | Country | |
|---|---|---|---|
| 61150208 | Feb 2009 | US |
