WO2003005210A1

WO2003005210A1 - Method, apparatus, and system for parallel processing of user requests

Info

Publication number: WO2003005210A1
Application number: PCT/CN2001/001151
Authority: WO
Inventors: Lingyun Tuo; Tao Huang; Zhang Hongyi; Jian Liu
Original assignee: Intel Corporation; Intel China Ltd.
Priority date: 2001-07-02
Filing date: 2001-07-02
Publication date: 2003-01-16
Also published as: CN1271530C; CN1543607A

Abstract

According to one aspect of the invention, a method is provided in which a first request and a second request are received from a first user. The first request and the second request are processed in parallel. For each request, it is determined whether a response for the respective request is available within a predetermined time period. If the corresponding response for the respective request is available within the predetermined time period, the response is sent to the first user. If the corresponding response is not available within the predetermined time period, a message is sent to the first user indicating that the respective request has been timeout.

Description

METHOD, APPARATUS/ AND SYSTEM FOR PARALLEL PROCESSING OF

USER REQUESTS

FIELD OF THE INVENTION

The present invention relates to the field of computer processing. More specifically, the present invention relates to a method, apparatus, and system for parallel processing of user requests.

BACKGROUND OF THE INVENTION

The field of human-computer interaction, and interface has been undergoing rapid changes in recent years due to advances in computer technology and related fields. In particular, a lot of time and effort has been directed to utilizing technological advances in multimedia and multimodal processing to improve the usability and productivity of processing systems.

In recent years, more and more applications have been developed using advances in speech recognition technology to enable various users to interact with a system through audio input/output, in addition to the traditional method of text processing. More particularly, many applications have been implemented as speech-enabled interactive voice response (IVR) applications to allow the users to submit requests to the system and/or receive output information from the system in audio format (e.g., speech). These IVR applications are generally designed to serve multiple users that are connected to the system. However, in conventional or traditional IVR applications, one user can only submit one request to the system at a time. As a result, multiple requests from the same user can only be submitted to the Bystem and processed by the system sequentially. This type of architecture and processing method is usually referred to as a sequential model. An example of a sequential modal is illustrated and described in detail in VoiceXMLl.O specifications, which are available for reference at ht p://w-ww.voicexml.org/specs_l .html .

Figure 1 is a flow diagram illustrating an example of how a user checks information (e.g., stock and weather information) sequentially in a sequential processing model/architecture. Figure 2 is a flow diagram illustrating in general how user requests are submitted and processed sequentially in a conventional system/application. In the sequential model/architecture, once a user has submitted a request to the system, the same user is not allowed to submit new request until a response of the previous request arrives. If the request involves large database search or Internet search or simply because of slow network, the system most likely cannot determine whether it can get appropriate information or not in a given time period for the user. The user may get a timeout notification if expected information cannot arrive in time. This sequential model may lead to a large portion of time wasted on waiting for system response even if the user wants to check other useful information that maybe available during that period. In addition, system resources may be significantly under-utilized in this sequential model or sequential architecture. As a result, the sequential model or sequential architecture is very inefficient in processing user requests.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will be more fully understood by reference to the accompanying drawings, in which: Figure 1 is a flow diagram illustrating an example of how a user checks information sequentially in a sequential processing model/architecture;

Figure 2 is a flow diagram illustrating in general how user requests are submitted and processed sequentially in a conventional system/applica io ;

Figure 3 shows a block diagram o£ one embodiment of a system architecture/configuration in accordance with the teachings of the present invention;

Figure 4 shows a structure diagram of a request list according to the teachings of the present invention;

Figure 5 is a flow diagram of one embodiment of a user input management method according to the teachings of the present invention;

Figure 6 is a flow diagram of one embodiment of a service process management method according to the teachings of the present invention;

Figure 7 illustrates a flow diagram of one embodiment of a method for dispatching system response in accordance with the teachings of the present invention,-

Figure 8 shows a flow diagram of one embodiment of a method according to the teachings of the present invention; and

Figure 9 show a flow diagram of one embodiment of a method in accordance with the teachings of the present invention.

DETAILED DESCRIPTION

In the following detailed description numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be appreciated by one skilled in the art that the present invention may be understood and practiced without these specific details. In the discussion below, the teachings of the present invention are utilized to implement a method, apparatus, system, and machine-readable medium for parallel processing of user requests. According to the teachings of the present invention, parallel processing of user requests is implemented through' a parallelized architecture for speech- enabled interactive voice response (IVR) applications.

In one embodiment of the new IVR application architecture described herein, a user can submit new requests without having to wait for the responses of previous requests, Multiple requests from the same user will be processed in parallel. In one embodiment, a system in which the teachings of the present invention are implemented will report information available to the user based on the order in which the corresponding responses arrive. Thus, the system can serve multiple requests from the same user at the same time. In one embodiment, multiple input requests are received from a user. These multiple input requests are then processed in parallel. In one embodiment, to perform the parallel processing of the multiple input requests, various components in the system including a user input manager, a service process manager, and a system response dispatcher cooperate with one another to process the multiple requests in parallel as described in more details below. In one embodiment, upon receiving an input request from the user, the user input manager determines whether the respective input request is a new service request or a command request with respect to an existing service request that was previously submitted by the user. If the input request is a new service request, the user input manager adds the new service request to a request list. If the input request is a command request, the user input manager updates a corresponding in the request list for the existing service request based upon .the received command. While the user input manager performs its corresponding function, the service process manager also performs the following functions in parallel. In one embodiment, the service process manager determines or detects whether a new service request has been received from the user input manager. If a new service request has been received, the service process manager creates a service process to handle/process the respective new service request. Because each service process runs independently from other service processes, multiple requests can be processed simultaneously in a parallel mode.

Figure 3 shows a block diagram of one embodiment of a system configuration/architecture 300 according to the teachings of the present invention. The system architecture 300 is capable of handling or processing multiple requests from the same user in a parallel mode. As shown in Figure 3, the system architecture 300 includes a user input manager 310, a service process manager 3^'25, and a system response dispatcher 335. The system architecture 300 further includes an input state 315, a request list 320, and service process pool 330. In one embodiment, the service process pool 330 includes multiple service processes that can run independently to process multiple requests from a user 301 in a parallel mode. The operations and functions of each component or unit shown in Figure 3 are described in greater detail below.

In one embodiment, the user 301 represents one of the users of the system who is able to access the system 300 to get information he or she needs. In one embodiment, the user 301 is also able to provide commands to manage service requests that were previously submitted by the user 301. Examples of some of the commands (also called request managing commands herein) that can be submitted or provided by the user 301 include the following:

- Cancel/stop (cancel a previous request)

- Cancel/stop all (cancel all previous requests)

- Retry (reissue a previous request)

- Report state (report the status of the requests)

- Next (next request)

In on embodiment, the input state 315 is a state variable that is used to indicate the state of a current connected user (e.g., user 301). In one embodiment, the input state variable 315 can be set to one of two values: idle or active. When the system detects that there is no user input, the input state variable 315 is set to idle. When the system detects that there is user input (e.g., by speech or any other input methods) , the input state variable 315 is set to active. In one embodiment, the user input manager 310 is configured to detect user input activity and set the input state variable 315 accordingly. As described in more details below, in an intelligent mode, the system response dispatcher 335 will check the input state variable 315 to decide whether to present information to the user 301 or not.

In one embodiment, the request list 320 is a list that contains all requests from a user (e.g., user 301), including both pending requests and processed requests. The pending requests are those requests that have been received by the system but no results or responses are available at the moment . The processed requests are those requests for which the results or responses have been returned but have not been reported to the user. In one embodiment, new requests are added to this list once they are collected and the state of these requests are tagged as pending. Once the corresponding response for a pending request arrives, the state of the request is changed to processed. In one embodiment, the request list 320 is used to store^' a plurality of request entries each of which corresponds to a particular request received from the user 301.

A structure diagram 400 of the request list 320 is illustrated in Figure 4. In one embodiment, each request entry may contain various data items or fields including request identifier 410, request content 420, request state flag 430, request repeat times 440, and request response 450, etc. In one embodiment, request identifier 410 is a unique number or identifier for each request. For example, the first request in the request list 320 can be assigned a unique identifier of "1", the second request can be assigned a unique identifier of "2", and so on. In one embodiment, the request content 420 contains a description of the corresponding request. The request state flag 430 is used to indicate the current state of the corresponding request (e.g., pending or processed) . In one embodiment, the repeat times field 440 is used to indicate how many times the corresponding request has been tried in case of timeout or failure. The request response 450, in one embodiment, represents the result or response for the request that is returned from the corresponding service process once the service process finishes processing the respective request.

In one embodiment, the user input manager 310 is responsible for gathering user inputs (e.g., new service requests or request managing commands, etc.) and dispatching the user inputs to corresponding components so that they are processed in appropriate places. In general, most IVR systems or applications employ two types of input methods: DTMF/pulse key input and speech input. The user inputs are interpreted as character strings using DTMF/pulse key detector or speech recognizer before the user input manager 310 receives them. The components for DTMF/pulse key detector or speech recognizer are not shown in Figure 3.

Figure 5 shows a flow diagram one embodiment of a process 500 that is performed by the user input manager 310. As shown in Figure 5, the user input manager 310 is able to collect multiple user requests continuously. It has no need to wait for the result of a previous request for getting more user requests. In one embodiment, there are various types of user inputs including service requests and requests managing commands. The request managing commands can be submitted by a user to manage all the. requests associated with that user including unprocessed and processed requests. In one embodiment, the processed requests may be reported to the user automatically by the system in conditions described below.

In one embodiment, the user input manager 310 is also responsible for detecting user activity and setting the value of the input state variable 315 accordingly. For example, if there is no user input, the input state variable 315 is set to idle. If there is user input detected by the user input manager 310 , the input state variable 315 is set to active.

Referring again to Figure 5, the process 500 starts at block 501 and proceeds to block 510 to get user input. At decision block 520, the type of user input is determined. The process 500 proceeds to block 530 if the user input is a new service request. Otherwise, the process 500 proceeds to block 540. At block 530, the new service request is added to the request list 320 and a notification is sent to the service process manager 325 to inform or notify the service process manager 325 that a new service request has been received. At block 540, the request list is modified based upon the request managing command received. A notification may also be sent to the service process manager 325 if necessary. For example, if the request managing command is a command to cancel a previous request, a cancellation notification is sent to the service process manager 325. In this case, the service process manager 325 will cancel or stop the corresponding service process that was created for the respective service request. The process 500 will then loop back from either block 530 or 540 to block 510.

Figure 6 shows a flow diagram of one embodiment of a process 600 performed by the service process manager 325. In one embodiment, the service process manager 325 is responsible for processing the user requests as follows. Upon receiving a service request from the user input manager 310, the service process manager 325 creates a service process to handle the request according to the information stored in the request list 320. Once the corresponding service process finishes the processing of the service request or a timeout condition occurs, the service process manager will get either the result information (or time out message) from the corresponding service process. The service process manager 325 will then send an appropriate notification to the system response dispatcher 335 to inform the system response dispatcher 335 of the status of the respective service request (e.g., whether the result information is available to be sent to the user or a timeout has occurred) . The service process manager 325 then puts the result information (or timeout message) in the request list 320 for the respective service request. The state of that service request is changed to "processed" accordingly. In one embodiment, the processed requests form a sub-list of the requests in the order of the service requests that have been processed. This sub- list can be referred to as the processed requests list. Because each service process runs independently with respect to other service processes, multiple requests are being processed simultaneously. Accordingly, the system designed and implemented in accordance with the teachings of the present invention is more efficient (e.g., more information can be delivered to a user in a given time period) compared to the sequential model in traditional or conventional systems/applications .

In one embodiment, the service process manager 325 can receive commands to cancel ongoing service processes . For example, this may occur when the user logouts or the user issues specific commands to request cancellation of service requests. In this instance, the service process manager 325 will stop or cancel the corresponding processes immediately.

Referring to Figure 6, the process 600 starts at block 601 and proceeds to decision block 610. At decision block 610, the process 600 proceeds to block 615 if a new service request has been received. Otherwise the process 600 proceeds to decision block 620. At block 615, a service process is created or activated to process the respective service request. At decision block 620, the process 600 proceeds to block 625 if a service process completes its processing or a timeout occurs. Otherwise the process 600 proceeds to block 630. At block 625, a notification message is sent to the system response dispatcher 335. Result information (or timeout information in the event that a timeout has occurred) is put in the request list 320. At decision block 630, if the a message to cancel a request is received, the process 600 proceeds to block 635 to cancel or stop the corresponding service process immediately. Otherwise the process 600 loops back to block 610 to continue the processing of service requests.

Figure 7 illustrates a flow diagram of one embodiment of a process 700 performed by the system response dispatcher 335 in accordance with the teaching of the present invention. In one embodiment, the system response dispatcher 335 is configured to report the result of a user request returned by the system to the user. In one embodiment, the system response dispatcher 335 receives appropriate notifications from the corresponding service processes via the service process manager 325 when they finish processing or when timeout conditions occur. Upon receiving the appropriate notifications, the. system response dispatcher 335 may notify the user of the current state of the processed request list such as the number of total processed requests. In one embodiment, after the user gets the result, a post process is performed for the request. The user may choose to refresh the request (e.g., issue the request again because of timeout) or delete it from the request list or just leave it alone. In one embodiment, the system can implement its own policy on whether to refresh/keep/delete the processed request when the user has specified no preferences. As described above, the user input manager 310 is responsible for getting the user input and handling the user commands .

In one embodiment, the system response dispatcher 335 can choose one of the below reporting modes to report results to the user, depending on the system configuration:

1. Blind mode: the system response dispatcher 335 will report the results to the user as soon as the results are available, regardless of the user activity at that time.

2. Intelligent mode: the system response dispatcher 335 will report the results to the user when the user is idle (e.g., by checking the value of the input state variable

315) .

3. Passive mode: in this mode, the user will get no notification when a result is available so the user has to issue the appropriate commands to check for the result.

In any case, the user can retrieve the information on his/her own. Referring again to Figure 7, the process 700 starts at block 701 and proceeds to block 710 to set a flag called HASNOTIFICATION to a first value (e.g., false). At decision block 715, the process 700 proceeds to block 720 to set the flag HASNOTIFICATION to a second value (e.g., true) if a new notification has been received. Otherwise the process 700 proceeds to decision block 725 to check whether the HASNOTIFICATION flag is true. If the HASNOTIFICATION is true, the process 700 proceeds to decision block 735 to determine the appropriate reporting mode. If the reporting mode is blind mode, the process 700 proceeds to block 755. If the reporting mode is intelligent mode, the process 700 proceeds to decision block 745 to check whether the user is idle. If the user is idle, the process 700 proceeds to block 755 to report the result information to the user. Otherwise the process loops back to block 710 to continue processing. If the reporting mode is passive mode, the process 700 proceeds to block 765. At block 765, the HASNOTIFICATION flag is reset to false value. The process 700 then loops back from block 765 to block 710 to continue processing.

Figure 8 illustrates a flow diagram of one embodiment of a method 800 according to the teachings of the present invention. At block 810, a first request and a second request are received from a first user. At block 820, the first request and the second request are processed in parallel. At block 830, for each request, it is determined whether a response for the respective request is available within a predetermined time period. At block 840, if the corresponding response for the respective request is available within the predetermined time period, the response is sent to the first user. At block 850, if the corresponding response is not available within the predetermined time period, a message or notification is sent to the first user indicating to the first user that the respective request has been timeout.

Figure 9 shows a block diagram of one embodiment of a method 900 according to the teachings of the present invention. At block 910, multiple requests (e.g., service requests or request managing commands, etc.) are received from a first user. At block 920, it is determined whether an input request is a new service request or a command with respect to an existing service request (e.g., a request that was submitted previously by the first user) . At block 930, if the input request is a new service request, the respective new service request is added to a request list. A service process is created or activated to handle/process the new service request. At block 940, if the input request is a command, a corresponding entry in the request list is updated accordingly based upon the command received. As described above, one or more corresponding functions (e.g., cancellation of service request, report status of the requests, etc.) are then performed according to the command received.

While the present invention has been described herein using speech-enabled IVR systems/applications as examples, it should be appreciated and understood by one skilled in the art that the teachings of the present invention can be applied to other types of systems and applications. The teachings of the present invention can be utilized in various speech-enabled service systems/applications such as voice portals and web-based applications.

The invention has been described in conjunction with the preferred embodiment. It is evident that numerous alternatives, modifications, variations and uses will be apparent to those skilled in the art in light of the foregoing description.

Claims

What is claimed is: 1. A method comprising: receiving a first request and a second request from a first user; processing the first request and the second request in parallel; determining, for each request, whether a response for the respective request is available within a predetermined time period; if the corresponding response for the respective request is available within the predetermined time period, sending the corresponding response to the first user,- and if the corresponding response for the respective request is not available within the predetermined time period, sending a message to the first user indicating that the respective request has been timeout.

2. The method of claim 1 wherein processing the first request and the second request in parallel includes : adding the first request and the second request to a request list associated with the first user; and assigning a corresponding status of the first request and the second request to a first value indicating that the first request and the second request are pending requests for which corresponding responses are currently not available .

3. The method of claim 2 further including: creating a separate service process _.for each pending request in the request list to handle the corresponding request; and running each service process independently with respect to other service processes.

4. The method of claim 3 further including.- in response to a notification indicating chat the respective request has been completed, updating the status of the respective request to a second value indicating that a response for the respective request is now available to be sent to the first user.

5. The method of claim 1 further including: receiving a third request from the first user including a specific command to be performed with respect to one or more previously submitted requests; and performing the specific command with respect to the one or more previously submitted request .

6. The method of claim 5 wherein the specific command is a command to cancel a specific request that was previously submitted by the first user.

7. The method of claim 5 wherein the specific command is a command to cancel all requests that were previously submitted by the first user.

8. The method of claim 5 wherein the specific command is a command to retry a specific request that was previously submitted by the first user.

9. The method of claim 5 wherein the specific command is a command to report the current status of one or more requests previously submitted by the first user.

10. A method comprising: receiving multiple input requests from a first user,- and processing the multiple input requests from the first user in parallel, including: determining whether an input request from a first user is a new service request or a command with respect to an existing service request ; if the input request is a new service request, adding the new service request to a request list; and if the input request is a command, updating a corresponding entry in the request list for the existing service request;

11. The method of claim 10 wherein processing the multiple input requests further including: detecting whether a new service request has been received; if a new service request has been received, creating a service process to handle the respective new service request; detecting whether the respective service process has completed within a predetermined time period; if the service process has completed within the predetermined time period, sending result information generated by the respective service process to the first user; and if the service process has not completed within the predetermined time period, sending a message to the first user indicating that the corresponding service request has been timeout.

12. The method of claim 11 further including: in response to receiving a command with respect to one or more existing service requests, performing one or more corresponding functions based upon the command received.

13. The method of claim 11 further including: determining a reporting mode associated with the first user; and performing a corresponding reporting function according to the reporting mode associated with the first user.

14. An apparatus comprising: logic to receive a first request and a second request from a first user; logic to process the first request and the second request in parallel; logic to determine, for each request, whether a response for the respective request is available within a predetermined time period logic to send the corresponding response to the first user if the corresponding response for the respective request is available within the predetermined time period; and logic to send a message indicating that the corresponding service request has been timed out if the corresponding response for the respective request is not available within the predetermined time period.

15. The apparatus of claim 14 wherein logic to process the first request and the second request in parallel includes: logic to add the first request and the second request to a request list associated with the first user; and logic to assign a corresponding status of the first request and the second request to a first value indicating that the first request and the second request are pending requests for which corresponding responses are currently not available.

16. The apparatus of claim 15 further including: logic to create a separate service process for each pending request in the request list to handle the corresponding request; logic to run each service process independently with respect to other service processes.

17. The apparatus of claim 16 further including: logic to update the status of the respective request to a second value indicating that a corresponding response for the respective service request is available, in response to a notification indicating that the respective request has been completed.

-16-

18. The apparatus of claim 14 further including: logic to receive a third request from the first user, the third request including a specific command to be performed with respect to one or more previously submitted requests; and logic to perform the specific command with respect to the one or more previously submitted request.

19. A system comprising: logic to receive multiple input requests from a first user; and logic to process the multiple input requests from the first user in parallel, including: logic to determine whether an input request from a first user is a new service request or a command with respect to an existing service request; if the input request is a new service request, logic to add the new service request to a request list; and if the input request is a command, updating a corresponding entry in the request list for the existing service request;

20. The system of claim 19 wherein logic to process the multiple input requests further including: logic to detect whether a new service request has been received; if a new service request has been received, logic to create a service process to handle the respective new service request;

21. The system of claim 20 further including: logic to detect whether the respective service process has completed within a predetermined time period; if the service process has completed within the predetermined time period, logic to send result information generated by the respective service process to the first user; and if the service process has not completed within^"" the predetermined time period, logic to send a message to the first user indicating that the corresponding service request has been timeout.

22. The system of claim 19 further including: in response to receiving a command with respect to one or more existing service requests, logic to perform one or more corresponding functions based upon the command received.

23. The system of claim 22 wherein the command received is a command to cancel a specific service request that was previously submitted by the first user.

24. The system of claim 22 wherein the command received is a command to cancel all requests that were previously submitted by the first user.

25. The system of claim 22 wherein the command received is a command to retry a specific request that was previously submitted by the first user.

26. The syBtem of claim 22 wherein the command received is a command to report the current status of one or more requests previously submitted by the first user.

27. A machine-readable medium comprising instructions which, when executed by a machine, cause the machine to perform operations including: receiving a firβt request and a second request from a first user; processing the first request and the second request in parallel; determining, for each request, whether a response for the respective request is available within a predetermined time period; if the corresponding response for the respective request is available within the predetermined time period, sending the corresponding response to the first user^"; and if the corresponding response for the respective request is not available within the predetermined time period, sending a message to the first user indicating that the corresponding service request has been timeout.

28. The machine-readable medium of claim 27 wherein processing the first request and the second request in parallel includes: adding the first request and the second request to a user-request list associated with the first user; and assigning a corresponding status of the first request and the second request to a first value indicating that the first request and the second request are pending requests for which corresponding responses are currently not available.

29. The machine-readable medium of claim 28 further including : creating a separate service process for each pending request in the user-request list to handle the corresponding request; and running each service process independently with respect to other service processes.

30. The machine-readable medium of claim 27 further including: receiving a third request from the first user including a specific command to be performed with respect to one or more previously submitted requests; and performing the specific command with respect to the one or more previously submitted request.