DETAILED ACTION
Status of Claims
The present application, filed on or after 3/16/2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the Application and claims filed 03/30/2026.
Claims 1, 3, 4, 11, 13, 15, 16 are amended.
Claims 2, 5, 12, 14, 17, 19 are canceled.
Claims 1, 3-4, 6-11, 13, 15-16, 18, 20 have been examined and are pending.
(AIA ) Examiner Note
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.
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 15 is rejected under 35 U.S.C. 112(b) or (for pre-AIA ) 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor, a joint inventor, or (for pre-AIA ) the applicant regards as the invention.
Pertaining to Claim 15, which recites the following: The method of claim 11, wherein the BmDL was issued and digitally signed by an employer of the user, Examiner notes this appears to be completely non-functional descriptive material; i.e. claim 15 does not state that the method further includes issuing and digitally signing the BmDL. The method of claim 11 is directed towards a method performed “on an electronic online system” which is distinct from the user device where the BmDL is claimed to reside. It appears the method, of claim 11, is agnostic as to who issued and signed the BmDL which resides on the user device. Furthermore, the Specification does not appear to contemplate that the online system of claim 11 is used by the employer to issue and sign the BmDL. Therefore, it is not clear whether a further limitation is being imputed upon the method claimed as being performed by the online system. Claim 15 is therefore rejected as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor, a joint inventor, or (for pre-AIA ) the applicant regards as the invention. For the purpose of compact prosecution, the claim is interpreted to be completely directed towards non-functional descriptive material which fails to further place a limitation upon the method performed by the online system of the parent claim.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 6, 7, 15 are rejected under 35 U.S.C. 112(d), as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Pertaining to Claim 6, which recites the following: The verifier system of claim 1, wherein the BmDL was issued by an employer of the user, Examiner notes this is completely non-functional descriptive material; the BmDL is not claimed as part of nor a component of the verifier system of claim 1. Instead, the BmDL is recited as being on the user device which is not claimed as a component of the verifier system. Furthermore, it is immaterial to the verifier system who or what issued the BmDL contained on a device which is not claimed as part of the system. Claim 6 is rejected under 35 USC 112(d) as failing to further stipulate a limitation on the parent claim from which it depends.
Pertaining to Claim 7, which recites the following: The verifier system of claim 1, wherein the BmDL is digitally signed by an issuer system, Examiner notes this is completely non-functional descriptive material; the BmDL is not claimed as part of nor a component of the verifier system of claim 1. Instead, the BmDL is recited as being on the user device which is not claimed as a component of the verifier system. Claim 7 is rejected under 35 USC 112(d) as failing to further stipulate a limitation on the parent claim from which it depends.
Pertaining to Claim 15, which recites the following: The method of claim 11, wherein the BmDL was issued and digitally signed by an employer of the user, Examiner as noted supra in regards to the 35 USC 112(b) rejection, this claim is interpreted as being comprised completely of non-functional descriptive material; the method of claim 11 is directed towards a method performed “on an electronic online system” which is distinct from the user device where the BmDL is claimed to reside. The Specification does not appear to contemplate that the online system of claim 11 is used by the employer to issue and sign the BmDL. It appears the method, of claim 11, is agnostic as to who issued and signed the BmDL which resides on the user device. Claim 15 is rejected under 35 USC 112(d) as it appears to fail to stipulate a limitation on the parent claim from which it depends.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-4, 6-11, 13, 15, 16, 18, 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea (i.e. a judicial exception) without significantly more.
Per step 1 of the 2019 Revised Patent Subject Matter Eligibility Guidance, the claims are directed towards a process, machine, or manufacture.
Per step 2A Prong One, the claims recite specific limitations which fall within at least one of the groupings of abstract ideas enumerated in the 2019 PEG, as follows:
Per Independent claims 1, 11, and 16:
a request for a data element from a user device of a user, the request specifying an employment verification for the user.
receiving a response… the response including: [an] issuer certificate and the data element that satisfies the request, the data element including an identifier of an employer of the user;
verifying authenticity of the issuer certificate using a public key associated with the issuer system; and
confirming that the data element has not been altered based on the verified issuer certificate to prove a place of employment of the user or a status of employment of the user.
As noted supra, these limitations fall within at least one of the groupings of abstract ideas enumerated in the 2019 PEG. Specifically, these limitations fall within the group Certain Methods Of Organizing Human Activity (e.g. fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
That is, the claimed method is directed towards controlling access to employer resources by checking and verifying a user’s identity and authorization to access such resources. There is no technical problem being solved and no technical solution presented to a technical problem. The steps are claimed at a very high-level of generality and abstraction. For example, requesting information (e.g. data elements) regarding employment verification is a business decision and not technical in nature. There is no technical solution for making the request. Furthermore, the response is not technical and it is a fundamental business practice to provide a response to such as request by an employee when requested to do so. It is a business decision of an employer to verify authenticity of the user’s response and if the response includes an encrypted certificate using PKI, then it is common to decrypt such certificates using a public key (this is not applicant’s invention and is not a technical improvement to any business method). The confirming step appears to be nothing more than an assumption, per the Specification at [0048]1, where once the verification step is completed then the data elements contained within the certificate are assumed to be valid. There is nothing technical about this assumption but instead, it is purely a business decision. There is no technical problem purported here and no technical solution to solve a technical problem. Thus, the claims are directed towards controlling access to employer resources and thus falling into Certain Methods of Organizing Human Activity. Furthermore, the mere nominal recitation of a generic computer components to request and receive requested data does not take the claim limitation out of the enumerated grouping. Thus, the claims recite an abstract idea.
Per step 2A Prong 2, the Examiner finds that the judicial exception is not integrated into a practical application. Although there are additional elements, other than those noted supra, recited in the claims, none of these additional element(s) or a combination of elements as recited in the claims apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception. As drafted, the claims as a whole merely describe how to generally “apply” the aforementioned concepts using generic computer components, or, link them to a field of use (i.e. in this case controlling access to employer resources) or, serve as insignificant extra-solution activity (e.g. data collection, acquisition, transmittal, or storage). The claimed computer components are recited at a high level of generality and are merely invoked as tools to implement the idea but are not technical in nature. Simply implementing the abstract idea on or with generic computer components is not a practical application of the abstract idea.
These additional limitations are all those not specifically identified supra, e.g.: “…A verifier system for managing digital employment records, the verifier system comprising: a processor subsystem; and memory including instructions, which when executed by the processor subsystem, cause the processor subsystem to: transmit… [to] a user device… the data element included in a business mobile driver's license (BmDL) data structure that is linked to a mobile driver's license (mDL) of the user via a driver's license identifier, the BmDL data structure including an employment credential, an issuer certificate certifying authenticity of the employment credential, and a device identifier of the user device, where the issuer certificate issued by an issuer system; receive a response from the user device,…”
However, these elements do not present a technical solution to a technical problem; i.e. Applicant’s invention is not a technique nor technical solution for “transmit[ting]” a request nor “receiving” requested data nor is it any particular data structure or device. Applicant has not purported to invent any particular data structure and this feature is seen as a generic reference to a database and or the well-known .mdoc file format from which data may be retrieved when recited at this high-level of generality. Furthermore, the devices mentioned are all generic in nature and are not the applicant’s invention. The additional elements do not recite a specific manner of performing any of the steps core to the already identified abstract idea. Instead, these features merely serve to generally “apply” the aforementioned concepts or, link them to a field of use or, are insignificant extra-solution activity to the already identified abstract idea and do not integrate the abstract idea into a practical application thereof.
Per Step 2B, the Examiner does not find that the claims provide an inventive concept, i.e., the claims do not recite additional element(s) or a combination of elements that amount to significantly more than the judicial exception recited in the claim. As discussed with respect to Step 2A Prong Two, the additional elements in the independent claims were considered as merely serving to generally “apply” the aforementioned concepts via generically described computer components (e.g. by one or more processors, user devices, etc…) and “link” them to a field of use (i.e. in this case managing employment records), or as insignificant extra-solution activity (i.e. data transmittal such as transmitting a request for data, and data acquisition, such as receiving a response, etc…). For the same reason these elements are not sufficient to provide an inventive concept; i.e. the same analysis applies here in 2B. Mere instructions to apply an exception using a generic computer component and conventional data gathering cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. So, upon revaluating here in step 2B, these elements are determined to amount to no more than mere instructions to apply the exception using generic computer components (i.e. a server) and/or gather and transmit data which is well-understood, routine, conventional activity in the field; i.e. note the Symantec, TLI, and OIP Techs Court decisions cited in MPEP 2106.05(d)(ll) indicate that mere receipt or transmission of data over a network is a well-understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here).
Accordingly, alone and in combination, these elements do not integrate the abstract idea into a practical application, as found supra, nor provide an inventive concept, and thus the claims are not patent eligible.
As for the dependent claims, the dependent claims do recite a combination of additional elements. However, these claims as a whole, considered either independently or in combination with the parent claims, do not integrate the identified abstract idea into a practical application thereof nor do they provide an inventive concept.
For example, dependent claim 3 recites the following: “…wherein the identifier of the employer includes an employer name..” However, a description of idea as basic as a name being used as an identifier is not technical in nature nor does it provide a technical solution to a technical problem and is not significantly more than the abstract idea itself and does not further integrate the abstract idea into a practical application thereof.
Therefore, the Examiner does not find that these additional claim limitations integrate the abstract idea into a practical application nor provide an inventive concept. Instead, these limitations, as a whole and in combination with the already recited claim elements of the parent claims, are not significantly more than the already identified abstract idea. A similar finding is found for the remaining dependent claims.
For these reasons, the claims are not found to include additional elements that are sufficient to amount to significantly more than the judicial exception and therefore the claims are not found to be patent eligible.
Please see the 2019 Revised Patent Subject Matter Eligibility Guidance published in the Federal Register (84 FR 50) on January 7, 2019 (found at http://www.uspto.gov/patent/laws-and-regulations/examination-policy/examination-guidance-and-training-materials).
Claim Rejections - 35 USC § 103 (AIA )
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 1, 3-4, 8-11, 13, 16, 18, 20 are rejected under 35 U.S.C. 103 as obvious over Maddukuri (2025/0038984 A1; hereinafter, “Maddukuri”) in view of Official Notice in view of Cloud (US 2013/0103495 A1; hereinafter, “Cloud”).
Claims 1, 11, 16
Pertaining to claims 1, 11, 16 exemplified in the limitations of claim 1, Maddukuri as shown teaches the following:
A verifier system for managing digital employment records (Maddukuri, see at least Figs.1&2
PNG
media_image1.png
608
826
media_image1.png
Greyscale
),
the verifier system comprising:
a processor subsystem; and memory including instructions (Maddukrui, see citations noted supra, including Fig. 2 and [0031]-[0032] regarding Verifier Computing Environment 105 includes processor and memory storing instructions), which when executed by the processor subsystem, cause the processor subsystem to:
transmit a request for a data element from a user device of a user, the request specifying an employment verification for the user (Maddukuri, see citations noted supra including also at least [0019]-[0024], e.g.: “…the verifier computing environment 105 can establish a session [transmit a request], in some cases an interactive session, with a wallet service 112 executed by a client device 109 [a user device of a user] to verify a verifiable credential 118 issued to the user by an issuer. The session can be established for various purposes, such as …verifying the identity of a user [e.g. specifying an employment verification], or verifying any credentials of the user that are issued electronically as a verifiable credential 118… a verifiable credential 118 corresponds to a digital credential used to identify an attribute [a data element] (e.g., qualification, component, authority [e.g. employee has authority according to employment agreement], achievement, personally quality, etc.) associated with the credential holder (e.g., user 103)… The verifiable credential 118 can include information represented by a physical credential (e.g., passport, driver's license, birth certificate, etc.) or a non-physical credential (e.g., bank account ownership, etc.) that identifies one or more attributes associated with the user 103…”; Examiner finds the disclosure of Maddukuri implies, if not explicitly states, his established session with user device is to request, and receive from his user’s device, the verifiable credential 118, including the attributes [data element(s)] information which Maddukuri teaches can be included in such verifiable credential, to enable the verification of such credential and attributes contained therein as is disclosed; e.g. verify user identity and/or user authority, etc… Furthermore, Examiner takes Official Notice of the following facts: it was old and well known to a person of ordinary skill in the art before the effective filing date of the claimed invention that such identity and/or authority verification is commonplace for employment verification e.g. such as to comply with Homeland Security Presidential Directive 12 ("HSPD-12")2 which establishes a mandatory, U.S. Government-wide standard for secure and reliable forms of identification issued by the Federal Government to its employees and contractors (including contractor employees). This directive mandates a federal standard for secure and reliable forms of identification and employee verification. Therefore, in view of these findings, Examiner finds Maddukuri, in view of the knowledge of a person of ordinary skill in the art, provides ample motivation to a person of ordinary skill in the art before the effective filing date of the claimed invention to perform a step of transmitting a request to Maddukuri’s user’s mobile device requesting the attribute(s) [data element(s)] for which the verifiable credential 118 is intended to represent and which are to be verified for the purpose of specifying an employment verification of the user; e.g. for the purpose of complying with Homeland Security Presidential Directive 12 ("HSPD-12") and because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.),
the data element included in a business mobile driver's license (BmDL) data structure that is linked to a mobile driver's license (mDL) of the user via a driver's license identifier, the BmDL data structure including an employment credential, an issuer certificate certifying authenticity of the employment credential, and a device identifier of the user device, where the issuer certificate issued by an issuer system (Furthermore, Examiner notes this clause is considered non-functional descriptive material. This description does not materially place a further limitation upon the claimed verifier system (claim 1), nor the method claimed to be performed by this verifier system called an electronic online system (claim 11), nor the non-transitory CRM (claim 16) which is claimed as storing instructions which when executed by a machine in an online system causes the machine to perform the claimed method; i.e. a description of where the data element which is being requested by the verifier system is, or was, stored (e.g. included in a BmDL data structure), and a description of other items which may be stored therein and/or have a link within this BmDL data structure is completely immaterial to the system and the request being made of the user device for the data element, by this system. This description of elements which are outside the scope of the claimed subject matter does not alter nor limit the claimed subject matter.
Nonetheless, Maddukuri, teaches the context as recited, e.g. per citations noted supra, e.g. see at least Fig. 2, [0019]-[0024], and [0080]-[0085]. Maddukrui’s attributes associated with the user [data elements], e.g. identity, authority, passport, drivers license, etc… are included in a verifiable credential 118 [issuer certificate] stored in wallet 142 [BmDL data structure] and the wallet is also disclosed as storing “a verifier public key 130” [device identifier] which is described as being “used by the client device 109 and/or wallet service 112 associated with the user 103 to authenticate the client device 109 in future interactions, etc…”; note applicant’s “employment credential” is broad and is not specifically contemplated in applicant’s specification from precluding such employment credential being the requested data element. Therefore, it appears they may be one and the same; i.e. the requested data element is an employment credential),
receive a response from the user device, the response including the issuer certificate and the data element that satisfies the request, (Maddkuri, see citations noted supra, e.g. again per [0019]-[0024]: teaching the verifier computer system receives the verifiable credential [issuer certificate] which include attributes [the data element].)
[…]
verify authenticity of the issuer certificate using a public key associated with the issuer system (Maddukuri, see again citations noted supra, in view of at least [0026]-[0027]: “…The issuer DID 121 can also contain or reference a public key of the issuer [a public key associated with the issuer]. Using the schema and the public key, the verifier computing environment 105 can verify the user 103 based upon the verifiable credential proof 125 obtained from the client device 109 of the user 103…” and per [0085]: “…At step 630, the verifier service 211 can verify the verifiable credential 118 [issuer certificate] or the verifiable credential proof 125 presented by the wallet service 112 to the verifier service 211 using the issuer public key 227 [using a public key associated with the issuer system] and/or schema); and
confirm that the data element has not been altered based on the verified issuer certificate to prove a place of employment of the user or a status of employment of the user (Maddukuri, again see citations noted supra, e.g. [0085]: “…At step 630, the verifier service 211 can verify the verifiable credential 118 [issuer certificate] or the verifiable credential proof 125 presented by the wallet service 112 to the verifier service 211 using the issuer public key 227 [using a public key associated with the issuer system] and/or schema)…”; In view of these teachings, the Examiner finds it is implied and there is motivation to likewise confirm that the attributes contained in the verified credential are also authenticate; i.e. if the verifiable credential 118 has been verified, then it follows the attributes [data elements] included therein, as noted e.g. per [0024] are also verified [the data element has not been altered]. It would have been obvious to do this because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649. Furthermore, as noted supra, Examiner has found it is obvious to perform the verification of Maddukuri for the purpose of to prove employment status of a user, e.g. verifying authority or identity of user for the purpose of verifying employment status to comply with Homeland Security Presidential Directive 12 ("HSPD-12") as noted supra. Note also applicant’s Specification at [0048] stating verification of issuer certificate results in assuming the authenticity of the data elements.)
Although Maddukuri in view of Official Notice teaches the above limitations, including attributes [data elements] of a verifiable credential [issuer certificate] which may be used to verify a user’s identity and/or authority, e.g. employment status, Maddukuri may not explicitly teach his attribute may be an identifier of an employer of the user. However, regarding this nuance, Maddukuri in view of Cloud teaches the following:
the data element including an identifier of an employer of the user (Cloud, see at least [0039], teaching, e.g.: “…The transaction certificate may also include additional types of information [data element] about the user, including the name or an identifier for the user's employer 716 [an identifier of an employer of the user], an indication of the user's position or job title 718, an indication of the user's monthly or yearly income 720…”);
Therefore, the Examiner understands that the limitation in question is merely applying a known technique of Cloud (directed towards using an identifier of an employer as an attribute of a verifiable certificate) which is applicable to a known base device/method of Maddukuri (already directed towards use of verifiable credential/certificates containing attribute to be verified, e.g. user identity, authority, etc…) to yield predictable results. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the technique of Cloud to the device/method of Maddukuri in order to perform the limitation in question such that Maddukuri’s attributes also contain an explicit reference to he user's employer 716 [an identifier of an employer of the user] for the purpose of verifying employment status, and because Maddukuri and Cloud are analogous art in the same field of endeavor (at least G06Q30/02) and because according to MPEP 2143(I) (C) and/or (D), the use of known technique to improve a known device, methods, or products in the same way (or which is ready for improvement) is obvious.
Claims 3, 13, 18
Maddukuri/Cloud teaches the limitations upon which these claims depends. Furthermore, as shown, Maddukur in view of Cloud teaches the following: …wherein the identifier of the employer includes an employer name or a business name (Cloud, see at least [0039], teaching, e.g.: “…The transaction certificate may also include additional types of information [data element] about the user, including the name or an identifier for the user's employer 716 [an identifier of an employer of the user], an indication of the user's position or job title 718, an indication of the user's monthly or yearly income 720…”).
Claim 4:
Maddukuri/Cloud teaches the limitations upon which these claims depends. Furthermore, as shown, Maddukur in view of Cloud teaches the following: The verifier system of claim 2, wherein the identifier of the employer includes a business name (Cloud, see at least [0039], teaching, e.g.: “…The transaction certificate may also include additional types of information [data element] about the user, including the name or an identifier for the user's employer 716 [an identifier of an employer of the user], an indication of the user's position or job title 718, an indication of the user's monthly or yearly income 720…”)
Claims 8, 20
Maddukuri/Cloud teaches the limitations upon which these claims depends. Furthermore, as shown, Maddukuri teaches the following: …wherein the response is used to allow the user access to secured premises (Maddukuri, see citations noted supra, e.g. [0024], [0058], etc… regarding his credential which can include information represented by a physical credential (e.g. a passport, etc…) [a passport is used to control access to secured premises, e.g. secured border crossings]; therefore, there is motivation provided by Maddukuri’s disclosure to a person of ordinary skill in the art before the effective filing date of the claimed invention to use Maddukuri’s response to allow a user access such as in the case of use of passports to access secured premises, e.g. border crossings and therefore it would be obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use Maddukuri’s user’s device response to allow a user access to secured premises such as my be controlled by and/or require verification of passport credentials which Maddukuri’s response conveys and because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.)
Claim 9:
Maddukuri/Cloud teaches the limitations upon which these claims depends. Furthermore, as shown, Maddukuri teaches the following: The verifier system of claim 1, wherein the response is used to allow the user access to secured business resources (Maddukuri, see citations noted supra, e.g. [0024], [0058], etc… regarding his credential which can include information represented by a physical credential (e.g. a passport, etc…) [a passport is used to control access to secured government resources, e.g. secured border crossings to access the resources made available by businesses only within specific nations or countries, etc…]; therefore, there is motivation provided by Maddukuri’s disclosure to a person of ordinary skill in the art before the effective filing date of the claimed invention to use Maddukuri’s response to allow a user access to such secured business resources such as in the case of use of passports to access secured border crossings and the business resources only available across such border and therefore it would be obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use Maddukuri’s user’s device response to allow a user such access as my be controlled by and/or require verification of passport credentials which Maddukuri’s response conveys and because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.).
Claim 10:
Maddukuri/Cloud teaches the limitations upon which these claims depends. Furthermore, as shown, Maddukuri teaches the following: The verifier system of claim 1, wherein the request and response are transmitted over a secure communication channel established between the verifier system and the user device (Maddukuri, see citations noted supra, including at least [0023], teaching, e.g.: “…In various examples, the verifier computing environment 105 can establish a first communication channel (e.g., WebSocket, gRPC, etc.) with the wallet service 112 upon determining the wallet address or pathway associated with the wallet service 112. In various examples, the verifier computing environment 105 can be identified by the wallet service 112 based at least in part on the verifier public key that is shared in the initial interaction. For example, the verifier computing environment 105 can sign any cryptographic challenges sent to the verifier computing environment 105 for user verification using a verifier private key 136. In this example, the verifier public key 130 can be used to verify the signature of the cryptographic challenge thereby authenticating the verifier computing environment 105…”).
Response to Arguments
Applicant amended claims 1, 3, 4, 11, 13, 15, 16 and canceled claims 2, 5, 12, 14, 17, 19 on 3/30/2026. Applicant's arguments (hereinafter “Remarks”) also filed 3/30/2026, have been fully considered but are moot in view of the new grounds of rejection necessitated by applicant’s amendments. Note the new 35 USC 101, 112(b) and (d), and 103 rejections with Maddukuri in view of Official Notice and Cloud.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J SITTNER whose telephone number is (571)270-3984. The examiner can normally be reached M-F; ~9:30-6:30. 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, Waseem Ashraf can be reached on (571) 270-3948. 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.
/Michael J Sittner/
Primary Examiner, Art Unit 3621
1 [0048]: “… the user device may be configured to transmit the issuer certificate and one or more data elements of the bmdoc to the verification device. The verification device may verify the authenticity of the issuer certificate using a list of known trusted issuer certificates, for example, and then assume the authenticity of the data elements that are sent to the verification device.”
2 https://www.dhs.gov/homeland-security-presidential-directive-12
Prosecution Insights