CTNF 18/874,831 CTNF 95514 DETAILED ACTION 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. The present application, filed on December 13, 2024, is accepted. Claims 71 – 90 are being considered on the merits. Drawings The drawings, filed on December 13, 2024, are accepted. Specification The specification, filed on December 13, 2024, is accepted. Double Patenting No rejection warranted at application’s initial filling time of filling for a patent. Claim Objections 07-29-01 AIA Claim 80 is objected to because of the following informalities: In Claim 80, it recites “The second TLS device according to any one of claims 77” and there’s only a claim 77 listed . Appropriate correction is required. Claim Rejections - 35 USC § 112 Claims 78, 79, and 86-90 are rejected under 35 U.S.C. 112(b) 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. Claim 78 recites the limitation “the first signature” in line 1. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination, “the first signature” is considered as “a first signature”. Claims 79 and 86 recite the limitation “the second credential type request message” in line 1. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination, “the second credential type request message” is considered as “a second credential type request message”. Claim 90 recites the limitation “the first VC comprises an assertion on the second TLS device” in line 1. However, in the context of claim 86, the first VC is: Received by the first TLS device from a trusted entity, Sent by the first TLS device to the second TLS device, Used to authenticate the first TLS device. Logically, the assertion within the first VC should be about the first TLS device (i.e., the entity being authenticated), not the second. For the purpose of examination, “the first VC comprises an assertion on the second TLS device” is considered as “the first VC comprises an assertion on the first TLS device”. The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-20-aia AIA 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. 07-21-aia AIA Claim s 71 –90 are rejected under 35 U.S.C. 103 as being unpatentable over US 11316700 B1 to Michaelis et al., (hereinafter, “Michaelis”) in view of “Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)” to Wouters et al., (hereinafter, “Wouters”) and “Verifiable Credentials Data Model v1.1” to Sporney et al., (hereinafter, “Sporney”) and Regarding claim 71, Michaelis teaches a method for supporting authentication of a first Transport Layer Security (TLS) device, the method being performed by a second TLS device and comprising: receiving a first credential type indication message from the first TLS device, [Michaelis, col. 12 lines 32 – 36 discloses a user of requesting entity, such as a user of user device 104, a node, etc., requests access to the resource by sending a request to access policy evaluator node 106 via local-area network 124 (if applicable) and wide-area network 122.] and wherein the credential type is Verifiable Credential (VC); [Michaelis, col. 12 lines 19 – 31 discloses the issuer entity may generate a verifiable credential each for one or more users based on the verifiable credential template and particulars of each user, respectively. For example, the issuer entity may generate a verifiable credential naming John Smith as a user, that John Smith possesses a top-secret security clearance, and a photograph of John Smith. The issuer entity cryptographically signs the verifiable credential with a private key of the issuer's DID and then provides the signed, verifiable credential it to John Smith via wide-area network 122, local-area network 124 (if applicable) and user device 104 where it is stored in memory 202, providing protection against a 3rd party accessing and using the signed, verifiable credential.] , but Michaelis does not teach wherein the first credential type indication message is indicative of a credential type to use for authenticating the first TLS device, receiving, from the first TLS device, a first VC, first presentation metadata, and a first Verifiable Presentation (VP) proof for verifying the first TLS device; authenticating the first TLS device using the first VC, the first presentation metadata, and the first VP proof. However, Wouters does teach wherein the first credential type indication message is indicative of a credential type to use for authenticating the first TLS device, [Wouters, page 3 – 4 section 3 discloses the two TLS extensions client_certificate_type and server_certificate_type, which can be used as part of an extended TLS handshake when raw public keys are used… This specification uses raw public keys whereby the already available encoding used in a PKIX certificate in the form of a SubjectPublicKeyInfo structure is reused. To carry the raw public key within the TLS handshake, the Certificate payload is used as a container. (Examiner noted that the client_certificate_type and server_certificate_type TLS extensions, which allow TLS peers to negotiate the credential type to be used for authentication during the TLS handshake. It defines an extensible framework where new credential types can be registered.)] Therefore, it would be obvious to one of ordinary skill within the art before the effective filling date to combine Wouters’s system with Michaelis’s system, with a motivation for introduces the use of raw public keys in TLS/DTLS. With raw public keys, only a subset of the information found in typical certificates is utilized: namely, the SubjectPublicKeyInfo structure of a PKIX certificate that carries the parameters necessary to describe the public key. Other parameters found in PKIX certificates are omitted. By omitting various certificate-related structures, the resulting raw public key is kept fairly small in comparison to the original certificate, and the code to process the keys can be simpler. [Wouters, page 2 section 1] However, Michaelis in view of Wouters does not teach receiving, from the first TLS device, a first VC, first presentation metadata, and a first Verifiable Presentation (VP) proof for verifying the first TLS device; authenticating the first TLS device using the first VC, the first presentation metadata, and the first VP proof, but Sporney does teach receiving, from the first TLS device, a first VC, first presentation metadata, and a first Verifiable Presentation (VP) proof for verifying the first TLS device; [Sporney, section 4.7 discloses At least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential or presentation to be a verifiable credential or verifiable presentation; that is, to be verifiable. This specification identifies two classes of proof mechanisms: external proofs and embedded proofs. An external proof is one that wraps an expression of this data model, such as a JSON Web Token, which is elaborated on in Section 6.3.1 JSON Web Token. An embedded proof is a mechanism where the proof is included in the data, such as a Linked Data Signature, which is elaborated upon in Section 6.3.2 Data Integrity Proofs. a mathematical proof varies by representation language and the technology used, the set of name-value pairs that is expected as the value of the proof property will vary accordingly. For example, if digital signatures are used for the proof mechanism, the proof property is expected to have name-value pairs that include a signature, a reference to the signing entity, and a representation of the signing date. The example below uses RSA digital signatures. Section 4.10 discloses Presentations MAY be used to combine and present credentials. They can be packaged in such a way that the authorship of the data is verifiable. The data in a presentation is often all about the same subject, but there is no limit to the number of subjects or issuers in the data. The aggregation of information from multiple verifiable credentials is a typical use of verifiable presentations. A verifiable presentation is typically composed of the following properties: id - The id property is optional and MAY be used to provide a unique identifier for the presentation. For details related to the use of this property, see Section 4.2 Identifiers. Type - The type property is required and expresses the type of presentation, such as VerifiablePresentation. For details related to the use of this property, see Section 4.3 Types. verifiableCredential-If present, the value of the verifiableCredential property MUST be constructed from one or more verifiable credentials, or of data derived from verifiable credentials in a cryptographically verifiable format. Holder-If present, the value of the holder property is expected to be a URI for the entity that is generating the presentation. Proof-If present, the value of the proof property ensures that the presentation is verifiable. For details related to the use of this property, see Section 4.7 Proofs (Signatures).] authenticating the first TLS device using the first VC, the first presentation metadata, and the first VP proof. [Sporney, section 4.7 discloses a mathematical proof varies by representation language and the technology used, the set of name-value pairs that is expected as the value of the proof property will vary accordingly. For example, if digital signatures are used for the proof mechanism, the proof property is expected to have name-value pairs that include a signature, a reference to the signing entity, and a representation of the signing date. The example below uses RSA digital signatures. Section 4.10.1 discloses Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold claims from a verifiable credential without revealing the verifiable credential itself. In these schemes, a claim from a verifiable credential might be used to derive a presented value, which is cryptographically asserted such that a verifier can trust the value if they trust the issuer.] Therefore, it would be obvious to one of ordinary skill within the art before the effective filling date to combine Sporney’s system with Michaelis’s system, with a motivation for A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance. [ Sporney , section 1.1] AS per claim 72, modified Michaelis teaches the method according to claim 71, wherein the first VP proof comprises a first signature. [Michaelis, col. 32 lines 51 – 67 to col. 33 lines 1 – 3 discloses a cryptographic block is created from the validation list, comprising a block header that comprises an identifier of this block for the purpose of e.g. caching published blocks, a locality, or list of localities in form of one or more UUIDs of the proposals validated and contained in the block, the validation list of cryptographic hashes for each proposal/transaction, and proposal/transaction meta-data, such as cluster IDs, localities, and node identifiers, such as node DIDs, associated with the routing node performance metrics/scores. The ledger nodes each sign the block header, and their signatures are added into the block. The meta-data in each block header allows a transaction-reading node, such as any member node in system 500, to only retrieve block elements of interest, e.g. performance metrics/routing paths involving nodes of a particular locality UUID or set of UUIDs. Each routing node information proposals can be verified individually by a transaction-reading node (such as a manager node) from the block header and the validator nodes' signatures in the header] As per claim 73, modified Michaelis teaches the method according to claim 72, wherein the first signature is generated based on at least the first credential type indication message, the first VC, the first presentation metadata, and the first VP proof. [Michaelis, col. 32 lines 51 – 67 to col. 33 lines 1 – 3 discloses a cryptographic block is created from the validation list, comprising a block header that comprises an identifier of this block for the purpose of e.g. caching published blocks, a locality, or list of localities in form of one or more UUIDs of the proposals validated and contained in the block, the validation list of cryptographic hashes for each proposal/transaction, and proposal/transaction meta-data, such as cluster IDs, localities, and node identifiers, such as node DIDs, associated with the routing node performance metrics/scores. The ledger nodes each sign the block header, and their signatures are added into the block. The meta-data in each block header allows a transaction-reading node, such as any member node in system 500, to only retrieve block elements of interest, e.g. performance metrics/routing paths involving nodes of a particular locality UUID or set of UUIDs. Each routing node information proposals can be verified individually by a transaction-reading node (such as a manager node) from the block header and the validator nodes' signatures in the header] As per claim 74, modified Michaelis teaches the method according to claim 73, wherein the first signature is generated further based on one or more additional messages received by the first TLS device from the second TLS device and/or sent by the first TLS device to the second TLS device. [Michaelis, col. 22 lines 45 – 57 discloses an HMAC (sometimes referred to as either a keyed-hash message authentication code or a hash-based message authentication code) is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both data integrity and authenticity of a message. HMAC can provide message authentication using a shared secret instead of using digital signatures with asymmetric cryptography. It trades off the need for a complex public key infrastructure by delegating the key exchange to nodes that are responsible for establishing and using a trusted channel to agree on the key prior to communication.] Regarding claim 75, modified Michaelis teaches the method according to claim 71, but Michaelis does not teach wherein the second TLS device is authenticated by the first TLS device with the credential type X.509. However, Wouters does teach wherein the second TLS device is authenticated by the first TLS device with the credential type X.509. [Wouters, page 11 section 5.3 discloses the client uses a raw public key for client authentication, and the server provides an X.509 certificate. This exchange starts with the client indicating its ability to process an X.509 certificate, OpenPGP certificate, or a raw public key, if provided by the server. It prefers a raw public key, since the RawPublicKey value precedes the other values in the server_certificate_type vector.] Therefore, it would be obvious to one of ordinary skill within the art before the effective filling date to combine Wouters’s system with Michaelis’s system, with a motivation for introduces the use of raw public keys in TLS/DTLS. With raw public keys, only a subset of the information found in typical certificates is utilized: namely, the SubjectPublicKeyInfo structure of a PKIX certificate that carries the parameters necessary to describe the public key. Other parameters found in PKIX certificates are omitted. By omitting various certificate-related structures, the resulting raw public key is kept fairly small in comparison to the original certificate, and the code to process the keys can be simpler. [Wouters, page 2 section 1] Regarding claim 76, Michaelis teaches a method for supporting authentication of a first Transport Layer Security (TLS) device, the method being performed by the first TLS device and comprising: receiving a first Verifiable Credential (VC) from a trusted entity; [Michaelis, col. 12 line 19 – 31 discloses the issuer entity may generate a verifiable credential each for one or more users based on the verifiable credential template and particulars of each user, respectively. For example, the issuer entity may generate a verifiable credential naming John Smith as a user, that John Smith possesses a top-secret security clearance, and a photograph of John Smith. The issuer entity cryptographically signs the verifiable credential with a private key of the issuer's DID and then provides the signed, verifiable credential it to John Smith via wide-area network 122, local-area network 124 (if applicable) and user device 104 where it is stored in memory 202, providing protection against a 3rd party accessing and using the signed, verifiable credential.] sending a first credential type indication message to a second TLS device, [Michaelis, col. 12 lines 32 – 36 discloses a user of requesting entity, such as a user of user device 104, a node, etc., requests access to the resource by sending a request to access policy evaluator node 106 via local-area network 124 (if applicable) and wide-area network 122.] wherein the first credential type indication message comprises an indication of a credential type to use for authenticating the first TLS device, [Michaelis, col. 12 lines 36 – 39 discloses The request comprises an identification of the requested resource, in one embodiment a DID of the resource, an identity of the user (which may also be a DID assigned to the user), and the verifiable credential of the user.] wherein the credential type is Verifiable Credential (VC); [Michaelis, col. 12 lines 19 – 31 discloses the issuer entity may generate a verifiable credential each for one or more users based on the verifiable credential template and particulars of each user, respectively. For example, the issuer entity may generate a verifiable credential naming John Smith as a user, that John Smith possesses a top-secret security clearance, and a photograph of John Smith. The issuer entity cryptographically signs the verifiable credential with a private key of the issuer's DID and then provides the signed, verifiable credential it to John Smith via wide-area network 122, local-area network 124 (if applicable) and user device 104 where it is stored in memory 202, providing protection against a 3rd party accessing and using the signed, verifiable credential.] and sending the first VC, the first presentation metadata, and the first VP proof to the second TLS device. [Michaelis, col. 12 lines 32 – 36 discloses a user of requesting entity, such as a user of user device 104, a node, etc., requests access to the resource by sending a request to access policy evaluator node 106 via local-area network 124 (if applicable) and wide-area network 122. The request comprises an identification of the requested resource, in one embodiment a DID of the resource, an identity of the user (which may also be a DID assigned to the user), and the verifiable credential of the user.] , but Michaelis does not teach generating first presentation metadata and a first VP proof; However, Sporney does teach generating first presentation metadata and a first VP proof; [Sporney, section 4.7 discloses a mathematical proof varies by representation language and the technology used, the set of name-value pairs that is expected as the value of the proof property will vary accordingly. For example, if digital signatures are used for the proof mechanism, the proof property is expected to have name-value pairs that include a signature, a reference to the signing entity, and a representation of the signing date. The example below uses RSA digital signatures. Section 4.10.1 discloses Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold claims from a verifiable credential without revealing the verifiable credential itself. In these schemes, a claim from a verifiable credential might be used to derive a presented value, which is cryptographically asserted such that a verifier can trust the value if they trust the issuer.] Therefore, it would be obvious to one of ordinary skill within the art before the effective filling date to combine Sporney’s system with Michaelis’s system, with a motivation for A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance. [ Sporney , section 1.1] Regarding claim 77, it recites features similar to features within claim 71, therefore, it is rejected in a similar manner. Regarding claim 78, it recites features similar to features within claim 74, therefore, it is rejected in a similar manner. Regarding claim 79, modified Michaelis teaches the second TLS device according to claim 77, wherein the processing circuitry causes the second TLS device to be operative to: send a second credential type indication message to the first TLS device, [Michaelis, col. 12 lines 32 – 36 discloses a user of requesting entity, such as a user of user device 104, a node, etc., requests access to the resource by sending a request to access policy evaluator node 106 via local-area network 124 (if applicable) and wide-area network 122.] , but Michaelis does not teach wherein the second credential type request message comprises an indication of a credential type to use for authenticating the second TLS device. However, Wouters does teach wherein the second credential type request message comprises an indication of a credential type to use for authenticating the second TLS device. [Wouters, page 3 – 4 section 3 discloses the two TLS extensions client_certificate_type and server_certificate_type, which can be used as part of an extended TLS handshake when raw public keys are used… This specification uses raw public keys whereby the already available encoding used in a PKIX certificate in the form of a SubjectPublicKeyInfo structure is reused. To carry the raw public key within the TLS handshake, the Certificate payload is used as a container. (Examiner noted that the client_certificate_type and server_certificate_type TLS extensions, which allow TLS peers to negotiate the credential type to be used for authentication during the TLS handshake. It defines an extensible framework where new credential types can be registered.)] Therefore, it would be obvious to one of ordinary skill within the art before the effective filling date to combine Wouters’s system with Michaelis’s system, with a motivation for introduces the use of raw public keys in TLS/DTLS. With raw public keys, only a subset of the information found in typical certificates is utilized: namely, the SubjectPublicKeyInfo structure of a PKIX certificate that carries the parameters necessary to describe the public key. Other parameters found in PKIX certificates are omitted. By omitting various certificate-related structures, the resulting raw public key is kept fairly small in comparison to the original certificate, and the code to process the keys can be simpler. [Wouters, page 2 section 1] Regarding claim 80, modified Michaelis teaches the second TLS device according to any one of claims 77, wherein the processing circuitry causes the second TLS device to be operative to: receive a second VC from a trusted entity; [Michaelis, col. 12 line 19 – 31 discloses the issuer entity may generate a verifiable credential each for one or more users based on the verifiable credential template and particulars of each user, respectively. For example, the issuer entity may generate a verifiable credential naming John Smith as a user, that John Smith possesses a top-secret security clearance, and a photograph of John Smith. The issuer entity cryptographically signs the verifiable credential with a private key of the issuer's DID and then provides the signed, verifiable credential it to John Smith via wide-area network 122, local-area network 124 (if applicable) and user device 104 where it is stored in memory 202, providing protection against a 3rd party accessing and using the signed, verifiable credential.] and send the second VC, the second presentation metadata, and the second VP proof to the first TLS device. [Michaelis, col. 12 lines 32 – 36 discloses a user of requesting entity, such as a user of user device 104, a node, etc., requests access to the resource by sending a request to access policy evaluator node 106 via local-area network 124 (if applicable) and wide-area network 122. The request comprises an identification of the requested resource, in one embodiment a DID of the resource, an identity of the user (which may also be a DID assigned to the user), and the verifiable credential of the user.] , but Michaelis does not teach generate a second VP proof for verifying the second TLS device and a second presentation metadata; However, Sporney does teach generate a second VP proof for verifying the second TLS device and a second presentation metadata; [Sporney, section 4.7 discloses a mathematical proof varies by representation language and the technology used, the set of name-value pairs that is expected as the value of the proof property will vary accordingly. For example, if digital signatures are used for the proof mechanism, the proof property is expected to have name-value pairs that include a signature, a reference to the signing entity, and a representation of the signing date. The example below uses RSA digital signatures. Section 4.10.1 discloses Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold claims from a verifiable credential without revealing the verifiable credential itself. In these schemes, a claim from a verifiable credential might be used to derive a presented value, which is cryptographically asserted such that a verifier can trust the value if they trust the issuer.] Therefore, it would be obvious to one of ordinary skill within the art before the effective filling date to combine Sporney’s system with Michaelis’s system, with a motivation for A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance. [ Sporney , section 1.1] As per claim 81, modified Michaelis teaches the second TLS device according to claim 80, wherein the second VC comprises an assertion on the second TLS device, a second credential metadata, and a second VC proof for verifying the trusted entity which issued the second VC. [Michaelis, col. 12 line 19 – 31 discloses the issuer entity may generate a verifiable credential each for one or more users based on the verifiable credential template and particulars of each user, respectively. For example, the issuer entity may generate a verifiable credential naming John Smith as a user, that John Smith possesses a top-secret security clearance, and a photograph of John Smith. The issuer entity cryptographically signs the verifiable credential with a private key of the issuer's DID and then provides the signed, verifiable credential it to John Smith via wide-area network 122, local-area network 124 (if applicable) and user device 104 where it is stored in memory 202, providing protection against a 3rd party accessing and using the signed, verifiable credential.] Regarding claim 82, it recites features similar to features within claim 72, therefore, it is rejected in a similar manner. Regarding claim 83, it recites features similar to features within claim 73, therefore, it is rejected in a similar manner. Regarding claim 84, it recites features similar to features within claim 74, therefore, it is rejected in a similar manner. Regarding claim 85, it recites features similar to features within claim 75, therefore, it is rejected in a similar manner. Regarding claim 86, it recites features similar to features within claim 76, therefore, it is rejected in a similar manner. Regarding claim 87, modified Michaelis teaches the first TLS device according to claim 86, but Michaelis does not teach wherein the first TLS device sends the first VC, the first presentation metadata, and the first VP proof in a same message. However, Sporney does teach wherein the first TLS device sends the first VC, the first presentation metadata, and the first VP proof in a same message. [Sporney, section 4.7 discloses a mathematical proof varies by representation language and the technology used, the set of name-value pairs that is expected as the value of the proof property will vary accordingly. For example, if digital signatures are used for the proof mechanism, the proof property is expected to have name-value pairs that include a signature, a reference to the signing entity, and a representation of the signing date. The example below uses RSA digital signatures. Section 4.10.1 discloses Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold claims from a verifiable credential without revealing the verifiable credential itself. In these schemes, a claim from a verifiable credential might be used to derive a presented value, which is cryptographically asserted such that a verifier can trust the value if they trust the issuer.] Therefore, it would be obvious to one of ordinary skill within the art before the effective filling date to combine Sporney’s system with Michaelis’s system, with a motivation for A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance. [ Sporney , section 1.1] Regarding claim 88, modified Michaelis teaches the first TLS device according to claim 86, but Michaelis does not teach wherein the first TLS device sends the first VC, the first presentation metadata, and the first VP proof in separate messages. However, Sporney does teach wherein the first TLS device sends the first VC, the first presentation metadata, and the first VP proof in separate messages. [Sporney, section 4.7 discloses a mathematical proof varies by representation language and the technology used, the set of name-value pairs that is expected as the value of the proof property will vary accordingly. For example, if digital signatures are used for the proof mechanism, the proof property is expected to have name-value pairs that include a signature, a reference to the signing entity, and a representation of the signing date. The example below uses RSA digital signatures. Section 4.10.1 discloses Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold claims from a verifiable credential without revealing the verifiable credential itself. In these schemes, a claim from a verifiable credential might be used to derive a presented value, which is cryptographically asserted such that a verifier can trust the value if they trust the issuer.] Therefore, it would be obvious to one of ordinary skill within the art before the effective filling date to combine Sporney’s system with Michaelis’s system, with a motivation for A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance. [ Sporney , section 1.1] Regarding claim 89, it recites features similar to features within claim 72, therefore, it is rejected in a similar manner. As per claim 90, modified Michaelis teaches the first TLS device according to claim 86, wherein the first VC comprises an assertion on the second TLS device, a first credential metadata, and a first VC proof for verifying the trusted entity which issued the first VC. [Michaelis, col. 12 line 19 – 31 discloses the issuer entity may generate a verifiable credential each for one or more users based on the verifiable credential template and particulars of each user, respectively. For example, the issuer entity may generate a verifiable credential naming John Smith as a user, that John Smith possesses a top-secret security clearance, and a photograph of John Smith. The issuer entity cryptographically signs the verifiable credential with a private key of the issuer's DID and then provides the signed, verifiable credential it to John Smith via wide-area network 122, local-area network 124 (if applicable) and user device 104 where it is stored in memory 202, providing protection against a 3rd party accessing and using the signed, verifiable credential.] Conclusion Pertinent prior art made of record however not relied upon: US 20220377084 A1 to Zhang et al. “A verifier device in one embodiment is configured to communicate over one or more networks with a client device and a server device. The verifier device participates in a three-party handshake protocol with the client device and the server device in which the verifier device and the client device obtain respective shares of a session key of a secure session with the server device. The verifier device receives from the client device a commitment relating to the secure session with the server device, and responsive to receipt of the commitment, releases to the client device additional information relating to the secure session that was not previously accessible to the client device. The verifier device verifies correctness of at least one characterization of data obtained by the client device from the server device as part of the secure session, based at least in part on the commitment and the additional information.” Any inquiry concerning this communication or earlier communications from the examiner should be directed to Phuc Pham whose telephone number is (571)272-8893. The examiner can normally be reached Monday - Thursday 7:30 AM - 4:30 PM; Friday 8:00 AM - 12:00 PM. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached at (571) 270-5440. 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. /P.P./Patent Examiner, Art Unit 2408 /LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408 Application/Control Number: 18/874,831 Page 2 Art Unit: 2408 Application/Control Number: 18/874,831 Page 3 Art Unit: 2408 Application/Control Number: 18/874,831 Page 4 Art Unit: 2408 Application/Control Number: 18/874,831 Page 5 Art Unit: 2408 Application/Control Number: 18/874,831 Page 6 Art Unit: 2408 Application/Control Number: 18/874,831 Page 7 Art Unit: 2408 Application/Control Number: 18/874,831 Page 8 Art Unit: 2408 Application/Control Number: 18/874,831 Page 9 Art Unit: 2408 Application/Control Number: 18/874,831 Page 10 Art Unit: 2408 Application/Control Number: 18/874,831 Page 11 Art Unit: 2408 Application/Control Number: 18/874,831 Page 12 Art Unit: 2408 Application/Control Number: 18/874,831 Page 13 Art Unit: 2408 Application/Control Number: 18/874,831 Page 14 Art Unit: 2408 Application/Control Number: 18/874,831 Page 15 Art Unit: 2408 Application/Control Number: 18/874,831 Page 16 Art Unit: 2408 Application/Control Number: 18/874,831 Page 17 Art Unit: 2408 Application/Control Number: 18/874,831 Page 18 Art Unit: 2408 Application/Control Number: 18/874,831 Page 19 Art Unit: 2408 Application/Control Number: 18/874,831 Page 20 Art Unit: 2408 Application/Control Number: 18/874,831 Page 21 Art Unit: 2408
Prosecution Insights