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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/26/2025 has been entered.
Response to Amendment
Applicant’s amendment, filed 11/26/2025, has been entered and fully considered.
Response to Arguments
Applicant’s arguments, see page 6, filed 11/26/2025, with respect to the rejection of claims 1-20 under 35 U.S.C. 112(a) have been fully considered and are persuasive. The rejection under 35 U.S.C. 112(a) of claims 1-20 has been withdrawn. The Examiner notes that support in the specification for claim elements “the authorization information indicates that the electronic device is intended to be included in a network and is not a rogue access point” can be found in, at least, paragraph [0039] and paragraph [0056] of the specification, filed 11/14/2023.
Applicant’s arguments with respect to the rejection of claim(s) 1-20 under 35 U.S.C. 103, see pages 6-12, 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. In particular, Mehta is relied upon for teaching the argued claim elements of “in a circumstance where the electronic device comprises a first type of electronic device that includes an instance of a trusted platform module (TPM) chip and a circumstance where the electronic device comprises a second type of electronic device that excludes the TPM chip”.
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.
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.
Claim(s) 1-2, 6-7, 9, 16, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Covolato et al. (USP App Pub 2022/0067127; hereinafter Covolato) in view of Mehta et al. (USP App Pub 2010/0313262; hereinafter Mehta).
Regarding claim 1, A computer system (Covolato: paragraph [0018], “system 100A”), comprising:
an interface circuit configured to communicate with an electronic device (Covolato: paragraph [0022], “Communication between license verification and hardware control circuit 130-1 (e.g., control module 150-1) and controlled circuit 120-1 is described in FIG. 7” i.e., controlled circuit 120 corresponds to the electronic device);
a processor (Covolato: paragraph [0053], “general purpose processor”); and
memory that stores program instructions, wherein, when executed by the processor, the program instructions cause the computer system to perform (Covolato: paragraph [0053], “a general purpose processor, such as an IntelNAMD® x86 or ARM® processor, that operates under the control of software stored in a memory”) remote attestation of the electronic device (Covolato: paragraph [0016], “Verification can therefore be performed to enable features in the circuit without relying on the CPU or OS”; paragraph [0022], “controlled circuit 120-1”) by performing, … and a second circumstance where the electronic device comprises a second type of electronic device that excludes the TPM chip (Covolato: paragraph [0022], “internal registers of controlled circuit 120-4” i.e., controlled circuit 120 may not comprise an instance of a TPM), operations comprising:
receiving (Covolato: paragraph [0034], “FPGA 150-2 may receive license information (also referred to as a payload) from CPU 110”), from a second electronic device (Covolato: paragraph [0034], “CPU 110”; FIG. 3A, CPU 110 and FPGA 150-2 are distinct modules in the system 110B at least because License Verification and Hardware Control Circuit 130-2 is a distinct module from CPU 110), provisioning information (Covolato: paragraph [0034], “Payload 520 may include feature ID 512, customer ID 514, and system ID 516”; abstract: “communicating with circuitry to enable functionality of the circuitry specified in the license payload” i.e., the BRI of ‘provisioning information’ encompasses information regarding provisioning of the controlled circuit 120. The disclosed payload provides the necessary information to the system such that the system verifies the license and activates a desired feature on the controlled circuit 120. The ordinary meaning of ‘provision’ in the art encompasses the supplying of resources to use a system. The disclosed payload is a computing resource; paragraph [0034], “Payload 510 may include more license information (e.g., start date/time, an expiration (e.g., valid until) date/time…)” i.e., an alternative interpretation of the limitation ‘provisioning information’ may encompass information regarding provisioning or ‘setting aside’ certain resources like computing time for a particular use) for the electronic device (Covolato: paragraph [0042], “FPGA 150-2 activates/enables the feature/function in controlled circuit 120-2”);
confirming (Covolato: paragraph [0042], “TPM 140-2 determines that first hash and the second hash match (they are the same)”) a license (Covolato: paragraph [0033], “workflow 400 for verifying a hardware license”; paragraph [0027], “When the first hash and the second hash match (they are the same), the license is said to be verified/validated”) associated with the electronic device (Covolato: paragraph [0042], “At step 465, FPGA 150-2 activates/enables the feature/function in controlled circuit 120-2” i.e., the verification/validation of the license is to activate a function on the controlled circuit 120) based at least in part on the provisioning information (Covolato: paragraph [0034], “Payload 520 may include feature ID 512, customer ID 514, and system ID 516”);
receiving, associated with the electronic device (Covolato: paragraph [0042], “At step 465, FPGA 150-2 activates/enables the feature/function in controlled circuit 120-2” i.e., the verification/validation of the license is to activate a function on the controlled circuit 120), confirmation information (Covolato: paragraph [0042], “When TPM 140-2 does not return an error code (and instead returns an O.K. indication 632), FPGA 150-2 proceeds to step 465” i.e., an O.K. indication is confirmation information);
performing a join flow with the electronic device (Covolato: paragraph [0042], “At step 465, FPGA 150-2 activates/enables the feature/function in controlled circuit 120-2”) based at least in part on the confirmation information (Covolato: paragraph [0042], “When TPM 140-2 determines that first hash and the second hash match (they are the same) (step 460), TPM 140-2 returns an O.K. code”), wherein the join flow establishes a connection between the electronic device and the computer system (Covolato: paragraph [0050], “When a license to enable the controlled circuit is verified, the control module may enable the controlled circuit by writing to the internal registers” i.e., the control module corresponds to the claimed computer system and the controlled circuit corresponds to the claimed electronic device. Since the control module can access the internal registers of the controlled circuit, a connection between the control module and the controlled circuit has been established; FIG. 1, control module 150-1 is a module in system 110A); and
providing, addressed to the electronic device, authorization information (Covolato: paragraph [0050], “When a license to enable the controlled circuit is verified, the control module may enable the controlled circuit by writing to the internal registers”; paragraph [0042], “At step 465, FPGA 150-2 activates/enables the feature/function in controlled circuit 120-2”), …
Covolato does not teach … in a circumstance where the electronic device comprises a first type of electronic device that includes an instance of a trusted platform module (TPM)… wherein the electronic device comprises a computer network device, and the authorization information indicates that the electronic device is intended to be included in a network and is not a rogue access point.
However, in the same field of endeavor, Mehta does teach … in a circumstance where the electronic device (Mehta: paragraph [0014], “Remote access point 400”) comprises a first type of electronic device that includes an instance of a trusted platform module (TPM) (Mehta: paragraph [0015], “This information may be stored in memory hierarchy 420, as an example in EEPROM or flash storage, and/or in TPM 460 if a TPM is present”; paragraph [0016], “If remote access point 400 contains a TPM 460, the key for this certificate is stored in the TPM” i.e., ‘if’ remote access point 400 contains a TPM 460 is a circumstance)… wherein the electronic device (Mehta: paragraph [0014], “Remote access point 400”; paragraph [0029], “With the configuration information now present, initialization is complete, and operation of the remote access point in its provisioned state many now begin”) comprises a computer network device (Mehta: paragraph [0002], “a remote access point at a remote location establishes a connection with its home (corporate) controller over the switched internet”), and the authorization information (Mehta: paragraph [0026], “Once identities have been verified, controller 100 sends configuration information to remote access point 400”) indicates that the electronic device is intended to be included in a network (Mehta: paragraph [0024], “If the MAC address, which is present in the device credentials such as digital certificate, is on the whitelist, the connection is accepted”; paragraph [0029], “operation of the remote access point in its provisioned state many now begin”) and is not a rogue access point (Mehta: paragraph [0024], “controller 100 may contain a whitelist stored in memory hierarchy 120 of those individual remote access points which are to be accepted”; paragraph [0024], “…otherwise the connection is rejected”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the feature activation system of Covolato (Covolato: paragraph [0018], “When authorized by a license, controlled circuit 120-1 performs features or functions, such as Media Access Control security (MACsec) and Internet Protocol Security (IPsec)”) to incorporate the teachings of Mehta to authorize and verify the operation of an access point performing internet security features including IPsec (Mehta: paragraph [0002], “a remote access point at a remote location establishes a connection with its home (corporate) controller over the switched internet. In most cases this connection is an encrypted tunnel”; See References cited). The motivation for doing so is to use secure storage (Mehta: paragraph [0014], “Remote access point 400 is also a purpose-built digital device … and may contain TPM 460 for secure storage”) and to provide network access in a controlled and secure manner (Mehta: paragraph [0002], “This allows corporate users full access to systems and services in remote locations, such as remote offices or homes… to provide such access in a controlled and secure manner”).
Regarding claim 2, Covolato and Mehta teach the computer system of claim 1, wherein
confirming the license (Covolato: paragraph [0033], “workflow 400 for verifying a hardware license”; paragraph [0042], “TPM 140-2 determines that first hash and the second hash match”) comprising confirming that the electronic device (Covolato: paragraph [0051], “the system ID may be a serial number of line card 820”; FIG. 8, line card comprises the controlled circuit 120 i.e., the system ID identifies the controlled circuit 120) is associated with a customer (Covolato: paragraph [0034], “Customer ID 514 represents a particular customer”; paragraph [0041], “FPGA 150-2 requests TPM 140-2 to verify license signature 540…license signature 540 includes…customer ID 544, and system ID 546”; paragraph [0041], “TPM 140-2 may decrypt license signature 540 using LVK 622 (which was stored in TPM 140-2 under key handle 624) to produce the first hash”; paragraph [0038], “FPGA 150-2 receives second hash 612” i.e., the customer ID is verified with the system ID, therefore the TPM confirms they are associated with each other).
Regarding claim 6, Covolato and Mehta teach the computer system of claim 1, wherein
the electronic device (Covolato: paragraph [0022], “controlled circuit 120-1”; Mehta: paragraph [0014], “Remote access point 400”) comprises the instance of the TPM chip (Mehta: paragraph [0014], “Remote access point 400 is also a purpose-built digital device … and may contain TPM 460 for secure storage”).
Regarding claim 7, Covolato, Mehta teach the computer system of claim 6, wherein
the provisioning information (Covolato: paragraph [0034], “Payload 520 may include feature ID 512, customer ID 514, and system ID 516”; Mehta: paragraph [0015], “during manufacturing, identification information is generated and stored in remote access point 400… This identification information contains device unique information, which may be for example a serial number”) comprises an identifier (Mehta: paragraph [0015], “This information may be stored … in TPM 460 if a TPM is present”) associated with the instance of the TPM chip in the electronic device (Mehta: paragraph [0014], “Remote access point 400 is also a purpose-built digital device … and may contain TPM 460 for secure storage” i.e., storing information in a TPM is associating the information with the TPM).
Regarding claim 9, Covolato, Mehta teach the computer system of claim 6, wherein
the license (Covolato: paragraph [0033], “workflow 400 for verifying a hardware license”; FIG. 3B, hardware license data comprises a system ID for the hardware) is associated with the instance of the TPM chip (Covolato: paragraph [0023], “a Trusted Platform Module (TPM 130)”; paragraph [0030], “a device (that has a connector adapted to connect to a removable TPM)” i.e., the tpm is part of the hardware of the device therefore it is associated).
The motivation to combine the above listed references is the same as the motivation stated in the rejection of claim 1.
Re. claims 16, 18, they recite analogous limitations as claim 1 and therefore are rejected for the same reasons.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Covolato in view of Mehta in further view of Park et al. (USP App Pub 2021/0127245; hereinafter Park).
Regarding claim 3, Covolato and Mehta teach the computer system of claim 1, wherein
the join flow (Covolato: paragraph [0042], “At step 465, FPGA 150-2 activates/enables the feature/function in controlled circuit 120-2”) comprises…
Covolato and Mehta do not teach …performing mutual authentication with the electronic device.
However, in the same field of endeavor, Park does teach …performing mutual authentication with the electronic device (Park: paragraph [0107], “If the electronic device 901 and the external electronic device 902 succeed in mutual authentication (915), the electronic device 901 and the external electronic device 902 may establish a secure communication connection”; paragraph [0048], “A connecting terminal 178 may include a connector via which the electronic device 101 may be physically connected with the external electronic device (e.g., the electronic device 102)” i.e., the external electronic device corresponds to the claimed electronic device).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the activation of the controlled circuit of Covolato and Mehta to incorporate the teachings of Park to mutually authenticate the external controlled circuit and the electronic control module before activation. The motivation for doing so is to ensure both devices trust each other (Park: paragraph [0188], “since the electronic device and the external electronic device perform mutual authentication using certificates of the electronic device registered for a user account and the external electronic device, trusted devices may securely establish communication connection with each other”).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Covolato in view of Mehta in further view of Hughes et al. (USP App Pub 2008/0319779; hereinafter Hughes).
Regarding claim 4, Covolato and Mehta teach the computer system of claim 1, wherein
the confirmation information (Covolato: paragraph [0042], “When TPM 140-2 determines that first hash and the second hash match (they are the same) (step 460), TPM 140-2 returns an O.K. code”) comprises…
Covolato and Mehta do not teach …a manufacturer certificate.
However, in the same field of endeavor, Hughes does teach …a manufacturer certificate (Hughes: paragraph [0087], “The confirmation identifier in the example 600 also includes an encrypted hash value 604…the hash value 604 may be formed using the installation identifier”; paragraph [0081], “representation of an installation identifier…an identification string may be formed based on the particular hard drive or CPU in a computer. The string may identify the manufacturer”; paragraph [0085], “the confirmation identifier may be generated if all previous verification processing of steps 502, 504 and 506 has completed successfully” i.e., the confirmation identifier has a string that identifies the manufacturer; claim 1, “generating a license in accordance with said binding certificate…, said binding certificate identifying an entity to which said license is bound”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the confirmation information of Covolato and Mehta to incorporate the teachings of Hughes to use a manufacturer certificate as part of confirmation information. The motivation for doing so is to have unique information that can particularly identify the device (Covolato: paragraph [0081], “The string may identify the manufacturer and other information unique to the computer's CPU or hard drive (e.g., "INTEL 989709789798")”).
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Covolato in view of Mehta in further view of Matsumoto (USP App Pub 2020/0280446).
Regarding claim 5, Covolato and Mehta teach the computer system of claim 1, wherein
the authorization information (Covolato: paragraph [0034], “Payload 510 may include more license information (e.g., start date/time, an expiration (e.g., valid until) date/time”; paragraph [0084], “When unauthorized use—a license violation—is detected, the control module may deactivate/disable the controlled circuit (again) by writing to the internal registers”) comprises…
Covolato and Mehta do not teach …a JavaScript Object Notation (JSON) Web Token (JWT).
However, in the same field of endeavor, Matsumoto does teach …a JavaScript Object Notation (JSON) Web Token (JWT) (Matsumoto: paragraph [0112], “the verification unit 342 generates, as an authentication result, data including an authentication token corresponding to a user ID…The authentication token is a token such as that typified by, for example, JSON Web Token (JWT)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the authorization information of Covolato and Mehta to incorporate the teachings of Matsumoto include a JWT. The motivation for doing so is to verify a request by verifying the token (Matsumoto: paragraph [0114], “the user verification unit 331 of the service providing system 102 verifies the authentication token and thus specifies a user ID with use of the token”).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Covolato in view of Mehta in further view of Badaoui-Najjar et al. (USP App Pub 2011/0040961; hereinafter Badaoui-Najjar).
Regarding claim 8, Covolato, Mehta teach the computer system of claim 7,
wherein the identifier (Covolato: paragraph [0052], “perform license verification using a serial number of the chassis as the system ID”) comprises…
Covolato and Mehta do not teach …a serial number of the instance of the TPM chip.
However, in the same field of endeavor, Badaoui-Najjar does teach …a serial number of the instance of the TPM chip (Badaoui-Najjar: paragraph [0018], “data may be bound using only the TPM specific information such as a TPM serial number”; paragraph [0014], “One use of a TPM is to bind data to a host. This data may be an application or portion of an application (e.g. a module, subroutine, function). A TPM may selectively use the keys to achieve the desired binding of data to a specific host”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the identifier of the TPM of Covolato and Mehta to incorporate the teachings of Badaoui-Najjar to use a serial number. The motivation for doing so is to ensure that operations are only performed on a specific TPM (Badaoui-Najjar: paragraph [0016], “The numeric values may be specific to the TPM, such as a serial number”; paragraph [0018], “data may be bound using only the TPM specific information such as a TPM serial number”).
Claim(s) 10-12, 14, 17, 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Covolato in view of Mehta in further view of Hughes in further view of Appenzeller et al. (USP App Pub 2006/0095771; hereinafter Appenzeller).
Regarding claim 10, Covolato and Mehta teach the computer system of claim 6, wherein, prior to performing the join flow (Covolato: paragraph [0042], “At step 465, FPGA 150-2 activates/enables the feature/function in controlled circuit 120-2”), the operations comprise:…
Covolato and Mehta do not teach …providing, addressed to the electronic device, an attestor identity key (AIK) certificate; signing the AIK certificate; and performing remote attestation with the electronic device based at least in part on the AIK certificate, wherein the remote attestation comprises TPM attestation.
However, in the same field of endeavor, Hughes does teach …providing, addressed to the electronic device (Hughes: paragraph [0063], “The public key certificate for the TPM”), an attestor identity key (AIK) certificate (Hughes: paragraph [0063], “The public key certificate for the TPM of the computer 102 may be obtained”);
…
performing remote attestation with the electronic device based at least in part on the AIK certificate (Hughes: paragraph [0063], “sent to the BS 110 for certification. As known in the art, this certification may be performed by a certificate authority (CA) to attest that the public key contained in the certificate belongs to the TPM entity noted in the certificate”), wherein the remote attestation comprises TPM attestation (Hughes: paragraph [0063], “to attest that the public key contained in the certificate belongs to the TPM entity noted in the certificate”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the activation step of Covolato and Mehta to incorporate the teachings of Hughes to attest the TPM prior to activation. The motivation for doing so is to “to attest that the public key contained in the certificate belongs to the TPM entity noted in the certificate” (Hughes: paragraph [0063]).
In addition, in the same field of endeavor, Appenzeller does teach …signing the AIK certificate (Appenzeller: paragraph [0087], “the authentication certificate authority creates and signs an authentication certificate for the user. The authentication certificate contains the authentication ID and the authentication public key Kp for the user at device 20”); and…
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the public key certificate of Covolato, Mehta and Hughes to incorporate the teachings of Appenzeller to sign the certificate. The motivation for doing so is to ensure that the certificate is associated with a particular party (Appenzeller: paragraph [0050], “Digital signatures (e.g., signatures from a certificate authority or other entity that use private keys and that can be verified using matching public keys) may be used to ensure that a message or other signed information is associated with a particular party”).
Regarding claim 11, Covolato, Mehta, Hughes and Appenzeller teach the computer system of claim 10, wherein
the confirmation information (Covolato: paragraph [0042], “When TPM 140-2 does not return an error code (and instead returns an O.K. indication 632), FPGA 150-2 proceeds to step 465” i.e., an O.K. indication is confirmation information; Hughes: paragraph [0066], “After both the BC and EC 122 have been successfully verified, the LS 120 retrieves the binding type information from the EC and determines whether the BC contains the proper binding type as indicated in the BC in step 254. If not, the activation process may terminate with an error condition and message to the computer 102”) comprises the AIK certificate (Hughes: paragraph [0066], “If the license is bound to a TPM instance, a public key certificate for a TPM root of a trusted CA(certificate authority) may be stored”).
Regarding claim 12, Covolato, Mehta, Hughes and Appenzeller teach the computer system of claim 11, wherein the operations comprise performing verification of the electronic device based at least in part on the identifier (Hughes: paragraph [0066], “each license issued for a purchase token with respect to a hardware identifier binding”) and a result of the TPM attestation (Hughes: paragraph [0063], “this certification may be performed by a certificate authority (CA) to attest that the public key contained in the certificate belongs to the TPM entity noted in the certificate”); and
wherein the authorization information (Hughes: FIG. 5, step 266 issues a license, and a license is an authorization to use a system) is provided when the verification is successful (Hughes: paragraph [0066], “Information regarding the new license issued is recorded in a database 120a of the LS 120 for use in connection with other processing steps described herein…For example, for each license issued for a purchase token with respect to a hardware identifier binding, the license service database may associate the hardware identifier of the binding with the purchase token.”; FIG. 5, step 266 is a verification successful branch, in contrast to step 264).
Regarding claim 14, Covolato, Mehta, Hughes and Appenzeller teach the computer system of claim 10, wherein
the AIK certificate is signed by a privacy certificate authority (CA) in the computer system (Hughes: paragraph [0063], “sent to the BS 110 for certification. As known in the art, this certification may be performed by a certificate authority (CA) to attest that the public key contained in the certificate belongs to the TPM entity noted in the certificate”; paragraph [0066], “If the license is bound to a TPM instance, a public key certificate for a TPM root of a trusted CA(certificate authority) may be stored”).
The motivation to combine references is the same as the one stated in the rejection of claim 10.
Re. claims 17, 19-20, they recite analogous limitations as claims 10, 10, 12, respectively, and therefore are rejected for the same reasons.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Covolato in view of Mehta in further view of Hughes in further view of Appenzeller in further view of Vasudevan et al. (USP App Pub 2016/0259941; hereinafter Vasudevan).
Regarding claim 13, Covolato, Mehta, Hughes and Appenzeller teach the computer system of claim 10, wherein
the AIK certificate (Hughes: paragraph [0063], “The public key certificate for the TPM of the computer 102 may be obtained”) is associated with a TPM verifier in the computer system (Hughes: paragraph [0063], “sent to the BS 110 for certification. As known in the art, this certification may be performed by a certificate authority (CA) to attest that the public key contained in the certificate belongs to the TPM entity noted in the certificate” i.e., BS 110/CA corresponds to the claimed TPM verifier), and the TPM verifier performs the TPM attestation (Hughes: paragraph [0063], “sent to the BS 110 for certification. As known in the art, this certification may be performed by a certificate authority (CA) to attest”)…
Colvolato, Mehta, Hughes and Appenzeller do not teach …with a TPM attestor in the electronic device.
However, in the same field of endeavor, Vasudevan does teach …with a TPM attestor in the electronic device (Vasudevan: paragraph [0059], “The TPM endorsement key is included as part of the TPM” i.e., an attestor is something that attests and the TPM endorsement key is used as part of the attestation; paragraph [0059], “a certificate that is digitally signed by a trusted entity (e.g., a third party trusted by the management service) and that attests to the TPM endorsement key for the computing device is assigned to the TPM”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the public key certificate (Hughes: paragraph [0063], “The public key certificate for the TPM of the computer 102 may be obtained”) of Colvolato, Mehta, Hughes and Appenzeller to incorporate the teachings of Vasudevan to include the key as a part of the TPM. The motivation for doing so is to protect the TPM key from manipulation (Vasudevan: paragraph [0059], “The TPM endorsement key is included as part of the TPM, protecting the TPM endorsement key from being modified by malicious code on the computing device”).
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Covolato in view of Mehta in further view of Hughes in further view of Appenzeller in further view of Caceres et al. (USP App Pub 2020/0021445; hereinafter Caceres).
Regarding claim 15, Covolato, Mehta, Hughes and Appenzeller teach the computer system of claim 10, wherein
the operations comprise…performing the TPM attestation with the electronic device (Hughes: paragraph [0063], “sent to the BS 110 for certification. As known in the art, this certification may be performed by a certificate authority (CA) to attest that the public key contained in the certificate belongs to the TPM entity noted in the certificate”.
Covolato, Mehta, Hughes and Appenzeller do not teach …periodically…
However, in the same field of endeavor, Caceres does teach …periodically (Caceres: paragraph [0024], “The application server device may send the challenge…periodically the application server device may generate and send a challenge to the application based on a time-based trigger (e.g., triggering a new challenge every few minutes, hours, etc.)”; paragraph [0024], “The challenge may assert the identity of the application server device, and include a request for an attestation key, or an attestation certificate signed by a trusted source (i.e., the secure element), by which the application server device may attest to the identity and/or trusted state of the application”) performing the…attestation with the electronic device (Caceres: paragraph [0023], “to perform an application attestation for an application running on a client”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the TPM attestation of Covolato, Mehta, Hughes and Appenzeller to incorporate the teachings of Caceres to periodically attest. The motivation for doing so is to ensure that the system is regularly attested (Caceres: paragraph [0024], “the application server device may generate and send a challenge to the application based on a time-based trigger (e.g., triggering a new challenge every few minutes, hours, etc.)… In this way, the application may be regularly attested.”).
References Cited
Taylor et al. (USP App Pub 2006/0221916; hereinafter Taylor) is cited to show that it is common knowledge and well known in the prior art that a remote access point may use a secure communications path with an IPsec security protocol (Taylor: paragraph [0015], “the remote AP sets up a secure communication path by establishing a tunnel in accordance an Open Systems Interconnection (OSI) "Layer 3" (L3) security protocol that protects and authenticates messages between participating devices. One type of L3 security protocol is Internet Protocol Security (IPsec) protocol”; paragraph [0013], “remote access points (APs)”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADITYA SRIRAM whose telephone number is (703)756-1715. The examiner can normally be reached Su-Sa: 9:00 AM - 11:59 AM PST and 1:00 PM - 8 PM PST.
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, William Korzuch can be reached at (571) 272-7589. 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.
/A.S./Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491