Patent Description:
The present disclosure generally relates to system and method dynamically predicting a shot type in sport using a personalized neural network.

Although often viewed as a niche and somewhat impenetrable sport, cricket is more accessible and global than first glance. Since the sport's first international match in <NUM>, the sport of cricket has grown into one of the most popular and lucrative in the world, with over <NUM> member nations and huge television audiences. For example, the <NUM> World Cup between India and Pakistan saw in excess of <NUM> million unique viewers. Non-patent publication to <NPL>) relates to a framework for predicting shot location and type in tennis. It incorporates neural memory modules to model the episodic and semantic memory components of a tennis player. It proposes a Semi Supervised Generative Adversarial Network architecture that couples these memory models with the automatic feature learning power of deep neural networks and demonstrate methodologies for learning player level behavioural patterns with the proposed framework.

In some embodiments, a method for predicting a shot type is disclosed herein as defined in appended claim <NUM>.

A system for predicting a shot type is disclosed herein as defined in appended claim <NUM>.

In some embodiments, a non-transitory computer readable medium is disclosed herein as defined in appended claim <NUM>.

It is to be noted, however, that the appended drawings illustrated only typical embodiments of this disclosure and are therefore not to be considered limiting of its scope, for the disclosure may admit to other equally effective embodiments, according to the appended claims.

The ability to predict what shot a batsman will attempt given the type of ball and match situation is both one of the most challenging and strategically important tasks in cricket. The goal of each batsman is to score as many runs as possible without being dismissed. Batsmen can be dismissed in several ways, including being caught by fielders or having their wickets knocked over. While simple in principle, the type of shots and style of a batsman is greatly influenced by the format of the game. Accordingly, getting the right batsman/bowler match-up is of paramount importance. For example, for the fielding team, the choice of bowler against the opposition star batsman could be the key difference between winning or losing. Therefore, the ability to have a predefined playbook, which would allow a team to predict how best to set their fielders given the context of the game, the batsman they are bowling to, and bowlers at their disposal would give them a significant strategic advantage.

In cricket, there has not been any previous work on personalizing predictions on shot locations or shot types. Previous analyses have concentrated on scorecard level data for performance analysis, such as the rating of batsman performance in Test match and One Day forms of the game. Other analyses have looked to simulate match scores or predict optimal run scoring strategies, none of which utilize the spatial or shot type data to aid in team strategies.

One of more techniques disclosed herein provide a system and method to predict the probabilities of where a specific batsman will hit a specific bowler and bowl type in a specific game-scenario. For example, the one or more techniques described herein may utilize a personalized deep neural network approach to generating such dynamic predictions. The prediction output will provide cricket teams, for the very first time, with dynamic analyses that may be implemented both prior to a match and during match play.

Although the below discussion is directed to the sport of cricket, those skilled in the art recognize that the operations and techniques may be applied to other sports as well (e.g., baseball, basketball, football, hockey, soccer, etc.).

<FIG> is a block diagram illustrating a computing environment <NUM>, according to example embodiments. Computing environment <NUM> may include tracking system <NUM>, organization computing system <NUM>, and one or more client devices <NUM> communicating via network <NUM>.

Network <NUM> may be of any suitable type, including individual connections via the Internet, such as cellular or Wi-Fi networks. In some embodiments, network <NUM> may connect terminals, services, and mobile devices using direct connections, such as radio frequency identification (RFID), near-field communication (NFC), Bluetooth™, low-energy Bluetooth™ (BLE), Wi-Fi™, ZigBee™, ambient backscatter communication (ABC) protocols, USB, WAN, or LAN. Because the information transmitted may be personal or confidential, security concerns may dictate one or more of these types of connection be encrypted or otherwise secured. In some embodiments, however, the information being transmitted may be less personal, and therefore, the network connections may be selected for convenience over security.

Network <NUM> may include any type of computer networking arrangement used to exchange data or information. For example, network <NUM> may be the Internet, a private data network, virtual private network using a public network and/or other suitable connection(s) that enables components in computing environment <NUM> to send and receive information between the components of environment <NUM>.

Tracking system <NUM> may be positioned in a venue <NUM>. For example, venue <NUM> may be configured to host a sporting event that includes one or more agents <NUM>. Tracking system <NUM> may be configured to capture the motions of all agents (i.e., players) on the playing surface, as well as one or more other objects of relevance (e.g., ball, referees, etc.). Tracking system <NUM> is an optically-based system using, for example, a plurality of fixed cameras. For example, a system of six stationary, calibrated cameras, which project the three-dimensional locations of players and the ball onto a two-dimensional overhead view of the court may be used. In another example, a mix of stationary and non-stationary cameras may be used to capture motions of all agents on the playing surface as well as one or more objects or relevance. As those skilled in the art recognize, utilization of such tracking system (e.g., tracking system <NUM>) may result in many different camera views of the court (e.g., high sideline view, free-throw line view, huddle view, face-off view, end zone view, etc.). In some embodiments, tracking system <NUM> may be used for a broadcast feed of a given match.

Game file <NUM> may be representative of data associated with a particular match. For example, game file <NUM> may include information such as the capture motions of all agents, as well as one or more other objects of relevance. In some embodiments, game file <NUM> may further include ball-by-ball information. In some embodiments, game file <NUM> may further include game event information (pass, made shot, turnover, hit, out, etc.) and context information (current score of team and batsman, balls and wickets remaining, balls faced by the batsman, innings, etc.). In some embodiments, game file <NUM> may further include ball-by-ball data for each shot in a cricket match. Such ball-by-ball data include a raw shot data label for each shot. Such data labels include no shot, forward defensive, backward defensive, fended, leave, padded, shoulders arms, worked, pushed, steer, dropped, drive, sweep, cut, slog-sweep, hook, upper cut, pull, glance, reverse sweep, flick, late cut, slog, scoop, and switch hit. In some embodiments, ball-by-ball data may further include line and length (i.e., where the ball lands on the pitch), movement of the ball both through the air and off the pitch (e.g., swing through the air or spin direction after bouncing), handedness of the bowler, style of the bowler (e.g., spin vs. speed), angle from which the bowler delivers the ball relative to the wickets at the bowlers' end (e.g., over the wicket or around the wicket), the batsman, and the like.

Tracking system <NUM> may be configured to communicate with organization computing system <NUM> via network <NUM>. Organization computing system <NUM> may be configured to manage and analyze the broadcast feed captured by tracking system <NUM>. Organization computing system <NUM> may include at least a web client application server <NUM>, a pre-processing engine <NUM>, a data store <NUM>, and a prediction engine <NUM>.

Each of pre-processing engine <NUM> and prediction engine <NUM> may be comprised of one or more software modules. The one or more software modules may be collections of code or instructions stored on a media (e.g., memory of organization computing system <NUM>) that represent a series of machine instructions (e.g., program code) that implements one or more algorithmic steps. Such machine instructions may be the actual computer code the processor of organization computing system <NUM> interprets to implement the instructions or, alternatively, may be a higher level of coding of the instructions that is interpreted to obtain the actual computer code. The one or more software modules may also include one or more hardware components. One or more aspects of an example algorithm may be performed by the hardware components (e.g., circuitry) itself, rather as a result of the instructions.

Data store <NUM> may be configured to store one or more game files <NUM>. Each game file <NUM> may include at least the play-by-play or ball-by-ball data for a given match. In some embodiments, each game file <NUM> may further include video data (e.g., broadcast data) of a given match. For example, the video data may be representative of a plurality of video frames captured by tracking system <NUM>. In another example, the video data may be representative of a plurality of video frames from a broadcast video feed of the respective match.

Pre-processing engine <NUM> may be configured to process data retrieved from data store <NUM> and/or tracking system <NUM>. For example, pre-processing engine <NUM> may be configured to supplement the ball-by-ball data received from data store <NUM> and/or tracking system <NUM>. In some embodiments, pre-processing engine <NUM> may be configured to assign labels to each shot in the ball-by-ball data based on the aggression of the shot. A shot aggression may be defined as the power or number of runs a batsman attempts to score on a given shot. The aggression of the shot may be dictated by the raw shot data label in the ball-by-ball data. For example, pre-processing engine <NUM> may assign a shot a label of <NUM>, <NUM>, or <NUM>, from least aggressive to most aggressive, for each shot type. In some embodiments a label of <NUM> may be assigned to no shot, forward defensive, backward defensive, fended, leave, padded, and shoulder arms shot data labels. In some embodiments, a label of <NUM> may be assigned to worked, pushed, steer, and dropped shot types. In some embodiments, a label of <NUM> may be assigned to drive, sweep, cut, slog-sweep, hook, upper cut, pull, glance, reverse sweep, flick, late cut, slog, scoop, and switch hit shot types.

Pre-preprocessing engine <NUM> may combine the aggression labels with the shot angle to create bespoke target variables based on splitting the field into one or more zones. For example, pre-processing engine <NUM> may split the field into <NUM> zones that follow standard cricketing nomenclature. Such zones may include, for example, third man, fine leg, square leg, mid wicket, mid on, mid off, extra cover, cover, and point. In some embodiments, pre-processing engine <NUM> may define a <NUM>th zone - defensive zone - for when the ball is not hit with any aggression (i.e., shots with aggression label <NUM>). This may result in <NUM> target variables. The zones referenced above may be used to effectively measure intent and shot angle rather than where the ball is and fielded. This may provide, for example, a clearer description on where the batsman is attempting to hit the ball and is therefore a more accurate guide for fielder placement and bowling (i.e., pitch) tactics.

<FIG> is a block diagram illustrating a spatial map 200a of bespoke target variables generated by pre-processing engine <NUM>, according to example embodiments. <FIG> is a block diagram illustrating a spatial map 200b of bespoke target variables generated by pre-processing engine <NUM>, according to example embodiments. Spatial map 200a may be representative of the field upon which cricket is played from the perspective of a right-handed batsman. Spatial map 200b may be representative of the field upon which cricket is played from the perspective of a left-handed batsman. As shown in spatial maps 200a, 200b, the field may be split into <NUM> zones labeled <NUM>-<NUM>. The zones that are dashed may correspond to zones that are associated with Aggression <NUM> label. The zones that are hashed may correspond to zones that are associated with Aggression <NUM> label. The zones that are checkered may correspond to zones that are associated with Aggression <NUM> and <NUM> labels. For example, the zones that are associated with Aggression <NUM> and <NUM> labels may correspond to the third man and fine leg zones near the top of the field. This is because the direction of the delivery by the bowler is already towards these zones, so shots played up the batsman usually aim to deflect the ball and take advantage of its natural velocity. As a result, such shots may usually reach the boundary in this direction if no fielders are positioned to intercept it.

Referring to <FIG>, pre-processing engine <NUM> may supplement the ball-by-ball information with ball-by-ball match context features. For example, another key factor in determining the likely shot type is the current match situation. If, for example, a batsman has faced few deliveries in the match, then safe shot types are often preferred options until the batsman gets acquainted to the speed the ball bounces from the pitch and atmospheric conditions which can influence ball movement through the air. Similarly, on the other end of the scale, after a batsman has established themselves by facing many delivers, then aggressive shot intent is more likely. All these decisions, of course, may also depend on the period of the team's innings, the number of wickets the team has left, and current field placement restrictions. Accordingly, the ball-by-ball match context features may include information that captures such variables. For example, the ball-by-ball match context features may include, but is not limited to, team information (e.g., stage of the innings, wickets taken by the bowling team, runs scored by the batting team, etc.) and batsman specific information (e.g., their current runs scored, deliveries faced, etc.). These match features may add context to the delivery trajectory information to provide a more detailed description of factors that may influence the batsman's choice of shot type.

In some embodiments, pre-processing engine <NUM> may be configured to generate personalized embeddings. For example, the ball-by-ball information and ball-by-ball match context features may provide context for the batsman the make their shot decision. However, the final shot type ultimately depends on the batsman themselves and their personal preferences and ability. Generally, shot types may be broken down into multiple levels - some players will prefer to work the ball around the field to steadily accumulate runs (<NUM>, <NUM> run shots) throughout their innings while others will look for big shots (<NUM>, <NUM> run shots) to score more quickly. In addition, different batsmen may prefer to target certain areas of the field. For example, some batsmen are stronger hitting straight, while others prefer hitting at <NUM>-degree angles. For this reason, pre-processing engine <NUM> may be configured to generate personalized embeddings based on both the batsman and the bowler. Personalized batsman features may include, for example, measures of ability and aggression for various delivery trajectories, as well as general information regarding the batsman's favored hitting directions. Personalized bowler features may include, for example, the average number of runs scored, proportion of dot balls (<NUM> runs) and boundaries (<NUM>, <NUM> runs) for different delivery trajectories.

To generate the personalized embeddings, pre-processing engine <NUM> may identify the previous deliveries that each player has faced. For example, to ensure the personalized embeddings are dynamic and account for changes in player ability and preferences over time, pre-processing engine <NUM> may identify the previous <NUM> deliveries that each batsman has faced in data store <NUM>. This may allow for organization computing system <NUM> to generate predictions based on the most relevant and up-to-date information possible. In some embodiments, a player may have faced less than <NUM> deliveries. In such embodiments, pre-processing engine <NUM> may use a linearly weighted average between the player's value and the global average value for that feature, based on how many deliveries the player has participated in. For example, a player with only <NUM> deliveries before a given match would see their personal historic data contribute about <NUM>% to their features, with the global average contributing about <NUM>%.

In some embodiments, batsman embeddings may include various calculations from the point-of-view of the batsman, such as, but not limited to, one or more of features representing the historical proportion of shots directed into the off-side (e.g., point, cover, extra cover), legside (e.g., square leg, mid wicket), straight (e.g., mid on, mid off), behind square (e.g., third man, fine leg) and defended zones, features representing their historical mean aggression value, features representing their historical scoring rate, features representing the historical proportion of shots where they score zero runs to different length deliveries, features representing the historical proportion of shots where they hit a boundary to different length deliveries, features representing the historical proportion of shots where they score zero runs to different line deliveries, and features representing the historical proportion of shots where they hit a boundary to different line deliveries.

In some embodiments, bowler embeddings may include various calculations from the point-of-view of the bowler, such as, but not limited to, one or more of features representing the historical proportion of shots directed into the off-side (e.g., point, cover, extra cover), legside (e.g., square leg, mid wicket), straight (e.g., mid on, mid off), behind square (e.g., third man, fine leg) and defended zones, features representing the historical mean aggression value of batsman when facing the bowler, features representing the historical scoring rate the bowler concedes off their deliveries (e.g., strike-rate), features representing the historical scoring rate the bowler concedes off their deliveries to different length deliveries, features representing the historical proportion of shots where they concede zero runs to different length deliveries, features representing the historical proportion of shots where they concede a boundary to different length deliveries, features representing the historical scoring rate the bowler concedes off their deliveries to different line deliveries, features representing the historical proportion of shots where they concede zero runs to different line deliveries, features representing the historical proportion of shots where they concede a boundary to different line deliveries.

Prediction engine <NUM> may be configured to predict a shot type based on at least the ball-by-ball data. For example, given the ball-by-ball delivery information supplemented with the ball-by-ball match context features, as well as the personalized embeddings, prediction engine <NUM> may be configured to predict a shot type for pitch delivered from the bowler to the batsman. Prediction engine <NUM> is discussed in further detail below, in conjunction with <FIG>.

Client device <NUM> may be in communication with organization computing system <NUM> via network <NUM>. Client device <NUM> may be operated by a user. For example, client device <NUM> may be a mobile device, a tablet, a desktop computer, or any computing system having the capabilities described herein. Users may include, but are not limited to, individuals such as, for example, subscribers, clients, prospective clients, or customers of an entity associated with organization computing system <NUM>, such as individuals who have obtained, will obtain, or may obtain a product, service, or consultation from an entity associated with organization computing system <NUM>.

Client device <NUM> may include at least application <NUM>. Application <NUM> may be representative of a web browser that allows access to a website or a stand-alone application. Client device <NUM> may access application <NUM> to access one or more functionalities of organization computing system <NUM>. Client device <NUM> may communicate over network <NUM> to request a webpage, for example, from web client application server <NUM> of organization computing system <NUM>. For example, client device <NUM> may be configured to execute application <NUM> to access content managed by web client application server <NUM>. The content that is displayed to client device <NUM> may be transmitted from web client application server <NUM> to client device <NUM>, and subsequently processed by application <NUM> for display through a graphical user interface (GUI) of client device <NUM>.

<FIG> is a block diagram illustrating neural network architecture <NUM> of prediction engine <NUM>, according to example embodiments. Neural network architecture <NUM> includes a multi-layered long short-term memory (LSTM) recurrent neural network (hereinafter LSTM <NUM>) and a multi-layered feed forward neural network <NUM> (hereinafter "neural network <NUM>"). As illustrated, LSTM <NUM> includes layer <NUM> and layer <NUM>. In some embodiments, each of layers <NUM>, <NUM> may include <NUM> nodes. In operation, LSTM <NUM> is configured to receive, as input, ball-by-ball delivery information supplemented with the ball-by-ball match context features (represented by "<NUM>"). Accordingly, LSTM <NUM> may be trained using the ball-by-ball delivery information and the ball-by-ball match context features. In some embodiments, layer <NUM> may be configured to output a hidden state representation of the same size as the input layer. A dropout layer may then clear a proportion (e.g., p=<NUM>) of this data at random. In some embodiments, layer <NUM> may be configured to output a single vector for each feature containing information about the whole sequences (e.g., <NUM> balls).

LSTM <NUM> may be configured to learn various relationships between the shot type and the various ball-by-ball delivery information and the ball-by-ball match context features to determine how the delivery information and match context features affects the shot type. As output <NUM>, LSTM <NUM> may generate a flattened version of the ball-by-ball delivery information supplemented with the ball-by-ball match context features.

Neural network <NUM> may include two fully-connected layers <NUM>, <NUM>. In some embodiment, layer <NUM> may include <NUM> nodes with ReLu activation. In some embodiments, layer <NUM> may include <NUM> nodes with ReLu activation. In operation, LSTM <NUM> may be configured to receive, as input, the flattened output from LSTM <NUM> concatenated with the personalized embeddings <NUM> generated by pre-processing engine <NUM> (collectively, concatenated data <NUM>). Given the output <NUM> from LSTM <NUM> and the personalized embeddings, neural network <NUM> generates an output <NUM> that identifies in which zone the shot is predicted to fall.

In some embodiments, LSTM <NUM> and neural network <NUM> may be trained simultaneously. In some embodiments, the parameters for LSTM <NUM> and neural network <NUM> are selected using backpropagation to learn (<NUM>) the optimal weights for LSTM <NUM>; and (<NUM>) the optimal way to combine the ball-by-ball data (e.g., passes through LSTM <NUM>) and personalized embedding data (e.g., does not pass through LSTM <NUM>).

<FIG> is a is a flow diagram illustrating a method <NUM> of generating a fully trained prediction engine <NUM>, according to example embodiments. Method <NUM> may begin at step <NUM>.

At step <NUM>, organization computing system <NUM> may retrieve one or more data sets for training. Each data set may include ball-by-ball data captured by tracking system <NUM> during the course of a match. In some embodiments, ball-by-ball data may include the ball-by-ball delivery information supplemented with the ball-by-ball match context features.

At step <NUM>, organization computing system <NUM> may generate, for each data set, personalized embeddings based on both the batsman and the bowler for each pitch. Personalized batsman features may include, for example, measures of ability and aggression for various delivery trajectories, as well as general information regarding the batsman's favored hitting directions. Personalized bowler features may include, for example, the average number of runs scored, proportion of dot balls (<NUM> runs) and boundaries (<NUM>, <NUM> runs) for different delivery trajectories.

To generate the personalized embeddings, pre-processing engine <NUM> may identify the previous deliveries that each player has faced. For example, to ensure the personalized embeddings are dynamic and account for changes in player ability and preferences over time, pre-processing engine <NUM> may identify the previous <NUM> deliveries that each batsman has faced in data store <NUM>. This may allow for prediction engine <NUM> to generate predictions based on the most relevant and up-to-date information possible. In some embodiments, a player may have faced less than <NUM> deliveries. In such embodiments, pre-processing engine <NUM> may use a linearly weighted average between the player's value and the global average value for that feature, based on how many deliveries the player has participated in. For example, a player with only <NUM> deliveries before a given match would see their personal historic data contribute about <NUM>% to their features, with the global average contributing about <NUM>%.

At step <NUM>, organization computing system <NUM> may learn, based on the one or more data sets and the one or more sets of personalized embeddings, how to predict a shot type. For example, prediction engine <NUM> may learn, based on the one or more data sets and the one or more personalized embeddings, how to predict a shot outcome given at least bowler information and batsman information. In some embodiments, organization computing system <NUM> may use the ball-by-ball data may include the ball-by-ball delivery information supplemented with the ball-by-ball match context features to train LSTM <NUM>.

At step <NUM>, organization computing system <NUM> may output a fully trained prediction model. For example, at the end of the training and testing processes, prediction engine <NUM> may have a fully trained neural network architecture <NUM>.

Once neural network architecture <NUM> is trained, neural network architecture <NUM> may be used, for example, to simulate personalized batsman prediction, provide pre-match tactical planning to optimize batsman-bowler matchups and field placements, and to generate in-game tactics tailored to the on-going match context.

<FIG> is a flow diagram illustrating a method <NUM> of generating a shot type prediction, according to example embodiments. For discussion purposes, method <NUM> is directed to simulating a set of delivers from given bowler during a match, but to a different target batsman. Method <NUM> may begin at step <NUM>.

At step <NUM>, organization computing system <NUM> may receive (or retrieve) ball-by-ball data for a given bowler from a given event. In some embodiments, the ball-by-ball data may include the ball-by-ball delivery information supplemented with the ball-by-ball match context features. For example, the ball-by-ball data may include the set of deliveries from a given bowler during the course of a previously played match.

At step <NUM>, organization computing system <NUM> may generate personalized embeddings for both the target batsman and the identified bowler. Personalized batsman features may include, for example, measures of ability and aggression for various delivery trajectories, as well as general information regarding the batsman's favored hitting directions. Personalized bowler features may include, for example, the average number of runs scored, proportion of dot balls (<NUM> runs) and boundaries (<NUM>, <NUM> runs) for different delivery trajectories.

To generate the personalized embeddings, pre-processing engine <NUM> may retrieve historical ball-by-ball data for each of target batsman and identified bowler from data store <NUM>. Given the ball-by-ball data, pre-processing engine <NUM> may identify the previous <NUM> deliveries that the batsman has faced and the bowler has faced. If, for example, the batsman has faced less than <NUM> deliveries, pre-processing engine <NUM> may use a linearly weighted average between the player's value and the global average value for that feature, based on how many deliveries the player has participated in. If, for example, the bowler has bowled less than <NUM> deliveries, pre-processing engine <NUM> may similarly use a linearly weighted average between the player's value and the global average value for that feature, based on how many deliveries the player has participated in.

At step <NUM>, organization computing system <NUM> may input the ball-by-ball data and the personalized embeddings into prediction engine <NUM>. Prediction engine <NUM> may input the ball-by-ball data into LSTM <NUM>. LSTM <NUM> may be configured to generate a flattened representation of the ball-by-ball data. Prediction engine <NUM> may concatenate the personalized embeddings with the flattened representation of the ball-by-ball data output by LSTM <NUM>. Prediction engine <NUM> may provide the concatenated data to neural network <NUM>.

At step <NUM>, organization computing system <NUM> may generate a prediction based on the inputted data. For example, prediction engine <NUM> may generate a shot type prediction for each delivery from the bowler in the game but in the context of the target batsman being the player facing the deliver. The prediction may include the zone in which the shot is predicted to fall.

At step <NUM>, organization computing system <NUM> may generate a graphical representation of the prediction.

<FIG> are block diagrams illustrating projected shot zones for several batsmen, according to example embodiments. The projected shot zones illustrated in <FIG> are generated using one or more operations discussed above in <FIG>. Using a specific example, the identified bowler may be Trent Boult of the New Zealand team. Prediction engine <NUM> may be configured to simulate personalized batsman predictions for the top <NUM> batsmen on the England Cricket team - Jason Roy, Jonny Bairstow, Joe Root, Jos Butler, Ben Strokes, and Eoin Morgan - based on deliveries previously bowled by Trent Boult during a target match.

As illustrated, block diagram includes projected shot zones 602a-602f. Each shot zone 602a-602f corresponds to a different batsman. For example, shot zone 602a may correspond to Jason Roy; shot zone 602b may correspond to Jos Butler; shot zone 602c may correspond to Eoin Morgan; shot zone 602d may correspond to Jonny Bairstow; shot zone 602e may correspond to Joe Root; and shot zone 602f may correspond to Ben Strokes.

<FIG> is a flow diagram illustrating a method <NUM> of generating a shot type prediction, according to example embodiments. For discussion purposes, method <NUM> is directed to simulating shots from a given batsman against a given bowler. Such operations allow a team to scout or plan against various batsman prior to a match. Method <NUM> may begin at step <NUM>.

At step <NUM>, organization computing system <NUM> may receive (or retrieve) ball-by-ball data for a given batsman for a plurality of events. In some embodiments, the ball-by-ball data may include the ball-by-ball delivery information supplemented with the ball-by-ball match context features. For example, the ball-by-ball data may include the set of deliveries faced by a given batsman during the course of a season.

At step <NUM>, organization computing system <NUM> may generate personalized embeddings for both the target batsman and the target bowler. Personalized batsman features may include, for example, measures of ability and aggression for various delivery trajectories, as well as general information regarding the batsman's favored hitting directions. Personalized bowler features may include, for example, the average number of runs scored, proportion of dot balls (<NUM> runs) and boundaries (<NUM>, <NUM> runs) for different delivery trajectories.

At step <NUM>, organization computing system <NUM> may generate a prediction based on the inputted data. For example, prediction engine <NUM> may generate a shot type prediction for various types of deliveries bowled by the target bowler. For example, given a yorker delivery from the target bowler, what proportion of shots taken by the English batsman will be aggressive.

<FIG> illustrate plots of shot type predictions for a target batsman against various bowlers, according to example embodiments. The shot type predictions illustrated in <FIG> may be generated using one or more operations discussed above in conjunction with <FIG>. Using a specific example, the block diagram focuses on New Zealand's potential planning against the England batsman Ben Stokes. Prediction engine <NUM> may draw from Stokes' innings in the previous year leading up to the final to find the typical match context when he is batting (i.e., the match score and stage of the innings). Prediction engine <NUM> may then use this match context information to explore a large parameter space of four different bowling lines, four different bowling lengths, and five different New Zealand bowlers who were selected for the final. For the right-handed bowlers, prediction engine <NUM> may vary the side of the stumps from which they deliver the ball; for a left-handed pace bowler facing a left-handed batsman will practically always bowl from the same side.

Block diagram illustrates shot type predictions of Ben Stokes at the start of his innings when facing different delivery lengths, with all other parameters fixed. For example, shot type prediction chart 802a may correspond to the proportion of aggressive shots and shot type prediction chart 802b may correspond to the proportion of legside zone shots. Chart 802c may correspond to a proportion of aggressive shots when faced with <NUM>-<NUM> balls in comparison to greater than <NUM> balls. Chart 802d may correspond to a proportion of legside zone shots when faced with <NUM>-<NUM> balls in comparison to greater than <NUM> balls.

<FIG> is a flow diagram illustrating a method <NUM> of generating a shot type prediction, according to example embodiments. For discussion purposes, method <NUM> is directed to generating a shot type prediction during the course of a match. For example, given the current game context (score, batsman, bowler, balls remaining, etc.), prediction engine <NUM> may generate a prediction as to where the shot will fall. Method <NUM> may begin at step <NUM>.

At step <NUM>, organization computing system <NUM> may receive (or retrieve) a ball-by-ball data for a given event. In some embodiments, the ball-by-ball data may include the ball-by-ball delivery information supplemented with the ball-by-ball match context features. In some embodiments, the ball-by-ball data may include the data related to the last X (e.g., last <NUM>) deliveries or pitches from the bowling team. For example, assuming there are <NUM> deliveries in an over, the <NUM>th delivery may include information on the previous <NUM> balls (i.e., <NUM> by the previous bowler and <NUM> by themselves).

At step <NUM>, organization computing system <NUM> may generate personalized embeddings for both the batsman and the bowler. Personalized batsman features may include, for example, measures of ability and aggression for various delivery trajectories, as well as general information regarding the batsman's favored hitting directions. Personalized bowler features may include, for example, the average number of runs scored, proportion of dot balls (<NUM> runs) and boundaries (<NUM>, <NUM> runs) for different delivery trajectories.

To generate the personalized embeddings, pre-processing engine <NUM> may retrieve historical ball-by-ball data for each of batsman and bowler from data store <NUM>. Given the ball-by-ball data, pre-processing engine <NUM> may identify the previous <NUM> deliveries that the batsman has faced and the bowler has delivered. If, for example, the batsman has faced less than <NUM> deliveries, pre-processing engine <NUM> may use a linearly weighted average between the player's value and the global average value for that feature, based on how many deliveries the player has participated in. If, for example, the bowler has bowled less than <NUM> deliveries, pre-processing engine <NUM> may similarly use a linearly weighted average between the player's value and the global average value for that feature, based on how many deliveries the player has participated in.

At step <NUM>, organization computing system <NUM> may generate a prediction based on the inputted data. For example, prediction engine <NUM> may generate a shot type prediction based on the ball-by-ball data and the personalized embeddings. The prediction may include the zone in which the shot is predicted to fall.

<FIG> illustrates a system bus computing system architecture <NUM>, according to example embodiments. System <NUM> may be representative of at least a portion of organization computing system <NUM>. One or more components of system <NUM> may be in electrical communication with each other using a bus <NUM>. System <NUM> may include a processing unit (CPU or processor) <NUM> and a system bus <NUM> that couples various system components including the system memory <NUM>, such as read only memory (ROM) <NUM> and random access memory (RAM) <NUM>, to processor <NUM>. System <NUM> may include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of processor <NUM>. System <NUM> may copy data from memory <NUM> and/or storage device <NUM> to cache <NUM> for quick access by processor <NUM>. In this way, cache <NUM> may provide a performance boost that avoids processor <NUM> delays while waiting for data. These and other modules may control or be configured to control processor <NUM> to perform various actions. Other system memory <NUM> may be available for use as well. Memory <NUM> may include multiple different types of memory with different performance characteristics. Processor <NUM> may include any general purpose processor and a hardware module or software module, such as service <NUM><NUM>, service <NUM><NUM>, and service <NUM><NUM> stored in storage device <NUM>, configured to control processor <NUM> as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor <NUM> may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction with the computing device <NUM>, an input device <NUM> may represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device <NUM> (e.g., display) may also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems may enable a user to provide multiple types of input to communicate with computing device <NUM>. Communications interface <NUM> may generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

Storage device <NUM> may be a non-volatile memory and may be a hard disk or other types of computer readable media which may store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) <NUM>, read only memory (ROM) <NUM>, and hybrids thereof.

Storage device <NUM> may include services <NUM>, <NUM>, and <NUM> for controlling the processor <NUM>. Other hardware or software modules are contemplated. Storage device <NUM> may be connected to system bus <NUM>. In one aspect, a hardware module that performs a particular function may include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor <NUM>, bus <NUM>, display <NUM>, and so forth, to carry out the function.

<FIG> illustrates a computer system <NUM> having a chipset architecture that may represent at least a portion of organization computing system <NUM>. Computer system <NUM> may be an example of computer hardware, software, and firmware that may be used to implement the disclosed technology. System <NUM> may include a processor <NUM>, representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. Processor <NUM> may communicate with a chipset <NUM> that may control input to and output from processor <NUM>. In this example, chipset <NUM> outputs information to output <NUM>, such as a display, and may read and write information to storage <NUM>, which may include magnetic media, and solid state media, for example. Chipset <NUM> may also read data from and write data to storage <NUM> (e.g., RAM). A bridge <NUM> for interfacing with a variety of user interface components <NUM> may be provided for interfacing with chipset <NUM>. Such user interface components <NUM> may include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on. In general, inputs to system <NUM> may come from any of a variety of sources, machine generated and/or human generated.

Chipset <NUM> may also interface with one or more communication interfaces <NUM> that may have different physical interfaces. Such communication interfaces may include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying, and using the GUI disclosed herein may include receiving ordered datasets over the physical interface or be generated by the machine itself by processor <NUM> analyzing data stored in storage <NUM> or <NUM>. Further, the machine may receive inputs from a user through user interface components <NUM> and execute appropriate functions, such as browsing functions by interpreting these inputs using processor <NUM>.

It may be appreciated that example systems <NUM> and <NUM> may have more than one processor <NUM> or be part of a group or cluster of computing devices networked together to provide greater processing capability.

Claim 1:
A method for predicting a shot type, comprising:
retrieving, by a computing system, ball-by-ball data for a plurality of sporting events, wherein the ball-by-ball data is obtained by an optical-based tracking system;
generating, by the computing system, a trained neural network, by:
generating a plurality of training data sets based on the ball-by-ball data by supplementing the ball-by-ball data with ball-by-ball match context features, the ball-by-ball data including no shot, forward defensive, backward defensive, fended, leave, padded, shoulders arms, worked, pushed, steer, dropped, drive, sweep, cut, slog-sweep, hook, upper cut, pull, glance, reverse sweep, flick, late cut, slog, scoop, and/or switch hit data labels;
generating, from the ball-by-ball data, personalized embeddings based on a batsman and a bowler for each delivery; and
learning, by a neural network associated with the computing system, to predict a shot type based on the ball-by-ball data and the personalized embeddings;
receiving, by the computing system, a target batsman and a target bowler for a pitch to be delivered in a target event;
identifying, by the computing system, target ball-by-ball data for a window of pitches preceding the pitch to be delivered;
retrieving, by the computing system, historical ball-by-ball data for each of the target batsman and the target bowler;
generating, by the computing system, target personalized embeddings for both the target batsman and the target bowler based on the historical ball-by-ball data; and
predicting, by the computing system using the trained neural network, a target shot type for the pitch to be delivered based on the target ball-by-ball data and the target personalized embeddings,
wherein the neural network comprises: a long term-short term memory (LSTM) network; and a feed forward neural network; and,
wherein learning, by the neural network, to predict the shot type based on the ball-by-ball data and the personalized embeddings comprises: inputting the ball-by-ball data into the LSTM network; and generating, by the LSTM network, an output based on the ball-by-ball data; and, further comprising:
concatenating the output of the LSTM network with the personalized embeddings to generate concatenated data; and inputting the concatenated data into the feed forward neural network.