Providing automatic user input to applications during disruptions

Abstract

This specification relates to techniques for addressing disruptions that prevent an application from receiving user input, that prevent a user from providing input to an application, and / or that prevent or affect a user's receipt of application output. One example method involves detecting a disruption to an interactive application during a user's interaction with the interactive application, generating automatic user input, and providing the automatic user input to the interactive application during the disruption to the interactive application.

Description

[Background technology]

[0001] background

[0001] In many computing environments, disruptions are a problem. For example, when a user is playing a video game or using another type of interactive application over a network, a network disruption may cause the interactive application to be unable to respond to the user's input. Disruptions may also be non-technical in nature, such as when a family member or friend interrupts the user. Automation efforts to address such disruptions have had limited success. Summary of the Invention

[0002] overview

[0002] This Summary is provided to introduce selected concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0003]

[0003] This description generally relates to techniques for addressing disruptions to an application's ability to receive user input, provide input, and / or receive application output. An example includes a method or technique that may be executed on a computing device. The method or technique may include detecting a disruption to an interactive application during a user's interaction with the interactive application. The method or technique may also include generating automatic user input or providing the automatic user input to the interactive application in response to detecting the disruption.

[0004]

[0004] Another example includes a system having a hardware processing unit and a storage resource storing computer-readable instructions. The computer-readable instructions, when executed by the hardware processing unit, can cause the hardware processing unit to detect a network disruption that at least temporarily prevents a streaming interactive application from receiving one or more actual user inputs. The computer-readable instructions can also cause the hardware processing unit to generate automatic user inputs using previously received actual user inputs. The computer-readable instructions can also cause the hardware processing unit to substitute the automatic user inputs for one or more actual user inputs to the streaming interactive application in response to detecting the network disruption.

[0005]

[0005] Another example includes a computer-readable storage medium storing computer-readable instructions that, when executed by a hardware processing unit, cause the hardware processing unit to perform operations. The operations may include receiving a video output of an interactive application and receiving an actual user input to the interactive application provided by a user. The operations may also include detecting a disruption that prevents the interactive application from receiving further actual user input. The operations may also include providing the video output of the interactive application and the actual user input to a predictive model and obtaining predicted user input from the predictive model. The operations may also include providing the predicted user input to the interactive application during the disruption.

[0006]

[0006] The examples listed above are intended to provide a quick reference to assist the reader and are not intended to define the scope of the concepts described herein.

[0007] BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The detailed description will now be described with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference number identifies the figure in which the reference number first appears. Use of like reference numbers in different instances of the description and figures may indicate similar or identical items. [Brief description of the drawings]

[0008] [Figure 1] 1 illustrates an example of a gaming environment consistent with some implementations of the present concepts. [Diagram 2]

[0009] 1 illustrates an example timeline consistent with some implementations of the present concepts. [Figure 3A]

[0010] 1 illustrates an example user experience consistent with some implementations of the present concepts. [Figure 3B]

[0010] Examples of user experiences consistent with some implementations of the present concepts are provided. [Figure 3C]

[0010] Examples of user experiences consistent with some implementations of the present concepts are provided. [Figure 3D]

[0010] Examples of user experiences consistent with some implementations of the present concepts are provided. [Figure 3E]

[0010] Examples of user experiences consistent with some implementations of the present concepts are provided. [Figure 4]

[0011] 1 illustrates an example process flow consistent with some implementations of the present concepts. [Diagram 5]

[0012] 1 illustrates an example user interaction model consistent with some implementations of the present concepts. [Figure 6]

[0013] 1 illustrates an example system consistent with some implementations of the present concepts. [Figure 7]

[0014] 1 provides examples of methods or techniques consistent with some implementations of the present concepts. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Detailed Description General

[0015] As described, disruptions can be problematic for users of interactive applications (such as video games, augmented reality applications, or other applications) where the user frequently provides inputs to control the application. In the case of online applications, a network disruption between the user device and the application server may cause the application server to receive inputs too late to effectively use those inputs to control the online application. In addition, a network disruption may cause the user device to receive application server output, such as video or audio output, too late for the user to respond effectively. In either case, the application experience is disrupted.

[0010]

[0016] One basic approach to dealing with application disruptions is to continue to use recent input during the disruption that was received before the disruption began. However, this approach can have a negative impact on the user's application experience. For example, the recent input can have negative or unexpected results in the application because the user did not have an opportunity to adjust their input to respond to the application output that was generated during the disruption time.

[0011]

[0017] A more sophisticated alternative might involve monitoring internal application state and adjusting the internal application state during disruptions to provide a more fluid user experience, but this approach might involve a significant development effort, including modifying internal application code to manage disruptions and / or providing hooks into the internal application state to external disruption management software.

[0012]

[0018] The disclosed implementations provide techniques for mitigating application disruptions that address the above problems. In the disclosed implementations, automated user input is used in place of actual user input during the application disruption. Once the disruption is over, control can be returned to the user.

[0013]

[0019] In some implementations, the automatic user input can be generated without accessing internal application state. For example, a user interaction model can use information such as application output and previously received user input to generate the automatic user input, and the automatic user input generated by the user interaction model can be provided to the application during the disruption. As a result, the disclosed implementations can provide a seamless experience to the user during the disruption without requiring modification of application code.

[0014]

[0020] Additionally, the disclosed implementations can provide a realistic user experience by utilizing automated user input that accurately reflects how a particular user would interact with a given application in the absence of disruptions In comparison, as discussed further below, approaches that attempt to mimic optimal behavior rather than predict user behavior can yield unrealistic results.

[0015] Terminology

[0021] For purposes of this specification, the term "application" refers to any type of executable software, firmware, or hardware logic for performing a specified function. The term "interactive application" refers to an application that performs processing in response to received user input and adjusts application output repetitively, frequently, or continuously in response to received user input. The term "online application" refers to an application that can be accessed over any type of computer network or communication link by streaming or downloading the application from one device to another. The term "streaming application" refers to an online application that runs on a first device and transmits a stream of application output over a network or other communication link to one or more other devices. The one or more other devices can reproduce the application output, for example, using a display or audio device, and can also provide user input to the streaming application.

[0016]

[0022] The term "disruption" refers to any situation that at least temporarily affects or at least temporarily prevents a user from interacting with an interactive application. For example, a disruption may be technical in nature, such as, for example, a network disruption or other technical issue that prevents an interactive application from receiving actual user input and / or prevents a user from receiving application output. Common disruptions may include network conditions such as latency, bandwidth limitations, or dropped packets. Disruptions may also be non-technical in nature, such as, for example, a user being distracted by a conversation with a friend or family member, an incoming phone call, etc.

[0017]

[0023] The term "user interaction model" refers to any type of machine learning, heuristic, or rule-based technique that can be used to model user interaction with an application, for example, by generating automated user input. The term "actual user input" refers to input actually provided by a user during the course of an interaction with an interactive application. The term "automated user input" refers to a machine-generated representation that can be used in place of the actual user input during a disruption. In some cases, the automated user input output by a given model can be used without modification, while in other cases, the automated user input output by a model can be smoothed or combined with previously received actual user input before being provided to the interactive application. Thus, the term "automated user input" encompasses both the unmodified output of a user interaction model and the output of a user interaction model that has been smoothed or combined with actual user input.

[0018]

[0024] The term "machine learning model" refers to any of a broad range of models that can learn to generate automated user input by observing characteristics of past interactions between users and applications. For example, machine learning models can be neural networks, support vector machines, decision trees, clustering algorithms, and the like. In some cases, machine learning models can be trained using labeled training data, reward functions, or other mechanisms, while in other cases, machine learning models can learn by analyzing data without explicit labels or rewards. The term "user-specific model" refers to a model that has at least one component that is at least partially trained or constructed for a particular user. Thus, the term encompasses models that are fully trained for a particular user, models that are initialized using multi-user data and tuned for a particular user, and models that have both a general component trained for multiple users and one or more components trained or tuned for a particular user. Similarly, the term "application-specific model" refers to a model that has at least one component that is at least partially trained or constructed for a particular application.

[0019]

[0025] The term "neural network" refers to a type of machine learning model that uses layers of nodes to perform certain operations. In a neural network, the nodes are connected to each other via one or more edges. A neural network may include an input layer, an output layer, and one or more hidden layers. Individual nodes may process their respective inputs according to a predefined function (e.g., a transfer function such as ReLU or sigmoid) and provide the output of the function to a subsequent layer (or, in some cases, a previous layer). The input to a given node may be multiplied by the corresponding weight value of the edge between the input and the node. In addition, the nodes may have individual bias values, which are also used to generate the output. Various training procedures may be applied to learn the edge weights and / or bias values.

[0020]

[0026] A neural network structure may have different layers that perform different specific functions. For example, one or more layers of nodes may collectively perform a specific operation, such as pooling, encoding, or convolution operations. For purposes of this specification, the term "layer" refers to a group of nodes that share inputs and outputs (e.g., to or from external sources or other layers of the network). The term "operation" refers to a function that may be performed by one or more layers of nodes.

[0021] Example of a video game system

[0027] The following describes some specific examples of how the present concepts can be employed in the context of streaming video games, where network disruptions can affect game play. However, as discussed elsewhere herein, the present concepts are not limited to video games, nor to streaming or network-connected applications, nor to dealing with network disruptions. Rather, the present concepts can be employed in a wide range of technology environments to deal with many different types of disruptions to various types of interactive applications.

[0022]

[0028] 1 illustrates an example gaming environment 100 consistent with disclosed implementations. For example, FIG. 1 illustrates example communications between an application server 102, an intermediary server 104, a client device 106, and a video game controller 108. The application server can execute an interactive application, such as a streaming video game, and generate output 110, which may include video, audio, and / or haptic output. The application server can send the output to the intermediary server, which can forward the output to the client device 106.

[0023]

[0029] The client device 106 can display video output on a display and play audio output through speakers. In examples where the video game provides haptic output, the client device can forward the haptic output to a video game controller 108 (not shown in FIG. 1). The video game controller can generate haptic feedback based on the haptic output received from the application server. In addition, the video game controller can generate actual user input 112 based on user interaction with various input mechanisms of the video game controller. The video game controller can send the actual user input to the client device, which can forward the actual user input back to the intermediary server 104.

[0024]

[0030] In the absence of a disruption, the intermediary server 104 may simply act as a pass-through server and forward the actual user input 112 to the game server. However, if a network disruption is detected, the intermediary server may instead provide automatic user input 114 to the application server. As described further below, automatic user input allows the application server to continue application processing in a manner that reduces or eliminates user perception of the disruption, such that the user is seamlessly reintroduced into the application experience once the disruption ends.

[0025] Timeline Example

[0031] 2 illustrates an example timeline 200. Timeline 200 encompasses three time periods: a time 202 that occurs before a network disruption, a time 204 that there is a network disruption, and a time 206 that occurs after the network disruption. Timeline 200 illustrates how the disclosed implementations can be used to address a network disruption, which in FIG. 2 is illustrated through a network state representation 208.

[0026]

[0032] At time 202, actual user input 210 is utilized to control a video game. The video game may generate video output 212, audio output 214, and / or haptic output 216 in response to the actual controller input and / or internal game state. Note that these outputs are not necessarily provided at a fixed rate, although in some implementations video and audio, among other things, may be provided at a specified frame rate. In many instances, the haptic output and user input, among other things, are asynchronous.

[0027]

[0033] At time 204, the network is disrupted. For purposes of this example, it is assumed that the disruption affects both traffic flow to and from the user, and thus the user's device does not receive video game output and the application server does not provide actual user input. During the disruption, automated user input 218 is provided to substitute for actual user input that is unavailable due to the network disruption. As discussed further below, in some implementations, the automated user input can be generated by a user interaction model that has access to the video game output during the network disruption. For example, the user interaction model can have local network access to the application server and the network disruption occurs on an external network, or the user interaction model can run on the same device as the video game.

[0028]

[0034] At time 206, the network is restored and further actual user input is received and provided to the game. As discussed further below, this allows the video game to seamlessly transition from network disruption to user control without causing disruption to the user. As discussed elsewhere herein, some implementations may smooth or combine automated user input with actual user input to further reduce the impact of the network disruption on the user input.

[0029] User Experience Examples

[0035] 3A-3E show an exemplary user experience 300 of a user playing a driving video game. In FIG. 3A, a car 302 is shown moving along a road 304. FIG. 3A also shows a directional representation 310 and a trigger representation 320, which represent controller inputs to the driving game. In general, a directional representation conveys the magnitude of a direction for a directional input mechanism of a video game controller (e.g., a thumbstick for steering a car). Similarly, a trigger representation 320 conveys the magnitude of a trigger input in a video game controller, for example, to control the throttle of a car. Thumbsticks and triggers are two examples of "analog" input mechanisms that can be provided on a controller. The term "analog" is used to refer to input mechanisms that are not simply on / off. For example, by varying the magnitude of the input to an analog input mechanism, a user can cause the analog input mechanism to generate a signal that can be digitally represented using a range of values ​​greater than two.

[0030]

[0036] The directional representation 310 is shown with the received actual directional input 312 shown in black, and the automatic directional input 314 shown in white. Similarly, the trigger representation 320 shows the received actual trigger input 322 in black, and the automatic trigger input 324 in white. For the purposes of the following, it is assumed that the automatic input is being generated in the background by the user interaction model as the user plays the driving game.

[0031]

[0037] In Figure 3A, the user is steering the car 302 gently to the left with the throttle at medium opening, so that the car is being controlled via real directional input 312 and real trigger input 322. Auto directional input 314 and auto trigger input 324 generated by the user interaction model are similar to real user inputs, but are not currently used to control the car.

[0032]

[0038] 3B and 3C, the car 302 continues to move along road 304 as the user continues to navigate the car gently to the left, and the actual and automated user inputs differ to some extent: the car remains in control of the actual user inputs, because no disruption has yet occurred.

[0033]

[0039] In FIG. 3D, a disruption occurs. For purposes of this example, assume that the disruption prevents the video game from receiving actual user input, but does not prevent its visual output to the user. The user needs to swerve left and throttle back on the road 304 to correctly navigate the curve. However, recent actual user inputs are stale, and even though the user has adjusted their thumbstick and trigger inputs to, for example, make a sharp turn and throttle back, those actual user inputs have not been received by the video game. As a result, if the stale user inputs were used, the car would run off the road, as shown by ghost car 330, because the magnitude of the stale directional input to the left is too small to correctly navigate the curve.

[0034]

[0040] At this point, the automatic user input can be substituted for the actual user input. For example, in Figure 3D, the automatic direction input 314 is used instead of the stale, recently received user input, which causes the car to make a sharp left turn, and the automatic trigger input 324 throttles back to slow the car 302. Thus, during the disruption, the car continues to move along the road 304 without veering off the road because it is controlled by the automatic user input. Figure 3D also shows the current actual user input 316 (hatch pattern), which is affected by the disruption and is therefore not available for controlling the gameplay.

[0035]

[0041] 3E shows the video game after recovery from the disruption. Because automatic user inputs were used to control the car 302 during the disruption, when control is returned to the user the car is approximately where the user expected it to be on the road 304. The received actual direction input 312 received from the user is moving left to indicate that the user correctly made a sharp left turn. Similarly, the received actual trigger input 322 received from the user is tightening the throttle.

[0036]

[0042] Because the automated user input used during the disruption was similar to the actual input provided by the user during the disruption, the user does not perceive much of an impact on the gameplay experience. In contrast, if recently received stale user input had been used instead of the automated input, the user may have experienced a collision, as shown by ghost car 330 crashing into tree 340.

[0037] Example of model processing flow

[0043] 4 illustrates an example process flow 400 that may be employed to selectively provide real or automatic input to an application 402. In the process flow 400, a real input source 404 provides real user input 406 to a user interaction model 408. The user interaction model 408 may use the real user input and / or application output 410 to generate automatic user input 412. The application output may also be provided to an output mechanism 414, such as for displaying images or videos, playing audio, generating haptic feedback, etc.

[0038]

[0044] The input adjudicator 416 can select the actual user input 406 or the automatic user input 412 to provide to the application 402 as the selected input 418. For example, if there is no disruption, the input adjudicator can provide the actual user input to the application as the selected input. If a disruption occurs, the input adjudicator can directly substitute the automatic user input for the actual user input, for example, by outputting the automatic user input as the selected input provided to the application. In other cases, the input adjudicator can smooth or combine the automatic user input provided by the user interaction model with previously received actual user input and output the smoothed / combined automatic user input to the application.

[0039]

[0045] As discussed further below, the process flow 400 can be employed in a wide variety of technology environments. For example, in some implementations, each portion of the process flow executes on a single device. In other cases, different portions of the process flow execute on different devices. Figure 1 illustrates a particular example, where, for example, the application 402 may be on the application server 102, the actual input source 404 may be a video game controller 108, the output mechanism 414 may be provided by the client device 106, and the user interaction model 408 and input adjudicator 416 may be provided by the intermediary server 104.

[0040]

[0046] Also, note that the process flow 400 does not necessarily rely on access to internal application state to determine the automatic user input. As previously suggested, this can be beneficial because it allows the disclosed concepts to be implemented without modifying application code. However, in other cases, the user interaction model has access to internal application state and can use the internal application state to determine the automatic user input. In general, any internal game state can be employed to determine the automatic user input, from raw data in CPU or GPU memory to specific data structures or intermediate graphics pipeline stages. For example, a driving video game can provide many different simulated driving courses, and the user interaction model can have access to an identifier of the current driving course. As another example, a driving video game can provide many different vehicle models for the user to drive, and the user interaction model can have access to an identifier of the currently selected vehicle model. In implementations where the user interaction model does not have access to internal game state, the user interaction model may be able to infer the current driving course or vehicle model from the application output, for example, by analyzing the video output by the application.

[0041] Specific examples of user interaction models

[0047] As mentioned above, one way to implement the user interaction model 408 is to employ machine learning techniques. FIG. 5 illustrates a neural network-based predictive model 500 that can be employed as a user interaction model consistent with the present concept. The following describes one particular implementation of how the neural network-based predictive model can be employed to predict user inputs to an interactive application. In the following description, reference numbers beginning with "4" refer to elements previously introduced in FIG. 4, and reference numbers beginning with "5" refer to elements newly introduced in FIG. 5.

[0042]

[0048] Actual user input 406 and application output 410 may be input for preprocessing 502. For example, if actual user input is provided via a video game controller having buttons and analog input mechanisms, the controller input may be preprocessed by representing the buttons as Boolean values ​​and normalizing the values ​​of the analog input to a value range of -1 to 1. Video or audio output may be preprocessed by reducing the resolution of the video and / or audio output, and haptic output may also be normalized, for example, to a range of -1 to 1.

[0043]

[0049] In some implementations, pre-processing 502 maintains respective windows for user input and application output. For instance, the following example assumes a one second time window. Pre-processing may include performing time alignment of the actual user input with the corresponding frames of video and / or audio data. In addition, the haptic output may be time aligned with the actual user input. This process results in an input window 504 and an output window 506.

[0044]

[0050] The input window 504 may be input to a fully connected neural network 508, and the output window 506 may be input to a convolutional neural network 510. The output of the fully connected neural network (e.g., a vector space representation of features extracted from the input window) and the convolutional neural network (e.g., a vector space representation of features extracted from the output window) may be input to a recurrent neural network 512, such as a long short-term memory ("LSTM") network.

[0045]

[0051] The recurrent neural network 512 can output embeddings 514, which can represent the user inputs and application outputs in a vector space. The embeddings can be fed back to the recurrent neural network (as indicated by arrow 513) or can be input to another fully-connected network 516. Note that some implementations can employ multiple recurrent neural networks (e.g., a first recurrent neural network to process the output of the fully-connected network 508 and a second recurrent neural network to process the output of the convolutional neural network 510).

[0046]

[0052] The fully connected network 516 can map from the embeddings output by the recurrent neural network to the automated user inputs 412. The embeddings represent information about the user inputs and application outputs used by the fully connected network 512 to determine the automated user inputs 412 (e.g., future predicted user inputs).

[0047]

[0053] In addition, automated user input 412 may also be input to preprocessing 502 and preprocessed as described above. Thus, at any given time step, the inputs that are preprocessed are the inputs selected for that time step, for example, by input adjudicator 416. Consequently, at any given time, input window 504 may include all actual user inputs, all automated user inputs (e.g., assuming a disruption at least as long as the input window), and / or a combination of both actual and automated user inputs.

[0048] Specific model processing examples

[0054] As described, pre-processing 502 can be performed as a series of time steps. For example, one convenient interval can be for using a standardized video frame rate, with one time step per video frame. A 60 Hz video frame rate results in 60 frames within a given 1 second window. Each input window 504 can have 60 respective sets of actual or automated user inputs, and each output window 506 can have 60 respective sets of application outputs. As described, the input and output windows can be time-aligned with each other.

[0049]

[0055] In general, actual or automated user inputs and application outputs can be pre-processed to obtain features for input to the fully connected neural network 508 and the convolutional neural network 510, respectively. Thus, in some instances, pre-processing 502 can involve extracting features that may be useful for discrimination across the input window 504 and the output window 506 to accurately predict the user input for the next time step. For example, pre-processing can include extracting uniqueness features from the actual or predicted user input for the current time step, where the uniqueness features indicate whether the user input has changed from the user input of the previous time step.

[0050]

[0056] Some user inputs (such as those provided by a video game controller) can be represented as vectors. For example, certain entries of the vector can represent different button states as Boolean on / off values, while other entries of the vector can represent magnitudes for analog input mechanisms, such as trigger states and directional pressure applied to a thumbstick. The vector may also include entries that indicate whether a value has changed from a state at a previous time. This vector representation can be used for both actual and predicted user inputs.

[0051]

[0057] In an implementation where user inputs and application outputs are discretized and time-aligned to a 60 Hz video frame rate using 1 second windows, each individual network of the neural network-based predictive model 500 can simultaneously process 60 stacked input / output vectors, each vector representing 16.67 milliseconds of time. The recurrent neural network 512 can also maintain an internal recurrent state that can be used to represent previous outputs of the recurrent network, which may contain information not present in the current input / output window. Thus, the recurrent neural network 512 can effectively model sequences of input / output data that are longer than the duration of the respective time windows provided by the preprocessing 502.

[0052]

[0058] It should also be noted that some implementations may smooth or combine the automatic user input 412 with previous actual or predicted user input to reduce jitter and / or user perception that the game is not responsive to the user's input. It should also be noted that the neural network based predictive model 500 may predict the final user input value or a delta relative to the last seen user input.

[0053] Model Training and Architecture

[0059] The following discussion provides details on how a model such as neural network-based predictive model 500 can be trained to generate automated user inputs. The following training techniques can be applied to a variety of other machine learning model types, including other neural network structures and model types other than neural networks.

[0054]

[0060] One method for training a model involves using imitation learning techniques. For example, the DAgger algorithm is provided in S. Ross, GJ Gordon, and J. Bagnell, “A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning,” in AISTATS, 2011. DAgger presents an iterative approach to learning policies to mimic users, where the policies specify predicted user actions (e.g., user inputs) as a function of previously received information. As another example, the AggreVaTe algorithm is provided in S. Ross and J. Bagnell, “Reinforcement and Imitation Learning via Interactive No-Regret Learning,” in arXiv:1406.5979, 2014. AggreVaTe is an extension of DAgger that uses a “cost-to-go” loss function to inform training, rather than a binary zero-or-one classification loss.

[0055]

[0061] In some implementations, a separate model can be trained for each user and / or each application. Although this approach can ultimately provide a high-quality model that can accurately predict user inputs, generating a new model from scratch for each user and each application can be time-consuming. In addition, this approach generally involves extensive use of computational resources, such as storage resources for storing separate models and processor time for training separate models for each user. Moreover, this approach relies on obtaining a large amount of training data for each user and / or each application. As a result, users cannot benefit from an accurate predictive model until after extensive interactions with the application. In other words, models developed using this approach do not quickly "provide all the latest information" to new users.

[0056]

[0062] Another high-level approach involves training a model for multiple users and then adapting some or all of the model to a specific user. To achieve this, several different techniques can be employed. One approach involves pre-training a model for many different users and then adapting the entire model to a new user, for example, by adjusting the pre-trained model using a separate training epoch for the new user. In this approach, each user eventually arrives at its own complete user-specific model, but user data for other users can be used to accelerate the training of the model. Alternatively, the model itself may have certain general components, such as one or more neural network layers trained for multiple users, and one or more user-specific components, such as one or more separate layers trained specifically for each user.

[0057]

[0063] One can also employ meta-learning techniques, for example by starting with a set of weights learned from a large group of users and then customizing those weights for a new user. For background information on meta-learning techniques, see Munkhdalai et al., “Rapid Adaptation with Conditionally Shifted Neurons,” in Proceedings of the 35th International Conference on Machine Learning and Machine Learning (IMDM), pp. 1171-1175, 2012. th International Conference on Machine Learning, pp. 1-12, 2018, Munkhdalai et al., “Meta Networks,” in Proceeding of the 34 th International Conference on Machine Learning, pp. 1-23, 2017, Koch et al., “Siamese Neural Networks for One-shot Image Recognition,” in Proceedings of the 32nd International Conference on Machine Learning, Volume 37, pp. 1-8, 2015, Santoro et al., “Meta-Learning with Memory-Augmented Neural Networks,” in Proceedings of the 33 rd International Conference on Machine Learning, Volume 48, pp. 1-9, 2016, Vinyals et al., “Matching Networks for One Shot Learning,” in Proceedings of the 30 th Conference on Neural Information Processing Systems, pp. 1-9, 2016 and Finn et al., “Model-Agnostic Meta-Learning for Fast Adaptation of Deep Networks,” in Proceedings of the 34 th International Conference on Machine Learning, pp. 1-13, 2017. These techniques can help rapidly tailor the disclosed techniques to new users, thus reducing and / or potentially eliminating instances where users are adversely affected by disruptions. Additionally, these techniques can rapidly adapt to changes in user skill and / or application difficulty, for example, by allowing the predictive models to adapt as users become better at playing video games and as the video games become proportionately more difficult.

[0058]

[0064] In further implementations, the model can be trained using auxiliary training tasks. For example, the model can be trained to predict which user generated a given input stream or to predict a given user's skill level from the input stream. A reward function can be defined on these goals, and the model is rewarded for correctly identifying the user who generated the input stream or the user's skill level. By training the model on such auxiliary tasks using input data obtained from multiple users with different characteristics (e.g., skill levels), the model can learn how to distinguish between different users. Then, when a new user begins playing the game, the model trained in this way may have the ability to infer that the new user is similar to one or more other users for which the model has already been trained.

[0059]

[0065] Model training can use a variety of data sources. For example, a given model can be trained offline based on previous instances where one or more users have interacted with the application. In other examples, the model can be trained online as one or more users interact with the application. Actual user inputs received during a given application session can serve as labeled training data for the model. Thus, when a given interactive application is executed and a user interacts with the application, the model can generate predicted user inputs, compare them with the actual user inputs, and propagate the errors to the model to improve the model. In other words, the model can be trained to mimic a user while the user is interacting with the application.

[0060]

[0066] In some cases, after the disruption, actual user input that was intended during the disruption time may be received. For example, packets having actual user input may be communicated with a delay (e.g., after automated user input has been substituted for the actual user input). Although the actual user input during the disruption time may be discarded for purposes of controlling the application, the actual user input during the disruption time may nevertheless be used for training purposes.

[0061]

[0067] In addition, individual parts of a given model can be trained offline and / or separately from the rest of the model. For example, in some implementations, the convolutional neural network 510 of the neural network-based predictive model 500 can be trained using video output even in the absence of user input. For example, the convolutional neural network can be trained using auxiliary training tasks as described above or using reconstruction or masking tasks. The pre-trained convolutional neural network can be inserted into a larger neural network structure along with other layers, and then the entire network structure can be trained together using inputs and outputs obtained while one or more users interact with the application. This allows the untrained components of the neural network to learn more quickly than if the convolutional neural network were trained to learn from scratch along with the rest of the model.

[0062]

[0068] The disclosed concepts can also be used in a wide range of model architectures. In general, the more context a model knows, the more accurate its prediction of user inputs. Thus, for example, using a longer input / output window can generally improve the accuracy of predictions. On the other hand, using a longer input / output window can proportionally increase the amount of input data to the model, which can increase training time and introduce computational latency at run time. Some implementations can employ alternative model structures to allow the model to know more context for the purpose of increasing efficiency. For example, one can employ a stack of dilated causal convolutional layers as discussed in Oord et al., “WaveNet: A Generative Model of Raw Audio,” arXiv:1609.03499 1-15, 2016, and / or a hierarchy of autoregressive models as discussed in Mehri et al., “SampleRNN: An Unconditional End-to-End Neural Audio General Model,” in Proceedings of the 5th International Conference on Learning Representations, pp. 1-11, 2017.

[0063]

[0069] It should also be noted that some implementations may employ input adjudication within the predictive model, rather than as a separate functionality. For example, the predictive model may learn when to use predicted user input instead of actual user input, e.g., using additional features describing network conditions (e.g., latency, bandwidth, packet drops, etc.). Similarly, the predictive model may learn to combine predicted user input with actual user input to reduce the impact of disruptions to the user. For example, the predictive model may train using feedback indicative of perceived user disruptions, and learn to smooth or combine actual and predicted user inputs to minimize or mitigate the perceived disruptions.

[0064] Input Adjudication

[0070] In some implementations, one or more trigger criteria can be used to determine when to employ an automatic user input. For example, returning to FIG. 4, one or more trigger criteria can be used to determine whether the input adjudicator 416 selects actual user input 406 or automatic user input 412. For example, one approach is to define a threshold time (e.g., 100 milliseconds) and select automatic user input whenever no actual user input is received during that threshold amount of time.

[0065]

[0071] Considering the network connection scenario as shown in FIG. 1, a network disruption may prevent the application server 102 from receiving actual user input. A network disruption may occur due to a variety of underlying reasons, such as packets being received too late, out of order, and / or not being received at all due to packets being dropped on the network. One way to handle a network disruption is to substitute automatic user input when no packets are received by the intermediary server 104 from the client device for a threshold time. In some cases, the client may send a heartbeat signal at regular intervals (e.g., 10 ms) to allow the intermediary server to distinguish a network disruption from a scenario where the user is simply not handling the controller 108.

[0066]

[0072] In further implementations, the threshold time can be adjusted for different users and / or different applications. For example, user sensitivity to disruptions may vary based on user skill or by type of application. Considering video games specifically, experienced users may tend to notice shorter disruptions than novice users, or relatedly, players of one video game may tend to notice shorter disruptions (e.g., 50 milliseconds) that players of another video game do not notice.

[0067]

[0073] In other implementations, the threshold is related to the video frame rate, for example, the threshold may be defined as 3 frames or approximately 50 milliseconds at a frame rate of 60 Hz. Further implementations may learn the threshold as part of a user interaction model for different applications and / or different users.

[0068]

[0074] Moreover, it should be noted that the term "network disruption" may encompass scenarios in which traffic is not completely blocked. For example, network "jitter" or variations in time delays of data packets can significantly impact a user's experience with an interactive application. In some cases, automatic user input can be employed when jitter exceeds a predefined threshold (e.g., 50 ms). Jitter can be detected using timestamps associated with actual user input.

[0069]

[0075] It should be noted that a network disruption can be bidirectional (i.e., it can affect both the flow of actual user input to an application and the flow of application output to a user device). However, in other cases, a network disruption only affects the flow of traffic in a particular direction. For example, a network disruption can prevent actual user input from being received without affecting the flow of application output to a user. Conversely, a network disruption can prevent application output from reaching a user without affecting the flow of actual user input to the application.

[0070]

[0076] Automatic user input can be used to address any type of network disruption. For example, consider a scenario in which the actual user input is not affected by the network disruption, but the network disruption causes application output to be unable to reach the user for a threshold amount of time. Even if the actual user input is available for this type of network disruption, in some scenarios it may still be worthwhile to use automatic user input instead of the actual user input received during the disruption. Because the user does not receive the application output during the disruption, the user has no opportunity to adjust that input to change the application output. In this case, the automatic user input may more accurately reflect what the user would have provided if the disruption had not caused the application output to be unable to reach the user.

[0071]

[0077] In some implementations, the input adjudicator 416 can also take corrective action after the disruption ends. For example, the input adjudicator substitutes automatic user input for some previous actual user inputs, and then assumes that those actual user inputs arrived late after the disruption ends. Further, it assumes that the automatic user input steered the car at a steeper angle than indicated by the late actual user input. In some implementations, this can be corrected by adjusting the later received actual user input to steer the car more gently some time after the disruption to compensate for the difference between the automatic user input and the late actual user input. Doing so can move the car closer to where it would have been if there had been no disruption.

[0072] Alternative Implementations

[0078] Above, the present concepts have been described primarily using examples directed to particular types of interactive applications (e.g., streaming video games), particular types of disruptions (e.g., network disruptions), and particular types of automated user input (e.g., predictive controller input generated using machine learning models). However, the present concepts can be employed for many different interactive application types to address many different disruption types using many different types of automated user input, as discussed further below.

[0073]

[0079] Taking application types first, video games are just one example of an interactive application. Other examples include virtual or augmented reality applications, educational or training applications, etc. For example, consider a multi-user driving simulator in which users learn how to drive a vehicle. As with video games, during disruptions in the driving simulator, it may be preferable to predict actual user behavior rather than optimal user behavior. This can provide a more realistic experience (e.g., two drivers both make mistakes that lead to a simulated accident). If a disruption were to occur and a model to generate optimal inputs was used rather than a model to predict realistic user inputs, the crash would be avoided, but it would give the user a false sense of safety, reducing the training value of the simulation.

[0074]

[0080] As another example, consider an automated inventory management application that constantly places orders to replenish merchandise. In some cases, a disruption may prevent the inventory management application from learning about user orders for an extended period of time (e.g., overnight). By using predicted user orders to simulate how inventory changes during the disruption time, such an application can mitigate the impact of the disruption by, for example, ensuring that enough parts are available in the factory so that production can continue based on predicted user orders rather than actual user orders.

[0075]

[0081] As yet another example, consider a semi-autonomous robot, e.g., for disaster relief or medical applications. Typically, such a robot can be controlled by a remotely located user. In some cases, such a robot may operate remotely with spotty satellite signal reception and can utilize local predictive models to take over the role of the remotely located user when a network outage occurs. In some cases, this type of application can benefit from using a model trained for optimal behavior rather than mimicking a particular user.

[0076]

[0082] In addition, disclosed implementations can be employed to address other types of disruptions besides network disruptions. For example, some implementations can detect when a user is distracted from an interactive application, such as by detecting an incoming message or phone call, by using a gyroscope or accelerometer on the client device, or simply by a lack of input to an input mechanism for a threshold amount of time. Any of these disruptions can be mitigated by providing automatic user input to the interactive application during the disruption.

[0077]

[0083] In addition, disclosed implementations can be used to provide an enhanced experience for users who may have physical disabilities. Consider a user who has difficulty holding a joystick or other input mechanism steady. Some implementations can treat tremors or other shaking movements as disruptions and smooth or combine the user's actual input with predicted user input to mitigate the impact of the user's disability on their application experience.

[0078]

[0084] As another example, consider a disruption within a particular device. For example, consider a single physical server running a first virtual machine and a second virtual machine in different time slices. If the first virtual machine is running an interactive application, there may be user input received in a given time slice when the interactive application is not currently active on the processor. Previous techniques may have buffered the actual user input in memory until the context is switched from the second virtual machine to the first virtual machine. Using the disclosed techniques, the actual user input that occurred during the time slice when the first virtual machine is not active can be discarded and automatic user input can be generated and provided to the interactive application once the first virtual machine begins running on the processor. Thus, memory can be saved since no buffer is needed to hold the actual user input during the time slice when the first virtual machine is not active.

[0079]

[0085] As another example, automatic user inputs can be used for compression purposes. For example, in the example shown in FIG. 1, the client device 106 can discard certain user inputs (e.g., skip every other user input and do not send them to the intermediation server 104). The intermediation server can substitute the automatic user inputs for every other actual user input. This approach can conserve network bandwidth while still providing a satisfying user experience.

[0080]

[0086] As another compression example, instead of discarding the actual user input entirely, some implementations can discard a portion of some actual user input, for example by sending a certain number (e.g., 3) of the most significant bits of the actual user input to the intermediary server and having the intermediary server fill in the remaining bits (e.g., 13 bits for a 16-bit input) with the user interaction model 408. Yet another compression example can employ another example of a predictive model on the user device. The user device can calculate the difference between each actual user input and the corresponding predicted input and send the difference to the intermediary server, which can derive the actual user input from the difference since it is running the same predictive model on the intermediary server. Since the difference between the predicted user input and the actual user input is often relatively small, sending this information over the network requires fewer bits than the complete actual user input. The compression techniques described above can be viewed as mechanisms for intentionally introducing pre-programmed disruptions to reduce the amount of network traffic.

[0081]

[0087] In some cases, pre-programmed disruptions can be used to conserve battery life (e.g., on a video game controller). For example, the video game controller can sleep for a specified amount of time (e.g., 50 milliseconds) and then wake up, detecting inputs and sending a new set of controls each time it wakes up. The intermediary server 104 can fill in any gaps between sleep intervals using automatic inputs.

[0082]

[0088] As another example, automatic user input can be used for preemptive scheduling or loading of application code. For example, assume that a given application module is loaded into memory if a user performs a particular action (such as successfully completing an objective in a video game or crashing a car in a driving simulation). Some implementations can predict whether a future input of the user is likely to perform that action. If so, this can be used as a trigger for the interactive application to begin loading that module into memory or schedule execution of that module before receiving the user's actual input. In this case, the automatic user input is not necessarily used to control the application, but rather to selectively perform certain operations in advance, such as loading code or data from storage to memory or informing a scheduling decision by the operating system. In some cases, the user interaction model can maintain a future window (e.g., 500 milliseconds) of predicted user input and use the predicted user input within that window to selectively load and / or schedule application code.

[0083]

[0089] Moreover, the disclosed implementations can be employed in scenarios other than the client / server scenario as described above. For example, a peer-to-peer game may involve communication between two peer devices. When communication between the peer devices is disrupted (e.g., when the devices are temporarily out of range in the case of a short-range wireless connection such as Bluetooth), automatic user input can be employed to provide a satisfying user experience. Thus, in this example, the trigger criteria for selecting automatic user input rather than actual user input may be related to characteristics of the short-range wireless connection such as signal strength or throughput. Note also that this allows both users to perceive predicted versions of each other during times of disruption in the peer-to-peer game. This approach can improve the experience of users other than the user whose input is predicted, e.g., disruption is mitigated from the perspective of a second user viewing a representation of the first user in a peer-to-peer game when predicted user input for the first user is substituted during the disruption.

[0084]

[0090] The disclosed implementations may also be employed on a single device. For example, a user interaction model may be provided on a game console or other device. An input adjudicator may be provided on the device to select whether an interactive application receives actual user input or automatic user input. For example, in some implementations, the input adjudicator may use criteria such as disk throughput, memory usage, or processor usage to recognize instances where there may be delays in user input to the interactive application and provide automatic user input to the interactive application in those instances.

[0085]

[0091] Also, as described, some implementations may use machine learning user interaction models, while other implementations may utilize other types of user interaction models. For example, in a driving game, the user interaction model may provide pre-computed directional or throttle inputs for each location along the driving course, where the pre-computed inputs are static and not user specific. These pre-computed inputs may be used in place of actual user inputs during disruptions. Similar to the use of predictive models, the user's previous inputs may be smoothed or combined at run time with pre-defined user inputs for a given location on the course.

[0086]

[0092] In addition, some implementations can predict not only user inputs but also application outputs. Recall, for example, that network disruptions are not always bidirectional. It was previously described that automatic user input substitutions can be used to mitigate network disruptions that prevent a user from receiving application output. Alternatively, some implementations can predict application output and provide the user with the predicted application output during the disruption. In this circumstance, actual user inputs can be used because those inputs are provided to the user in response to the predicted application output, rather than in response to a "frozen" application output during the disruption.

[0087] Example System

[0093] The present concepts can be implemented in a variety of technology environments and on a variety of devices. Figure 6 illustrates an example of a system 600 in which the present concepts can be employed, as discussed further below. As illustrated in Figure 6, the system 600 includes the application server 102, the intermediary server 104, the client device 106, and the video game controller 108, which were introduced above with respect to Figure 1. The system 600 also includes the client device 610. The client device 106 is connected to the video game controller 108 via a local wireless link 606. Both the client device 106 and the client device 610 are connected to the intermediary server 104 via a wide area network 620. The intermediary server 104 is connected to the application server 102 via a local area network 630.

[0088]

[0094] Certain components of the client devices and servers shown in Figure 6 may be referred to herein with reference numbers in parentheses. For purposes of the following description, a reference number in parentheses (1) indicates the presence of a given component on client device 106, (2) indicates the presence of a given component on client device 610, (3) indicates the presence on intermediary server 104, and (4) indicates the presence on application server 102. Unless a specific example of a given component is identified, this specification will generally refer to the components without the parentheses.

[0089]

[0095] 6 may have respective processing resources 612 and storage resources 614, which are discussed in further detail below. The devices may also have various modules that function to perform the techniques discussed herein using the processing and storage resources, as discussed further below.

[0090]

[0096] The video game controller 108 may include controller circuitry 602 and a communication component 604. The controller circuitry may digitize inputs received by various controller mechanisms, such as buttons or analog input mechanisms. The communication component may communicate the digitized inputs over a local wireless link 606 to the client device 106. An interface module 616 on the client device 106 may obtain the digitized inputs and transmit them over a wide area network 620 to the intermediation server 104.

[0091]

[0097] The client device 610 can provide a controller emulator 622. The controller emulator can display a virtual controller on a touch screen of the client device. Input received through the virtual controller can be transmitted over a wide area network to the intermediation server 104.

[0092]

[0098] The intermediary server 104 can receive packets with actual controller inputs from the client device 106 or the client device 610 over the wide area network 620. An input adjudicator 416 on the intermediary server can determine whether to send those actual controller inputs to the application server 102 over the local area network 630 or to send automated user inputs generated through the user interaction model 408. For example, the input adjudicator can substitute automated user inputs for the actual user inputs during a network disruption and discontinue the substitution when the network disruption is resolved by providing the later received actual user inputs to the application server.

[0093]

[0099] The interactive application 642 can process the received real or automated user input and generate a corresponding application output. The interactive application can send output over the local area network 630 to the intermediation server 104, which can use the output to generate further automated user input. In addition, the intermediation server can forward the output to the client device 106 or the client device 610 over the wide area network 620.

[0094]

[0100] Client device 106 and / or client device 610 can display video output and play audio output. If the application output includes haptic feedback, client device 106 can send haptic signals over local wireless link 606 to video game controller 108, which can generate haptic output based on the received signals. If the output provided to client device 610 includes haptic signals, client device 610 can generate the haptic output on the client device itself through controller emulator 622.

[0095] Example of how to

[0101] 7 illustrates an example of a method 700 that can be used to selectively provide actual or automatic user input to an application consistent with the present concepts. As discussed elsewhere herein, method 700 can be implemented on many different types of devices, for example, by one or more cloud servers, by a client device such as a laptop, tablet or smartphone, or by a combination of one or more servers, client devices, etc.

[0096]

[0102] Method 700 begins at block 702, where actual user input is received. For example, the actual user input may be received via a client device, via a dedicated controller such as a video game or virtual reality controller, or by any other suitable mechanism for providing user input to an application.

[0097]

[0103] The method 700 proceeds to block 704 where application output is received. As described, the application output may include video, audio, and / or haptic feedback generated by the interactive application.

[0098]

[0104] The method 700 proceeds to block 706 where automatic user input is generated. For example, the automatic user input may be generated by a user interaction model as the user interacts with the application. Alternatively, the automatic user input may be generated in advance of user interaction, for example, by pre-computing the automatic user input.

[0099]

[0105] The method 700 proceeds to decision block 708 where a determination is made whether a disruption has occurred. As will be described, disruptions may include network disruptions, incoming phone calls, periods of user inactivity, pre-programmed disruptions, etc.

[0100]

[0106] If no disruption is detected at block 708, the method 700 proceeds to block 710 where the actual user input is provided to the application. The method 700 returns to block 702 where another iteration of the method may be performed.

[0101]

[0107] If a disruption is detected at block 708, the method 700 proceeds to block 712 where automated user input is provided to the application. The method 700 returns to block 704 where additional application output is received. The method 700 proceeds to block 706 where additional automated user input is generated, e.g., using actual user input received before the disruption, application output received before or during the disruption, and / or automated user input generated before or during the disruption. The method 700 may repeat through blocks 704, 706, 708, 712 until the disruption is over.

[0102]

[0108] Note that in some implementations, block 706 may be performed by a user interaction model running in the background during normal operation of the interactive application, while in other implementations the user interaction model is not active during normal operation and may be activated during a disruption.

[0103]

[0109] Also recall that some disruptions may affect both actual user input and application output, while other disruptions may affect only application output or actual user input, but not both. The above description of method 700 addresses disruptions that affect actual user input, but not application output. However, as previously described, automatic user input may also be provided to an application during other types of disruptions.

[0104] Device implementation

[0110] 6, system 600 includes several devices, including client device 106, client device 610, intermediation server 104, and application server 102. Also as described, not all device implementations are shown, and other device implementations should be apparent to one of ordinary skill in the art from the above and below description.

[0105]

[0111] The terms "device," "computer," "computing device," "client device," and / or "server device," as used herein, may refer to any type of device having some hardware processing capability and / or hardware storage / memory capability. Processing capability may be provided by one or more hardware processors (e.g., hardware processing units / cores) capable of executing computer-readable instructions to provide functionality. Computer-readable instructions and / or data may be stored in storage resources. The term "system," as used herein, may refer to a single device, multiple devices, etc.

[0106]

[0112] Storage resources may be internal or external to the respective devices with which they are associated. Storage resources may include any one or more of volatile or non-volatile memory, hard drives, flash storage devices, and / or optical storage devices (e.g., CDs, DVDs, etc.), among others. In some instances, modules of system 600 are provided as executable instructions that are stored in persistent storage devices, loaded into random access memory devices, and read from the random access memory by processing resources for execution.

[0107]

[0113] As used herein, the term "computer-readable medium" may include signals. In contrast, the term "computer-readable storage medium" excludes signals. Computer-readable storage medium includes "computer-readable storage devices." Examples of computer-readable storage devices include volatile storage media such as RAM and non-volatile storage media such as hard drives, optical disks, and flash memory, among others.

[0108]

[0114] In some cases, the device is configured to have a general-purpose hardware processor and storage resources. In other cases, the device may include a system-on-chip (SOC) type design. In a SOC design implementation, the functionality provided by the device may be integrated on a single SOC or multiple combined SOCs. One or more associated processors may be configured to cooperate with shared resources (such as memory, storage, etc.) and / or one or more dedicated resources (such as hardware blocks configured to perform a particular functionality). Thus, the terms "processor", "hardware processor", or "hardware processing unit", as used herein, may refer to a central processing unit (CPU), a graphics processing unit (GPU), a controller, a microcontroller, a processor core, or other types of processing devices suitable for implementation in both traditional computing architectures and SOC designs.

[0109]

[0115] Alternatively or additionally, the functionality described herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), programmable complex logic devices (CPLDs), etc.

[0110]

[0116] In some configurations, any of the modules / codes discussed herein may be implemented in software, hardware, and / or firmware. In any case, the modules / codes may be provided during manufacture of the device or by an intermediary who prepares the device for sale to an end user. In other examples, the end user may install these modules / codes later, such as by downloading executable code and installing the executable code on the corresponding device.

[0111]

[0117] It should also be noted that devices may generally have input and / or output functionality. For example, a computing device may have a variety of input mechanisms, such as a keyboard, a mouse, a touchpad, voice recognition, gesture recognition (e.g., using depth cameras such as stereo or time-of-flight camera systems, infrared camera systems, RGB camera systems, or using accelerometers / gyroscopes, facial recognition, etc.) A device may also have a variety of output mechanisms, such as a printer, a monitor, etc.

[0112]

[0118] It should also be noted that the devices described herein can function stand-alone or in conjunction to perform the techniques described. For example, the methods and functionality described herein can be performed on a single computing device and / or distributed across multiple computing devices communicating over networks 620 and / or 630.

[0113]

[0119] In addition, some implementations can employ any of the disclosed techniques in the context of the Internet of Things (IoT). In such implementations, a consumer electronics product or an automobile can provide the computing resources to implement the modules of system 600. Also, as mentioned, some implementations can be used for virtual or augmented reality applications by performing some or all of the disclosed functionality on a head mounted display, a handheld virtual reality controller, or by using techniques such as depth sensors to obtain user input through physical gestures performed by the user.

[0114]

[0120] Various device examples are described above. Additional examples are described below. One example includes a method performed by a computing device, the method including generating automatic user input for an interactive application, detecting a disruption to the interactive application during a user's interaction with the interactive application, and providing the automatic user input to the interactive application in response to detecting the disruption.

[0115]

[0121] Further examples may include any of the above and / or below examples, where the method further includes generating a user interaction model of a user interaction with the interactive application, and generating the automated user input with the user interaction model.

[0116]

[0122] Further examples may include any of the examples above and / or below, where the user interaction model may be a user-specific model for a user.

[0117]

[0123] Further examples may include any of the examples above and / or below, where the user interaction model may be an application-specific model for an interactive application.

[0118]

[0124] Further examples may include any of the above and / or below examples, where the method further includes obtaining actual user input before the disruption, obtaining output of the interactive application before the disruption, and inputting the actual user input and output into the user interaction model.

[0119]

[0125] Further examples may include any of the above and / or below examples, where the user interaction model includes a machine learning model.

[0120]

[0126] Another example may include any of the above and / or below examples, where the method further includes training the machine learning model using discarded actual user input, where the discarded actual user input is provided by a user during the disruption and received after the disruption ends.

[0121]

[0127] Other examples may include any of the above and / or below examples, where the method is performed without providing an internal application state of the interactive application to the user interaction model.

[0122]

[0128] Further examples may include any of the examples above and / or below, where the interactive application includes an online application.

[0123]

[0129] Further examples may include any of the above and / or below examples, where the disruption includes a network disruption.

[0124]

[0130] Further examples may include any of the above and / or below examples, where the method further includes detecting a network disruption when a packet having actual user input has not been received for a threshold time.

[0125]

[0131] Further examples may include any of the examples above and / or below, where the online application includes streaming video games.

[0126]

[0132] Further examples may include any of the examples above and / or below, where the automated user input includes predictive controller input for a video game controller.

[0127]

[0133] Other examples may include any of the examples above and / or below, where predictive controller input is used in place of actual user input provided by an analog input mechanism on a video game controller.

[0128]

[0134] Another example includes a system including a hardware processing unit and a storage resource storing computer-readable instructions that, when executed by the hardware processing unit, cause the hardware processing unit to detect a network disruption affecting receipt of one or more actual user inputs by a streaming interactive application, generate automatic user inputs using previously received actual user inputs to the streaming interactive application, and, in response to detecting the network disruption, substitute the automatic user input for the one or more actual user inputs to the streaming interactive application.

[0129]

[0135] Another example may include any of the above and / or below examples, where the computer readable instructions, when executed by the hardware processing unit, cause the hardware processing unit to forward received actual user input to a computing device running a streaming interactive application in the absence of a network disruption, and to forward automatic user input to the computing device running the streaming interactive application during a network disruption.

[0130]

[0136] Further examples may include any of the above and / or below examples, where the computer readable instructions, when executed by a hardware processing unit, cause the hardware processing unit to generate automated user input using output of a streaming interactive application.

[0131]

[0137] Another example may include any of the above and / or below examples, where the computer readable instructions, when executed by the hardware processing unit, cause the hardware processing unit to detect that the network disruption has been resolved and that further actual user input has been received, and in response to detecting that the network disruption has been resolved, cease substituting the automatic user input for the further actual user input.

[0132]

[0138] Another example includes a computer-readable storage medium storing computer-readable instructions that, when executed by a hardware processing unit, cause the hardware processing unit to perform operations including receiving a visual output of an interactive application; receiving an actual user input to the interactive application provided by a user; detecting a disruption affecting receipt of further actual user input by the interactive application; providing the visual output of the interactive application and the actual user input to a predictive model; obtaining predicted user input from the predictive model; and providing the predicted user input to the interactive application during the disruption.

[0133]

[0139] Further examples may include any of the examples above and / or below, where the operation further includes detecting that the disruption has ended and, in response to detecting that the disruption has ended, providing the subsequently received actual user input to the interactive application.

[0134] conclusion

[0140] Although the subject matter has been described in language specific to structural features and / or method operations, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or operations described above. Rather, the specific features and operations described above are disclosed as example forms of implementing the claims, and other features and operations that will be recognized by those skilled in the art are intended to be within the scope of the claims.

Claims

1. A hardware processing unit; a storage resource for storing computer readable instructions; 11. A system for mediating data between a streaming interactive application and a client device, comprising: detecting a network disruption affecting receipt of one or more actual user inputs transmitted from the client device to the streaming interactive application; obtaining application output including at least one of video, audio, or haptic output streamed to the client device by the streaming interactive application; inputting previous actual user input from the client device to the streaming interactive application and the application output into a user interaction model to generate automated user input, the user interaction model being the same as that on the client device, processing the application output to obtain application output embeddings, and mapping the application output embeddings to automated user inputs; in response to detecting the network disruption, substituting the one or more actual user inputs to the streaming interactive application. The system further comprises:

2. The computer readable instructions, when executed by the hardware processing unit, forwarding actual user input received from the client device to a computing device running the streaming interactive application in the absence of the network disruption; and transferring the automated user input to the computing device running the streaming interactive application during the network disruption; and The system of claim 1 , further comprising:

3. The system of claim 1 , wherein the application output embedding represents a video output by the streaming interactive application.

4. The computer readable instructions, when executed by the hardware processing unit, detecting that the network outage has been resolved and that further actual user input has been received; in response to detecting that the network disruption has been resolved, ceasing to substitute the automated user input for the further actual user input; The system of claim 1 , further comprising:

5. The system of claim 1 , wherein the application output embedding represents an audio output by the streaming interactive application.

6. The system of claim 1 , wherein the automated user input comprises predictive controller input for a video game controller.

7. The system of claim 1 , wherein the application output embedding represents a haptic output by the streaming interactive application.

8. The computer readable instructions, when executed by the hardware processing unit, generating said user interaction model; The system of claim 1 , further comprising:

9. The system of claim 1 , wherein the user interaction model is a user-specific model.

10. The system of claim 9 , wherein the user interaction model is an application-specific model for the streaming interactive application.

11. The system of claim 1 , wherein inputting the application output to the user interaction model comprises extracting features from an output window of the application output and providing the features to the user interaction model.

12. the user interaction model is a machine learning model, and the computer readable instructions, when executed by the hardware processing unit, training the machine learning model using discarded actual user input, the discarded actual user input being provided by a user during the network disruption and received after the network disruption ends; The system of claim 1 , further comprising:

13. 1. A computer-readable storage medium storing computer-readable instructions that, when executed by a hardware processing unit of a system for mediating data between a streaming interactive application and a client device, detecting a network disruption affecting receipt of one or more actual user inputs transmitted from the client device to the streaming interactive application; obtaining application output including at least one of video, audio, or haptic output streamed to the client device by the streaming interactive application; inputting previous actual user input from the client device to the streaming interactive application and the application output into a user interaction model to generate automated user input, the user interaction model being the same as that on the client device, processing the application output to obtain application output embeddings, and mapping the application output embeddings to automated user inputs; in response to detecting the network disruption, substituting the one or more actual user inputs to the streaming interactive application.

23. A computer-readable storage medium for causing the hardware processing unit to perform operations including:

14. The operation, detecting that the network disruption has ended; and in response to detecting that the network disruption has ended, providing subsequently received actual user input to the streaming interactive application; The computer-readable storage medium of claim 13 , further comprising:

15. The operation, smoothing said subsequently received actual user input in conjunction with said automatic user input. The computer-readable storage medium of claim 14 , further comprising:

16. 1. A method performed by a computing device that mediates data between a streaming interactive application and a client device, comprising: detecting a network disruption affecting receipt of one or more actual user inputs transmitted from the client device to the streaming interactive application; obtaining application output including at least one of video, audio, or haptic output streamed to the client device by the streaming interactive application; inputting previous actual user input from the client device to the streaming interactive application and the application output into a user interaction model to generate automated user input, the user interaction model being the same as that on the client device, processing the application output to obtain application output embeddings, and mapping the application output embeddings to automated user inputs; in response to detecting the network disruption, substituting the one or more actual user inputs to the streaming interactive application. The method includes:

Images