DETAILED ACTION
Status of Application
This action is a Final Rejection. This action is in response to the amendment and response filed on July 7, 2026.
Claims 1, 8, 11, 14, and 20 have been amended.
Claims 1-20 are pending and rejected.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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.
Response to Arguments
Regarding step 2A, prong one of the rejection under 35 U.S.C. 101, Applicant argues that “the amended claims do not recite a method of organizing human activity.” Remarks at 12. Applicant asserts that “[t]he amended independent claims recite technical operations….” Id. at 11. However, but for the technical features, the claims recite certain methods of organizing human activity as explained in the rejection. Although the claims recite additional elements, they also recite a method of providing in-context information to a user. Therefore, the claims recite an abstract idea.
Regarding step 2A, prong two of the rejection, Applicant argues that the amended claims “provide a specific technical approach to coordinating communication between distributed systems (e.g., ‘an authentication system, a database, and one or more user accounts’) through a unified ‘integration system,’ and dynamically controlling the sensitivity of data retrieved from the database based on the type of authentication method completed.” Remarks at 14. Applicant asserts that “the claimed improvement is to the mechanism of inter-system coordination and tiered data access control, not to any underlying business process.” Id. at 14-15. In support of this argument, Applicant points to paragraphs in the Specification. Id. at 12-13. However, although the integration system can combine or connect multiple software systems, applications, and/or modules into a unified system, Applicant has not invented or improved the technology for combining or connecting systems, but is instead using these existing technological capabilities to implement the claimed abstract idea.
Regarding step 2B of the rejection, Applicant argues that the claims provide an “ordered combination [that] reflects the specific technical architecture described in the specification for coordinating authentication and data retrieval across distributed systems” and are not “well-understood, routine, or conventional activity.” Remarks at 15. However, when the independent claims are viewed as a whole, they are still using a programmed general purpose computing device as a tool to implement the claimed abstract idea. Additionally, the rejection does not allege that the claim limitations are well-understood, routine, or conventional. As such, the rejection has been maintained.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03)
Yes, with respect to claims 1-19, which recite a method and, therefore, are directed to the statutory class of process.
Yes, with respect to claim 20, which recites a system and, therefore, is directed to the statutory class of machine or manufacture.
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a))
The following claims identify the limitations that recite the abstract idea in regular text and that recite additional elements in bold:
1. A method for providing in-context information, the method comprising:
monitoring, by an integration system executing on at least one processor, a user interface for a trigger event, wherein the trigger event comprises initiation of a web browser;
automatically generating, by the integration system and in response to detecting the trigger event, a request for the in-context information comprising user-specific data;
establishing a communication link, by the integration system via at least one of an application programming interface (API), a browser plug-in, or an embedded browser, between an authentication system, a database, and one or more user accounts;
transmitting, by the integration system to the authentication system via the communication link, a verification request;
receiving, by the integration system, a user verification level from the authentication system in response to the verification request, wherein the user verification level is determined by the authentication system using one or more authentication methods;
upon receiving the user verification level, requesting, by the integration system, the user-specific data from the database, the user-specific data associated with the one or more user accounts and corresponding to the received user verification level; and
causing, by the integration system the user interface to display the in-context information, the displayed in-context information comprising the user-specific data determined based on the received user verification level.
2. The method of claim 1, wherein the integration system combines the authentication system, the database, and one or more user accounts into a unified system via an application programming interface (API), a web browser plug-in, or an embedded browser.
3. The method of claim 1, wherein the user-specific data includes any of an account balance, an estimated payoff time, an interest rate associated with an account, an estimated amount of interest to be paid based on a purchase, or an estimated amount of interest to be paid based on the account balance.
4. The method of claim 1, wherein the user verification level is determined based on the one or more authentication methods used.
5. The method of claim 1, wherein the user-specific data associated with the one or more user accounts includes one or more of prior user purchases from a retailer, prior user returns from the retailer, or other user transactions with the retailer.
6. The method of claim 5, further comprising:
providing one or more recommendations for the user based on the user-specific data associated with the one or more user accounts; and
causing to display the one or more recommendations via the user interface.
7. The method of claim 6, wherein the one or more recommendations include using a particular bank card or lifestyle suggestions.
8. The method of claim 1, wherein the causing the user interface to display the in-context information includes modifying the user interface using JavaScript to generate an embedded context window to display the in-context information on a webpage.
9. The method of claim 1, further comprising:
embedding a user-specific information window using JavaScript, the user-specific information window populated with at least the user-specific data; and
causing to display the user-specific data via the user-specific information window.
10. The method of claim 9, further comprising:
modifying one or more aspects of the user-specific information window via the user interface.
11. A method for providing in-context information, the method comprising:
receiving, by an integration system executing on at least one processor and via a user interface, customization settings from a user, the customization settings defining, for each of one or more user verification levels, a corresponding category of user-specific data to display and a display format for user-specific data;
monitoring, by the integration system, the user interface for a trigger event, wherein the trigger event comprises initiation of a web browser;
automatically generating, by the integration system and in response to detecting the trigger event, a request for the in-context information comprising the user-specific data;
establishing a communication link, by the integration system, between an authentication system, a database, and one or more user accounts, the integration system configured to establish the communication link via a browser plug-in;
transmitting, by the integration system to the authentication system via the communication link, a verification request;
receiving, by the integration system, a user verification level from the authentication system in response to the verification request, wherein the user verification level is determined by the authentication system using one or more authentication methods;
upon receiving the user verification level, requesting, by the integration system, the user-specific data from the database, the user-specific data associated with the one or more user accounts and corresponding to the received user verification level; and
causing, by the integration system the user interface to display the in-context information according to the customization settings from the user, the displayed in-context information comprising the user-specific data determined based on the received user verification level.
12. The method of claim 11, wherein the in-context information includes any of an account balance, an estimated payoff time, an interest rate associated with an account, an estimated amount of interest to be paid based on a purchase, or an estimated amount of interest to be paid based on the account balance.
13. The method of claim 11, wherein the integration system combines the authentication system, the database, and one or more user accounts into a unified system via an API, a web browser plug-in, or an embedded browser.
14. The method of claim 11, wherein the trigger event further comprises one or more of a selection made by a user via an input device or a focus area selected by the user via the input device.
15. The method of claim 11, wherein the user verification level is determined based on the one or more authentication methods used.
16. The method of claim 11, wherein the user-specific data associated with the one or more user accounts includes one or more of prior user purchases from a retailer, prior user returns from the retailer, or other user transactions with the retailer.
17. The method of claim 16, further comprising:
providing one or more recommendations for a user based on the user-specific data associated with the one or more user accounts; and
causing to display the one or more recommendations via the user interface.
18. The method of claim 17, wherein the one or more recommendations include using a particular bank card or lifestyle suggestions.
19. The method of claim 11, further comprising:
generating a user-specific information window, the user-specific information window comprising at least user-specific data; and
causing to display the user-specific data via the user-specific information window.
20. A system, the system comprising:
at least one memory storing instructions; and
at least one processor executing the instructions to implement an integration system, the integration system performing operations for providing in-context information, the operations including:
monitoring a user interface for a trigger event, wherein the trigger event is any of a selection made by a user, a focus area selected by a user, or initiation of a web browser;
automatically generating, in response to detecting the trigger event, a request for the in-context information;
establishing a communication link via an API, between the integration system, an authentication system, a database, and one or more user accounts;
transmitting a verification request to the authentication system via the communication link;
receiving a user verification level or receiving an unsuccessful verification from the authentication system in response to the verification request, wherein the user verification level is determined by the authentication system using one or more authentication methods;
upon receiving the user verification level, requesting data, from the database, associated with the one or more user accounts, and corresponding to the received user verification level; or
upon receiving the unsuccessful verification, terminating the communication link to the one or more user accounts and requesting data that does not require user verification; and
causing the user interface to display the data associated with the one or more user accounts based on the received user verification level, or
causing the user interface to display the data that does not require user verification.
Yes. But for the recited additional elements as shown above in bold, the remaining limitations of the claims recite certain methods of organizing human activity. The claims are directed to providing information to a user that will help the user understand the effect of a purchase. This type of method of organizing human activity is a fundamental economic practice because it includes mitigating risk by determining a verification level based on the method of authentication and a commercial interaction such as sales activities or behaviors and business relations. Thus, the claims recite an abstract idea.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d))
No. The claims as a whole merely use a computer as a tool to perform the abstract idea. The computing components (i.e., additional elements that are in bold above) are recited at a high level of generality and are merely invoked as a tool to implement the steps. For example, only a programmed general purpose computing device is needed to implement the claimed process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Furthermore, the abstract idea is merely being linked to a particular technological environment, i.e., an online shopping environment. Employing known technology within an online shopping environment to execute the abstract idea, even when limiting the use of the abstract idea to this environment, does not integrate the exception into a practical application or add significantly more. Additionally, there is no improvement to the functioning of a computer or technology. Therefore, the abstract idea is not integrated into a practical application.
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05)
No. As discussed with respect to Step 2A, Prong 2, the additional elements in the claims, both individually and in combination, amount to no more than tools to perform the abstract idea. Merely performing the abstract idea using a computer cannot provide an inventive concept. Therefore, the claims do not provide an inventive concept.
As such, the claims are not patent eligible.
Relevant Prior Art
The following reference is relevant to Applicant’s invention:
Olliphant et al., U.S. Patent Number 11,580,597 B2. This reference teaches a method for providing user-specific dynamic content for facilitating online transactions.
Hodges, U.S. Patent Application Publication Number 2012/0095905 A1. See Figure 1, item 108 and associated text.
Email Communications
Per MPEP 502.03, Applicant may authorize email communications by filing Form PTO/SB/439, available at https://www.uspto.gov/sites/default/files/documents/sb0439.pdf, via the USPTO patent electronic filing system.
Conclusion
THIS ACTION IS MADE FINAL. 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH H ROSEN whose telephone number is (571) 270-1850 and email address is elizabeth.rosen@uspto.gov. The examiner can normally be reached Monday - Friday, 10 AM ET - 7 PM ET.
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, Michael Anderson, can be reached at 571-270-0508. 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.
/ELIZABETH H ROSEN/Primary Examiner, 3693
Prosecution Insights