Unified digital wallet

This application is a continuation of U.S. patent application Ser. No. 18/295,896, filed on Apr. 5, 2023, which is a continuation of U.S. patent application Ser. No. 17/592,610, filed on Feb. 4, 2022, now U.S. Pat. No. 11,663,884, which is a continuation of U.S. patent application Ser. No. 17/064,283, filed Oct. 6, 2020, now U.S. Pat. No. 11,328,555, which is a continuation of U.S. patent application Ser. No. 16/795,902, filed Feb. 20, 2020, now U.S. Pat. No. 10,885,741, which is a continuation of U.S. patent application Ser. No. 15/269,227, filed Sep. 19, 2016, now U.S. Pat. No. 10,607,442, which claims the benefit of priority to U.S. Provisional Patent Application No. 62/232,588, which was filed on Sep. 25, 2015, all of which are incorporated herein by reference in their entireties.

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. Copyright 2015-2024, LNW Gaming, Inc.

The present invention relates generally to software architecture and systems, and, more particularly, to a software architecture and system for a unified digital wallet for use with one or more gaming systems.

Digital wallets are gaining acceptance, but the architecture and design of conventional digital wallets are constrained or disadvantaged in several respects. First, a conventional digital wallet is not scalable across multiple vertical computer systems, partly due to internalized coupling constraints programmed into the wallet's design and partly due to the wallet's subservient position in the layers of the software architecture. Second, conventional digital wallets are vulnerable to system crashes or data corruption, which can cast doubt on the integrity of the data when full functionality is restored. Third, conventional digital wallets do not offer seamless conversion from various types of funds or fund equivalents across different vertical systems. Fourth, data associated with conventional digital wallets is typically organized according to a specific data model, which does not integrate seamlessly with systems that use a different data model. Fifth, digital wallets used in distributed systems are plagued by resource contention, requiring additional overhead to ensure data integrity.

A unified wallet manager (sometimes generally referred to herein as a wallet) is provided over a representational state (REST) service utilizing a hypertext transfer protocol (HTTP) or HTTPS and considered a peer relative to other vertical gaming systems. The wallet is a standalone relative to other vertical gaming systems, which means that the wallet possesses its own storage, process space, security layer, and memory, and data flows into a single virtual service and egresses out through an extract-transform-load (ETL) process operating on a distributed database management system. Transactions using a unified wallet manager are treated as immutable facts that are memorialized forever within queues or logs that record requests, responses, and stored funds (such as real money and points having real value like loyalty or bonus points, progressive pools, and play or virtual money having no exchange value per se). Request (e.g., GET, POST) and response calls relative to the wallet occur mutually asynchronously and are completely decoupled from one another such that a response is not dependent upon when a request call is made to the wallet service.

Any new transaction entry, once committed to a queue within the wallet, can never be overwritten, moved, deleted, or modified in any way. New entries are always appended to the last entry logged in a queue, and the queue is traversed by computing logical offsets based on a current offset and message size, as opposed to utilizing expensive message IDs. Every wallet becomes an immutable timeline history record of facts or an immutable accounting of all ledger transactions that involved each wallet from inception to the present. It can be viewed as an infinite or ever-expanding series of transaction events where any historical event or set of events can be peered into through a window applied to the series by computationally calculating logical offsets in the queue without using any message IDs. Mutating or conflicting states are thus completely avoided, eliminating contention, and promoting confidence in the reliability and integrity of the transactions passing through the wallet.

A rules engine applies rules to convert ledgers not only from one ledger type to another but also from one type of gaming system (e.g., casino gaming system) to a completely different type of gaming system (e.g., sports betting gaming system) and cross-ledger currency conversions (e.g., from real money to loyalty points or from bonus points to play money or virtual credits). Rules or conditions on the conversions are also applied, such as 500 loyalty points for every $5 spent, but if spent on this date and between these times, 5×500 loyalty points are awarded). The rules engine can also create a new value to the ledger from nothing without any corresponding exchange value, such as if a player uses a wagering game terminal in March during a time range, award that player $5, which adds $5 to the real money ledger for that player's wallet. Conversions can be embedded into request calls to the wallet and converted by the rules engine accordingly either cross-ledger and/or across multiple vertical gaming systems. Different conversion rates for different gaming system are also specified by the rules engine because a loyalty point at a particular casino gaming system can worth compared to the same loyalty point at a sports betting gaming system or even a competitor's casino gaming system. Rules can be chained together and can inherit properties or attributes from other rules, which allows different gaming systems to share ledger types that previously have not been sharable. Actions can be inferred given a set of facts from the immutable queues based on the rules by the (infinite) rules engine.

Payloads can accompany funds as they traverse through the wallet, allowing gaming system callers to the wallet to attach to any wallet transaction any payload with its own metadata that will be retained in the wallet and can be retrieved at will unscathed. In this way, the wallet can also act as a pass-through storage for wallet-related data in a way that is completely transparent and agnostic to the wallet. Because all transactions are memorialized, all associated payloads are also retained forever in the immutable queues as a permanent historical record for any gaming system consumer. Examples of payloads include an electronic receipt of a transaction, a uniform resource indicator (URI) link to a promotion or coupon, a lottery ticket, or any other indicia of a transaction involving funds. An external (to the wallet) daemon job can be written to inspect a payload for a lottery ticket, for example, to check if a winning number is associated with the lottery ticket.

Treatment of the wallet as a co-equal standalone peer of all vertical gaming systems, memorializing all transactions passing through the wallet as immutable and unalterable facts, virtualizing all services within the wallet as a single virtual service so that the wallet is treated as a service, among other attributes result in a highly scalable, fault-tolerant, extensible, contention-free, flexible architecture for deployment of a digital wallet in any multi-gaming ecosystem, regardless of system constraints or requirements. Another way to view the wallet is that its ledgers provide a single source of truth for all transactions conducted relative to the wallet. For example, data stored in the wallet is completely agnostic as to the data model that defines how the data should be organized. One gaming system may demand a row-column type of data model, but another gaming system may demand a column-row or graph type of data model. In other words, the data in the wallet is not beholden to any data model. Because the entire history of transactions or any subset thereof can be recreated at will, even if originally a data model of a first type were applied to the wallet data, when recreated, a different data model of another type can be applied to the recreated data by simply writing a new extract-load-transform (ETL) job, allowing different perspectives to emerge, to conform the wallet data to the requirements of another vertical gaming system, or to rebuild the system automatically, all without ever having to recertify the wallet.

According to an aspect of the present invention, a standalone digital wallet manager managing a plurality of balances of funds associated with a plurality of players of one or more gaming systems, includes: one or more processors; one or more memory devices coupled to the one or more processors; one or more data storage devices utilizing one or more data models; an input interface and an output interface; a plurality of software services operated by the one or more processors and deployed over a representational state transfer (REST) service utilizing a hypertext transfer protocol (HTTP), each of the software services responding to request or response calls over the REST service; a request queue receiving asynchronous request calls from at least one of the plurality of software services via the input interface; a response queue holding response calls from at least one of the plurality of software services for communication to the output interface, wherein the plurality of software services includes a responsible gaming service having a responsible gaming ledger response queue; a storage queue feeding the one or more data storage devices the plurality of balances of funds associated with the plurality of players of one or more gaming systems; and a ledger service coupled to the storage queue, the response queue, and the request queue, the ledger service managing access to the balances of funds stored in the storage queue. Each of the request queue, the response queue, and the storage queue is immutable such that all new entries to the queue are appended sequentially to the queue and no edits or deletion of any existing entries in the queue is permitted.

The wallet manager can further include a rules engine coupled to the ledger service, the rules engine including a plurality of conversion rates and a corresponding rule associated with each of the conversion rates. Each of the conversion rates can indicate a conversion exchange value between at least two funds of different types, and each of the corresponding rules can indicate one or more conditions that must be satisfied to convert between the at least two funds of different types. At least one of the conversion rates can indicate a conversion exchange value between a first fund of a first type associated with a first of the one or more gaming systems and a second fund of a second type associated with a second of the one or more gaming systems, wherein the first and the second gaming systems are of different types. The different types are distinct ones of a casino gaming system, a lottery gaming system, a sports betting gaming system, or a social gaming system.

The wallet manager can further include a rules engine coupled to the ledger service. The rules engine can include a rule that creates a new value to add to one of the plurality of balances of funds associated with one of the plurality of players. The new value has no exchange value when created. The rule can indicate at least one condition to be satisfied by the one of the plurality of players interacting with any one or more of the one or more gaming systems and an extent of the new value to be added when the at least one condition is satisfied.

One of the pluralities of software services can be a read-only vault service that exposes data obtained or derived from the storage queue to the output interface. The data can be exposed via an extract, transform, and load (ETL) process operating on a distributed database management system. All request or response calls relative to the input or output interface can pass through the request queue or the response queue. All messages stored in the request queue or in the response queue can be exposed by their respective logical offsets in the queue.

An identifier (ID) of a new message to be appended to the request queue or the response queue can be computed by adding a length of a current message to its logical offset without associating any explicit message-IDs to any of the messages stored in the request queue or the response queue. The request queue can be a plurality of request queues including any two or more of the following queues: a wager queue, a win queue, a purchase queue, an award queue, a deposit queue, and a withdraw queue. The wager queue can store requests to deduct an amount of money from a requested one of the balances of funds associated with a requested one of the players, the deducted amount of money corresponding to an amount of a wager placed by the requested player on one of the one or more gaming systems. The win queue can store requests to deposit an amount of money to a requested one of the balances of funds associated with a requested one of the players. The deposited amount of money can correspond to an amount of a win awarded to the requested player by one of the one or more gaming systems. The purchase queue can store requests to purchase a number of virtual credits by the requested player in one of the one or more gaming systems. The deposit queue can store requests to deposit an amount of real money into the requested one of the balances of funds. The withdraw queue can store requests to withdraw an amount of real money from the requested one of the balances of funds.

At least one of the request calls can include a payload associated with at least one of the funds passing through the storage queue. The payload can include a uniform resource locator (URL) link or a uniform resource indicator (URI) or a receipt or other indicia of a transaction involving funds. At least one of the response calls can include the same payload in unaltered form.

The one or more gaming systems can include a first gaming system of a first type and a second gaming system of a second type distinct from the first type. The first type can be a casino gaming system, a lottery gaming system, a sports betting gaming system, or a social gaming system, and the second type can be any other of the first type.

The immutability of the request, response, and storage queues can allow data stored in the one or more data storage devices to be organized according to or characterized by any data model. Data stored in the one or more data storage devices can be independent of whichever data model is used to organize or characterize the data. The one or more data storage devices can include one or more mass storage devices.

According to another aspect of the present disclosure, a computer-implemented method is provided of managing a plurality of balances of funds associated with a plurality of players of one or more gaming systems. The method includes: operating a plurality of software services by one or more processors; deploying the plurality of software services over a representational state transfer (REST) service utilizing a hypertext transfer protocol (HTTP), each of the software services responding to request or response calls over the REST service; receiving in a request queue asynchronous request calls from at least one of the plurality of software services via an input interface; holding response calls in a response queue from at least one of the plurality of software services for communication to an output interface; a storage queue feeding one or more data storage devices the plurality of balances of funds associated with the plurality of players; managing access to the balances of funds stored in the storage queue by a ledger service coupled to the storage queue, the response queue, and the request queue, wherein each of the request queue, the response queue, and the storage queue is immutable such that all new entries to the queue are appended sequentially to the queue and no edits or deletion of any existing entries in the queue is permitted.

The method can further include: providing a plurality of rules in a rules engine coupled to the ledger service. The rules engine can include a plurality of conversion rates. Each of the conversion rates can indicate a conversion exchange value between at least two funds of different types. Each of the corresponding rules can indicate one or more conditions that must be satisfied to convert between the at least two funds of different types.

At least one of the conversion rates can indicate a conversion exchange value between a first fund of a first type associated with a first of the one or more gaming systems and a second fund of a second type associated with a second of the one or more gaming systems. The first and the second gaming systems can be of different types. The different types can be distinct ones of a casino gaming system, a lottery gaming system, a sports betting gaming system, or a social gaming system.

The method can further include creating a new value by a rule operated by a rules engine coupled to the ledger service to add to one of the plurality of balances of funds associated with one of the plurality of players. The new value can have no exchange value when created. The rule can indicate at least one condition to be satisfied by the one of the plurality of players interacting with any one or more of the one or more gaming systems and an extent of the new value to be added when the at least one condition is satisfied.

The method can further include transferring all request or response calls relative to the input or output interface through the request queue or the response queue. All messages stored in the request queue or in the response queue can be exposed by their respective logical offsets in the queue.

An identifier (ID) of a new message to be appended to the request queue or the response queue can be computed by adding a length of a current message to its logical offset without associating any explicit message-IDs to any of the messages stored in the request queue or the response queue.

The request queue can be a plurality of request queues including any two or more of the following queues: a wager queue, a win queue, a purchase queue, an award queue, a deposit queue, and a withdraw queue. The wager queue can store requests to deduct an amount of money from a requested one of the balances of funds associated with a requested one of the players, the deducted amount of money corresponding to an amount of a wager placed by the requested player on one of the one or more gaming systems. The win queue can store requests to deposit an amount of money to a requested one of the balances of funds associated with a requested one of the players. The deposited amount of money can correspond to an amount of a win awarded to the requested player by one of the one or more gaming systems. The purchase queue can store requests to purchase a number of virtual credits by the requested player in one of the one or more gaming systems. The deposit queue can store requests to deposit an amount of real money into the requested one of the balances of funds. The withdraw queue can store requests to withdraw an amount of real money from the requested one of the balances of funds.

At least one of the request calls can include a payload associated with at least one of the funds passing through the storage queue, the payload including a uniform resource locator (URL) link or a URI or a receipt or other indicia of a transaction involving funds. At least one of the response calls can include the same payload in unaltered form.

The method can further include organizing data stored in the one or more data storage devices according to a first data model; reconstructing data using at least a subset of information stored in at least the storage queue; and organizing the reconstructed data according to a second data model different from the first data model. Data stored in the one or more data storage devices can be independent of whichever data model is used to organize or characterize the data.

Additional aspects of the invention will be apparent to those of ordinary skill in the art in view of the detailed description of various embodiments, which is made with reference to the drawings, a brief description of which is provided below.

While the invention is susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the invention is not intended to be limited to the forms disclosed. Rather, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

While this invention is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail preferred embodiments of the invention with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and is not intended to limit the broad aspect of the invention to the embodiments illustrated. For purposes of the present detailed description, the singular includes the plural and vice versa (unless specifically disclaimed); the words “and” and “or” shall be both conjunctive and disjunctive; the word “all” means “any and all”; the word “any” means “any and all”; and the word “including” means “including without limitation.”

For purposes of the present detailed description, the terms “wagering game,” “casino wagering game,” “casino gaming system,” “sports betting,” “gambling,” “lottery,” “slot game,” “casino game,” and the like include games in which a player places at risk a sum of money or other representation of value, whether or not redeemable for cash, on an event with an uncertain outcome, including without limitation those having some element of skill. In some embodiments, a wagering game or sports betting game involves wagers of real money, as found with typical land-based or online casino games. In other embodiments, the wagering game additionally, or alternatively, involves wagers of non-cash values, such as virtual currency, and therefore may be considered a social or casual game, such as would be typically available on a social networking web site, other web sites, across computer networks, or applications on mobile devices (e.g., phones, tablets, etc.). When provided in a social or casual game format, the wagering game may closely resemble a traditional casino game, or it may take another form that more closely resembles other types of social/casual games.

This disclosure refers to a digital unified wallet manager (UWM), shown in, which is a combined interface exposed by multiple services, which are aggregated into a single virtual service. The UWMprovides a secure, auditable, scalable gaming wallet capable of managing real money, with multiple currency support, bonus points or promotions, loyalty points, virtual credits, and play or virtual money for multiple vertical gaming systems. For convenience, the term “wallet” or wallet service can be used herein to refer to the UWMgenerally or to the single virtualized service of multiple services aggregated as the UWMand exposed via an application program interface (API). In some aspects, a wallet as used herein does not breach compliance with the Payment Card Industry (PCI) security standards, which means that no credit or debit card numbers, whether in encrypted form or otherwise, ever pass through or are stored in the UWM(although an encrypted PCI-compliant token can be stored in the UWM). The vertical computer gaming systems include any one or more of a casino gaming system, a sports betting gaming system, a lottery gaming system, and a social gaming system. Each of these computer gaming systems are treated as vertical systems relative to one another, and each has its own independent processing resources, storage and memory resources, security systems, and so forth. In this way, both the UWMand each of the gaming systems is considered architecturally to be a first-class citizen in the gaming ecosystem. By “computer” gaming system it is meant that the gaming systems operate under control of one or more computers. The terms manager, service, virtual, protocol, engine, proxy, server, topics, queue, log, window, publish-subscribe, message, data store, program, data model, interface, database, ID, link, system, cluster, event, hub, daemon, computer, applications, and their grammatical variants used throughout this disclosure have their ordinary meanings as understood by those of ordinary skill in the art of software architecture and design. The terms credits, winnings, wager, real money, play money, virtual credits, loyalty points, bonus points, lottery, social gaming, exchange value, casino, sports betting, progressive, pool, and deposit have their ordinary meanings as understood by those of ordinary skill in the art of gaming systems, including casino gaming systems, sports betting gaming systems, lottery gaming systems, and social gaming systems.

A “fund” or funds as used herein encompasses real money (e.g., real world currency), loyalty points, bonus points, progressive pools, virtual or play money, and credits including virtual credits, and representations thereof. In the case of play money, play money may or may not have a real-world exchange value. For example, play or virtual money can be used on social gaming systems, and real money can be used to purchase play money, although the reverse does not necessarily hold true, i.e., play money cannot necessarily be exchanged for real money. In fact, when traversing from a social gaming system to a lottery gaming system, for example, play money cannot be converted into corresponding real money. A balance of funds refers to a total value of funds accumulated by a player and stored in a wallet. The wallet described herein can store many different types of funds for many different players transacting these funds at many different gaming systems.

The UWMhas various attributes, some of which are summarized here and described in more detail below. The UWMis stand-alone and completely independent of the consuming vertical applications of the various gaming systems. The UWMis deployed over a representational state transfer (REST) service utilizing a hypertext transfer protocol (HTTP) and can be self-hosted in a filesystem. HTTP herein includes HTTPS.

Some workhorses of the UWMinclude a Wallet Service, a Ledger Service, a Funding Service, a Vault Service, with supporting services such as a Currency Service, a Loyalty Conversion Service, and a Timer Service. A Rules Engineis deployed to enable the Ledger Serviceto convert or award currencies between the various Ledgers. The funding of digital walletswith real money and withdrawals of real money are handled by the Funding Serviceand not the Wallet Service. The UWMcan be accessed via an application programming interface (API) proxy server. The Wallet Manageris the combined interfaces exposed by the Wallet Service, the Funding Service, and the Vault Service. These services can be aggregated into a single virtual service by the API proxy server. When the wallet is consolidated as a single virtual service, inbound data flows are consumed at an input interface thereof and outbound data flows egress from an output interface of the virtual service.

The unified virtual service of the UWMis a highly available and fault-tolerant service, which can use asynchronous queues and publish-subscribe mechanisms. The asynchronous queues can be categorized into four main types: request, response, sync, and storage queues.

Request queuesreceive requests for processing from the Wallet Service, and the Funding Service. Neither of these services,will directly call any other service. All communications between the Wallet Managerand the Ledger Servicewill be via request queuesin an asynchronous manner. These request queueshave a sliding window for message expiration.

In this example, there are six request queues, but fewer or more request queues can be present.

Wager request queue: All requests to the Wallet Managerfor a deduction of real money for the purpose of placing a wager on a gaming system() that permits wagering, such as a casino gaming system, a sports betting gaming system, or a lottery gaming system. In other words, the wager request queue stores requests to deduct an amount of money from a requested one of the balances of funds (such as the real money ledger) associated with a requesting player. The deducted amount of money corresponds to an amount of a wager placed by the requesting player on a casino gaming system.

Win request queue: A deposit via the Wallet Mangerin the event a player() has a win on a game of a gaming system, such as a casino gaming system, a sports betting gaming system, or a lottery gaming system. A player, such as shown ininteracts with the UWMusing a computer terminal over a computer network. In other words, the win request queue stores requests to deposit an amount of (real) money to a requested ledgerassociated with a player. The deposited amount of money corresponds to an amount of a win awarded to the requesting player by a casino gaming system.

Purchase request queue: Used to purchase virtual credits. The purchase request queue stores requests to purchase a number of virtual creditsby the requested player in a gaming system.

Award request queue: Used to award loyalty points.

Deposit request queue: Used by the Funding Serviceto deposit real money. The deposit request queue stores requests to deposit an amount of real money into the requested real money ledgerof the player's wallet.

Withdraw request queue: Used by the Funding Serviceto request a cash withdrawal. The withdraw request queue stores requests to withdraw an amount of real money from the requested real money ledger

Response queuesare used by services to communicate with the Wallet and Funding Services,. They generally hold responses to actions initiated by these services,that resulted in updates to balances stored in the ledgers. For example, a deposit by the Funding Servicewill result in the ledger queuebeing updated with new information that the Walletneeds to update its internal balances. The real money deposit can also trigger an update of loyalty pointsvia the Rules Engine. Response queuesalso have a sliding window for message expiration.

There are two types of response queues. A ledger response queue stores all actions that cause an update to any of the ledgersmanaged by the ledger service, which triggers a record to be added to the ledger response queue. The walletsubscribes to this ledger response queue and uses the update to update the wallet'sown internal running balances. Another type of response queueis a responsible gaming (RG) ledger queue, which is owned by an RG service. All updates to an RG profile are recorded here in the RG ledger queue. The Funding Serviceand the Wallet Servicecan both subscribe to this RG ledger queue and use the data to update their RG counters.

Storage queuesare managed by the Ledger Service. Each type of Currency support by the UWMhas its own master queue (-). Extract-transform-load (ETL) daemons used to load the reporting databases subscribe to these queues-in a distributed database management system (,). These queues are long-term storage, and many different ETL daemonscan be used to populate a data warehouse,(). The many different types of data storage that can be populated from the same immutable queues can be characterized as various indexes and materialized views on the same set of data. The ETL daemonsare not constrained by any data model.

In this example, there are five types of storage queuesmanaged by the Ledger Service:

Real money queue—This queue holds are deposits and withdrawals of real money.

Loyalty queue—Loyalty points accumulated across various vertical gaming systems.

Virtual credits queue—These are credits that have been purchased, such as P4F credits (Play4Free).