DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 1, 13, and 18 are objected to because of the following informalities:
In each of claims 1, 13, and 18, the first instance of “an immutable CL” should instead read “an immutable central ledger (CL)” for clarity
In claim 13, “a session has been established by the users” should instead read “a session has been established by the user”
In claim 18, “(CMS) that is associated with and a venue gaming account” should instead read “(CMS) that is associated with a venue gaming account”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 17 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 17 recites both a system and a process of using the system. When both an apparatus and a method are claimed in the same claim, it is unclear whether infringement occurs when the apparatus is constructed or when the apparatus is used. Therefore, the scope is indefinite. See MPEP § 2173.05(p). For purposes of examination, Examiner is interpreting that claim 17 was intended to instead depend upon claim 13 (rather than claim 10) and therefore claims a method.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-9, and 11-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 10, and 19 of copending Application No. 18/894,837 (hereinafter “Summers,” and published as US 2025/0111748) in view of US 2022/0148376 (hereinafter “Cleveland”). This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Pending US Application 18/894,559
Co-pending US Appl. 18/894,837 (Summers)
Claim 1: A computer system comprising at least one processor in communication with at least one memory device, with a casino management system (CMS) that is associated with a venue gaming account, and with an immutable CL that is associated with a system account that stores actual funds, the immutable CL including a venue virtual account and multiple virtual user accounts for a stored value account of a user,
the at least one processor configured to execute instructions which, when executed by the at least one processor, cause the at least one processor to:
determine a session has been established by the user at a gaming device associated with the CMS;
receive a transaction request associated with the gaming device, the transaction request identifying a transaction amount;
in response to determining the session has been established and receiving the transaction request, transmit instructions to the immutable CL to cause the immutable CL to record a virtual transfer of funds record equal to the transaction amount from a virtual user account associated with the user to the venue virtual account; and
in response to receiving a first confirmation from the immutable CL that the virtual transfer of funds record is recorded, transmit instructions to a venue system to cause the CMS to initiate a transfer of the transaction amount from the venue gaming account to a credit balance of the gaming device.
Claim 1: A computer system comprising:
at least one memory device configured to store an immutable central ledger (CL) that is associated with a system account that stores actual funds, the immutable CL including multiple virtual user accounts for a stored value account of a user, wherein each of the multiple virtual accounts is associated with a respective location;
at least one processor configured to execute instructions which, when executed by the at least one processor, cause the at least one processor to:
receive a transaction request associated with a gaming device, the transaction request identifying (i) a user of the gaming device, (ii) a location of the gaming device, and (iii) a transaction amount;
in response to receiving the transaction request, record within the immutable CL a virtual transfer of funds record equal to the transaction amount from a virtual user account associated with the user to a virtual location account associated with the location of the gaming device;
transmit instructions to cause the gaming device to load the transaction amount from a venue gaming account corresponding to the virtual location account associated with the location to a credit balance of the gaming device; and
cause an actual transfer of funds between the system account and an external account associated with the location based on the virtual transfer of funds record associated with the location.
Further regarding Claim 1, Summers is silent as to a casino management system, determining a session has been established, or receiving a confirmation that the virtual transfer record is recorded. However, Cleveland discloses a casino management system (CMS) that is associated with a venue gaming account (figs. 1, 2A-2B: casino management system server 114; fig. 4A: venue gaming account 408), and with a CL that is associated with a system account that stores actual funds (par. 0100: “the external provider server 416 that is used to store funds that may be used for wager gaming;” par. 0124: “update 818 the ledger according to CMS complete message;” par. 0088: “the server(s) 284a may be configured to electronically credit or debit the account of a player that is maintained by a financial institution, e.g., an account that is maintained via the financial institution data center 270. The server(s) 284a may, in some examples, be configured to maintain an audit record of such transactions”); in response to determining the session has been established and receiving the transaction request, transmit instructions to the CL to cause the CL to record a virtual transfer of funds record equal to the transaction amount from a virtual user account associated with the user to the venue virtual account (par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players begin… play sessions;” par. 0124: “a player at device 404 [during a session] may initiate a transfer funds request that is transmitted 802 to API 452… update 812 a ledger to indicate a transaction message will be sent to CMS 420 and then generates and transmits 814 a credit/debit message (e.g., including the transfer funds request/command) to CMS 420;” par. 0040: “a digital gaming wallet linked to a player's wagering account may… manage gaming related transactions, such as transferring funds to the virtual gaming service”); and in response to receiving a first confirmation from the CL that the virtual transfer of funds record is recorded, transmit instructions to a venue system to cause the CMS to initiate a transfer of the transaction amount from the venue gaming account to a credit balance of the gaming device (par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players begin… play sessions, performing transactions that, for example, establish a credit balance on a given gaming machine (e.g., to EGM 104);” par. 0124: “CMS 420 then generates and transmits 816 a CMS complete message to adapters 470 indicating that, for example, CMS 420 has stored a record of the credit/debit message and approved the credit/debit message. Adapters 470 then update 818 the ledger according to CMS complete message and again updates 820 the ledger to indicate a transaction message will be sent to external provider server 416. Adapters 470 then generate and transmit 822 an external debit/credit message to server 416. Server 416 then facilitates completion of the requested external transaction and generates and transmits 824 a debit/credit completion message to adapters 470. Adapters 470 then update 826 ledger to indicate receipt of the debit/credit completion message).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the casino management system and recordkeeping/confirmation of Cleveland with the system of Summers in order to more simply manage certain aspects of the casino (Cleveland, par. 0101) and to ensure proper validation that transfers are recorded and completed (Cleveland, fig. 17; par. 0124).
Regarding Claim 2, Summers is silent as to any message broker. However, Summers modified by Cleveland further discloses a message broker in communication with the at least one processor and with the CMS (fig. 4B: message queue 460 in communication with CMS 420 and at least processor of device 404; par. 0113: “the message queue 460 is provided by RabbitMQ, an open source message broker”), wherein the instructions further cause the at least one processor to transmit the instructions to cause the CMS to transfer the transaction amount through the message broker (par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits);” par. 0009: “the funds transfer request identifying a funds transfer amount and an external player account of the player”).
Regarding Claim 3, Summers modified by Cleveland further discloses a wallet database in communication with the at least one processor (par. 0127: “Process 1000 is performed via a plurality of devices, services, providers, etc. such as a gaming device 426, CMS 420, adapters 470, wallet database 610, external provider server 416, and notification service 608;” par. 0135: “The digital wallet computing system includes at least one processor in communication with a memory device storing instructions”), wherein the instructions further cause the at least one processor to: receive, through the message broker, a second confirmation from the CMS that the transaction amount is transferred to the credit balance of the gaming device (par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers);” par. 0137: “moving the second funds transfer amount from the external player account and causing a credit balance associated with the second funds transfer amount to be established at the second electronic gaming device;” par. 0169: “meter module 1422 can record the total amount of money wagered on the gaming device, total amount of money deposited, total amount of money withdrawn, total amount of winnings on the EGM. In FIG. 13, meter information is shared between the virtual gaming service 1416 and account management system 1406 using a message broker 1408”); and store the second confirmation in the wallet database (par. 0118: “wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers)… nodes 502 may be in communication with a message queue 512 (e.g., RabbitMQ), an SQL server/database 514;” par. 0124: “CMS 420 has stored a record of the credit/debit message and approved the credit/debit message. Adapters 470 then update 818 the ledger according to CMS complete message and again updates 820 the ledger to indicate a transaction message will be sent to external provider server 416).
Regarding Claim 4, Summers modified by Cleveland further discloses transmitting the instructions to cause the venue wallet system to transfer the transaction amount through a message broker (fig. 4B: message queue 460 in communication with CMS 420 and at least processor of device 404; par. 0113: “the message queue 460 is provided by RabbitMQ, an open source message broker;” par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits);” par. 0009: “the funds transfer request identifying a funds transfer amount and an external player account of the player”).
Regarding Claim 5, Summers modified by Cleveland further discloses the instructions further cause the at least one processor to determine the session has been established by determining a user card associated with the user has been entered at the gaming device (par. 0006: “After a player enters a player tracking card, a player tracking device connected to or embedded within the EGM communicates with the player tracking system to obtain, manage, and/or track player information;” par. 0112: “players 402 establishing carded gaming sessions”).
Regarding Claim 6, Summers modified by Cleveland further discloses the instructions further cause the at least one processor to determine the session has been established by receiving a request to establish the session at the gaming device from a mobile device associated with the user (par. 0102: “player app 412 may allow the player 402 to wirelessly connect with gaming devices 426 at various gaming properties, establish rated gaming sessions (e.g., wirelessly card into gaming devices 426)”).
Pending US Application 18/894,559
Co-pending US Application 18/894,837
Claim 7: The computer system of Claim 1, wherein the transaction request is received from the gaming device.
Claim 1: … receive a transaction request associated with a gaming device, the transaction request identifying (i) a user of the gaming device, (ii) a location of the gaming device, and (iii) a transaction amount…
Regarding Claim 8, Summers modified by Cleveland further discloses the transaction request is received from a mobile device associated with the user (par. 0008: “receive an initiation of a funds transfer request from the mobile device of the player;” par. 0112: “players 402 wirelessly connecting with their mobile devices 404… digital wallet system server 414 may thus recognize, register, and consider eligibility of the various devices 490 for the various funds transfers controlled by the digital wallet system 400”).
Regarding Claim 9, Summers modified by Cleveland further discloses the instructions further cause the processor to: determine the session has ended (Cleveland, par. 0106: “the player 402 may conclude their gaming session in one of many ways… the player 402 may disconnect their mobile device 404 from the local gaming device 424 (e.g., via loss of power, moving the mobile device 404 too far away from the local gaming device 424, initiate a disconnect feature within the player app 412, or the like)”); receive, from the CMS, a remaining credit balance amount that has been transferred from the gaming device to the venue gaming account (Cleveland, par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players… end play sessions… transfer credit off of the gaming machine at the end of the player's play session (e.g., from EGM 104 on cash out)”); and in response to determining the session has ended, transmit instructions to the CL to cause the CL (see claim 1 above) to record a second virtual transfer of funds record equal to the remaining credit balance from the venue virtual account to the virtual user account within the CL (Cleveland, par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players… end play sessions… transfer credit off of the gaming machine at the end of the player's play session (e.g., from EGM 104 on cash out);” par. 0136: “processor to determine, in response to the initiation of a funds transfer request, that the player has stopped playing at the electronic gaming device, determine a remaining credit balance including an amount of credits remaining at the electronic gaming device, and cause the remaining credit balance to be deposited as funds into the external player account;” par. 0124: “update 812 a ledger to indicate a transaction message will be sent to CMS 420 and then generates and transmits 814 a credit/debit message (e.g., including the transfer funds request/command) to CMS 420”).
Regarding Claim 10, Summers modified by Cleveland further discloses the instructions further cause the processor to determine the session has ended by determining a user card associated with the user has been removed at the gaming device (par. 0024: “the process may trigger based on an end of session event (e.g., on an EGM;” par. 0035: “a carded gaming session;” Examiner notes that a “carded” session would inherently/necessarily end when the card is removed by definition).
Regarding Claim 11, Summers modified by Cleveland further discloses the instructions further cause the processor to determine the session has ended by receiving a request to end the session at the gaming device from a mobile device associated with the user (par. 0106: “the player 402 may conclude their gaming session in one of many ways… the player 402 may disconnect their mobile device 404 from the local gaming device 424 (e.g., via loss of power, moving the mobile device 404 too far away from the local gaming device 424, initiate a disconnect feature within the player app 412, or the like)”).
Regarding Claim 12, Summers modified by Cleveland further discloses the instructions further cause the processor to determine the session has ended by determining a mobile device associated with the user is not detected by a wireless beacon of the gaming device (par. 0106: “the player 402 may conclude their gaming session in one of many ways… moving the mobile device 404 too far away from the local gaming device 424”).
Pending US Application 18/894,559
Co-pending US Application 18/894,837
Claim 13: A method performed by at least one processor in communication with at least one memory device, with a venue wallet system that is associated with a venue gaming account, and with an immutable CL that is associated with a system account that stores actual funds, the immutable CL including a venue virtual account and multiple virtual user accounts for a stored value account of a user, the method comprising:
determining a session has been established by the users at a gaming device associated with the venue wallet system;
receiving a transaction request associated with the gaming device, the transaction request identifying a transaction amount;
in response to determining the session has been established and receiving the transaction request, transmitting instructions to the immutable CL to cause the immutable CL to record a virtual transfer of funds record equal to the transaction amount from a virtual user account associated with the user to the venue virtual account; and
in response to receiving a first confirmation from the immutable CL that the virtual transfer of funds record is recorded, transmitting instructions to a venue system to cause the venue wallet system to initiate a transfer of the transaction amount from the venue gaming account to a credit balance of the gaming device.
Claim 10: A computer-implemented method performed by at least one processor in communication with at least one memory device configured to store an immutable central ledger (CL) that is associated with a system account that stores actual funds, the immutable CL including multiple virtual user accounts for a stored value account of a user, wherein each of the multiple virtual accounts is associated with a respective location, the computer-implemented method comprising:
receiving a transaction request associated with a gaming device, the transaction request identifying (i) a user of the gaming device, (ii) a location of the gaming device, and (iii) a transaction amount;
in response to receiving the transaction request, recording within the immutable CL a virtual transfer of funds record equal to the transaction amount from a virtual user account associated with the user to a virtual location account associated with the location of the gaming device;
transmitting instructions to cause the gaming device to load the transaction amount from a venue gaming account corresponding to the virtual location account associated with the location to a credit balance of the gaming device; and
causing an actual transfer of funds between the system account and an external account associated with the location based on the virtual transfer of funds record associated with the location.
Further regarding Claim 13, Summers is silent as to a casino management system, determining a session has been established, or receiving a confirmation that the virtual transfer record is recorded. However, Cleveland discloses these missing elements. See explanation and rationale for combining Summers and Cleveland regarding claim 1 above.
Regarding Claim 14, Summers modified by Cleveland further discloses transmitting the instructions to cause the venue wallet system to transfer the transaction amount through a message broker (fig. 4B: message queue 460 in communication with CMS 420 and at least processor of device 404; par. 0113: “the message queue 460 is provided by RabbitMQ, an open source message broker;” par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits);” par. 0009: “the funds transfer request identifying a funds transfer amount and an external player account of the player”).
Regarding Claim 15, Summers modified by Cleveland further discloses receiving, through the message broker, a second confirmation from the venue wallet system that the transaction amount is transferred to the credit balance of the gaming device (par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers);” par. 0137: “moving the second funds transfer amount from the external player account and causing a credit balance associated with the second funds transfer amount to be established at the second electronic gaming device;” par. 0169: “meter module 1422 can record the total amount of money wagered on the gaming device, total amount of money deposited, total amount of money withdrawn, total amount of winnings on the EGM. In FIG. 13, meter information is shared between the virtual gaming service 1416 and account management system 1406 using a message broker 1408”); and storing the second confirmation in a wallet database (par. 0118: “wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers)… nodes 502 may be in communication with a message queue 512 (e.g., RabbitMQ), an SQL server/database 514;” par. 0124: “CMS 420 has stored a record of the credit/debit message and approved the credit/debit message. Adapters 470 then update 818 the ledger according to CMS complete message and again updates 820 the ledger to indicate a transaction message will be sent to external provider server 416).
Regarding Claim 16, Summers modified by Cleveland further discloses the instructions further cause the at least one processor to store the first confirmation in the wallet database (par. 0124: “CMS 420 has stored a record of the credit/debit message and approved the credit/debit message”).
Regarding Claim 17, Summers modified by Cleveland further discloses determining the session has ended (par. 0106: “the player 402 may conclude their gaming session in one of many ways… the player 402 may disconnect their mobile device 404 from the local gaming device 424 (e.g., via loss of power, moving the mobile device 404 too far away from the local gaming device 424, initiate a disconnect feature within the player app 412, or the like)”);
receiving, from the venue wallet system, a remaining credit balance amount that has been transferred from the gaming device to the venue gaming account (Cleveland, par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players… end play sessions… transfer credit off of the gaming machine at the end of the player's play session (e.g., from EGM 104 on cash out)”); and in response to determining the session has ended, transmitting instructions to the immutable CL to cause the immutable CL (see claim 1 above) to record a second virtual transfer of funds record equal to the remaining credit balance from the venue virtual account to the virtual user account within the immutable CL (Cleveland, par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players… end play sessions… transfer credit off of the gaming machine at the end of the player's play session (e.g., from EGM 104 on cash out);” par. 0136: “processor to determine, in response to the initiation of a funds transfer request, that the player has stopped playing at the electronic gaming device, determine a remaining credit balance including an amount of credits remaining at the electronic gaming device, and cause the remaining credit balance to be deposited as funds into the external player account;” par. 0124: “update 812 a ledger to indicate a transaction message will be sent to CMS 420 and then generates and transmits 814 a credit/debit message (e.g., including the transfer funds request/command) to CMS 420”).
Examiner reiterates that claim 17 is being interpreted to depend upon claim 13 instead of claim 10. See rejection under 35 U.S.C. § 112 above.
Pending US Application 18/894,559
Co-pending US Application 18/894,837
Claim 18: At least one non-transitory computer-readable storage media having instructions embodied thereon, wherein when executed by at least one processor in communication with at least one memory device, with a casino management system (CMS) that is associated with a venue gaming account, and with an immutable CL that is associated with a system account that stores actual funds, the immutable CL including a venue virtual account and multiple virtual user accounts for a stored value account of a user, the instructions cause the at least one processor to:
determine a session has been established by the user at a gaming device associated with the CMS;
receive a transaction request associated with the gaming device, the transaction request identifying a transaction amount;
in response to determining the session has been established and receiving the transaction request, transmit instructions to the immutable CL to cause the immutable CL to record a virtual transfer of funds record equal to the transaction amount from a virtual user account associated with the user to the venue virtual account; and
in response to receiving a first confirmation from the immutable CL that the virtual transfer of funds record is recorded, transmit instructions to a venue system to cause the CMS to initiate a transfer of the transaction amount from the venue gaming account to a credit balance of the gaming device.
Claim 19: At least one non-transitory computer-readable storage media having instructions embodied thereon, wherein when executed by at least one processor in communication with at least one memory device configured to store an immutable central ledger (CL) that is associated with a system account that stores actual funds, the immutable CL including multiple virtual user accounts for a stored value account of a user, wherein each of the multiple virtual accounts is associated with a respective location, the instructions cause the at least one processor to:
receive a transaction request associated with a gaming device, the transaction request identifying (i) a user of the gaming device, (ii) a location of the gaming device, and (iii) a transaction amount;
in response to receiving the transaction request, record within the immutable CL a virtual transfer of funds record equal to the transaction amount from a virtual user account associated with the user to a virtual location account associated with the location of the gaming device;
transmit instructions to cause the gaming device to load the transaction amount from a venue gaming account corresponding to the virtual location account associated with the location to a credit balance of the gaming device; and
cause an actual transfer of funds between the system account and an external account associated with the location based on the virtual transfer of funds record associated with the location.
Further regarding Claim 18, Summers is silent as to a casino management system, determining a session has been established, or receiving a confirmation that the virtual transfer record is recorded. However, Cleveland discloses these missing elements. See explanation and rationale for combining Summers and Cleveland regarding claim 1 above.
Regarding Claim 19, Summers modified by Cleveland further discloses the instructions further cause the at least one processor to: receive, through a message broker, a second confirmation from the CMS that the transaction amount is transferred to the credit balance of the gaming device (fig. 4B: message queue 460 in communication with CMS 420 and at least processor of device 404; par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers);” par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers);” par. 0137: “moving the second funds transfer amount from the external player account and causing a credit balance associated with the second funds transfer amount to be established at the second electronic gaming device;” par. 0169: “meter module 1422 can record the total amount of money wagered on the gaming device, total amount of money deposited, total amount of money withdrawn, total amount of winnings on the EGM. In FIG. 13, meter information is shared between the virtual gaming service 1416 and account management system 1406 using a message broker 1408”); and store the second confirmation in a wallet database (par. 0118: “wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers)… nodes 502 may be in communication with a message queue 512 (e.g., RabbitMQ), an SQL server/database 514;” par. 0124: “CMS 420 has stored a record of the credit/debit message and approved the credit/debit message. Adapters 470 then update 818 the ledger according to CMS complete message and again updates 820 the ledger to indicate a transaction message will be sent to external provider server 416).
Regarding Claim 20, Summers modified by Cleveland further discloses the instructions further cause the at least one processor to store the first confirmation in the wallet database (par. 0124: “CMS 420 has stored a record of the credit/debit message and approved the credit/debit message”).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea(s) without significantly more.
Regarding Claim 1, analyzed as the representative claim:
[Step 1] Claim 1 recites “A computer system…” which falls within the “machine” statutory category of invention under 35 U.S.C. § 101.
[Step 2A – Prong 1] Claim 1 recites “a computer system comprising at least one processor in communication with at least one memory device, with a casino management system (CMS) that is associated with a venue gaming account, and with an immutable CL that is associated with a system account that stores actual funds, the immutable CL including a venue virtual account and multiple virtual user accounts for a stored value account of a user, the at least one processor configured to execute instructions which, when executed by the at least one processor, cause the at least one processor to: determine a session has been established by the user at a gaming device associated with the CMS; receive a transaction request associated with the gaming device, the transaction request identifying a transaction amount; in response to determining the session has been established and receiving the transaction request, transmit instructions to the immutable CL to cause the immutable CL to record a virtual transfer of funds record equal to the transaction amount from a virtual user account associated with the user to the venue virtual account; and in response to receiving a first confirmation from the immutable CL that the virtual transfer of funds record is recorded, transmit instructions to a venue system to cause the CMS to initiate a transfer of the transaction amount from the venue gaming account to a credit balance of the gaming device.” The bolded limitations, under their broadest reasonable interpretation, encompass mental processes (such as the “determining,” “receiv[ing],” and “record[ing]” steps) or methods of organizing human activity, including managing interactions between people and/or fundamental economic practices (e.g., transferring funds between accounts). See MPEP § 2106.04(a)(2). Accordingly, the claim recites an abstract idea(s).
[Step 2A – Prong 2] The judicial exception is not integrated into a practical application. Specifically, the claim recites the additional element of a computer system comprising at least one processor in communication with at least one memory device, wherein the computing device is recited at a high level of generality and merely automate the determining, receiving, and recording steps. Therefore, this additional element amounts to no more than mere instructions to apply the exception using a generic computing device, which does not impose any meaningful limits on practicing the abstract idea(s). Additionally and/or alternatively, the limitations of “transmit[ting]” are drawn to insignificant extra-solution activity (data transmission). See MPEP § 2106.05(g).Thus, the claim is directed to an abstract idea(s).
[Step 2B] The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea(s) into a practical application, the additional element of a computer program executing on a computing device comprising a processor and a memory for performing the method steps amounts to no more than mere instructions to apply the exception using a generic computing device and/or insignificant extra-solution activity, which cannot provide an inventive concept. Accordingly, representative claim 1 is not patent eligible.
Claims 2-12 are dependent on representative claim 1 and include all of the limitations of claim 1. Therefore, the dependent claims recite the same abstract idea(s) as those recited in the independent claim or contain limitations drawn to generic computer components and/or reciting extra solution activities. While the dependent claims may have a narrower scope than the representative claim, no claim contains an additional element to integrate the abstract idea(s) into a practical application or to render an inventive concept that transforms the corresponding claim into a patent eligible application of the otherwise ineligible abstract idea(s). Thereby, claims 2-12 are also patent ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Cleveland and further in view of US 2022/0237985 (hereinafter “Purohit”).
Regarding Claims 1, 13, and 18, Cleveland discloses a computer system comprising at least one processor in communication with at least one memory device (fig. 2: gaming device 200 with processor 204 in communication with memory 208), with a casino management system (CMS) that is associated with a venue gaming account (figs. 1, 2A-2B: casino management system server 114; fig. 4A: venue gaming account 408), and with a CL that is associated with a system account that stores actual funds (par. 0100: “the external provider server 416 that is used to store funds that may be used for wager gaming;” par. 0124: “update 818 the ledger according to CMS complete message;” par. 0088: “the server(s) 284a may be configured to electronically credit or debit the account of a player that is maintained by a financial institution, e.g., an account that is maintained via the financial institution data center 270. The server(s) 284a may, in some examples, be configured to maintain an audit record of such transactions”), the CL including a venue virtual account and multiple virtual user accounts for a stored value account of a user (fig. 4A: user accounts 408, 410; par. 0100: “digital wallet system 400 establishes or otherwise utilizes various funds accounts of the player 402;” par. 0102: “digital wallet app 406 allows the player 402 to establish protected access to and perform privileged transactions with their external player account 410 and one or more casino player accounts 408”), the at least one processor configured to execute instructions which, when executed by the at least one processor (par. 0008: “computing system includes at least one processor in communication with a memory device storing instructions”), cause the at least one processor to:
determine a session has been established by the user at a gaming device associated with the CMS (par. 0102: “player app 412 may allow the player 402 to wirelessly connect with gaming devices 426 at various gaming properties, establish rated gaming sessions (e.g., wirelessly card into gaming devices 426)”);
receive a transaction request associated with the gaming device, the transaction request identifying a transaction amount (par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits);” par. 0009: “the funds transfer request identifying a funds transfer amount and an external player account of the player”);
in response to determining the session has been established and receiving the transaction request, transmit instructions to the CL to cause the CL to record a virtual transfer of funds record equal to the transaction amount from a virtual user account associated with the user to the venue virtual account (par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players begin… play sessions;” par. 0124: “a player at device 404 [during a session] may initiate a transfer funds request that is transmitted 802 to API 452… update 812 a ledger to indicate a transaction message will be sent to CMS 420 and then generates and transmits 814 a credit/debit message (e.g., including the transfer funds request/command) to CMS 420;” par. 0040: “a digital gaming wallet linked to a player's wagering account may… manage gaming related transactions, such as transferring funds to the virtual gaming service”); and
in response to receiving a first confirmation from the CL that the virtual transfer of funds record is recorded, transmit instructions to a venue system to cause the CMS to initiate a transfer of the transaction amount from the venue gaming account to a credit balance of the gaming device (par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players begin… play sessions, performing transactions that, for example, establish a credit balance on a given gaming machine (e.g., to EGM 104);” par. 0124: “CMS 420 then generates and transmits 816 a CMS complete message to adapters 470 indicating that, for example, CMS 420 has stored a record of the credit/debit message and approved the credit/debit message. Adapters 470 then update 818 the ledger according to CMS complete message and again updates 820 the ledger to indicate a transaction message will be sent to external provider server 416. Adapters 470 then generate and transmit 822 an external debit/credit message to server 416. Server 416 then facilitates completion of the requested external transaction and generates and transmits 824 a debit/credit completion message to adapters 470. Adapters 470 then update 826 ledger to indicate receipt of the debit/credit completion message).
Cleveland does not explicitly disclose that the CL is an immutable CL. However, Purohit discloses an immutable CL (par. 0057: “a distributed, immutable ledger (e.g., the blockchain 310);” par. 0019: “Decentralized ledger technology (e.g., blockchain) may be used to provide a distributed ledger amongst participating nodes in a blockchain network (e.g., a peer-to-peer network) that may provide aspects of decentralization, tracking, immutability, security, and transparency for transaction data added to the ledger”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the immutable central ledger of Purohit as the central ledger of Cleveland in order to provide more secure and reliable record-keeping which cannot be altered (Purohit, par. 0019).
Further regarding Claim 13, Cleveland modified by Purohit discloses a method performed by at least one processor in communication with at least one memory device (Cleveland, par. 0206: “a processor (e.g., one or more microprocessors) will receive instructions from a memory or like device, and execute those instructions, thereby performing one or more processes defined by those instructions. Further, programs that implement such methods… may be stored and transmitted using a variety of media”), the method comprising the above steps (see claim 1).
Further regarding Claim 18, Cleveland modified by Purohit discloses at least one non-transitory computer-readable storage media having instructions embodied thereon (Cleveland, par. 0159: “a non-transitory computer-readable medium including instructions stored thereon is described”), the instructions cause the at least one processor to: perform the above steps (see claim 1).
Regarding Claim 2, Cleveland further discloses a message broker in communication with the at least one processor and with the CMS (fig. 4B: message queue 460 in communication with CMS 420 and at least processor of device 404; par. 0113: “the message queue 460 is provided by RabbitMQ, an open source message broker”), wherein the instructions further cause the at least one processor to transmit the instructions to cause the CMS to transfer the transaction amount through the message broker (par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits);” par. 0009: “the funds transfer request identifying a funds transfer amount and an external player account of the player”).
Regarding Claim 3, Cleveland further discloses a wallet database in communication with the at least one processor (par. 0127: “Process 1000 is performed via a plurality of devices, services, providers, etc. such as a gaming device 426, CMS 420, adapters 470, wallet database 610, external provider server 416, and notification service 608;” par. 0135: “The digital wallet computing system includes at least one processor in communication with a memory device storing instructions”), wherein the instructions further cause the at least one processor to:
receive, through the message broker, a second confirmation from the CMS that the transaction amount is transferred to the credit balance of the gaming device (par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers);” par. 0137: “moving the second funds transfer amount from the external player account and causing a credit balance associated with the second funds transfer amount to be established at the second electronic gaming device;” par. 0169: “meter module 1422 can record the total amount of money wagered on the gaming device, total amount of money deposited, total amount of money withdrawn, total amount of winnings on the EGM. In FIG. 13, meter information is shared between the virtual gaming service 1416 and account management system 1406 using a message broker 1408”); and
store the second confirmation in the wallet database (par. 0118: “wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers)… nodes 502 may be in communication with a message queue 512 (e.g., RabbitMQ), an SQL server/database 514;” par. 0124: “CMS 420 has stored a record of the credit/debit message and approved the credit/debit message. Adapters 470 then update 818 the ledger according to CMS complete message and again updates 820 the ledger to indicate a transaction message will be sent to external provider server 416).
Regarding Claim 14, Cleveland further discloses transmitting the instructions to cause the venue wallet system to transfer the transaction amount through a message broker (fig. 4B: message queue 460 in communication with CMS 420 and at least processor of device 404; par. 0113: “the message queue 460 is provided by RabbitMQ, an open source message broker;” par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits);” par. 0009: “the funds transfer request identifying a funds transfer amount and an external player account of the player”).
Regarding Claim 15, Cleveland further discloses receiving, through the message broker, a second confirmation from the venue wallet system that the transaction amount is transferred to the credit balance of the gaming device (par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers);” par. 0137: “moving the second funds transfer amount from the external player account and causing a credit balance associated with the second funds transfer amount to be established at the second electronic gaming device;” par. 0169: “meter module 1422 can record the total amount of money wagered on the gaming device, total amount of money deposited, total amount of money withdrawn, total amount of winnings on the EGM. In FIG. 13, meter information is shared between the virtual gaming service 1416 and account management system 1406 using a message broker 1408”); and
storing the second confirmation in a wallet database (par. 0118: “wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers)… nodes 502 may be in communication with a message queue 512 (e.g., RabbitMQ), an SQL server/database 514;” par. 0124: “CMS 420 has stored a record of the credit/debit message and approved the credit/debit message. Adapters 470 then update 818 the ledger according to CMS complete message and again updates 820 the ledger to indicate a transaction message will be sent to external provider server 416).
Regarding Claim 19, Cleveland further discloses the instructions further cause the at least one processor to:
receive, through a message broker, a second confirmation from the CMS that the transaction amount is transferred to the credit balance of the gaming device (fig. 4B: message queue 460 in communication with CMS 420 and at least processor of device 404; par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers);” par. 0118: “worker nodes 508 are configured to control wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers);” par. 0137: “moving the second funds transfer amount from the external player account and causing a credit balance associated with the second funds transfer amount to be established at the second electronic gaming device;” par. 0169: “meter module 1422 can record the total amount of money wagered on the gaming device, total amount of money deposited, total amount of money withdrawn, total amount of winnings on the EGM. In FIG. 13, meter information is shared between the virtual gaming service 1416 and account management system 1406 using a message broker 1408”); and
store the second confirmation in a wallet database (par. 0118: “wallet transfer messages (e.g., withdrawals, deposits) and wallet transfer state messages (e.g., status of wallet transfers)… nodes 502 may be in communication with a message queue 512 (e.g., RabbitMQ), an SQL server/database 514;” par. 0124: “CMS 420 has stored a record of the credit/debit message and approved the credit/debit message. Adapters 470 then update 818 the ledger according to CMS complete message and again updates 820 the ledger to indicate a transaction message will be sent to external provider server 416).
Regarding Claims 4, 16, and 20, Cleveland further discloses the instructions further cause the at least one processor to store the first confirmation in the wallet database (par. 0124: “CMS 420 has stored a record of the credit/debit message and approved the credit/debit message”).
Regarding Claim 5, Cleveland further discloses the instructions further cause the at least one processor to determine the session has been established by determining a user card associated with the user has been entered at the gaming device (par. 0006: “After a player enters a player tracking card, a player tracking device connected to or embedded within the EGM communicates with the player tracking system to obtain, manage, and/or track player information;” par. 0112: “players 402 establishing carded gaming sessions”).
Regarding Claim 6, Cleveland further discloses the instructions further cause the at least one processor to determine the session has been established by receiving a request to establish the session at the gaming device from a mobile device associated with the user (par. 0102: “player app 412 may allow the player 402 to wirelessly connect with gaming devices 426 at various gaming properties, establish rated gaming sessions (e.g., wirelessly card into gaming devices 426)”).
Regarding Claim 7, Cleveland further discloses the transaction request is received from the gaming device (par. 0127: “funds transfer that may be performed by the digital wallet systems 400, 500, 600 shown in FIGS. 4A-6. In some embodiments, the process 1000 may trigger based on an end of session event (e.g., on an EGM;” fig. 4A: cash-out request originates from gaming device 424).
Regarding Claim 8, Cleveland further discloses the transaction request is received from a mobile device associated with the user (par. 0008: “receive an initiation of a funds transfer request from the mobile device of the player;” par. 0112: “players 402 wirelessly connecting with their mobile devices 404… digital wallet system server 414 may thus recognize, register, and consider eligibility of the various devices 490 for the various funds transfers controlled by the digital wallet system 400”).
Regarding Claim 9, modified Cleveland further discloses the instructions further cause the processor to:
determine the session has ended (Cleveland, par. 0106: “the player 402 may conclude their gaming session in one of many ways… the player 402 may disconnect their mobile device 404 from the local gaming device 424 (e.g., via loss of power, moving the mobile device 404 too far away from the local gaming device 424, initiate a disconnect feature within the player app 412, or the like)”);
receive, from the CMS, a remaining credit balance amount that has been transferred from the gaming device to the venue gaming account (Cleveland, par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players… end play sessions… transfer credit off of the gaming machine at the end of the player's play session (e.g., from EGM 104 on cash out)”); and
in response to determining the session has ended, transmit instructions to the immutable CL to cause the immutable CL (see claim 1 above) to record a second virtual transfer of funds record equal to the remaining credit balance from the venue virtual account to the virtual user account within the immutable CL (Cleveland, par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players… end play sessions… transfer credit off of the gaming machine at the end of the player's play session (e.g., from EGM 104 on cash out);” par. 0136: “processor to determine, in response to the initiation of a funds transfer request, that the player has stopped playing at the electronic gaming device, determine a remaining credit balance including an amount of credits remaining at the electronic gaming device, and cause the remaining credit balance to be deposited as funds into the external player account;” par. 0124: “update 812 a ledger to indicate a transaction message will be sent to CMS 420 and then generates and transmits 814 a credit/debit message (e.g., including the transfer funds request/command) to CMS 420”).
Regarding Claim 10, Cleveland discloses the instructions further cause the processor to determine the session has ended by determining a user card associated with the user has been removed at the gaming device (par. 0024: “the process may trigger based on an end of session event (e.g., on an EGM;” par. 0035: “a carded gaming session;” Examiner notes that a “carded” session would inherently/necessarily end when the card is removed by definition).
Regarding Claim 11, Cleveland further discloses the instructions further cause the processor to determine the session has ended by receiving a request to end the session at the gaming device from a mobile device associated with the user (par. 0106: “the player 402 may conclude their gaming session in one of many ways… the player 402 may disconnect their mobile device 404 from the local gaming device 424 (e.g., via loss of power, moving the mobile device 404 too far away from the local gaming device 424, initiate a disconnect feature within the player app 412, or the like)”).
Regarding Claim 12, Cleveland further discloses the instructions further cause the processor to determine the session has ended by determining a mobile device associated with the user is not detected by a wireless beacon of the gaming device (par. 0106: “the player 402 may conclude their gaming session in one of many ways… moving the mobile device 404 too far away from the local gaming device 424”).
Regarding Claim 17, modified Cleveland further discloses determining the session has ended (par. 0106: “the player 402 may conclude their gaming session in one of many ways… the player 402 may disconnect their mobile device 404 from the local gaming device 424 (e.g., via loss of power, moving the mobile device 404 too far away from the local gaming device 424, initiate a disconnect feature within the player app 412, or the like)”);
receiving, from the venue wallet system, a remaining credit balance amount that has been transferred from the gaming device to the venue gaming account (Cleveland, par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players… end play sessions… transfer credit off of the gaming machine at the end of the player's play session (e.g., from EGM 104 on cash out)”); and
in response to determining the session has ended, transmitting instructions to the immutable CL to cause the immutable CL (see claim 1 above) to record a second virtual transfer of funds record equal to the remaining credit balance from the venue virtual account to the virtual user account within the immutable CL (Cleveland, par. 0119: “the digital wallet system 500 may perform digital wallet transactions on behalf of players when players… end play sessions… transfer credit off of the gaming machine at the end of the player's play session (e.g., from EGM 104 on cash out);” par. 0136: “processor to determine, in response to the initiation of a funds transfer request, that the player has stopped playing at the electronic gaming device, determine a remaining credit balance including an amount of credits remaining at the electronic gaming device, and cause the remaining credit balance to be deposited as funds into the external player account;” par. 0124: “update 812 a ledger to indicate a transaction message will be sent to CMS 420 and then generates and transmits 814 a credit/debit message (e.g., including the transfer funds request/command) to CMS 420”).
Examiner reiterates that claim 17 is being interpreted to depend upon claim 13 instead of claim 10. See rejection under 35 U.S.C. § 112 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 2022/0020242 (Wyllie) teaches a gaming system in which funds are managed based on the proximity of a user’s mobile device to electronic gaming machines.
WO 2023/239946 (McCabe) teaches a gaming system in which transactions are stored on an immutable ledger.
US 2023/0173395 (Cella) teaches a gaming engine smart contract system in which transactions are immutably recorded on a blockchain.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIE DOSHER whose telephone number is (571) 272-4842. The examiner can normally be reached Monday - Friday, 10 a.m. - 6 p.m. ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Dmitry Suhol can be reached at (571) 272-4430. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.G.D./Examiner, Art Unit 3715
/DMITRY SUHOL/Supervisory Patent Examiner, Art Unit 3715
Prosecution Insights