DISTRIBUTED LEDGER BASED DISTRIBUTED GAMING SYSTEM
The technology teaches a distributed gaming system, comprising a server-side node configured to administer transactions for a gambling casino, selling and redeeming chips using a private database, and recording transactions on a distributed ledger using crypto-tokens for a house account, with a token vault wallet that has a unique identifier and private key to track transactions. Customer wallets, intermediary accounts and one-way redemption wallets track transactions on the distributed ledger. Client-side nodes accept token purchase messages and transfer tokens in the ledger and record in the database, accept token-to-chip messages from an intermediary account and transfer tokens on the ledger to the redemption wallet to extinguish and record the exchange, accept chip-to-token messages from an intermediary account and transfer tokens from the vault to the customer account and record the exchange, and accept token-to-fiat messages from an intermediary account and transfer tokens to extinguish, and record the exchange.
Latest SPOONREAD INC. Patents:
This application is a continuation of U.S. patent application Ser. No. 17/060,454, entitled “DISTRIBUTED LEDGER BASED DISTRIBUTED GAMING SYSTEM”, filed 1 Oct. 2020 (Atty. Docket No. SPRD 1002-3), which is continuation-in-part of U.S. patent application Ser. No. 16/832,759, entitled “DISTRIBUTED LEDGER BASED DISTRIBUTED GAMING SYSTEM”, filed 27 Mar. 2020 (Atty. Docket No. SPRD 1002-2), which claims the benefit of U.S. Provisional Patent Application No. 62/965,153, entitled “BLOCK CHAIN BASED CASHLESS GAMING TABLE”, filed 23 Jan. 2020 (Atty. Docket No. SPRD 1002-1); which applications are incorporated herein by reference.
BACKGROUND Technological FieldThe present invention generally relates to the field of gaming casinos and in particular to a framework of tools improving technology used for interactions between gaming customers and the gaming casino house.
Description of Related ArtCasinos are an area of business with a focus on luxury and pampering of guests and customers as they come and go. With this focus on customer experience, it makes sense to give those visiting the casino what they need right at their fingertips with concierge apps that act as a virtual best friend for customers staying and playing at a casino.
A blockchain network is a decentralized and distributed system that hosts electronic ledgers that can record transactions efficiently and in a verifiable and permanent way. The electronic ledgers comprise blocks of transactions and other information pertinent to the blocks. Transactions can encode for example, transfers of control of tokens between participants in the blockchain network. Each block contains a cryptographic hash of the previous block, thereby creating a chain of blocks or a “blockchain.” Blockchain is an append-only linear transactional database. Examples of popular blockchain platforms include Ethereum™, Eris™, Multichain™, Bitcoin™, Hyperledger Fabric™, Credo Blockchain™, and Hyperledger Corda™.
It is desirable to provide improvements in technology than can manage transactions between a customer and a gaming house without using cash, while safely providing for redemption of non-cash tokens into fiat, and establishing immutable records of non-cash transactions available to provide transparency and trust in the network.
SUMMARYA technology is described herein that includes a method of administering transactions for a gambling casino in a distributed gaming system, including selling chips and redeeming chips using a private database, comprising recording at least some of the transactions on a distributed ledger using crypto-tokens, including one or more administrator wallets, each having a unique house identifier and private key to track transactions on the distributed ledger that include the unique house identifier. The method also includes maintaining user accounts for customers including customer wallets having unique customer identifiers and private keys to track transactions on the distributed ledger that include the unique customer identifiers and maintaining dealer accounts for dealers. The method further includes executing an application program interface (API) with client-side nodes, the API having procedures for accepting token purchase messages indicating confirmation of fiat attributed to the user account for a particular customer and in response transferring tokens from an administrator wallet to a customer wallet. The method additionally includes accepting chip purchase messages indicating confirmation of delivery of chips from a dealer account to an identified user account, and in response transferring tokens from the customer wallet of the identified user account to one of the one or more administrator wallets and recording the purchase of chips in the private database. The method also includes accepting redemption messages indicating confirmation of delivery of chips attributed to the user account for a particular customer to a dealer account, and in response transferring tokens from the customer wallet of the identified user account to one of the one or more administrator wallets and recording the redemption of chips in the private database.
The technology described herein includes a method of administering transactions for a gambling casino in a distributed gaming system, including selling chips and redeeming chips using a private database and a distributed ledger, comprising maintaining a token vault wallet having a unique house identifier and private key to track transactions on the distributed ledger that include the unique house identifier. The method also includes maintaining user accounts for customers including customer wallets having unique customer identifiers and private keys to track transactions on the distributed ledger that include the unique customer identifiers and maintaining intermediary accounts including unique intermediary identifiers and private keys to track transactions on the distributed ledger that include the unique intermediary identifiers. The method further includes maintaining a one-way redemption wallet having a unique redemption identifier and private key to track transactions on the distributed ledger that include the unique redemption identifier. The method additionally includes communicating with client-side nodes in a communication network to execute procedures. One procedure accepts token purchase messages from an identified customer account indicating confirmation of fiat payment by the identified customer account for tokens, and in response transfers tokens in the distributed ledger from the token vault to the unique customer identifier of the identified customer account, and records the token purchase in the private database. Another procedure accepts token-to-chip exchange messages from an identified intermediary account indicating confirmation of exchange tokens for chips, and in response transfers tokens on the distributed ledger to the redemption wallet to extinguish the tokens, and records the token-to-chip exchange in the private database. A further procedure accepts chip-to-token exchange messages from an identified intermediary account indicating confirmation of delivery of chips from a customer having an identified customer account to an intermediary having the identified intermediary account, and in response transfers tokens in the distributed ledger from the token vault to the unique customer identifier of the identified customer account, and records the chip-to-token exchange in the private database. Yet another procedure accepts token-to-fiat exchange messages from an identified intermediary account indicating confirmation of delivery of fiat currency to a customer having an identified user account, and in response transfers tokens from the customer wallet of the identified user account to the redemption wallet to extinguish, and records the token-to-fiat exchange in the private database and on the distributed ledger.
The technology disclosed also includes a computer system having one or more network nodes, configured to execute a set of procedures for establishing and maintaining accounts and for executing the methods described herein.
The technology disclosed also includes a computer program product storing a computer program on non-transitory memory, which when executed at one or more network nodes, executes a set of procedures for establishing and maintaining accounts and other methods described herein.
Other aspects and advantages of the present technology can be seen on review of the drawings, the detailed description and the claims, which follow.
A detailed description of embodiments of the technology is provided with reference to the
A flexible technology platform that supports administering transactions for a gambling casino in a distributed gaming system, including selling chips and redeeming chips using a private database is described herein. The platform provides a technology executed efficiently for frequent, embedded, real-time monitoring of the experience of customers of the gaming house and the experience of the gaming house itself.
The cashless casino gaming system described herein provides a computer implemented device around gambling, many of the layers of which come together to convert the value of physical chips used at gaming tables to stable digital tokens on blockchain. The digital tokens are backed by fiat currency, also known as legal tender, whose value is backed by the government that issued it.
The system includes or has access to a financial repository, or repositories, for fiat currency, and includes or has access to a house blockchain account. The system includes procedures to declare a set of tokens and to store the tokens in trust assurance network. The system includes procedures to distribute stored cryptocurrency tokens tied to the fiat currency in the repository or repositories, and to exchange tokens in the house account for the fiat currency in the financial repository. Tokens in user accounts and in the house account, and tokens exchanged for the chips in circulation, are immutably recorded in the blockchain. The value of the tokens and chips are backed by a promise to exchange them for fiat currency, supported by the immutable records.
Tokens can be transferred among users of blockchain using applications referred to as wallets or digital wallets. A wallet maintains in a secure memory unique identifiers for the holder of the wallet, and provides an interface useable by the holder to support monitoring of the blockchain to identify blockchain transactions to receive tokens and to support creation of blockchain transactions to transfer tokens linked to the unique identifier or unique identifiers of the holder to other participants in the blockchain.
As used herein, a network node is an addressable application running on a hardware device or virtual device that is attached to a network, and is capable of sending, receiving, or forwarding information over a communications channel to or from other network nodes. Examples of electronic devices which can be deployed as hardware network nodes include all varieties of computers, workstations, laptop computers, handheld computers, and smartphones. Network nodes can be implemented in a cloud-based server system. More than one virtual device configured as a network node can be implemented using a single physical device.
Trust assurance network 106 serves as a banking network buffer and can have an interface for transactions in banking networks, also referred to as financial repository 105. Electronic tokens are fiat backed for participants in the trust assurance network 106 who agree to rely on the banking network buffer to isolate the transactions in the trust assurance network from the banking network, and to rely on agreements to exchange tokens in the trust assurance network for cash in the banking network. The blockchain system 118 provides immutability and transparency for the participants and works to establish trust. Trust assurance network 106 maintains and tracks a strict balance of cash in one or more financial repositories, with issued tokens in circulation on the blockchain and chips in circulation among customers (and others). Security is insured via the immutability of transactions on the distributed ledger in addition to the use of a private database for tracking transactions. The server-side node or nodes in the distributed gaming system are configured to maintain a token vault wallet having a unique house identifier and private key to track transactions on the distributed ledger that include the unique house identifier. The data processors of the server-side node or nodes include logic for authentication and authorization of intermediary account holders and customer account holders at client-side nodes. This logic includes a first protocol for customer account holders on client-side nodes on the communication network, and a second protocol for intermediary account holders on client-side nodes on the communication network. The second protocol for intermediary account holders can include receiving from an authorized supervisor application a request to enable a dealer application, generating a verification code for the request, providing the verification code to the supervisor application in response to the request from the supervisor application to enable a particular intermediary account holder, the verification code being provided to a dealer outside the communication network, and receiving a login request via the communication network from a dealer application to login the particular intermediary account holder by the dealer application using the verification code. Examples of intermediary account holders are dealers and merchants, who each have a unique private key and identifier for their corresponding intermediary accounts.
The server-side node or nodes are configured to create, or utilize, a tranche of tokens in the token vault wallet. The server-side node or nodes are configured to assign tokens to the token vault wallet in response to a message confirming receipt of value. This value can be cash, surety, or other obligation to honor the fiat value of the tokens. The gambling house sends the fiat currency amount to the designated program bank account and receives a message confirming receipt of value, in one scenario. In a different scenario customer-funded tokens can be minted in the token vault wallet. Assignment of tokens to the token vault wallet can be completed using any of several blockchain platforms, including Ethereum™, Eris™, Multichain™, Bitcoin™ Hyperledger Fabric™, Credo Blockchain™, and Hyperledger Corda™.
In
Management system 104 is a server-side node configured to administer transactions for the gambling casino, for selling chips and redeeming chips, and includes a house account with at least one administrator wallet to track transactions. Management system 104 includes one or more data processors, having access to a private database and a distributed ledger. Management system 104 maintains user accounts for customers, including customer wallets that accept messages indicating confirmation of transactions on the distributed ledger that include the customer's unique identifier, via customer app 102 API. That is, the customer's wallet tracks blockchain transactions and token balance. The customer wallet is related to a corresponding customer account using the customer's unique identifier. Additionally, customer app 102 API procedures identify and authenticate the user, in some cases storing the customer's unique QR code and providing near field communication for authenticating the user. Customer app 102 API procedures can also enable a user to request transactions with marketplaces, in some cases.
When a customer registers for the first time, a customer identification code is generated and loaded into the customer wallet after registration is complete. The customer authentication code is a QR code, in one case. Additional registration elements may be included. When the customer requests digital tokens, customer app 102 API procedures initiate the purchase of digital tokens via a credit card or a cash transaction with a teller. Tokens are transferred to the customer using the customer's unique customer identifier, also known as their blockchain address, via a blockchain transaction also serving as a recording of the cash transaction. The teller functionality of processing a credit card or cash is automated in one implementation; in another the teller is a human. The result of a successful customer transaction requesting to buy digital tokens is the transfer of fiat currency to the financial institution, and the transfer of electronic tokens to the customer wallet in the trust assurance network 106. Management system 104 is configured to administer the transactions for the casino, including selling chips and redeeming chips using a private database. Management system 104 records the transactions on a distributed ledger using crypto-tokens, including administrator wallets, each of which has a unique house identifier and private key to track transactions on the distributed ledger that include the unique house identifier.
Customer app 102 identifies and authenticates the customer as present and ready to interact at the table, via multi-factor authentication (MFA) with some combination of multiple identifiers for the customer, such as near field communication, unique QR code and customer PIN before completing point of sale (PoS) transactions. Dealer app 103 receives a request for an electronic token transfer for physical chips for a customer at a gaming table. A verbal exchange, or an exchange of electronic messages, between the dealer and the pit boss confirms the requested transaction, in some scenarios, and the customer receives physical chips in exchange for the customer electronic tokens and uses the physical chips to complete play at the casino tables. Both physical chips and digital tokens are directly usable for shopping for food and drinks and merchandise and services, in some implementations of the digital wallet. In some cases, customer app 102 also receives loyalty digital tokens, based on rules that identify transaction patterns to be rewarded. When the customer leaves the property or community, they can exchange physical chips for digital tokens, typically with a dealer using dealer app 103 at a gaming table. Customer app 102 completes a blockchain transaction transferring the digital tokens to an administrator wallet, in which the tokens correspond to actual cash units (ACUs) that have a one to one value with the fiat currency and can be exchanged for cash or credit card credit. In this scenario, the result of a successful customer transaction is that management system 104 returns to the customer the value of the customer's unused digital tokens via the transfer of ACUs, using fiat currency from the bank or via credit being issued to the customer's credit card in exchange for the digital tokens in the customer's digital wallet.
In an example system, wallets are maintained for the various participants, including the following:
-
- 1) Customer Wallet: Stores Tokens that a customer can use to exchange fiat currency for tokens, tokens for chips, chips for tokens, and tokens for fiat currency.
- 2) Dealer Wallet: Stores Tokens derived from Tips (from Chips). Dealer can exchange chips for tokens, and tokens for fiat currency.
- 3) Token Vault (Wallet): Source of all tokens which traverse the trust assurance network. All tokens of a given tranche or all tranches generated & stored here when the system is initialized for the casino tokens on the blockchain network.
- 4) House Redemption Wallet: Tokens are sent here, and extinguished, when the house delivers cash or chips to customers, merchants, or a house account in exchange for tokens.
- 5) Merchant Wallet: Tokens are sent here from a customer wallet when a Merchant offer is redeemed from the marketplace. Tokens in a merchant wallet can be exchanged for fiat currency.
- 6) House Wallet: Tokens are sent here from a customer wallet when a custom house offer (for goods or services other than chips) is redeemed from the marketplace. Tokens in a house wallet can be exchanged for fiat currency.
Management system 104 manages access by the server-side node to dealer account records by a supervisor application in cooperation with a supervisor account that includes supervisor account records identifying a set of dealer accounts under supervision. This includes receiving from a supervisor application a request to enable a dealer application. The protocol includes generating a verification code for the request, providing the verification code to the supervisor application in response to the request from the supervisor application to enable a particular dealer account. The verification code can be provided to a dealer. The protocol also includes receiving a login request from a dealer application to login the particular dealer account including the verification code, and in response authorizing access to dealer account records for the particular dealer account by the dealer application. These steps securely link the dealer application to the server.
Continuing the description of
Using the disclosed distributed ledger transactions for customers, the identity of customers and of dealers and their private identity information (PII) are protected. In one case, table dealers are onboarded by employee number assigned by the company, and that resolves within their HR system. The sovereign identity system (SIS) manages codes for login to PoS and monitoring apps. Hierarchy and login control enable reporting to be accessed by only those who are securely registered.
For the distributed gaming system, a disclosed house account, with a unique house identifier and private key, records transactions on a distributed ledger using crypto-tokens. Administrator wallet 222 tracks transactions on the distributed ledger that include the unique house identifier. The distributed ledger can utilize a blockchain platform such as Ethereum™ Eris™, Multichain™, Bitcoin™, Hyperledger Fabric™, Credo Blockchain™, and Hyperledger Corda™. Customers carry digital currency around in customer wallets, with access via their mobile devices. Fiat to token transactions are recorded at back of house and token to chip and chip to token transactions are viewed by the supervisor in supervisor wallet 228 (pit boss) on the casino floor. Token to chip and chip to token transactions are recorded to administrative app 212 in administrator wallet 222 (back of house) and in a private database. An AI based bot can be utilized to analyze frames of data in the private database, and transactions on the blockchain recorded in wallets, for fraud detection across all transaction points, including the interactions between the PoS at the dealer table and the back of house actions, in one implementation.
Management system 104 further includes message processing API 408 that accepts input messages indicating confirmation of payment by a customer and in response transfer tokens from an administrator wallet to a customer wallet. The input messages are API calls that utilize a representational state transfer (REST) API in one implementation. In one case, payment by a customer is via Stripe, a service that allows its users to accept payments online and to keep track of payments and search past payments. In another case, PayPal or Square or other payment processing APIs can be implemented. Message processing API 408 also accepts input messages indicating confirmation of delivery of chips from a dealer to a customer, and in response transfer of tokens from a customer wallet to at least one administrator wallet 222. The dealer app 103 user interface displays a confirmation requirement for the dealer to acknowledge the completion of the transfer of physical chips to a customer in exchange for electronic tokens transferred. Message processing API 408 also accepts input messages indicating confirmation of delivery of chips from a customer to a dealer, and in response transfers tokens from at least one administrator wallet 222 to a customer wallet 262. The dealer app 103 user interface displays a confirmation requirement for the dealer to acknowledge the completion of the transfer of physical chips from a customer in exchange for electronic tokens transferred to the customer. Management system 104 also includes redemption wallet API 415 having a unique redemption identifier and private key to track transactions on the distributed ledger that include the unique redemption identifier. Redemption wallet processes a one directional transaction to extinguish tokens converted to chips, and to extinguish tokens converted to fiat currency. Records in the distributed ledger of extinguished tokens provide a traceable history, for transparency for the customer and for non-repudiation protection for the house, of each step of the history of exchanges.
Management system 104 further includes status tracker and reporter module 418 that records the transactions on a distributed ledger using crypto-tokens for a house account having a unique house identifier and private key, tracking transactions and performance of individual customers and dealers. Status tracker and reporter module 418 maintains user accounts for customers including unique customer identifiers and private keys, utilizing customer wallets 262 that track transactions on the distributed ledger that include a unique customer identifier. The unique customer identifier is the blockchain address for the customer, in one implementation. Status tracker and reporter module 418 also maintains dealer accounts for dealers including unique dealer identifiers and private keys, utilizing dealer wallets 255 that track transactions on the distributed ledger that include a unique dealer identifier, which is the blockchain address for the dealer in one implementation. API for data structures 405 is used to access and update data structures that support the transactions.
Management system 104 also includes tools 425 for display of reports of the status for dealers and customers. Transaction reports can be displayed on a smart phone or tablet in one example, and may be utilized by a floor supervisor, pit boss or dealer to review transactions of customers using the gambling system and to review rewards earned by customers under its supervision according to game rules. Hierarchy and login control enables house reporting to be viewable from multiple perspectives, including data fields of time, supervisor, table, dealer, customer, transaction type, and transaction amount, because the data is included in the distributed ledger entries on the blockchain.
Management system 104 also includes login module 422 which supports identification of a back of house administrator, as well as authentication and authorization procedures necessary for linking to PoS table 225. Management system 104 further includes an ecommerce link 428 linking to resources for the purposes of supporting electronic commerce to obtain rewards in support of the disclosed distributed gaming system.
An example API, including procedures and parameters used for setting up a blockchain ecosystem for blockchain transactions by the customer app and the management system are described next. Master contract interface API procedures set up a smart contract on the blockchain. Ethereum platform is utilized in the example. Ethereum is based on the use of tokens. Tokens represent digital assets, as smart contracts that make use of the Ethereum blockchain. A current instance of the Ethereum master contract pairs with the sub-contract interface declaration API. A different blockchain platform can be utilized for administering transactions for the gambling casino in a distributed gaming system. Owner contract with owner address provides basic authorization control functions, thus simplifying the implementation of user permissions for the contract. The current owner of the blockchain contract can transfer control of the contract to a new owner, in one implementation. When an Ethereum contract is executed, tokens are pre-assigned to the creator, stored in a token vault which can be one of the administrator wallets of the network described herein, in one implementation. An ERC20Basic interface parameters include the total number of tokens in existence and the total number of tokens spent in sale stages. Procedures include transfer of tokens for a specified address and amount to be transferred, as tokens ‘to’, tokens ‘from’ and ‘to’ and procedures to get the balance of the specified address. The distributed gaming system utilizes standard tokens that can be irreversibly burned (destroyed). Procedures include the transfer tokens from one address to another, the ability to check the amount of tokens that an owner allowed to a spender, the ability to increase the amount of tokens that an owner allowed to a spender, and the ability to decrease the amount of tokens that an owner allowed to a spender. The spender is a customer of a casino, in one use case.
Flowcharts illustrating procedures for administering transactions for a gambling casino in a distributed gaming system are described herein. The logic can be implemented using processors programmed using computer programs stored in memory accessible to the computer systems and executable by the processors, by dedicated logic hardware, including field programmable integrated circuits, and by combinations of dedicated logic hardware and computer programs. With all flowcharts herein, it will be appreciated that many of the steps can be combined, performed in parallel or performed in a different sequence without affecting the functions achieved. In some cases, as the reader will appreciate, a re-arrangement of steps will achieve the same results only if certain other changes are made as well. In other cases, as the reader will appreciate, a re-arrangement of steps will achieve the same results only if certain conditions are satisfied. Furthermore, it will be appreciated that the flow charts herein show only steps that are pertinent to an understanding of the invention, and it will be understood that numerous additional steps for accomplishing other functions can be performed before, after and between those shown.
The technology disclosed herein can be implemented in the context of any computer-implemented system including a database system, a multi-tenant environment, or a relational database implementation like an Oracle™ compatible database implementation, an IBM DB2 Enterprise Server™ compatible relational database implementation, a MySQL™ or PostgreSQL™ compatible relational database implementation or a Microsoft SQL Server™ compatible relational database implementation or a NoSQL™ non-relational database implementation such as a Vampire™ compatible non-relational database implementation, an Apache Cassandra™ compatible non-relational database implementation, a BigTable™ compatible non-relational database implementation or an HBase™ or DynamoDB™ compatible non-relational database implementation. In addition, the technology disclosed can be implemented using different programming models like MapReduce™, bulk synchronous programming, MPI primitives, etc. or different scalable batch and stream management systems like Apache Storm™, Apache Spark™, Apache Kafka™, Apache Flink™, Truviso™, Amazon Elasticsearch Service™, Amazon Web Services™ (AWS), IBM Info-Sphere™, Borealis™, and Yahoo! S4™.
User interface input devices 1122 may include a keyboard, pointing devices such as a mouse, trackball, touchpad, or graphics tablet, a scanner, a touchscreen incorporated into the display, audio input devices such as voice recognition systems, microphones, and other types of input devices. In general, use of the term “input device” is intended to include all possible types of devices and ways to input information into network node 1102 or onto network 115.
User interface output devices 1120 may include a display subsystem, a printer, a fax machine, or nonvisual displays such as audio output devices. The display subsystem may include a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a projection device, or some other mechanism for creating a visible image. The display subsystem may also provide a nonvisual display such as via audio output devices. In general, use of the term “output device” is intended to include all possible types of devices and ways to output information from network node to the user or to another machine or network node. In particular, an output device of the network node on which the e-book engagement system is implemented, may include a visual output informing a user of action recommendations made by the system, or may include a communication device for communicating action signals.
Storage subsystem 1124 stores the basic programming and data constructs that provide the functionality of certain embodiments of the present invention. For example, the various modules implementing the functionality of certain embodiments of the invention may be stored in storage subsystem 1124. These software modules are generally executed by processor subsystem 1162.
Memory subsystem 1126 typically includes a number of memories including a main random access memory (RAM) 1130 for storage of instructions and data during program execution and a read-only memory (ROM) 1132 in which fixed instructions are stored. File storage subsystem 1128 provides persistent storage for program and data files, and may include a hard disk drive, a floppy disk drive along with associated removable media, a CD ROM drive, an optical drive, or removable media cartridges. The databases and modules implementing the functionality of certain embodiments of the invention may have been provided on a computer-readable medium such as one or more CD-ROMs, volatile memory, non-volatile memory, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed. The databases and modules implementing the functionality of certain embodiments of the invention may also be stored by file storage subsystem 1128. The host memory subsystem 1126 contains, among other things, computer instructions which, when executed by the processor subsystem 1162, cause the computer system to operate or perform functions as described herein. As used herein, processes and software that are said to run in or on “the host,” “the computer” or “the network,” execute on the processor subsystem 1162 in response to computer instructions and data in the host memory subsystem 1126 including any other local or remote storage for such instructions and data.
Bus subsystem 1155 provides a mechanism for letting the various components and subsystems of network node 1102 communicate with each other as intended. Although bus subsystem 1155 is shown schematically as a single bus, alternative embodiments of the bus subsystem may use multiple busses.
A network node can be of varying types including a personal computer, a portable computer, smart phone, tablet computer, a workstation, a computer terminal, a network computer, a television, a mainframe, a server farm, a widely-distributed set of loosely networked computers, or any other data processing system or user device. Due to the ever-changing nature of computers and networks, the description of network node depicted in
In some embodiments, in addition, one or more of the server application, the supervisor application, and the reader application can be implemented in the network node as a Software-as-a-Service (SaaS) application, a web-architected application or a cloud-delivered service. Examples of common SaaS applications today include Salesforce.com™, Box™ Dropbox™, Google Apps™, Amazon Web Services AWS™, Microsoft Office 365™, Workday™, Oracle on Demand™, Taleo™, Yammer™, and Concur™. SaaS applications provide functionalities to users that are implemented in the cloud, and that are the target of policies, e.g., logging in, editing user information, updating whitelists, deleting contacts from the contact list, in contrast to the offerings of simple websites and e-commerce sites. Note that a SaaS application can be supported by both web browser clients and application clients that use URL-based APIs (application programming interfaces).
Disclosed technology for managing transactions between a customer and a gaming house without using cash utilizes blockchain transactions enabling a management application to facilitate purchase of digital tokens by the customer using a credit card or cash and providing the digital tokens via blockchain transaction. Also included is receiving a request from the customer, at a PoS table, for chips in exchange for tokens and exchanging the tokens for chips using a blockchain transaction. Further disclosed is exchanging a quantity of physical chips for digital tokens and exchanging the digital tokens for fiat currency via a blockchain transaction.
Other implementations of the method described in this section can include a non-transitory computer readable storage medium storing instructions executable by a processor to perform any of the methods described above. Yet another implementation of the method described in this section can include a system including memory and one or more processors operable to execute instructions, stored in the memory, to perform any of the methods described above.
Any data structures and code described or referenced above are stored according to many implementations on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, volatile memory, non-volatile memory, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed.
The system delivers tokens to customers using a blockchain transfer from trust assurance network blockchain account. The system includes procedures to deliver tokens to customers, using a blockchain transaction. The system also includes procedures to use a blockchain transaction to exchange tokens for chips, and to extinguish tokens exchanged for the chips. The system further includes procedures to transfer tokens to the house blockchain account using a blockchain transaction, such as for chips “lost” by a customer in a game.
While the present invention is disclosed by reference to the preferred embodiments and examples detailed above, it is to be understood that these examples are intended in an illustrative rather than in a limiting sense. It is contemplated that modifications and combinations will readily occur to those skilled in the art, which modifications and combinations will be within the spirit of the invention and the scope of the following claims. What is claimed is:
Claims
1. A distributed gaming system, comprising:
- a server-side node or nodes, including one or more data processors, having access to a distributed ledger, the server-side node or nodes configured to:
- maintain a crypto-token vault wallet having a unique house identifier and private key to track transactions on the distributed ledger that include the unique house identifier;
- maintain user accounts for customers, including unique customer identifiers and private keys to track transactions on the distributed ledger that include the unique customer identifiers;
- maintain intermediary accounts, including unique intermediary identifiers and private keys to track transactions on the distributed ledger that include the unique intermediary identifiers;
- maintain a redemption wallet having a unique redemption identifier and private key to track transactions on the distributed ledger that include the unique redemption identifier; and
- communicate with client-side nodes in a communication network to execute procedures: to accept crypto-token purchase messages from an identified customer account indicating confirmation of fiat payment by the identified customer account for crypto-tokens, and in response transfer crypto-tokens in the distributed ledger from the crypto-token vault wallet to the unique customer identifier of the identified customer account, and record a crypto-token purchase; to accept crypto-token-to-chip exchange messages from an identified intermediary account indicating confirmation of exchange of crypto-tokens for chips, and in response transfer crypto-tokens on the distributed ledger to the redemption wallet to extinguish the crypto-tokens, and record a crypto-token-to-chip exchange; to accept chip-to-crypto-token exchange messages from an identified intermediary account indicating confirmation of delivery of chips from a customer having an identified customer account to an intermediary having the identified intermediary account, and in response transfer crypto-tokens in the distributed ledger from the crypto-token vault wallet to the unique customer identifier of the identified customer account, and record a chip-to-crypto-token exchange; and to accept crypto-token-to-fiat exchange messages from an identified intermediary account indicating confirmation of delivery of fiat currency to a customer having an identified user account, and in response transfer tokens from the identified user account to the redemption wallet to extinguish, and record a crypto-token-to-fiat exchange on the distributed ledger.
2. The system of claim 1, the server-side node or nodes being configured to create a tranche of crypto-tokens in the crypto-token vault wallet.
3. The system of claim 1, the server-side node or nodes being configured to assign crypto-tokens to the crypto-token vault wallet in response to a message confirming receipt of value.
4. The system of claim 1, wherein the one or more data processors of the server-side node or nodes include logic for authentication and authorization of intermediary account holders and customer account holders at client-side nodes, including a first protocol for customer account holders on client-side nodes on the communication network, and a second protocol for intermediary account holders on client-side nodes on the communication network.
5. The system of claim 4, wherein the second protocol for intermediary account holders includes
- receiving from a supervisor application a request to enable a dealer application;
- generating a verification code for the request;
- providing the verification code to the supervisor application in response to the request from the supervisor application to enable a particular intermediary account holder, the verification code being provided to a dealer outside the communication network; and
- receiving a login request via the communication network from a dealer application to login the particular intermediary account holder by the dealer application using the verification code.
6. (canceled)
7. (canceled)
8. (canceled)
9. The system of claim 1, wherein the server-side node or nodes is configured to maintain a dealer wallet for intermediary accounts to track transaction on the distributed ledger for the corresponding intermediary account.
10. The system of claim 1, wherein the server-side node or nodes is configured to maintain a customer wallet for customer accounts to track transaction on the distributed ledger for the corresponding customer account.
11. A non-transitory computer readable memory storing computer instructions for administering transactions for a gambling casino in a distributed gaming system, including selling chips and redeeming chips using a distributed ledger, comprising computer instructions to:
- maintain a crypto-token vault wallet having a unique house identifier and private key to track transactions on the distributed ledger that include the unique house identifier;
- maintain user accounts for customers, including unique customer identifiers and private keys to track transactions on the distributed ledger that include the unique customer identifiers;
- maintain intermediary accounts, including unique intermediary identifiers and private keys to track transactions on the distributed ledger that include the unique intermediary identifiers;
- maintain a redemption wallet having a unique redemption identifier and private key to track transactions on the distributed ledger that include the unique redemption identifier; and
- communicate with client-side nodes in a communication network to execute procedures: to accept crypto-token purchase messages from an identified customer account indicating confirmation of fiat payment by the identified customer account for crypto-tokens, and in response transfer tokens in the distributed ledger from the crypto-token vault wallet to the unique customer identifier of the identified customer account, and record a crypto-token purchase; to accept crypto-token-to-chip exchange messages from an identified intermediary account indicating confirmation of exchange crypto-tokens for chips, and in response transfer crypto-tokens on the distributed ledger to the redemption wallet to extinguish the crypto-tokens, and record a crypto-token-to-chip exchange; to accept chip-to-crypto-token exchange messages from an identified intermediary account indicating confirmation of delivery of chips from a customer having an identified customer account to an intermediary having the identified intermediary account, and in response transfer crypto-tokens in the distributed ledger from the crypto-token vault wallet to the unique customer identifier of the identified customer account, and record a chip-to-crypto-token exchange; and to accept crypto-token-to-fiat exchange messages from an identified intermediary account indicating confirmation of delivery of fiat currency to a customer having an identified user account, and in response transfer crypto-tokens from the identified user account to the redemption wallet to extinguish, and record a crypto-token-to-fiat exchange on the distributed ledger.
12. The non-transitory computer readable memory storing computer instructions of claim 11, including computer instructions for authentication and authorization of intermediary account holders and customer account holders at client-side nodes, including a first protocol for customer account holders on client-side nodes on the communication network, and a second protocol for intermediary account holders on client-side nodes on the communication network.
13. The non-transitory computer readable memory storing computer instructions of claim 12, wherein the second protocol for intermediary account holders includes
- receiving from a supervisor application a request to enable a dealer application;
- generating a verification code for the request;
- providing the verification code to the supervisor application in response to the request from the supervisor application to enable a particular intermediary account holder, the verification code being provided to a dealer outside the communication network; and
- receiving a login request via the communication network from a dealer application to login the particular intermediary account holder by the dealer application using the verification code.
14. (canceled)
15. (canceled)
16. The non-transitory computer readable memory storing computer instructions of claim 11, wherein the distributed ledger comprises a block chain.
17. The non-transitory computer readable memory storing computer instructions of claim 11, including computer instructions to maintain a dealer wallet for intermediary accounts to track transaction on the distributed ledger for the corresponding intermediary account.
18. The non-transitory computer readable memory storing computer instructions of claim 11, including computer instructions to maintain a customer wallet for customer accounts to track transaction on the distributed ledger for the corresponding customer account.
19. A method of administering transactions for a gambling casino in a distributed gaming system, including selling chips and redeeming chips using a distributed ledger, comprising:
- maintaining a crypto-token vault wallet having a unique house identifier and private key to track transactions on the distributed ledger that include the unique house identifier;
- maintaining user accounts for customers, including unique customer identifiers and private keys to track transactions on the distributed ledger that include the unique customer identifiers;
- maintaining intermediary accounts, including unique intermediary identifiers and private keys to track transactions on the distributed ledger that include the unique intermediary identifiers;
- maintaining a redemption wallet having a unique redemption identifier and private key to track transactions on the distributed ledger that include the unique redemption identifier; and
- communicating with client-side nodes in a communication network to execute procedures: to accept crypto-token purchase messages from an identified customer account indicating confirmation of fiat payment by the identified customer account for crypto-tokens, and in response transfer crypto-tokens in the distributed ledger from the crypto-token vault wallet to the unique customer identifier of the identified customer account, and record a crypto-token purchase; to accept crypto-token-to-chip exchange messages from an identified intermediary account indicating confirmation of exchange crypto-tokens for chips, and in response transfer crypto-tokens on the distributed ledger to the redemption wallet to extinguish the crypto-tokens, and record a crypto-token-to-chip exchange; to accept chip-to-crypto-token exchange messages from an identified intermediary account indicating confirmation of delivery of chips from a customer having an identified customer account to an intermediary having the identified intermediary account, and in response transfer crypto-tokens in the distributed ledger from the crypto-token vault wallet to the unique customer identifier of the identified customer account, and record a chip-to-crypto-token exchange; and to accept crypto-token-to-fiat exchange messages from an identified intermediary account indicating confirmation of delivery of fiat currency to a customer having an identified user account, and in response transfer crypto-tokens from the identified user account to the redemption wallet to extinguish, and record a crypto-token-to-fiat exchange on the distributed ledger.
20. The method of claim 19, including assigning crypto-tokens to the crypto-token vault wallet in response to a message confirming receipt of value.
21. The method of claim 19, including executing procedures for authentication and authorization of intermediary account holders and customer account holders at client-side nodes, including a first protocol for customer account holders on client-side nodes on the communication network, and a second protocol for intermediary account holders on client-side nodes on the communication network.
22. The method of claim 21, wherein the second protocol for intermediary account holders includes
- receiving from a supervisor application a request to enable a dealer application;
- generating a verification code for the request;
- providing the verification code to the supervisor application in response to the request from the supervisor application to enable a particular intermediary account holder, the verification code being provided to a dealer outside the communication network; and
- receiving a login request via the communication network from a dealer application to login the particular intermediary account holder by the dealer application using the verification code.
23. (canceled)
24. (canceled)
25. The method of claim 19, wherein the distributed ledger comprises a block chain.
26. The method of claim 19, including maintaining a dealer wallet for intermediary accounts to track transaction on the distributed ledger for the corresponding intermediary account.
27. The method of claim 19, including maintaining a customer wallet for customer accounts to track transaction on the distributed ledger for the corresponding customer account.
Type: Application
Filed: Jul 24, 2023
Publication Date: Jan 25, 2024
Applicant: SPOONREAD INC. (Aptos, CA)
Inventors: Bart Alan MELTZER (Corralitos, CA), Mayank V. VADODARIA (Cupertino, CA)
Application Number: 18/225,662