DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
The following is a Final Office Action in response to communications received July 11, 2025. Claim(s) 2, 6, 9-10, 16 and 21 have been canceled. Claims 1, 13 and 17 have been amended. No new claims have been added. Therefore, claims 1, 3-5, 7-8, 11-15 and 17-20 are pending and addressed below.
Priority
Application 18308347 filed 04/27/2023 is a Continuation of 16687128, filed 11/18/2019, now U.S. Patent # 11669816 and having 1 RCE-type filing therein 16687128 is a Continuation of 13178431 , filed 07/07/2011, now abandoned and having 1 RCE-type filing therein 13178431 is a Continuation of PCT/EP2010/050158 , filed 01/08/2010 PCT/EP2010/050158 is a Continuation of 12416902 , filed 04/02/2009, now U.S. Patent #8688574 and having 1 RCE-type filing therein claims foreign priority to 0900223.9, filed 01/08/2009.
Applicant Name/Assignee: Visa Europe Limited
Inventor(s): Winfield-Chislett, Peter; Stringfellow, Westley; Lesuisse, Itamar; Casabonne, Veronica; Tamblyn, Raymond
Response to Arguments/Amendments
Claim Rejections - 35 USC § 101
Applicant's arguments filed 07/11/2025 have been fully considered but they are not persuasive.
In the remarks applicant recites the limitations arguing that under step 2A prong 2, the claimed limitations integrate any alleged abstract idea into a practical application. This is because the additional elements impose meaningful limits upon the judicial exception and provides improvement to technology. The improvement as described in the specification [¶ 0058-0059 and 0086] is the trusted intermediary system storing transactional data such that payments, authorizations and settlements are managed by the trusted intermediary, and the system can store audit data associated with merchant online activity and general system activity. The specification further discloses the user specifies payment method at POS and the user is authenticated by their online bank, so the intermediary system does not need to hold user specific data and the user logging onto online banking account services to authenticate them to the intermediary system there is no need for a second authentication process. Applicant argues that such functioning is an improvement of computer and computer networks by reducing storage allocations, reducing number of communications between user system and third party (by providing security eliminating additional authentication) and reducing network bandwidth because of the reduction of storage allocations and communications. Applicant’s argument is not persuasive. The claim limitations do not recite any processes directed toward storage allocations, rather the claim limitations recite a signin process on an online banking website where the signin page presented via an iframe loaded with contents by an intermediary system, the content corresponding to the URL of the signin page causing a browser of user system accessing a webpage of an online merchant to display the signin page on the display of the user system, where the intermediary system retrieves the URL of the signin page of the online banking website and sends the URL of the signin page to the iframe based on receiving from the user system a user selection of a bank identity code. This process does not impact the storage capacity or storage allocation of the intermediary system. Accordingly, applicant argument that the claimed limitations improve technology by reducing storage is not persuasive. With respect to the argument that the claimed limitations improve technology by reducing number of communications between user system and third party by providing security eliminating additional authentication. Eliminating additional authentication in a transaction process is not a process directed toward addressing issues with bandwidth load because a business process has reduced communications between parties. Rather the elimination of additional authentication is simply changing a business authentication process and any ancillary results in velocity of communication between parties in a transaction is simply an expected result when a business process does not require additional communication. Accordingly the authentication process claimed is not directed toward addressing a problem rooted in bandwidth load but rather the transaction process claimed. The rejection is maintained.
In the remarks applicant argues that the claimed limitations are directed toward a specific way to improve security of transmitted data related to the transaction. The user information are held by the issuing bank and trusted entity and not the merchant or third party. By keeping unnecessary data from the hands of merchants/third parties and only allowing release of sensitive information after authentication the limitations provide improvements to computer data security. The applicant argues that the use of an authentication token and an iframe for communicating sensitive information and thereby emptying the iframe prevents theft of such data. Therefore, the claimed process is an improvement over conventional data transmission using computer networks. Applicant’s argument is not persuasive. The use of Iframe in single signon environment is known in the art. As evidence the examiner provides NPL “A method to close previous iFrame session under SSO environment” by IBM as evidence that such use of iframe is available in the art. The current limitations do not attempt to improve iframe technology or apply iframe technology that changes the iframe normal functionality in any way. The limitations merely apply iframe technology in a transaction signon process in order to mitigate transaction risk. The rejection is maintained.
In the remarks applicant argues that the additional security measures claimed which include an authentication token and an iframe for communicating and the emptying of the iframe prevents theft, therefore improving computer security. Applicant’s argument is not persuasive. As evidenced in the NPL article above, the application of iframe under single signon through an authentication token is known application iframe and authentication tokens in the art . The emptying of the iframe after the transaction process does not further limit the authentication or signon process. It merely refreshes the iframe in order to set up the iframe for the next session. The limitations do not improve computer security but instead apply existing technology in its ordinary capacity to mitigate transaction risk. The rejection is maintained.
In the remarks applicant argues that under step 2B, the claimed subject matter as a combination recite unconventional technical process that integrates the secure use of iframe with the alleged abstract idea in order to provide authentication only once through their issuing bank instead of providing authentication with third parties. The combination of using iframe and self-expiring authentication tokens and releasing sensitive information only after user authenticated operates in an unconventional manner to ensure secure data transmission. The specific non-generic order of steps provide an unconventional manner that achieves technical and practical advantages over conventional systems and is therefore patent eligible. The examiner respectfully disagrees. As evidences in the NPL article above single signon which incorporate iframe and authentication tokens have been established in the art. Additional evidence includes WO 2008/111048 A2 by Schreiber et al – “inside a first web site to embed content from a second website. Modern browsers therefore provide an HTML element called an iframe, and/or similar elements, which may be embedded in a first web site and which may be supplied with a URL by way of an attribute called ISRC which will direct the browser to load a second web site from the URL into the iframe. Although the first web site may control the ISRC parameter of the iframe, the browser will usually prohibit any communication between code from the first web site and code from the second web site if they are downloaded from different domains “[0004 wherein the background indicates known in the art]…“ SSO functionality 3103 will send a GET or POST or other protocol to effect a sign-in prior to relaying the HTTP request 3111. SSO functionalty 3103 receives back a Cookie or authentication token from the Web site target of HTTP request 3111, which is then attached to HTTP request 3111. HTTP request 3111 with the attached cookie is then forwarded to third party service 1010 as HTTP request 3112. “ [0056-0057]; see also ¶ 0015; CA 2462212 C with priority date 2004/01/05 wherein the prior art teaches file transported in HTML tag type component for use of SSO process. , Further evidence includes US Pub No. 2008/0183902 A1 by Cooper et al; US Pub No. 2005/0154887 A1 by Birk et al (para 0033-0036, para 0053). Furthermore when considered as a combination the limitations as a combination recite high level functions that as a process are not directed toward technology or a unique technical process but instead to apply technology to perform single signon for transaction using existing technology without details of technical application or technical disclosure instead the functions are directed toward an expected outcome in a transaction process in order to mitigate risk. The rejection is maintained.
In the remarks applicant argues that the claimed details do not monopolize any judicial exception. Applicant is arguing a rejection not applied in the 101 rejection. The claimed limitations are rejected for lack of patent eligible subject matter not for preemption. The rejection is 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, 3-5, 7-8, 11-15 and 17-20 are rejected under 35 U.S.C. § 101 because the instant application is directed to non-patentable subject matter. Specifically, the claims are directed toward at least one judicial exception without reciting additional elements that amount to significantly more than the judicial exception. The rationale for this determination is in accordance with the guidelines of USPTO, applies to all statutory categories, and is explained in detail below.
In reference to claims 1, 3-5, 7-8 and 11-12:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 1 and the dependent claims. Such methods fall under the statutory category of "process." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. Method claim 1 recites a method to steps 1) receiving signin data, 2) activating a token 3) transmitting the token, an instruction to redirect iFrame and a request 4) receiving the token and the request 5) determining token received matches generated token 6) transmitting list of accounts and selection page 7) generating account selection page (8) receiving selection from list of accounts, the token 9) providing credential 10) generates authorization request message comprising credential 11) transmits authorization notification 12) transmits a return merchant URL with notification 13) reloading iframe.
The claimed limitations which under its broadest reasonable interpretation, covers performance of an authorization process. When considered as a whole the claimed subject matter is directed toward transaction process and commercial activity. These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims recite a process of 1) receiving signon data-insignificant extra solution activity, 2) activating authentication token- a applying technology to mitigate risk in an authentication process 3) transmitting the token, an instruction to redirect iFrame and a request -applying technology to transmit data at a high level lacking technical details- insignificant extra solution activity 4) receiving the token and the request -insignificant extra solution activity 5) determining token received matches generated token- a business practice of analyzing data for risk mitigation 6) transmitting list of accounts and selection page-insignificant extra solution activity 7) generating account selection page – applying technology for a transaction process (8) receiving selection from list of accounts, the token -insignificant extra solution activity (9) providing credential- insignificant extra solution activity and sales activity 9) generates authorization request message comprising credential – applying technology for a business practice and risk mitigation 10) transmits authorization request notification message -insignificant extra solution activity 11) transmitting transmits a return merchant URL with notification -insignificant extra solution activity 12) reloading iframe.-applying technology to provide content to another.
The functions are is recited at a high-level of generality such that it amounts to no more than applying the exception using generic computer components. Taking the claim elements separately, the method steps performed by the issuing bank server at each step of the process is purely in terms of results desired and devoid of implementation of details. Technology is not integral to the process as the claimed subject matter is so high level that any generic programming could be applied and the functions could be performed by any known means. Furthermore, the claimed functions do not provide an operation that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations 1-3 are an insignificant extra solution business related activity of receiving sign-on details using an online banking web page, generating a token that transmits the token and instructions to redirect the iframe of the web page from a URL to a trusted intermediary system – which is a process using technology to transmit data and generate a token for an authentication/authorization process toward a sales activity and commercial interaction. (a business practice). The combination of limitations 1-3 and 4-6 are directed toward generating and receiving the token and a request for list of accounts, transmitting list of account and determining the token received from the trusted intermediary matches generated token in response to limitations 1-3 which is directed toward an extra solution insignificant activity, risk mitigation as part of a sales activity. The combination of limitations 1-6 and 7-10 is directed toward receiving account list selection for use in transaction, providing credentials, generating and transmitting authorization request message - which is directed toward a sales activity, insignificant extra solution activity of transmitting sales related data and risk mitigation. The combination of limitations 1-10 and 11-13 is directed toward insignificant extra solution activity of transmitting data using technology and refreshing the iframe content when the transaction process has been completed. The combinations of parts is not directed toward improvement to any technical process or technological technique or technological solution to a problem rooted in technology.
The additional elements recited in the claim includes a data communications network by an issuing bank server which is applied to perform insignificant extra solution activity of receiving sign in details associated with an issuing bank. The signin page is presented using iframe that has been loaded and is applied with a corresponding URL of the page causing a browser of the user system to access a web page of the merchant server to display the signin page on user system wherein the intermediary system retrieves the url of the signin page of the online banking system and sends the URL of the signin page to the iframe based on receiving from the user selection a bank identity code. The iframe is applied at a high level to perform iframe functions in its ordinary capacity in a single signon process for use in applying the URL embedded in the iframe in the intermediary system for retrieving URL of the signon page of the online banking website and sending the sign-in page to the iframe based on identity code in the transaction process. The claim limitations recite detailed steps on the application of the iframe in the transmission of data, however the details are not directed toward iframe technology itself but instead how the how the iframe is applied in the transaction process for use in retrieving and sending URL signin website. Additional computer components applied in the transaction process claimed include a issuing bank server, intermediary system, merchant system and user system which communicate data between the systems in the transaction process. The additional limitations (issuing bank server, intermediary system, merchant system, user system, signon page, iframe and display) do not impose meaningful limits upon the judicial exception or apply a particular machine.
The claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea of the commercial activity of the limitations. . This is because the claimed subject matter when considered as a whole is not solving a technical problem or providing improvement to any of the recited systems or Html tag iframe technology. The focus of the invention is not on issues related to the merchant computer, user system, intermediary system or iframe processes. Rather the focus of the claimed steps when considered as a combination of parts or as a whole is to perform a transaction process applying technology to mitigate risk by generating a token, providing a list of accounts for selection for the transaction and credentials where technology is applied at a high level to transmit data between the user system, intermediary system and merchant computer. The claim limitations and specification do not provide any details as to iframe process beyond its use in the transmission of data content. Accordingly, under step 2A prong 2, the claim subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The analysis of the claimed limitations lacks technical details in how the functions of the different computer systems and iframe application are performed. The claim limitations are solely result oriented, functional language omitting any specific requirements as to how these steps performed by the different technological elements are performed. The functions recited in the claims recite the concept of receiving request, transmitting account list for selection and receiving account selection, providing credentials and generating authorization request which is a process directed toward a business practice.
The integration of elements do not improve upon technology or improve upon computer functionality or capability in how computers carry out one of their basic functions. The integration of elements do not provide a process that allows computers to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to manage, transmit and receive account related data of a request in order to generate an authorization request which is a sales activity and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional element “iframe” as claimed is merely used to provide content from a web page that has been redirected and then emptied when an authorization has been sent. The limitations being performed by the iframe are recited at a high level of generality and amounts to no more than mere instructions to apply iframe processes in its ordinary capacity used in data transmission for transaction authorization process. The limitations only recite iframe outcomes without any details as to technical implementation. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea. Moreover, Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
There is no indication in the claim language that the structure and/or the manner in which an issuer server operates is changed in any way. The Specification describes the challenges authorization request for payment transaction (Spec. 0004-0005). The Specification also describes that current invention relieves the need for a user to have a relationship with a merchant who apply third party payment system (pay pal), which has disadvantages of the merchant does not receive payment directly, cannot avail itself of payment scheme based on guarantee payment, effect the buyer who does not have visibility of the merchant and the buyer is not protected by card scheme rules because the payment system is not with the merchant system. The claim provides no technical details regarding how the operations of transmitting, receiving, providing and generating authorization requests performed. Instead, similar to the claims at issue intellectual Ventures I LLC v. Capital One Financial Corp., 850 F.3d 1332 (Fed. Cir. 2017), “the claim language . . . provides only a result-oriented solution with insufficient detail for how a computer accomplishes it. Our law demands more.” Intellectual Ventures, 850 F.3d at 1342 (citing Elec. Power Grp. LLC v. Alstom, S.A., 830 F.3d 1350, 1356 (Fed. Cir. 2016)).
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional element recited in the claim beyond the abstract idea include the “issuing bank server”, “trusted intermediary system”, “data communication network”, “online merchant server” and “display of user system” to perform the operations operating in its ordinary capacity and using iframe at a high level with URL information transmit and receive content from web pages/sites where once the authorization message has been transmitted the iframe reloads and returns to a merchant. The specification and claim limitations lack technical disclosure as to a technical process for the use of the iframe that goes beyond its ordinary function and use in the authorization process for providing content of redirected pages. The claim limitations and specification do not provide any information as to how the use of the computer elements claimed provide a new way in which to perform the recited transmission of data, match/compare data or empty/reload iframe. Taking the claim elements separately, the function performed by the computer at each step of the process is purely conventional.
The claims still “simply recite conventional actions in a generic way” (e.g., the claims still “simply recite conventional actions in a generic way” (e.g., receiving a transaction request, verifying the identity of a customer and merchant and allowing a transaction) and “do not purport to improve any underlying technology.”) the use of iframe for redirecting content merely applies iframe technology failing to provide a particular unique technical process. The limitations are high level lacking technical details.
When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) ("Absent a possible narrower construction of the terms “generating”, “transmitting”, “intercepting”, identifying”, “determining”, “replacing” and “routing' ... are functions can be achieved by any general purpose computer without special programming"). Similarly, none of these activities are used in some unconventional manner nor do any produce some unexpected result. As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
The limitation “an instruction to re-direct an iFrame associated with the browser to a trusted intermediary application” of claim 1. The iFrame is a type of HTML element used to embed another HTML document within a current one which means you can display a page within a page. Based on BRI the limitation merely transmits at a high level instruction data to generate a page which lacks technical disclosure. This limitation amounts to no more than mere instructions to apply the exception “generate list of accounts” using interface and HTML element technology. The “transmitting” is generally applying the abstract idea without limiting the technology beyond their ordinary capacity.
The independent claim(s) do not describe the bank servers, intermediary system or merchant computer in any further technical detail that would distinguish them from their generic counterparts. Each is functionally described as either "receiving" (sign-in details, token, request for list of accounts, selection of an account selected from account list, token) or "generating” (token, authorization request), “transmitting” (token, instructions to redirect iframe, request for list of accounts, list of accounts, authorization request message, notification successful authorization, return merchant URL), “determining" (token received matches token generated), “providing” (account selection page, a credential, ), and “causing” (iframe to empty/reload (i.e. refresh). The functions associated with generic server, system, computer and iframe is further described in functional terms; that is, it is configured to perform information-processing steps to obtain a transmit, receive, generate, provide, match and reload. Putting it together, these steps simply call for using a generic computer components and software operations to function as one of ordinary skill in the art would expect such computer hardware and software to function. The independent Claim(s) "consist[ s] solely of result-orientated, functional language and omit[ s] any specific requirements as to how these steps of information manipulation are performed." Mobile Acuity Ltd. v. Blippar Ltd., 110 F.4th 1280, 1292-93 (Fed. Cir. 2024). With respect to the causing iframe to empty/reload (i.e. refresh) functions, the Specification attributes no special technical meaning to any of this operations, individually or in the combination, as claimed. In view of the analysis, the recited operations are common processing functions that one of ordinary skill in the art at the time of the invention would have known generic servers were capable of performing and would have associated with such generic devices. Cf OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015).
Similar to Recentive v Fox, which found the process was not directed toward AI technology itself but rather the application of AI technology in the performance of an abstract idea. The claimed limitations recite detailed steps on the application of the iframe in the transmission of data, however the details are not directed toward iframe technology itself but instead how the how the iframe is applied in the transaction process for use in retrieving and sending URL signin website. The claimed signin page is presented using iframe that has been loaded and is applied with a corresponding URL of the page causing a browser of the user system to access a web page of the merchant server to display the signin page on user system wherein the intermediary system retrieves the url of the signin page of the online banking system and sends the URL of the signin page to the iframe based on receiving from the user selection a bank identity code. The iframe is applied at a high level to perform iframe functions in its ordinary capacity in a single signon process for use in applying the URL embedded in the iframe for use in the intermediary system for retrieving URL of the signon page of the online banking website and sending the sign-in page to the iframe based on identity code in the transaction process.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
A commonplace business method or mathematical algorithm being applied on a general purpose computer, Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 573 U.S. 208, 223, 110 USPQ2d 1976, 1983 (2014); Gottschalk v. Benson, 409 U.S. 63, 64, 175 USPQ 673, 674 (1972); Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015);
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added));
Iframe application evidence includes:
“Web Robot Detection Techniques Based on Statistics of Their Requested URL Resources” by Guo et al (2005); “Method for dynamically loading and updating portlets” by Ip.com (2005); “A Systematic Approach to Web-Application Development” by Fodor et al. (2007);
US Patent No. 8,136,148 B1 by Chayanam et al.Col 5 lines 47-Col 6 lines 1-2, Col 8 lines 14-32 “authentication widget is implemented within an IFRAME, only the IFRAME might be submitted rather than the web page 212. In other examples, for instance, non-IFRAME implementations, the authentication widget 214 may communicate with the authentication server 220 by transmitting (e.g., submitting) a request to post a form”
US Pub No. 2006/0212803 A1 by Arokiaswamy-Abstract; para 0005 wherein the prior art teaches that it is known (background) for adding HTML iframe element mechanisms to enable web page to include an iframe reference within the HTML of a web page to designate the URL that is to be loaded into the iframe as the web page being loaded into the user’s browser application.
US Pub No. 2003/0023445 A1 by Trifon -para 0007, 0011-0013, wherein the prior art teaches that it is known (background) to embed a web page URL within another web page in the form of an iframe which can be applied across multiple industries
WO 2005/078607 A1 by Lim et al -para 0024-0025 “An IFRAME is an HTML element which provides a mechanism for embedding data within an HTML document. The embedded data may be displayed in a subwindow of the web browser's window. Thus, IFRAMES are more analogous to an object, such as an image, within an HTML document than to a typical HTML frame. When an IFRAME is created, it does not affect the browser's history (i.e. the browser does not add a history entry for the IFRAME). “
US Patent No. 7,802,262 B1 by Lynch et al “To allow the user to navigate the RIA using the browser`s` forward and back buttons, the referring page may contain a conventional iframe, which designates a frame that will not be displayed. Each time the regular RIA provides additional REST information as described above, it directs the browser to reload the iframe, using a URL that references a utility referring page, and also includes the same REST information that was provided to the browser for display in the address bar as described above. The browser will load or reload the utility referring page into the iframe.”
US Patent No. 8,335,929 B2 by Isaacs et al- Col 2 lines 49-67 “An Iframe is a construct which embeds a document, such as a web page, into an HTML document. Traditionally, iframes have been used so that embedded data can be displayed inside a sub-window of the browser's window…Basically, an Iframe element is of the form: <iframe src="URL" more attributes>; iframe> Browsers which support iframes display or load the document referred to by the URL in a subwindow, typically with vertical and/or horizontal scroll bars; such browsers ignore the content of the Iframe element (i.e., everything between the start tag <iframe . . .>; and the end tag <iframe>)
NPL - Reload - Refresh multiple iframes – Javascript by Tek-Tips (2007); how to force an iframe to reload? By web Developer (2005)
US Pub No. 2007/0011258 A1 by Khoo-para 0042 wherein the prior art evidence includes “Other mechanisms familiar to those skilled in the art may also be used to achieve asynchronous data fetches that do not require a page "refresh", or a reload may be used, such as by embedding a Java Applet within the preview window, or by using frames and iframes within the preview window to fetch data from a server.”
“A method to close previous iFrame session under SSO environment” by IBM
WO 2008/111048 A2 by Schreiber et al – “inside a first web site to embed content from a second website. Modern browsers therefore provide an HTML element called an iframe, and/or similar elements, which may be embedded in a first web site and which may be supplied with a URL by way of an attribute called ISRC which will direct the browser to load a second web site from the URL into the iframe. Although the first web site may control the ISRC parameter of the iframe, the browser will usually prohibit any communication between code from the first web site and code from the second web site if they are downloaded from different domains “[0004 wherein the background indicates known in the art]…“ SSO functionality 3103 will send a GET or POST or other protocol to effect a sign-in prior to relaying the HTTP request 3111. SSO functionalty 3103 receives back a Cookie or authentication token from the Web site target of HTTP request 3111, which is then attached to HTTP request 3111. HTTP request 3111 with the attached cookie is then forwarded to third party service 1010 as HTTP request 3112. “ [0056-0057]; see also ¶ 0015
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 1, 3-5, 7-8 and, 11-12 these dependent claim have also been reviewed with the same analysis as independent claim 1. Dependent claim 3 is directed toward limiting the application as part of an intermediary system with a database that holds data – generic well known structure and does not further limit the method. Dependent claim 4 is directed toward limiting the credential of the method to a debit card- sales activity. Dependent claim 5 is directed toward debit card number is linked to account held to intermediary-directed toward a transaction process.
Dependent claim 7 is directed toward transmitting message- insignificant extra solution activity. Dependent claim 8 is directed toward user system is personal computer- does not further limit the method directed toward conventional technology. Dependent claim 11 is directed toward limiting the list to list of card account- business activity. Dependent claim 12 is directed toward system communicating with merchant when list account received- insignificant extra solution activity.
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 1. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 1, 3-5, 7-8 and 11-12 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to Claims 13-15:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a system, as in independent Claim 13 and the dependent claims. Such systems fall under the statutory category of "machine." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. System claim 13 recites functional process of 1) receiving sign-in data that is inputted into sign-in page presented 2) accessing merchant online web page 3) generating a token 3) retrieves URL of sign-in page and sends URL to iframe 4) activating token 5) authenticates user to intermediary system (6) transmitting the token, an instruction to redirect iFrame to intermediary application 7) trigger instructions to obtain account list 8) receiving the token and the accounts list request 9) determining token received matches generated token 10) transmitting list of accounts and selection page 11) providing account selection page to user in display 12) receiving selection from list of accounts, the token 13) providing credential 14) generates authorization request message comprising credential 15) transmits authorization request message 16) transmitting successful authorization notification 17) transmits a return merchant URL with notification 18) reloading iframe.
The claimed limitations which under its broadest reasonable interpretation, covers performance of an authorization process. When considered as a whole the claimed subject matter is directed toward transaction process and commercial activity. These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims recite system operations of 1) receiving data-insignificant extra solution activity, 2) accessing merchant online web page- applying technology for a business practice 3) generating a token- a business practice applying technology 4) retrieves URL of sign-in page and sends URL to iframe- applying technology to receiving and transmit data 5) activating token – applying technology in a transaction process 6) transmitting the token, an instruction to redirect iFrame to intermediary application -applying technology for risk mitigation and authentication and using technology to transmit transaction request 7) trigger instructions to obtain account list – apply technology to perform a transaction process 8) receiving the token and the accounts list request -insignificant extra solution activity in a transaction process 9) determining token received matches generated token- a business practice of analyzing data for risk mitigation 10) transmitting list of accounts and selection page-insignificant extra solution activity 11) providing account selection page to user in display- applying technology to display transaction related data 12) receiving selection from list of accounts, the token -insignificant extra solution activity 13) providing credential- insignificant extra solution activity and sales activity 14) generates authorization request message comprising credential – applying technology for a business practice and risk mitigation 15) transmits authorization request message -insignificant extra solution activity 16) transmitting successful authorization notification --insignificant extra solution activity 17) transmits a return merchant URL with notification -insignificant extra solution activity 18) reloading iframe.-applying technology to provide content to another.
The functions are is recited at a high-level of generality such that it amounts to no more than applying the exception using generic computer components. Taking the claim elements separately, the method steps performed by the issuing bank server at each step of the process is purely in terms of results desired and devoid of implementation of details. Technology is not integral to the process as the claimed subject matter is so high level that any generic programming could be applied and the functions could be performed by any known means. Furthermore, the claimed functions do not provide an operation that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations 1-4 are an insignificant extra solution business related activity of receiving sign-on details using an online banking web page, generating a token that transmits the token and instructions to redirect the iframe of the web page from a URL to a trusted intermediary system – which is a process using technology to transmit data and generate a token for an authentication/ authorization process toward a sales activity and commercial interaction. (a business practice). The combination of limitations 1-4 and 5-10 are directed toward activating and transmitting the token that is received using the iframe for transmission and matched – for a transaction process. The combination of limitations 1-10 and 11-16. The combination of limitations 1-16 and 17-19 is directed toward transmitting successful authorization request of the transaction process of limitations 1-16 and transmitting a return URL to merchant and reloading iframe for next transaction. The combinations of parts is not directed toward improvement to any technical process or technological technique or technological solution to a problem rooted in technology. The limitations do not impose meaningful limits upon the judicial exception or apply a particular machine.
The additional elements recited in the claim includes a data communications network by an issuing bank server which is applied to perform insignificant extra solution activity of receiving sign in details associated with an issuing bank.
The signin page is presented using iframe that has been loaded and is applied with a corresponding URL of the page causing a browser of the user system to access a web page of the merchant server to display the signin page on user system wherein the intermediary system retrieves the url of the signin page of the online banking system and sends the URL of the signin page to the iframe based on receiving from the user selection a bank identity code. The iframe is applied at a high level to perform iframe functions in its ordinary capacity in a single signon process for use in applying the URL embedded in the iframe for use in the intermediary system for retrieving URL of the signon page of the online banking website and sending the sign-in page to the iframe based on identity code in the transaction process. The claim limitations recite detailed steps on the application of the iframe in the transmission of data, however the details are not directed toward iframe technology itself but instead how the how the iframe is applied in the transaction process for use in retrieving and sending URL signin website. Additional computer components applied in the transaction process claimed include a issuing bank server, intermediary system, merchant system and user system which communicate data between the systems in the transaction process. The additional limitations (issuing bank server, intermediary system, merchant system, user system, signon page, iframe and display) do not impose meaningful limits upon the judicial exception or apply a particular machine.
The claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea of the commercial activity of the limitations. This is because the claimed subject matter when considered as a whole is not solving a technical problem or providing improvement to any of the recited systems or Html tag iframe technology. The focus of the invention is not on issues related to the merchant computer, user system, intermediary system or iframe processes. Rather the focus of the claimed steps when considered as a combination of parts or as a whole is to perform a transaction process applying technology to mitigate risk by generating a token, providing a list of accounts for selection for the transaction and credentials where technology is applied at a high level to transmit data between the user system, intermediary system and merchant computer. The claim limitations and specification do not provide any details as to iframe process beyond its use in the transmission of data content. Accordingly, under step 2A prong 2, the claim subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The analysis of the claimed limitations lacks technical details in how the functions of the different computer systems and iframe application are performed. The claim limitations are solely result oriented, functional language omitting any specific requirements as to how these steps performed by the different technological elements are performed. The functions recited in the claims