AU2001291481A1 - Method and system for the rapid addition of contact information to an electronic address book using a uniform resource locator - Google Patents

Description

METHOD AND SYSTEM FOR THE RAPID ADDITION OF CONTACT INFORMATION TO AN ELECTRONIC ADDRESS BOOK USING A UNIFORM

RESOURCE LOCATOR

TECHNICAL FIELD

The present invention relates to a computer method and system for the rapid addition of an entity's contact information to an offline electronic address book through the use of a Uniform Resource Locator (URL).

BACKGROUND OF THE INVENTION

A person or organization typically has a large amount of contact information associated with it. For instance, a person may have several phone numbers (e.g., telephone, facsimile, cell phone and pager) and addresses (e.g., mail, email and street).

In order to organize and store this information various "electronic address books" have been created. These allow the contact details associated with a person or organization to be entered into a database which then allows subsequent browsing, searching and retrieval of contact information. Electronic address book functionality has been incorporated into personal computer communications software, telephones and handheld computing devices. Each time a new entry is created for an entity in an electronic address book the entity's details must be inputted into the database associated with the electronic address book. The input process is usually accomplished by manual data entry (e.g., using a keyboard). This is especially the case where an entity has communicated its contact details in a non-electronic way, such as via a business card or paper correspondence. The potential exists for human errors to be made in the manual entry of contact details taken from such a source. Further, an entity's contact details may have changed between the time a nonelectronic representation of those details was created and the time at which they are manually entered into an electronic address book. This would again have the potential to result in incorrect information being placed in the electronic address book.

Where contact details are represented in a non-electronic format, such as a business card, only a limited amount of information may be shown. In many instances it may not be possible to depict all of an entity's contact details. Even where there is space available to allow representation of all an entity's contact details, in many cases a recipient of that information is unlikely to enter all of these details into their electronic address book, since this may require considerable time to be expended to input infrequently used though potentially useful details.

Business card scanners such as those manufactured by Corex Technologies Corporation of Cambridge, Massachusetts have been developed to accelerate the process of entering business card details into electronic address books. Such devices will scan a business card and convert it to a digital representation. Optical character recognition techniques can then be applied to the digital representation allowing details depicted on the card to be converted into text and placed in an electronic address book. The accuracy of details captured from a business card using a scanning device will depend upon whether those details are depicted on the card in way suitable for optical character recognition. Only details present on the business card may be entered into an electronic address book using a business card scanner.

One common method of communicating contact information concerning a person is through the use of a personalized network URL. A person may register a network name (e.g., JohnKevinSmith.com) and map the network name to a numeric network address from which a network server can deliver information about the person (e.g., a web server delivering HyperText Markup Language pages).

It is also common for personalized URLs to be generated from existing network names by specifying an identifier in the network path portion of the URL. For instance, Apache, a widely used HyperText Transfer Protocol (HTTP) server distributed by the Apache Software Foundation of Forest Hill, Maryland allows a person's personal home page to be retrieved by appending an identifier to domain name. Configured appropriately, an Apache server which listens on the network address associated with the domain name "xyzname.com" will, in response to a request for the URL "http://xyzname.com/~jks" deliver the personal web page of the person with the identifier "jks". Various Internet domains have been established which allow a user identifier to be prepended to an existing domain name thereby creating a personalized URL. For instance, the assigned names authority administrator of the ".au" domain established the "id.au" domain in 1995 for this purpose (http://www.id.au). The id.au domain has been subsequently subdelegated into a number of subdomains (e.g. "wattle.id.au" and "dropbear.id.au") in which persons can apply for further subdomains based on the prepending of a personal identifier (e.g. "smith.wattle.id.au"). Such personalised domain names then allow persons allocated those domains to maintain resources of a personal nature which can be located using the personalised domain name.

U.S. Pat. No. 6,085,242 describes a method of managing a repository of user information by providing a network user with a personalized URL consisting of an identifier prepended to a domain name. While reference is made to personal information, such as contact details, being part of the repository managed using the method, U.S. Pat. No. 6,085,242 does not teach a method of enabling contact information to be rapidly entered into an electronic address book.

SUMMARY OF THE INVENTION

The present invention provides a method and system for enabling the recipient of a business card to rapidly enter information associated with the entity represented by the business card in an offline electronic address book. A Uniform Resource Locator ("URL") consisting of a domain name mapping to a server system and a unique identifier is placed on the business card. A recipient of the business card can use a browser to send a request to retrieve the network resource associated with the URL. When the server system receives the request it isolates the identifier from the URL. The identifier is then used by the server system to retrieve contact details for the entity from a database. The server system then sends the browser a Web page containing hyperlinks which allow automated entry of those details in an offline electronic address book in response to a single action by the recipient. Alternatively, the browser is immediately sent the entity's contact details encoded in a form enabling automated entry of those details in an electronic address book.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an embodiment of the present invention.

FIG. 2 is an illustration of a business card containing a URL which permits rapid entry of contact information.

FIG. 3 illustrates two methods of encoding an identifier into a URL.

FIG. 4 is a flow diagram illustrating the steps taken by the server system once a URL is entered in a browser by a card recipient.

FIG. 5 is a flow diagram of a routine for determining whether a request received by the server system is for contact information.

FIG. 6 provides examples of requests received by the server system as a consequence of a card recipient entering each different type of URL in a browser. FIG. 7 is an example of a HTML page generated by the server system in response to a request for contact information.

FIG. 8 is a flow diagram of a routine for sending a card recipient an entity's contact information in a particular file format in response to a selection made by the recipient.

FIG. 9 provides examples of contact information generated by the server system in output formats suitable for rapid entry into electronic address book applications.

DETAILED DESCRIPTION OF THE INVENTION

The present invention provides a method and system which enables the recipient of a business card to rapidly enter information associated with the entity represented by the business card in an electronic address book using a server system.

FIG. 1 is a block diagram illustrating an embodiment of the present invention which allows rapid entry of contact information in an electronic address book using the Internet and HyperText Transport Protocol (World Wide Web) as a communications method. The server system includes a server engine 101 , a contact information database 102 and an identifier/contact information table 103. In response to network requests 109 from a browser 107 the server engine generates HyperText Markup Language ("HTML") pages 104 and files 105 containing contact information. The files containing contact information are suitable for direct import by electronic address book applications 108.

In one embodiment, an entity with a business card enters information associated with itself into a contact information database which can be accessed by the server engine. The information entered may include typical contact details such as the entity's name, job title, organisation, phone numbers or addresses (e.g., street, postal, website and email). The entity may also include other details which could be useful to communicate to business or personal contacts, such as a photo, geographic position coordinates, timezone information, birthdate, public key or digital recording of the correct pronunciation of the entity's name. This information may be either manually entered by or on behalf of the entity, or it could all or in part be taken from an existing database of information (e.g., a corporate or white pages directory). A person skilled in the art would appreciate that all of these details do not have to be stored in one database but may be distributed throughout more than one database, provided that they can all be accessed by the server system. For instance, contact information may be stored in a database 106 which while not part of the server system can be queried by the server engine.

The entity is assigned an identifier. The identifier may be allocated by the server system, chosen by the entity or allocated by the operator of the server system. The identifier could also one of the entity's contact details (e.g., a telephone number). The identifier consists of one or more characters or symbols drawn from a character set (e.g., ASCII) which can be entered using a keyboard. The server system maps the identifier to the contact information accessible by the server system which the entity wishes to make available to recipients of the entity's business card. This mapping is stored in an identifier / contact information table. A person skilled in the art would be aware that this table could be integrated into the contact information database.

The entity then places the identifier on the entity's business card in combination with instructions to retrieve a network resource which enables capture of the entity's contact details. The instructions may take the form of a Uniform Resource Locator ("URL") or Internet address in combination with words stating that the entity's contact details can be retrieved from this location, as illustrated in FIG. 2. The URL consists of an Internet domain name in conjunction with the identifier. The Internet domain name maps to the network address of the server system such that requests for resources located at the domain name are received by the server system. FIG. 3 illustrates two possible ways in which the identifier may be incorporated into the URL. In 301 the identifier is placed after the domain name and separated from it using the character "/". In 302 the identifier is again placed after the domain name, but it is separated from it using the character "/" followed by an additional delimiter consisting of one or more characters. This scheme allows the use of a domain name which is also used to deliver other network resources. The delimiter should be chosen so as to not conflict with the names of any network resources also to be made available at the network location represented by the domain name. For instance, if the network protocol associated with the URL is the HyperText Transport Protocol ("HTTP") a delimiter consisting of the character "+" could be used because resources associated with HTTP servers rarely begin with the character "+". This form of URL would enable a domain name which is already associated with a HTTP server to be used because the presence of a "+" at the beginning of the resource name could be used to differentiate URLs associated with contact information from URLs associated other with network resources. A person skilled in the art would recognise that there are other ways of encoding the identifier in a URL in combination with a domain name which maps to the server system. Where the scheme associated with the URL is HTTP, the prefix "http://" may be omitted since the HTTP protocol is normally inferred in the case of URLs which are not prefaced by a scheme.

In both of the methods illustrated in FIG. 3 the identifier associated with the card entity is encoded, together with a domain name which maps to the server system, into a single URL. This enables a card recipient to send a request for contact details associated with the card entity to the server system by entering the URL in a browser. Each encoding scheme results in a URL consisting only of a domain name, identifier and delimiter characters. This permits entry of such URLs with as few keystrokes as possible.

FIG. 4 illustrates in overview the steps taken by the server system when the recipient of a business card enters the URL in a browser. Each of these steps is described below.

Once a card recipient enters the URL in a browser and instructs the browser to retrieve the network resource associated with the URL (e.g., by pressing the "Enter" key) the browser will send a request for the resource specified by the URL to the server system. In step 401, the server system receives the browser request. In step 402, the server system determines whether the request is for contact information or some other network resource by matching the requested URL against the types illustrated in FIG. 3. In the case of URLs conforming to the type of URL 302 the presence of the delimiter will indicate whether the request is for contact information as opposed to another network resource (e.g., a static HTML document). FIG. 5 is a flow diagram of a routine for determining whether a request is for contact information or another resource. When a card recipient types the URL depicted in the card in a browser, the browser will send a request for the URL to the server system. In step 501, the server system receives this request. In step 502, the server system checks if the request contains the delimiter character (e.g., a "+") in the appropriate position (e.g., after the "/"). If the delimiter is present the server system knows the request is for contact information. If the delimiter is not present the server system can conclude that this is a request for a network resource other than contact information and either deliver that network resource to the requesting browser or redirect the browser to another URL where the network resource can be found (step 503). If the URL conforms to type 301 the server system can conclude immediately that the request is for contact information on the basis that no other resources share these domain names. All requests for resources to network addresses mapped to these domain names must be requests for contact information since these domain names are only used to construct URLs which refer to contact information.

Where the server system determines that the request is for contact information the server system then, in step 403, determines the identifier sent by the browser as part of the request. FIG. 6 illustrates the HTTP version 1.1 requests the server system can expect to receive if an example URL of type 301 (601) or 302 (602) is entered in a HTTP version 1.1 compliant browser. In each case the browser transmits the identifier to the server system as shown in underline, and the server engine isolates the identifier from the request.

In step 404, the server engine queries the identifier/contact information table to determine which items of contact information the entity associated with the identifier wishes to make available to card recipients. The contact information is then retrieved from the contact information database and utilised by the server engine in step 405 to generate a HTML page. FIG. 7 is an example of such a HTML page. Section 701 contains all or part of the entity's contact information. Section 702 contains a number of hyperlinks to URLs which allow direct download of the entity's contact information in different file formats. The URL associated with each hyperlink consists of a domain name which maps to the server system, the identifier, and an indication of the file format to be downloaded. Each hyperlink is represented on the page by text which describes the file format of contact information which will be sent if a link is clicked on and/or the application software or device which can utilise contact information in that particular file format. FIG. 8 shows the steps which occur if a card recipient clicks on one of the hyperlinks enabling download of the entity's contact information in a particular file format. The card recipient's browser will send a request which will be received by the server system in step 801. In step 802 the server engine first determines the identifier from the request and then queries the identifier / contact information table to determine which items of contact information the entity associated with the identifier wishes to make available to card recipients. The contact information is then retrieved from the contact information database. In step 803, the server engine reformats the contact information into the particular file format (e.g., vCard) the card recipient has requested. In step 804, the server system sends this file to the card recipient's browser. Once the browser has completed download of the file (step 805) the browser will typically launch application software associated with the file type (e.g., in the case of a card recipient who chooses to download the entities details in vCard format, an address book application which supports vCard format files will be launched) (step 806). If address book application software which supports the file format downloaded as a method of importing contact information is available (e.g., Microsoft Outlook when the file type is a vCard) the entity's contact information will be automatically profiled into a new entry in the card recipient's electronic address book.

The entity's contact information may also be stored in scripting language commands (e.g., Javascript) embedded in a hyperlink in the HTML page generated in step 405 and delivered to the card recipient. Where address book application software is available which supports entry of address book details via scripting language commands (e.g., Netscape Communicator), activating such a hyperlink will cause the execution of the scripting commands resulting in the entity's contact information being entered in the electronic address book associated with the card recipient's software which supports the scripting commands used.

FIG. 9 illustrates step 803 in detail and shows three possible output formats for contact information. In response to a request for contact information from a browser, the server engine 902 retrieves the contact information from the contact information database 901. This information is then dynamically reformatted by the server engine into a format which can imported into an electronic address book. Which particular format the information is delivered in is determined by the hyperlink clicked on by the card recipient. Format 903 is an example of contact information formatted into a vCard file which can then be directly imported into an electronic address book which supports vCard. When such a file is sent to a browser the HTTP "Content-type" header is set to "application/vcard" so the browser is aware the file being sent is a vCard and can launch any address book application available which is associated with this file type (e.g., Microsoft Outlook). In 904 the same contact information is URL encoded in a HTML hyperlink containing Javascript commands which when clicked on will cause the contact information to be profiled into a new entry in the address book of a compatible application (e.g., Netscape Communicator). In 905 the contact information is formatted as a comma separated values (CSV) file suitable for electronic address books which support the import of generically formatted information (e.g. Psion Series 3a handheld computers).

Using the embodiment of the invention described a card recipient can have an entity's contact information automatically entered into an electronic address book simply by typing a single URL into a browser and selecting the type of electronic address book to populate from a list shown on the resulting HTML page. The system entirely avoids manual entry of the entity's contact information and the potential for errors to be made during this process. Since the contact information used to populate the electronic address book is not drawn from the card itself but a contact information database, up to date contact information can be retrieved using a card which may contain out of date details, provided information in the contact information database is kept current. The system also allows more contact information than is present on a card to be entered into an electronic address book.

In one embodiment of the invention the server system does not generate a HTML page in response to a request for a URL which relates to contact information but instead sends the recipient's browser a file containing the entity's contact information (e.g., a vCard file) without the intermediate step of generating a HTML page offering a selection of file formats. This method would be appropriate where a particular file format for storing contact details predominates and it is not necessary to provide the card recipient with a choice of format to download. The present invention is not intended to be limited to the particular preferred embodiments which have been described above. Modifications which fall within the spirit and scope of the invention will be apparent to those skilled in the art. For example, while an embodiment of the invention allowing contact information to be entered in an electronic address book using a HTTP browser, the server system may respond to requests from any type of browser (e.g., a Wireless Application Protocol microbrowser). Also, contact information may be encoded in file formats (e.g. SyncML) which can be imported into electronic address books residing on devices other than personal computers, such as mobile phones, personal organizers, handheld computers and personal digital assistants. The URL used to request card information may also be placed on items other than business cards where it is desirable to allow recipients of the item to rapidly add contact information to their address book (e.g., letterheads and advertisements). The scope of the present invention is defined by the claims that follow.

Claims (6)

1. A server system programmed for transferring contact information associated with an entity from the server system to an electronic address book via the Internet in response to a request via the Internet from a Web browser, the request being in the form of a URL including a domain name which maps to the server system and a unique identifier associated with the entity, wherein the server system retrieves the contact information associated with the entity based on the unique identifier and sends the Web browser contact information in a format which allows automated entry of the contact information into the electronic address book.

2. A server system as claimed in claim 1 , wherein the server sends the Web browser a Web page including a hyperlink.

3. A method for transferring contact information associated with an entity from a server system to an electronic address book via the Internet in response to a request via the Internet from a Web browser, .the method including:- assigning the entity a unique identifier and storing contact information associated with the entity; receiving a request from a Web browser via the Internet, the request taking the form of a URL including a domain name which maps to the server system and the unique identifier; employing the unique identifier to retrieve the contact information associated with the entity; sending the Web browser contact information in a format which allows automated entry of the contact details into the electronic address book.

4. A method as claimed in claim 3, wherein the server sends the Web browser a Web page including a hyperlink

5. A computer readable medium including a program which when loaded on a server system facilitates the transfer of contact information associated with an entity from the server system to an electronic address book via the Internet, the program enabling the server system to receive a request from a Web browser, the request being in the form of a URL including a domain name which maps to the server system and a unique identifier associated with the entity, and wherein the program enables the server system to retrieve the contact information associated with the entity and to send the Web browser contact information in a format which allows automated entry of the contact information into the electronic address book.

6. A computer readable medium as claimed in claim 5, wherein the server sends the Web browser a Web page including a hyperlink.