WO2001067731A2 - Directory assistance system capable of providing telephonic concierge services - Google Patents

Abstract

A system and method is described for providing concierge-like services to individuals requesting such services comprising a pool of operators agents capable of receiving the request for concierge-like services and generating an electronic ticket representing such request and a pool of fulfillment agents capable of receiving the electronic ticket and engaging in such action as necessary to fulfill the request. The agents are networked to directory assistance and concierge databases and to third-party providers of concierge services to facilitate the process.

Description

DIRECTORY ASSISTANCE SYSTEM CAPABLE OF PROVIDING TELEPHONIC CONCLERGE SERVICES

Michael A. Kepler Nicholas J. Elsey Michael Essex

John S. Stafford Timothy A. Timmins

TECHNICAL FIELD The present invention relates to a system and method for providing concierge-like services to individuals who request such services, particularly in a wireless environment and to individuals traveling from a first geographic region to a second geographic region.

BACKGROUND OF THE INVENTION Concierge Concierge services are typically provided by hotels. The method generally employed is where a hotel guest, using the hotel room telephone, places a call to the hotel reception and asks to speak to the hotel concierge. The guest is connected to the concierge who then listens to the request of the hotel guest, such as a request for a restaurant reservation, and notes any preferences, such as the guest's preference for outdoor dining. The concierge then suggests a service, an event or restaurant in accordance with the guest's desires and preferences. The suggestion is often based on the concierge's personal knowledge in the field, and/or by consulting a listing book or directory. Should the suggestion be satisfactory, the concierge will make the necessary reservations and inform the hotel guest of the reservation details. Concierge services are especially useful for a visitor who is unfamiliar with an area's services, eating establishments or upcoming events. The problem with such a service is that it is restricted to the guests at a specific hotel only. The concierge's suggestions can also often be biased, erratic or based on limited listing or directory information. In addition to the above, the hotel guest may also need to write down the reservation details, obtain directions and arrange transportation.

Furthermore, the whole process can be slow, as access to large listings are often manually searched by the concierge. The concierge may also be limited by the type of search he/she can perform. He may not be able to search for multiple preferences simultaneously, such as for example an outdoor, non-smoking, vegetarian restaurant, in a specific area. In addition, the concierge may only be familiar with restaurants in a particular area and therefore may be of little use to a hotel guest who is departing that day for another city.

Telephone Directory Assistance

Traditionally, directory assistance has focused on providing telephone number directory information only. Typically, a directory assistance operator receives a request from a caller for the telephone number of a desired party. The operator locates the required number from a listing directory and may either give the number to the caller or connect the caller to the desired party.

Each year, a growing number of people spend a significant amount of time traveling for business or pleasure. Mobile communication and portable computers have created an opportunity for these people to conduct business and communicate while on the move. Wireless telephones have become a standard business tool in this environment. Wireless telephone users may find current directory assistance services inconvenient or difficult to use. Such users are usually away from their general work environments (for example, traveling in a vehicle), and thus may not be able to remember, or make a note of a desired number. Callers who would normally be able to call upon secretaries or personal assistants at their offices, may not have access to such assistance when traveling. The wireless telephone caller thus needs a comparable service to that which they would experience in an office environment. While improvements to telephone directory assistance have been made over the years, such systems do not fully address the needs of wireless telephone users. The present assignee has redressed certain of the above-mentioned difficulties by providing directory assistance services that eliminate the need to make notes of the desired number, or undertake a redialing exercise as well as by providing verbal driving directions. The present assignee has also established a country- wide network of directory assistance or call centers that are able to provide its customers with nationwide directory assistance. However, in today's directory assistance environments, operator resources are primarily focused on providing telephone number directory assistance. Having an operator respond to a customer's request for concierge-type services would be expected to introduce delays and inefficiencies into a directory assistance system. Moreover, the information infrastructure to allow operators to provide concierge-type services in a timely and efficient manner is not generally available in the current directory assistance environment.

Therefore, there is a need for a nationwide telephonic system that is able to efficiently and effectively receive and respond to requests for concierge-type services from calling customers traveling throughout the country. The system should be able to respond to requests regardless of the locale of the customer or the geographical destination of the request.

SUMMARY OF THE INVENTION

The present invention is directed to providing a calling party with telephonic concierge-type services. The concierge service is intended for use by, but not limited to, wireless telephone subscribers. The service encompasses a wide range of concierge-type services such as for example a telephonic restaurant guide and reservation service, ordering specific services such as flowers or food delivery, arranging transportation, accessing entertainment guides, an event ticketing and reservation service, a hotel reservation and availability service as well as a travel or flight reservation and ticketing services.

According to a preferred embodiment of the present invention, the system includes a nationwide wide area network (WAN) connecting a plurality of directory assistance centers to a server and directory listing database located in an information hub. Communication channels connect calling customers to operators in the directory assistance center. A computer, preferably web-based, interface allows the operator to interrogate the calling customer for information regarding a request for concierge services. Various databases in the system facilitate the generation of the request. Upon completion of the request (called a "ticket"), the ticket is submitted over the WAN. The server sends the ticket to a fulfillment agent in a directory assistance center proximate to the concierge-type service request. A computer, preferably web-based, interface directs the fulfillment agent through the various actions necessary to fill the request. Communication channels, which allow the fulfillment agents to rapidly and easily connect to the various establishments desired by the calling customers, facilitate the filling of the requests and the notification of the calling customer of the filled request. The method according to a preferred embodiment of the invention is illustrated by the following example. A caller dials and is connected to an enhanced directory assistance service. The caller is informed about the concierge service by a recorded message or by an operator. Alternatively, the caller may already be aware of the concierge service. The operator then obtains a request from the caller. Such a request may either be a request for listing information, such as for example a request for all vegetarian restaurants in a particular area, or the caller may immediately request a reservation, at for example the caller's favorite restaurant. The operator then obtains the caller's details and inputs these details into a computer database. Such details may include the caller's contact details, dietary preferences, desired restaurant location, type of credit card to be used, restaurant views, etc. The operator then looks up listing information from another computer database, based on the caller details, to produce a desired output such as a list of vegetarian restaurants in a specific suburb. A fulfillment agent attempts to contact the restaurant to make the reservation. Finally, the caller is notified whether the reservation was in fact made or not, and any reservation details, if applicable.

In a preferred embodiment, the reservation process is undertaken by a fulfillment agent who exclusively attends to such requests, thus allowing the operator to attend to other tasks. In an alternative embodiment, the operator who receives the request for concierge services may attend to the request.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and additional features and advantages of the present invention will be more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.

FIG. 1 is a telephonic system according to a preferred embodiment including a wide area network;

FIG. 2 illustrates a first graphical user interface of the present invention; FIG. 3 illustrates a second graphical user interface of the present invention; FIG. 4 illustrates a third graphical user interface of the present invention;

FIG. 5 illustrates a fourth graphical user interface of the present invention; FIG. 6 illustrates a fifth graphical user interface of the present invention; FIG. 7A and 7B illustrate block diagrams depicting the hardware used to implement an embodiment of the present invention; FIG. 8 provides a detailed view of a voice server used in an embodiment of the invention;

FIG. 9 provides a detailed view of a switching matrix platform used in an embodiment of the invention;

FIG. 10 is a flow chart depicting an embodiment of the method by which telephonic concierge assistance is provided to a caller; and

FIG. 11 is a flow chart further depicting an embodiment of the method by which telephonic concierge assistance is provided to a caller. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

As illustrated in FIG. 1, the telephonic system according to a preferred embodiment of the present invention includes a wide area network (WAN) 30 covering a wide coverage area. The WAN 30 can be an internet-based network such as the world wide web or can be a private intranet based network. According to a preferred embodiment, the WAN 30 covers an entire region (e.g. the entire eastern seaboard of the United States), an entire country (e.g. United States) or group of countries (e.g. all of Canada, Mexico and the United States). The WAN 30 connects a plurality of operators and fulfillment agents dispersed throughout the wide coverage area in a plurality of directory assistance centers 21, 22, 23, 24, 25, 26 and 27. Each of the directory assistance centers 21, 22, 23, 24, 25, 26 and 27 cover one or more regional coverage areas. One or more information hubs 10 are also included in the WAN 30. An information hub 10 contains one or more databases 20 and one or more servers 28 which are accessible by the operators, and fulfillment agents in the system.

As will be explained in more detail below in connection with FIG. 7, operators are generally provided web browser capabilities, telephone facilities as well as fully-featured operator user interface applications which facilitate the searching and retrieval of directory assistance information from database sources. It is well understood that directory assistance operators receive and respond to requests for directory assistance. According to the present invention, in addition to responding to requests for directory assistance, the operators are capable of receiving requests from calling customers throughout the system for requests for concierge-type services. When a request for concierge-type services is received by an operator, the operator completes a record of the request. This record is referred to as a "ticket."

A web-based form of ticket is accessible by each of the operators over the WAN. One such form is shown in FIG. 2. To complete the ticket, information regarding the concierge services request is gathered in a number of ways. The customer may, for example, specifically request a particular restaurant or a particular airplane flight or hotel reservation. Using a request for a restaurant reservation as an example, the operator may solicit from the calling customer their first choice for a restaurant, their second choice for a restaurant, preferred seating times, alternative seating times, etc. In this case, information may be directly entered into the form. More typically, however, the customer will have certain desires - - e.g., a vegetarian outdoor restaurant in 'Cardiff by the Sea' as per FIG. 2, or a midnight flight from New York's JFK airport to San Diego International airport. In this case, the operator will search the various databases at his/her disposal to compile a specific request for the calling customer. (The term "operator" is meant to include both human operators as well as automated operators such as voice response and voice detection units.) The operator may then obtain directly from the calling customer information regarding preferred seating times, alternative seating times, etc.

Information, such as who the calling customer is and contact numbers so that the system can confirm with the calling customer when the request is fulfilled, are advantageously obtained from information regarding the calling customer residing on the system databases. The system automatically uses this database information to complete part of each ticket.

According to the present invention, the operator's web browser provides a direct connection to either a server in one of the information hubs, or to a central server, in the system. In essence, the operator interface and the server are in a client-server arrangement. Thus, in effect, when the ticket is filled-in, the operator sends the ticket over the WAN to the concierge database to be picked up for fulfillment.

Fulfillment agents fill the requests for concierge services received by the operators. Fulfillment agents are provided similar web browser and telephone facilities to those provided to the operators. By means of the web browser, the fulfillment agent has access to one or more web pages. These web pages provide the fulfillment agents with information regarding outstanding requests for concierge services. (The public's access to these web pages is restricted so the privacy of the calling customer is protected.) When a ticket created by an operator needs fulfillment in a particular regional coverage area, the web page for the fulfillment agent in that regional coverage area will change and indicate that a ticket needs to be processed. The system periodically refreshes the web pages to keep fulfillment tickets current. Advantageously, the fulfillment agents are located throughout the coverage area. A fulfillment agent preferably is an individual with specialized knowledge of the regional coverage area and the services provided therein so they can effectively fulfill the requests for local concierge services. The fulfillment agent may be a call center supervisor, an underutilized operator or a task specific employee in a particular directory assistance center. According to the preferred embodiment, a centralized concierge relational database is maintained in a central information hub. The preferred database being a structured query language (SQL) relational database, although other relational and non-relational systems may be implemented without departing from the scope or intent of the present invention. A motivation behind maintaining the concierge database in a single information hub is that such centralization provides the capability of receiving a request for concierge services in a first regional coverage area where the requested services are in a second regional coverage area. For example, suppose a business traveler in New York intends to fly later that day to San Diego to have dinner that evening in 'Cardiff by the Sea.' The traveler dials the New York directory assistance center. The traveler informs the operator who receives the call in the New York center of his travel plans and his desire to eat at a 'Cardiff by the Sea' restaurant. The operator in the New York center creates the ticket for the business traveler. That ticket is recorded in the centralized concierge database. The server will then automatically route the ticket to a fulfillment agent in the San Diego directory assistance center. As a result, the ticket appears on the screen of the San Diego fulfillment agent in the San Diego directory assistance center.

Each directory assistance center has an identification number and/or name. When an operator creates a ticket, the system by default assigns the ticket to the directory assistance center where it was created. This is accomplished by assigning the originating center's identification number/name to the ticket. However, the operators have the capability to change this assignment, by manually inputting the identification number/name of the center where the request for concierge services is to be directed. In the example above, the operator in the New York center would change the identification number/name of the fulfilling center from the default of the New York center to the San Diego center. While implementation of full concierge databases/database server in each directory assistance center adds administrative overhead, the present invention encompasses embodiments where the concierge database/database server is not centralized in a single information hub but is instead distributed throughout the system. Similarly, in a further alternative embodiment in addition to the centralized database, one or more localized concierge databases may be maintained locally to keep, maintain and update travel and concierge-type information relevant to only that particular locale. Further, while the concierge database is described and depicted as a separate and independent database from the other maintained databases (e.g. directory assistance database or a customer information database), it is well understood by those skilled artisans that the concierge database may reside as part of one or more of the databases maintained by the organization.

Referring to FIG. 1, both the operators and fulfillment agents have access to these concierge databases. The WAN 30 connects the operators and fulfillment agents to the concierge databases 20. In general terms, the concierge database maintains information regarding concierge services. For example, the concierge database includes customer credit card information, and information regarding the status of the request for concierge service. Typically, restaurants and hotel listings are maintained on a directory assistance database separate from customer and ticket data. However, in an alternative embodiment, all concierge information is maintained on a separate concierge database.

A further network is provided to connect the fulfillment agents to providers of concierge-like services, such as airlines, hotel chains, restaurants, travel agents (including web-based travel service providers such as Expedia, Priceline.com, Travelocity). Such a network connection may be a public or private network (such as a VPN).

FIG. 2 illustrates a graphical interface used by an operator to generate a ticket. The interface is designed so that the operator asks appropriate questions to accumulate sufficient information to fill the customer's request. The intent of the interface is that the ticket can be filled by the fulfillment agent without further interaction between the system and the calling customer. However, should further interaction be required, the interface includes contact information so a follow-up phone call can be placed to the customer, either to advise the customer that the request has been filled or to obtain further information so the request may be filled. The interface shown in FIG. 2 is directed to a request for a restaurant reservation. It should be appreciated that different interfaces may be used for different types of requests. For example, an interface may be specifically designed for hotel reservations, airplane reservations or car reservations. The operators may select via menu the appropriate interface for the customer request. Alternatively, the appropriate menu may be selected automatically by the system based on skills-based routing or by dialed telephone number. Referring now specifically to the interface shown in FIG. 2, the interface includes a plurality of sets of fields, each of the fields capable of capturing data input. The first set of fields relates to the identification of the calling customer. The first of the three fields in the first set is the "Name of Reservation" indicating the calling customer requesting the reservation. The second field is the "Caller MIN" indicating the calling customer's Mobile Identification Number (MIN). The third field is the "Carrier ID" indicating the carrier who provided the call to the calling center. The system may be designed to input the information into these fields automatically. The calling center's switching equipment described below is capable of detecting the information associated with these fields directly from the incoming call. Thus, when an operator selects this interface in connection with a call, these fields may automatically be filled in. Additional fields relating to the identification of the calling customer may also be automatically filled in and displayed. The additional fields include the home address of the calling party and the present location of the calling party to the extent such information is available from the carrier, by GPS or other locating means.

The next two sets of fields relate to the particular restaurant desired by the calling customer. The first set of fields relate to the first choice for the restaurant, its phone number, and its address. Similarly, the second set of fields relate to the second choice for the restaurant, its phone number and its address. The fields titled "First Choice

Restaurant" and "Second Choice Restaurant" are typically completed with information solicited by the operator from the calling customer. However, records kept in the databases may include a list of favorite restaurants for this particular customer. In addition, there may be more than one list of favorite restaurants maintained, one for each of the different cities frequented by the calling customer. In another embodiment of the present invention, the operator may offer the calling customer recommendations of restaurants from well-known lists of restaurants such as those generated by Zagats, Sidewalk.com or another director database maintained by the system. Advantageously, once the 'restaurant names' fields are completed, the remaining fields relating to the phone number and address of the restaurants may automatically be filled in by information obtained from the directory assistance databases maintained in the system. Relevant database information can also be manually transferred by the operator into the ticket fields.

The next set of fields in the operator interface relate to the details needed for making the restaurant reservation. The first field is titled "Date of Reservation" which is the date the customer wants the reservation. This field is completed with information solicited by the operator from the calling customer. The date of the telephone call is used as the default and may be modified by operator input to a future date if requested by the caller. The next field is titled "Number in Party" and corresponds to the size of the party for which the reservation is sought. This field is completed with information solicited by the operator from the calling customer. This field advantageously may default to information contained in a record entry in a database corresponding to the calling customer's preferred size of dining party. The third field is titled "Preferred Time" which corresponds to the time the calling customer desires the reservation. This field is completed with information solicited by the operator from the calling customer. This field advantageously may default to information contained in a record entry in a database corresponding to the calling customer's preferred dining hour. The fourth field in this set is titled "If unavailable then from:" which corresponds to the calling customer's acceptable dining times. Again, this field is completed with information solicited by the operator from the calling customer and advantageously defaults to a record entry in a database corresponding to the calling customer's preferred dining hours.

The last set of fields in the operator interface corresponds to contact information. The contact information fields comprise two sets of fields corresponding to a contact name, contact method, and telephone number. Typically, this information advantageously defaults to information contained in a record entry in a database corresponding to the calling customer's preferred contact names, methods and phone numbers. The operator is expected to confirm with the calling customer the correctness of this information. Regarding the contact method, a pulldown menu is provided. Any number of contact methods are available including phone, wireless phone, pager, fax, and email. Whenever one particular method is chosen, the corresponding telephone number and/or email address appears. It is understood that the same name may be entered in both contact name fields but two different contact methods may be chosen, for example phone and pager.

A notes field not illustrated in FIG. 2, is an additional field in which the operator may type in comments such as special dietary requirements, special seating requests, etc. A further field not illustrated in FIG. 2 is the field associated with the center targeted to fill the request. As described previously, the system uses the center which generates the ticket as the default fulfillment center. However, in instances in which the caller seeks concierge services outside the generating center's regional area, the operator will modify the ticket to direct the ticket to the appropriate fulfillment center. In a preferred embodiment, the system, automatically recognizes when the request for concierge services are outside the generating center's regional area and will prompt the operator if he/she wants to direct the ticket to a more appropriate calling center. Some forms of tickets according to the preferred embodiment are illustrated in FIGs. 3 - 6. Referring to the form of ticket illustrated in FIG. 3, this ticket is presented by the system to a fulfillment agent sitting in the directory assistance call center which will fulfill the ticket, in this example the San Diego call center. Via the WAN, the server in the information hub directs a ticket to the display of a San Diego fulfillment agent. The ticket provides the fulfillment agent with general information regarding a customer's request for concierge services. For example, with the ticket shown in FIG. 3, the fulfillment agent is provided with information regarding the identification of the ticket, the date and time of the next action to fill the request the desired reservation date and time, the name of the requesting customer, the name of the target restaurant and the status of the request.

A first field is labeled "ID" and corresponds to the identification of the particular request for concierge services. The ticket is linked in the database to other records regarding the concierge services request such as all of the information taken down by the operator in generating the request. The fulfillment agent can access these additional records by selecting the ID field. (Because the ticket is presented to the fulfillment agent in the form of a web page, the fulfillment agent may select the ID field by means of a mouse click. The system server recognizes the mouse click and presents information to the operator.)

It is understood that a fulfillment agent will usually attempt to fill more than one ticket at a time. Thus, a fulfillment agent will necessarily have the capability to step through the various tickets currently at the fulfillment call center that require fulfillment. This advantageously allows the fulfillment agent to prioritize which of the then-pending tickets he/she will attempt to fulfill. Server software may also automatically prioritize tickets, allowing the fulfillment agent to override such prioritization if necessary. The concierge database may be searchable by any and all of the fields in the request, but preferably by the restaurant or customer name. In FIG. 3 it is shown that the agent is provided on his/her screen, facilities to search requests by restaurant name or by reservation name. In addition, the fulfillment agent may step through the tickets pending at that call center, one by one, by page-up and page-down keys, or by back and forward keys on the web browser interface.

The system creates an environment to ensure that tickets are responded to by fulfillment agents in such a way so as to maximize the probability that customers' requests are filled. One of the methods that the system implements towards this end is to prioritize, schedule and record all of the actions taken by the fulfillment agents on each request. Thus, the system advantageously minimizes the amount of guess work associated with the request. Instead, it provides each fulfillment agent with clear instructions when attempts to fill a request should be made. The field labeled "Next Action Date/Time" is integral in this process. It informs the fulfillment agent of the time and date that the agent should attempt to fill the customer's request. The system advantageously includes an alarm subsystem which automatically signals the fulfillment agent that an action should be taken toward the fulfillment of the request.

In terms of prioritization, the system employs one or more queues which allow the system to process tickets based on next action time. Depending upon the availability of system resources, the system may assign a plurality of fulfillment agents to each of the queues to maximize the probably of request fulfillment. Each ticket's next action time is preferably based on when an action last took place. A ticket's next action time may be set as follows: 1. No further action required as of midnight of the reservation date.

2. Currently needs further processing.

3. Needs more processing as target telephone was busy.

4. Needs more processing as targeted telephone had no answer.

5. Fulfillment agent may override the next action time. More urgent tickets may be processed before less urgent ones. The system weighs a number of factors in determining which of the tickets are most urgent. These factors include the proximity between the current time and the reservation date and time and the duration of time that the request has been under the status "Requires Fulfillment." In addition, particular customers may warrant higher or different priority treatment. With these requests, the systems may place these tickets ahead of other tickets in the queue. Alternatively, the system may employ two queues, one for priority customers and one for non-priority customers. Special fulfillment agents, such as those having special language skills or those having more years of experience on the job, may be assigned to the priority queues. Scheduling and recording of the processing of tickets is now described in connection with FIGs. 4 - 6. FIG. 4 illustrates a ticket after its creation. The ticket comprises a request section and an event section. The request section appears just below the event section and is simply the request as taken down by the operator as described above in connection with FIG. 2. The fulfillment agent may scroll up and down the page to view the different portions of the ticket.

The event section is illustrated in FIGs. 4 - 6. The event sections are essentially a menu-driven table. The event table facilitates the scheduling and recordation of all of the actions taken upon a particular request. A time and date stamp identifies when the last action was taken upon the request. Next, a menu driven list sets forth all of the permissible actions that may be taken with respect to the request. The list of permissible actions include calling the first restaurant, calling the second restaurant, contacting the first customer contact, contacting the second customer contact, or simply viewing the request. Additional action types may be added, as needed. One of the major advantages of the present invention is the ease by which these actions are taken by the fulfillment agent. Upon selection of a particular action, the directory assistance center automatically retrieves the number or routing information of the appropriate party (e.g., the telephone number of the first or second restaurants or the pager or email address of the first or second customer contact) from the ticket record and may thereafter attempt to establish a connection with the appropriate party. As described later in connection with FIG. 7, the directory assistance center of the present invention includes one or more voice and/or data connections 112, 113 which provide connection to a public network over which outgoing calls or messages may be placed. Because of this environment, when the fulfillment agent selects a particular action in the menu, a connection to the appropriate party may be established without further action on the part of the fulfillment agent. This eliminates the requirement that the fulfillment agent look up the telephone number in some database (whether it be a phone book or computer database), manually dial the telephone number, redial if a misdial occurs, look up a second number for the second restaurant, and so on. Thus, the present invention significantly reduces the time and effort associated with providing concierge services. The fulfillment agent may also, if desired, manually dial the desired telephone number.

The next column in the event table is a menu driven list of the results of the last action. The list of permissible results of the last action include both the successful completion of an action (e.g., reservation made at desired time, customer contact notified and reservation confirmed, etc.), incomplete attempt to complete action (leaving message on answering machine of restaurant, being placed on waiting list of restaurant, reservation available but outside range of time, unable to contact person, etc.) as well as the failure to complete a request because of the inability of the restaurant to meet the customer request (no reservation within range requested, no tables available, etc.). In addition, any of the possible network communication events such as ring-no-answer, busy, or network problem may be result of last action. These network communication events may advantageously be detected by the directory assistance center and automatically entered into the list.

The next column in the events table is a place for the fulfillment agent, if applicable, to write any notes. These notes, along with the remainder of the ticket, allow a second fulfillment agent to pickup where a first fulfillment agent left off and continue processing the first fulfillment agent's ticket. A ticket has a current status. The ticket may be "new." A "new" ticket indicates there is a first action to be taken for the reservation request. The ticket may "require fulfillment." A ticket "requiring fulfillment" indicates a first action has been taken but further actions are required. The ticket may "require customer notification." A ticket requiring customer notification indicates that the customer must be notified because either the reservation has been successfully completed or there was a failure to complete the reservation and no other actions are possible. The ticket may also be "canceled" or "closed" indicating that the customer has canceled the request or that the request has been completed and the ticket has been closed. A "notified" ticket indicates that the customer has been informed of the status of the request. The event section of the ticket further includes a next action time/date. Whenever further actions are required on the ticket, the system automatically establishes a time and date for the next further action to be taken. The system uses a simple algorithm to establish the time and date for the next action. So long as there is sufficient time between the current time and the time by which the reservation must be made, the next action time/date will be set at regular intervals (for example, every 15 or 30 minutes). However, when the time between the current time and the time by which the reservation must be made draws near, the next action time/date will accelerate to ensure the customer is notified. This auto next action time may be manually overridden.

With reference to FIG. 7A and 7B, a directory assistance center 100 according to a preferred embodiment of the present invention includes a switching matrix platform 114, also known as a private branch exchange (PBX) or switch, connected to one or more external Tl voice connections 112 and one or more corresponding Tl data connections

113 from caller networks. (The Tl carrier is the most commonly used digital line in the United States, Canada, and Japan. In these countries, it carries 24 pulse code modulation (PCM) signals using time-division multiplexing at an overall rate of 1.544 megabits per second. Tl lines use copper wire and span distances within and between major metropolitan areas. It should be appreciated that other systems may also be used.) Switching matrix platform 114 is also connected via Tl communication links to a channel bank 116 for coupling to a plurality of operator and fulfillment agent telephones 118 and 119 respectively.

Each operator and fulfillment agent is equipped with a terminal 120 and 121 that includes a monitor and keyboard with associated dialing pad. The operator terminals are coupled over a data network 124 to a database server 126, allowing an operator to access the data in database server 126 through the operator terminals 120 and fulfillment agent terminals 121. The database server 126 contains standard telephone directory information.

The data network 124 further connects to a voice response unit (VRU) 130 and a switching matrix host computer 128 (also known as a PBX host), which in turn is connected to the switching matrix platform 114 by switch data link 122. The data network 124 may, but not necessarily, also further connect to a directory listing or concierge database 136 and a caller profile database 134. The caller profile database 134 stores detailed information about a subscriber. Such details may include the subscriber's name, contact details, preferences, dietary requirements, likes and dislikes, past logged activity, etc. The directory listing or concierge database 136 may contain directory listing information on restaurants, events, accommodation, transportation, travel information and booking, stock prices, weather and other services such as grocery or flower delivery, etc. In one embodiment, the VRU 130, database server 126, and switching matrix host 128 have redundant systems (not shown), which can operate as either back-up systems in the event of primary system failure, or provide load-sharing in either a master-slave or a peer-to-peer relationship with the primary system.

The data network 124 consists of, but is not limited to, a local area network (LAN) 127. The LAN 127 may connect to a plurality of other similar remote LANs 129 to form the WAN 115. The LANs 127 and 129 are connected to one another via routers or other WAN connections 125. The WAN may furthermore be connected by a frame relay connection which is a telecommunication service designed for cost-efficient data transmission for intermittent traffic between local area networks (LANs) and between end-points in a WAN. It should be appreciated by one skilled in the art, that databases 126, 134 and 136 may be located at each LAN or at a single central LAN.

A subscribers mobile or wireless telephone 144 communicates with a wireless telephone network 146 which in turn is connected to a carrier network node 142 and carrier switching center 140.

The Tl voice connections 112, or voice links, provide connection between the directory assistance center's switching matrix platform 114 and the carrier's switching center 140, through which incoming directory assistance calls are received. The Tl voice connections 112 further provide connection to the network over which outgoing calls are placed (which network may be different than that used for incoming traffic). Similarly, Tl data connections 113, or data links, provide a signaling connection between the directory assistance center's node and the carrier's SS7 network node 142, through which incoming and outgoing signaling messages are transmitted (Common Channel Signaling System No. 7 (SS7) is a global standard for telecommunications defined by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T).

The standard defines the procedures and protocol by which network elements in the public switched telephone network (PSTN) exchange information over a digital signaling network to effect wireless and wireline call setup, routing and control). The directory assistance node is contained within the switching matrix platform 114, but one with skill in the art will appreciate that the directory assistance node could also be a physically distinct component. It the outgoing call is being placed over a different network than that on which the incoming call was received, a second data connection to the outgoing network will be established.

The switching matrix platform 114 is described in detail in currently copending United States patent application 08/816,921, which is incorporated herein by reference. In general, referring to FIGS. 8 and 9, operation of switching matrix platform 114 is governed by computer-readable instructions stored and executed on switch matrix host computer 128. In one embodiment of the invention, switching matrix platform 114 is an Excel LNX 2000 and switch data link 122 is a 38.4 kb serial link; in another embodiment, switch data link is an Ethernet link. Switching matrix platform 114 includes expandable central processing unit ("EXCPU") 304 and/or matrix central processing unit ("MXCPU") 304. EXCPU/MXCPU 304 serves as an interface for switching matrix platform 114 to switching matrix host computer 128 (via switch data link 122). EXCPU/MXCPU 304 and other components of switching matrix platform 114 communicate through shared communication path 302, commonly called a "midplane." In the currently-described embodiment, midplane 302 utilizes a time division multiplexing ("TDM") method of sharing a common pathway. Thus, a plurality of data (other than SS7 messaging) and/or voice streams can be interlaced onto the single path, separated by time.

Another board-level component of switching matrix platform 114 is multi-frequency digital signal processor ("MFDSP") unit 310, which includes four single in-line memory module ("SIMM") packagings. Each SIMM packaging is comprised of four DSP arrays. Each DSP array is composed of multiple, illustratively sixteen, programmable DSPs. The DSPs can be programmed or reprogrammed to function as, among other things, call progress analyzers ("CPA"), call progress generators ("CPG"), multi-frequency ("MF") receivers or transmitters, dual-tone multi-frequency ("DTMF") receivers or transmitters, or conference units, depending upon, the demand placed on directory assistance center 100 and switching matrix platform 114 for each corresponding function.

The present assignee uses these DSPs to provide its customers with enhanced directory assistance. Such enhanced directory assistance is described in United States patent application serial number 08/816,921, all of which are incorporated by reference. It will be recognized by one skilled in the art that a variety of types of, or even multiple instances of, switching matrix platform 114 may be incorporated into a telephone network or directory assistance center 100 without exceeding the scope of this invention. In the preferred embodiment, the switching matrix platform supports digital Tl telephone circuits and includes digital signal processing circuitry which provides the requisite conference capability (described below), SS7 message generation/detection capabilities, and dual tone multi-frequency (DTMF) and multi-frequency (NE) tone generation/detection capabilities. With respect to the SS7 functionality, the switching matrix platform acts as a signaling node, also known as a service switching point (SSP), as discussed above.

The voice response unit (VRU) 130 is incorporated into the system to play the frequently repeated parts of an operator's speech, namely the various greetings and signoffs (or closings), and the caller's desired telephone number where requested. Not only does this system provide a voice-saving and monotony-relief function for the operators, it performs a "branding" function (i.e. the pre-recorded messages incorporate the name of the telephone company through which the caller was routed to the directory assistance service), and it also reduces the amount of time an operator is actually connected to a caller. The VRU may also contain a voice recognition system for receiving verbal input from a party connected to the VRU. VRU 130 is connected via the data network 124 to the switching matrix host 128

(to which it acts as a slave processor) and via one or more Tl spans to the switching matrix platform 114 itself. Each VRU 130, when more than one is employed in directory assistance center 100, connects to switching matrix platform 114 via a separate voice server link. VRU 130 consists of a general purpose computer plus one or more voice cards (a first voice card 402 is depicted in FIG. 8), which serve as the interface between VRU 130 and the Tl span to switching matrix platform 114. Voice card 402 monitors and controls communications over the Tl span; its capabilities include telephone tone detection and generation, voice recording and playback, and call progress analysis. Therefore, very similar to switching matrix platform 114, VRU 130 is capable of detecting connection status conditions, detecting caller keypresses, and generating tones. Although the figures depict VRU 130 distinct from database server 126, in alternative embodiments they are coterminous.

VRU 130 also includes typical computer components such as central processing unit 404, data storage unit 406, and bus 310 for transferring voice and data signals. VRU 130 may also contain a voice recognition subsystem (not shown) for receiving verbal input from a party connected to the voice server.

At appropriate stages in a call progression, the switching matrix host 128 initiates a voice path between the VRU and the switching matrix platform such that the caller, or the caller and the operator, are able to hear whatever pre-recorded speech is played on that circuit by the VRU. The switching matrix host 128 then instructs the VRU, via the data network, what type of message to play, passing data parameters that enable the VRU to locate the message appropriate to the call state, the service-providing telephone company, and the operator. The recording density used is high enough to provide a good enough quality of message playback that most users of the system should be unaware they are listening to a recording.

The directory listing database 136 and server database 126 provides operators with the means to search for a caller's desired party, and determine the appropriate telephone number. In the preferred embodiment, the databases provide the capability to search not just by name and address, but also by type of goods/services and/or geographical region, or by any other attribute in the caller record, including phone number, e.g., the preferred database can answer queries soliciting the names/numbers of Chinese restaurants on a given street. Data indexed in this fashion is usually not commercially available, so the present assignee starts with a commercially available database file (e.g. the Directory Assistance Database Source available from U.S. West), and enriches it by adding further data manually. The databases may be SQL relational databases. SQL (Structured Query Language) is a standard interactive and programming language for getting information from and updating a database. Queries take the form of a command language that lets you select, insert, update, find out the location of data, and so forth. Databases 134 and 136 may also be located at a centralized location. Each remote LAN thus accessing these databases via the LAN. Databases 126 and 136 are separated for ease of explanation, but may be incorporated into a single database.

Desirably, the results of the database search presented on the operator's terminal 120 or fulfillment agents terminal 121 are not alphabetized prior to display, but rather are presented in the order located by the database search engine. (If desired, a deliberate randomization of order could be effected before display.) Businesses at the beginning of the alphabet are thereby not unduly favored by callers using the directory assistance service. In the alternative, businesses can bid to be listed at the beginning of the list. The database software itself is conventional. The presently preferred best mode is to use a relational database, such as is available from Sybase. However, much simpler software can alternatively be used, such as DBase 4.

Directory listing information may be obtained from a number of commercially available services and/or may be manually entered into the directory listing database 136.

Method of Operation

Callers of a particular telephone company simply dial the access digits established for directory assistance by that company. Examples of typical access digits are "#555" and

"555-1212." The participating telephone company's own switching system will then reroute the call to the directory assistance service center 100 (via a Tl channel), where it appears as an incoming call. In a SS7 system, the telephone company or wireless carrier transmits call set-up information associated with the call to the directory assistance center from the telephone company's signaling network node (also via a Tl channel) to the directory assistance center. For purposes of illustration, a SS7 call initiation procedure will be described, which is utilized not only in routing a caller's call to the directory assistance center, but also by the directory assistance center in connecting the calling caller to the desired number. The phone company (as the originating SSM) first transmits an Initial Address

Message (TAM) to reserve an idle trunk circuit from the originating switch to the destination switch (in this case, switching matrix platform 114). The destination switch examines the dialed number, determines that it serves the called party and that the line is available for ringing. The destination switch then transmits an Address Complete Message (ACM) to the originating switch to indicate that the remote end of the trunk has been reserved. The destination switch rings the called party line and sends a ringing tone over the trunk to the originating switch. When the originating switch receives the ACM, it connects the calling party's line to the trunk to complete the voice circuit from the calling party to the called party. The calling party hears the ringing tone on the voice trunk. When the called party picks up the phone, the destination switch terminates the ringing tone and transmits an Answer Message (ANM) to the originating switch. The originating switch then verifies that the calling party's line is connected to the reserved trunk and, if so, initiates billing.

During the course of the call, if the calling party hangs up first, the originating switch sends a Release Message (REL) to release the trunk circuit between the switches. Upon receiving the REL, the destination switch disconnects the trunk from the called party's line, sets the trunk state to idle, and transmits a Release Complete Message (RLC) to the originating switch to acknowledge the remote end of the trunk circuit. When the originating switch receives the RLC, it terminates the billing cycle and sets the trunk state to idle in preparation for the next call. On the other hand, if the called party hangs up first, or if the line is busy, the destination switch sends an REL to the originating switch indicating the release cause, such as a normal release or busy condition. When the originating switch generates the RLC, it terminates the billing cycle and sets the trunk to idle. Automatic Call Distribution (ACD) logic is used to queue (if necessary) and distribute calls to operators in the order in which they are received, and such that the call traffic is distributed evenly among the operators. In other embodiments, other distribution logic schemes are utilized, such as Skills-Based Routing or a priority scheme for preferred callers The queue is maintained by switching matrix host 128

When a call is connected to an operator, switching matrix host 128 directs the VRU 130 (also conferenced into the call) to play a greeting message, using a message prerecorded by the connected operator Both the operator and the calling caller hear the message, which incorporates the name of the service or company to which the caller is a subscriber (in other words, the call is "branded") The message ends with a prompt, thus cueing the caller to volunteer what information they are seeking

When the automated greeting is complete, the VRU is disconnected, and the operator and the caller are left connected by a 2-way speech path From this point, the caller is interacting with a live operator In the event that the VRU is non-functional (for whatever reason), the incoming call is connected to the operator and a short "trill," or "zip" tone is played to indicate that a caller is on the line (Note that once operators are logged in to the system, they wear headsets, and have their telephones 118 permanently off-hook Their telephones do not ring when a call is presented ) The operator then speaks a greeting and prompt in real time, instead of the VRU playing a message

Concierge Service

The concierge service will now be illustrated by an example, as per an embodiment of a method illustrated in FIGS. 10A and 10B The scenario depicted in the illustrative example is where a caller using his wireless telephone at John F Kennedy airport in New York, requires a dinner reservation at a vegetarian restaurant in "Cardiff by the Sea" near San Diego It should be appreciated however, that a restaurant reservation service is but one type of service that the telephonic concierge service may be able to provide Other areas of use may include, but are not limited to information, reservation and ticketing for events, accommodation, transportation and travel, information regarding news, stock prices and weather, and providing access to other services such as grocery or flower delivery, etc

As per the illustrative example, illustrated in FIGs 10 and 11, the caller dials Directory Assistance (DA) 200 The caller is connected to an operator or a VRU 202 After a greeting, the caller is informed either by the VRU or by the operator about the telephonic concierge service 204 At this point the concierge service may also be explained to the caller. The caller may already be aware of the concierge service and therefore can skip the introduction and/or explanation of the service 240.

If the caller is interested in using the concierge service, she can either request directory listing information 210 or directly make a reservation request 208. If the caller requests restaurant listing information 210 the operator prompts the caller 211 for details regarding for example the type of restaurant, the restaurant location, the approximate date and time of the reservation and other preferences like for example dietary requirements, smoking or non-smoking, outdoors or indoors etc. The operator then inputs these details into a caller profile database 213 (depicted by numeral 134 in FIG. 7A). Using a search engine, the operator searches a directory listing database 212 (depicted by numeral 136 in FIG. 7A) for restaurants based on the above-mentioned caller details and preferences. As per our example, a suitable restaurant is located in "Cardiff by the Sea," near San Diego. If the caller knew the name of the restaurant she wanted she may make a specific reservation request 208 directly on connection to the operator. In such a cast or as per our example, the operator then prompts the caller for reservation details 214 such as the restaurant name (if the operator did not locate it, supra), the callers name, a second choice of restaurant, a required reservation date and time, alternative times, contact details and any additional preferences such as smoking or non-smoking, type of credit card to be used, restaurant views, etc. These details are input into a browser type graphical user interface (GUI) as shown in FIG. 2. The reservation details are then stored in the caller profile database along with a reservation request or ticket. The operator then informs the caller that the reservation request is being processed and either reconnects the caller to the directory assistance operator or disconnects the caller from the system 236.

The ticket is automatically forwarded to a fulfillment agent (FA) 216 for processing. It should be noted that the operator may also process the ticket herself. By default, the ticket is automatically forwarded to a fulfillment agent at the directory assistance center where the call was received, in our example New York. The operator, fulfillment agent or an automated system at the directory assistance center will then forward the request to the directory assistance center nearest the requested venue. In the illustrative example the request will be forwarded to the San Diego directory assistance center. The fulfillment agent in San Diego thus automatically receives the reservation request 218, shown by the graphical user interface in FIG. 3-6. The fulfillment agent then attempts to contact the restaurant 220. Should the fulfillment agent be able to contact the restaurant he will attempt to make a reservation 222. The fulfillment agent then updates the status of the ticket 224 on the system irrespective of whether he was, in fact, successful in making the reservation or not, indicating last action performed, result, reservation details etc. (as seen in FIGs. 4 through 6). After each change of status the fulfillment agent or the system automatically sets a next action time for his attention sometime in the future. The request then slots into the appropriate place in a fulfillment queue. The fulfillment agent cannot set nonsensical time periods like zero minutes or two years. New tickets are prioritized so as to be dealt with in a timely manner on a first-in-first-out basis. After a set amount of unsuccessful tries, the fulfillment agent is automatically prompted to try the second restaurant choice.

After a set amount of time, say for example thirty minutes, the fulfillment agent retrieves the status of the request 228 and contacts the caller informing her of the status of her request 230. The fulfillment agent may contact the caller by phone, fax, email or pager. The caller may also call the service back before the caller is contacted by the fulfillment agent 226. The reservation status is retrieved from the system 228 and the caller is informed of the current status of the reservation request 230. If required, the operator or fulfillment agent may modify the reservation request 232 which is automatically reforwarded to the fulfillment agent 218. Once the reservation is made or the caller indicates a desire to cancel the request, the operator or fulfillment agent closes the Ticket and connects the caller to directory assistance or disconnects the caller from the system 236.

An important feature of the present invention is an activity logging function 234. All caller requests are logged in the caller profile database, as depicted in FIG. 7A by numeral 134. The activity log helps with internal auditing and billing of that particular caller. On-demand printed reservation status reports may be provided to call center managers and/or supervisors. Furthermore when the caller makes use of the concierge service, her mobile identification number (MIN), caller details, most frequent requests and past request activity is automatically presented to the operator. The caller therefore will not have to resupply repetitive details to the operator, thus speeding up the process and reducing the operator's processing time. A fulfillment agent such as a supervisor who is not currently active, then handles any concierge requests that are active or open at that particular directory assistance center. The system may generate reports such as the number of calls processed by a particular center or by the system as a whole. Other reports may include reports indicating the average time spent on each ticket, the time spent fulfilling a ticket request and the time taken to contact a customer. The telephonic concierge system may be affected by other scenarios such as: the fulfillment agent may be unsuccessful in contacting the restaurant; the requested reservation time may be unavailable; the caller might cancel the request; the caller may request a change in the reservation time while still pending.

Additional features The system and method of the present invention has been described. Clearly, there are still other alternatives and equivalents that are within the spirit and intent of the invention and will occur to a person skilled in the art. For example, without limitation, the system may also provide an automated notification to the fulfillment agent when time limits are being exceeded. The caller may receive automated delivery of recorded and/or text-to-speech notification of status of the reservation, with schedule of attempts followed until confirmation of receipt is received. The caller may be able to make periodic requests, such as for example the same restaurant reservation on the first Monday of each month. The caller may request a group notification, to inform a group of people of the reservation confirmation details. The caller may make a "type" request where for example all restaurants of a particular type are contacted, from the nearest to the farthest until the request can be fulfilled. The caller may make a group negotiation by making a group reservation and getting consensus from all parties.

Data extracted from the system may used for internal reports. Such reports may indicate system usage information or service (a particular restaurant hotel, airline) usage information. This information may include the most popular service requests, for example the most popular restaurants, and may be used by fulfillment agents or operators to make recommendations. The data may also be utilized for other purposes such as marketing or market research.

Accordingly, it is intended that the scope of the invention be limited only by the claims that follows and all equivalents thereto.

Claims

What is claimed is:

1. A system for providing concierge-like services comprising:

a service agent capable of receiving a plurality of requests for concierge-like

services; a service agent capable of fulfilling a plurality of request for concierge-like services; an electronic ticket generated by a receiving agent having information associated

with the request for concierge-like services; one or more databases for electronic tickets;

a network over which an electronic ticket is capable of being transferred from a receiving agent to the one or more databases; and a network over which an electronic ticket is capable of being transferred from the one or more databases to a fulfillment agent.

2. A system as in claim 1, further comprising one or more directory databases

containing directory information.

3. A system as in claim 2, wherein a receiving agent has access to the one or more

directory databases to facilitate the generation of electronic tickets.

4. A system as in claim 2, wherein a fulfillment agent has access to the one or more

directory databases to facilitate the fulfillment of electronic tickets.

5. A system as in claim 1, further comprising a pool of agents, wherein the receiving

agent and fulfillment agent are from the pool of agents.

6. A system as in claim 1, further comprising a first and second pools of agents,

wherein the receiving agent is from the first pool of agents and the fulfillment agent is from

the second pool of agents.

7. A system as in claim 1, wherein an electronic ticket includes an identification of the

locale where the concierge-like services are requested.

8. A system as in claim 7, wherein the network transfers the electronic ticket to a

fulfillment agent proximate to the locale identified in the electronic ticket.

9. A system as in claim 1, wherein the ticket includes one or more fields for the name and one or more items of contact information of the individual requesting concierge-like services.

10. A system as in claim 9 wherein the name of the individual requesting concierge-like

services is automatically detected by the system and automatically filled into a field of the

ticket.

11. A system as in claim 9 wherein one or more items of contact information of the

individual requesting concierge-like services is obtained from a database and automatically

filled into a field of the ticket.

12. A system as in claim 1, further comprising an alarm that alerts service agents of a

request for concierge-like services that needs to be fulfilled.

13. A system as in claim 1, wherein fulfillment agents are capable of stepping through a

plurality of tickets waiting to be fulfilled in order to prioritize requests.

14. A system as in claim 1, further comprising a server capable of prioritizing the order

in which a plurality of electronic tickets should be processed and communicating to a

fulfillment agent such order of priority.

15. A system as in claim 1, further comprising a server capable of providing

instructions to a fulfillment agent on actions necessary to fulfill a ticket.

16. A system as in claim 1, further comprising a network connecting a fulfillment agent

to one or more providers of concierge-like services.

17. A system as in claim 16, wherein the network connecting a fulfillment agent to one

or more providers of concierge-like services is a virtual private network.

18. A system as in claim 16, wherein the network connecting a fulfillment agent to one

or more providers of concierge-like services is a dedicated network.

19. A method for providing concierge-like services comprising the steps of:

connecting a communication from a user to a service agent;

receiving by a service agent a request for concierge-like services;

presenting the request to a service agent for fulfillment; fulfilling by the fulfillment agent the request for concierge-like services; and

communicating the fulfillment of the request.

20. A method as in claim 19, further comprising the step of generating a ticket

associated with the request for concierge-like services.

21. A method as in claim 19, further comprising the step of prioritizing the order in

which the requests are presented to the fulfillment agent.

22. A method as in claim 19, further comprising the step of directing the request to a service agent located in the region where the request for concierge-like services concerns activities or information particular to such region.

23. A method as in claim 19, further comprising the step of accessing by the fulfillment agent one or more databases for directory information concerning fulfilling the request for

concierge-like services.

24. A method as in claim 23, further comprising the step of maintaining said databases

locally to keep and maintain travel and concierge-type information relevant to only that particular locale.

25. A method as in claim 19, wherein said communication of said fulfillment of the

request for concierge-like services is transmitted via pager.

26. A method as in claim 19, wherein said communication of said fulfillment of the

request for concierge-like services is transmitted via fax.

27. A method as in claim 19, wherein said communication of said fulfillment of the

request for concierge-like services is transmitted via wireless phone.

28. A method as in claim 19, wherein said communication of said fulfillment of the

request for concierge-like services is transmitted via email.

29. A method as in claim 19, wherein said communication of said fulfillment of the

request for concierge-like services is transmitted by a wireless device.

30. A method as in claim 19, wherein said communication of said fulfillment of the request for concierge-like services is transmitted by a telephone.

31. A method as in claim 19, further comprising the step of providing recommendations

to a caller from information regarding concierge-like services maintained on a database.

32. A method as in claim 20, further comprising obtaining information concerning a

restaurant selected by caller from a database and automatically input into a relevant field in

the ticket.

33. A method as in claim 19, further comprising the step of paging through pending

requests to prioritize such requests.

34. A method as in claim 19 further comprising the step of alerting service agents by

means of an alarm of a request for concierge-like services that needs to be fulfilled.

35. An electronic ticket used in fulfilling a request for concierge-like services

comprising:

a first field into which data concerning a user's contact information is input;

a second field into which information concerning the request for concierge-like

services is input; and a third field into which an identifier of the locale where concierge-like services are

requested.

36. A ticket as in claim 35, further comprising a forth field into which the time of the

next action to be taken towards fulfillment of the request is entered into a field of the ticket.

37. A ticket as in claim 35, wherein the first field is linked to a database having user contact information.

38. A ticket as in claim 35, wherein the second field is linked to a database having

concierge-like services information.