DETAILED ACTION
Notice of 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 .
Status of Claims
This action is in reply to the first amendment to non-final filed on January 22, 2026.
Claims 1–4, 6, 4, 6, and 8–20 have been amended and are hereby entered.
Claims 1–20 are currently pending and have been examined.
This action is made FINAL.
Response to Amendment
The amendment filed January 22, 2026 has been entered. Claims 1–20 remain pending in the application.
Claim Rejections - 35 USC § 101
The following is a quotation of 35 U.S.C. 101:
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–20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
First of all, claims must be directed to one or more of the following statutory categories: a process, a machine, a manufacture, or a composition of matter. Claims 1–7 are directed to a process (“A computer-implemented method”), and claims 8–20 are directed to a machine (“One or more computer-readable non-transitory storage media” and “A system”). Thus, claims 1–20 satisfy Step One because they are all within one of the four statutory categories of eligible subject matter.
Claims 1–20, however, are directed to an abstract idea without significantly more. For claim 1, the specific limitations that recite an abstract idea are:
receiving, by . . . a user, . . . user data from a user account of the user associated with a second service provider. . .;
receiving, . . . a credential associated with a user account of a user associated with the second service provider;
sending . . . the credential to . . . the second service provider, wherein based at least in part on the sending of the credential . . .;
sending, . . . a request for the user data;
receiving, . . . the user data from . . . the second service provider; and
sending, . . . without having provided the credential to . . . the first service provider, at least a portion of the user data to . . . the first service provider.
The claims, therefore, recite a secure data transfer interaction, which is the abstract idea of certain methods of organizing human activity because they recite a commercial interaction and the fundamental economic practice of mitigating risk.
The judicial exception recited above is not integrated into a practical application. The additional elements of the claims are various generic technologies and computer components to implement this abstract idea (“mobile payment application”, “user device”, “computing device”, “encryption protocol”, “login page”, “user interface”, “secure communication session”, “encryption”, “application programming interfaces”, “scraping component”, “computer-readable non-transitory storage media”, “processors”, and “memory”). The claims also recite “wherein the instructions include a type of encryption protocol to use to acquire the user data”, “causing presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider”, “a secure communication session using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider”, and “automatically closing the login page of the second service provider in the user interface of the mobile payment application”. These additional elements are not integrated into a practical application because the invention merely applies the abstract idea to generic computer technology, using the computer to request data, authenticate a user, and then transfer data. The claims do recite more specific technology—user interface login pages for establishing secure sessions—but again, these are still being used as generic tools to send and receive data. Because the invention is using the computer simply as a tool to perform the abstract idea on, the judicial exception is not integrated into a practical application.
Finally, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, the additional elements in combination are at a high level of generality such that they amount to no more than mere instructions to apply the abstract idea using generic components. Because merely “applying” the exception using generic computer components cannot provide an inventive concept, the additional elements do not recite significantly more than the judicial exception. Thus, claim 1 is not patent eligible.
Independent claims 8 and 15 are rejected as ineligible subject matter under 35 U.S.C. 101 for substantially the same reasons as independent method claim 1. There are no additional elements recited in these claims other than the generic technology and computer parts discussed above (“computer-readable non-transitory storage media”, “mobile payment application”, “user device”, “computing device”, “encryption protocol”, “login page”, “user interface”, “secure communication session”, “processors”, and “memory”). The only differences are that the steps of claim 1 are implemented by computer program instructions in claim 8 and performed by a system in claim 15. Thus, because the same analysis should be used for all categories of claims, claims 8 and 15 are also not patent eligible. See Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 134 S. Ct. 2347, 2354 (2014).
Dependent claims 2–7, 9–14, and 16–20 have been given the full two part analysis, analyzing the additional limitations both individually and in combination. The dependent claims, when analyzed individually and in combination, are also held to be patent ineligible under 35 U.S.C. 101.
For claims 2, 9, and 16, the additional recited limitations of these claims merely further narrow the abstract idea discussed above. These dependent claims only narrow the data interaction recited in claims 1, 8, and 15 by further specifying the credential—“a password, a security key, log-in data, a passcode, or a single sign-on”.
For claims 3, 10, and 17, the additional recited limitations of these claims merely further narrow the abstract idea discussed above. These dependent claims only narrow the data interaction recited in claims 1, 8, and 15 by further specifying the request—“converting the second request”, “sending . . . based on context”, and “instruction to input the credential”. The limitations of these claims fail to integrate the abstract idea into a practical application because these claims do not introduce additional elements other than the generic components discussed above (“computing device” and “mobile payment application”). These dependent claims, therefore, also amount to merely using a computer, in its ordinary capacity, as a tool to perform the abstract idea. Finally, the additional recited limitations of these dependent claims fail to establish that the claims provide an inventive concept because claims that merely use a computer, in its ordinary capacity, as a tool to perform the abstract idea cannot provide an inventive concept.
For claims 4 and 11, the additional recited limitations of these claims merely further narrow the abstract idea discussed above. These dependent claims only narrow the data interaction recited in claims 1 and 8 by further specifying the authentication process—“receiving . . . authentication details” and “wherein sending the credential . . . comprises at least one of: sending a particular credential specified in the authentication details; sending the credential in a particular format specified in the authentication details; sending the credential using a particular type of encryption specified in the authentication details; sending, along with the credential, additional data specified in the authentication details; sending the credential using a particular protocol specified in the authentication details; or sending the credential with an indication of a particular type of authentication to implement specified in the authentication details”. The limitations of these claims fail to integrate the abstract idea into a practical application because these claims do not introduce additional elements other than the generic components discussed above (“computing device” and “mobile payment application”). These claims do recite encryption, but again, this is also merely being used as a tool to communicate the credentials more securely. These dependent claims, therefore, also amount to merely using a computer, in its ordinary capacity, as a tool to perform the abstract idea. Finally, the additional recited limitations of these dependent claims fail to establish that the claims provide an inventive concept because claims that merely use a computer, in its ordinary capacity, as a tool to perform the abstract idea cannot provide an inventive concept.
For claims 5 and 12, the additional recited limitations of these claims merely further narrow the abstract idea discussed above. These dependent claims only narrow the data interaction recited in claims 1 and 8 by further specifying how the data is accessed—“application programming interfaces” and “a scraping component”. The limitations of these claims fail to integrate the abstract idea into a practical application because these claims do not introduce additional elements other than the generic components discussed above. These claims do recite an application programming interface and a scraping component, but again, these are also merely being used as tools to access the data. These dependent claims, therefore, also amount to merely using a computer, in its ordinary capacity, as a tool to perform the abstract idea. Finally, the additional recited limitations of these dependent claims fail to establish that the claims provide an inventive concept because claims that merely use a computer, in its ordinary capacity, as a tool to perform the abstract idea cannot provide an inventive concept.
For claims 6 and 18, the additional recited limitations of these claims merely further narrow the abstract idea discussed above. These dependent claims only narrow the data interaction recited in claims 1 and 15 by further specifying the time period of the interaction—“a period of time or until an occurrence of an event”. The limitations of these claims fail to integrate the abstract idea into a practical application because these claims do not introduce additional elements other than the generic components discussed above (“computing device”). These dependent claims, therefore, also amount to merely using a computer, in its ordinary capacity, as a tool to perform the abstract idea. Finally, the additional recited limitations of these dependent claims fail to establish that the claims provide an inventive concept because claims that merely use a computer, in its ordinary capacity, as a tool to perform the abstract idea cannot provide an inventive concept.
For claims 7, 13, and 19, the additional recited limitations of these claims merely further narrow the abstract idea discussed above. These dependent claims only narrow the data interaction recited in claims 1, 8, and 15 by further specifying how the portion of data is determined—“designation by the user” and “request, from . . . the service provider”. The limitations of these claims fail to integrate the abstract idea into a practical application because these claims do not introduce additional elements other than the generic components discussed above (“computing device”). These dependent claims, therefore, also amount to merely using a computer, in its ordinary capacity, as a tool to perform the abstract idea. Finally, the additional recited limitations of these dependent claims fail to establish that the claims provide an inventive concept because claims that merely use a computer, in its ordinary capacity, as a tool to perform the abstract idea cannot provide an inventive concept.
For claims 14 and 20, the additional recited limitations of these claims merely further narrow the abstract idea discussed above. These dependent claims only narrow the data interaction recited in claims 8 and 15 by further specifying the second service provider and the data type—“payroll service provider” and “payroll data”.
Claim Rejections - 35 USC § 103
In the event that the determination of the status of the application as subject to 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.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 nonobviousness.
Claims 1, 2, 4–9, 11–13, 15, 16, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Shablygin et al., U.S. Patent App. No. 2013/0042110 (“Shablygin”) in view of Fakhraie et al., U.S. Patent No. 10,963,589 (“Fakhraie”); Gupta, U.S. Patent App. No. 2018/0255030 (“Gupta”); and Hockey et al., U.S. Patent App. No. 2021/0081947 (“Hockey”).
For claim 1, Shablygin teaches:
A computer-implemented method comprising (¶ 97: example method): . . .
sending, by the mobile payment application, the credential to at least one computing device of the second service provider, (¶ 73–74, 161: authentication transaction begins between user, service provider, and third-party; ¶ 31: third-party is authentication system separate from user and service provider; ¶ 168: invention may be software application for payments) . . .;
receiving, by the mobile payment application and via the secure communication session, the user data from the at least one computing device of the second service provider (¶ 160–161, 73–74: user data stored in container of third-party system is received) . . ..
Shablygin does not teach: receiving, by a mobile payment application associated with a first service provider and operating on a user device of a user, instructions from at least one computing device of the first service provider to acquire user data from a user account of the user associated with a second service provider, wherein the instructions include a type of encryption protocol to use to acquire the user data; based at least in part on receiving the instructions, causing presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider; receiving, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider; wherein based at least in part on the sending of the credential, a secure communication session, using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider; automatically closing the login page of the second service provider in the user interface of the mobile payment application; sending, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data; and sending, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider.
Fakhraie, however, teaches:
receiving, by a mobile payment application associated with a first service provider and operating on a user device of a user (col. 24, lines 28–49: third party client application on customer mobile device; col. 34, lines 34–60: third party client application is payment application), instructions from at least one computing device of the first service provider to acquire user data from a user account of the user associated with a second service provider (col. 24, lines 28–49: information request via third party client application API to financial institution computing system; col. 22, lines 11–48: customer information includes account information for account associated with financial institution).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin by adding the third party application from Fakhraie. One of ordinary skill in the art would have been motivated to make this modification for the purpose of facilitating and securing the sharing of financial information—a benefit explicitly disclosed by Fakhraie (col. 1, line 48–col. 2, line 6: providing access to information can be cumbersome and risks exposure; col. 2, lines 10–44: invention provides user interface through user device application for requesting and authorizing additional information) and desired by Shablygin (¶ 6–7: problems associated with loss of private data).
The combination of Shablygin and Fakhraie does not teach: wherein the instructions include a type of encryption protocol to use to acquire the user data; based at least in part on receiving the instructions, causing presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider; receiving, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider; wherein based at least in part on the sending of the credential, a secure communication session, using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider; automatically closing the login page of the second service provider in the user interface of the mobile payment application; sending, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data; and sending, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider.
Gupta, however, teaches:
wherein the instructions include a type of encryption protocol to use to acquire the user data (¶ 31–32: token used for encryption of connection with service provider); and
wherein based at least in part on the sending of the credential, a secure communication session, using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider (¶ 36, 38, 42: secure session for data exchange created based on receiving token at login page).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin and the third party application in Fakhraie by adding the encrypted session from Gupta. One of ordinary skill in the art would have been motivated to make this modification for the purpose of facilitating the sharing of information without sharing secure information—a benefit explicitly disclosed by Gupta (¶ 5–6: need for better securing information used for accessing and sharing data; ¶ 22–25: invention provides token and OAuth session for securing data) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, and Gupta are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
The combination of Shablygin, Fakhraie, and Gupta does not teach: based at least in part on receiving the instructions, causing presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider; receiving, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider; automatically closing the login page of the second service provider in the user interface of the mobile payment application; sending, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data; and sending, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider.
Hockey, however, teaches:
based at least in part on receiving the instructions, causing presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider (Figs. 29A–29B, ¶ 383–384: user interface of first system displays account credential page for selected external institution; ¶ 185: external user account system APIs accessed by first-party mobile device applications);
receiving, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider (¶ 384: user enters account credentials);
automatically closing the login page of the second service provider in the user interface of the mobile payment application (Fig. 29H, ¶ 388: user interface closed);
sending, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data (¶ 172: third-party system requests account data without disclosing credentials); and
sending, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider (¶ 289: access to account and user information obtained, but account credentials not provided to user-facing application or management system).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin, the third party application in Fakhraie, and the encrypted session in Gupta by adding the external login from Hockey. One of ordinary skill in the art would have been motivated to make this modification for the purpose of linking accounts using credential-less authentication—a benefit explicitly disclosed by Hockey (¶ 2–6: authentication for new systems can provide barrier that deters use, so there is need for linking accounts through credential-less authentication; ¶ 34–35: invention provides credential-less authentication for enhancing and improving user experience). Shablygin, Fakhraie, Gupta, and Hockey are all related in part to authentication, so one of ordinary skill in the art would have been motivated to make this authentication even more convenient by combining these references together.
For claim 2, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 1 above, and Shablygin further teaches:
The computer-implemented method of claim 1, wherein the credential comprises a password, a security key, log-in data, a passcode, or a single sign-on usable by the user to access services associated with at least the second service provider (¶ 42: ID Tokens and User ID for accessing third-party authentication system).
For claim 4, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 1 above, and Shablygin further teaches:
The computer-implemented method of claim 1, further comprising: sending, by the mobile payment application to the at least one computing device of the first service provider, a request for authenticating with the second service provider (¶ 86, 115: request from service provider; ¶ 168: software application for payments); and
receiving, by the mobile payment application, authentication details from the at least one computing device of the first service provider, the authentication details having been communicated by the first service provider to the second service provider (¶ 73: service provider provides ID to third-party identification system);
wherein sending the credential to the at least one computing device of the second service provider comprises at least one of: sending a particular credential specified in the authentication details; sending the credential in a particular format specified in the authentication details; sending the credential using a particular type of encryption specified in the authentication details; sending, along with the credential, additional data specified in the authentication details; sending the credential using a particular protocol specified in the authentication details; or sending the credential with an indication of a particular type of authentication to implement specified in the authentication details (¶ 82, 85: service provider ID and User ID sent together and encrypted).
For claim 5, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 1 above, and Fakhraie further teaches:
The computer-implemented method of claim 1, wherein the user data is accessible via the secure communication session using at least one of: one or more application programming interfaces; or a scraping component (col. 24, lines 28–49: third party client application API).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin, the encrypted session in Gupta, and the external login in Hockey by adding the API from Fakhraie. One of ordinary skill in the art would have been motivated to make this modification for the purpose of facilitating and securing the sharing of financial information—a benefit explicitly disclosed by Fakhraie (col. 1, line 48–col. 2, line 6: providing access to information can be cumbersome and risks exposure; col. 2, lines 10–44: invention provides user interface through user device application for requesting and authorizing additional information) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, Gupta, and Hockey are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
For claim 6, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 1 above, and Shablygin further teaches:
The computer-implemented method of claim 1, further comprising maintaining the secure communication session for at least one of a period of time or until an occurrence of an event, wherein while the secure communication session is maintained, updated user data is received from the at least one computing device of the second service provider (¶ 80: authentication transaction assigned a maximum time period).
For claim 7, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 1 above, and Shablygin further teaches:
The computer-implemented method of claim 1, wherein the portion of the user data is determined based at least in part on a designation by the user (¶ 86, 71: user specifies data container based on request).
For claim 8, Shablygin teaches:
One or more computer-readable non-transitory storage media embodying software comprising instructions operable when executed to (¶ 24, 58: storage media and memory storing operating instructions): . . .
send, by the mobile payment application, the credential to at least one computing device of the second service provider (¶ 73–74, 161: authentication transaction begins between user, service provider, and third-party; ¶ 31: third-party is authentication system separate from user and service provider; ¶ 168: invention may be software application for payments) . . .;
receive, by the mobile payment application and via the secure communication session, the user data from the at least one computing device of the second service provider (¶ 160–161, 73–74: user data stored in container of third-party system is received) . . ..
Shablygin does not teach: receive, by a mobile payment application associated with a first service provider and operating on a user device of a user, instructions from at least one computing device of the first service provider to acquire user data from a user account of the user associated with a second service provider, wherein the instructions include a type of encryption protocol to use to acquire the user data; based at least in part on receiving the instructions, cause presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider; receive, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider; wherein based at least in part on the sent credential, a secure communication session using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider; automatically close the login page of the second service provider in the user interface of the mobile payment application; send, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data; and send, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider.
Fakhraie, however, teaches:
receive, by a mobile payment application associated with a first service provider and operating on a user device of a user (col. 24, lines 28–49: third party client application on customer mobile device; col. 34, lines 34–60: third party client application is payment application), instructions from at least one computing device of the first service provider to acquire user data from a user account of the user associated with a second service provider (col. 24, lines 28–49: information request via third party client application API to financial institution computing system; col. 22, lines 11–48: customer information includes account information for account associated with financial institution).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin by adding the third party application from Fakhraie. One of ordinary skill in the art would have been motivated to make this modification for the purpose of facilitating and securing the sharing of financial information—a benefit explicitly disclosed by Fakhraie (col. 1, line 48–col. 2, line 6: providing access to information can be cumbersome and risks exposure; col. 2, lines 10–44: invention provides user interface through user device application for requesting and authorizing additional information) and desired by Shablygin (¶ 6–7: problems associated with loss of private data).
The combination of Shablygin and Fakhraie does not teach: wherein the instructions include a type of encryption protocol to use to acquire the user data; based at least in part on receiving the instructions, cause presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider; receive, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider; wherein based at least in part on the sent credential, a secure communication session using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider; automatically close the login page of the second service provider in the user interface of the mobile payment application; send, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data; and send, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider.
Gupta, however, teaches:
wherein the instructions include a type of encryption protocol to use to acquire the user data (¶ 31–32: token used for encryption of connection with service provider); and
wherein based at least in part on the sent credential, a secure communication session using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider (¶ 36, 38, 42: secure session for data exchange created based on receiving token at login page).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin and the third party application in Fakhraie by adding the encrypted session from Gupta. One of ordinary skill in the art would have been motivated to make this modification for the purpose of facilitating the sharing of information without sharing secure information—a benefit explicitly disclosed by Gupta (¶ 5–6: need for better securing information used for accessing and sharing data; ¶ 22–25: invention provides token and OAuth session for securing data) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, and Gupta are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
The combination of Shablygin, Fakhraie, and Gupta does not teach: based at least in part on receiving the instructions, cause presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider; receive, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider; automatically close the login page of the second service provider in the user interface of the mobile payment application; send, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data; and send, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider.
Hockey, however, teaches:
based at least in part on receiving the instructions, cause presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider (Figs. 29A–29B, ¶ 383–384: user interface of first system displays account credential page for selected external institution; ¶ 185: external user account system APIs accessed by first-party mobile device applications);
receive, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider (¶ 384: user enters account credentials);
automatically close the login page of the second service provider in the user interface of the mobile payment application (Fig. 29H, ¶ 388: user interface closed);
send, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data (¶ 172: third-party system requests account data without disclosing credentials); and
send, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider (¶ 289: access to account and user information obtained, but account credentials not provided to user-facing application or management system).
For claim 9, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 8 above, and Shablygin further teaches:
The one or more computer-readable non-transitory storage media of claim 8, wherein the credential comprises a password, a security key, log-in data, a passcode, or a single sign-on usable by the user to access services associated with at least the second service provider (¶ 42: ID Tokens and User ID for accessing third-party authentication system).
For claim 11, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 8 above, and Shablygin further teaches:
The one or more computer-readable non-transitory storage media of claim 8, wherein the software is further operable when executed to: send, by the mobile payment application to the at least one computing device of the first service provider, a request for authenticating with the second service provider (¶ 86, 115: request from service provider; ¶ 168: software application for payments); and
receive, by the mobile payment application, authentication details from the at least one computing device of the first service provider, the authentication details having been communicated by the first service provider to the second service provider (¶ 73: service provider provides ID to third-party identification system);
wherein sending the credential to the at least one computing device of the second service provider comprises at least one of: sending a particular credential specified in the authentication details; sending the credential in a particular format specified in the authentication details; sending the credential using a particular type of encryption specified in the authentication details; sending, along with the credential, additional data specified in the authentication details; sending the credential using a particular protocol specified in the authentication details; or sending the credential with an indication of a particular type of authentication to implement specified in the authentication details (¶ 82, 85: service provider ID and User ID sent together and encrypted).
For claim 12, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 8 above, and Fakhraie further teaches:
The one or more computer-readable non-transitory storage media of claim 8, wherein the user data is accessible via the secure communication session using at least one of: one or more application programming interfaces; or a scraping component (col. 24, lines 28–49: third party client application API).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin, the encrypted session in Gupta, and the external login in Hockey by adding the API from Fakhraie. One of ordinary skill in the art would have been motivated to make this modification for the purpose of facilitating and securing the sharing of financial information—a benefit explicitly disclosed by Fakhraie (col. 1, line 48–col. 2, line 6: providing access to information can be cumbersome and risks exposure; col. 2, lines 10–44: invention provides user interface through user device application for requesting and authorizing additional information) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, Gupta, and Hockey are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
For claim 13, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 8 above, and Shablygin further teaches:
The one or more computer-readable non-transitory storage media of claim 8, wherein the portion of the user data is determined based at least in part on the request, from the at least one computing device of the first service provider, for particular user data (¶ 86, 71: data container specified based on service provider request).
For claim 15, Shablygin teaches:
A system comprising one or more processors and a memory coupled to the one or more processors comprising instructions executable by the one or more processors, the processors being operable when executing the instructions to (¶ 58: example system with processor and memory storing operating instructions): . . .
send, by the mobile payment application, the credential to at least one computing device of the second service provider, (¶ 73–74, 161: authentication transaction begins between user, service provider, and third-party; ¶ 31: third-party is authentication system separate from user and service provider; ¶ 168: invention may be software application for payments) . . .; and
receive, by the mobile payment application and via the secure communication session, the user data from the at least one computing device of the second service provider (¶ 160–161, 73–74: user data stored in container of third-party system is received) . . ..
Shablygin does not teach: receive, by a mobile payment application associated with a first service provider and operating on a user device of a user, instructions from at least one computing device of the first service provider to acquire user data from a user account of the user associated with a second service provider, wherein the instructions include a type of encryption protocol to use to acquire the user data; based at least in part on receiving the instructions, cause presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider; receive, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider; wherein based at least in part on the sent credential, a secure communication session using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider; automatically close the login page of the second service provider in the user interface of the mobile payment application; send, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data; and send, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider.
Fakhraie, however, teaches:
receive, by a mobile payment application associated with a first service provider and operating on a user device of a user (col. 24, lines 28–49: third party client application on customer mobile device; col. 34, lines 34–60: third party client application is payment application), instructions from at least one computing device of the first service provider to acquire user data from a user account of the user associated with a second service provider (col. 24, lines 28–49: information request via third party client application API to financial institution computing system; col. 22, lines 11–48: customer information includes account information for account associated with financial institution).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin by adding the third party application from Fakhraie. One of ordinary skill in the art would have been motivated to make this modification for the purpose of facilitating and securing the sharing of financial information—a benefit explicitly disclosed by Fakhraie (col. 1, line 48–col. 2, line 6: providing access to information can be cumbersome and risks exposure; col. 2, lines 10–44: invention provides user interface through user device application for requesting and authorizing additional information) and desired by Shablygin (¶ 6–7: problems associated with loss of private data).
The combination of Shablygin and Fakhraie does not teach: wherein the instructions include a type of encryption protocol to use to acquire the user data; based at least in part on receiving the instructions, cause presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider; receive, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider; wherein based at least in part on the sent credential, a secure communication session using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider; automatically close the login page of the second service provider in the user interface of the mobile payment application; send, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data; and send, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider.
Gupta, however, teaches:
wherein the instructions include a type of encryption protocol to use to acquire the user data (¶ 31–32: token used for encryption of connection with service provider); and
wherein based at least in part on the sent credential, a secure communication session using the type of encryption protocol specified in the instructions, is established between the mobile payment application and the at least one computing device of the second service provider (¶ 36, 38, 42: secure session for data exchange created based on receiving token at login page).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin and the third party application in Fakhraie by adding the encrypted session from Gupta. One of ordinary skill in the art would have been motivated to make this modification for the purpose of facilitating the sharing of information without sharing secure information—a benefit explicitly disclosed by Gupta (¶ 5–6: need for better securing information used for accessing and sharing data; ¶ 22–25: invention provides token and OAuth session for securing data) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, and Gupta are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
The combination of Shablygin, Fakhraie, and Gupta does not teach: based at least in part on receiving the instructions, cause presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider; receive, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider; automatically close the login page of the second service provider in the user interface of the mobile payment application; send, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data; and send, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider.
Hockey, however, teaches:
based at least in part on receiving the instructions, cause presentation of a login page of the second service provider, via a user interface of the mobile payment application associated with the first service provider (Figs. 29A–29B, ¶ 383–384: user interface of first system displays account credential page for selected external institution; ¶ 185: external user account system APIs accessed by first-party mobile device applications);
receive, via the login page of the second service provider, a credential associated with the user account of the user associated with the second service provider (¶ 384: user enters account credentials);
automatically close the login page of the second service provider in the user interface of the mobile payment application (Fig. 29H, ¶ 388: user interface closed);
send, by the mobile payment application and to the at least one computing device of the second service provider and via the secure communication session, a request for the user data (¶ 172: third-party system requests account data without disclosing credentials); and
send, by the mobile payment application and without having provided the credential to the at least one computing device of the first service provider, at least a portion of the user data to the at least one computing device of the first service provider (¶ 289: access to account and user information obtained, but account credentials not provided to user-facing application or management system).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin, the third party application in Fakhraie, and the encrypted session in Gupta by adding the external login from Hockey. One of ordinary skill in the art would have been motivated to make this modification for the purpose of linking accounts using credential-less authentication—a benefit explicitly disclosed by Hockey (¶ 2–6: authentication for new systems can provide barrier that deters use, so there is need for linking accounts through credential-less authentication; ¶ 34–35: invention provides credential-less authentication for enhancing and improving user experience). Shablygin, Fakhraie, Gupta, and Hockey are all related in part to authentication, so one of ordinary skill in the art would have been motivated to make this authentication even more convenient by combining these references together.
For claim 16, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 15 above, and Shablygin further teaches:
The system of claim 15, wherein the credential comprises a password, a security key, log-in data, a passcode, or a single sign-on usable by the user to access services associated with at least the second service provider (¶ 42: ID Tokens and User ID for accessing third-party authentication system).
For claim 18, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 15 above, and Shablygin further teaches:
The system of claim 15, wherein the processors are further operable when executing the instructions to maintain the session for at least one of a period of time or until an occurrence of an event, wherein while the session is maintained, updated user data is received from the at least one computing device of the second service provider (¶ 80: authentication transaction assigned a maximum time period).
For claim 19, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 15 above, and Shablygin further teaches:
The system of claim 15, wherein the portion of the user data is determined based at least in part on the request, from the at least one computing device of the first service provider, for particular user data (¶ 86, 71: data container specified based on service provider request).
Claims 3, 10, 14, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shablygin et al., U.S. Patent App. No. 2013/0042110 (“Shablygin”) in view of Fakhraie et al., U.S. Patent No. 10,963,589 (“Fakhraie”); Gupta, U.S. Patent App. No. 2018/0255030 (“Gupta”); Hockey et al., U.S. Patent App. No. 2021/0081947 (“Hockey”); and Graham, III et al., U.S. Patent App. No. 2011/0270763 (“Graham”).
For claim 3, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 1 above, and Shablygin further teaches:
The computer-implemented method of claim 1, further comprising: . . . sending the converted second request to access specific data to the at least one computing device of the first service provider, based on context of the second request (¶ 82: request sent to service provider); and
receiving, from the at least one computing device of the first service provider, an instruction to input the credential associated with the user account via the mobile payment application, and wherein the credential associated with the user account is received in response to receiving the instruction (¶ 82: User ID and Encryption Key requested and received).
The combination of Shablygin, Fakhraie, Gupta, and Hockey does not teach: receiving a request to obtain specific data; and converting the request to conform with the service provider.
Graham, however, teaches:
receiving a second request to obtain specific data (¶ 285: user sends request for data); and
converting the second request to conform with the first service provider (¶ 287: records reformatted based on request).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin, the third party application in Fakhraie, the encrypted session in Gupta, and the external login in Hockey by adding the data request from Graham. One of ordinary skill in the art would have been motivated to make this modification for the purpose of securing and protecting dissemination of valuable information—a benefit explicitly disclosed by Graham (¶ 11: need for individuals and businesses to secure, protect, and control this information; ¶ 12: invention provides system for securing data storage and transfer) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, Gupta, Hockey, and Graham are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
For claim 10, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 8 above, and Shablygin further teaches:
The one or more computer-readable non-transitory storage media of claim 8, wherein the software is further operable when executed to: . . . send the converted second request to access specific data to the at least one computing device of the first service provider, based on context of the second request (¶ 82: request sent to service provider); and
receive, from the at least one computing device of the first service provider, an instruction to input a credential associated with the user account via the mobile payment application, and wherein the credential associated with the user account is received in response to receiving the instruction (¶ 82: User ID and Encryption Key requested and received).
The combination of Shablygin, Fakhraie, Gupta, and Hockey does not teach: receive a second request to obtain specific data; and convert the second request to conform with the first service provider.
Graham, however, teaches:
receive a second request to obtain specific data (¶ 285: user sends request for data); and
convert the second request to conform with the first service provider (¶ 287: records reformatted based on request).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin, the third party application in Fakhraie, the encrypted session in Gupta, and the external login in Hockey by adding the data request from Graham. One of ordinary skill in the art would have been motivated to make this modification for the purpose of securing and protecting dissemination of valuable information—a benefit explicitly disclosed by Graham (¶ 11: need for individuals and businesses to secure, protect, and control this information; ¶ 12: invention provides system for securing data storage and transfer) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, Gupta, Hockey, and Graham are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
For claim 14, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 8 above. The combination of Shablygin, Fakhraie, Gupta, and Hockey does not teach: wherein the second service provider is a payroll service provider and the user data is payroll data.
Graham, however, teaches:
The one or more computer-readable non-transitory storage media of claim 8, wherein the second service provider is a payroll service provider and the user data is payroll data (¶ 316, 318: payroll service provider; ¶ 138: information includes payroll data).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin, the third party application in Fakhraie, the encrypted session in Gupta, and the external login in Hockey by adding the payroll information from Graham. One of ordinary skill in the art would have been motivated to make this modification for the purpose of securing and protecting dissemination of valuable information—a benefit explicitly disclosed by Graham (¶ 11: need for individuals and businesses to secure, protect, and control this information; ¶ 12: invention provides system for securing data storage and transfer) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, Gupta, Hockey, and Graham are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
For claim 17, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 15 above, and Shablygin further teaches:
The system of claim 15, wherein the one or more processors are further operable when executing the instructions to: . . . send the converted second request to access specific data to the at least one computing device of the first service provider, based on context of the second request (¶ 82: request sent to service provider); and
receive, from the at least one computing device of the first service provider, an instruction to input a credential associated with the user account via the mobile payment application, and wherein the credential associated with the user account is received in response to receiving the instruction (¶ 82: User ID and Encryption Key requested and received).
The combination of Shablygin, Fakhraie, Gupta, and Hockey does not teach: receive a second request to obtain specific data; and convert the second request to conform with the first service provider.
Graham, however, teaches:
receive a second request to obtain specific data (¶ 285: user sends request for data); and
convert the second request to conform with the first service provider (¶ 287: records reformatted based on request).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin, the third party application in Fakhraie, the encrypted session in Gupta, and the external login in Hockey by adding the data request from Graham. One of ordinary skill in the art would have been motivated to make this modification for the purpose of securing and protecting dissemination of valuable information—a benefit explicitly disclosed by Graham (¶ 11: need for individuals and businesses to secure, protect, and control this information; ¶ 12: invention provides system for securing data storage and transfer) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, Gupta, Hockey, and Graham are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
For claim 20, Shablygin, Fakhraie, Gupta, and Hockey teach all the limitations of claim 15 above. The combination of Shablygin, Fakhraie, Gupta, and Hockey does not teach: wherein the second service provider is a payroll service provider and the user data is payroll data.
Graham, however, teaches:
The system of claim 15, wherein the second service provider is a payroll service provider and the user data is payroll data (¶ 316, 318: payroll service provider; ¶ 138: information includes payroll data).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the data storage in Shablygin, the third party application in Fakhraie, the encrypted session in Gupta, and the external login in Hockey by adding the payroll information from Graham. One of ordinary skill in the art would have been motivated to make this modification for the purpose of securing and protecting dissemination of valuable information—a benefit explicitly disclosed by Graham (¶ 11: need for individuals and businesses to secure, protect, and control this information; ¶ 12: invention provides system for securing data storage and transfer) and desired by Shablygin (¶ 6–7: problems associated with loss of private data). Shablygin, Fakhraie, Gupta, Hockey, and Graham are all related to securing information, so one of ordinary skill in the art would have been motivated to make this information even more secure by combining these references together.
Response to Arguments
Claim Rejections Under 35 U.S.C. § 101
Applicant’s arguments filed on January 22, 2026 have been fully considered but they are not persuasive.
First, Applicant argues that the claims are not directed to an abstract idea because they recite an improvement to computing capabilities. Applicant explains that the claims allow users to provide credentials directly to a second service provider through a login page, so that the credential is stored locally and need not be provided to the first service provider, which improves computing security. Applicant further explains that the claims send instructions including a type of encryption protocol to use to establish a secure session, which also improves network security. Applicant points to the specification to further highlight that the claimed invention reduces risk of hackers and allows for longer secure session by both storing the credential locally and a more secure encryption, respectively. Finally, Applicant explains that these steps cannot be practically performed in the human mind, and even if the claims recite an abstract idea, they are still integrated into a practical application for the reasons discussed above. Even if the claims do not recite mental processes, however, they still recite securing a data transfer interaction, which is the abstract idea of certain methods of organizing human activity. Furthermore, the improvements recited by Applicant are merely improvements to this abstract idea to make it more secure. The claims merely use the computer as a tool to encrypt the interaction and determine who has access to the secure data. Rather than provide an improvement to the encryption or network security technologies themselves, the claims merely recite that a more specific encryption protocol is used and that sensitive data is not shared with certain parties. These features are therefore merely using these technologies as generic tools to make the abstract idea of the transaction more secure. Applicant also cites to a recent USPTO Appeals Review Panel decision, which found an improvement to machine learning technology to be patent eligible, to highlight that software features can also provide non-abstract improvements to computer technology. While the claims in that case, however, optimized performance and functionality of the machine learning model, the claimed invention here is merely using the technologies as tools to implement the abstract idea. As explained above, the claims are not optimizing or improving the encryption or network security technologies themselves, but are instead making the transaction more secure by merely applying these technologies. Thus, claims 1–20 do recite an abstract idea, and do not include additional elements sufficient to integrate the claims into a practical application.
Next, Applicant argues that the claims recite significantly more than the judicial exception. Applicant cites the newly amended additional elements of claim 1 and explains that these features—using the user device as a conduit for transferring data, using a particular encryption protocol, and directly presenting a login page in the mobile payment application—are not well-understood, routine, or conventional. As discussed above, however, these features merely apply the abstract idea to the generic computer technology, using it as a tool, rather than improving the technology itself in any way. And, merely applying an abstract idea to a computer, as established in Step 2A Prong Two, cannot provide an inventive concept, as required under Step 2B. See MPEP 2106.05(f). Thus, claims 1–20 do not include additional elements sufficient to amount to significantly more than the judicial exception.
Claim Rejections Under 35 U.S.C. § 103
Applicant’s arguments with respect to claims 1–20 have been considered but are moot because the arguments do not apply to the references being used in the current rejection.
Applicant has amended claims 1, 8, and 15 and argues that the combination of Shablygin (U.S. Patent App. No. 2013/0042110), Fakhraie (U.S. Patent No. 10,963,589), and Gupta (U.S. Patent App. No. 2018/0255030) does not disclose these additional limitations. Claim 1, however, is currently rejected under 35 U.S.C. 103 over Shablygin in view of Fakhraie, Gupta, and Hockey (U.S. Patent App. No. 2021/0081947). Thus, Applicant’s arguments with respect to claims 1, 8, and 15 are moot.
Applicant argues that the dependent claims are allowable by virtue of their dependence on claims 1, 8, and 15, which were amended to overcome the rejection under 35 U.S.C. 103. As discussed above, however, claims 1, 8, and 15 are currently rejected under 35 U.S.C. 103 over Shablygin in view of Fakhraie, Gupta, and Hockey. Thus, Applicant’s arguments with respect to claims 2–7, 9–14, and 16–20 are moot.
Prior Art Not Relied Upon
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure. Those prior art references are as follows:
Pate et al., U.S. Patent No. 11,316,862, discloses application programming interfaces for authorizing users.
Hockey et al., U.S. Patent No. 9,449,346, discloses application proxy instances for requesting account data from external financial systems through proprietary application programming interfaces.
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 DIVESH PATEL whose telephone number is (571) 272–3430. The examiner can normally be reached on Monday and Thursday 10:00 AM–8:00 PM EST.
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, Matthew Gart can be reached on (571) 272–3955. 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.
/DIVESH PATEL/Examiner, Art Unit 3696