Patent Application
20110131219
The present disclosure relates to address books, and in particular the managing of contact information in a local and a network address book.
An address book is a book or database used for storing entities called contacts. Each contact entry usually consists of a few standard fields, such as: the first name, the last name, company name, address, telephone number, email address, fax number, cell number, instant messaging contact information, among others.
The information in an address book is usually input or updated manually or can be updated or input using various formats, such as: a lightweight directory access protocol data interchange format (LDIF) or a Versitcard (vCard), among others.
The present disclosure will be better understood with reference to the drawings in which:
The present disclosure provides for a system and method for defining multiple external identities of the user for the contacts in an address book. A user can create various address subsets such as: an address subset for personal external identity, an address subset for a professional/work external identity, and a subset for a traveling external identity, among others. The subset of fields and/or values of fields exposed to different contacts can be different for each. For example, a user that is to receive a work address subset could receive contact information of a work email address and an instant messaging address. Conversely, a contact that is to receive a personal address subset could receive a home phone number, an email address that contains a different email address than the work email address, a cell phone number, or other information.
A user can specify multiple external identities, which are various subsets of his or her full contact information set exposed to other users. The external identities are either statically predefined by the user or can be created and modified based on user specified rules upon the first or every request from the contact information requestor and can contain/link to either static or dynamic information. For example, an external identity containing only static information could be provided depending on the name or category of the contact accessing address information. The category can be broken up, for example, to include co-worker's, friends, family, sailing club buddies, among others.
An example of dynamic information contained in an external identity is when this information is established dynamically based on the rules specified by the user and associated with his or her dynamic status. Such dynamic status could include presence, location, time of the day, time zone, or network state, among others. Alternatively, the dynamic information in the external identity could be established based on the external identity of the contact information requestor.
The rules established by the user for building dynamic subset of his or her external identity may operate on static and/or dynamic fields of the receiving party external identity. For example, if an address book is configured to interact with a social networking site, the information about the recipient could be used to build the dynamic subset of user's external identity, for instance if the recipient is defined in this social networking site as user's “friend”, the recipient gets a broader set of user's contact information as opposed to the general public. In another example, the user's external identity could depend on whether the receiving party is in the same time zone as the user, whether he or she is currently driving or not, etc.
The address book, in various embodiments, could be tied to other information servers or services. For example, the address book could have knowledge of a contact's presence through a presence server, knowledge of a contact's telephone activities by being integrated with a corporate private branch exchange (PBX), knowledge of a contact's information through a location service or global positioning service (GPS), knowledge of a contact's schedule by being integrated with a contact's calendar, or knowledge of a contact's personal information through integration with a social networking site, among others. The knowledge of the auxiliary information could be used to update or arrange a contact's information to make the information more relevant.
Further, an address book on a mobile device could be synchronized with a network based address book to accomplish the above.
The present disclosure therefore provides a method for managing multiple external identities of users with a local or network based address book comprising the steps of: creating a set of address book field and value information, said set of address book field and value information being one or more external identities; and forwarding the one or more external identities to a receiving party.
The present disclosure further provides an address book for managing multiple external identities of users, the address book being local or network based, comprising: a processing module adapted to create a set of address book field and value information, said set of address book field and value information being one or more external identities; and a communications module adapted to forward the one or more external identities to a receiving party.
In the address book of a user, the user can save his or her information in various fields. For example, this can include, but are not limited to: the name, email address, a second email address, among others. The address book is either a network based address book (also referred to as a converged address book) or the address book can be a local address book present on a user's device that is synchronized with a network based address book.
The address book provides notification of the user's contact information updated to each receiving party linked to the user. Another means to update a user's address book would be to directly provide updates, for instance in the case when user subscribes to contact changes. Contacts in the address book can be classified under different categories. For example, this includes, but is not limited to, friends, co-workers, family, among others. Notification can be subject to the rules applicable to the category. The address book can further contain additional information, such as a user's presence information (available, busy, offline, among others) and communications presences (short message service (SMS), email, instant messaging (IM), among others).
Reference is now made to
In the example of
The address subset 110 further includes a work address 140.
Referring to
Address subset 210 includes identification information 220 and information about the external identity type 222.
Further, a contact information area 230 is provided. In contact information area 230, an email address 232, a home phone number 234, a mobile phone number 236, and an IM address 238 are provided.
A home address field 240 is also provided to contacts receiving the “home” address subset.
Referring to
A contact information area 330 is provided in address subset 310. Contact information 330 includes an email address 332, a mobile phone number 334, and an instant messaging address 336.
Further, address subset 310 includes a work address 340 and a home address 350.
When comparing
Also, the instant messaging contact information 138 from
The above references to
The above could be, for example, implemented using an extension to the vCard. A standard vCard example includes:
As will be appreciated by those skilled in the art, an “hCard” is an hypertext markup language (HTML) vCard and is a microformat for publishing contact information in Atom, RSS, or arbitrary XML. Mapping of Standard vCard to hCard example:
The above could be extended by adding two fields to a vCard format. These fields include:
With the extensions to the above vCard format, examples with multiple views could include:
External Identity/View 1 (Personal)
External Identity/View 2 (Professional)
As with the above, the vCard can be mapped to hCard:
External Identity/View 1 (Personal)
External Identity/View 2 (Professional)
As will be appreciated by those skilled in the art, it is possible that the user may offer more than one of his or her external identities to a single contact. In this case, the presentation methods for the different external identities may include the ability to view the different external identities or different field of the various external identities by, for example, scrolling, tabs in the contact display, menu items, links, among others. The above is not meant to be limiting and various viewing options are available as would be appreciated by those skilled in the art.
Views may be customized with specific skins associated to each external identity for better visualization. The skins can include information such as background images, color of the text, fonts used for the address book, icons or other visual information.
Address subsets may be dynamic. Thus, an address subset could be based on a current status, such as a presence, location, among others of the viewer and of the person whose contact information is shown. The address subset may also be pseudo-static and thus, dependent on certain rules defined by the content information owner (e.g.: includes phone and cell phone during the day, but only cell phone in the evening). These rules are applied to build an external identity when someone requests contact information for the first time or for subsequent updates. Rules may also include validation on whether the requesting contact belongs to certain groups, clubs, geographical locations, among others.
References are now made to
Some external identity selections settings can be associated to each external identity of a contact in an address book. For example, a “work address subset” can be shown as active or default from 9 a.m. to 6 p.m. A driving address subset could be shown between 8 a.m. and 9 p.m. and 6 p.m. and 7 p.m. A no phone calls address subset can be shown at night. A home address subset could be shown at other times.
In the example of
The example of
The address subset could also be changed based on a location field which could be use by any location type methods such as GPS, AGPS, cell ID, SSID, WLAN, etc. 434.
The address subset could also be changed based on a Bluetooth proximity field 436.
The address subset could also be changed based on an alternative radio access field (e.g.: WIFI zone) 438.
The address subset could also be changed based on a custom field 440.
In particular, time field 432 could indicate that between certain times, a certain address subset should be active, and could also indicate which external identity to switch to after the time expires. In the example of
The location field (e.g. GPS) 434 could, for example, be used to indicate that if the user within a certain geographic area, a work address subset could be activated. Alternatively, if the user is in a different location corresponding to the user's home, the home field could be activated. Alternatively, if the user is in a user that does not match work or home, a travel external identity could be utilized.
Bluetooth proximity field 436 could indicate that if the device is capable of communicating via Bluetooth, then a certain address subset should be switched to.
Similarly, if an alternative radio access field 438 which could be used for WiFi zone, Bluetooth, WiMax, LTE, etc, could indicate that if the device is capable of communicating over the alternative radio access methods, a certain address subset should be switched to.
A custom field 440 could be utilized to create rules, for example, if various fields present conflicting information about which address subset to switch to. This could be used to indicate which fields take precedence, among others. The custom field could also utilize other criteria than those indicated above.
Utilizing the example of
After 6 pm, a home address subset could be specified by the user. In this case, if the receiving party does not have rights to receive the home address subset, the work address subset may still be provided to the receiving party, but with less fields. For example, if the work address subset includes a work telephone number during business hours, this may be removed after business hours since the user cannot be reached at that number.
As what will be appreciated, when sharing a user's information, the settings would apply and the user information is displayed according to his or her contacts.
In a further embodiment, the user could provide communication preferences for each of the different address subsets. The preferred communications method could appear first or appear highlighted and alternative communications information could be available only when expanding the contact details in an address book.
Reference is now made to
In a further embodiment, if the address book allows multiple variants for the same communication method, the information displayed for the contact external identity should be shown with the preferred variant for each communications method as the obvious choice. Thus, for example, if a contact has multiple emails addresses and it if is possible to send an email from the address book, the address book should show by default the preferred email address for the address subset of the contact offered to the address book owner. If this address subset contains other email address for the contact, these could be shown upon additional action such as expanding a drop down list, scrolling, menu selection, among others.
Further, if a communication application on the device allows communicating by selecting a contact from the address book, the user should only view the address subset, contact, and the default valid email address, instant messaging identifier, among others, according to the current contact external identity, which will by default be used by the communications application. For example, a receiving party wants to email John Smith. John Smith has multiple emails addresses, but one that is set for the default address for the current contact external identity. Thus, if the receiving party is utilizing an email application and selects John Smith, the email application should utilize the default email address when creating the email to be sent.
As will be appreciated by those skilled in the art, the above works both for both non-connected and non-shared address books, as well as the connected and network based address books described above.
As will be appreciated, if an address book is a network based address book, various other information may be available to the address book that can be integrated into the address book.
In a first embodiment, presence information could be available and integrated with the address book. This could significantly increase the value of contact information in the address book. Instant messaging status and presence information could appear in the contact field when relevant. Further, the available communications method could be reflected in the different address subsets.
Reference is now made to
In other embodiments, a presence time stamp 640 could be provided to indicate easily to a user that the contact is in a time zone which is ahead or behind of the user's current time zone by a certain amount of time.
As will be appreciated by those skilled in the art, presence information usually requires frequent updates by communications between the device and the present platform. One way to save device resources and bandwidth would be to integrate into the address book the presence information of a contact, that is also a contact in an instant messaging application, the presence status of the contact in the instant messaging application.
In a further embodiment, the user's own presence status could be updated by signaling, as part of a message, the user's state. One example of signaling could be how long since the user's last interaction with the device. This status identifier could be posted to the presence server (e.g. via the host server (email, MMS, SMS servers) or an intermediate server (or gateway), which can pass the information to the presence server). In this case, a converged address book utilized presence information and the converged address book server in the network retrieves this information from the presence platform and the address book of each user can be updated with the presence states of the contacts.
An example of this is found in PCT publication WO 2005/017770, the contents of which are incorporated herein by reference. This document describes a system and method for integration between an address book and instant messaging application on a mobile device. This is for offering a consolidated view of a contact's address information and instant messaging handle (contact) and through an aggregated UI a user be made aware of a contacts individual or group IM presence status as well as initiating IM related operations such as initiating an individual or group IM conversation based on access to the address book and Instant messaging databases. Furthermore the document includes use of APIs for IM and Address book to allow for the aggregated data view to be presented both by the Address Book and IM UI. Additionally the API's can be used to add new entries, edit existing ones and also reflect IM contact presence information. The API for the aggregated data view provides an indirection repository based on VM object based storage for storing API entry points. The Address Book application incorporates a schema where metadata can identify the address book and instant messaging related fields for the Address Book UI. In the Address Book UI a buddy list can be displayed and IM actions such as starting an individual or group conversation can be performed. Within the UI as previously mentioned both individual and group presence availability is reflected. Furthermore contact name and IM handles are displayed side by side in the UI for improved association.
Additionally, in order to limit the communication between client and servers for presence status, if presence information is sent to the device and integrated into the address book to update contact information, the display of presence information in the user interface can be modified, over time or turned to inactive if the period between the two subsequent updates of presence information is over a predefined time threshold.
PCT publication WO 2005/060221, the contents of which are incorporated herein by reference relates to a set of rules to a contact profile (address book entry) on a mobile device where the rules indicate what method of communication (phone, email, text) the contact prefers to receive. When the mobile user sends a message to the contact the preferred method of communication is used based on the rules applied to the contact's profile.
PCT publication WO 2005/027383, the contents of which are incorporated herein by reference, relates to presence information, which is typically in the form of “available”, “away” and “disconnected”. In addition, the user can typically set their own state, to either one of the predefined ones, or a custom one like “at the gym”, but most users rarely configure a custom state. On a mobile device with telephone and organizer functionality, it is possible to automatically set and unset a few additional states, including “on the phone” when a phone call starts and ends, or “in a meeting”, if the Calendar has an appointment for the current time period. It's also possible to set additional states based on some applications or services being active or not, or based on inactivity timeouts. This reference shows how this rich presence information could be presented to the user, with icons and strings.
U.S. patent application Ser. No. 11/567,260, the contents of which are incorporated herein by reference, relates to a method and apparatus to maintain accurate presence information for a given mobile device without introducing substantial new traffic to the wireless network by deriving mobile device presence information by analyzing or monitoring the traffic going to and from the mobile device.
The address book could be also associated with a calendar for the user. If this is the case, the availability status can be updated based on calendar information. For example, if in the work external identity, when the user is in a meeting, the user can be shown as ‘busy’. If the receiving party is within the same corporate domain, additional information could also be displayed to the receiving party when viewing the contact information. Thus, for example, the contact can be shown as busy and in a meeting with John Smith until 11:30 a.m. Similarly, if the user is shown as out of the office, the address book user interface can reflect this and the preferred method of communication can be altered. For example, if the user is out of the office, the preferred method of communication can be shown as cell phone first and office phone number last.
Reference is now made
In a further embodiment, the address book can also be integrated with a corporate private branch exchange (PBX). In this case, the preferred contact method can reflect that the user is on a call and the message will be derived to a voice mail.
Reference is now made to
As will be appreciated by those skilled in the art, when an address book is regularly synchronized or connected with a centralized address book, the detection of relevant user external identities can be updated on a more accurate basis.
For example, if user is roaming or traveling in a different time zone, the user's device could retrieve the local time and notify the central address book to switch the contact information for the user to a “travel address subset” for other users. This could be done manually or automatically on user settings. Further, the time zone offset could be made available as part of the traveling addresses subset for other users. Additionally the availability status of the user is switch to the relevant state.
As will be appreciated, if the address books are connected through a presence system, the above could also be achieved.
Further, if the device is location enabled for example GPS enabled or GPS assisted, the traveling address subset could be updated with the latest location of the user. As will be appreciated by those skilled in the art, when referring to GPS in the present disclosure, other location methods are equally applicable, including waypoints, CGI, service set identifier (SSID), among others. The user's GPS location could then be used to offer location-based services such as directions to or from another contact in the address book, local weather information for the contact, nearby points of interest, information, meeting or conference rooms in the vicinity, among others. This could, as will be appreciated, be displayed in the address book. Referring to
Further, other means to switch from one external identity to another would be apparent to those skilled with the art having regard to the above. Specifically, if a user switches the external identity manually, upon GPS location, upon time, upon Bluetooth or WIFI zone detection for known areas such as work or home, this could be reflected in the address book.
In a further embodiment, the address book could be connected to a social network system or application. Examples include Facebook™ or Plaxo™. In this regard, additional information such as personal events could be reflected for the address subset. For example, the address book could display the birthday or anniversary date for a personal external identity, personal URLs.
Reference is now made to
As will be appreciated, the social networks could be used for other information, such as utilizing an avatar instead of a user's picture or utilizing an updated picture for the social network. Such information may not be initially part of the shared contact information and can be added or restored as part of the contact details. Additional information could also follow a different storage or sharing policy according to the user, contact or service provider or based on preference settings.
In a further embodiment, notification of changes from contact could be reflected in the address book utilizing various visual aspects such as different colors, different fonts, and different backgrounds, among others. Thus, if a user changes his or her telephone number, viewers of this contact could see the telephone in red until they selected the contact or interacted with that contact. The viewer may have the choice of accepting or refusing all or part of the changes. A user, in some embodiments, could automatically accept all or part of the changes for all contacts or all or part of the changes for certain category of contacts.
Referring to
In a further embodiment, a free field could allow a user to advertise specific information by entering the information manually in the free field, entering a URL to an RSS field or other similar means that could allow a user's contacts to see an icon, information, advertisements, recommendation that would have been selected directly or indirectly by the user. The free field can be directed or used by a particular application, such as an advertisement solution, a specific category of social networking tool, a mood or smiley from an instant messaging application, among others.
In a further embodiment, if a receiving party is set to a particular external identity, his or her address book can be set to present him or her with a subset with his or her contacts that will be relevant to that particular external identity. For example, if the receiving party is in the “travel address subset” but is on holiday, the receiving party may choose to see only personal contacts in his or her address book and/or a subset of the professional contacts such as close team members. Additionally, the receiving party will be shown with his or her travel address subset, but be displayed as not available or with minimal information to non-personal contacts.
The above therefore provides for formatting and use of address subsets based on a receiving party's information.
The network or converged address book is defined as a centralized address book that contains users and contacts information on behalf of converged address book users (subscribers). The converged address book provides the methods to create the different external identities for the users.
One particular method of a network/converged address book to define and create external identities on behalf of a user is shown with regard to
Reference is now made to
In the case of a network address book, users can upload a full set of their contact information. The network address book will create a different mask in views of the user when his or her contact is required by others. Particularly, when another user is authenticated as a “professional contact” the mask “office” could be applied to the contact information before it is delivered.
In the case of
When a mobile device 1430 contacts CAB server 1420, a processing module 1440 includes an authentication, authorization and notification module 1444, a transformation module 1446 and a rules module 1448. Authentication, authorization and notification module 1444 is utilized to authenticate the mobile device 1430 utilizing any technique known to those skilled in the art, authorize for access to contact data, and notify about the changes in the known external identities. Further, when the mobile device 1430 wants to retrieve contact information for a contact, the data is then transformed by module 1446 with respect to the rules applied by module 1448 to data that is stored in CAB database 1410. The transformations and rules may be applied prior to the data request from the mobile device 1430 and the requested external identities may already be stored and ready for retrieval in the CAB database 1410.
CAB information or information from a local address book can be stored on mobile device 1430 within an internal or external memory. Examples of such memory are known to those skilled in the art, and for external memory can include a (universal) subscriber identity module ((U)SIM), removable user identity module (RUIM), Compact Flash, MicroSD, memory sticks, among others. A mobile device can then write to the external or internal memory and read from it.
The exemplary steps of the above CAB server 1420 may include:
As will be appreciated by those skilled in the art, the exemplary steps of CAB server 1420 identified above are not limiting, and other implementations would be evident to those skilled in the art.
In addition to the above, additional steps could adapt the data to the user devices capabilities. For instance the XSLT transformation could provide a vCard, extended vCard, hCard, or HTML document to deliver the contact external identities to a particular device.
Additionally, to simplify the mask creation, a hierarchical graph structure (e.g. nested XML document) could be used, where a node works as a category definition. Any fields can be freely linked to any external identity or to any category. Some categories may be present in a CAB but not link to any external identity. (e.g.: for a period of time, based on user selection etc) The address book display of fields is based on a selected external identity but not on standalone categories. For example, a work category means displaying work information first, along with a preferred communications channel. Other information could be available or not depending on permissions, and utilize different levels of access (e.g. see all in a menu, or scroll further down etc).
Additionally the rules and policy of a given mask could facilitate the update of an external identity based on dynamic modification of information that is part of a group, category or external identity. For instance the User Interface could display a small difference of the social community icon if information from the social community node has been updated. For resource reasons, such updating in the UI could be provided based only on a user subscription or on specific devices condition (WiFi, LAN connections, plugged devices etc).
Reference is now made to
A user has a link to a personal node 1520, which defines personal information such as name 1522, birthdate 1524, among others.
A user further has a link to a Social Community (SC) node 1530. SC node 1530 includes information such as hobbies 1532, favorite URLs 1534, SC IDs 1536, among others.
Identity A 1512 is associated with a work node 1540, which includes various information such as a work phone 1542, a work email 1544, and an alternate email 1546, among others.
Identity B 1514 is associated with a home node 1550. Home node 1550 includes a home address 1552, a home phone 1554, and an email address 1556, among others.
Identity C 1516 is associated with a travel node 1560. Travel node 1560 includes information such cell phone number 1562, a location 1564, among others.
Identity A 1512 and identity B 1514 also have a link to a cell phone number 1562, thereby providing the ability to display this number associated with this external identity.
Identity A 1512 also includes information about group subscriptions 1570. The above therefore provides for the linking of fields to any external identity or any category based on a hierarchical graphical structure.
Further, CAB rules and transformation components could be abstraction layer above, for example, a Lotus notes or a Microsoft exchange server where could be stored contacts and users information. This is shown by Microsoft exchange server 1460 and Lotus notes server 1462 in
Additionally, the CAB mask can be based on PEEM policies and methods. The OMA PEEM policies would apply as a set of rules in module 1448 of
Reference is now made to
The process starts at step 1610 and proceeds to step 1620, in which a set of address book field and value information (one or more external identities) are created by applying rules, mask and PEL policies.
The process then proceeds to step 1630 in which the one or more external identities are forwarded to a receiving party.
The embodiments described herein are examples of structures, systems or methods having elements corresponding to elements of the techniques of this application. This written description may enable those skilled in the art to make and use embodiments having alternative elements that likewise correspond to the elements of the techniques of this application. The intended scope of the techniques of this application thus includes other structures, systems or methods that do not differ from the techniques of this application as described herein, and further includes other structures, systems or methods with insubstantial differences from the techniques of this application as described herein.
This is a divisional application of U.S. patent application Ser. No. 11/952,804 filed Dec. 7, 2007.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11952804 | Dec 2007 | US |
| Child | 13015808 | US |
