Predictive service request system and methods

In some embodiments, a method is provided that includes one or more of the following features including creating service request outcome models each being based on a service request outcome. A service request entered using natural language can be received and tokenized. A binary matrix can be created from the tokenized service request, and a service request outcome model can be identified based on the binary matrix. The service request outcome model can be used to identify a service request category, a service request predicted resolution, and a service request diagnostic. A confidence value can be calculated based on the service request predicted resolution. The service request category, the service request predicted resolution, and the service request diagnostic can be transmitted to an automated service request resolution system to resolve the service request.

BACKGROUND OF THE INVENTION

Customers that need to enter service requests are often forced to interact with support systems and teams to define and clarify a problem. The costs of support personnel can be substantial. Current support solutions involve the use of self-help and decision trees to guide a customer to a resolution, which shifts the work from support to the customer. This still involves human time and energy to resolve support issues. Systems are needed to reduce the amount of human time required to resolve service requests.

BRIEF SUMMARY OF THE INVENTION

In some embodiments, a method can be used that includes one or more of the following features including creating service request outcome models each being based on a service request outcome. A service request entered using natural language can be received and tokenized. A binary matrix can be created from the tokenized service request, and a service request outcome model can be identified based on the binary matrix. The service request outcome model can be used to identify a predicted service request category, a predicted service request resolution, and a predicted service request diagnostic. A confidence value can be calculated based on the predicted service request resolution. The predicted service request category, the predicted service request resolution, and the predicted service request diagnostic can be transmitted to an automated service request resolution system to resolve the service request.

In some embodiments, the features may also include identifying a service request part value based on the service request outcome model, and the service request part value can be transmitted to the automated service request resolution system. In some embodiments the method can also include receiving a second service request entered using natural language. The second service request can be tokenized, and a second binary matrix can be created based on the tokenized second service request. A second service request outcome model can be identified based on the second binary matrix. A second predicted service request category, a second predicted service request resolution, and a second predicted service request diagnostic can be identified based on the second service request outcome model. A second confidence value can be calculated based on the second predicted service request resolution. A technical support team can be identified based on the second predicted service request category, and the second service request can be transmitted to the technical support team to resolve the service request.

In some embodiments, the method can also include creating a modified service request outcome model based on the binary matrix, and adding the modified service request outcome model to the service request outcome models. In some embodiments, the method can also include eliminating stop words based on a custom dictionary from the service request prior to tokenizing the service request. In some embodiments, upon receipt of the predicted service request category, the predicted service request resolution, the predicted service request diagnostic, and the predicted service request part value at the automated service request resolution system, a service request part is automatically ordered based on the service request part value and an installation technician is automatically scheduled to install the service request part. In some embodiments, the method may also include receiving metadata regarding the service request including at least two of an event code, a product name, a serial number, and a problem category.

In some embodiments, a system can include a processor and a memory storing instructions that cause the processor to create service request outcome models each being based on a service request outcome. The instructions can also cause the processor to receive a service request entered with natural language, tokenize the service request, and create a binary matrix based on the tokenized service request. The instructions can also cause the processor to identify a service request outcome model based on the binary matrix, and, based on the service request outcome model, identify a predicted service request category, a predicted service request resolution, and a predicted service request diagnostic. The instructions can also cause the processor to calculate a confidence value based on the predicted service request resolution and transmit the predicted service request category, the predicted service request resolution, and the predicted service request diagnostic to an automated service request resolution system to resolve the service request.

The instructions can also cause the processor to include one or more of the following features: identify a predicted service request part value based on the service request outcome model and transmit the predicted service request part value to the automated service request resolution system. Receive a second service request entered using natural language and tokenize the second service request. Create a second binary matrix based on the tokenized second service request and identify a second service request outcome model based on the second binary matrix. Identify a second predicted service request category, a second predicted service request resolution, and a second predicted service request diagnostic based on the second service request outcome model and calculate a second confidence value of the identified second predicted service request resolution. Identify a technical support team based on the second predicted service request category and transmit the second service request to the technical support team to resolve the service request.

The instructions can also cause the processor to include one or more of the following features: Create a modified service request outcome model and add the modified service request outcome model to the available service request outcome models. Eliminate stop words based on a custom dictionary from the service request prior to tokenizing the service request. Upon receipt of the predicted service request category, the predicted service request resolution, the predicted service request diagnostic, and the predicted service request part value at the automated service request resolution system, a service request part can be automatically ordered based on the predicted service request part value and an installation technician can be automatically scheduled to install the service request part. Receive metadata regarding the service request including at least two of an event code, a product name, a serial number, and a problem category.

DETAILED DESCRIPTION OF THE INVENTION

Many service request systems include extensive human interaction to identify, classify, and resolve service request issues. While some support systems exist that utilize self-help and decision tree based solutions, they only shift the work from the support personnel to the customer. Further, many hardware and software systems are designed to fail predictably. For that reason, statistical based models, device telemetry data, and natural language processing can be used to classify customer support issues and automatically engage a suitable resolution. The result is a support system that significantly decreases or eliminates the need for human intervention for identification, classification, and resolution of support issues.

FIG. 1depicts a simplified diagram of a service request resolution system100. The service request resolution system100can include a user105, with a user computer system110, a predictive service request system115, a database117, an automated service request resolution system120, a non-automated service request resolution system125, and a process for resolving the service request130.

In some embodiments, a user105can determine that there is an issue with a hardware or software component of a computer system used by user105. The user105can submit a service request using user computer system110. User computer system110can be any suitable computer system such as that described in more detail with respect toFIG. 10. The service request can be entered using natural language. In some embodiments, the service request can be entered using an electronic form. The electronic form can allow the entry of a natural language request. In some embodiments, the electronic form can include specific questions to allow the user to provide specific information. The submission of the service request can send the service request to the predictive service request system115. The predictive service request system115can be any suitable computer system, such as that described with respect toFIG. 10. As described with respect toFIG. 10, the predictive service request system115can be coupled to the user computer system110through a network, allowing the submission of the electronic form. Transmission or submission of data through the network between computer systems can be done using a communications subsystem1024as described inFIG. 10. Each computing system can include a processor or processing unit (e.g., processing unit1004), which can include instructions for execution that cause the processor to instruct the communication subsystem to transmit data, and the processor can process and/or access data received through the communication subsystem.

Upon submission of the service request, the predictive service request system115can receive the service request and process the service request. The predictive service request system115can process the service request to determine whether to port the service request to the automated service request resolution system120or the non-automated service request resolution system125. For example, upon receiving the service request, which in some embodiments is entered using natural language, the predictive service request system can tokenize the service request.

Prior to tokenizing the service request, in some embodiments, the predictive service request system115can remove stop words from the service request. For example, in some embodiments, extraneous words can be removed such as “a,” “the,” and “and.” Additionally, a custom dictionary can be used by the predictive service request system115to remove specific words that are known to be too general or otherwise unhelpful or undesirable. For example, in some embodiments the custom dictionary can contain the words “system” and “help” such that any service request that is received will have the words “system” and “help” removed prior to tokenizing the service request.

The predictive service request system115can, in some embodiments, obtain additional information from metadata or other data from the user computer system110or from the computer system that includes the hardware or software used by the user that is the subject of the service request. In such embodiments, the additional information can also be tokenized. In some embodiments, the additional information can also have stop words removed.

Once the predictive service request system115obtains and tokenizes all the relevant information from the service request and the additional information, the tokenized data from all sources can be combined and the predictive service request system115can build a binary matrix based on the tokenized data. The matrix can be a sparse matrix. The binary matrix can include an entry for each token of the tokenized data. The binary matrix can then be run against a database of service request outcome models117. The service request outcome model that best fits the binary matrix can be selected from the database of service request outcome models117. The service request outcome models can include information that can resolve the service request. The service request outcome model can identify a predicted service request category, a predicted service request resolution, a predicted service request diagnostic, and/or a predicted service request part. In some embodiments, the predicted service request category can identify a problem type, and in some embodiments the predicted service request category can identify a problem type and a required part. The predictive service request system115can calculate a confidence score of the predictions based on how well the binary matrix fits the selected service request outcome model. If the confidence score is above a threshold, the predictive service request system115can transmit the predicted service request category, the predicted service request resolution, the predicted service request diagnostic, and/or the predicted service request part to the automated service request resolution system120. The threshold value can be entered during a configuration of the predictive service request system115. The threshold value can be specified at product, support group, or outcome level.

Providing the predicted service request category, the predicted service request resolution, the predicted service request diagnostic, and/or the predicted service request part to the automated service request resolution system relieves the need for the user to provide detailed information to the automated service request resolution system in a specific format for which it requires data entry. The prediction of the service request resolution based on the user's natural language entry of the information allows the user105to provide, in his or her own words, a description of the problem. The predictive service request system115can utilize the database of service request outcome models117to identify the likely problem and resolution and provide the necessary information to the automated service request resolution system in the format required by the automated service request resolution system120.

In some embodiments, if the calculated confidence score is below the threshold value, the predictive service request system115can determine that the automated service request resolution system120will not have sufficient information to properly resolve the service request. Instead of routing the service request information and predicted values as described above to the automated service request resolution system120, the predictive service request system115can transmit the service request to a non-automated service request resolution system125. In some embodiments, the predictive service request system115can utilize the predicted service request category to identify a specific support team to route the service request to.

Upon determining a resolution to the service request by either the automated service request resolution system120or the non-automated service request resolution system125, the service request can be resolved by processes at130. In some embodiments, that can include sending a part and a service technician to install the part to resolve the service request. In some embodiments providing a knowledge article to the user105can provide the guidance for the user105to resolve the service request through a series of steps outlined in the knowledge article. In some embodiments, a software update can manually or automatically be run on the affected system to resolve the service request. Any combination of necessary steps can be taken at130to resolve the service request.

FIG. 2depicts a flow chart of a predictive service request system200, which can be the predictive service request system115ofFIG. 1. The predictive service request system200can include the ability to receive user input205and service request data225. The user input205can be entered using an electronic submission form, such as, for example, on an internet or intranet page. The electronic submission form can include a portion for entry of a natural language description of the service request. In some embodiments, the natural language entry of the service request can be the only input. In some embodiments, the electronic submission form can include form elements that allow the user to enter information in response to specific questions such as, for example, part numbers, and other data that can be used to identify a resolution to the service request. In some embodiments, the user input205can be entered by a user into a computer system that allows the user to speak the issue and voice recognition software is used to turn the voice data into text that is submitted to the predictive service request system200. Upon submission of the user input205, the predictive service request system200can receive the service request submission.

The user input205can be tokenized into tokenized input210. The user input can be processed prior to tokenizing to remove common words that may not be helpful (e.g., “a” or “the”), and a custom dictionary can be utilized to remove stop words from the user input. Once the stop words and other words that are undesirable are removed from the user input205, the words that remain can be tokenized. Each word and phrase can be turned into a token as will be discussed in further detail with respect toFIG. 4.

The predictive service request system200can receive service request data225. In some embodiments, the predictive service request system200can request the service request data225based on the submission of the user input205. In some embodiments, the service request data225can be automatically sent by the affected system to the predictive service request system200. The service request data225can include, for example, metadata including event codes, product numbers or information, serial numbers, and/or a selected problem category.

The predictive service request system200can determine whether the service request data contains feature information that is categorical at230. For example, the service request data225can include a part number that can allow the predictive service request system to determine that a category of the service request is hardware. If the feature information allows for a determination that there is categorical information, the predictive service request system can create a categorical binary matrix235based on the categorical information provided in the service request data225.

Feature information that is not categorical at230and the tokenized input210can be combined to create the bag of words215. The bag of words215can be all the tokenized words and phrases the predictive service request system200has obtained from the user input205and the service request data225that can be used to predict the best resolution to the service request.

The bag of words can be turned into a bag of words binary matrix220by the predictive service request system200. The bag of words binary matrix220can include an entry in the binary matrix for each tokenized entry in the bag of words215.

The predictive service request system200can also create a categorical binary matrix235from the features that were categorical in the service request data225. The categorical binary matrix235can include an entry in the binary matrix for each categorical feature. Categorical features can also include custom features. The custom features can be used to weight service request outcome models based on business rules.

The predictive service request system200can combine the categorical binary matrix235and the bag of words binary matrix220to have a single binary matrix240that contains an entry for every tokenized word or phrase in the bag of words and every categorical feature. The binary matrix240can be run against the service request outcome models from a database of service request outcome models. The database of service request outcome models can be, for example, the database117ofFIG. 1. The service request outcome models can contain information that can be useful for determining a resolution to the service request, including, for example, a predicted service request category, resolution, diagnostic, and/or part. After running the binary matrix240against the service request outcome models, the predictive service request system200can identify the service request outcome model245that best fits the binary matrix240.

Once the predictive service request system200identifies the service request outcome model245that best fits the binary matrix240, the predictive service request system200can utilize the service request outcome model245to identify information that can be used to resolve the service request. The information can include, for example, a predicted service request category, a predicted service request resolution, a predicted service request diagnostic, and/or a predicted service request part.

In some embodiments, the predicted service request system200can send the predicted information to an automated service request resolution system250to resolve the service request. Automated service request resolution systems often require specific information in a specific format to automatically resolve a service request. The predictive service request system200can provide the information to the automated service request resolution system250in the appropriate format to ensure that the automated service request resolution system250can complete resolution of the service request. In some embodiments, the predictive service request system200can provide the predicted service request category, the predicted service request resolution, the predicted service request diagnostic, and/or the predicted service request part to the automated service request resolution system250. The submission of the necessary information by the predictive service request system200can eliminate the need for the user to input information into the automated service request resolution system250in the necessary format for the automated service request resolution system250to automatically resolve the service request without human intervention from a support team.

FIG. 3depicts a block diagram300of a predictive service request system355. The service request is created at block305. The service request can be created by entry of a service request by a user using any appropriate submission form. The submission can be using form entry information or natural language. In some embodiments, a service request can be created at block305from a system failure that results in an automatic transmission of information to a system that can create the service request. Once the service request is created, it is submitted to the predictive service request system355, where the predictive broker310receives the service request.

The predictive broker310can delegate the natural language inputs to service recommenders. The process for identifying the service recommenders was described in more detail with respect toFIG. 2above. The result can be a part prediction315, a resolution prediction320, and/or a diagnostic prediction325. The diagnostic prediction can be sent to the automation framework service request orchestration330. That information can be used to allow the automated service request resolution system (e.g., automated service request resolution system250) to run the predicted diagnostic at335using the part prediction315. The results of running the diagnostic335as well as the resolution prediction320can be sent to the diagnostic broker345. The outcome of running the diagnostic can be reconciled with the part prediction315, resolution prediction320and diagnostic prediction325to determine whether the predicted resolution320is accurate.

If the predicted resolution320is accurate, the predictive service request system300can have a high confidence value that the predicted resolution320will resolve the service request. In such cases, the predicted values can be sent to the automated service request resolution system to resolve the service request at350. If the confidence value is not high, or if the resolution prediction320is not confirmed by the diagnostic broker345, the predictive service request system300can send the service request instead to a support team to resolve the service request at350.

FIG. 4depicts a simplified block diagram of a tokenizer portion400of a predictive service request system (e.g., predictive service request system200) with an exemplary input and output. The block diagram includes an input405, a tokenizer410, and an output415.

The input405can be the natural language user input entered into a service request system as described with respect to the previous figures. The input, in this example, is “The Warehouse Management Software is not working properly. It is intermittently freezing.” That input405can be received by tokenizer410. Prior to the input being received at tokenizer410, or as part of tokenizer410, the input405can be processed to have unnecessary and/or stop words removed from the input405. In this example, the words “the,” “is,” and “it” can be removed. In some embodiments, a custom dictionary can be used to identify and remove stop words from the input405. The custom dictionary can be configured and modified by an administrator of the system. In some embodiments, machine learning techniques can be used to identify words that generate failures or are otherwise undesirable can be automatically added to the custom dictionary.

The tokenizer410can use the remaining words from input405to create a set of tokens415. The tokenizer410can use the words and phrases identified in the input405to create a token for each word and each phrase identified in the input405. In the example, the words and phrases identified from input405are “Warehouse Management,” “not working,” “intermittent,” “freeze,” and “intermittently freezing.” The output405includes a token for the word “intermittent” based on the entry of the word “intermittently.” In some embodiments, the token can be “intermittently” instead of “intermittent.” Also, the phrases “Warehouse Management” and “intermittently freezing” can be identified and assigned a token by tokenizer410. In this example, “Warehouse Management” is the product name.

FIG. 5depicts a simplified block diagram of a model comparator portion500of a predictive service request system (e.g., predictive service request system355ofFIG. 3). The model comparator portion500of the predictive service request system can include tokenized input505, metadata510, combination data515, a model comparator520, and prediction outcome data525.

The tokenized input505can be, for example, the tokenizer output415ofFIG. 4, as is shown in this example. The metadata510can be, for example, an event code, serial number, and version number from the affected system. The metadata510can be, for example, the service request data225ofFIG. 2. The tokenized input505and the metadata510can be combined to create the combination data515which can be run against the service request outcome models in the service request outcome model database (e.g., database117ofFIG. 1). The combination data515is not shown as a binary matrix for human clarity, but can be the binary matrix240of

FIG. 2. As shown inFIG. 5, the tokens from the tokenized input505can be combined with the metadata510, which can also be tokenized in some embodiments. The combined data515can be input into the model comparator520.

The model comparator520can run the combined data515against a number of service request outcome models from the database of service request outcome models. The service request outcome models can be entered in the database initially through a manual setup process. In some embodiments, a configuration program can be run that automatically populates the service request outcome model database with a set of service request outcome models based on information obtained from test runs of the predictive service request system.

The model comparator520can select a subset of service request outcome models from the service request outcome model database to run the combined data515against based on specific information contained in the combined data515. For example, the model comparator520can identify the token that corresponds to the phrase “Warehouse Management” and identify the product as “Warehouse Management.” Based on this identification, the model comparator520can select only service request outcome models that are related to software service requests because “Warehouse Management” is a software product. In some embodiments, the model comparator520can select only service request outcome models that are related to the Warehouse Management software program.

After the model comparator520runs the combined data515against the service request outcome models that are selected for comparing (i.e., either a subset or all of the models in the database), the model comparator520can select the service request outcome model that best fit the combined data515.

The model comparator520can output the prediction outcome data525based on the selected service request outcome model. Each service request outcome model can identify prediction information including, for example, a predicted service request category, a predicted service request resolution, a predicted service request diagnostic, and/or a predicted service request part. The prediction outcome data525can include, a predicted service request category of “software,” for example. In the example shown inFIG. 5, Warehouse Management is a software product, and the version currently running on the affected system is 4.2, based on metadata510. Based on that information, the model comparator520can select a model that identifies the predicted service request category as “software.” The selected service request outcome model can also identify that an upgrade to the latest version can resolve the issue, which can be output in the prediction outcome data525as the predicted service request resolution. Associated with the upgrade and identified by the selected service request outcome model can be a predicted service request diagnostic, for which a path may be identified, as shown in prediction outcome data525. The predicted service request diagnostic can be, for example, a path to “Warehouse Management/4.5/upgrade,” which can diagnose whether earlier versions can be upgraded to version 4.5 to resolve issues, for example.

FIG. 6depicts a flow diagram of a method of a predictive service request system. The method can be executed with the systems described withinFIGS. 1-5above. The method begins at605, and at610the method includes creating service request outcome models. The service request outcome models can be stored in a database, such as database117ofFIG. 1. The service request outcome models can include information for identifying the type of service request that the outcome model is intended to resolve as well as information for resolving the service request. For example, a service request outcome model can include information about whether the included resolution is intended to resolve a hardware, firmware, or software service request. As another example, the service request outcome model can include the specific software, firmware, or hardware that it is intended to resolve including part numbers and/or version numbers. As another example, the service request outcome model can include the type of problem that the service request might be related to including broken parts, freezing software, or other specific keywords that can help to identify the appropriate service request outcome model. Additionally, the service request outcome model can include prediction information for diagnosing and resolving the service request. For example, the service request outcome model can include a predicted service request category, a predicted service request diagnostic, a predicted service request resolution, and/or a predicted service request part.

The service request outcome models can be generated in an initial configuration phase of the predictive service request system. For example, the models may be generated and uploaded manually based on service request information that is already known. Service request outcome models can also be automatically added to the database based on the operation of the predictive service request system. For example, upon each run of the predictive service request system, the service request may not precisely match any stored service request outcome models, so a new service request outcome model can be generated based on that service request and entered into the database.

At615the predictive service request system can receive a natural language service request. The service request can be entered by a user at any computer system that is communicatively coupled to the predictive service request system. The service request can be entered by the user in any suitable way. For example, the computer system can include a web interface allowing the user to type in a request. As another example, the computer system can allow the user to state the service request verbally, which the computer system can convert into a format accepted by the predictive service request system.

At620the predictive service request system can tokenize the service request. Each word and/or phrase of the service request that is not eliminated by a custom dictionary or otherwise determined to be unhelpful or undesirable can be turned into or assigned a token. Tokenizing is described in further detail with respect toFIGS. 1, 2, and 4.

At625the predictive service request system can create a binary matrix based on the tokenized service request. The binary matrix can include an entry for each token of the tokenized service request. In some embodiments, features collected by the predictive service request system through metadata or other information can be identified and also tokenized or otherwise included in the binary matrix for inclusion in the process of determining the predicted resolution of the service request.

At630the predictive service request system can identify a service request outcome model based on the binary matrix. The binary matrix can be run against multiple service request outcome models from the database of service request outcome models to identify the service request outcome model that best fits the binary matrix. In other words, the binary matrix can include information containing details of the service request and the affected system that requires service. The service request outcome models can be examined to find the one that contains a resolution for the problem most closely matching the service request. Machine learning and human trained algorithms are used to identify the closest match.

At635the predictive service request system can identify a predicted service request category, predicted service request resolution, and predicted service request diagnostic based on the service request outcome model. As described above, the service request outcome models include predicted information for use in resolving the service request. That predicted information can include a category, resolution, and diagnostic.

At640the predictive service request system can calculate a confidence value of the predicted service request resolution. As described with respect toFIG. 3, the diagnostic broker345can utilize the predicted information to run the diagnostic and reconcile the predictions to determine whether the predictions are accurate. Such reconciliation can include calculating a confidence value that predicted service request resolution is accurate.

At645the predicted service request category, predicted service request resolution, and the predicted service request diagnostic can be transmitted to the automated service request resolution system. As described with respect toFIG. 10, the predictive service request system can include a communications subsystem (e.g., communications subsystem1024) to transmit the data. The predictive service request system additionally can include a processing unit (e.g., processing unit1004) that can include instructions that, when executed, can instruct the communications subsystem to transmit the data to the automated service request system. Automated service request resolution systems can require inputs to be entered in a specific format or specific data to be entered. Failure to meet the automated service request resolution system requirements can result in the automated service request resolution system failing to be able to resolve the service request. In many cases, the result is that the service request is routed to a support team by the automated service request resolution system after receiving input, particularly from a user, that is insufficient to meet the requirements of the automated service request resolution system. The predictive service request system can provide the information required by the automated service request resolution system in the proper format, in many cases removing the requirement for human intervention. Additionally, the automated service request resolution system can have multiple workflows that allow the service request to be resolved, and the predictive service request system can submit the necessary information to the automated service request resolution system to invoke the proper workflow for the service request to be resolved automatically.

In some embodiments, if the information required by the automated service request resolution system is not obtained by the predictive service request system or the confidence value calculated at 640 is not high enough, the predictive service request system can route the service request to a support team. In such cases, the predictive service request system can, in some embodiments, utilize the predicted service request category or other service request information including the product name if available, to direct the service request to a specific support team. In other words, the predictive service request system can use intelligent routing to direct the service request to the appropriate destination.

FIG. 7Adepicts a flow diagram of a portion of a method700of a predictive service request system. The portion of the method700can be executed with the method600described with respect toFIG. 6. At705, the predictive service request system can identify a predicted service request part value based on the service request outcome model. The predicted service request part value can identify a part that can be used to fix the broken equipment that resulted in the service request.

At710the predictive service request system can transmit the predicted service request part value to the automated service request resolution system. The automated service request resolution system can utilize the predicted service request part value to resolve the service request. In some embodiments, the part can automatically be ordered and service technician can be scheduled automatically to install the part.

FIG. 7Bdepicts a flow diagram of a portion of a method715of a predictive service request system. The portion of the method715can be executed with the method600described with respect toFIG. 6. At720the predictive service request system can create a modified service request outcome model based on the binary matrix. As described elsewhere herein, the service request outcome model that best fits the binary matrix can be selected from the service request outcome model database. In some embodiments, the binary matrix developed from the service request may not fit the service request outcome model precisely, in which case the predictive service request system can develop a new service request outcome model that fits the binary matrix precisely or better than the selected predictive service request outcome model.

At725the predictive service request system can add the modified service request outcome model to the service request outcome model database. Adding the modified service request outcome model to the database can make the modified model available to the predictive service request system for use in future selections of service request outcome models. In some embodiments, the model can be entered into a temporary database for approval before the model is added to the service request outcome model database for use in future runs of the predictive service request system.

FIG. 8depicts a simplified diagram of a distributed system800for implementing one of the embodiments. In the illustrated embodiment, distributed system800includes one or more client computing devices802,804,806, and808, which are configured to execute and operate a client application such as a web browser, proprietary client (e.g., Oracle Forms), or the like over one or more network(s)810. Server812may be communicatively coupled with remote client computing devices802,804,806, and808via network810.

In various embodiments, server812may be adapted to run one or more services or software applications provided by one or more of the components of the system. The services or software applications can include nonvirtual and virtual environments. Virtual environments can include those used for virtual events, tradeshows, simulators, classrooms, shopping exchanges, and enterprises, whether two- or three-dimensional (3D) representations, page-based logical environments, or otherwise. In some embodiments, these services may be offered as web-based or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices802,804,806, and/or808. Users operating client computing devices802,804,806, and/or808may in turn utilize one or more client applications to interact with server812to utilize the services provided by these components.

In the configuration depicted in the figure, the software components818,820and822of system800are shown as being implemented on server812. In other embodiments, one or more of the components of system800and/or the services provided by these components may also be implemented by one or more of the client computing devices802,804,806, and/or808. Users operating the client computing devices may then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or combinations thereof. It should be appreciated that various different system configurations are possible, which may be different from distributed system800. The embodiment shown in the figure is thus one example of a distributed system for implementing an embodiment system and is not intended to be limiting.

Although exemplary distributed system800is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, etc., may interact with server812.

Server812may be composed of one or more general purpose computers, specialized server computers (including, by way of example, PC (personal computer) servers, UNIX® servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. Server812can include one or more virtual machines running virtual operating systems, or other computing architectures involving virtualization. One or more flexible pools of logical storage devices can be virtualized to maintain virtual storage devices for the server. Virtual networks can be controlled by server812using software defined networking. In various embodiments, server812may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server812may correspond to a server for performing processing described above according to an embodiment of the present disclosure.

Distributed system800may also include one or more databases814and816. Databases814and816may reside in a variety of locations. By way of example, one or more of databases814and816may reside on a non-transitory storage medium local to (and/or resident in) server812. Alternatively, databases814and816may be remote from server812and in communication with server812via a network-based or dedicated connection. In one set of embodiments, databases814and816may reside in a storage-area network (SAN). Similarly, any necessary files for performing the functions attributed to server812may be stored locally on server812and/or remotely, as appropriate. In one set of embodiments, databases814and816may include relational databases, such as databases provided by Oracle, that are adapted to store, update, and retrieve data in response to SQL-formatted commands.

FIG. 9is a simplified block diagram of one or more components of a system environment900by which services provided by one or more components of an embodiment system may be offered as cloud services, in accordance with an embodiment of the present disclosure. In the illustrated embodiment, system environment900includes one or more client computing devices904,906, and908that may be used by users to interact with a cloud infrastructure system902that provides cloud services. The client computing devices may be configured to operate a client application such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application, which may be used by a user of the client computing device to interact with cloud infrastructure system902to use services provided by cloud infrastructure system902.

It should be appreciated that cloud infrastructure system902depicted in the figure may have other components than those depicted. Further, the embodiment shown in the figure is only one example of a cloud infrastructure system that may incorporate an embodiment of the invention. In some other embodiments, cloud infrastructure system902may have more or fewer components than shown in the figure, may combine two or more components, or may have a different configuration or arrangement of components.

Client computing devices904,906, and908may be devices similar to those described above for802,804,806, and808.

Although exemplary system environment900is shown with three client computing devices, any number of client computing devices may be supported. Other devices such as devices with sensors, etc. may interact with cloud infrastructure system902.

Network(s)910may facilitate communications and exchange of data between clients904,906, and908and cloud infrastructure system902. Each network may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including those described above for network(s)810.

Cloud infrastructure system902may comprise one or more computers and/or servers that may include those described above for server812.

Large volumes of data, sometimes referred to as big data, can be hosted and/or manipulated by the infrastructure system on many levels and at different scales. Such data can include data sets that are so large and complex that it can be difficult to process using typical database management tools or traditional data processing applications. For example, terabytes of data may be difficult to store, retrieve, and process using personal computers or their rack-based counterparts. Such sizes of data can be difficult to work with using most current relational database management systems and desktop statistics and visualization packages. They can require massively parallel processing software running thousands of server computers, beyond the structure of commonly used software tools, to capture, curate, manage, and process the data within a tolerable elapsed time.

Extremely large data sets can be stored and manipulated by analysts and researchers to visualize large amounts of data, detect trends, and/or otherwise interact with the data. Tens, hundreds, or thousands of processors linked in parallel can act upon such data in order to present it or simulate external forces on the data or what it represents. These data sets can involve structured data, such as that organized in a database or otherwise according to a structured model, and/or unstructured data (e.g., emails, images, data blobs (binary large objects), web pages, complex event processing). By leveraging an ability of an embodiment to relatively quickly focus more (or fewer) computing resources upon an objective, the cloud infrastructure system may be better available to carry out tasks on large data sets based on demand from a business, government agency, research organization, private individual, group of like-minded individuals or organizations, or other entity.

In various embodiments, cloud infrastructure system902may be adapted to automatically provision, manage and track a customer's subscription to services offered by cloud infrastructure system902. Cloud infrastructure system902may provide the cloud services via different deployment models. For example, services may be provided under a public cloud model in which cloud infrastructure system902is owned by an organization selling cloud services (e.g., owned by Oracle) and the services are made available to the general public or different industry enterprises. As another example, services may be provided under a private cloud model in which cloud infrastructure system902is operated solely for a single organization and may provide services for one or more entities within the organization. The cloud services may also be provided under a community cloud model in which cloud infrastructure system902and the services provided by cloud infrastructure system902are shared by several organizations in a related community. The cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

In certain embodiments, cloud infrastructure system902may also include infrastructure resources930for providing the resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, infrastructure resources930may include pre-integrated and optimized combinations of hardware, such as servers, storage, and networking resources to execute the services provided by the PaaS platform and the SaaS platform.

In certain embodiments, a number of internal shared services932may be provided that are shared by different components or modules of cloud infrastructure system902and by the services provided by cloud infrastructure system902. These internal shared services may include, without limitation, a security and identity service, an integration service, an enterprise repository service, an enterprise manager service, a virus scanning and white list service, a high availability, backup and recovery service, service for enabling cloud support, an email service, a notification service, a file transfer service, and the like.

In certain embodiments, cloud infrastructure system902may provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functionality may include capabilities for provisioning, managing and tracking a customer's subscription received by cloud infrastructure system902, and the like.

In one embodiment, as depicted in the figure, cloud management functionality may be provided by one or more modules, such as an order management module920, an order orchestration module922, an order provisioning module924, an order management and monitoring module926, and an identity management module928. These modules may include or be provided using one or more computers and/or servers, which may be general purpose computers, specialized server computers, server farms, server clusters, or any other appropriate arrangement and/or combination.

In exemplary operation934, a customer using a client device, such as client device904,906or908, may interact with cloud infrastructure system902by requesting one or more services provided by cloud infrastructure system902and placing an order for a subscription for one or more services offered by cloud infrastructure system902. In certain embodiments, the customer may access a cloud User Interface (UI), cloud UI912, cloud UI914and/or cloud UI916and place a subscription order via these UIs. The order information received by cloud infrastructure system902in response to the customer placing an order may include information identifying the customer and one or more services offered by the cloud infrastructure system902that the customer intends to subscribe to.

After an order has been placed by the customer, the order information is received via the cloud UIs,912,914and/or916.

At operation936, the order is stored in order database918. Order database918can be one of several databases operated by cloud infrastructure system918and operated in conjunction with other system elements.

At operation938, the order information is forwarded to an order management module920. In some instances, order management module920may be configured to perform billing and accounting functions related to the order, such as verifying the order, and upon verification, booking the order.

At operation940, information regarding the order is communicated to an order orchestration module922. Order orchestration module922may utilize the order information to orchestrate the provisioning of services and resources for the order placed by the customer. In some instances, order orchestration module922may orchestrate the provisioning of resources to support the subscribed services using the services of order provisioning module924.

In certain embodiments, order orchestration module922enables the management of business processes associated with each order and applies business logic to determine whether an order should proceed to provisioning. At operation942, upon receiving an order for a new subscription, order orchestration module922sends a request to order provisioning module924to allocate resources and configure those resources needed to fulfill the subscription order. Order provisioning module924enables the allocation of resources for the services ordered by the customer. Order provisioning module924provides a level of abstraction between the cloud services provided by cloud infrastructure system900and the physical implementation layer that is used to provision the resources for providing the requested services. Order orchestration module922may thus be isolated from implementation details, such as whether or not services and resources are actually provisioned on the fly or pre-provisioned and only allocated/assigned upon request.

At operation944, once the services and resources are provisioned, a notification of the provided service may be sent to customers on client devices904,906and/or908by order provisioning module924of cloud infrastructure system902.

At operation946, the customer's subscription order may be managed and tracked by an order management and monitoring module926. In some instances, order management and monitoring module926may be configured to collect usage statistics for the services in the subscription order, such as the amount of storage used, the amount data transferred, the number of users, and the amount of system up time and system down time.

In certain embodiments, cloud infrastructure system900may include an identity management module928. Identity management module928may be configured to provide identity services, such as access management and authorization services in cloud infrastructure system900. In some embodiments, identity management module928may control information about customers who wish to utilize the services provided by cloud infrastructure system902. Such information can include information that authenticates the identities of such customers and information that describes which actions those customers are authorized to perform relative to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.) Identity management module928may also include the management of descriptive information about each customer and about how and by whom that descriptive information can be accessed and modified.

FIG. 10illustrates an exemplary computer system1000, in which various embodiments of the present invention may be implemented. The system1000may be used to implement any of the computer systems described above. As shown in the figure, computer system1000includes a processing unit1004that communicates with a number of peripheral subsystems via a bus subsystem1002. These peripheral subsystems may include a processing acceleration unit1006, an I/O subsystem1008, a storage subsystem1018and a communications subsystem1024. Storage subsystem1018includes tangible computer-readable storage media1022and a system memory1010.

Processing unit1004, which can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of computer system1000. One or more processors may be included in processing unit1004. These processors may include single core or multicore processors. In certain embodiments, processing unit1004may be implemented as one or more independent processing units1032and/or1034with single or multicore processors included in each processing unit. In other embodiments, processing unit1004may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

In various embodiments, processing unit1004can execute a variety of programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in processor(s)1004and/or in storage subsystem1018. Through suitable programming, processor(s)1004can provide various functionalities described above. Computer system1000may additionally include a processing acceleration unit1006, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.

I/O subsystem1008may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, pointing devices such as a mouse or trackball, a touchpad or touch screen incorporated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and/or gesture recognition devices such as the Microsoft Kinect® motion sensor that enables users to control and interact with an input device, such as the

Microsoft Xbox® 360 game controller, through a natural user interface using gestures and spoken commands. User interface input devices may also include eye gesture recognition devices such as the Google Glass® blink detector that detects eye activity (e.g., ‘blinking’ while taking pictures and/or making a menu selection) from users and transforms the eye gestures as input into an input device (e.g., Google Glass®). Additionally, user interface input devices may include voice recognition sensing devices that enable users to interact with voice recognition systems (e.g., Siri® navigator), through voice commands.

Computer system1000may comprise a storage subsystem1018that comprises software elements, shown as being currently located within a system memory1010. System memory1010may store program instructions that are loadable and executable on processing unit1004, as well as data generated during the execution of these programs.

Storage subsystem1018may also provide a tangible computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that when executed by a processor provide the functionality described above may be stored in storage subsystem1018. These software modules or instructions may be executed by processing unit1004. Storage subsystem1018may also provide a repository for storing data used in accordance with the present invention.

Storage subsystem1000may also include a computer-readable storage media reader1020that can further be connected to computer-readable storage media1022. Together and, optionally, in combination with system memory1010, computer-readable storage media1022may comprehensively represent remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information.

Communications subsystem1024provides an interface to other computer systems and networks. Communications subsystem1024serves as an interface for receiving data from and transmitting data to other systems from computer system1000. For example, communications subsystem1024may enable computer system1000to connect to one or more devices via the Internet. In some embodiments communications subsystem1024can include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology, such as 3G, 4G or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and/or other components. In some embodiments communications subsystem1024can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

In some embodiments, communications subsystem1024may also receive input communication in the form of structured and/or unstructured data feeds1026, event streams1028, event updates1030, and the like on behalf of one or more users who may use computer system1000.

Additionally, communications subsystem1024may also be configured to receive data in the form of continuous data streams, which may include event streams1028of real-time events and/or event updates1030, that may be continuous or unbounded in nature with no explicit end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measuring tools (e.g. network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

Communications subsystem1024may also be configured to output the structured and/or unstructured data feeds1026, event streams1028, event updates1030, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to computer system1000.