Address book clearinghouse interface system and method

[0001] The present invention relates in general to computerized address books and in particular to a system and method for providing access to an integrated address book clearinghouse.

[0002] Computerized address books and personal information managers are well known in the computing field. Software applications such as email programs, instant messaging programs and computer fax programs include or have access to computerized address books of one form or another. Such conventional address book utilizing applications generally store address book information locally on a computing device. Often the address books are in incompatible formats, requiring that the information contained in each application's address book be individually keyed in. Even where some of the format fields are common, common information must often be entered multiple times, once for each address book. Some applications have integrated address book in a way that allows a personal information manager, that can send email, stores physical address information along with email addresses. Other address book integration examples include email program address books that include instant messenger handles or fax program address books that include physical addresses and voice phone numbers.

[0003] While integrated address books included in or accessible by applications running on client computers have solved some of the previous problems of having to enter identical or similar information multiple times (once for each different type of program), such address books are ineffective when applications are located on remote computers connected to client computers or devices via a network. More specifically, networks are also well known in the computing field. By definition, a network is a group of computers and associated devices that are connected by communication facilities or links. An internetwork, in turn, is the joining of multiple computer networks, both similar and dissimilar, by means of gateways or routers that facilitate data transfer and conversion from the multiple computer networks. A well known abbreviation for the term internetwork is “internet.” As currently understood, the capitalized term “Internet” refers to the collection of networks and routers that use the Internet protocol to communicate with one another. The Internet has recently seen increased growth by virtue of its ability to link computers based throughout the world. As will be better appreciated from the following description, the present invention could find use in many network environments. However, for purposes of discussion, the Internet is used as an exemplary network environment for implementing the present invention.

[0004] The Internet has quickly become a popular method of disseminating information due, in large part, to its ability to deliver information quickly and reliably. To retrieve online resources or other data over the network, a user typically uses communications or network browsing software. A common way of retrieving online resources is to use such communications or network browsing software to access online resources at a uniform resource identifier (“URI”) address such as a uniform resource locator (“URL”) address that indicates the location of the online resources on a server connected to the network or internetwork.

[0005] As the Internet (and other networks) have developed some of the address book utilizing applications that were formerly performed on client devices are now provided by online resources accessed via the network. One example is a Web-based email network application. As a result, the storage of address book information was shifted from client devices to online accessible devices. Online address book information storage eliminates the need for a user to export address book information when the user changes to a new device and/or adds a new device to the user's inventory of devices.

[0006] Prior attempts have been made to integrate separate address book information associated with network applications. One example is an integrated online contact list that compares all addresses in an online contact list to the addresses in an online buddy list to determine which contacts in the contact list should have an indicator showing that the contact has its instant messaging capabilities enabled (contacts with instant messaging capabilities are commonly referred to as “buddies”). This system is inefficient and stores unnecessarily redundant information. More specifically, this system retains two separate lists, an online contact list and an online buddy list, each of which can be separately updated. If inconsistent information is added to either list, their comparisons and pairings break down. For example, if the email address of a contact in the address book of a Web based email application was different than the email address of a buddy in the address book of a Web based instant messenger application, the pairing between the two is broken unless some other type of link is used to maintain the pairing.

[0007] Even though such prior attempts allowed for secure access to a user's network-based application's address book information, the information was not available to an authenticated user in an integrated fashion.

[0008] Accordingly, there is a need for an address book information clearinghouse, and an interface thereto, that provides secure access and management of address book information for particular users to multiple client device applications and/or network-based applications. It is desirable that any address book clearinghouse interface accept and provide information in an application independent manner.

[0009] The present invention is directed to a programming interface, system, and computer-readable medium for accessing and managing an integrated online address book clearinghouse. One aspect of the present invention provides a programming interface layer with address book management functions for accessing and managing an integrated online address book clearinghouse. The programming interface layer receives application programming interface (“API” or programming interface) calls from applications desiring access and management of address books included in the integrated address book clearinghouse. The programming interface layer executes one or more functions in response to received programming interface calls. The address book functions manage address books by adding, deleting, updating, and finding address books, contacts, and groups of contacts in the integrated address book clearinghouse. Additionally, the functions can manage communications permissions for address books that have communications limitations (e.g., address books for applications with parental control limits or employer-imposed limits). The programming interface layer also uses identity information and any associated identity authentication information to assure that each API call is directed to a desired address book when an address book function is executed. The programming interface layer further includes a parameter processing module for processing function-specific parameters passed in data envelopes to the programming interface layer by the applications. The programming interface layer also includes, in this aspect, a response generating module to generate a function-specific response from an address book function that is encapsulated in a data envelope and sent back to the application that sent an API call to the programming interface layer.

[0010] In some aspects of the present invention, the authentication information associated with identity information is explicitly included as a parameter passed in a data envelope to the programming interface layer.

[0011] As can be seen from the summary above, the present invention provides a programming interface for accessing and managing an online integrated address book clearinghouse system and a related computer-readable medium and system.

[0020] The detailed description which follows is represented largely in terms of processes and symbolic representations of operations by conventional computing components including processors, memory storage devices for the processors, connected display devices, and input devices, all of which are well known in the art. These processes and operations may utilize conventional computing components in a heterogeneous distributed computing environment, including remote storage servers, computer servers, and memory storage devices; such processes, devices, and operations also being known to those skilled in the art and others. Each of these conventional distributed computing components is accessible by the processors via a communications network.

[0021] The present invention is directed to providing a programming interface for managing network accessible address books embodied in an integrated online address book clearinghouse. The programming interface layer in one exemplary embodiment of the present invention is an application programming interface (“API”) with specific address book clearinghouse functions for managing a multitude of network accessible address books shared across multiple devices and applications. One exemplary embodiment of such an API is described in the attached appendix. However, those of ordinary skill in the art and others will appreciate that the attached API description is merely one example of a programming interface suitable for accessing an integrated online address book clearinghouse system and that, within the scope and spirit of the present invention, other APIs are possible.

[0022] FIG. 1 is a pictorial diagram of an exemplary, simplified integrated online address book clearinghouse 100 for providing address book information (address books, contacts, contact groups, etc.) associated with particular users to client devices via the Internet 105. For ease of illustration, a single client device 110 shown pictorially as a personal computer is included in FIG. 1, it being recognized that in actual implementations of the multiple client devices in a variety of forms, including cellular telephones and personal digital assistants (PDAs), would be included. That is, the integrated address book clearinghouse 100 functions in a distributed computing environment that includes a plurality of computing devices interconnected by the Internet 105 (or some other suitable network). In addition to the client device 110, the plurality of computing devices shown in FIG. 1 include an authentication server 115 and a partner server 120. The address books clearinghouse includes a partner front end server 130, a public front end server 200, and an address book clearinghouse storage 150. The client device 110 has computing capabilities and may be any form of device capable of communicating with the other devices of the present invention. As noted above, while the client device 110 is pictorially shown as a personal computer, this depiction should be taken as illustrative and not limiting. As will be appreciated by those of ordinary skill in the art, the authentication server 115, partner server 120, partner front end server 130, public front end server 200 and address book clearinghouse storage 150 may reside on any device accessible, directly or indirectly, by the client device 110, shown in FIG. 1 via the Internet 105. An exemplary public front end server 200 is shown in further detail in FIG. 2 and described below.

[0023] While only a single client device 110, authentication server 115, partner server 120, partner front end server 130, public front end server 200, and address book clearinghouse storage 150 have been shown in FIG. 1, it will be appreciated that many more client devices 110, authentication servers 115, partner servers 120, partner front end servers 130, public front end servers 200, and address book clearinghouse storages 150 can be included in an actual system practicing the present invention. The devices of the address book clearinghouse, namely, the public front end server 200, partner front end server 130, and address book clearinghouse 150 provide access to integrated address book information stored in the address book clearinghouse storage 150. Additionally, while both a public front end server 200 and partner front end server 130 are shown in FIG. 1, it will be appreciated that in alternate embodiments of the present invention, only a public front end server 200 or only a partner front end server 130 may be used without departing from the spirit and scope of the present invention.

[0024] FIG. 2 illustrates an exemplary public front end server 200 suitable for use in the address book clearing house 100 shown in FIG. 1. In its most basic form, the public front end server 200 typically includes at least one processing unit 202 and memory 204. Depending on the exact configuration and type of public front end server 200, memory 204 may be volatile (such as RAM), nonvolatile (such as ROM, flash memory, etc.), or some combination of the two. This most basic configuration is illustrated in FIG. 2 by dashed line 206. The public front end server 200 may also have additional features and/or functionality. For example, the public front end server 200 may also include additional storage (removable and/or nonremovable) including, but not limited to, magnetic or optical discs or tape. Such additional storage is illustrated in FIG. 2 by removable storage 208 and nonremovable storage 210. In general, computer storage media includes volatile and nonvolatile, removable and nonremovable media implemented in any method or technology for storage of computing information (e.g., computer-readable instructions, data structures, program modules, other data, etc.). Memory 204, removable storage 208, and nonremovable storage 210, are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disc storage, or other magnetic storage devices, or any other medium which can be used to store or read desired information and which can be accessed by the public front end server 200. Any such computer storage media may be part of the public front end server 200. The memory 204 of a public front end server 200 practicing the present invention stores an programming interface (API) layer 220 that includes routines for accessing storage resources.

[0025] The public front end server 200 also contains a communications connection 212 that allows the device to communicate with other devices. The communications connection 212 is used to communicate computer-readable instructions, data structures, program modules or other data using a modulated data signal that includes a carrier wave or other transport mechanism modulated by the data to be communicated. By way of example and not limitation, communication connection 212 includes wired connections, both copper and optical, and wireless connections such as acoustic, radio frequency, infrared, etc. Public front end server 200 may also have input device(s) 214 such as a keyboard, a mouse, a pen, a voice input device, a touch input device, etc. Output device(s) 216 such as a display, speakers, a printer, etc., may also be included. Since all these devices are well known in the art, they are not described here.

[0026] Since, in general, the partner front end server 130 can be similar to the public front end server 200 described above, the partner front end server 130 is not described in detail. Similarly, the authentication server 115 and the partner server 120, except for the API Layer 222, can also be similar to the public front end server 200 described above, and these servers are also not described in detail.

[0027] The operation of an integrated address book clearinghouse 100 according to the present invention will be better understood by reference to FIG. 3, which illustrates one exemplary sequence of communication interactions between the client device and selected ones of the servers shown in FIG. 1, and the address book clearinghouse storage 150. The selected servers are the authentication server 115, and the public front end server 200. The exemplary communications interactions shown in FIG. 3 begin by the client device 110 sending 301 an encapsulated address book API call and data envelope to the public front end server 200. Next, the public front end server 200 parses 303 the data envelope to retrieve the API call and any function parameters. In the exemplary communications interactions shown in FIG. 3, the public front end server 200 redirects 305 the client device 110 to the authentication server 115 if the authentication data in the envelope is expired or missing. If this occurs, the client device 110 submits 310 an authentication request to the authentication server 115. Those of ordinary skill in the art and others will appreciate that authentication servers 115 may take many forms. In one exemplary embodiment of the present invention the authentication server 115 is provided by a network authentication service such as Microsoft's NET Passport service. Other authentication servers 115 able to verify a user's identity using conventional authentication techniques may be used as well.

[0028] The authentication server 115 authenticates 315 the identity included in the authentication request 310. After the authentication server has authenticated 315 the identity, authentication credentials are sent 320 back to the client device 110. The authentication credentials may take any form that can be provided by the client device 110 to other devices to indicate that client device 110 is being operated by a user who is allowed to access the address book clearinghouse server 150 via the public front end server 200. One exemplary form of authentication credentials is authentication “cookies.” An authentication cookie is cryptographically signed and encrypted data provided to a client device 110 by an authentication server 115 to persist an identity's authentication at the client device 100. Other exemplary forms of authentication credentials include kerberos tokens and transient cryptographically signed and authenticated access information.

[0029] Next, the client device 110 encapsulates 325 parameters in an address book function data envelope that includes the authentication credentials and other address book function specific parameters. This further (second) encapsulated address book API call and data envelope is then sent 330 to the public front end server 200. The public front end server 200 parses 335 the envelope. Next, the public front end server 200 verifies 340 the encapsulated authentication credentials included in the data envelope. Once the identity of the user is thusly verified, the public front end server sends 345 an clearinghouse function call to the address book clearinghouse storage 150 that corresponds to the address book function specified in the API call. The address book clearinghouse storage 150 processes 350 the clearinghouse function call and returns 355 the function call response to the public front end server 200. The public front end server 200 then encapsulates 360 the function call response in a response data envelope that identifies the API call it is responding to and the identified address book of that call and returns 365 the encapsulated API response data envelope to the client device 110.

[0030] Those of ordinary skill in the art and others will appreciate that the communications interactions illustrated in FIG. 3 provide structured and efficient access to an online address book clearinghouse. If necessary, the request for access can be authenticated prior to allowing access to the address book clearinghouse storage 150. Those of ordinary skill in the art and others will appreciate that FIG. 3 represents only one exemplary set of communication interactions. Others are possible. For example, authenticating an identity by the authentication server 115 may grant the authenticated user permission to send other identities to the public front end server 200, e.g., may grant a parent permission to access address books belonging to a child associated with the parent (and their identity). Address books with parental controlled access and other forms of associated access (such as employer controlled access) are allow one user to control the accesses and communication of another user. Exemplary “ABAllowListSet” (for setting those emails and instant messenger contacts that a particular subsidiary user has access to) and “ABAllowListGet” (for setting the emails and instant messenger contacts that a particular subsidiary user is allowed to receive from) functions are described in greater detail in the Appendix portion of this detailed description.

[0031] The communication interactions illustrated in FIG. 3 between various external devices and devices of the integrated address book clearinghouse 100 may employ any conventional computing communication form. In one exemplary embodiment of the present invention, the communications are formatted using the Simple Open Access Protocol (“SOAP”) with extensible markup language (“XML”) formatted instructions and/or parameters. An exemplary XML formatted instruction for an address book creation request (ABAdd) is illustrated by the following code:

[0032]

TABLE
POST /abservice/abservice.asmx HTTP/1.1
Host: contacts.msn.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: “http://www.msn.com/webservices/AddressBook/ABAdd”
<?xml version=“1.0” encoding=“utf-8”?>
<soap:Envelope xmlns:xsi=
“http://www.w3.org/2001/XMLSchema-instance”
xmlns:xsd=“http://www.w3.org/2001/XMLSchema”
xmlns:soap=“http://schemas.xmlsoap.org/soap/envelope/”>
	<soap:Header>
	<ABApplicationHeader xmlns=
	“http://www.msn.com/webservices/AddressBook”>
	<ApplicationId>
	000000000000000000010010efd4e487</ApplicationId>
	<IsMigration>0</IsMigration>
	</ABApplicationHeader>
	<ABAuthHeader xmlns=
	“http://www.msn.com/webservices/AddressBook”>
	<ManagedGroupRequest>0</ManagedGroupRequest>
	</ABAuthHeader>
	</soap:Header>
	<soap:Body>
	<ABAdd xmlns=“http://www.msn.com/webservices/AddressBook”>
	<abInfo>
	<name></name>
	<ownerEmail>[email protected]</ownerEmail>
	<fDefault>1</fDefault>
	<isMessengerMigrated>0</isMessengerMigrated>
	</abInfo>
	</ABAdd>
	</soap:Body>
</soap:Envelope>

[0033] Those of ordinary skill in the art and others will appreciate that the address book creation request (ABAdd) illustrated above is merely one form of instructions between the FIG. 3 devices and that many other forms of communications may be possible. The attached appendix includes other forms of data envelopes and methods that may be used to communicate between the FIG. 3 devices.

[0034] FIG. 4 is a flow chart illustrating an address book clearinghouse API call routine 400 implemented by the client device 110 for carrying out the communication interactions shown in FIG. 3. The API calling routine 400 begins at block 401 and proceeds to block 405 where parameters for an address book function are encapsulated in an address book API call and data envelope by the calling client device. The data envelope is then sent in block 410 to the public front end server 200. Next, in block 415 an address book function-specific response is received back from the public front end server 200 to the encapsulated address book API call and data envelope sent in block 405. The address book clearinghouse API calling routine 400 then ends at block 499.

[0035] After the public front end server 200 receives the address book API call and data envelope sent by the client device as shown in FIG. 3, the public front end server 200 processes the API call. FIG. 5 illustrates an API call processing routine 500. The API call processing routine 500 begins at block 501 and proceeds to block 505 where both the address book API call and data envelope is received from the client device 110. Next, the data envelope is parsed in block 510 to extract the API call parameters, including the authentication data associated with an address book function being accessed by the API call. The parsing of the data envelope (e.g. by executing an parameter processing module) also identifies which address book function is being called by the API. In block 515, the authentication information in the data envelope is verified (e.g. by executing an identity authentication module). In decision block 520 a determination is made whether the identity identified by the authentication information is authorized to access the called address book function. If the identity is not authorized, processing proceeds to block 560 where an error condition is generated as an address book function response. Processing then continues to block 545 where the address book function response is encapsulated in a data envelope (e.g. by executing an response generating module). In block 550, the data envelope is sent to the client device, after which API call processing routine 500 ends at block 599.

[0036] As will be readily understood by those skilled in the art and others, the path through blocks 560, 545 and 550 may cause the client device to seek authorization credentials for an authorization server 115 as shown in FIG. 3 and described above.

[0037] If in decision block 520 a determination was made that the identity is authorized, then processing proceeds to decision block 530 where a determination is made whether an address book exists for the identity. If no address book is found to exist in decision block 530, processing proceeds to subroutine block 600 where an address book is created for the identity. An address book creating subroutine 600 is illustrated in FIG. 6 and described below. After an address book has been created, and the address book creating subroutine 600 has returned, processing proceeds to block 535. If an address book was found to exist in decision block 530, processing proceeds directly to block 535. At block 535 the clearinghouse function call specified in the received data envelope is sent to the address book clearinghouse storage 150. In block 540, the address book function response is received from the address book clearinghouse storage. Processing then proceeds to block 545 where the address book function response is encapsulated in a data envelope as discussed above. Then, in block 550 the API response data envelope is sent to the client device.

[0038] Those of ordinary skill in the art and others will appreciate that there are many possible API function calls that may be made to an address book clearinghouse. The appendix to this detailed description, includes a number of exemplary address book clearinghouse API function calls. The exemplary API function calls include: ABAdd (for adding a new address book); ABDelete (for deleting an existing address book); ABUpdate (for updating an address book); ABFind (for locating an address book); ABContactAdd (for adding a new contact); ABContactDelete (for deleting an existing contact); ABContactUpdate (for updating a contact); ABContactFind (for finding Contacts), ABFindAll (for gathering all address book, contact and group information); ABFindByContacts (for finding all contacts and any groups containing listed contacts); ABFindByGroups (for locating all contacts in given groups and the groups themselves); ABFindMessengerUsers (for locating contacts with instant messaging capability); ABFindMeContact (for locating the contact for the address book owner); ABGroupAdd (for adding a new group); ABGroupDelete (for deleting an existing group); ABGroupUpdate (for updating a group); ABGroupFind (for locating a group); ABGroupContactAdd (for adding a contact to a group); ABGroupContactDelete (for removing a contact from a group); ABAllowListSet (for setting those emails and instant messenger contacts that a particular subsidiary user has access to); ABAllowListGet (for setting the emails and instant messenger contacts that a particular subsidiary user is allowed to receive from). Those of ordinary skill in the art and others will appreciate that both more and less API function calls may be employed in an address book clearinghouse system, without departing from the spirit and scope of the present invention.

[0039] FIG. 6 illustrates an exemplary address book creating subroutine 600 for creating an identity coupled address book in accordance with the present invention. The address book creating subroutine 600 begins at block 601 and proceeds to block 605 where an address book creation request is received for a specific user identity. In block 610, the address book creation request is sent to the address book clearinghouse storage 150 indicating that an address book should be created for the specified identity. In block 615, an address book creation confirmation is received back from the address book clearinghouse storage. Address book creating subroutine 600 then ends at block 699, returning the address book identification to its calling routine.

[0040] Those of ordinary skill in the art and others will appreciate that address book creating subroutines may include other elements and steps other than those listed above and illustrated in FIG. 6. The “ABAdd” API call listed in the appendix provides exemplary parameters that may be used when creating an address book in accordance with the present invention. The ABAdd API call is presented merely as one example of an address book creating function call, and those of ordinary skill in the art and others will appreciate that there are a myriad of other possible address book creating function calls all of which fall within the spirit and scope of the present invention.

[0041] FIG. 1 illustrates a partner server 120 in communication with devices of the integrated address book clearinghouse 100. A flow chart illustrating an address book clearinghouse API calling routine 800 implemented by the partner server 120, in accordance with one exemplary embodiment of the present invention, is shown in FIG. 7. The API calling routine 700 begins at block 701 and proceeds to block 705 where a function call request is received from the client device 110. Next, in block 710, parameters for an address book function are encapsulated in an address book function-specific data envelope. The data envelope is then sent in block 715 to the partner front end server 120. Next, in block 720 an address book function-specific response is received back from the partner front end server 120 that corresponds to the encapsulated address book function-specific data envelope sent in block 710. In block 725, the partner server 120 sends a partner response to the client device 110 with information from the address book function-specific response received from the partner front end server 120. Address book clearinghouse API calling routine 700 then ends at block 799.

[0042] Those of ordinary skill in the art and others will appreciate that the API calling routine of the partner server 120 illustrated in FIG. 7 is similar to the API calling routine of the client device 110 illustrated in FIG. 4. It will also be appreciated that various actions delegated to the client device 110 or the partner server 120 may be performed in whole or in part by the client device 110 or the partner server 120, when a partner server (or other intermediary devices) is interposed between the partner front end server 130 and the client device 110 when accessing the address book clearinghouse storage 150.

[0043] While the presently preferred embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention as defined by the appended claims. claimed are defined as follows: