Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s remarks, see page 8, filed 07/02/2026, with respect to the requirement to file an Information Disclosure Statement (IDS) have been fully considered. Applicant has been notified three distinct times on the record of the requirement to file an information disclosure statement (IDS) containing the material incorporated by reference from Korean Patent Registration No. KR 101139630B1 and US Publication No. US 2013/0101114A1 found within the specification. Applicant is respectfully reminded that they have a duty of candor and good faith under 37 CFR 1.56 to disclose information material to patentability (see 37 C.F.R. 1.56).
The filing of a reply by a party to a request for information from the Office, whether by a practitioner or non-practitioner, constitutes a certification under § 11.18(b). Thus, violations of § 11.18(b)(2) in this context may subject the party to sanctions under § 11.18(c). See 37 CFR 1.4(d)(4)(i). Section 11.18(b)(2) calls for a duty of reasonable inquiry to ensure that the paper is not being presented for any improper purpose, the legal contentions are warranted by law, the allegations and other factual contentions have evidentiary support, and the denials of factual contentions are warranted on the evidence.
Compliance will not be held in abeyance with respect to responding to the objection, rejection, or other requirement for the incorporation to be effective see MPEP 608.01(p). In no case may the correction be made later than the close of prosecution as defined in 37 CFR 1.114(b), or abandonment of the application, whichever occurs earlier. Any correction inserting material by amendment that was previously incorporated by reference must be accompanied by a statement that the material being inserted is the material incorporated by reference and the amendment contains no new matter. 37 CFR 1.57(g).
Applicant’s arguments, see pages 8-9, filed 07/02/2026, with respect to the rejection of claims 1, 6-9, 13-16 under 35 U.S.C. § 112(b) have been fully considered. The previous rejections of claims 1, 6-9, 13-16 under 35 U.S.C. § 112(b) have been withdrawn in response to the amended claims solving the previous antecedent basis issues.
Applicant’s arguments, see pages 9-13, filed 07/02/2026, with respect to the rejection of claims 1, 6-9, 13-16 under 35 U.S.C. § 112(a) have been fully considered but they are not persuasive.
Applicant first argues that the amendment introduces the limitation “wherein the unique key is a physically unclonable function (PUF) output of the user terminal” and that such an amendment “materially changes the written description inquiry”.
Upon further consideration, the Examiner maintains that endemic written description issues remain in the response to arguments and the full rejection below concerning other claim elements. The Examiner also submits that paragraph [0030] of the originally filed specification does not contain the excerpt relied upon by the Applicant for the unique key on page 9 of the remarks filed 07/02/2026.
Applicant next argues on page 10 that the seed key is supported by the specification at paragraphs [0052-0056].
The Examiner respectfully disagrees.
The Examiner traverses Applicant’s stated rationale on page 10 of the remarks filed 07/02/2026 “The specification also describes the rationale for this combination: to address the constancy limitations of bioinformation alone” as this rationale is utterly absent from the originally filed disclosure. In fact, paragraphs [0054-0055] make the conclusory statements that “The degree to which constancy is secured in the bioinformation 210, and at least some of the bioinformation 210 whose constancy is secured may be determined based on at least one of the type of the bioinformation 210, the characteristics of the user, an environment in which the bioinformation 210 is detected, and the characteristics of the sensor that detects the bioinformation 210. The type of the bioinformation 210 includes a fingerprint, iris, voice, face, vein distribution, retina, etc., and the degree to which constancy is secured (e.g., number of bits, bit length, etc.) may vary depending on the characteristics of the corresponding type” and “it is assumed that at least some of the bioinformation 210 whose constancy is secured has B bits”; with no further disclosure on how such a determination of alleged constancy is made or this assumption is valid or supported.
Furthermore, paragraph [0056] of the originally field disclosure recites the rationale “security and convenience may be improved due to single processing of user authentication based on the bioinformation 210 and device authentication based on the unique key 220, as well as the issue of constancy of the bioinformation 210 itself may be remedied”, again without disclosing how such an issue of constancy is resolved as it is assumed in the specification somehow that the bioinformation already has “some of the bioinformation 210 whose constancy is secured has B bits” and the recited rationale listed is silent with respect to argued “leveraging the time-variant properties of the PUF output”.
The written description requirement is not satisfied, sufficiently, with respect to the seed key. As stated in the Non-Final Rejection mailed 04/02/2026 and in the Final Rejection mailed 09/08/2025, the originally filed disclosure is silent with regarding how the inventor intended to select the division of “at least some of bioinformation” and “at least some of a unique key” as it merely states that “some” of the seed key is bioinformation “and the rest” is at least one bit of the unique key. Additionally, there is insufficient written description support for obtaining bioinformation, nor how the seed key is created/produced/obtained from the “at least some of” bioinformation and a unique key. For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date.
As in MPEP 2161.01 (I), "The description requirement of the patent statute requires a description of an invention, not an indication of a result that one might achieve if one made that invention." It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015).
Applicant next argues on pages 10-11 that the amended claim limitation “wherein the first inborn ID is generated from a first part of an authentication key extracted from the authentication key” is supported by paragraph [0060] and that the amended limitation “generated from a first part of an authentication key” allegedly only covers the direct-use embodiment for the inborn ID.
The Examiner respectfully disagrees.
The Examiner first maintains as in the Non-Final Rejection mailed 04/02/2026, that the originally filed disclosure is utterly silent with any generation of an inborn ID whatsoever, and there is no recitation of any hashing, encoding, or other “operations” with respect to generating an inborn ID. Furthermore, Applicant’s contention that the amended limitation “generated from a first part of an authentication key” allegedly only covers the direct-use embodiment for the inborn ID is unpersuasive. As in MPEP 2173.01, “under a broadest reasonable interpretation, words of the claim must be given their plain meaning, unless such meaning is inconsistent with the specification. The plain meaning of a term means the ordinary and customary meaning given to the term by those of ordinary skill in the art at the time of the invention. The ordinary and customary meaning of a term may be evidenced by a variety of sources, including the words of the claims themselves, the specification, drawings, and prior art. However, the best source for determining the meaning of a claim term is the specification - the greatest clarity is obtained when the specification serves as a glossary for the claim terms. The presumption that a term is given its ordinary and customary meaning may be rebutted by the applicant by clearly setting forth a different definition of the term in the specification. In re Morris, 127 F.3d 1048, 1054, 44 USPQ2d 1023, 1028 (Fed. Cir. 1997) (the USPTO looks to the ordinary use of the claim terms taking into account definitions or other "enlightenment" contained in the written description); But c.f. In re Am. Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1369, 70 USPQ2d 1827, 1834 (Fed. Cir. 2004) ("We have cautioned against reading limitations into a claim from the preferred embodiment described in the specification, even if it is the only embodiment described, absent clear disclaimer in the specification."); In re Bigio, 381 F.3d 1320, 1325, 72 USPQ2d 1209, 1211 (Fed. Cir. 2004) (The claims at issue were drawn to a "hair brush." The court upheld the Board’s refusal to import from the specification a limitation that would apply the term only to hairbrushes for the scalp. "[T]his court counsels the PTO to avoid the temptation to limit broad claim terms solely on the basis of specification passages."). When the specification sets a clear path to the claim language, the scope of the claims is more easily determined and the public notice function of the claims is best served. See MPEP § 2111.01 for a full discussion of the plain meaning of claim language”. The Examiner submits that the plain meaning of the word “generate” according to Merriam-Webster dictionary includes “to bring into existence: such as to create by means of a defined process”. Furthermore, the originally filed specification directly contradicts Applicant’s interpretation at paragraph [0058] “In some embodiments, the seed key 230 may be directly used as the authentication key 240, or the authentication key 240 may be generated from the seed key 230 using an encryption algorithm” (bolding added) where it’s clear that the claim language “generated from” still explicitly includes generation per se and the interpretation is not confined to the direct-use embodiment as Applicant contends. The only recitation of the claimed “generated from” phrase, is presented as an alternative to the direct-use embodiment in paragraph [0058] of the originally filed disclosure. Therefore, the Examiner maintains the position that regarding the claimed first inborn ID, the claims are still expressly drawn to a generation per se, therefore Applicant’s characterization that disclosure of “the first part of the authentication key is the inborn ID, without any transformation” is allegedly sufficient is wholly unpersuasive as the broadest reasonable interpretation expressly includes generating the first inborn ID, although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Furthermore, Applicant’s argument that the direct-use embodiment is sufficient disclosure to convey possession of the genus of all conceivable ways of generating a first inborn ID from a first part of an authentication key is wholly unpersuasive as the originally filed disclosure is silent with respect to any algorithm/series of steps regarding how the inventor achieved the claimed generation.
In MPEP 2161.01, "computer-implemented functional claim language must still be evaluated for sufficient disclosure under the written description". And MPEP 2161.01(I) "generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed." For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date.
As in MPEP 2161.01 (I), "The description requirement of the patent statute requires a description of an invention, not an indication of a result that one might achieve if one made that invention."). It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015).
AS in MPEP 2161.01 “For instance, generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1349-50, 94 USPQ2d at 1171 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention’s boundaries.") (citing Eli Lilly, 119 F.3d at 1568, 43 USPQ2d at 1405-06); Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement because it failed to support the scope of the genus claimed); Fiers v. Revel, 984 F.2d 1164, 1170, 25 USPQ2d 1601, 1606 (Fed. Cir. 1993) (rejecting the argument that "only similar language in the specification or original claims is necessary to satisfy the written description requirement").”
“The Federal Circuit has explained that a specification cannot always support expansive claim language and satisfy the requirements of 35 U.S.C. 112 "merely by clearly describing one embodiment of the thing claimed." LizardTech v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1346, 76 USPQ2d 1731, 1733 (Fed. Cir. 2005). The issue is whether a person skilled in the art would understand applicant to have invented, and been in possession of, the invention as broadly claimed. In LizardTech, claims to a generic method of making a seamless discrete wavelet transformation (DWT) were held invalid under 35 U.S.C. 112, first paragraph, because the specification taught only one particular method for making a seamless DWT and there was no evidence that the specification contemplated a more generic method. "[T]he description of one method for creating a seamless DWT does not entitle the inventor . . . to claim any and all means for achieving that objective." LizardTech, 424 F.3d at 1346, 76 USPQ2d at 1733.”
As an aside to clarify the record, the Examiner is not aware of what Applicant means by admitting on the record that “identity transformation is a well-understood mathematical operation. The claim does not require a non-trivial transformation” on page 11 of the remarks filed 07/02/2026 as there is no identity transformation discussed in the prior rejection or in the currently amended claims.
Applicant then argues on pages 11-12 that paragraph [0058] of the originally filed disclosure adequately supports generating the authentication key from the seed key.
The Examiner respectfully disagrees.
Paragraph [0058] of the originally filed disclosure recites in full, “The authentication key 240 is determined based on the seed key 230. In some embodiments, the seed key 230 may be directly used as the authentication key 240, or the authentication key 240 may be generated from the seed key 230 using an encryption algorithm”. The claim recites “wherein the authentication key is generated by applying a predetermined encryption process to a seed key”. As in the Non-Final Rejection mailed 04/02/2026, the broadest reasonable interpretation of the claim still includes the entire genus of all public key algorithms, [independent claim 1 recites at least “applying a public key algorithm” and “wherein the authentication key is generated by applying a predetermined encryption process to a seed key”, thereby claiming the entire genus explicitly using plain English], while remarkably not even disclosing a single algorithm or method step capable of achieving the desired result. Applicant’s argument that the claim somehow refers to “a specific, preselected” encryption process is wholly unpersuasive. Any encryption algorithm could read upon the broadest reasonable interpretation of the claim limitation at issue, and the originally filed disclosure does not even disclose a single algorithm or method step capable of achieving the desired result of generating an authentication key. The scope of the claim limitation at issue includes the broad genus of all conceivable encryption/public key algorithms as using any such algorithm would read upon the invention as currently claimed. Applicant’s remarks that “the specific algorithm is a design choice within a defined, bounded technical category” and “Key derivation functions (KDFs) constitute a bounded, well-characterized category of cryptographic operations (HKDF, PBKDF2, and similar constructs are standardized in NIST and IETF publications). A POSITA would understand what class of operation is intended and would be able to implement it” are unpersuasive as the algorithm is not a mere design choice as the selected algorithm arrives at the desired result of generating an authentication key from a seed key, there are a myriad of possible encryption algorithms, and Applicant’s remarks and examples of key derivation functions are helpful and illustrative, however none of them make an appearance or are even suggested/alluded to in the originally filed disclosure.
Furthermore, the Examiner traverses Applicant’s argument on pages 11-12 “Critically, the Examiner's own cited reference, Asim, at paragraph [0037], confirms that combining biometric measurement and device ID using "simple concatenation or XORing" is the standard approach understood by a POSITA. This confirms that the combination step - which the specification describes as generating a seed key from bioinformation and a unique key - is well-understood in the art, and that the specification's disclosure of the seed key composition is adequate”. Paragraph [0037] of the Asim reference makes no mention that the disclosed feature of the prior art “is the standard approach understood by a POSITA”. The Asim reference at paragraph [0037] does not state that the disclosed combining biometric measurement and device ID is allegedly well-known or well-understood in the art. Asim having a fully disclosed and supported invention including a method of combining biometric measurement and device ID, as Applicant describes, does not cure the endemic written description deficiencies regarding possession of the claimed seed key. Applicant’s own originally filed disclosure does not contain any support for obtaining a seed key, and relying upon a prior art reference to satisfy the written description requirement of the instant pending patent application is improper, see MPEP 2163 “To comply with the written description requirement of 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, … each claim limitation must be expressly, implicitly, or inherently supported in the originally filed disclosure” (underline added).
Applicant remarks “The Examiner's objection that no specific encryption algorithm is named is respectfully traversed” on page 11. To promote clarity of the record, the Applicant has characterized this rejection as “objections”; ordinarily an objection is petitionable, and a rejection is appealable, but when the objection is "determinative of the rejection" the matter may be addressed by the Board. See In re Hengehold, 440 F.2d 1395, 1403, 169 USPQ 473, 479 (CCPA 1971) and Ex parte Frye, 94 USPQ2d 1072, 1078 (Bd. Pat. App. & Int. 2010)(precedential), see MPEP § 1201. This is a rejection under 35 U.S.C. § 112(a) and not an objection.
Applicant next argues on page 12 that paragraph [0066] of the originally filed disclosure supports the limitation “wherein the certificate is generated by encrypting the second inborn ID and the public key of the user terminal with a private key of the authentication system”.
The Examiner respectfully disagrees.
Paragraph [0066] consists of a repetition of claim language and is silent with respect to even disclosing a single encryption algorithm capable of achieving the desired result of generating a certificate by encrypting the second inborn ID and the public key. Applicant has no response to this lack of disclosure, and instead relies upon the argument “Encrypting data with a private key is the standard definition of digital signing in public key infrastructure (PKI), which is the foundational technology of the claimed system”. The originally filed disclosure is silent with respect to any public key infrastructure (PKI). Applicant’s further conclusory argument that “Figure 4 of the specification depicts the certificate issuance operation, showing the inborn ID and public key as inputs and the certificate as the output. The specification adequately discloses this operation” is non-responsive. As in the Non-Final Rejection mailed 04/02/2026, the Examiner has already submitted the inquiry of where in Figure 4 is certificate generation supported? Figure 4 appears to disclose “Inborn ID PERSONAL INFORMATION Inborn ID”, an example “xx10101101xx” that is unlabeled, an example name, an arrow containing the text “ISSUANCE”, and a box representing a certificate with an inner box representing “INBORN ID AND PUBLIC KEY”. The Examiner respectfully submits that there is simply no disclosure of how the certificate generation is actually performed, and that the disclosure merely states that the functional desired result is just achieved by reciting “encrypting” while simultaneously not even disclosing a single such encryption algorithm that achieves the desired function.
Applicant finally argues that the amended application is different and that Vasudevan is improperly applied.
The Examiner respectfully disagrees.
As in MPEP 2161, (underline added)
The written description requirement of 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, applies to all claims including original claims that are part of the disclosure as filed. Ariad, 598 F.3d at 1349, 94 USPQ2d at 1170. As stated by the Federal Circuit, "[a]lthough many original claims will satisfy the written description requirement, certain claims may not." Id. at 1349, 94 USPQ2d at 1170-71; see also LizardTech, Inc. v. Earth Res. Mapping, Inc., 424 F.3d 1336, 1343-46, 76 USPQ2d 1724, 1730-33 (Fed. Cir. 2005); Regents of the Univ. of Cal. v. Eli Lilly & Co., 119 F.3d 1559, 1568, 43 USPQ2d 1398, 1405-06 (Fed. Cir. 1997)("The description requirement of the patent statute requires a description of an invention, not an indication of a result that one might achieve if one made that invention."). Problems satisfying the written description requirement for original claims often occur when claim language is generic or functional, or both. Ariad, 593 F.3d at 1349, 94 USPQ2d at 1171 ("The problem is especially acute with genus claims that use functional language to define the boundaries of a claimed genus. In such a case, the functional claim may simply claim a desired result, and may do so without describing species that achieve that result. But the specification must demonstrate that the applicant [inventor] has made a generic invention that achieves the claimed result and do so by showing that the applicant [inventor] has invented species sufficient to support a claim to the functionally-defined genus.").
Similarly, original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. See MPEP §§ 2163.02 and 2181, subsection IV.
When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. An algorithm is defined, for example, as "a finite sequence of steps for solving a logical or mathematical problem or performing a task." Microsoft Computer Dictionary (5th ed., 2002). Applicant may "express that algorithm in any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure." Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340, 86 USPQ2d 1609, 1623 (Fed. Cir. 2008) (internal citation omitted). It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015) (reversing and remanding the district court’s grant of summary judgment of invalidity for lack of adequate written description where there were genuine issues of material fact regarding "whether the specification show[ed] possession by the inventor of how accessing disparate databases is achieved"). If the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention a rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, for lack of written description must be made. For more information regarding the written description requirement, see MPEP § 2162- § 2163.07(b).
There is simply no disclosure regarding how to obtain the at least some bioinformation, there is no disclosure regarding how the seed key is obtained including at least some of bioinformation and at least some of a unique key, how the authentication key is generated, how the first inborn ID is generated from a first part of the authentication key, and how the certificate is generated by encrypting the second inborn ID and the public key of the user terminal with a private key of the authentication system. The Examiner traverses Applicant’s closing remarks using the word “structure” to describe on page 13 “the seed key” and “output” as the there is simply no structure depicted or disclosed capable of performing the various claimed functions within Figure 2, Figure 4, or the originally filed disclosure.
Applicant's arguments, see pages 13-18, filed 07/02/2026, with respect to the rejection of claims 1, 6-9 and 13-16 under 35 U.S.C. § 103 have been fully considered but they are not persuasive.
Applicant first argues that the previously presented prior art does not teach “wherein the unique key is a physically unclonable function (PUF) output of the user terminal”.
The Examiner respectfully disagrees.
The previously presented Choi reference at least in Fig. 6 showcases a PUF being combined with biometrics to be used as additional authentication means (Choi [0111] “An algorithm substantially same as that for generating the biometric code can be applied to an algorithm for generating the additional codes. Further, data encrypted in the process of generating the additional codes (e.g., encrypted dynamic signature) can be stored in the smartcard or the communication terminal together with the private key. The encrypted data stored in the smartcard or the communication terminal can be used as additional authentication means for a primary user authentication (based on the biometric matching) performed in the smartcard or the communication terminal”). This renders obvious the now-claimed PUF output. Applicant’s remarks concerning paragraphs [0030-0032] on page 14 of the remarks are unpersuasive as these paragraphs of the specification do not contain the purported advantages of a PUF as argued.
Applicant’s conclusory opinion regarding “Substituting a PUF output for a MAC address is not a routine design choice - it requires different hardware architecture (a PUF circuit must be physically embedded in the device during fabrication), a different enrollment procedure (PUF challenge-response pairs must be established during manufacturing), and addresses a fundamentally different threat model (physical device cloning and hardware-level attacks, as opposed to network impersonation)” helpful and illustrative, but none of these conclusions or supporting evidence thereof appear in the originally filed disclosure.
Applicant’s remarks disparaging Figure 6 and paragraphs [0105-0113] of the Choi reference are unpersuasive. At least paragraph [0119] of Choi further discloses “In some embodiments, each of the authentication elements (biometric code, OTP, PUF, and the like) is transmitted in a separate form, and in some embodiments, each of the authentication elements is transmitted as a single piece of concatenated authentication data”. Furthermore, upon further consideration, the Choi reference further teaches inserting other aforementioned codes from the smartcard into the key through concatenation “The above-mentioned one or more additional codes can be concatenated with each of the biometric codes. Consequently, the private key and the public key include a plurality of biometric code or a plurality of biometric code with the additional code concatenated. In this case, the plurality of biometric codes can be used for different purposes from each other. For example, any one of the plurality of biometric codes is designated to be used for performing a normal user authentication of the private key… for requesting an initialization of an authentication management system that is managed by a remote entity (e.g., a service providing server, an authentication server, a centralized controller, or the like), and the like” (Choi [0047]). Furthermore, when the Choi reference discusses the Extended Validation (EV) domain of a key, the Choi reference in paragraph [0091] uses the particular language “That is, the biometric code is inserted in the generated private key and public key”. Paragraph [0098] further supports the insertion language “Subsequently, the communication terminal generates a pair of keys (a public key and a private key) by inserting the generated biometric code in an extended validation (EV) domain of the public key certificate (Step S456). That is, the biometric code is inserted in the generated private key and public key. The private key is stored in the communication terminal to be used in the user authentication procedure later on. Although it is not shown in FIG. 4A, other additional code can be generated in a manner same as or similar to that for the biometric code, and added to the public key certificate as an additional authentication element”. Paragraph [0112] of Choi describes authentication information containing codes inserted in the private key wherein specifically Fig. 6(j) of Choi displays an explicit example of a biometric code concatenated with a UPC/EPC code, a PAN code, and most importantly a PUF code; this disclosure renders obvious at least the claimed “wherein the seed key includes at least some of bioinformation of the user obtained from the user terminal and at least some of a unique key corresponding to the user terminal, and wherein the unique key is a physically unclonable function (PUF) output of the user terminal” as Choi explicitly teaches at least combining bioinformation and a PUF via concatenation and insertion into a key. The Examiner respectfully traverse’s Applicant’s characterization on page 15 of the remarks referring to the claims as structural/architectural as there are endemic and severe written description issues present as of the current record and Applicant’s repeated reliance upon one of ordinary skill in the art to achieve various specialized claim functions. The Examiner further clarifies the record that no “single unified seed key” is claimed as of the current record. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant’s closing remarks on page 15 stating that the combination of Asim and Choi would not arrive at the claimed invention have been fully considered, but they are not persuasive. Upon further consideration, in light of the responses above, and in response to Applicant’s amendments, the Examiner defers to the rejection below as a response to Applicant’s arguments that the combination does not allegedly “arrive” at the claimed invention.
Applicant next argues on page 15 that “The Examiner has used Applicant's prior admissions regarding routine operations (bit extraction, key length selection, encryption algorithms) to support the obviousness rejection. Applicant respectfully submits that none of these admissions address the PUF limitation. No admission was made that: (1) combining PUF output with bioinformation to form a seed key is routine; (2) the specific architecture of generating a single authentication key from a PUF- biometric seed and then dividing that key into functionally distinct segments is routine; or (3) the prior art teaches or suggests this combination. The admissions regarding individual operations (bit extraction, key length selection) do not concede that the specific architectural combination claimed is obvious”.
The Examiner acknowledges Applicant’s remarks and once more traverses the characterization of “specific architecture” and “specific architectural combination” when referring to the claimed invention as the current prosecution record has clearly demonstrated that there are genuine issues of material fact regarding whether the originally filed specification demonstrates possession by the inventor of the claimed invention. Furthermore, the admissions that bit extraction operations have been fundamental to computing since the 1960s, deriving an authentication key from a seed key may be performed by one skilled in cryptographic arts using any standard algorithm and is routine in the art and requires no inventive contribution, and the selection of identifier lengths in authentication systems is a routine design choice well within the knowledge of those skilled in the art… the specific bit length is a routine parameter, still remain as of the current record, and will be maintained in the rejection below.
Applicant then argues on page 15-16 that Kim’s disclosure “is architecturally different”, “serves an entirely different purpose”, “a qualitatively different authentication mechanism” and therefore claims 1, 6-8, and 16 are nonobvious.
The Examiner respectfully disagrees.
In response to applicant's argument that Kim is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, Kim is at least reasonably pertinent to the particular problem because the claim recites “performing primary authentication of a user of the user terminal by checking whether the first inborn ID and the second inborn ID match each other”. This is a simple, rudimentary check to see if one piece of data (first inborn ID) matches a second piece of data (second inborn ID). Kim accomplishes this by disclosing at least “the management device 120 may compare in step 163a whether the device information included in the device binding information corresponds to device information acquired by the management device through the step 161. To this end, the management device 120 can verify the digital signature of the certificate authority with respect to the device binding information, and can also perform certificate chain verification consequently. For example, the management device 120 may determine whether at least a portion of the device information is included in device binding information in the certificate”. Applicant’s argument on page 16 hinges upon the notion that, “In the claimed invention, the "first inborn ID" is regenerated at authentication time from live bioinformation obtained from the user and the PUF output of the user terminal. The first inborn ID is not a static identifier stored in the device - it is dynamically derived from the combination of the user's current biometric measurement and the device's PUF output, processed through the seed key and authentication key generation steps. The first inborn ID is then compared against the "second inborn ID" that was previously registered with the authentication system and embedded in the certificate. This regeneration-and-comparison architecture serves a fundamentally different purpose from Kim's static identifier matching”. This interpretation of the claimed invention is completely unmoored from the currently amended claims and the originally filed disclosure. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the "first inborn ID" is regenerated at authentication time from live bioinformation obtained from the user and the PUF output of the user terminal”, “The first inborn ID is not a static identifier stored in the device - it is dynamically derived from the combination of the user's current biometric measurement and the device's PUF output”, and “regeneration-and-comparison architecture”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). No such regeneration as argued is claimed whatsoever, no dynamic derivation is claimed, and no “regeneration-and-comparison architecture” is claimed whatsoever. The Kim reference was relied upon for a rudimentary check to see if the first and second IDs match each other, that is all the claim requires by reciting “performing primary authentication of a user of the user terminal by checking whether the first inborn ID and the second inborn ID match each other”; said otherwise, the claim merely requires checking that one piece of data (first inborn ID) matches a second piece of data (second inborn ID), the claim limitation requires nothing more under the broadest reasonable interpretation.
In response to applicant's argument that “Furthermore, Kim's purpose is explicitly to authenticate a specific physical camera device to a management server for surveillance network security - not to authenticate a human user with anonymity protection”, a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim. Here, the claim limitation only requires comparing two pieces of data (IDs) and seeing if they match under the broadest reasonable interpretation.
Applicant’s argument on page 17 “Even combining all three references - Asim, Kim, and Choi - the combination does not teach or suggest:…” constitutes a mere allegation of patentability. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant’s further arguments on page 17 of the remarks against the rationale to combine Asim in view of Kim, in view of Choi have been fully considered, but they are not persuasive. As in the Non-Final Rejection mailed 04/02/2026, in response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Kim teaches using the device information to compare and distinguish one device from another, so that secure PKI-based security protocols may be used to provide confidentiality of data (see Kim [0049-0051]). This teaching is sufficient for a person having ordinary skill in the art to be motivated to rely upon the Kim reference to perform the rudimentary check to see if the first and second IDs match each other.
Applicant finally argues on pages 17-18 that all of the pending issues have been resolved and the prior art does not teach the claimed invention. The Examiner respectfully disagrees at least for the reasons set forth above in the response to remarks and additionally defers to the final rejection presented below as a response to this argument. To clarify the record, the Examiner traverses Applicant’s characterization on page 18 “The cited prior art (Asim, Choi, Kim) does not disclose or suggest the specific architecture” as there are still remaining genuine issues of material fact regarding whether the originally filed specification demonstrates possession by the inventor of the claimed invention.
Information Disclosure Statement
The listing of references in the specification is not a proper information disclosure statement. 37 CFR 1.98(b) requires a list of all patents, publications, or other information submitted for consideration by the Office, and MPEP § 609.04(a) states, "the list may not be incorporated into the specification but must be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on form PTO-892, they have not been considered.
In nonprovisional applications, applicants and other individuals substantively involved with the preparation and/or prosecution of the application have a duty to submit to the Office information which is material to patentability as defined in 37 CFR 1.56. Applicant has still not filed an information disclosure statement (IDS) containing the material incorporated by reference from Korean Patent Registration No. KR 101139630B1 and US Publication No. US 2013/0101114A1 found within the specification.
The filing of a reply by a party to a request for information from the Office, whether by a practitioner or non-practitioner, constitutes a certification under § 11.18(b). Thus, violations of § 11.18(b)(2) in this context may subject the party to sanctions under § 11.18(c). See 37 CFR 1.4(d)(4)(i). Section 11.18(b)(2) calls for a duty of reasonable inquiry to ensure that the paper is not being presented for any improper purpose, the legal contentions are warranted by law, the allegations and other factual contentions have evidentiary support, and the denials of factual contentions are warranted on the evidence.
Compliance will not be held in abeyance with respect to responding to the objection, rejection, or other requirement for the incorporation to be effective see MPEP 608.01(p). In no case may the correction be made later than the close of prosecution as defined in 37 CFR 1.114(b), or abandonment of the application, whichever occurs earlier. Any correction inserting material by amendment that was previously incorporated by reference must be accompanied by a statement that the material being inserted is the material incorporated by reference and the amendment contains no new matter. 37 CFR 1.57(g).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 6-9, 13-16 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding Claims 1, 9, and 16:
Independent claims 1, 9, and 16 recite “a first inborn ID” and independent claims 1 and 16 also recite “a second inborn ID”. The limitations in question do not satisfy the written description requirement under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph. The specification does not describe the limitation in sufficient detail so that one of ordinary skill in the art would recognize that the applicant had possession of the claimed invention. The only support for determining/generating an “inborn ID” is in paragraphs [0014], [0021], [0029-0030], [0032], [0033-0034], [0047-0048], [0060-0061], [0070], [0082], [0090], [0104], Fig. 1-2, and Fig. 5-7. Paragraphs [0014], [0021], [0029], [0082], [0090], and [0104] merely recite claim language which do not provide support because none of the listed paragraphs disclose any steps/procedures or algorithms pertaining to how the inventor intended to obtain inborn IDs.
Paragraphs [0030] and [0032] only state that the “inborn ID” is “a combination of a device-specific physically unclonable function (PUF) and bioinformation” which fails to adequately disclose any steps/procedures or algorithms pertaining to how the inventor intended to obtain the inborn ID from such a combination.
Paragraphs [0033-0034] defer to Figure 1 and Figure 2 to support the generation of an inborn ID. However, both figures fail to adequately disclose any steps/procedures or algorithms pertaining to how the inventor intended to generate the inborn ID. Figure 1 is depicted as a black-box implementation where bioinformation is inputted into user terminal 100, and the intended result of “inborn id and key generation” is outputted. Figure 2 contains inborn ID 270 being obtained from a process which begins with bioinformation 210 and unique key 220. This generation process is still deficient in supporting the obtainment of an inborn ID.
Paragraphs [0047-0048] state the following: “FIGS. 1 and 2 are diagrams for describing an operation of generating an inborn ID and key in a user terminal according to an embodiment. Referring to FIG. 1, a user terminal 100 may generate an inborn ID and a key on the basis of bioinformation of a user and a unique key in the user terminal 100. The bioinformation may be input by the user, and the unique key may be a value inherent in the user terminal 100.” As described above, Figures 1 and 2 fail to adequately disclose any steps/procedures or algorithms pertaining to how the inventor intended to generate the inborn ID. Paragraphs [0047-0048] merely state that the inborn ID may be obtained “on the basis of bioinformation and a unique key” without actually disclosing how the inventor actually intended generate the ID.
Paragraphs [0060-0061] fail to adequately disclose any steps/procedures or algorithms pertaining to how the inventor intended to obtain the inborn ID because it relies on the description of Figure 2, and does not adequately describe how the inborn ID 270 is obtained because it is dependent upon the black-box implementations displayed in seed key 230 being input to a black box “encryption algorithm” (which is not described in the originally filed disclosure) and the desired result of authentication key 240 is obtained without any disclosure regarding how the inventor obtained such a desired result.
Finally, paragraph [0070] of the disclosure recites “A user terminal 510 may determine a seed key using at least some of bioinformation obtained from a user and at least some of a unique key, and generate an authentication key on the basis of the seed key. The user terminal 510 may generate an inborn ID on the basis of a first part of the authentication key, and generate a public key and a private key on the basis of a second part of the authentication key. In another embodiment, the user terminal 510 may determine a seed key using at least one of at least some of bioinformation, at least some of a unique key, and at least some of stored random number information, and generate an authentication key on the basis of the seed key.” The specification is silent with regard to the steps/procedures or algorithms pertaining to how the inventor intended to obtain inborn IDs. It is only described in paragraph [0070] that the inborn ID is generated by the user terminal 510 “on the basis of a first part of the authentication key” without actually disclosing how the inventor intended to actually generate the inborn ID itself.
In MPEP 2161.01, "computer-implemented functional claim language must still be evaluated for sufficient disclosure under the written description". And MPEP 2161.01(I) "generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed." For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date.
As in MPEP 2161.01 (I), "The description requirement of the patent statute requires a description of an invention, not an indication of a result that one might achieve if one made that invention."). It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015).
AS in MPEP 2161.01 “For instance, generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1349-50, 94 USPQ2d at 1171 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention’s boundaries.") (citing Eli Lilly, 119 F.3d at 1568, 43 USPQ2d at 1405-06); Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement because it failed to support the scope of the genus claimed); Fiers v. Revel, 984 F.2d 1164, 1170, 25 USPQ2d 1601, 1606 (Fed. Cir. 1993) (rejecting the argument that "only similar language in the specification or original claims is necessary to satisfy the written description requirement").”
“The Federal Circuit has explained that a specification cannot always support expansive claim language and satisfy the requirements of 35 U.S.C. 112 "merely by clearly describing one embodiment of the thing claimed." LizardTech v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1346, 76 USPQ2d 1731, 1733 (Fed. Cir. 2005). The issue is whether a person skilled in the art would understand applicant to have invented, and been in possession of, the invention as broadly claimed. In LizardTech, claims to a generic method of making a seamless discrete wavelet transformation (DWT) were held invalid under 35 U.S.C. 112, first paragraph, because the specification taught only one particular method for making a seamless DWT and there was no evidence that the specification contemplated a more generic method. "[T]he description of one method for creating a seamless DWT does not entitle the inventor . . . to claim any and all means for achieving that objective." LizardTech, 424 F.3d at 1346, 76 USPQ2d at 1733.”
Independent claims 1 and 16 also recite “receiving … a certificate issued by an authentication system from a user terminal” and “obtaining … a public key of the user terminal included in the certificate by decrypting the certificate using a public key of the authentication system”. The specification does not describe the limitation in sufficient detail so that one of ordinary skill in the art would recognize that the applicant had possession of the claimed invention. The only support for the certificate being issued by an authentication system is in Figures 4 and 6. These figures fail to provide support for the described claim limitations because both the figures and the written description fail to adequately disclose the steps/procedures regarding how the inventor intended to obtain the certificate issued by an authentication system, only the intended results that a certificate may be issued based on the inborn ID and public key, and that the authentication execution device obtains such a public key to attempt to decrypt the certificate are disclosed. The limitation currently claims generically all forms of certificates, and the specification does not provide support for such a broad genus limitation.
Independent claims 1, 9, and 16 further recite “wherein the first inborn ID is generated from a first part of an authentication key extracted from the authentication key, wherein the first part corresponds to a length required for the first inborn ID, wherein a private key and a public key of the user terminal are generated by applying a public key algorithm to a second part of the authentication key extracted from the authentication key, wherein the second part corresponds to a length required for generating the private key and the public key, wherein the first part and the second part are non-overlapping parts of the authentication key, wherein the certificate is generated by encrypting the second inborn ID and the public key of the user terminal with a private key of the authentication system, wherein the authentication key is generated by applying a predetermined encryption process to a seed key, wherein the seed key includes at least some of bioinformation of the user obtained from the user terminal and at least some of a unique key corresponding to the user terminal. The specification does not describe the limitations in sufficient detail so that one of ordinary skill in the art would recognize that the applicant had possession of the claimed invention. The only support for the generation of the first part of the authentication key comes from Figure 2 and paragraphs [0058-0061] of the disclosure. Figure 2 of the disclosure fails to adequately support this claim limitation as it only displays intended results that the “seed key” 230 goes through an encryption algorithm to produce “authentication key 240”, and then the authentication key 240 is split into “first part of authentication key” 250 and “second part of authentication key” 260. When viewing paragraphs [0058-0061], the disclosure is silent with regard to how the inventor intended to actually create the authentication key by using “a predetermined encryption algorithm”, nor does the disclosure describe how the inventor intended to extract or designate the first and second part of the authentication key. The originally filed disclosure is silent with respect to determining any length required for any key/inborn ID. The originally filed disclosure is deficient with respect to adequately supporting public key algorithms, encryption algorithms, decryption algorithms, key extractions, obtaining “some” bioinformation from the user, or how to generate the seed key from the output of a PUF and at least some bioinformation.
Independent claims 1, 9, and 16 recite the limitation “applying a predetermined encryption process to a seed key”. This amended claim limitation constitutes new matter and will be rejected on the ground that it recites elements without support in the original disclosure. See Waldemar Link, GmbH & Co. v. Osteonics Corp., 32 F.3d 556, 559, 31 USPQ2d 1855, 1857 (Fed. Cir. 1994); Vas-Cath Inc. v. Mahurkar, 935 F.2d 1555, 1560, 19 USPQ2d 1111, 1114 (Fed. Cir. 1991)(A written-description question often arises when an applicant, after filing a patent application, subsequently adds "new matter" not present in the original application.); In re Rasmussen, 650 F.2d 1212, 211 USPQ 323 (CCPA 1981). The originally filed disclosure as a whole is silent with respect to any recited “predetermined encryption process” and thus constitutes new matter.
Dependent claims fall together accordingly.
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) 9 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Asim et. al. (US Publication No. US 2012/0033807 A1) hereinafter Asim, in view of Choi; Unho (US Publication No. US 2017/0359180 A1) hereinafter Choi.
Regarding Claim 9:
Asim discloses an operating method of a user terminal, comprising (Asim Fig. 5, [0043]): … transmitting the first inborn ID, private key signature information of the user terminal, and a certificate issued by an authentication system to the authentication execution device (Asim Fig. 5 [0043-0048]); and receiving results of primary authentication and secondary authentication that are performed by the authentication execution device on the basis of at least one of the first inborn ID, the private key signature information, and the certificate (Asim [0046-0048] “The service provider searches its database for the certificate of the user, and checks the signature. If the signature verifies successfully, the data is accepted and assigned to the user-device pair or simply to the user … whose key was used. Otherwise, the data is rejected and a notification sent back to the user”), … wherein the certificate is generated by encrypting the second inborn ID and the public key of the user terminal with a private key of the authentication system (Asim [0045-0046]).
Asim does not explicitly disclose generating a first inborn ID in response to a user's request for an authentication execution device; … wherein the first inborn ID is generated from a first part of an authentication key extracted from the authentication key, wherein the first part corresponds to a length required for the first inborn ID, wherein a private key and a public key of the user terminal are generated by applying a public key algorithm to a second part of the authentication key extracted from the authentication key, wherein the second part corresponds to a length required for generating the private key and the public key, wherein the first part and the second part are non-overlapping parts of the authentication key … wherein the authentication key is generated by applying a predetermined encryption process to a seed key, wherein the seed key includes at least some of bioinformation of the user obtained from the user terminal and at least some of a unique key corresponding to the user terminal, and wherein the unique key is a physically unclonable function (PUF) output of the user terminal.
Choi teaches generating a first inborn ID in response to a user's request for an authentication execution device (Choi [0046] unique identity data,; [0050] service provider requests to verify authentication, [0106] “For example, in some embodiments, an addition code (i.e., a device code) coded (tokened) from identity data of an loT device of the user can be concatenated with the biometric code (see FIG. 6(b) and (c)). The identity data of the loT device is unique identity data assigned to each loT device at the time of manufacturing, distributing, or purchasing the device. The identity data of the loT device contains device number, release information, serial number, electronic product code (EPC), universal product code (UPC), physically unclonable function (PUF)” [0118]); … wherein the first inborn ID is generated from a first part of an authentication key extracted from the authentication key (Applicant admitted bit extraction operations have been fundamental to computing since the 1960s; Choi [0046], [0106-0122]), wherein the first part corresponds to a length required for the first inborn ID (Applicant admitted “The selection of identifier lengths in authentication systems is a routine design choice well within the knowledge of those skilled in the art… the specific bit length is a routine parameter”; Choi Fig. 6, [0105-0122] include the concatenated key segment of Choi to be able to utilize different parts of the key for different uses and can be different from each other), wherein a private key and a public key of the user terminal are generated by applying a public key algorithm to a second part of the authentication key extracted from the authentication key (Applicant admitted bit extraction operations have been fundamental to computing since the 1960s; Applicant admitted deriving an authentication key from a seed key may be performed by one skilled in cryptographic arts using any standard algorithm and is routine in the art and requires no inventive contribution; Choi Fig. 6, [0105-0113] include the concatenated key segment of Choi to be able to utilize different parts of the key for different uses), wherein the second part corresponds to a length required for generating the private key and the public key (Applicant admitted “The selection of identifier lengths in authentication systems is a routine design choice well within the knowledge of those skilled in the art… the specific bit length is a routine parameter”; Choi Fig. 6, [0105-0113] include the concatenated key segment of Choi to be able to utilize different parts of the key for different uses and can be different from each other), wherein the first part and the second part are non-overlapping parts of the authentication key (Applicant admitted “The selection of identifier lengths in authentication systems is a routine design choice well within the knowledge of those skilled in the art… the specific bit length is a routine parameter”; Choi Fig. 6, [0105-0113] include the concatenated key segment of Choi to be able to utilize different parts of the key for different uses and can be different from each other)… wherein the authentication key is generated by applying a predetermined encryption process to a seed key (Applicant admitted deriving an authentication key from a seed key may be performed by one skilled in cryptographic arts using any standard algorithm and is routine in the art and requires no inventive contribution; Choi [0047] “The above-mentioned one or more additional codes can be concatenated with each of the biometric codes. Consequently, the private key and the public key include a plurality of biometric code or a plurality of biometric code with the additional code concatenated. In this case, the plurality of biometric codes can be used for different purposes from each other. For example, any one of the plurality of biometric codes is designated to be used for performing a normal user authentication of the private key… for requesting an initialization of an authentication management system that is managed by a remote entity (e.g., a service providing server, an authentication server, a centralized controller, or the like), and the like”, [0096-0098] “The communication terminal then encrypts the biometric data of the user with the issued public key certificate (Step S454). That is, the communication terminal encrypts the biometric data based on an encryption algorithm defined in the public key certificate. The encrypted biometric data is stored in the communication terminal, to be used in the user authentication procedure later on”), wherein the seed key includes at least some of bioinformation of the user obtained from the user terminal and at least some of a unique key corresponding to the user terminal (Choi [0098] “Subsequently, the communication terminal generates a pair of keys (a public key and a private key) by inserting the generated biometric code in an extended validation (EV) domain of the public key certificate (Step S456). That is, the biometric code is inserted in the generated private key and public key. The private key is stored in the communication terminal to be used in the user authentication procedure later on. Although it is not shown in FIG. 4A, other additional code can be generated in a manner same as or similar to that for the biometric code, and added to the public key certificate as an additional authentication element”, [0105-0122] authentication information including containing codes inserted in the private key wherein specifically Fig. 6(j) of Choi displays an explicit example of a biometric code concatenated with a UPC/EPC code, a PAN code, and most importantly a PUF code), and wherein the unique key is a physically unclonable function (PUF) output of the user terminal (Choi [0105-0122] authentication information including containing codes inserted in the private key wherein specifically Fig. 6(j) of Choi displays an explicit example of a biometric code concatenated with a UPC/EPC code, a PAN code, and most importantly a PUF code).
It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the authentication execution device operating method taught by Asim with the key generation and segmentation taught by Choi.
The motivation for this combination would be to improve security by extending the key creation/segmentation to incorporate multi-factor authentication such as incorporating a physically unclonable function (PUF), biometrics, or tokened identity data as taught in Choi (Choi paragraph [0109] for example discusses how incorporating location information into the key for example could improve trust).
Regarding Claim 13:
The combination of Asim and Choi further teaches the operating method of claim 9 (Asim Fig. 5, [0043]), wherein the certificate is generated by signing the second inborn ID and the public key of the user terminal, which are transmitted from the user terminal to the authentication system in a setup process, with a private key of the authentication system (Asim [0046]).
Regarding Claim 14:
The combination of Asim and Choi further teaches the operating method of claim 9 (Asim Fig. 5, [0043]), wherein the second inborn ID and the public key of the user terminal, which are transmitted from the user terminal to the authentication system in a setup process, along with personal information of the user are registered in the authentication system (Asim [0046]).
Regarding Claim 15:
The combination of Asim and Choi further teaches the operating method of claim 9 (Asim Fig. 5, [0043]), wherein, in the receiving of the results of the primary authentication and secondary authentication, a result of an operation that is performed according to the request is received in response to completion of the primary authentication and the secondary authentication (Asim [0047-0048] authentication is requested in order for the user to use the device to produce a measurement and transmit to a health provider).
Claim(s) 1, 6-8, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Asim in view of Kim, Youngsam (European Patent Office Publication EP 3461100A1) hereinafter Kim, further in view of Choi.
Regarding Claims 1 and 16:
Claim 1. Asim discloses an operating method of an authentication execution device, comprising (Asim Fig. 5, [0043]): receiving a first inborn ID, private key signature information, and a certificate issued by an authentication system from a user terminal (Asim Fig. 5, [0041] “The data and MAC are sent to the service provider, step A1.5, together with the identity of the user Uj (for example the user ID, the email address, etc.). Authentication of the user and the device are then carried out…” [0046] “a certificate authority (or the service provider) can create a public-key certificate for the user and his devices in the enrolment phase (these certificates will contain the user identity information, the device identity information, the public key for that user/device pair Kuij_pub, and perhaps other personal data information such as age, address, etc. All this information would then be signed by the private key of the certificate authority. If self certification is used, then the user will sign this data with his private key Kuij.”, and [0048] “The data and signature are sent to the service provider, together with the user/device certificate containing the public-key Kuij_pub.”); obtaining a second inborn ID and a public key of the user terminal included in the certificate by decrypting the certificate using a public key of the authentication system (Asim [0041], [0046], [0048] the certificate received contains the public key); … and when the primary authentication is completed, performing secondary authentication of the user by verifying the private key signature information with the public key of the user terminal (Asim [0046-0048] “The service provider searches its database for the certificate of the user, and checks the signature. If the signature verifies successfully, the data is accepted and assigned to the user-device pair or simply to the user … whose key was used. Otherwise, the data is rejected and a notification sent back to the user”)… wherein the certificate is generated by encrypting the second inborn ID and the public key of the user terminal with a private key of the authentication system (Asim [0046]).
Asim does not specifically disclose a method step of performing primary authentication of a user of the user terminal by checking whether the first inborn ID and the second inborn ID match each other… wherein the first inborn ID is generated from a first part of an authentication key extracted from the authentication key, wherein the first part corresponds to a length required for the first inborn ID, wherein a private key and a public key of the user terminal are generated by applying a public key algorithm to a second part of the authentication key extracted from the authentication key, wherein the second part corresponds to a length required for generating the private key and the public key, wherein the first part and the second part are non-overlapping parts of the authentication key... wherein the authentication key is generated by applying a predetermined encryption process to a seed key, wherein the seed key includes at least some of bioinformation of the user obtained from the user terminal and at least some of a unique key corresponding to the user terminal, and wherein the unique key is a physically unclonable function (PUF) output of the user terminal.
Kim teaches a method step of performing primary authentication of a user of the user terminal by checking whether the first inborn ID and the second inborn ID match each other (Kim Fig. 2, [0036] device information may be requested; [0039-0041] “it is determined whether the device binding information included in the certificate is generated based on the device information about the camera [the camera is the subject device which sent the certificate] 110 (in step 163a)… the management device 120 may compare in step 163a whether the device information included in the device binding information corresponds to device information acquired by the management device through the step 161. To this end, the management device 120 can verify the digital signature of the certificate authority with respect to the device binding information, and can also perform certificate chain verification consequently. For example, the management device 120 may determine whether at least a portion of the device information is included in device binding information in the certificate.”).
It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the operation of an authentication execution device as disclosed by Asim with the step of matching the first and second ID as taught by Kim. The motivation for this combination would be to improve security by using the device information to compare and distinguish one device from another, so that secure PKI-based security protocols may be used to provide confidentiality of data (see Kim [0049-0051]).
Kim does not explicitly teach wherein the first inborn ID is generated from a first part of an authentication key extracted from the authentication key, wherein the first part corresponds to a length required for the first inborn ID, wherein a private key and a public key of the user terminal are generated by applying a public key algorithm to a second part of the authentication key extracted from the authentication key, wherein the second part corresponds to a length required for generating the private key and the public key, wherein the first part and the second part are non-overlapping parts of the authentication key... wherein the authentication key is generated by applying a predetermined encryption process to a seed key, wherein the seed key includes at least some of bioinformation of the user obtained from the user terminal and at least some of a unique key corresponding to the user terminal, and wherein the unique key is a physically unclonable function (PUF) output of the user terminal.
Choi teaches wherein the first inborn ID is generated from a first part of an authentication key extracted from the authentication key (Applicant admitted bit extraction operations have been fundamental to computing since the 1960s; Choi [0046], [0106-0122]), wherein the first part corresponds to a length required for the first inborn ID (Applicant admitted “The selection of identifier lengths in authentication systems is a routine design choice well within the knowledge of those skilled in the art… the specific bit length is a routine parameter”; Choi Fig. 6, [0105-0122] include the concatenated key segment of Choi to be able to utilize different parts of the key for different uses and can be different from each other), wherein a private key and a public key of the user terminal are generated by applying a public key algorithm to a second part of the authentication key extracted from the authentication key (Applicant admitted bit extraction operations have been fundamental to computing since the 1960s; Applicant admitted deriving an authentication key from a seed key may be performed by one skilled in cryptographic arts using any standard algorithm and is routine in the art and requires no inventive contribution; Choi Fig. 6, [0105-0113] include the concatenated key segment of Choi to be able to utilize different parts of the key for different uses), wherein the second part corresponds to a length required for generating the private key and the public key (Applicant admitted “The selection of identifier lengths in authentication systems is a routine design choice well within the knowledge of those skilled in the art… the specific bit length is a routine parameter”; Choi Fig. 6, [0105-0113] include the concatenated key segment of Choi to be able to utilize different parts of the key for different uses and can be different from each other), wherein the first part and the second part are non-overlapping parts of the authentication key (Applicant admitted “The selection of identifier lengths in authentication systems is a routine design choice well within the knowledge of those skilled in the art… the specific bit length is a routine parameter”; Choi Fig. 6, [0105-0113] include the concatenated key segment of Choi to be able to utilize different parts of the key for different uses and can be different from each other)… wherein the authentication key is generated by applying a predetermined encryption process to a seed key (Applicant admitted deriving an authentication key from a seed key may be performed by one skilled in cryptographic arts using any standard algorithm and is routine in the art and requires no inventive contribution; Choi [0047] “The above-mentioned one or more additional codes can be concatenated with each of the biometric codes. Consequently, the private key and the public key include a plurality of biometric code or a plurality of biometric code with the additional code concatenated. In this case, the plurality of biometric codes can be used for different purposes from each other. For example, any one of the plurality of biometric codes is designated to be used for performing a normal user authentication of the private key… for requesting an initialization of an authentication management system that is managed by a remote entity (e.g., a service providing server, an authentication server, a centralized controller, or the like), and the like”, [0096-0098] “The communication terminal then encrypts the biometric data of the user with the issued public key certificate (Step S454). That is, the communication terminal encrypts the biometric data based on an encryption algorithm defined in the public key certificate. The encrypted biometric data is stored in the communication terminal, to be used in the user authentication procedure later on”), wherein the seed key includes at least some of bioinformation of the user obtained from the user terminal and at least some of a unique key corresponding to the user terminal (Choi [0098] “Subsequently, the communication terminal generates a pair of keys (a public key and a private key) by inserting the generated biometric code in an extended validation (EV) domain of the public key certificate (Step S456). That is, the biometric code is inserted in the generated private key and public key. The private key is stored in the communication terminal to be used in the user authentication procedure later on. Although it is not shown in FIG. 4A, other additional code can be generated in a manner same as or similar to that for the biometric code, and added to the public key certificate as an additional authentication element”, [0105-0122] authentication information including containing codes inserted in the private key wherein specifically Fig. 6(j) of Choi displays an explicit example of a biometric code concatenated with a UPC/EPC code, a PAN code, and most importantly a PUF code), and wherein the unique key is a physically unclonable function (PUF) output of the user terminal (Choi [0105-0122] authentication information including containing codes inserted in the private key wherein specifically Fig. 6(j) of Choi displays an explicit example of a biometric code concatenated with a UPC/EPC code, a PAN code, and most importantly a PUF code).
It would have been further obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the authentication execution device operating method taught by Asim and the step of matching the first and second ID as taught by Kim, further with the key generation and segmentation taught by Choi. The motivation for this combination would be to improve security by extending the key creation/segmentation to incorporate multi-factor authentication such as incorporating a physically unclonable function (PUF), biometrics, or tokened identity data as taught in Choi (Choi paragraph [0109] for example discusses how incorporating location information into the key may improve trust).
Regarding independent claim 16, the claim(s) recite(s) substantially the same content as claim(s) 1 and is rejected by the rationales set forth for claim 1. The recitation of “an authentication execution device, comprising: a processor; and a memory including at least one instruction executable by the processor” is rendered obvious by the teachings of Kim in paragraphs [0072-0074]. It would have further been obvious for one of ordinary skill in the art to combine the operating method disclosed by Asim with the device taught by Kim, and the motivation would be to improve security by placing upon the method disclosed by Asim into a device comprising a processor and a memory as taught by Kim.
Regarding Claim 6:
The combination of Asim, Kim, and Choi further teaches the operating method of claim 1 (Asim Fig. 5, [0043]), wherein the certificate is generated by signing the second inborn ID and the public key of the user terminal, which are transmitted from the user terminal to the authentication system in a setup process, with a private key of the authentication system (Asim [0046]).
Regarding Claim 7:
The combination of Asim, Kim, and Choi further teaches the operating method of claim 1 (Asim Fig. 5, [0043]), wherein the second inborn ID and the public key of the user terminal, which are transmitted from the user terminal to the authentication system in a setup process, along with personal information of the user are registered in the authentication system (Asim [0046]).
Regarding Claim 8:
The combination of Asim, Kim, and Choi further teaches the operating method of claim 1 (Asim Fig. 5, [0043]), further comprising, when the secondary authentication is completed, performing an operation according to a request received from the user terminal (Asim [0047-0048] authentication is requested in order for the user to use the device to produce a measurement and transmit to a health provider).
Conclusion
The prior art made of record in the submitted PTO-892 Notice of References Cited and not relied upon is considered pertinent to applicant’s disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MIGUEL A LOPEZ whose telephone number is (703)756-1241. The examiner can normally be reached 8:00AM-5:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached on 5712727624. 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.
/M.A.L./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/ Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights