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 07/08/2025 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected under 35 USC 103 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.
Applicant argued in the remark that prior arts do not disclose wherein the attestation information indicates whether a particular network node is capable of supporting attestation procedures in a multicast routing protocol" and "determining, based on the attestation information, that the second network apparatus supports the attestation procedures in a multicast routing protocol,"
Examiner respectfully disagrees Lokamathe US 2019/0109866 discloses 0003 As successful attestation indicates that device/node that got attested is working that support attestation results and 0142 the final results, along with any data unique to the nodes/groups being attested for verification, can be stored in a blockchain network, or any such storage means that the attested indicates that satisfies requirements in terms of privacy, security, i.e. support attestation procedures, and such data storage norms. Par 0021 FIG. 3. Further, the verifier nodes may be configured to initiate the attestation, in response to an instruction/request received from a prover node of the network, which, i.e. indication of a particular network apparatus, is to be attested.
Moreover, Klawe et al US 2019/0207953 discloses [0050] The primary node may then transfer such rules to the secondary nodes(s), for example, at predetermined time intervals, when a secondary node is known to lose connection with the primary node, or begins to lose connection with the secondary node. The rules, in one example, configure the secondary nodes to perform a set or a subset of actions that the primary node is capable of performing. For example, the rules can configure the secondary node to attest other secondary or tertiary nodes, for example to process payment transactions, by providing the nodes with timed or un-timed attestation tickets. In one implementation, the rules may be further configured or re-configured based on a current attestation session executed by the nodes. It can be seen as the attestation indicates the configuration rules to be performed in the secondary nodes to attest in the network.
Applicant argued in the remark that prior arts do not disclose wherein "the attestation information is included in a Type-Length-Value (TLV) that 508339029
is appended to advertisements originating in the second network apparatus.
Examiner respectfully disagrees. Kim et al US 2006/0034250 discloses
0026 a neighbor BS having received a ranging request message from a BS requiring acquisition of time synchronization and 0033 BS 2 104 transmits a ranging request message requesting time synchronization information to the neighbor BSs including BS 1 102 and BS 3 106. And 0035 the certificate profile included in the ranging response message is transmitted together with the time synchronization information, and the certificate profile is generated by the BS which has received time synchronization information from the GPS transmitter 100 and has initially acquired time synchronization and 0042 The information elements are additionally included in the conventional ranging messages as certificate profile TLV (Type, Length & Value) 0045 The certificate profile is produced by the BS which has acquired time synchronization from the initial GPS signal and is included in the ranging response message in the form of certificate profile TLV information.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21-25,28-32, and 35-39 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-5,8-11,14-18 and 20 of U.S. Patent No. 11, 575,513 in view of Lokamathe US 2019/0109866 and Kim et al US 2006/0034250.
As per claim 21. Patent discloses a first network apparatus, comprising:
one or more processors; and one or more computer-readable non-transitory storage media coupled to the one or more processors and comprising instructions that, when executed by the one or more processors, cause the first network apparatus to perform operations ( claim 1 one or more processors; and one or more computer-readable non-transitory storage media coupled to the one or more processors and comprising instructions that, when executed by the one or more processors, cause the first network apparatus to perform operations) comprising:
receiving, from a second network apparatus, a multicast message comprising attestation information associated with the second network apparatus( claim 1 );
determining that the attestation information fails to satisfy one or more pre- determined attestation requirements; and processing the multicast message based on a local policy ( claim 1 ) .
Patent does not disclose wherein the attestation information is any information that indicates whether a particular network apparatus is configured to support attestation procedures in a multicast routing protocol, processing, in response to determining that the attestation information fails to satisfy one or more pre-determined attestation requirements, the multicast message based on a local policy," wherein the attestation information is included in a Type-Length-Value (TLV) that is appended to an advertisement originating in the second network apparatus.
However, Lokamathe discloses wherein the attestation information is any information that indicates whether a particular network apparatus is configured to support attestation procedures in a multicast routing protocol (0003 As successful attestation indicates that device/node that got attested is working that support attestation results and 0142 the final results, along with any data unique to the nodes/groups being attested for verification, can be stored in a blockchain network, or any such storage means that the attested indicates that satisfies requirements in terms of privacy, security, i.e. support attestation procedures, and such data storage norms. Par 0021 FIG. 3. Further, the verifier nodes may be configured to initiate the attestation, in response to an instruction/request received from a prover node of the network, which, i.e. indication of a particular network apparatus, is to be attested);
processing, in response to determining that the attestation information fails to satisfy one or more pre-determined attestation requirements, the multicast message based on a local policy(0143 attestation triggered by a verifier node fails to collect information from all nodes in the network (due to lack of connectivity between the nodes), thus leading to failure of the attestation process).
Patent and Lokamathe are both considered to be analogous to the claimed invention because they are in the same field of multicasting.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Patent to incorporate the teachings of Lokamathe and provide authorized policy.
Doing so would a broadcast or multicast, thereby forming messaging checking policy.
The combination fails to discloses wherein the attestation information is included in a Type-Length-Value (TLV) that is appended to an advertisement originating in the second network apparatus.
However, Kim discloses wherein the attestation information is included in a Type-Length-Value (TLV) that is appended to an advertisement originating in the second network apparatus ( 0026 a neighbor BS having received a ranging request message from a BS requiring acquisition of time synchronization and 0033 BS 2 104 transmits a ranging request message requesting time synchronization information to the neighbor BSs including BS 1 102 and BS 3 106. And 0035 the certificate profile included in the ranging response message is transmitted together with the time synchronization information, and the certificate profile is generated by the BS which has received time synchronization information from the GPS transmitter 100 and has initially acquired time synchronization and 0042 The information elements are additionally included in the conventional ranging messages as certificate profile TLV (Type, Length & Value) 0045 The certificate profile is produced by the BS which has acquired time synchronization from the initial GPS signal and is included in the ranging response message in the form of certificate profile TLV information).
Patent and Lokamathe and Kim are both considered to be analogous to the claimed invention because they are in the same field of multicasting.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Patent to incorporate the teachings of Lokamathe, the teaching of kim, and provide authorized policy.
Doing so would a broadcast or multicast, thereby forming messaging checking policy.
As per claim 22. Patent and Lokamathe and Kim discloses The first network apparatus of Claim 21, wherein the first multicast message is one of the following: a Protocol-Independent Multicast (PIM) hello message; or a Label Distribution Protocol (LDP) message(patent claim 2).
As per claim 23. Patent and Lokamathe and Kim discloses The first network apparatus of Claim 21, the attestation information comprising attestation-capability information associated with the second network apparatus, the operations further comprising determining that the attestation-capability information fails to satisfy a pre-determined attestation-capability requirement( Patent claim 3).
As per claim 24. Patent and Lokamathe and Kim discloses the first network apparatus of Claim 21, the attestation information comprising security level information associated with the second network apparatus, the operations further comprising determining that a security level associated with the second network apparatus fails to satisfy a pre-determined security level threshold (Patent claim 4).
As per claim 25. Patent and Lokamathe and Kim discloses The first network apparatus of Claim 21, the attestation information comprising an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state, the operations further comprising determining that the attestation token is invalid for the second network apparatus at a current time ( Patent claim 5) .
As per claim 28. Patent discloses A method, comprising: receiving, by a first network apparatus and from a second network apparatus, a multicast message comprising attestation information associated with the second network apparatus; determining, by the first network apparatus, that the attestation information fails to satisfy one or more pre-determined attestation requirements ( claim 8); and processing, by the first network apparatus, the multicast message based on a local policy ( claim 8).
Patent does not disclose processing, in response to determining that the attestation information fails to satisfy one or more pre-determined attestation requirements, the multicast message based on a local policy,"
However, Lokamathe discloses processing, in response to determining that the attestation information fails to satisfy one or more pre-determined attestation requirements, the multicast message based on a local policy(0143 attestation triggered by a verifier node fails to collect information from all nodes in the network (due to lack of connectivity between the nodes), thus leading to failure of the attestation process).
Patent and Lokamathe are both considered to be analogous to the claimed invention because they are in the same field of multicasting.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Patent to incorporate the teachings of Lokamathe and provide authorized policy.
Doing so would a broadcast or multicast, thereby forming messaging checking policy.
The combination fails to discloses wherein the attestation information is included in a Type-Length-Value (TLV) that is appended to an advertisement originating in the second network apparatus.
However, Kim discloses wherein the attestation information is included in a Type-Length-Value (TLV) that is appended to an advertisement originating in the second network apparatus ( 0026 a neighbor BS having received a ranging request message from a BS requiring acquisition of time synchronization and 0033 BS 2 104 transmits a ranging request message requesting time synchronization information to the neighbor BSs including BS 1 102 and BS 3 106. And 0035 the certificate profile included in the ranging response message is transmitted together with the time synchronization information, and the certificate profile is generated by the BS which has received time synchronization information from the GPS transmitter 100 and has initially acquired time synchronization and 0042 The information elements are additionally included in the conventional ranging messages as certificate profile TLV (Type, Length & Value) 0045 The certificate profile is produced by the BS which has acquired time synchronization from the initial GPS signal and is included in the ranging response message in the form of certificate profile TLV information).
Patent and Lokamathe and Kim are both considered to be analogous to the claimed invention because they are in the same field of multicasting.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Patent to incorporate the teachings of Lokamathe, the teaching of kim, and provide authorized policy.
Doing so would a broadcast or multicast, thereby forming messaging checking policy.
As per claim 29. Patent and Lokamathe discloses The method of Claim 28, wherein the first multicast message is one of the following: a Protocol-Independent Multicast (PIM) hello message; or a Label Distribution Protocol (LDP) message ( Patent claim 9).
As per claim 30. Patent and Lokamathe discloses The method of Claim 28, the attestation information comprising attestation-capability information associated with the second network apparatus, further comprising: determining that the attestation-capability information fails to satisfy a pre-determined attestation-capability requirement ( patent claim 10).
As per claim 31. Patent and Lokamathe and Kim discloses The method of Claim 28, the attestation information comprising security level information associated with the second network apparatus, further comprising: determining that a security level associated with the second network apparatus fails to satisfy a pre-determined security level threshold ( patent claim 11).
As per claim 32. Patent and Lokamathe and Kim discloses The method of Claim 28, the attestation information comprising an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state, further comprising: determining that the attestation token is invalid for the second network apparatus at a current time (patent claim 14).
As per claim 35. Patent discloses One or more computer-readable non-transitory storage media embodying instructions that, when executed by a processor, cause the processor to perform operations comprising: receiving, by a first network apparatus and from a second network apparatus, a multicast message comprising attestation information associated with the second network apparatus (claim 15 ); determining that the attestation information fails to satisfy one or more pre- determined attestation requirements; and processing the multicast message based on a local policy ( claim 15).
Patent does not disclose processing, in response to determining that the attestation information fails to satisfy one or more pre-determined attestation requirements, the multicast message based on a local policy,"
However, Lokamathe discloses processing, in response to determining that the attestation information fails to satisfy one or more pre-determined attestation requirements, the multicast message based on a local policy(0143 attestation triggered by a verifier node fails to collect information from all nodes in the network (due to lack of connectivity between the nodes), thus leading to failure of the attestation process).
Patent and Lokamathe are both considered to be analogous to the claimed invention because they are in the same field of multicasting.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Patent to incorporate the teachings of Lokamathe and provide authorized policy.
Doing so would a broadcast or multicast, thereby forming messaging checking policy.
The combination fails to discloses wherein the attestation information is included in a Type-Length-Value (TLV) that is appended to an advertisement originating in the second network apparatus.
However, Kim discloses wherein the attestation information is included in a Type-Length-Value (TLV) that is appended to an advertisement originating in the second network apparatus ( 0026 a neighbor BS having received a ranging request message from a BS requiring acquisition of time synchronization and 0033 BS 2 104 transmits a ranging request message requesting time synchronization information to the neighbor BSs including BS 1 102 and BS 3 106. And 0035 the certificate profile included in the ranging response message is transmitted together with the time synchronization information, and the certificate profile is generated by the BS which has received time synchronization information from the GPS transmitter 100 and has initially acquired time synchronization and 0042 The information elements are additionally included in the conventional ranging messages as certificate profile TLV (Type, Length & Value) 0045 The certificate profile is produced by the BS which has acquired time synchronization from the initial GPS signal and is included in the ranging response message in the form of certificate profile TLV information).
Patent and Lokamathe and Kim are both considered to be analogous to the claimed invention because they are in the same field of multicasting.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Patent to incorporate the teachings of Lokamathe, the teaching of kim, and provide authorized policy.
Doing so would a broadcast or multicast, thereby forming messaging checking policy.
As per claim 36. Patent and Lokamathe and Kim discloses The one or more computer-readable non-transitory storage media of Claim 35, wherein the first multicast message is one of the following: a Protocol-Independent Multicast (PIM) hello message; or a Label Distribution Protocol (LDP) message ( patent claim 16).
As per claim 37. Patent and Lokamathe and Kim discloses The one or more computer-readable non-transitory storage media of Claim 35, the attestation information comprising attestation-capability information associated with the second network apparatus, the operations further comprising determining that the attestation-capability information fails to satisfy a pre-determined attestation-capability requirement ( patent claim 17).
As per claim 38. Patent and Lokamathe and Kim discloses The one or more computer-readable non-transitory storage media of Claim 35, the attestation information comprising security level information associated with the second network apparatus, the operations further comprising determining that a security level associated with the second network apparatus fails to satisfy a pre-determined security level threshold ( Patent claim 18).
As per claim 39. Patent and Lokamathe and Kim discloses The one or more computer-readable non-transitory storage media of Claim 35, the attestation information comprising an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state, the operations further comprising determining that the attestation token is invalid for the second network apparatus at a current time (Patent claim 20).
Specification
The abstract of the disclosure is objected to because in one embodiment. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
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.
Claim(s) 21, 26-28,33-34 and 35 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Lokamathe et al US 2019/0109866 and Klawe et al US 2019/0207953 and Kim et al US 2006/0034250.
As per claim 21, Lokamathe et al discloses a first network apparatus, comprising: one or more processors; and one or more computer-readable non-transitory storage media coupled to the one or more processors and comprising instructions that, when executed by the one or more processors, cause the first network apparatus to perform operations comprising:
receiving, from a second network apparatus, a multicast message comprising attestation information associated with the second network apparatus (fig.5, 0083 verifier node, i.e. a second network apparatus, broadcasts the attestation results to other verifier nodes and so as to generate final results that represent final attestation results of nodes being tested for authentication purpose. The final result thus obtained is then distributed among all nodes of the network and 0141 [0141] Each group is further configured to run a majority function over the consolidated result, and generate final attestation results (for example, v1, v2, v3, and v4). In an embodiment, for the given network, values of v1, v2, v3, and v4 are expected to be the same. The final results can be then distributed among/shared with all nodes/groups in the network, for further reference/verification purpose. ), wherein the attestation information is any information that indicates whether a particular network apparatus is configured to support attestation procedures in a multicast routing protocol (0003 As successful attestation indicates that device/node that got attested is working that support attestation results and 0142 the final results, along with any data unique to the nodes/groups being attested for verification, can be stored in a blockchain network, or any such storage means that the attested indicates that satisfies requirements in terms of privacy, security, i.e. support attestation procedures, and such data storage norms. Par 0021 FIG. 3. Further, the verifier nodes may be configured to initiate the attestation, in response to an instruction/request received from a prover node of the network, which, i.e. indication of a particular network apparatus, is to be attested);
determining that the attestation information fails to satisfy one or more pre- determined attestation requirements (0143 attestation triggered by a verifier node fails to collect information from all nodes in the network (due to lack of connectivity between the nodes), thus leading to failure of the attestation process);
determining, in response to determining that the attestation information fails to satisfy the one or more pre-determined attestation requirements, not to trust the second network apparatus (0144 perform a check to detect presence of any malicious node(s) in the network. The networks may be further configured to determine, which node/group among the nodes/groups of the network is malicious, i.e. not to trust the second apparatus, based on the final attestation results); and
processing, in response to determining not to trust the second network apparatus, the multicast message based on a local policy of the first network apparatus (0144 By identifying the malicious nodes, communication between two nodes of the network can be routed such that the malicious node has no or minimum presence in the communication path selected, which in turn helps in fault tolerance. 0145 the nodes of the network are configured generate own trust metric, i.e. a local policy, based on the final attestation results and 0101 TRUST METRIC TABLE is maintained by every node in the swarm and this metric evolves over period of time);
Lokamathe does not disclose a particular network apparatus is configured to support attestation procedures, wherein the attestation information is included in a Type-Length-Value (TLV) that is appended to an advertisement originating in the second network apparatus.
However, Klawe discloses a particular network apparatus is configured to support attestation procedures ([0050] The primary node may then transfer such rules to the secondary nodes(s), for example, at predetermined time intervals, when a secondary node is known to lose connection with the primary node, or begins to lose connection with the secondary node. The rules, in one example, configure the secondary nodes to perform a set or a subset of actions that the primary node is capable of performing. For example, the rules can configure the secondary node to attest other secondary or tertiary nodes, for example to process payment transactions, by providing the nodes with timed or un-timed attestation tickets. In one implementation, the rules may be further configured or re-configured based on a current attestation session executed by the nodes. It can be seen as the attestation indicates the configuration rules to be performed in the secondary nodes to attest in the network),
Lokamathe and Klawe are both considered to be analogous to the claimed invention because they are in the same field of network communication.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lokamathe to incorporate the teachings of Klawe and provide an attestation session based on the rules. Doing so would provide an attestation session provides independent verification system, thereby increasing enhancing trust for the network node.
The combination fails to disclose wherein the attestation information is included in a Type-Length-Value (TLV) that is appended to an advertisement originating in the second network apparatus.
However, Kim discloses ( 0026 a neighbor BS having received a ranging request message from a BS requiring acquisition of time synchronization and 0033 BS 2 104 transmits a ranging request message requesting time synchronization information to the neighbor BSs including BS 1 102 and BS 3 106. And 0035 the certificate profile included in the ranging response message is transmitted together with the time synchronization information, and the certificate profile is generated by the BS which has received time synchronization information from the GPS transmitter 100 and has initially acquired time synchronization and 0042 The information elements are additionally included in the conventional ranging messages as certificate profile TLV (Type, Length & Value) 0045 The certificate profile is produced by the BS which has acquired time synchronization from the initial GPS signal and is included in the ranging response message in the form of certificate profile TLV information).
Lokamathe and Klawe and Kim are both considered to be analogous to the claimed invention because they are in the same field of network communication.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lokamathe to incorporate the teachings of Klawe, including the teaching of Kim and provide an attestation using Type-Length-Value. Doing so would provide structured format enables verifiers to reliably analyze evidence from a device's Trusted Execution Environment (TEE) to make trust decisions, thereby increasing robust validation of platform state by remote verifiers.
As per claim 26. Lokamathe and Klawe and Kim discloses the first network apparatus of Claim 21, Lokamathe discloses wherein the local policy instructs the first network apparatus to drop the multicast message(0145 the nodes of the network are configured generate own trust metric, i.e. a local policy, based on the final attestation results and 0101 TRUST METRIC TABLE is maintained by every node in the swarm and this metric evolves over period of time ).
As per claim 27. Lokamathe and Klawe and Kim discloses the first network apparatus of Claim 21, Lokamathe discloses wherein the local policy instructs the first network apparatus to set a metric of one or more links associated with the second network apparatus to a maximum value (0145 the nodes of the network are configured generate own trust metric, i.e. a local policy, based on the final attestation results and 0101 TRUST METRIC TABLE is maintained by every node in the swarm and this metric evolves over period of time, i.e. maximum value).
As per claims 28, and 33-34, those claims are rejected based on the same rational set forth in the claims 21, and 26-27 respectfully.
As per claims 35, and 40, those claims are rejected based on the same rational set forth in the claims 21 and 27 respectively.
Claim(s) 22 and 29 and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Lokamathe et al US 2019/0109866 and Klawe et al US 2019/0207953 and Kim et al US 2006/0034250 and Torres et al US 2004/0132448.
As per claim 22. Lokamathe and Klawe and Kim discloses the first network apparatus of Claim 21, the combination does not disclose wherein the multicast message is one of the following: a Protocol-Independent Multicast (PIM) hello message; or a Label Distribution Protocol (LDP) message.
However, Torres discloses wherein the multicast message is one of the following: a Protocol-Independent Multicast (PIM) hello message; or a Label Distribution Protocol (LDP) message (0068 The destination host 115, per step 401, requests to join a multicast via an IGMP message or a multicast routing protocol join message (e.g., PIM-SM message)).
Lokamathe and Klawe and Kim and Torres are both considered to be analogous to the claimed invention because they are in the same field of network communication.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lokamathe to incorporate the teachings of Klawe, including the teaching of Kim, including the teaching of Torres and provide an attestation using Type-Length-Value. Doing so would provide structured format enables verifiers to reliably analyze evidence from a device's Trusted Execution Environment (TEE) to make trust decisions, thereby increasing robust validation of platform state by remote verifiers.
As per claim 29, this claim is rejected based on the same rational set forth in the claim 22.
As per claim 36, this claim is rejected based on the same rational set forth in the claim 22.
Claim(s) 23 and 30 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Lokamathe et al US 2019/0109866 and Klawe et al US 2019/0207953 and Kim et al US 2006/0034250 and US Hind et al 6,823,454.
As per claim 23. Lokamathe and Klawe and Kim discloses the first network apparatus of Claim 21, the combination does not disclose the attestation information comprising attestation-capability information associated with the second network apparatus, the operations further comprising determining that the attestation-capability information fails to satisfy a pre-determined attestation-capability requirement.
However, Hind disclose the attestation information comprising attestation-capability information associated with the second network apparatus, the operations further comprising determining that the attestation-capability information fails to satisfy a pre-determined attestation-capability requirement (col 5, lines 60-65 the second device certificate, i.e. attestation, may further comprises a capability indicator indicating whether the address assignment service is authorized to assign addresses. In this case, the received address is not used if the capability indicator is not properly set and col 11, lines 15-25 the device certificate 300 also includes capability indicators 320. Preferably, these capability indicators 320 will comprise an address provider flag 321 and a DNS server flag 322. These capability indicators are used to prevent devices from masquerading as legitimate address providers and DNS servers).
Lokamathe and Klawe and Kim and Hind are both considered to be analogous to the claimed invention because they are in the same field of network communication.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lokamathe to incorporate the teachings of Klawe, including the teaching of Kim, including the teaching of Hind and provide an attestation using Type-Length-Value. Doing so would provide structured format enables verifiers to reliably analyze evidence from a device's Trusted Execution Environment (TEE) to make trust decisions, thereby increasing robust validation of platform state by remote verifiers.
As per claim 30, this claim is rejected based on the same rational set forth in the claim 23.
As per claim 37, this claim is rejected based on the same rational set forth in the claim 23.
Claim(s) 24 and 31 and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Lokamathe et al US 2019/0109866 and Klawe et al US 2019/0207953 and Kim et al US 2006/0034250 and Aissi US 2014/0066015.
As per claim 24. Lokamathe and Klawe and Kim discloses the first network apparatus of Claim 21, the combination does not explicitly disclose the attestation information comprising security level information associated with the second network apparatus, the operations further comprising determining that a security level associated with the second network apparatus fails to satisfy a pre-determined security level threshold.
However, Aissi discloses the attestation information comprising security level information associated with the second network apparatus, the operations further comprising determining that a security level associated with the second network apparatus fails to satisfy a pre-determined security level threshold ( [0078] The Root of Trust may also determine the set of security policies being enforced in mobile device 350, and generate an attestation value indicating the level of security protection being provided by the components of mobile device 350. The Root of Trust may also perform a trusted execution environment discovery to determine the types of trusted execution environment (e.g., presence of a VMM, secure element, etc.) available on mobile device 350, and generate an attestation value indicating the execution environments available on mobile device 350.).
Lokamathe and Klawe and Kim and Aissi are both considered to be analogous to the claimed invention because they are in the same field of network communication.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lokamathe to incorporate the teachings of Klawe, including the teaching of Kim, including the teaching of Aissi and provide an attestation using Type-Length-Value. Doing so would provide structured format enables verifiers to reliably analyze evidence from a device's Trusted Execution Environment (TEE) to make trust decisions, thereby increasing robust validation of platform state by remote verifiers.
As per claim 31, this claim is rejected based on the same rational set forth in the claim 24.
As per claim 38, this claim is rejected based on the same rational set forth in the claim 24.
Claim(s) 25 and 32 and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Lokamathe et al US 2019/0109866 and Klawe et al US 2019/0207953 and Kim et al US 2006/0034250 and Smith et al US 2020/0084202.
As per claim 25. Lokamathe and Klawe and Kim discloses the first network apparatus of Claim 21, the combination does not disclose the attestation information comprising an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state, the operations further comprising determining that the attestation token is invalid for the second network apparatus at a current time.
However, Smith discloses the attestation information comprising an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state, the operations further comprising determining that the attestation token is invalid for the second network apparatus at a current time. ( 0160 the attestation token verification fails (e.g., the token has expired or the current environment differs from the expected environment) then a re-attestation may be required. The ASP 830 is notified regarding the failure and the previous token is invalidated (if not expired); the resource or service provider 840 may be contacted for re-attestation or the resource or service provider 840 may proactively seek re-attestation upon detection of an invalid token).
Lokamathe and Klawe and Kim and Smith are both considered to be analogous to the claimed invention because they are in the same field of network communication.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lokamathe to incorporate the teachings of Klawe, including the teaching of Kim, including the teaching of Smith and provide an attestation using Type-Length-Value. Doing so would provide structured format enables verifiers to reliably analyze evidence from a device's Trusted Execution Environment (TEE) to make trust decisions, thereby increasing robust validation of platform state by remote verifiers.
As per claim 32, this claim is rejected based on the same rational set forth in the claim 25.
As per claim 39, this claim is rejected based on the same rational set forth in the claim 25.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/ Primary Examiner, Art Unit 2496