DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Jun. 5, 2026, and is made Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Interviews are “indispensable to advance the prosecution of a patent application.” MPEP § 713. Accordingly, the following Examiner’s guidance and suggested workflow maximizes this benefit to Applicant by: (1) avoiding back and forth telephone calls for scheduling, (2) permitting Examiner out-of-office notifications to the Applicant when emailing the agenda, and (3) permitting real-time document collaboration and screen sharing.
Interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. If an interview is needed more quickly than permitted by the AIR scheduling tool, note this in the AIR remarks for consideration. The Examiner routinely considers such urgent requests when practicable.
An agenda submitted when filing the AIR is strongly encouraged, because Examiners use agendas when determining whether to grant an interview. The AIR has character limits, so send the agenda contemporaneously to James.Miller1@uspto.gov and reference the AIR.
After-Final Interviews Requests are granted only at the Examiner’s discretion and only if disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. An advance agenda explaining how the interview advances prosecution—e.g., through targeted arguments, identified Examiner error, or proposed claim amendments—is strongly suggested.
For GRANTED requests, expect an email within two (2) business days confirming a date/time slot and collaboration tool access instructions. For DENIED requests, the record will include an explanation for the denial.
The examiner is generally available for interviews, Monday through Friday, 10:00 a.m. to 4:00 p.m. ET.
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 .
Claim Status
The status of claims is as follows:
Claims 1–20 remain pending and examined Claims 1, 8, and 15 in independent form.
Claims 1, 6, 8, 9, 10, 11, 12, 13, 15, 15, and 19 are presently amended.
No Claims are presently cancelled or added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Dec. 29, 2016, [“Applicant’s Specification”] and accepted for examination.
Response to Arguments
Claim Interpretation
Applicant argues that (1) the amended claims do not contain any “such that” clause and requests removal of the claim interpretation set forth in the Non-Final Office Action mailed Feb. 5, 2026, [Non-Final Office Action] and (2) the interpretation of “securely compartmentalized” reads the modifier “securely” out of the claims. Applicant’s Reply at 9. Applicant’s arguments are persuasive. The prior interpretations are withdrawn. The “such that” clause is withdrawn as moot because Applicant cancelled that language by amendment, rendering the prior interpretation moot. The modifier “securely” is given weight.
35 U.S.C. § 101 Argument
Applicant identifies the portions of Representative Claim 8 [“Rep. Claim 8”] that recite a fundamental economic practice and commercial interaction under the organizing human activity exception. Applicant further identifies the additional elements of Rep. Claim 8 and argues the additional elements render the amended claims eligible. Applicant’s Reply at 12–13.
Although Applicant frames the argument as a Step 2B analysis (Applicant’s Reply at 14), the arguments are more properly addressed and are persuasive at Step 2A, Prong Two (“practical application”) for the reasons discussed below. Because eligibility is resolved at Step 2A, Prong Two, Examiner does not reach Applicant’s case law analogies or Step 2B. The rejection of Claims 1–20 under § 101, as set forth in the Non-Final Office Action, is WITHDRAWN. MPEP § 2106.06(e).
35 U.S.C. § 103 Argument
Applicant’s arguments with respect to Claims 1–20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Examiner’s Statement of Eligibility Under 35 U.S.C. § 101
Examiner adopts Applicant’s characterization of both the abstract idea exception and additional elements. Applicant’s Reply at 12–13. Thus, Independent Claims 1, 8, and 15 recite a fundamental economic practice and commercial interaction under the organizing human activity exception. MPEP §§ 2106.04(a)(2)(II)(A), (B). The additional elements, individually and in combination, integrate the exception into a practical application because they impose meaningful limitations beyond generally linking the use of the judicial exception to a particular technological environment. MPEP § 2106.05(e).
Rep. Claim 8 recites the following meaningful limitations: (1) a financial plugin is launched within a framework of the native mobile retail application and does not launch an additional application on the mobile device; (2) the plugin interacts with a financial server distinct from the retail application server; (3) the plugin does not share the financial information with either the native mobile retail application or the retail application server—the financial information is “securely compartmentalized” from the native mobile retail application and the retail application server; (4) a menu item of the plugin is added to a menu of the native mobile retail application displayed on the display of the mobile device; (5) the financial information is presented within the frame of the native mobile retail application; and (6) the financial information is not presented as a pop-up, a new tab, or a new window, to overcome a real estate limitation of said display of said mobile device. Claims 1 and 15 recite similar limitations.
Considered individually, each limitation specifies a particular constraint: (a) a constraint on how the plugin is launched (“within a framework of the native mobile retail application and does not launch an additional application on the mobile device”); (b) the compartmentalization constraint on the financial information after receipt (“the financial information received at said financial plugin is … securely compartmentalized from said native mobile retail application and said retail application server”); (c) the data-sharing constraint on the plugin (“said financial plugin does not share said financial information with either said native mobile retail application or said retail application server”); (d) the menu item integration constraint (“add a menu item of said financial plugin to a menu of said native mobile retail application displayed on said display”); (e) where the financial information is presented on the display and what forms may not take constraint (“present said financial information … on said display of said mobile device within said frame of said native mobile retail application” and “wherein said financial information is not presented as a pop-up, a new tab, or a new window, to overcome a real estate limitation of said display of said mobile device”).
Considered in combination, these limitations do not merely associate the exception with a mobile device environment. MPEP § 2106.05(h). In combination they describe a particular arrangement, (1)–(6) supra, that limits with particularity how the abstract idea is implemented to solve a challenge particular to the internet and computers. The specification confirms the combination is not conventional. Spec. ¶ 15 (“Importantly, the embodiments of the present invention, as will be described below, provide an approach for seamless integration of financial information within a mobile retail application framework which differs significantly from the conventional processes used by native applications. In conventional approaches, the application has access to all of the data being ported through it.”).
Although some of the additional elements, including “does not share,” “securely compartmentalized,” and “does not launch an additional application,” are stated in functional terms, MPEP § 2106.05(e) focuses on whether the additional elements impose meaningful limits on the recited exception, not on whether the claim recites specific technical mechanisms. That inquiry is met by the current record for the reasons supra. Giving Applicant the benefit of any reasonable doubt, Examiner finds that the additional elements, as a whole and in combination, reflect a specific mobile device architecture rather than merely applying the abstract idea with a computer. Accordingly, the additional elements of Claims 1, 8, and 15 integrate the exception into a practical application. MPEP § 2106.05(e).
Claim Interpretation
Under the broadest reasonable interpretation, the following claim terms are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. MPEP § 2111.
presentation methodology means “display”. Spec. ¶ 79.
framework, as recited by the claims, means “a native mobile retail application having a financial plugin.” E.g., Claims 1, 8, 15.
data window means “access to the specified data type”. Spec. ¶ 29 (“the plugin on the application would provide a window into the information from the credit account.”).
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, 8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ayyagari et al. (U.S. Pat. Pub. No. 2018/0047009) (Filed: Aug. 12, 2016) [“Ayyagari”] in view of Collison et al. (U.S. Pat. Pub. No. 2013/0117185) [“Collison”], in view of Purves et al. (U.S. Pat. Pub. No. 2013/0346302) [“Purves”] and further in view of NPL: Business Wire, “Visa Checkout Introduces New Interactive Button for Faster Mobile Commerce” (March 11, 2016) [“NPL Visa”]
Regarding Claim 1, Ayyagari discloses
A method for seamless integration of financial information within a mobile retail application framework operating on said mobile device, the method comprising:
(See at least Fig. 1, disclosing “Retail App 131” “Event Plug-in 132” and “computer 130,” which may be a smartphone. ¶ 15. The “framework” is defined by the subsequent claim language as “a native retail application [Retail App 131] and a financial plugin [Event Plug-in 132].” The integration is “seemless” because “Event Plug-in 132 requests mobile OS 133 to monitor the operations of computer 130 for various events significant to the ability to complete a desired e-commerce transaction such as a mobile payment in a timely manner … [and] monitor[s] for events.” ¶ 18. The italicized limitations are interpreted as intended use. Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).)
launching, on a mobile device, a mobile retail application, said mobile retail application operating on said mobile device and,
(See at least Fig. 1 and associated text ¶ 17, “Retail app 131 using event plug-in 132 initiates and provides the ability to execute e-commerce transactions such as mobile payments.” “Event plug-in 132 is a software extension to retail app 131. In various embodiments, an event plug-in performing the operations and function of event plug-in 132 is included in other mobile applications (e.g., in mobile banking apps, mobile wallet apps, net banking apps, and the like) that provide the ability to perform mobile financial transactions or mobile payments).” ¶ 18; see also ¶ 26.)
interacting with a retail application server [merchant website] and obtaining retail information therefrom, said retail application server distinct from said mobile device; and
(See at least Fig. 1 and associated text ¶ 17, “Retail app 131 may provide access to a merchant website or other on-line shopping website, allowing browsing and the selection of products for purchase.” See also, ¶ 21. The computer 130 accesses network resources through network 110. ¶ 14. A PHOSITA would have understood that the remotely accessed merchant website is provided by a merchant server distinct from the mobile computer 130. The retail application 131 and computer 130 are distinct. Fig. 1. )
providing a visual display of said mobile retail application in a frame on a display of said mobile device;
(See at least ¶ 17, “Retail app 131 is an application or program on computer 130. In various embodiments, retail app 131 is a mobile application or "app" for connecting computer 130 to a retail internet site, a merchant website, a company website, or the like for on-line shopping.” ¶ 20, “user interface 135 is a graphical user interface (GUI) or a web user interface (WUI) and can display text, documents, web browser windows, user options, application interfaces, and instructions for operation, and include the information (such as graphic, text, and sound) that a program presents to a user and the control sequences the user employs to control the program.” User interface 135 is a component of computer 130 (Fig. 1). ¶ 15, “Computer 130 may be a smart phone, a tablet, a wearable computer (e.g., a smart watch),” i.e., a mobile device. Under BRI, the disclosed GUI or WUI region displaying the retail application is “a frame”.
receiving, at said mobile device, a request for said financial information; launching, on the mobile device and within a framework of said mobile retail application, a financial plugin, [event plug-in 132]
(See at least ¶ 17, “retail app 131 is any mobile application or app configured with event plug-in 132 used for mobile payments, e-commerce transactions, mobile or online banking.” “Event plug-in 132 is a software extension to retail app 131 … an event plug-in performing the operations and function of event plug-in 132 is included in other mobile applications (e.g., in mobile banking apps, mobile wallet apps, net banking apps, and the like).” ¶ 18. A framework is a native mobile retail application having a financial plugin.)
said financial plugin configured to interact with a financial server to obtain said financial information,
(See at least ¶ 17, “retail app 131 is any mobile application or app configured with event plug-in 132 used for mobile payments, e-commerce transactions, mobile or online banking. … Retail app 131 may use payment gateway 140 to access server 160 for authorization and the completion of mobile payments or online financial transactions requested by a user on UI 135. Payment gateway 140 may be invoked directly by retail app 131 using event plug-in 132 or retail app 131 using event plug-in 132 may invoke another app on computer 130 (e.g., a smart phone or a laptop computer) which can communicate with payment gateway 140.” ¶ 23, “server 160 is a server used in a financial institution or a financial services system such as a bank or a credit card corporation. Server 160 sends and receives data from computer 130 and payment gateway 140 such as requests for additional transaction time generated by event plug-in 132 on computer 130 and requests for mobile payment authorization in support of a product or service purchase generated by a user.”). ¶ 32, “event plug-in 132 receives a user input initiating an online banking request (e.g., a transfer of funds). In an embodiment, retail app 131 receives the authorization request to process an e-commerce transaction (e.g., a mobile payment or online banking request) and notifies event plug-in 132 of the request.” Under BRI, a person of ordinary skill would understand that the disclosed plugin used for online banking, communicating with a financial institution server, and facilitating the transfer of fund to be configured and capable of obtaining financial information needed to perform the online banking transaction.)
[Collision]
wherein said launching of said financial plugin does not launch an additional application on said mobile device;
(A framework is a native mobile retail application having a financial plugin. Fig. 1 identifies an “event plug-in 132,” which is part of “retail app 131,” which is a framework. Another application is not launched because the “Event plug-in 132 is a software extension to retail app 131 … an event plug-in performing the operations and function of event plug-in 132 is included in other mobile applications (e.g., in mobile banking apps, mobile wallet apps, net banking apps, and the like).” ¶ 18.)
[Purves]
receiving, at the financial plugin and from the financial server, said financial information comprising: financial data [mobile or online banking information] and account management information [transfer of funds],
(The retail app 131 used, for example, in “mobile or online banking,” ¶¶ 10, 11, 12, 17, 18, and “a server 160 … used in … a credit card corporation,” ¶ 23, reasonably teaches or suggests “receiving at the financial plugin on said mobile device and from the financial server, the financial information comprising financial data and account management information.” A PHOSITA would not access online banking, for example, without being able to view the requested account information and “transfer funds”. ¶¶ 11, 17, 18, 21, 23, 32.)
[Collision]
presenting said financial information in a user readable format on said display of said mobile device within said frame of said mobile retail application,
(See at least ¶ 17, “retail app 131 is any mobile application or app configured with event plug-in 132 used for mobile payments, e-commerce transactions, mobile or online banking … In an embodiment, retail app 131 is a mobile banking app, a mobile wallet app, a direct payment app, or the like for mobile banking and/or mobile financial transactions.” ¶ 32, “event plug-in 132 receives a user input initiating an online banking request (e.g., a transfer of funds). In an embodiment, retail app 131 receives the authorization request to process an e-commerce transaction (e.g., a mobile payment or online banking request) and notifies event plug-in 132 of the request.” Information is presented through a graphical user interface. ¶ 20, “user interface 135 is a graphical user interface (GUI) or a web user interface (WUI) and can display text, documents, web browser windows, user options, application interfaces, and instructions for operation, and include the information (such as graphic, text, and sound) that a program presents to a user and the control sequences the user employs to control the program. User interface 135 enables computer 130 to receive a user input such as a password, security code, or the like to initiate and process a mobile payment request to server 160.” Fig. 1 discloses that user interface 135 is part of computer 130. ¶ 53, “Display 418 provides a mechanism to display data to a user and may be, for example, a computer monitor. Display 418 can also function as a touchscreen, such as a display of a tablet computer.” Under BRI, the GUI or WUI region displaying the retail application is the claimed “frame.” A PHOSITA would understand that the mobile or banking application that receives a request to conduct an online banking transaction such as a transfer of funds, and displays application interfaces through interface 135, presents the requested financial information in a user-readable format within the displayed interface of retail app 131.)
[NPL Visa]
Ayyagari discloses a financial plugin. Ayyagari does not explicitly disclose that the financial plugin does not share financial information with either said mobile retail application or said retail application server. Ayyagari discloses receiving, at the financial plugin from the financial server, the financial information. Ayyagari does not disclose the financial information received at the financial plugin is securely compartmentalized from said mobile retail application and the retail application server. Therefore, Ayyagari does not disclose but Collison discloses:
wherein said financial plugin does not share said financial information with either said mobile retail application or said retail application server,
(See at least ¶ 7, “With Stripe.js, merchants retain full control of their customers' payment flows but their servers are never exposed to sensitive payment information.” ¶ 11, “The Customer's payment information (220) is sent from the Customer's browser (210) to Stripe (300), never touching the Merchant's Servers (120) … The client-side application does not send the payment information (220) to the server-side application.” ¶ 42, “The input fields representing sensitive payment data (220) do not have a "name" attribute. This prevents them from hitting the Merchant's Servers (120) when the Payment Form (110) is submitted.” ¶ 72, “After the Single-use Token (350) is added to the Payment Form (110), it posts the form data, without Payment Information (220), to the Merchant's Servers (120).”)
wherein said financial information received at said financial plugin is securely compartmentalized from said mobile retail application and said retail application server; and
(See at least ¶ 7, “With Stripe.js, merchants retain full control of their customers' payment flows but their servers are never exposed to sensitive payment information.” ¶ 11, “The Customer's payment information (220) is sent from the Customer's browser (210) to Stripe (300), never touching the Merchant's Servers (120) … The client-side application does not send the payment information (220) to the server-side application.” ¶ 42, “The input fields representing sensitive payment data (220) do not have a "name" attribute. This prevents them from hitting the Merchant's Servers (120) when the Payment Form (110) is submitted.” ¶ 72, “After the Single-use Token (350) is added to the Payment Form (110), it posts the form data, without Payment Information (220), to the Merchant's Servers (120).” Under BRI in view of Applicant’s Specification, Examiner interprets “wherein said financial information received at said financial plugin is securely compartmentalized from said mobile retail application” as “the native retail application is not provided access to the financial information”. The native retail application resides on the user’s mobile device. ¶¶ 36, 38. The financial plugin [“Stripe.js”] resides on the mobile device and within the native retail application. ¶¶ 7, 8. “The Customer's payment information (220) is sent from the Customer's browser (210) to Stripe (300), never touching the Merchant's Servers (120). In this manner, the client-side application electronically sends payment information retrieved from the customer's electronic device to the payment processor. The client-side application does not send the payment information (220) to the server-side [retail] application.” ¶ 11; see also ¶¶ 82, 85, 86 (redacts PAN and CVC), 279. “However, in an alternative embodiment, the client-side application does not run in a web browser. Instead, the merchant's client-side application runs in a native mobile application (for example, in an Android™ or iPhone® app).” ¶ 142.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined wherein said financial plugin does not share said financial information with either said mobile retail application or said retail application server and received at said financial plugin is securely compartmentalized from said mobile retail application and said retail application server, as explained in Collison, to the known invention of Ayyagari, in the same field of invention, with the motivation to comply with industry data protection standards. Collison, ¶ 6.
Ayyagari does not disclose but Purves discloses:
adding a menu item of said financial plugin to a menu of said mobile retail application displayed on said display;
(See at least ¶ 104, “Within implementations, integration of an electronic wallet, a desktop application, a plug-in to existing applications, a standalone mobile application, a web based application, a smart prepaid card, and/or the like in capturing payment transaction related objects.” ¶ 105, “Similarly, although mobile wallet user interface elements are depicted, alternative and/or complementary user interfaces are also contemplated including: desktop applications, plug-ins to existing applications, stand alone mobile applications, web based applications (e.g., applications with web objects/frames, HTML 5 applications/wrappers, web pages, etc.), and other interfaces are contemplated.” ¶ 106, “FIG. lA provides a block diagram illustrating BillPay widget injection into third party sites within embodiments of the Bill-Pay … by displaying a Bill-Pay button 140 embedded in the webpage.” ¶ 107, “a user may access his banking site 108b, and click on the Bill-Pay button 140 and directly pay for an outstanding balance. … and click on the Bill-Pay button
140 to engage in bill payment.” ¶ 109, “The user may pay the bill via various portals. For example, the user may log into a third party site, such as an online banking site 108, wherein the banking site may allow the user to view a bank account 115, make a transfer
116, and/or pay the bill with a Bill-Pay widget 117 within the online banking site 108.” ¶ 116, “the widget package may comprise a java widget toolkit, such as but not limited to SWT, JavaFX, and/or the like. In one implementation, the requesting entities 210a-c may incorporate the received widget into its webpage, and present a user interface embedded with the Bill-Pay widget 272a-c to the user 202. For example, the user may see a "Pay with Visa Pay" option button(e.g., 140 in FIG. 1A) on a banking site, email, biller site, and/or the like.” See also, Figs. 1A, 1B, 2A, 5A. Under BRI, the displayed, selectable Bill-Pay or Visa Pay option embedded among the host application’s functions is a menu item of the financial plugin.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined Purves’s Bill-Pay option into the menu or user interface of Ayyagari’s retail app 131 to provide a predictable, user selectable control for initiating the financial functionality of event plugin 132. Purves teaches embedding its financial widget in a host banking or biller interface so the user can select the displayed Bill-Pay option and directly perform the financial transaction. Purves, ¶¶ 106–109, 116.
Ayyagari does not disclose but NPL Visa reasonably suggests:
wherein said financial information is not presented as a pop-up, a new tab, or a new window, to address a real estate limitation of said display of said mobile device.
(See at least p. 1, “The dynamic, new interactive button brings an engaging new way to pay with Visa Checkout, especially on mobile devices with smaller screens. … In 2014, Visa first introduced the Visa Checkout lightbox, which lets consumers pay online, on any device, without being redirected from the merchant's site or app. The new interactive button streamlines the payment experience even further. Now, instead of a lightbox, a consumer sees a picture of her card on the Visa Checkout button, swipes it to the right, and simply enters her password inside the button itself to authenticate.” NPL Visa explicitly discloses presenting financial information inside an existing interactive button, using the new interactive button instead of a lightbox, avoiding redirection from the merchant site or app and employing this presentation on mobile devices with smaller screens. Presenting information inside the button instead of through the prior art lightbox or redirected representation reasonably suggests that the information is presented within the existing merchant application interface instead of through a separate pop-up, new tab, or new window. The explicit identification of mobile devices with smaller screens suggests that NPL Visa addresses the limited display real estate of the mobile device.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the financial information display of Ayyagari, as modified by Collison and Purves, to use the button of NPL Visa. Ayyagari teaches retail app 131 configured with event plug-in 132 for mobile payments, e-commerce transactions, and mobile or online banking. Ayyagari, ¶¶ 17–18. Collison teaches securely integrating Stripe.js into a merchant’s payment form while sending sensitive payment information directly to the payment processor and preventing the information from reaching the merchant’s server-side application. Collison, ¶¶ 7–8, 11, 42, and 72. A person having ordinary skill in the art would have been motivated to employ Collison’s tokenization and server-isolation technique in Ayyagari’s mobile-payment application to reduce exposure of sensitive payment information and comply with payment-data security requirements. Collison, ¶¶ 5–8.
It would have been further obvious to provide a displayed, selectable menu item or option for accessing that integrated financial functionality, as taught by Purves. Purves teaches embedding a Bill-Pay widget in a host application or site “by displaying a Bill-Pay button 140 embedded in the webpage.” Purves, ¶ 106. Purves further teaches permitting the user to “click on the Bill-Pay button 140 and directly pay for an outstanding balance,” ¶ 107, and displaying a “‘Pay with Visa Pay’ option button” in a host banking or biller interface, ¶ 116. Providing Purves’s selectable financial option in the menu or user interface of Ayyagari’s retail application would have predictably provided the user with a visible and convenient control for invoking the integrated financial functionality.
It would have been further obvious to implement Purves’s selectable financial button using the improved interactive-button presentation taught by the Visa Checkout reference. That reference expressly teaches replacing the prior Visa Checkout lightbox with an interactive button in which the consumer views a picture of her card and enters her password “inside the button itself.” NPL Visa, p. 1. The reference expressly identifies the benefits of streamlining the payment experience, avoiding redirection from the merchant’s site or application, and improving usability “especially on mobile devices with smaller screens.” Id.
Applying NPL Visa’s known in-button presentation technique to Purves’s embedded Bill-Pay option in the Ayyagari-Collison mobile retail application would have yielded the predictable result of allowing the user to access and view the integrated financial functionality within the existing retail-application interface, rather than through the prior lightbox or a separately redirected presentation. A person having ordinary skill in the art would have had a reasonable expectation of success because Purves already teaches an embedded financial widget and selectable payment button, while NPL Visa teaches an improved implementation of that same type of payment button on smartphones, tablets, and laptops. The proposed combination therefore represents: (1) combining prior-art elements according to known methods to yield predictable results; (2) using a known technique to improve similar devices and methods in the same way; and (3) applying a known technique to a known device ready for improvement to yield predictable results.
Regarding Claim 8, Ayyagari, discloses
A mobile device comprising: a memory storing instructions; and a processor, when executing the instructions, to:
(See at least ¶ 15, “smartphone.” Fig. 4 and associated text ¶ 49.)
The remaining limitations of Claim 8 the limitations are not substantively different than that presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, Purves, and NPL Visa for the same rationale presented in Claim 1 supra.
Regarding Claim 15, Ayyagari, discloses
A non-transitory computer-readable medium for storing instructions, the instructions comprising: one or more instructions which, when executed by one or more processors, cause one or more processors to:
(See at least Fig. 4 and associated text ¶ 49.)
The remaining limitations of Claim 15 the limitations are not substantively different than that presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, Purves, and NPL Visa for the same rationale presented in Claim 1 supra.
Claims 2, 3, 4, 6, 7, 9, 10, 11, 13, 14, 16, 17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ayyagari, Collison, Purves, and NPL Visa and further in view of Numata (U.S. Pat. Pub. No. 2006/0080231) [“Numata”]
Regarding Claim 2, Ayyagari, Collison, Purves, and NPL Visa disclose
The method of Claim 1 and the receiving of the financial information.
Ayyagari does not disclose but Numata discloses
wherein the receiving of the financial information comprises: receiving a credit history.
(This limitation is interpreted as printed matter because it is claimed for what it communicates to a human user and has no functional relationship with the claimed mobile device or financial server. Thus, it is not entitled to patentable weight. MPEP § 2111.05. However, should a reviewing court disagree, See at least Fig. 3 and associated text ¶ 35 disclosing “FIG. 3 shows an example of a customer's credit history information table in the credit sales system of the embodiment”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined receiving a credit history as explained in Numata, to the known invention of Ayyagari, in the same field of invention, with the motivation to “permit[ ] [the] purchase of a commodity or service beyond a credit limit and preventing a one-sided increase in the risk of the credit sales company.” Numata, ¶ 5.
Regarding Claim 3, Ayyagari, Collison, Purves, and NPL Visa disclose
The method of Claim 1 and the receiving of the financial information.
Ayyagari does not disclose but Numata discloses
wherein the receiving of the financial information comprises: receiving a purchase history.
(This limitation is interpreted as printed matter because it is claimed for what it communicates to a human user and has no functional relationship with the claimed mobile device or financial server. Thus, it is not entitled to patentable weight. MPEP § 2111.05. However, should a reviewing court disagree, See at least Abstract.)
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 2 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 3.
Regarding Claim 4, Ayyagari, Collison, Purves, and NPL Visa disclose
The method of Claim 1 and the receiving of the financial information.
Ayyagari does not disclose but Numata discloses
wherein the receiving of the financial information comprises: receiving a remaining credit available.
(This limitation is interpreted as printed matter because it is claimed for what it communicates to a human user and has no functional relationship with the claimed mobile device or financial server. Thus, it is not entitled to patentable weight. MPEP § 2111.05. However, should a reviewing court disagree, See at least Fig. 2, element 123, “credit limit”)
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 2 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 4.
Regarding Claim 6, Ayyagari, Collison, Purves, and NPL Visa disclose
The method of Claim 1 as discussed above.
Ayyagari further discloses
receiving at said financial plugin a purchase request from said mobile retail application,
(See at least ¶ 32, “In step 204, event plug-in 132 receives a mobile payment request. In various embodiments, event plug-in 132 receives an input from a user (e.g., a user input on UI 135 in computer 130 in FIG. 1) initiating a mobile payment authorization request for an online transaction or purchase. In an embodiment, event plug-in 132 receives a user input initiating an online banking request (e.g., a transfer of funds). In an embodiment, retail app 131 receives the authorization request to process an e-commerce transaction (e.g., a mobile payment or online banking request) and notifies event plug-in 132 of the request”)
[Numata]
sending, from said financial plugin to said financial server, a request […].
(See at least ¶ 34, “event plug-in 132 sends a request for additional input time (step 210) to server 160 using payment gateway 140.” ¶ 23, “server 160 is a server used in a financial institution or a financial services system such as a bank or a credit card corporation. Server 160 sends and receives data from computer 130 and payment gateway 140 such as requests for additional transaction time generated by event plug-in 132 on computer 130 and requests for mobile payment authorization in support of a product or service purchase generated by a user.”
Ayyagari does not disclose but Numata discloses:
said purchase request comprising an amount greater than a credit limit;
(See at last ¶ 2, “permits a credit sale whose purchase price is higher than the credit limit”; see also ¶ 5 (“permitting purchase of a commodity or service beyond a credit limit”)
sending […] a request to adjust said credit limit based on said purchase request.
(See at least ¶ 47, “when insufficient funds are informed, the member store's shop terminal 30 checks whether the credit balance increment rate has been calculated or not. If the rate has not been calculated, the member store's shop terminal 30 sends the request information for calculating credit balance increment including the customer ID and the commodity ID to the member store's original system 20.” ¶ 48, “After finishing the calculations, the credit balance increment rate, which is a result of the credit balance increment calculation, is sent back to the member store's shop terminal 30. Receiving the credit balance increment rate, the member store's shop terminal 30 re-sends the card-payment request information including the received credit balance increment rate to the credit system 10 of the credit sales company”. See also, ¶ 30.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined said purchase request comprising an amount greater than a credit limit and sending a request to adjust said credit limit based on said purchase request, as taught by Numata, to the known invention of Ayyagari, in the same field of invention, with the motivation to reduce failed or incomplete mobile payment transactions and avoid lost sales opportunities.
Regarding Claim 7, Ayyagari, Collison, Purves, NPL Visa, and Numata disclose
[t]he method of Claim 6 and adjusting said credit limit as discussed above.
Ayyagari does not disclose but Numata discloses
increasing the credit limit to allow a purchase of a product at an amount higher than a present credit limit.
(See at least Abstract, disclosing “If the purchase history information satisfies the credit balance increment condition, the member store calculates a credit balance increment rate on its own risk. The member store approves a payment by the credit card when the requested payment price is lower than the product of the credit balance by the credit balance increment rate even if the requested payment price is higher than the credit balance.”)
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 6 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 7.
Regarding Claims 9, 10, 11, 13, and 14, Ayyagari, Collison, Purves, and NPL Visa disclose
T]he mobile device of claim 8 as discussed above.
The remaining limitations of Claims 9, 10, 11, 13, and 14 are not substantively different than those presented in Claims 2, 3, 4, 6, and 7, respectively, and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, Purves, NPL Visa, and Numata for the same rationale presented in Claims 2, 3, 4, 6, and 7, respectively, supra.
Regarding Claims 16, 17, 19, and 20, Ayyagari, Collison, Purves, and NPL Visa disclose
The non-transitory computer-readable medium of claim 15 as discussed above.
The remaining limitations of Claims 16, 17, 19, and 20 are not substantively different than those presented in Claims 3, 4, 6, and 7, respectively, and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, Purves, NPL Visa, and Numata for the same rationale presented in Claims 3, 4, 6, and 7, respectively, supra.
Claims 5, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ayyagari, Collision, Purves, and NPL Visa, and further in view of Kalgi (U.S. Pat. Pub. No. 2013/0013499) [“Kalgi”]
Regarding Claim 5, Ayyagari, Collision, Purves, and NPL Visa disclose
[t]he method of Claim 1 and receiving of the financial information.
Ayyagari does not disclose but Kalgi discloses:
wherein the receiving of the financial information comprises: receiving a rewards information.
(See at least Fig. 15A, element 1518, and associated text ¶ 118, where in the left most figure, the remaining reward points are displayed. Fig. 2, upper left figure (same). It is axiomatic that to display these remaining credit balances the device of Kalgi must receive them.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined receiving a rewards information as explained in Kalgi, to the known invention of Ayyagari, in the same field of invention, with the motivation to review your online credit account to determine if there are any rewards associated with using the selected payment card. Kalgi, ¶ 58.
Regarding Claim 12, Ayyagari, Collision, Purves, and NPL Visa disclose
[t]he one or more devices of claim 8 as discussed above.
The remaining limitations of Claim 12 are not substantively different than those presented in Claim 5, and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, Purves, NPL Visa, and Kalgi for the same rationale presented in Claim 5, supra.
Regarding Claim 18, Ayyagari, Collision, Purves, and NPL Visa disclose
The non-transitory computer-readable medium of claim 15.
The remaining limitations of Claim 18 are not substantively different than those presented in Claim 5, and are therefore, rejected, mutatis mutandis, based on Ayyagari, Collison, Purves, NPL Visa, and Kalgi for the same rationale presented in Claim 18, supra.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/ Primary Examiner, Art Unit 3694
Prosecution Insights