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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected under 35 U.S.C 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 an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state; and a security level, wherein the security level represents a level of trustworthiness associated with a particular node; determining whether the attestation-capability information fails to satisfy satisfies one or more pre-determined attestation requirements; in response to determining that the attestation-capability information satisfies the one or more pre-determined attestation requirements, determining whether the attestation token is valid; in response to determining that the attestation token is valid, determining whether the security level satisfies a pre-determined security level threshold ;
Examiner respectfully disagrees. WO 2015/047258 discloses disclose an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state; and a security level, wherein the security level represents a level of trustworthiness associated with a particular node ( [0076] In one implementation, a method at a computer platform comprises determining a first strength value for a first network node coupled to the computer platform, wherein the first strength value is based on first attestation information from the first network node, wherein the first attestation information indicates a trustworthiness level of the first network node. The method further comprises performing, with underwriter logic of the computer platform, detecting an indication of a transaction, in response to detecting the indication of the transaction, automatically determining based on the first strength value a first indemnification value representing a cost of an indemnification for the transaction, and sending the first indemnification value to the first node, wherein the first node performs a determination, based on the first indemnification value, of whether a participation in the transaction is to take place. The method further comprises executing a general purpose operating system of the computer platform, wherein access to the underwriter logic by the general purpose operating system is restricted);
determining whether the attestation-capability information fails to satisfy satisfies one or more pre-determined attestation requirements (0077 automatically determining the first indemnification value further comprises determining a value of a completion of the transaction. In another embodiment, automatically determining the first indemnification value is further based on second attestation information which indicates a trustworthiness level of a second network node. In another embodiment, the method further comprises calculating the first strength value based on a complexity metric. In another embodiment, the method further comprises calculating the first strength value based on an immutability metric. In another embodiment, the method further comprises calculating the first strength value based on a path protection metric. In another embodiment, the method further comprises calculating the first strength value based on a profile protection metric. In another embodiment, the underwriter logic comprises a hardware security module. In another embodiment, the underwriter logic comprises a trusted platform module. In another embodiment, the underwriter logic comprises circuitry to provide a security management mode of software execution.);
in response to determining that the attestation-capability information satisfies the one or more pre-determined attestation requirements, determining whether the attestation token is valid([0078] In another implementation, a computer platform comprises a memory to store a first strength value for a first network node coupled to the computer platform, the first strength value based on first attestation information from attestation logic of the first network node, wherein access to the attestation logic by a general purpose operating system of the first network node is restricted, wherein the first attestation information indicates a trustworthiness level of the first network node. The computer platform further comprises underwriter logic to detect an indication of a transaction and, in response to detection of the indication of the transaction, to automatically determine based on the first strength value a first indemnification value to represent a cost of an indemnification for the transaction, the underwriter logic further to send the first indemnification value to the first node, wherein the first node performs a determination, based on the first indemnification value, of whether a participation in the transaction is to take place. );
in response to determining that the attestation token is valid, determining whether the security level satisfies a pre-determined security level threshold (0080 determining a first strength value for a first network node coupled to the computer platform, wherein the first strength value is based on first attestation information from the first network node, wherein the first attestation information indicates a trustworthiness level of the first network node. The method further comprises performing, with underwriter logic of the computer platform, detecting an indication of a transaction, in response to detecting the indication of the transaction, automatically determining based on the first strength value a first indemnification value representing a cost of an indemnification for the transaction, and sending the first indemnification value to the first node, wherein the first node performs a determination, based on the first indemnification value, of whether a participation in the transaction is to take place. The method further comprises executing a general purpose operating system of the computer platform, wherein access to the underwriter logic by the general purpose operating system is restricted);
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 21-40 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 21/28/35, those claims recite the phase “capability”, this phase can be seen as this term is might not have the ability to perform. Thus, the boundary of the attestation is unclear. Thus, this claim is indefinite.
All the dependent claims are rejected based on the same rational set forth in the above claims respectively.
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).
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 Smith Ned M W0 2015/047258( hereafter Smith).
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 an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state; and a security level, wherein the security level represents a level of trustworthiness associated with a particular node; determining whether the attestation-capability information fails to satisfy satisfies one or more pre-determined attestation requirements; in response to determining that the attestation-capability information satisfies the one or more pre-determined attestation requirements, determining whether the attestation token is valid; in response to determining that the attestation token is valid, determining whether the security level satisfies a pre-determined security level threshold ;
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 an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state; and a security level, wherein the security level represents a level of trustworthiness associated with a particular node; determining whether the attestation-capability information fails to satisfy satisfies one or more pre-determined attestation requirements; in response to determining that the attestation-capability information satisfies the one or more pre-determined attestation requirements, determining whether the attestation token is valid; in response to determining that the attestation token is valid, determining whether the security level satisfies a pre-determined security level threshold ;
However, Smith discloses disclose an attestation token, wherein the attestation token is for proving that the second network apparatus is in a known safe state; and a security level, wherein the security level represents a level of trustworthiness associated with a particular node ( [0076] In one implementation, a method at a computer platform comprises determining a first strength value for a first network node coupled to the computer platform, wherein the first strength value is based on first attestation information from the first network node, wherein the first attestation information indicates a trustworthiness level of the first network node. The method further comprises performing, with underwriter logic of the computer platform, detecting an indication of a transaction, in response to detecting the indication of the transaction, automatically determining based on the first strength value a first indemnification value representing a cost of an indemnification for the transaction, and sending the first indemnification value to the first node, wherein the first node performs a determination, based on the first indemnification value, of whether a participation in the transaction is to take place. The method further comprises executing a general purpose operating system of the computer platform, wherein access to the underwriter logic by the general purpose operating system is restricted);
determining whether the attestation-capability information fails to satisfy satisfies one or more pre-determined attestation requirements (0077 automatically determining the first indemnification value further comprises determining a value of a completion of the transaction. In another embodiment, automatically determining the first indemnification value is further based on second attestation information which indicates a trustworthiness level of a second network node. In another embodiment, the method further comprises calculating the first strength value based on a complexity metric. In another embodiment, the method further comprises calculating the first strength value based on an immutability metric. In another embodiment, the method further comprises calculating the first strength value based on a path protection metric. In another embodiment, the method further comprises calculating the first strength value based on a profile protection metric. In another embodiment, the underwriter logic comprises a hardware security module. In another embodiment, the underwriter logic comprises a trusted platform module. In another embodiment, the underwriter logic comprises circuitry to provide a security management mode of software execution.);
in response to determining that the attestation-capability information satisfies the one or more pre-determined attestation requirements, determining whether the attestation token is valid([0078] In another implementation, a computer platform comprises a memory to store a first strength value for a first network node coupled to the computer platform, the first strength value based on first attestation information from attestation logic of the first network node, wherein access to the attestation logic by a general purpose operating system of the first network node is restricted, wherein the first attestation information indicates a trustworthiness level of the first network node. The computer platform further comprises underwriter logic to detect an indication of a transaction and, in response to detection of the indication of the transaction, to automatically determine based on the first strength value a first indemnification value to represent a cost of an indemnification for the transaction, the underwriter logic further to send the first indemnification value to the first node, wherein the first node performs a determination, based on the first indemnification value, of whether a participation in the transaction is to take place. );
in response to determining that the attestation token is valid, determining whether the security level satisfies a pre-determined security level threshold (0080 determining a first strength value for a first network node coupled to the computer platform, wherein the first strength value is based on first attestation information from the first network node, wherein the first attestation information indicates a trustworthiness level of the first network node. The method further comprises performing, with underwriter logic of the computer platform, detecting an indication of a transaction, in response to detecting the indication of the transaction, automatically determining based on the first strength value a first indemnification value representing a cost of an indemnification for the transaction, and sending the first indemnification value to the first node, wherein the first node performs a determination, based on the first indemnification value, of whether a participation in the transaction is to take place. The method further comprises executing a general purpose operating system of the computer platform, wherein access to the underwriter logic by the general purpose operating system is restricted);
Lokamathe and Klawe 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 Smith and indicates a trustworthiness level of a second network node. Doing so would be improving the security of the communication between devices.
As per claim 26. Lokamathe and Klawe and Smith 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 Smith 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 Smith and Torres et al US 2004/0132448.
As per claim 22. Lokamathe and Klawe and Smith 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 Smith 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 Smith, including the teaching of Torres and indicates a trustworthiness level of a second network node. Doing so would be improving the security of the communication between devices.
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.
Allowable Subject Matter
Claims 23-25,30-32 and 37-39 are would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 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
Prosecution Insights