WO2005013165A2

WO2005013165A2 - System and method for making a reservation and/or purchase

Info

Publication number: WO2005013165A2
Application number: PCT/GB2004/003239
Authority: WO
Inventors: James Mcilroy
Original assignee: Surrey Technologies Limited
Priority date: 2003-07-26
Filing date: 2004-07-26
Publication date: 2005-02-10
Also published as: WO2005013165A3; GB0317590D0

Abstract

A method of making a reservation comprising providing a terminal having a display and arranged to display at least two of the following display items: i. a calendar display; ii. a room type selector; iii. the number of occupants; iv. the age of the occupants; v. availability and vi. price. The method further comprising connecting the terminal to a server that provides a data feed to the terminal such that should any one of the display items be altered then the remaining display items are updated accordingly. The data feed provides objects from an object database which are sent to the terminal and reassembled thereon in order to generate the display items.

Description

SYSTEM AND METHOD FOR MAKING A RESERVATION AND/OR PURCHASE

Background of the Invention.

This invention provides a system and related methods for making a reservation and/or purchase, particularly, but not exclusively over a network connection such as an Internet connection or the like. In particular the method and system may be applicable to accommodation, such as hotel, reservations and bookings and/or performance reservations (for example theatre, cinema, etc.) and/or travel reservations.

Discussion of the Prior Art.

It is convenient to discuss the invention in relation to the hotel industry but the invention has wider applicability. The Hotel Industry has been slow to adopt Internet based reservation systems; in part, this is due to the complex, often rigid process that web-based users are faced with to book their accommodation. Research shows that 70% of on-line hotel bookings are started but never completed.

Existing systems are based on and are dependent on outdated relational database architecture from the 1970's and some are dependent on proprietary browser "plug-ins" that must be first downloaded from a vendor site, or loosely supported standards. The industry standard for online transactions is generally presented as a series of multiple forms, which are neither intuitive, or interactive. These forms serve to confuse and alienate the Web user increasing the likelihood of a given web user being unable to complete his/her booking leading to the 70% Figure for incomplete bookings previously mentioned. Plug-ins to a user's browser can be problematic in that they require extra software over and above the browser before they can work. The use of plug-ins can require extra processing power in order to re-work a particular page if it changes, can require a higher bandwidth to download the information and may be platform specific. Such platform specificity is not desirable since it can reduce the number of users that are able to access the web site. Extra processing power in order to re- work a page and increased bandwidth increase the costs associated with using such plug-ins.

An example of a plug-in that is used by a number of websites is the FLASH™ plug-in. The FLASH™ plug-in is a proprietary plug-in, and is not a cross-platform plug-in. Being a proprietary system, FLASH™ is reliant on support from Macromedia™ whch could potentially be removed thus rendering websites using FLASH™ unusable. A further disadvantage of the FLASH™ plug-in is that right clicks of a mouse are not supported as they are reserved for bringing up a control means for controlling the plug-in itself.

An example of a prior art system that uses the FLASH™ plug-in is provided by iHotelier of 3100 Richmond, Suite 200 Houston, TX 77098- 3102 USA whose website, www.ihotelier.com, provides a one screen booking system for a singular hotel property. iHotelier provides single site specific booking forms.

Outline of the Present Invention

According to a first aspect of the invention there is provided a method of making a reservation comprising providing a terminal having a display and arranged to display at least two of the following display items: i. a calendar display; ii. a room type selector; iii. the number of occupants; iv. the age of the occupants; v. availability and vi. price; the method further comprising connecting the terminal to a server that provides a data feed to the terminal such that should any one of the display items be altered then the remaining display items are updated accordingly wherein the data feed provides objects from an object database which are sent to the terminal and reassembled thereon in order to generate the display items.

An advantage of such a method is that it allows for greater flexibility and reusability of the display items, and lower terminal resource requirements such as bandwidth, memory and CPU processing time.

The method may automatically handle reservations via user-friendly, interactive, interfaces, which are browser-based, web-enabled, thin client. This method is advantageous because it may eliminate the need for multiple-forms and separate clickable pages, typical of existing, industry standard products and legacy systems.

The data-feed provides what may be thought of as a feedback mechanism since it allows any one of the display items to be updated if a first one is altered. The feedback mechanism is preferably a real-time feedback mechanism or as close to real-time as practicable. Such an arrangement is convenient since it allows information displayed on the terminal to be updated dependent upon a user's input to the terminal. For example, should a user make a selection on the calendar display then the price displayed on the terminal may be altered accordingly. Further, if a user were to select a type of accommodation then the calendar display may be altered to indicate when the selected types of accommodation was available. The method preferably allows a user of a terminal to alter the display items in any order. Such a method is convenient because it makes use of the terminal more convenient and reduces the level of skill required of the operator. Prior art systems require a user to alter display items in a predetermined order which can lead to user frustration if this is not followed. Therefore, the present invention may make the process quicker.

Conveniently, the server and the terminal are connected to one another via a Wide Area Network (WAN) such as the Internet. As such the terminal and the server may communicate using HTTP (Hyper Text Transfer Protocol) or any other suitable protocol.

Preferably the method provides a transmission window on the terminal which is arranged to run code to send data back to the server. In perhaps the preferred embodiment, the transmission window is of zero size and as such cannot be viewed by a user of the terminal. However, the skilled person will appreciate that such a transmission window can still run code therein. An advantage of such a transmission window is that it facilitates sending data back to the server. Other code running on the terminal may pass data to the code running within the transmission window in order that that data can be transmitted to the server. It will be appreciated that environments such as web browsers often use a page refresh in order to send data back to the server. An advantage of using a transmission window, particularly a zero sized transmission window, is that if a refresh is required to send data to the server then there is minimal impact on data displayed on the display of the terminal outside of that transmission window. It is preferable that the display items are displayed outside of the transmission window. Such a method is convenient because they will not be affected by a refresh of any data displayed within the transmission window.

In one particular embodiment the transmission window is provided as an inline frame (IFRAME) as is defined in HTML (Hyper Text Markup Language) . Such a window is convenient because it can be positioned anywhere on the display of the terminal and is part of the HTML standard.

The display items may be provided as a GUI (Graphical User Interface) . Such a method is convenient as it will be familiar to a large number of people and will therefore be readily useable.

Conveniently, the method comprises providing a toolkit that allows a user to build a display including at least two data items. Such a toolkit will be familiar to developers of programs for environments such as Microsoft™ Windows™, Apple™ OsX™, etc. Preferably, the toolkit is written in Javascript, although it will be appreciated that other languages are equally suitable.

The method may provide at least one firewall. The firewall may be provided between the server and the terminal. Alternatively, or additionally, the firewall may be provided between servers. It will be appreciated that one or more firewalls are advantageous to increase the security of data held on the server and/or terminal.

Preferably the method allows hotel rooms to be reserved. However, the skilled person will appreciate that it may equally be used to make other reservations including any of the following: camp sites; hostels; bed and 013165 6 breakfast; booked services; hire equipment; tours; recreational pursuits, seats (including for travel and performances) and the like.

The display may be arranged to display a description or the like (which may include images, video clips or the like) about the subject of the reservation. For example, if the reservation provides accommodation the display may provide images of the room, etc.

Conveniently, the description or the like may be associated with one or more of the display items. Indeed, more than one, or indeed each of, the display items may have a description or the like associated therewith.

The method may allow an operator of the system to access the server and alter objects within the object database. Such a method is advantageous because it allows details about the reservation to be updated; for example, the prices, availability, etc. of the reservation may be updated.

Conveniently, the method allows an operator to make global changes across a range of objects and/or change one or more selected objects.

The method may be compliant with OTA (Open Travel Alliance) data structures. Such an arrangement is convenient because it allows the system to interface with systems in use by hotels and the like.

The method outlined above may provide any one or more of the following advantages: Automation and/or streamlining of the reservation process (in particular but not exclusively hotel reservations), reduction of the complexity and generate cost-savings, which may be substantial, throughout the supply chain; enablement of multi-channel use on legacy systems allowing users (which may be hotels) to efficiently manage their electronic distribution from one platform; provision of connectivity to third-party marketing services, utilising on-line (Internet) technologies; reduction of cost, perhaps significantly, for both hoteliers and reservation agents than existing channels; increase, perhaps substantially, occupancy; help in elimination of the need of multiple-forms currently used by competitors which confuses and discourages the consumer losing the hotelier business; provision of feature-rich Control Centre, allowing reservation managers to override rates, availability, room descriptions, property policies, in fact any information required for web bookings; provide control over a customers Web site reservation process, while retaining brand, price integrity and yield; provision of a browser-based service for minimal technology management burden; compliance with OpenTravel™ Alliance (OTA); connection of Internet sales channels to the Property Management System/Central Reservation System (PMS/CRS) reservations system inventory; connection of two-way real time information from CRS and internet reservations to the PMS; elimination of manual processing of online reservations and cancellations.

As will be understood by those skilled in the art, the PMS is used by hoteliers for the day-to-day running of their property and comprises software that typically runs on an internal network at the hotel property. PMS usually has a grid showing availability and provides the means for the hotel clerk to check people in and out of their rooms. The CRS is a centralised database that hotel chains often use to store inventory, bookings and may distribute them online through legacy Global Distribution Systems (GDS) .

According to a second aspect of the invention there is provided a reservation system allowing a user thereof to make a reservation, the system comprising a server having an object database accessible thereby and a terminal connected thereto, the terminal comprising a display arranged to display at least two of the following display items: i. a calendar display; ii. a room type selector; iii. the number of occupants; iv. the age of the occupants; v. availability and vi. price; and the terminal being further arranged to allow a user of the terminal to alter one or more of the display items and thereafter update any other display items according to the alteration made by the user; wherein the terminal and the server have a connection therebetween which is arranged to have objects from the object database sent from the server to the terminal in order that the terminal can generate the display items therefrom.

The server may comprise more than one server. In one, perhaps the preferred embodiment, the server comprises three servers: a web server; an application server; and a database server. Should the server comprise a plurality of servers then these may be provided as a distinct hardware servers and/or may be provided as separate processes running on the same hardware.

According to a third aspect of the invention there is provided a reservation server arranged to have access to an object database, said server being arranged to facilitate reservations and being further arranged to have a connection made thereto from a terminal and receive requests for objects from the database from said connection, the server being arranged to retrieve the requested object and send the object to the connection for transmission to the terminal.

The reservation server may be arranged to use an Object-Relational mapping, which turns a relational database into an "Object Persistence" database. Such an object relational mapping is desirable in order to feed the objects, which may be Javascript objects, to a terminal. It is preferable that both the server and the terminal have the same object structures since they need to share the same concepts of the business objects.

With Object Database Management Systems, such as provide object databases, the program code is mixed with the data in such a way that the Object is a piece of data mixed with only program code that is relevant to it and perform functions on just that data. The object also "knows" of relationships between itself and other objects and the system runs by having objects emit signals to each other, each encapsulating just the data that is relevant to itself.

A Room object, for instance is only concerned with how many people it can sleep and what types of beds it has. It does not matter what price it is sold at. The price of the room may for example be handled by a Price object (this may be because prices fluctuate seasonally for a given room type) . The price object may provide the price the room it is associated with at a given point in time, if the price is required, the room object will communicate with its associated Price object, and send the result.

In prior art using technology such as relational databases, the data has no intelligence required, and a separate program is needed to perform all the actions required to link up the data in meaningful ways, and try to keep track of everything outside of the structure of the data. This makes it difficult to send data items to a terminal which can be reassembled into what may be an identical "live" structure in memory of the terminal, with the same signal sending behaviour, and the same mixing of data and function. An object database, by contrast, is suited to this purpose.

The reservation server may have the object database stored thereon or may have the object database stored on a device to which it has a connection. According to a fourth aspect of the invention there is provided a reservation terminal comprising a display arranged to display at least two of the following display items: i. a calendar display; ii. a room type selector; iii. the number of occupants; iv. the age of the occupants; v. availability and vi. price; and being further arranged to allow a user to alter one or more of the display items and send the alterations via a connection to a remote server and receive back data objects from the remote server, which the terminal is arranged to assemble into memory objects and use those memory objects to generate new display items which are alterations of the previous display items to reflect the users alterations to the one or more display items.

According to a fifth aspect of the invention there is provided a method of making a reservation comprising providing a reservation server, providing the server with access to an object database, arranging the server to facilitate reservations by connecting said server to a terminal, allowing said server to receive requests for objects from the database from the terminal, to retrieve the requested object and to send the object to the terminal.

According to a sixth aspect of the invention there is provided a machine readable medium containing instructions which when loaded onto a computer cause that computer to perform the method of the first aspect of the invention.

According to a seventh aspect of the invention there is provided a machine readable medium containing instructions which when loaded onto a computer cause that computer to function as the server of the third aspect of the invention. According to an eighth aspect of the invention there is provided a machine readable medium containing instructions which when loaded onto a computer cause that computer to function as the terminal of the fourth aspect of the invention.

The machine readable medium of any of aspects of the invention may be any one or more of the following: a floppy disk; a CDROM/RAM; a DND ROM /RAM (including +R/RW.-R/RW); any form of magneto optical disk; a hard drive; a memory; a transmitted signal (including an internet download, file transfer, or the like) ; a wire; or any other form of medium.

Aspects of the invention can be used with a number of existing websites, such as www.expedia.co.uk and www.travelocity.co.uk, to replace the systems that these websites currently use. Using the invention with existing websites provides a more dynamically intuitive and interactive system in real time which can dramatically increase the volume of online transactions, while enhancing the internet experience for the end-user and consumer.

Brief Description of the Drawings

There now follows by way of example only a detailed description of one embodiment of the present invention with reference to the accompanying drawings of which:

FIGURE 1 shows schematically a computer system such as may be used in performing the method of the invention; FIGURE 2 shows schematically two computer systems as shown in Figure 1 communicating over the Internet; FIGURE 3 shows detail of the memory of a computer system arranged to carry out the present invention; FIGURE 4 shows an overview of the relevant system components, including an informational overview of the back-end configuration;

FIGURE 5 shows a "screen shot" of the working interface that the web customer uses to book their rooms;

FIGURE 6 shows a flow chart of the steps performed in carrying out one embodiment of the present invention;

FIGURE 7 shows an activity diagram of functions that a user takes to perform a booking;

FIGURE 8 shows a UML diagram of a portion of the schema, used by the system of Figure 1 ; FIGURE 9 shows the syntax of a query used by the computer system of Figure 1 ; and

FIGURE 10 shows the syntax of a response returned by a server. Detailed description of the invention

A Graphical User Interface (GUI) "toolkit" written in JavaScript European Computer Manufacturers' Association Script (ECMAScript 262) facilitates a higher level of interactivity in a standard web page than the "Forms" mechanism inherent in the World Wide Web Consortium (W3C) Hyper-Text Mark-up Language (HTML) specification. This GUI toolkit is loosely modelled after traditional GUI toolkits for windowing environments, such as XI 1, the Apple™ Mac OS and Microsoft™ Windows.

A "four tier" approach is used for the processing of web browser requests. There are three tiers in the back-end, comprising of the web server, application server and database server, with the web browser serving as a further tier which presents the front-end visible GUI.

JavaScript code is sent to the user, using Hyper Text Transfer Protocol (HTTP) 1.1 requests. This JavaScript code implements the Dynamic HTML (DHTML) that drives the interaction between the user and the booking-engine, using W3C Document Object Model (DOM), level 1.

All requests that require back-end action are performed via an Object Request Broker (ORB) , allowing the back-end and front-end application to use the same basic object structure for their internal operation. This object structure itself is designed using the Object Model Group (OMG) Unified Modelling Language (UML) , to integrate with systems designed around or compliant with the Open Travel Alliance (OTA) 2003A Specification.

The computer system of Figure 1 comprises a display 102, processing circuitry 104, a keyboard 106, a mouse 108. The processing circuitry 104 comprises a processing unit 112, a display driver 113, a hard drive 114, a memory 116, an I/O subsystem 118, an IP port 117 and a system bus 120. The processing unit 112, hard drive 114, memory 116, I/O subsystem 118, display driver 113 and IP port 117 communicate with each other via the system bus 120, which in this embodiment is a PCI bus, in a manner well known in the art. It will be appreciated that although reference is made to a memory 116 it is possible that the memory could be provided by a variety of devices. For example, the memory may be provided by a cache memory, a RAM memory, a local mass storage device such as the hard disk 114, or any of these connected to the processing circuitry 104 over a network connection such as the IP port 113. The processing unit 112 can access the memory 114,116 via the system bus 120 to access program code to instruct it what steps to perform and also to access the data samples. The processing unit 112 then processes the data samples as outlined by the program code.

Figure 2 shows two such computer systems 100a, 100b arranged to communicate over the Internet. Data from one computer system (which may be a server 100a) can be transmitted via its IP port 113 to the Internet using known protocols such as TCP/IP or WAP and can then be transmitted to a second, remote computer system 100 (which may be thought of as a terminal 100b) . The data may comprise, for example, a website, or may be a request for a service or information.

It will be appreciated that both a server supplying a website as a data feed and the computer (perhaps a home computer or a lap-top) used to access a website by a Web Customer (i.e. the terminal) may share similar architecture to the computer system 100 shown.

Figure 3 shows the memory 114 of a terminal such as the computer system 100 of Figure 1 once it has accessed a reservations website in greater detail. It can be seen that the memory comprises a portion 300 dedicated to program storage and a portion 302 dedicated to holding data. The computer system 100 holds in a short term cache objects in an Object Cache relating to a calendar object 304, a Room Type Selector object 306, a 'Number of Occupants' object 308, an 'Age of Occupants' object 310, an Availability object 312 and a Price object 314. The data held in the Object Cache is used by the computer system to generate display items and thus provide elements of a reservations webpage.

In use of the system, and as shown in Figures 6 and 7, a Web Customer selects a regular browser link (step 600) to the booking engine [003] . Their Web Browser will request a page providing an interface to the booking engine [003] from the Web Server [029], which will return a page containing a "loading... " page as the initial visible page elements [004], with some "Bootstrap" ECMAScript code [005] that fetches the relevant code for the User Interface [009] , the Application Rules [010], the Storage Interface [011], the ECMAScript Request to HTML form Conversion mechanism [013] , the back-end response to ECMAScript object mechanism [012], the storage Object Cache [014] and various Browser Compatibility Functions [015] (required for non-fully ECMAScript 262 compliant web browsers) .

Once this is complete, the Application Rules [010] request [018] of the Storage Interface [011] to load initial data. A call-back function is passed to the Storage at this point. The Storage Interface [011] creates the Invisible IFRAME [006] then passes [020] the request to the HTML Form Conversion system [013], which fills [021] a form [008] and submits [022] it to the web server [029] .

The Web Server [029] recognises the request as an application request, and so passes it to its FastCGI dispatching engine [030] .

The FastCGI dispatching engine [030] opens (or re-uses) a connection to the Application Server.

The Request is received by the Application Server's I/O (Input/Output) sub-system [031] 118, which interprets the response and assembles it into an Object Structure. It then passes the request on to the Request Logic sub-system [032].

The Request Logic sub-system [032] interprets the request, and selects the relevant piece of code that performs the query or operation that the request is for. It then uses the Storage Access sub-system [033] to query the Database server [034] or a replicate [035] , assembling the returned rows into business objects. This cycle happens as many times are as necessary to satisfy the business logic of the particular request being carried out. The Request Logic [032] then compiles a response to the original query as an object structure, passing it to the Response Generator [036] .

The Response Generator [036] will then either generate a suitable response HTML page, containing embedded ECMAScript that, once evaluated by the client in the Response Evaluator [012] , will re-assemble valid business objects. It passes this response through the I/O sub-system [031]118 back to the Web Server's FastCGI dispatching engine [030] , which buffers the response in its buffers [038] and distributes [023] them to the web browser via the Internet.

Once the result has been received in the form of new content for the invisible IFRAME [006] , the IFRAME then has all of the Response Objects, as well as Return Values and Codes [007] to the original request made by the Storage Interface [011] on behalf of the Application Rules [010] . This information is stored as a string containing ECMAScript code, and calls [024] a function in the parent page. The Response Evaluator [012] then uses the ECMAScript code evaluation function ("eval") to convert the response into a set of business objects and response values, and pass [025] them back to the Storage Interface [011] . The Storage interface then calls back [026] the Application Rules [010] , utilising the call-back that was originally passed in [018] with the request.

Once the initial request is complete, the Application Rules [010] then create User Interface components using [027] the User Interface Toolkit [009] . These components in turn modify [028] the visible page elements, and the user sees [002] the page update.

The user can then perform step 602 and input their reservation requests by completing the following actions [001] with the Visible Page Elements [004] . Certain page elements will fire "events" [016] to the User Interface Toolkit [009] components that they were created from. The User Interface Toolkit [009] will then report [017] these events to the Application Rules [010] .

When the Application Rules [010] receive an event, one of two things can happen; either it is a simple interaction that does not require information from the system, or it is a request for extra information - or to perform a request (like a booking) .

If it is a simple request, the business objects are updated within the Application Rules [010] , which then calls [027] the User Interface Toolkit [009] component methods to update [028] the visible page elements [004] .

If it requires support from the system, then it will contact [018] the Storage Interface [011], supplying a call-back function. If the request is a simple fetch of a business object by its object identifier, then the Storage Interface [011] first consults [019] the Object Cache [014] to see if the desired object is already present in memory. If so, it immediately calls [026] the call-back function it was passed with the objects from the Object Cache [014] . If it is a request to perform a function, or a fetch by ID of an object not already in the Object cache [014] , then the method dispatch call previously described is followed.

Due to the simple, predictable manner of contact of each level, there are many points for "fire-walling" ([040] and [041]) , to enhance system security.

Description of the Booking Interface

The booking engine interface is implemented using a pure JavaScript GUI toolkit which itself is implemented using the standard W3C DOM level 1 API for HTML. This GUI toolkit combined with the aforementioned ORB architecture allows Widgets to be constructed to represent the display aspect of the business objects served by the back-end and facilitates intuitive control of the objects' states. It will be appreciated that a Widget is a building block of a GUI such as a window, a drop down box, etc.

Importantly the user may start at any point and in any order, this intuitive interface allows the user irrespective of their online experience level to work their way through the process until all the steps are completed and the reservation can be made. The GUI interface provides feedback at any time of the state of the reservation process to the user, letting them know which actions have affected the total cost, as well as indicating and disallowing impossible configurations (such as selecting a room type across a date range where such a room is unavailable) .

With reference to Figure 5, the steps to be completed (in any order) are:

Select check in/out dates [050, 051] Select room types [052]

Configure the number of rooms selected [055]

Configure the number of guests [056, 057, 058]

Enter Credit Card information [060]

Enter Contact details [059]

Further functionality is added to show reservation totals [062] , view descriptive information about the room types [061] and access to online help [064] .

The Calendar [050] responds to mouse clicks. A click on a cell that represents a date on which a given room type, or any date if no room type has been selected, is available for reservation, highlights the cell as selected, or deselects the cell as a toggle action depending on its state (selected or available) . A subsequent mouse click on a different cell selects that cell as well as the cells representing dates in between. In the event that a room type has been selected, the selected date range will span from the median between any existing selection, or from the first cell selected in the direction of the newly selected cell until either the target cell is reached, or a cell representing a date with no availability of the selected room type is reached, in which case a warning is raised, and the longest possible continuous range is selected.

The Month Selector [051] has a list of buttons representing each month of the year and allows changing the months on display by the Calendar, thereby reloading the availability Schedule for that month from the back- end system.

Room Type Selector [052] shows a button for each room type for sale at the hotel. Choosing a room type updates the image below [061] which has a tooltip description of the room type. Rooms that are displayed as 'greyed out' represent those types for which there are none available for the selected date range, if such exists, otherwise, each room can be selected in turn, updating the availability grid on the Calendar.

A legend is included [054] which lends the key to the various states a particular date/room type combination can be in: Available, Selected, Unavailable, Checkout Only.

RoomSpinner [055] allows the user to add rooms of the type currently selected to the reservation. The number and types are displayed accordingly in this component which allows the addition or subtraction of the selected room type. Changing the number of rooms for this reservation updates the Calendar at the same time showing availability. It will be appreciated that a Spinner is one particular form of Widget and generally comprises a numerical digit together with a down and an up arrow to adjust the displayed numerical digit.

Guests are added using the Adults [056] ,Children[057] and Infants [058] spinners. If the number of guests exceeds the total capacity of the rooms chosen, then a warning is raised to this effect, and the reservation cannot be completed until this is rectified.

If a suitable room is available (step 604), Credit card details [060] and contact information [059] must also be supplied by the user in order to complete the reservation by clicking on the button that completes the reservation [063] in step 606. If no suitable room is available, the user quits the website in step 608.

Description of the Query Format

Figure 8 details the object structure for this explanation in the OMG Unified Modeling Language (UML) . The request format is described by example. Standard accessors (set_x and get_x methods that return the attribute x) are not detailed.

Figure 9 contains a list of the "Form Parameters" that are uploaded to the server in a typical request.

The query contains a "site" (line 001) and a session ID (SID - line 002) , these are used to shortcut explicit authentication on each request, and to enable session affinity when load balancing is in use. In the example, it is a randomly generated 128-bit MD5 sum.

The query also contains a series of commands, each of which have a series of arguments. In the example, there are three commands, on lines 003-004, 005-006 and 007-008. The rough equivalent Perl [071] and Java [072] code fragments are also detailed.

Each command is constructed as if it were a function or object method call. The first argument is either the name of a function to call, or a reference to an existing server side object. Line 003 demonstrates this; the object with ID number "3340002" is loaded from the database at the start of the operation. It is assumed that the server-side execution engine is implementing security of the request, in order to check that the user has access to refer to the object ID they pass. The next argument, "get_Customer" , the name of the method to call. As no further arguments are passed, it is equivalent to line 010 of the Perl fragment, or line 015 of the Java fragment.

The second command (lines 005 and 006) uses a special syntax to refer to a result from a previous operation in the same request; it refers to "resO" (result from the 0th command) . It calls the "get_PersonName" method, with the Perl and Java equivalents on lines 011 and 016 of the source, respectively. The third command (lines 007 and 008) is similar, but calls the get_Address method.

Figure 10 contains a portion of the server response [080] . First of all, two temporary variables are created to hold objects being sent to the front end (lines 001 , 002) . They are then "constructed" using the standard JavaScript constructor syntax, passing the field names in as an anonymous JavaScript object (lines 003 through 005).

After that, any fields which are not simple fields but are made up of further complex data structures are created (lines 006 through 009) . In line 006 there is an example of a value which will be filled in subsequently, while in line 009 there is an example of a value which is not delivered with this message - however, an object ID is supplied so that it can later be fetched by ID in a subsequent request, should it be needed.

Then, objects are "stitched" together (lines 010 through 015) , by way of calling "set" accessors, thereby leaving an object structure in JavaScript which is identical to that on the back-end server, if incomplete.

So that the front-end may refer to them later in subsequent requests, the object ID of the dispatched objects are set inside every object (lines 016 through 018) . Finally, a "result" object is set up that contains the actual results from the individual methods called, to maintain transparency of the requests to the front-end application (lines 019 through 022).

Claims

« ,„,„^--5/013165 24 CLAIMS

1. A method of making a reservation comprising providing a terminal having a display and arranged to display at least two of the following display items: i. a calendar display; ii. a room type selector; iii. the number of occupants; iv. the age of the occupants; v. availability and vi. price; the method further comprising connecting the terminal to a server that provides a data feed to the terminal such that should any one of the display items be altered then the remaining display items are updated accordingly wherein the data feed provides objects from an object database which are then sent to the terminal and reassembled thereon in order to generate the display items.

2. The method according to claim 1 further comprising allowing a user of the terminal to alter the display items in any order.

3. The method according to claim 1 or claim 2 wherein the server and the terminal are connected to one another via a Wide Area Network (WAN) .

4. The method according to any preceding claim wherein the terminal and the server communicate using HTTP (Hyper Text Transfer protocol) .

5. The method according to any preceding claim further comprising a transmission window on the terminal, which is arranged to run code to send data back to the server,

6. The method according to claim 5 wherein the transmission window is of zero size and as such cannot be viewed by a user of the terminal.

7. The method according to claim 5 or claim 6 wherein the display items are displayed outside of the transmission window.

8. The method according to any preceding claim wherein the display items are provided as a GUI (Graphical User interface) .

9. The method according to any preceding claim further comprising providing a toolkit that allows a user to build a display including at least two data items.

10. The method according to any preceding claim further comprising providing at least one firewall.

11. The method according to claim 10 wherein the firewall is provided between the server and the terminal.

12. The method according to claim 10 wherein the firewall is provided between a plurality of servers.

13. The method according to any preceding claim wherein the method allows hotel rooms to be reserved.

14. The method according to any preceding claim wherein the display is arranged to display a description or the like (which may include images, video clips or the like) about the subject of the reservation.

15. The method according to claim 14 wherein the description or the like is associated with one or more of the display items.

16. The method according to any preceding claim wherein the method allows an operator of the system to access the server and alter objects within the object database.

17. The method according to claim 16 wherein the method allows the operator to make global changes across a range of objects and/or change one or more selected objects.

18. The method according to any preceding claim wherein the method is compliant with OPT A (Open Travel Alliance) data structures.

19. A reservation system allowing a user thereof to make a reservation, the system comprising a server having an object database accessible thereby and a terminal connected thereto, the terminal comprising a display arranged to display at lest two of the following display items: i. a calendar display; ii a room type selector; iii. The number of occupants; iv. the age of the occupants; v. availability and vi. price; and the terminal being further arranged to allow a user of the terminal to alter one or more of the display items and thereafter update any other display items according to the alteration made by the user; wherein the terminal and the server have a connection therebetween which is arranged to have objects from the object database sent from the server to the terminal in order that the terminal can generate the display items therefrom.

20. The reservation system according to claim 19 wherein the server comprises more than one server.

21. The reservation system according to claim 20 wherein the server comprises three servers: a web server; an application server; and a database server.

22. The reservation system according to claim 20 or claim 21 wherein the plurality of servers are provided as distinct hardware servers.

23. The reservation system according to claim 20 or claim 21 wherein the plurality of servers are provided as separate processes running on the same hardware.

24. A reservation server arranged to have access to an object database, said server being arranged to facilitate reservations and being further arranged to have a connection made thereto from a terminal and receive requests for objects from the database from said connection, the server being arranged to retrieve the requested object and send the object to the connection for transmission to the terminal.

25. The reservation server according to claim 24 further arranged to use an Object-Relational mapping to turn a relational database into an "Object Persistence" database.

26. The reservation server according to claim 24 or claim 25 further arranged to have the object database stored thereon.

27. The reservation server according to claim 24 or claim 25 further arranged to have the object database stored on a device to which it has a connection.

28. A reservation terminal comprising a display arranged to display at least two of the following display items: i. a calendar display; ii. a room type selector; iii. the number of occupants; iv. the age of the occupants; v. availability and vi. price; and being further arranged to allow a user to alter one or more of the display items and send the alterations via a connection to a remote server and receive back data objects from the remote server, which the terminal is arranged to assemble into memory objects and use those memory objects to generate new display items which are alterations of the previous display items to reflect the users alterations to the one or more display items.

29. A method of making a reservation comprising providing a reservation server, providing the server with access to an object database, arranging the server to facilitate reservations by connecting said server to a terminal, allowing said server to receive requests for objects from the database from the terminal, to retrieve the requested object and to send the object to the terminal.

30. A machine readable medium containing instructions which when loaded onto a computer cause that computer to perform the method of any one of claims 1 to 18.

31. A machine readable medium containing instructions which when loaded onto a computer cause that computer to function as the server of any one of claims 24 to 27.

32. A machine readable medium containing instructions which when loaded onto a computer cause that computer to function as the terminal of claim 28.