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 .
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 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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/03/2024 has been considered by the examiner.
Restriction/Interview Election
REQUIREMENT FOR UNITY OF INVENTION
As provided in 37 CFR 1.475(a), a national stage application shall relate to one invention only or to a group of inventions so linked as to form a single general inventive concept (“requirement of unity of invention”). Where a group of inventions is claimed in a national stage application, the requirement of unity of invention shall be fulfilled only when there is a technical relationship among those inventions involving one or more of the same or corresponding special technical features. The expression “special technical features” shall mean those technical features that define a contribution which each of the claimed inventions, considered as a whole, makes over the prior art.
The determination whether a group of inventions is so linked as to form a single general inventive concept shall be made without regard to whether the inventions are claimed in separate claims or as alternatives within a single claim. See 37 CFR 1.475(e).
When Claims Are Directed to Multiple Categories of Inventions:
As provided in 37 CFR 1.475 (b), a national stage application containing claims to different categories of invention will be considered to have unity of invention if the claims are drawn only to one of the following combinations of categories:
(1) A product and a process specially adapted for the manufacture of said product; or
(2) A product and a process of use of said product; or
(3) A product, a process specially adapted for the manufacture of the said product, and a use of the said product; or
(4) A process and an apparatus or means specifically designed for carrying out the said process; or
(5) A product, a process specially adapted for the manufacture of the said product, and an apparatus or means specifically designed for carrying out the said process.
Otherwise, unity of invention might not be present. See 37 CFR 1.475 (c).
Restriction is required under 35 U.S.C. 121 and 372.
This application contains the following inventions or groups of inventions which are not so linked as to form a single general inventive concept under PCT Rule 13.1.
In accordance with 37 CFR 1.499, applicant is required, in reply to this action, to elect a single invention to which the claims must be restricted.
Group I, claim(s) 1-8 and 11-15, drawn to generating an endorsement of a private attestation.
Group II, claim(s) 9-10, drawn to generating a pre-endorsement using a PAP challenge.
Groups I and II lack unity of invention because even though the inventions of these groups require the technical features of “binding a user of the connected device to the Attestation, by: collecting a set of user certified attribute names from said attributes selected by the user, authenticating the user to the Issuing Authority, generating a key pair for the user, comprising a public key (PuK) and a private key (PrK), transmitting said public key (PuK) to said Issuing Authority; and binding pivotal attributes to equivalent attributes of an Issuing Authority, by: requesting the Issuing Authority for its authorization to endorse said Attestation based on it validating said set of user certified attribute names, and if validated, receiving from said Issuing Authority a signed Server Proof”, this technical feature is not a special technical feature as it does not make a contribution over the prior art in view of Toth (US20190097812). See as presented with specificity hereinbelow with regards 35 U.S.C. 102.
During a telephone conversation with Marc Boillot on 11/25/2025 and follow-up email on 11/26/2025 a provisional election was made without traverse to prosecute the invention of Group I, claims 1-8 and 11-15. Affirmation of this election must be made by applicant in replying to this Office action. Claim(s) 9-10 is/are withdrawn from further consideration by the examiner, 37 CFR 1.142(b), as being drawn to a non-elected invention.
Applicant is reminded that upon the cancelation of claims to a non-elected invention, the inventorship must be corrected in compliance with 37 CFR 1.48(a) if one or more of the currently named inventors is no longer an inventor of at least one claim remaining in the application. A request to correct inventorship under 37 CFR 1.48(a) must be accompanied by an application data sheet in accordance with 37 CFR 1.76 that identifies each inventor by his or her legal name and by the processing fee required under 37 CFR 1.17(i).
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “110” has been used to designate both “PAP 110” (see, e.g., [0028]), “touchless sensing unit 110” (see [0062]), and “Mobile Device 110” (see [0069]).
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description: “224” (see fig. 2), “226” (see fig. 2), and “726” (see fig. 7).
Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claim(s) 1, 3-4, 6-7, 11, 13, and 15 is/are objected to because of the following informalities:
Claim 1 recites “requesting the Issuing Authority to authorize user […]” in line 17. For grammatical consistency, Examiner suggests amending to, e.g., “requesting the Issuing Authority said user […]” or similar, if intended. Claims 3 recite a similar deficiency, are rejected under like rationale.
Claim 1 recites “if validated, receiving […]” in lines 20-21. Claim limitations must be positively recited. Examiner suggests amending to, e.g., “when validated, receiving […]” or similar, if intended. Claims 3, 13, and 15 recite a similar deficiency, and are objected to under like rationale.
Claim 1 recites “and an optional PAP signature” in line 5. Claim limitations must be positively recited (unless removed). Claim 4 recites a similar deficiency, and is objected to under like rationale.
Claim 6 recites “of a user of said connected device” in lines 4-5. Examiner suggests amending to, e.g., “to the
Claim 11 recites “a system […] comprising: […] a Private Attribute Provider (PAP) provides an Attestation […]” in lines 1-6. This is grammatically inconsistent. Examiner suggests amending to, e.g., “a system […] comprising: […] a Private Attribute Provider (PAP), wherein the PAP provides an Attestation […]” or similar, if intended.
Appropriate correction is required.
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.
Claim(s) 1-8 and 11-15 is/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. Particularly:
Claim 1 recites the limitation "and endorse said Attestation based on it validating […]" [emphasis added] in lines 17-18. Claim elements must be explicitly referenced, and there is unclear antecedent basis for “it” in the claim. Claims 11, 13, and 15 recite a similar deficiency, and are rejected under like rationale. Claims 2-8 and 12-14 incorporate the deficiency of their parent claim, and are rejected under like rationale. Further, claim 15 recites “and endorse said Attestation based on it, validating […]” [emphasis added] – and is grammatically inconsistent.
Claim 1 recites “said attributes selected by the user” in lines 9-10. There is insufficient/unclear antecedent basis for this limitation in the claim (e.g., is this referring the Attestation attributes of line 4? Selection/Selected attributed have not been introduced). Claims 12 and 15 recite a similar deficiency, and are rejected under like rationale. Claims 2-8 and 13-14 incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 3 recites “the Server Proof” in line 9. There is insufficient antecedent basis for this limitation in the claim. Claim 14 recites a similar deficiency, and is rejected under like rationale. Claims 4-5 incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 4 recites “said Endorsed Attestation” in line 1. There is insufficient antecedent basis for this limitation in the claim. Claim 5 incorporates the deficiency of its parent claim, and is rejected under like rationale. Claims 7-8 recite a similar deficiency, and are rejected under like rationale.
Claim 4 recites “said Mobile Signed Blob” in line 4. There is insufficient antecedent basis for this limitation in the claim. Claim 5 incorporates the deficiency of its parent claim, and is rejected under like rationale.
Claim 4 recites “said Verifier Blob” in line 5. There is insufficient antecedent basis for this limitation in the claim. Claim 5 incorporates the deficiency of its parent claim, and is rejected under like rationale.
Claim 4 recites “said Verifier Challenge” in line 8. There is insufficient antecedent basis for this limitation in the claim. Claim 5 incorporates the deficiency of its parent claim, and is rejected under like rationale.
Claim 6 recites “said step of checking a validity […]” in lines 1-2. There is insufficient antecedent basis for this limitation in the claim.
Claim 7 recites “wherein the access to said service” in line 1. There is insufficient antecedent basis for the limitations “the access” and “said service” in the claim.
Claim 7 recites “said device key” in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 7 recites "or other conditional measure" in lines 4-5. This renders the claim(s) indefinite because the claim(s) include(s) elements not actually disclosed (those encompassed by "or other conditional measure"), thereby rendering the scope of the claim(s) unascertainable. See MPEP § 2173.05(d). Claim 8 recites a similar deficiency, and is rejected under like rationale.
Claim 11 recites “binds the user […]” in line 10, as well as “binds pivotal attributes […]” in line 11. Subsequently, claim 11 recites “where responsive to said bindings, […]”. There is unclear antecedent basis as to which of the first or second introduced “binds” are being referred to by “said bindings”. Claims 12-14 incorporate the deficiency of their parent claim, and are rejected under like rationale.
Consideration Under 35 USC § 101
Note: the claims have been considered and analyzed by the Examiner under 35 USC § 101 with respect to statutory category and judicial exceptions, and appear to recite a form of subject matter statutorily compliant with § 101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1 and 7-8 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Toth (US20190097812; Hereinafter “Toth”).
Regarding claim 1, Toth teaches a method for non-repudiable endorsement of a private attestation (abstract, [00447], and [0507]), the method comprising:
receiving an Attestation from a Private Attribute Provider (PAP), wherein the Attestation includes attributes with corresponding attribute names and values, and an optional PAP signature ([0427], [0486], [0491], and [0524] – personal device <i.e., connected device> receives an identity document <i.e., Attestation> provided by an identity document issuer <i.e., Private Attribute Provider>. E.g., the personal device acquires a credential image such as a driver’s license <i.e., Attestation> issued by the DMV <i.e., Private Attribute Provider>; [0470-471] – the identity document <i.e., Attestation> comprises attribute value pairs, e.g., a driver’s license comprises Name <i.e., attribute name>: Chris <i.e., attribute value>, etc.);
the method characterized by:
binding a user of a connected device to the Attestation ([0430-432], [0468-0470], and [0545-546] – a true copy e-credential is generated binding the user of the personal device <i.e., connected device> to the identity document <i.e., Attestation>), by:
collecting a set of user certified attribute names from said attributes selected by the user ([0524], [0486-488], [0493] and [0534] – The user of the personal device <i.e., connected device> creates a template of attribute names <i.e., attributes selected by the user>. The selected attribute names are provided to the issuer as part of an e-credential request with supporting information <i.e., certified by the user>; [0470-471] – the attributes names may be, e.g., name, birth, marriage, distinguishing features, etc.; [0426], [0429], and [0489] – The personal device may be, e.g., a laptop, a phone, etc. <i.e., selections/inputs are provided using a display>),
authenticating the user to an Issuing Authority ([0427], [0458-460] and [0486-488] – the personal device <i.e., connected device> is used to send user authenticating information to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer uses the information to authenticate the user),
generating a key pair for the user, comprising a public key (PuK) and a private key (PrK) ([0439], [0471], [0534], and [0556] – identity engine of the personal device <i.e., connected device> generates a key pair comprising a public key and a private key for the user and stores the keys in memory),
transmitting said public key (PuK) to said Issuing Authority ([0017-018], [0441], and [0471] – the public key is transmitted to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer <i.e., Issuing Authority> then issues an e-credential and includes the public key in the e-credential); and
binding pivotal attributes to equivalent attributes of the Issuing Authority ([0486-488], [0458-0460], and [0537] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes from the identity document <i.e., has pivotal attributes from the Attestation’s listed attributes>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer. The e-credential issuer <i.e., Issuing Authority> then issues the e-credential with the determined attribute values <i.e., Issuing Authority binds the e-credential attribute names to the equivalent attributes determined by the Issuing Authority>), by:
requesting the Issuing Authority to authorize user and endorse said Attestation based on it validating said set of user certified attribute names ([0486-488], [0458-0460], and [0447] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes <i.e., certified attribute names> from the identity document and sends it to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer <i.e., validates the attributes>. Based on the matching <i.e., authorization>, the e-credential issuer <i.e., Issuing Authority> adds their digital seal <i.e., endorsement> to the e-credential comprising the identity document <i.e., endorses the Attestation>), and
if validated, receiving from said Issuing Authority a signed Server Proof ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof> to the e-credential comprising the identity document. The digital seal is returned to the personal device <i.e., connected device receives the signed Server Proof>).
Regarding claim 7, Toth teaches the method of claim 1, wherein the access to said service grants a right or privilege to a user of a device holding said device key, wherein said Attestation further includes a purpose for using said attributes that limits said access by said PAP, and said purpose in said Attestation contains terms of usage, an expiry date, or other conditional measure for using the Endorsed Attestation ([0554], [0567], [0585] – the e-credential <i.e., Endorsed Transaction> for the identity document <i.e., Attestation> may be presented to relying parties and/or web services to authenticate and access services; [0470], [0486], and [0522] – the identity document <Attestation> may include driver’s license information <i.e., purpose/usage information> and expiry information <i.e., limiting information>. Similarly, the associated true copy e-credential <i.e., Endorsed Attestation> include, e.g., expiry date, creation conditions, driver’s license information etc.).
Regarding claim 8, Toth teaches the method of claim 1, further comprising including terms of usage, an expiry date, or other conditional measure in said Issuing Authority Challenge to limit use of the Endorsed Attestation by said Issuing Authority ([0470], [0486], and [0522] – the identity document may include driver’s license information <i.e., purpose/usage information> and expiry information <i.e., limiting information>. Similarly, the associated true copy e-credential <i.e., Endorsed Attestation> include, e.g., sealer’s expiry date, creation conditions, driver’s license information <i.e., purpose/usage information included>, driver’s license expiry date, etc.).
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) 2-6 and 11-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Toth in view of Everson et al. (US20200100108; Hereinafter “Everson”).
Regarding claim 2, Toth teaches the method of claim 1, further comprising packaging the Attestation with the |signed Server Proof| to produce an Endorsed Attestation ([0524-525], [0458-464], and [0447] – user device packages the identity document <i.e., Attestation> with the digital seal <i.e., signed Server Proof> to provide a true copy e-credential <i.e., Endorsed Attestation>, as well as providing the true copy e-credential <i.e., Endorsed Attestation> to a verifier; [0554], [0567], [0585] – the e-credential <i.e., Endorsed Transaction> for the identity document <i.e., Attestation> may be presented to relying parties and/or web services to authenticate and access services); and
presenting said Endorsed Attestation to a Verifier to access a service offered by said Verifier ([0524-525], [0458-464], and [0447] – user device packages the identity document <i.e., Attestation> with the digital seal <i.e., signed Server Proof> to provide a true copy e-credential <i.e., Endorsed Attestation>, as well as providing the true copy e-credential <i.e., Endorsed Attestation> to a verifier; [0554], [0567], [0585] – the e-credential <i.e., Endorsed Transaction> for the identity document <i.e., Attestation> may be presented to relying parties and/or web services to authenticate and access services).
Yet, Toth appears to fail to specifically disclose using a Verifier Challenge with the digital seal <i.e., signed Server Proof>. Particularly: aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob; signing the Verifier Blob with said private key (PrK) to produce a mobile signed blob; aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob signing the Verifier Blob with said private key (PrK) to produce a mobile signed blob; packaging the Attestation with the mobile signed blob to produce an Endorsed Attestation; and presenting said Endorsed Attestation to a Verifier to access a service offered by said Verifier.
However, Everson teaches a similar system including a challenge from a verifier with a signed server proof (see, e.g., Everson at [0212-220]), particularly comprising:
aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob ([0219-220] – challenge data is received from a verifier. The user device packages the challenge data + a signature of an encrypted credential blob <i.e., signed Proof> into a credential message <i.e., Verifier Blob>. The user device then signs the package <i.e., producing Mobile Signed Blob> using a device private key; [0005], [0212-0213] – a server cryptographically signed the encrypted credential blob and provides the it to the user device <i.e., signed server proof>);
signing the Verifier Blob with said private key (PrK) to produce a Mobile Signed Blob ([0219-220] – challenge data is received from a verifier. The user device packages the challenge data + a signature of an encrypted credential blob <i.e., signed Proof> into a credential message <i.e., Verifier Blob>. The user device then signs the package <i.e., producing Mobile Signed Blob> using a device private key. A receiving verifier can then verify the correct challenge was used in the verification request; [0005], [0212-0213] – a server cryptographically signed the encrypted credential blob and provides the it to the user device <i.e., signed server proof>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Toth with the teachings of Everson, particularly comprising aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob; signing the Verifier Blob with said private key (PrK) to produce a Mobile Signed Blob; packaging the Attestation with the Mobile Signed Blob to produce an Endorsed Attestation; and presenting said Endorsed Attestation to a Verifier to access a service offered by said Verifier, to reduce the efficacy of replay attacks (see, e.g., Everson at [0218] and [0190]; with Toth at [0524-525], [0458-464], and [0447]).
Regarding claim 3, Toth teaches the method of claim 1, wherein for said step of binding pivotal attributes, said Issuing Authority performs steps of:
checking a validity of said set of user certified attribute names against equivalent corresponding attribute values ([0486-488], [0458-0460], and [0447] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes <i.e., certified attribute names> from the identity document and sends it to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer <i.e., validates the attributes>. Based on the matching <i.e., authorization>, the e-credential issuer <i.e., Issuing Authority> adds their digital seal <i.e., endorsement> to the e-credential comprising the identity document <i.e., endorses the Attestation>), and
if valid, endorsing said Attestation alongside said set of user certified attribute names and a hashed Attestation and a hashed Public key ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof>; [0522], [0502], and [0473-480] – The digital seal/signature includes a sealing image of the identity document <i.e., attestation>, any selected user identity elements <i.e., certified attribute names>, public encryption keys, and any other predetermined elements. Digital seal/signatures are created by hashing inputs and then encrypting the hashed inputs); and
returning said signed Server Proof ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof> to the e-credential comprising the identity document. The digital seal is returned to the personal device <i.e., connected device receives the signed Server Proof>); otherwise, if not valid, not endorsing said Attestation ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof> to the e-credential comprising the identity document. The digital seal is returned to the personal device <i.e., connected device receives the signed Server Proof>. Upon failure, no digital seal is added to the identity document <i.e., Attestation not endorsed>),
wherein said endorsing includes signing the Server Proof to produce said signed Server Proof ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof>; [0522], [0502], and [0473-480] – The digital seal/signature includes a sealing image of the identity document <i.e., attestation>, any selected user identity elements <i.e., certified attribute names>, public encryption keys, and any other predetermined elements. Digital seal/signatures are created by hashing inputs and then encrypting the hashed inputs), said signed Server Proof comprising said hashed Attestation, a hash of said user certified attribute names, [[an Issuing Authority Challenge,]] and said hashed Public Key ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof>; [0522], [0502], and [0473-480] – The digital seal/signature includes a sealing image of the identity document <i.e., attestation>, any selected user identity elements <i.e., certified attribute names>, public encryption keys, and any other predetermined elements. Digital seal/signatures are created by hashing inputs and then encrypting the hashed inputs).
Toth appears to fail to specifically disclose wherein the signed server proof comprises an Issuing Authority Challenge. However, Everson teaches a similar system including a challenges in transmissions (see, e.g., Everson at [0212-213] and [0176]), particularly with said signed Server Proof comprising an Issuing Authority Challenge ([0212-0213] and [0176] – a server <i.e., Issuing Authority> cryptographically signs an encrypted credential blob and provides the it to the user device <i.e., user device acquires signed server proof>. The Issuing Authority includes a nonce in the signed credential blob <i.e., comprises Issuing Authority Challenge>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Toth with the teachings of Everson, particularly comprising said signed Server Proof comprising an Issuing Authority Challenge, to reduce the efficacy of replay attacks (see, e.g., Everson at [0218] and [0190]; with Toth at [0524-525], [0458-464], and [0447]).
Regarding claim 4, the combination of Toth and Everson teach the method of claim 3, wherein said Endorsed Attestation comprises:
said Attestation and, optionally, said PAP signature (Toth at [0486-488], [0458-0460], and [0524] – true copy e-credential <i.e., Endorsed Attestation> comprises the identity document <i.e., Attestation>); and
said Mobile Signed Blob comprising: a connected device signature over said Verifier Blob using private key (PrK) (Everson at [0219-220] – challenge data is received from a verifier. The user device packages the challenge data + a signature of an encrypted credential blob <i.e., signed Server Proof> into a credential message <i.e., Verifier Blob>. The user device then signs the package <i.e., producing Mobile Signed Blob> using a device private key; [0005], [0212-0213] – a server cryptographically signs an encrypted credential blob and provides the it to the user device <i.e., signed server proof>); and
said Verifier Blob comprising: said Verifier Challenge; and said signed Server Proof (Everson at [0219-220] – challenge data is received from a verifier. The user device packages the challenge data + a signature of an encrypted credential blob <i.e., signed Server Proof> into a credential message <i.e., Verifier Blob>. The user device then signs the package <i.e., producing Mobile Signed Blob> using a device private key; [0005], [0212-0213] – a server cryptographically signs an encrypted credential blob and provides the it to the user device <i.e., signed server proof>; with Toth at [0486-488], [0458-0460], and [0447] – generating digital seal <i.e., signed server proof> step) comprising:
said hashed Attestation, said hash of said user certified attribute names, said Issuing Authority Challenge, said hashed Public Key, and an Issuing Authority signature (Toth at [0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof>; [0522], [0502], and [0473-480] – The digital seal/signature includes a sealing image of the identity document <i.e., attestation>, any selected user identity elements <i.e., certified attribute names>, public encryption keys, and any other predetermined elements. Digital seal/signatures are created by hashing inputs and then encrypting the hashed inputs; with Everson at [0212-0213] and [0176] – a server <i.e., Issuing Authority> cryptographically signs an encrypted credential blob and provides the it to the user device <i.e., user device acquires signed server proof>. The Issuing Authority includes a nonce in the signed credential blob <i.e., comprises Issuing Authority Challenge>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Toth with the teachings of Everson, particularly comprising: said Mobile Signed Blob comprising: a connected device signature over said Verifier Blob using private key (PrK); and said Verifier Blob comprising: said Verifier Challenge; and said signed Server Proof comprising: said hashed Attestation, said hash of said user certified attribute names, said Issuing Authority Challenge, said hashed Public Key, and an Issuing Authority signature, to reduce the efficacy of replay attacks (see, e.g., Everson at [0212-220]; with Toth at [0524-525], [0458-464], and [0447]).
Regarding claim 5, the combination of Toth and Everson teaches the method of claim 4, wherein said step of endorsing said Attestation alongside said set of user certified attribute names and a hashed Attestation and a hashed Public key binds the user to said key pair of the connected device, thereby preventing the user from denying the connected device signature (Toth at [0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof>. Owners cannot repudiate digitally sealing the credential; [0522], [0502], and [0473-480] – The digital seal/signature includes a sealing image of the identity document <i.e., attestation>, any selected user identity elements <i.e., certified attribute names>, public encryption keys, and any other predetermined elements. Digital seals/signatures are created by hashing inputs and then encrypting the hashed inputs. The digital seal/signature binds the user to the e-credential comprising the public key of the personal device).
Regarding claim 6, the combination of Toth and Everson teach the method of claim 2, wherein said step of checking a validity includes authenticating said user certified attribute names to a civil registry, an identification documents registry, an administrative registry or any source of prior registered information for connected device authentication of a user of said connected device (Toth at [0486-488], [0563], [0498], and [0506] – the personal device <i.e., connected device> constructs an e-credential request. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer <i.e., validates the attributes>. Based on the matching <i.e., authorization>, the e-credential issuer <i.e., Issuing Authority> adds their digital seal <i.e., endorsement> to the e-credential comprising the identity document. To confirm matching, an e-credential registry system may be used to confirm personally identifying information/documents).
Regarding claim 11, Toth teaches a system for non-repudiable endorsement of a private attestation comprising:
an Issuing Authority ([0427], [0486], [0491], and [0524] – e.g., an employee at the DMV); a Verifier ([0554], [0567], [0585] – e-credential for an identity document may be presented to relying parties and/or web services to verify the e-credential and access services); and a Private Attribute Provider (PAP) provides an Attestation comprising attributes and corresponding attribute values ([0427], [0486], [0491], and [0524] – personal device <i.e., connected device> receives an identity document <i.e., Attestation> provided by an identity document issuer <i.e., Private Attribute Provider>. E.g., the personal device acquires a credential image such as a driver’s license <i.e., Attestation> issued by the DMV <i.e., Private Attribute Provider>; [0470-471] – the identity document <i.e., Attestation> comprises attribute value pairs, e.g., a driver’s license comprises Name <i.e., attribute name>: Chris <i.e., attribute value>, etc.); and
a connected device operated by a user, wherein the connected device: is further characterized in that it: binds the user to the Attestation ([0430-432], [0468-0470], and [0545-546] – a true copy e-credential is generated binding the user of the personal device <i.e., connected device> to the identity document <i.e., Attestation>),
binds pivotal attributes to equivalent attributes of said Issuing Authority ([0486-488], [0458-0460], and [0537] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes from the identity document <i.e., has pivotal attributes from the Attestation’s listed attributes>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer. The e-credential issuer <i.e., Issuing Authority> then issues the e-credential with the determined attribute values <i.e., Issuing Authority binds the e-credential attribute names to the equivalent attributes determined by the Issuing Authority>),
where responsive to said bindings ([0486-488], [0458-0460], and [0537] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes from the identity document <i.e., has pivotal attributes from the Attestation’s listed attributes>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer. The e-credential issuer <i.e., Issuing Authority> then issues the e-credential with the determined attribute values <i.e., Issuing Authority binds the e-credential attribute names to the equivalent attributes determined by the Issuing Authority>),
packages the Attestation with the |signed Server Proof| to produce an Endorsed Attestation ([0524-525], [0458-464], and [0447] – user device packages the identity document <i.e., Attestation> with the digital seal <i.e., signed Server Proof> to provide a true copy e-credential <i.e., Endorsed Attestation>, as well as providing the true copy e-credential <i.e., Endorsed Attestation> to a verifier; [0554], [0567], [0585] – the e-credential <i.e., Endorsed Transaction> for the identity document <i.e., Attestation> may be presented to relying parties and/or web services to authenticate and access services); and
presents said Endorsed Attestation to a Verifier to access a service offered by said Verifier ([0524-525], [0458-464], and [0447] – user device packages the identity document <i.e., Attestation> with the digital seal <i.e., signed Server Proof> to provide a true copy e-credential <i.e., Endorsed Attestation>, as well as providing the true copy e-credential <i.e., Endorsed Attestation> to a verifier; [0554], [0567], [0585] – the e-credential <i.e., Endorsed Transaction> for the identity document <i.e., Attestation> may be presented to relying parties and/or web services to authenticate and access services).
Yet, Toth appears to fail to specifically disclose using a Verifier Challenge with the digital seal <i.e., signed Server Proof>. Particularly: aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob; signing the Verifier Blob with said private key (PrK) to produce a mobile signed blob; aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob signing the Verifier Blob with said private key (PrK) to produce a mobile signed blob; packaging the Attestation with the mobile signed blob to produce an Endorsed Attestation; and presenting said Endorsed Attestation to a Verifier to access a service offered by said Verifier.
However, Everson teaches a similar system including a challenge from a verifier with a signed server proof (see, e.g., Everson at [0212-220]), particularly that: aggregates the signed Server Proof with a Verifier Challenge to produce a Verifier Blob ([0219-220] – challenge data is received from a verifier. The user device packages the challenge data + a signature of an encrypted credential blob <i.e., signed Server Proof> into a credential message <i.e., Verifier Blob>. The user device then signs the package <i.e., producing Mobile Signed Blob> using a device private key; [0005], [0212-0213] – a server cryptographically signs an encrypted credential blob and provides the it to the user device <i.e., signed server proof>;);
signs the Verifier Blob with said private key (PrK) to produce a Mobile Signed Blob ([0219-220] – challenge data is received from a verifier. The user device packages the challenge data + a signature of an encrypted credential blob <i.e., signed Proof> into a credential message <i.e., Verifier Blob>. The user device then signs the package <i.e., producing Mobile Signed Blob> using a device private key. A receiving verifier can then verify the correct challenge was used in the verification request; [0005], [0212-0213] – a server cryptographically signed the encrypted credential blob and provides the it to the user device <i.e., signed server proof>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Toth with the teachings of Everson, particularly comprising aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob; signing the Verifier Blob with said private key (PrK) to produce a Mobile Signed Blob; packaging the Attestation with the Mobile Signed Blob to produce an Endorsed Attestation; and presenting said Endorsed Attestation to a Verifier to access a service offered by said Verifier, to ensure freshness and reduce the efficacy of replay attacks (see, e.g., Everson at [0218] and [0190]; with Toth at [0524-525], [0458-464], and [0447])..
Regarding claim 12, the combination of Toth and Everson teach the system of claim 11, wherein the connected device binds the user to the Attestation by: collecting a set of user certified attribute names, but not attribute values, from said attributes selected by the user(Toth at [0524], [0486-488], [0493] and [0534] – The user of the personal device <i.e., connected device> creates a template of attribute names <i.e., attributes selected by the user>. The selected attribute names are provided to the issuer as part of an e-credential request with supporting information <i.e., certified by the user>; [0470-471] – the attributes names may be, e.g., name, birth, marriage, distinguishing features, etc.; [0426], [0429], and [0489] – The personal device may be, e.g., a laptop, a phone, etc. <i.e., selections/inputs are provided using a display>),
authenticating the user to the Issuing Authority(Toth at [0427], [0458-460] and [0486-488] – the personal device <i.e., connected device> is used to send user authenticating information to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer uses the information to authenticate the user),
generating a key pair for the user, comprising a public key (PuK) and a private key (PrK) (Toth at [0439], [0471], [0534], and [0556] – identity engine of the personal device <i.e., connected device> generates a key pair comprising a public key and a private key for the user and stores the keys in memory), and
transmitting said public key (PuK) to said Issuing Authority (Toth at [0017-018], [0441], and [0471] – the public key is transmitted to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer <i.e., Issuing Authority> then issues an e-credential and includes the public key in the e-credential).
Regarding claim 13, the combination of Toth and Everson teach the system of claim 12, wherein the connected device binds pivotal attributes to equivalent attributes of said Issuing Authority (Toth at [0486-488], [0458-0460], and [0537] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes from the identity document <i.e., has pivotal attributes from the Attestation’s listed attributes>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer. The e-credential issuer <i.e., Issuing Authority> then issues the e-credential with the determined attribute values <i.e., Issuing Authority binds the e-credential attribute names to the equivalent attributes determined by the Issuing Authority>) by:
requesting the Issuing Authority for its authorization to endorse said Attestation based on it validating said set of user certified attribute names (Toth at [0486-488], [0458-0460], and [0447] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes <i.e., certified attribute names> from the identity document and sends it to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer <i.e., validates the attributes>. Based on the matching <i.e., authorization>, the e-credential issuer <i.e., Issuing Authority> adds their digital seal <i.e., endorsement> to the e-credential comprising the identity document <i.e., endorses the Attestation>), and
if validated, receiving from said Issuing Authority said signed Server Proof (Toth at [0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof> to the e-credential comprising the identity document. The digital seal is returned to the personal device <i.e., connected device receives the signed Server Proof>).
Regarding claim 14, the combination of Toth and Everson teach the system of claim 13, wherein said Issuing Authority:
checks a validity of said set of user certified attribute names to its own corresponding attribute values ([0486-488], [0458-0460], and [0447] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes <i.e., certified attribute names> from the identity document and sends it to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer <i.e., validates the attributes>. Based on the matching <i.e., authorization>, the e-credential issuer <i.e., Issuing Authority> adds their digital seal <i.e., endorsement> to the e-credential comprising the identity document <i.e., endorses the Attestation>), and
if valid, endorses said Attestation alongside said set of user certified attribute names and a hashed Attestation and a hashed Public key ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof>; [0522], [0502], and [0473-480] – The digital seal/signature includes a sealing image of the identity document <i.e., attestation>, any selected user identity elements <i.e., certified attribute names>, public encryption keys, and any other predetermined elements. Digital seal/signatures are created by hashing inputs and then encrypting the hashed inputs); and
returns said signed Server Proof ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof> to the e-credential comprising the identity document. The digital seal is returned to the personal device <i.e., connected device receives the signed Server Proof>); otherwise,
if not valid, not endorsing said Attestation ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof> to the e-credential comprising the identity document. The digital seal is returned to the personal device <i.e., connected device receives the signed Server Proof>. Upon failure, no digital seal is added to the identity document <i.e., Attestation not endorsed>),
wherein said Issuing Authority signs the Server Proof to produce said signed Server Proof ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof>; [0522], [0502], and [0473-480] – The digital seal/signature includes a sealing image of the identity document <i.e., attestation>, any selected user identity elements <i.e., certified attribute names>, public encryption keys, and any other predetermined elements. Digital seal/signatures are created by hashing inputs and then encrypting the hashed inputs), said signed Server Proof comprising said hashed Attestation, a hash of said user certified attribute names, an Issuing Authority Challenge, and said hashed Public Key ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof>; [0522], [0502], and [0473-480] – The digital seal/signature includes a sealing image of the identity document <i.e., attestation>, any selected user identity elements <i.e., certified attribute names>, public encryption keys, and any other predetermined elements. Digital seal/signatures are created by hashing inputs and then encrypting the hashed inputs).
Regarding claim 15, Toth teaches a connected device for non-repudiable endorsement of a private attestation (abstract, [00447], and [0507]) comprising:
a power supply to provide power; a memory to store instructions and data; a communication module to transmit and receive data; a display to present information and receive user input; and a processor to run a computer program ([0426], [0429], [0431], and [0489]– system implemented via, e.g., a computer executing instructions stored in memory via a processor, communicating with other systems, and interacting with users. E.g., the computer may be a laptop computer, smart phone, etc. <i.e., has a display and receives user input, uses power supply>); said computer program comprising a non-transitory computer readable medium storing program code to be executed by at least one computer processing unit (CPU) in a computational environment, whereby execution of the program code causes the at least one CPU to perform operations ([0426], [0429], [0431], and [0489]– system implemented via, e.g., a computer processors executing instructions stored in memory), comprising:
receiving an Attestation from a Private Attribute Provider (PAP), wherein the Attestation includes attributes and corresponding attribute values ([0427], [0486], [0491], and [0524] – personal device <i.e., connected device> receives an identity document <i.e., Attestation> provided by an identity document issuer <i.e., Private Attribute Provider>. E.g., the personal device acquires a credential image such as a driver’s license <i.e., Attestation> issued by the DMV <i.e., Private Attribute Provider>; [0470-471] – the identity document <i.e., Attestation> comprises attribute value pairs, e.g., a driver’s license comprises Name <i.e., attribute name>: Chris <i.e., attribute value>, etc.);
and, is further characterized by:
binding a user of the connected device to the Attestation ([0430-432], [0468-0470], and [0545-546] – a true copy e-credential is generated binding the user of the personal device <i.e., connected device> to the identity document <i.e., Attestation>), by:
collecting a set of user certified attribute names, but not attribute values, from said attributes selected by the user via said display ([0524], [0486-488], [0493] and [0534] – The user of the personal device <i.e., connected device> creates a template of attribute names <i.e., attributes selected by the user> that does not comprise corresponding attribute values <i.e., a set of names is collected without attribute values>. The selected attribute names are provided to the issuer as part of an e-credential request with supporting information <i.e., certified by the user>; [0470-471] – the attributes names may be, e.g., name, birth, marriage, distinguishing features, etc.; [0426], [0429], and [0489] – The personal device may be, e.g., a laptop, a phone, etc. <i.e., selections/inputs are provided using a display>),
authenticating the user to the Issuing Authority ([0427], [0458-460] and [0486-488] – the personal device <i.e., connected device> is used to send user authenticating information to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer uses the information to authenticate the user),
generating a key pair for the user, comprising a public key (PuK) and a private key (PrK) and storing in said memory ([0439], [0471], [0534], and [0556] – identity engine of the personal device <i.e., connected device> generates a key pair comprising a public key and a private key for the user and stores the keys in memory),
transmitting said public key (PuK) to said Issuing Authority via said communication module ([0017-018], [0441], and [0471] – the public key is transmitted to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer <i.e., Issuing Authority> then issues an e-credential and includes the public key in the e-credential); and
binding pivotal attributes of said attributes to equivalent attributes of an Issuing Authority ([0486-488], [0458-0460], and [0537] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes from the identity document <i.e., has pivotal attributes from the Attestation’s listed attributes>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer. The e-credential issuer <i.e., Issuing Authority> then issues the e-credential with the determined attribute values <i.e., Issuing Authority binds the e-credential attribute names to the equivalent attributes determined by the Issuing Authority>), by:
requesting the Issuing Authority for its authorization to endorse said Attestation based on it, validating said set of user certified attribute names ([0486-488], [0458-0460], and [0447] – the personal device <i.e., connected device> constructs an e-credential request that includes selected user identity attributes <i.e., certified attribute names> from the identity document and sends it to the e-credential issuer <i.e., Issuing Authority>. The e-credential issuer <i.e., Issuing Authority> investigates the selected user identity attributes to ensure the user’s requested e-credential matches the actual attributes determined by the issuer <i.e., validates the attributes>. Based on the matching <i.e., authorization>, the e-credential issuer <i.e., Issuing Authority> adds their digital seal <i.e., endorsement> to the e-credential comprising the identity document <i.e., endorses the Attestation>), and
if validated, receiving from said Issuing Authority a signed Server Proof ([0486-488], [0458-0460], and [0447] – upon successful identity proofing/validation, the e-credential issuer <i.e., Issuing Authority> computes a digital seal <i.e., signed Server Proof> using its embossing key and affixes the digital seal <i.e., signed Server Proof> to the e-credential comprising the identity document. The digital seal is returned to the personal device <i.e., connected device receives the signed Server Proof>);
packaging the Attestation with the |signed Server Proof| to produce an Endorsed Attestation ([0524-525], [0458-464], and [0447] – user device packages the identity document <i.e., Attestation> with the digital seal <i.e., signed Server Proof> to provide a true copy e-credential <i.e., Endorsed Attestation>, as well as providing the true copy e-credential <i.e., Endorsed Attestation> to a verifier; [0554], [0567], [0585] – the e-credential <i.e., Endorsed Transaction> for the identity document <i.e., Attestation> may be presented to relying parties and/or web services to authenticate and access services); and
presenting said Endorsed Attestation to a Verifier to access a service offered by said Verifier ([0524-525], [0458-464], and [0447] – user device packages the identity document <i.e., Attestation> with the digital seal <i.e., signed Server Proof> to provide a true copy e-credential <i.e., Endorsed Attestation>, as well as providing the true copy e-credential <i.e., Endorsed Attestation> to a verifier; [0554], [0567], [0585] – the e-credential <i.e., Endorsed Transaction> for the identity document <i.e., Attestation> may be presented to relying parties and/or web services to authenticate and access services).
Yet, Toth appears to fail to specifically disclose using a Verifier Challenge with the digital seal <i.e., signed Server Proof>. Particularly: aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob; signing the Verifier Blob with said private key (PrK) to produce a mobile signed blob; aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob signing the Verifier Blob with said private key (PrK) to produce a mobile signed blob; packaging the Attestation with the mobile signed blob to produce an Endorsed Attestation; and presenting said Endorsed Attestation to a Verifier to access a service offered by said Verifier.
However, Everson teaches a similar system including a challenge from a verifier with a signed server proof (see, e.g., Everson at [0212-220]), particularly comprising: aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob ([0219-220] – challenge data is received from a verifier. The user device packages the challenge data + a signature of an encrypted credential blob <i.e., signed Server Proof> into a credential message <i.e., Verifier Blob>. The user device then signs the package <i.e., producing Mobile Signed Blob> using a device private key; [0005], [0212-0213] – a server cryptographically signs an encrypted credential blob and provides the it to the user device <i.e., signed server proof>);
signing the Verifier Blob with said private key (PrK) to produce a Mobile Signed Blob ([0219-220] – challenge data is received from a verifier. The user device packages the challenge data + a signature of an encrypted credential blob <i.e., signed Proof> into a credential message <i.e., Verifier Blob>. The user device then signs the package <i.e., producing Mobile Signed Blob> using a device private key. A receiving verifier can then verify the correct challenge was used in the verification request; [0005], [0212-0213] – a server cryptographically signed the encrypted credential blob and provides the it to the user device <i.e., signed server proof>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Toth with the teachings of Everson, particularly comprising aggregating the signed Server Proof with a Verifier Challenge to produce a Verifier Blob; signing the Verifier Blob with said private key (PrK) to produce a Mobile Signed Blob; packaging the Attestation with the Mobile Signed Blob to produce an Endorsed Attestation; and presenting said Endorsed Attestation to a Verifier to access a service offered by said Verifier, to ensure freshness and reduce the efficacy of replay attacks (see, e.g., Everson at [0218] and [0190]; with Toth at [0524-525], [0458-464], and [0447]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Barbir (US20140173697) teaches a system wherein a relying party uses an authentication broker to gather information from multiple identity service providers and attribute providers, as well as aggregating and validating identity information (see, e.g., Barbir at abstract, [0008-012]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.
/J.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights