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 .
Priority
Acknowledgement is made this application is a CON of 17/565,073 filed on 12/29/2021 (PAT 12,321,908) which is a CON of 16/731,535 filed on 12/31/2019 (PAT 11,276,049).
Examiner Comments
Claim 1 presented examination on 05/06/2025. Applicant filed a preliminary amendment on 07/22/2025 canceling the claim 1 and adding new claims 2-21. Therefore, the claims 2-21 are pending.
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. A non-statutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); 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) or 1.321(d) may be used to overcome an actual or provisional rejection based on a non-statutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
1. Claims 2-20 of instant application are rejected on the ground of non-statutory double patenting over claims 1-20 of U. S. Patent No. 12,321,908 since the claims, if allowed, would improperly extend the "right to exclude" already granted in the patent.
The subject matter claimed in the instant application is fully disclosed in the patent and is covered by the patent since the patent ‘908 and the application are claiming common subject matter of claims 2, 9 and 16 of instant application and claims 1, 9 and 15 of patent ‘908, as follows:
“receive a request for processing a transaction, transmit programming instructions to the first mobile application of the device, cause the device to retrieve authentication data associated with a second mobile application of the device, and wherein the authentication data is usable for authenticating a user of the device with a service provider server; automatically authenticate the user for processing the transaction based on the authentication data; and in response to authenticating the user based on the authentication data, process the transaction for the user.”
The claims 3 and 4 of instant application teach following limitation of claims 1, 9 and 5 of patent ‘908: “in response to authenticating the user based on the authentication credentials retrieved from the web application, causing the browser object to store an authentication session token in a data store of the browser object associated with the mobile application, the authentication session token usable for authenticating the user by the mobile application in a subsequent interaction with the user.”
Further the claims 7, 13 and 14 of the instant application are taught by the claims 2, 10 and 15 of patent ‘908 respectively.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 9-15 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
.As per amended claims 9-15, claim 9 recites " authenticating, by the computer system, the user for processing the transaction based on the authentication data associated with the second mobile device” which is not supported by the disclosures as submitted including the written description. It appeared there is a typo error on” the second mobile device” as it should have been “a second application of mobile device.”
The written description only supports “a second application of mobile device” but not “the second mobile device”.
Applicant requested to cite a portion of submitted written description/disclosure where support for above limitation is disclosed, otherwise the limitation would constitute a new matter.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
When considering subject matter eligibility under 35 U.S.C. 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself. Examples of abstract ideas include fundamental economic practices; certain methods of organizing human activities; an idea itself; and mathematical relationships/formulas. Alice Corporation Pty. Ltd. v. CLS Bank International, et al., 573 U.S. ____ (2014).
In the instant case, Claims 2-20 are directed to system and method for receiving and displaying customized user interface after detection of presence and authentication of payment application on the mobile device. The claims 1-20 are analyzed to see if claims are statutory category of invention, recites judicial exception and the claims are further analyzed to see if the claims are integrated into practical application if the judicial exception is recited and the claims provides an inventive as per 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) and October 2019 Update: Subject Matter Eligibility as set forth below:
Analysis:
Step 1: Statutory Category? This part of the eligibility analysis evaluates whether the claim falls within any statutory category. MPEP 106.03.
Claim 2 is directed to a system comprising at least a memory device and a processor, for creating dynamic session. The claimed system is therefore directed to a statutory category, i.e., a machine (a combination of device) (Step 1: YES).
Claim 9 is directed to a process i.e., a series of method steps or acts, of creating dynamic session which is a statutory categories of invention (Step 1: YES).
Claim 16 is directed to a non-transitory computer readable storage medium, which is a manufacture. The claim, thus a statutory category of invention (Step 1: YES).
Step 2A - Prong 1: Judicial Exception Recited? This part of the eligibility analysis evaluates whether the claim recites a judicial exception. As explained in MPEP 2106.04(II) and the October 2019 Update, a claim “recites” a judicial exception when the judicial exception is “set forth” or “described” in the claim. There are no nature- based product limitations in this claim, and thus the markedly different characteristics analysis is not performed. However, the claim still must be reviewed to determine if it recites any other type of judicial exception.
Claims 2, 9 and 16 are similar and they are then analyzed to determine whether it is directed to a judicial exception. The claim recite plurality of steps “receive a request for processing a transaction, transmit programming instructions to the first mobile application of the device, and the programming instructions cause the device to retrieve authentication data associated with a second mobile application of the device.”
The limitations of receive a request for processing a transaction, transmit programming causing the device to retrieve authentication data associated with a second mobile application of the device similar to Mortgage Grader, Inc., V. First Choice Loan Servs. Inc., covers performance of the limitation in the mind but for the recitation on of generic computer components. That is, other than reciting “memory and a processor,” nothing in the claim element precludes the step from practically being performed in the mind and thus fall within the “mental processes” grouping of abstract idea set forth in the 2019 PEG. 2019 PEG Section I, 84 Fed. Reg. at 52. For example, but for the “a processor coupled with a non-transitory storage medium” language, “receive a request for processing a transaction, transmit programming causing the device to retrieve authentication data associated with a second mobile application of the device ” in the context of this claim encompasses the user manually receiving request and retrieve authentication data.” The recitation of a processor in this claim does not negate the mental nature of these limitations because the claim here merely uses the processor as a tool to perform the otherwise mental processes. See October Update at Section I(C)(ii). Thus, the above limitations of recite concepts that fall into the “mental process” grouping of abstract ideas. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas (YES).
Step 2A - Prong 2: Integrated into a Practical Application? This part of the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by (a) identifying whether there are any additional elements recited in the claim beyond the judicial exception, and (b) evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. 2019 PEG Section III(A)(2), 84 Fed. Reg. at 54-55.
Besides the abstract idea as described in Prong 1, the claim recites the additional elements of the processor performing “wherein the authentication data is usable for authenticating a user of the device with a service provider server; automatically authenticate the user for processing the transaction based on the authentication data; and in response to authenticating the user based on the authentication data, process the transaction for the user.” The order combination elements of the claim is integrated into a practical application by providing a technical solution to problem of browser session tied to an underlying mobile application and is not authenticated with payment processing platform requiring second mobile application be downloaded and installed the mobile device. The combination order of elements of the claim provide technology-based solution by providing browser object that displays dynamic user interface based on mobile device has installed payment application and user of mobile device has authenticated with payment application (Specification: paragraph [0003 and 0013]). The claims 2, 9 and 16 are eligible because they do not recite a judicial exception as per 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) and October 2019 Update of Subject Matter Eligibility.
Step 2B: Claim provides an Inventive concept? – Not Applicable.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 2-21 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by Venkatakrishnan et al., U.S. Pub No. 2017/0316400 (reference 4 in US Patent Publication in IDS dated 06/13/2025 submitted by the applicant).
As per claim 2, Venkatakrishnan et al. teach a system comprising:
a non-transitory memory storing instructions (see Fig. 12, memory (1206)); and
one or more hardware processors coupled with the non-transitory memory and configured to execute the instructions from the non-transitory memory (see Fig. 12, Processing (1204): paragraph [0082-0083]) to cause the system to:
receive, from a first mobile application of a device, a request for processing a transaction (see Fig. 1, Sweater ($15.00 x 2 = $30.00) -> Checkout with Payment Service Provider (114); Fig. 2, Step 202; where user mobile with installed mobile application of purchasing Sweater request checkout of item to make a payment for the purchase);
transmit programming instructions to the first mobile application of the device, wherein the programming instructions, when executed by the device, cause the device to retrieve authentication data associated with a second mobile application of the device (see Fig. 6, Merchant Application (604), SDK Application (612), Browser Application of Service Provider (302); Fig. 5, URL-> Payment Service Provider, Username, Password; where user is provided with Login by second application of Payment Service Provider for providing user credentials), and
wherein the authentication data is usable for authenticating a user of the device with a service provider server; automatically authenticate the user for processing the transaction based on the authentication data (see Fig. 5, Click here if you want to be remembered by the payment service provider (508): paragraph [0037]; where user is automatically authenticated without user providing user credential information when previous entered credentials are remembered by the system);and
in response to authenticating the user based on the authentication data, process the transaction for the user (see Fig.7 -> Fig. 8, Thank you for your purchase (800): paragraph [0063-0064]; where transaction of purchasing Sweater purchase processed and completed based on automated authentication of the user credential).
As per claim 3, Venkatakrishnan et al. teach the system as described in the claim 2 as described above. Venkatakrishnan et al. further teach instructions further causes the system to:
receive, from the first mobile application, the authentication data based on the device executing the programming instructions (see Fig. 5, Authentication Data: Username, Password (504):paragraph [0037]; where user credential as authentication data is received from mobile application on the user mobile device)..
As per claim 4, Venkatakrishnan et al. teach the system as described in the claim 2 as described above. Venkatakrishnan et al. further teach the system, wherein
the authentication data indicates a previous authentication of the user by the service provider server (see Fig. 5, Click here if you want to be remembered by the payment service provider (508): paragraph [0037]; where previous authentication credential is remembered by the application and used for subsequent authentication for next purchase).
As per claim 5, Venkatakrishnan et al. teach the system as described in the claim 2 as described above. Venkatakrishnan et al. further teach instructions further causes the system to:
cause the first mobile application to store an authentication session token in a data store of the device associated with the first mobile application, wherein the authentication session token is usable for authenticating the user by the service provider server in a subsequent interaction between the user and the first mobile application (see Fig. 6, Access Token (626), Authentication Platform (311), Checkout Platform (627): paragraph 0062]; where access token authenticate and allow user allowing to received correct user financial information rendering appropriate checkout information to complete the transaction).
As per claim 6, Venkatakrishnan et al. teach the system as described in the claim 5 as described above. Venkatakrishnan et al. further teach the system wherein executing the instructions further causes the system to:
receive, from the first mobile application of the device, a second request for processing a second transaction; detect a presence of the authentication session token in the data store of the device associated with the first mobile application; and authenticate the user of the device for processing the second transaction based on the authentication session token (see Fig. 5, Click here if you want to be remembered by the payment service provider (508); Fig. 6, Refresh Token: : paragraph [0037, 0062]; where previous authentication credential is remembered by the application and used for subsequent authentication for next purchase if refresh token is valid).
As per claim 7, Venkatakrishnan et al. teach the system as described in the claim 2 as described above. Venkatakrishnan et al. further teach the system wherein executing the instructions further causes the system to:
detect an absence of an authentication session token in a data store of the device associated with the first mobile application, wherein transmitting the programming instructions is responsive to detecting the absence of the authentication session token (see Fig. 6, Refresh Token: paragraph [0061]; where session/refresh token detected expired is not valid and user is redirected to login page for authentication).
As per claim 8, Venkatakrishnan et al. teach the system as described in the claim 2 as described above. Venkatakrishnan et al. further teach the system, wherein
the second mobile application is a web browser application (see Fig. 6, Browser (302): paragraph [00058]; where browser is other application besides merchant application).
As per claim 9, Venkatakrishnan et al. teach a method, comprising:
receiving, by a computer system, a request for processing a transaction from a first mobile application of a user device (see Fig. 1, Sweater ($15.00 x 2 = $30.00) -> Checkout with Payment Service Provider (114); Fig. 2, Step 202; where user mobile with installed mobile application of purchasing Sweater request to checkout of item to make a payment for the purchase);
in response to detecting an absence of an authentication session token association
with the first mobile application stored on the user device, transmitting, by the computer
system, programming instructions to the first mobile application of the user device (see Fig. 1, Refresh Token (622); paragraph [0062\ where refresh token is expired for mobile application and user is directed login webpage as shown in Fig. 2 which is an application of payment service provider as illustrated by URL in Fig. 5)
wherein the programming instructions, when executed by the user device, cause the user device to retrieve, from the user device, authentication data associated with a second mobile application of the user device (see Fig. 5, URL -> Payment Service Provider, Username and Password (504): paragraph [0036]);
authenticating, by the computer system, the user for processing the transaction based on the authentication data associated with the second (application of ) mobile device (see Fig. 3, Authentication Platform (311), User Credentials (310): paragraph [0038-0039]); and
in response to authenticating the user based on the authentication data, processing, by the computer system, the transaction for the user (see Fig.7: -> Fig. 8, Thank you for your purchase (800): paragraph [0043, 0063-0064]; where transaction of purchasing Sweater purchase processed and completed based on automated authentication of the user credential)
As per claim 10, Venkatakrishnan et al. teach the method as described in the claim 9 as described above. Venkatakrishnan et al. further teach the method, wherein
the programming instructions comprise an application programming interface (API) call to an operating system of the user device (see paragraph [0075]; where plurality applications such as payment applications interfaced with application program interface over networks).
As per claim 11, Venkatakrishnan et al. teach the method as described in the claim 9 as described above. Venkatakrishnan et al. further teach the method, wherein the programming instructions, when executed by the user device, further cause the user device to
detect a presence of the second mobile application on the user device prior to retrieving the authentication session token from the user device (see Fig. 6 and Fig. 5: paragraph [0061]; where Payment application Payment Service Provider detected and entered user credential and authentication token such as refresh token and access token is generated according to its expiry or not).
As per claim 12, Venkatakrishnan et al. teach the method as described in the claim 9 as described above. Venkatakrishnan et al. further teach the method, wherein
the second mobile application is a non-web browser application (see paragraph [0075]; where second mobile application payment application of payment service provider).
As per claim 13, Venkatakrishnan et al. teach the method as described in the claim 9 as described above. Venkatakrishnan et al. further teach the method further comprising:
presenting, by the computer system and on the user device, a customized user interface after the authenticating the user (see Fig. 8; where customized interface with user order and address where user order items will be displayed after authentication via payment application by entering user credentials).
As per claim 14, Venkatakrishnan et al. teach the method as described in the claim 9 as described above. Venkatakrishnan et al. further teach the method comprising:
causing the first mobile application to store an authentication session token on the user device, wherein the authentication session token is usable for authenticating the user by the computer system in a subsequent interaction between the user and the first mobile
application (see Fig. 5 and 6: paragraph [0037, 0061]); where first mobile application stores the user credential on checking item 508 during login and refresh token is used if it is not expired or valid).
As per claim 15, Venkatakrishnan et al. teach the method as described in the claim 14 as described above. Venkatakrishnan et al. further teach the method comprising:
receiving, from the first mobile application of the user device, a second request for processing a second transaction; detecting a presence of the authentication session token on the user device; and authenticating the user of the device for processing the second transaction based on the authentication session token (see paragraph [0037 and 0061]: where authentication credential that is remembered by previously clicking item 508 in Fig for the authentication subsequent second transaction and refresh token is also used if refresh token has not expired).
As per claim 16, Venkatakrishnan et al. teach a non-transitory machine-readable medium having stored thereon machine-readable instructions executable by a machine (see Fig. 12, Processing (1204): paragraph [0082-0083]) to perform operations comprising:
receiving a request for processing a transaction from a first mobile application of a device (see Fig. 1, Sweater ($15.00 x 2 = $30.00) -> Checkout with Payment Service Provider (114); Fig. 2, Step 202; where user mobile with installed mobile application of purchasing Sweater request checkout of item to make a payment for the purchase);
transmitting programming code to the first mobile application of the device executed (see paragraph [0065]); where programming code/instructions for implementing mobile application) wherein the programming code, when executed by the device, causes the device to (i) detect whether an authentication object associated with the first mobile application is stored on the device (see Fig. 5, Item selection (508); Fig. 6, Refresh Token (622): paragraph [0037]; where checkout operation include detection of user credential remembered or refresh token is valid or not expired);
(ii) in response to detecting that the authentication object is not stored on the device, retrieve authentication data from a data store of the device associated with a second mobile application of the device; authenticating the user for processing the transaction based on the authentication data (see Fig. 5 and 6, paragraph [0061]; where if authentication data is not stored or refresh token is expired, authentication platform redirect user to login page in Fig. 5); and
in response to authenticating the user, processing the transaction for the user (see Fig.7 -> Fig. 8, Thank you for your purchase (800): paragraph [0063-0064]; where transaction of purchasing Sweater purchase processed and completed based on automated authentication of the user credential).
17. As per claim 17, Venkatakrishnan et al. teach the non-transitory machine-readable medium as described in the claim 16 as described above. Venkatakrishnan et al. further teach
the non-transitory machine-readable medium
detecting whether the second mobile application has been installed on the device,
wherein the transmitting the programming code is responsive to detecting that the second mobile application has been installed on the device (see Fig. 5: paragraph [0061]; where payment service provider application is second application is detected and allows user to reenter credential if it is not remembered).
As per claim 18, Venkatakrishnan et al. teach the non-transitory machine-readable medium as described in the claim 16 as described above. Venkatakrishnan et al. further teach
the operations further comprise:
obtaining the authentication data from the device via the first mobile application (see Fig. 5).
As per claim 19, Venkatakrishnan et al. teach the non-transitory machine-readable medium as described in the claim 16 as described above. Venkatakrishnan et al. further teach
the operations e non-transitory machine-readable medium, wherein
the authentication data indicates a previous authentication of the user by a service provider server (see Fig. 5, Item selection (508): paragraph [0037]); where subsequent transaction remember and use previously entered credentials for authentication).
As per claim 20, Venkatakrishnan et al. teach the non-transitory machine-readable medium as described in the claim 16 as described above. Venkatakrishnan et al. further teach
the operations, wherein the operations further comprise:
generating the authentication object based on the authenticating the user for processing the transaction; and causing the first mobile application to store the authentication object on the device in association with the first mobile application, wherein the authentication object is usable for authenticating the user in a subsequent interaction between the user and the first mobile application (see Fig. 5, Item selection (508): paragraph [0037]; where previously entered credential is stored and remembered and used for subsequent transaction).
As per claim 21, Venkatakrishnan et al. teach the non-transitory machine-readable medium as described in the claim 20 as described above. Venkatakrishnan et al. further teach
the non-transitory machine-readable medium, wherein the operations further comprise:
receiving, from the first mobile application of the device, a second request for processing a second transaction; detecting a presence of the authentication object on the device; and
authenticating the user of the device for processing the second transaction based on the authentication object (see Fig. 5, Click here if you want to be remembered by the payment service provider (508); Fig. 6, Refresh Token: : paragraph [0037, 0062]; where previous authentication credential is remembered by the application and used for subsequent authentication for next purchase if refresh token is valid).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosures. The following are pertinent to current invention, though not relied upon:
Ho (U.S. Patent No. 10,885,541) teaches payments using rewards points.
Massey et al. (U.S. Patent No. 8,943,150) teach customizing mobile application based on user association with one or more entities.
Power et al. (U.S. Pub No. 2020/0028753) teach dynamically rendering a customized user interface on a mobile device.
Shah et al. (U.S. Patent No. 10,430,796) teach automated detecting of mobile payment applications.
Soppitt et al. (U.S. Pub No. 2018/0137505) teach customized content integration in mobile device application.
Varma (U.S. Pub No. 2020/0082459) teach persistent virtual shopping cart.
WEN (U.S. Pub No. 2015/0178726) teaches system and method for mobile payment authentication.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIJENDRA K SHRESTHA whose telephone number is (571)270-1374. The examiner can normally be reached on 8:00AM-5:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas can be reached on (571) 270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Respectfully submitted,
/BIJENDRA K SHRESTHA/Primary Examiner, Art Unit 3691 July 5, 2026
Prosecution Insights