HK1178008A - Booking method and system - Google Patents

Abstract

The invention relates to a booking method and system, wherein, provided is a method of a mediator carrying on a communication with a client terminal having a client identifier address, including: a) initializing a communication with the client terminal, including associating a particular reply address to which a reply to a dialogue needs to be directed, including selecting the particular reply address from a multiplicity of addresses at which the mediator receives replies; b) initiating a dialogue to the client terminal that includes the particular reply address; c) receiving a reply at the particular reply address from the client terminal, the reply including the client identifier address; and d) evaluating the reply using the client identifier address and the particular reply address at which the reply is received; further including storing the replies in a matrix having a first axis corresponding to client identifier addresses and a second axis corresponding to reply addresses. The method and system are particularly suited for use with mobile phone users by Small Message Service messages.

Description

Booking method and system

The application is a divisional application, the original application of which has the application number of 03819821.5 and the application date of 8/21/2003, and the invention is named as a reservation method and a reservation system.

Technical Field

The present invention relates to the field of telecommunications. In particular, the present invention relates to a method and system for booking in a booking system and synchronizing bookings in several booking systems comprising at least one booking system; involving at least one service provider; a broker service; the client and the at least one client terminal device, which may be mobile devices, include a dialog. Further, the system includes a telecommunications connection for connecting the reservation system, the service provider, the mediator, and the client terminal device.

Background

Services subscribed to or used through the internet are increasing. The internet enables people to use a variety of online services, such as services connected to banks, healthcare services, travel agencies, vehicle maintenance, etc.

The increasing popularity of mobile computing and communication devices presents new challenges to services on the internet. The mobile terminal can transmit information to the user when needed. Users desire ubiquitous access to information and applications from devices at hand. They also want to be able to access and update information wherever they go.

However, it is important to note that not all terminals are mobile. Future services must be able to communicate with a large number of terminal devices, which may or may not be mobile. Different terminal devices have very different capabilities.

The interoperability of different services and terminal devices requires multiple levels of standards. That is, it is not sufficient to have a common communication protocol. It is important to share common principles and understand what a certain piece of data means in a particular environment. However, because there are very many companies, organizations, and other participants in the field, it is very difficult to agree on these issues.

Many services must be able to manage subscriptions. They include, for example, subscribing to healthcare service appointments; booking travel hotel, airline, and taxi reservations; booking tickets for the venue; booking a vehicle maintenance appointment; subscription apartment maintenance, and the like. This is very useful if these services get information from each other. For example, if a customer is booking a ticket for a concert, he or she may also wish to book a counter in a restaurant. This is helpful if the restaurant reservation service gets basic information, such as the date and customer name from the reservation system of the theater. Unfortunately, there is no way to exchange information in different types of subscription systems.

There are a number of ways to exchange information between services. With respect to services that include subscription or calendar functionality, information exchange often occurs when subscriptions or calendar entries are synchronized. For this reason, several important standardization efforts are ongoing. For example, SyncML is an industry initiator that proposes a common data synchronization protocol.

vCalendar is an exchange format for personal schedule information. It is applicable to many calendar and scheduling products and is useful in exchanging information in a variety of transportation methods. Many vendors have adopted this specification because it allows the vendors' products to exchange calendar and scheduling information. vCalendar is an Open specification based on industry standards such as the x/Open and XAPIA Calendar and Scheduling API (CSA), the ISO 8601 international date and time standard, and the related MIME email standard. The vCalendar format facilitates cross-platform exchange of information about entries such as events and do-things using data typically stored in calendar and scheduling applications. An event is a calendar and scheduling entity that represents a specified amount of time on the calendar. A task is a calendar and schedule view representing a behavior entry or task. For example, it may be a work item assigned to an individual.

vCard is used to automatically exchange personal information that is typically present on traditional business cards. vcards are used in applications such as internet mail, voice mail, web browsers, telephony applications, call centers, video conferencing, PIM (personal information manager), PDA (personal data assistant), pagers, facsimile machines, office equipment, and smart cards. In addition to text, vCard information may include elements such as pictures, company logos, on-site web sites, etc.

As these examples illustrate, a great deal of effort has been expended to establish a system that enables the synchronization of reservation systems. One problem common to all of these existing solutions is that they do not provide common semantics for different systems. For example, if the login (entry) is trial, different systems may understand the login in different ways.

Another problem is that the reservation system has a number of different and often quite complex user interfaces. If the user wants to book a dentist and book a rental car to take him or her there, the user needs to enter all the booking information into the two booking systems in different ways.

Yet another problem is that managing customer replies becomes challenging if the client is given many questions. For example, since it is very common in many countries, such as finland, to communicate using SMS text messages and to create revenue for the operator, it makes sense to ask the customer using SMS text messages which option he or she chooses. However, if the client replies to multiple queries by sending multiple text messages, finding which answer (answer) corresponds to a particular question may be cumbersome because the reply (reply) does not automatically contain a reference to the question. Say, a service asks the customer if he or she wants to book a taxi and hotel room in addition to an airline ticket, and the customer replies "yes" to one question and "no" to another question, the service does not necessarily know which booking the customer has accepted.

Disclosure of Invention

It is an object of the present invention to obviate one of the above-mentioned drawbacks or at least to avoid them to a large extent. The invention enables new value added services which are particularly essential for mobile services.

It is another object of the present invention to provide a method and system for enabling a subscription-type transaction involving at least one service provider and a plurality of users, each of which may communicate using a mobile telephone capable of receiving and sending short text messages.

It is a further object of the present invention to provide a method and system for conducting subscription-type transactions between a plurality of service providers and a plurality of users, each of which may communicate using a mobile telephone capable of receiving and sending short text messages.

According to an aspect of the present invention, there is provided a method for a mediator to communicate with a client terminal having a client identifier address, comprising: a) initiating communication with said client terminal, including associating a specific reply address with a reply to which a dialog must be directed, including selecting a specific reply from a plurality of addresses at which replies are received by said mediator; b) initiating a dialog with the client terminal, the client terminal including the specific reply address; c) receiving a reply from the client terminal at the particular reply address, the reply including the client identifier address; and d) evaluating said reply using said client identifier address and said particular reply address from which said reply was received; further comprising storing the reply in a matrix having a first axis corresponding to the customer identifier address and a second axis corresponding to the reply address.

According to another aspect of the present invention there is provided a mediator for controlling communications between at least one service provider and a client terminal, the client terminal having a client identifier address, the mediator comprising: a) a plurality of addresses at which the mediator can receive messages from the client terminals; b) logic and resources to: i) initiating communication with a client terminal with respect to a particular service provider, including associating a particular reply address with a reply to which the dialog must be directed, the particular reply address being selected from the plurality of addresses; ii) initiating a dialog with the client terminal, the client terminal including the specific reply address; iii) receiving a reply at the particular reply address; and iv) evaluating said reply using said client identifier address and said particular reply address from which said reply was received; wherein the communication comprises a plurality of conversations and reply exchanges with the client terminal, and different reply addresses are associated with different conversations and reply exchanges; wherein the logic and resources adapted to initiate the communication comprise a matrix having a first axis corresponding to a customer identifier address and a second axis corresponding to a reply address.

According to another aspect of the present invention, there is provided a mediator for controlling a system having at least one service provider and a client terminal device used by a client having a client identifier address, the mediator including: a) a plurality of addresses at which the mediator is able to receive messages from the client terminals, b) logic and resources to: preparing at least one dialog, in response to an inquiry about the service provider, associating a specific reply address with each dialog, the specific reply address being selected from the plurality of addresses, sending the at least one dialog to the client terminal, receiving a reply from the client terminal device including the client identifier address at the specific reply address; and evaluating said reply using said client identifier address and said particular reply address from which said reply was received; wherein the logic and resources comprise a matrix comprising a first axis indexed by a customer identifier address and a second axis indexed by a reply address; wherein a plurality of dialogs are prepared in response to the request, and wherein the logic and resources adapted to associate particular reply addresses are adapted to select different particular reply addresses to associate with each dialog, whereby the logic and resources are adapted to evaluate replies even if different replies are received in different orders with different dialogs.

According to another aspect of the invention, there is provided a method for a broker of a client from a service provider to subscribe to a resource, the client having a client identifier address and communicating with the broker using a client terminal device, the broker performing the acts of: a) preparing at least one dialog in response to the request; b) associating a specific reply address with each conversation, said specific reply address being selected from a plurality of addresses available for receipt from client terminal devices; c) transmitting the at least one dialog to the client terminal device; d) receiving a reply to the at least one conversation from the client terminal device, the reply including the client identifier address; and e) evaluating a reply to the at least one conversation using the client identifier address and the particular reply address; further comprising storing replies to the at least one conversation in a matrix comprising a first axis indexed by client identifiers and a second axis indexed by reply addresses; the at least one dialog includes a plurality of dialogs having different specific reply addresses associated with each dialog, whereby the replies can continue to be evaluated even if the replies are received in a different order than the sent dialogs.

According to another aspect of the present invention, there is provided a method of authenticating a customer using a mobile telephone device capable of sending and receiving SMS messages and having a calling line identification number of the customer, by a mediator, which performs the actions of: a) assigning a unique reply address to the SMS conversation from a plurality of available reply addresses; b) sending said SMS conversation to said customer with said customer's calling line identification number; and c) authenticating the client if a reply to the SMS conversation is received at the unique reply address; wherein the mediator comprises a network server programmed to perform the method, and wherein the method further comprises storing the reply in a matrix comprising a first axis indexed by a caller identifier number of the client and a second axis indexed by a reply address.

Drawings

In the following sections, the invention will be described in detail by means of a few examples of its embodiments, in which

FIG. 1 shows a system according to a first embodiment of the invention;

FIG. 2 shows a system according to a second embodiment of the invention;

FIG. 3 shows a system according to a third embodiment of the invention;

Fig. 4 is a first embodiment of a sequence diagram representing messages transmitted in a system according to the invention;

fig. 5 is a second embodiment of a sequence diagram representing messages transmitted in a system according to the invention;

FIG. 6 illustrates an example of a dynamic dialog matrix applied to queries and replies in accordance with the present invention;

FIG. 7 illustrates the stages of the subscription process in a preferred embodiment of the present invention; and

fig. 8 shows a matrix diagram corresponding to example 2, according to a preferred embodiment of the present invention.

Detailed Description

The present invention relates to exchanging and synchronizing information between a subscription system and user terminal devices. The service may be, for example, a subscription to a healthcare service appointment; booking travel hotel, airline, and taxi reservations; booking tickets for the venue; booking a vehicle maintenance appointment; subscription apartment maintenance, and the like.

The booking system according to the invention comprises at least one service provider booking system; at least one service provider; a mediator (also called mediator); a customer; at least one client terminal device, which may be a mobile device capable of receiving text messages, and including a dialog (dialog); and a telecommunications connection for interconnecting the service provider booking system, the service provider, the mediator, and the client terminal device with each other.

A service provider is a service provider with which a customer wants to make a reservation, or other booking, and has resources of the booking system to be allocated. The service provider manages the business by subscribing to services by the service provider. As used herein, a broker is a network-based service that can be used by a network to subscribe to services for a service provider, providing additional semantics, translation, and synchronization services needed for the communication of information needed by the customer to complete a transaction with the service provider. The service provider subscription service and mediator are preferably applications running on a network server, such as the internet or a private intranet. In general, the system will include multiple service providers and service provider booking systems (implementing service provider booking services), but may have a simple booking system for only one service provider, in which case the broker and service provider may be tightly integrated into a single application.

The client preferably comprises a client communicating on a mobile telephone capable of receiving short text messages, such as Short Message Service (SMS) messages. Of course, a system capable of handling SMS messages will also handle other clients with greater capabilities. The mediator preferably communicates with the mobile phone client via an SMS gateway, for example operating via mobile phone providers and devices well known today. The mediator communicates with the client using a dialog. A conversation is a short message that presents information to a client and allows simple replies. The dialog preferably provides the user with a simple choice, e.g. yes/no, or allows a selection from an ordered list (orderedlist). The dialog may also be one-way, e.g. positive subscription. A transaction may typically involve a list of conversations, each of which includes a simple reply. A conversation includes asynchronous communication of messages. The system makes it possible to coordinate bookings among different service provider systems to meet customer needs, such as coordinating airline bookings with transportation to airports.

Figure 1 is a diagram of the simplest system that includes a single service provider booking system 100 for a single service provider, a mediator 102 in communication with the service provider over a network, and a user with a mobile phone having a conversation entered thereon.

FIG. 2 illustrates a plurality of service provider booking systems in communication with a broker over a network.

Figure 3 shows a mediator named boot communicating with various service provider systems and users having telephone devices capable of communication sessions.

From a client perspective, reason-based client dialogs are a desirable improvement because the service provider can create its own dialog connected with each subscription time. A dialog is closely related to a specific subscription condition. At which point it automatically becomes active or the client can initiate a conversation as needed or another entity in the system can send a message to the conversation to initiate it. The dialog then sends a query to another entity in the system, or notifies the customer, and possibly queries the customer for a selection. With this type of dialogue, the client can make reservations in several reservation systems using only one user interface. The dialogue is connected to the remote booking system, for example via the internet or even a mobile network.

The broker service can communicate subscription information between service provider subscription systems. For example, after entering a reservation into an airline reservation system, a taxi reservation system can provide a shipment to an airport to a client. In this application, a reservation is an allocation of a single resource (either an airline reservation or a taxi reservation in the previous example), while a reservation is a combination of reservations made for all resources of the same event (airline reservation plus taxi reservation in the previous example). The dialogue between the client, mediator, and subscription system and the stored user profile ensures that the client gets the reason-based service he or she needs without inserting advertisements.

Customers may subscribe to and confirm, change, and cancel them using many types of communication devices including, but not limited to, the internet, email, and mobile terminals, among others. The client may also use the synchronization function of the mediator to synchronize a calendar provided by the mediator or the service provider with the terminal device.

The service provider may prompt the customer for periodic bookings to increase customer loyalty. The broker may help the service provider bring their subscription systems together to provide a more comprehensive service without having to scale their business. Because of internationalization, the mediator can support many languages, time zones, currencies, and data formats, for example.

The system includes at least one dialog, mediator, service provider, and service provider booking system, which may be based on one of the following criteria:

1. there is a set of predetermined dialogs in the system. Their content and possible selections are preset. For example, if a client subscribes to a ticket, the dialog always provides some other subscription. Without considering the prior behavior of the client.

2. There are an unlimited number of dynamic or "intelligent" conversations that are based on, for example, the customer's created profile, usage history, and customer location for himself or herself. Simple logic supports the decision. It is a low level expert system.

3. The system can make decisions on its own and support the customer in making decisions. At this level, the dialog may include an advanced expert system. It can act as a proxy to negotiate with several service providers to obtain the best service without the direct involvement of the customer.

In a preferred embodiment of the method, the client subscribes to a service from a service provider. The subscription may be performed using a terminal connected to the broker service. First, the customer connects to the broker service using a dialog. The client enters a subscription query into a dialog that sends the query to the mediator. The broker queries for possible subscriptions from the service provider's information system using principles and terminology understood by those services. The query is based on customer preferences. The client reveals some preferences related to the specific subscription when he or she enters a subscription query into the dialog. In addition, the dialog and the broker service may have stored the general preferences of the customer and use them so that the customer does not need to enter all preferences each time.

Queries and subscriptions are managed based on a complex state model. Each subscription includes several phases described by states that track its situation through its life cycle. For example, when the broker has queried for a subscription from a service provider, the corresponding entry in each system has a status that the subscription is pending but not confirmed. If these systems do not agree on what a particular state means, the mediator translates them. A preferred subscription procedure including phases and states is described in example 1.

In addition to querying subscriptions from service providers, the mediator can synchronize subscriptions in the system of several service providers. The synchronization is based on rules specified in the broker service. For example, a rule may be "if a customer asks for a reservation for an airline ticket, also asking for a reservation for a taxi to the airport". Thus, queries from clients may be increased in the broker service, forming multiple queries. If the service provider can provide the requested service, they answer to the broker and may add some additional information such as seating or timing. The mediator merges the collected information and sends it to the client's dialog showing a simple list of options. For example, the customer may display three flight options and ask whether the customer also wants to reserve a taxi that has in fact been temporarily reserved by the mediator. The customer makes the decision by selecting an option from a simple list of alternatives. The dialog sends information about the client selection to the mediator, which confirms the subscription according to the client selection and cancels unnecessary subscriptions.

Fig. 4 shows a sequence diagram of a query CINQ1 initiated by a client using a dialog DINQ1 sent to a mediator. The mediator initiates a query MINQ1 corresponding to CINQ1 and DINQ1 to the reservation system 1 (service provider reservation system). Finally, the answer DANQ1 is returned to the client providing a choice to respond with the option CSEL1, causing the customer on the reservation system 1 to make a reservation. The mediator confirms the potential need for supplementary services from the subscription service 2 and initiates a query MINQ2 to the subscription system 2, the MINQ2 eventually forming a suggestion that includes several options DANS2, returning to the client making the selection CSEL2, resulting in a supplementary subscription on the subscription system 2.

The reservation may also be accomplished in other ways, such as by calling the service provider by telephone, or by visiting the service provider's office on site. In this case, the service provider may notify the broker of the customer's subscription so that the broker may notify the customer of other options. For example, the dentist tells the broker that the customer has booked an appointment so that the broker may also offer to book a taxi.

Likewise, a solicitation may be added to the broker service so that the broker may ask the customer at a particular time if a new subscription is desired. For example, the mediator may send a notification to the client that a year has passed since the client last dated with his dentist and ask the client whether to make a new subscription. Such a notification may already include some appointment options. If the customer has allowed, the mediator checks his or her calendar so that the given options are convenient for the customer. The dialog displays the options in a simple and convenient manner. The customer only needs to select which option is the best for him or her, or whether he or she wants to get a new option or defer subscription. Fig. 5 is a chronological table of a case where the original query MINQ1 was initiated by a mediator.

Example 1-preferred reservation System

A preferred reservation system according to the invention is described below in relation to the system named BookIt.

BookIT is designed as an interface between a service provider subscription system and other parties on a network, such as the internet, and an end-user client equipped with a mobile phone capable of receiving text messages. The former is preferably implemented using a generic XML interface. BookIT supports the vCard and vCalendar standards because they are used by all major subscription and calendar systems.

BookIT communicates with mobile phone users using Short Message Service (SMS) which communicates asynchronously via an SMS gateway. BookIT uses a novel Dynamic Dialog Matrix (DDM) for secure transmission and mapping of SMS messages. The DDM will be described further below.

A clear distinction needs to be made between the service provider process and the BookIT process. The former covers standard subscriptions with only time and resource subscriptions. The latter includes subscription, work, and financial transactions. Both processes end at the same point. The BookIT process includes several phases:

phase (State processing)

These phases combine between resources (rubber bands). At each stage of the BookIT process, the data relating to the subscription will be modified to reflect the needs of the stage in question. For the states and values, please see the table below.

These stages will be described in more detail in the discussion that follows.

1. Submission

Submission refers to the initialization of the BookIT process and the booking process. As a result of the initialization, an entry is inserted into the database w/base information. Since there is no scheduling information, it does not appear in the calendar. It may be displayed as an open task in a separate task list for the owner.

2. Request for

In the request phase, a reservation request is sent to the resources required by the previously submitted task. This phase may be performed together with the scheduling phase, since there is no scheduling, which will be essential in most cases.

3. Scheduling

The calendar is given to the owner and the resource. As part of and as a result of the schedule, the following data is needed:

a start time of proposal (ISO time stamp w/time zone)

b start position (coordinates) of recommendation

c end time of proposal (ISO time stamp w/time zone)

d end position (coordinate) of end

4. Confirmation

The time and location are received by the already received resources. Data relating to this phase:

a received start time (ISO timestamp w/time zone)

b start position (coordinate) received

c received end time (ISO timestamp w/time zone)

d received end position (coordinate)

By default data is copied from the planning phase.

In fact, if the scheduled time is not needed, the same data structure can be used for this stage, and the state represents the actual meaning of the data.

5. Work by

These resources perform the task of booking. The data related to this phase includes different attributes and their values, which are related to the actual task. Furthermore, the following static structure is required:

a actual start time (ISO timestamp w/time zone)

b actual start position (coordinates)

c actual end time (ISO time stamp w/time zone)

d actual end position (coordinate)

e product used, premium, mileage, …

By default data is copied from the validation phase.

6. Settlement of accounts

At this time, all data stored on the data structure at the previous stage is analyzed and processed for invoicing purposes.

Data relating to this phase: and (5) settlement data. Will be defined separately.

7. Complete the process

This task has been completed. From the point of view of the entire BookIT process, this is not related to the success or failure of the task. In connection with a settlement phase in which financial actions are taken on the organiser. At this stage, housekeeping is done in order to complete the BookIT process (database content, temporary files, …).

The following table shows the data available at each stage. The booking phases are indicated in italics.

Phase state, value, and transition

The following table describes the phases, their states, and values and the transition to the next logical phase according to the resulting values. Further, the corresponding vCalendar state at the time of application is shown.

At any point, the internal phase actions of pause, resume, cancel for all relevant phases are as follows:

<stage y>	Pausing	<State x>
					<Stage y>	Resume	<State x>
<Stage y>	Cancellation	Settlement of accounts

FIG. 6 illustrates a workflow transition from one phase to another. For the conditions, see table above. In addition, note that canceling the status always results in settlement.

Confirming (entire) subscriptions

To ensure that the entire reservation is successful, all resources receiving the reservation need to have the same schedule. Furthermore, there will be resources with different roles and the data relating to the working phase may vary greatly.

The different states of the entire subscription are:

a "No replies (NoReplies)" (0) means "no one replies to the organizer's request"

b "no rejects" (nodecenes) "(1) means" not all invitees have replied. The person who has replied to accepts. "

c "all Accepts" (2) means "all invitees confirmed"

d "partial refusals (SomeDesclines)" (3) means "partial invitees have refused"

e "all denials (alldecines)" (4) means "all invitees have rejected"

The following decision table helps to estimate the status of the entire subscription. "possible (Maybe)" means that this condition does not specify a true or false result without doubt.

Based on the above information and decision tables, the organizer/application must decide what to do with the subscription. This may be a decision made automatically by the system according to preset rules or manually by the organizer.

One major problem solved by the present invention is the challenge of managing customer responses when a customer has been given a number of questions and uses SMS text messaging or similar techniques, where the responses do not automatically contain an accurate reference to the query. The present invention solves this problem using a dynamic dialog matrix. The challenge always includes some type of address or identification of the recipient. In the case of SMS text messages this is the so-called B-subscriber's number. Alternatively, the number or Calling Line Identification (CLI), or similar identification, of the sender's a-subscriber may be appended to each text message. Thus, it is often easy for a client or B-subscriber to reply to a message using the reply or reply function of the mobile device. If the broker service sending the query to the client uses different a-subscriber numbers in different queries, it is possible to distinguish between replies depending on which number the client sent the reply. For example, if the broker sends a query using subscriber number a1, "do you need a taxi in addition? "give the customer and then ask" do you need a hotel room "from the a-subscriber number a 2? ", the customer replies to the first question to number a1 and the second to number a 2. Using the dialog matrix, the mediator tracks queries and answers. In this matrix, a column is used for each customer and a row is used for each A-subscriber number used by the broker. Obviously, rows could also be used for each customer, and columns for each A-subscriber number accordingly. After sending a query from a certain a-subscriber number to the client, the state and the reply are stored in the corresponding shell (shell) of the matrix. As a result, the mediator can discover whether the client replies to a particular request and what the answer is. Likewise, it is also possible to use the matrix to collect information about customer behavior and use it for marketing purposes, for example. The mediator only needs a limited number of a-subscriber numbers. The dialog matrix may also be used to find out the a-subscriber number that can be used if the next query is sent to a particular customer.

The use of a dynamic dialog matrix as described above is illustrated in fig. 7.

The dynamic dialog matrix is also a powerful but very simple installation measure for authenticating mobile phone users having only the ability to send and receive messages. The problem is that the service needs to confirm the identity of the sender. One way to attempt to identify the user is to check the address of the sender. Typically, SMS, email, and other detailed messages are attached with the sender's address. This address may be, for example, the sender's a-subscriber number or Calling Line Identification (CLI), or an email address or IP address. However, it is very easy to forge the sender address. The downlink from the service provider to the user is usually relatively reliable from the service provider's perspective and it is difficult for others to capture or alter the message, but the uplink from the user to the service provider is very vulnerable and it is very difficult to give the wrong sender's address. A well-known solution to the above problem is to ensure communication using encryption techniques, Public Key Infrastructure (PKI) being a good example. For example, the user device may be equipped with a secure SIM card, such as a microchip, a GSM device, to encrypt messages using the user's private key. Then, if the message can be decrypted using the user's public key, the service provider can ensure that the message is from the user. However, this solution requires specialized equipment that has not heretofore been very common, inexpensive, or standardized. Relying on such a solution greatly limits the number of potential users.

The use of DDM provides a new solution. When the service sends requests to the mobile phone user, each request includes a different, preferably randomly selected, reply number. Thus, an acceptable reply is only a reply sent to the correct reply address.

Example 2 use of dynamic dialogue matrix

This simple example relates to the problem of ensuring tomorrow early shift airline tickets. The system sends a series of questions as SMS messages requiring abbreviated responses. Each message is flagged so that its response can be identified so that the messages do not have to be sent or replied to in a particular order until logically so required (e.g., if the answer to one question affects the content of the next question).

A user with a phone number ID 0418979813 has requested a ticket. The system sends the following requests as individual SMS messages:

please select one of the following departure times:

6:00a.m., answer A

7:30a.m., answer B

8:15a.m., answer C

If these times are all suitable, answer D

The sender: +358440844027

Please select the air ticket level:

first class cabin: answer A

A business cabin: answer B

An economy class: answer C

The cheapest available airline tickets: answer D

The sender: +358440844011

Please select:

seat against window, answer A

Seat on the back, answer C

The sender: +358440844034

Please select the diet:

vegetarian food, answer A

Beef, answer B

Chicken meat: answer C

The sender: +358440844003

The answers received from the user to the aforementioned question and several other questions are as follows:

"A" corresponds to the question of reference number + 358440844027

"D" corresponds to the question of reference number + 358440844011

"A" corresponds to the question of reference number + 358440844034

"B" corresponds to the question of reference number + 358440844003

"D" corresponds to the question of reference number + 358440859751

"A" corresponds to the question of reference number + 358440844277

"C" corresponds to the question of reference number + 358440841368

Accordingly, the service provider may find out to the user to select:

-a first morning shift (═ a),

the cheapest ticket available (═ D),

-a window seat (═ a),

-beef rice (═ B),

And so on.

It is important that the user can answer the questions in any order using the matrix, and can even not answer some of the questions. If these are relevant, the system asks for a response. If not, the system can continue without this information.

The responses are shown in a three-dimensional matrix in fig. 8, with the user number plotted on the X-axis, the reply number plotted on the Y-axis, and the answer plotted on the Z-axis. The user with telephone number 0418979813 is the leftmost user along the X-axis. The answer is plotted along the Z-axis corresponding to the reply number on the Y-axis.

Additional security may be obtained using semantic analysis. In the matrix shell (matrix shell), there is information about the queries and what responses are acceptable. If the answer does not meet the criteria, it is rejected. For example, if the service provider asks the user to tell how many items to book, and the user answers "yes," it is clear that the user is not up to what the question is, and thus the message is not an answer to the question.

It is also possible that the service provider is actually a mediator, with the "real" service provider being elsewhere. In this case, the mediator need only have a matrix-based system, and the actual service provider communicates with the mediator using the mediator's matrix system or other security means such as a secret channel. For example, an automobile sharing system may be implemented in the following manner: cars were randomly placed around the city. When the user needs a car, he or she sends a message to the mediator asking where the nearest car is. The mediator sends a message telling the car's location. This reply comes from the random address y'. When the user arrives at the car, he or she sends a message to y' telling the rental time to start and asks the mediator to unlock remotely. This message is relatively reliable because it is sent to an address that is known only to the user. It therefore constitutes a legitimate reason for unlocking and for starting the billing. On the other hand, the communication between the mediator and the car is invisible to the user and outsiders. The car may be equipped with a dedicated device, so that remote command unlocking etc. can be encrypted. Alternatively, communication between the vehicle and the mediator may be implemented using a matrix. In either case, the mediator operates as a "firewall" between the user and the vehicle, prohibiting unauthorized use by outsiders.

Although the present invention has been described in considerable detail with reference to certain preferred versions thereof, other versions are possible. Therefore, the spirit and scope of the appended claims should not be limited to the preferred embodiments of the invention.

Claims (35)

1. A method for a mediator to communicate with a client terminal having a client identifier address, comprising:

a) initiating communication with said client terminal, including associating a specific reply address with a reply to which a dialog must be directed, including selecting a specific reply from a plurality of addresses at which replies are received by said mediator;

b) initiating a dialog with the client terminal, the client terminal including the specific reply address;

c) receiving a reply from the client terminal at the particular reply address, the reply including the client identifier address; and

d) evaluating the reply using the client identifier address and the particular reply address from which the reply was received;

further comprising storing the reply in a matrix having a first axis corresponding to the customer identifier address and a second axis corresponding to the reply address.

2. The method of claim 1, wherein evaluating the reply further comprises analyzing semantics of the reply.

3. The method of claim 1, wherein the communication is related to a particular service provider.

4. The method of claim 1, wherein selecting the particular reply address from the plurality of addresses is a random selection.

5. The method of claim 1, wherein the communication comprises a plurality of conversations and reply exchanges with the client terminal, and initiating comprises associating different reply addresses with different conversations and reply exchanges.

6. The method of claim 5, wherein evaluating the replies continues even when the different replies are received in a different order than initiating the exchange.

7. A method according to claim 3, wherein initiating communication is responsive to a set-up request identifying the client terminal and a particular service provider.

8. The method of claim 7, wherein the mediator communicates with a plurality of other client terminals simultaneously, each client terminal having a different client identifier address, and wherein the method further comprises tracking which of the plurality of addresses is currently available.

9. The method of claim 1, wherein initializing a communication further comprises selecting the particular reply address from currently available addresses.

10. A mediator for controlling communications between at least one service provider and a client terminal, the client terminal having a client identifier address, the mediator comprising:

a) A plurality of addresses at which the mediator can receive messages from the client terminals;

b) logic and resources to:

i) initiating communication with a client terminal with respect to a particular service provider, including associating a particular reply address with a reply to which the dialog must be directed, the particular reply address being selected from the plurality of addresses;

ii) initiating a dialog with the client terminal, the client terminal including the specific reply address;

iii) receiving a reply at the particular reply address; and

iv) evaluating said reply using said client identifier address and said particular reply address from which said reply was received;

wherein the communication comprises a plurality of conversations and reply exchanges with the client terminal, and different reply addresses are associated with different conversations and reply exchanges;

wherein the logic and resources adapted to initiate the communication comprise a matrix having a first axis corresponding to a customer identifier address and a second axis corresponding to a reply address.

11. The mediator of claim 10, wherein the logic and resources to evaluate the reply further analyze semantics of the reply.

12. The mediator of claim 11, wherein the logic and resources are adapted to process replies to conversations even when the different replies are received out of order from the query.

13. The mediator of claim 10, wherein the logic and resources to initialize the communication are adapted to respond to a setup request identifying the client terminal and the particular service provider.

14. The mediator of claim 10, wherein the logic and resources to select the particular reply address from the plurality of addresses randomly selects the selection.

15. The mediator of claim 10, wherein the customer identifier is selected from the group consisting of a customer a subscriber's number, calling line identification, email address, and IP address.

16. A mediator for controlling a system having at least one service provider and a client terminal device used by a client having a client identifier address, the mediator comprising:

a) a plurality of addresses at which the mediator is able to receive messages from the client terminals,

b) Logic and resources to:

preparing at least one dialog in response to a query regarding the service provider,

associating a particular reply address with each conversation, the particular reply address selected from the plurality of addresses,

sending said at least one dialog to said client terminal,

receiving a reply from the client terminal device including the client identifier address at the specific reply address; and

evaluating the reply using the client identifier address and the particular reply address from which the reply was received;

wherein the logic and resources comprise a matrix comprising a first axis indexed by a customer identifier address and a second axis indexed by a reply address;

wherein a plurality of dialogs are prepared in response to the request, and wherein the logic and resources adapted to associate particular reply addresses are adapted to select different particular reply addresses to associate with each dialog, whereby the logic and resources are adapted to evaluate replies even if different replies are received in different orders with different dialogs.

17. The mediator of claim 16, wherein the customer identifier address includes an identifier selected from the group consisting of a customer a subscriber's number, calling line identification, email address, and IP address.

18. The mediator of claim 16, wherein the logic and resources to evaluate the reply further analyze semantics of the reply.

19. The mediator of claim 16, wherein the query is responsive to a service request, the service request identifying the client terminal device.

20. The mediator of claim 16, wherein the logic and resources include logic and resources to track those of the plurality of different addresses that are currently available and to randomly allocate the particular reply address from those addresses that are currently available.

21. The mediator of claim 16, wherein the at least one dialog is a question that can be answered by selecting an item from a list of ordered choices, wherein each choice has an order position.

22. The mediator of claim 21, wherein the matrix further comprises a third axis index for storing the selected ordinal position.

23. A method for a broker of a client from a service provider to reserve resources, the client having a client identifier address and communicating with the broker using a client terminal device, the broker performing the acts of:

a) Preparing at least one dialog in response to the request;

b) associating a specific reply address with each conversation, said specific reply address being selected from a plurality of addresses available for receipt from client terminal devices;

c) transmitting the at least one dialog to the client terminal device;

d) receiving a reply to the at least one conversation from the client terminal device, the reply including the client identifier address; and

e) evaluating a reply to the at least one conversation using the client identifier address and the particular reply address;

further comprising storing replies to the at least one conversation in a matrix comprising a first axis indexed by client identifiers and a second axis indexed by reply addresses;

the at least one dialog includes a plurality of dialogs having different specific reply addresses associated with each dialog, whereby the replies can continue to be evaluated even if the replies are received in a different order than the sent dialogs.

24. The method of claim 23, wherein the act of evaluating the reply further comprises analyzing semantics of the reply.

25. The method of claim 23, wherein the act of associating a particular reply address with each dialog is performed so as to randomly select the particular reply address.

26. The method of claim 23, wherein the query is in response to a service request from the client terminal device.

27. The method of claim 23, wherein the customer identifier address comprises an identifier selected from the group consisting of a customer a subscriber's number, calling line identification, email address, and IP address.

28. The method of claim 23, wherein the act of preparing the at least one dialog further comprises preparing the at least one dialog in a form that can be answered by selecting from an ordered list of choices, wherein each choice has a sequential position in the list of choices.

29. The method of claim 28, wherein the matrix includes a third axis indexed for storing sequential positions of selections, and wherein the method further comprises storing selections of the at least one reply along the third axis.

30. The method of claim 28, wherein the client terminal device comprises a mobile telephone device and the conversation comprises an SMS message.

31. A network server programmed as a mediator to perform the method of claim 23.

32. A network server programmed as a mediator to perform the method of claim 28.

33. A method for a mediator to authenticate a customer using a mobile telephone device capable of sending and receiving SMS messages and having a customer's calling line identification number, the mediator performing the acts of:

a) assigning a unique reply address to the SMS conversation from a plurality of available reply addresses;

b) sending said SMS conversation to said customer with said customer's calling line identification number; and

c) authenticating the client if a reply to the SMS conversation is received at the unique reply address;

wherein the mediator comprises a network server programmed to perform the method, and wherein the method further comprises storing the reply in a matrix comprising a first axis indexed by a caller identifier number of the client and a second axis indexed by a reply address.

34. The method of claim 33, wherein the unique reply address is randomly assigned from the plurality of available reply addresses.

35. The method of claim 33, wherein the act of discriminating further comprises analyzing semantics of the reply.