DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This application has PRO 63/534,256 08/23/2023
This application has PRO 63/460,087 04/18/2023
Status of Claims
Claims 1-30 are canceled.
Claims 31-50 are currently pending and rejected.
Claim Rejection – 35 U.S.C. 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 31-50 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The rationale for this finding is explained below. In the instant case, the claims are directed towards verifying income and employment of a verifyee (i.e., subject of verification request). The concept is clearly related to a longstanding economic practice, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. The claims do not include limitations that are “significantly more” than the abstract idea because the claims do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Note that the limitations, in the instant claims, are done by the generically recited computer device. The limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry. Therefore, claims 31-50 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Step 1: The claims 31-50 are directed to a process, machine, manufacture, or composition matter.
In Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014), the Supreme Court applied a two-step test for determining whether a claim recites patentable subject matter. First, we determine whether the claims at issue are directed to one or more patent-ineligible concepts, i.e., laws of nature, natural phenomenon, and abstract ideas. Id. at 2355 (citing Mayo Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1296–96 (2012)). If so, we then consider whether the elements of each claim, both individually and as an ordered combination, transform the nature of the claim into a patent-eligible application to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself.
Claims 31-40 are directed to a machine (i.e., device/system claims).
Claims 41-50 and are directed to a process (i.e., method claims)
Step 2A: The claims are directed to an abstract idea.
Prong One
The present claims are directed towards verifying income and employment of a verifyee (i.e., subject of verification request). The concept comprises providing a user access for a verification request, receiving and store the verifyee user information comprising a master PIN and a temporary PIN, sending notification to the verifyee upon PIN being set or updated, enabling the verifyee to select one or more types of permissible purposes, receiving a submission for a verification request from a verifier, processing the verification request, generating a verification report, and automatically sending a notification to verifyee that the verification request has been requested. Verifying income and employment information is a fundamental economic activity. Such practice is required for job application, housing rental application, car purchase, etc. Thus, the present claims clearly fall within the Certain Method of Organizing Human Activity grouping. Examiner also points out that the present claims. The performance of the claim limitations using generic computer components (i.e., a server comprising verification application, a controller, operating memory, and a communications interface, data store, data sources, and a notification module) does not preclude the claim limitation from being in the certain methods of organizing human activity grouping or mental processes grouping. Accordingly, the present claims recite an abstract idea.
Prong Two
Independent claims 31 and 41 recite a server (comprising a verification application, a controller, operating memory, a communication interface), a data store, and one or more data sources as additional elements. The additional elements are claimed to perform basic computer functions, such as providing access, receiving a submission for request, processing request, sending notification, receiving and storing information, and allowing one or more types of verifications. Dependent claims 32-40, and 42-50 do not recite any other additional element. The recitation of the computer elements amounts to mere instruction to implement an abstract concept on computers. Moreover, the specification states the subject matter “may be implemented using hardware, software, or a combination thereof and maybe implemented in one or more computer systems or other processing systems” (see page 26 line 17-20). The disclosure suggests hardware elements are not important, and the claimed invention can be implemented with any general-purpose computer. The present claims do not solve a problem specifically arising in the realm of computer networks. The present claims do not recite limitation that improve the functioning of computer, effect a physical transformation, or apply the abstract concept in some other meaningful way beyond generally linking the use of the abstract concept to a particular technological environment. As such, the present claims fail to integrate into a practical application.
Step 2B: The claims do not recite additional elements that amount to significantly more than the abstract idea.
As discussed earlier, independent claims 1, 10, 18, and 26 recite a server (comprising a verification application, a controller, operating memory, a communication interface), a data store, and one or more data sources as additional elements. The additional elements are claimed to perform basic computer functions, such as providing access, receiving a submission for request, processing request, sending notification, receiving and storing information, and allowing one or more types of verifications. Dependent claims 2-9, 11-17, 19-25, and 27-30 do not recite any other additional element. According to MPEP 2106.05(d), “performing repetitive calculations”, “receiving, processing, and storing data”, “electronically scanning or extracting data from a physical document”, “electronic recordkeeping”, “storing and retrieving information in memory”, and “receiving or transmitting data over a network, e.g., using the Internet to gather data” are considered well-understood, routine, and conventional functions of computer. The present claims do not improve the functioning of computer. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Claim Rejection – 35 U.S.C. 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) 31, 33-41, and 43-50 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shahidzadeh et al. (Patent No.: US 10,387,980), in view of Mossoba et al. (Pub. No.: US 2023/0306970) and Crudele et al. (Pub. No.: US 2023/0008975).
As per claim 31 and 41, Shahidzadeh teaches a system for providing an individual with real-time notification of one or more of an employment, income, and unemployment claim and/or benefit verification event, the system comprising:
a. a server accessible via a network, the server comprising a verification
application, a controller, operating memory, and a communications interface (see col 1 and col 2, “communicating with a real time authorization server (e.g., an AIISO such as eGuardianTM) which in pat identifies the registered authorizing party”; see col 21 line 58 through col 22 line 36, “the DMV 101 initiates registration of Bob with the AIISO 120 (e.g., AccepttoTM) via an application program interface (API) provided by the AIISO 120 to create an account for Bob”; see col 14 line 50 through col 15 line 21, “The computing device 200 might also include a communications subsystem 230…the computing device 200 will further comprise a non-transitory working memory 235”);
b. a data store in communication with the server (see col 6 line 63-67, “FIG.3 discloses a Data Owner (or their agent) depositing a Data Commodity (or Data Commodities) or data stores at one of a plurality of ESICs 101 in the JIISN 100 and request to be notified when other interested parties inquire about it (e.g., Requesting Entities)”; see col 12 line 6 through col 13 line 5, “This enable authorization requests to the user identity such as social security, health, state ID, passport, etc. in various government or private identity and credit data stores”; see col 17 line 41-61, “The JIISN 100 described herein further allows for transfer from a data source ESIC 101 to another requiring data store destinations ESIC 101 which is inquiring about the desired Data Commodity 302”), the data store configured to store employer records comprising employee data and user account data (see col 1 – col 6; also see col 8 line 49 through col 9 line 11, “The JIISN 100 members may also broadly include users or companies conducting background checks, employment verifications, payroll related verification services (e.g., payroll, W-2), tax and/or IRS issues, and death and/or birth certificates to open a bank account”; also see col 23 line 7-24, “receiving a request for identity verification and services associated with the transaction, such as a credit report, employment verification…”);
c. one or more data sources accessible to the verification application via the
network (see col 11 line 1-47, “Examples of vouching agencies may include the DMV, IRS, Department of Homeland Security, AccepttoTM, Pacific Gas $ Electric or AT&T” and “here is the verifier trusted authority (e.g., DMV with a AIISO plug-in) then the verifier trusted authors how to connect a consumer through an AISSO (e.g., AccepttoTM ItsMeTM)”, these vouching agencies are data sources as well; also see col 21 line 58 through col 22 line 36);
d. a notification module configured to automatically generate and send notifications to users of the system (col 10 line 3-67, “The AIISO 120 will then contact an Authorizing Entity 130 which has the ability to authorize release of the personal data”; col 13 line 46 through col 14 line 5, “an authorization request is sent to the Authorizing Entity 130 mobile device 130c. In step 158, the Authorizing Entity through the mobile device 130c either accepts or declines the release of the data”; also see col 21 line 58 through col 22 line 36, “a Requesting Entity (e.g., Bank of America) 110 initiating a query about a person of interest (e.g., ‘Bob’)…The DMV 101 in step 706 verifies that it has a record for Bob in its active directory and sends via the AIISO application program interface (API) a request to the person of interest Bob indicating that a Requesting Entity 110, Bank of America, is requested for Bob’s information and needs proof of entity and approval for transaction”; in this case, Bob is the verifyee); and
e. wherein the controller is configured to execute stored program instructions to (see col 15 line 22-57, “one or more procedures described with the respect to the method(s) discussed above might be implemented as code and/or instructions executable by a computer” and “A set of these instructions and/or code might be stored on a computer-readable storage medium…These instructions might take the form of executable code, which sis executable by computing device 200”):
i. provide access to a verifyee user of the system, wherein the verifyee user is one of a currently employed individual and an unemployed individual (see col 1 line 39 through col 2 line 36; also see col 9 line 12 through col 10 line 2, prior art teaches login methods which allow user to access the verification system; also see col 20 line 13-57, “In step 508, the Authorizing Entity 130 logs into the AIISO 120 authorization server by username (e.g., email address) and a random one time ephemeral key A (e.g., a big prime number)”);
ii. receive and store verifyee user information comprising a master personal identification number (see col 9 line 12 through col 10 line 2, “Multi-factor Authentication refer to where the release of data by Data Owner and/or Authorizing Entity to a Requesting Entity is to present two or more independent pieces of information…something only the Data Owner (or agent) knowns (e.g., password, PIN, pattern)…”, the PIN here is interpreted master personal identification number);
iii. upon the temporary personal identification number being set or updated automatically send via the notification module a notification to the verifyee user that a temporary personal identification number event has occurred (see col 1 line 39-60, “configuring a specific user selected policy for notification…computing the required action based on the configuration of the policies”; see col 6 line 63-67, “FIG.3 discloses a Data Owner (or their agent) depositing a Data Commodity (or Data Commodities) or data stores at one of a plurality of ESICs 101 in the JIISN 100 and request to be notified when other interested parties inquire about it (e.g., Requesting Entities)”; see col 20 line 12-57, “configures a specific policy for notification and authorization of identity requests”; further see col 23 line 25-49, “the ability of a user to lock and/or suspend, require real time authorization or notification for use of one’s identity”; prior art teaches user could configure notification policy, and as such one skilled in the art could use the prior art’s configurable notification to notify any account event, including setting/updating a temporary PIN);
iv. enable the verifyee user to select one or more types of permissible purposes allowable for a verification request (see col 23 line 7-24, “receiving a request for identity verification and services associated with the transaction, such as a credit report, employment verification…”; see col 10 line 22-31, “The AIISO 120 will then contact an Authorizing Entity 130 which has the ability to authorize release of the personal data”);
v. receive a submission for a verification request from a verifier (see col 1 line 39 through col 2 line 36, “receiving at an identity organization a request for registration and verification of the identity information”; also see col 5 line 48 through col 6 line 22, “receiving a request for identity verification and services associated with the transaction”), the submission comprising a permissible purpose for the verification request and identifying information related to the verifyee user (see col 23 line 7-24, “receiving a request for identity verification and services associated with the transaction, such as a credit report, employment verification…”; see col 10 line 22-31, “The AIISO 120 will then contact an Authorizing Entity 130 which has the ability to authorize release of the personal data”);
vi. process the verification request (see col 1 through col 6, “processing the request in a Joint Identity and information Service Network (JIISN) server framework for the detection and verification of a request against an active directory of user”); and
viii. automatically send via the notification module a notification to the verifyee user that the verification request has been requested (col 10 line 3-67, “The AIISO 120 will then contact an Authorizing Entity 130 which has the ability to authorize release of the personal data”; col 13 line 46 through col 14 line 5, “an authorization request is sent to the Authorizing Entity 130 mobile device 130c. In step 158, the Authorizing Entity through the mobile device 130c either accepts or declines the release of the data”; also see col 21 line 58 through col 22 line 36, “a Requesting Entity (e.g., Bank of America) 110 initiating a query about a person of interest (e.g., ‘Bob’)…The DMV 101 in step 706 verifies that it has a record for Bob in its active directory and sends via the AIISO application program interface (API) a request to the person of interest Bob indicating that a Requesting Entity 110, Bank of America, is requested for Bob’s information and needs proof of entity and approval for transaction”; in this case, Bob is the verifyee).
Examiner notes Shahidzadeh does not teach receive and store a temporary personal identification number, wherein the temporary personal identification number is set by the verifyee user and has a defined expiration date set by the verifyee user; including the temporary personal identification number provided by the verifyee user to the verifier; and using the temporary personal identification number and the identifying information related to the verifyee user.
Mossoba teaches receive and store a temporary personal identification number, wherein the temporary personal identification number is set by the verifyee user and has a defined expiration date set by the verifyee user (see paragraph 0055, “the identifier may indicate a PIN or other numerical representation associated with the user. For example, the user may request a new PIN to use. Alternatively, the user may request a temporary PIN to provide to another person to use”; also see paragraph 0063-0064, “the generated identifier may expired based on a time window associated with the generate identifier and/or based on a quantity of uses of the generated identifier”); and
including the temporary personal identification number provided by the verifyee user to the verifier; using the temporary personal identification number and the identifying information related to the verifyee user (see paragraph 0055, “the identifier may indicate a PIN or other numerical representation associated with the user. For example, the user may request a new PIN to use. Alternatively, the user may request a temporary PIN to provide to another person to use”; see paragraph 0063-0064, “the generated identifier may expired based on a time window associated with the generate identifier and/or based on a quantity of uses of the generated identifier”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Shahidzadeh with teaching from Mossoba to include receive and store a temporary personal identification number, wherein the temporary personal identification number is set by the verifyee user and has a defined expiration date set by the verifyee user; including the temporary personal identification number provided by the verifyee user to the verifier; and using the temporary personal identification number and the identifying information related to the verifyee user. The modification would have been obvious, because it is merely applying a known technique (i.e., using a temporary PIN to identify a user) to a known system (i.e., information verification system) ready to provide predictable result (i.e., enhance security using known technique).
The combination of Shahidzadeh and Mossoba does not explicitly teach vii. automatically generate a verification report about the verifyee user, the verification report comprising information related to one or more of employment, income, and unemployment claims and/or benefits of the verifyee user.
Crudele teaches automatically generate a verification report about the verifyee user, the verification report comprising information related to one or more of employment, income, and unemployment claims and/or benefits of the verifyee user (see paragraph 0108, “the host platform can generate a PDF or other document that includes an identity and/or income verification report, and sends the report via a webhook/response architecture”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the combination of Shahidzadeh and Mossoba with teaching from Crudele to include automatically generate a verification report about the verifyee user, the verification report comprising information related to one or more of employment, income, and unemployment claims and/or benefits of the verifyee user. The modification would have been obvious, because it is merely applying a known technique (i.e., automatically generating a verification report) to a known system (i.e., information verification system) ready to provide predictable result (i.e., replace manual labor).
As per claim 33 and 43, Shahidzadeh teaches wherein the master personal identification number facilitates a login process for the verifyee user to access the verification application (see col 9 line 16-29, “Multi-factor Authentication refer to where the release of data by a Data Owner and/or Authorizing Entity to a Requesting Entity is to present two or more independent pieces of information (something beyond the username and password in the context of login) as means of authentication such as the following: something only the Data Owner (or agent) knows (e.g., password, PIN, pattern)…”; prior art teaches inputting identifying information, such as PIN, to use the verification service).
As per claim 34 and 44, Shahidzadeh does not explicitly teach wherein the data store is configured to further store the generated verification report.
Crudele teaches the data store is configured to further store the generated verification report (see paragraph 0108, “the host platform can generate a PDF or other document that includes an identity and/or income verification report, and sends the report via a webhook/response architecture”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Shahidzadeh with teaching from Crudele to include the data store is configured to further store the generated verification report. The modification would have been obvious, because it is merely applying a known technique (i.e., automatically generating a verification report) to a known system (i.e., information verification system) ready to provide predictable result (i.e., allow reports to be retrieved at a later time).
As per claim 35 and 45, Shahidzadeh does not teach wherein the defined expiration date of the temporary personal identification number specifies a date after which the verifier is not allowed to perform a verification event using the temporary personal identification number.
Mossoba teaches the defined expiration date of the temporary personal identification number specifies a date after which the verifier is not allowed to perform a verification event using the temporary personal identification number (see paragraph 0055, “the identifier may indicate a PIN or other numerical representation associated with the user. For example, the user may request a new PIN to use. Alternatively, the user may request a temporary PIN to provide to another person to use”; see paragraph 0063-0064, “the generated identifier may expired based on a time window associated with the generate identifier and/or based on a quantity of uses of the generated identifier”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Shahidzadeh with teaching from Mossoba to include the defined expiration date of the temporary personal identification number specifies a date after which the verifier is not allowed to perform a verification event using the temporary personal identification number. The modification would have been obvious, because it is merely applying a known technique (i.e., providing a temporary PIN with defined expiration as identifier) to a known system (i.e., information verification system) ready to provide predictable result (i.e., enhance security using known technique).
As per claim 36 and 46, Shahidzadeh teaches wherein notifications sent via the notification module comprise one or more of a text message, email, and a pop-up notification delivered via a mobile application or a desktop application (see col 22 line 37 through col 23 line 7, “in step 812 a verification is made with taxpayer via push notification, text message, email…”).
As per claim 37 and 47, Shahidzadeh teaches wherein the verification event comprises a request submitted by the verifier for verification of one or more of an employment, income, and unemployment claim and/or benefit of the verifyee (see col 8 line 49 through col 9 line 11, “The JIISN 100 members may also broadly include users or companies conducting background checks, employment verifications, payroll related verification services (e.g., payroll, W-2), tax and/or IRS issues, and death and/or birth certificates to open a bank account”; also see col 23 line 7-24, “receiving a request for identity verification and services associated with the transaction, such as a credit report, employment verification…”).
As per claim 38 and 48, Shahidzadeh teaches wherein the permitted purpose comprises any one or more of credit grantor, collection agency, insurance, mortgage, employer, rental housing, court order, government agency, open bank account, and unemployment insurance (see col 8 line 49 through col 9 line 11, “The JIISN 100 members may also broadly include users or companies conducting background checks, employment verifications, payroll related verification services (e.g., payroll, W-2), tax and/or IRS issues, and death and/or birth certificates to open a bank account”; also see col 23 line 7-24, “receiving a request for identity verification and services associated with the transaction, such as a credit report, employment verification…”).
As per claim 39 and 49, Shahidzadeh teaches wherein the verification request comprises a verification of unemployment claims and/or benefits (see col 8 line 49 through col 9 line 11, “The JIISN 100 members may also broadly include users or companies conducting background checks, employment verifications, payroll related verification services (e.g., payroll, W-2), tax and/or IRS issues, and death and/or birth certificates to open a bank account”; also see col 23 line 7-24, “receiving a request for identity verification and services associated with the transaction, such as a credit report, employment verification…”), and
wherein the controller is further configured to execute stored program instructions to automatically send a notification via the notification module to the verifyee inquiring whether the verifyee has submitted an unemployment claim and/or received benefits, and wherein the verifyee's response to the inquire is received by the verifier (col 10 line 3-67, “The AIISO 120 will then contact an Authorizing Entity 130 which has the ability to authorize release of the personal data”; col 13 line 46 through col 14 line 5, “an authorization request is sent to the Authorizing Entity 130 mobile device 130c. In step 158, the Authorizing Entity through the mobile device 130c either accepts or declines the release of the data”; also see col 21 line 58 through col 22 line 36, “a Requesting Entity (e.g., Bank of America) 110 initiating a query about a person of interest (e.g., ‘Bob’)…The DMV 101 in step 706 verifies that it has a record for Bob in its active directory and sends via the AIISO application program interface (API) a request to the person of interest Bob indicating that a Requesting Entity 110, Bank of America, is requested for Bob’s information and needs proof of entity and approval for transaction”; in this case, Bob is the verifyee).
As per claim 40 and 41, Shahidzadeh teaches wherein the server further comprises an authentication module configured to manage an authentication process for users of the system and a security module configured to perform security functions with respect to data stored in the data store (see col 12 line 6 through col 13 line 5, “enable verification of specific security protocols meeting the level of assurance required to automatically authorized (based on certain predetermined policies and contextual intelligence and trust relationships between the source and the destination) and real time notification and or approval of the data owner”; also see col 21 line 6-16).
Claim(s) 32 and 42 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shahidzadeh et al. (Patent No.: US 10,387,980), in view of Mossoba et al. (Pub. No.: US 2023/0306970) and Crudele et al. (Pub. No.: US 2023/0008975), and further in view of Armstrong et al. (Pub. No.: US 2019/0259013).
As per claim 32 and 42, Shahidzadeh does not teach wherein the master personal identification number is assigned by a past or present employer of the verifyee use.
Armstrong teaches wherein the master personal identification number is assigned by a past or present employer of the verifyee use (see paragraph 0041, “The employer may want to also collect baseline biometric data at this time, along with assignment of passwords and one or more personal identification numbers”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Shahidzadeh with teaching from Armstrong to include wherein the master personal identification number is assigned by a past or present employer of the verifyee use. The modification would have been obvious, because it is merely applying a known technique (i.e., employer assigning PIN) to a known system (i.e., information verification system) ready to provide predictable result (i.e., give employer some control over account creation process).
Response to Remarks
Rejection under 35 U.S.C. 101
Applicant canceled all the prior claims and submitted new claims 31-50. Applicant argued that the new claims are not directed to an abstract concept without providing any rationale. Examiner disagrees and points out that the new claims are still directed to an abstract concept of “verifying income and employment of a verifyee”.
Applicant argued that the new claims “provide a specific technological improvements in how employment/income verification systems operate”, and “in at least one aspect, improve computer functionality and security by automating real-time detection of verification events, triggering instantaneous notifications to employee (verifyees), providing secure, employee-centered authorization pathways, integrating unemployment claims/benefits fraud-reporting pathway directly into the system, enabling a technical safeguard against identity and/or unemployment claims/benefits misuse”. Examiner disagrees and points out that the present claims merely utilize existing notification system similar to those used in banking industry to transfer messages to user. The cited prior arts disclose similar notification system. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Examiner maintains the ground of rejection under 35 U.S.C 101.
Rejection under 35 U.S.C .102/103
Applicant canceled all the prior claims and submitted new claims 31-50. Examiner cites Shahidzadeh et al. (Patent No.: US 10,387,980), Mossoba et al. (Pub. No.: US 2023/0306970), Crudele et al. (Pub. No.: US 2023/0008975), and Armstrong et al. (Pub. No.: US 2019/0259013) to address the new claims.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO FU whose telephone number is (571)270-3441. The examiner can normally be reached 9:00 AM - 6:00 PM PST.
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, Christine M Behncke can be reached at (571) 272-8103. 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.
/HAO FU/Primary Examiner, Art Unit 3695
APR-2026
Prosecution Insights