DETAILED ACTION
This Office Action corresponds to the response filed on 03/14/2026 in which claims 1-24 are presented for examination on the merits.
Notice of Pre-AIA or AIA Status
The present application is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/22/2026 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
Response to Arguments
1. Applicant's arguments in pages 10-21 of the REMARKS filed on 03/14/2026 with respect to the rejection under 35 USC § 103(a) are acknowledged. However, after careful review, the rejection under 35 U.S.C. 103(a) to claims 1-24 are maintained for the reasons specified in the rejection below.
2. Regarding independent claims 1, 10, 14, 23, and 24 rejected under 35 U.S.C. 103(a), applicant argues, for example:
"In view of the above, in Patange, the blockchain transaction (purchase cryptographic tokens) is made without using any software information. In addition, Patange relies on token-based transactions and smart contract records to define and manage software entitlements, and does not disclose publishing software information as trade block data, as recited in claim 1. Therefore, Patange does not disclose or suggest 'sending a blockchain trade according to the blockchain information and the software information to generate a first trade block corresponding to the blockchain, wherein the first trade block comprises published software information corresponding to the software information', as recited in claim 1 of the subject application."
The argument is not persuasive. After careful review, the Examiner respectfully disagrees with Applicant's characterization of the cited references.
With respect to Patange, Applicant contends that the blockchain transaction in Patange is made without using software information and that Patange does not disclose publishing software information as trade block data. However, this argument mischaracterizes the scope of Patange's disclosure. Patange explicitly discloses that licensed software and subscription services associated with an enterprise are received by a rights management server, wherein a proprietary blockchain monitor is utilized for software/service usage and to manage subscriptions (Patange, Paragraphs 0034, 0036, 0038, 0039: licensed software and subscription services associated with an enterprise wherein software and/or service usage by devices/clients on the private network is received by right management server).
Further, Patange discloses that the entitlement agent enforces blockchain transactions locally wherein software and/or service usage by devices/clients on the private network is received and recorded (Patange, Paragraph 0039). This directly corresponds to sending a blockchain trade according to blockchain information and software information to generate a trade block.
Applicant further asserts that Kozul generates its token prior to, and independent from, any assignment to a specific user or machine, and therefore the token is generated without blockchain information established according to client information.
This argument is not persuasive. Kozul explicitly discloses that a primary distributed ledger is used to manage an organization's software licenses wherein each license in an organization may be converted to a token in the distributed ledger (Kozul, Para. 0027: token includes an identifier of at least one of a publisher of the software, a version number of the software, a purchase order associated with the license, and at least one maintenance date for the license.. wherein Blockchain is used to manage an organization's software licenses. As software is assigned to users or machines, the primary distributed ledger may transfer the token to a “side chain” that is specific to the user or machine).
As new licenses are purchased, a new token may be generated, and as software is assigned to users or machines, the primary distributed ledger may transfer the token to a "side chain" that is specific to the user or machine as disclosed above in Para. 0027 of Kozul. Importantly, Kozul discloses that the token includes an identifier of at least one of a publisher of the software, a version number of the software, a purchase order associated with the license, and at least one maintenance date for the license (Kozul, Para 0017, 0006: token includes an identifier of at least one of a publisher of the software, a version number of the software, a purchase order associated with the license, and at least one maintenance date for the license.. wherein Blockchain is used to manage an organization's software licenses).
This constitutes published software information corresponding to the software information as claimed, clearly covering software name, software version, and authorization period—the very content of the first trade block recited in claim 1.
Contrary to Applicant's assertion, Kozul does not operate in isolation from blockchain information established from client interaction. Kozul discloses that when a new software license request is received, a check is made to see if tokens representing a purchased license are available, and the destination (user or electronic device) is identified before a token is assigned (Kozul, Paras. 0044-0051: token comprises an identification associated with electronic device and software wherein the publisher keep the “ID” of the token as published hardware information specific to the device).
The assignment of the token to a wallet associated with the specific user or electronic device, and the writing of the token reservation to the license distributed ledger, constitutes the establishment of blockchain information based on client information, in a manner that teaches the claimed limitation.
The combination of Patange and Kozul thus leaves no ambiguity that sending a blockchain trade according to the blockchain information and software information to generate a first trade block wherein the first trade block comprises published software information corresponding to the software information is disclosed by the cited art, as would be understood by one of ordinary skill in the art. It would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate Kozul's token-based published software information into Patange's blockchain framework because doing so would provide a standardized, immutable record of software license details that facilitates compliance tracking—a predictable design choice yielding known advantages. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).
Accordingly, the rejection of independent claims 1, 14, and 23, is maintained. Claims 7 and 20, which depend from claims 1 and 14 respectively, are likewise maintained for at least the same reasons.
3. Regarding independent claim 10, applicant argues, for example:
"Patange uses only one parameter (i.e., remaining amount of entitlement) to meter usage of the software assets, but does not disclose authenticating whether the software information matches the published software information, as recited in claim 10. Therefore, Patange does not disclose or suggest 'authenticating whether the software information matches the published software information', as recited in claim 10 of the subject application."
"Kozul does not disclose or suggest 'authenticating whether the software information matches the published software information', as recited in claim 10 of the subject application."
The argument is not persuasive. After careful review, the Examiner respectfully disagrees. Applicant argues that Patange only meters usage based on a remaining amount of entitlement and does not authenticate whether software information matches published software information. However, Applicant's argument improperly reads limitations from the specification into the claim. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Claim 10 recites "authenticating whether the software information matches the published software information" without specifying the particular manner in which such authentication is performed. Patange explicitly discloses that the local blockchain is updated based on entitlement usage, and the global decentralized blockchain is likewise updated to match the local instantiation of the proprietary blockchain (Patange, Para. 0047: determining an entitlement usage of the amount of entitlement the enterprise has for the one or more software assets based on the telemetry data, updating the local blockchain based on the entitlement usage, updating the global decentralized blockchain based on the entitlement usage).
This process of comparing software/service usage against the blockchain records—to validate that usage falls within licensed limits which constitutes an authentication of whether software information matches the published software information as broadly recited in claim 10.
Furthermore, Kozul clearly teaches that during software launch, a check is made to confirm that the user and/or machine has the token corresponding to that software in their wallet (Kozul, Para. 0028). The agent or program accesses the appropriate wallet associated with the electronic device or user for a token associated with the computer program, and verifies that the token is in the wallet (Kozul, Paras. 0059, 0060). This is precisely an authentication step which compares the software information (the launched software's identity) against the published software information (the token in the distributed ledger). Applicant's assertion that Kozul only checks for the presence of a token without authenticating its content against software information is an overly narrow reading of the reference. The token in Kozul inherently carries published software information including a software identifier, license type, publisher identifier, and version number (Kozul, Paras. 0006, 0051, 0055), and the validation step checks that this token corresponds to the launched software—an authentication of software information against published software information.
Thus, the aforesaid teachings in Patange and Kozul, individually and in combination, leave no ambiguity that authenticating whether the software information matches the published software information is taught by the cited art, as would be understood by one of ordinary skill in the art.
In view of the above, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate Kozul's authentication framework into Patange's blockchain-based entitlement system because such a modification would provide a reliable mechanism to prevent unauthorized software execution—a well-recognized goal in the field and a predictable result of combining the two references' teachings. The mere existence of differences between the prior art and the claimed invention does not establish nonobviousness. Dann v. Johnston, 425 U.S. 219, 230 (1976).
Accordingly, the rejection of independent claim 10 is maintained. Independent claim 24, which incorporates the same authentication limitation, is likewise maintained for at least the same reasons.
4. Applicant asserts “..that independent claims 1 and 14 are patentable over the cited prior art. Claims 6 and 8-9 depend from claim 1, claims 19 and 21-22 depend from claim 14, and therefore, the rejections of these claims should be withdrawn for at least the same reasons. In re Fine, 837 F.2d 1071, 5 U.S.P.Q.2d 1596, 1600 (Fed. Cir. 1988).”
The argument is not persuasive. As set forth above, the rejections of independent claims 1 and 14 are maintained. Dependent claims 6 and 8-9 depend from claim 1; dependent claims 19 and 21-22 depend from claim 14. Applicant's sole argument for the patentability of these dependent claims is predicated on the allowability of the parent independent claims. Because the independent claims remain rejected, the rejections of these dependent claims are likewise maintained. See In re Fine, 837 F.2d 1071, 5 U.S.P.Q.2d 1596, 1600 (Fed. Cir. 1988).
Regarding claims 6 and 19 (blockchain information comprising a public key, private key, and blockchain address), Todasco explicitly teaches a blockchain address of a sender comprising an alphanumeric string derived from the public key using asymmetric-key cryptography with a pair of keys such as a public key and a private key (Todasco, Paras. 0146, 0151: blockchain address of sender 1330, includes an alphanumeric string of characters derived from the public key …asymmetric-key cryptography using a pair of keys, such as a public key and a private key. Additional factors may be considered).
Todasco further discloses blockchain addresses (Todasco, Para. 0029). The motivation to combine Todasco's key-pair framework with Patange and Kozul is well-established: secure blockchain transactions employing public-private key cryptography are a standard, well-known technique for facilitating secured execution of blockchain transactions, as expressly recognized in Todasco (See, Abstract).
Regarding claims 8 and 21 (Proof of Authority consensus), Todasco teaches a proof of work consensus model wherein a node validates a transaction (Todasco, Para. 0162: a proof of work consensus model, a node validates a transaction, for example, by running a check or search through the current ledger stored in the blockchain). The selection of a Proof of Authority consensus mechanism would have been an obvious design choice to one skilled in the art as a predictable variant of blockchain consensus mechanisms, yielding no unexpected results.
Regarding claims 9 and 22 (Proof of Work or Proof of Stake consensus), Todasco explicitly discloses that various consensus models may be used, including a proof of work model, a proof of stake model, a delegated proof of stake model, a round robin model, proof of authority, or proof of identity model (Todasco, Para. 0166). This directly and explicitly teaches the limitations of claims 9 and 22.
Accordingly, the rejections of claims 6, 8-9, 19, and 21-22 are maintained.
5. Applicant asserts “in view of the foregoing distinctions, neither of the utilized references individually or in combination teaches or suggests the limitations of the independent claim 24. Applicant respectfully submits that none of the prior art at least discloses "authenticating whether the software information matches the published software information" as recited in claim 24. Therefore, Applicant respectfully submits that the prior art fails to disclose or teach each and every element of the claimed invention and does not render the claimed invention obvious.”
The test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference, but rather what the combined teachings of the references would have suggested to those of ordinary skill in the art. In re Keller, 642 F.2d 413, 425 (CCPA 1981). As demonstrated above, the combination of Patange, Kozul, and Todasco as appropriate, expressly or impliedly teaches each and every limitation of the rejected claims. The Examiner has presented a clear and convincing motivation for combining the references based on their recognized advantages within the same field of software license management using distributed ledger technology. The claimed invention as a whole was at least prima facie obvious in view of the cited art, especially in the absence of sufficient, clear, and convincing evidence of secondary considerations of nonobviousness. See Graham v. John Deere Co., 383 U.S. 1, 17-18 (1966); KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).
Applicant's Remarks do not provide a convincing rationale or objective factual support sufficient to overcome the prima facie case of obviousness.
In view of the foregoing, the rejections of claims 1, 7, 10, 14, 20, and 23-24 under 35 U.S.C. § 103 are hereby maintained. The rejections of claims 6, 8-9, 19, and 21-22 under 35 U.S.C. § 103 are likewise maintained.
Claim Rejections - 35 USC § 103
6. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
7. 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.
8. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
9. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
10. Claims 1, 7, 10, 14, 20, and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Patange et al. (US 20230342435 A1, hereinafter, Patange) in view of Kozul et al. (US 20210056177 A1, hereinafter, Kozul).
Regarding claim 1, Patange discloses a blockchain technique-based software authorization method, performed by an authentication server connected to a blockchain (Para 0006, 0039: local blockchain comprises a private extension of a global decentralized blockchain, determining an entitlement usage of the amount of entitlement the enterprise has for the software assets wherein where nodes validate new blocks. Local and/or private blockchains, also known as permissioned blockchains, are also be managed by a peer-to-peer network or a trusted intermediary),
the software authorization method comprising: receiving client information of a software pack from a client (Para 0034, 0036, 0038, 0039: licensed software and subscription services associated with an enterprise wherein software and/or service usage by devices/clients on the private network is received by right management server)
establishing blockchain information and software information of the software pack according to the client information (Para 0034, 0036, 0038, 0039: licensed software and subscription services associated with an enterprise wherein software and/or service usage by devices/clients on the private network is received by right management server wherein proprietary blockchain monitor is utilized for software/service usage and to manage subscriptions);and
sending a blockchain trade according to the blockchain information and the software information to generate a first trade block corresponding to the blockchain (Para 0039: the local blockchain enforces transactions locally wherein entitlement agent includes or interface with a web application (e.g., a user portal 414) that a user can access via a web browser to purchase or otherwise acquire cryptographic tokens (e.g., blockchain based tokens/currency), sell, distribute, or otherwise divest cryptographic tokens, monitor cryptographic token usage, monitor software/service usage, perform automated metering of software/service licenses, manage subscriptions to licenses/services),
[wherein the first trade block comprises published software information corresponding to the software information].
Patange does not explicitly state but Kozul from the same or similar fields of endeavor teaches wherein the first trade block comprises published software information corresponding to the software information (Kozul, Para 0017, 0027: token includes an identifier of at least one of a publisher of the software, a version number of the software, a purchase order associated with the license, and at least one maintenance date for the license.. wherein Blockchain is used to manage an organization's software licenses. As software is assigned to users or machines, the primary distributed ledger may transfer the token to a “side chain” that is specific to the user or machine.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention wherein the first trade block comprises published software information corresponding to the software information as taught by Kozul in the teachings of Patange for the advantage obtaining a license for the software; generating a token for the license, wherein the token comprises an identification of a license type and a software identifier; writing the token to a license distributed ledger/blockchain for software license management (Kozul, Abstract).
Regarding claim 7, the combination of Patange and Kozul discloses the software authorization method according to claim 1, wherein the software information comprises a software name of the software pack, a software version of the software pack, and an authorization period of the software pack (Kozul Para 0006: token includes an identifier of at least one of a publisher of the software, a version number of the software, a purchase order associated with the license, and at least one maintenance date for the license).
Regarding claim 10, Patange discloses a blockchain technique-based software authentication method, performed by a host associated with a client, wherein the host is installed with a software pack, and the software pack has software information (Para 0040, 0036: cryptographic tokens and/or entitlement/licensing associated with a user and right management provider), the software authentication method comprising:
initiating an authentication program to establish a connection between the host and a blockchain (Para 0041, 0039: requesting entitlements wherein a communication is established between enterprise and a software provider to run analytics and perform global metering of entitlements to make sure the enterprise is not violating its licenses wherein software/service usage and subscription are being validated by the use of blockchain);
querying a first trade block associated with the client from the blockchain, (Para 0006, 0047: determining an entitlement usage of the amount of entitlement the enterprise has for the one or more software assets based on the telemetry data, updating the local blockchain based on the entitlement usage, updating the global decentralized blockchain based on the entitlement usage), [wherein the first trade block comprises published software information corresponding to the software information]
authenticating whether the software information matches the published software information (Patange Para 0006, 0039: local blockchain comprises a private extension of a global decentralized blockchain, determining an entitlement usage of the amount of entitlement the enterprise has for the software assets wherein where nodes validate new blocks. Local and/or private blockchains, also known as permissioned blockchains, are also be managed by a peer-to-peer network or a trusted intermediary; Kozul, Para 0057: software license validation using a distributed ledger/blockchain); and
executing the software pack in response to the software information matching the published software information (Patange Para 0039, 0042: entitlement agent utilizes an engine for the global decentralized blockchain to update blocks of the global decentralized blockchain to match the local instantiation of a proprietary blockchain 408 via an API 412.. The entitlement agent 400 may also include or interface with a web application (e.g., a user portal 414) that a user can access via a web browser to purchase or otherwise acquire cryptographic tokens (e.g., blockchain based tokens/currency), sell, distribute, or otherwise divest cryptographic tokens, monitor cryptographic token usage, monitor software/service usage, perform automated metering of software/service licenses, manage subscriptions to licenses/services)
Patange does not explicitly state but Kozul from the same or similar fields of endeavor teaches wherein the first trade block comprises published software information corresponding to the software information (Kozul, Para 0017, 0027: token includes an identifier of at least one of a publisher of the software, a version number of the software, a purchase order associated with the license, and at least one maintenance date for the license.. wherein Blockchain is used to manage an organization's software licenses. As software is assigned to users or machines, the primary distributed ledger may transfer the token to a “side chain” that is specific to the user or machine.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention wherein the first trade block comprises published software information corresponding to the software information as taught by Kozul in the teachings of Patange for the advantage obtaining a license for the software; generating a token for the license, wherein the token comprises an identification of a license type and a software identifier; writing the token to a license distributed ledger/blockchain for software license management (Kozul, Abstract).
Regarding claim 14; Claim 14 is similar in scope to claim 1, and is therefore rejected under similar rationale (For limitations “a communication circuit, configured to connect to a blockchain; and a control circuit”, See Para 0031, 0025: control other devices communicatively coupled to the controller where the he operating parameters is used to map control variables within the controller including programmable logic controller (PLC) control programming. Microprocessors configured to execute instructions stored in the memory and implemented as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs)).
Regarding claim 20; Claim 20 is similar in scope to claim 7, and is therefore rejected under similar rationale.
Regarding claim 23; Claim 23 is similar in scope to claim 1, and is therefore rejected under similar rationale and furthermore the combination of Patange and Kozul discloses limitations: sending another blockchain trade according to the blockchain information and hardware information to generate a second trade block corresponding to the blockchain (Kozul, Abstract, Para 0007, 0015: generating a token for the license, wherein the token is associated with a software identifier; writing the token to a license distributed ledger and electronic device and adding a second token for the license to an electronic wallet associated with the electronic device wherein the electronic wallet associated with the electronic device is maintained by a second distributed ledger)
wherein the blockchain information and the software information are associated with client information of a software pack (Kozul Para 0026-0027: Blockchain manages an organization's software licenses wherein each license in an organization is converted to a token in a token the distributed ledger. As new licenses are purchased, a new token is generated (e.g., mined). As software is assigned to users or machines, the primary distributed ledger may transfer the token to a “side chain” that may be specific to the user or machine; Kozul, Para 0057: software license validation using a distributed ledger/blockchain); and
the hardware information is associated with a host, and the host is associated with a client (Kozul, Abstract, Para 0007, 0015, 0093: generating a token for the license, wherein the token is associated with a software identifier; writing the token to a license distributed ledger and electronic device and adding a second token for the license to an electronic wallet associated with the electronic device wherein the electronic wallet associated with the electronic device is maintained by a second distributed ledger wherein the combination of hardware and software used by the processing machine that allows a user to interact)
Regarding claim 24; Claim 24 is similar in scope to claim 1, and is therefore rejected under similar rationale and furthermore the combination of Patange and Kozul discloses limitations:
querying a first trade block associated with the client from the blockchain (Patange, Para 0006, 0047: determining an entitlement usage of the amount of entitlement the enterprise has for the one or more software assets based on the telemetry data, updating the local blockchain based on the entitlement usage, updating the global decentralized blockchain based on the entitlement usage),
[wherein the first trade block comprises published software information corresponding to the software information]
querying a second trade block associated with the client from the blockchain (Patange, Para 0006, 0047: determining an entitlement usage of the amount of entitlement the enterprise has for the one or more software assets based on the telemetry data, updating the local blockchain based on the entitlement usage, updating the global decentralized blockchain based on the entitlement usage),
[wherein the second trade block comprises published hardware information corresponding to the hardware information; and authenticating whether the hardware information matches the published hardware information, wherein the hardware information is associated with the host]
Patange does not explicitly state but Kozul from the same or similar fields of endeavor teaches wherein the first trade block comprises published software information corresponding to the software information ( Kozul, Para 0017, 0027: token includes an identifier of at least one of a publisher of the software, a version number of the software, a purchase order associated with the license, and at least one maintenance date for the license....wherein Blockchain is used to manage an organization's software licenses. As software is assigned to users or machines, the primary distributed ledger may transfer the token to a “side chain” that is specific to the user or machine) and
wherein the second trade block comprises published hardware information corresponding to the hardware information (Kozul Abstract, Para 0007, 0015, 0093: generating a token for the license, wherein the token is associated with a software; writing the token to a license distributed ledger and electronic device and adding a second token for the license to an electronic wallet associated with the electronic device wherein the electronic wallet associated with the electronic device is maintained by a second distributed ledger wherein the combination of hardware and software used by the processing machine that allows a user to interact); and
authenticating whether the hardware information matches the published hardware information, wherein the hardware information is associated with the host (Para 0017, 0051, 0049, 0075: token comprises an identification associated with electronic device and software wherein the publisher keep the “ID” of the token as published hardware information specific to the device)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention wherein the first trade block comprises published software information corresponding to the software information and wherein the second trade block comprises published hardware information corresponding to the hardware information; and authenticating whether the hardware information matches the published hardware information, wherein the hardware information is associated with the host as taught by Kozul in the teachings of Patange for the advantage obtaining a license for the software; generating a token for the license, wherein the token comprises an identification of a license type and a software identifier; writing the token to a license distributed ledger/blockchain for software license management (Kozul, Abstract).
11. Claims 6, 8-9, and 19, 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Patange et al. (US 20230342435 A1, hereinafter, Patange) in view of Kozul et al. (US 20210056177 A1, hereinafter, Kozul), and further in view of Todasco et al. (US 20230186281 A1, hereinafter, Todasco).
Regarding claim 6, the combination of Patange and Kozul discloses the software authorization method according to claim 1, however, the combination does not explicitly state but Todasco from the same or similar fields of endeavor teaches wherein the blockchain information comprises a public key of the blockchain, a private key of the blockchain (Todasco Para 0146, 0151: blockchain address of sender 1330, includes an alphanumeric string of characters derived from the public key …asymmetric-key cryptography using a pair of keys, such as a public key and a private key. Additional factors may be considered) and an address of the blockchain (Todasco Para 0029: blockchain addresses).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention wherein the blockchain information comprises a public key of the blockchain, a private key of the blockchain and an address of the blockchain as taught by Todasco in the teachings of Patange and Kozul for the advantage of facilitating secured execution of blockchain transactions and restricting the first user from accessing the one or more digital assets (Todasco, Abstract).
Regarding claim 8, the combination of Patange and Kozul discloses the software authorization method according to claim 1, however, the combination does not explicitly state but Todasco from the same or similar fields of endeavor teaches wherein a consensus mechanism of the blockchain is a proof of authority (PoA) (Todasco Para 0162: a proof of work consensus model, a node validates a transaction, for example, by running a check or search through the current ledger stored in the blockchain. The node will create a new block for the blockchain that will include the data for one or more validated transactions).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention wherein a consensus mechanism of the blockchain is a proof of authority (PoA) as taught by Todasco in the teachings of Patange and Kozul for the advantage of facilitating secured execution of blockchain transactions and restricting the first user from accessing the one or more digital assets (Todasco, Abstract).
Regarding claim 9, the combination of Patange and Kozul discloses the software authorization method according to claim 1, however, the combination does not explicitly state but Todasco from the same or similar fields of endeavor teaches wherein a consensus mechanism of the blockchain is a proof of work (PoW) or a proof of stake (PoS) (Todasco, Para 0166: a blockchain network determines which of the full nodes 1005 publishes a next block to the blockchain. In a permissionless blockchain network, the nodes 1005 competes to determine which one publishes the next block. Various consensus models may be used, for example, a proof of work model, a proof of stake model, a delegated proof of stake model, a round robin model, proof of authority or proof of identity model, and proof of elapsed time model).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention wherein a consensus mechanism of the blockchain is a proof of work as taught by Todasco in the teachings of Patange and Kozul for the advantage of facilitating secured execution of blockchain transactions and restricting the first user from accessing the one or more digital assets (Todasco, Abstract).
Regarding claim 19; Claim 19 is similar in scope to claim 6, and is therefore rejected under similar rationale.
Regarding claim 21; Claim 21 is similar in scope to claim 8, and is therefore rejected under similar rationale.
Regarding claim 22; Claim 20 is similar in scope to claim 9, and is therefore rejected under similar rationale.
Examiner Notes
12. The Examiner notes that incorporating the combined limitations of claims 6, 7, and 9 into independent claim 1 would better clarify the subject matter/embodiment of claimed invention. Similarly, amending independent claim 10, 14, and 23-24 with aforesaid claim limitations from similar claims would help advance the prosecution as it would clarify the claimed invention.
Allowable Subject Matter
13. Claims 2-5, 11-13, 15-18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Reasons for Allowance
14. The following is an examiner’s statement of reasons for placing claims 2-5, 11-13, and 15-18 under allowable subject matters:
The limitation of dependent claims 2-5, 11-13, 15-18 are allowed and the corresponding dependent claims including respective and any intervening claims are not disclosed by the any of the prior art of record. For example, the limitations in claim 2 including the intervening claims recites “..checking whether the first trade block is successfully written into the blockchain; and sending a purchase success notice to the client in response to the first trade block being successfully written into the blockchain…transmitting the blockchain information to a host” which are not are not taught or fairly suggested by the prior art of record.
The allowable subject matters in above dependent claims are novel and non-obvious in scope over the prior art of record as the prior-art references fail to teach each and every features of the aforesaid dependent claim(s) including the limitations set forth above.
In view of the foregoing, the scope of claimed subject matters renders the invention patentably distinct as none of the prior art of record, either taken by itself or in any combination, would have anticipated or made obvious the invention of the present application at or before the time it was filed.
Furthermore, the Examiner performed updated search which does not yield other specific references that reasonably, either alone or in combination, would result a proper rejection of all the claimed features presented in each of the dependent claims 2-5, 11-13, 15-18 under 35 U.S.C 102 or 35 U.S.C.103 with proper motivation.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled "Comments on Statement of Reasons for Allowance."
Conclusion
15. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Crowley et al. (US 20230054904 A1) discloses A layered-infrastructure blockchain-based system for software license distribution includes a distributed cloud of blockchain full nodes. Each blockchain full node contains a blockchain data structure on which a complete set of license key transactions.
Jose (US 20190286794 A1) discloses method for using blockchain for flexible application licensing are presented. A licensing token, from a pool of licensing tokens, is provided using a transactional database based on blockchain protocols for using an application.
16. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHFUZUR RAHMAN whose telephone number is (571)270-7638. The examiner can normally be reached on Monday thru Friday.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached on 571-272-8878. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAHFUZUR RAHMAN/Primary Examiner, Art Unit 2498
Prosecution Insights