CA2296433A1 - Method for purchasing services using a distributed database reservation system - Google Patents
Method for purchasing services using a distributed database reservation system Download PDFInfo
- Publication number
- CA2296433A1 CA2296433A1 CA 2296433 CA2296433A CA2296433A1 CA 2296433 A1 CA2296433 A1 CA 2296433A1 CA 2296433 CA2296433 CA 2296433 CA 2296433 A CA2296433 A CA 2296433A CA 2296433 A1 CA2296433 A1 CA 2296433A1
- Authority
- CA
- Canada
- Prior art keywords
- computer system
- server
- message
- client
- database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 230000004044 response Effects 0.000 claims abstract description 17
- 238000004891 communication Methods 0.000 claims description 32
- 238000010586 diagram Methods 0.000 description 9
- 230000008859 change Effects 0.000 description 5
- 238000013461 design Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000010006 flight Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 235000021184 main course Nutrition 0.000 description 1
- 238000012011 method of payment Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Tourism & Hospitality (AREA)
- Operations Research (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Development Economics (AREA)
- Quality & Reliability (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention relates to a method for reserving services using a distributed database computer system. One embodiment of the invention includes the steps of receiving a request for services on a server-side computer system, creating an entry in a server-side database responsive to the request for services, passing the request for services to from the server-side computer system to a client-side computer system, accessing a client-side database to determine whether the requested services are available, creating an entry in the client-side database responsive to the request for services if the requested services are available, generating a response on the client-side computer system that indicates whether the requested services were available, passing the response to the server-side database, and updating the server-side database according to the response.
Description
TITLE
METHOD FOR PURCHASING SERVICES USING A
DISTRIBUTED DATABASE RESERVATION SYSTEM
Field of the Invention This invention relates generally to the field of computer databases, and more particularly to a system for operating a distributed database using an Internet connection. In one particular version, the invention relates to a method for purchasing or reserving services over an Internet connection using a distributed database between a server and a client computer.
Background of the Invention With the growth of the Internet, an increasing number of consumers desire to use the Internet to purchase goods and services from on-line vendors. For some purchases, such as the purchase of a book or other specific item, the transactions involved between the customer's computer and the vendor are fairly straightforward. The customer merely locates the vendor's website and specifies the item to be purchased, along with a shipping address and method of payment. The vendor, upon receiving the customer's request, simply ships the item to the customer and then charges the customer in the manner specified.
Not all Internet consumer transactions, however, are so straightforward. Purchasing or making reservations for services over the Internet can be more involved, especially when the reservations can be cancelled or changed, or if a third party acts as an agent between the consumer and the vendor. For example, many golfers would like to reserve tee times at courses throughout the nation, or even the world, over the Internet. Most golf courses, however, lack either the ability or the desire to create a website for this purpose, and even if they provided a website, a golfer would have to visit a different website for every course that he or she wished to play in order to book tee times. Thus, there is a need for a service which could provide a single website that would allow a golfer to select a golf course, or courses, in the area in which he or she wished to play, determine the availability of tee times on desired dates, and book the desired reservations on-line.
Since golf courses traditionally book tee times over the telephone or through other non-Internet methods, it is important that if a golf course allows on-line booking, it still maintains complete control over its tee sheet to prevent double bookings or other conflicts. Various methods have been attempted to resolve this problem, but none have been completely satisfactory. For example, one method involves storing the tee sheet in a database located at the golf course. A third party, acting as an agent for the golf course, is provided with the ability to access the database of the golf course and present this information to golfers over a website operated by the third party. While this technique offers real-time access to the golf courses tee sheet, it is difficult to achieve quick response time. Further, it requires a dedicated, and expensive, high speed telecommunication line between the third party agent and the golf course; otherwise, performance is unacceptably slow. And, if the high speed line goes down, the golf course cannot book tee times on-line.
The company booking tee times would also be unable to conduct any business until communications to the course were restored. Further, the Internet, currently, is neither fast nor reliable. Thus, accessing a database over an Internet connection means the database connection must be open longer. This increases the chance for deadlock and takes longer to return results to the client causing the connection to appear slow.
Another effort to provide on-line access to a golf course's tee sheet involves storing the tee sheet on a database located at the third party agent's location instead of the golf course itself. In this case, an on-line golfer wishing to book a tee time accesses the tee sheet database through the third party agent's website. While this may improve the speed of access for the on-line golfer, this method also requires an expensive high speed telecommunication line between the third party agent and the golf course in order to obtain satisfactory performance, especially since the golf course relies on access to off-site database. Moreover, if the line between the golf course and the third party agent goes down, the golf course would be unable to view its own tee sheet and would be uncertain what tee times it had already booked. The course, in essence, would be unable to conduct business until the connection was restored.
Similar problems exist in booking other type of reservations, such as those for theatre tickets or airline flights, over the Internet through a third-party agent.
Summary of the Invention One object of the invention is to overcome the difficulties discussed above. In one embodiment, invention includes the use of a dual database system with one database being located at the vendor's location. This database is directly accessible by the vendor and contains all information about the services, reservations or bookings sold by the vendor. This database may be thought of as the client-side database. A corresponding database is located at the third-party agent's location. This database is said to be on the server-side, and it includes a copy of the information stored on the client-side database. The server-side database is accessible on-line to those wishing to book reservations or purchase other services from the vendor. The client-side and server-side databases are connected to each other over the Internet. When an on-line party wishes to purchase a service from the vendor, for example if an on-line golfer wishes to book a tee time at a given golf course, he or she would access the server-side database through the agent's website. The transaction would be recorded on the server-side database and, simultaneously, a communication would be sent to the vendor to access the client-side database to confirm that the desired service (e.g., a particular tee time) is available. If so, the transaction is appropriately recorded on the client-side database and a communication is sent back, over the Internet, to the third-party agent. The server-side database is then updated to indicate that the requested purchase of services is confirmed, and an e-mail is generated back to the consumer advising him or her this fact. By the same token, if the client-side database indicates that the requested service is not available, then the appropriate message is sent back to the third party agent' s computer system. The server-side database is then updated to reflect that this service is not available and an appropriate e-mail is generated back to the potential purchaser.
Another aspect of the invention relates to the use of a message queuing system to allow communications between the databases that are distributed between server-side and client-side computer systems. In one version of the invention, the distributed database system includes a client-side queue and a server-side queue. The two queues communicate over the Internet. All messages to be exchanged between the client-side and server-side systems of the distributed database system are queued up in the appropriate queue before being sent. The queue on the server-side computer system, however, is adapted to track the dynamic IP address of the client-side system and to update outgoing messages with the most recent IP address of the client in order to assure accurate communications.
Still another aspect of the invention relates to a method for reserving services using a distributed database computer system. According to an embodiment of the invention, a request for services is received on the server-side computer system. The request for services may come from a third party connected to the server-side computer system through its web page, or through an email request. Alternately, the request may be sent to the server computer system through more traditional methods such as phone or facsimile requests, although this may require manual involvement from personnel operating the server-side computer system.
Once the request is received, the server-side computer system creates an entry in the server-side database that is responsive to the request for services. The nature of the entry will depend on the services being requested. If the requested services are a tee time at a golf course, then the entry will record the date, tee-off time, name of the golf course, and possibly other information such as the number of players, the cost and billing information, and an email address for communicating back to the person requesting the tee time. If the requested services are reservations for seats to a sporting event, for example, then the entry will contain the date, time, and location of the event, the location of the seats, as well as cost and billing information and any other information deemed desirable.
The request for services is then passed from the server-side computer system to the client-side computer system. This may be performed by various methods, such as a dedicated phone line, but preferably the communication is performed over the Internet to reduce the cost and improve performance of the communications. The client-side database is then accessed to determine whether the requested services are available. Returning to the sporting event embodiment, if the seats have already been sold, then the request must be denied. But if the seats are available, then an entry is created in the client-side database responsive to the request. This establishes the reservations for the person requesting them.
Finally, a response is generated on the client-side computer system that indicates whether the requested services were successfully booked. This response is passed to the server-side system, which updates its database to either confirm the reservation or indicate unavailability, and then sends a message to the person requesting the reservation, preferably by email, although other conventional methods could by used as a matter of design choice.
Still other objects and advantages achieved by the present invention will become apparent to those of skill in the art in view of the following detailed description of embodiments of the invention and the drawings discussed therein.
Brief Description of the Drawings Figure 1 is a block diagram showing an overview of an online distributed database system according to an embodiment of the invention.
Figure 2 is a depiction of a web page presented to an on-line consumer who wishes to purchase services over the Internet.
Figure 3 is a block diagram of an embodiment of the invention particularly useful in booking golf course tee times over the Internet.
Figure 4 is a data flow diagram depicting the operation of software running on the client-side computer system according to an embodiment of the invention.
Figure 5 is a data flow diagram depicting the operation of software according to an embodiment of the invention running on the server-side computer system.
Figure 6 illustrates the content of a typical message for reserving or booking tee times according to an embodiment to the invention.
Figure 7 is a list of typical messages which may be transferred between the client-side and server-side computer systems in connection with an embodiment of the invention for on-line booking of tee times at a client golf course.
Figure 8 is block diagram of a further embodiment of the invention useful to allow corporate booking of a collection of the vendor's services.
Detailed Description of Embodiments of the Invention FIG. 1 is a simplified block diagram showing an overview of an on-line distributed database system according to an embodiment of the invention. In this embodiment, the invention is described in connection with its application to booking tee times at remote golf course over the Internet. It will be understood, however, that the invention is not limited to booking golf course reservations, but could easily be adapted by those of skill in the art to any type of reservation system that could benefit by the use of a distributed database system described herein. In this case, a golfer 100 seeks to book a tee time at golf course 101 over the Internet 102. Golf course 101 is assumed to be previously registered with the distributed database reservation system 103. Registration of golf courses will be described later. Golfer 100 communicates with the distributed database reservation system 103 through a web page provided by the operators of the distributed database reservation system 103. The web page presents the golfer with an array of choices through conventional means such as pull-down menus, point-and-click buttons, or blank forms that can be electronically completed on-line. An exemplary format for accessing the distributed database system is shown in FIG. 2. It should be noted that the golfer 100 can select any golf course 100, regardless of its location, through this single website, as long as it is registered with the distributed database system. In this way, a golfer, who wishes to make reservations with multiple golf courses, will not have to visit multiple websites.
Once a golfer provides the information indicated in FIG. 2, he or she sends a communication to the server-side of the distributed database system 103. The server-side of the distributed database system 103 records the transaction in the server-side database and books a "pending" tee time for the golfer 100. The server-side of the distributed database system 103 then sends a communication, also over the Internet 102, to the golf course 101.
Golf course 101 runs the client-side of the distributed database system on its local computer. This communication accesses the local database stored at the golf course 101 to determine whether the tee time requested by the golfer is, in fact, available. If so, the tee time is booked on the local golf course database, and a message is sent back from the golf course database to the distributed database system 103. The distributed database system 103 then changes the status of the requested tee time from "pending" to "confirmed"
and sends an e-mail back to the golfer 100 advising him or her this result. On the other hand, if the requested tee time is not available, then the golf course 101 then communicates this to the distributed database system which, in turn, sends the appropriate e-mail to the golfer 100.
FIG. 3 is a detailed block diagram of the components for the distributed database system according to an embodiment of the invention. In this case, the golf course books its tee times on a software tee sheet running on an on-site computer. The on-site computer itself is not critical, and a suitable computer system would be a PENTIUM based computer processor running the MICROSOFT WINDOWS '95 or '98 operating systems. The computer system will typically contain a modem to communicate to the Internet through a suitable Internet service provider, such as America-On-line. It should be noted that the distributed database system described herein may rely on a low-cost Internet communication as opposed to the much more expensive, dedicated, high-speed phone lines required by other systems that do not employ the teachings of the present invention. The software running on the golf course computer will be referred to, generally, as client-side software.
The distributed database system disclosed herein is, obviously, not limited to implementation in a Microsoft windows environment. Nevertheless, for purposes of illustration, the embodiments described herein will make numerous reference to various Microsoft development products such as Microsoft Message Queue, Microsoft Transaction Server and the Microsoft Distributed Network Architecture. These development tools are described in numerous publications available from Microsoft or other vendors.
The client-side software 300 includes a number of components. One component is the calendar, or tee sheet 301. In one particularly advantageous embodiment, the calendar is created as an .EXE file through VISUAL BASIC or some other suitable software language. The calendar component 301 provides a user interface to golf course employees, allowing them to view, create, delete, and modify the tee time bookings. The calendar 301 is coupled to a local database 302 via data access layer 303. The database contains all bookings for the golf course, whether they are created manually through the calendar 301 or through the Internet as will be described later. It is preferable that priority always be given to the local database 302 so that personnel at the golf course will always have complete control of its bookings. Any suitable database may be employed for database 302, such as MICROSOFT ACCESS which creates files in the .MDB format, as long as it has capacity to store tee time information. A data access layer 303 in this embodiment is arranged between the calendar 301 and the database 302, data access layer 303 allows communication to the client-side middleware component 304. The data access layer 303 provides data security and allows network access of the local database 302 according to conventional Microsoft Distributed Network Architecture ("DNA") standards.
The middleware component 304 facilitates communications between the data access layer 303, and hence the database 302, and the server-side software 305. In addition, the client-side middleware 304 also provides software "hooks" for other third party tee sheet software packages 306. This allows, for example, a golf course which has already invested in tee sheet software to continue to use the same calendar interface and database 307 that it is accustomed to and, yet, still access the server-side software that enables golfers to make Internet bookings to the golf course. In other words, this feature of the middleware 304 allows for a golf course to substitute third party software for the calendar 301 data access layer 303 and database 302 without losing the advantages provided by the middleware component 304 and server-side software 305.
In one embodiment of the invention, the middleware 304 exchanges messages between the client-side software and the server-side software over a queue. The queue comprises a two-part message queue 308 and 309, each part being connected to the other over an Internet connection 310. The Internet connection can be provided by any common ISP. Preferably, the queue employs Microsoft Message Queue, version 1Ø Message queue 308 queues up incoming or outgoing messages to be sent to the data access layer 303 or server-side message queue 309, as the case may be. If the Internet connection 310 between the client-side software and the server-side software is disrupted, the distributed database system will not lose important messages between the client-side and server-side software, but, instead, will store the messages until Internet connection 315 is re-established. The messages will then be exchanged in order. If the Internet connection 310 is disrupted for an extended length of time, then it is advantageous to allow some messages on the server-side message queue 309 to "time out" and be passed to a "dead letter" queue (not shown). Once passed the dead letter queue, the messages will not be exchanged between the client-side and server-side if the Internet connection is re-established. Instead, they will be reported to the server-side software and handled according to other ways that may be selected as a matter of design choice. For example, if a pending request for a tee-time booking has been stored in the message queue 309 for some extended period of time, say six hours, then the request is transferred to the dead-letter queue, and the server-side software generates an e-mail back to the requesting golfer informing him that the golf course is unable to accept his reservation over the Internet. Since priority is given to the client-side database, however, it is advantageous not to allow messages queued in message queue 308 to time out. These messages will always be sent once 5 connection is established.
The message queue 309 is included within the server-side middleware 310. The server-side middleware 310 also includes a software component to implement the business logic for processing the messages that are transmitted between the client-side and server-side software. The business 10 logic is, in essence, the rules that determine how the distributed database system operates. In this embodiment, the business logic is implemented on an application server, using the MICROSOFT SERVER TRANSACTION
software, version 2Ø The application server manages the com objects that perform the functions required on the server-side software. For example, the application server communicates with a database, such as a SQL 7 database, that stores all booking information for all golf courses registered with the distributed database system. This information may also include historical booking records for statistical, billing and usage reports useful to the operator of the distributed database system and the owners of the golf courses. With respect to current tee time information, i.e., tee times booked but not yet played, the server-side database 312 should be substantially identical to the local golf course database 302 for any particular golf course. The application server 311 also communicates with the web server 313. The web server provides the web page to the booking golfer 314 over the Internet 310 according to methods well known to website developers.
The components of exemplary client-side middleware 304 will now be described in greater detail with respect to the dataflow diagram shown in FIGs. 4 and 5. This embodiment of the invention will be described as implemented in an object-oriented programming language like C++. Those skilled in the art will recognize that the particular choice of software is not critical and the inevntion is easily adapted to non-object oriented programming languages.
FIG. 4 shows a Microsoft Message Queue ("MSMQ") implemented on the server-side (MSMQ 309) and on the client side (MSMQ 308). The client side and server side communicate with each other by sending messages back and forth between MSMQs 308 and 309, which are connected by the Internet.
There are two primary categories of messages used in the system. One is referred to as B4MX NetMessages. These messages are used to communicate information about the system and are not used specifically in making golf reservations. B4MX NetMessages include "heartbeat" messages used to periodoically verify that each side of the system is operating properly, "signon" messages used to allow a course to log on to the system, "resync"
messages used to re-synchronize the client and server side databases if necessary, and any other desired messages necessary to keep the system operating properly.
The second category of messages are B4MX Messages. B4MX
Messages are related to actually booking tee time and tracking course informaiton. The data elements of B4MX Messages therefore contain information such as the date and time of the course reservation, the number of players, billing information, etc. FIG. 6 shows the fields in a typical Message, in this case, a CourseAdd message used to add a course to the system. The message has a header, containing fields for the Internet IP
address of the course, a unique club identifying number, the message type, and the version of the software that created the message. The main body of the message includes fields for the name id number and name of the course (some golf clubs have multiple courses), the local rules for the course, the course designer, number of holes, playing times, etc. Some of the methods available in a CourseAdd message include a GetMessageType to return the type of message, and SendToServer which sends the message to the server side of the system via the MSMQ.
The version of application information may be included in both categories of messages and is useful to ensure that the golf courses have properly updated their client-side software and, also, to accurately translate any incoming message from non-current versions of client-side software which may be in use. The golf course name is typically an ASCII string that uniquely identifies the registered golf course. The golf course IP address is the Internet address that the MSMQ 309 must communicate over the Internet 315 so that it accurately can transmit message information to the desired golf course. It should be noted that unlike systems that use conventional dedicated phone lines and networking techniques, the IP address for computers connected to the Internet is dynamic. That is, the IP address for the particular computer changes each time the computer connects to the Internet. The solution to this problem will be discussed in greater detail herein with respect to the handshaking between the MSMQ queues 308 and 309.
FIG. 7 is an exemplary list of B4MXMessages and B4MXNetMessages useful with an embodiment of the invention.
Referring now to FIG. 4, it is seen that MSMQ 309 is connected through the Internet 315 to the MSMQ 308 on the client-side. The MSMQ 308 sends and receives messages to B4MC Monitor 400. B4MC Monitor 400 is a software object that operates the MSMQ 308 by pushing and pulling messages to and from the MSMQ. B4MC Monitor 400 also analyses incoming messages from the MSMQ 308 and decides whether to forward them to B4MC Net Receiver 401 or B4MC Receiver 402, depending on the category of the incoming message. If B4MC Monitor 400 determines that an incoming message from MSMQ 308 is an B4MX NetMessage it passes the message to object B4MC Net Receiver 401. B4MC Net Receiver 401 performs a task according to the B4MX NetMessage it received, then it creates another instance of B4MX NetMessages containing the result of the task. The instance of B4MX NetMessages is then sent to B4MC Monitor 400.
B4MC monitor 400 then passes this message on to MSMQ 308 for transmission to the server-side software, via the Internet 315, to server-side MSMQ 309.
If B4MC Monitor 400 determines that the incoming message from MSMQ 308 is a B4 MXMessage, then it passes the message to B4MC
Receiver 402. B4MC Receiver 402 is typically a com object that translates the incoming message into instructions that can be passed directly to the data access layer 303. The data access layer, includes B4MC Data Access 303 in FIG. 4. B4MC Data Access contains logic for processing the messages from B4MC Receiver 402. This logic includes logic to operate the database 302.
For example, an incoming request to Book a tee time to causes B4MC Data Access 303 to access database 302. Database 302 contains a number of stored procedures that are invoked by messages from B4MC Database Access 303 according to conventional techniques known to those skilled in the art.
B4MC Data Access 303 also receives messages for booking tee times from the calendar interface 301 which is operated by personnel at the golf course. On receiving a message to book a tee time from the calendar interface 301, B4MC Data Access 303 accesses database 302 and generates a message to B4MC Receiver 402 informing it of this action. B4MC Receiver then generates an instance of B4MX Messages that contains information about the calendar booking.
If a booking is successfully completed in response to a B4MX
Message, B4MC Receiver 402 sends a message to calendar 301 to update its display, informing personnel at the golf course that a specific tee time has been booked. B4MC Receiver 402 also generates a new instance of B4MXMessages that contains information about the succesful booking.
Conversely, if the booking were unsuccessful that would be reflected in the content of the B4MXMessage. The B4MXMessage is then passed to B4MC
Monitor 400 for transmission to the server side of the system via the MSMQ.
FIG. 5 is a dataflow diagram depicting the operation of the server-side software 305. The server-side software in this embodiment to the invention includes the Server-side middleware 310. The server-side middleware 310 is similar to that of the client-side software in that it includes a number of software objects that perform administrative and booking tasks corresponding to those performed by the client-side soft ware.
B4MS Monitor 500 communicates with MSMQ 309 on the server-side.
On receiving a message from MSMQ 309, B4MS Monitor 500 determines whether the message is a B4MXNetMessage (i.e., an administrative message) or a B4MXMessage (i.e., a data message). If it is an administrative message, B4MS Monitor 500 passes the message to B4MS Net Receiver 501. B4MS Net Receiver translates the message into instructions to another message containing instructions be performed by B4MSADMINCOM 502.
B4MSADMINCOM 502 forwards the instructions to other software modules such as ADMIN APP 503 and B4MS Administrator Database 513, that actually perform the requisite system tasks. These tasks include searching for golf course IDs and creating new golf course IDs in the B4MS
Administrator Database 505. The B4MS Administrator Database 505 stores information about the golf courses registered with the distributed database system. After ADMIN APP 503 or B4MS Main Database 504 perform the required tasks, the results are passed back to B4MSADMINCOM 502.
B4MSADMINCOM 502 then creates a B4MX Net Message 505, to be sent back to the client-side software via B4MS Monitor 500 and MSMQ 309, assuming a response to the client-side is required. B4MSADMINCOM 502 may also originate messages to be sent to the client-side, depending on the nature of the administrative message.
If B4MS Monitor 500 determines that an incoming message from the MSMQ 309 is a data message, it passes the message to B4MS Distributor 506. B4MS Distributor is an object that creates a temporary software objects referred to as a B4MS workers. A B4MS Worker is an object that communicates with the application server software 508. The application server software is preferably implemented from server software, such as Microsoft Transaction Server. The application server 508 includes software objects B4TC Transactions 509 and B4TWT Transactions 510. B4TC
Transactions 509 receives information from the B4MS Worker objects 507.
This information may contain, for example, a message from B4MS Distributor 506 that instructs B4TC Transactions 509 to change the status of a pending book tee time in the main database 312 and send an e-mail message to notify the booking golfer of the change in status. It should be noted that use of multiple B4MS Workers 507 is preferable because it allows the server-side software to multi-task a number of incoming booking requests, thereby improving system performance.
The operation of the distributed database system will now be described in greater detail with respect to an Internet booking. In this embodiment, a 5 golfer connects to the server's website 313 over the Internet 315. After completing the information that appears on the golfer's browser, the golfer sends the information to the application server software 508. B4TWT 510 accesses the server-main database 312 and invokes a stored procedure. The stored procedure determines whether the requested tee time at the requested 10 course is available. If so, it creates an entry into the database that is associated with a "pending" status. At this point, the requested tee time is only pending because the server-side software has not received confirmation from the golf course that the requested tee time is, in fact, available. Since the golf course tee sheet database is always given priority, according to this 15 version of the invention, the requested tee time will not be confirmed until a confirmation message is received back from the golf course. This is advantageous because the Internet communication system is not always reliable and the golf course will be booking tee times over the telephone or other non-Internet methods.
The B4TWTransaction process 510 then passes this information to B4MSDatasend 511. B4MSDatasend 511 creates in instance of B4MX
Messages 512. Referring to FIG. 7, the type of B4MXMessage is a BookingAddFromServer (referred to as a "booking add" message). B4MX
Messages 512 is sent to B4MS Monitor 500, where it is queued up in a conventional manner, with the exception of the use of a dynamic IP address in the header filed, which will be described in greater detail later.
The MSMQ 309 then transmits the booking add message over the Internet 315 to the MSMQ 308 on the client-side. The booking add message is then passed to B4MC Monitor 400, which recognizes the message as a booking message from the header information and forwards it to B4MC
Receiver 402. B4MC Receiver 402 then translates the message into a format suitable for B4MCData Access 303. B4MC Data Access 303 then sends a request to the tee sheet database 302. This invokes a stored procedure on the tee sheet database 302 which attempts to book the requested tee time.
The results of this attempted booking are then passed back through B4MC
Data Access 303 to B4MC Receiver 402 which creates another instance of B4MXMessages (type BookingRespFromClient) that contains the results of the attempted booking in its message body. B4MC Receiver 402 then passes the message to B4MC Monitor 400, which in turn transmits it to MSMQ 308.
MSMQ 308 queues up the message in a manner that is conventional with the MSMQ software.
The message is then transmitted over the Internet 315 to MSMQ 309, which in turn passes it to B4MS Monitor 500. B4MS Monitor 500 now analyses the message and determines it is an incoming data message related to an attempted booking over the Internet. Accordingly, B4MS Monitor 500 passes the message to B4MS Distributor 506. B4MS Distributor 506 then creates or uses an existing Worker Object 507 to handle the message. The Worker Object 507 then translates the message into a format that can be processed by B4TC Transactions 509. B4TC Transactions object 509 interprets the message information and generates an e-mail to the golfer advising him or her whether the requested tee time is confirmed. If not, B4TC
Transactions will typically include a message explaining to the golfer the reasons why the request failed, such as the tee time is unavailable, the golf course is unavailable, or the golf course is currently unable to process Internet requests. If the tee time request is available, then B4TC Transaction 509 will also invoke a stored procedure at the server-side main database 312 that changes the status of the request from "pending" to "confirmed." A
confirmation email will be sent to the golfer.
Another common action is a calendar booking. In this case, a reservation is booked over the phone, or through some other means by personnel at the golf course. Golf course personnel book tee times through the calendar interface 301. The particular interface used is not critical, and its operation is a matter of design choice, as long as it provides efficient functionality for golf course personnel to specify the date, time, and any other 1~
desired information to be associated with the reservation. This information is then passed through B4MC DataAccess 303 and placed into the golf course database 302. The calenday then creates a B4MX Message 403 to advise the server-side software of the booking. The message is then forwarded through B4MC Monitor 400, MSMQ 308, MSMQ 309, and on to B4MS Monitor 500. B4MS Monitor 500 then passes this message to B4MS Distributor 506 through a worker 507 and on to B4TC Transactions 509. B4TC Transactions 509 then invokes a stored procedure in the database 312 and records the tee time reservation.
As discussed earlier, administrative messages are used to ensure that the client-side and server-side systems are properly operating together. For example, one advantageous message is a heartbeat message. A heartbeat message is a type of B4MXNetMessage. B4MSADMINCOM generates a periodic heartbeat message to be sent to the client system. This heartbeat allows the server to track whether the client server has gone off-line and for how long. The heartbeat message is passed from B4MS ADMIN COM 502 to B4MS Monitor 500. B4MS Monitor 500 then sends the heartbeat message through MSMQs 308 and 309 to B4MC Monitor 400 on the client-side software. B4MC Monitor 400 recognizes the message as a heartbeat message and forwards it to B4MC Net Receiver 401. B4MC Net Receiver 401 then translates the message and generates an instance of B4MXNetMessage 403 responsive to the heartbeat request. The B4MXNetMessage is forwarded to B4MC Monitor 400 which sends it back to B4MS Monitor 500. B4MS monitor 500 recognizes this as a response to the heartbeat message and forwards the message to B4MS Net Receiver 501 which translates the message and causes B4MS ADMIN COM to invoke a stored procedure in an administrative database 513 to store the golf course name, date, and time of the last communication received in response to the heartbeat request. Should problems arise, personnel operating the server-side system can access the heartbeat database in administration database 513 and determine the last time the server-side system received a communication from the client-side.
Ig Alternately, reports can be generated or the service side software could take action on its own to aid in resolving the communication problems between the server and client systems. For example, an error message could be automatically generated and displayed at the server-side software informing personnel there to contact the golf course to find out why no communications had been received for a pre-determined period of time.
Other administrative communications include, for example, a sign-up communication. A sign-up message is used whenever a new golf course is to be registered with the distributed database system. In this case, when the client-side software is first initiated on the client computer, the golf course personnel are prompted to enter a variety of information about the golf course into the system through the server-side website interface. This information may include the name of the golf course, the number of courses available at the golf course, contact and billing information, location of the course, e-mail addressee, any special seasons or times in which the course is not available, and any particular times the course may wish to "block out," i.e., decline to accept reservations over the Internet. Other information may, of course, be included as a matter of design choice. This information is stored in a series of B4MXNetMessages and B4MXDataMessages and forwarded through the MSMQs to B4MS Monitor 500. The B4MS Monitor 500 then forwards the information to a B4MSNet Receiver 501, B4MS ADMIN COM 502, ADMIN
APP 503, and on to B4MS Main DB 504. B4MS Main DB 504 then invokes a stored procedure in golf course main database 312 so that the information is stored and the course is now available for on-line booking through the I nternet.
Those of skill in the art recognize it is important that messages be reliably transmitted between the clients and server-side systems. Although the Internet connection 315 is convenient and low cost, it is not typically as reliable as the more expensive dedicated phone lines used in prior art systems. Further, unlike dedicated phone line systems in which the IP
address for the client computer is static, the IP address for the client computer system is dynamic, i.e., it will change each time the client connects to the Internet 315. Moreover, the IP address of the client can change between the time a message for the client is queued up and the time it is actually sent.
This would result in a message being undeliverable, and, hence, lost. To overcome these problems, the server-side software maintains the current IP
address for the desired golf course in the golf main database 312. Whenever the IP address of a golf course changes, it sends a log-on message that contains, among other things, the name of the course and the IP address assigned to the course for this particular Internet session. When the B4MS
Monitor 500 receives this message, it passes it to B4MS MainDB 504. The B4MSMainDB 504 then invokes a stored procedure in golf main database 312 to update the IP address associated with that golf course. Whenever an outgoing message stored in the MSMQ 309 is scheduled to be forwarded over the Internet, B4MS Monitor 500 retrieves the latest IP address for the golf course from the golf course main database 312 and inserts it into the IP
address field of the outgoing message. In this way, the outgoing messages always have the latest IP address available for any particular golf course.
This eliminates any problems that could be caused by a change in the IP
address from the time the message is originally queued up to be sent and the time the message is actually sent over the Internet.
In the specific embodiment of the invention in which the Microsoft Message Queue Software is used to communicate over the Internet, those of skill in the art will appreciate that the MSMQ system retrieves the IP address from a database referred to as MQIS in Microsoft documentation. Therefore, before the message is actually sent, B4MS Monitor 500 retrieves the IP
address for the golf course and inserts it into the MQIS database at the desired location for that particular message. The message is then forwarded to the MSMQ 308 on the client-side.
In a further embodiment, the invention lends itself to corporate tee time bookings. Corporate tee time bookings are useful when a corporation owns a number of courses across the country. This embodiment of the invention is discussed in greater detail with respect to FIG. 8. In this case, the computer is located at the corporation's location 805 and connected to the distributed database system server-side 800. The distributed database system is, in turn, connected over the Internet to a variety of golf courses in 802-804, owned by the corporation 805. The corporation 805 can create parameters that concern any or all of its golf courses 802-804 by sending messages to the 5 computer database system 800 to make the appropriate entries into its main course database. These entries can include a specification of seasons during which the courses will be open, the prices charged for playing at certain seasons or times, the blocking out of any time periods during which the golf course is not to make bookings over the Internet, and any other parameters 10 that the corporation deems useful. The server-side system then stores these parameters into the main database 312 and the business logic located on the distributed database system will operate accordingly. Thus, if the corporation decides that it does not wish to permit Internet bookings on any of its golf courses for weekend tee times for the hours between 7 and 10 a.m., it can 15 communicate this request to the distributed database system 800. If an Internet request comes in, a distributed database system attempting to request a tee time during these hours, this will be detected by logic in the B4TW Transaction object 510, which is the communication with the main database 312. The application server 508 would then cause B4TC
20 Transactions 509 to generate an e-mail to the booking golfer denying his request.
In addition, the distributed database system 800 may track historical information about all tee times that have been booked on the ledger database 801. This data may then be submitted to the corporation in a form of utilization reports to allow the corporation to assess the functionality of a distributed database system.
Although the present invention has been described with respect to application to an Internet-based golf tee time reservation system, it will be appreciated by those of skill in the art that it is not so limited and is easily extendable to other types of reservation systems and Internet communication systems by those of ordinary skill in the art.
METHOD FOR PURCHASING SERVICES USING A
DISTRIBUTED DATABASE RESERVATION SYSTEM
Field of the Invention This invention relates generally to the field of computer databases, and more particularly to a system for operating a distributed database using an Internet connection. In one particular version, the invention relates to a method for purchasing or reserving services over an Internet connection using a distributed database between a server and a client computer.
Background of the Invention With the growth of the Internet, an increasing number of consumers desire to use the Internet to purchase goods and services from on-line vendors. For some purchases, such as the purchase of a book or other specific item, the transactions involved between the customer's computer and the vendor are fairly straightforward. The customer merely locates the vendor's website and specifies the item to be purchased, along with a shipping address and method of payment. The vendor, upon receiving the customer's request, simply ships the item to the customer and then charges the customer in the manner specified.
Not all Internet consumer transactions, however, are so straightforward. Purchasing or making reservations for services over the Internet can be more involved, especially when the reservations can be cancelled or changed, or if a third party acts as an agent between the consumer and the vendor. For example, many golfers would like to reserve tee times at courses throughout the nation, or even the world, over the Internet. Most golf courses, however, lack either the ability or the desire to create a website for this purpose, and even if they provided a website, a golfer would have to visit a different website for every course that he or she wished to play in order to book tee times. Thus, there is a need for a service which could provide a single website that would allow a golfer to select a golf course, or courses, in the area in which he or she wished to play, determine the availability of tee times on desired dates, and book the desired reservations on-line.
Since golf courses traditionally book tee times over the telephone or through other non-Internet methods, it is important that if a golf course allows on-line booking, it still maintains complete control over its tee sheet to prevent double bookings or other conflicts. Various methods have been attempted to resolve this problem, but none have been completely satisfactory. For example, one method involves storing the tee sheet in a database located at the golf course. A third party, acting as an agent for the golf course, is provided with the ability to access the database of the golf course and present this information to golfers over a website operated by the third party. While this technique offers real-time access to the golf courses tee sheet, it is difficult to achieve quick response time. Further, it requires a dedicated, and expensive, high speed telecommunication line between the third party agent and the golf course; otherwise, performance is unacceptably slow. And, if the high speed line goes down, the golf course cannot book tee times on-line.
The company booking tee times would also be unable to conduct any business until communications to the course were restored. Further, the Internet, currently, is neither fast nor reliable. Thus, accessing a database over an Internet connection means the database connection must be open longer. This increases the chance for deadlock and takes longer to return results to the client causing the connection to appear slow.
Another effort to provide on-line access to a golf course's tee sheet involves storing the tee sheet on a database located at the third party agent's location instead of the golf course itself. In this case, an on-line golfer wishing to book a tee time accesses the tee sheet database through the third party agent's website. While this may improve the speed of access for the on-line golfer, this method also requires an expensive high speed telecommunication line between the third party agent and the golf course in order to obtain satisfactory performance, especially since the golf course relies on access to off-site database. Moreover, if the line between the golf course and the third party agent goes down, the golf course would be unable to view its own tee sheet and would be uncertain what tee times it had already booked. The course, in essence, would be unable to conduct business until the connection was restored.
Similar problems exist in booking other type of reservations, such as those for theatre tickets or airline flights, over the Internet through a third-party agent.
Summary of the Invention One object of the invention is to overcome the difficulties discussed above. In one embodiment, invention includes the use of a dual database system with one database being located at the vendor's location. This database is directly accessible by the vendor and contains all information about the services, reservations or bookings sold by the vendor. This database may be thought of as the client-side database. A corresponding database is located at the third-party agent's location. This database is said to be on the server-side, and it includes a copy of the information stored on the client-side database. The server-side database is accessible on-line to those wishing to book reservations or purchase other services from the vendor. The client-side and server-side databases are connected to each other over the Internet. When an on-line party wishes to purchase a service from the vendor, for example if an on-line golfer wishes to book a tee time at a given golf course, he or she would access the server-side database through the agent's website. The transaction would be recorded on the server-side database and, simultaneously, a communication would be sent to the vendor to access the client-side database to confirm that the desired service (e.g., a particular tee time) is available. If so, the transaction is appropriately recorded on the client-side database and a communication is sent back, over the Internet, to the third-party agent. The server-side database is then updated to indicate that the requested purchase of services is confirmed, and an e-mail is generated back to the consumer advising him or her this fact. By the same token, if the client-side database indicates that the requested service is not available, then the appropriate message is sent back to the third party agent' s computer system. The server-side database is then updated to reflect that this service is not available and an appropriate e-mail is generated back to the potential purchaser.
Another aspect of the invention relates to the use of a message queuing system to allow communications between the databases that are distributed between server-side and client-side computer systems. In one version of the invention, the distributed database system includes a client-side queue and a server-side queue. The two queues communicate over the Internet. All messages to be exchanged between the client-side and server-side systems of the distributed database system are queued up in the appropriate queue before being sent. The queue on the server-side computer system, however, is adapted to track the dynamic IP address of the client-side system and to update outgoing messages with the most recent IP address of the client in order to assure accurate communications.
Still another aspect of the invention relates to a method for reserving services using a distributed database computer system. According to an embodiment of the invention, a request for services is received on the server-side computer system. The request for services may come from a third party connected to the server-side computer system through its web page, or through an email request. Alternately, the request may be sent to the server computer system through more traditional methods such as phone or facsimile requests, although this may require manual involvement from personnel operating the server-side computer system.
Once the request is received, the server-side computer system creates an entry in the server-side database that is responsive to the request for services. The nature of the entry will depend on the services being requested. If the requested services are a tee time at a golf course, then the entry will record the date, tee-off time, name of the golf course, and possibly other information such as the number of players, the cost and billing information, and an email address for communicating back to the person requesting the tee time. If the requested services are reservations for seats to a sporting event, for example, then the entry will contain the date, time, and location of the event, the location of the seats, as well as cost and billing information and any other information deemed desirable.
The request for services is then passed from the server-side computer system to the client-side computer system. This may be performed by various methods, such as a dedicated phone line, but preferably the communication is performed over the Internet to reduce the cost and improve performance of the communications. The client-side database is then accessed to determine whether the requested services are available. Returning to the sporting event embodiment, if the seats have already been sold, then the request must be denied. But if the seats are available, then an entry is created in the client-side database responsive to the request. This establishes the reservations for the person requesting them.
Finally, a response is generated on the client-side computer system that indicates whether the requested services were successfully booked. This response is passed to the server-side system, which updates its database to either confirm the reservation or indicate unavailability, and then sends a message to the person requesting the reservation, preferably by email, although other conventional methods could by used as a matter of design choice.
Still other objects and advantages achieved by the present invention will become apparent to those of skill in the art in view of the following detailed description of embodiments of the invention and the drawings discussed therein.
Brief Description of the Drawings Figure 1 is a block diagram showing an overview of an online distributed database system according to an embodiment of the invention.
Figure 2 is a depiction of a web page presented to an on-line consumer who wishes to purchase services over the Internet.
Figure 3 is a block diagram of an embodiment of the invention particularly useful in booking golf course tee times over the Internet.
Figure 4 is a data flow diagram depicting the operation of software running on the client-side computer system according to an embodiment of the invention.
Figure 5 is a data flow diagram depicting the operation of software according to an embodiment of the invention running on the server-side computer system.
Figure 6 illustrates the content of a typical message for reserving or booking tee times according to an embodiment to the invention.
Figure 7 is a list of typical messages which may be transferred between the client-side and server-side computer systems in connection with an embodiment of the invention for on-line booking of tee times at a client golf course.
Figure 8 is block diagram of a further embodiment of the invention useful to allow corporate booking of a collection of the vendor's services.
Detailed Description of Embodiments of the Invention FIG. 1 is a simplified block diagram showing an overview of an on-line distributed database system according to an embodiment of the invention. In this embodiment, the invention is described in connection with its application to booking tee times at remote golf course over the Internet. It will be understood, however, that the invention is not limited to booking golf course reservations, but could easily be adapted by those of skill in the art to any type of reservation system that could benefit by the use of a distributed database system described herein. In this case, a golfer 100 seeks to book a tee time at golf course 101 over the Internet 102. Golf course 101 is assumed to be previously registered with the distributed database reservation system 103. Registration of golf courses will be described later. Golfer 100 communicates with the distributed database reservation system 103 through a web page provided by the operators of the distributed database reservation system 103. The web page presents the golfer with an array of choices through conventional means such as pull-down menus, point-and-click buttons, or blank forms that can be electronically completed on-line. An exemplary format for accessing the distributed database system is shown in FIG. 2. It should be noted that the golfer 100 can select any golf course 100, regardless of its location, through this single website, as long as it is registered with the distributed database system. In this way, a golfer, who wishes to make reservations with multiple golf courses, will not have to visit multiple websites.
Once a golfer provides the information indicated in FIG. 2, he or she sends a communication to the server-side of the distributed database system 103. The server-side of the distributed database system 103 records the transaction in the server-side database and books a "pending" tee time for the golfer 100. The server-side of the distributed database system 103 then sends a communication, also over the Internet 102, to the golf course 101.
Golf course 101 runs the client-side of the distributed database system on its local computer. This communication accesses the local database stored at the golf course 101 to determine whether the tee time requested by the golfer is, in fact, available. If so, the tee time is booked on the local golf course database, and a message is sent back from the golf course database to the distributed database system 103. The distributed database system 103 then changes the status of the requested tee time from "pending" to "confirmed"
and sends an e-mail back to the golfer 100 advising him or her this result. On the other hand, if the requested tee time is not available, then the golf course 101 then communicates this to the distributed database system which, in turn, sends the appropriate e-mail to the golfer 100.
FIG. 3 is a detailed block diagram of the components for the distributed database system according to an embodiment of the invention. In this case, the golf course books its tee times on a software tee sheet running on an on-site computer. The on-site computer itself is not critical, and a suitable computer system would be a PENTIUM based computer processor running the MICROSOFT WINDOWS '95 or '98 operating systems. The computer system will typically contain a modem to communicate to the Internet through a suitable Internet service provider, such as America-On-line. It should be noted that the distributed database system described herein may rely on a low-cost Internet communication as opposed to the much more expensive, dedicated, high-speed phone lines required by other systems that do not employ the teachings of the present invention. The software running on the golf course computer will be referred to, generally, as client-side software.
The distributed database system disclosed herein is, obviously, not limited to implementation in a Microsoft windows environment. Nevertheless, for purposes of illustration, the embodiments described herein will make numerous reference to various Microsoft development products such as Microsoft Message Queue, Microsoft Transaction Server and the Microsoft Distributed Network Architecture. These development tools are described in numerous publications available from Microsoft or other vendors.
The client-side software 300 includes a number of components. One component is the calendar, or tee sheet 301. In one particularly advantageous embodiment, the calendar is created as an .EXE file through VISUAL BASIC or some other suitable software language. The calendar component 301 provides a user interface to golf course employees, allowing them to view, create, delete, and modify the tee time bookings. The calendar 301 is coupled to a local database 302 via data access layer 303. The database contains all bookings for the golf course, whether they are created manually through the calendar 301 or through the Internet as will be described later. It is preferable that priority always be given to the local database 302 so that personnel at the golf course will always have complete control of its bookings. Any suitable database may be employed for database 302, such as MICROSOFT ACCESS which creates files in the .MDB format, as long as it has capacity to store tee time information. A data access layer 303 in this embodiment is arranged between the calendar 301 and the database 302, data access layer 303 allows communication to the client-side middleware component 304. The data access layer 303 provides data security and allows network access of the local database 302 according to conventional Microsoft Distributed Network Architecture ("DNA") standards.
The middleware component 304 facilitates communications between the data access layer 303, and hence the database 302, and the server-side software 305. In addition, the client-side middleware 304 also provides software "hooks" for other third party tee sheet software packages 306. This allows, for example, a golf course which has already invested in tee sheet software to continue to use the same calendar interface and database 307 that it is accustomed to and, yet, still access the server-side software that enables golfers to make Internet bookings to the golf course. In other words, this feature of the middleware 304 allows for a golf course to substitute third party software for the calendar 301 data access layer 303 and database 302 without losing the advantages provided by the middleware component 304 and server-side software 305.
In one embodiment of the invention, the middleware 304 exchanges messages between the client-side software and the server-side software over a queue. The queue comprises a two-part message queue 308 and 309, each part being connected to the other over an Internet connection 310. The Internet connection can be provided by any common ISP. Preferably, the queue employs Microsoft Message Queue, version 1Ø Message queue 308 queues up incoming or outgoing messages to be sent to the data access layer 303 or server-side message queue 309, as the case may be. If the Internet connection 310 between the client-side software and the server-side software is disrupted, the distributed database system will not lose important messages between the client-side and server-side software, but, instead, will store the messages until Internet connection 315 is re-established. The messages will then be exchanged in order. If the Internet connection 310 is disrupted for an extended length of time, then it is advantageous to allow some messages on the server-side message queue 309 to "time out" and be passed to a "dead letter" queue (not shown). Once passed the dead letter queue, the messages will not be exchanged between the client-side and server-side if the Internet connection is re-established. Instead, they will be reported to the server-side software and handled according to other ways that may be selected as a matter of design choice. For example, if a pending request for a tee-time booking has been stored in the message queue 309 for some extended period of time, say six hours, then the request is transferred to the dead-letter queue, and the server-side software generates an e-mail back to the requesting golfer informing him that the golf course is unable to accept his reservation over the Internet. Since priority is given to the client-side database, however, it is advantageous not to allow messages queued in message queue 308 to time out. These messages will always be sent once 5 connection is established.
The message queue 309 is included within the server-side middleware 310. The server-side middleware 310 also includes a software component to implement the business logic for processing the messages that are transmitted between the client-side and server-side software. The business 10 logic is, in essence, the rules that determine how the distributed database system operates. In this embodiment, the business logic is implemented on an application server, using the MICROSOFT SERVER TRANSACTION
software, version 2Ø The application server manages the com objects that perform the functions required on the server-side software. For example, the application server communicates with a database, such as a SQL 7 database, that stores all booking information for all golf courses registered with the distributed database system. This information may also include historical booking records for statistical, billing and usage reports useful to the operator of the distributed database system and the owners of the golf courses. With respect to current tee time information, i.e., tee times booked but not yet played, the server-side database 312 should be substantially identical to the local golf course database 302 for any particular golf course. The application server 311 also communicates with the web server 313. The web server provides the web page to the booking golfer 314 over the Internet 310 according to methods well known to website developers.
The components of exemplary client-side middleware 304 will now be described in greater detail with respect to the dataflow diagram shown in FIGs. 4 and 5. This embodiment of the invention will be described as implemented in an object-oriented programming language like C++. Those skilled in the art will recognize that the particular choice of software is not critical and the inevntion is easily adapted to non-object oriented programming languages.
FIG. 4 shows a Microsoft Message Queue ("MSMQ") implemented on the server-side (MSMQ 309) and on the client side (MSMQ 308). The client side and server side communicate with each other by sending messages back and forth between MSMQs 308 and 309, which are connected by the Internet.
There are two primary categories of messages used in the system. One is referred to as B4MX NetMessages. These messages are used to communicate information about the system and are not used specifically in making golf reservations. B4MX NetMessages include "heartbeat" messages used to periodoically verify that each side of the system is operating properly, "signon" messages used to allow a course to log on to the system, "resync"
messages used to re-synchronize the client and server side databases if necessary, and any other desired messages necessary to keep the system operating properly.
The second category of messages are B4MX Messages. B4MX
Messages are related to actually booking tee time and tracking course informaiton. The data elements of B4MX Messages therefore contain information such as the date and time of the course reservation, the number of players, billing information, etc. FIG. 6 shows the fields in a typical Message, in this case, a CourseAdd message used to add a course to the system. The message has a header, containing fields for the Internet IP
address of the course, a unique club identifying number, the message type, and the version of the software that created the message. The main body of the message includes fields for the name id number and name of the course (some golf clubs have multiple courses), the local rules for the course, the course designer, number of holes, playing times, etc. Some of the methods available in a CourseAdd message include a GetMessageType to return the type of message, and SendToServer which sends the message to the server side of the system via the MSMQ.
The version of application information may be included in both categories of messages and is useful to ensure that the golf courses have properly updated their client-side software and, also, to accurately translate any incoming message from non-current versions of client-side software which may be in use. The golf course name is typically an ASCII string that uniquely identifies the registered golf course. The golf course IP address is the Internet address that the MSMQ 309 must communicate over the Internet 315 so that it accurately can transmit message information to the desired golf course. It should be noted that unlike systems that use conventional dedicated phone lines and networking techniques, the IP address for computers connected to the Internet is dynamic. That is, the IP address for the particular computer changes each time the computer connects to the Internet. The solution to this problem will be discussed in greater detail herein with respect to the handshaking between the MSMQ queues 308 and 309.
FIG. 7 is an exemplary list of B4MXMessages and B4MXNetMessages useful with an embodiment of the invention.
Referring now to FIG. 4, it is seen that MSMQ 309 is connected through the Internet 315 to the MSMQ 308 on the client-side. The MSMQ 308 sends and receives messages to B4MC Monitor 400. B4MC Monitor 400 is a software object that operates the MSMQ 308 by pushing and pulling messages to and from the MSMQ. B4MC Monitor 400 also analyses incoming messages from the MSMQ 308 and decides whether to forward them to B4MC Net Receiver 401 or B4MC Receiver 402, depending on the category of the incoming message. If B4MC Monitor 400 determines that an incoming message from MSMQ 308 is an B4MX NetMessage it passes the message to object B4MC Net Receiver 401. B4MC Net Receiver 401 performs a task according to the B4MX NetMessage it received, then it creates another instance of B4MX NetMessages containing the result of the task. The instance of B4MX NetMessages is then sent to B4MC Monitor 400.
B4MC monitor 400 then passes this message on to MSMQ 308 for transmission to the server-side software, via the Internet 315, to server-side MSMQ 309.
If B4MC Monitor 400 determines that the incoming message from MSMQ 308 is a B4 MXMessage, then it passes the message to B4MC
Receiver 402. B4MC Receiver 402 is typically a com object that translates the incoming message into instructions that can be passed directly to the data access layer 303. The data access layer, includes B4MC Data Access 303 in FIG. 4. B4MC Data Access contains logic for processing the messages from B4MC Receiver 402. This logic includes logic to operate the database 302.
For example, an incoming request to Book a tee time to causes B4MC Data Access 303 to access database 302. Database 302 contains a number of stored procedures that are invoked by messages from B4MC Database Access 303 according to conventional techniques known to those skilled in the art.
B4MC Data Access 303 also receives messages for booking tee times from the calendar interface 301 which is operated by personnel at the golf course. On receiving a message to book a tee time from the calendar interface 301, B4MC Data Access 303 accesses database 302 and generates a message to B4MC Receiver 402 informing it of this action. B4MC Receiver then generates an instance of B4MX Messages that contains information about the calendar booking.
If a booking is successfully completed in response to a B4MX
Message, B4MC Receiver 402 sends a message to calendar 301 to update its display, informing personnel at the golf course that a specific tee time has been booked. B4MC Receiver 402 also generates a new instance of B4MXMessages that contains information about the succesful booking.
Conversely, if the booking were unsuccessful that would be reflected in the content of the B4MXMessage. The B4MXMessage is then passed to B4MC
Monitor 400 for transmission to the server side of the system via the MSMQ.
FIG. 5 is a dataflow diagram depicting the operation of the server-side software 305. The server-side software in this embodiment to the invention includes the Server-side middleware 310. The server-side middleware 310 is similar to that of the client-side software in that it includes a number of software objects that perform administrative and booking tasks corresponding to those performed by the client-side soft ware.
B4MS Monitor 500 communicates with MSMQ 309 on the server-side.
On receiving a message from MSMQ 309, B4MS Monitor 500 determines whether the message is a B4MXNetMessage (i.e., an administrative message) or a B4MXMessage (i.e., a data message). If it is an administrative message, B4MS Monitor 500 passes the message to B4MS Net Receiver 501. B4MS Net Receiver translates the message into instructions to another message containing instructions be performed by B4MSADMINCOM 502.
B4MSADMINCOM 502 forwards the instructions to other software modules such as ADMIN APP 503 and B4MS Administrator Database 513, that actually perform the requisite system tasks. These tasks include searching for golf course IDs and creating new golf course IDs in the B4MS
Administrator Database 505. The B4MS Administrator Database 505 stores information about the golf courses registered with the distributed database system. After ADMIN APP 503 or B4MS Main Database 504 perform the required tasks, the results are passed back to B4MSADMINCOM 502.
B4MSADMINCOM 502 then creates a B4MX Net Message 505, to be sent back to the client-side software via B4MS Monitor 500 and MSMQ 309, assuming a response to the client-side is required. B4MSADMINCOM 502 may also originate messages to be sent to the client-side, depending on the nature of the administrative message.
If B4MS Monitor 500 determines that an incoming message from the MSMQ 309 is a data message, it passes the message to B4MS Distributor 506. B4MS Distributor is an object that creates a temporary software objects referred to as a B4MS workers. A B4MS Worker is an object that communicates with the application server software 508. The application server software is preferably implemented from server software, such as Microsoft Transaction Server. The application server 508 includes software objects B4TC Transactions 509 and B4TWT Transactions 510. B4TC
Transactions 509 receives information from the B4MS Worker objects 507.
This information may contain, for example, a message from B4MS Distributor 506 that instructs B4TC Transactions 509 to change the status of a pending book tee time in the main database 312 and send an e-mail message to notify the booking golfer of the change in status. It should be noted that use of multiple B4MS Workers 507 is preferable because it allows the server-side software to multi-task a number of incoming booking requests, thereby improving system performance.
The operation of the distributed database system will now be described in greater detail with respect to an Internet booking. In this embodiment, a 5 golfer connects to the server's website 313 over the Internet 315. After completing the information that appears on the golfer's browser, the golfer sends the information to the application server software 508. B4TWT 510 accesses the server-main database 312 and invokes a stored procedure. The stored procedure determines whether the requested tee time at the requested 10 course is available. If so, it creates an entry into the database that is associated with a "pending" status. At this point, the requested tee time is only pending because the server-side software has not received confirmation from the golf course that the requested tee time is, in fact, available. Since the golf course tee sheet database is always given priority, according to this 15 version of the invention, the requested tee time will not be confirmed until a confirmation message is received back from the golf course. This is advantageous because the Internet communication system is not always reliable and the golf course will be booking tee times over the telephone or other non-Internet methods.
The B4TWTransaction process 510 then passes this information to B4MSDatasend 511. B4MSDatasend 511 creates in instance of B4MX
Messages 512. Referring to FIG. 7, the type of B4MXMessage is a BookingAddFromServer (referred to as a "booking add" message). B4MX
Messages 512 is sent to B4MS Monitor 500, where it is queued up in a conventional manner, with the exception of the use of a dynamic IP address in the header filed, which will be described in greater detail later.
The MSMQ 309 then transmits the booking add message over the Internet 315 to the MSMQ 308 on the client-side. The booking add message is then passed to B4MC Monitor 400, which recognizes the message as a booking message from the header information and forwards it to B4MC
Receiver 402. B4MC Receiver 402 then translates the message into a format suitable for B4MCData Access 303. B4MC Data Access 303 then sends a request to the tee sheet database 302. This invokes a stored procedure on the tee sheet database 302 which attempts to book the requested tee time.
The results of this attempted booking are then passed back through B4MC
Data Access 303 to B4MC Receiver 402 which creates another instance of B4MXMessages (type BookingRespFromClient) that contains the results of the attempted booking in its message body. B4MC Receiver 402 then passes the message to B4MC Monitor 400, which in turn transmits it to MSMQ 308.
MSMQ 308 queues up the message in a manner that is conventional with the MSMQ software.
The message is then transmitted over the Internet 315 to MSMQ 309, which in turn passes it to B4MS Monitor 500. B4MS Monitor 500 now analyses the message and determines it is an incoming data message related to an attempted booking over the Internet. Accordingly, B4MS Monitor 500 passes the message to B4MS Distributor 506. B4MS Distributor 506 then creates or uses an existing Worker Object 507 to handle the message. The Worker Object 507 then translates the message into a format that can be processed by B4TC Transactions 509. B4TC Transactions object 509 interprets the message information and generates an e-mail to the golfer advising him or her whether the requested tee time is confirmed. If not, B4TC
Transactions will typically include a message explaining to the golfer the reasons why the request failed, such as the tee time is unavailable, the golf course is unavailable, or the golf course is currently unable to process Internet requests. If the tee time request is available, then B4TC Transaction 509 will also invoke a stored procedure at the server-side main database 312 that changes the status of the request from "pending" to "confirmed." A
confirmation email will be sent to the golfer.
Another common action is a calendar booking. In this case, a reservation is booked over the phone, or through some other means by personnel at the golf course. Golf course personnel book tee times through the calendar interface 301. The particular interface used is not critical, and its operation is a matter of design choice, as long as it provides efficient functionality for golf course personnel to specify the date, time, and any other 1~
desired information to be associated with the reservation. This information is then passed through B4MC DataAccess 303 and placed into the golf course database 302. The calenday then creates a B4MX Message 403 to advise the server-side software of the booking. The message is then forwarded through B4MC Monitor 400, MSMQ 308, MSMQ 309, and on to B4MS Monitor 500. B4MS Monitor 500 then passes this message to B4MS Distributor 506 through a worker 507 and on to B4TC Transactions 509. B4TC Transactions 509 then invokes a stored procedure in the database 312 and records the tee time reservation.
As discussed earlier, administrative messages are used to ensure that the client-side and server-side systems are properly operating together. For example, one advantageous message is a heartbeat message. A heartbeat message is a type of B4MXNetMessage. B4MSADMINCOM generates a periodic heartbeat message to be sent to the client system. This heartbeat allows the server to track whether the client server has gone off-line and for how long. The heartbeat message is passed from B4MS ADMIN COM 502 to B4MS Monitor 500. B4MS Monitor 500 then sends the heartbeat message through MSMQs 308 and 309 to B4MC Monitor 400 on the client-side software. B4MC Monitor 400 recognizes the message as a heartbeat message and forwards it to B4MC Net Receiver 401. B4MC Net Receiver 401 then translates the message and generates an instance of B4MXNetMessage 403 responsive to the heartbeat request. The B4MXNetMessage is forwarded to B4MC Monitor 400 which sends it back to B4MS Monitor 500. B4MS monitor 500 recognizes this as a response to the heartbeat message and forwards the message to B4MS Net Receiver 501 which translates the message and causes B4MS ADMIN COM to invoke a stored procedure in an administrative database 513 to store the golf course name, date, and time of the last communication received in response to the heartbeat request. Should problems arise, personnel operating the server-side system can access the heartbeat database in administration database 513 and determine the last time the server-side system received a communication from the client-side.
Ig Alternately, reports can be generated or the service side software could take action on its own to aid in resolving the communication problems between the server and client systems. For example, an error message could be automatically generated and displayed at the server-side software informing personnel there to contact the golf course to find out why no communications had been received for a pre-determined period of time.
Other administrative communications include, for example, a sign-up communication. A sign-up message is used whenever a new golf course is to be registered with the distributed database system. In this case, when the client-side software is first initiated on the client computer, the golf course personnel are prompted to enter a variety of information about the golf course into the system through the server-side website interface. This information may include the name of the golf course, the number of courses available at the golf course, contact and billing information, location of the course, e-mail addressee, any special seasons or times in which the course is not available, and any particular times the course may wish to "block out," i.e., decline to accept reservations over the Internet. Other information may, of course, be included as a matter of design choice. This information is stored in a series of B4MXNetMessages and B4MXDataMessages and forwarded through the MSMQs to B4MS Monitor 500. The B4MS Monitor 500 then forwards the information to a B4MSNet Receiver 501, B4MS ADMIN COM 502, ADMIN
APP 503, and on to B4MS Main DB 504. B4MS Main DB 504 then invokes a stored procedure in golf course main database 312 so that the information is stored and the course is now available for on-line booking through the I nternet.
Those of skill in the art recognize it is important that messages be reliably transmitted between the clients and server-side systems. Although the Internet connection 315 is convenient and low cost, it is not typically as reliable as the more expensive dedicated phone lines used in prior art systems. Further, unlike dedicated phone line systems in which the IP
address for the client computer is static, the IP address for the client computer system is dynamic, i.e., it will change each time the client connects to the Internet 315. Moreover, the IP address of the client can change between the time a message for the client is queued up and the time it is actually sent.
This would result in a message being undeliverable, and, hence, lost. To overcome these problems, the server-side software maintains the current IP
address for the desired golf course in the golf main database 312. Whenever the IP address of a golf course changes, it sends a log-on message that contains, among other things, the name of the course and the IP address assigned to the course for this particular Internet session. When the B4MS
Monitor 500 receives this message, it passes it to B4MS MainDB 504. The B4MSMainDB 504 then invokes a stored procedure in golf main database 312 to update the IP address associated with that golf course. Whenever an outgoing message stored in the MSMQ 309 is scheduled to be forwarded over the Internet, B4MS Monitor 500 retrieves the latest IP address for the golf course from the golf course main database 312 and inserts it into the IP
address field of the outgoing message. In this way, the outgoing messages always have the latest IP address available for any particular golf course.
This eliminates any problems that could be caused by a change in the IP
address from the time the message is originally queued up to be sent and the time the message is actually sent over the Internet.
In the specific embodiment of the invention in which the Microsoft Message Queue Software is used to communicate over the Internet, those of skill in the art will appreciate that the MSMQ system retrieves the IP address from a database referred to as MQIS in Microsoft documentation. Therefore, before the message is actually sent, B4MS Monitor 500 retrieves the IP
address for the golf course and inserts it into the MQIS database at the desired location for that particular message. The message is then forwarded to the MSMQ 308 on the client-side.
In a further embodiment, the invention lends itself to corporate tee time bookings. Corporate tee time bookings are useful when a corporation owns a number of courses across the country. This embodiment of the invention is discussed in greater detail with respect to FIG. 8. In this case, the computer is located at the corporation's location 805 and connected to the distributed database system server-side 800. The distributed database system is, in turn, connected over the Internet to a variety of golf courses in 802-804, owned by the corporation 805. The corporation 805 can create parameters that concern any or all of its golf courses 802-804 by sending messages to the 5 computer database system 800 to make the appropriate entries into its main course database. These entries can include a specification of seasons during which the courses will be open, the prices charged for playing at certain seasons or times, the blocking out of any time periods during which the golf course is not to make bookings over the Internet, and any other parameters 10 that the corporation deems useful. The server-side system then stores these parameters into the main database 312 and the business logic located on the distributed database system will operate accordingly. Thus, if the corporation decides that it does not wish to permit Internet bookings on any of its golf courses for weekend tee times for the hours between 7 and 10 a.m., it can 15 communicate this request to the distributed database system 800. If an Internet request comes in, a distributed database system attempting to request a tee time during these hours, this will be detected by logic in the B4TW Transaction object 510, which is the communication with the main database 312. The application server 508 would then cause B4TC
20 Transactions 509 to generate an e-mail to the booking golfer denying his request.
In addition, the distributed database system 800 may track historical information about all tee times that have been booked on the ledger database 801. This data may then be submitted to the corporation in a form of utilization reports to allow the corporation to assess the functionality of a distributed database system.
Although the present invention has been described with respect to application to an Internet-based golf tee time reservation system, it will be appreciated by those of skill in the art that it is not so limited and is easily extendable to other types of reservation systems and Internet communication systems by those of ordinary skill in the art.
Claims (14)
1. A method for reserving services using a distributed database computer system comprising:
Receiving a request for services on a server-side computer system;
Creating an entry in a server-side database responsive to the request for services;
Passing the request for services to from the server-side computer system to a client-side computer system;
Accessing a client-side database to determine whether the requested services are available;
Creating an entry in the client-side database responsive to the request for services if the requested services are available;
Generating a response on the client-side computer system that indicates whether the requested services were available;
Passing the response to the server-side database;
Updating the server-side database according to the response.
Receiving a request for services on a server-side computer system;
Creating an entry in a server-side database responsive to the request for services;
Passing the request for services to from the server-side computer system to a client-side computer system;
Accessing a client-side database to determine whether the requested services are available;
Creating an entry in the client-side database responsive to the request for services if the requested services are available;
Generating a response on the client-side computer system that indicates whether the requested services were available;
Passing the response to the server-side database;
Updating the server-side database according to the response.
2. A method as in claim 2 wherein the step of receiving a request for services comprises receiving a communication from a computer system connected to the server-side computer system over a telecommunications link.
3. A method as in claim 2 wherein the telecommunications link comprises an Internet connection.
4. A method as in claim 1 wherein the step of creating an entry in a server-side database comprises reserving the requested services in the server-side database as pending.
5. A method as in claim 1 wherein the step of passing the request for services comprises generating a message responsive to the request for services and queuing the message on a server-side queue before passing the message to the client-side computer system.
6. A method as in claim 5 wherein the step of passing the message to the client-side computer system comprises passing the message to a corresponding queue on the client-side computer system over an Internet connection between the server-side and client-side computer systems.
7. A method as in claim 6 further comprising the step of updating the message with the most recent IP address of the client-side computer system available to the server-side computer system before the message is passed over the Internet connection.
8. A method as in claim 1 wherein the step of updating the server-side database comprises designating the entry in the server-side database as confirmed if the response indicates the requested services were available.
9. A method as in claim 8 further comprises the step of sending an email communication over the Internet to the computer system from which the request for services was received indicating whether the requested services were reserved.
10. A method for reserving golf tee times over the Internet using a distributed database computer system, the method comprising the steps of:
Receiving a request to reserve a tee time on a server-side computer system from a requesting computer system connected to the server-side computer system over the Internet;
Creating an entry in a server-side database responsive to the requested tee time;
Passing the requested tee time from the server-side computer system to a client-side computer system over the Internet;
Accessing a client-side database to determine whether the requested tee time is available;
Creating an entry in the client-side database that reserves the requested tee time if the requested tee time is available;
Generating a response on the client-side computer system that indicates whether the requested tee time is reserved;
Passing the response to the server-side computer system over an Internet connection;
Updating the server-side database according to the response;
and Sending a communication over the Internet to the requesting computer system that indicates whether the tee time is reserved at the golf course.
Receiving a request to reserve a tee time on a server-side computer system from a requesting computer system connected to the server-side computer system over the Internet;
Creating an entry in a server-side database responsive to the requested tee time;
Passing the requested tee time from the server-side computer system to a client-side computer system over the Internet;
Accessing a client-side database to determine whether the requested tee time is available;
Creating an entry in the client-side database that reserves the requested tee time if the requested tee time is available;
Generating a response on the client-side computer system that indicates whether the requested tee time is reserved;
Passing the response to the server-side computer system over an Internet connection;
Updating the server-side database according to the response;
and Sending a communication over the Internet to the requesting computer system that indicates whether the tee time is reserved at the golf course.
11. A method as in claim 10 wherein the step of passing the requested tee time comprises generating a message responsive to the requested tee time and queuing the message on a server-side queue before passing the message to the client-side computer system.
12. A method as in claim 11 wherein the step of passing the message to the client-side computer system comprises passing the message to a corresponding queue on the client-side computer system over an Internet connection between the server-side and client-side computer systems.
13. A method as in claim 12 further comprising the step of updating the message with the most recent IP address of the client-side computer system available to the server-side computer system before the message is passed over the Internet connection.
14. A method for communicating messages over the Internet using a plurality of communication queues, the method comprising:
Connecting a first communication queue on a first computer system over an Internet connection to a second communication queue on a second computer system having a dynamic IP address;
Maintaining a database on the first computer system that stores the IP address for the second computer system each time the first computer system detects that the IP address for the second computer system has changed;
Storing a message in the first communication queue that includes an IP address for the second computer system;
Updating the message in the first communication queue with the most recent IP address for the second computer system before the message is sent from the first communication queue to the second communication queue.
Connecting a first communication queue on a first computer system over an Internet connection to a second communication queue on a second computer system having a dynamic IP address;
Maintaining a database on the first computer system that stores the IP address for the second computer system each time the first computer system detects that the IP address for the second computer system has changed;
Storing a message in the first communication queue that includes an IP address for the second computer system;
Updating the message in the first communication queue with the most recent IP address for the second computer system before the message is sent from the first communication queue to the second communication queue.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2296433 CA2296433A1 (en) | 2000-01-19 | 2000-01-19 | Method for purchasing services using a distributed database reservation system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2296433 CA2296433A1 (en) | 2000-01-19 | 2000-01-19 | Method for purchasing services using a distributed database reservation system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2296433A1 true CA2296433A1 (en) | 2001-07-19 |
Family
ID=4165118
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2296433 Abandoned CA2296433A1 (en) | 2000-01-19 | 2000-01-19 | Method for purchasing services using a distributed database reservation system |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2296433A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007086718A1 (en) * | 2006-01-30 | 2007-08-02 | Alberto Vargas Chavez | System and method for the internet exchange of golf course tee times |
| WO2011156890A3 (en) * | 2010-06-17 | 2012-02-02 | Ian Huang | Online appointment booking system |
| CN113765975A (en) * | 2020-11-12 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | Information processing method and device and storage medium |
-
2000
- 2000-01-19 CA CA 2296433 patent/CA2296433A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007086718A1 (en) * | 2006-01-30 | 2007-08-02 | Alberto Vargas Chavez | System and method for the internet exchange of golf course tee times |
| WO2011156890A3 (en) * | 2010-06-17 | 2012-02-02 | Ian Huang | Online appointment booking system |
| CN113765975A (en) * | 2020-11-12 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | Information processing method and device and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3427933B2 (en) | Processing long-term transactions in client-server systems | |
| US7167904B1 (en) | Unified web-based interface-to multiple registrar systems | |
| AU2001271596B2 (en) | System and method for integrating public and private data | |
| US6845448B1 (en) | Online repository for personal information | |
| US9934321B2 (en) | System and method of accelerating response time to inquiries regarding inventory information in a network | |
| US6883142B2 (en) | Method and system for providing service to remote users by inter-computer communications | |
| US7076558B1 (en) | User-centric consent management system and method | |
| JP3906010B2 (en) | Transaction management apparatus, transaction management method, and recording medium | |
| US7743100B2 (en) | Method and system for controlled distribution of one or more distinct profiles for a user | |
| US20020046279A1 (en) | Methods and systems for call processing utilizing a uniform resource locator | |
| US20020059436A1 (en) | Service provision method via a network and service provision system using the same | |
| US20050015425A1 (en) | Transaction manager freezing | |
| WO2000057298A2 (en) | Apparatus and method for providing a business card web page | |
| KR20020022650A (en) | A shared registration system for registering domain names related application | |
| JP2003523011A (en) | Information service | |
| JPH10511793A (en) | Data management computer system and method of operating this system | |
| US7636669B1 (en) | Recreational outing reservation system | |
| US20020173996A1 (en) | Method and system for asynchronously booking travel inventory | |
| US20050114185A1 (en) | Method and apparatus for restaurant ordering and reservations | |
| CA2296433A1 (en) | Method for purchasing services using a distributed database reservation system | |
| WO2003073217A2 (en) | Auction bidding system for wireless internet enabled telephones | |
| JP2002215945A (en) | Reservation management method, reservation management program, and recording medium recording reservation management program | |
| WO2001086382A2 (en) | Methods and systems for call processing utilizing a uniform resource locator |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |