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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 01, 2025, has been entered.
Status of Claims
Applicant filed an amendment on December 01, 2025. Claims 1-28 were pending in the Application. Applicant has withdrawn claims 1-14, 18-20, and 23-28. New claims 29-31 have been added. No new claims have been canceled, with claims 15-17 and 21-22 remaining canceled. Claim 29 is the independent claim, the remaining claims depend on claim 29. Thus claims 29-31 are currently pending. After careful and full consideration of Applicant arguments and amendments, the Examiner finds them to be moot and/or not persuasive.
Response to Arguments
In the context of 35 U.S.C. §101, Applicant does not necessarily agree with this rejection and respectfully traverses the rejection. Applicant is of the opinion that the claims are statutory and submits that “Claims 12 and 28 stand rejected under 35 U.S.C. §101 for allegedly using a computer to implement an abstract idea; the applicant has canceled Claims 12 and 28 and added independent Claim 29, rendering the rejection moot; the new independent Claim 29 is ready for allowance; with the addition of Claim 29, the invention as claimed is directed to technical improvements with technical advantages; the claimed invention is directed to techniques for executing smart contracts to cause transactions related to a machine-readable token to be carried out using electronic ledgers; the interrelatedness of these elements alongside the use of smart contracts in carrying out techniques of the invention meet the criteria for being “significantly more” than an abstract idea; and Claim 29 is eligible under 35 U.S.C. §101 as it is directed to patent-eligible subject matter that improves computer and blockchain technology”.
Initially, the Examiner would like to point out that the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106, which applies a two-step framework, earlier set out in Mayo Collaborative Services v. Prometheus Laboratories, Inc., 566 U.S. 66 (2012), "for distinguishing patents that claim laws of nature, natural phenomena, and abstract ideas from those that claim patent-eligible applications of those concepts." Alice, 573 U.S. at 217.
Under the two-step framework, it must first be determined if "the claims at issue are directed to a patent-ineligible concept." If the claims are determined to be directed to a patent-ineligible concept, e.g., an abstract idea, then the second step of the framework is applied to determine if "the elements of the claim ... contain an "inventive concept" sufficient to 'transform' the claimed abstract idea into a patent-eligible application." (citing Mayo, 566 U.S. at 72-73, 79).
With regard to step one of the Alice framework, we apply a "directed to" two-prong test: 1) evaluate whether the claim recites a judicial exception, and 2) if the claim recites a judicial exception, evaluate whether the claim "applies, relies on, or uses the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception," i.e., whether the claim integrates the judicial exception into a practical application. (MPEP §2106.04 II.A.1. and II.B.2.).
The Specification, (PG Pub US 20230116613 A1, para 3), provides evidence as to what the claimed invention is directed. In this case, the specification, (‘613 A1, para 3), discloses that the invention relates to enabling entities to carry out multiple transactions using tokens, and is grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)”, in prong one of step 2A. (MPEP §2106.04 II.A.1.).
Claim 29 provides additional evidence, and recites the limitations of “receiving an indication authorized by a selling entity to transfer a demand token to a buying entity, wherein the demand token was issued by an admission system in communication with but distinct from the electronic ledger system, wherein the selling entity and the buying entity receive machine-readable signals utilizing one or more separate programmable processors; determining that the demand token has not been converted to an admission token; identifying a first smart contract and a second smart contract referenced by the demand token, wherein the smart contracts govern transactions associated with transfer of the demand token; executing, by the one or more nodes of the electronic ledger system, the first smart contract, wherein executing the first smart contract causes a first transaction to be committed to the electronic ledger, the first transaction causing the demand token to be transferred to the buying entity from the selling entity; in response to successful execution of the first smart contract, executing, by the one or more nodes of the electronic ledger system, the second smart contract, wherein executing the first smart contract causes a second transaction to be committed to the electronic ledger, the second transaction causing a first portion of a first quantity of currency to be transferred to the selling entity and, in response to a determination that the first quantity of currency exceeds a second quantity of currency associated with a prior transfer of the demand token, causes a third transaction to be committed to the electronic ledger, the third transaction causing a second portion of the first quantity of currency to be transferred to another entity; causing the demand token to be converted to an admission token; and providing the admission token to a point of sale system for redemption”, where the italicized claim language represents the abstract idea of “multiple transactions using tokens”, and the bolded claim language represents the additional elements. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “causing transactions associated with a machine-readable token to be committed to an electronic ledger of an electronic ledger system comprising one or more nodes”, “an admission system in communication with but distinct from the electronic ledger system”, “machine-readable signals utilizing one or more separate programmable processors”, “a first smart contract and a second smart contract”, “the smart contracts”, “executing, by the one or more nodes of the electronic ledger system, the first smart contract, wherein executing the first smart contract”, “in response to successful execution of the first smart contract, executing, by the one or more nodes of the electronic ledger system, the second smart contract, wherein executing the first smart contract”, and “a point of sale system”, amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “carrying out multiple transactions using tokens”.
Examiner notes the basis of the rejection was, and is not as any mental process covering performance in the mind, but classified as an abstract idea, “carrying out multiple transactions using tokens”, grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).”
With respect to the additional elements operating in a non-conventional and non-generic way and reflecting an improvement to a particular technological environment, the cited additional elements represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “carrying out multiple transactions using tokens”. The claim is not directed to improving computer functionality nor improving another technology or technical field, but improving the method for “carrying out multiple transactions using tokens”. For potential improvement in an abstract idea “carrying out multiple transactions using tokens”, it is important to keep in mind that an improvement in the abstract idea itself (e.g., a carrying out multiple transactions using tokens concept) is not an improvement in technology. (MPEP § 2106.04(d)(1)). Therefore, claim 29 is non-statutory.
Finally, Examiner notes the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106. And, based on this standard, the claims are non-statutory, and correctly rejected under 35 U.S.C. § 101.
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 29-31 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 29-31 are directed to “a method”. Therefore, these claims are directed to one of the four statutory categories of invention.
Claim 29 recites “carrying out multiple transactions using tokens”, which is a form of commercial or legal interactions (i.e., organizing human activity), and therefore, an abstract idea. Specifically, the claim recites “receiving an indication authorized by a selling entity to transfer a demand token to a buying entity, wherein the demand token was issued by an admission system in communication with but distinct from the electronic ledger system, wherein the selling entity and the buying entity receive machine-readable signals utilizing one or more separate programmable processors; determining that the demand token has not been converted to an admission token; identifying a first smart contract and a second smart contract referenced by the demand token, wherein the smart contracts govern transactions associated with transfer of the demand token; executing, by the one or more nodes of the electronic ledger system, the first smart contract, wherein executing the first smart contract causes a first transaction to be committed to the electronic ledger, the first transaction causing the demand token to be transferred to the buying entity from the selling entity; in response to successful execution of the first smart contract, executing, by the one or more nodes of the electronic ledger system, the second smart contract, wherein executing the first smart contract causes a second transaction to be committed to the electronic ledger, the second transaction causing a first portion of a first quantity of currency to be transferred to the selling entity and, in response to a determination that the first quantity of currency exceeds a second quantity of currency associated with a prior transfer of the demand token, causes a third transaction to be committed to the electronic ledger, the third transaction causing a second portion of the first quantity of currency to be transferred to another entity; causing the demand token to be converted to an admission token; and providing the admission token to a point of sale system for redemption”. The abstract idea is in italics, and the additional elements are in bold. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “causing transactions associated with a machine-readable token to be committed to an electronic ledger of an electronic ledger system comprising one or more nodes”, “an admission system in communication with but distinct from the electronic ledger system”, “machine-readable signals utilizing one or more separate programmable processors”, “a first smart contract and a second smart contract”, “the smart contracts”, “executing, by the one or more nodes of the electronic ledger system, the first smart contract, wherein executing the first smart contract”, “in response to successful execution of the first smart contract, executing, by the one or more nodes of the electronic ledger system, the second smart contract, wherein executing the first smart contract”, and “a point of sale system”, amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “carrying out multiple transactions using tokens”.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of “carrying out multiple transactions using tokens” using computer technology (e.g., “machine-readable signals utilizing one or more separate programmable processors” and “an electronic ledger system”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 29 is non-statutory
Dependent claims 30-31 further describe the abstract idea of “carrying out multiple transactions using tokens”, which is insufficient to overcome the rejection of claim 29, above.
Dependent claims 30-31 do not recite any new additional elements that integrate the abstract idea into a practical application, and that do no more than represent a computer performing functions that correspond to implementing the acts of “carrying out multiple transactions using tokens”, when analyzed under Step 2A, Prong Two. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field, when analyzed under Step 2B.
Hence, claims 29-31 are not patent eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. § 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. § 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 29-31 are rejected under 35 U.S.C. § 112(a) or 35 U.S.C. § 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. § 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
New Matter
Specification, (PG Pub US 20230116613 A1), lacks sufficient details so that one of ordinary skill in the art would understand how “identifying a first smart contract and a second contract referenced by the demand token, …” is performed, and therefore, is an issue of new matter. Claim 29 recites, “identifying a first smart contract and a second contract referenced by the demand token, wherein the smart contracts govern transactions associated with transfer of the demand token”. Specification, (US 20230116613 A1, para 23), recites “… Different types of digital tokens ( e.g., a demand token and an admission token, described below) may be implemented or instantiated to represent certain rights to buy or sell event tickets or admission to an event or venue, and also to control or determine the number of outstanding tickets that are remaining in the hands of resellers …”, which is directed to a demand token and an admission token being implemented or instantiated to represent certain rights to buy or sell event tickets or admission to an event or venue, and to control or determine the number of outstanding tickets that are remaining in the hands of resellers, but is not directed to identifying a first smart contract and a second contract referenced by the demand token, as being claimed.
Specification, (US 20230116613 A1, para 31), recites “… A demand token refers to a token representing the right to demand an asset from another party … a demand token may represent ownership rights and more particularly the right to demand a ticket, ticket token, or admission token from one or more parties or entities participating in a token exchange. An admission token, in contrast, may be a token that represents the right to attend an event. An admission token essentially would be the digital equivalent to a printed ticket. A ticket, as used herein, may refer to either a demand token or an admission token…”, which is directed to a demand token representing the right to demand an asset from another party and ownership rights and the right to demand a ticket, ticket token, or admission token from one or more parties or entities participating in a token exchange, but is not directed to identifying a first smart contract and a second contract referenced by the demand token, as being claimed.
Thus, the specification, (‘613 A1, paras 23 and 31), lacks sufficient details so that one of ordinary skill in the art would understand how “identifying a first smart contract and a second contract referenced by the demand token” is performed. Therefore, this is an issue of new matter, which is matter not present on the filing date of the application in the specification, claims, or drawings that has been added after the application filing. Dependent claims 30-31, which depend from claim 29, are also similarly rejected. (MPEP § 2163.06 I).
Specification, (PG Pub US 20230116613 A1), lacks sufficient details so that one of ordinary skill in the art would understand how “causing the demand token to be converted to an admission token” is performed, and therefore, is an issue of new matter. Claim 29 recites “causing the demand token to be converted to an admission token.” The specification does not adequately inform one of ordinary skill how the limitation “causing the demand token to be converted to an admission token” is to be performed. Specification, (PG Pub US ‘613 A1), is silent and lacks sufficient details so that one of ordinary skill in the art would understand how “causing the demand token to be converted to an admission token” is performed. Thus, specification, (‘613 A1), does not disclose what causing comprises. Therefore, this is an issue of new matter, which is matter not present on the filing date of the application in the specification, claims, or drawings that has been added after the application filing. Dependent claims 30-31, which depend from claim 29 are also similarly rejected. (MPEP § 2163.06 I).
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 29-31 are 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 pre-AIA the applicant regards as the invention.
Antecedent Basis
Claim 29 recites “identifying …, wherein the smart contracts govern transactions …”. There is insufficient antecedent basis for “the smart contracts” in claim 29. Dependent claims 30-31, which depend from claim 29, are also similarly rejected. (MPEP § 2173.05 (e)). The claim is being interpreted as “the first and second smart contracts”.
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 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 set forth in Graham v. John Deere Co., 383 U. S. 1. 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 29-31 are rejected under 35 U.S.C. 103 as being unpatentable over Gonzales, Jr., et al (U. S. Patent No. 11367071 B2), herein referred to as Gonzales, and in further view of Kang et al (U. S. Patent Application Publication No. 20210357893 A1), herein referred to as Kang.
Regarding claim 29, Gonzales discloses a computer-implemented method for causing transactions associated with a machine-readable token to be committed to an electronic ledger of an electronic ledger system comprising one or more nodes, the method comprising:
receiving an indication authorized by a selling entity to transfer a demand token to a buying entity (FIG. 4F, items 460, 462, 464; C/L 19/5-15, “… FIG. 4F is a control flow diagram illustrating still another example of a process 460 for transferring and using a ticket managed on a ticket tracking data blockchain, where an issuer of the ticket creates a token on a blockchain for the ticket … at 462, an issuer creates a token for the ticket on a ticket tracking data blockchain. At 464, the token is sent to a purchaser of the ticket by transferring ownership of the token to the purchaser on the ticket tracking data blockchain, e.g. by adding a ticket tracking data block with the purchaser indicated as the owner or holder …”), wherein the demand token was issued by an admission system (FIG. 1, item 110; C/L 9/1-2, “… FIG. 1, the item information or ticket is provided by item originator or ticket issuer device 110 …”; C/L 9/15-19, “… an item originator device 110 owns and controls the data blocks 142 in item tracking data blockchain 140 and can verify or validate transfers of the item repre-sented by the item tracking data blocks 142B, 142C, 142D and 142E …”) in communication with but distinct from the electronic ledger system (FIG. 1, items 130, 140; C/L 9/2-10, “… and secured on item or ticket tracking data blockchain 140. The information in the data blocks 142 of the blockchain can be made accessible to other entities, such as client/servers 120A, 120B or 120C or blockchain platform 130 … the client/servers 120 can communicate with item originator or ticket issuer device 110 as well as a network of servers for blockchain platform 130 that supports and maintains blockchain 140…”), wherein the selling entity and the buying entity receive machine-readable signals utilizing one or more separate programmable processors (FIG. 1, items 110, 112, 114, 120A-C; FIG. 8, items 806 A-N; FIG. 9, items 900, 902; C/L 28/58-29/15, “… FIG. 9, an illustrative computing device architecture 900 for a computing device that is capable of executing various software components is described herein for an item tracking data blockchain ledger. The computing device architecture 900 is applicable to computing devices that can manage an item tracking data blockchain ledger … the computing devices include, but are not limited to, mobile telephones, on-board computers, tablet devices, slate devices, portable video game devices, traditional desktop computers, portable computers (e.g., laptops, notebooks, ultra-portables, and netbooks), server computers, game consoles, and other computer systems. The computing device architecture 900 is applicable to the item originator or ticket issuer device 110, validation device 112, venue device 114, and client/servers 120A-C shown in FIG. 1 and computing device 806A-N shown in FIG. 8. The computing device architecture 900 illustrated in FIG. 9 includes a processor 902, memory components 904, net-work connectivity components 906, sensor components 908, input/output components 910, and power components 912. In the illustrated configuration, the processor 902 is in communication with the memory components 904, the net-work connectivity components 906, the sensor components 908, the input/output ("I/O") components 910, and the power components 912 …”);
determining that the demand token has not been converted (FIG. 2C, items 260, 262B, 262C, 262D, 262E; C/L 12/65-13/1-12, “… FIG. 2C is a data architecture diagram showing another illustrative example of a ticket tracking data blockchain 260, where the ticket tracking data blocks 262 include block state indicating a current holder or owner of the ticket, e.g. a public key for the current owner entity, along with a current price field, a venue key, e.g. venue_key(KEY), which, in this example, permits a holder of the ticket to enter a venue, and a used indicator. To establish blockchain 260 for ticket, issuer device 110 creates genesis ticket tracking data block 262A, which identifies the ticket that the block represents, such as by the venue_key(KEY) value, indicates the issuer e.g. a public key or other identifier for the issuer entity, as the holder, indicates the current price as the original price of the ticket, e.g. current_price(ORIGINAL), and indicates that the ticket has not been used, e.g. used(FALSE) …”) to an admission token (FIG. 4D, items 114, 436, 438; C/L 18/33-43, “… At 436, a current holder of the ticket presents the ticket at a venue or service provider, e.g. Transferee B using client/server device 120B presents the ticket to venue device 114 in FIG. 3B. At 438, a Use method defined in the ticket tracking data block is invoked, e.g. by the venue device 114, to check that the ticket is not used, e.g. ticket[id].used=FALSE, validate a ticket code and holder as presented against the latest ticket tracking data block 262 in the ticket tracking data blockchain 260, and, if valid, mark the ticket as used in the ticket tracking data block, e.g. ticket[id].used=TRUE …”);
identifying a first smart contract (FIG. 3B, items 242, 320; C/L 14/54-56, “… FIG. 3B is a data architecture diagram showing an illustrative example of item tracking data block 242 that includes the Transfer and Complete scripts …”) and a second smart contract (FIG. 3D, items 262, 350, 352, 354; C/L 15/56-59, “… FIG. 3D is a data architecture diagram showing an illustrative example of ticket tracking data block 262 that includes the Transfer and Use scripts …”) referenced by the demand token, wherein the smart contracts govern transactions associated with transfer of the demand token (FIG. 3A, items 240, 242; C/L 14/41-54, “… FIG. 3A, the provenance of the item can be obtained by tracing the blocks of item tracking data blockchain 240 to the genesis block 242A. The disclosed technology enables the item provenance data to be securely stored and traced on the item tracking data blockchain 240. The blockchain 240 can be made widely accessible for review, such as by potential purchasers or users. The signatures in each of the blocks 242 ensures the authenticity of the provenance data and transfers. Scripts for transfer of an item and completion of a transfer transaction can be secured by the item tracking data blocks 242 of item tracking data blockchain 240 and executed by the operating system of the decentralized, distributed block-chain platform …”);
executing, by the one or more nodes of the electronic ledger system (FIG. 1, item 140; C/L 9/2-3, “… and secured on item or ticket tracking data blockchain 140 …”; C/L 9/15-23, “… an item originator device 110 owns and controls the data blocks 142 in item tracking data blockchain 140 and can verify or validate transfers of the item repre-sented by the item tracking data blocks 142B, 142C, 142D and 142E … a validation device 112, which can represent an authorized entity such as a certified appraiser or authorized seller, distributor or technician, can verify or validate the transfers represented by the item tracking data blocks 142B, 142C, 142D and 142E …”; C/L 9/35-38, “… a venue device 114, which represents a venue or service provider for the ticket, can mark the ticket as used when a holder of the ticket represented by the ticket tracking data blockchain 140 presents the ticket for use … ), the first smart contract, wherein executing the first smart contract causes a first transaction to be committed to the electronic ledger, the first transaction causing the demand token to be transferred to the buying entity from the selling entity (FIG. 3B, items 242, 320; C/L 14/56-67, “… Also shown is a process 320 in a blockchain environment that creates an item tracking data block 242 … block state 322 defined for the item tracking data blocks 242 … the Transfer script is called by a transferee with an identifier for the item, e.g. provenanceID. The Transfer script invokes a function validateProvenance( ) to call a third party verification environment to validate the item for the transaction and set up payment to the transferor … the transferee calls the Complete script to complete the transfer of payment to the transferor …”);
in response to successful execution of the first smart contract, executing, by the one or more nodes of the electronic ledger system, the second smart contract (FIG. 3D, items 262, 350, 352, 354; C/L 15/59-16/16, “… Also shown is a process 350 in a blockchain environment that creates a ticket tracking data block 262. An example of block state 352 defined for the ticket tracking data blocks 262 is also shown … the Transfer script is called by a trans-feree with an identifier for the ticket, e.g. ticketID, an identifier for the seller, e.g. a public key address for the 65 transferor entity, and an identifier for the buyer, e.g. a public key address for the transferee. If the ticket has not been used, e.g. ticketID.used= =FALSE, and the seller identifier matches the ticket holder, e.g. seller==ticket[id].holder, then … the Transfer script invokes a function validateTransfer( ) to validate the venue_key and, if the key is valid, set the buyer as the current holder of the ticket, e.g. ticket[ id] .holder=buyer. The Use script is called by a venue device with the identifier for the ticket, e.g. ticketID, an identifier for the presenter, e.g. a public key address for the entity presenting the ticket, and the venue_key value as presented by the presenter. If the caller is the venue, the presenter is the holder, e.g. presenter==ticket[id].holder, and the presented venue_key matches the ticket venue_key value, e.g. venue_key==ticket[id].venue_key, then the venue device 114 sets the used field for the ticket to TRUE …”), wherein executing the first smart contract causes a second transaction to be committed to the electronic ledger, the second transaction causing a first portion of a first quantity of currency to be transferred to the selling entity and, in response to a determination that the first quantity of currency exceeds a second quantity of currency associated with a prior transfer of the demand token, causes a third transaction to be committed to the electronic ledger, the third transaction causing a second portion of the first quantity of currency to be transferred to another entity (FIG. 4E, items 440, 444, 446, 448, 450; C/L 18/44-61, “… FIG. 4E is a control flow diagram illustrating another example of a process 440 for transferring a ticket on a ticket tracking data blockchain, where a portion of a price increase in the ticket can be transferred to the issuer of the ticket, such as is illustrated in the scenario of FIG. 3E. At 444, if the ticket is not used, a transferee, e.g. TransfereeB in FIG. 3E, invokes a transfer method defined in a ticket tracking data block to transfer the ticket from the transferor who is the current holder, e.g. ticket[id].holder is TransfereeA, to the subsequent holder, e.g. ticket[id].holder is set to TransfereeB, at a transfer price. At 446, if the transfer price is greater than the current_price in the ticket tracking data block, then control branches to 448, where a portion of the price increase can be sent to the issuer of the ticket. Alternatively, a fixed transfer fee may be sent to the issuer when the ticket is transferred. The transfer process can be repeated for subsequent transfers, at 450 …”);
causing the demand token to be converted to an admission token (FIG. 4D, items 114, 436, 438; C/L 18/33-43, “… At 436, a current holder of the ticket presents the ticket at a venue or service provider, e.g. Transferee B using client/server device 120B presents the ticket to venue device 114 in FIG. 3B. At 438, a Use method defined in the ticket tracking data block is invoked, e.g. by the venue device 114, to check that the ticket is not used, e.g. ticket[id].used=FALSE, validate a ticket code and holder as presented against the latest ticket tracking data block 262 in the ticket tracking data blockchain 260, and, if valid, mark the ticket as used in the ticket tracking data block, e.g. ticket[id].used=TRUE …”); and …
Gonzales does not specifically disclose, however, Kang discloses providing the admission token to a point of sale system for redemption (FIG. 1, item 100; para 60, “… FIG. 1 is an exemplary schematic of an event ticket securitization system 100 using a distributed ledger (e.g., blockchain). The system 100 may be referred to as a "platform" throughout the disclosure. The system 100 is a combination of decentralized infrastructure that includes identity verification (e.g., buyer or seller of a live event ticket), and security and/or authentication features to provide integrity to a sale of a live event ticket from end-to-end (e.g., the original point of sale and creation to the final sale to be used for admission to the live event) …”; para 94, “… In implementation of the YHT tokens, rewards may be granted in (but not limited to) the following cases: … “; para 95, “… After redeeming a ticket and therefore attending an event; …”; para 106, “… Based on data collected by the platform, the platform may determine what entities or persons are buying, selling, transferring, and ultimately redeeming a given ticket or tickets. Redeeming may refer to the act of entering a live-ticket event using the non-fungible token (e.g., ticket) …”).
Kang discloses systems and methods for commerce in a distributed system with blockchain protocols and smart contracts. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include systems and methods for commerce in a distributed system with blockchain protocols and smart contracts, as in Kang, to improve and/or enhance the technology for secure tracking and transfer of items using a blockchain, as in Gonzales, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide systems and methods for creating a blockchain-based online ticketing platform that is fully decentralized, that is completely public, and that is entirely transparent to a buyer and/or a seller of live events (e.g., sporting events, concerts, theatrical productions, and other live entertainment events); and that provide the ability to control end-to-end commerce so that revenue on secondary markets can be recaptured and redistributed in a controlled and orderly manner to different participants in the transaction(s).
Regarding claim 30, Gonzales and Kang disclose the limitations of claim 29. Gonzales further specifically discloses the method of claim 29, wherein one or more smart contracts are configured to adjust a quantity of currency associated with prior transfer of a demand token incrementally or in real time responding to increases or decreases in demand for a demand token (FIG. 3F, items 262, 382, 384; C/L 17/3-6, “… FIG. 3F is a data architecture diagram showing an illustrative example of ticket tracking data block 262 that 5 includes the Transfer and Use scripts…”; C/L 17/10-16, “… The example of FIG. 3F is similar to the example of FIG. 3D but with the addition of code in the Transfer script that determines whether the price of the ticket has increased and sends a portion of the increased price to the issuer of the ticket … a fixed retransfer fee can be sent to the ticket issuer for each transfer of the ticket …).
Regarding claim 31, Gonzales and Kang disclose the limitations of claim 29. Gonzales does not specifically disclose, however, Kang discloses the method of claim 29, wherein a percentage of a difference between the second quantity of currency and a third quantity of currency is transferred to the selling entity (FIG. 1, items 100, 104, 110; para 77, “… The rules defined by the ticket "minter" for each ticket are encoded as "smart contracts" 104 and deployed onto the blockchain 110. The "Rules" may include but are not limited to the following: …”; para 80, “… % of ticket markup to by split with the seller; …).
Kang discloses systems and methods for commerce in a distributed system with blockchain protocols and smart contracts. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include systems and methods for commerce in a distributed system with blockchain protocols and smart contracts, as in Kang, to improve and/or enhance the technology for secure tracking and transfer of items using a blockchain, as in Gonzales, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide systems and methods for creating a blockchain-based online ticketing platform that is fully decentralized, that is completely public, and that is entirely transparent to a buyer and/or a seller of live events (e.g., sporting events, concerts, theatrical productions, and other live entertainment events); and that provide the ability to control end-to-end commerce so that revenue on secondary markets can be recaptured and redistributed in a controlled and orderly manner to different participants in the transaction(s).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Joseph et al (U. S. Patent Application Publication No. 20230281591 A1) – Blockchain Based Tax Mechanism
Joseph recites a computer implemented method of facilitating a consumption tax on a purchase of one or more goods and/or services by a buyer from a seller, wherein at least the buyer is a buyer-seller who makes an onward sale based on said goods and/or services. The method comprises, by the seller of the purchase, obtaining a first blockchain transaction that can be redeemed by a second blockchain transaction meeting either of two alternative conditions: a first condition requiring at least that the second blockchain transaction is signed with a cryptographic signature of the buyer, and a second condition requiring at least that the second blockchain transaction is signed with at least a cryptographic signature of a tax authority; and in response to receiving a payment of the consumption tax from the buyer, sending the first blockchain transaction to be recorded on a blockchain.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN CHISM whose telephone number is (571) 272-5915. The examiner can normally be reached during 9:00 AM – 3:00 PM Monday – Thursday, EST.
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, Ryan D. Donlon can be reached (571) 270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN CHISM/
Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 August 7, 2026
Prosecution Insights