DETAILED ACTION
Notice of AIA Status
The present application, filed on 06/01/2023, is being examined under the AIA first inventor to file provisions.
Status of Claims
The following is a FINAL Office Action in response to Applicant’s amendments filed on 06/10/2025.
a. Claims 1, 11, 20 are amended
b. Claims 2, 4, 12, 14 are cancelled
Overall, Claims 1, 3, 5-11, 13, 15-20 are pending and have been considered below.
Information Disclosure Statement (IDS)
The information disclosure statement(s) (IDS)s submitted on 06/10/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, such IDS is being considered by Examiner.
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, computer implemented method, claims 11, 13-19 are directed to a computer implemented method, and claim 20 is directed to 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.
[INDEPENDENT CLAIMS]
Per Step 2A.1. Claim 1, (which is representative of Claims 11, 20) is rejected under 35 USC 101 because the claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The limitations of the independent claim 1 (which is representative of claims 11, 20) recite an abstract idea, shown in bold 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;
[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 an 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 including an executable function operable to perform the 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.
Claim 1 (which is representative of claims 11, 20) recites: database storing customer relation management information as transaction records ([B]); interface to deploy contract ([C]); create transaction voucher to authorize voucher recipient and the transaction voucher being signed by a private key ([D]) transmit transaction voucher ([E]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “enabling a means of completing a transaction”.
This is a combination that, under its broadest reasonable interpretation, covers agreements in the form of sales activities or behaviors, which 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
Alternatively, and/or in addition, the limitations, as drafted, constitute a process that under its broadest reasonable interpretation, covers performance of the limitations mentally or manually, but for the recitation of generic computer components. Nothing in the claim elements precludes the steps from being practically performed mentally or manually by a human. For example, “confirming that the wallet identifier matches an identifier identifying the voucher recipient account”, as drafted in the context of this claim, encompasses the user manually or mentally matching two identifiers. If a claim limitation, under broadest reasonable interpretation, covers performance of the limitation in mind, but for the recitation of generic computer components, then it falls within the Mental Processes – Concepts Performed in the Human Mind (e.g. observation, evaluation, judgement, opinion) grouping of abstract ideas.
Accordingly, it is reasonable to conclude that claim 1 (which is representative of claims 11, 20) recites an abstract idea that represents a judicial exception.
[INDEPENDENT CLAIMS – QUALIFIERS]
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 additional elements “processor”, “blockchain”, “smart”, “communication interface” 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 modifiers do not preclude from carrying out the identified abstract idea of enabling a means of completing transaction. Therefore, those modifiers do not serve to integrate the identified abstract idea into a practical application.
[INDEPENDENT CLAIMS – ADDITIONAL STEPS]
The additional claim elements also recite: one or more hardware processors to create a transaction voucher (limitation [D]). When considered individually or as an ordered combination, they amount to nothing more than reception, transmission and/or general computation of claim elements that serves merely to implement the abstract idea using computing components for performing computer function (adding the words “apply it” or an equivalent – MPEP 2106.05(f)), or merely uses a computer as a tool to perform the identified abstract idea.
Therefore, the additional elements 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 further elements that are sufficient to amount to significantly more than the judicial exception because, when the claim is reevaluated as a whole, as a combination under the considerations of Step 2B, the outcome is the same like in 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 about the computing environment or the additional steps (limitations [D]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea (“enabling a means of completing transaction 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]
Dependent claim 3, which is representative of claim 13, 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.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “enabling a means of completing a transaction”. The elements in this dependent claim are comparable to 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. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“enabling a means of completing a transaction”) into a practical application (see MPEP 2106.05(f)).
The dependent claim elements have the same relationship to the underlying abstract idea (“enabling a means of completing a transaction”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“enabling a means of completing a transaction”).
Therefore, claim 3 (which is representative of claim 13) is deemed ineligible.
Dependent claim 5, which is representative of claim 15, recites:
wherein the action comprises minting a token to a wallet owned by the voucher recipient account.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “enabling a means of completing a transaction”. The elements in this dependent claim are comparable to 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. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“enabling a means of completing a transaction”) into a practical application (see MPEP 2106.05(f)).
The dependent claim elements have the same relationship to the underlying abstract idea (“enabling a means of completing a transaction”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“enabling a means of completing a transaction”).
Therefore, claim 5 (which is representative of claim 15) is deemed ineligible.
Dependent claim 6, which is representative of claim 16, recites:
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.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “enabling a means of completing a transaction”. The elements in this dependent claim are comparable to 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. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“enabling a means of completing a transaction”) into a practical application (see MPEP 2106.05(f)).
The dependent claim elements have the same relationship to the underlying abstract idea (“enabling a means of completing a transaction”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“enabling a means of completing a transaction”).
Therefore, claim 6 (which is representative of claim 16) is deemed ineligible.
Dependent claim 7, which is representative of claim 17, recites:
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.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “enabling a means of completing a transaction”. The elements in this dependent claim are comparable to 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. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“enabling a means of completing a transaction”) into a practical application (see MPEP 2106.05(f)).
The dependent claim elements have the same relationship to the underlying abstract idea (“enabling a means of completing a transaction”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“enabling a means of completing a transaction”).
Therefore, claim 7 (which is representative of claim 17) is deemed ineligible.
Dependent claim 8, which is representative of claim 18, recites:
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.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “enabling a means of completing a transaction”. The elements in this dependent claim are comparable to 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. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“enabling a means of completing a transaction”) into a practical application (see MPEP 2106.05(f)).
The dependent claim elements have the same relationship to the underlying abstract idea (“enabling a means of completing a transaction”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“enabling a means of completing a transaction”).
Therefore, claim 8 (which is representative of claim 18) is deemed ineligible.
Dependent claim 9, which is representative of claim 19, recites:
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.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “enabling a means of completing a transaction”. The elements in this dependent claim are comparable to 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. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“enabling a means of completing a transaction”) into a practical application (see MPEP 2106.05(f)).
The dependent claim elements have the same relationship to the underlying abstract idea (“enabling a means of completing a transaction”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“enabling a means of completing a transaction”).
Therefore, claim 8 (which is representative of claim 18) is deemed ineligible.
Dependent claim 10, recites:
the smart contract includes an invalidation function operable to invalidate the transaction voucher upon receiving an invalidation request signed by the voucher private key.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “enabling a means of completing a transaction”. The elements in this dependent claim are comparable to 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. Thus, it is reasonable to conclude that these claim elements do not integrate the identified abstract idea (“enabling a means of completing a transaction”) into a practical application (see MPEP 2106.05(f)).
The dependent claim elements have the same relationship to the underlying abstract idea (“enabling a means of completing a transaction”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“enabling a means of completing a transaction”).
Therefore, claim 10 is deemed ineligible.
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. The most significant elements, which form the abstract concept, are set forth in the independent claims. The fact that the computing devices and the dependent claims are facilitating the abstract concept is not enough to confer statutory subject matter eligibility, since their individual and combined significance do not transform the identified abstract concept at the core of the claimed invention into eligible subject matter. Therefore, it is concluded that the dependent claims of the instant application, considered individually, or as a as a whole, as an ordered combination, do not amount to significantly more (see MPEP 2106.07(a)II).
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
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 difference 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 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(a) are summarized as follows:
i. Determining the scope and contents of the prior art.
ii. Ascertaining the differences between the prior art and the claims at issue.
iii. Resolving the level of ordinary skill in the pertinent art.
iv. 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 et al (US 11379429 B1), in view of Moreno et al (US 20210090108 A1), in further view of Bishnoi et al (US 20190012695 A1), in further view of Negi et al (US 11625731 B2).
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 (reads on: 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 (reads on: 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 (reads on: 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 an action, and {see at least [13/61-67] In some embodiments, 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 (reads on: 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}
Lupowitz does not disclose, however, Moreno discloses:
a blockchain interface operable to deploy to the blockchain a smart contract owned by a 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 {see at least [0020] creating a smart contract template by the issuer server (reads on: voucher creator) from the at least one attestation threshold, the voucher, the identifier of the voucher holder application (reads on: tenant) and the attestation application, and registering the public key of the issuer server application in the smart contract system (reads on: voucher creator being linked with public key) and signing the smart contract template with the private key of the issuer server application}
{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. (reads on: transaction voucher is validated by using checking the digital signature using the public key)}
In addition, it would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Lupowitz to include the elements of Moreno. One would have been motivated to do so, in order to validate voucher to provide a reward. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). Lupowitz, evidently discloses storing and transferring token. Moreno is merely relied upon to illustrate the functionality of validating transaction vouchers in the same or similar context. As best understood by Examiner, since both storing and transferring token, as well as validating transaction vouchers are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements 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.
Lupowitz, Moreno does not disclose, however, Bishnoi discloses:
a communication interface operable to transmit the transaction voucher to a client device. {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 (reads on: client device), possessed by the recipient 106. (voucher is sent to a recipient device 112). [0031] the recipient device 112 and authorized point of sale devices 102) may possess encryption keys (reads on: public or private keys) suitable for decryption of the encrypted voucher (reads on: 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 (reads on: POS device 102 checks if the identifiers matches before performing operation)}
In addition, it would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Lupowitz, Moreno to include the elements of Bishnoi. One would have been motivated to do so, in order to authenticate transaction voucher(s). Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). Lupowitz, Moreno evidently discloses creating token and having a voucher creator. Bishnoi is merely relied upon to illustrate the functionality of signing transaction using private key in the same or similar context. As best understood by Examiner, since both creating token and having a voucher creator as well as signing transaction using private key are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Lupowitz, 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.
Lupowitz, Moreno, Bishnoi does not disclose, however, Negi discloses:
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; {see at least [3/45-50] such as the example TEE engine 128 of FIG. 1 , in which the private key is inaccessible to any party (including the owner/operator of the TEE engine 128). Such protective measures reduce and/or eliminate the possibility of the private key being inadvertently and/or maliciously released. (Reads on: keys being inaccessible)}
In addition, it would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Lupowitz, Moreno, Bishnoi to include the elements of Negi. One would have been motivated to do so, in order to reduce and/or eliminate the possibility of the private key being inadvertently and/or maliciously released. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). Lupowitz, Moreno, Bishnoi evidently discloses creating token and having a voucher creator. Negi is merely relied upon to illustrate the functionality of reducing and/or preventing the release of private key in the same or similar context. As best understood by Examiner, since both creating token and reducing and/or preventing the release of private key are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Lupowitz, Moreno, Bishnoi as well as Negi 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/Negi.
Regarding Claims 3, 13. Lupowitz, Moreno, Bishnoi, Negi 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 (reads on: 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. (reads on: 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 to one of ordinary skill in the art, at the time of filing, to modify Lupowitz, Moreno, Bishnoi, Negi to include additional elements of Moreno. One would have been motivated to do so, in order to assign roles to multiple accounts. In the instant case, Lupowitz, Moreno, Bishnoi, Negi evidently discloses storing private key being stored in a database. Moreno is merely relied upon to illustrate the additional functionality of showing polarity of accounts with voucher role in the same or similar context. 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.
Lupowitz, Moreno, Bishnoi, Negi does not disclose, however, 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. (reads on: 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 to one of ordinary skill in the art, at the time of filing, to modify Lupowitz, Moreno, Bishnoi, Negi to include additional elements of Bishnoi. One would have been motivated to do so, in order to securely store the private key. In the instant case, Lupowitz, Moreno, Bishnoi, Negi evidently discloses authenticating transaction voucher. Bishnoi is merely relied upon to illustrate the additional functionality of storing voucher private key in the relational database in the same or similar context. 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, Negi 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. (reads on: the token storage is the wallet owned by the user.)]
Regarding Claims 6, 16. Lupowitz, Moreno, Bishnoi discloses the limitations of Claims 1, 11. Lupowitz, Moreno, Bishnoi, Negi does not disclose, however, 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 to one of ordinary skill in the art, at the time of filing, to modify Lupowitz, Moreno, Bishnoi, Negi to include additional elements of Moreno. One would have been motivated to do so, in order to validate transaction. In the instant case, Lupowitz, Moreno, Bishnoi, Negi evidently discloses creating and authenticating vouchers. Moreno is merely relied upon to illustrate the additional functionality of validating transaction voucher in the same or similar context. 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 Negi, as applied to claims [1, 11] above, in further view of Al Suwailem et al (US 20230385819 A1).
Regarding Claims 7, 17. Lupowitz, Moreno, Bishnoi, Negi discloses the limitations of Claims 1, 11. Lupowitz, Moreno, Bishnoi, Negi does not disclose, however, 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. {see at least [0006] recording in a blockchain network, with a user computing device of a user with at least one blockchain based voucher, (reads on: 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 (reads on: voucher is invalid after a finite period of time.)}
In addition, it would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Lupowitz, Moreno, Bishnoi, Negi to include the elements of Al Suwailem. One would have been motivated to do so, in order to validate transaction. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). Here, Lupowitz, Moreno, Bishnoi, Negi, evidently discloses storing and transferring token. Al Suwailem is merely relied upon to illustrate the functionality of invalidating vouchers after the period of validity is passed in the same or similar context. As best understood by Examiner, since both storing and transferring token, as well invalidating vouchers after the period of validity is passed are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Lupowitz, Moreno, Bishnoi, Negi 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, Negi/Al Suwailem.
Regarding Claims 8, 18. Lupowitz, Moreno, Bishnoi, Negi discloses the limitations of Claims 1, 11. Lupowitz, Moreno, Bishnoi, Negi does not disclose, however, 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. {[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 (reads on: 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 (reads on: transaction is validated if the transaction amount is less than or equal to the voucher amount.)}
In addition, it would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Lupowitz, Moreno, Bishnoi, Negi to include additional elements of Al Suwailem. One would have been motivated to do so, in order to validating transaction voucher. In the instant case, Lupowitz, Moreno, Bishnoi, Negi evidently discloses storing and transferring token. Al Suwailem is merely relied upon to illustrate the additional functionality of completing the purchase when set of rules in the same or similar context. 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, Negi discloses the limitations of Claim 1. Lupowitz, Moreno, Bishnoi, Negi does not disclose, however, Al Suwailem discloses:
wherein the smart contract includes an invalidation function [(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; (reads on: voucher is validated by the blockchain network, and valid for a finite period.)]
In addition, it would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Lupowitz, Moreno, Bishnoi, Negi to include additional elements of Al Suwailem. One would have been motivated to do so, in order to validate transaction. In the instant case, Lupowitz, Moreno, Bishnoi, Negi evidently discloses storing and transferring token. Al Suwailem is merely relied upon to illustrate the additional functionality of invalidating vouchers after the period of validity is passed in the same or similar context in the same or similar context. 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.
Al Suwailem not disclose, but the following is intended use:
operable to invalidate the transaction voucher upon receiving an invalidation request signed by the voucher private key. [The claim element “operable to invalidate the transaction voucher upon receiving an invalidation request signed by the voucher private key” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but which imparts neither structure nor functionality to the claimed method, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.]
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 Negi, as applied to claims [1, 11] above, in further view of Law et al (US 20230385819 A1).
Regarding Claims 9, 19. Lupowitz, Moreno, Bishnoi, Negi discloses the limitations of Claims 1, 11. Lupowitz, Moreno, Bishnoi, Negi does not disclose, however, 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 (reads on: 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. (reads on: confirming that the wallet identifiers matches.)]
In addition, it would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Lupowitz, Moreno, Bishnoi, Negi to include the elements of Law. One would have been motivated to do so, in order to validate transaction vouchers. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). Lupowitz, Moreno, Bishnoi, Negi, evidently discloses storing and transferring token. Law is merely relied upon to illustrate the functionality of validating recipient’s wallet ID by the decrypted recipient wallet ID in the same or similar context. As best understood by Examiner, since both storing and transferring token, as well as validating recipient’s wallet ID by the decrypted recipient wallet ID are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Lupowitz, Moreno, Bishnoi, Negi, 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, Negi/Law.
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.
Response to Amendments/Arguments
Applicant’s submitted remarks and arguments have been fully considered.
Applicant disagrees with the Office Action conclusions and asserts that the presented claims fully comply with the requirements of 35 U.S.C. § 101 regrading judicial exceptions. Further, Applicant is of the opinion that the prior art fails to teach Applicant’s invention.
Examiner respectfully disagrees in both regards.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits:
a. The pending claims are not directed to an abstract idea.
b. The identified abstract idea is integrated into a practical application.
c. The pending claims amount to significantly more.
Furthermore, Applicant asserts that the Office has failed to meet its burden to identify the abstract idea and to establish that the identified abstract idea is not integrated into a practical application and that the pending claims do not amount to significantly more.
Examiner responds – The arguments have been considered in light of Applicants’ amendments to the claims. The arguments ARE NOT PERSUASIVE. Therefore, the rejection is maintained.
The pending claims, as a whole, are directed to an abstract idea not integrated into a practical application. This is because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05 (a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05 (b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05 (c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05 (e) and the Vanda memo).
In addition, the pending claims do not amount to significantly more than the abstract idea itself.
As such, the pending claims, when considered as a whole, are directed to an abstract idea not integrated into a practical application and not amounting to significantly more.
More specific:
Applicant submits: “By way of example, the Applicant respectfully submits that claim 1 does not fall into any of these enumerated categories. Claim 1 recites a computing system that includes a relational database, a blockchain interface, a processor, and a communication interface that collectively are configured to perform specific operations related to executing blockchain-related actions involving cryptographic operations based on public and private key signatures and smart contracts. Such a system is not directed to a fundamental economic principle or practice such as hedging, insurance, or risk. Such a system is not directed to commercial or legal interactions such as legal obligations, advertising, or contracts. Please note that a "smart contract" is simply a term for a particular configuration of executable computer code and metadata, and is not a legal contract. Smart contracts are used for many purposes (e.g., NFTs), and not necessarily for business transactions. Such a system is also not directed to managing personal behavior or relationships or interactions between people such as social activities or teaching. Because claim 1 does not fall into any of the enumerated categories, claim 1 is not directed to "Certain Methods of Organizing Human Activity" as defined in the MPEP.” Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Examiner Response: Examiner disagree with applicants argument, the applicants claim as a whole directed to completing transaction. Although examiner understands “smart contract” is an executable code, however, applicant claims are directed towards completing a transaction. Thus, the rejection is proper and has been maintained.
Applicant submits: “Claim 1 recites "a relational database storing customer relations management information for a plurality of tenants" including "transaction records that reflect tokens minted on a blockchain and transferred to customers of the plurality of tenants." As a general matter, the human mind is incapable of executing the many complex operations needed to provide a relational database. Claim 1 recites "a blockchain interface operable to deploy to the blockchain a smart contract." Deploying a smart contract to the blockchain involves executing complex operations involving cryptographic authentication, transmitting requests to remote computing devices, and receiving and responding to requests from remote computing devices. The human mind is capable of performing none of these operations, even with the aid of pencil and paper. Claim 1 recites one or more processors operable to create a transaction voucher "signed with the voucher private key." Signing a voucher with a private key associated with a blockchain account is a complex cryptographic operation not capable of being performed in the human mind. According to the MPEP, "A Claim With Limitation(s) That Cannot Practically be Performed in the Human Mind Does Not Recite a Mental Process". Because claim 1 recites several limitations that cannot practically be performed in the human mind, claim 1 is not directed to a Mental Process. Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Examiner Response: Examiner disagree with applicant that claim 1 recites limitations that cannot be performed in the human mind. The amended claim 1 (which is representative of claim 11, 20), recites “by confirming the identifier matches an identifying voucher recipient account”. The matching of two identifiers can be done in a human mind as it evaluating two set of numbers. And evaluation falls under Mental Processes, i.e., Concepts Performed in the Human Mind grouping of abstract ideas. See MPEP 2106.04(a)(2). Thus, the rejection is proper and has been maintained.
Applicant submits: Summary For at least the preceding reasons, the Applicant respectfully submits that claim 1 is not directed to an abstract idea and hence is directed to patent eligible subject matter. Claims 11 and 20 have been amended to recite features similar to those recited in claim 1 and hence are directed to patent eligible subject matter for the same reasons as claim 1. The remaining claims are dependent claims which are directed to patent eligible subject matter for at least the same reasons as the independent claims on which they are based. Accordingly, it is respectfully requested that the rejections of the claims under 35 U.S.C. 101 be withdrawn.” Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Examiner response: See reasoning immediately above. Thus, the rejection is proper and has been maintained.
It follows from the above that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself. Therefore, the rejection under 35 U.S.C. § 101 is maintained.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits: “claim 1 recites a blockchain interface operable to deploy to the blockchain a smart contract. The smart contract is 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 voucher account is associated with a voucher creator role, but the voucher private key is "inaccessible to the voucher creator account." Thus, in claim 1, the account assigned to the "voucher creator role" is nevertheless unable to access the voucher private key. Instead, the database system creates the voucher at the request of the voucher creator role and then uses the voucher private key to sign the transaction voucher. The Office Action acknowledges that the combination of Lupowitz, Moreno, and Bishnoi does not disclose a configuration in which a voucher private key is inaccessible to the voucher creator account (Office Action, page 19). Instead, the Office Action cites Fernando as disclosing these features.” Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Examiner Response: Applicants argument is directed towards amended claims and not the original set of claims. Furthermore, the Negi reference discloses the limitation where the private key is in accessible. See the rejection above directly above. Thus, the rejection is proper and has been maintained.
Applicant submits: “Fernando states that "only an authorized person can have access to the private key." (Abstract). Fernando also states that the "public key can be disclosed to the public or maybe advertised as widely as the user wants while private key has to be kept secret." (Introduction). However, claim 1 recites a specific configuration in which a "voucher private key" is stored in a database system and is "inaccessible" to a "voucher creator account" that is assigned to a "voucher creator role." A general description of public key cryptography, as provided in Fernando, is different from the specific configuration of two different sets of public and private keys recited in claim 1. Fernando does not describe any such key configuration, and in particular does not describe creating a voucher upon request by a voucher creator role that cannot access the voucher public key needed to sign the voucher transaction. Al Suwailem is not cited as disclosing a configuration in which a voucher private key is inaccessible to the voucher creator account, nor can Applicant's attorney find any discussion of such features in Al Suwailem. Law is not cited as disclosing or suggesting any feature recited in an independent claim and, therefore, is not discussed herein.” Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Examiner Response: Examiner disagree with applicant, as every private key is unique to the specific user. Furthermore, applicants argument is directed towards amended language. See rejection above. The combination of Lupowitz, Moreno, and Bishnoi, and Negi does disclose private key being inaccessible. In addition, the applicant argue Al Suwailem is not cited as disclosing in which a voucher private key is inaccessible to the voucher creator account. Examiner disagree, as the examiner used combination of Lupowitz, Moreno, Bishnoi and Al Suwailem to reject claim 4 in the previous office action. Claim 4 (which is representative of claim 14) in the original disclosure recites “The computing system recited in claim 1, wherein the voucher private key is inaccessible to the voucher creator account.”. However, applicant has canceled claim 4 and amended claim 1 to have claim 4’s limitation. See the rejection above. Applicant also argued that Law reference does not recite any feature recited in an independent claim. However, examiner uses the combination of Lupowitz, Moreno, and Bishnoi and Law to reject claim 9 (which is representative of claim 19). See the rejection above. Thus, the rejection is proper and has been maintained.
Applicant submits: “Part 2 By way of example, claim 1 recites a blockchain interface operable to deploy to the blockchain a smart contract owned by an 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 Office Action acknowledges that the combination of Lupowitz, Moreno, and Bishnoi does not disclose a configuration in which an owner account accesses 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 (Office Action, page 15). Instead, the Office Action cites Al Suwailem as disclosing these features. Al Suwailem mentions keys in only one passage ([0096]). In this passage, Al Suwailem states: "In whatever form the blockchain network takes, blockchain network 102 can access the blockchain and initiate transactions that will be recorded in and modify the blockchain (e.g. using respective secret keys)." ([0096]). Al Suwailem does not provide any specifics Application regarding the key configuration, and in particular does not describe different keys associated with a voucher account and an owner account. Because Al Suwailem does not describe separate voucher keys and owner keys, Al Suwailem also does not describe deploying to the blockchain a smart contract owned by an 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". Fernando is not cited as disclosing a configuration that involves deploying to the blockchain a smart contract owned by an 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", nor can Applicant's attorney find any discussion of such features in Fernando.
Examiner response: Applicant’s argument and remarks are gear towards the amendments. Examiner has carefully reviewed and considered Applicant’s remarks, however they ARE MOOT in light of the fact that they are geared towards the amendments.
Applicant submits: “Summary Hence, the cited references, considered alone or in combination, fail to disclose or suggest several features recited in claim 1 as amended. Since claim 1 recites features that are not disclosed in any of the cited references, considered alone or in combination, claim 1 is patentable over the cited references. Claims 11 and 20 have been amended to recite features similar to those recited in claim 1 and hence are patentable for the same reasons as claim 1. The remaining claims are dependent claims which are patentable for at least the same reasons as the independent claims on which they are based. Accordingly, it is respectfully requested that the rejections of the claims under 35 U.S.C. 103 be withdrawn.” Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Examiner response: Examiner disagree with the applicant that cited reference alone or in combination fail to disclose or suggest several features of recited claim 1 (which is representative of claims 11, 20) as amended. The applicants’ argument are geared towards amended language and see reasoning directly above. Thus, the rejection is proper and has been maintained.
Applicant submits remarks and arguments geared toward the amendments. Examiner has carefully reviewed and considered Applicant’s remarks, however they ARE MOOT in light of the fact that they are geared towards the amendments.
The other arguments presented by Applicant continually point back to the above arguments as being the basis for the arguments against the other 103 rejections, as the other arguments are presented only because those claims depend from the independent claims, and the main argument above is presented against the independent claims. Therefore, it is believed that all arguments put forth have been addressed by the points above.
Examiner has reviewed and considered all of Applicant’s remarks. The changes of the grounds for rejection, if any, have been necessitated by Applicant’s extensive amendments to the claims. Therefore, the rejection is maintained, necessitated by the extensive amendments and by the fact that the rejection of the claims under 35 USC § 101 has not been overcome.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Inquiries
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 on Monday – Friday 8:30am – 6pm EST. 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.
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.
As disclosed in MPEP 502.03, communications via Internet e-mail are at the discretion of the applicant. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. A paper copy of such correspondence will be placed in the appropriate patent application. The following is a sample authorization form which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with me concerning any subject matter of this application by electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center information webpage. Status information for unpublished applications is available to registered users through Patent Center information webpage only.
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.
Any response to this action should be mailed to:
Commissioner of Patents and Trademarks
P.O. Box 1450
Alexandria, VA 22313-1450
or faxed to 571-273-8300
Hand delivered responses should be brought to the:
United States Patent and Trademark Office
Customer Service Window
Randolph Building
401 Dulany Street
Alexandria, VA 2231
/Md. S. H./
Examiner, AU 3698
09/17/2025
/RADU ANDREI/Primary Examiner, Art Unit 3698
Prosecution Insights