Supply of video segments based on gameplay of a videogame

SUMMARY

It is to be understood that both the following general description and the following detailed description are exemplary and explanatory only and are not restrictive. Provided are methods and systems for gaming using historical performance data. Credits (e.g., coins, tickets, money, tokens, credit card information, debit card information, etc.) can be received from a user to initiate a round of a game. A listing of entities can be provided to a user. A selection of one or more of the entities can be received from a user. A performance period can then be selected for each of the entities. For each of the selected entities, it is determined whether the respective selected entity met a performance benchmark in their corresponding selected performance period according to historical performance data. A payout for the round of the game is based on a number of the selected entities that satisfied the performance benchmark during their respective performance period.

Also provided are technologies to supply of video segments and other types of media assets during a gameplay of a videogame. In some embodiments, a gaming device can receive first data identifying a sports player within a listing of sports players. The gaming device also can receive second data identifying a performance benchmark within a listing or performance benchmarks. The gaming device can select a performance period corresponding to the sports player. The gaming device can then determine if a performance of the sports player during the performance period meets or exceeds the performance benchmark. In response to a positive determination, the gamins device can cause a display device to present a sequence of video segments corresponding to the performance of the sports player during the performance period.

Additional advantages will be set forth in part in the description which follows or may be learned by practice. The advantages will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments and together with the description, serve to explain the principles of the methods and systems:

FIG. 1A shows an exemplary electronic gaming table on which the gaming methods can be executed;

FIG. 1B shows an exemplary schematic for an electronic system for enabling play of the gaming methods described herein;

FIG. 1C shows another exemplary schematic for an electronic system for enabling play of the gaming methods described herein;

FIGS. 2A and 2B show example user interfaces for the gaming methods described herein;

FIG. 3 is a chart depicting example payouts for the gaming methods described herein;

FIG. 4 shows an exemplary flow diagram;

FIG. 5 shows an exemplary computing device;

FIG. 6 illustrates an example of an operational environment for the supply video segments as part of gameplay of a videogame, in accordance with one or more embodiments of this disclosure;

FIG. 7A illustrates an example of a user interface that can be presented in a gaming device as part of gameplay of a videogame, in accordance with one or more embodiments of this disclosure;

FIG. 7B illustrates an example of another user interface that can be presented in a gaming device as part of gameplay of a videogame, in accordance with one or more embodiments of this disclosure;

FIG. 8 illustrates an example of yet another user interface that can presented in a gaming device as part of gameplay of a videogame, in accordance with one or more embodiments of this disclosure;

FIG. 9 illustrates an example of a method for supplying video segments as part of gameplay of a videogame, according to one or more embodiments of this disclosure; and

FIG. 10 is a flowchart of an example of a method for composing a sequence of video segments to be supplied as part of gameplay of a videogame, according to one or more embodiments of this disclosure.

DETAILED DESCRIPTION

Before the present methods and systems are disclosed and described, it is to be understood that the methods and systems are not limited to specific methods, specific components, or to particular implementations. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

As used in the specification and the appended claims, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Ranges may be expressed herein as from “about” one particular value, and/or to “about” another particular value. When such a range is expressed, another embodiment includes from the one particular value and/or to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent “about,” it will be understood that the particular value forms another embodiment. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint.

“Optional” or “optionally” means that the subsequently described event or circumstance may or may not occur, and that the description includes instances where said event or circumstance occurs and instances where it does not.

Throughout the description and claims of this specification, the word “comprise” and variations of the word, such as “comprising” and “comprises,” means “including but not limited to,” and is not intended to exclude, for example, other components, integers or steps. “Exemplary” means “an example of” and is not intended to convey an indication of a preferred or ideal embodiment. “Such as” is not used in a restrictive sense, but for explanatory purposes.

Disclosed are components that can be used to perform the disclosed methods and systems. These and other components are disclosed herein, and it is understood that when combinations, subsets, interactions, groups, etc. of these components are disclosed that while specific reference of each various individual and collective combinations and permutations of these may not be explicitly disclosed, each is specifically contemplated and described herein, for all methods and systems. This applies to all aspects of this application including, but not limited to, steps in disclosed methods. Thus, if there are a variety of additional steps that can be performed it is understood that each of these additional steps can be performed with any specific embodiment or combination of embodiments of the disclosed methods.

The present methods and systems may be understood more readily by reference to the following detailed description of preferred embodiments and the examples included therein and to the Figures and their previous and following description.

As will be appreciated by one skilled in the art, the methods and systems may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the methods and systems may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied in the storage medium. More particularly, the present methods and systems may take the form of web-implemented computer software. Any suitable computer-readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

Embodiments of the methods and systems are described below with reference to block diagrams and flowchart illustrations of methods, systems, apparatuses and computer program products. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create a means for implementing the functions specified in the flowchart block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including computer-readable instructions for implementing the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

Methods and systems are described herein for a game using historical performance data. Credits (e.g., coins, tickets, money, tokens, credit card information, debit card information, etc.) can be received from a user to initiate a round of a game. A listing of entities can be provided to a user. The entities can include, for example, sports players, stocks, or other entities as can be appreciated. In an aspect, the listing of entities may be provided as a subset of entities selected from a pool of entities. In such an aspect, the subset of entities may be selected randomly from the pool of entities. In an aspect, the entities may be organized into groups. For example, the groups may include performance tiers, sports team positions, or other groups. In such an aspect, the listing of entities may be provided according to the respective groups. In an aspect, each of the entities may correspond to a temporal constraint such as a year, a season, or other time period that will serve as a constraint for selecting a performance period, as will be described below. For example, a sports team player may correspond to a particular season or year. As another example, a stock may be associated with a particular year, fiscal year, or other period.

A selection of one or more of the entities can be received from a user. In aspects in which the entities are organized into groups, this can include a selection of a predefined number of entities from each of the groups. A performance period can then be selected for each of the selected entities. The performance period can include a particular game, season, date range, or other period for each of the selected entities. In aspects in which the selected entities correspond to a particular temporal constraint, the performance period can be selected from within the temporal constraint. For example, for a sports player corresponding to a particular season as a temporal constraint, the performance period may correspond to a game or series from within the particular season. As another example, for a stock corresponding to a particular year as a temporal constraint, the performance period may correspond to a particular day, week, month, or quarter within the particular year. The performance period can be selected randomly, by applying one or more rules, or according to other criteria.

For each of the selected entities, it is determined whether the respective selected entity met a performance benchmark in their corresponding selected performance period according to historical performance data. For example, assume that the performance period is a randomly selected game for each selected player. Historical performance data for that particular player and game is accessed to determine if the player met a performance benchmark. The performance benchmark could include a number of runs or points scored, a number of yards gained, a number of successful or attempted shots, or other performance benchmark as can be appreciated. In an aspect, the performance benchmark may be the same or different for each of the selected entities. For example, the performance benchmark for a kicker in football may be a number of successful field goals or a maximum distance of a kickoff or punt, while the performance benchmark for a quarterback may be a total number of passing yards.

In an aspect, the historical performance data may be updated prior to determining whether the respective selected entity met a performance benchmark in their corresponding selected performance period. For example, the historical performance data for a quarterback in football may have changed in the intervening time period between the start of the game and the selection of the one or more of the entities by the user. Updating the historical performance data would allow the game to be more accurate when determining whether the performance benchmark was met.

A payout for the round of the game is based on a number of the selected entities that satisfied the performance benchmark during their respective performance period. In an aspect, the payout may be based on a bet or number of credits used to initialize the round of the game. In an aspect, the payout from one round of the game may serve as a credit or bet for a subsequent round of the game. The disclosed gaming model includes both chance-based and skill-based components for winning Chance-based components can include which entities are presented to a user for selection, which performance period is selected for a given selected entity, and what performance benchmark is used for comparison to the historical data for a given entity and performance period. Skill-based components can include which entities are selected from the listing of entities based on a user's historical knowledge and estimations of historical entity performance.

Turning to FIG. 1A, a video gaming machine 2 in accordance with the methods and systems described herein is shown. Machine 2 can comprise a main cabinet 4, which can surround the machine interior (not shown) and can be viewable by users. The main cabinet can comprise a main door 8 on the front of the machine, which opens to provide access to the interior of the machine. Player-input switches or buttons 32, a coin acceptor 28, and a bill validator 30, a coin tray 38, and a display area including a mechanical gaming system (or a separate electronic game) 40 can be attached to the main door 8. There can be an overlay of touchscreen functionality on the separate electronic game 40 or some of the buttons 32 can be functional on the separate mechanical gaming system 40. The separate mechanical gaming system can be in a relatively vertical viewing position as shown or in a more horizontal (table like) display unit. A video display monitor 34 and an information panel 36 can be viewable through the main door 8. The display monitor 34 can be a cathode ray tube, high resolution flat-panel LCD, LED, plasma screen or other conventional electronically controlled video monitor. The example, the video display monitor 34 can be used to display the user interfaces shown in FIGS. 2A and 2B. The information panel 36 can be a back-lit, silk screened glass panel with lettering to indicate general game information comprising, for example, a game denomination (e.g. $0.25 or $1). The bill validator 30, player-input switches 32, video display monitor 34, and information panel 36 can be devices used to play a game on the game machine 2. The devices can be controlled by circuitry (e.g., the master gaming controller) housed inside the main cabinet 4 of the machine 2.

The gaming machine 2 can be operable to provide a play of a game of chance and/or a game of skill. The instances may be differentiated according to themes, sounds, graphics, type of game (e.g., slot game vs. card game), denomination, number of paylines, maximum jackpot, progressive or non-progressive, bonus games, etc. The gaming machine 2 can be operable to allow a player to select a game of chance and/or a game of skill to play from a plurality of instances available on the gaming machine 2. For example, the gaming machine 2 can provide a menu with a list of the instances of games that are available for play on the gaming machine 2 and a player can be able to select from the list a first instance of a game of chance and/or a game of skill that they wish to play.

The various instances of games available for play on the gaming machine 2 can be stored as game software on a mass storage device in the gaming machine 2 or can be generated on a remote gaming device and displayed on the gaming machine 2. In an aspect, the game software can be configured for performing the methods disclosed herein. The gaming machine 2 can executed game instructions, such as but not limited to video streaming instructions that allow the game to be displayed on the gaming machine 2. When an instance is stored on the gaming machine 2, the instance can be loaded from the mass storage device into a RAM for execution. In some cases, after a selection of an instance, the game instructions that allow the selected instance to be generated can be downloaded from a remote gaming device, such as another gaming machine.

The gaming machine 2 can comprise a top box 6, which can sit on top of the main cabinet 4. The top box 6 can house a number of devices, which can be used to add features to a game being played on the gaming machine 2, can comprise speakers 10, 12, 14, a ticket printer 18, a key pad 22, a florescent display 16, a card reader 24, and a video display screen 42. The ticket printer 18 can be used to print tickets for a cashless ticketing system, such as print bar-coded ticket 20. For example, the ticket printer 18 can be used to print a ticket in use with the game using the user interface shown in FIG. 1D. The key pad can be used for entering player tracking information. The florescent display 16 can be used for displaying player tracking information. For example, the florescent display 16 can be used to display player tracking information for a player playing the game using the user interface shown in FIG. 1D. The card reader 24 can be used for entering a magnetic striped card comprising player tracking information. For example, the card reader 24 can be used to add credits for playing the game using the user interfaces shown in FIGS. 2A and 2B. Further, the top box 6 can house different or additional devices than shown in FIG. 1A. For example, the top box 6 can comprise a bonus wheel or a back-lit silk screened panel which can be used to add bonus features to the game being played on the gaming machine. As another example, the top box 6 can comprise a display for a progressive jackpot offered on the gaming machine. During a game, these devices can be controlled and powered, at least in part, by circuitry (e.g. a master gaming controller) housed within the main cabinet 4 of the gaming machine 2.

It is to be understood that gaming machine 2 is but one example from a wide range of gaming machine designs on which the methods and systems described herein can be implemented. For example, not all suitable gaming machines have top boxes or player tracking features. Further, some gaming machines have only a single game display-mechanical or video, while others are designed for bar tables and have displays that face upwards. As another example, a game can be generated on a host computer and can be displayed on a remote terminal or a remote gaming device. The remote gaming device can be connected to the host computer via a network of some type such as a local area network, a wide area network, an intranet or the Internet. The remote gaming device can be a portable gaming device such as but not limited to a cell phone, a personal digital assistant, or a wireless game player. Images rendered from 3-D gaming environments can be displayed on portable gaming devices that are used to play a game of chance and/or a game of skill. Further a gaming machine or server can comprise gaming logic for commanding a remote gaming device to render an image from a virtual camera in a 3-D gaming environment stored on the remote gaming device and to display the rendered image on a display located on the remote gaming device. Thus, those of skill in the art will understand that the systems and methods described herein can be deployed on most any gaming machine now available or hereafter developed.

In an aspect, the gaming machine 2 can be implemented with special features and/or additional circuitry that differentiates them from general-purpose computers (e.g., desktop personal computers (PCs) and laptops). Gaming machines can be highly regulated to ensure fairness and, in many cases, gaming machines are operable to dispense monetary awards of multiple millions of dollars. Therefore, to satisfy security and regulatory requirements in a gaming environment, hardware and software architectures can be implemented in gaming machines that differ significantly from those of general-purpose computers. For example, the gaming machine 2 can employ one or more hardware/software components and architectures such as watchdog timers, voltage monitoring systems, state-based software architecture and supporting hardware, specialized communication interfaces, security monitoring and trusted memory.

A watchdog timer can be used in gaming machine 2 to provide a software failure detection mechanism. In a normally operating system, the operating software periodically accesses control registers in the watchdog timer subsystem to “re-trigger” the watchdog. Should the operating software fail to access the control registers within a preset timeframe, the watchdog timer will timeout and generate a system reset. Typical watchdog timer circuits contain a loadable timeout counter register to allow the operating software to set the timeout interval within a certain range of time.

The gaming machine 2 can comprise a power supply with voltage monitoring circuitry comprising two thresholds of control. The first threshold can generate a software event that can be detected by the operating software and an error condition generated. This threshold is triggered when a power supply voltage falls out of the tolerance range of the power supply, but is still within the operating range of the circuitry. The second threshold can be set when a power supply voltage falls out of the operating tolerance of the circuitry. In this case, the circuitry generates a reset, halting operation of the computer.

The standard method of operation for game software is to use a state machine. Different functions of the game (bet, play, result, points in the graphical presentation, etc.) can be defined as a state. When a game moves from one state to another, critical data regarding the game software is stored in a custom non-volatile memory subsystem. This can ensure the player's wager and credits are preserved and to minimize potential disputes in the event of a malfunction on the gaming machine 2.

In general, the gaming machine 2 does not advance from a first state to a second state until critical information that allows the first state to be reconstructed is stored. This feature allows the game to recover operation to the current state of play in the event of a malfunction, loss of power, etc. that occurred just prior to the malfunction. After the state of the gaming machine 2 is restored during the play of a game of chance and/or a game of skill, game play may resume and the game may be completed in a manner that is no different than if the malfunction had not occurred. Typically, battery backed RAM devices can be used to preserve this critical data although other types of non-volatile memory devices may be employed.

As described in the preceding paragraph, when a malfunction occurs during a game of chance and/or a game of skill, the gaming machine 2 may be restored to a state in the game of chance just prior to when the malfunction occurred. The restored state may include metering information and graphical information that was displayed on the gaming machine 2 in the state prior to the malfunction. When a malfunction has occurred after the player has made one or more selections, the gaming machine 2 may be restored to a state that shows the graphical presentation at just prior to the malfunction, including an indication of selections that have already been made by the player. In general, the gaming machine 2 may be restored to any state in a plurality of states that occur in the game of chance and/or game of skill that occurs while the game of chance and/or game of skill is played or to states that occur between the play of a game of chance and/or game of skill.

Game history information regarding previous games played such as an amount wagered, the outcome of the game and so forth may also be stored in a non-volatile memory device. The information stored in the non-volatile memory may be detailed enough to reconstruct a portion of the graphical presentation that was previously presented on the gaming machine and the state of the gaming machine 2 (e.g., credits) at the time the game of chance and/or game of skill was played. The game history information may be utilized in the event of a dispute. For example, a player may decide that in a previous game of chance and/or game of skill that they did not receive credit for an award that they believed they won. The game history information may be used to reconstruct the state of the gaming machine prior, during and/or after the disputed game to demonstrate whether the player was correct or not in their assertion.

The gaming device 2 can further comprise one or more interfaces, including serial interfaces to connect to serial devices, to connect to specific subsystems internal and external to the gaming device 2. The serial devices may have electrical interface requirements that differ from the “standard” Electronic Industries Association (EIA) 232 serial interfaces. These interfaces may include EIA 485, EIA 422, Fiber Optic Serial, optically coupled serial interfaces, current loop style serial interfaces, etc. In addition, to conserve serial interfaces internally in the gaming device 2, serial devices may be connected in a shared, daisy-chain fashion where multiple peripheral devices are connected to a single serial channel.

The serial interfaces can be used to transmit information using communication protocols that are unique to the gaming industry. For example, the Netplex™ system of International Game Technology (IGT) is a proprietary communication protocol used for serial communication between gaming devices. As another example, Serial Attached Small Computer System Interface (SCSI) (SAS) is a communication protocol used to transmit information, such as metering information, from a gaming machine to a remote device. Often SAS is used in conjunction with a player tracking system.

The gaming device 2 can alternatively be treated as a peripheral device to a casino communication controller and connected in a shared daisy chain fashion to a single serial interface. In both cases, the peripheral devices can be assigned device addresses. If so, the serial controller circuitry can implement a method to generate or detect unique device addresses.

The gaming device 2 can comprise security monitoring circuits to detect intrusion into the gaming machine 2 by monitoring security switches attached to access doors in the cabinet 4. Access violations can result in suspension of game play and can trigger additional security operations to preserve the current state of game play. These circuits also function when power is off by use of a battery backup. In power-off operation, these circuits continue to monitor the access doors of the gaming machine 2. When power is restored, the gaming machine 2 can determine whether any security violations occurred while power was off, e.g., via software for reading status registers. This can trigger event log entries and further data authentication operations by software.

The gaming device 2 can comprise trusted memory devices to ensure the authenticity of the software that may be stored on less secure memory subsystems, such as mass storage devices. Trusted memory devices and controlling circuitry are typically designed to not allow modification of the code and data stored in the memory device while the memory device is installed in the gaming device 2. The code and data stored in these devices may include authentication algorithms, random number generators, authentication keys, operating system kernels, etc. The purpose of these trusted memory devices is to provide gaming regulatory authorities a root trusted authority within the computing environment of the gaming device 2 that can be tracked and verified as original. This may be accomplished via removal of the trusted memory device from the gaming device 2 and verification of the secure memory device contents is a separate third party verification device. Once the trusted memory device is verified as authentic, and based on the approval of the verification algorithms contained in the trusted device, the gaming machine 2 is allowed to verify the authenticity of additional code and data that may be located in the gaming device 2, such as code and data stored on hard disk drives.

Returning to the example of FIG. 1A, when a user wishes to play the gaming machine 2, he or she can insert cash through the coin acceptor 28 or bill validator 30. Additionally, the bill validator 30 can accept a printed ticket voucher which can be accepted by the bill validator 30 as indicia of credit when a cashless ticketing system is used. At the start of the game, the player can enter playing tracking information using the card reader 24, the keypad 22, and/or the florescent display 16. Further, other game preferences of the player playing the game can be read from a card inserted into the card reader 24. During the game, the player can view game information using the video display 34. Other game and prize information can also be displayed in the video display screen 42 located in the top box 6.

During the course of a game, a player can be required to make a number of decisions, which affect the outcome of the game. For example, a player can vary his or her wager on a particular game, select a prize for a particular game selected from a prize server, or make game decisions which affect the outcome of a particular game, including the selection of one or more entities from a listing of entities. The player can make these choices using the player-input switches 32, the video display screen 34 and/or using some other device which enables a player to input information into the gaming machine. For example, the player can use the play-input switches 32 or the video display screen 34 to select entities during a round of the game using the user interfaces shown in FIGS. 2A and 2B. In some embodiments, the player can be able to access various game services, such as concierge services and entertainment content services, using the video display screen 34 and one or more input devices.

During certain game events, the gaming machine 2 can display visual and auditory effects that can be perceived by the player. These effects can add to the excitement of a game, which can make a player more likely to continue playing. Auditory effects can comprise various sounds that are projected by the speakers 10, 12, 14. Visual effects can comprise flashing lights, strobing lights, and/or other patterns displayed from lights on the gaming machine 2 and/or from lights within the separate mechanical (or electronic) gaming system 40. After the player has completed a game, the player can receive game tokens from the coin tray 38 or the ticket 20 from the printer 18, which can be used to engage games or to redeem a prize. For example, the player can receive the prize from the coin tray 38 or the ticket 20 from the printer 18 after completing the game using the user interfaces shown in FIGS. 2A and 2B. Further, the player can receive a ticket 20 for food, merchandise, or games from the printer 18.

A gaming network that can be used to implement some aspects of the systems and methods described herein is depicted in FIG. 1B. Gaming establishment 1001 can be any sort of gaming establishment, such as a casino, a card room, an airport, a store, etc. Gaming network 1077 can comprise more than one gaming establishment, all of which are networked to game server 1022. Gaming machine 1002, and the other gaming machines 1030, 1032, 1034, and 1036, can comprise a main cabinet 1006 and a top box 1004. The main cabinet 1006 can house the main gaming elements and can also house peripheral systems, such as those that utilize dedicated gaming networks. The top box 1004 can also be used to house these peripheral systems.

The master gaming controller 1008 can control the game play on the gaming machine 1002 according to instructions and/or game data from game server 1022 and/or stored within gaming machine 1002 and/or can receive or send data to various input/output devices 1011 on the gaming machine 1002. For example, the master gaming controller 1008 can be used to control the game play for the game using the user interface shown in FIG. 1D. In one embodiment, master gaming controller 1008 can comprise processor(s) and other apparatuses of the gaming machines described above. The master gaming controller 1008 can also communicate with a display 1010. The display 1010 can be used to display the user interfaces shown in FIGS. 2A and 2B.

A particular gaming entity can provide network gaming services. Thus, dedicated networks can connect gaming machines to host servers that track the performance of gaming machines under the control of the entity, such as for accounting management, electronic fund transfers (EFTs), cashless ticketing, such as EZPay™, marketing management, and data tracking, such as player tracking. Therefore, master gaming controller 1008 can also communicate with EFT system 1012, EZPay™ system, and player tracking system 1020. The systems of the gaming machine 1002 can communicate the data onto the network 1022 via a communication board 1018.

It will be appreciated by those of skill in the art that embodiments of the systems and methods described herein could be implemented on a network with more or fewer elements than are depicted in FIG. 1B. For example, player tracking system 1020 is not a necessary feature of some implementations of the systems and methods described herein. However, player tracking programs can help to sustain a game player's interest in additional game play during a visit to a gaming establishment and can entice a player to visit a gaming establishment to partake in various gaming activities. Player tracking programs provide rewards to players that typically correspond to the player's level of patronage (e.g., to the player's playing frequency and/or total amount of game plays at a given casino). Player tracking rewards may be free meals, free lodging and/or free entertainment. Player tracking information may be combined with other information that is now readily obtainable by a server-based gaming (SBG) system.

Moreover, data collection unit (DCU) 1024 and translator 1025 are not required for all gaming establishments 1001. However, due to the sensitive nature of much of the information on a gaming network (e.g., electronic fund transfers and player tracking data), the manufacturer of a host system usually employs a particular networking language having proprietary protocols. For instance, 10-20 different companies produce player tracking host systems where each host system may use different protocols. These proprietary protocols are usually considered highly confidential and not released publicly.

Further, gaming machines are made by many different manufacturers. The communication protocols on the gaming machine can be hard-wired into the gaming machine and each gaming machine manufacturer can utilize a different proprietary communication protocol. A gaming machine manufacturer can also produce host systems, in which case their gaming machines are compatible with their own host systems. However, in a heterogeneous gaming environment, gaming machines from different manufacturers, each with its own communication protocol, can be connected to host systems from other manufacturers, each with another communication protocol.

A network device that links a gaming establishment with another gaming establishment and/or a central system will sometimes be referred to herein as a “site controller.” Here, site controller 1042 can provide this function for gaming establishment 1001. The site controller 1042 can be connected to a central system and/or other gaming establishments via one or more networks, which can be public or private networks. Among other things, the site controller 1042 can communicate with game server 1022 to obtain game data, such as ball drop data, bingo card data, etc. For example, the site controller 1042 can communicate with the game server 1022 to obtain the game using the user interface shown in FIG. 1D.

Gaming machines 1002, 1030, 1032, 1034 and 1036 can be connected to a dedicated gaming network 1022. In general, the DCU 1024 can function as an intermediary between the different gaming machines on the network 1022 and the site controller 1042. In general, the DCU 1024 can receive data transmitted from the gaming machines and send the data to the site controller 1042 over a transmission path 1026. In some instances, when the hardware interface used by the gaming machine is not compatible with site controller 1042, a translator 1025 can be used to convert serial data from the DCU 1024 to a format accepted by site controller 1042. The translator 1025 can provide this conversion service to a plurality of DCUs.

Further, in some dedicated gaming networks, the DCU 1024 can receive data transmitted from site controller 1042 for communication to the gaming machines on the gaming network. The received data can be, for example, communicated synchronously to the gaming machines on the gaming network.

Here, clerk validation terminal (CVT) 1052 can provide cashless and cashout gaming services to the gaming machines in gaming establishment 1001. For example, CVT 1052 can provide cashless and cashout gaming services to gaming machines executing the game using the user interface shown in FIG. 1D. Broadly speaking, CVT 1052 can authorize and validate cashless gaming machine instruments (also referred to herein as “tickets” or “vouchers”), including but not limited to tickets for causing a gaming machine to display a game result and cash-out tickets. Moreover, CVT 1052 can authorize the exchange of a cashout ticket for cash. These processes will be described in detail below. In one example, when a player attempts to redeem a cash-out ticket for cash at cash-out kiosk 1044, cash-out kiosk 1044 can read validation data from the cash-out ticket and transmit the validation data to CVT 1052 for validation. The tickets can be printed by gaming machines, by the cash-out kiosk 1044, by a stand-alone printer, by the CVT 1052, etc. Some gaming establishments may not have a cash-out kiosk 1044. Instead, a cash-out ticket can be redeemed for cash by a cashier (e.g. of a convenience store), by a gaming machine and/or by a specially configured CVT.

FIG. 1C illustrates an example of a network device that can be configured for implementing the systems and methods described herein. Network device 1160 can comprise a master central processing unit (CPU) 1162, interfaces 1168, and a bus 1167 (e.g., a PCI bus). Interfaces 1168 can comprise ports 1169 appropriate for communication with the appropriate media. In some embodiments, one or more of interfaces 1168 can comprise at least one independent processor and, in some instances, volatile RAM. The independent processors can be, for example, application specific integrated circuits (ASICs) or any other appropriate processors. According to some such embodiments, these independent processors can perform at least some of the functions of the logic described herein. In some embodiments, one or more of interfaces 1168 can control such communications-intensive tasks as encryption, decryption, compression, decompression, packetization, media control, and management. By providing separate processors for the communications-intensive tasks, interfaces 1168 can allow the master microprocessor 1162 efficiently to perform other functions such as routing computations, network diagnostics, security functions, etc.

The interfaces 1168 can be provided as interface cards (sometimes referred to as “linecards”). The interfaces 1168 can control the sending and receiving of data packets over the network and can support other peripherals used with the network device 1160. Among the interfaces 1168 that can be provided are Fibre Channel (FC) interfaces, Ethernet interfaces, frame relay interfaces, cable interfaces, digital subscriber line (DSL) interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces can be provided, such as fast Ethernet interfaces, Gigabit Ethernet interfaces, Asynchronous Transfer Mode (ATM) interfaces, High-Speed Serial Interface (HSSI) interfaces, Packet-over-Synchronous Optical Networking (SONET) (POS) interfaces, Fiber Distributed Data Interface (FDDI) interfaces, Actuator Sensor Interface (ASI) interfaces, DigiCable Headend Expansion Interface (DHEI) interfaces and the like.

The CPU 1162 can be responsible for implementing specific functions associated with the functions of a desired network device. According to some embodiments, the CPU 1162 can accomplish the systems and methods described herein under the control of instructions, including an operating system and any appropriate applications. The CPU 1162 can be used to execute the game using the user interface shown in FIG. 1D.

The CPU 1162 can comprise one or more processors 1163 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, the processor 1163 can be specially designed hardware for controlling the operations of network device 1160. In a specific embodiment, a memory 1161 (such as non-volatile RAM and/or ROM) also can form part of the CPU 1162. However, there are many different ways in which memory could be coupled to the system. The memory 1161 can be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, etc. The memory 1161 can be used to store instructions for performing the game using the user interface shown in FIG. 1D.

Regardless of network device's 1160 configuration, it can employ one or more memories or memory modules (such as, for example, memory block 1165) configured to store data, program instructions for the general-purpose network operations and/or other information relating to the functionality of the techniques described herein. The program instructions can control the operation of an operating system and/or one or more applications, for example.

A device enabling practice of the systems and methods described herein can comprise: a display device; a player position input device; a memory for storing a plurality of instructions; and a processor for accessing and executing the plurality of instructions. These instructions, when executed by the processor, can cause the processor to operate in cooperation with the display device and the input device to perform activities that are physically and visually determinable, for a performance of a wagering event and/or game of skill.

Turning now to FIG. 2A, shown is an example user interface 200a for a round of gaming using historical performance data. The user interface 200a presents a listing of entities. In this example, the listing of entities is a listing of football players. As was described above, the listing of players can be selected randomly from a larger pool of players. Each of the players is grouped into one of three performance tiers 202a, 202b, and 202c, or a separate group 204 for quarterbacks. The user interface 200a solicits a selection of three players from each of the performance tiers 202a, 202b, and 202c, and a selection of one player from the quarterback group 204. Each of the selectable players is denoted by a user interface element 206. The user interface element 206 can correspond to a selectable button, a selectable touch-screen input, or other user interface element 206 facilitating the selection of a corresponding entity. In this example, each user interface element 206 lists a player name, a two-digit representation of a year, and a two- or three-letter abbreviation of a team of which the player was a member. Other information can also be presented to inform a user of the entities available for selection.

Moving on to FIG. 2B, shown is an example user interface 200b. Here, highlighted user interface elements 208 indicate which players have been selected by a user for inclusion in the given round of the game. Also shown is an input 210 for confirming the selection of players. On a “yes” selection from the input 210, the gaming machine presenting the user interface accesses the historical performance data for each of the selected players for a given performance period. In an aspect, performance period can be selected from multiple performance periods available for a selected player. In an aspect, the performance period can be selected according to a temporal constraint corresponding to the selected player. In this example, each player is listed with a corresponding two-digit year abbreviation. The performance period can comprise a game selected from a year or season denoted by the two-digit year abbreviation.

Using the historical performance data for each of the selected players, a payout is determined based on how many of the players meet or exceed a performance benchmark. In an aspect, the performance benchmark may be indicated to a user through a user interface 200a or 200b. The performance benchmark may also be hidden or otherwise unknown to a user. An example table of payouts is set forth in FIG. 3. Column 302 includes entries for a number of players who meet their respective performance benchmarks, with corresponding payouts in column 304. In this example, a user selecting five or fewer players whose performance benchmarks were met would receive no payout, and would receive increasingly greater payouts for each player above five who met their benchmark. In an aspect, the payout can also be based on a bet or number of credits used to initiate a round of a game.

In an aspect, the historical performance data for each of the selected players may be updated prior to determining how many of the players met or exceeded the performance benchmark. For example, the historical performance data for a group of quarterbacks may have changed in the intervening time period between the start of the game and the selection of the one or more of the entities. Updating the historical performance data would allow the game to be more accurate when determining whether the performance benchmark was met.

FIG. 4 is a flow chart 400 of an exemplary method. At step 402, a credit can be received from a user to initiate a round of a game. A credit can be a coin, a ticket, money, a token, credit card information, debit card information, and/or the like. At step 404, a listing of entities is provided to a user. In an aspect, this can include selecting the listing of entities from a larger pool of entities. In an aspect, this selection can be performed randomly. In an aspect, the entities may be organized into one or more groups, including performance tiers, player positions, or other groups. In such an aspect, providing the listing of entities can include selecting a number of entities from each of the groups for presentation to the user. In an aspect, each of the entities may be associated with a temporal constraint, such as a year, season, or other period. For example, an entity listing can include a player and a corresponding year from which a performance period will be selected, as will be described below. In such an embodiment, an entity can appear more than once in the listing of entities provided that it is associated with a different temporal constraint. For example, a given player can appear multiple times in the listing of entities provided that each entry in the listing corresponds to a different season or year.

Next, at step 406, a selection of entities is received from the user. The entities are selected by the user from the listing of entities provided in step 404. In an aspect, the entities can be selected according to the groups into which the entities are classified. For example, a predefined number of entities can be selected from each of the groups. At step 408, a performance period is selected for each of the selected entities. The performance period can include, for example, an individual game, a series of games, a season, or a time period. In aspects in which the entities are associated with a temporal constraint, the performance period can be selected from within a time defined by the temporal constraint. For example, if a player is associated with a year in the listing of entities, the performance period can be selected as a game or series from within the associated year. As another example, if a stock is associated with a year, the performance period can be selected as a day, week, month, quarter, or other period within the year. The performance period can be selected randomly, or according to one or more rules. For example, the performance period can be selected as a predefined game number in the respective temporal constraint of a given entity. As an example, the performance period can be selected as the first game in the respective season corresponding to each selected entity.

At step 410, historical performance data is selected for each of the selected entities reflecting their performance during their corresponding selected performance period. In an aspect, the historical performance data for each of the selected entities may be updated prior to proceeding to the next step, which would improve the accuracy of the method. For example, for a given player having a given game as its selected performance period, the historical performance data would indicate that player's performance during that game. Next, at step 412, a number of entities meeting a performance benchmark in their respective performance period is determined using the historical performance data. This can include, for each entity, determining if a particular benchmark is met according to their selected historical performance data. The performance benchmark can include, for example, points scored, distance covered, percentage of attempts that were successful, money earned, growth percentage, or other benchmark as can be appreciated. In an aspect, the performance benchmark can be the same across all entities, or differ between entities.

At step 414, a payout is provided based on the number of selected entities that met their corresponding performance benchmark. For example, in an aspect, no payout can be provided if the number of entities meeting their performance benchmark falls below a threshold. In an aspect, the payout can increase as the number of entities meeting their performance benchmark increases above the threshold. In an aspect the payout can be based on a bet, number of credits, or previous payout used to initiate the round of the game.

In an exemplary aspect, the methods and systems can be implemented on a computer 501 as illustrated in FIG. 5 and described below. By way of example, video gaming machine 2 of FIG. 1A can be a computer as illustrated in FIG. 5. Similarly, the methods and systems disclosed can utilize one or more computers to perform one or more functions in one or more locations. FIG. 5 is a block diagram illustrating an exemplary operating environment for performing the disclosed methods. This exemplary operating environment is only an example of an operating environment and is not intended to suggest any limitation as to the scope of use or functionality of operating environment architecture. Neither should the operating environment be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment.

The present methods and systems can be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that can be suitable for use with the systems and methods comprise, but are not limited to, personal computers, server computers, laptop devices, and multiprocessor systems. Additional examples comprise set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that comprise any of the above systems or devices, and the like.

The processing of the disclosed methods and systems can be performed by software components. The disclosed systems and methods can be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers or other devices. Generally, program modules comprise computer code, routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The disclosed methods can also be practiced in grid-based and distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

Further, one skilled in the art will appreciate that the systems and methods disclosed herein can be implemented via a general-purpose computing device in the form of a computer 501. The components of the computer 501 can comprise, but are not limited to, one or more processors 503, a system memory 512, and a system bus 513 that couples various system components including the one or more processors 503 to the system memory 512. The system can utilize parallel computing.

The system bus 513 represents one or more of several possible types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, or local bus using any of a variety of bus architectures. By way of example, such architectures can comprise an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, an Accelerated Graphics Port (AGP) bus, and a Peripheral Component Interconnects (PCI), a PCI-Express bus, a Personal Computer Memory Card Industry Association (PCMCIA), Universal Serial Bus (USB) and the like. The bus 513, and all buses specified in this description can also be implemented over a wired or wireless network connection and each of the subsystems, including the one or more processors 503, a mass storage device 504, an operating system 505, video gaming software 506, video gaming data 507, a network adapter 508, the system memory 512, an Input/Output Interface 510, a display adapter 509, a display device 511, and a human machine interface 502, can be contained within one or more remote computing devices 514a,b,c at physically separate locations, connected through buses of this form, in effect implementing a fully distributed system.

The computer 501 typically comprises a variety of computer readable media.

Exemplary readable media can be any available media that is accessible by the computer 501 and comprises, for example and not meant to be limiting, both volatile and non-volatile media, removable and non-removable media. The system memory 512 comprises computer readable media in the form of volatile memory, such as random access memory (RAM), and/or non-volatile memory, such as read only memory (ROM). The system memory 512 typically contains data such as the video gaming data 507 and/or program modules such as the operating system 505 and the video gaming software 506 that are immediately accessible to and/or are presently operated on by the one or more processors 503.

In another aspect, the computer 501 can also comprise other removable/non-removable, volatile/non-volatile computer storage media. By way of example, FIG. 5 illustrates the mass storage device 504 which can provide non-volatile storage of computer code, computer readable instructions, data structures, program modules, and other data for the computer 501. For example and not meant to be limiting, the mass storage device 504 can be a hard disk, a removable magnetic disk, a removable optical disk, magnetic cassettes or other magnetic storage devices, flash memory cards, CD-ROM, digital versatile disks (DVD) or other optical storage, random access memories (RAM), read only memories (ROM), electrically erasable programmable read-only memory (EEPROM), and the like.

Optionally, any number of program modules can be stored on the mass storage device 504, including by way of example, the operating system 505 and the video gaming software 506. Each of the operating system 505 and the video gaming software 506 (or some combination thereof) can comprise elements of the programming and the video gaming software 506. The video gaming data 507 can also be stored on the mass storage device 504. The video gaming data 207 can be stored in any of one or more databases known in the art. Examples of such databases comprise, DB2®, Microsoft® Access, Microsoft® SQL Server, Oracle®, mySQL, PostgreSQL, and the like. The databases can be centralized or distributed across multiple systems.

In another aspect, the user can enter commands and information into the computer 501 via an input device (not shown). Examples of such input devices comprise, but are not limited to, a keyboard, pointing device (e.g., a “mouse”), a microphone, a joystick, a scanner, tactile input devices such as gloves, and other body coverings, and the like These and other input devices can be connected to the one or more processors 503 via the human machine interface 502 that is coupled to the system bus 513, but can be connected by other interface and bus structures, such as a parallel port, game port, an IEEE 1394 Port (also known as a Firewire port), a serial port, or a universal serial bus (USB).

In yet another aspect, the display device 511 can also be connected to the system bus 513 via an interface, such as the display adapter 509. It is contemplated that the computer 501 can have more than one display adapter 509 and the computer 501 can have more than one display device 511. For example, the display device 511 can be a monitor, an LCD (Liquid Crystal Display), or a projector. In addition to the display device 511, other output peripheral devices can comprise components such as speakers (not shown) and a printer (not shown) which can be connected to the computer 501 via the Input/Output Interface 510. Any step and/or result of the methods can be output in any form to an output device. Such output can be any form of visual representation, including, but not limited to, textual, graphical, animation, audio, tactile, and the like. The display device 511 and computer 501 can be part of one device, or separate devices.

The computer 501 can operate in a networked environment using logical connections to one or more remote computing devices 514a,b,c. By way of example, a remote computing device can be a personal computer, portable computer, smartphone, a server, a router, a network computer, a peer device or other common network node, and so on. Logical connections between the computer 501 and a remote computing device 514a,b,c can be made via a network 515, such as a local area network (LAN) and/or a general wide area network (WAN). Such network connections can be through the network adapter 508. The network adapter 508 can be implemented in both wired and wireless environments. Such networking environments are conventional and commonplace in dwellings, offices, enterprise-wide computer networks, intranets, and the Internet.

For purposes of illustration, application programs and other executable program components such as the operating system 505 are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computing device 501, and are executed by the one or more processors 503 of the computer. An implementation of the video gaming software 506 can be stored on or transmitted across some form of computer readable media. Any of the disclosed methods can be performed by computer readable instructions embodied on computer readable media. Computer readable media can be any available media that can be accessed by a computer. By way of example and not meant to be limiting, computer readable media can comprise “computer storage media” and “communications media.” “Computer storage media” comprise volatile and non-volatile, removable and non-removable media implemented in any methods or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Exemplary computer storage media comprises, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer.

In some embodiments of this disclosure, outcome of gameplay (e.g., a winning wager or a losing wager) of a videogame can be represented with one or several video segments and/or other types of media assets (still images, audio segments, etc.) associated with the gameplay, as is disclosed in greater detail hereinafter. At least one of the video segment(s) can convey the outcome of the gameplay while entertaining an end-user. The videogame can be a game of chance, a game of skill, or a game that combines both skill-based components and chance-based components. While some embodiments are disclosed in connection with basketball, the disclosure is not limited in that respect. Indeed, the videogame and the gaming functionality of this disclosure can pertain to other sports, such as racing (e.g., Formula 1, NASCAR, or similar); baseball, soccer, cricket, and the like.

More concretely, FIG. 6 illustrates an example of an operational environment 600 for provision of media assets for presentation at a gaming device 605 during gameplay of a videogame (e.g., a game of chance), in accordance with one or more embodiments of this disclosure. The gaming device 605 includes computing resources, e.g., one or several processors, one or several memory devices, and the like. The gaming device 605 can be embodied in, for example, a mobile computing device or a tethered pseudo-stationary computing machine (such as a slot machine or a gaming kiosk). Such a mobile computing device can be a smartphone, a tablet computer, a laptop computer, a handheld gaming console, or another type of mobile computing device. The mobile computing device need not be portable. Indeed, in some embodiments, the mobile computing device can be embodied in an in-vehicle infotainment console.

To provide gameplay of the videogame, the gaming device 605 executes a gaming application 610. In one aspect, the gaming application 610 includes device-accessible instructions or device-readable data, or both, that can be accessed and/or executed by one or many processors to cause the gaming device 605 to provide gaming functionality corresponding to the videogame. The device-accessible instructions can include, in some configurations, computer-readable instructions or computer-executable instructions, or both. As is illustrated in FIG. 6, the gaming application 610 can be retained in a non-volatile storage device 640.

To execute the gaming application 610, the gaming device 605 can include a processing device 620 having one or many processors, each having at least one processing core. The one or more processors can be assembled in one or more computing chipsets. By executing the gaming application 610, the gaming device 605 can load an executable image of the gaming application 610 into a volatile memory device 630 from a non-volatile storage device 640. The volatile memory device 630 can be a system memory device, such as a RAM device of the gaming device 605, for example. The non-volatile storage device 640 can be embodied in a solid-state memory device, for example.

In one example of the videogame, execution of the gaming application 610 can cause a display device 650 to present a first user interface (UI) presenting a listing of sports players to an end-user. The display device 650 can be integrated into the gaming device 605, as is illustrated in FIG. 1. The first UI can include selectable first visual elements identifying respective sports players in the listing of sports players. In addition, or in some configurations, the first UI can include second selectable visual elements identifying teams of respective sports players in the listing of sports players. Further, or in other configurations, the first UI can include fourth selectable visual elements identifying a temporal constraint associated with a sports player. As mentioned, the temporal constraint can be, for example, a year, a season, or other time period that can serve as a constraint for selecting a performance period. Furthermore, or in yet other configurations, the first UI can include third selectable visual elements corresponding to pictures of respective sports players in the listing of sports players.

To present the listing of sports players, the gaming application 610, in execution, can access first data identifying a sports player, second data identifying a particular temporal constraint, and third data identifying the team of the sports player during a particular constraint. Such data can be accessed from one or more memory elements 644 (referred to as player data 644) containing various types of sports player data characterizing sports players. The gaming application 610, in execution, also can select one or a combination of first, second, third, and fourth selectable visual elements to be presented in the first UI. Such visual elements can be selected from one or more memory elements 642 (referred to as gaming media 642).

A listing of sports players—and selectable visual elements that represent such a listing—can be presented in numerous ways within the first UI. As an example, in one configuration, a group of combinations of the first, second, third, and fourth selectable visual elements can constitute the listing of sports players. The group of combinations can be presented in a particular layout within the first UI. Each one of such combination defines a sports player in the listing of sports players. Simply as an illustration, FIG. 7A presents a UI 705 that embodies the first UI, and includes a group of four combinations of first, second, third, and fourth selectable visual elements defining a listing of sports players. The group includes a first combination including a selectable image 708(1) of a first sports player, a selectable visual element 710(1) identifying the first sports player, a selectable visual element 712(1) identifying a team of the first sports player, and a selectable visual element 714(1) identifying a temporal constraint associated with the first sports player. The group also includes a second combination including a selectable image 708(2) of a second sports player, a selectable visual element 710(2) identifying the second sports player, a selectable visual element 712(2) identifying a team of the second sports player, and a selectable visual element 714(2) identifying a temporal constraint associated with the second sports player. The group further includes a third combination including a selectable image 708(3) of a third sports player, a selectable visual element 710(3) identifying the third sports player, a selectable visual element 712(3) identifying a team of the third sports player, and a selectable visual element 714(3) identifying a temporal constraint associated with the second sports player. The group still further includes a fourth combination including a selectable image 708(4) of a fourth sports player, a selectable visual element 710(4) identifying the fourth sports player, a selectable visual element 712(4) identifying a team of the fourth sports player, and a selectable visual element 714(4) identifying a temporal constraint associated with the second sports player.

As another example, in another configuration, the first UI can present a carousel element presenting a particular number of combinations of the first, second, third, and fourth selectable visual elements at a time. That particular number of combinations constitute a subset of the listing of sports players. Interaction of an end-user with the carousel element can permit perusing the listing of sports players by causing the carousel element to render visible other combinations of the first, second, third, and fourth selectable visual elements at a time. Those other combinations constitute other subsets of the listing of sports players. In some configurations, an end-user can swipe the carousel element one or several times in order to change the subset of the listing of sports players that is presented. In response to the swipe(s), the gaming application 610, in execution, can cause an animation to be presented, emulating movement of the carousel element. Simply as an illustration, FIG. 7B presents a UI 755 that that embodies the first UI and includes a carousel element 756 conveying a listing of sports players as is described above. The carousel element 756 can present a group of combinations of first, second, third, and fourth selectable visual elements defining the listing of sports players. As is shown in FIG. 7B, in some instances, that group includes a first combination including a selectable image 758(1) of a first sports player, a selectable visual element 760(1) identifying the first sports player, a selectable element 762(1) identifying a team of the first sports player, and a selectable visual element 764(1) identifying a temporal constraint associated with the first sports player. The group also includes a second combination including a selectable image 758(2) of a second sports player, a selectable visual element 760(2) identifying the second sports player, a selectable element 762(1) identifying a team of the second sports player, and a selectable visual element 764(2) identifying a temporal constraint associated with the second sports player. The group further includes a third combination including a selectable image 758(3) of a third sports player, a selectable visual element 760(3) identifying the third sports player, a selectable visual element 762(3) identifying a team of the third sports player, and a selectable visual element 764(3) identifying a temporal constraint associated with the third sports player. Interaction with the carousel element 756 can cause the gaming device 605 to redraw the UI 755 to present other combinations of first, second, third, and fourth selectable visual elements.

Regardless of the manner of presenting the listing of sports players in the first UI, the selectable visual elements presented in the first UI can be selected in response to an interaction between an end-user and a selectable visual element. In embodiments in which the display device 650 includes a touchscreen, the interaction can include the application of pressure to a portion of the touchscreen corresponding to a particular selectable visual element being selected. Thus, in one example, the particular selectable visual element can be selected by tapping or swiping such an element. In addition, or in other embodiments, the particular selectable visual element can be selected in response to a gesture relative to the particular selectable visual element.

Accordingly, a particular sports player in the listing of sports players being presented in the first UI can be selected by selecting a corresponding selectable visual element in the first UI. Thus, in execution, the gaming application 610 can obtain (e.g., receive or otherwise access) data identifying a selection of the particular sports player.

The first UI that presents the listing of sports players also can present a listing of performance benchmarks. Each one of the performance benchmarks can define a threshold performance in the sport to which the sports players in the listing of sports players pertain. The threshold performance, in some configurations, can be represented by one or many attributes identifying respective scoring metrics in the sports. Simply as an example, in basketball, a performance benchmark can identify a number of points and a number of three-point field goals. As such, a first attribute can correspond to the number of points and a second attribute can correspond to the number of three-point field goals. As part of a gameplay of the videogame corresponding to the gaming application 610, by selecting a particular performance benchmark, the particular performance benchmark can be associated with the particular sports player that has been selected. The association of the particular performance benchmark with the particular sports player can create a wager. The wager constitutes the gameplay. In some configurations, each performance benchmark in the listing of performance benchmarks identifies a number of points scored during a sports game and a number of specific plays during the sports game. Examples of a specific play include a three-point field goal attempt, a two-point field goal attempt, a free-throw attempt, and an assist. The specific play has a defined outcome; for example, “Goal” outcome or “No-Goal” (or “Miss” or “Fail”) outcome. Accordingly, an example of the particular performance benchmark that is selected can be 24 points and 5 three-point field goals.

The listing of performance benchmarks can be presented in numerous ways within the first UI. As an example, in one configuration, the first UI can include multiple selectable visual elements for respective ones of the listing of performance benchmarks. Thus, in some embodiments, a particular performance benchmark can be selected by tapping a corresponding selectable visual element, for example. In addition, or in other embodiments, the particular selectable visual element can be selected in response to a gesture relative to the corresponding selectable visual element. Simply as an illustration, with further reference to FIG. 7A, the UI 705 includes a group of four selectable visual elements arranged in a particular layout. Each one of those selectable visual elements identifies a performance benchmark. More specifically, the group includes a first selectable visual element 716(1) identifying a first performance benchmark; a second selectable visual element 716(2) identifying a second performance benchmark; a third selectable visual element 716(3) identifying a third performance benchmark; and a fourth selectable visual element 716(4) identifying a fourth performance benchmark.

As another example, in another configuration, the first UI can present a carousel element including multiple visual elements for respective ones of the listing of performance benchmarks. An end-user can swipe the carousel element one or several times in order to select a particular performance benchmark. In response to the swipe(s), the gaming application 610, in execution, can cause an animation to be presented, emulating movement of the carousel element. In some cases, the multiple visual elements can be selectable. After the swipe(s), an end-user can select a particular performance benchmark by selecting one of the selectable visual elements visible in the carousel element. In other cases, rather than actively selecting the particular benchmark after the swipe(s), the gaming application 610 can automatically select the particular performance benchmark. To that end, after termination of the animation responsive to the swipe(s), the gaming application 610 can determine that the particular performance benchmark is the performance benchmark corresponding to one of the visual elements visible in the carousel element. Simply as an illustration, with further reference to FIG. 7B, the UI 755 includes a carousel element 768 conveying a listing of performance benchmarks as is described above. As is illustrated, the carousel element 768 can present a group of visual elements (selectable or otherwise) defining at least a subset of the listing of benchmarks. As is shown in FIG. 7B, in some instances, the group includes a first selectable visual element 766(1) identifying a first performance benchmark; a second selectable visual element 766(2) identifying a second performance benchmark; a third selectable visual element 766(3) identifying a third performance benchmark; and a fourth selectable visual element 766(4) identifying a fourth performance benchmark.

Regardless of the manner of presenting performance benchmarks in the first UI, the gaming application 610, in execution, can obtain (e.g., receive or otherwise access) data identifying a selection of a particular performance benchmark.

The gaming application 610, in execution, also can select a particular performance period (e.g., a game within a tournament season) consistent with a temporal constraint corresponding to a selected particular sports player. The performance period can be selected randomly from a pool of performance periods, in some embodiments. The performance period also can be selected by applying one or many selection rules, in other embodiments. As an example, the gaming application 610, in execution, can select a particular sports game from some or all sports games within one or several seasons of a sports competition. Selection of the performance period also constitutes a gameplay.

The gaming application 610, in execution, can determine if the selected particular sports player meets or exceeds the selected particular performance benchmark during the selected particular performance period. To that end, in some embodiments, the gaming application 610, in execution, can obtain historical performance data and can then determine, using the historical performance data, the performance of the particular sports player during the selected particular performance period. The gaming application 610, in execution, can then compare such a performance to the selected particular performance benchmark. The outcome of that comparison can establish if the selected particular sports player meets or exceeds the selected particular performance benchmark.

In some configurations, the gaming application 610 can obtain the historical performance data from the game server 1022. The historical performance data can be retained in a data repository 664 (referred to as game data 664) containing various types of game data. The gaming application 610, in execution, can generate a request 652 for the historical performance data. The request 652 can be embodied in a uniform resource locator (URL), in some cases. The request also can be embodied in a hypertext transfer protocol (HTTP) request message, in other cases. Both the URL and the HTTP request message can be formatted to identify the selected particular sports player and particular performance period. Execution of the gaming application 650 also can cause a network adapter 624 of the gaming device 605 to send the request 652 to the game server 1022. The functionality of the network adapter 624 can be similar, or the same, as the functionality of the network adapter 508 (FIG. 5). The request 652 can be sent by means of one or more networks 660 (e.g., wireless network(s), wireline network(s), or a combination of both).

The game server 1022 can receive the request 652 and, in response, can supply historical performance data corresponding to the selected particular sports player and the selected particular performance period that are conveyed in the request 652. To that point, the game server 1022 can identify, using the request 652, the selected particular sports player and the selected particular performance period. The game server 1022 can then extract such historical performance data from the game data 664. The game server 1022 can generate a response message containing the historical data. The response message can be embodied in an HTTP response message, for example. The game server 1022 can then send the response message to the gaming device 605 by means of at least one of the network(s) 660. The network adapter 624 can receive the response message. As is illustrated in FIG. 6, the response message can be embodied in, or can include, a report 668. As an example, the sports player can be a basketball player and the performance period can be a game in the playoffs of a particular season. Thus, in this example, the historical performance data—and therefore the report 668—can include data identifying one or a combination of points scored, three-point field goals, free throws, number of rebounds, number of violations, number of fouls, ball possession time, or similar.

In response to a determination that the selected particular sports player meets or exceeds the selected particular performance benchmark during the particular performance period, execution of the gaming application 610 can cause the display device 650 to present a sequence of video segments. Each video segment in the sequence of video segments can represent an attribute of the selected particular performance benchmark. More specifically, each video segment in the sequence of video segments corresponds to a defined play within the particular performance period. The defined play has a particular outcome. For instance, the defined play can be a three-point field goal attempt, and the particular outcome can be “Goal” or “No-Goal” (or miss) for that three-pointer attempt. Each video segment in the sequence of video segments has a defined duration. The duration of a video segment can be in a range from approximately two seconds to approximately 20 seconds. The duration of the video segment can be based on the complexity of the defined play conveyed by the video segment. For example, a video segment corresponding to a defined play involving substantial passing between the particular sports player and other players before a two-point field goal can have a longer duration than another video segment corresponding to a defined play involving a free throw.

Accordingly, presentation of the sequence of video segments provides a visual representation of the selected performance benchmark. Thus, presentation of the sequence of video segments conveys the outcome of a gameplay.

Execution of the gaming application 610 can cause the display device 650 to present a second UI including an area where the sequence of video segments can be presented. In some configurations, execution of the gaming application 610 also can cause an audio output unit (not depicted in FIG. 6) to generate sound corresponding to audio data contained in respective audio channels of the sequence of video segments. Simply as an illustration, FIG. 8 presents an example of a UI 805 embodying the second UI. The UI 805 includes first visual elements 806 identifying the selected particular player, and a visual element 810 identifying the selected performance benchmark. The UI 805 also includes a video area 820 where the gaming application 610, in execution, can playback the sequence of video segments.

To cause the presentation of the sequence of video segments, in some embodiments, the gaming application 610 in execution can obtain the sequence of video segments from a content source subsystem 670 remotely located relative to the gaming device 605. The content source subsystem 670 can provide various types of digital content assets, including video assets, such as animations or other types of video segments. To obtain the sequence of video segments, the gaming application 610, in execution, can generate a request 654 for the sequence of video segments. The request can be embodied in a URL, in some cases. The request also can be embodied in an HTTP request message, in other cases. Both the URL and the HTTP request message can be formatted to identify the selected particular performance period, the selected particular performance benchmark, and the selected particular sports player. Because the report 668 can be available to the gaming application 610, the request 654 also can be formatted to include an outcome attribute indicating if the particular sports player meets or exceeds the particular performance benchmark.

In addition, the gaming application 650, in execution, can cause the network adapter 624 of the gaming device 605 to send the request 654 to the content source subsystem 670. The request 654 can be sent by means of one or more networks 660 (e.g., wireless network(s), wireline network(s), or a combination of both).

The content source subsystem 670 can include a distribution unit 672 that can receive the request 654. In response, the distribution unit 672 can supply a video sequence 682a based on the request 654. To that end, the distribution unit 672 can identify, using the request 654, the particular sports player, the particular performance period, the performance benchmark, and the outcome attribute conveyed in the request 654. The distribution unit 672 can then identify a group of video segments corresponding to the sports player and the performance period. To that, the distribution unit 672 can access a content repository 674 containing multiple video segments, including video segments 676(j), where each one of the video segments 676(j) corresponds to a sports player and a performance period. Here, j and N are natural numbers, with j=1, 2, N−1, N. The video segments 676(j) can be categorized according to the performance period (e.g., game 18 in the 2004 season). In addition, each one of the video segments 676(j) can be tagged with first data identifying the sports player; second data identifying a play (e.g., three-point field goal attempt); and third data identifying an outcome of the play. Further, in some configurations, at least one of the video segments 676(j) can include respective audio channels carrying audio data defining sound corresponding to the images in a respective video segment. As is illustrated in FIG. 6, the content repository 674 can be included in the content source subsystem 670.

The distribution unit 672 can then compose a video sequence 682 in response to the request 654. To accomplish that, the distribution unit 672 can access the outcome attribute included in the request 654, and can then identify a group of video segments consistent with the outcome attribute. In an instance in which the performance attribute indicates that the performance benchmark identified in the request 654 is not met or exceeded, the distribution unit 672 can identify one or several video segments, each tagged with data identifying a “No-Goal” (or “Miss” or “Fail”) outcome for a particular type of play corresponding to the performance benchmark identified in the request 654. For instance, the performance benchmark can include a number of three-point field goals, and thus, the distribution unit 672 can identify one or many video segments corresponding to failed attempts at three-point field goals. In the alternative, in an instance in which the outcome attribute indicates that the performance benchmark identified in the request 654 is met or exceeded, the distribution unit 672 can identify one or several other video segments, each tagged with data identifying a “goal” (or “success”) outcome for a particular type of play corresponding to the performance benchmark. For instance, as mentioned, the performance benchmark can include a number of three-point field goals. Thus, the distribution unit 672 can identify one or many video segments corresponding to successful attempts at three-point field goals.

Accordingly, for a particular outcome attribute (either “Goal” or “Miss,” for example), the distribution unit 672 can select a group of the identified video segment(s). The selected group constitutes the video sequence responsive to the request 654. The particular video segment(s) can be selected in numerous ways. In some configurations, the distribution unit 672 can select all the identified video segment(s) to form the group. In addition, or in other configurations, the distribution unit 672 can randomly select one or many video segments from the identified video segment(s) to form the group.

Further, or in yet other configurations, the content source platform 670 also can include a classification unit (not shown in FIG. 6) that can generate respective scores for the identified video segment(s) by applying a trained machine-learning model to such video segment(s). Each score represents an entertainment appeal of a video segment. For instance, the score can range from 0 to 1, where “1” indicates a video segment with broad appeal amongst end-users and “0” indicates that the video segment has negligible appeal. The classification unit can then select particular video segments having scores greater than or equal to a threshold score. The distribution unit 674 can use the selected video segment(s) to form the group of video segments.

The distribution unit 672 can send the generated video sequence 682a to the gaming device 605. The network adapter 624 can receive the video sequence 682a. The video sequence 682a can be sent by means of at least one of the network(s) 660. The gaming device 605, in execution, can receive the video sequence 682a and can retain the video sequence 682a in the volatile memory device 630 (e.g., a main memory device, such as a RAM device). The video segment 682 can be retained as video sequence 632 within the non-volatile memory device 630, in some cases. Execution of the gaming application 610 can result in the video sequence 682a being accessed and sent to the display device 650 for presentation.

In further response to the selected particular sports player satisfying the selected particular performance benchmark during the particular performance period, execution of the gaming application 610 can provide a payout based at least on the selected particular performance benchmark. In some embodiments, the gaming application 605, in execution, can apply one or many payout rules to generate payout data defining the payout. The payout rule(s) can be retained in a memory element 648 (referred to as payout rule(s) 648).

In some instances, the gaming application 610, in execution, determines that the selected particular sports player fails to satisfy the selected particular performance benchmark during the selected particular performance period, In response to such a determination, execution of the gaming application 610 also can cause the display device 650 to present a sequence of video segments. Again, each video segment in the sequence of video segments can represent an attribute of the selected particular performance benchmark. More specifically, as mentioned, each video segment in the sequence of video segments corresponds to a defined play within the particular performance period. The defined play has a particular outcome. For instance, the defined play can be a three-point field goal attempt and the particular outcome can be a “Goal” outcome or a “No-Goal” (or “Fail”) outcome of that three-pointer attempt. Each video segment in the sequence of video segments has a defined duration. The duration of a video segment can be in a range from approximately two seconds to approximately 20 seconds, for example. As further mentioned, the duration of the video segment can be based on the complexity of the defined play conveyed by the video segment.

In those instances, to cause the display device 650 to present a sequence of video segments, the gaming device 605 can send another request 654 to the content source subsystem 670. Because in those instances the selected particular sports player fails to meet or exceed the selected particular performance benchmark during the selected particular performance period, the outcome attribute included in the request 654 can indicate that the selected particular sports player fails to meet or exceed the selected particular performance benchmark. Such a request 654 also can be formatted to identify the selected particular sports player, the selected particular performance benchmark, and the selected performance period. In response to such a request 654, the content source subsystem 670 can generate a video sequence 682b that is different from the video sequence 682a. The video sequence 682b can be generated in the same manner as the video sequence 682a is generated, in accordance with aspects disclosed above.

Further, in those instances, execution of the gaming application 610 can cause the display device 650 to present a no-payout message. In some configurations, the no-payout message can be based at least on the selected particular performance benchmark. Simply as an illustration, the no-payout message can be included within the gaming media 642. The no-payout message can include a group of visual elements identifying one or many sports players meeting or exceeding the selected particular performance benchmark during the selected particular performance period. The group of visual elements can include, for example, graphical elements or textual elements, or both.

FIG. 9 is a flow chart of an example of a method 900 for supplying video segments as part of gameplay of a videogame, according to one or more embodiments of this disclosure. It is noted that the example method 900 is not limited to supplying video segments and, in some embodiments, one or more other media assets can be provided instead of, or in addition to, the video segments. A gaming device can perform, entirely or partially, the method 600. To that end, the gaming device has various computing resources. Specifically, the gaming device can include at least one processor that can implement (e.g., compile, execute, compile and execute, etc.) one or several blocks of the example method 900. The gaming device also can include at least one memory devices, other types of computing resources, or a combination thereof. Such processor(s), memory device(s), and computing resource(s), individually or in a particular combination, can permit the gaming device to implement the example method 900, entirely or partially. Those computing resources can include, for example, a firmware, an operating system; software or other program code; CPU(s), GPU(s), or other types of processing devices; interface(s) (I/O interface devices, programming interface(s) (such as APIs, etc.); a controller device; a combination of the foregoing; or similar. The computing resources available to the gaming device also can include downstream communication bandwidth and/or upstream communication bandwidth. The gaming device can be embodied in the gaming device 605 (FIG. 6), in some cases.

Examples of the gaming device include a mobile computing device (such as a smartphone, a table computer, a handheld gaming console) and a tethered pseudo-stationary machine (such as a slot machine or a gaming kiosk). As mentioned, the mobile computing device can be a smartphone, a tablet computer, a laptop computer, a handheld gaming console, an in-vehicle infotainment console, or another type of mobile computing device.

At block 910, the gaming device can provide a listing of sports players to an end-user. To that end, in some embodiments, a display device associated with the gaming device can present a first UI presenting the listing of players. The first UI can include, for example, selectable visual elements defining the listing of players. In one example, the first UI user interface can include the UI 755 (FIG. 7B). The display device can be integrated into the gaming device or can be functionally coupled thereto. In instances in which the gaming device is embodied in the gaming device 605 (FIG. 6), the display device can be embodied in the display device 650 (FIG. 6).

At block 915, the gaming device can provide a listing of performance benchmarks to an end-user. To that end, in some embodiments, the first UI presented at block 910 also can present the listing of performance benchmarks. The first UI can include, for example, second selectable visual elements defining the listing of performance benchmarks.

At block 920, the gaming device can receive a selection of a particular sports player from the listing of sports players. Receiving the selection of the particular sports player can include obtaining data identifying particular sports player. In some embodiments, the data can be obtained as a result of selection of a selectable visual element corresponding to the particular sports player, in accordance with aspects described herein.

At block 930, the gaming device can receive a selection of a particular performance benchmark from a listing of benchmarks. Receiving the selection of the performance benchmark can include obtaining data identifying the particular performance benchmark. In some embodiments, the data can be obtained as a result of selection of a particular second selectable visual element corresponding to the performance benchmark, in accordance with aspects described herein.

At block 940, the gaming device can select a performance period. In some configurations, performance period can be selected randomly from a pool of performance periods. In one example, the gaming device can select a particular game within a pool of games spanning one or several seasons of a sports competition (e.g., a tournament season, playoff season, or the like).

At block 950, the gaming device can determine if the particular sports player satisfies the particular performance benchmark during the performance period. To that end, in some embodiments, the gaming device can obtain historical performance data, and can then determine, using the historical performance data, the performance of the particular sports player during the selected performance period. The gaming device can then compare such a performance to the particular performance benchmark. In response to a positive determination (“Yes” branch in FIG. 9), the flow of the example method 900 can continue to block 960, where the gaming device can cause the display device to present a first sequence of video segments. Further in response to the positive determination, the gaming device can provide a payout based at least on the performance benchmark at block 970.

In some configurations, causing the display device to present the first sequence of video segments can include obtaining one or many of the video segments in the first sequence, and directing the display device to display the first sequence of video segments. In some configurations, the gaming device also can cause a speaker device or another type of audio output device to generate sound corresponding to audio data contained in respective audio channels of the first sequence of video segments. The sequence of video segments can be obtained from a content source subsystem, as is disclosed hereinbefore. The content source subsystem can include one or several service devices that can be functionally coupled to one or several content repositories. In some embodiments the content source subsystem can be embodied in the content source subsystem 670 (FIG. 6).

In response to a negative determination at block 950 (“No” branch in FIG. 9), the flow of the example method 900 can continue to block 980, where the gaming device can cause the display device to present a second sequence of video segments. Again, in some configurations, causing the display device to present the second sequence of video segments can include obtaining one or many of the video segments in the second sequence, and directing the display device to display the second sequence. In some configurations, the gaming device also can cause a speaker device or another type of audio output device to generate sound corresponding to audio data contained in respective audio channels of the second sequence of video segments. The second sequence of video segments can be obtained from a content source subsystem, as is disclosed hereinbefore.

Further, in some embodiments, in response to the negative determination, the gaming device can cause the display device to present a no-payout message at block 990. In some configurations, the no-payout message can be based at least on the performance benchmark. In those configurations, simply as an example, the no-payout message can include a group of markings identifying one or many sports players from the listing of sports players, the identified player(s) satisfying the performance benchmark during the performance period.

FIG. 10 is a flowchart of an example of a method 1000 for composing a sequence of video segments to be supplied as part of gameplay of a videogame, according to one or more embodiments of this disclosure. It is noted that the example method 1000 is not limited to video segments and, in some embodiments, one or more other media assets can be contemplated instead of, or in addition to, the video segments. A computing system can perform, entirely or partially, the method 1000. The example method 1000 can be implemented, entirely or partially, by a computing system having various computing resources. The computing system can include, for example, the distribution unit 672. The computing system has at least one processor that can implement one or several blocks of the example method 1000. The computing system also can include one or many memory devices, other types of computing resources, or a combination thereof. Such processor(s), memory device(s), and computing resource(s), individually or in a particular combination, can permit the computing system to implement the example method 1000, entirely or partially. The computing resources can include operating system(s); software for configuration and/or control of a virtualized environment; firmware; CPU(s); GPU(s); TPU(s); virtual memory; disk space; interface(s) (I/O interface devices, programming interface(s) (such as APIs, etc.); controller devices(s); a combination of the foregoing; or similar. The computing resources available to the computing system also can include downstream communication bandwidth and/or upstream communication bandwidth. The computing system can embody, or can constitute, the content platform subsystem 670 (FIG. 6) in some cases.

In some scenarios, one or several blocks of the example method 1000 can be implemented in a distributed fashion by two or more computing devices contained in the computing system. Each one of the two or more computing devices can have at least one processor or can be functionally coupled to at least one processor, where such processor(s) can implement at least one of the block(s). The computing device(s) also can include memory device(s) and/or other computing resources. Regardless of the example method 1000 being implemented by a distributed or non-distributed computing system, the at least one processor can be functionally coupled to at least one memory device or other types of computer-readable non-transitory storage media.

At block 1010, the computing system can receive a request for the sequence of video segments based on a player, a performance benchmark, and a performance period. For example, the request can be embodied in, or can include, the request 654 (FIG. 6). As mentioned, the request can be embodied in a URL, in some cases. The request also can be embodied in an HTTP request message, in other cases. Both the URL and the HTTP request message can be formatted to identify the player, the performance benchmark, the performance period, and an outcome attribute in accordance with aspects described herein. Accordingly, the request can include first data identifying the player, second data identifying the performance benchmark, third data identifying the performance period, and fourth data representing the performance of the player relative to the performance benchmark.

At block 1020, the computing system can identify, using the request, one or many video segments within multiple video segments corresponding to the player and the performance period identified by the request (e.g., request 654 (FIG. 6). The multiple video segments can be retained in one or many content repositories within the computing system. The multiple video segments can be embodied in, for example, the video segments 676(j) (FIG. 6). The one or many repositories can be embodied in, or can include, the content repository 674 (FIG. 6).

At block 1030, the computing system can select at least one particular video segment from the one or more video segments. The particular video segment(s) can be selected in numerous ways, as is disclosed herein.

At block 1030, the computing system can generate the sequence of video segments using the at least one first video segment. Depending on the request that is received, the sequence of video segments can be the video sequence 682a (FIG. 6) or the video sequence 682b (FIG. 6), for example.

The methods and systems can employ Artificial Intelligence techniques such as machine learning and iterative learning. Examples of such techniques include, but are not limited to, expert systems, case based reasoning, Bayesian networks, behavior based AI, neural networks, fuzzy systems, evolutionary computation (e.g. genetic algorithms), swarm intelligence (e.g., ant algorithms), and hybrid intelligent systems (e.g. Expert inference rules generated through a neural network or production rules from statistical learning).

While the methods and systems have been described in connection with preferred embodiments and specific examples, it is not intended that the scope be limited to the particular embodiments set forth, as the embodiments herein are intended in all respects to be illustrative rather than restrictive.

Unless otherwise expressly stated, it is in no way intended that any method set forth herein be construed as requiring that its steps be performed in a specific order. Accordingly, where a method claim does not actually recite an order to be followed by its steps or it is not otherwise specifically stated in the claims or descriptions that the steps are to be limited to a specific order, it is in no way intended that an order be inferred, in any respect. This holds for any possible non-express basis for interpretation, including: matters of logic with respect to arrangement of steps or operational flow; plain meaning derived from grammatical organization or punctuation; the number or type of embodiments described in the specification.

It will be apparent to those skilled in the art that various modifications and variations can be made without departing from the scope or spirit. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit being indicated by the following claims.

Number	Name	Date	Kind
20040029627	Hannan et al.	Feb 2004	A1
20070087804	Knowles et al.	Apr 2007	A1
20090156311	Ng et al.	Jun 2009	A1
20110246889	Moore	Oct 2011	A1
20140200070	Bahou	Jul 2014	A1
20140315614	Granich et al.	Oct 2014	A1
20180015360	Litman	Jan 2018	A1
20180190076	Lukasik	Jul 2018	A1
20190221072	Litman	Jul 2019	A1

	Number	Date	Country
Parent	17018640	Sep 2020	US
Child	18194956		US
Parent	15862440	Jan 2018	US
Child	16899238		US

	Number	Date	Country
Parent	16899238	Jun 2020	US
Child	17018640		US

Supply of video segments based on gameplay of a videogame

Information

Patent Number

Date Filed

Date Issued

Inventors

Original Assignees

Examiners

Agents

CPC

Field of Search

CPC

International Classifications

Disclaimer

Term Extension

Abstract

Description

Claims

CROSS REFERENCE TO RELATED PATENT APPLICATION

US Referenced Citations (9)

Non-Patent Literature Citations (6)

Related Publications (1)

Provisional Applications (1)

Continuations (2)

Continuation in Parts (1)

Entry
Non-Final Office Action on U.S. Appl. No. 17/848,041 dated Sep. 14, 2023.
International Preliminary Report on Patentability on PCT Appl. No. mailed Mar. 23, 2023.
International Search Report and Written Opinion on PCT Appl. No. PCT/US2021/049828 mailed Jan. 28, 2022.
Non-Final Office Action on U.S. Appl. No. 17/018,640 dated Jun. 2, 2022.
Notice of Allowance on U.S. Appl. No. 17/018,640 dated Nov. 25, 2022.
Notice of Allowance on U.S. Appl. No. 17/848,041 dated Jan. 10, 2024.