Live event information display method, system, and apparatus

Abstract

A method and system for using artificial intelligence (AI) to assess and adjust the betting odds for live game wagers before they are presented to users based on correlations between various parameters and user betting behavior, and to adjust the betting odds while the betting window is open based on how users are currently betting compared to expected user betting behavior.

Description

LIVE EVENT INFORMATION DISPLAY METHOD, SYSTEM, AND APPARATUSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority from U.S. Provisional Application No. 63 / 500,356, filed on May 5, 2023, U.S. Provisional Application No. 63 / 500,369, filed on May 5, 2023, U.S. Provisional Application No. 63 / 592,257, filed on October 23, 2023, U.S. Provisional Application No. 63 / 592,258, filed on October 23, 2023, and U.S. Provisional Application No. 63 / 592,259, filed on October 23, 2023, the entire contents of which are incorporated herein by reference.BACKGROUND

[0001] The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to implementations of the claimed technology.

[0002] When odds are calculated for a wager objective data and statistics are used so that the payout is proportional to the actual chances of the outcome. A problem is that people do not usually place wagers based on objective data, which can result in largely one sided bets that could result in a loss for the house. Another problem is that when demand one side of a wager greatly exceeds the demand expected based on the odds, the house misses out on profit it could have made by offering lower odds. Yet another problem is that errors in the original odds calculation could be exploited by clever users if the odds aren't subsequently adjusted.SUMMARY

[0003] Embodiments include methods, systems, and apparatuses for using artificial intelligence to adjust wagering odds for a live event in real time. One embodiment may include methods for adjusting odds based on betting behavior. The methods may include identifying, using artificial intelligence, a plurality of betting preferences for a user based on historical betting data associated with the user, selecting one or more wagers from a wagering market, analyzing one or more game dynamics and wagering market trends, determining a wager adjustment corresponding to the one or more selected wagers based on the plurality of betting preferences and the one or more game dynamics and wagering market trends, adjusting the one or more wagers based on the determined wager adjustment, and displaying the one or more adjusted wagers to the user.BRIEF DESCRIPTION OF THE FIGURES

[0002] Advantages of embodiments of the present invention will be apparent from the following detailed description of the exemplary embodiments. The following detailed description should be considered in conjunction with the accompanying figures in which:

[0003] FIG. 1 illustrates a system for artificial intelligence based live game probability calculation, according to an embodiment.

[0004] FIG. 2 illustrates a live event module, according to an embodiment.

[0005] FIG. 3 illustrates a live event database, according to an embodiment.

[0006] FIG. 4 illustrates a base module, according to an embodiment.

[0007] FIG. 5 provides an illustration of a probability module, according to an embodiment.

[0008] FIG. 6 illustrates a data module, according to an embodiment.

[0009] FIG. 7 illustrates a historic action database, according to an embodiment.

[0010] FIG. 8 illustrates a historic sensor database, according to an embodiment.

[0011] FIG. 9 illustrates a recommendations database, according to an embodiment.

[0012] FIG. 10 illustrates a probabilities database, according to an embodiment.

[0013] FIG. 11 illustrates an adjustment database, according to an embodiment.

[0014] FIG. 12 illustrates an adjustment database, according to another embodiment.

[0015] FIG. 13 illustrates a recommendations database, according to another embodiment.

[0016] FIG. 14A illustrates an example of a probabilities module, according to an embodiment.

[0017] FIG. 14B illustrates an example of a probabilities module, according to an embodiment.

[0018] FIG. 15 A illustrates another example of a probabilities module, according to an embodiment.

[0019] FIG. 15B illustrates another example of a probabilities module, according to an embodiment.

[0020] Fig. 16 shows an exemplary system for generating or optimizing probabilities based on betting behavior.

[0021] Fig. 17 shows an exemplary system for generating or optimizing probabilities based on balance analysis.

[0022] Fig. 18 shows a plurality of exemplary scheme specific base modules.DETAILED DESCRIPTION

[0023] Aspects of the invention are disclosed in the following description and related drawings directed to specific embodiments of the invention. Alternate embodiments may be devised without departing from the spirit or the scope of the invention. Additionally, well-known elements of exemplary embodiments of the invention will not be described in detail or will be omitted so as not to obscure the relevant details of the invention. Further, to facilitate an understanding of the description discussion of several terms used herein follows.

[0024] As used herein, the word “exemplary” means “serving as an example, instance or illustration.” The embodiments described herein are not limiting, but rather are exemplary only. It should be understood that the described embodiments are not necessarily to be construed as preferred or advantageous over other embodiments. Moreover, the terms “embodiments of the invention”, “embodiments” or “invention” do not require that all embodiments of the invention include the discussed feature, advantage or mode of operation.

[0025] With respect to the embodiments, a summary of terminology used herein is provided.

[0026] An action refers to a specific play or specific movement in a sporting event. For example, an action may determine which players were involved during a sporting event. In some embodiments, an action may be a throw, shot, pass, swing, kick, hit, performed by a participant in a sporting event. In some embodiments, an action may be a strategic decision made by a participant in the sporting event such as a player, coach, management, etc. In some embodiments, an action may be a penalty, foul, or type of infraction occurring in a sporting event. In some embodiments, an action may include the participants of the sporting event. In some embodiments, an action may include beginning events of sporting event, for example opening tips, coin flips, opening pitch, national anthem singers, etc. In some embodiments, a sporting event may be football, hockey,basketball, baseball, golf, tennis, soccer, cricket, rugby, MMA, boxing, swimming, skiing, snowboarding, horse racing, car racing, boat racing, cycling, wrestling, Olympic sport, eSports, etc. Actions can be integrated into the embodiments in a variety of manners.

[0027] Digital gaming refers to any type of electronic environment that can be controlled or manipulated by a human user for entertainment purposes. A system that enables a human and a computer to interact according to set of both implicit and explicit rules, in an electronically powered domain for the purpose of recreation or instruction. “eSports” refers to a form of sports competition using video games, or a multiplayer video game played competitively for spectators, typically by professional gamers. Digital gaming and “eSports” can be integrated into the embodiments in a variety of manners.

[0028] The term event refers to a form of play, sport, contest, or game, especially one played according to rules and decided by skill, strength, or luck. In some embodiments, an event may be football, hockey, basketball, baseball, golf, tennis, soccer, cricket, rugby, MMA, boxing, swimming, skiing, snowboarding, horse racing, car racing, boat racing, cycling, wrestling, Olympic sport, etc. Event can be integrated into the embodiments in a variety of manners.

[0029] Managed service user interface service is a service that can help customers (1) manage third parlies, (2) develop the web, (3) do data analytics, (4) connect thru application program interfaces and (4) track and report on player behaviors. A managed service user interface can be integrated into the embodiments in a variety of manners.

[0030] Managed service risk management services are a service that assists customers with (1) very important person management, (2) business intelligence, and (3) reporting. These managed service risk management services can be integrated into the embodiments in a variety of manners.

[0031] Managed service compliance service is a service that helps customers manage (1 ) integrity monitoring, (2) play safety, (3) responsible gambling and (4) customer service assistance. These managed service compliance services can be integrated into the embodiments in a variety of manners.

[0032] Managed service and technology platform are services that helps customers with (1) web hosting, (2) IT support and (3) player account platform support. These managed service and technology platform services can be integrated into the embodiments in a variety of manners.

[0033] Managed service and marketing support services are services that help customers (1) acquire and retain clients and users, (2) provide for bonusing options and (3) develop press release content generation. These managed service and marketing support services can be integrated into the embodiments in a variety of manners.

[0034] “Fantasy sports connector” are software connectors between method steps or system elements in the embodiments that can integrate fantasy sports. Fantasy sports allow a competition in which participants select imaginary teams from among the players in a league and score points according to the actual performance of their players. For example, if a player in a fantasy sport is playing at a given real time sports, probabilities could be changed in the real time sports for that player.

[0035] Software as a service (or SaaS) is a method of software delivery and licensing in which software is accessed online via a subscription, rather than bought and installed on individual computers. Software as a service can be integrated into the embodiments in a variety of manners.

[0036] Automatic content recognition (ACR) is an identification technology to recognize content played on a media device or present in a media file. Devices containing ACR support enable users to quickly obtain additional information about the content they see without any user-based input or search efforts. To start the recognition, a short media clip (audio, video, or both) is selected. This clip could be selected from within a media file or recorded by a device. Through algorithms such as fingerprinting, information from the actual perceptual content is taken and compared to a database of reference fingerprints, each reference fingerprint corresponding to a known recorded work. A database may contain metadata about the work and associated information, including complementary media. If the fingerprint of the media clip is matched, the identification software returns the corresponding metadata to the client application. For example, during an in-play sports game a “fumble” could be recognized and at the time stamp of the event, metadata such as “fumble” could be displayed. Automatic content recognition (ACR) can be integrated into the embodiments in a variety of manners.

[0037] Augmented reality means a technology that superimposes a computer-generated image on a user's view of the real world, thus providing a composite view. In an example, a real time view of the game can be seen and a “guess” which is a computer-generated data point is placed above the player that is guessed on. Augmented reality can be integrated into the embodiments in a variety of manners.

[0038] Some embodiments of this disclosure, illustrating all its features, will now be discussed in detail. It can be understood that the embodiments are intended to be open ended in that an item or items used in the embodiments is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items.

[0039] As used herein Robotic Process Automation (RPA) may be the use of software with some aspects of Al or machine learning capabilities to handle high-volume, repeatable tasks that previously required humans to perform. An example of this may be software for a "web crawler" that can eliminate hundreds of hours of searching each time the same searches need to be conductedon specific web searches. Robotic process automation may be integrated with one or more of the embodiments.

[0040] As used herein a database may include, but is not limited to, publicly available data sets such as dictionaries, databases behind a paywall, internal databases of, for example, nondisclosure agreements, invention disclosures, competitive analysis, statistical information of, for example, a sports game, etc. It may be understood that some databases may include an Application Specific Interface (API) which may enable a program to extract data from a search.

[0041] As used herein, a scheme may refer to any game plan, play, or strategy used before, during, or after a sporting game or event.

[0042] It can be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Although any systems and methods similar or equivalent to those described herein can be used in the practice or testing of embodiments, only some exemplary systems and methods are now described.

[0043] FIG. 1 is a system for artificial intelligence based live game probability calculation. This system may include a live event 102, for example a sporting event such as a football game, basketball game, baseball game, hockey game, tennis match, golf tournament, etc. The live event 102 may include some number of actions or plays, upon which probabilities can be calculated.

[0044] Further, a live action input module 104 may receive data about each individual action in a game or match and store the data in a live event database 106. In some embodiments, an action may be a specific play or specific event in a sporting event. In some embodiments, an action may be a throw, shot, pass, swing, kick, hit, performed by a participant in a sporting event. In some embodiments, an action may be a strategic decision or scheme made by a participant inthe sporting event such as a player, coach, management, etc. In some embodiments, an action may be a penalty, foul, or type of infraction occurring in a sporting event. In some embodiments, an action may include the participants of the sporting event. In some embodiments, an action may include beginning events of sporting event, for example opening tips, coin flips, opening pitch, national anthem length, and the like. In some embodiments, a sporting event may be football, hockey, basketball, baseball, golf, tennis, soccer, cricket, rugby, MMA, boxing, swimming, skiing, snowboarding, horse racing, car racing, boat racing, cycling, wrestling, Olympic sport, and the like. The live event database 106 may be provided, which may store data collected by the live event module 104 such as the results of the action that has just occurred as well as the situational data for the next upcoming action.

[0045] In some embodiments the system for artificial intelligence based live game probability calculation may include a detection system such as a plurality of sensors 108. The sensors may include, for example, motion sensors, temperature sensors, humidity sensors, cameras such as an RGB-D Camera which is a digital camera providing color (RGB) and depth information for every pixel in an image, microphones, radiofrequency receiver, a thermal imager, a radar device, a lidar device, an ultrasound device, a speaker, wearable devices etc. Also, the plurality of sensors 108 may include tracking devices, such as RFID tags, GPS chips or other such devices embedded on uniforms, in equipment, in the field of play, in the boundaries of the field of play, or other markers on the field of play. Imaging devices may also be used as tracking devices such as player tracking that provides statistical information through real-time X, Y positioning of players and X, Y, Z positioning of the ball. In some embodiments, the sensor data is collected from the live event 102 and sent to a server or a cloud 110 where it is stored in a historical action database130. In some embodiments, the sensor data may be collected from a third party source and storedon the server or cloud 110. Further, the availability of sensor data may be displayed to a user and / or any sensor data itself may be displayed to a user. Further, the availability or use of sensor data may be activated or deactivated by a user.

[0046] A cloud 110 or communication network may be a wired and / or a wireless network. The communication network, if wireless, may be implemented using communication techniques such as visible light communication (VLC), worldwide interoperability for micro wave access (WiMAX), long term evolution (LTE), wireless local area network (WLAN), infrared (IR) communication, public switched telephone network (PSTN), radio waves, and other communication techniques, as desired. The communication network may allow ubiquitous access to shared pools of configurable system resources and higher-level services that can be rapidly provisioned with minimal management effort, often over internet and relies on sharing of resources to achieve coherence and economies of scale, like a public utility, while third-party clouds enable organizations to focus on their core businesses instead of expending resources on computer infrastructure and maintenance. A live event data API 112 delivers data from the live event 102 to a data network 122. A display device API 114 delivers data between the data network 122 and a display device 116.

[0047] The display device 116 may be a computing device, laptop, smartphone, tablet, computer, smart speaker, television screen, teleprompter, or TO device. I / O devices may be present in the computing device. Input devices may include keyboards, mice, trackpads, trackballs, touchpads, touch mice, multi-touch touchpads and touch mice, microphones, multi-array microphones, drawing tablets, cameras, single-lens reflex camera (SLR), digital SLR (DSLR), CMOS sensors, accelerometers, infrared optical sensors, pressure sensors, magnetometer sensors, angular rate sensors, depth sensors, proximity sensors, ambient light sensors, gyroscopic sensors,or other sensors. Output devices may include video displays, graphical displays, speakers, headphones, inkjet printers, laser printers, and 3D printers. Devices may include a combination of multiple input or output devices, including, e.g., Microsoft KINECT®, Nintendo Wiimote® for the WIT, Nintendo® WII U GAMEPAD®, or Apple IPHONE®. Some devices allow gesture recognition inputs through combining some of the inputs and outputs. Some devices may provide for facial recognition which may be utilized as an input for different purposes including authentication and other commands. Some devices may provide for voice recognition and inputs, including, e.g., Microsoft KINECT®, SIRI® for IPHONE by Apple, Google Now or Google Voice Search, and the like.

[0048] Additional devices may have both input and output capabilities, including, e.g., haptic feedback devices, touchscreen displays, or multi-touch displays. Touchscreen, multi-touch displays, touchpads, touch mice, or other touch sensing devices may use different technologies to sense touch, including, e.g., capacitive, surface capacitive, projected capacitive touch (PCT), incell capacitive, resistive, infrared, waveguide, dispersive signal touch (DST), in-cell optical, surface acoustic wave (SAW), bending wave touch (BWT), or force-based sensing technologies. Some multi-touch devices may allow two or more contact points with the surface, allowing advanced functionality including, e.g., pinch, spread, rotate, scroll, or other gestures. Some touchscreen devices, including, e.g., Microsoft PIXELSENSE® or Multi-Touch Collaboration Wall, may have larger surfaces, such as on a table-top or on a wall, and may also interact with other electronic devices. Some I / O devices, display devices or group of devices may be augmented reality devices. The I / O devices may be controlled by an I / O controller. The I / O controller may control one or more I / O devices, such as, e.g., a keyboard and a pointing device, e.g., a mouse or optical pen. Furthermore, an I / O device may also provide storage and / or an installation mediumfor the computing device. In still other embodiments, the computing device may provide USB connections (not shown) to receive handheld USB storage devices. In further embodiments, an I / O device may be a bridge between the system bus and an external communication bus, e.g. a USB bus, a SCSI bus, a FireWire bus, an Ethernet bus, a Gigabit Ethernet bus, a Fibre Channel bus, or a Thunderbolt bus. The display device 116 can leverage the sensors in for purposes such as automatic content recognition, augmented reality or the synchronization of screens between the user device interface and other displays. The display device 116 may display the probabilities for the next action of the live game 102. It may also be appreciated that the display device 116 could be part of a live video display, live television display or any other live video feed of the live game 102 on which probabilities are being provided. In some embodiments there may be a data GUI 118, or guided user interface or graphical user interface, which may display the data options and probabilities for various actions in the live event 102. The interface(s) may either accept inputs from users or provide outputs to the users or may perform both the actions. In one case, a user can interact with the interface(s) using one or more user-interactive objects and devices. The user- interactive objects and devices may include user input buttons, switches, knobs, levers, keys, trackballs, touchpads, cameras, microphones, motion sensors, heat sensors, inertial sensors, touch sensors, virtual reality, augmented reality, eye tracking, or a combination of the above. Further, the interface(s) may either be implemented as a command line interface (CLI), a graphical user interface, a voice interface, or a web-based user-interface. The data network 122 may provide an artificial intelligence based software module that compares data from the live event to data in the historic action database 130 in order to calculate probability of the next action in the live game 102. The data network 122 may be located on the server or cloud 110 which may perform real time analysis on the type of play and the result of a play or action. The server, or cloud 110, may alsobe synchronized with game situational data, such as the time of the game, the score, location on the field, weather conditions, and the like, which may affect the choice of play utilized. For example, in other exemplary embodiments, the server may not receive data gathered from sensors and may, instead, receive data from an alternative data feed, such as Sports Radar. Data may be received from a remote terminal or mobile device that may be located at the live event 102. The data related to the live event 102 may be entered into the remote terminal or mobile device by one or more administrators of the live game probability calculation system, employee, technician, or other third-party persons. For example, a person may be located at the live event 102 and may provide the position of the players on the field, such as the offensive formation in an American football game, through an input into a remote terminal or mobile device. This human collected data may be used independently, or in conjunction with sensor data, in the generation of probabilities. This data may be provided following the completion of any play and the data from this feed may be compared with a variety of team data and league data based on a variety of elements, including down, possession, score, time, team, and so forth, as described in various exemplary embodiments herein. The system for artificial intelligence based live game probability calculation may further include a base module 124 which receives the live event database 106 from the live event module 104, which contains historical and situational data on the live event 102 currently occurring. The base module 124 stores the historical data in the historic action database 130 and sends the situational data to a probabilities module 126 and initiates the probabilities module 126. The probabilities module 126 uses the situational data from the live event 102 to filter the historic action database 130 on previous actions with some the same situational data and performs correlations on the similar actions in order to determine the difference in the correlations and compare the difference in correlations to the recommendation database 132 in order to adjustthe probabilities within the probabilities database 134 accordingly. A data module 128 compares the probabilities database 134 to the adjustment database 136 in order to determine if there is a match in the probabilities IDs. Then, if there is a match, then the probabilities are adjusted accordingly, by the data module 128. A historic action database 130 stores all the historic actions of an event. A recommendation database 132 is used to determine the appropriate adjustment in the probabilities by using the difference in the correlated data from the data module 126. The probabilities database 134 contains the current probabilities. An adjustment database stores the probabilities ID and the appropriate adjustment, for example increase by 5% or decrease by 5%. Any adjusted probabilities can then be displayed via the display device 116, or interface, on a live video feed, such as on a television feed, or any other video live stream. Further, adjusted probabilities may be shown in real time, for example showing a 66% chance of a running play and a 34% chance of a passing play in a football game when the quarterback is positioned under the center and changing to a 75% chance of a passing play and 25% chance of a running play when the quarterback then moves back into a shotgun formation.

[0049] FIG. 2 provides an illustration of the live action input module 104. The process begins with an action, for example a play, that occurs in an event, such as a sporting event, at step 200. The live action input module 104 then stores the results of the action in the live event database 106, at step 202. The live event module 104 also stores situational data in the live event database 106 which is information for the upcoming action in an event, at step 204. The live action input module 104 then sends the live event database 106 to the data network 122, base module 124, and the process returns to step 200, at step 206.

[0050] FIG. 3 provides an illustration of the live event database 106 which contains information on the live event 102, such as results of the last action and information for theupcoming action. The live event database 106 may contain result data such as the action ID, offensive team, offensive players, quarter or time period of the event, down, distance and result of the action such as a pass. In some embodiments, the result data may contain statistical information for offensive, defensive teams, or special teams, players, or coaches. The live event database 106 may also contain situational data or information for the upcoming action in the live event 102. The situational data may include the action ID, offensive team, offensive players, quarter or time period of the event, down and distance. In some embodiments, the live event database 106 may contain information regarding the defensive team or players, individual coaches, location of the event, temperature, levels of precipitation, type of precipitation, time of the event, referees or officials of the event, color of the uniforms for each team, at step 300.

[0051] FIG. 4 provides an illustration of the base module 124. The process begins with the base module 124 continuously polling for the live event database 106 from the live action input module 104, at step 400. The base module 124 receives the live event database 106, at step 402. The base module 124 stores the results data, or the results of the last action, in the historic action database 130 which contains historical data of all previous actions, at step 404. The situational data from the live event database 106 is extracted, at step 406. The extracted situational data from the live event database 106 is sent to the probability module 126, at step 408. The probability module 126 is initiated, and the process returns to continuously polling for the live event database 106, at step 410.

[0052] FIG. 5 provides an illustration of the probability module 126. The process begins with the probability module 126 being initiated by the base module 124, at step 500. The probability module 126 receives the situational data, or information about the upcoming action or action in an event, from the base module 124, at step 502. The probability module 126 filters thehistoric action database 130 on the team and down from the situational data, at step 504. The first parameter of the historic action database 130 is selected, for example the event, at step 506. Then the probability module 126 performs correlations on the data. For example, the historical action database 130 is filtered on the team, the players, the quarter, the down and the distance to be gained. The first parameter is selected which in this example is the event, which may either be a pass, or a run and the historical action database 130 is filtered on the event being a pass. Then, correlations are performed on the rest of the parameters, which are yards gained, temperature, decibel level, etc. In FIG. 15B, the graph shows the correlated data for the historical data involving the Patriots in the second quarter on second down with five yards to go and the action being a pass, which has a correlation coefficient of .81. The correlations are also performed with the same filters and the next event which is the action being a run which is also shown in FIG. 15B and has a correlation coefficient of .79, at step 508. It is determined if the correlation coefficient is above a predetermined threshold, for example .75, in order to determine if the data is highly correlated and deemed a relevant correlation, at step 510. It may be understood the threshold may be set by Al and / or ML, or may be set by another method such as an algorithm or calculation. If the correlation is deemed highly relevant, then the correlation coefficient is extracted from the date. For example, the two correlation coefficients of .81 for a pass and .79 for a run are both extracted, at step 512. If it is determined that the correlations are not highly relevant, then then it is determined if there are any parameters remaining. Also, if the correlations were determined to be highly relevant therefor extracted It is also determined if there are any parameters remaining to perform correlations on, at step 514. If there are additional parameters to have correlations performed then the probability module 126 selects the next parameter in the historic action database 130 and returns to step 508, at step 516. Once there are no more remaining parameters to performcorrelations on, the probability module 126 then determines the difference between each of the extracted correlations. For example, the correlation coefficient for a pass is .81 and the correlation coefficient for a run is .79. The difference between the two correlation coefficients (.81 - .79) is .02. In some embodiments, the difference may be calculated by using subtraction on the two correlation coefficients. In some embodiments, the two correlation coefficients may be compared by determining the statistical significance. The statistical significance, in an embodiment, may be determined by, for example, using the following formula: Zobserved = (zl - z2) I (square root of [ (1 / N1 - 3) + (1 / N2 - 3) ], where zl is the correlation coefficient of the first dataset, z2 is the correlation coefficient of the second dataset, N 1 is the sample size of the first dataset, and N2 is the sample size of the second dataset, and the resulting Zobserved may be used instead of the difference of the correlation coefficients in the recommendation database 132 to compare the two correlation coefficient based on statistical significance as opposed to the difference of the two correlation coefficients, at step 516. The difference between the two correlation coefficients, .02, is then compared to the recommendation database 132. The recommendation database 132 contains various ranges of differences in correlations as well as the corresponding probability adjustment for those ranges. For example, the .02 difference of the two correlation coefficients falls into the range +0-2 difference in correlations which according to the recommendation database 132 may have a probability adjustment of 5% increase, at step 518. The probability module 126 then extracts the probability adjustment from the recommendation database 132, at step 520. The extracted probability adjustment is stored in the adjustment database 136, at step 522. Then probability module 126 initiates the data module 128, at step 524.

[0053] In other embodiments, it may be appreciated that the previous formula may be varied depending on a variety of reasons, for example adjusting probability based on furtherfactors, adjusting probability based on changing conditions or additional variables. Additionally, in other exemplary embodiments, one or more alternative equations may be utilized in the probability module 126. One such equation could be Zobserved = (zl - z2) / (square root of [ (1 / N1 - 3) + (1 / N2 - 3) ], where zl is the correlation coefficient of the first dataset, z2 is the correlation coefficient of the second dataset, N1 is the sample size of the first dataset, and N2 is the sample size of the second dataset, and the resulting Zobserved to compare the two correlation coefficient based on statistical significance as opposed to the difference of the two correlation coefficients. Another equation used may be Z=bi-b2 / Sbi-b to compare the slopes of the datasets or may introduce any of a variety of additional variables, such as bi is the slope of the first dataset, b2 is the slope for the second dataset, Sbi is the standard error for the slope of the first dataset and Sb2 is the standard error for the slope of the second dataset. The results of calculations made by such equations may then be compared to the recommendation database 132 and the probability module 126 may then extract a probability adjustment from the recommendation database 132. The extracted probability adjustment is then stored in the adjustment database 136 and the data module 128 is initiated by the probability module 126, as in the above.

[0054] In other embodiments, the probability module 126 may adjust probabilities based on one or more current states of the live event 102. In one state, the probability module 126 may use data from the historic action database 130 to create probabilities for one or more potential outcomes of the current state of the live event 102. For example, the data network 122 may determine there is a 75% chance that Aaron Judge gets a hit in his current at-bat, based on his batting average in previous at-bats against the current pitcher. In a second state, the probability module 126 may utilize data from the live event data API 112 to adjust the probability. For example, spin rate of pitches may be tracked in real-time. The average spin rate on four-seamfastballs thrown by Clayton Kershaw in the current game may be 2732. That may be 10% higher than his average spin rate has been on that pitch this season. This may be used to adjust the probability of Aaron Judge getting a hit in the current at-bat from the 75% that would be used based on the two players’ historical interactions to 80%.

[0055] It can be noted that the probability module 126 can be made available for access, reconfiguration, modification, or control for customers or used for managed service user interface service, managed service risk management services, managed service compliance service, managed service pricing and trading service, managed service and technology platform, managed service and marketing support services, payment processing services, business applications, engaging promotions, business applications, state based integration, game configurator, “fantasy sports connector”, software as a service, synchronization of screens, automatic content recognition (ACR), joining social media, Augmented reality, digital gaming, or “eSports”.

[0056] Functioning of the data module 128 will now be explained with reference to FIG.6. One skilled in the art will appreciate that, for this and other processes and methods disclosed herein, the functions performed in the processes and methods may be implemented in differing order. Furthermore, the outlined steps and operations are only provided as examples, and some of the steps and operations may be optional, combined into fewer steps and operations, or expanded into additional steps and operations without detracting from the essence of the disclosed embodiments.

[0057] Figure 6 provides an illustration of the data module 128. The process begins with the data module 128 being initiated by the base module 124, at step 600. The data module 128 selects the first probability ID in the adjustment database 136, which stores the probability ID as well as the most reoccurring action from the filtered data from the process described in Fig. 5, atstep 602. Then the data module 128 filters the adjustment database 136 on the probability ID, which leaves all the most reoccurring action or play result data that were calculated for the specific action. Play data can be any data that indicates anything about the live game, such as, but not limited to audio or visual data that indicates "actions" , "sides", "event" data, "total" data, "listed pitchers", specific players, whistles, fouls, touchdowns, goals, yardage, player error, etc., at step 604. The data module 128 then calculates the averages of all the most reoccurring action or play results, such as a pass or a run, for the filtered probability ID. The average of the play results may be used as probabilities of the action occurring which may be used to update or improve the current probability that are stored in the current probabilities database 134, at step 606. Then the data module 128 matches the probability ID from the adjustment database 136 to the probability ID stored in the current probabilities database 134 in order to update the corresponding probability , at step 608. The adjustment module 136 then updates the current probabilities database 134 by using the probabilities calculated in step 606. For example, probability ID 123654, which is a probability for a pass to occur on the next play which is 3rd and ten to go, otherwise known as a 3rd and long, is originally calculated with probability of -105. The averages calculated from the adjustment database show that out of four highly correlated instances three plays were passing plays and only one was a run play. So, the probability of the play being a pass would be 75%, or 33 / 100 which would translate to -300 and the probability for probability ID 123654 in the current probabilities database 134 would be updated to -300, at step 610. It is then determined by the adjustment module 136 if there are any remaining probability IDs in the adjustment database 136, at step 612. If it is determined there are more remaining probability IDs then the next probability ID is selected and the process returns to 604, at step 614. If there is no more remaining probabilityIDs from the adjustment database 136 then the process returns to the base module 110, at step 616.

[0058] FIG. 7 provides an illustration for the historic action database 130, which is created via the base module 124 storing the results from the live event database 106. The historic action database 130 contains situational data such as the action ID, the team, the players, the quarter, the down, and the distance. The historic action database 130 also contains parameters such as the event, yards gained, temperature, decibel level, and players. It should be noted that the historic action database 130, in an embodiment, is used for the purpose of a working example for football, but can also be implemented for any other sport or event, as desired. The historic action database 130 may contain situational data and parameters for various events or sporting events such as football, basketball, baseball, hockey, soccer, rugby, golf, tennis, etc. The situational data is information about actions such as the statistical information for teams or individuals competing in an event, the time period of the event, and information leading up to the upcoming action, for example, in the current lead or deficit for a team or player, the location of a certain player or players on the event field, court, or pitch, etc. In some embodiments, the situational data may be information related to sensor data related to individual players, teams, or sensor data retrieve from wearable devices or equipment such as balls, protective equipment, clubs, bats, etc. The parameters would be the information containing the results of the situational data which would be the statistical data that resulted from the action related to the situational data, in FIG. 7.

[0059] Functioning of the historic sensor database 120 will now be explained with reference to FIG. 8. One skilled in the art will appreciate that, for this and other processes and methods disclosed herein, the functions performed in the processes and methods may be implemented in differing order. Furthermore, the outlined steps and operations are only provided as examples, and some of the steps and operations may be optional, combined into fewer steps andoperations, or expanded into additional steps and operations without detracting from the essence of the disclosed embodiments.

[0060] Figure 8 illustrates the historic sensor database 120 which contains all the sensor data collected from participants of previous live events. The database contains event data, which is information about the event at that specific period of time in the event such as which team the sensor data was collected for, the player or participant the sensor data was collected for, what position the player plays or is aligned for the specific play, the quarter or period of time in the event the data was collected, the down and distance to go and the resulting play, for example a pass or run. The database also contains the sensor data collected during the play such as the speed of the payer, the distanced the player traveled in total, the separation and the yards after catch. The database as currently shown is filtered for the event data and the participant in order to determine if there are any correlations between the sensor data collected and the outcome of the play to determine if the probabilities should be adjusted in the probabilities database 134. In some embodiments, the sensor data collected may represent player's or participant's position on the field of play during an event.

[0061] FIG. 9 provides an illustration for the recommendations database 132 which is used by the probability module 126 to determine how the probabilities should be adjusted depending on the difference between the correlation coefficients of the correlated data points. The recommendations database 132 may contain the difference in correlations and the probability adjustment. For example, in FIG. 1 B there is a correlation coefficient for a Patriots 2nddown pass of .81 and a correlation coefficient for a Patriots 2ndrun of .79, the difference between the two would be +.02 when compared to the recommendation database 132 the probability adjustment would be a 5% increase for a Patriots pass or otherwise identified as probability 201 in theadjustment database 136. In some embodiments, the difference in correlations may be the statistical significance of comparing the two correlation coefficients in order to determine how the probabilities should be adjusted.

[0062] FIG. 10 provides an illustration for the probability database 134 which contains the potential probability of actions in the event and is updated via the probabilities module 126 and the data module 128 depending on the resulting correlation coefficients. The probability database 134 may contain the probability ID, the event, the time, the quarter, and the probability. It should be noted that the probability database 134 is currently constructed to provide a working example using football as the event, but the probability database 134 may be constructed based on a sport by sport basis.

[0063] FIG. 11 provides an illustration for the adjustment database 136 which may be used to adjust the probabilities of the probabilities database 134, if it is determined that a probability should be adjusted. The adjustment database 136 contains the probability ID, which is used to match the with the probability database 134 to adjust the correct probability.

[0064] Functioning of the adjustment database 136 will now be explained with reference to FIG. 12. One skilled in the art will appreciate that, for this and other processes and methods disclosed herein, the functions performed in the processes and methods may be implemented in differing order. Furthermore, the outlined steps and operations are only provided as examples, and some of the steps and operations may be optional, combined into fewer steps and operations, or expanded into additional steps and operations without detracting from the essence of the disclosed embodiments.

[0065] Figure 12 illustrates another exemplary embodiment of the adjustment database 136 which may stores the most re-occurring play data extracted from the probabilities module 126along with the probability ID in order to determine the probability of the upcoming play by determining the average occurrence of the play happening with similar event data and highly correlated sensor data through the process described in the data module 128. The database may contain the probabilities ID and the play data, such as a pass or a run.

[0066] Functioning of another exemplary embodiment of the probabilities database 134 will now be explained with reference to FIG. 13. One skilled in the art will appreciate that, for this and other processes and methods disclosed herein, the functions performed in the processes and methods may be implemented in differing order. Furthermore, the outlined steps and operations are only provided as examples, and some of the steps and operations may be optional, combined into fewer steps and operations, or expanded into additional steps and operations without detracting from the essence of the disclosed embodiments.

[0067] The probabilities database 134 may contains a list of all current probabilities available to the users of the server. The database may contain probability data such as the probability ID, a description of action, and the probability. The database may contain event data related to the probability such as the team, the quarter or time period for the upcoming play, the down, and the distance to gain.

[0068] FIG.14A provides an illustration of an example of the probability module 126 and the resulting correlations. In FIG. 14A, the data is filtered by the team, down and quarter and finding the various correlations with the team, down and quarter and the various parameters such as the yards to gain, punt yardage, field goal yardage, etc. An example of non-correlated parameters with the team, down, and quarter and the yards to gain and punt yardage with a 15% (which is below the 75% threshold), therefore there is no correlation and the next parameters should be correlated, unless there are no more parameters remaining.

[0069] FIG. 14B provides an illustration of an example of the probability module 126 and the resulting correlations. In FIG. 14B, the data is filtered by the team, down and quarter and finding the various correlations with the team, down and quarter and the various parameters such as the event, yards to gain, yards gained, etc. An example of correlated parameters is with the event being a pass and the team, down, and quarter with an 81%, therefore there is a correlation (since it is above the 75% threshold) and the correlation coefficient needs to be extracted and compared with the other extracted correlation coefficient which in this example is the event data where the event is a run, which is correlated at 79%. The difference of the two correlations is compared to the recommendations database in order to determine if there is a need to adjust the probabilities. In this example, there is a .02 difference between the event being a pass and the event being a run, which means on second down in the second quarter the New England Patriots are slightly more likely to throw a pass than to run the ball and the probabilities are adjusted 5% decrease in order to match the correlated data. Conversely, if the correlated data of run, .79 is compared to the correlated data of a pass, .81, then the difference would be -.02 and the probabilities would be adjusted by 5% increase, at step 1104.

[0070] FIG. 15A provides an illustration for another example of the probability module and the resulting correlations. In FIG. 15 A, the data that is filtered by the team, down and quarter and finding the various correlations with the team, down and quarter and the various parameters such as the decibel level in the stadium, punt yardage, field goal yardage, etc. An example of noncorrelated parameters with the team, down, and quarter and the decibel level in the stadium and punt yardage with a 17% (which is below the 75% threshold), therefore there is no correlation and the next parameters should be correlated, unless there are no more parameters remaining.

[0071] FIG. 15B provides an illustration for another example of the probability module and the resulting correlations. In FIG. 15B, the data that is filtered by the team, down and quarter and finding the various correlations with the team, down and quarter and the various parameters such as the event, temperature, yards gained, etc. An example of correlated parameters is with the event being a run and the team, down, and quarter with an 92%, therefore there is a correlation (since it is above the 75% threshold) and the correlation coefficient needs to be extracted and compared with the other extracted correlation coefficient which in this example is the event data where the event is a pass, which is correlated at 84%. The difference of the two correlations are compared to the recommendations database in order to determine if there is a need to adjust the probabilities. In this example, there is a .08 difference between the event being a run and the event being a pass, which means on first down in the first quarter the New England Patriots are more likely to throw a run than to pass the ball and the probabilities are adjusted 15% decrease in order to match the correlated data. Conversely, if the correlated data of run, .84 is compared to the correlated data of a pass, .92, then the difference would be -.08 and the probabilities would be adjusted by 15% increase.

[0072] In one or more exemplary embodiments Al or ML may be used to generate probabilities based on a plurality of factors.

[0073] Referring to exemplary Fig 16, a first exemplary system for generating or optimizing probabilities based on betting behavior 1600 may be shown. The system for generating probabilities based on the betting behavior 1600 may include a betting behavior base module 1602. The betting behavior base module 1602 may control one or more other betting behavior modules in order to generate or optimize probabilities being offered on one or more prediction markets on one or more plays in a sports game, for example on plays in an American football game or abaseball game. The betting behavior base module 1602 may be controlled or connected to a larger system base module, for example base module 124 described above.

[0074] In an exemplary embodiment the betting behavior base module 1602 may control the one or more other betting behavior modules to adjust probabilities to ensure that bettors receive personalized wagering opportunities that align with their preferences. This dynamic adaptation may promote engagement and satisfaction while maintaining equitable odds for all participants. The probabilities may be adjusted at any point between when the prediction market opens and closes or may be adjusted as pre-market or post-market probabilities.

[0075] It may be understood that engagement can be determined by any individual or combinations of factors. For example, engagement can be determined by a number of wagers that have been viewed by a user. Engagement can be determined based on a number of wagers placed by a user. Engagement can be determined by an number of deposits into a wallet associated with the data network 122, by size of deposits into a wallet associated with the data network 122, or by frequency of deposits to a wallet associated with data network 122. Some embodiments may also determine engagement by other user views on data network 122, such as a number of times that a user has viewed their wallet, balance, or other monetary information. Additionally, any of these factors can be combined and / or correlated to best determine engagement.

[0076] It may be understood that probabilities offered may be changed at any point, and may change dynamically, in response to changes in circumstances before, during, or after the one or more plays. In some embodiments specific sub-modules may be triggered in response to specific events, and the probabilities determined may be stored in a better classification odds database 1612. It may be understood that the modules may be called in any order and / or that multiple modules may be run simultaneously.

[0077] Now explaining the modules in more detail, in an exemplary embodiment a bettor classification module 1604 may analyze inherent biases in human nature that drive bettors to place more money on long shots than they should, primarily for entertainment purposes. The bettor classification module 1604 may utilize historical betting data to identify patterns and preferences in individual bettors' wagering habits. The bettor classification module 1604 may utilize Al and algorithms to analyze this data, discerning tendencies for betting on long shots or favorites. The resulting classifications may provide insights into each bettor's wagering style, allowing for tailored margin adjustments that cater to the bettor’s specific preferences.

[0078] The bettor classification module 1604 may leverage historical data that demonstrates the propensity for bettors to place more money on long shots than is mathematically justified, which may be utilized for classification. The bettor classification module 1604 may analyze various factors, including game dynamics and wagering market trends, to determine wagers that could have their margin adjusted based on the individual bettor's classification.

[0079] Now explaining the wager identification module 1606 in more detail. The wager identification module 1606 may use Al for identifying and analyzing the wagers within data network 122 that can or should have their margins adjusted. The wager identification module 1606 may assess each wager's potential for adjustment by considering factors such as the wager odds, the margin on the odds, and the total price of the bet. For example, in an exemplary football match odds for one team may be heavily skewed. The wager identification module 1606 may determine Team A, the favorite, has moneyline odds of -500, while Team B, the longshot, has moneyline odds of +800. The wager identification module 1606 may examine the wager odds and margins to assess if adjustments could lead to optimized profits. Bettors inclined to bet on longshots or favorites are not likely to bet the opposite of their tendency just because they are offered a slightlyinferior price on their preferred wager. As a result, the wager identification module 1606 may flag the wagers on this match as prime candidates for margin adjustment.

[0080] In another example the wager identification module 1606 may determine in an exemplary basketball game with relatively even odds between the two teams. Team X may have moneyline odds of -110, and Team Y may have moneyline odds of +120. In this scenario, the wager identification module 1606 may assess the wager odds, margins, and the total price of the bet. Since the odds are already relatively balanced, adjusting the margins may change betting selections and volume more than in the first example. This may be because bettors are more sensitive to price changes when the odds are close to even. Consequently, the wager identification module 1606 may determine that wagers on this game are not suitable candidates for margin adjustment.

[0081] The wager identification module 1606 may determine the best candidates for margin adjustment and identify those that would not benefit from adjustments. This process may help the system to effectively maximize profits and enhance the efficiency of the w data network 122. The wager identification module 1606 may work with individual wagers and parlays, encompassing various types of bets such as pre-match, pre-game, in-game, full-game, and prop bets. By analyzing and identifying potential combinations of wagers, the wager identification module 1606 may optimize the margins across a broader range of betting options, catering to diverse bettor preferences and improving the overall betting experience.

[0082] In another example the wager identification module 1606 may analyze a single bet on a football match between Team A and Team B, where Team A is a heavy favorite with odds of -300 and Team B is a longshot with odds of +250. The wager identification module 1606 may evaluate the margin on this individual bet and examine the total price, determining whether themargin aligns with the sportshook's desired level. Next, the wager identification module 1606 may look for a potential second wager that could be parlayed with the current wager being examined. It may identify a basketball game between Team C and Team D, where the odds are closer to even: for example Team C has odds of -110, and Team D has odds of +100. The wager identification module 1606 may then evaluates the margin on this individual bet and examine the total price, similarly determining whether the margin aligns with the sportsbook's desired level. Once the second wager is identified, the wager identification module 1606 may combine the two wagers into a parlay and analyzes the combined odds, margin, and total price. If the wager identification module 1606 determines that the margin on the parlay could be further optimized, it may flag the parlay as a candidate for margin adjustment and recommend this combination to the Margin Adjustment Module 1608. In some embodiments the wager identification module 1606 may be applied to in-game bets, where the odds and margins change rapidly as the game progresses, as well as full-game bets and prop bets, which focus on specific aspects of a game or player's performance.

[0083] Now explaining the margin adjustment module 1608 in more detail. The margin adjustment module 1608 may be responsible for determining the optimal margin adjustments for the identified wagers and bettors. The margin adjustment module 1608 may take into account the bettor classification and the wagers identified by the previous modules. The margin adjustment module 1608 may adjust the margins to maximize the sportsbook's margin without significantly affecting betting behavior.

[0084] The margin adjustment module 1608 may first analyze the odds and betting patterns of the identified bettors, considering their betting tendencies and the wagers they are likely to place. Next, the margin adjustment module 1608 may evaluate different scenarios of marginadjustments, calculate the potential impact on betting behavior and the overall price of the wager. The margin adjustment module 1608 may then select the most suitable margin adjustments based on its evaluation, ensuring that the changes are not too drastic so as not to discourage the bettors or create imbalances in the betting market. Finally, the margin adjustment module 1608 may communicate the adjusted odds to the sportsbook.[00851 In a first example, the bettor classification module 1604 may identify a group of bettors with a strong preference for betting on favorites. The wager identification module 1606 may identify a wager where the favorite has odds of -200, and the longshot has odds of +180. The margin adjustment module 1608 may determine that a slight increase in the favorite's odds to -210 and a corresponding decrease in the longshot's odds to +190 will not significantly affect the betting behavior of the identified bettors, as they are less price-sensitive due to their strong preference for favorites. The sportsbook may then adjust the odds accordingly, maintaining the overall price of the wager while increasing its margin.

[0086] In a second example, the bettor classification module 1604 may identify a group of bettors with a strong preference for betting on longshots. The wager identification module 1606 may identify a wager where the favorite has odds of -120, and the longshot has odds of +100. The margin adjustment module 1608 may determine that a slight decrease in the favorite's odds to -125 and a corresponding increase in the longshot's odds to +105 will not significantly affect the betting behavior of the identified bettors, as they are less price-sensitive due to their strong preference for longshots. The sportsbook may then adjust the odds accordingly, maintaining the overall price of the wager while increasing its margin. In both examples, the margin adjustment module 1608 may consider the betting tendencies of the identified bettors and the wager's odds to make adjustmentsthat will maximize margins without deterring the bettors or creating an imbalance in the betting market.

[0087] Now explaining the behavior variance detection module 1610 in more detail. The behavior variance detection module 1610 may monitor and analyze the effects of the margin adjustments and personalization applied by the bettor classification module 1604, the wager identification module 1606, and the margin adjustment module 1608 on bettors' behavior. The behavior variance detection module 1610 may determine if the changes have led to unintended consequences, such as bettors altering their betting behavior, possibly indicating that the margin adjustment was too severe or that they have detected the personalization offering them less desirable prices.

[0088] For example, in an embodiment after the margin adjustment module 1608 has adjusted the odds for this bettor, the behavior variance detection module 1610 may notice a pattern of less favorable prices on the favorites they usually bet on. As a result, the bettor may decide to reduce their bet volume on favorites or even start betting on longshots, which were previously not a part of the bettor’s typical betting strategy. In this case, the the behavior variance detection module 1610 may identify this behavior change and provide feedback to the other modules to adjust their algorithms and recommendations accordingly.

[0089] In the example where a bettor tends to bet on favorites, the behavior variance detection module 1610 may employ statistical methods to quantify the variance in their betting behavior. One such method may be the calculation of the average odds they bet on before and after the margin adjustments. If the average odds on favorites have shifted significantly, it may indicate that the bettor has become more reluctant to bet on their preferred selections due to the less favorable prices.

[0090] Another method may be to measure the variance in behavior is to calculate the bettor's bet frequency and bet volume on favorites before and after the margin adjustments. A considerable drop in bet frequency or volume may signify that the bettor is either betting less or diverting their bets to other markets or selections. The system may be alerted when the bettor's behavior deviates beyond this threshold by setting a predetermined threshold for these changes, which may be set by Al and / or ML. In some embodiments the threshold may be set by another method such as an algorithm or calculation, or any other method known in the art.

[0091] For instance, if the bettor's average odds on favorites shift by more than 10% or their bet frequency or bet volume decreases by more than 20%, the system may consider these changes significant enough to trigger a response. This response may involve the behavior variance detection module 1610 providing feedback to one or more other modules, prompting them to reevaluate and adjust their strategies to better cater to the bettor's preferences and ensure their satisfaction with the betting experience.

[0092] By incorporating these mathematical measurements and predefined thresholds, which may be set by Al and / or ML, the behavior variance detection module 1610 may effectively monitor bettors' behavior and identify any significant changes that may require adjustments to the personalization and margin adjustment strategies implemented by the other modules in the system.

[0093] The behavior variance detection module 1610 may continuously track and compare the betting patterns and tendencies of the bettors before and after the margin adjustments and personalization have been implemented. The behavior variance detection module 1610 may evaluate factors such as bet volume, frequency, and types, and the selection of favorites or longshots, among others. By identifying any significant deviations in the bettors' behavior, the behavior variance detection module 1610 may help sportsbooks fine-tune their personalizationstrategies and margin adjustments to better balance optimizing margins and maintaining customer satisfaction.

[0094] Now explaining the bettor classification odds database 1612 in more detail. The bettor classification odds database 1612 may store all the data that is created in executing the system for generating or optimizing probabilities based on betting behavior 1600 and related submodules.

[0095] Referring to exemplary Fig 17, an exemplary system for generating or optimizing probabilities based on balance analysis 1700 may be shown. The system for generating probabilities based on the balance analysis 1700 may include a bettor balance analysis base module 1702. The bettor balance analysis base module 1702 may optimize online wallet balances on betting platforms and may constantly monitor and analyze a bettor's current wallet balance, juxtaposing it with their historical betting patterns and any discernible shifts in betting behavior. The bettor balance analysis base module 1702 may include a balance analysis module 1704, an incentive management module 1706, an abuse detection module 1708, a user retention module 1710, and / or a bettor analysis odds database 1712. The bettor balance analysis base module 1702 may be controlled or connected to a larger system base module, for example base module 124 described above.

[0096] The bettor balance analysis base module 1702 may, upon activation, at the conclusion of a bet, or at regular intervals, collaboratively interacts with other integral modules within the network base module 1800 which may ensure the bettor's personalized and optimized experience.

[0097] Now explaining the balance analysis module 1704 in more detail.

[0098] The balance analysis module 1704 may operate in real-time, whether during in-play or pre-game betting scenarios and may dynamically adjust the wallet balance threshold for each bettor. The threshold may be calculated based on, for example, the bettor's past wagering activities, deposit frequencies, and current betting context and may be set by Al and / or ML,.

[0099] For example, in an exemplary embodiment a better may engage in a 3-leg parlay. After the outcomes of the first two legs, the balance analysis module 1704 may evaluate the results in conjunction with the bettor's current wallet balance and past tendencies. A bettor who has won the first two legs and historically wagers more after consecutive wins may have a higher threshold, say $500. Conversely, a bettor with one leg loss and historically cautious post-loss wagers may have a reduced threshold, perhaps at $300. The module's precision in setting these thresholds may ensure that any incentives or adjustments offered are contextually relevant. The analysis and thresholds may be generated through the use of Al or ML algorithms, which may allow the balance analysis module 1704 to make informed decisions on when and how to intervene, for example through odds adjustments or incentivized offers.

[0100] As another example, in a scenario where a bettor with two consecutive wins reaches a balance of $600, no immediate action might be taken given the $500 threshold. However, another bettor with a single leg loss and a dwindling balance of $80 might be immediately flagged for an odds boost or another incentive as they fall below the $100 threshold.

[0101] In an embodiment, by constantly assessing and responding to both immediate bet outcomes and longitudinal wallet balances, the balance analysis module 1704 may ensure the platform offers timely and contextually apt interventions. Once the relevant actions are determined and executed, the resultant odds or incentives become the offerings presented to the respective bettor, ensuring an adaptive and rewarding wagering experience.

[0102] Now explaining the incentive management module 1706 in more detail, the incentive management module 1706 may, based on insights from the balance analysis module 1704, evaluate the real-time wallet balance of a bettor in conjunction with their historical receptiveness to incentives to develop an incentive strategy.

[0103] For example, in a scenario where a bettor is engrossed in a 3-leg parlay The the incentive management module 1706 response may be contingent on the bettor's progression and context. If a bettor clinches victories in the initial two legs and has a history of elevated wagers following such streaks, especially when their wallet balance is buoyant (for instance, holding $600 in contrast to a set threshold of $500), the incentive management module 1706 may subtly amplify the odds for the third leg. This strategy may cause the bettor to stake more without resorting to direct monetary enticements.

[0104] In another scenario, if a bettor faces a setback in one of the initial legs, historically adopts a more reserved wagering stance post such losses, and their wallet exhibits a dwindling trend (say $80, falling below a designated threshold of $100), the incentive management module 1706 may pivot its approach. The incentive management module 1706 may generate and display a more attractive odds boost or even offer a complimentary bet, aiming to rekindle their interest and spur the bettor to top up their balance.

[0105] These context-aware strategies, embedded within the incentive management module 1706, may appeal to the bettor's immediate sentiments and wallet status but also resonate with their historical interactions, fostering a tailored and resonant wagering environment.

[0106] Now explaining the abuse detection module 1708 in more detail, the abuse detection module 1708 may ensure integrity and fairness of the platform by scrutinizing bettorbehaviors, keenly observing for any patterns or anomalies that might hint at attempts to unduly exploit the system's incentives or odds adjustments.

[0107] In an example if a bettor consistently shows a pattern of maintaining a balance slightly below the threshold (for instance, hovering around $490 when the threshold is $500) just to avail of the system's incentives and then refrains from engaging substantially with the platform post-incentive, it may raise a red flag for the abuse detection module 1708. Similarly, a bettor who consistently wagers on boosted odds but displays an abnormal pattern of withdrawal or nonengagement right after may also be flagged.

[0108] Upon detecting such patterns, the abuse detection module 1708 may adjust or entirely withhold the suspicious user's incentives to prevent potential exploitation. Furthermore, if the system identifies repetitive or egregiously suspicious activities, it may instigate a more comprehensive review and / or necessitate manual intervention from platform administrators.

[0109] Now explaining the user retention module 1710 in more detail. The user retention module 1710 may monitor bettor’s long-term behavior and analyze nuances like the cadence of their deposits, their cashout tendencies in various contexts, and their receptivity and responsiveness to past incentives. For example, in an exemplary embodiment their may be a bettor john. Over the past year, John may have demonstrated a pattern of depositing substantial amounts during major sports events, with a clear tendency to cash out 70% of his wallet after any significant loss. The User Retention Module 1710 may note such behavior, registering the emotional highs and lows tied to big events and their outcomes.

[0110] In another exemplary embodiment their may be a bettor Clara. Clara, over the past six months, may have consistently maintained her balance at around $490, a strategic move just below the $500 threshold, indicating her savvy approach to capitalize on the system's incentives.However, her deposit patterns have recently shown a shift, becoming less frequent, and the amounts have diminished, hinting at a potential waning interest or external factors affecting her wagering activities.

[0111] Based on these insights and monitoring, in an exemplary embodiment the User Retention Module 1710 may detect that john posts a significant loss during a high-profile sports event, and the User Retention Module 1710 may deploy a "recovery incentive." This could be in the form of, for example, a "Next Bet Boost" or a "Deposit Match" offer, which may sooth the sting of the loss and encourage John to stay engaged rather than cashing out. This strategy may not only retains John but also understands and caters to his emotional betting journey.

[0112] For Clara, sensing the gradual drift in her engagement, the User Retention Module 1710 may introduce a "Loyalty Bonus." Recognizing her previous strategy of hovering just below the threshold, this bonus could offer a direct cash bonus for every deposit above a new, slightly higher threshold, say $520. Alternatively, it may provide enhanced odds on her favorite betting markets or even introduce a "Frequent Bettor Club" with exclusive perks. Such tailored approaches may serve to reignite Clara's interest, prompting her not only to deposit more frequently but also to explore new betting avenues on the platform.

[0113] Now explaining the better analysis odds database 1712 in more detail. The better analysis odds database 1712 may store all the data that is created in executing the system for generating or optimizing probabilities based on balance analysis 1700 and related submodules.

[0114]

[0115] Referring now to Fig. 18, in some embodiments a plurality of exemplary scheme specific base modules 1800 may be used. Each of the plurality of scheme specific base module 1800 may be called by the network base module 1802. For example, the network base module1802 may call one or more of the behavior base module 1602, the bettor analysis base module 1702 there may be, a double down base module 1804, and / or a social parlay base module 1806.

[0116] In an exemplary embodiment the double down base module 1804 may optimize or adjust probabilities or odds in parlay bets based on outcomes of earlier legs and the live status and changing probabilities of ongoing events within the parlay. For example, as individual legs of a parlay are concluded, bettors may have the option to modify their wagers on the remaining legs. The system may repackage the ongoing legs at a potentially discounted rate and apply an odds boost, resulting in adjusted returns for the combined outcomes.

[0117] In an exemplary embodiment the double down base module 1804 may use one or more sub modules to, for example, optimize the double-down opportunities presented to the bettor. The one or more sub modules may include, for example, a parlay leg monitoring module, a parlay repackaging module, and a bettor response analysis module. The parlay leg monitoring module may ensure that the progress of each leg within a parlay is continuously tracked in real time. The Parlay Leg Monitoring module may determine the specific juncture at which a bettor might be offered the chance to double down on the remaining legs of their parlay. The Parlay Leg Monitoring module watches the status of each of a plurality of legs within a parlay, identifying when a leg has concluded and consequently triggering the next steps in the double-down process.

[0118] For example, in an embodiment there may be a four- leg parlay on football games: Match A, Match B, Match C, and Match D. As the matches progress, the Parlay Leg Monitoring Module may continuously monitor the outcomes of each match in real-time. Once Match A concludes and the bettor's selected outcome is successful, the Parlay Leg Monitoring Module may detect this change in the parlay status. Recognizing that the first leg of the parlay has beensuccessfully completed, the module may determine that this is a potential point to offer a doubledown opportunity for the remaining legs.

[0119] In an exemplary embodiment the parlay repackaging module may reshape and repropose multi-leg parlays based on the results of concluded legs. In some embodiments the parlay repackaging module may utilize updated data provided by the parlay leg monitoring module to assess the bettors current position and offer or adjust new odds. For example, if a bettor's parlay is on a winning streak, the Parlay Repackaging Module may repackage the remaining legs and recalibrates the odds. While keeping the bet mathematically sound, the odds adjustment also factors in the heightened allure associated with the double-down incentive.

[0120] In another exemplary embodiment For a Bettor With One or More Lost Legs the Parlay Repackaging Module may identify and offer an alternative pathway. While a traditional parlay might be deemed lost, the module may create a fresh wagering opportunity from the remaining legs. While the odds might not be as lucrative as the original, it may allow the bettor to reclaim some potential return on their stake.

[0121] Additionally, by continuously communicating with the Wagering Network Base Module - Bettor Response Analysis Module, the Parlay Repackaging Module may monitor a bettor's reaction to new parlay offers. By understanding and predicting bettor behavior, the Parlay Repackaging Module may offer revised wager offers to prolong engagement and satisfaction.

[0122] In an exemplary embodiment the bettor response analysis module may decipher and predict bettor reactions to betting propositions to ensure that repackaged offers, odds adjustments, and incentives continually align with bettor preferences and tendencies. The bettor response analysis module may engage in real-time analysis of bettor engagement which mayinclude, for example, metrics like acceptance rates of repackaged parlays, the time taken to ponder over an offer, or even instances of outright declining an offer.

[0123] The bettor response analysis module may further perform predictive modeling. Utilizing a plurality of historical response data an Al algorithms, one or more models may be built which anticipate potential reactions from a bettor in a plurality of scenarios. For example, data patterns may reveal that after clinching two consecutive wins in a parlay, bettors exhibit an inclination to embrace aggressive odds adjustments.

[0124] In some embodiments, the module may monitor for potential disconnects between a bettor’s preferences and presented propositions when faced with negative or neutral responses characterized by declined offers or hesitance. This observation may result in in-depth reassessment, wherein the module juxtaposes this response data against the bettor's historical wagering patterns, betting amounts, and past reactions to odds adjustments. In some embodiments the bettor analysis module may further offer real-time feedback to the Parlay Repackaging Module, thereby which may enable the repackaged offers to undergo iterative refinement based on realtime bettor behaviors. Similarly, its collaboration with the Parlay Leg Monitoring Module may aid in discerning whether reactions might be influenced by specific match outcomes or the broader progression of a parlay.

[0125] In an exemplary embodiment the social parlay base module 1808 may construct or adjust probabilities or odds and parlay bets based on outcomes of live betting dynamics. The social parlay base module 1808 may automatically amalgamate popular wagers into potential parlays, for example, if there's a significant uptake in individual bets on specific outcomes, the module may amalgamate them into one parlay option, optimizing the potential return for bettors based on the prevailing betting trends.

[0126] For example, in an exemplary embodiment there may be a major football weekend.As games progress, the module may note a significant number of individual bets being placed onTeam A to win their game, Player X to score the first goal in another match, and Team B to draw in a third fixture. Given the high volume of these bets, the Parlay Construction Module may automatically craft a parlay combining these three prevalent wagers.

[0127] In some embodiments the social parlay base module 1808 may interact with a plurality of sub modules, for example a parlay construction module and a parlay customization module. In an exemplary embodiment the parlay construction module may utilize Al or ML to draw from a plurality of user created parlays and, subsequently, and may utilize real-time monitoring of individual wagers to understand prevailing betting dynamics and patterns. In an embodiment the parlay construction module may utilize an algorithm to scan and collate user created or other existing parlays. The parlay construction module may then utilize a plurality of live bets data to generate one or more parlay patterns to generate one or more parlays.

[0128] For example, on a given weekend, numerous bettors may independently construct a specific parlay linking Tennis Player A’s victory, Baseball Team B’s win, and Football Player C's goal-scoring feat. Recognizing the popularity of this user-generated combination, the Parlay Construction Module may highlight and promote this parlay. Simultaneously, the module may identify that there's also a growing trend of bets on Tennis Player D and Baseball Player E, even though they aren't commonly linked in user-created parlays. The module may then generate a new parlay that encapsulates Player A, Team B, Player C, Player D, and Player E.

[0129] In an exemplary embodiment the parlay customization module refine one or more parlay wagers, for example a parlay wager received from the parlay construction module, and may customize the parlay based on one or more user profiles and circumstances. In an exemplaryembodiment, the parlay customization module may first establish a base user understanding, which may include user past patterns, favored sports, teams, events, etc. based on the base user understanding the module may additionally evaluate real-time context, for example available wagers, the stage of each game event (from pre-game odds to in-play dynamics), and recent betting outcomes. Additional factors may include, for example, the user's current wallet balance to gauge risk appetite, potential wager sizes, the user's typical betting range, and recent news or trends related to teams or players that might influence a bettor's decision.

[0130] For example, in an embodiment Jane, a regular bettor may historically favor underdog football teams and top-seeded tennis players. On a specific weekend, the Parlay Construction Module may construct a parlay featuring Tennis Player A (a top seed), Baseball Team B, and Football Team C (a favorite). Upon accessing Jane's profile, the Parlay Customization Module may determine one or more betting habits and consider her recent loss in a significant bet, her current wallet balance, and available wagers. Considering these factors, the module may amend the parlay by replacing Football Team C with Football Team D, an underdog, while retaining Tennis Player A. This customized parlay may be understood to align more closely with Jane's historical preferences and her current betting situation.

[0131] The foregoing description and accompanying figures illustrate the principles, preferred embodiments and modes of operation of the invention. However, the invention should not be construed as being limited to the particular embodiments discussed above. Additional variations of the embodiments discussed above will be appreciated by those skilled in the art.

[0132] Therefore, the above-described embodiments should be regarded as illustrative rather than restrictive. Accordingly, it should be appreciated that variations to those embodimentscan be made by those skilled in the art without departing from the scope of the invention as defined by the following claims.

Claims

CLAIMSWhat is claimed is:

1. A method for adjusting odds based on betting behavior, comprising: identifying, using artificial intelligence, a plurality of betting preferences for a user based on historical betting data associated with the user; selecting one or more wagers from a wagering market; analyzing the wagering market; determining a wager adjustment corresponding to the one or more selected wagers based on the plurality of betting preferences and the analysis of the wagering market; adjusting the one or more wagers based on the determined wager adjustment; displaying the one or more adjusted wagers to the user.

2. The method for adjusting odds based on betting behavior of claim 1, wherein at least one of the one or more wagers is an over / under wager.

3. The method for adjusting odds based on betting behavior of claim 1, wherein at least one of the one or more wagers is a moneyline wager.

4. A method for generating or adjusting parlay wagers, comprising: receiving situational data from a live event; monitoring, in real time, a plurality of wagers associated with the live event to determine, by artificial intelligence, one or more betting patterns of one or more users;receiving a parlay wager from the plurality of wagers; determining if at least one leg of the received parlay wager is closed; and displaying a new parlay wager offer after determining that at least one leg of the received parlay wager is closed.

5. The method for generating or adjusting parlay wagers of claim 4, wherein the new parlay wager offer includes at least one of any non-closed legs of the received parlay wager.

6. The method for generating or adjusting parlay wagers of claim 5, wherein at least one leg of the new parlay wager offer is determined based on the one or more betting patterns of one or more users.

7. The method for generating or adjusting parlay wagers of claim 5, wherein at least one leg of the new parlay wager offer is determined based on at least a betting pattern of a user of the one or more users.

Images