Fixture Specific Models for Bet Simulations and Pricing of Real Time Events

The technology described herein generally relates to devices, systems, and processes for adjusting market pricing by player for mainline handicap and over/under bets for sporting events. More specifically, the technology described herein generally relates to the development and use of fixture specific models used in massive real-time simulations to determine pricing for bets on real-time events.

An online gaming system (“OGS”) commonly utilizes a combination of one or more gaming servers (herein, a “front-end system (FES)”—as further described below) that receive data feeds from one or more third party servers (herein, each a “back-end system (BES)”—as further described below), such as SWISH™ data provided by Swish Analytics of San Francisco, California, USA and Sportradar of St. Gallen, Switzerland. The FES commonly facilitates betting by bettors (herein, each being a “user” and as defined herein) on one or more “events” (as defined herein) and may include live events and future vents. The FES uses data provided by the BES.

An event may include one or more “activities” (as defined herein) with respect to which bets may be placed. Further, a FES may allow a user to place same game parlay (“SGP”) bets wherein bets are placed on multiple future activities occurring. For example, an SGP may include bets on total points scored and total assists in a given event. Today, data is provided by the BES which the FES uses to determine odds, pricing, and results for activities, SGPs, and other forms of bets.

Further, an event typically includes one or more “event entities” (herein, each a “player”) that participate in the event and/or an event activity. Non-limiting examples of players include a team, an individual participant on a team, a collection of participants on a team (e.g., an NFL defensive squad), a coach of a team, or otherwise. Event activities, such as scoring activities, may be attributed to one or more players. A player's activities may be further identified in a player props line (a “Props”). For example, a player's scoring activity may be identified as an over/under of a given point total in a Props. For a further example, a Props may identify a player scoring greater (over) or less (under) twenty points in a game. Bets may be placed in view of the odds, other users' bets, statistical results, and other data of the player so scoring over or under the given total.

The player's activities may be further attributed to various team categories that collectively contribute to the overall performance of a team of players for one or more given events and/or one or more given activities. For example, player A may score a basket and thereby contribute points to a team's overall score, while player B provides an assist that results in the basket being scored. Collectively, player activities may result in adjustments to team activities.

Commonly, a FES will provide users with various team-based betting options and various SGP player betting options. For example, a team-based betting option may be generated based on a first team model while an SGP player betting option may be generated based on a second Props model. While both models may consider total points scored by a given player by quarter, overall, or otherwise (e.g., a scoring activity by a basketball team may occur by a first player or another player), and while data regarding team-based event activities and Props is commonly readily available, correlations, and systems and methods for generating such correlations, of an individual player's contributions to the team-based event activities are needed for pricing of real-time betting lines, such as SGPs, which may include real-time SGPs (“RSGPs”).

During an event, betting lines are commonly determined based upon generic models. The models may be event, event-activity, or otherwise specified. Typically, the generic models do not account for fixtures (as defined below) occurring with regards to a particular type of an event and/or an event-activity. For example, an event may be a baseball game, an activity may be an inning in the game, and a fixture may be a particular then occurring or later occurring pitcher/batter match-up. Generic models commonly do not account for the given pitcher/batter match-up and accordingly a betting line is typically generated based on one or more generic models that can be associated with a higher level of abstraction such as on an event level (e.g., a baseball game) and/or an activity level (e.g., a half-inning of a baseball game) and without consideration of specific elements of the event-activity, as identified by one or more fixtures thereof.

Further, use of fixture specific models have been proposed in the past, current systems are commonly limited in their processing power and speed and are incapable of generating models for a given fixture on a substantially real time (as defined herein) basis. Thus, gaming system commonly use generic models in the numerous (often thousands) of simulations that are used to determine a betting line, or an adjustment thereto. The generic model is not reflective of a given currently occurring fixture and the fixture data currently available during an activity and an event and thus are inherently inaccurate. Such inaccuracies commonly result in the simulations generating probability grids that contain recognizable errors. Such errors are then commonly adjusted by intervention of a gaming manager (a person or automated process) or otherwise. Such interventions are time and resource intensive and are still subject to errors which may result in betting lines that do not accurately reflect the probabilities that should actually exist for a given event—activity—fixture.

Accordingly, devices, systems and processes are needed for pricing betting lines based on real-time variations in fixtures for a given activity of a given event.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. A more extensive presentation of features, details, utilities, and advantages of various implementations of the present disclosure is provided in the following written description and illustrated in the accompanying drawings.

Various implementations are described of devices, systems, and processes for generating fixture specific models and utilizing such fixture specific models during real-time event simulations to generate real-time pricing for one or more betting lines where the real-time pricing accounts for one or more real-time variations in one or more fixtures for the event.

In accordance with at least one implementation of the present disclosure, a system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination thereof installed on the system that, in operation, cause(s) the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by a data processing apparatus, cause the apparatus to perform the actions.

For at least one implementation of the present disclosure, a server may include comprising: a data store storing non-transitory first computer instructions for instantiating a model adaptation engine (“MAE”); a processor may be configured to execute the first computer instructions and instantiate the MAE. The MAE, when instantiated by the processor, may instruct the server to perform MAE operations (“MAEO”) including: searching a database for fixture specific model (“FSM”) data (“FSMD”) pertinent to a given event-activity-fixture (“EAF”); obtaining generic model data (“GMD”) for a given event-activity pairing; and modifying the GMD with the FSMD to generate FSM adapted data (“FSMAD”) for the given EAF. An FSMS bus couples the processor with the data store.

For at least one implementation of the server, the data store may further store non-transitory second computer instructions for instantiating a generic modeling engine (“GME”); the processor may be further configured to execute the second computer instructions and instantiate the GME. The GME, when instantiated by the processor, may instruct the server to perform GME operations (“GMEO”) including obtaining the GMD from a generic model database (“GMDB”).

For at least one implementation of the server, the GMDB includes non-transitory generic models identifiable based on at least one of an event identifier and an activity identifier.

For at least one implementation of the server, at least one of the generic models has been refined using a supervised artificial intelligence and machine learning (“AI/ML”). The AI/ML may be initially trained based on past instances of an event-activity pairing and the AI/ML may be refined based on additional event-activity pairings. The GME may further perform the GMEO of obtaining the GMD from the GMDB by utilizing the AI/ML to identify, on a Cloud storage device, data pertinent to one or more event-activity pairings that are substantially similar to the given event-activity pairing.

For at least one implementation of the server, the GMEO may further include: receiving event-activity-fixture data (“EAFD”) from at least one of a historical EAF database (“HEAFDB”) and an EAF database (“EAFDB”); and further obtaining the generic model based on at least one of HEAF data (“HEAFD”) received from the HEAFDB and RTEAF data (“RTEAFD”) received from the EAFDB.

For at least one implementation of the server, the data store may further store non-transitory third computer instructions for instantiating an EAF data engine (“EAFDE”); the processor may be further configured to execute the third computer instructions and instantiate the EAFDE. The EAFDE, when instantiated by the processor, may instruct the server to perform EAFDE operations (“EAFDEO”) including: requesting the HEAFD from the HEAF database; receiving the RTEAFD from a real-time data server (“RTDS”); and providing at least one of the HEAFD and the RTEAFD to the MAE.

For at least one implementation of the server, the data store may further store non-transitory fourth computer instructions for instantiating an FSM leveling engine (“FSMLE”); the processor may be further configured to execute the fourth computer instructions and instantiate the FSMLE. The FSMLE, when instantiated by the processor, may instruct the server to perform FSMLE operations (“FSMLEO”) including: receiving the FSMAD from the MAE; leveling the FSMAD received from the MAE in a relational database; and outputting leveled FSM data (“FSMLD”) for storage in an FSM level database (“FSMLDB”).

For at least one implementation of the server, the FSMLD stored in the FSMLDB may be utilized by a simulation server during a real time EAF to simulate one or more outcomes of the real-time EAF; and the one or more outcomes are utilized by an EAF pricing server to determine one or more betting lines for the event.

For at least one implementation of the present disclosure, a process for generating a fixture specific model (“FSM”) may include: searching a database for FSM data (“FSMD”) pertinent to a given event-activity-fixture (“EAF”); obtaining generic model data (“GMD”) for a given event-activity pairing; and modifying the GMD with the FSMD to generate FSM adapted data (“FSMAD”) for the given EAF.

For at least one implementation of the process, the GMD may be obtained from a generic model database; and the generic model database may include non-transitory generic models identifiable based on at least one of an event identifier and an activity identifier.

For at least one implementation of the process, at least one of the generic models may be refined using a supervised artificial intelligence and machine learning (“AI/ML”). The AI/ML may be initially trained based on past instances of an event-activity pairing; the AI/ML may be refined based on additional event-activity pairings; and the process may further include utilizing the AI/ML to identify, on a Cloud storage device, data pertinent to one or more event-activity pairings that are substantially similar to the given event-activity pairing.

For at least one implementation of the process, the process may include receiving event-activity-fixture data (“EAFD”) from at least one of a historical EAF database (“HEAFDB”) and a real-time EAF database (“EAFDB”); and further obtaining the generic model based on HEAF data (“HEAFD”) received from at least one of the HEAFDB and RTEAF data (“RTEAFD”) received from the EAFDB.

For at least one implementation of the process, the process may include: requesting the HEAFD from the HEAFDB; and receiving the RTEAFD from a real-time data server (“RTDS”).

For at least one implementation of the process, the process may include: leveling the FSMAD in a relational database; and outputting leveled FSM data (“FSMLD”) for storage in an FSM level database (“FSMLDB”).

For at least one implementation of the process, the FSMLD stored in the FSMLDB may be utilized by a simulation server during a real time EAF to simulate one or more outcomes of the real-time EAF; and the one or more outcomes may be utilized by an EAF pricing server to determine one or more betting lines for the event.

For at least one implementation, a computer readable medium may non-transiently store non-transitory first computer instructions which when executed by a processor, in a server, instantiates a model adaptation engine (“MAE”) that instructs the server to perform MAE operations (“MAEO”) including: searching a database for fixture specific model (“FSM”) data (“FSMD”) pertinent to a given event-activity-fixture (“EAF”); obtaining generic model data (“GMD”) for a given event-activity pairing; and modifying the GMD with the FSMD to generate FSM adapted data (“FSMAD”) for the given EAF.

For at least one implementation of the computer readable medium, the computer readable medium may further store non-transitory second computer instructions which, when executed by the processor, instantiates a generic modeling engine (“GME”) which may instruct the server to perform GME operations (“GMEO”) including: obtaining the GMD from a generic model database (“GMDB”). The GMDB may include non-transitory generic models identifiable based on at least one of an event identifier and an activity identifier.

For at least one implementation of the computer readable medium, at least one of the generic models may be refined using a supervised artificial intelligence and machine learning (“AI/ML”); wherein the AI/ML has been initially trained based on past instances of an event-activity pairing and the AI/ML may be refined based on additional event-activity pairings. The GME may further perform the GMEOs of obtaining the GMD from the GMDB by utilizing the AI/ML to identify, on a Cloud storage device, data pertinent to one or more event-activity pairings that are substantially similar to the given event-activity pairing.

For at least one implementation of the computer readable medium, the computer readable medium may further store non-transitory third computer instructions which, when executed by the processor, instantiates an EAF data engine (“EAFDE”) which instructs the server to perform EAFDE operations (“EAFDEO”) including: providing event-activity-fixture data (“EAFD”) to the MAE. The EAFD may be obtained from at least one of a historical EAF database (“HEAFDB”) and an EAF database (“EAFDB”).

For at least one implementation of the computer readable medium, the computer readable medium may further store non-transitory fourth computer instructions which, when executed by the processor, instantiates an FSM leveling engine (“FSMLE”) which instructs the server to perform FSMLE operations (“FSMLEO”) including: receiving the FSMAD from the MAE; leveling the FSMAD received from the MAE in a relational database; and outputting leveled FSM data (“FSMLD”) for storage in an FSM level database (“FSMLDB”). The FSMLD may be utilized by a simulation server during a real time EAF to simulate one or more outcomes of the real-time EAF and the one or more outcomes may be utilized by an EAF pricing server to determine one or more betting lines for the event.

Various implementations of the present disclosure describe independent bet processing devices, systems, and processes for generating fixture responsive betting lines including, but not limited to, betting lines for on-line gaming involving SGPs and RSGPs.

For at least one implementation, a system is provided which generates, based on a fixture specific model (“FSM”) and real time event-activity-fixture (“RTEAF”) data, probabilities of an outcome of a real-time activity of an event. The probabilities are further utilized to determine pricing for one or more betting lines, such as a player Props line, a team activity betting line, an activity result betting line, or the like. For example, a fixture specific model may be utilized to determine, in view of real-time fixture data, probabilities of a given player (e.g., a batter in a baseball game) hitting a home run against a given pitcher. Such probabilities may be generated, using the fixture specific model, based on various instances of fixture data with non-limiting example including pitch count, past pitcher/batter results, weather, game status, or any other available data relevant to determining a probability for a given fixture of an activity and/or an event.

In accordance with the present disclosure such probabilities may be generated and reflect one or more real-time variations in one or more fixtures for a given event by using one or more of multiple pre-determined fixture specific models that feed multiple simultaneously performed and substantially real-time simulations to generate the probabilities—such probabilities further being used by event pricing systems to substantially real-time adjust odds and pricing of one or more betting lines for the given event.

“Acceptable delay” is a delay of less than a given metric. For at least one implementation, an acceptable delay in the selection, by an event simulation server, of an existing fixture specific model that has already been downloaded to a fixture specific leveled database (as described below) for a real-time event in which one or more variations in a fixture for the given real-time event have occurred is a delay of less than one millisecond (1 ms), wherein the delay may be determined from a “fixture variation time” (as defined herein). For at least one implementation, an “acceptable delay” in the use, by the event pricing server, of a fixture specific model selected for the given real-time event to update one or more betting odd when one or more fixture variations have occurred during the real-time event, is a delay of less than four hundred nanoseconds (400 ns) after the fixture variation time. For at least one implementation, a given delay may be determined based on a quantification of one or more networked communications characteristics occurring between a back-end system element and an OGS element. It is to be appreciated that such one or more networked communications characteristics may vary over time and with use thereof.

“Activity” herein refers to one or more, including multiple, quantifiable sub-parts of an event with respect to which a betting line may be established. For a non-limiting example, a baseball game (an event) may include activities such as scores, runs, balls, strikes, outs, walks, errors and the like. Such activities may exist on an event level basis (e.g., total runs scored in the game), an inning basis (e.g., strikeouts in a given half of an inning), or otherwise. For another non-limiting example, a basketball game (an event) may include activities such as points, assists, blocks, steals, turnovers and the like. The activities may be tabulated as the event occurs and an OGS will often allow a user to place bets based on various future potential event activities (e.g., the score at a particular point of time later in the basketball game). The later time may be within any given time period, such as within seconds, minutes, or otherwise. An activity may be further defined, for one or more betting purposes or otherwise, in terms of one or more fixtures (as defined herein).

“Additional I/O interface” (AIOI) herein refers to one or more components, provided with or coupled to a device, configured to support a receiving and/or presenting of additional inputs and outputs to and from one or more users. An AIOI may be configured to support the receiving and presenting of the additional I/O content (AIO) to users. Herein, the AIO, as communicated, may be referred to as “AIO signals.” An AIO signal may include an audible signal or a visible signal and may be communicated separately or collectively therewith. An AIOI may include any interface not otherwise categorized as an Audio I/O interface or a Visual I/O interface with non-limiting examples including touch pads, keyboards, sensors, motion detectors, tactile elements, and the like. Any known or later arising technologies configured to convey information to or from one or more users as an AIO signal may be utilized for at least one implementation of the present disclosure. An AIOI includes hardware and computer instructions (herein, “AIO technologies”) which supports the input and output of other signals with a user.

“Application” herein refers to a set of computer instructions that configure one or more processors to perform one or more tasks that are other than tasks commonly associated with the operation of the processor itself (e.g., a “system software,” an example being an operating system software), or the providing of one or more utilities provided by a device (e.g., a “utility software,” an example being a print utility). An application may be bundled with a given device or published separately. Non-limiting examples of applications include word processing applications (e.g., Microsoft WORD™), video streaming applications (e.g., SLINGTV™), video conferencing applications (e.g., ZOOM™), gaming applications (e.g., FORTNITE™), and the like.

“AI/ML” (Artificial Intelligence/Machine Learning) herein refers to the use of one or more supervised learning, unsupervised learning, and/or refinement learning processes (as executed by one or more processors which may include processors associated with one or more neural networks) to perform one or more of the operations of the various computer engines described herein.

“Audio I/O interface” herein refers to one or more components, provided with or coupled to an electronic device, configured to support a receiving and/or presenting of humanly perceptible audible content to one or more users. Such audible content (which is also referred to herein as being “audible signals”) may include spoken text, sounds, or any other audible information. Such audible signals may include one or more humanly perceptible audio signals, where humanly perceptible audio signals typically arise between 20 Hz and 20 KHz. The range of humanly perceptible audio signals may be configurable to support an audible range of a given individual user. An audio I/O interface includes hardware and computer instructions (herein, “audio technologies”) which supports the input and output of audible signals to a user. Such audio technologies may include, but are not limited to, noise cancelling, noise reduction, technologies for converting human speech to text, text to speech, translation from a first language to one or more second languages, playback rate adjustment, playback frequency adjustment, volume adjustments and otherwise. An audio I/O interface may use one or more microphones and speakers to capture and present audible signals respectively from and to a user. Such one or more microphones and speakers may be provided by a given device itself or by a device communicatively couple additional audible device component. For example, earbuds may be communicatively coupled to a smartphone, with the earbuds functioning as an audio I/O interface and capturing and presenting audio signals as sound waves to and from a user, while the smartphone functions as a UD. An audio I/O interface may be configured to automatically recognize, and capture comments spoken by a user and intended as audible signals for sharing with other users, inputting commands, or otherwise.

“Back-end system” (BES) herein refers to one or more computer servers, data storage devices, applications, and the like which, singularly and/or cooperatively, address one or more back-end on-line gaming functions. As used herein, a “back-end online gaming function” (BEOGF) is one or more data processing operations and communications operations performed by one or more servers which facilitate the providing of fixture data, Props, results of in-game activities, and event results. A BES may include one or more servers, data stores, communications interfaces, user interfaces, security, power, busses, and related components. The BES components may be physically, logically, virtually or otherwise grouped and/or coupled to facilitate the one or more back-end on-line gaming functions including, but not limited to, those identified herein.

“Bus” herein refers to any known and/or later arising technologies which facilitate the transfer of data within and/or between devices. Non-limiting examples include Universal Serial Bus (USB), PCI-Express, Compute Express Link (CXL), IEEE-488 bus, High Performance Parallel Interface (HIPPI), and the like.

“Cloud” herein refers to cloud computing, cloud storage, cloud communications, and/or other technology resources which a given user does not actively manage or provide. A usage of a Cloud resource may be private (limited to various users and/or uses), public (available for multiple users and/or uses), hybrid, dedicated, non-dedicated, or otherwise. It is to be appreciated that implementations of the present disclosure may use Cloud resources to provide for processing, storage and other functions related to facilitating pricing of betting lines which account for changes in probabilities occurring due to fixture variations during an event. An implementation may utilize Cloud resources using any known or later arising data delivery, processing, storage, virtualization, or otherwise technologies, standards, protocols (e.g., the Simple Object Access Protocol (SOAP), the Hyper Text Transfer Protocol (HTTP), Representational State Transfer protocol (REST), the KAFKA protocol, as provided by the Apache Software Foundation and as further described at https://kafka.apache.org/documentation/#introduction (the contents of which are incorporated herein by reference), or the like. Non-limiting examples of such technologies include Software as a Service (SaaS), Platform as a Service (Paas), Infrastructure as a Service (Iaas), and the like. Cloud resources may be provided by one or more entities, such as AMAZON WEB SERVICES provided by Amazom.com Inc., AZURE provided by Microsoft Corp., and others.

“Computer engine” (or “engine”) herein refers to a combination of a processor and computer instruction(s). A computer engine executes computer instructions to perform one or more logical operations (herein, a “logic”) which facilitate various actual (non-logical) and tangible features and function provided by a system, a device, and/or combinations thereof.

“Content” herein refers to data that that may be presented, using a suitable presentation device, to a user in a humanly perceptible format. When presented to a human, the data becomes “information.” Non-limiting examples of content include gaming images and graphics such as those related to bet placement, or otherwise. Content may include, for example and not by limitation, one or more sounds, images, video, graphics, gestures, or otherwise. The content may originate from any source, including live and/or recorded, augmented reality, virtual reality, computer generated, or otherwise. The content may be presented to a given user using any user device and any user interface. Content may be stored, processed, communicated, or otherwise utilized.

“Coupling” herein refers to the establishment of a communications link between two or more elements of a given system. A coupling may utilize any known and/or later arising communications and/or networking technologies, standards, protocols or otherwise. Non-limiting examples of such technologies include packet switch and circuit switched communications technologies, with non-limiting examples including, Wide Area Networks (WAN), such as the Internet, Local Area Networks (LAN), Public Switched Telephone Networks (PSTN), Plain Old Telephone Service (POTS), cellular communications networks such as a 3G/4G/5G or other cellular network, IoT networks, Cloud based networks, private networks, public networks, or otherwise. One or more communications and networking standards and/or protocols may be used, with non-limiting examples including, the TCP/IP suite of protocols, ATM (Asynchronous Transfer Mode), the Extensible Message and Presence Protocol (XMPP), Voice Over IP (VOIP), Ethernet, Wi-Fi, CDMA, Z-WAVE, Near Field Communications (NFC), GSM/GRPS, TDMA/EDGE, EV/DO, WiMAX, SDR, LTE, MPEG, BLUETOOTH, and others. A coupling may include use of physical data processing and communication components. A coupling may be physically and/or virtually instantiated. Non-limiting examples of physical network components include data processing and communications components including computer servers, blade servers, switches, routers, encryption components, decryption components, and other data security components, data storage and warehousing components, and otherwise. Any known or later arising physical and/or virtual data processing and/or communications components may be utilized for a given coupling.

“Data” (which is also referred to herein as a “computer data”) herein refers to any representation of facts, information or concepts in a form suitable for processing, storage, communication, or the like by one or more electronic device processors, data stores, routers, gateways, or other data processing and/or communications devices and systems. Data, while and/or upon being processed, may cause or result in an electronic device or other device to perform at least one function, task, operation, provide a result, or otherwise. Data may be communicated, processed, stored and/or otherwise exist in a transient and/or non-transient form, as determined by any given state of such data, at any given time. For a non-limiting example, a given data packet may be non-transient while stored in a storage device, but transient during communication of the given data packet from a first device or system to a second (or more) device or system. When received and stored in memory, data storage device, or otherwise, the given data packet has a non-transient state. For example, and not by limitation, data may take any form including as one or more applications, content, or otherwise. Instructions, as further described herein, are a form of data.

“Data store” herein refers to any device or combinations of devices configured to store data on a temporary, permanent, non-transient, non-transitory, or other basis. A data store is also referred to herein as a “computer readable medium.” A data store may store data in any form, such as electrically, magnetically, physically, optically, or otherwise. A data store may include a memory devices, with non-limiting examples including random access memory (RAM) and read only memory (ROM) devices. A data store may include one more storage devices, with non-limiting examples including electrical storage drives such as EEPROMs, Flash drives, Compact Flash (CF), Secure Digital (SD) cards, Universal Serial Bus (USB) cards, and solid-state drives, optical storage drives such as DVDs and CDs, magnetic storage drives such as hard drive discs, magnetic drives, magnetic tapes, memory cards, and others. Any known or later arising memory and data storage device technologies may be utilized for a given data store. Available storage provided by a given one or more data stores may be partitioned or otherwise designated by the storage controller as providing for permanent storage and temporary storage. Non-transient and/or non-transitory data, computer instructions, or other the like may be suitably stored in a data store. As used herein, permanent storage is distinguished from temporary storage, with the latter providing a location for temporarily storing data, variables, or other instructions used for a then arising or soon to arise data processing operations. A non-limiting example of a temporary storage is a memory component provided with and/or embedded onto a processor or integrated circuit provided therewith for use in performing then arising data calculations and operations. Accordingly, it is to be appreciated that a reference herein to “temporary storage” is not to be interpreted as being a reference to transient or transitory storage of data. Permanent storage and/or temporary storage may be used to store transient, transitory, non-transient, and non-transient data with the data, while stored, being herein deemed to be non-transitory data.

“Device” and “electronic device” herein refer to any known or later arising electrical device configured to, singularly and/or in combination, communicate, manipulate, output for presentation as information to a human, process, store, or otherwise utilize data. Non-limiting examples of devices include user devices and servers.