Patent Application
20060095437
The following discussion provides a broad overview of the problems encountered with conventional systems for contacting travellers. Since one of the embodiments of the system for centralising traveller contact information employs the lightweight directory access protocol (LDAP), the following discussion will also provide a brief overview of LDAP.
1. General Overview
As people travel more and more, it becomes increasingly difficult for other people to contact them. At present, there is no efficient way of ascertaining where a person is when he is not in his usual workplace (e.g., when a person is in a hotel, airplane, airport or on vacation). Furthermore, even if by some chance it is possible to locate a person, it is still necessary to determine the best means of contacting the person at the given location (e.g., depending on the location, it may only be possible to contact a traveller by FAX, email, mobile phone, post, etc.)
In order to overcome this problem, organizations have attempted to centralize contact information for their employees in enterprise-wide directories (e.g., Netscape's Directory Server and Microsoft's Active Directory). In conjunction with such data centralization, recent years have seen the development of a number of new applications (e.g., calendar, address book, intelligent mail, etc.) for presenting the personal information stored in the centralised data repositories. In tandem with the above developments, recent years have also seen the evolution of a number of applications that use centralized contact information to handle phone call rerouting, mail forwarding, etc.
Nonetheless, a problem still exists in updating centralized contact information directories with efficient, standardized information, whilst protecting the user's privacy and control over the information stored in the centralized directories.
2. Lightweight Directory Access Protocol (LDAP)
LDAP comprises a set of protocols for accessing information directories. Although not yet widely implemented, LDAP should eventually make it possible for almost any application running on virtually any computer platform to obtain directory information, such as email addresses and public keys. LDAP is based on standards contained within the X.500 standard, but is significantly simpler to implement. This is borne out by the fact that LDAP is supported by most major programming languages, including C, Java, and Perl, and either is, or will be, supported by most major operating systems including Solaris, GNU/Linux, Microsoft Windows, and Mac OS.
From a technical point of view, LDAP was designed to be an extensible general-purpose directory. To this end, it uses an object-oriented, inheritance-based schema definition, which provides for easy extension. More particularly, LDAP includes a base schema as part of its specification and other de facto standards for various services. The LDAP specification states that LDAP clients can request an entire feature list and data schema from any LDAP server, thus allowing a client to vary its functionality according its server. Furthermore, since LDAP uses UTF-8 for internal string representations, LDAP can potentially store and manipulate text in any language.
Beyond the above interoperability features, LDAP also provides advanced data replication and security features.
In particular, using data replication, it is possible to replicate all or part of an LDAP directory to physically separate locations. This feature provides highly-available data in which data can be moved as close as necessary to the client. Furthermore, using referrals, data mastery of portions of the directory can be distributed across different LDAP servers, thus allowing individual sections of an organisation to have control over particular data portions whilst maintaining a single authority over each piece of data.
Whilst existing security protocols such as Transport Layer Security (TLS) and Simple Authentication and Security Layer (SASL) enable secure data transmission, they do not mediate the processes of access control and user authentication. LDAP provides the ability to control all three aspects of the process of securing information in a directory (namely access, authentication, and authorization) through Access Control Lists (ACLs). ACLs can be used to grant access based on a number of different factors. In particular, ACLs can be used to force specific types of authentication, and once the client is fully authenticated as a valid user, ACLs can be used to authorize the user.
The present invention is directed to a traveller contact information centralising method and system and computer program.
The traveller contact information centralising system is designed to obtain up-to-date information regarding a user's location. The traveller contact information centralising system sends this information to the user, so that he can decide whether a centralised directory should be updated with this information. In the event that the user agrees to the update of the centralised directory with the relevant information, the traveller contact information centralising system provides the secure transfer of the information to an application that manages the centralized directory.
Three embodiments of the traveller contact information centralising system will now be described with reference to the accompanying drawings in which:
1. General Overview
The first embodiment relates to a generic traveller contact information centralising system without reference to a specific data access and transfer protocol. The second and more preferred embodiment is a more specialised form of the traveller contact information centralising system in which the LDAP protocol is used to facilitate the process of accessing and updating a centralised directory. The third embodiment is a traveller contact information centralising system of similar architecture to the second embodiment. However, the third embodiment differs from the second embodiment insofar as the third embodiment uses a different mechanism for updating traveller contact information stored in a central data repository.
For the sake of simplicity, the traveller contact information centralising system of the first embodiment will be known henceforth as a generic traveller contact center. The traveller contact information centralising system of the second and third embodiments will also be respectively known as the LDAP traveller contact center and the temporary update traveller contact center.
2. Hardware and Software Architecture of the Generic Traveller Contact Data Center
Referring to
At any given intermediary point, a first application 22 can provide the traveller 14 with contact information for the intermediary point. The first application 22 could be a standard email application, or SMS messaging application capable of sending contact information to the traveller's email address or mobile phone number.
The generic traveller contact data center comprises a second application 24 acting as a gateway to the central directory 10. The second application 24 is capable of receiving email or SMS messages containing contact information from the intermediary point. On receipt of the contact information, the second application 24 is capable of updating the user profile 12 of the traveller 14 in the central directory 10 with the relevant contact information.
3. Detailed Description of a User Profile
A user profile 12 is composed of the following standard fields.
In a preferred embodiment of the traveller contact information centralising system, the information stored in the central directory 10 and provided by the first application 22 (at any given intermediary point) is provided in accordance with the VCARD standard (RFC2426). Information regarding the VCARD standard can be obtained from the Internet Mail Consortium (http://www.imc.org/pdi/) and in particular in http://www.imc.org/pdi/vcard-21.doc.
4. Method of the Generic Traveller Contact Data Center
For the purposes of explaining the operation of the generic traveller contact data center an example will be used in which an intermediary point on a traveller's itinerary is a hotel. However, it will be understood that the traveller contact information centralising system is not limited to this specific example and could in fact operate in a similar fashion at other types of intermediary points (e.g., airport, etc). Furthermore, the present example relies on the transmission of contact information to the central directory by way of SMS messaging (i.e., through an SMS gateway). However, it will be understood that the central directory (or LDAP server) of the traveller contact information centralising system is not limited to the receipt of SMS messages, but could in fact, also receive and extract contact information from emails.
Returning to the present example, and referring to
On receipt of the message 30, the traveller may choose whether to forward the message 30 to the central directory 110 to update his user profile 112. In the event that the traveller chooses to update his user profile 112 with the hotel's contact information, the traveller forwards 34 the hotel's message 30 to an SMS gateway 36 to the central directory 110.
On receipt of the message 30 by the SMS gateway 36, the phone number of the originator of the message 30 is checked against the list of user mobile phone numbers stored in the central directory 110. If the phone number of the originator of the message 30 is present in the central directory 110 and a corresponding user profile 112 is found, the message 30 is assumed to be valid. The contact information of the hotel is extracted from the SMS message 30 and the contact information 120 stored in the relevant user profile 112 is updated accordingly.
Once the user's profile 112 is updated 38 with the relevant contact information, an acknowledgement message 40 is returned 42 to the traveller's mobile phone 32.
5. Hardware and Software Architecture of the LDAP Traveller Contact Data Center
The central directory of the LDAP traveller contact data center is based on an LDAP server. As in the central directory of the generic traveller contact data center, the LDAP server of the LDAP traveller contact data center contains several user profiles, each of the user profiles being identified by a unique user name. Only the user identified by a particular user name (or an application with appropriate access rights) can update the user's profile. The application used to create a user profile can be a basic browser supporting an LDAP interface, or dedicated component using information contained in email or SMS messages. The processes of authentication and access control in the LDAP server are handled by the ACL mechanisms of LDAP in order to prevent unauthorized users or applications gaining access to a user's profile.
6. Method of the LDAP Traveller Contact Data Center
The method implemented by the LDAP traveller contact data center is broadly similar to that previously described for the generic traveller contact data center. However, since the central directory in the LDAP traveller contact center is maintained on an LDAP server, contact information stored in a given user profile is updated using an LDAP update procedure.
7. Method Performed by the Temporary Update Traveller Contact Data Center
Referring to
In particular, instead of transmitting the contact information of the hotel directly to the traveller's mobile phone 32 (as in the generic and LDAP traveller contact data centers), in the temporary update traveller contact data center, the hotel receptionist 26 transmits 43 a message 44 containing the hotel's contact details to the central server 210. The hotel's contact information is stored in a temporary directory 46 and the central server 210 sends 47 a query 48 to the SMS gateway 36 requesting permission to update the user's contact information 220. It is to be appreciated that in a lieu of an hotel receptionist, the full service of transmitting hotel's contact details to the central server, and of storing these details in a VCARD format of the user profile for the purpose of updating it, maybe handled by a service provider.
The SMS gateway 36 forwards the query 48 to the traveller's mobile phone 32. In the event that the traveller authorises the update of his user profile 112, the traveller's mobile phone 32 transmits 49 a confirmatory message 50 to the SMS gateway 36. The confirmatory message 50 includes details of the transaction ID and the time of the validity of the update information. The SMS gateway 36 forwards 51 the confirmatory message 50 to the central server 210, which transfers the hotel's contact information from the temporary directory 46 to a contact information field 220 of a user's profile 212.
Alterations and modifications may be made to the above without departing from the scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 04300736.8 | Oct 2004 | EP | regional |
