DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
This is a FINAL Office Action rejection prepared in response to Applicant’s amendments filed on
10/14/2025.
Claims 10-12 and 14-15 are amended.
Claims 1-15 are pending.
Claims 1-9 are withdrawn.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 10-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an
abstract idea without significantly more.
Step 1: Claims 10-14 are directed to a method (i.e., process). Claim 15 is directed to a system (i.e., blockchain network). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 10, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A method for verification of a hardware wallet use, comprising:
a hardware wallet initiating execution of a function of a protected smart contract deployed on blockchain and configured to provide the function for hardware wallets having required capabilities;
an attestation smart contract, which is a smart contract deployed on the blockchain configured to confirm that the hardware wallet has required capabilities, checking whether the hardware wallet is of a certified hardware wallet model having the required capabilities and, responsive to determining the hardware wallet is of a certified hardware wallet model having the required capabilities, providing an attestation confirmation; and
the protected smart contract executing the function for the hardware wallet responsive to the attestation smart contract providing the attestation confirmation.
Claim 10, recites (i.e., sets forth or describes) a verification method for authorizing the execution of a function, where in the verification depends on confirmation of specific capabilities associated with stored data. The claim achieves this by:
initiating execution of a function
checking whether specific required capabilities are within the stored data, if the specific required capabilities are within the stored data, providing a confirmation
executing the function if the confirmation is provided
Claim 15 is significantly similar to claim 10. As such claim 15 also recite an abstract idea. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of a hardware wallet, a protected smart contract and an attestation smart contract merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 11-14 have also been analyzed for subject matter eligibility. However, claims 11-14 also fail to recite patent eligible subject matter for the following reasons:
Claim 11 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the protected smart contract transmitting a request for an attestation confirmation to the attestation smart contract and
the attestation smart contract, in response to the request, checking whether the hardware wallet is of a certified hardware wallet model having the required capabilities and,
responsive to determining that the hardware wallet is of a certified hardware wallet model having the required capabilities, providing the attestation confirmation to the protected smart contract, wherein the protected smart contract executes the function for the hardware wallet responsive to it being provided by the attestation confirmation from the attestation smart contract.
The claim further recites the abstract idea of a verification method for authorizing the execution of a function and based on a confirmation received by checking stored capabilities. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)).
Claim 12 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the hardware wallet providing attestation information with a request for registration at the protected smart contract before initiating execution of the function, wherein
the attestation smart contract checks whether the hardware wallet is of a certified hardware wallet model having the required capabilities using the attestation information.
The claim further recites the abstract idea of a verification method for authorizing the execution of a function and based on a confirmation received by checking stored capabilities. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)).
Claim 13 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the attestation smart contract checks whether the hardware wallet is of a certified hardware wallet model having the required capabilities using the attestation information in response to the registration.
The claim further recites the abstract idea of a verification method for authorizing the execution of a function and based on a confirmation received by checking stored capabilities. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)).
Claim 14 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the protected smart contract stores, if responsive to the attestation smart contract providing the attestation confirmation, an indication that the hardware wallet has the required capabilities and executes the function for the hardware wallet responsive to it having stored an indication that the hardware wallet has the required capabilities.
The claim further recites the abstract idea of a verification method for authorizing the execution of a function and based on a confirmation received by checking stored capabilities. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)).
Claim Rejections - 35 USC § 103
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.
Claims 10-15 are rejected under 35 U.S.C. 103 as being unpatentable over Parthipan (US 2024/0346127 A1) in view of Prasad (US 11392947 B1), and further in view of Smith (US 2019/0349426 A1) .
Regarding claims 10 and 15, Parthipan discloses:
A method for verification of hardware wallet use, comprising: (Parthipan abstract, A trusted attestation method and a communication apparatus are provided. Parthipan ¶0077, In embodiments of this application, an operation performed by the "node" may be performed by a device, may be performed by a component (for example, a processor, a chip, or a chip system) of the device, or may be performed by a software module or unit that integrates a logical function. The node may be a server, a personal computer (PC), a network device or a terminal device in a communication network, or any device having a computing and storage capability. The node may alternatively be a processor, a chip, or a functional module in the foregoing enumerated devices.)
an attestation smart contract, which is a smart contract deployed on the blockchain configured to confirm that the hardware wallet has required capabilities, (Parthipan ¶0010, The smart contract is deployed on a blockchain node on the first blockchain. Parthipan ¶0119, The remote attestation smart contract is referred to as a smart contract for short, and may include the first smart contract and the second smart contract. Parthipan ¶0120, FIG. 6 shows a structure of the remote attestation smart contract. The structure of the smart contract may include a plurality of pieces of data (data). The plurality of pieces of data may be, for example, the following pieces of data: an owner (owner), an evidence writer (evidence writer), an evidence reader (evidence reader), a device controller (device controller), a device (device), and a storage unit. Each piece of data may include public key information and account information corresponding to a device.)
the protected smart contract executing the function for the hardware wallet responsive to the attestation smart contract providing the attestation confirmation. (Parthipan ¶0219, For example, the second smart contract verifies a signature, to attest that the signature is from a legitimate trusted platform module (TPM). The second smart contract may also verify a quote and log attestation to attest that the attestation information is not tampered with, further verify a timestamp to attest generation time of the attestation information, and finally verify trustworthiness of the attestation information by using a reference value (reference value). Parthipan ¶0220, S2007: The second smart contract returns, to the second node, the attestation information about the first node or an attestation result indicating whether the first node is trusted.)
Parthipan does not disclose, however Prasad teaches:
a hardware wallet initiating execution of a function of a protected smart contract deployed on blockchain and configured to provide the function for hardware wallets having required capabilities; (Prasad abstract, Techniques are described for managing devices, such as Internet of Things (IoT) devices, using smart contract(s) on a distributed ledger ( e.g., blockchain). Prasad Col 17 lines 9-20, FIG. 10 illustrates the decentralized identity management system 700 for device management, in accordance with embodiments described herein. As described herein, in certain embodiments the smart contract(s) 710 may manage outgoing communications sent from the IoT device(s) 704, in addition to or instead of managing incoming commands or other access to the IoT device(s) 704. As illustrated in the example of FIG. 10, an IoT device 704 may attempt to send a communication 1002 to an external service 1004. In certain embodiments, the communication 1002 may be an attempted transaction, such as a purchase transaction or a request that payment be sent to some external entity.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the features of Parthipan with Prasad’s teaching. One of ordinary skills in the art would have been motivated to combine these features in order to enhance security and trust of the execution process by ensuring that only devices with the required capabilities are able to perform the functions.
The combination does not disclose, however Smith teaches:
checking whether the hardware wallet is of a certified hardware wallet model having the required capabilities and, responsive to determining the hardware wallet is of a certified hardware wallet model having the required capabilities, providing an attestation confirmation; (Smith ¶0378, A second method, as described with respect to the ladder diagram of FIG. 13, may use attestation to validate the integrity, credentials, or identity of the device. As used herein, attestation is a secure method for disclosing the trust properties of a device or platform, in which the device or platform self-reports the trust properties. The trust properties may include the platform manufacturer, certifications achieved by the vendor that reflect security hardening, such as FIPS140-2 for crypto module implementation. Further, ISO9000 may be relevant, as well as vendor processes followed to ensure quality. Attestation typically reveals the hardware, firmware and software versions and patch levels. It may reveal information about keys that are protected by the hardened environment, such as a trusted execute environment (TEE), and information about key types. ¶1126, The smart contract 15708 may support device attestation features and decide whether or not to accept a particular device in the smart contract 15708. The contents of the commissioning transaction may be used to determine acceptance. The join contract function 15710 may enforce policies on a device before it is allowed to join the smart contract 15708. For example, the join contract function 15710 may require that the device encrypts its hard disk, or storage, using a specified minimum standard before joining. The join contract function 15710 may require other features or extra interactions with the device to prepare it before accepting it into the smart contract 15708. ¶1130, The smart contract 15708 can issue tokens 15718 to devices during the commissioning process, or at any time thereafter. The tokens may have a number of abstract meanings and may be issued for different purposes. For example, if a device meets criteria set within the smart contract 15708, for example, having a certain level of encryption capabilities, then it may be issued a special type of trust token. ¶0133, In the case of attributes for machines, these machine attributes may be attested by technical methods, including trusted sensing or hardware root of trust (HWROT). In response to this attestation, a list of the participating entities may be maintained in the permissions guide and the entities may now request tokens from the permissions guide. ¶1142, At block 15820, the device may request tokens for functioning under the smart contract. The tokens may be presented by the device to owners of services when trying to access, or offer, services, or resources, once the device is fully operational. The criteria for the issuing of tokens may take features such as attribute attestation into account. At block 15822, if a particular attribute is attested, a higher value token may be assigned to the device at block 15824. If not, a lower value token may be assigned, for example at block 15826. Multiple token types and token volumes may be assigned to the device. However, this is at the discretion of the smart contract owner, when they are designing the smart contract. Some tokens may be consumable, for example, when they are presented to a process, service, or system owner during device operation, they are consumed in a pay-per-use model in which the tokens are transferred from the device's wallet to the owner's wallet. Other tokens may be perpetual, for example, they may be presented merely to verify that the device is a member of a particular smart contract, a group of devices, or to attest to the device possessing specific attributes, capabilities, or features. )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the features of Parthipan and Prasad with Smith’s teaching. One of ordinary skills in the art would have been motivated to combine these features in order to enhance security and trust of the execution process by ensuring that only devices with the required capabilities are able to perform the functions.
Further, the claimed limitation “configured to…” in “configured to provide the function for hardware wallets having required capabilities” and “configured to confirm that the hardware wallet has required capabilities” consists of language disclosing an intended use, 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.
Furthermore, in regards to the method claim 10, the claimed limitation “responsive to determining the hardware wallet is of a certified hardware wallet model having the required capabilities, providing an attestation confirmation” and “the protected smart contract executing the function for the hardware wallet responsive to the attestation smart contract provides providing the attestation confirmation” are conditional limitations which means that the claim limitations are only required when the stated conditions are met.
Finally, the claimed limitation “which is a smart contract deployed on the blockchain” only describes characteristics of the smart contract which is non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Regarding claim 11, Parthipan, Prasad and Smith disclose each and every element of claim 10.
Parthipan further discloses:
the smart contract transmitting a request for an attestation confirmation to the attestation smart contract and (Parthipan ¶0214, S2002: The second node requests the second smart contract to evaluate whether a target device (that is, the first node) is trusted, or the second node requests attestation information about the target device to the second smart contract. ¶0215, S2003: The second smart contract sends a request to the first smart contract, to request the attestation information about the first node.)
the attestation smart contract, in response to the request, checking whether the hardware wallet is of a certified hardware wallet model having the required capabilities and, responsive to determining the hardware wallet is of a certified hardware wallet model having the required capabilities providing an attestation confirmation to the smart contract, wherein the smart contract executes the function for the hardware wallet if it is provided by the attestation confirmation from the attestation smart contract. (Parthipan ¶0216, After receiving the attestation information, the first smart contract may first verify the attestation information and store the attestation information in the first blockchain.) ¶0217, S2005: The first smart contract sends the attestation information to the second smart contract. Parthipan ¶0219, For example, the second smart contract verifies a signature, to attest that the signature is from a legitimate trusted platform module (TPM). The second smart contract may also verify a quote and log attestation to attest that the attestation information is not tampered with, further verify a timestamp to attest generation time of the attestation information, and finally verify trustworthiness of the attestation information by using a reference value (reference value). Parthipan ¶0220, 2007: The second smart contract returns, to the second node, the attestation information about the first node or an attestation result indicating whether the first node is trusted.)
Furthermore, in regards to the method claim 10, the claimed limitation “responsive to determining the hardware wallet is of a certified hardware wallet model having the required capabilities providing an attestation confirmation to the smart contract” is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
Regarding claim 12, Parthipan, Prasad and Smith disclose each and every element of claim 10. Smith further teaches:
the hardware wallet providing attestation information with a request for registration at the protected smart contract before initiating execution of the function, wherein (Smith ¶1124, The block 15702 represents, for example, when a device boots. This may occur after the device is powered or may occur after the device has been rebooted. As described with respect to block 15502 of FIG. 155, the device would boot and run code in a secure enclave, such as a TEE. Smith ¶1125, At block 15704, the device may generate a key to be used as a blockchain client. This may be performed, for example, as described with respect to block 14206 of FIG. 142. Smith ¶1126, At block 15706, the device may interact with a smart contract 15708 on the blockchain, for example, by creating a commissioning transaction. A join contract function 15710 may be performed when a new device first interacts with the smart contract 15708. The smart contract 15708 may support device attestation features and decide whether or not to accept a particular device in the smart contract 15708. The contents of the commissioning transaction may be used to determine acceptance. The join contract function 15710 may enforce policies on a device before it is allowed to join the smart contract 15708. For example, the join contract function 15710 may require that the device encrypts its hard disk, or storage, using a specified minimum standard before joining. The join contract function 15710 may require other features or extra interactions with the device to prepare it before accepting it into the smart contract 15708. Smith ¶1128, If the device is allowed to join the smart contract 15708, it is added to a list of created devices 15714, for example, in the blockchain.)
the attestation smart contract checks whether the hardware wallet is of a certified hardware wallet model having the required capabilities using the attestation information. (Smith ¶1130, The smart contract 15708 can issue tokens 15718 to devices during the commissioning process, or at any time thereafter. The tokens may have a number of abstract meanings and may be issued for different purposes. For example, if a device meets criteria set within the smart contract 15708, for example, having a certain level of encryption capabilities, then it may be issued a special type of trust token.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the features of Parthipan, Prasad and Smith with Smith’s additional teaching. One of ordinary skills in the art would have been motivated to combine these features in order to ensure that only authorize devices that meet the capability requirements are allow to register and subsequently trigger the functions of the smart contract which enhances trust and security within the system.
Regarding claim 13, Parthipan, Prasad and Smith disclose each and every element of claim 12.
Smith further teaches:
the attestation smart contract checks whether the hardware wallet is of a certified hardware wallet model having the required capabilities using the attestation information in response to the registration. (Smith ¶1130, The smart contract 15708 can issue tokens 15718 to devices during the commissioning process, or at any time thereafter. The tokens may have a number of abstract meanings and may be issued for different purposes. For example, if a device meets criteria set within the smart contract 15708, for example, having a certain level of encryption capabilities, then it may be issued a special type of trust token.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the features of Parthipan, Prasad and Smith with Smith’s additional teaching. One of ordinary skills in the art would have been motivated to combine these features in order to enhance security and trust of the execution process by ensuring that only devices with the required capabilities are able to perform the functions.
Regarding claim 14, Parthipan, Prasad and Smith disclose each and every element of claim 13.
Parthipan further discloses:
the protected smart contract stores, responsive to the attestation smart contract providing the attestation confirmation, an indication that the hardware wallet has the required capabilities and executes the function for the hardware wallet responsive to it having stored an indication that the hardware wallet has the required capabilities. (Parthipan ¶0008, The attestation information of each time or digest information about the attestation information is stored in the first blockchain, which ensures that content of the attestation information is correct and is tamper-proof. The attestation information is determined based on the information about the first blockchain, and the information about the first blockchain is traceable. Therefore, the attestation information of each time is historical and traceable. Parthipan ¶0216, After receiving the attestation information, the first smart contract may first verify the attestation information and store the attestation information in the first blockchain.)
Furthermore, in regards to the method claim 10, the claimed limitation “if the attestation smart contract provides the attestation confirmation, an indication that the hardware wallet has the required capabilities and executes the function for the hardware wallet if it has stored an indication that the hardware wallet has the required capabilities” is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
Response to Arguments
Claim Objections
Claim objections in the previous non-final action dated 07/18/2025 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 112
Claim rejection 35 U.S.C. § 112 in the previous non-final action dated 07/18/2025 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 101
The applicant presents several assertions, i.e., “the Office Action's analysis improperly isolates each of the functions/operations recited in the claims, declaring them to be "abstract ideas," and then concludes, without any substantial analysis, that the remaining portions of the claim "merely serve as a tool to perform the abstract idea," which the Office Action characterized as nothing more than "organizing human activity."”, “the claim, when properly considered as a whole, is directed to specifics of how to allocate and perform operations, among these components, to carry out a specific task that directly relates to the hardware capabilities of the hardware wallet.” and “the Office Action's assertion that these claims are directed to "organizing human activity" is clearly incorrect. These claims having nothing to do with "managing personal behavior or relationships or interactions between people.”. The basis of these assertions are based on the applicant’s argument on pages 7-9.
Regarding the applicant’s argument that “the Office Action's analysis improperly isolates each of the functions/operations recited in the claims, declaring them to be "abstract ideas," and then concludes, without any substantial analysis, that the remaining portions of the claim "merely serve as a tool to perform the abstract idea," which the Office Action characterized as nothing more than "organizing human activity."”, the examiner respectfully disagrees. The applicant is attempting to conflate the Step 2A, 1st prong, test, with Step 2A, 2nd prong test. As per MPEP 2106.04(a), in step 2A prong one to determine whether a claim recites an abstract idea, the specific limitations in the claim under examination must be identified and analyzed to determine whether they fall within at least one of the recognize groupings of abstract ideas. If one of the limitations in the examined claim falls within one of the groups, it is reasonable to conclude that the claims recite an abstract idea and the examination continues to step 2A prong two. As shown in the 101 section above the claim recites a verification method for authorizing the execution of a function, where in the verification depends on confirmation of specific capabilities associated with stored data. This is analogous to a verification process where a user checks whether a participant meets specific criteria/requirements for allowing an action, if the criteria/requirements are met, then provides confirmation and allows the action to be performed. As such the claim recites an abstract idea in the group of managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
Regarding the applicant’s assertion that “the claim, when properly considered as a whole, is directed to specifics of how to allocate and perform operations, among these components, to carry out a specific task that directly relates to the hardware capabilities of the hardware wallet.”, examiner also disagrees. Even when considered as a whole, the claim merely implements managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) as described above. The examiner finds that a verification method for authorizing the execution of a function, where in the verification depends on confirmation of specific capabilities associated with stored data does not provide any specific improvement to the functioning of the blockchain network, the hardware wallet or any other technology. The claimed “specifics of how to allocate and perform operations, among these components, to carry out a specific task” do not constitute an improvement to the underlining technology. Instead, it represents the organization and execution of operations that rely on generic computing elements. Further, the hardware wallet, the attestation smart contract and the protected smart contract are merely used to apply the abstract idea. Therefore, the claim does not recite any technological advancement or inventive integration beyond applying these tools to an abstract concept and thus fail to impose any meaningful limit that would transform the abstract idea into a practical application under the second prong of step 2A of the subject matter eligibility framework.
Regarding, the applicant’s assertion that “the Office Action's assertion that these claims are directed to "organizing human activity" is clearly incorrect. These claims having nothing to do with "managing personal behavior or relationships or interactions between people”, the examiner respectfully disagrees. While the claims do not involve interaction between people, the claim still falls under managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) group of abstract ideas because it establishes rules and conditions that govern how an object is allow to act within a system depending if certain conditions are met.
As such, the amended claims fail to meet the eligibility requirements under 35 U.S.C. § 101. The rejection is therefore maintained.
Claim Rejections – 35 U.S.C. § 103
Applicant presents several arguments in regard to 103 rejection on the previous non-final action dated 07/18/2025 which have been considered and addressed below:
First, applicant argues that “the Office Action has not established that the relied upon subject matter in Parthipan is prior art at all” because Parthipan was filed on 06/21/2024 and claims priority to a foreign application which is in Chinese. According to the applicant “the office has not provided a translation of this priority document, and has not identified where the relied-upon subject matter from Parthipan can be found in this Chinese priority document” which make the rejection incomplete and requests the rejections to be removed or replaced with new rejections. The examiner respectfully disagrees with the applicant’s argument above. The examiner notes that there is no authority requiring the examiner to provide a translation of a foreign priority document nor to identify where the relied-upon subject matter can be found in the prior art. Accordingly, the foreign priority date of the cited prior art can be relied upon for the purpose of establishing effective date of the prior art. As courtesy, the examiner has attached to this office action a machine translated copy of the Chinese document in question.
Second, applicant argues that “Parthipan does not disclose or suggest a hardware wallet at all” The examiner respectfully disagrees. Although, Parthipan does not explicitly teach or disclose a “hardware wallet”, Parthipan clearly teaches a variety of devices including “a processor, a chip or a chip system” or “software module or unit that integrates a logical function” ¶0077. Under the broadest reasonable interpretation standards, this definition encompasses hardware wallets and similar devices which typically contain processors or chips and execute software modules to perform cryptographic operations. The prior art does not need to explicitly identify the device as a hardware wallet to meet the claimed limitation.
Third, applicant further argues that the office failed to disclose a “hardware wallet” on the secondary reference of Prasad, however the examiner respectfully disagrees. Although, there is no need for Prasad to disclose or at least suggest a hardware wallet as this was already disclosed by Parthipan, Prasad also suggest a hardware wallet. Under BRI, Prasad is not just limited to IoT devices but instead it encompasses any hardware device capable of performing cryptographic operations (i.e., a hardware wallet).
Fourth, applicant argues that “the cited portions of Prasad fail to say anything at all about a smart contract configured to provide a certain function for hardware wallets having required capabilities.” The examiner finds this not persuasive and also disagrees. The limitation “configured to…” consists of language disclosing an intended use, so it is considered but given no patentable weight per MPEP 2111.05, 2114. Therefore, the combination of Parthipan with Prasad is still considered obvious to one in the ordinary skill in the art because Prasad teaches a device initiating execution of a function of a smart contract and Parthipan teaches an attestation smart contract performing an attestation necessary for the smart contract to complete the execution of the function.
Further, the applicant argues that the limitation “providing an attestation confirmation," which was previously ignored because the limitation "is a conditional limitation." should now be considered in view of the amended limitation. Examiner respectfully disagree. The amended limitation “responsive to determining the hardware wallet is of a certified hardware wallet model having the required capabilities, providing an attestation confirmation” still recites a conditional limitation. The term “responsive to” defines an action that occurs only if a particular condition is met. Here, “responsive to” signals that “providing an attestation confirmation” occurs only when “it is determined that the hardware wallet is of a certified hardware wallet model having the required capabilities”. Therefore, the examiner maintains the same position as in the non-final rejection.
Finally, the applicant argues that “the Office Action is equating Parthipan's second node to the "protected smart contract" of claim 11, which is a "smart contract deployed on the blockchain."” and “The Office Action does not provide any basis for its implicit conclusion that Parthipan's second node is a smart contract.”” The examiner has carefully reviewed this argument and agrees. In response, the examiner has updated the rejection to include “¶0215, S2003: The second smart contract sends a request to the first smart contract, to request the attestation information about the first node.” which recites a second smart contract (protected smart contract) requesting attestation information to a first smart contract (attestation smart contract).
In view of the prior arguments and analysis, it is respectfully submitted that the claims, as currently amended, remain rejected under the applied prior art combination.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2016/0275461 A1 to Sprague et al. discloses: Systems and methods are disclosed that provide for a full validation of an unknown client device prior to acceptance of a block chain transaction would provide further security for block chain transactions. The health of the device can be attested to prior to engaging in electronic transactions. In some embodiments, automation of full device integrity verification is provided as part of a block chain transaction. Certain aspects of the invention enable trust in devices. Some embodiments operate on the fundamental premise that a reliable relationship with a device can make for a much safer, easier and stronger relationship with an end user. Achieving this requires knowing with confidence that a device involved in a current transaction is the same device it was in previous transactions.
US 2019/0065733 A1 to Forehand discloses: A distributed ledger is used by one or more parties executing a ledger node to document a lifecycle of a device. When devices are manufactured, shipped, and used, attestation transactions are recorded to the distributed ledger that identify the devices and include attestation information about the device. The distributed ledger further supports command transactions that are used to change the behavior of the device, such as unlocking capabilities on the device. The distributed ledger provides a history of device attestation and activation.
US 20180069836 A1 to Mandyam discloses: A method operational at a gateway device is provided to facilitate attestation of client devices by an attestation recipient device. The gateway device may obtain attestation metadata from a metadata service. It may then receive a transaction request from a client device. The client device attestation information may be verified by the gateway device against the obtained attestation metadata. The gateway device may then generate a gateway device attestation information and sends the transaction request to a recipient device along with the gateway device attestation information. The gateway device attestation information serves to at least partially vouch for the client device. The gateway may then receive a confirmation for the transaction request and forwards the confirmation for the transaction request to the client device.
US 2020/0067708 A1 to Subba discloses: A mechanism for registering a device with an Internet of Things (IoT) edge network is disclosed. The manufacturer of the device stores credentials of the device in a secure storage of the device. The manufacturer also stores the credentials on a public blockchain with sensitive parameters hashed or encrypted. A certifying node accesses the credentials from the public blockchain to establish a secure connection with the device and to verify its credentials. The device sends the credentials to the certifying node, only if the certifying node is able to decrypt a device access parameter from the public blockchain. Upon verifying the credentials of the device, the certifying node issues a digital certificate to the new device and it is stored on a permissioned blockchain within the IoT network. Other nodes in the IoT network may use the digital certificate on the permissioned blockchain for secure communication with the device.
US 20210006416 A1 to Scarlata et al. discloses: NOVELTY - The computer readable storage medium includes instructions for obtaining signed data from a first remote device by a front end service. The software of the first remote device is conformed as authentic based on the signed data. A credential is generated to enable communication between the first remote device and a second remote device. The front end service is caused to transmit the credential to the first remote device. The processors are caused to cause the front end service to transmit the credential to the second remote device. The signed data is attested to an authenticity of the software of the first remote device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698