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 .
Applicant filed a response dated December 2, 2025 in which claims 1, 9, 17, and 20 have been amended. Therefore, claims 1-20 are currently pending in the application.
Priority
Application 18/327,486 was filed on 06/01/2023 is a CON of 16/984,915 08/04/2020 and claims priority to SINGAPORE 10201908025R 08/30/2019.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. See In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) may be used to overcome an actual or provisional rejection based on a non-statutory double patenting ground provided the conflicting application or patent is shown to be commonly owned with this application. See 37 CFR 1.131(c). A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional, the reply must be complete. MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to MPEP 1490(V)(A).
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 11,704,653 in view of Brockmann, U.S. Patent Application Publication No. 2017/0068952.
Claims 1, 9, and 17 of the instant application are broader and fully encompass the method steps of claim 1 of U.S. Patent No. 11,704,653, except the implementation of the method steps “presenting, via a payment application running on the user device, an interactive user interface”.
As to claims 1, 9, and 17, as supported by the disclosure of 2017/0068952, Brockmann at paragraphs [0063]–[0065], it was known in the art, e.g., that a “user device to perform operations comprising: presenting, via a payment application running on the user device, an interactive user interface”. “For example, in some embodiments, the application 460 may initiate presentation of an interface for digital wallet management.”
And also as supported by the disclosure of 2016/0224966, Van Os at paragraphs [0316]-[0318] “In accordance with a determination that the credit card is not of the first type (e.g., based on the portion of the credit card number received), the electronic device displays input field 1046 (the security code input field) and 1048 (the expiration date input field).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine the method steps of the 11,704,563 Patent with the steps of “presenting, via a payment application running on the user device, an interactive user interface” and to “enables the user to manually enter the digital token in an input card information field” for the purposes of improving security, and providing flexibility and convenience in controlling transactions, controlling accounts used for transactions, and sharing transactions between various users.
Claim 17 of the instant application are broader and fully encompass the method steps of claim 1 of U.S. Patent No. 11,704,653, except the implementation of the method steps “sending, to the server, a request to initiate tokenization of a pre-linked payment card from a user selected merchant of the one or more user selected merchants, the request generated based on a user selection of a token based payment from the merchant payment interface; and
displaying, via the interactive user interface, the digital token in the floating widget at the merchant payment interface on the user device, wherein the floating widget enables the user to enter the digital token at the merchant payment interface for processing the online payment transaction;”.
As to claim 17, as supported by the disclosure of 2012/0030047, Fuentes at paragraphs [0017]-[0019] “In some implementations, a merchant-branded PT application may be developed with the PT functionality, which may directly connect the user into the merchant's transaction processing system. For example, the user may choose from a number of cards (e.g., credit cards, debit cards, prepaid cards, etc.) from various card providers, e.g., 203.”
And also as supported by the disclosure of 2018/0293573, Ortiz at paragraphs [0211]–[0213], it was known in the art, e.g., that a “As shown in FIGS. 14C and 14D, the GUI 1407 provided in FIG. 14B can be provided in the form of an interactive “overlay” screen 1409.” And “enable the user to scroll the GUI 1407 so as to view further payment options available through the wallet 114, options application 116, and or an associated FI 120, 160; and optionally to control payment using a combination of accounts or fund sources.”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine the method steps of the 11,704,563 Patent with the steps of “sending, to the server, a request to initiate tokenization of a pre-linked payment card from a user selected merchant of the one or more user selected merchants, the request generated based on a user selection of a token based payment from the merchant payment interface; and displaying, via the interactive user interface, the digital token in the floating widget at the merchant payment interface on the user device, wherein the floating widget enables the user to enter the digital token at the merchant payment interface for processing the online payment transaction;” for the purposes of improved user control over electronic transactions such as purchases, including where a purchaser is authorized to access multiple accounts or other funding sources in order to complete a transaction.
Application 18/168,458 Claim 1
Application 18/168,458 Claim 17
US Patent No. 11,704,653
A computer program product comprising at least one non-transitory computer-readable storage medium, the computer-readable storage medium comprising a set of instructions which, when executed by one or more processors in a user device, cause the user device to perform operations comprising:
A computing device comprising: a processor; and a memory coupled to the processor, the memory storing instructions which, when executed by the processor, cause the computing device to perform operations comprising:
receiving, by a server system associated with a payment network, a tokenization request based on selecting a payment card of a plurality of payment cards of a user from a payment application running on a user device for processing an online payment transaction using the selected payment card at a merchant payment interface on the user device, wherein the tokenization request at least comprises a card information of the selected payment card;
presenting, via a payment application running on the user device, an interactive user interface;
presenting, via a payment application running on the computing device, an interactive user interface;
sending, to a server, a tokenization request based on a selected payment card of a user for processing an online payment transaction using the selected payment card at a merchant payment interface on the user device, wherein the tokenization request at least comprises a card information of the selected payment card;
sending, to a server, a tokenization request based on a selected payment card of a user for processing an online payment transaction using the selected payment card at a merchant payment interface on the computing device, wherein the tokenization request at least comprises a card information of the selected payment card;
facilitating, by the server system, generation of a digital token comprising a tokenized card information of the selected payment card; and
receiving, from the server, a digital token comprising a tokenized card information of the selected payment card; displaying, via the interactive user interface, the digital token as an image in a floating widget, wherein the floating widget remains visible after switching to the merchant payment interface and enables the user to manually enter the digital token in an input card information field at the merchant payment interface for processing the online payment transaction; and
receiving, from the server, a digital token comprising a tokenized card information of the selected payment card; and displaying, via the interactive user interface, the digital token as an image in a floating widget, wherein the floating widget remains visible after switching to the merchant payment interface and enables the user to manually enter the digital token in an input card information field at the merchant payment interface for processing the online payment transaction;
provisioning, by the server system, the digital token as an image in a floating widget for display at the merchant payment interface on the user device, wherein the floating widget remains visible after switching to the merchant payment interface and enables the user to manually enter the digital token at the merchant payment interface for processing the online payment transaction,
detecting switching of the merchant payment interface by an other application other than the payment application running on the user device; and automatically closing the floating widget based on the detecting the switching of the merchant payment interface by the other application, and
sending, to the server, a request to initiate tokenization of a pre-linked payment card from a user selected merchant of one or more user selected merchants, the request generated based on a user selection of a token based payment from the merchant payment interface; and displaying, via the interactive user interface, the digital token in the floating widget at the merchant payment interface on the user device, wherein the floating widget enables the user to enter the digital token at the merchant payment interface for processing the online payment transaction,
wherein a screenshot of the floating widget is disabled while the digital token as the image is displayed to prevent copying of the digital token; and
wherein a screenshot of the floating widget is disabled while the digital token as the image is displayed to prevent copying of the digital token; and
wherein a screenshot of the floating widget is disabled while the token as an image is displayed to prevent copying of the token; and
wherein the floating widget is automatically closed based on detecting switching of the merchant payment interface by an application other than the payment application running on the computing device.
wherein the floating widget is automatically closed based on one or more of detecting an inactivity for a predetermined time-period on the merchant payment interface or detecting switching of the merchant payment interface by an application other than the payment application running on the user device.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1, 9, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Brockmann, U.S. Patent Application Publication Number 2017/0068952; in view of Ortiz, U.S. Patent Application Publication Number 2018/0293573; in view of Van Os, U.S. Patent Application Publication Number 2016/0224966; in view of Lancioni, U.S. Patent Application Publication Number 2018/0063091; in view of Liu, WIPO Patent Application Publication Number 2018/000605; in view of Gnanasekaran, U.S. Patent Application Publication Number 2019/0347305.
As per claim 1,
Brockmann explicitly teaches:
A computer program product comprising at least one non-transitory computer-readable storage medium, the computer-readable storage medium comprising a set of instructions which, when executed by one or more processors in a user device, cause the user device to perform operations comprising: presenting, via a payment application running on the user device, an interactive user interface;
(Brockmann US20170068952 at paras. 60, 63-65, 82-84) ([0064] "As further illustrated in FIG. 4, the network remote server 402 comprises computer readable instructions 458 of an application 460. In some embodiments, the memory device, 454 includes data storage 456 for storing data related to and/or used by the application 460. The application 460 may perform one or more of the steps and/or sub-steps discussed herein and/or one or more steps not discussed herein. For example, in some embodiments, the application 460 may initiate presentation of an interface for digital wallet management.")
sending, to a server, a tokenization request based on a selected payment card of a user for processing an online payment transaction using the selected payment card at a merchant payment interface on the user device, wherein the tokenization request at least comprises a card information of the selected payment card;
(Brockmann US20170068952 at paras. 40-42, 59-61) ([0041] "As illustrated in FIG. 1, a tokenization service 50 may be available for the user 2 to use during transactions. As such, before entering into a transaction, the user 2 may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52.")
receiving, from the server, a digital token comprising a tokenized card information of the selected payment card;
(Brockmann US20170068952 at paras. 40-42, 59-61) ([0041] "As illustrated in FIG. 1, a tokenization service 50 may be available for the user 2 to use during transactions. As such, before entering into a transaction, the user 2 may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52.")
Brockmann does not explicitly teach, however, Ortiz does teach:
displaying, via the interactive user interface, the digital token as an image in a floating widget, wherein the floating widget remains visible after switching to a merchant payment interface and [enables the user to manually enter the digital token in an input card information field at the merchant payment interface for processing the online payment transaction; and]
(Ortiz US20180293573 at paras. 211-213) ([0212] "As shown in FIGS. 14C and 14D, the GUI 1407 provided in FIG. 14B can be provided in the form of an interactive “overlay” screen 1409, either by causing the display to generate a new GUI 1407 and overwrite the previous screen completely, or for example by using ‘fade’ or ‘grey-out’ imaging techniques to allow the user 190 to interact with the payment options 116 and/or wallet 114 without otherwise terminating or interrupting a checkout session or process being executed by the merchant system 130, including the merchant's default checkout processes governed by the GUI 1402 shown in FIG. 14A. This can, for example, enable the user to scroll the GUI 1407 so as to view further payment options available through the wallet 114, options application 116, and or an associated FI 120, 160; and optionally to control payment using a combination of accounts or fund sources.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann and Ortiz, because it allows for improved user control over electronic transactions such as purchases, including where a purchaser is authorized to access multiple accounts or other funding sources in order to complete a transaction. (Ortiz at Abstract and paras. 19-25).
Brockmann and Ortiz do not explicitly teach, however, Van Os does teach:
displaying, via the interactive user interface, the digital token as an image in a floating widget, [wherein the floating widget remains visible after switching to the merchant payment interface] and enables the user to manually enter the digital token in an input card information field at the merchant payment interface for processing the online payment transaction; and
(Van Os US20160224966 at paras. 316-318, Figs. 10E-10F) ("[0317] At FIG. 10F, the electronic device receives user input, such as a portion of the credit card number at field 1042. In accordance with a determination that the credit card is of a first type (e.g., based on the portion of the credit card number received), the electronic device forgoes displaying input field 1046 (the security code input field) and 1048 (the expiration date input field). In accordance with a determination that the credit card is not of the first type (e.g., based on the portion of the credit card number received), the electronic device displays input field 1046 (the security code input field) and 1048 (the expiration date input field). If a field is displayed, such as first entry field 1046 or second entry field 1048, and then the electronic device subsequently determines that the displayed field 1046 or 1048 is not needed (e.g., the user goes back and changes the inputted credit card number), the electronic device marks the displayed, but not needed field as “Not Applicable”, grays out the field, or otherwise indicates the data for that field is not needed, rather than removing the field.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, and Van Os, because it allows for faster, more efficient methods and interfaces for conducting payment transactions and linking payment accounts for payment transactions, thereby increasing the effectiveness, efficiency, and user satisfaction with such devices. (Van Os at Abstract and paras. 3-13).
Brockmann, Ortiz, and Van Os do not explicitly teach, however, Lancioni does teach:
wherein a screenshot of the floating widget is disabled while the digital token as the image is displayed to prevent copying of the digital token.
(Lancioni US20180063091 at paras. 147-150) ("[0148] In FIG. 10, Carolina receives a message 1004 from Kevin. The only visible content of this message is carrier image 906. The message also includes the notification, “You have a secret message,” along with a hyperlink that will activate decryption for the message. [0149] Security layer 502 may then decrypt the message, and display plain text message 1006, with the original text of sensitive message 904. There is also a policy notification, specifically, that the message will be destroyed in 24 hours. Note that while plain text message 1006 is displayed, certain functions may be disabled, such as screen capture. Also note that a policy may prevent message 1004 from being forwarded or copied.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, and Lancioni, because it allows for an improved system to control distribution of sensitive or classified information and an additional security layer to provide initial security (such as by encrypting or otherwise protecting the message), but may also provide the user control over an application. (Lancioni at Abstract and paras. 18-20).
Brockmann, Ortiz, Van Os, and Lancioni do not explicitly teach, however, Liu does teach:
“detecting switching”; and
detecting switching of the merchant payment interface by an other application other than the payment application running on the user device; and
(Liu WO2018000605 at pp. 2-3) (“Detecting whether the display page of the first application jumps to the payment page; wherein the first application is any one of the applications installed in the electronic device; If the display page of the first application jumps to the payment page, detecting whether the first application is a security application; If the first application is not a secure application, the payment page is closed.”)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, and Liu, because it improves the user experience while maintaining security. (Liu at Abstract and pp. 8).
Brockmann, Ortiz, Van Os, Lancioni, and Liu do not explicitly teach, however, Gnanasekaran does teach:
automatically closing the floating widget based on the detecting the [switching] of the merchant payment interface by the other application, and
(Gnanasekaran US20190347305 at paras. 60-64, 72-74) (“[0063] The method 400 may then proceed to optional block 410 where application(s) are closed. In an embodiment, subsequent to providing the applications at block 408, the user device may monitor a variety of factors to determine whether to close the applications at optional block 410. For example, the user device 500 may monitor its location to determine whether it is no longer at the location detected at block 404 and, if so, automatically close the applications that were provided at block 408. In another example, the user device 500 may monitor the time passed subsequent to launching the applications at block 408 and, if that time exceeds a predetermined amount of time, automatically close the applications that were provided at block 408. Closing applications may include closing a launched application, closing a quick launch window, reconfiguring applications and/or the user device such that the applications may not be voice launched, etc. While a few examples have been provided, one of skill in the art in possession of the present disclosure will recognize that the user device may automatically close any applications provided at block 408 in response to a variety of situations while remaining within the scope of the present disclosure. Furthermore, in other embodiments, optional block 410 may be skipped and the applications provided at block 408 may not be closed following block 408." "[0072] The user devices 902 may further include other applications as may be desired in particular embodiments to provide desired features to the user devices 192. In particular, the other applications may include a payment application for payments assisted by a payment service provider through the payment service provider device 910. The other applications may also include security applications for implementing customer-side security features, programmatic customer applications for interfacing with appropriate application programming interfaces (APIs) over the network 914, or other types of applications. Email and/or text applications may also be included, which allow user payer to send and receive emails and/or text messages through the network 914. The user devices 902 includes one or more user and/or device identifiers which may be implemented, for example, as operating system registry entries, cookies associated with the browser application, identifiers associated with hardware of the user devices 902, or other appropriate identifiers, such as a phone number. In one embodiment, the user identifier may be used by the payment service provider device 910 to associate the user with a particular account as further described herein." "[0061] Thus, applications may be provided for display in a quick-launch mode that results in the provisioning of application icons for those applications such that the user may select any of the applications icons to launch their associated applications and being using them. While the quick launch window 800 has been illustrated and described as being provided over a lock screen 802 on the user device 500, similar quick launch windows may be provided over a home screen on the user device (e.g., a screen that provides access to application icons for applications included on the user device 500), over an application currently being used on the user device 500, and/or in a variety of other situations known in the art.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, Liu, and Gnanasekaran, because it improves the process of finding a particular application icon amongst the plurality of application icons included on the home screens of the user device, which can be very difficult and time consuming, particularly when application icons may be located in folders with other application icons such that they are not immediately recognizable on the home screen. (Gnanasekaran at Abstract and paras. 1-3).
Claim 9 is substantially similar to claim 1, thus, it is rejected on similar grounds.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Brockmann, U.S. Patent Application Publication Number 2017/0068952; in view of Ortiz, U.S. Patent Application Publication Number 2018/0293573; in view of Van Os, U.S. Patent Application Publication Number 2016/0224966; in view of Lancioni, U.S. Patent Application Publication Number 2018/0063091; in view of Liu, WIPO Patent Application Publication Number 2018/000605; in view of Gnanasekaran, U.S. Patent Application Publication Number 2019/0347305; in view of Fuentes, U.S. Patent Application Publication Number 2012/0030047.
As per claim 17,
Brockmann explicitly teaches:
A computing device comprising: a processor; and a memory coupled to the processor, the memory storing instructions which, when executed by the processor, cause the computing device to perform operations comprising: presenting, via a payment application running on the computing device, an interactive user interface;
(Brockmann US20170068952 at paras. 60, 63-65, 82-84) ([0064] "As further illustrated in FIG. 4, the network remote server 402 comprises computer readable instructions 458 of an application 460. In some embodiments, the memory device, 454 includes data storage 456 for storing data related to and/or used by the application 460. The application 460 may perform one or more of the steps and/or sub-steps discussed herein and/or one or more steps not discussed herein. For example, in some embodiments, the application 460 may initiate presentation of an interface for digital wallet management.")
sending, to a server, a tokenization request based on a selected payment card of a user for processing an online payment transaction using the selected payment card at a merchant payment interface on the computing device, wherein the tokenization request at least comprises a card information of the selected payment card;
(Brockmann US20170068952 at paras. 40-42, 59-61) ([0041] "As illustrated in FIG. 1, a tokenization service 50 may be available for the user 2 to use during transactions. As such, before entering into a transaction, the user 2 may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52.")
receiving, from the server, a digital token comprising a tokenized card information of the selected payment card; and
(Brockmann US20170068952 at paras. 40-42, 59-61) ([0041] "As illustrated in FIG. 1, a tokenization service 50 may be available for the user 2 to use during transactions. As such, before entering into a transaction, the user 2 may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52.")
Brockmann does not explicitly teach, however, Ortiz does teach:
displaying, via the interactive user interface, the digital token as an image in a floating widget, wherein the floating widget remains visible after switching to the merchant payment interface and [enables the user to manually enter the digital token in an input card information field at the merchant payment interface for processing the online payment transaction;]
(Ortiz US20180293573 at paras. 211-213) ([0212] "As shown in FIGS. 14C and 14D, the GUI 1407 provided in FIG. 14B can be provided in the form of an interactive “overlay” screen 1409, either by causing the display to generate a new GUI 1407 and overwrite the previous screen completely, or for example by using ‘fade’ or ‘grey-out’ imaging techniques to allow the user 190 to interact with the payment options 116 and/or wallet 114 without otherwise terminating or interrupting a checkout session or process being executed by the merchant system 130, including the merchant's default checkout processes governed by the GUI 1402 shown in FIG. 14A. This can, for example, enable the user to scroll the GUI 1407 so as to view further payment options available through the wallet 114, options application 116, and or an associated FI 120, 160; and optionally to control payment using a combination of accounts or fund sources.")
displaying, via the interactive user interface, the digital token in the floating widget at the merchant payment interface on the user device, wherein the floating widget enables the user to enter the digital token at the merchant payment interface for processing the online payment transaction,
(Ortiz US20180293573 at paras. 211-213) ([0212] "As shown in FIGS. 14C and 14D, the GUI 1407 provided in FIG. 14B can be provided in the form of an interactive “overlay” screen 1409, either by causing the display to generate a new GUI 1407 and overwrite the previous screen completely, or for example by using ‘fade’ or ‘grey-out’ imaging techniques to allow the user 190 to interact with the payment options 116 and/or wallet 114 without otherwise terminating or interrupting a checkout session or process being executed by the merchant system 130, including the merchant's default checkout processes governed by the GUI 1402 shown in FIG. 14A. This can, for example, enable the user to scroll the GUI 1407 so as to view further payment options available through the wallet 114, options application 116, and or an associated FI 120, 160; and optionally to control payment using a combination of accounts or fund sources.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann and Ortiz, because it allows for improved user control over electronic transactions such as purchases, including where a purchaser is authorized to access multiple accounts or other funding sources in order to complete a transaction. (Ortiz at Abstract and paras. 19-25).
Brockmann and Ortiz do not explicitly teach, however, Van Os does teach:
displaying, via the interactive user interface, the digital token as an image in a floating widget, [wherein the floating widget remains visible after switching to the merchant payment interface] and enables the user to manually enter the digital token in an input card information field at the merchant payment interface for processing the online payment transaction;
(Van Os US20160224966 at paras. 316-318, Figs. 10E-10F) ("[0317] At FIG. 10F, the electronic device receives user input, such as a portion of the credit card number at field 1042. In accordance with a determination that the credit card is of a first type (e.g., based on the portion of the credit card number received), the electronic device forgoes displaying input field 1046 (the security code input field) and 1048 (the expiration date input field). In accordance with a determination that the credit card is not of the first type (e.g., based on the portion of the credit card number received), the electronic device displays input field 1046 (the security code input field) and 1048 (the expiration date input field). If a field is displayed, such as first entry field 1046 or second entry field 1048, and then the electronic device subsequently determines that the displayed field 1046 or 1048 is not needed (e.g., the user goes back and changes the inputted credit card number), the electronic device marks the displayed, but not needed field as “Not Applicable”, grays out the field, or otherwise indicates the data for that field is not needed, rather than removing the field.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, and Van Os, because it allows for faster, more efficient methods and interfaces for conducting payment transactions and linking payment accounts for payment transactions, thereby increasing the effectiveness, efficiency, and user satisfaction with such devices. (Van Os at Abstract and paras. 3-13).
Brockmann, Ortiz, and Van Os do not explicitly teach, however, Lancioni does teach:
wherein a screenshot of the floating widget is disabled while the digital token as the image is displayed to prevent copying of the digital token; and
(Lancioni US20180063091 at paras. 147-150) ("[0148] In FIG. 10, Carolina receives a message 1004 from Kevin. The only visible content of this message is carrier image 906. The message also includes the notification, “You have a secret message,” along with a hyperlink that will activate decryption for the message. [0149] Security layer 502 may then decrypt the message, and display plain text message 1006, with the original text of sensitive message 904. There is also a policy notification, specifically, that the message will be destroyed in 24 hours. Note that while plain text message 1006 is displayed, certain functions may be disabled, such as screen capture. Also note that a policy may prevent message 1004 from being forwarded or copied.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, and Lancioni, because it allows for an improved system to control distribution of sensitive or classified information and an additional security layer to provide initial security (such as by encrypting or otherwise protecting the message), but may also provide the user control over an application. (Lancioni at Abstract and paras. 18-20).
Brockmann, Ortiz, Van Os, and Lancioni do not explicitly teach, however, Liu does teach:
[wherein the floating widget is automatically closed based on] detecting switching of the merchant payment interface by an application other than the payment application running on the computing device.
(Liu WO2018000605 at pp. 2-3) (“Detecting whether the display page of the first application jumps to the payment page; wherein the first application is any one of the applications installed in the electronic device; If the display page of the first application jumps to the payment page, detecting whether the first application is a security application; If the first application is not a secure application, the payment page is closed.”)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, and Liu, because it improves the user experience while maintaining security. (Liu at Abstract and pp. 8).
Brockmann, Ortiz, Van Os, Lancioni, and Liu do not explicitly teach, however, Gnanasekaran does teach:
wherein the floating widget is automatically closed based on detecting [switching] of the merchant payment interface by an application other than the payment application running on the computing device.
(Gnanasekaran US20190347305 at paras. 60-64, 72-74) (“[0063] The method 400 may then proceed to optional block 410 where application(s) are closed. In an embodiment, subsequent to providing the applications at block 408, the user device may monitor a variety of factors to determine whether to close the applications at optional block 410. For example, the user device 500 may monitor its location to determine whether it is no longer at the location detected at block 404 and, if so, automatically close the applications that were provided at block 408. In another example, the user device 500 may monitor the time passed subsequent to launching the applications at block 408 and, if that time exceeds a predetermined amount of time, automatically close the applications that were provided at block 408. Closing applications may include closing a launched application, closing a quick launch window, reconfiguring applications and/or the user device such that the applications may not be voice launched, etc. While a few examples have been provided, one of skill in the art in possession of the present disclosure will recognize that the user device may automatically close any applications provided at block 408 in response to a variety of situations while remaining within the scope of the present disclosure. Furthermore, in other embodiments, optional block 410 may be skipped and the applications provided at block 408 may not be closed following block 408." "[0072] The user devices 902 may further include other applications as may be desired in particular embodiments to provide desired features to the user devices 192. In particular, the other applications may include a payment application for payments assisted by a payment service provider through the payment service provider device 910. The other applications may also include security applications for implementing customer-side security features, programmatic customer applications for interfacing with appropriate application programming interfaces (APIs) over the network 914, or other types of applications. Email and/or text applications may also be included, which allow user payer to send and receive emails and/or text messages through the network 914. The user devices 902 includes one or more user and/or device identifiers which may be implemented, for example, as operating system registry entries, cookies associated with the browser application, identifiers associated with hardware of the user devices 902, or other appropriate identifiers, such as a phone number. In one embodiment, the user identifier may be used by the payment service provider device 910 to associate the user with a particular account as further described herein." "[0061] Thus, applications may be provided for display in a quick-launch mode that results in the provisioning of application icons for those applications such that the user may select any of the applications icons to launch their associated applications and being using them. While the quick launch window 800 has been illustrated and described as being provided over a lock screen 802 on the user device 500, similar quick launch windows may be provided over a home screen on the user device (e.g., a screen that provides access to application icons for applications included on the user device 500), over an application currently being used on the user device 500, and/or in a variety of other situations known in the art.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, Liu, and Gnanasekaran, because it improves the process of finding a particular application icon amongst the plurality of application icons included on the home screens of the user device, which can be very difficult and time consuming, particularly when application icons may be located in folders with other application icons such that they are not immediately recognizable on the home screen. (Gnanasekaran at Abstract and paras. 1-3).
Brockmann, Ortiz, Van Os, Lancioni, Liu, and Gnanasekaran do not explicitly teach, however, Fuentes does teach:
sending, to the server, a request to initiate tokenization of a pre-linked payment card from a user selected merchant of one or more user selected merchants, the request generated based on a user selection of a token based payment from the merchant payment interface; and
(Fuentes US20120030047 at paras. 17-19) ([0018] "FIGS. 2A-B shows application user interface diagrams illustrating example features of application interfaces for controlling tokenized payments for purchase transactions in some embodiments of the PT. In some implementations, an app executing on the device of the user may include an app interface providing various features for the user. In some implementations, the app may include an indication of the location (e.g., name of the merchant store, geographical location, information about the aisle within the merchant store, etc.) of the user, e.g., 201. The app may provide an indication of a pay amount due for the purchase of the product, e.g., 202. In some implementations, the app may provide various options for the user to pay the amount for purchasing the product(s). For example, the app may utilize the GPS coordinates to determine the merchant store within the user is present, and direct the user to a website of the merchant. In some implementations, the PT may provide an API for participating merchants directly to facilitate transaction processing. In some implementations, a merchant-branded PT application may be developed with the PT functionality, which may directly connect the user into the merchant's transaction processing system. For example, the user may choose from a number of cards (e.g., credit cards, debit cards, prepaid cards, etc.) from various card providers, e.g., 203. In some implementations, the app may provide the user the option to pay the purchase amount using funds included in a bank account of the user, e.g., a checking, savings, money market, current account, etc., e.g., 204. In some implementations, the user may have set default options for which card, bank account, etc. to use for the purchase transactions via the app. In some implementations, such setting of default options may allow the user to initiate the purchase transaction via a single click, tap, swipe, and/or other remedial user input action, e.g., 205. In some implementations, when the user utilizes such an option, the app may utilize the default settings of the user to initiate the purchase transaction.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, Liu, Gnanasekaran, and Fuentes, because it allows for an improved system to securely complete purchase transactions. (Fuentes at Abstract and paras. 1-3, 19).
Claims 2, 3, and 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Brockmann, U.S. Patent Application Publication Number 2017/0068952; in view of Ortiz, U.S. Patent Application Publication Number 2018/0293573; in view of Van Os, U.S. Patent Application Publication Number 2016/0224966; in view of Lancioni, U.S. Patent Application Publication Number 2018/0063091; in view of Liu, WIPO Patent Application Publication Number 2018/000605; in view of Gnanasekaran, U.S. Patent Application Publication Number 2019/0347305; in view of Oberheide, U.S. Patent Application Publication Number 2016/0197914.
As per claim 2,
Brockmann does not explicitly teach, however, Ortiz does teach:
and displaying, via the interactive user interface, [the one of the PIN, the password or the OTP in] the floating widget, [wherein the floating widget enables the user to enter the one of the PIN, the password or the OTP] at the merchant payment interface for processing the online payment transaction.
(Ortiz US20180293573 at paras. 211-213) ([0212] "As shown in FIGS. 14C and 14D, the GUI 1407 provided in FIG. 14B can be provided in the form of an interactive “overlay” screen 1409, either by causing the display to generate a new GUI 1407 and overwrite the previous screen completely, or for example by using ‘fade’ or ‘grey-out’ imaging techniques to allow the user 190 to interact with the payment options 116 and/or wallet 114 without otherwise terminating or interrupting a checkout session or process being executed by the merchant system 130, including the merchant's default checkout processes governed by the GUI 1402 shown in FIG. 14A. This can, for example, enable the user to scroll the GUI 1407 so as to view further payment options available through the wallet 114, options application 116, and or an associated FI 120, 160; and optionally to control payment using a combination of accounts or fund sources.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann and Ortiz, because it allows for improved user control over electronic transactions such as purchases, including where a purchaser is authorized to access multiple accounts or other funding sources in order to complete a transaction. (Ortiz at Abstract and paras. 19-25).
Brockmann, Ortiz, Van Os, Lancioni, Liu, and Gnanasekaran do not explicitly teach, however, Oberheide does teach:
wherein the instructions, when executed, cause the user device to perform further operations comprising: receiving, from the server, one of a Personal Identification Number (PIN), a password or a One-time Password (OTP); and displaying, via the interactive user interface, the one of the PIN, the password or the OTP in the floating widget, wherein the floating widget enables the user to enter the one of the PIN, the password or the OTP [at the merchant payment interface for processing the online payment transaction.]
(Oberheide US20160197914 at paras. 18-19, 24, 40,51-53, 57-66, and 71) ("[0018] An access device is a computing device used in accessing an outside service such as a desktop computer, a mobile phone, a tablet, a connected television, a gaming system, wearable computer, ATM machine, or any suitable computing device." "[0027] The method 100 is preferably operable on one or more devices including an access device (i.e., a device used to access an outside service) and an authenticating device (a device to which an OTP is generated and/or to which an OTP is sent). In some cases, the authenticating device and access device may be the same device (e.g., a web browser of a smartphone is used to access an outside service; a text containing an OTP is sent to the phone number associated with that smartphone)." "[0051] S130 includes generating an OTP." "[0052] S130 is preferably performed by an OTP app on the authenticating device, but may additionally or alternatively be performed on any device. For example, S130 may include generating the OTP at a cloud-based platform and transmitting the OTP to the authenticating device." "[0066] S153 includes populating an OTP field with the OTP. S153 functions to enable the OTP field to be populated in response to receipt of the OTP at the access device. S153 prefer include automatically populating an OTP entry field, but may additionally or alternatively enable field population in any manner. For example, S153 may include copying the OTP to the clipboard of the access device and prompting a user to paste the OTP in a corresponding OTP field. As another example, S153 may include prompting a user to select an OTP field, and populating that field automatically after selection." "[0024] If the communication channel between the facilitator software and the OTP app is not functioning, the OTP app can still generate an OTP and a user may manually enter the OTP.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, Liu, Gnanasekaran, and Oberheide, because it allows for a useful system and method for converting one-time passcodes to app-based authentication. (Oberheide at Abstract and paras. 2-8).
As per claim 3,
Brockmann, Ortiz, Van Os, Lancioni, Liu, and Gnanasekaran do not explicitly teach, however, Oberheide does teach:
wherein the OTP is received via an SMS application reading an SMS message containing the OTP.
(Oberheide US20160197914 at paras. 22-24) ("[0023] In one variation, the outside service may not depend on OTP generators and will transmit an OTP to an account-paired device. For example, after providing username and password, a website may send an OTP passcode through an SMS message. In this variation, the facilitator software may not initiate any actions. The OTP app preferably detects an OTP received on the app and can automatically trigger the OTP app to be activated so that a simple user-interface interaction is offered.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, Liu, Gnanasekaran, and Oberheide, because it allows for a useful system and method for converting one-time passcodes to app-based authentication. (Oberheide at Abstract and paras. 2-8).
Claim 10 is substantially similar to claim 2, thus, it is rejected on similar grounds.
Claim 11 is substantially similar to claim 3, thus, it is rejected on similar grounds.
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Brockmann, U.S. Patent Application Publication Number 2017/0068952; in view of Ortiz, U.S. Patent Application Publication Number 2018/0293573; in view of Van Os, U.S. Patent Application Publication Number 2016/0224966; in view of Lancioni, U.S. Patent Application Publication Number 2018/0063091; in view of Liu, WIPO Patent Application Publication Number 2018/000605; in view of Gnanasekaran, U.S. Patent Application Publication Number 2019/0347305; in view of Kalgi, U.S. Patent Application Publication Number 2013/0013499.
As per claim 4,
Brockmann, Ortiz, Van Os, Lancioni, Liu, and Gnanasekaran do not explicitly teach, however, Kalgi does teach:
wherein the instructions, when executed, cause the user device to perform further operations comprising: obtaining, via the interactive user interface, a biometric input from the user for authentication of the user; wherein the biometric input includes one or more of a facial scan, a fingerprint scan, a retina scan, an iris scan, or a voice input.
(Kalgi US20130013499 at paras. 34-36 and 47-52) ([0048] "For example, the merchant's website may present a webpage to the user. In various embodiments, the webpage may be a webpage with a link that the user may use to add EWCP support, a redirect to a webpage of the EWCP provider, a webpage with a Java applet that provides EWCP support, a Web 2.0 and/or Javascript widget loaded/embedded into the currently viewed webpage, and/or the like. [0051] "In another implementation, the merchant's website may detect (e.g., via Javascript) that the client supports multiple protocol handlers and provide a protocol string based on a ranking specified by the merchant. If a supported protocol handler is found, and the protocol handler is one that is handled by an EWCP application, the client may utilize the protocol handler to instantiate a EWCP application (e.g., an e-wallet application) and pass any parameters to it. For example, the client may first authenticate the user, e.g., 511. For example, the client may challenge the user in a variety of ways. As non-limiting illustrative example, the user may be required to enter login information, answer a challenge question, submit a voice/biometric signature, provide a digital certificate, enter into a video call for verification purposes, and/or the like. If the user is not verified, e.g., 512, option “No,” the client may use an alternative payment scheme if available (see FIG. 4, 440). If the user is verified, e.g., 512, option “Yes,” the client may obtain security credentials (e.g., a hash code, a secure key, etc.), for example, retrieved from the client's memory, to launch the wallet application, and may instantiate the wallet application, e.g., 513." [0035] "See FIGS. 13-19B for additional details regarding exemplary E-Wallet popup features and/or embodiments. In one embodiment, the E-Wallet may challenge the user with a password login/dialog box prior to displaying the information shown in the E-Wallet popup 208c and/or prior to allowing a single click purchase. In one embodiment, subsequent selections of the “Buy” or “Authorize” button(s) may use these default settings. Upon clicking the “Buy” button 208a, the default payment method (e.g., a specific credit card) may be used instead of prompting the customer to select a wallet and/or a payment method to be used.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, Liu, Gnanasekaran, and Kalgi, because it allows for a system to improve the efficiency of communicating the purchase transaction request, and may also advantageously improve the privacy protections provided to the user and/or merchant. (Kalgi at Abstract and paras. 70-72).
Claim 12 is substantially similar to claim 4, thus, it is rejected on similar grounds.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Brockmann, U.S. Patent Application Publication Number 2017/0068952; in view of Ortiz, U.S. Patent Application Publication Number 2018/0293573; in view of Van Os, U.S. Patent Application Publication Number 2016/0224966; in view of Lancioni, U.S. Patent Application Publication Number 2018/0063091; in view of Liu, WIPO Patent Application Publication Number 2018/000605; in view of Gnanasekaran, U.S. Patent Application Publication Number 2019/0347305; in view of Henderson, U.S. Patent Application Publication Number 2016/0210606.
As per claim 5,
Brockmann, Ortiz, Van Os, Lancioni, Liu, and Gnanasekaran do not explicitly teach, however, Henderson does teach:
wherein the instructions, when executed, cause the user device to perform further operations comprising: displaying a pre-defined list of merchants for user selection via the interactive user interface; receiving a user selection of one or more merchants from the pre-defined list of the merchants; and linking at least one payment card of one or more of payment cards of the user with each of the one or more user selected merchants.
(Henderson US20160210606 at paras. 55-60) ([0056] "FIG. 4A is a diagram of example view 400 of the user application's main page on a user's mobile device. The user application can retrieve a list of merchants 412 in response to an application query (e.g., on startup of the application). The ranking of merchants that are retrieved within the list will be described further below in reference to FIGS. 8 and 9. The application can display the list of merchants 412. The list of merchants can be organized into a plurality of rows, each row containing the name 412a of a single merchant. The list can also include an icon 412b for each merchant, e.g., located in the row with the name of the merchant. For example, each merchant's icon 412b can be located on the left side of the name 412a of the merchant. In some implementations, a cover image 408 for a merchant, e.g., the first merchant in the list, is displayed. The application can display a distance 410 that a merchant is from a current location of the mobile device. Again, the distance 410 can be located in the row with the name 412a of the merchant, e.g., on the right side of the name 412 of the merchant." [0058] "The application can present user account information by tapping an account button 402. When provided with input, the application can search for merchants in a search bar 404. For example, the application can send the search query to a cardless payment system and be provided with merchants that are relevant to the search query. Tapping a ‘favorites’ button 406 can cause the application to retrieve a list of favorites from the cardless payment system and display a list of favorite merchants selected by the user." [0059] "To select a favorite, a user can perform a side swipe motion on a merchant listing. This can cause the application to bring up a list of options related to the merchant. For example, the application can display options to favorite the merchant or share the merchant using different communication protocols (e.g., email or social network sharing). If a user selects a merchant as a favorite, the application sends the user's selection to the cardless payment system and associates the selection with the user's account.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, Liu, Gnanasekaran, and Henderson, because it allows for a convenient graphical user interface that lists merchants that allow cardless payment transactions that can be displayed on the user's mobile device. (Henderson at Abstract and paras. 3-10).
Claim 13 is substantially similar to claim 5, thus, it is rejected on similar grounds.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Brockmann, U.S. Patent Application Publication Number 2017/0068952; in view of Ortiz, U.S. Patent Application Publication Number 2018/0293573; in view of Van Os, U.S. Patent Application Publication Number 2016/0224966; in view of Lancioni, U.S. Patent Application Publication Number 2018/0063091; in view of Liu, WIPO Patent Application Publication Number 2018/000605; in view of Gnanasekaran, U.S. Patent Application Publication Number 2019/0347305; in view of System and method about widget dynamically relocation, Non-Patent Literature May 8, 2013.
As per claim 8,
Brockmann, Ortiz, Van Os, Lancioni, Liu, and Gnanasekaran do not explicitly teach, however, System and method about widget dynamically relocation does teach:
wherein the floating widget is sized to fit contents of the digital token, and wherein the floating widget is relocatable within a display screen of the user device.
(System and method about widget dynamically relocation May 8, 2013 at pp. 2, 5, and 6) ("The invention uses the event trigger method .It listens to the construction/destruction, hide/appear, relocation events of the components to determine the UI change in the screen.- The time and the sequence of the component construction event is recorded as well as the component location and size. The invention also checks the type of the components to determine whether they can be covered." "With this method, once an application has UI layout change (create a new window, resize/move an existing window, etc),- the new position info will be reported to the Layout Manager.- As Layout Manager has all the window/component information of the active applications that running in the current user context, it can calculate whether there is an overlap happened between the application and floating widgets. If it detects a critical component who need always displayed at the front was covered by the floating widgets, it will move the widgets to the free area.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brockmann, Ortiz, Van Os, Lancioni, Liu, Gnanasekaran, and System and method about widget dynamically relocation, because it allows for an efficient method to find the space that can be used to show a floating widget. (System and method about widget dynamically relocation at pp. 1).
Claim 16 is substantially similar to claim 8, thus, it is rejected on similar grounds.
Response to Arguments
Applicant’s arguments filed on December 2, 2025 have been fully considered but are not persuasive for the following reasons:
With respect to Applicant’s arguments as to the Double Patenting rejections for now pending claims 1-20, Examiner notes that the arguments are moot in light of the new grounds for rejection.
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1-20, Examiner notes the following:
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1-5, 8-13, and 16-17, Examiner notes that the arguments are moot in light of the new grounds for rejection.
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 6-7, 14-15, and 18-20, Examiner notes that the rejection is withdrawn.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
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 Tran can be reached on 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.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695