System and method for managing multiple external identities of users with local or network based address book

FIELD OF THE DISCLOSURE

p-0002The present disclosure relates to address books, and in particular the managing of contact information in a local and a network address book.

BACKGROUND

p-0003An 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.

p-0004The 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.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0005The present disclosure will be better understood with reference to the drawings in which:

p-0006<figref idrefs="DRAWINGS">FIG. 1</figref> is an exemplary user interface for a contact with a work external identity;

p-0007<figref idrefs="DRAWINGS">FIG. 2</figref> is an exemplary user interface for a contact with a home external identity;

p-0008<figref idrefs="DRAWINGS">FIG. 3</figref> is an exemplary user interface for a contact with a travel external identity;

p-0009<figref idrefs="DRAWINGS">FIG. 4</figref> is an exemplary user interface for assigning transition information for different external identities;

p-0010<figref idrefs="DRAWINGS">FIG. 5A</figref> is an exemplary diagram of an address book showing the user interface when scrolling over a particular user;

p-0011<figref idrefs="DRAWINGS">FIG. 5B</figref> is an exemplary diagram of an address book showing the user interface when clicking on a particular user;

p-0012<figref idrefs="DRAWINGS">FIG. 6</figref> is an exemplary diagram of an address book showing integration of presence information;

p-0013<figref idrefs="DRAWINGS">FIG. 7</figref> is an exemplary diagram of an address book showing integration with work status information;

p-0014<figref idrefs="DRAWINGS">FIG. 8</figref> is an exemplary diagram of an address book showing integration of a corporate PBX;

p-0015<figref idrefs="DRAWINGS">FIG. 9</figref> is an exemplary diagram of an address book showing integration with GPS information;

p-0016<figref idrefs="DRAWINGS">FIG. 10</figref> is an exemplary user interface showing a contact having GPS information.

p-0017<figref idrefs="DRAWINGS">FIG. 11</figref> is an exemplary diagram of an address book showing integration with a social networking server;

p-0018<figref idrefs="DRAWINGS">FIG. 12</figref> is an exemplary diagram of an address book showing change information in a different font;

p-0019<figref idrefs="DRAWINGS">FIG. 13</figref> is a block diagram showing the application of masks and contexts to contact data;

p-0020<figref idrefs="DRAWINGS">FIG. 14</figref> is a block diagram of an exemplary mobile system having a converged address book server;

p-0021<figref idrefs="DRAWINGS">FIG. 15</figref> is a block diagram of a hierarchical structure for relating external identities, nodes and values; and

p-0022<figref idrefs="DRAWINGS">FIG. 16</figref> is a flow diagram of an exemplary method according to the present disclosure.

DETAILED DESCRIPTION

p-0023The 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.

p-0024A 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.

p-0025An 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 requester.

p-0026The 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.

p-0027The 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.

p-0028Further, an address book on a mobile device could be synchronized with a network based address book to accomplish the above.

p-0029The 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.

p-0030The 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.

p-0031In 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.

p-0032The address book provides notification of the users 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).

p-0033Reference is now made to <figref idrefs="DRAWINGS">FIG. 1</figref>. <figref idrefs="DRAWINGS">FIG. 1</figref> shows a user's contact information when the person accessing the contact information has been identified as a “work” contact. In <figref idrefs="DRAWINGS">FIG. 1</figref>, address subset <b>110</b> can include an external identity portion <b>120</b> that includes, for example, a user's name, company, and title among others. A field <b>122</b> could also indicate the type of external identity that is being shown.

p-0034In the example of <figref idrefs="DRAWINGS">FIG. 1</figref>, the address subset <b>110</b> includes various contact information <b>130</b>, including an email address <b>132</b>, a work phone number <b>134</b>, a Skype™ address <b>136</b>, and an IM address <b>138</b>.

p-0035The address subset <b>110</b> further includes a work address <b>140</b>.

p-0036Referring to <figref idrefs="DRAWINGS">FIG. 2</figref>, a home address subset <b>210</b> is presented to contacts that have been identified to receive the “home” address subset.

p-0037Address subset <b>210</b> includes identification information <b>220</b> and information about the external identity type <b>222</b>.

p-0038Further, a contact information area <b>230</b> is provided. In contact information area <b>230</b>, an email address <b>232</b>, a home phone number <b>234</b>, a mobile phone number <b>236</b>, and an IM address <b>238</b> are provided.

p-0039A home address field <b>240</b> is also provided to contacts receiving the “home” address subset.

p-0040Referring to <figref idrefs="DRAWINGS">FIG. 3</figref>, <figref idrefs="DRAWINGS">FIG. 3</figref> shows an address subset <b>310</b> that is designated as a “travel” address subset. Under the travel address subset <b>310</b>, identification field <b>320</b> is provided including the name, company and position title. An external identity type field <b>322</b> is also presented in some embodiments.

p-0041A contact information area <b>330</b> is provided in address subset <b>310</b>. Contact information <b>330</b> includes an email address <b>332</b>, a mobile phone number <b>334</b>, and an instant messaging address <b>336</b>.

p-0042Further, address subset <b>310</b> includes a work address <b>340</b> and a home address <b>350</b>.

p-0043When comparing <figref idrefs="DRAWINGS">FIGS. 1</figref>, <b>2</b> and <b>3</b>, it will be apparent to those skilled in the art that both the fields and the information within the fields change based on the type of address subset. Specifically, in <figref idrefs="DRAWINGS">FIG. 1</figref>, the work address subset <b>110</b> includes a work email address that is different from the home email address <b>232</b> in address subset <b>210</b> of <figref idrefs="DRAWINGS">FIG. 2</figref>.

p-0044Also, the instant messaging contact information <b>138</b> from <figref idrefs="DRAWINGS">FIG. 1</figref> is different from that of <b>336</b> of <figref idrefs="DRAWINGS">FIG. 3</figref>. Thus, both the fields that are presented to a user and the information within these fields can vary based on the address subset.

p-0045The above references to <figref idrefs="DRAWINGS">FIGS. 1</figref>, <b>2</b> and <b>3</b> therefore provide for address subsets to be set based on the static information of the category of receiving party.

p-0046The above could be, for example, implemented using an extension to the vCard. A standard vCard example includes:

p-0047<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>BEGIN:VCARD</entry></row><row><entry /><entry>VERSION:3.0</entry></row><row><entry /><entry>FN:Joe Smith</entry></row><row><entry /><entry>TEL;WORK: +1-111-111-1111</entry></row><row><entry /><entry>TEL;HOME: +1-222-222-2222</entry></row><row><entry /><entry>TEL;CELL:+1-333-333-3333</entry></row><row><entry /><entry>URL: http://www.example.org/joesmith</entry></row><row><entry /><entry>EMAIL;INTERNET:joe.smith@example.org</entry></row><row><entry /><entry>END:VCARD</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0048As 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:

p-0049<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><div id=”hcard-Joe-Smith” class=vcard”></entry></row><row><entry>  <a class=“url fn”</entry></row><row><entry>  href=“http://www.example.org/joesmith”>Joe Smith</a></entry></row><row><entry>  <a class=“email”</entry></row><row><entry>href=“mailto:joe.smith@example.org”>joe.smith@example.org</a></entry></row><row><entry>  <div class=“tel”></entry></row><row><entry>    <span class=”type”> WORK</span> +1-111-111-1111</entry></row><row><entry>  </div></entry></row><row><entry>  <div class=“tel”></entry></row><row><entry>    <span class=”type”> HOME</span> +1-222-222-2222</entry></row><row><entry>  </div></entry></row><row><entry>  <div class=“tel”></entry></row><row><entry>    <span class=”type”> CELL</span> +1-333-333-3333</entry></row><row><entry>  </div></entry></row><row><entry></div></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0050The above could be extended by adding two fields to a vCard format. These fields include: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0048">1) VIEW EXTERNAL IDENTITY—A view external identity type will indicate the view external identity this vCard will represent. Therefore, for multiple external identity of the same user multiple vCard's need to be created with a different matching view external identity value and associated information;</li><li id="ul0002-0002" num="0049">2) VIEW SKIN URL—A view skin uniform resource locator (URL) represents the URL to the “skin” of the UI that should be applied to the current external identity view.</li></ul></li></ul>

p-0051With the extensions to the above vCard format, examples with multiple views could include:

p-0052<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>External identity/View 1 (Personal)</entry></row><row><entry>BEGIN:VCARD</entry></row><row><entry>VERSION:3.0</entry></row><row><entry>FN:Joe Smith</entry></row><row><entry>VIEW EXTERNAL IDENTITY: Personal</entry></row><row><entry>VIEW SKIN URL:http://www.example.org/joesmith/skins/personal</entry></row><row><entry>TEL;HOME: +1-222-222-2222</entry></row><row><entry>TEL;CELL:+1-333-333-3333</entry></row><row><entry>URL: http://www.example.org/joesmith</entry></row><row><entry>EMAIL;INTERNET:joe.smith@example.org</entry></row><row><entry>END:VCARD</entry></row><row><entry>External identity/View 2 (Professional)</entry></row><row><entry>BEGIN:VCARD</entry></row><row><entry>VERSION:3.0</entry></row><row><entry>FN:Joe Smith</entry></row><row><entry>VIEW EXTERNAL IDENTITY: Professional</entry></row><row><entry>VIEW SKIN URL:http://www.example.org/joesmith/skins/professional</entry></row><row><entry>TEL;WORK: +1-111-111-1111</entry></row><row><entry>TEL;CELL:+1-333-333-3333</entry></row><row><entry>URL: http://www.example.org/joesmith</entry></row><row><entry>EMAIL;INTERNET:joe.smith@example.org</entry></row><row><entry>END:VCARD</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0053As with the above, the vCard can be mapped to hCard:

p-0054<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>External identity/View 1 (Personal)</entry></row><row><entry><div id=”hcard-Joe-Smith” class=vcard”></entry></row><row><entry>  <a class=“url fn”</entry></row><row><entry>  href=“http://www.example.org/joesmith”>Joe Smith</a></entry></row><row><entry>  <a class=“email”</entry></row><row><entry>href=“mailto:joe.smith@example.org”>joe.smith@example.org</a></entry></row><row><entry>  <div class=“tel”></entry></row><row><entry>    <span class=”type”> HOME</span> +1-222-222-2222</entry></row><row><entry>  </div></entry></row><row><entry>  <div class=“tel”></entry></row><row><entry>    <span class=”type”> CELL</span> +1-333-333-3333</entry></row><row><entry>  </div></entry></row><row><entry>  <div class=”view external identity”>Personal</div></entry></row><row><entry>  <a class=”view skin URL” href=”</entry></row><row><entry>http://www.example.org/joesmith/skins/personal” >View Skin URL</a></entry></row><row><entry></div></entry></row><row><entry>External identity/View 2 (Professional)</entry></row><row><entry><div id=”hcard-Joe-Smith” class=vcard”></entry></row><row><entry>  <a class=“url fn”</entry></row><row><entry>  href=“http://www.example.org/joesmith”>Joe Smith</a></entry></row><row><entry>  <a class=“email”</entry></row><row><entry>href=“mailto:joe.smith@example.org”>joe.smith@example.org</a></entry></row><row><entry>  <div class=“tel”></entry></row><row><entry>    <span class=”type”> WORK</span> +1-111-111-1111</entry></row><row><entry>  </div></entry></row><row><entry>  <div class=“tel”></entry></row><row><entry>    <span class=”type”> CELL</span> +1-333-333-3333</entry></row><row><entry>  </div></entry></row><row><entry>  <div class=”view external identity”>Professional</div></entry></row><row><entry>  <a class=”view skin URL” href=”</entry></row><row><entry>http://www.example.org/joesmith/skins/professional” >View Skin</entry></row><row><entry>URL</a></entry></row><row><entry></div></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0055As 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.

p-0056Views 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.

p-0057Address 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.

p-0058References are now made to <figref idrefs="DRAWINGS">FIG. 4</figref>.

p-0059Some 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. <figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a menu for setting and creating such defaults.

p-0060In the example of <figref idrefs="DRAWINGS">FIG. 4</figref>, four address subsets are provided. The example <figref idrefs="DRAWINGS">FIG. 4</figref> includes a work subset <b>412</b>, a travel subset <b>414</b>, a home subset <b>416</b>, and a temporary subset <b>418</b>.

p-0061The example of <figref idrefs="DRAWINGS">FIG. 4</figref> further includes settings to change between the address subsets. Thus, in the example of <figref idrefs="DRAWINGS">FIG. 4</figref>, the address subset could be selected based on manual selection <b>430</b>. The address subset could also be changed based on time field <b>432</b>.

p-0062The 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. <b>434</b>.

p-0063The address subset could also be changed based on a Bluetooth proximity field <b>436</b>.

p-0064The address subset could also be changed based on an alternative radio access field (e.g.: WIFI zone) <b>438</b>.

p-0065The address subset could also be changed based on a custom field <b>440</b>.

p-0066In particular, time field <b>432</b> 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 <figref idrefs="DRAWINGS">FIG. 4</figref>, time field <b>432</b> includes a start time and an end time and indicates that it should change to a home address subset when the end of time has expired.

p-0067The location field (e.g. GPS) <b>434</b> 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.

p-0068Bluetooth proximity field <b>436</b> could indicate that if the device is capable of communicating via Bluetooth, then a certain address subset should be switched to.

p-0069Similarly, if an alternative radio access field <b>438</b> 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.

p-0070A custom field <b>440</b> 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.

p-0071Utilizing the example of <figref idrefs="DRAWINGS">FIG. 4</figref>, a receiving party wants contact information for a user. If the receiving party is designated as a work colleague, the user may have set the address book to only provide a work address subset to work colleagues. During the hours of 9 am to 6 pm, from the settings in <figref idrefs="DRAWINGS">FIG. 4</figref> a complete address subset for work could be presented to the receiving party.

p-0072After 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.

p-0073As 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.

p-0074In 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.

p-0075Reference is now made to <figref idrefs="DRAWINGS">FIG. 5A</figref>. In <figref idrefs="DRAWINGS">FIG. 5A</figref>, when a user scrolls over a name the preferred communications method is displayed. In the case of <figref idrefs="DRAWINGS">FIG. 5A</figref>, the home phone number <b>510</b> is the preferred communications method for this particular receiving party, and thus, the home phone number <b>510</b> is displayed. If the viewer then clicks on the contact, other information such as the cell phone number and a Phone over IP, e.g.: Skype™, identifier appear. This is illustrated in <figref idrefs="DRAWINGS">FIG. 5B</figref>, where mobile number <b>520</b> and Skype™ information <b>530</b> are displayed. The home phone number <b>510</b> remains for both the embodiments of <figref idrefs="DRAWINGS">FIG. 5A</figref> and <figref idrefs="DRAWINGS">FIG. 5B</figref>.

p-0076In 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.

p-0077Further, 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.

p-0078As 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.

p-0079As 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.

p-0080In 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.

p-0081Reference is now made to <figref idrefs="DRAWINGS">FIG. 6</figref>.

p-0082<figref idrefs="DRAWINGS">FIG. 6</figref> shows an address book in which contact information has presence information included therein. For example, in <figref idrefs="DRAWINGS">FIG. 6</figref>, the present “external identity” status is shown in field <b>612</b>. Also, icons <b>620</b> are provided that could reflect the presence information for a user.

p-0083In other embodiments, a presence time stamp <b>640</b> 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.

p-0084As 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.

p-0085In 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.

p-0086An 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.

p-0087Additionally, 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.

p-0088PCT 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.

p-0089PCT 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.

p-0090U.S. patent application Ser. No. 11/567,260, the contents of which are incorporated herein by reference, relates to a method and apparatus to maintains 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.

p-0091The 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.

p-0092Reference is now made <figref idrefs="DRAWINGS">FIG. 7</figref>. <figref idrefs="DRAWINGS">FIG. 7</figref> shows an address book that utilizes calendar information to update the address book. For example, a receiving party looking at contact <b>712</b> sees that the contact <b>712</b> is in a meeting until 2:30 p.m. and an icon <b>714</b> indicates that communication is not possible with the user.

p-0093In 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.

p-0094Reference is now made to <figref idrefs="DRAWINGS">FIG. 8</figref>. <figref idrefs="DRAWINGS">FIG. 8</figref> shows an address book in which the address book integrated with a corporate PBX. In this case, the corporate PBX provides information that a contact <b>812</b> is currently on a call, which might provide a receiving party the ability to go directly to voice mail or to not attempt the call until contact <b>812</b> is off the phone.

p-0095As 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.

p-0096For 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.

p-0097As will be appreciated, if the address books are connected through a presence system, the above could also be achieved.

p-0098Further, 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 <figref idrefs="DRAWINGS">FIG. 9</figref>, a contact <b>912</b> includes GPS enabled device information, such as where the user currently is. Referring to <figref idrefs="DRAWINGS">FIG. 10</figref>, if a viewer has clicked on the contact <b>912</b> from <figref idrefs="DRAWINGS">FIG. 9</figref>, the information for the user <b>1010</b> is presented and a last location area <b>1020</b> is provided indicating the last location of the user. Further, a request button update <b>1022</b> could be provided to the user to update the location of the user whose information is displayed. Alternatively, a periodic update could be performed by the device.

p-0099Further, 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.

p-0100In 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.

p-0101Reference is now made to <figref idrefs="DRAWINGS">FIG. 11</figref>.

p-0102<figref idrefs="DRAWINGS">FIG. 11</figref> shows an address book in which a social network system has been integrated. In <figref idrefs="DRAWINGS">FIG. 11</figref>, contact <b>1112</b> is a personal contact, rather than a professional contact and in this case, contact <b>1112</b> includes information that their birthday is in 7 days.

p-0103As 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.

p-0104In 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.

p-0105Referring to <figref idrefs="DRAWINGS">FIG. 12</figref>, <figref idrefs="DRAWINGS">FIG. 12</figref> shows a contact <b>1212</b> in which a mobile phone number has changed. The contact <b>1212</b> shows mobile number <b>1220</b> as different font until it has been selected.

p-0106In 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.

p-0107<figref idrefs="DRAWINGS">FIGS. 4 to 12</figref> therefore provide examples of where dynamic information can be used to make changes to an address subset.

p-0108In 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.

p-0109The above therefore provides for formatting and use of address subsets based on a receiving party's information.

p-0110The 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.

p-0111One particular method of a network/converged address book to define and create external identities on behalf of a user is shown with regard to <figref idrefs="DRAWINGS">FIG. 13</figref>. In <figref idrefs="DRAWINGS">FIG. 13</figref> a mask <b>1310</b> could be applied to information related to a contact. A user would be given the capability to define, upload, and modify all his or her information <b>1320</b> and different external identities <b>1330</b>. When sending his or her information to another user, or when another user retrieves the first user's information from the converged address book, a mask is applied to create the external identity that has to be exposed to the other user. The mask <b>1310</b> contains all necessary rules and information to create or publish the different external identities. The mask can reside within the device or in the network where the address book is stored. In the case of a local address book, the different identities and the mask can be created on the device before sending the contact information. For instance, this could be a new vCard format. In <figref idrefs="DRAWINGS">FIG. 13</figref>, contact information is stored in contact data <b>1320</b> and various external identities are defined by the users and shown as <b>1330</b>.

p-0112Reference is now made to <figref idrefs="DRAWINGS">FIG. 14</figref>.

p-0113In 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.

p-0114In the case of <figref idrefs="DRAWINGS">FIG. 14</figref>, a converged or network address book stores contacts and users information for CAB users in a common database <b>1410</b> which is either located on a network/converged address book (CAB) server <b>1420</b> or accessed remotely by the server. A mobile device <b>1430</b> can either access contact information in CAB directly using one of the data access protocols or to have its local address book synchronized with the CAB server <b>1420</b> and with the CAB database <b>1410</b> utilizing XML vCard format or one of the data synchronization mechanisms; or other means that would be apparent to those skilled in the art. Mobile devices <b>1430</b> are well known in the art, and can include any wireless device, mobile data device, personal digital assistant, digital pager, laptop, or other data device.

p-0115When a mobile device <b>1430</b> contacts CAB server <b>1420</b>, a processing module <b>1440</b> includes an authentication, authorization and notification module <b>1444</b>, a transformation module <b>1446</b> and a rules module <b>1448</b>. Authentication, authorization and notification module <b>1444</b> is utilized to authenticate the mobile device <b>1430</b> 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 <b>1430</b> wants to retrieve contact information for a contact, the data is then transformed by module <b>1446</b> with respect to the rules applied by module <b>1448</b> to data that is stored in CAB database <b>1410</b>. The transformations and rules may be applied prior to the data request from the mobile device <b>1430</b> and the requested external identities may already be stored and ready for retrieval in the CAB database <b>1410</b>.

p-0116CAB information or information from a local address book can be stored on mobile device <b>1430</b> 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.

p-0117The exemplary steps of the above CAB server <b>1420</b> may include: <ul><li id="ul0003-0001" num="0000"><ul><li id="ul0004-0001" num="0115">1—A user synchronizes his or her address book with a CAB server or makes a request to create the contact;</li><li id="ul0004-0002" num="0116">2—The CAB server, after all authorization and security steps have occurred, will search for the relevant data to see if the user is allowed to see the particular content;</li><li id="ul0004-0003" num="0117">3—The CAB server then applies rules according to preferences or policies of the requested contact on the contact information;</li><li id="ul0004-0004" num="0118">4—The CAB server applies a transformation defined in the mask, for example, an XSLT transformation to create an external identity by extracting, filtering, and updating the relevant information from the contact data; and</li><li id="ul0004-0005" num="0119">5—The CAB server transfers the subset of contact data to the requesting user.</li></ul></li></ul>

p-0118As will be appreciated by those skilled in the art, the exemplary steps of CAB server <b>1420</b> identified above are not limiting, and other implementations would be evident to those skilled in the art.

p-0119In 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.

p-0120Additionally, 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).

p-0121Additionally 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).

p-0122Reference is now made to <figref idrefs="DRAWINGS">FIG. 15</figref>. <figref idrefs="DRAWINGS">FIG. 15</figref> shows a user <b>1510</b> that has 3 external identities defined. Specifically, these are shown as identity A <b>1512</b>, identity B <b>1514</b>, and identity C <b>1516</b>.

p-0123A user has a link to a personal node <b>1520</b>, which defines personal information such as name <b>1522</b>, birthdate <b>1524</b>, among others.

p-0124A user further has a link to a Social Community (SC) node <b>1530</b>. SC node <b>1530</b> includes information such as hobbies <b>1532</b>, favorite URLs <b>1534</b>, SC IDs <b>1536</b>, among others.

p-0125Identity A <b>1512</b> is associated with a work node <b>1540</b>, which includes various information such as a work phone <b>1542</b>, a work email <b>1544</b>, and an alternate email <b>1546</b>, among others.

p-0126Identity B <b>1514</b> is associated with a home node <b>1550</b>. Home node <b>1550</b> includes a home address <b>1552</b>, a home phone <b>1554</b>, and an email address <b>1556</b>, among others.

p-0127Identity C <b>1516</b> is associated with a travel node <b>1560</b>. Travel node <b>1560</b> includes information such cell phone number <b>1562</b>, a location <b>1564</b>, among others.

p-0128Identity A <b>1512</b> and identity B <b>1514</b> also have a link to a cell phone number <b>1562</b>, thereby providing the ability to display this number associated with this external identity.

p-0129Identity A <b>1512</b> also includes information about group subscriptions <b>1570</b>. The above therefore provides for the linking of fields to any external identity or any category based on a hierarchical graphical structure.

p-0130Further, 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 <b>1460</b> and Lotus notes server <b>1462</b> in <figref idrefs="DRAWINGS">FIG. 14</figref>.

p-0131Additionally, the CAB mask can be based on PEEM policies and methods. The OMA PEEM policies would apply as a set of rules in module <b>1448</b> of <figref idrefs="DRAWINGS">FIG. 14</figref>. OMA PEEM PEL specification defines the language in which policies can be expressed. The PEL specification includes the definition of language constructs, and may define multiple language options, for the convenience of resolving particular issues. In order to use PEEL for the common adress book the conditions for the address book needs to be define as descrive above. The PEEL policy could then apply to the address book specific conditions. Additionaly an extension of the common PEEL policy may be needed.

p-0132Reference is now made to <figref idrefs="DRAWINGS">FIG. 16</figref>. <figref idrefs="DRAWINGS">FIG. 16</figref> illustrates a flow diagram for a method in accordance with the above.

p-0133The process starts at step <b>1610</b> and proceeds to step <b>1620</b>, 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.

p-0134The process then proceeds to step <b>1630</b> in which the one or more external identities are forwarded to a receiving party.

p-0135The 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.