CTFR 18/765,439 CTFR 101449 DETAILED ACTION Information Disclosure Statement The information disclosure statement (IDS) submitted on February 26, 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Response to Amendment The Amendment filed February 9, 2026 has been entered. Claims 1-20 remain pending in the application. Regarding the Objections to the Claims previously set forth in the Non-Final Office Action mailed November 28, 2025, Applicant’s amendments obviate the objections to claims 10, 13, and 17. Accordingly, the objections are withdrawn. Regarding the rejection of claims 9 and 13-16 under 35 U.S.C. 112(b), Applicant’s amendments obviate the rejections. Accordingly, the objections are withdrawn. Regarding the rejection of claim 12 under 35 U.S.C. 102, Applicant’s amendments to the Claims have modified the scope of the claims and warrant new grounds for rejection under 35 U.S.C. 103 as set forth below. Accordingly, the rejection under §102 is withdrawn. Regarding the rejection of claims 1-11 and 13-20 under 35 U.S.C. 103, Applicant’s amendments to the Claims have modified the scope of the claims and warrant new grounds for rejection as set forth below. Response to Arguments Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Regarding the §103 rejection of Claim 16, Applicant submits that US 20240250825 (Takeuchi) in view of US 20210232688 (Luciani) does not disclose “applying an algorithm to platform configuration register values to determine an observed verification value” (Remarks, p. 11, “§103 rejection of claim 16”). In response to Applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller , 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Examiner relies upon Takeuchi to disclose applying an algorithm to some values, and upon Luciani to disclose those values being platform configuration register values. The Examiner finds the Applicant's argument to be non-persuasive, and hereby maintains the format of the original rejection over Takeuchi in view of Luciani, amended to address the mention of “measurement hashes”. Examiner notes that the added mention of “measurement hashes” to claims 1, 12, and 16 is present in US 20210232688 (Luciani) as previously made of record. Please refer to the new grounds of rejection as cited below with respect to Luciani disclosing “measurement hashes”. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-103 AIA The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. 07-21-aia AIA Claim s 1-7, 9, 11, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US 20240250825 by Takeuchi et al. (hereinafter “Takeuchi”) in view of US 20210232688 by Luciani et al. (hereinafter “Luciani”) . Regarding claim 1, Takeuchi discloses: A method, comprising: accessing, by a verification engine (Takeuchi Fig. 1, 22) from a managed node separate from the verification engine (Takeuchi Fig. 1, 16, 18, 20) a plurality of integrity measurements (Takeuchi Fig. 3, S101) generated by the managed node responsive to the managed node changing power states (Takeuchi [0062]: “At the time of startup (activation) of various programs, secure boot for each program is executed as necessary.”) ; detecting, by the verification engine, whether the managed node has unexpectedly changed, wherein detecting whether the managed node has unexpectedly changed comprises: identifying, by the verification engine, an algorithm corresponding to the managed node (Takeuchi Fig. 3, S102 “hash function”) ; applying, by the verification engine, the algorithm to the plurality of integrity measurements to generate an observed verification value for the managed node (Takeuchi Fig. 3, S102) ; comparing, by the verification engine, the observed verification value with an expected verification value (Takeuchi Fig. 3, S104; see also Takeuchi [0064]) for the managed node; and detecting that the managed node has unexpectedly changed (Takeuchi [0052]: “In the case where the calculated hash value (for example, “ddd”) of monitored unit 16 and the expected hash value “aaa” of monitored unit 16 do not match, controller 30 determines that monitored unit 16 is anomalous (for example, the program has been tampered with)”.) . Takeuchi does not disclose that the integrity data are hashes of integrity measurements. Takeuchi also does not disclose taking a particular responsive action upon detecting a change. However, Luciani discloses using integrity measurement hashes to verify the integrity of a managed node: “PCRs are updated by hashing their previous value with the information to store. In the measured boot case, PCRs are used to store firmware and software integrity value. Using PCRs prevents removal of firmware or software execution events.” Luciani [0013]. Luciani also discloses initiating a responsive action in response to detecting that the managed node has unexpectedly changed (Luciani [0042]: “In another example… the endorsement information is not validated and an action can be performed. In one example, the event can be logged. In another example, a message can be sent to an administrator. In a further example, the management controller 110 can prevent boot of the computing system 100, 200”). Takeuchi and Luciani are art analogous to the claimed invention because all are directed to the field of endeavor of verifying the integrity of remote computer systems. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to use measurement hashes and initiate a responsive action as taught by Luciani in order to “prevent[] removal of firmware or software execution events” (Luciani [0013]) and “ensure that a security co-processor that is installed at manufacturing is the security co-processor that is used during boot of the computing device” (Luciani [0014]). Regarding claim 2, Takeuchi in view of Luciani discloses: The method of claim 1, The method of claim 1, wherein the plurality of integrity measurement hashes comprises platform configuration register (PCR) values (Luciani [0013]: “In the measured boot case, PCRs are used to store firmware and software integrity value”) . Regarding claim 3, Takeuchi in view of Luciani discloses: The method of claim 1, further comprising determining, by the verification engine, the expected verification value, wherein determining the expected verification value comprises: determining an expected inventory (Takeuchi [0055]: “When information processing device 2 is activated for the first time, the possibility that each of the plurality of monitored units 16, 18, and 20 has been tampered with by an unauthorized program is very low…”, where the expected inventory is the untampered unit contents) for the managed node; determining inputs corresponding to the expected inventory (Takeuchi [0055]: “…controller 30 calculates the hash value… of monitored unit 16 based on the data related to monitored unit 16 read by reader 26…” where the inputs are the “data related to monitored unit 16”) ; and applying the algorithm to the inputs (Takeuchi [0055]: “…controller 30 calculates the hash value…”) to determine the expected verification value (Id. “hash value”). Regarding claim 4, Takeuchi in view of Luciani discloses: The method of claim 3, wherein: determining the expected inventory comprises determining an expected firmware image for the managed node (Luciani [0024]: “In some examples the management controller 110 can be used to ensure that firmware of the computing system 100, 200 is secure… Further, in some examples, the management controller… can stop the computing system…from booting the compromised firmware” where the uncompromised firmware is the expected inventory) ; and determining the inputs comprise determining a hash value based on the expected firmware image (Luciani [0044]: “Various approaches can be used for validating the component, for example, keeping a hash of an expected firmware image, partial image…”) . Regarding claim 5, Takeuchi in view of Luciani discloses: The method of claim 3, wherein: determining the expected inventory comprises determining an expected firmware application or driver (Luciani [0024]: “In some examples the management controller 110 can be used to ensure that firmware of the computing system 100, 200 is secure… Further, in some examples, the management controller… can stop the computing system…from booting the compromised firmware” where the uncompromised firmware is the expected inventory) for the managed node; and determining the expected inventory comprises determining a hash value based on the expected firmware image (Luciani [0044]: “Various approaches can be used for validating the component, for example, keeping a hash of an expected firmware image, partial image…”) . Regarding claim 6, Takeuchi in view of Luciani discloses: The method of claim 3, wherein: determining the expected inventory comprises determining an expected firmware image of a peripheral for the managed node (Luciani [0071]: “The other components [being verified] can include a memory (e.g., a read only memory including the platform firmware)…” Examiner notes that Luciani also considers peripherals to be part of the computing system 100, 200. Luciani [0020]: “Further, the platform firmware may be capable to initialize various components of the computing system 100, 200 such as peripherals)”) for the managed node; and determining the expected inventory comprises determining a hash value based on the expected firmware image (Luciani [0044]: “Various approaches can be used for validating the component, for example, keeping a hash of an expected firmware image, partial image…”) . Regarding claim 7, Takeuchi in view of Luciani discloses: The method of claim 3, wherein: determining the expected inventory comprises determining an expected configuration for the managed node (Takeuchi [0055]: “When information processing device 2 is activated for the first time, the possibility that each of the plurality of monitored units 16, 18, and 20 has been tampered with by an unauthorized program is very low. Accordingly, when information processing device 2 is activated for the first time, reader 26 reads the data related to monitored unit 16 from the memory in monitored unit 16”) for the managed node; and determining the expected inventory comprises determining a hash value based on the expected firmware image (Luciani [0044]: “Various approaches can be used for validating the component, for example, keeping a hash of an expected firmware image, partial image…”; (Takeuchi [0055]: “…controller 30 calculates the hash value…”) . Regarding claim 9, Takeuchi in view of Luciani discloses: The method of claim 1, further comprising determining, by the verification engine, the expected value, wherein determining the expected verification value comprises: determining an expected value for the managed node (Takeuchi Fig. 3, S103) ; determining expected platform configuration register contents (Luciani [0013]) for the managed node based on the expected inventory (Takeuchi [0052]) ; and applying the algorithm to the contents to determine the expected verification value (Takeuchi Fig. 3, S102) . Regarding claim 11, Takeuchi in view of Luciani discloses: The method of claim 1, wherein initiating the responsive action comprises at least one of causing the managed node to be powered down, imposing a credential to be provided before the managed node can be rebooted, causing an alert to be provided to an administrative dashboard, causing an alert to be sent to a system administrator (Luciani [0042]: “In another example… the endorsement information is not validated and an action can be performed. In one example, the event can be logged. In another example, a message can be sent to an administrator. In a further example, the management controller 110 can prevent boot of the computing system 100, 200”) , causing an alert to be sent to a remote management server, causing the managed node to be quarantined from a network, or causing operations of the managed node associated with an external entity to be quiesced . Regarding claim 16, Takeuchi discloses: A system associated with a management service (Takeuchi Fig. 2, 22) , the system comprising: a repository to a data store associating managed nodes managed by the management service with respective algorithms and associating the managed nodes with respective expected verification values (Takeuchi Fig. 2, 28) ; a hardware processor (Takeuchi Fig. 2, 30) ; and a memory to store instructions that, when executed by the hardware processor, cause the hardware processor to: receive, from a given managed node of the managed nodes (Takeuchi Fig. 2, 16 20) , a collection of values corresponding to integrity measurement-related values made by a firmware-based measuring agent of the given managed node (Takeuchi Fig. 2, 16 20) ; responsive to the data, apply an algorithm (Takeuchi Fig. 3, S102 “hash function”) of the algorithms associated with the given managed node to the measurement-related values to determine an observed verification value (Takeuchi Fig. 3, S102 “hash function”) ; and selectively initiate a responsive action responsive to a comparison of the observed verification value with an expected verification value for the given managed node (Takeuchi Fig. 3, S113) . Takeuchi does not specify what the measurement-related values are. However, Luciani discloses using platform configuration register values corresponding to integrity measurement hashes for remote attestation (Luciani [0013]: “PCRs are updated by hashing their previous value with the information to store… In the measured boot case, PCRs are used to store firmware and software integrity value.” See also Luciani [0023]: “The TPM may be utilized for services on the computing system. The services may include device identification, authentication, encryption, measurement, determine device integrity, secure generation of cryptographic keys, remote attestation, and sealed storage. The TPM may include platform configuration registers (PCRs).”) Takeuchi and Luciani are art analogous to the claimed invention because all are directed to the field of endeavor of verifying the integrity of remote computer systems. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to use measurement hashes and initiate a responsive action as taught by Luciani in order to “prevent[] removal of firmware or software execution events” (Luciani [0013]) and “ensure that a security co-processor that is installed at manufacturing is the security co-processor that is used during boot of the computing device” (Luciani [0014]). Regarding claim 18, Takeuchi in view of Luciani discloses: The system of claim 16, wherein the hardware processor to further, communicate with a baseboard management controller (Luciani [0017]: “In some examples, the management controller 110 can be used to implement services for the computing system 100, 200… Management controllers such as baseboard management controllers (BMCs)…”) of the given managed node. Takeuchi in view of Luciani is silent as to whether baseboard management controller receive[s] the collection of platform configuration values . However, Luciani Fig. 1 shows management controller 110 operatively coupled via multiplexor 120 to the security co-processor 130, which may be a Trusted Platform Module (TPM, Luciani [0011]: “In some examples, the security co-processor (e.g., a TPM)…”). It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to receive the collection of platform configuration values through the BMC because such controllers “provide so-called “lights-out” functionality for computing devices. The lights out functionality may allow a user, such as a systems administrator, to perform management operations on the computing system 100, 200 even if an operating system is not installed or not functional on the computing device.” Luciani [0017] . 07-22-aia AIA Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Takeuchi in view of Luciani as applied to claim s 1 and 3 above, and further in view of US 11374745 to Khare et al. (hereinafter “Khare”) . Regarding claim 8, Takeuchi in view of Luciani discloses the method of claim 3. Takeuchi also discloses verifying application on boot (Takeuchi [0062]: “At the time of startup (activation) of various programs, secure boot for each program is executed as necessary.”) Neither Takeuchi nor Luciani disclose the inventory being a secure boot policy. However, Khare discloses: determining the expected inventory comprises determining an expected secure boot policy for the managed node (Khare 5:54 60: “In some embodiments, following the secure boot process, the key 148 may be sealed via contents of the PCR 120, so that the key can only be unsealed if the contents of the PCRs 120 reflect a set of expected boot sequence states of the hardware”, where the secure boot policy corresponds to the set of expected boot sequence states) ; and determining the inputs comprises determining a hash value based on the expected secure boot policy (Luciani [0044]: “Various approaches can be used for validating the component, for example, keeping a hash of an expected firmware image, partial image…”; (Takeuchi [0055]: “…controller 30 calculates the hash value…”) . Khare is art analogous to the claimed invention because both are directed to the field of endeavor of protecting computer systems. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to modify Takeuchi in view of Luciani’s invention to use an inventory comprising the boot sequence as taught by Khare in order to ensure the boot sequence was not modified (Takeuchi [0003]: “As security measures for firmware… integrity verification (secure boot) at the time of firmware startup… is desired.”) 07-22-aia AIA Claim s 10, 17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Takeuchi in view of Luciani as applied to claim 1 above, and further in view of CN 116032970 to Wang et al. (hereinafter “Wang”) . Regarding claim 10, Takeuchi in view of Luciani discloses the method of claim 1 . Takeuchi in view of Luciani does not disclose the remainder of the claim. However, Wang discloses: responsive to an inventory of the managed node change (Wang p. 6, 2 paragraphs under “Example 2”: “When the boot_option=1, as shown in fig. 3…”) replacing the algorithm (Wang p. 6, paragraph beginning “Specifically, as shown in fig. 4…”: “a first encryption algorithm”) corresponding to the managed node with a replacement algorithm (Wang p. 6, paragraph beginning “Further, as shown in fig. 5…”: “a second encryption algorithm M2”) and applying a second verification value based on the replacement algorithm (Wang p. 6, paragraph beginning “Further, as shown in fig. 5…”: “B (namely, a second reference encryption value)”) ; accessing, by a verification engine (Wang p. 6, paragraph beginning “Further, as shown in fig. 5…”: “the second secure encryption module ”) and from the managed node separate from the verification, a second plurality of integrity measurements generated by the managed node responsive to the managed node changing power states (Wang p. 6, paragraph beginning “Further, as shown in fig. 5…”: “first random number and the first encrypted value”) ; applying, by the verification algorithm, the replacement algorithm to the second plurality of integrity measurements to generate a second observed verification value for the managed node (Wang p. 6, paragraph beginning “Further, as shown in fig. 5…”: “…obtain B' (i.e., the second encrypted value)…”) ; comparing the second verification value with the second expected verification value for the managed node (Wang p. 6, paragraph starting “Further, as shown in fig. 5…”: “compares the second encryption value with the second reference encryption value”) ; and determining whether the managed node has unexpectedly changed responsive to the comparison of the second observed verification value with the second expected verification value (Wang p. 6, paragraph starting “Further as shown in fig. 5…”: “determines that the result to be determined is verification passing if the second encryption value is consistent with the second reference encryption value”) . Wang is art analogous to the claimed invention because both are directed to the field of endeavor of protecting computer systems. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to improve Takeuchi in view of Luciani’s design with the replacement method taught by Wang in order to “enhance the security of the target gateway” (Wang p. 6, paragraph starting “Further as shown in fig. 5…”) to allow a wider class of devices and inventories to be protected. Regarding claim 17, Takeuchi in view of Luciani and further in view of Wang discloses: The system of claim 16, wherein the hardware processor (Takeuchi Fig. 2, 30) to further, responsive to an update to the given managed node (Wang p. 6, 2 paragraphs under “Example two”: “When the boot_option=1, as shown in fig. 3, it indicates that the target startup mode, and the items to be verified… are verified…”) , update the data store to reassociate the managed node with another algorithm (Wang p.6, paragraph beginning “Further, as shown in fig. 5…”: “a second encryption algorithm M2”) and change the verification value associated with the managed node (Wang p.6, paragraph beginning “Further, as shown in fig. 5…”: “…B (namely, a second reference encryption value”) . Regarding claim 19, Takeuchi in view of Luciani and further in view of Wang discloses: The system of claim 16, wherein the hardware processor (Takeuchi Fig. 2, 30) to further: responsive to an authorized update being made to the given managed node (Wang p. 6, 2 paragraphs under “Example two”: “When the boot_option=1, as shown in fig. 3, it indicates that the target startup mode, and the items to be verified… are verified…”) , update the expected verification value (Wang p.6, paragraph beginning “Further, as shown in fig. 5…”: “…B (namely, a second reference encryption value”). Regarding claim 20, Takeuchi in view of Luciani and further in view of Wang discloses: The system of claim 19, wherein the hardware processor (Takeuchi Fig. 2, 30) to further: identify an image associated with the given managed node responsive to the authorized update (Wang p. 6, 2 paragraphs under “Example two”: “When the boot_option=1, as shown in fig. 3, it indicates that the target startup mode, and the items to be verified… are verified…) ; determine an integrity measurement corresponding to the image (Wang p.6, paragraph beginning “Further, as shown in fig. 5…”: “…the information to be encrypted is sent to the second encryption module…”) ; update the expected verification value based on the integrity measurement corresponding to the image (Wang p.6, paragraph beginning “Further, as shown in fig. 5…”: “…the target gateway encrypts the information to be encrypted by adopting a second encryption algorithm M2 to obtain B (namely, a second reference encryption value)”) . 07-22-aia AIA Claim s 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Takeuchi in view of Luciani as applied to claim 1 above, and further in view of “Analyzing Vectorized Hash Tables Across CPU Architectures” by Böther et al. (hereinafter “Böther”) . Regarding claim 12, Takeuchi discloses: A non-transitory storage medium that stores machine-readable instructions (Takeuchi [0123]: “Each of the structural elements in each of the foregoing embodiments may be configured in the form of an exclusive hardware product, or may be implemented by executing a computer program suitable for the structural element”) that, when executed by a machine associated with an attestation service, cause the machine to: identify an algorithm (Takeuchi Fig. 3, S102 “hash function”) corresponding to the managed node (Takeuchi Fig. 1, 16, 18, 20); apply the algorithm to expected integrity measurement hashes (Luciani [0013]: “PCRs are updated by hashing their previous value with the information to store… In the measured boot case, PCRs are used to store firmware and software integrity value.”) for the managed node to determine an expected verification value (Takeuchi [0055]: “Each of the expected hash values… is stored in storage 28 in advance, for example, when information processing device 2 is factory shipped”) for the managed node; access observed integrity measurement hashes provided by the managed node (Takeuchi Fig. 3, S101); apply the algorithm to the observed integrity measurement hashes to determine an observed verification value for the managed node (Takeuchi Fig. 3, S102); and determine whether the managed node unexpectedly changed (Takeuchi [0052]: “In the case where the calculated hash value (for example, “ddd”) of monitored unit 16 and the expected hash value “aaa” of monitored unit 16 do not match, controller 30 determines that monitored unit 16 is anomalous (for example, the program has been tampered with)…”) based on a comparison of the expected verification (Id. “aaa”) value with the observed verification value (Id. “ddd”) . Takeuchi does not disclose that the integrity data are hashes of integrity measurements. However, Luciani discloses using integrity measurement hashes to verify the integrity of a managed node: “PCRs are updated by hashing their previous value with the information to store. In the measured boot case, PCRs are used to store firmware and software integrity value. Using PCRs prevents removal of firmware or software execution events.” Luciani [0013]. Takeuchi and Luciani are art analogous to the claimed invention because all are directed to the field of endeavor of verifying the integrity of remote computer systems. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to use measurement hashes and initiate a responsive action as taught by Luciani in order to “prevent[] removal of firmware or software execution events” (Luciani [0013]) and “ensure that a security co-processor that is installed at manufacturing is the security co-processor that is used during boot of the computing device” (Luciani [0014]). Neither Takeuchi nor Luciani disclose identifying the algorithm based on attributes of the managed node . However, Böther discloses: identify an algorithm corresponding to the managed node (Böther p. 2766, Figure 13: “Decision guide for hashing scheme selection”) based on attributes of the managed node (Böther p. 2766, Figure 13: The white boxes correspond to decisions made based on attributes of the managed node.) Böther is art analogous to the claimed invention because its analysis of the speed of hashing operations would have been reasonably pertinent to a problem implicitly faced by the inventor, which is the speed of hash operations. One of ordinary skill in the art would appreciate the cumulative benefit of a small speed-up in many individual hash operations. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to select the algorithm based on some attribute of the managed node, such as processor type, as taught by Böther in order to improve the utilize the advantages provided by various types of hardware (Böther p. 2766: “The relative performance speedups of vectorization differ between platforms.” See also p. 2755, Figure 1: “Lookup performance of best scalar (RH) and vectorized (BBC) hashing schemes for load factor 90%”, where SQR refers to “successful query rate”, viz. p. 2759, “4.1 Setup”.) Regarding claim 13, Takeuchi in view of Luciani and further in view of Böther discloses: The storage medium of claim 12, wherein: the attributes comprise a model identifier corresponding to the managed node (Böther p. 2756-2757, “2.2 SIMD Programming and CPU Architectures”: “In the following, we discuss CPU architectures used in this work…”) ; the instructions, when executed by the machine, further cause the machine to select the algorithm based on the identifier (Böther p. 2766: “Figure 13: Decision guide for hashing scheme selection”. Examiner notes that the white boxes correspond to decisions made based on attributes of the managed node. “Architecture” decides whether to use VFP or BBC based on whether the processor is Power or x86/ARM, which have different model identifiers) . Regarding claim 14, Takeuchi in view of Luciani and further in view of Böther discloses: The storage medium of claim 12, wherein: the attributes comprise a model identifier corresponding to the managed node (Böther p. 2756-2757, “2.2 SIMD Programming and CPU Architectures”: “In the following, we discuss CPU architectures used in this work…”) ; the instructions, when executed by the machine, further cause the machine to select the algorithm based on the hardware processor category (Böther p. 2766: “Figure 13: Decision guide for hashing scheme selection”. Examiner notes that the white boxes correspond to decisions made based on attributes of the managed node. “Architecture” decides whether to use VFP or BBC based on whether the processor is Power or x86/ARM, which are different hardware processor categories) . 07-22-aia AIA Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Takeuchi in view of Luciani and Böther as applied to claim 12 above and further in view of “The Linux Kernel, v. 6.2.0, Trusted and Encrypted Keys” by the kernel development community, as available on February 21, 2023 from (hereinafter “Linux”) . Regarding claim 15, Takeuchi in view of Luciani and Böther disclose the storage medium of claim 12 . Takeuchi in view of Luciani and Böther does not disclose the attributes being a firmware version. However, Linux discloses: the attributes comprise a firmware version (Linux p. 4, “Usage”: “… For TPM 1.x the only allowed value is sha1. For TPM 2.x the allowed values are sha1, sha256, sha384, sha512 and sm3-256.”) ; the instructions, when executed by the machine, further cause the machine to select the algorithm based on the firmware version (Linux p. 4, “Usage”: “hash= hash algorithm name as a string.” The allowed hash versions are limited by the TPM firmware version.) . Linux is art analogous to the claimed invention both are directed to the same field of endeavor of safely operating computer systems. It would have been obvious to a person having ordinary skill in the art, prior to the effective filing date of the claimed invention, to select the hash algorithm based on the firmware version because older versions of the TPM specification required the use of SHA-1 (Arthur et al., “History of the TPM”, pp. 1-5 from A Practical Guide to TPM 2.0 , p. 4: “The TPM 1.2 architecture relied heavily on the SHA-1 algorithm and had hard-coded SHA-1 everywhere.”). Conclusion 07-96 The following prior art made of record and not relied upon is considered pertinent to applicant’s disclosure: US 20110131420 by Ali et al. discloses “computing entities, and associated methods, that can selectively use different cryptographic algorithms” based on different properties of the computing entity. 07-40 AIA Applicant's amendment necessitated the new grounds 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 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. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL HABASHI whose telephone number is (571)272-2245. The examiner can normally be reached M-F: 9 AM-6 PM. 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, Catherine Thiaw can be reached at (571)270-1138. 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. DH Examiner Art Unit 2407 /CHRISTOPHER A REVAK/Primary Examiner, Art Unit 2407 Application/Control Number: 18/765,439 Page 2 Art Unit: 2407 Application/Control Number: 18/765,439 Page 3 Art Unit: 2407 Application/Control Number: 18/765,439 Page 4 Art Unit: 2407 Application/Control Number: 18/765,439 Page 5 Art Unit: 2407 Application/Control Number: 18/765,439 Page 6 Art Unit: 2407 Application/Control Number: 18/765,439 Page 7 Art Unit: 2407 Application/Control Number: 18/765,439 Page 8 Art Unit: 2407 Application/Control Number: 18/765,439 Page 9 Art Unit: 2407 Application/Control Number: 18/765,439 Page 10 Art Unit: 2407 Application/Control Number: 18/765,439 Page 11 Art Unit: 2407 Application/Control Number: 18/765,439 Page 12 Art Unit: 2407 Application/Control Number: 18/765,439 Page 13 Art Unit: 2407 Application/Control Number: 18/765,439 Page 14 Art Unit: 2407 Application/Control Number: 18/765,439 Page 15 Art Unit: 2407 Application/Control Number: 18/765,439 Page 16 Art Unit: 2407 Application/Control Number: 18/765,439 Page 17 Art Unit: 2407 Application/Control Number: 18/765,439 Page 18 Art Unit: 2407 Application/Control Number: 18/765,439 Page 19 Art Unit: 2407 Application/Control Number: 18/765,439 Page 20 Art Unit: 2407 Application/Control Number: 18/765,439 Page 21 Art Unit: 2407 Application/Control Number: 18/765,439 Page 22 Art Unit: 2407
Prosecution Insights