DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The following is a Non-Final Office Action in response to communications received July 10, 2025. Claim(s) 1-15, 20, 23-24 have been canceled. Claims 16-17, 19, 21 and 30 have been amended. No new claims have been added. Therefore, claims 16-19, 21-22 and 25-33 are pending and addressed below.
Priority
Application 17/941 ,369 filed 09/09/2022 Claims Priority from Provisional Application 63243451 , filed 09/13/2021.
Applicant Name/Assignee: Mercury Financial Holdings LLC
Inventor(s): Katamreddy, Sateeshasatya; Tran, Van Heiu; Zheng, Jie; Shah, Anal; Kelly, Cory
Response to Amendment/Arguments
Claim Rejections - 35 USC § 101
Applicant's arguments filed July 10, 2025 have been fully considered but they are not persuasive.
In the remarks applicant argues that the claimed elements 1) generation of partner specific logic modifying modular and customizable logic, 2) partner-specific logic instructions for calling partner specific API to receive data and decrypt data according to customer preference 3) credit product application steps, reporting steps and underwriting according to core logic functions for plurality of partners 4) credit product application processing steps comprising calling the API in accordance with instructions of partner specific logic in response to calling, receiving data encrypted according to partner preference , decrypting data according to partner specific logic instructions and pre-populating credit product application with decrypted data 5) process flow engine to perform credit product application processing steps of plurality of partners, credit product applications reporting steps, underwriting associated with partners according to core logic without partner specific logic associated with new partner…provides patent eligible subject matter. The claim limitations recite computer functions that are unconventional combination of conventional steps and elements. Applicant references DDR Holdings, Bascom, Amdocs, Finjan Inc, Cellspin Soft Inc v Fitbit; CosmoKey Solutions, and Weisner v Google without analysis. Applicant’s argument is not persuasive. The claim limitations recite:
wherein the onboarding the user comprises:
generating, based on the onboarding information, partner-specific logic, the generating comprising modifying modular and customizable logic according to the onboarding information,
wherein: the onboarding information indicates a preference of the new partner for handling customer data,
the modular and customizable logic comprises predefined non-partner- specific functions, and the partner-specific logic comprises instructions for calling a partner-specific application programmable interface (API) to receive the customer data and decrypting the received customer data
The specification describe the “partner-specific logic” is developed and programmed to operate core logic for implementing partner specific functions, which include creating partner specific application (page 0007) comprising partner specific interface to include branding elements, functions and configurations. [spec ¶ 0007]. The specification is silent with respect to technical details on the technical process for “generating” the partner specific logic, instead the specification discloses the use of the partner-specific logic for onboarding interface which includes partner branding, functions and other partner configurations as part of the “onboarding” of the client. The limitations (“comprising modifying modular and customizable logic according to the onboarding information, wherein: the onboarding information indicates a preference of the new partner for handling customer data”) and specification do not focus on the technical details of how the logic itself is generated but instead focus on what in the interface that has been modified and customized to provide an interface with partner specific branding and functions for use in a commercial enterprise for an onboarded partner. Accordingly, the limitations are not directed toward patent eligible subject matter under step 2A prong 2 or 2B, as the limitations do not improve upon technology, provide a solution to a problem rooted in technology, apply the judicial exception with or by use of a particular machine, effect transformation of a particular article to a different state or apply the judicial exception in some meaningful way beyond generally linking the use of the judicial exception to a particular technological environment as the claimed technology does not impose meaningful limits upon the judicial exception. Nor do the claim limitations recite specific limitations other than what is well understood in the industry with the application of such logic to generate specifically branded interface with partner specific functions. This is made evident by the plethora of company specific branded interfaces with company specific functions that are available to the public for use in commercial activity. The rejection is maintained.
In the remarks applicant argues that the claimed limitations recite unconventional combination of steps/elements involve technical improvements and practical applications by optimizing shared resources while tailoring different partner requirements. The limitations improve credit product technologies by reducing inefficiencies without compromising partner needs. Applicant points to the modifying/customizing logic generates partner specific needs without generating logic from scratch. Applicant points to the specification [Abstract; ¶ 0021 ¶ 0078] arguing the claimed limitations improve the speed of the onboarding process increasing the number of credit product applicants and acquisition rate. Applicant argues the claimed partner specific logic allows the system to adapt to the new partner data handling needs which differs from other partners. The partner specific logic generates based on information of partner’s preference, for calling partner specific API to receive customer data and decrypting received data, one of ordinary skill in the art would understand the claimed instructions allow the system to perform different partner specific processes with different security needs. Applicant points to the specification [¶ 0027-0034] arguing that without partner specific instructions the partner may not have control on how a system handles customer data increasing security risk on customer data or the partner may use its own system to handle customer data and cope with inefficiencies. The partner specific logic generated is plug and play and not generated from scratch, thus the partner specific logic provides a practical application by allowing credit product company systems to meet partner needs. The claims require credit processing application system performs partner specific application processing in response to calling using API receiving encrypted customer data, according to partner’s preferences for handling customer data, decrypting customer data and pre-populating credit product application with decrypted data. Applicant’s argument is not persuasive. Applicant focuses on the commercial application of the partner specific logic which as a plug and play logic can be customized for the interface to have the partner brand and credit application product process functionality. Application of a “plug and play” logic that can be customized according to partner specific functional requirements with branding is well known application of technology in the art. The limitations of the claims focus on the application of such technology in the realm of commercial credit application processes according to partner preferences and requirements of functions. The rejection is maintained.
In the remarks applicant argues the core logic allows new partner channels with different partner specific functions to be added using a “plug n play” logic program allowing scalability of onboarding systems pointing to the specification [¶0037, 0048, 0043, 0065, 0070] without modification of the core logic. Applicant argues this improves efficiency for performing processes associated with new partners. Applicant’s argument is not persuasive. Application of “plug and play” refers to a technology that is common in the realm of business applications and well known in the industry. This technology has been around since the mid-1990s and has become a standard feature in modern operating systems, including Windows, macOS, and Linux. The primary goal of PnP is to simplify the process of installing and configuring hardware devices, making it easier for users to expand their system’s capabilities without requiring extensive technical knowledge. As evidence the examiner provides “Understanding Plug and Play Technology: The Convenience of Driverless Device Installation” by Garcia (2025). The rejection is maintained.
Claim Rejections - 35 USC § 103
Applicant's arguments are moot in light of the new ground of rejection that was necessitated by Applicant's amendments. Based on an updated search of the art, a new reference was used in the rejection below
Claim Interpretation
Claim language “onboarding”, in light of the specification the examiner is interpreting the term to be business practice of a new partner is put “onboard” with a credit product system for an application process where a new page for a credit product application page is presented. (see para 0004).
The specification discloses the creating partner-specific user interface by modifying the user interface to include one or more partner specific branding elements- which makes clear that functionality is not added but rather branding is added to the page.(spec para 0007). The specification discloses the developing of partner specific logic comprising modifying logic to include branding elements – which makes clear that functionality is not added but rather branding elements. (spec para 0007).
A communication channel refers to either a physical transmission medium, such as a wire, or a logical connection over a multiplexed medium, such as a radio channel in telecommunications and computer networking. In simpler terms, it’s the pathway through which information travels from a sender to a recipient.
A database layer is where the system stores all data.
The specification discloses the language “partner specific flow” as task related to partner workflow processes (see spec Fig. 8 ref # 0806, 0808; ¶ 0088) which discloses a task flow process for application process.
In light of the specification the examiner is interpreting data configuration (data template) associated with partners/new partner to be analogous to partner offer information, (spec ¶ 0006, ¶ 0008, ¶ 0056), partner specific branding element, logos, design elements, colors, font, layouts, fields, text box…),
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 16-19, 21-22, 25 and 21-33 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 16-19, 21-22, 25 and 21-33:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a system architecture, as in independent Claim 16 and the dependent claims. However the system architecture as claimed are directed toward software per se. under the broadest reasonable interpretation in light of the specification, describe software components. The claim term architecture is not defined in the specification. Per Microsoft Press Computer Dictionary 3rd Ed. 1997, architecture computer definition encompasses both eligible and ineligible subject matter:
Architecture: 1. The physical construction or design of a computer system and its components. 2. The data-handling capacity of a microprocessor. 3. The design of application software incorporating protocols and the means for expansion and interfacing with other programs.
While the claim also include “core logic associated with the plurality of partners and the new partner” per the specification, the core logic is described at [0006] “comprises one or more of: a content distribution network, a web client, web servers, a backend application, an internal facing front end application, an external facing front end application, a data layer, or a cache layer.” This description indicates that the core logic includes at least one software component or at least one hardware component. There is no requirement for the core logic to be comprised of hardware.
Claim 16 further recites “content management system” however the specification does not limit this element to a hardware embodiment
In light of the specification, the appropriate definition of architecture would include both definitions 1 and 3. Accordingly the “system architecture” fails to fall under the statutory category. Therefore, the claims are not directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. System claim 16 recites a functional process (1) applying interface technology for receiving partner data (2) onboarding a new user as a partner (3) generating customized logic according to onboarding information (4) onboarding information indicates partner preference (not a step) (5) customized logic include predefined non-partner specific functions (6) calling partner specific API to receive data and decrypt data (7) services layer comprising partner data used (not a step) (8) partner data comprises data associated with partners and new partner data(not a step) (9) partner data received (10) reporting results of credit application steps, (11) interface interfaces with flow engine to perform credit application processing steps, reporting and underwriting steps (12) performing credit product application processing steps (13) calling API (13) receiving encrypted customer data (14) decrypting customer data (15) pre-populating credit application (16) manages partner configuration data (17) partner data comprises configuration data associated with plurality of partners data (18) new partner data is determined based on onboarding data (19) perform credit product application processing steps of plurality of partners, credit product application reporting steps and underwriting associated with plurality of partners (20) data layer comprising database information (21) execute partner specific flows [tasks] based on onboarding information
. The claimed limitations which under its broadest reasonable interpretation, covers performance of onboarding process which allows co-branding customization of websites according to partnership agreements which can be applied for credit application and a credit application process itself. When considered as a whole the claimed subject matter is directed toward partnership agreements with a financial system for credit applications with a partnership brand that is issued by a financial institution. Such concepts can be found in the abstract category of commercial interactions. 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 by a system to (1) applying interface technology for receiving partner data -applying technology to receive data- insignificant extra solution activity (2) onboarding a new user as a partner- business process (3) generating customized logic according to onboarding information – applying technology for a business process (4) onboarding information indicates partner preference [not a step] (5) customized logic include predefined non-partner specific functions [not a step] (6) calling partner specific API to receive data and decrypt data – applying technology to receive data, thus performing insignificant extra solution activity (7) services layer comprising partner data used (not a step) (8) partner data comprises data associated with partners and new partner data(not a step) (9) partner data received -insignificant extra solution activity (10) reporting results of credit application steps,- insignificant extra solution activity (11) interface interfaces with flow engine to perform credit application processing steps, reporting and underwriting steps - (12) performing credit product application processing steps- fundamental economic practice (13) calling API- applying technology to receive encrypted customer data (14) decrypting customer data – data manipulation (15) pre-populating credit application- data manipulation and organization (16) manages partner configuration data- applying technology for a business process (17) partner data comprises configuration data associated with plurality of partners data [not a step] (18) new partner data is determined based on onboarding data – business practice (19) perform credit product application processing steps of plurality of partners, credit product application reporting steps and underwriting associated with plurality of partners- perform business practice (20) data layer comprising database information – not a step (21) execute partner specific flows [tasks] based on onboarding information -business process.
The additional elements recited in the claim include: a product system architecture comprising “presentation layer” for presenting interface to receive data, with an onboard configuration page; user interface; a services layer comprising partner data for application processing; a business layer comprising process flow engine interface interfaces with process flow engine; content management system and partner data configuration to perform credit application/reporting/underwriting steps,; a data layer comprising database information comprising repositories and data transfer objects; backend application that sends data, authenticates partners, checks data and executes partner specific flows (tasks), is merely the technical environment applied to implement the application process. The claimed API is merely applied to receive, encrypt and decrypt data. The claimed 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 operation performed by the system architecture at each step of the process is purely in terms of results desired and devoid of implementation of technical processes used to perform the application tasks and processes according to the partner specific flows (task). This is true with respect to the limitations “receiving onboarding information”, “user is onboarded as now partner”, “partner data is received”, “credit product application processing steps…using partner data, partner configuration data, credit product application…credit application reporting steps…”, “database information”, “send information, authenticates partner, executes partner specific flows and checks onboarding information” as the claimed limitations do not provide detail on how any technology to performs the recited functions. Rather the partner-specific logic and process flow engine interface are recited to perform the abstract idea of customizing an interactive commercial portal with the brand of the partner according to partnership agreements. With respect to the “content management system” this system merely receives data for the abstract process and is not directed toward improvement technology. With respect to the “generating partner specific logic comprising customizable onboarding logic data with pre-defined function according to partnership rules and applying API to receive, encrypt and decrypt financial related data. The core logic recited in the claim is merely applied to perform common functions for partners without details of what those “common functions” entail. 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-5 are directed toward applying a system interface for receiving business data and generating customized interface according to onboarding information and partner preference - business process. The combination of limitations 6-10 are directed toward applying technology to receive and decrypt data and reporting the results of credit application using the onboarded application of limitations 1-5. The combination of limitations 11-15 is directed toward applying technology to process and populate credit application. The combination of limitations 16-21 as a combination is directed toward managing partner configuration data to perform a credit application process, reporting and underwriting which includes a database and the execution of tasks based on onboarding data. When considered as a whole the claimed limitations are directed toward the generation of a partner interface with partner specific function using partner logic that is able to be modified according to partner preferences and needs which is applied to perform a credit application and present the result to customers.
Accordingly, the claim limitations when considered as a combination of parts or as a whole is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology. The claim limitations therefore, do not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. . This is because when considered as a whole the technology recited in the claim is merely the environment to apply the abstract idea of a credit application via a website. The claimed 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 functions recited in the claims recite the concept of onboarding partners into a system which provides partner specific interfaces according to partner preferences, that is branded and applies functions for submitting a credit application for a co-brand card which is a process directed toward a business practice. The partner specific logic is merely applying technology at a high level to customize interfaces for 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 direct a customer to a website for credit applications via an interface and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, a 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 the management system, logic or interface operates is changed in any way beyond providing a technical environment to apply an abstract idea. The analysis cannot find any such indication elsewhere in the specification. The Specification describes the challenges a system for a new partner/brand into a platform for providing to customers a means for submitting a partner/brand credit application, (Spec. ¶ 0005-0006) and discloses the logic as a “plug and play” logic program (
¶
. 0037, 0078) that is applied when new partner channels are onboarded.
The claim recites the concept of directing a customer to a website interface such that the credit underwriting is performed for a partner/brand credit application submitted by the customer via an interface that displays application status or technical details of the “generating…partner-specific logic”, instead the generating is claimed as “modifying modular and customizable logic according to onboarding information”. This makes clear that the “generating” is not directed toward specific technical processes but instead based on onboarding information. The claim is not attempting to provide a technical solution or to address a problem rooted in technology. The claim provides no technical details regarding how the “management system”, “user interface”, “process flow engine interface” or “partner-specific logic” operations are performed. Instead, similar to the claims at issue in 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 elements recited in the claim beyond the abstract idea include a credit product company system architecture comprising a presentation layer for presenting a user interface where the user interface is applied to perform insignificant/well understood activity of receiving data; comprising a services layer comprising data for a business process; comprising a business layer comprising a process flow engine interface with a process flow engine to perform credit application processing; comprising a content management system managing partner configuration data; comprising partner configuration data of onboarding data associated with partners and new partner and comprising a partner-specific logic; comprising a data layer comprising database data comprising entities, repositories and data transfer objects; and comprising a backend application used to send data to services layer (insignificant extra solution activity), authenticate partners, checks data and executes partner specific flows/tasks. The claim limitations recite the onboarding of users as comprising “generating…partner-specific logic…the generating comprising modifying modular and customizable logic according to onboarding information. The modular and customizable logic comprises predefined non-partner specific functions. The partner-specific logic comprises instructions for calling API to receive data (insignificant extra solution activity) and decrypting received data (mere data manipulation). The additional “core logic” elements comprises common functions for the partners. The different software elements of the system fail to provide any details on technical implementation or a technical process. Rather the functions recited in the claim language is high level directed toward applying the onboarding application process and the processing of a credit application which includes receiving data, underwriting and reporting results. .
Taking the claim elements separately, the function performed by the system at each step of the process is directed toward a credit application process and partner specific data applied to an onboarding task. Using a computer system, engines, logic and interface functions as claimed ----are some of the most basic functions of a computer. 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 “directing”, “retrieving”, “performing…invoking …underwriting”, “displaying”, “receiving”, “creating application”, “submitting application”, “calling API to receive data”, “decrypt” data, “pre-populate applications”, “perform credit application” and “sends data” ... are functions can be achieved by any general purpose computer without special programming. None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented any of these technical activities. In short, each step does no more than require a generic computer to perform generic computer functions.
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.
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:
The specification discloses the “content management system” is disclosed by its application to perform the abstract idea and not a technical process (para 0006)
[0008] …The credit product company system architecture comprises: a presentation layer programmed to present a user interface to a user; a services layer comprising partner data used in application processing steps or reporting steps; a business layer comprising a process flow engine interface, a content management system, and partner configuration data, wherein the process flow engine interfaces with a process flow engine; and a data layer comprising database information, the database information comprising entities, repositories, and data transfer objects. Additionally or alternatively, in some embodiments, the services layer communicates reporting results to one or more external systems. Additionally or alternatively, in some embodiments, when onboarding a new partner channel into the credit product company system, only the business layer is changed. Additionally or alternatively, in some embodiments, the changing only the business layer comprises: adding one or more partner-specific branding elements to the content management system, adding the partner configuration data, or adding one or more partner-specific logic and flows. Additionally or alternatively, in some embodiments, wherein the user is a new partner, the architecture further comprising: a backend application that sends partner information received by the user interface to the services layer, authenticates the new partner, checks the partner information, and executes partner-specific flows.
Please note that the specification in paragraph 0008 discloses the performance of the system to perform the abstract idea and not technical processes.
The specification discloses the presentation layer as how it can be applied/used and different webapp options:
[0029] FIG. lB illustrates a high-level block diagram of an architecture of a prior art partner channel. In some embodiments, the partner channel may be hosted by the partner's system. The architecture 111 comprises a presentation layer 161, a services layer 163, a business layer 165, and a data layer 167. The presentation layer 161 comprises client webapp 117 and admin webapp 119 and is used to present information to one or more users 113 (e.g., customer, admin, developer, etc.). The presentation layer 161 allows a customer applying for a credit product application, or a developer ( of the partner or credit product company) developing the new partner channel, to interface with the other layers in the architecture 111.
[0066] FIG. 4 illustrates a high-level block diagram of an exemplary credit product company system architecture, according to embodiments of the disclosure. The architecture 410 comprises a presentation layer 460, a services layer 462, a business layer 464, and a data layer 466. The presentation layer 460 comprises client webapp 416 and admin webapp 418. The presentation layer 460 may be used to present a user interface to users 412 (e.g., customer, admin, developer, etc.). For example, the user interface may be the credit product application page presented to a customer, or may be the onboarding configuration page presented to a partner. The presentation layer 460 allows a customer applying for a credit product application, or a developer to create a new partner channel to interface with the other layers in the architecture. Embodiments of the disclosure may include all layers being hosted on a single system, such as a credit product company system, or across multiple systems.
The specification discloses the services layer as comprising data and transmitting and receiving data in an application process and as further including a backend application and server (computer) used to perform authentication, checking data and onboarding process without significantly more:
[0008]… services layer comprising partner data used in application processing steps or reporting steps… the services layer communicates reporting results to one or more external systems…
[0030] The services layer 163 comprises application processing logic 123 and reporting logic 125. The application processing logic 123 processes the credit product application, and the reporting logic 125 reports the results. The results reported may include, but are not limited to, the number of approvals, the number of declines, approval status, decline category, decline code, approval data, offer name, offer variant, segment, etc. In some embodiments, at least some of the results may be based on information requested from a partner used to determine pricing and cost. The services layer 163 communicates information (e.g., reporting results) to the external systems 115…
[0031] In some embodiments, the services layer 163 may comprise partner configuration data (not shown)…
[0067] The services layer 462 comprises partner data 420, application processing logic 422, and reporting logic 424. The partner data 420 includes data specific to the partner. Non-limiting examples of partner data may be segment data, product data, or the like. The partner data 420 may be data used in application processing steps (underwriting, pre-processing, or post-processing) or reporting steps…. The services layer 462 communicates information (e.g., reporting results) to one or more external systems 414….
[0073] The services layer 562 may comprise a backend application and server. The user interface 502 may communicate with the services layer 562 using an API, where the user interface 502 may send customer information (input by the partner) to the services layer 562. The user interface 502 may inform the services layer 562 that a partner has clicked on the partner-specific URL to start the onboarding process. The backend application may perform authentication of the partner, check the partner information, and execute partner-specific flows. In some embodiments, the backend services layer 562 may send data (e.g., onboarding status) from the partner-specific
flows to the user interface 502.
[0074] The partner's input may cause the services layer 562 to interface with a process flow engine interface 526. The system may allow the partner to create partner-specific flows. In some embodiments, the partner may drag and drop steps into the user interface to create the partner specific flows (for implementing one or more partner-specific functions).
[0075] The process flow engine interface 526 may invoke a partner data fetch service 528 to store or retrieve partner information from a partner prospect database 534. The partner prospect database 534 may include partner data, such as a partner ID, a partner customer ID, an offer ID, an expiration date, attempts, etc. For a given partner, certain information such as customer data may be retrieved for pre-populating the application. The partner data fetch service 528 may retrieve the customer data and send it to the process flow engine interface 526. In some embodiments, the
process flow engine interface 526 may send the customer data to the services layer 562, and the services layer 562 may send the customer data to the user interface 502. The user interface 502 may display the credit product application page with at least some of the customer data pre-populated.
The specification discloses the business layer comprising a process flow engine, content management system and partner configuration data as an engine used to perform task for data management and manipulation when onboarding a partner:
[0008]… a business layer comprising a process flow engine interface, a content management system, and partner configuration data, wherein the process flow engine interfaces with a process flow engine… Additionally or alternatively, in some embodiments, when onboarding a new partner channel into the credit product company system, only the business layer is changed. Additionally or alternatively, in some embodiments, the changing only the business layer comprises: adding one or more partner-specific branding elements to the content management
system, adding the partner configuration data, or adding one or more partner-specific logic and flows….
[0032] The business layer 165 comprises a process flow engine interface 127. The process flow engine interface 127 may interface with a process flow engine. The process flow engine may author, test, store, or execute one or more tasks or actions for a given process flow. The process flow may be based on one or more rules or requirements of the partner. In some embodiments, the process flow engine may be external from the partner's system.
[0068] The business layer 464 comprises process flow engine interface 426, CMS 428, and partner configuration data 430. The process flow engine interface 426 may interface with a process flow engine. The process flow engine may author, test, store, or execute one or more tasks or actions for a given process flow. The process flow may be based on one or more rules or requirements of the partner. In some embodiments, the process flow engine may be external from the partner's system.
[0070] When a new partner channel is onboarded into the technology platform, in some embodiments, only the business layer 464 needs to be changed. These changes include, but are not limited to, adding ( or updating) one or more branding elements to the CMS 428, adding ( or updating) partner configuration 430, or adding partner-specific logic and flows. The branding elements may be used to create an application page, an application process, or an account management process that is branded specific to the partner….
The specification discloses a partner-specific logic as how it can be used to apply the abstract idea:
[0007]… creating a partner-specific application page; and developing partner-specific logic for implementing the one or more partner-specific functions, wherein the partner-specific logic is programmed to operate with core logic, wherein the core logic is developed before the onboarding the new partner channel and is used by multiple partner channels. Additionally or alternatively, in some embodiments, the creating the partner-specific application page comprises creating a partner-specific user interface for a partner-specific application page. Additionally or alternatively, in some embodiments, the creating the partner-specific user interface for the partner-specific application page comprises modifying a user interface by including the one or more partner-specific branding elements. Additionally or alternatively, in some embodiments, the developing the partner-specific logic comprises modifying logic to include the one or more partner-specific branding elements, the one or more partner-specific functions, or the one or more partner-specific configurations….
[0021]… the partner-specific logic may be logic that performs partner-specific functions. The partner-specific logic may originate from modular and customizable logic, modified to include partner-specific branding elements, functions, and configurations. Each time a new partner channel is onboarded into the credit product company's system, in some embodiments, only the partner-specific logic may need to be created and tested. This allows new partner channels to be quickly added without requiring new logic be written for each new partner channel. The faster onboarding process may increase the number of credit product applicants and the acquisition rate.
[0040] The functions of the core logic and the partner-specific logic may be described by way of examples as follows. For a first partner channel 200A, the customer may navigate to a partner-specific application page (step 222). The customer may be directed to the partner-specific application page by clicking on a partner-specific URL. When the customer clicks on the partner specific URL, the customer may be directed to a web or mobile application page hosted on the credit product company's system.
[0065] Other exemplary partner-specific functions may include, but are not limited to, asymmetric payload decryption, API integration, database lookups/validation, calling partner specific APis, etc. Instead of developing, updating, or testing the entire set of logic for each new partner channel (such as shown in FIG. 1), only logic specific to the partner channel needs to be developed, updated, or tested. The partner-specific logic may be programmed to operate with core logic. The core logic may be developed before onboarding the new partner channels. The core logic may be used by multiple partner channels. In some embodiments, one or more core functions (such as displaying a status of an application) may be common to the partner channels and may not be developed, updated, or tested each time a new partner channel is added to the system.
[0070]… The partner-specific logic and flows may reflect a given partner's specific interface for retrieving data, for example. The partner-specific logic and flows may be separate and independent from the core logic. When onboarding a new partner channel, the core logic may not be affected.
The specification discloses a data layer as database elements and data
[0008]… a data layer comprising database information, the database information comprising entities, repositories, and data transfer objects…
[0033] The data layer 167 comprises database information such as entities 133, repositories 135, and data transfer objects 137. The entities 133 may represent one or more columns in the database. The repositories 135 may represent the available database queries that are allowed on one or more database tables. The data transfer objects 137 may define the objects that are returned in response to a query (e.g., GET, POST, etc.) The repositories 135 may be communicated to data sources 139, and the data transfer objects 137 may be communicated to services 141. In some embodiments, data that needs to be persisted may be communicated between the data layer 167 and
the data sources 139, the services 141, or both. This data may include partner-specific configuration values, product definition, card application submission details, reporting configuration, etc.
[0071] The data layer 466 comprises database information. The database information may comprise entities 432, repositories 434, and data transfer objects 436. The entities 432 may represent one or more columns in the database. The repositories 434 may represent the available database queries that are allowed on one or more database tables. The data transfer objects 436 may define the objects that are returned in response to a query (e.g., GET, POST, etc.) The repositories 434 may be communicated to data sources 438, and the data transfer objects 436 may be communicated to services 440. In some embodiments, data that needs to be persisted may be communicated between the data layer 466 and the data sources 438, services 440, or both. This data may include partner-specific configuration values, product definition, card application submission details, reporting configuration, etc.
The specification discloses a backend application in the context of its use for performing the abstract idea:
[0008]… a backend application that sends partner information received by the user interface to the services layer, authenticates the new partner, checks the partner information, and executes partner-specific flows.
[0039]… The backend application may comprise business logic, underwriting logic, content creation, and database
orchestration….
[0046]… In some embodiments, the pre-processing step 226 may include making a request to a backend application to retrieve customer data. The customer data may be stored on one or more backend servers, for example. In some embodiments, customer data may be stored on a persistent data server. The backend application may respond with customer data. Additionally or alternatively, the backend application may pre-populate the credit product application with the customer data. The customer data may have been obtained, e.g., by the partner.
[0073]… The backend application may perform authentication of the partner, check the partner information, and execute partner-specific flows. In some embodiments, the backend services layer 562 may send data (e.g., onboarding status) from the partner-specific flows to the user interface 502.
Please note that the specification discloses the different system engines/logics/layers in the context for performing the abstract idea and not technical processes.
The specification further describes the partner specific logic as a “plug and play” logic program
[0037]…The development and control of the partner channels may not impact the development and control of the core logic, and vice versa. New partner channels implementing different partner- specific functions may be added in a "plug-and-play" manner into the system…
[0078]…onboarding a new partner channel may be efficient and simple, where new partner channels may be onboarded into the technology in a "plug and play" manner. Process 600 may include receiving a new partner in step 601 and associated partner information. Step 602 may comprise using the process flow engine to create a new partner-specific logic and flows. In step 604, the new partner channel may be