DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013 is being examined under the AIA first inventor to file provisions.
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 12/23/2025 has been entered.
Status of Claims
The following is a Non-Final Office Action in response to Applicant’s amendments filed on 12/23/2025.
a. Claims 1, 11, 20 are amended
b. Claims 2, 4, 12, 14 were previously cancelled.
Overall, Claims 1, 3, 5-11, 13, 15-20 are pending and have been considered below.
Priority
The application claims priority to provisional application 63/365,898, filed on 06/06/2022. The priority is acknowledged.
Information Disclosure Statement (IDS)
The information disclosure statement (IDS) submitted on 12/24/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, such IDS is being considered by Examiner.
Claim Objections
Claims 1, 11, 20 objected to because of the following informalities: Claim 1 recites the limitation “… a relational database storing…”, claim 1 further recites “a voucher creator account in the database system”. One of skill in the art cannot determine if the voucher creator account in the relational database or in a different database. Additionally, claim 1 further recites “(2) and (2) sign the transaction voucher with voucher private key”, claim 1 further recites “a communication interface operable to transmit the transaction voucher… perform the blockchain action after validating the transaction voucher … decrypting the transaction voucher” One of skill in the art cannot determine if the actions of transmitting, validating, and decrypting are on the signed transaction voucher or a different transaction voucher. Claims 11, and 20 recites similar limitation to claim 1 with similar informalities. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 USC 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, 3, 5-11, 13, 15-20 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more.
Per Step 1 of the multi-step eligibility analysis, claims 1, 3, 5-10 are directed to a system, claims 11, 13, 15-19 are directed to computer implemented method, and claim 20 is directed to a computer executable instructions stored on a non-transitory storage medium.
Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention.
Per Step 2A.1. The limitations of independent claim 1 (which is representative of Claims 11, 20) shown in bold recite an abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below.
[A] A computing system comprising:
[B] a relational database storing customer relations management information for a plurality of tenants, the customer relations management information including a plurality of transaction records that reflect tokens minted on a blockchain and transferred to customers of the plurality of tenants;
[C] a blockchain interface operable to deploy to the blockchain a smart contract owned by an owner account associated with a designated tenant of the plurality of tenants, the smart contract being linked to a voucher creator account in the database system assigned to a voucher creator role, the voucher creator role being linked to a voucher public key stored on the blockchain in association with the smart contract and a voucher private key stored in the relational database, the owner account accessing the smart contract via an ownership public key and an ownership private key that are different from the voucher public key and the voucher private key, the voucher private key being inaccessible to the voucher creator account. and the voucher public key and the voucher private key being configured to authorize blockchain operations separately from the ownership public key and the ownership private key;
[D] one or more hardware processors operable to: (1) create a transaction voucher upon request by the voucher creator account, the transaction voucher including a wallet identifier and authorizing a voucher recipient account to execute the smart contract to perform a blockchain action, and (2) sign the transaction voucher with the voucher private key; and
[E] a communication interface operable to transmit the transaction voucher to a client device, the smart contract being configured to include an executable function operable to perform the blockchain action after validating the transaction voucher by decrypting the transaction voucher with the voucher public key and by confirming that the wallet identifier matches an identifier identifying the voucher recipient account such that the blockchain action is performed responsive to the validating of the transaction voucher, and such that a minting operation is performed to a wallet identified by the transaction voucher and separately from a wallet identified by the owner account.
Claim 1 (which is representative of claims 11, 20) recites: a database for storing ([A]-[B]); interface to deploy contract ([C]); create accounts and sign transaction ([D]); and, transmitting transaction voucher ([E]), which, based on the claim language and in view of the application disclosure, represents a process aimed at managing authorization of transactions using vouchers.
This overall combination, covers business relationship, because the claim recites decrypting transactions voucher, identifying recipient, and validating the transaction voucher. Such limitation covers falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is reasonable to conclude that claim 1 (which is representative of claims 11, 20) recites an abstract idea that corresponds to a judicial exception.
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). For example, the added elements “blockchain,” “smart,” “one or more hardware processors,” “a communication” and “minting” recite computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The additional elements do not preclude from carrying out the identified abstract idea of managing authorization of transactions using vouchers. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application.
The additional elements in the independent claims, shown not bolded above, recite: blockchain ([B]-[E]), smart ([C]-[E]), one or more hardware ([D]), a communication ([E]), and minting ([E]). When considered individually, they amount to nothing more than reception, transmission and/or general computation (i.e., not specific enough computation) of claim elements that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea.
Therefore, the additional steps of claim 1 (which is representative of claims 11, 20) do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Claim 1 (which is representative of claims 11, 20) does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Therefore, when considered as a whole and as an ordered combination, the additional elements in the claim amount to instructions to apply the abstract idea on a computer. Moreover, as noted above, there is nothing the computing and additional elements (limitations [B]-[E]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea of managing authorization of transactions using vouchers could have been reasonably performed when provided with the relevant data and/or information. Therefore, it is concluded that independent claims 1, 11, 20 are deemed ineligible.
Dependent Claims: Claims 3, 5-10, 13, 15-19 are analyzed for subject matter eligibility. However, these claims fails to recite patent eligible subject matter for following reasons:
Claim 3 (which is representative of claim 13), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] wherein the voucher creator account is one of a plurality of accounts having been assigned a voucher role for the smart contract, two or more of the plurality of accounts being associated with a respective voucher public key stored on the blockchain and a respective voucher private key stored in the relational database.
The claim further recites the abstract idea of managing authorization of transactions using vouchers. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 5 (which is representative of claim 15), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] wherein the action comprises minting a token to a wallet owned by the voucher recipient account.
The claim further recites the abstract idea of managing authorization of transactions using vouchers. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 6 (which is representative of claim 16), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] wherein the smart contract is uniquely identified by a smart contract identifier stored on the blockchain, and
[B] wherein validating the transaction voucher comprises confirming that the smart contract identifier matches a value included in the transaction voucher.
The claim further recites the abstract idea of managing authorization of transactions using vouchers. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 7 (which is representative of claim 17), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] wherein the transaction voucher includes a transaction identifier that uniquely identifies the transaction voucher, and
[B] wherein performing the action comprises invalidating the transaction voucher by recording a transaction on the blockchain.
The claim further recites the abstract idea of managing authorization of transactions using vouchers. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 8 (which is representative of claim 18), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] wherein the transaction voucher includes a transaction amount, and
[B] wherein validating the transaction voucher involves confirming that the transaction amount matches a request amount included with the voucher.
The claim further recites the abstract idea of managing authorization of transactions using vouchers. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 9 (which is representative of claim 19), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] wherein the transaction voucher includes a wallet identifier, and
[B] wherein validating the transaction voucher involves confirming that the wallet identifier matches an identifier identifying the voucher recipient account.
The claim further recites the abstract idea of managing authorization of transactions using vouchers. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 10, recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] wherein the smart contract includes an invalidation function operable to invalidate the transaction voucher upon receiving an invalidation request signed by the voucher private key.
The claim further recites the abstract idea of managing authorization of transactions using vouchers. In other words, it recites limitation grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense, i.e., a computer receives information from another computer, processes that information and then sends a response based on processing results. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the computing devices are facilitating the abstract concept is not enough to confer subject matter eligibility. Overall, the further elements do not confer subject matter eligibility to the invention since their individual and combined significance are not changing the nature of the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly
more. (See MPEP 2106.05).
In sum, Claims 1, 3, 5-11, 13, 15-20 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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 non-obviousness.
Claims 1, 3, 5-6, 11, 13, 15-16, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lupowitz (US 11379429 B1), in view of Moreno (US 20210090108 A1), in further view of Bishnoi (US 20190012695 A1), in further view of Bodenmiller (US 20240346482 A1).
Regarding Claims 1, 11, 20. Lupowitz discloses:
a relational database storing customer relations management information for a plurality of tenants, the customer relations management information including a plurality of transaction records that reflect tokens minted on a blockchain and transferred to customers of the plurality of tenants; [see at least (6/36-39) In some embodiments, the asset database 140 may track one or more state(s) of one or more asset(s) represented by token(s) of the blockchain150. (7/11-18) hybrid blockchain environment 100 may include storage such as … distributed database. (11/11-18) sending assets and/or tokens to a destination, such as to another user (i.e., customer) and/or to an omnibus account for conversion to an asset, may include the tasks of depositing assets to mint tokens for the first user, sending the tokens to the destination, and the redeeming the tokens in exchange for the assets at the destination (i.e., token can be minted, and transferred to another user). (25/44-47) databases 707 and 715 may be any type of database, including a database managed by a database management system (DBMS). (25/60-65) DBMS … may include a … relational model (i.e., relational database)]
one or more hardware processors operable to: (1) create a transaction voucher upon request by the voucher creator account, the transaction voucher including a wallet identifier and authorizing a voucher recipient account to execute the smart contract to perform a blockchain action, and […] [(13/61-67) based on the operation type, the operation initiation instruction 105 may cause the blockchain 150 to initiate a smart contract 151 for performing the operation (i.e., executing the smart contract to perform the action). In some embodiments, the operation type may include, e.g., a token redeem, a token deposit, a token transfer, among other operation types or any combination thereof]
The Lupowitz discloses executing smart contract, however, Lupowitz does not disclose:
a blockchain interface operable to deploy to the blockchain a smart contract owned by an owner account associated with a designated tenant of the plurality of tenants, the smart contract being linked to a voucher creator account in the database system assigned to a voucher creator role, the voucher creator role being linked to a voucher public key stored on the blockchain in association with the smart contract and a voucher private key stored in the relational database, the owner account accessing the smart contract via an ownership public key and an ownership private key that are different from the voucher public key and the voucher private key, the voucher private key being inaccessible to the voucher creator account, and the voucher public key and the voucher private key being configured to authorize blockchain operations separately from the ownership public key and the ownership private key;
[…] (2) sign the transaction voucher with the voucher private key; and […]
a communication interface operable to transmit the transaction voucher to a client device, the smart contract being configured to include an executable function operable to perform the blockchain action after validating the transaction voucher by decrypting the transaction voucher with the voucher public key and by confirming that the wallet identifier matches an identifier identifying the voucher recipient account such that the blockchain action is performed responsive to the validating of the transaction voucher, and such that a minting operation is performed to a wallet identified by the transaction voucher and separately from a wallet identified by the owner account.
Nonetheless, Moreno discloses processing transaction(s):
a blockchain interface operable to deploy to the blockchain a smart contract owned by an owner account associated with a designated tenant of the plurality of tenants, the smart contract being linked to a voucher creator account in the database system assigned to a voucher creator role, the voucher creator role being linked to a voucher public key stored on the blockchain in association with the smart contract and […] [(0020) creating a smart contract template by the issuer server (i.e., voucher creator) from the at least one attestation threshold, the voucher, the identifier of the voucher holder application (i.e., tenant) and the attestation application, and registering the public key of the issuer server application in the smart contract system (i.e., voucher creator being linked with public key) and signing the smart contract template with the private key of the issuer server application]
[…] the smart contract being configured to include an executable function operable to perform the blockchain action after validating […] [see at least (0131) the voucher collector application receives the redemption request, it checks the digital signature of the voucher holder application using the public key of the voucher holder application. (0132) If the digital signature is not valid, the voucher collector application ignores the redemption request. (i.e., transaction voucher is validated by using checking the digital signature using the public key)]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz to include the features of Moreno. A person a having the ordinary skill in the art would have been motivated to combine the process of validating transaction by checking digital signature in Moreno with the smart contract of Lupowitz to securely process transaction with the user. Lupowitz discloses executing smart contract to perform various blockchain action. Moreno teaches processing transaction related to the user. Moreover, since the features disclosed by Lupowitz as well as Moreno would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lupowitz/Moreno.
The combination of Lupowitz in view of Moreno discloses processing transaction using smart contract and checking the user’s digital signature. However, the above combination of Lupowitz, Moreno does not disclose:
[…] a voucher private key stored in the relational database, the owner account accessing the smart contract via an ownership public key and an ownership private key that are different from the voucher public key and the voucher private key, the voucher private key being inaccessible to the voucher creator account, and the voucher public key and the voucher private key being configured to authorize blockchain operations separately from the ownership public key and the ownership private key;
[…] (2) sign the transaction voucher with the voucher private key; and
a communication interface operable to transmit the transaction voucher to a client device […] the transaction voucher by decrypting the transaction voucher with the voucher public key and by confirming that the wallet identifier matches an identifier identifying the voucher recipient account such that the blockchain action is performed responsive to the validating of the transaction voucher, and such that a minting operation is performed to a wallet identified by the transaction voucher and separately from a wallet identified by the owner account.
However, Bishnoi discloses signing transaction:
[…] a voucher private key stored in the relational database, […] [see at least (0031) the electronic voucher may be encrypted via the application program, where only other instances of the application program (e.g., on the recipient device 112 and authorized point of sale devices 102) may possess encryption keys suitable for decryption of the encrypted voucher. (0043) The memory 206 may include, for example, encryption keys (i.e., private key) and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and application programs of the processing device, and other data that may be suitable for use by the point of sale device 102 in the performance of the functions disclosed herein as will be apparent to persons having skill in the relevant art. In some embodiments, the memory 206 may be comprised of or may otherwise include a relational database that utilizes structured query language for the storage, identification, modifying, updating, accessing, etc. of structured data sets stored therein. (i.e., the relational database utilized for identification or for accessing, and the encryption keys is suitable for decryption which reads on accessing. Thus, one of skilled in the art based on disclosed section the Bishnoi reference, can conclude, the relational database of Bishnoi stores the encryption key)]
[…](2) sign the transaction voucher with the voucher private key; and [(0037) The private key may then be included in the electronic voucher, or used to generate unique data for inclusion in the electronic voucher, such as a digital signature generated using the private key via one or more signature generation algorithms.]
a communication interface operable to transmit the transaction voucher to a client device […] the transaction voucher by decrypting the transaction voucher with the voucher public key and by confirming that the wallet identifier matches an identifier identifying the voucher recipient account […] [see at least (0026) The sender 104 may possess a sender device 110, which may be used to purchase the electronic voucher, which may be subsequently delivered to a recipient device 112 (i.e., client device), possessed by the recipient 106. (i.e., voucher is sent to a recipient device 112). (0031) the recipient device 112 and authorized point of sale devices 102) may possess encryption keys (i.e., public or private keys) suitable for decryption of the encrypted voucher (i.e., transaction voucher is decrypted by the encryption keys). (0033) point of sale device 102 may identify the redemption amount, merchant identifier(s), and expiration date corresponding to the voucher identification number stored in the blockchain to confirm that the electronic voucher is valid for redemption (i.e., POS device 102 checks if the identifiers matches before performing operation)]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz, in view of Moreno to include the features of Bishnoi. A person a having the ordinary skill in the art would have been motivated to combine the process of signing transaction in Bishnoi with the process of validating transaction and checking the digital signature in Lupowitz, in view of Moreno to securely process transaction with the user. Lupowitz, in view of Moreno discloses executing smart contract to perform various blockchain action. Bishnoi teaches signing transaction related to the user. Moreover, since the features disclosed by Lupowitz, in view of Moreno as well as Bishnoi would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lupowitz, Moreno/Bishnoi.
The combination of Lupowitz in view of Moreno discloses processing transaction using smart contract and checking the user’s digital signature. However, the above combination of Lupowitz, Moreno does not disclose:
[…] the owner account accessing the smart contract via an ownership public key and an ownership private key that are different from the voucher public key and the voucher private key, the voucher private key being inaccessible to the voucher creator account, and the voucher public key and the voucher private key being configured to authorize blockchain operations separately from the ownership public key and the ownership private key;
[…]such that the blockchain action is performed responsive to the validating of the transaction voucher, and such that a minting operation is performed to a wallet identified by the transaction voucher and separately from a wallet identified by the owner account.
Nonetheless, Bodenmiller discloses minting operation:
[…] the owner account accessing the smart contract via an ownership public key and an ownership private key that are different from the voucher public key and the voucher private key, the voucher private key being inaccessible to the voucher creator account, and the voucher public key and the voucher private key being configured to authorize blockchain operations separately from the ownership public key and the ownership private key; [see at least (0012) provide services based on the level of authentication and ownership. (0015) verifying, by the system, an association of the token ID with the contract and/or wallet address; and upon verification, presenting, by the system, a first screen on the user device. (0016) unlockable section comprising the copy of UUID and the private key. The method further comprises receiving, the copy of UUID and the private key from the user device; receiving, the encrypted UUID read by the user device from the physical tag; decrypting the encrypted UUID using the private key; matching the copy of the UUID and the decrypted UUID; and upon a match, presenting a second screen on the user device. The method further comprises checking the presence of the token ID in any of one or more wallets; and upon presence, presenting a second screen on the user device. The first screen is configured to provide access to a set of first services, the second screen is configured to provide access to a second set of services, the second set of services is different from the first set of services. (0034) The services provided on the first screen are based on the first level of authentication (i.e., whether the owner or the transaction voucher’s cryptographic keys was used for the initial authentication). The said services can be accessed by the users in possession of the article, but the users may not be the owners of the article.]
Note: The Bodenmiller reference in the provided paragraph discloses presenting screen to the user based on the UUID and private, and based on the decrypting and matching, the user is able to get access to certain services. Thus, based on the discloses section of the Bodenmiller reference one of skill in the art can conclude based on the key, an user (i.e., owner or the transaction voucher) will have access to certain services (i.e., blockchain operation). Furthermore, based on this conclusion, the Bodenmiller reference discloses different keys (i.e., owner’s key or the transaction voucher key) will have access to different services.
[…] such that the blockchain action is performed responsive to the validating of the transaction voucher, and such that a minting operation is performed to a wallet identified by the transaction voucher and separately from a wallet identified by the owner account. [(0041) the NFT can be minted by creating a unique contract, in which case, the NFTs may be minted into a wallet owned by the creator, or they may be minted directly into a recipient's wallet (i.e., transaction voucher, and the minting process can be performing directly into the wallet identified by the transaction voucher). In this case, the contract address from which the NFTs originate is tied to creator, but the initial wallet address may or may not be tied to the creator.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz, in view of Moreno, in further view of Bishnoi to include the features of Bodenmiller. A person a having the ordinary skill in the art would have been motivated to combine the process of the minting operation performed directly into a specified wallet in Bodenmiller using the transaction validation operation of Lupowitz, in view of Moreno, in further view of Bishnoi to securely process transaction with the user. Lupowitz, in view of Moreno, in further view of Bishnoi discloses executing smart contract to perform various blockchain action. Bodenmiller teaches minting operation being performed in the specified wallet. Moreover, since the features disclosed by Lupowitz, in view of Moreno, in further view of Bishnoi as well as Bodenmiller would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lupowitz, Moreno, Bishnoi/Bodenmiller.
Regarding Claims 3, 13. Lupowitz, Moreno, Bishnoi, Bodenmiller discloses the limitations of Claims 1, 11. Moreno further discloses:
wherein the voucher creator account is one of a plurality of accounts having been assigned a voucher role for the smart contract, two or more of the plurality of accounts being associated with a respective voucher public key stored on the blockchain and [see at least (0020) registering the public key of the issuer server (i.e., voucher creator) application in the smart contract system. (0040) The electronic voucher system comprises a plurality of applications … the electronic voucher system respectively may comprise a voucher holder … an issuer server, voucher collector and a smart contract system. (0041) the smart contract identifier allows the voucher holder application and user to have a plurality of smart contracts wherein a plurality of vouchers can be obtained (0076) the smart contract system, or SCS, is a blockchain system. (i.e., the issuer server is the voucher creator and the public key is stored in the smart contract system which is the blockchain system.)]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to include the additional features of Moreno. A person a having the ordinary skill in the art would have been motivated to combine the process validating transaction by checking digital signature in Moreno using the transaction validation operation of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to securely process transaction with the user. Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses executing smart contract to perform various blockchain action. Moreno further teaches processing transaction related to the user. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Bishnoi further discloses:
a respective voucher private key stored in the relational database. [(0040) the point of sale device 102 may include a receiving device 202. (0041)The receiving device 202 may be configured to receive data signals electronically transmitted by recipient devices 112, which may be encoded with electronic vouchers, and a voucher identification number, and may also include additional data, such as a private key. (0043) The memory 206 may be configured to store data for use by the point of sale device 102, such as public and private keys, symmetric keys … the memory 206 may be comprised of or may otherwise include a relational database. (i.e., the receiving device 202 receive data about the electronic voucher and its private key. The receiving device 202 is a part the point of sales device 102.)]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to include the additional features of Bishnoi. A person a having the ordinary skill in the art would have been motivated to combine the process of signing transaction in Bishnoi with the process of validating transaction and checking the digital signature in Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to securely process transaction with the user. Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses executing smart contract to perform various blockchain action. Bishnoi further teaches signing transaction related to the user. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 5, 15. Lupowitz, Moreno, Bishnoi, Bodenmiller discloses the limitations of Claims 1, 11. Lupowitz further discloses:
wherein the action comprises minting a token to a wallet owned by the voucher recipient account. [(5/8-11) a token deposit operation may cause a smart contract 151 for minting tokens ( e.g., producing new tokens on the blockchain), and thus adding the tokens from the token storage of the user. (i.e., the token storage is the wallet owned by the user.)]
Regarding Claims 6, 16. Lupowitz, Moreno, Bishnoi discloses the limitations of Claims 1, 11. Moreno further discloses:
wherein the smart contract is uniquely identified by a smart contract identifier stored on the blockchain, and wherein validating the transaction voucher comprises confirming that the smart contract identifier matches a value included in the transaction voucher. [see at least (0068) As the redemption request is signed with the private key of the voucher holder application, the voucher collector application can check the authenticity of the redemption request with the public key of the voucher holder application. (0069) the smart contract identifier is comprised in the redemption request, the voucher collector application can check in the smart contract system which voucher and smart contract are trying to be redeemed … the voucher collector application may also check the state of the smart contract and its attributes.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to include the additional features of Moreno. A person a having the ordinary skill in the art would have been motivated to combine the process validating transaction by checking digital signature in Moreno using the transaction validation operation of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to securely process transaction with the user. Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses executing smart contract to perform various blockchain action. Moreno further teaches processing transaction related to the user. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claims 7-8, 10, 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Lupowitz in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller, as applied to claims [1, 11] above, in further view of Al Suwailem (US 20230385819 A1).
Regarding Claims 7, 17. Lupowitz, Moreno, Bishnoi, Bodenmiller discloses the limitations of Claims 1, 11. The combination of Lupowitz in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses processing transaction using smart contract and checking the user’s digital signature. However, the above combination of Lupowitz, Moreno, Bishnoi, Bodenmiller does not disclose:
wherein the transaction voucher includes a transaction identifier that uniquely identifies the transaction voucher, and wherein performing the action comprises invalidating the transaction voucher by recording a transaction on the blockchain.
Nonetheless, Al Suwailem discloses:
wherein the transaction voucher includes a transaction identifier that uniquely identifies the transaction voucher, and wherein performing the action comprises invalidating the transaction voucher by recording a transaction on the blockchain. [ (0006) recording in a blockchain network, with a user computing device of a user with at least one blockchain based voucher, (i.e., transaction voucher is recorded on a blockchain network.) a purchase request that identifies a proposed purchase with an authorized provider … the voucher to be usable only in transactions between the user and any of a set of one or more authorized providers of goods or services including both goods and services, and in some embodiments the voucher has a predefined, finite period of validity—after which the voucher becomes invalid or is invalidated (i.e., voucher is invalid after a finite period of time.)]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to include the features of Al Suwailem. A person a having the ordinary skill in the art would have been motivated to combine the process of validating vouchers for limited time in Al Suwailem using the transaction validation operation of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to securely process transaction by making sure the user is using valid transaction voucher. Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses executing smart contract to perform various blockchain action. Al Suwailem teaches transaction voucher having limited time. Moreover, since the features disclosed by Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller as well as Al Suwailem would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lupowitz, Moreno, Bishnoi, Bodenmiller/Al Suwailem.
Regarding Claims 8, 18. Lupowitz, Moreno, Bishnoi, Bodenmiller discloses the limitations of Claims 1, 11. The combination of Lupowitz in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses processing transaction using smart contract and checking the user’s digital signature. However, the above combination of Lupowitz, Moreno, Bishnoi, Bodenmiller does not disclose:
wherein the transaction voucher includes a transaction amount, and wherein validating the transaction voucher involves confirming that the transaction amount matches a request amount included with the voucher.
Nonetheless Al Suwailem discloses:
wherein the transaction voucher includes a transaction amount, and wherein validating the transaction voucher involves confirming that the transaction amount matches a request amount included with the voucher. [see at least (0007) validating, by the blockchain network, eligibility of the purchase request, based on the set of rules binding the voucher. (0008) unbinding the set of rules from the purchase amount of the voucher (i.e., transaction amount) (that is, the purchase price to be paid using the voucher, which may be less than or equal to the value of the at least one voucher) when the proposed purchase is completed (i.e., transaction is validated if the transaction amount is less than or equal to the voucher amount.)}
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to include the features of Al Suwailem. A person a having the ordinary skill in the art would have been motivated to combine the process of validating vouchers for limited time in Al Suwailem using the transaction validation operation of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to securely process transaction by making sure the user is using valid transaction voucher. Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses executing smart contract to perform various blockchain action. Al Suwailem teaches transaction voucher having limited time. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 10. Lupowitz, Moreno, Bishnoi, Bodenmiller discloses the limitations of Claim 1. The combination of Lupowitz in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses processing transaction using smart contract and checking the user’s digital signature. However, the above combination of Lupowitz, Moreno, Bishnoi, Bodenmiller does not disclose:
wherein the smart contract includes an invalidation function operable to invalidate the transaction voucher upon receiving an invalidation request signed by the voucher private key.
Nonetheless, Al Suwailem discloses:
wherein the smart contract includes an invalidation function operable to invalidate the transaction voucher upon receiving an invalidation request signed by the voucher private key. [see at least (0006) the voucher has a predefined, finite period of validity—after which the voucher becomes invalid or is invalidated. (0007) validating, by the blockchain network, eligibility of the purchase request, based on the set of rules binding the voucher; (i.e., voucher is validated by the blockchain network, and valid for a finite period.)]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to include the features of Al Suwailem. A person a having the ordinary skill in the art would have been motivated to combine the process of validating vouchers for limited time in Al Suwailem using the transaction validation operation of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to securely process transaction by making sure the user is using valid transaction voucher. Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses executing smart contract to perform various blockchain action. Al Suwailem teaches transaction voucher having limited time. Moreover, since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claims 9, 19 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Lupowitz in view of Moreno, in further view of Bishnoi, in further view Bodenmiller, as applied to claims [1, 11] above, in further view of Law (US 20070125838 A1).
Regarding Claims 9, 19. Lupowitz, Moreno, Bishnoi, Bodenmiller discloses the limitations of Claims 1, 11. The combination of Lupowitz in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses processing transaction using smart contract and checking the user’s digital signature. However, the above combination of Lupowitz, Moreno, Bishnoi, Bodenmiller does not disclose:
wherein the transaction voucher includes a wallet identifier, and wherein validating the transaction voucher involves confirming that the wallet identifier matches an identifier identifying the voucher recipient account.
Nonetheless, Law discloses:
wherein the transaction voucher includes a wallet identifier, and wherein validating the transaction voucher involves confirming that the wallet identifier matches an identifier identifying the voucher recipient account. [(0037) the wallet management center validates the recipient wallet ID by matching the decrypted recipient wallet ID in the payment instruction with the given recipient wallet ID in the caller identification of the incoming message from the recipient (i.e., matching the wallet identifiers.). When successfully matched, the wallet management center will advise the recipient that the payment instruction is authentic, i.e., it is originated from the specific sender and received by the specific intended recipient. As described, this process creates a basis for transaction non-repudiation. (i.e., confirming that the wallet identifiers matches.)]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to include the features of Law. A person a having the ordinary skill in the art would have been motivated to combine the process of validating recipient’s wallet using the recipient’s wallet ID with the validation operation of Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller to securely process transaction. Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller discloses executing smart contract to perform various blockchain action. Law teaches validating recipient’s wallet ID by the decrypted recipient wallet ID. Moreover, since the features disclosed by Lupowitz, in view of Moreno, in further view of Bishnoi, in further view of Bodenmiller as well as Law would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Lupowitz, Moreno, Bishnoi, Bodenmiller/Law.
Response to Amendments/Arguments
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits: “Applicant submits that the claims are not directed to an abstract idea, are not directed to methods of organizing human activity, and instead recite concrete, technical solutions for securely authorizing and executing public trust ledger actions that cannot be performed in the human mind. Even if the claims were found to recite an abstract idea, they nevertheless integrate any such idea into a practical application and therefore recite patent-eligible subject matter. By way of example, independent claim 1 recites a computing system that includes a relational database storing CRM transaction records reflecting tokens minted on a blockchain, a blockchain interface operable to deploy a smart contract linked to a voucher creator role and cryptographic key pairs, one or more hardware processors operable to create a transaction voucher signed with a voucher private key, and a smart contract executable function that validates the transaction voucher by decrypting the voucher with a voucher public key before performing an action such as minting a token. The Office Action asserts that the claimed features are allegedly directed to methods of organizing human activity, such as authorizing transactions or managing relationships. Applicant respectfully disagrees. Applicant submits that the claims are not directed to organizing people, contracts, or economic relationships. Instead, the claims are directed to technical mechanisms for controlling execution of smart contracts on a blockchain using cryptographically verifiable vouchers generated by a database system. As described in Applicant's Specification, the claimed features address technical problems unique to distributed ledger systems, including: eliminating the need for on-chain allow-lists or external oracles; reducing security risks associated with custodial wallets; enabling lazy minting through voucher-based authorization; and securely bridging enterprise database systems with public trust ledgers in a scalable manner. These are not methods of organizing human activity, but rather improvements to the technical functioning of blockchain-based systems and database-ledger interoperability. The claims do not merely recite business rules or human workflows implemented on a computer; they recite specific technical architectures and cryptographic mechanisms that govern how smart contracts are executed.”
Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant regarding the claims are not directed to an abstract idea but rather are directed to technical mechanism, and improvements to the technical functioning of blockchain-based system. Examiner would like to emphasize, the amended claims 1, 11, and 20 recites decrypting transactions voucher, identifying recipient, and validating the transaction voucher, these cover business relationship which covers falls under Certain Methods of Organizing Human Activity. The additional elements like such as blockchain serve as tool to perform the abstract idea. Additionally, the rejection is updated to reflect applicant’s amendment to the claim. See the updated rejection. Thus the rejection is proper, and has been maintained.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits: “Accordingly, Applicant submits that Lupowitz, Moreno, and Bishnoi do not disclose voucher keys as currently claimed, and do not disclose, among other things, a "smart contract being linked to a voucher creator account in the database system assigned to a voucher creator role, the voucher creator role being linked to a voucher public key stored on the blockchain in association with the smart contract and a voucher private key stored in the relational database, the owner account accessing the smart contract via an ownership public key and an ownership private key that are different from the voucher public key and the voucher private key, the voucher private key being inaccessible to the voucher creator account, and the voucher public key and the voucher private key being configured to authorize blockchain operations separately from the ownership public key and the ownership private key", or performing the blockchain action "such that the blockchain action is performed responsive to the validating of the transaction voucher, and such that a minting operation is performed to a wallet identified by the transaction voucher and separately from a wallet identified by the owner account", as currently claimed. Applicant submits that Negi fails to cure the deficiencies of Lupowitz, Moreno, and Bishnoi with respect to claim 1. Negi describes a TEE engine for cryptographic operations where a private key may be inaccessible to any party. While Negi generally describes a private key associated with a cryptographic engine, Negi does not disclose different keys associated with a block chain in which voucher public keys and the voucher private keys are used to authorize blockchain operations separately from ownership public keys and ownership private keys of the blockchain, and additionally does not disclose performing a blockchain action responsive to validating a transaction voucher where the minting operation is performed to a wallet identified by the transaction voucher and separately from a wallet identified by the owner account.”
Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s arguments are directed towards the amended claim language and not original set of claims. Examiner does not agree with applicants summary of the Negi reference, however, the examiner has updated the rejection and added Bodenmiller reference. The Bodenmiller references discloses minting operation being performed in specified wallet (see Bodenmiller [0041]). Additionally, the combination of Lupowitz, Moreno, Bishnoi, and Bodenmiller discloses the claim limitations of claims 1, 11, and 20. See the updated rejection. Thus the rejection is proper, and has been maintained.
Applicant submits: “Claims 7-8, 10, 17-18 were rejected under 35 U.S.C. 103 as allegedly being unpatentable over the combination of Lupowitz in view of Moreno, in further view of Bishnoi, in further view of Negi, as applied to claims [1, 11] above, in further view of Al Suwailem et al (US 20230385819 A1). Applicant respectfully traverses in view of the following. As discussed above, claim 1 is patentable over Lupowitz, Moreno, Bishnoi, and Negi. Al Suwailem fails to cure the deficiencies of Lupowitz, Moreno, Bishnoi, and Negi with respect to claim 1 because Al Suwailem does not disclose the features of claim 1. Claims 11 and 20 recite similar features and are patentable for at least the same reasons. The dependent claims are patentable at least by virtue of their dependency. Accordingly, Applicant submits that the combination directed to the dependent claims also fails to render the dependent claims unpatentable under 35 U.S.C. 103, and Applicant respectfully requests withdrawal of the rejections to the dependent claims. Claims 9, 19 were rejected under 35 U.S.C. 103 as allegedly being unpatentable over the combination of Lupowitz in view of Moreno, in further view of Bishnoi, in further view Negi, as applied to claims [1, 11] above, in further view of Law et al (US 20230385819 A1). Applicant respectfully traverses in view of the following. As discussed above, claim 1 is patentable over Lupowitz, Moreno, Bishnoi, and Negi. Law fails to cure the deficiencies of Lupowitz, Moreno, Bishnoi, and Negi with respect to claim 1 because Law does not disclose the features of claim 1. Claim 11 recites similar features and is patentable for at least the same reasons. The dependent claims are patentable at least by virtue of their dependency. Accordingly, Applicant submits that the combination directed to the dependent claims also fails to render the dependent claims unpatentable under 35 U.S.C. 103, and Applicant respectfully requests withdrawal of the rejections to the dependent claims.”
Examiner response: : Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. As established in the previous response, the combination of Lupowitz, Moreno, Bishnoi, and Bodenmiller discloses the claim limitations of claims 1, 11, and 20. And thus by at least virtue of dependency claims 7-8, 10, 17-18, and 9, 19 remain rejected. See the updated rejection. Thus the rejection is proper, and has been maintained.
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20140209673 A1 Phillips; Simon AUTOMATED OPENING OF ELECTRONIC WALLET FUNCTION IN MOBILE DEVICE - A method includes bringing a mobile device into proximity with an indicium, the indicium adjacent a radio frequency identification (RFID) integrated circuit (IC), the RFID IC coupled to an antenna. The method further includes the mobile device reading a message from the RFID IC, where the message is transmitted by the RFID IC via the antenna. The method further includes the mobile device responding to the message by opening an electronic wallet function in the mobile device.
US 20230105132 A1 White; Michael Wells et al. Pairing A Payment Object Reader With A Point-Of-Sale Terminal - In some examples, a system and method for pairing a payment object reader with a point-of-sale (POS) terminal is described herein. The payment object reader includes one or more light indicators configured to display information in an optical pattern of one or more colors, brightness, lightness, and intensities, wherein the light indicators display a first optical pattern representative of an operational status of the payment object reader in a first mode, and a second optical pattern representative of a pairing code in a second mode. A display control component, executed by a processor, is configured to control the light indicators in accordance with the pairing code to generate the second optical pattern, the second optical pattern when shared with the POS terminal enables pairing between the payment object reader and the POS terminal. When paired, the payment object reader allows the POS terminal to accept payments from a customer.
US 20220027041 A1 EVERITT; Katherine Mary et al. GRAPHICAL USER INTERFACE CONTROL FOR DUAL DISPLAYS - A computing device includes a first portion comprising a first display, and a second portion comprising a second display. The second portion is rotatably connected to the first portion. The computing device executes a program comprising a context user interface and a focus user interface. The focus user interface is configured to provide a more detailed view of a selected item from the context user interface. When the computing device is in a double-portrait orientation, the context user interface is displayed on the first display. Upon receipt of a spanning user input, the computing device displays the context user interface on the first display and the focus user interface on the second display. Upon detecting a rotation to a double-landscape orientation, the computing device displays the focus user interface on the first display and second display.
US 20220365632 A1 PRESTON; Daniel T. et al. INTERACTING WITH NOTES USER INTERFACES - An electronic device provides for efficient display and/or interaction with notes user interfaces. In some embodiments, an electronic device facilitates the addition of content displayed with a note to the note.
US 20230390627 A1 BOLTON; Craig D. et al. USER INTERFACES FOR PHYSICAL ACTIVITY INFORMATION - User interfaces for managing, modifying, and/or outputting workout content.
US 11341494 B2 Warner; Maribeth Sevigny et al. Dynamic security code authorization verification service - A method includes receiving a request to verify a dynamic security code included in a transaction authorization request message. The transaction authorization request message was generated in connection with a payment account transaction. The method further includes performing a verification process with respect to the dynamic security code to generate a verification result. In addition, the transaction authorization request message may be modified by adding the verification result to the transaction authorization request message. Also, the modified transaction authorization request message may be transmitted to an issuer of a payment account designated for use in the payment account transaction.
US 20240118793 A1 TRIVERIO; Marco et al. REAL-TIME COMMUNICATION USER INTERFACE - The present disclosure generally relates to real-time communication user interfaces. A computer system displays a visual representation of a user attempting to join a real-time communication session that includes an option that is selectable to determine whether the user is allowed to participate in the real-time communication session.
US 11625731 B2 Negi; Ansuya et al. Methods, Systems And Apparatus To Track A Provenance Of Goods - Methods, apparatus, systems and articles of manufacture are disclosed to track a provenance of goods. An example apparatus includes an unsigned block generator to generate a first unsigned block to store first processing data associated with the product by a first entity, a block signature engine to sign the first unsigned block with a first private key to generate a blockchain having a first signed block, the unsigned block generator to generate a second unsigned block in response to a second entity generating second processing data associated with the product by the second entity, the block signature engine to expand the blockchain by signing the second unsigned block with a second private key to generate a second signed block within the blockchain, and a blockchain validator to verify the product provenance by validating the first processing data and the second processing data using respective public keys associated with the first entity and the second entity.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6:00pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/M.S.H./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights