SPORT PERFORMANCE DEVELOPMENT AND ANALYTICS

BACKGROUND

Typically, businesses and activities, such as collegiate and professional sports, require the performance of particular personnel to be quantified. As a non-limiting example, in baseball, performance statistics, such as runs, hits, runs batted in (RBI), etc., are used in analyzing the performance of baseball players so that an educated decision whether to advance a player to a higher level, such as the “major leagues,” may be made. However, assessing the mental performance of the personnel, as opposed to the physical performance, remains problematic.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, with emphasis instead being placed upon clearly illustrating the principles of the disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.

FIG. 1 is an abstract representation of a networked environment according to various embodiments of the present disclosure.

FIG. 2 is a drawing of the networked environment of FIG. 1 according to various embodiments of the present disclosure.

FIGS. 3A-D are pictorial diagrams of example user interfaces rendered by a client in the networked environment of FIG. 1 according to various embodiments of the present disclosure.

FIG. 4 is a pictorial diagram of an example user interface rendered by a client in the networked environment of FIG. 1 according to various embodiments of the present disclosure.

FIG. 5 is a scenario table that may be employed in determination of a metric by an analytics engine in the networked environment of FIG. 1 according to various embodiments of the present disclosure.

FIG. 6 is a rating table that may be employed in determination of a metric by an analytics engine in the networked environment of FIG. 1 according to various embodiments of the present disclosure.

FIG. 7 is a pictorial diagram of an example user interface rendered by a client in the networked environment of FIG. 1 according to various embodiments of the present disclosure.

FIG. 8 is a data structure generated in the networked environment of FIG. 1 according to various embodiments of the present disclosure.

FIG. 9 is a flowchart illustrating one example of functionality implemented as portions of the performance development engine executed in a computing environment in the networked environment of FIG. 1 according to various embodiments of the present disclosure.

FIG. 10 is a flowchart illustrating one example of functionality implemented as portions of the analytics engine executed in a computing environment in the networked environment of FIG. 1 according to various embodiments of the present disclosure.

FIG. 11 is a schematic block diagram that provides one example illustration of a computing environment employed in the networked environment of FIG. 1 according to various embodiments of the present disclosure.

DETAILED DESCRIPTION

The following disclosure relates to a performance development application as well as the derivation of analytics. Businesses and activities, such as collegiate and professional sports, require the performance of particular personnel to be quantified. As a non-limiting example, in baseball, performance statistics, such as runs, hits, runs batted in's (RBIs), etc., are used in analyzing the performance of baseball players so that an educated decision whether to advance a player to a higher level, such as the “major leagues,” may be made. However, assessing the mental performance of the personnel, as opposed to the physical performance, remains problematic.

For example, a high school baseball player may have solid physical performance statistics, such as an impressive number of RBIs. Yet, the impressive number of RBIs may not paint a whole picture as to how the player may perform in an advanced level of competition. Similarly, there is no indication as to how the player may perform mentally when confronted with various scenarios. For example, assuming a runner is on first and third base, the player may not know where to throw the ball if it is hit to him or her.

Thus, it may be beneficial to train a player using a performance development application as well as determine metrics that quantify the mental performance of the player. A client device, such as a smartphone, laptop computer, or tablet, may be employed in the presentation of position-specific scenarios requiring a user of the client device to answer presented questions related to the scenarios. Quantifiable metrics may be generated based on the answers provided as well as the time taken to provide an answer, whether correct or incorrect. A predefined formulation may generate a metric corresponding to the user that indicates the mental performance of the user and the metric may be made accessible by requesting third-party sites.

As a non-limiting example, a choice of where to throw the ball (first base, second base, third base, or home plate) depends on key circumstances on the field such as what bases are occupied with runners (bases empty, bases loaded, runner on first base, runner on second base, runner on third base, runners on first and second bases, runners on first and third bases, or runners on second and third bases) and how many outs there are (0, 1, or 2). The user may first choose his/her position on the field. The performance development application may generate a scenario based on a number of outs and a number of bases occupied including other variables such as the direction of the ball, the speed of the runner, the current score, the inning, etc. The player (e.g., the user) may then select a base to which he would throw the ball. The program will measure the response and record a correct or wrong answer for each play or scenario. The user may complete as many plays or scenarios as he/she is able in a predetermined timeframe (e.g., two minutes). The program may generate a score and a rating metric based on the number of plays completed as well as the percentage correct. The performance development application may store the data for analysis and a recommended course of training may be presented to the user to improve the player's knowledge of the position. The program may also recognize problem areas for the player and generate more scenarios to focus on those problem areas. The data may be stored locally on the client device in a database on a server for further access by the player, coaches, parents, recruiters, etc. Accordingly, the performance development application may train the user to quickly respond while making accurate decisions. The ability to choose a player position, mentally train the user, analyze the responses, smartly focus on the user's problem areas, recommend a training regiment, and/or share the data with players, coaches, parents, recruiters, etc., may create a unique training experience for baseball/softball players of all ages. The compiled data, as well as the metrics generated from the data, may be ranked according to geographic area, age, etc., to determine top players by position, age, state, region, country, etc. In various embodiments, the compiled data, as well as the metrics generated from the data, may be shared via social networking sites.

Although the following description is provided in the context of baseball, the disclosure is not so limited. For example, a performance development application may be employed in presenting a player with a position-specific scenario or role-specific scenario in golf, football, soccer, wrestling, track and field, basketball, swimming and diving, etc. Moreover, a performance development application may be employed in the business context permitting the user of the application to assume the role (instead of a position as described herein) of a doctor, nurse, construction worker, business manager, etc. Quantifiable metrics may be generated for the employee based on answers provided responsive to being presented with particular scenarios, the time taken to provide the answers, as well as other information. In the following discussion, a general description of the system and its components is provided, followed by a discussion of the operation of the same.

With reference to FIG. 1, shown is abstract representation of a networked environment 100 according to various embodiments. In the non-limiting example of FIG. 1, a client device 103 is shown comprising a display 106. A performance development application, via a user interface, is rendered by the display 106 and is inherently made accessible by the user of the client device 103. To this end, the performance development application may provide the user with particular scenarios to educate the user for the particular scenario and/or test the user's knowledge for the particular scenario.

The performance development application may utilize the hardware of the client device 103 to communicate over a network 109 to a computing environment, such as one or more servers, that will be described in greater detail below. The computing environment may comprise, for example, a performance development engine 112 as well as an analytics engine 115. To this end, the performance development engine 112 may be configured to present various scenarios to the user over the network 109. The analytics engine 115 may be configured to determine one or more quantifiable that may be indicative of the user's mental performance relative to the presented scenarios. As a non-limiting example, a quantifiable metric may comprise a baseball academic rating (BAR) score 118 that may be encoded in regions of a user interface, as will be described in greater detail below.

With reference to FIG. 2, shown is a detailed description of the networked environment 100 according to various embodiments. The networked environment 100 includes a computing environment 203, a first client device 103a, and a second client device 103b (collectively client devices 103), which are in data communication with each other via the network 109. The network 109 includes, for example, the Internet, intranets, extranets, wide area networks (WANs), local area networks (LANs), wired networks, wireless networks, or other suitable networks, etc., or any combination of two or more such networks. For example, such networks may comprise satellite networks, cable networks, Ethernet networks, and other types of networks.

The computing environment 203 may comprise, for example, a server computer or any other system providing computing capability. Alternatively, the computing environment 203 may employ a plurality of computing devices that may be arranged, for example, in one or more server banks or computer banks or other arrangements. Such computing devices may be located in a single installation or may be distributed among many different geographical locations. For example, the computing environment 203 may include a plurality of computing devices that together may comprise a hosted computing resource, a grid computing resource and/or any other distributed computing arrangement. In some cases, the computing environment 203 may correspond to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources may vary over time.

Various applications and/or other functionality may be executed in the computing environment 203 according to various embodiments. Also, various data is stored in a data store 206 that is accessible to the computing environment 203. The data store 206 may be representative of a plurality of data stores 206 as can be appreciated. The data stored in the data store 206, for example, is associated with the operation of the various applications and/or functional entities described below.

The components executed on the computing environment 203, for example, include the performance development engine 112, the analytics engine 115, an application programming interface (API) (hereinafter API interface 209) and other applications, services, processes, systems, engines, or functionality not discussed in detail herein. As briefly described above, the performance development engine 112 is executed to present various predefined scenarios 207a to the user over the network 109. The analytics engine 115 is executed to determine one or more quantifiable metrics for the user that may be indicative of the user's mental performance relative to the presented scenarios. The API interface 209 is executed to receive programmatic service calls (e.g., API calls) from one or more requesting services for information associated with players or personnel. According to various embodiments, the API interface 209 may comprise a web service enabling communication between the computing environment 203 and other devices over the network 109.

The data stored in the data store 206 includes, for example, application data 210, user data 212a, historical data 215, authentication data 218, scenario data 221, rating data 224, and potentially other data. Application data 210 may comprise data used in encode the performance development application 266 on a client device 103. User data 212 may comprise information associated with a user of the performance development application 266 (also referred herein as “a player”) such as historical data 215 obtained by the performance development application 266 in association with scenarios accessed and/or performed. For example, after presentation of various scenarios, the user may be prompted with questions to demonstrate the ability of the user in understanding and/or remembering the various scenarios. Historical data 215 may comprise, for example, the scenarios performed, the answers provided to questions presented in the scenarios, and/or the temporal delay in providing answers in the form of user input, etc.

Authentication data 218 may comprise, for example, data utilized to authenticate a user and/or a client device 103 on which the user accesses the performance development application 266. To this end, authentication data 218 may comprise login credentials (e.g., previously provided usernames and passwords), biometric data, internet protocol (IP) addresses, digital fingerprints of the client devices 103, and/or other information that may be used in authenticating the user or the client device 103. Scenario data 221 may comprise data used in generating scenarios specific to the user and/or specific to a particular position. A non-limiting example of scenario data 221 will be described in greater detail below with respect to FIG. 5.

Rating data 224 may comprise data used to generate one or more metrics for a user or player. For example, rating data 224 may comprise formulae used to determine metrics that quantify the mental performance of the user or player. A non-limiting example of rating data 224 will be described in greater detail below with respect to FIG. 6.

The client devices 103a-b are representative of a plurality of client devices that may be coupled to the network 109. Either client device 103 may comprise, for example, a processor-based system such as a computer system. Such a computer system may be embodied in the form of a desktop computer, a laptop computer, personal digital assistants, cellular telephones, smartphones, set-top boxes, music players, web pads, tablet computer systems, game consoles, electronic book readers, or other devices with like capability. The clients 103a-b may include displays 106a-b. The displays 106a-b may comprise, for example, one or more devices such as liquid crystal display (LCD) displays, gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electrophoretic ink (E ink) displays, LCD projectors, or other types of display devices, etc.

The clients 103a-b may be configured to execute various applications such as the performance development application 266, a statistics application 269 (hereinafter client applications) and/or other applications. The client applications may be executed in a client device 103, for example, to access network content served up by the computing environment 203 and/or other servers, thereby rendering a user interface 272 on the display 106. To this end, the client applications may comprise, for example, a browser, a dedicated application, etc., and the user interface 272 may comprise a network page, an application screen, etc. The clients 103a-b may be configured to execute applications beyond the client applications such as, for example, email applications, social networking applications, word processors, spreadsheets, and/or other applications.

Next, a general description of the operation of the various components of the networked environment 100 is provided. To begin, it assumed that a user may execute the performance development application 266 on the client device 103a to mentally train by being presented with one or more sport-specific, business-specific, and/or position-specific scenarios. The historical data 215 corresponding to the user may be accessed, for example, via the data store 206 or other memory and may be utilized in determining one or more predefined scenarios 207b to present to the user by the performance development engine 112. The predefined scenarios 207b may be sent to the client device 103 as application input data. According to various embodiments, the performance development engine 112 may comprise two or more modes of operation. As a non-limiting example, a first mode of operation may comprise a “game mode” where scenarios are determined during which the user is graded. For example, in the game mode, the user input 250 and the temporal delay 253 in receiving the user input 250 is measured to be utilizing in generating one or more metrics for the user. According to various embodiments, the scenarios presented in the game mode of operation may be selected at random, however, may be selected utilizing historical data 215 such that repeated scenarios are lessened and/or avoided.

A second mode of operation may comprise a “practice mode” and/or a “training mode” during which the user may be presented with various scenarios and questioned about the scenarios without affecting the metrics. Similarly, in the “practice mode” and/or “training mode,” the performance development engine 112 may determine recommended scenarios based on areas the user is weakly performing. Likewise, the performance development engine 112 may recommend “training regiments” such as performing a certain amount of scenarios in a particular amount of time. As a non-limiting example, the user struggling with determining where to throw a ball in various scenarios may be recommended to conduct 10 cycles a week in practice mode, wherein each cycle contains 5 scenarios associated with determining where to throw the ball.

The BAR score 118b may be periodically sent to the client device 103 (or upon a request) so that the user may be constantly aware of their performance. The predefined scenario 207b and/or data necessary to render the predefined scenario 207b in the client device 103 may be encoded for transmission. As a non-limiting example, the scenario and/or data necessary to render the scenario may be formatted in the JSON format and/or any other machine-readable format. Next, the scenario and/or data necessary to render the scenario may be sent to the client device 103.

As may be appreciated, as the predefined scenario 207b is rendered by the client device 103 on the display 106 via the performance development application 266. The performance development application 226 executing on the client device 103 may monitor the user input 250 or the time elapsed between the rendering of the scenario and a response initiated by a user, such as an amount of time taken by the user to answer a question presented in the scenario. Thus, the measurements of the user input 250 and/or the amount of time taken by the user in providing user input (e.g., the temporal delay 253) may be received by the performance development engine 112 from the client device 103. In addition, any information provided by the user via the performance development application 266 may be sent as user data 212 to the computing environment 203. This may be used to update the historical data 215 corresponding to the user.

The analytics engine 115 may subsequently access the historical data 215 corresponding to a user and may generate one or more metrics for the user utilizing at least the historical data 215. As a non-limiting example, a metric may comprise the BAR score 118, the computation of which will be described in greater detail below. The historical data 215 used in determining the metric may comprise, for example, an accuracy of user input 250 responsive to the presented scenarios, the temporal delay 253 in providing the user input 250, and/or any other information that may be employed in the generation of the one or more metrics.

As may be appreciated, other services, network sites, or mobile applications may desire to access BAR scores 118 for one or more players. Accordingly, the BAR scores 118, generated by the analytics engine 118 and stored in data store 212, may be made accessible to third-party requests. For example, recruiting sites, college sports sites, professional sports sites, professional networking sites, etc., may submit requests for the BAR scores 118 and may be provided with a most recent and up-to-date BAR score 118. Thus, the computing environment 203 may receive third-party requests via, for example, the API interface 209. A request may comprise a solicitation for information about a specific player or a class of players (e.g., the top percentile of players ranking according to the BAR score 118). Thus, a request may be classified as generic (e.g., asking for a class of players such as the highest ranked players) or specific (e.g., asking for a BAR score 118 for a specific player).

If a request has been received, the request may be authenticated by comparing the requesting service or device to a white list of permissible requesting services or devices. Similarly, authentication of the third-party request may comprise comparing the requesting service or device to a black list of blocked requesting services or devices. The white lists and/or black list may be updated according to subscriptions maintained in the computing environment 203. The one or more metrics may be encoded for transmission and may be sent to the client device 103 for rendering via the API interface 209. Thus, the transmission may comprise, for example, user data 212b corresponding to the user as well as the B.A.R. score 118c.

Referring next to FIGS. 3A-D, shown are pictorial diagrams of example user interfaces 272 (FIG. 2) rendered by the clients 103a-d in the networked environment of FIGS. 1-2 according to various embodiments of the present disclosure. Referring first to FIG. 3A, the performance development application 266 may be executed to present scenarios associated with a certain position. In FIG. 3A, it is assumed that the user selected the position corresponding to the number “1” displayed in association with the “Pitcher” position, whereby subsequent user interfaces 272 may be rendered to present the user with scenarios corresponding to the “Pitcher” position. Although the user interface 272 of FIG. 3A shows numbering components (e.g., numbers 1-9), shorthand notation for the position may be listed (e.g, PI, LF, CF, RF, CA, 1B, 2B, 3B, SS). A continue component 303 allows the user to proceed in the scenario (and initiate the rendering of subsequent user interfaces 272) after selecting a position. As shown in FIG. 3B, the scenario is presented to the user of the performance development application 266 responsive to the selection of the “Pitcher” position. Accordingly, the “Pitcher” position, shown in the user interface 272, may be emphasized as well as the runners. Emphasizing the particular characteristics in the user interface 272 may comprise highlighting or otherwise emphasizing the icon to draw attention to the user. According to various embodiments, addition icons may be used (e.g., arrows) to draw attention to a particular aspect of the scenario, such as the location of runners. In various embodiments, icons such as a batter's helmet or an avatar may be used to represent an occupied base. As a non-limiting example, the scenario may involve a situation where there are runners on first and third bases and, off a fastball pitch, a batter decides to bunt, as shown in FIG. 3B.

Moving on to FIG. 3C, one or more questions may be presented to the user associated with the scenario in FIG. 3B. For example, the question may prompt the user as to whether the user (in the “Pitcher” position) should throw a fielded ball to first base (option A), second base (option B), third base (option C), or home plate (option D). User input responsive to the question may be obtained via user input components 306a-d, which may comprise buttons or similar user interface 272 components. Although shown with the options (A), (B), (C), and (D), the buttons could be similarly labeled (1), (2), (3), or (4) as well as “1^st”, “2^nd,” “3^rd,” or “H” (representing home plate). A timer 309a may provide the user with notice as to an elapsed time (i.e., the temporal delay 253) it takes the user to answer the question presented. In various embodiments, the timer 309a may not be shown in the user interface 272, however, the client device 103 may still collect the elapsed time to determine quantifiable metrics for the user.

As shown in the embodiment set forth in FIG. 3D, the performance development application 266 may render a three-dimensional representation of the scenario such that the user is provided a more accurate visualization of the scenario. As shown in FIG. 3D, the scenario of a runner on first base and a runner on third base may be denoted by icon 312a and icon 312b, each representing a runner. The position icon 315 may denote the location of the user in the scenario. In the non-limiting example of FIG. 3D, the position icon 315 denotes that the user is on the pitcher's mound and/or is assuming the position of the pitcher. An outs component 318 may denote the number of outs in the given scenario. A bases component 321 may further denote the locations of the runners (e.g., on first base and on third base). The timer 309b component may be further rendered in the display as well as input components 324a-d which are configured to receive user input.

Turning now to FIG. 4, shown is a pictorial diagram of an example user interface 272 (FIG. 2) rendered by the client device 103 in the networked environment of FIGS. 1-2 according to various embodiments of the present disclosure. In the non-limiting example of FIG. 4, a user interface 272 may comprise a ranking for the users of the performance development application 266. For example, utilizing the metrics generated for each player, a ranking may be determined wherein the top-most player may be the player having the highest metric and the bottom-most player may be the player having the lowest metric. The ranking may be generated respective of the level of the user. However, in alternative embodiments, the ranking may be generated utilizing factors such as age, grade level, physical performance level, etc. A percentile may be determined for the user by comparing the metric of the user to the metrics of a plurality of other users. In the non-limiting example of FIG. 4, the user is shown being in the 1.7^thpercentile.

Moving on to FIG. 5, shown is a scenario table 503 that may be utilized by the performance development engine 112 in determining and/or generating one or more scenarios to be presented on the client device 103 (FIG. 1). The scenario table 503 depicted in FIG. 5 may be a visual depiction of scenario data 221 stored in a data store 206 or similar memory and accessible by the performance development engine 112 in the computing environment 203 (FIG. 2). To this end, the performance development engine 112 may access the scenario data 221 for particular levels to determine an applicable scenario to present to a user.

The performance development engine 112 may further use various in-game factors 506 such as (1) a number of outs; (2) a number of base runners; (3) a location of the base runners; (4) a score (e.g., tied, up one, down one, down two or more, up two or more); (5) a speed of a runner (e.g., slow, average, fast); (6) a depth of the infield or the outfield (e.g., in or back); (6) a direction of the ball being hit (e.g., right at you, two steps to the left or right); (7) a speed of the ball (e.g., slow, average, fast). Utilizing these factors 506, at least 95% of game situations may be quantifiable and presented by the performance development engine 112 for a respective position. As may be appreciated, the factors 506 utilized by the performance development engine 112 may vary according to the level of the user. For example, determining a scenario for a user in level one may not utilize advanced factors such as the speed of the ball or the depth of the infield or outfield. However, a user in a higher level (e.g., level 7) may utilize the speed of the ball or the depth of the infield or outfield. According to various embodiments, the progression of levels may include the use of additional factors in determining scenarios.

Referring next to FIG. 6, shown is a rating table 603 that may be employed in determination of a metric, such as the BAR score 118, by the analytics engine 115 in the networked environments of FIGS. 1-2 according to various embodiments of the present disclosure. The rating table 603, shown in FIG. 6, may be a visual depiction of rating data 224 stored in the data store 206 or similar memory and accessible by the analytics engine 115 in the computing environment 203 (FIG. 2). To this end, the analytics engine 115 may utilize historical data 215 (FIG. 2) stored in association with the user to generate one or more metrics utilizing one or more predefined formulas stored in, for example, rating data 224.

In the non-limiting example of FIG. 6, an accuracy 609 in choosing a correct answer when presented with various scenarios may be utilized in determining a metric corresponding to a user. Similarly, a response time 612 in choosing the correct answer may be utilized in determining a metric corresponding to a user. The following equation may be employed to summarize the rating table 603:

$\begin{matrix} Metric = ((\frac{{Accuracy}_{Actual}}{{Accuracy}_{Goal}}) + (\frac{{ResponseTime}_{Actual}}{{ResponseTime}_{Goal}}) * W) + L & (eq . 1) \end{matrix}$

wherein W is a weight and L is the level of the user.

In the non-limiting example of FIG. 6, W is equal to 2 as the sum of the factors utilized in determining the metric (the accuracy 609 and the response time 612). Accordingly, W may be utilized in eq. 1 to average representative metrics for each of the factors.

Turning now to FIG. 7, shown is a pictorial diagram of an example user interface 272 rendered by a client device 103 (FIGS. 1-2) in the networked environments of FIGS. 1-2 according to various embodiments of the present disclosure. As a non-limiting example, the user interface 272 may be rendered in the statistics application 269 (FIG. 2) of the client device 103b of FIG. 2. As discussed above, the statistics application 269 may comprise a network site accessible by a browser or a stand-alone application executable by the client device 103b, such as a mobile application.

As may be appreciated, various recruiting websites or professional statistics websites depict various statistics for players. Accordingly, it may be beneficial for one or more metrics generated by the analytics engine 115 to become accessible to third-party applications or network sites to display in a metric describing mental performance relative to the other statistics. For example, a recruiting website may request one or more metrics for a particular player from the computing environment 203 (FIG. 2). In response, the computing environment 203 may encode the one or more metrics in a data packet for transmission to the statistics application 269 for rendering. According to various embodiments, the data packet may comprise further information associated with the player, such as age, level, state, name, rank, high school, college, professional team, etc.

In the non-limiting example of FIG. 7, the metric encoded in the user interface 272 includes the BAR score 118 generated by the analytics engine 115 as shown in FIG. 6. Thus, the recruiting website may encode the BAR score 118 in a player profile relative to physical information about the player (e.g., height, weight, age, etc.) as well as performance statistics (e.g., 40-yard dash, in-game statistics, etc.).

Moving on to FIG. 8, shown is an example of player information 803 encoded in JavaScript Object Notation (JSON) format that may be employed in delivery of information about one or more players, such as a BAR score 118. As a non-limiting example, a website (e.g., the recruiting website of FIG. 7) or a mobile application (e.g., the performance development application 266 of FIG. 4) may request information about one or more players from the computing environment 203. The API interface 209 may process the request and/or respond with requested data. For example, the requesting website or mobile application may request the top three players according to their respective BAR score 118. In response, the API interface 209 may query the data store 206 to identify the top three players as well as obtain other information about the player via user data 212. The API interface 209 may encode the information in the JSON format for interpretation by the requesting website or the mobile application. To this end, the one or more metrics generated by the analytics engine 115 may be made readily available to all requesting services utilizing the API interface 209.

Referring next to FIG. 9, shown is a flowchart that provides one example of the operation of a portion of the performance development engine 112 according to various embodiments. It is understood that the flowchart of FIG. 9 provides merely an example of the many different types of functional arrangements that may be employed to implement the operation of the portion of the performance development engine 112 as described herein. As an alternative, the flowchart of FIG. 9 may be viewed as depicting an example of elements of a method implemented in the computing environment 203 (FIG. 2) according to one or more embodiments.

As described above, a user may execute the performance development application 266 on a client device 103. Beginning with 903, the user may be authenticated utilizing at least login credentials (e.g., username and password), biometric data, internet protocol (IP) addresses, fingerprints of the client device 103 and/or other information. Next, in 906, the historical data 215 corresponding to the user may be accessed, for example, via the data store 206 or other memory. In 909, the performance development engine 112 may determine one or more scenarios to present to the user. To this end, the performance development engine 112 may utilize the scenario table 503 as depicted in FIG. 5. In 912, the scenario and/or data necessary to render the scenario in the client device 103 may be encoded for transmission. As a non-limiting example, the scenario and/or data necessary to render the scenario may be formatted in the JSON format described above with respect to FIG. 8 although other formats may be employed. Moving on the 915, the scenario and/or data necessary to render the scenario may be sent to the client device 103.

As may be appreciated, as the scenario is rendered by the client device 103 on the display 106, the client device 103 may monitor the user input 250 or the time elapsed between the rendering of the scenario and a response initiated by a user, such as an amount of time taken by the user to answer a question presented in the scenario. Thus, in 918, the measurements of the user input 250 and/or the amount of time taken by the user may be received by the performance development engine 112 from the client device 103. In 921, this may be used to update the historical data 215 corresponding to the user. In 924, the historical data 215 may be made accessible to the analytics engine 115 to derive one or more metrics for the user, as will be discussed in greater detail below.

Referring next to FIG. 10, shown is a flowchart that provides one example of the operation of a portion of the analytics engine 115 according to various embodiments. It is understood that the flowchart of FIG. 10 provides merely an example of the many different types of functional arrangements that may be employed to implement the operation of the portion of the analytics engine 115 as described herein. As an alternative, the flowchart of FIG. 10 may be viewed as depicting an example of elements of a method implemented in the computing environment 203 (FIG. 2) according to one or more embodiments.

As discussed above with respect to FIG. 9, the historical data 215 for a user may be made accessible by the analytics engine 115. Accordingly, in 1003, the historical data 215 corresponding to one or more users is accessed by the analytics engine 115. In 1006, the analytics engine 115 is executed to generate one or more metrics for a user utilizing at least the historical data 215 corresponding to the user. As a non-limiting example, a metric may comprise the BAR score 118, computation of which is described above with respect to FIG. 6. The historical data 215 may comprise, for example, the accuracy 609, the response time 612, and/or any other information that may be employed in the generation of the one or more metrics.

Moving on to 1009, it is determined whether a request has been received from a requesting client device 103 for one or more metrics. A request may comprise a solicitation for information about a specific player or a class of players (e.g., the top percentile of players ranking according to the BAR score 118). If a request has been not been received, the process may end. Alternatively, if the request has been received, in 1012, then the request may be authenticated (1012). Authentication may comprise comparing the requesting service or device to a white list of permissible requesting services or devices. Similarly, authentication may comprise comparing the requesting service or device to a black list of blocked requesting services or devices. According to various embodiments, the white lists and/or black list may be updated according to subscriptions maintained in the computing environment 203. In 1015, one or metrics corresponding to a player may be identified, for example, according to a player or class of players identified in the request. In 1018, the one or more metrics may be encoded for transmission. In 1021, the one or more metrics may be sent to the client device 103 for rendering.

With reference to FIG. 11, shown is a schematic block diagram of the computing environment 203 according to an embodiment of the present disclosure. The computing environment 203 includes one or more computing devices 1103. Each computing device 1103 includes at least one processor circuit, for example, having a processor 1106 and a memory 1109, both of which are coupled to a local interface 1112. To this end, each computing device 1103 may comprise, for example, at least one server computer or like device. The local interface 1112 may comprise, for example, a data bus with an accompanying address/control bus or other bus structure as can be appreciated.

Stored in the memory 1109 are both data and several components that are executable by the processor 1106. In particular, stored in the memory 1109 and executable by the processor 1106 are the performance development engine 112, the analytics engine 115, the API interface 209, and potentially other applications. Also stored in the memory 1109 may be a data store 206 and other data. In addition, an operating system may be stored in the memory 1109 and executable by the processor 1106.

It is understood that there may be other applications that are stored in the memory 1109 and are executable by the processor 1106 as can be appreciated. Where any component discussed herein is implemented in the form of software, any one of a number of programming languages may be employed such as, for example, C, C++, C#, Objective C, Java®, JavaScript®, Perl, PHP, Visual Basic®, Python®, Ruby, Flash®, or other programming languages.

A number of software components are stored in the memory 1109 and are executable by the processor 1106. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor 1106. Examples of executable programs may be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory 1109 and run by the processor 1106, source code that may be expressed in proper format such as object code that is capable of being loaded into a random access portion of the memory 1109 and executed by the processor 1106, or source code that may be interpreted by another executable program to generate instructions in a random access portion of the memory 1109 to be executed by the processor 1106, etc. An executable program may be stored in any portion or component of the memory 1109 including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

The memory 1109 is defined herein as including both volatile and nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power. Thus, the memory 1109 may comprise, for example, random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, and/or other memory components, or a combination of any two or more of these memory components. In addition, the RAM may comprise, for example, static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM) and other such devices. The ROM may comprise, for example, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other like memory device.

Also, the processor 1106 may represent multiple processors 1106 and/or multiple processor cores and the memory 1109 may represent multiple memories 1109 that operate in parallel processing circuits, respectively. In such a case, the local interface 1112 may be an appropriate network that facilitates communication between any two of the multiple processors 1106, between any processor 1106 and any of the memories 1109, or between any two of the memories 1109, etc. The local interface 1112 may comprise additional systems designed to coordinate this communication, including, for example, performing load balancing. The processor 1106 may be of electrical or of some other available construction.

Although the performance development engine 112, the analytics engine 115, the API interface 209, and other various systems described herein may be embodied in software or code executed by general purpose hardware as discussed above, as an alternative the same may also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies may include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field-programmable gate arrays (FPGAs), or other components, etc. Such technologies are generally well known by those skilled in the art and, consequently, are not described in detail herein.

The flowcharts of FIGS. 9 and 10 show the functionality and operation of an implementation of portions of the performance development engine 112, the analytics engine 115, and/or the API interface 209. If embodied in software, each block may represent a module, segment, or portion of code that comprises program instructions to implement the specified logical function(s). The program instructions may be embodied in the form of source code that comprises human-readable statements written in a programming language or machine code that comprises numerical instructions recognizable by a suitable execution system such as a processor 1106 in a computer system or other system. The machine code may be converted from the source code, etc. If embodied in hardware, each block may represent a circuit or a number of interconnected circuits to implement the specified logical function(s).

Although the flowcharts of FIGS. 9 and 10 show a specific order of execution, it is understood that the order of execution may differ from that which is depicted. For example, the order of execution of two or more blocks may be scrambled relative to the order shown. Also, two or more blocks shown in succession in FIGS. 9 and 10 may be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks shown in FIGS. 9 and 10 may be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids, etc. It is understood that all such variations are within the scope of the present disclosure.

Also, any logic or application described herein, including the performance development engine 112, the analytics engine 115, and/or the API interface 209, that comprises software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as, for example, a processor 1106 in a computer system or other system. In this sense, the logic may comprise, for example, statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a “computer-readable medium” can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system.

The computer-readable medium can comprise any one of many physical media such as, for example, magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium would include, but are not limited to, magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Also, the computer-readable medium may be a random access memory (RAM) including, for example, static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). In addition, the computer-readable medium may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other type of memory device.

Further, any logic or application described herein, including the performance development engine 112, the analytics engine 115, the API interface 209, may be implemented and structured in a variety of ways. For example, one or more applications described may be implemented as modules or components of a single application. Further, one or more applications described herein may be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein may execute in the same computing device 1103, or in multiple computing devices in the same computing environment 203. Additionally, it is understood that terms such as “application,” “service,” “system,” “engine,” “module,” and so on may be interchangeable and are not intended to be limiting.

Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the disclosure. Many variations and modifications may be made to the above-described embodiment(s) without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

SPORT PERFORMANCE DEVELOPMENT AND ANALYTICS

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims

CROSS REFERENCE TO RELATED APPLICATIONS

Provisional Applications (1)