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 added in the admin user interface (UI). The admin UI may be displayed on the admin webapp, for example. In some embodiments, the admin UI may display the onboarding configuration page.
NPL article “Understanding Plug and Play Technology: The Convenience of Driverless Device Installation by Garcia provides evidence that “plug and play” technology is well known and generally applied in the industry.
Plug and play technology is a set of specifications that allows devices to be
automatically recognized and configured by the operating system without the
need for user intervention. 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.
US No. 2012/0029998 A1 by Aversano et al-discloses a partner site setup tool and partner site integration (para 0024, para 0030); US Pub No. 2017/0330242 A1 by Shusterman- teaches a web portal to generated by software program for marketing programs provided by brand via web portal (para 0035). US Pub No. 2014/0337189 A1 by Barsade et al-wherein the prior art teaches user interface according to client specific parameters where user interface allow business partners to integrate user server to launch commands in their own proprietary platforms (para 0054-0059). US Pub No. 2014/0316927 A1 Ganesan – wherein the prior art teaches templates needed for creating custom look and feel for partners that can match color fonts, images and partner sites. (para 0060-0062). US Pub No. 2013/0304576 A1 by Berland et al- create custom application- para 0006
As evidence of the conventionality of such computer components in a logic for business applications, the examiner provides: WO 2017/205984 A1 by Antonini discloses FIG. 5; “Figure 5 shows an embodiment of one of the server nodes. The server node may be include a general purpose programmable computing and communication resource, for example one or more devices hosting an operating system as an execution environment supporting a web server and/or an application server for computing and communicating with client nodes.” ; US Pub No. 2017/0098264 A1 by Priebatsch – discloses para 0069 “The communication module 234 may be a conventional component (e.g., a network interface or transceiver) designed to provide communications with a network, such as the Internet and/or any other land-based or wireless telecommunications network or system, and, through the network, with a consumer's device 102. To enable the handling of requests from the mobile device 102, the memory 224 contains a web-server block 236, which can be a conventional web server application executed by the processor 222”…”a gateway for transmitting the user's data to the network 104. The mobile device 102 can support multiple communication channels for exchanging multimedia and other data with the servers”; WO 0180123 A1 by Bet et al discloses – “Client computer systems 121, 125, 135, and 137 can each, with the appropriate web browsing software, view HTML pages provided by the web server 109… his gateway computer system 131 is coupled to the ISP 107 to provide Internet connectivity to the client computer systems 135 and 137. The gateway computer system 131 can be a conventional server computer system. Also, the web server system 109 can be a conventional server computer system… example of a conventional computer system that can be used as a client computer system or a server computer system or as a web server system. It will also be appreciated that such a computer system can be used to perform many of the functions of an Internet service provider…The computer system 201 interfaces to external systems… an applicant interface for receiving completed portions of a credit application from an applicant and for returning messages from the online broker to the applicant”
Evidence of the history of co-brand/affinity cards well-known and understood concept.
History by onboardpartners.com (2024)-created in late 1970’s ect…
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 17-19, 21-22 and 25-33 these dependent claim have also been reviewed with the same analysis as independent claim 16. Dependent claim 17 is directed toward insignificant extra solution activity of communicating results. Dependent claim 18 is directed toward applying technology at a high level to change a business layer (adding branding elements) when onboarding new partner channel- (spec ¶ 0070). Dependent claim 19 is directed toward adding branding elements, partner data or logic flows (task) – generic use of technology manipulate data and perform business task-business practice. Dependent claim 21 is directed toward perform underwriting, application pre-processing, post-processing, displaying branding elements in interface, submitting application and displaying status- applying technology to perform an application process and output application information- a business process. Dependent claim 22 is directed toward requesting data to be retrieved- insignificant extra solution activity. Dependent claim 25 is directed toward presenting partner specific information in partner data configuration-insignificant extra solution activity. Dependent claim 26 is directed toward onboarding user comprises new partner channel in credit product company-business practice. Dependent claim 27 is directed toward partner specific branding elements, function and configuration- business process. Dependent claim 28 is directed toward a partner specific application page create- product for business process creating a business practice. Dependent claim 29 is directed toward partner specific application page partner specific interface -well known understood technology and business practice. Dependent claim 30 is directed toward determining partner logic based on branding elements, function and data configurations-the creation of a partner specific page- business practice. Dependent claim 31 is directed toward insignificant extra solution activity of reporting configurations. Dependent claim 32 is directed toward performing credit application processes-business practice. Dependent claim 33 is directed toward user interface interactive drag drop tools used to create task flows- well understood technology .
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 16. 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 17-19, 21-22 and 25-33 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.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 16-19, 21-22 and 25-31 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Pub No. 2014/0316927 A1 by Ganesan (Ganesan) in view of US Pub No. 2014/0089185 A1 by Desai et al. (Desai) in view of in view of US Patent No. 11,132,183 B2 by Gupta et al (Gupta) and further in view of Merchant Services Application by Cayman National (Cayman).
In reference to Claim 16:
Ganesan teaches:
(Currently Amended) A credit product company system architecture ((Ganesan) in at least para 0011), comprising:
a presentation layer for presenting a user interface to a user ((Ganesan) in at least para 0019, para 0039-0040, para 0060-0061, para 0071-0072, para 0144 wherein the prior art teaches modular (layer) interfaces), wherein:
the user is a new partner, the user interface comprises an onboard configuration page for receiving onboarding information, and the user is onboarded as the new partner according to the onboarding information ((Ganesan) in at least para 0032, para 0060-0062, para 0065, para 0072, para 0101), 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 ((Ganesan) in at least FIG. 7; para 0061, para 0075, para 0088, para 0144), wherein:
the onboarding information indicates a preference of the new partner for handling customer data ((Ganesan) in at least para 0062 wherein the prior art teaches after buyers register brokering system (partner) can allow customer to create bookmarks to add preferred sellers, para 0108 wherein the partner brokering system provides anonymous communication, para 0109 wherein the brokering/partner system can broadcast customer needs),
the modular and customizable logic comprises predefined non-partner- specific functions ((Ganesan) in at least para 0061-0062, para 0108 wherein the partner brokering system provides anonymous communication, para 0109 wherein the brokering/partner system can broadcast customer needs, para 0116 wherein the brokering/partner system connects localized product/service business with customers, para 0124 wherein the prior art teaches brokering system partner sites includes yellow pages, classified listings), 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 ((Ganesan) in at least para 0071, para 0080 wherein the prior art teaches API interface for accessing information from partners/affiliates, para 0152 wherein the prior art teaches API interface to external data sources, para 0157);
services layer comprising partner data used in … product application reporting steps ((Ganesan) in at least para 0103, para 0116, para 0144, para 0150, para 0153, para 0155), wherein:
the partner data comprises data associated with a plurality of partners and new partner data ((Ganesan) in at least para 0032, para 0060-0062, para 0065, para 0072, para 0101), …
the results are determined based on the partner data and the partner configuration data, and a frequency of the reporting is determined according to the partner configuration data ((Ganesan) in at least para 0067-0068; table 1-5);
a business layer comprising a process flow engine interface, a content management system and the partner configuration data ((Ganesan) in at least FIG. 13-15; para 0019, para 0028-0031, para 0125-0126, para 0144, para 0169-0199), wherein;
the process flow engine interface interfaces with a process flow engine configured to perform …product application processing steps of the new partner, … product application reporting steps of the new partner, …according to the partner- specific logic associated with the new partner, and core logic associated with the plurality of partners and the new partner ((Ganesan) in at least para 0031-0032, para 0039-0040, para 0060-0062, para 0071-0072 wherein the prior art teaches core engine and the core product consist of modular components integrated with interfaces and core databases, para 0072-0082, para 0144-0156, para 0262-0263).,
the core logic comprises common functions for the plurality of partners and the new partner ((Ganesan) in at least para 0071-0072, para 0144-0156),
the content management system manages the partner configuration data, wherein the partner configuration data comprises configuration data associated with the plurality of partners and new partner configuration data, the new partner configuration data is determined based on the onboarding information, ((Ganesan) in at least para 0030-0032, para 0039-0041, para 0060-0062, para 0065, para 0072-0075, para 0101, para 0144, para 0262-0263), …
a data layer comprising database information, the database information comprising entities, repositories, and data transfer objects ((Ganesan) in at least para 0071, para 0144); and
a backend application that sends the onboarding information to the services layer, authenticates the new partner, checks the onboarding information, and executes partner- specific flows, wherein the partner-specific flows are determined based on the onboarding information. ((Ganesan) in at least para 0030-0032, para 0060-0062, para 0071-0082, para 0100 wherein the prior art teaches checking information, words, characters, name field, numbers; para 0103 wherein the prior art teaches security layers checking rate of request, clinging user data input, validating data and verification methods, para 0157, para 0160, para 0262-0263
Ganesan does not explicitly teach:
credit product…
services layer comprising partner data used in credit product application reporting steps,
in accordance with the user being onboarded as the new partner, the new partner data is received from a system associated with the user and external to the credit product company system, and the credit product application reporting steps comprise reporting results of the credit product application steps, wherein:
the results are determined based on the partner data and the partner configuration data, and a frequency of the reporting is determined according to the partner configuration data;
the performing the credit product application processing steps of the new partner according to the partner-specific logic comprises:
calling the partner-specific API in accordance with the instructions of the partner-specific logic,
in response to the calling the partner-specific API, receiving the customer data, wherein the customer data is encrypted according to the preference of the new partner for handling customer data,
decrypting the customer data in accordance with the instructions of the partner-specific logic, and
pre-populating a credit product application with the decrypted customer data,
the process flow engine is further configured to perform credit product application processing steps of the plurality of partners, credit product application reporting steps of the plurality of partners, and underwriting associated with the plurality of partners according to the core logic without the partner specific logic;
Desai teaches:
the onboarding the user ((Desai) in at least para 0076, para 0089-0090, para 0108-0109) comprises:
generating, based on the onboarding information, partner-specific logic, the generating comprising modifying modular and customizable logic according to the onboarding information ((Desai) in at least Fig. 6-7; para 0076, para 0084, para 0089-0090, para 0108-0109, para 0126, para 0145, para 0168, para 0210), wherein:
the onboarding information indicates a preference of the new partner for handling customer data ((Desai) in at least para 0109, para 0112, para 0115-0116, para 0121, para 0129, para 0133, para 0428, para 0525),
the modular and customizable logic comprises predefined non-partner- specific functions ((Desai) in at least para 0077, para 0086, para 0090 wherein the prior art teaches configuration module allow customizability for parameters, para 0095 wherein the prior art teaches VAS module includes library of service templates and implementation for common business services; para 0109, para 0112, para 0115-0116, para 0121, para 0129, para 0133, para 0140, para 0145-0146, para 0163, para 0168, para 0428, para 0525), 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 ((Desai) in at least FIG. 4; para 0085-0086, para 0089, para 0091, para 0097, para 0099, para 0123, para 0173, para 0206);…
the partner data comprises data associated with a plurality of partners and new partner data ((Desai) in at least FIG. 12; para 0154-0155),
in accordance with the user being onboarded as the new partner, the new partner data is received from a system associated with the user and external to the credit [financial] product company system ((Dasai) in at least para 0095, para 0154-0155, para 0248, para 0251, para 0298, para 0507, para 0521) and
the credit [financial] product application reporting steps comprise reporting results of the credit product application steps ((Dasai) in at least para 0194-0197), wherein:
the results are determined based on the partner data and the partner configuration data ((Dasai) in at least para 0169, para 0177, para 0180-0182, para 0194-0197, and…
a business layer comprising a process flow engine interface, a content management system, and the partner configuration data ((Dasai) in at least para 0084, para 0092, para 0095, para 0118-0119, para 0130, para 0142, para 0274), …
the core logic comprises common functions for the plurality of partners and the new partner ((Desai) in at least para 0095 wherein the prior art teaches VAS module includes library of service templates and implementation for common business services; para 0166),
the performing the …product application processing steps of the new partner according to the partner-specific logic comprises: calling the partner-specific API in accordance with the instructions of the partner-specific logic, in response to the calling the partner-specific API, receiving the customer data, wherein the customer data is encrypted according to the preference of the new partner for handling customer data ((Dasai) in at least Fig. 41, Fig. 44-45; para 0088, para 0099, para 0109, para 0112-0113, para 0115-0116, para 0121, para 0129, para 0133, para 0140, para 0144, para 0167-0168, para 0293, para 0357, para 0383, para 0385, para 0442, para 0448), decrypting the customer data in accordance with the instructions of the partner-specific logic ((Desai) in at least para 0099, para 0422, para 0424) , and…
the content management system manages the partner configuration data, wherein: the partner configuration data comprises configuration data associated with the plurality of partners and new partner configuration data, the new partner configuration data is determined based on the onboarding information ((Desai) in at least Fig. 6-7; para 0076, para 0084, para 0089-0090, para 0108-0109, para 0126, para 0145, para 0168, para 0210, para 0293, para 0357, para 0383, para 0385, para 0428, para 0525) , and the process flow engine is further configured to perform …[financial] product application processing steps of the plurality of partners, …[financial] product application reporting steps of the plurality of partners, … associated with the plurality of partners according to the core logic without the partner-specific logic is determined based on the new partner configuration data ((Desai) in at least para 0014, para 0087, para 0095, para 0109, para 0112, para 0115-0116, para 0121, para 0129, para 0133, para 0140, para 0142-0143, para 0159, para 0166, para 0242);
a data layer comprising database information, the database information comprising entities, repositories, and data transfer objects ((Dasai) in at least para 0093, para 0099, para 0232, para 0280, para 0382); and
a backend application that sends the onboarding information to the services layer, authenticates the new partner, checks the onboarding information, and executes partner- specific flows, wherein the partner-specific flows are determined based on the onboarding information.((Dasai) in at least para 0011, para 0014, para 0087, para 0095, para 0109, para 0112, para 0115-0116, para 0121, para 0129, para 0133, para 0140, para 0142-0143, para 0159, para 0166, para 0242)
Both Ganesan and Dasai are directed toward broker/ecosystems which provide onboarding functions and services that are customized for businesses that are branded providing interactive services to customers. Dasai teaches the motivation of providing carrier grade infrastructure platform for transactional services allowing merchants to provide secure electronic business operations among users. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the co-branded product process of Ganesan to include the onboarding components and processes of Dasai since Dasai teaches the motivation of providing carrier grade infrastructure platform for transactional services allowing merchants to provide secure electronic business operations among users.
Cayman teaches and provides supporting evidence:
in accordance with the user being onboarded as the new partner, the new partner data is received from a system associated with the user and external to the credit product company system, and the credit product application reporting steps comprise reporting results of the credit product application steps ((Cayman) see merchant services an application collecting user data and Part 1 agreements including reporting results and credit product application steps),
Both Ganesan and Cayman are direct toward a contractual process for merchants to acquire services which provide customized web pages and products with logos for commercial enterprises. Cayman teaches the motivation providing in the application process for co-brand services the product reporting steps and result of the application as part of the contractual agreement terms and conditions and other requirements. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the co-branded product process of Ganesan to include an application and agreement terms as taught by Cayman since . Cayman teaches the motivation providing in the application process for co-brand services the product reporting steps and result of the application as part of the contractual agreement terms and conditions and other requirements
Gupta teaches and provides supporting evidence:
a presentation layer for presenting a user interface to a user ((Gupta) in at least FIG. 2, FIG. 21; Col 6 lines 62-col 7 lines 1-14, Col 8 lines 14-37, Col 9 lines 15-48);
the partner-specific [online services] logic comprises instructions for calling a partner-specific[online services] application programmable interface (API) to receive the customer data …. ((Gupta) in at least FIG. 2-3; Col 7 lines 52-Col 8 lines 1-36)
services layer comprising partner data used in credit product application reporting steps ((Gupta) in at least Abstract wherein the prior art teaches deployment platform decisions with decision engine, Col 6 lines 22-41, Col 6 lines 62-col 7 lines 1-14, Col 7 lines 52-67, Col 10 lines 17-48, col 11 lines 15-28, Col 12 lines 5-48, Col 13 lines 53-Col 14 lines 1-3, lines 16-37, Col 16 lines 12-49, Col 16 lines 37-48 );
in accordance with the user being onboarded as the new partner, the new partner data is received from a system associated with the user and external to the credit product company system, and the credit product application reporting steps comprise reporting results of the credit product application steps ((Gupta) in at least FIG. 7; FIG. 11-12; Col 7 lines 52-67, Col 14 lines 60-Col 15 lines 1-40, Col 16 lines 15-col 17 lines 1-5), wherein:
the results are determined based on the partner data and the partner configuration data, and a frequency of the reporting is determined according to the partner configuration data ((Gupta) in at least FIG. 11-12;Col 11 lines 51-67, Col 23 lines 5-15, lines 43-Col 14 lines 1-49) ;
a business layer comprising a process flow engine interface, a content management system, and partner configuration data ((Gupta) in at least Col 6 lines 22-41, Col 6 lines 62-col 7 lines 1-14, Col 10 lines 17-48, col 11 lines 15-28, Col 12 lines 5-48, Col 13 lines 45-Col 14 lines 1-3, lines 16-37, Col 16 lines 12-18, Col 16 lines 20-48 );
the process flow engine interface interfaces with a process flow engine configured to perform credit product application processing steps…, the credit product application reporting steps…, and the underwriting [loan analysis and decision] …according to the partner- specific logic associated with the new partner[online services] ((Gupta) in at least FIG. 4-5, FIG. 7, FIG. 11-12, FIG. 14-16, FIG. 21; Col 7 lines 52-Col 8 lines 1-2, Col 14 lines 56-Col 15 lines 1-19, Col 23 lines 60-Col 24 lines 1-49, col 32 lines 22-54); …
the performing the credit product application processing steps of the new partner according to the partner-specific [online services] logic comprises: calling the partner-specific API in accordance with the instructions of the partner-specific logic, in response to the calling the partner-specific API, receiving the customer data, …((Gupta) in at least FIG. 2-3; Col 7 lines 52-Col 8 lines 1-36), pre-populating a credit product application with the … customer data ((Gupta) in at least Col 11 lines 5-11 wherein the prior art teaches automatically extracting, transforming (formatting) and loading data fields from one or more data sources, lines 30-43, Col 22 lines 17-28),
the process flow engine is further configured to perform credit product application processing steps of the plurality of partners, credit product application reporting steps of the plurality of partners, and underwriting associated with the plurality of partners according to the core logic without the partner specific logic ((Gupta) in at least Col 6 lines 22-41, Col 6 lines 62-col 7 lines 1-30, Col 10 lines 17-62, col 11 lines 1-28, Col 12 lines 5-67 wherein the prior art teaches autopilot component can be separate component from software development program, Col 13 lines 11-Col 14 lines 1-3, lines 16-37, Col 16 lines 12-18, Col 16 lines 20-48);
wherein the process flow engine interface interfaces with a process flow engine configured to perform the credit product application processing steps, the credit product application reporting steps, and the underwriting associated with the plurality of partners [online services ]according to the core logic without the partner specific logic ((Gupta) in at least Col 6 lines 22-41, Col 6 lines 62-col 7 lines 1-14, Col 10 lines 17-48, col 11 lines 15-28, Col 12 lines 5-67, Col 13 lines 45-Col 14 lines 1-3, lines 16-37, Col 16 lines 12-18, Col 16 lines 20-48); and
a data layer comprising database information, the database information comprising entities, repositories, and data transfer objects. ((Gupta) in at least Col 6 lines 7-41, Col 10 lines 17-56, Col 20 lines 36-54, Col 27 lines 8-20, Col 30 lines 57-65, Col 33 lines 52-57); …
Both Ganesan and Gupta are directed toward selecting decision and management software for supporting business applications. Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the co-branded product process of Ganesan to include a loan application task process of Gupta since Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users.
In reference to Claim 17:
The combination of Ganesan, Dasai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 17.
(Currently Amended) The credit product company system architecture of claim 16 (see rejection of claim 16 above),
Ganesan does not explicitly teach:
wherein the services layer communicates the results of the credit product application steps of the new partner to the system external to the credit product company system
Gupta teaches:
wherein the services layer communicates the results of the credit product application steps of the new partner to the system external to the credit product company system ((Gupta) in at least FIG. 11-12; Col 10 lines 17-47, Col 16 lines 12-18, Col 23 lines 5-15, lines 43-Col 14 lines 1-49)
Both Ganesan and Gupta are directed toward selecting decision and management software for supporting business applications. Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users which include decision reporting process and in order to allow applicable data reporting to be accessible to systems which support the user including third party external systems and service providers as well as to comply with regulatory requirements, It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the co-branded product process of Ganesan to include a loan application task process of Gupta since Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users. Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users which include decision reporting process and in order to allow applicable data reporting to be accessible to systems which support the user including third party external systems and service providers as well as to comply with regulatory requirements,
In reference to Claim 18:
The combination of Ganesan, Dasai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 18.
(Previously Presented) The credit product company system architecture of claim 16 (see rejection of claim 16 above),
wherein when onboarding a new partner channel into the credit product company system, the business layer is changed. ((Ganesan) in at least para 0032, para 0060-0062 wherein the prior art teaches templates needed for creating custom look and feel for partners as well as interface parameters, colors, fonts and images (partner specific branding elements and configurations, para 0065, para 0072, para 0101)
In reference to Claim 19:
The combination of Ganesan, Dasai, Cayman and Gupta discloses the limitations of dependent claim 18. Ganesan further discloses the limitations of dependent claim 19.
(Currently Amended) The credit product company system architecture of claim 18 (see rejection of claim 18 above),
wherein 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, adding the partner-specific logic, adding the partner-specific logic flows, or any combination thereof ((Ganesan) in at least para 0031-0032, para 0060-0062 wherein the prior art teaches templates needed for creating custom look and feel for partners as well as interface parameters, colors, fonts and images (partner specific branding elements and configurations,)
In reference to Claim 21:
The combination of Ganesan, Dasai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 21.
(Currently amended) The credit product company system architecture of claim 16 (see rejection of claim 16 above), wherein the partner-specific flows comprise:
invoking, using the process flow engine interface, …partner application pre-processing, and partner application post- processing ((Ganesan) in at least para 0020 wherein the prior art teaches user request form allowing buyer to enter product, service features, terms and other information, para 0111),
displaying, using the presentation layer, a second user interface, wherein the second user interface comprises the one or more partner-specific branding elements ((Ganesan) in at least para 0023, para 0028, para 0032, para 0040, para 0061),
receiving, via the second user interface, customer input ((Ganesan) in at least par a0030-0031, para 0089),
creating, via the services layer, the…product application further using the customer input ((Ganesan) in at least para 0040, para 0061, para 0072, para 0075);
submitting, via the services layer, the … product application ((Ganesan) in at least para 0020 wherein the prior art teaches user request form allowing buyer to enter product, service features, terms and other information),; and
Ganesan does not explicitly teach:
the process flow engine to perform the underwriting associated with the new partner,
creating, via the services layer, a credit product application using the customer input
submitting, via the services layer, the credit product application
displaying a status of the credit product application,
Cayman teaches:
receiving, via the second user interface, customer input ((Cayman) in at least Application data fields)
creating, via the services layer, the credit product application further using the customer input ((Cayman) in at least Application data fields and part 1)
Both Ganesan and Cayman are direct toward a contractual process for merchants to acquire services which provide customized web pages and products with logos for commercial enterprises. Cayman teaches the motivation providing in the application process for co-brand services the product application input fields for user application and application other requirements. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the co-branded product process of Ganesan to include an application and agreement terms as taught by Cayman since . Cayman teaches the motivation providing in the application process for co-brand services the product application input fields for user application and application other requirements.
Gupta teaches:
invoking, using the process flow engine interface, the process flow engine to perform the underwriting associated with the new partner,… ((Gupta) in at least Col 6 lines 22-41, Col 6 lines 62-col 7 lines 1-14, Col 7 lines 52-67, Col 8 lines 43-52, Col 9 lines 2-15, Col 10 lines 17-48, col 11 lines 15-28, Col 12 lines 5-48, Col 13 lines 53-Col 14 lines 1-3, lines 16-37, Col 16 lines 12-49, Col 16 lines 37-48
receiving, via the second user interface, customer input ((Gupta) in at least Col 8 lines 3-13, lines 61-Col 9 lines 1-15),
creating, via the services layer, the credit product application further using the customer input ((Gupta) in at least FIG. 3, FIG. 7; FIG. 11-12; Col 7 lines 52-67, Col 14 lines 60-Col 15 lines 1-40, Col 16 lines 15-col 17 lines 1-5);
submitting, via the services layer, the credit product application ((Gupta) in at least Col 23 lines 26-35); and
displaying a status of the credit product application ((Gupta) in at least FIG. 11-12, FIG. 14-16, ;Col 11 lines 51-67, Col 23 lines 5-15, lines 43-Col 14 lines 1-49, Col 23 lines 26-42),
Both Ganesan and Gupta are directed toward selecting decision and management software for supporting business applications. Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users which include receiving user information for product application, the application analysis and result in order to provide to the user the status of the user application decision, It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the co-branded product process of Ganesan to include a loan application task process of Gupta since Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users. Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users which include receiving user information for product application, the application analysis and result in order to provide to the user the status of the user application decision,
In reference to Claim 22:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 23.
(Previously Presented) The credit product company system architecture of claim 16 (see rejection of claim 16 above),
Ganesan does not explicitly teach:
wherein the partner-specific flows comprise requesting the backend application to retrieve customer data.
Gupta teaches:
wherein the partner-specific flows comprise requesting the backend application to retrieve customer data. ((Gupta) in at least Col 6 lines 3-13, Col 6 lines 32-41, Col 10 lines 17-35, Col 21 lines 65-Col 22 lines 1-47)
Both Ganesan and Gupta are directed toward selecting decision and management software for supporting business applications. Gupta teaches the motivation of backend components/engines and teaches data resource layer to provide functionality for data retrieval and access used in the application and decisioning process. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the layer processing the functionality of Ganesan to include the backend component for data retrieval of Gupta since Gupta teaches the motivation of backend components/engines and teaches data resource layer to provide functionality for data retrieval and access used in the application and decisioning process.
In reference to Claim 25:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 25.
(Previously Presented) The credit product company system architecture of claim 16 (see rejection of claim 16 above),
wherein the presentation layer is further for presenting a second user interface, the second user interface comprising one or more partner-specific offer information, the one or more partner- specific offer information included in the partner configuration data. ((Ganesan) in at least para 0071-0072, para 0080, para 0144)
In reference to Claim 26:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 26.
(Previously Presented) The credit product company system architecture of claim 16 (see rejection of claim 16 above),
Ganesan does not explicitly teach:
wherein the onboarding the user comprises onboarding a corresponding new partner channel into the credit product company system
Cayman teaches:
wherein the onboarding the user comprises onboarding a corresponding new partner channel into the credit product company system.((Cayman) in at least see application and part 1)
Both Ganesan and Cayman are direct toward a contractual process for merchants to acquire services which provide customized web pages and credit card products with logos for commercial enterprises. Cayman teaches the motivation providing in the application process for co-brand services the product application input fields for user application and application other requirements. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the co-branded product process of Ganesan to include an application and agreement terms as taught by Cayman since . Cayman teaches the motivation providing in the application process for co-brand services the credit card product application input fields for user application and application other requirements.
In reference to Claim 27:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 27.
(Previously Presented) The credit product company system architecture of claim 16 (see rejection of claim 16 above), wherein the onboarding information comprises
one or more partner-specific branding elements, one or more partner-specific functions, and one or more partner-specific configurations. ((Ganesan) in at least para 0031-0032, para 0060-0062 wherein the prior art teaches templates needed for creating custom look and feel for partners as well as interface parameters, colors, fonts and images (partner specific branding elements and configurations,)
In reference to Claim 28:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 28.
(Previously Presented) The credit product company system architecture of claim 16 (see rejection of claim 16 above),
wherein in accordance with the user being onboarded as the new partner, a partner-specific application page for the new partner is created. ((Ganesan) in at least para 0032, para 0060-0062 wherein the prior art teaches templates needed for creating custom look and feel for partners as well as interface parameters, colors, fonts and images (partner specific branding elements and configurations, para 0065, para 0072, para 0101)
In reference to Claim 29:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of dependent claim 28. Ganesan further discloses the limitations of dependent claim 27.
(Previously Presented) The credit product company system architecture of claim 28 (see rejection of claim 28 above), wherein the partner-specific application page comprises
a partner-specific user interface. ((Ganesan) in at least para 0030-0037, para 0039-0041, para 0072, para 0080, para 0089)
In reference to Claim 30:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 30.
(Currently amended) The credit product company system architecture of claim 16 (see rejection of claim 16 above),
wherein the partner-specific logic is determined further based on one or more partner-specific branding elements, one or more partner-specific functions, one or more partner-specific configurations , or any combination thereof. ((Ganesan) in at least para 0032, para 0060-0062, para 0065, para 0072, para 0101)
In reference to Claim 31:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 31.
(Previously Presented) The credit product company system architecture of claim 16, wherein content of the results is determined based on reporting configurations (see rejection of claim 16 above), the reporting configurations specifying one or more of:
which tables and columns to include in reports, and recipients. ((Ganesan) in at least para 0067-0068; table 1-5)
Claim(s) 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Pub No. 2014/0316927 A1 by Ganesan (Ganesan) in view of US Pub No. 2014/0089185 A1 by Desai et al. (Desai) in view of US Patent No. 11,132,183 B2 by Gupta et al (Gupta) and further in view of Merchant Services Application by Cayman National (Cayman) as applied to claim 16 above, and further in view of US Pub No. 2008/0201421 A1 by Adelman et al (Adelman)
In reference to Claim 32:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 32.
(Previously Presented) The credit product company system architecture of claim 16 (see rejection of claim 16 above),
Ganesan does not explicitly teach:
wherein in accordance with the user being onboarded as the new partner, only the partner-specific logic is tested by the process flow engine when performing the credit product application processing steps, the credit product application reporting steps,.
Gupta teaches:
wherein in accordance with the user being onboarded as the new partner, only the partner-specific logic is tested by the process flow engine when performing the credit product application processing steps, the credit product application reporting steps,. ((Gupta) in at least Abstract; FIG. 24; Col 1 lines 41-50, Col 6 lines 22-41, Col 6 lines 62-col 7 lines 1-14, Col 10 lines 17-48, col 11 lines 15-28, Col 12 lines 5-48, Col 13 lines 45-Col 14 lines 1-3, lines 16-37, Col 16 lines 12-18, Col 16 lines 20-48, Col 33 lines 18-26, Col 34 lines 25-33); and
Both Ganesan and Gupta are directed toward selecting decision and management software for supporting business applications. Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users which include decision reporting process and in order to allow applicable data reporting to be accessible to systems which support the user including third party external systems and service providers as well as to comply with regulatory requirements, It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the co-branded product process of Ganesan to include a loan application task process of Gupta since Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users. Gupta teaches the motivation of software development for online services which include loan origination and decisioning process for greater automation and control of users which include decision reporting process and in order to allow applicable data reporting to be accessible to systems which support the user including third party external systems and service providers as well as to comply with regulatory requirements,
Adelman teaches:
wherein in accordance with the user being onboarded as the new partner only the partner-specific by the process flow engine when performing the …product application processing steps, the … product application reporting steps… ((Adelman) in at least para 0019-0020, para 0063-0064)
Both Ganesan and Adelman are directed toward applying web tools to create the creation of partnered websites. Adelman teaches in the background that it is known for hosting provider to perform a text on the application in order to verify that the application conforms to a predetermined standard and available to hosting customers. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the known creation of known partnership websites/applications of Ganesan to include testing such applications as taught by Adelman since Adelman teaches in the background that it is known for hosting provider to perform a text on the application in order to verify that the application conforms to a predetermined standard and available to hosting customers.
Claim(s) 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Pub No. 2014/0316927 A1 by Ganesan (Ganesan) in view of US Pub No. 2014/0089185 A1 by Desai et al. (Desai) in view of US Patent No. 11,132,183 B2 by Gupta et al (Gupta) and further in view of Merchant Services Application by Cayman National (Cayman) as applied to claim 22 above, and further in view of EP 3296865 A1 by Panner et al (Panner) herein as annotated by the examiner
In reference to Claim 33:
The combination of Ganesan, Desai, Cayman and Gupta discloses the limitations of independent claim 16. Ganesan further discloses the limitations of dependent claim 33.
(Previously Presented) The credit product company system architecture of claim 16 (see rejection of claim 16 above),
Ganesan does not explicitly teach:
wherein the user interface allows the user to drag and drop user interface elements associated with steps to create the partner-specific flows
Panner teaches:
wherein the user interface allows the user to drag and drop user interface elements associated with steps to create the partner-specific flows. ((Panner) in at least para 0031)
Both Ganesan and Panner are directed toward applying templates in order to generate customized websites. Panner teaches the motivation of applying drag/drop tool in order to allow a client to drag a website template from a list of available templates or to edit a website template. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the application of templates for customized websites where the website can include specific font, color or other features of Ganesan to include drag/drop tool as taught by Panner since Panner teaches the motivation of applying drag/drop tool in order to allow a client to drag a website template from a list of available templates or to edit a website template.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. CA 3125542 A1 by Ellis et al; US Pub No. 2020/0118205 A1 by Bloy et al
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARY M GREGG whose telephone number is (571)270-5050. The examiner can normally be reached M-F 9am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine Behncke can be reached at 571-272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MARY M GREGG/Examiner, Art Unit 3695
Prosecution Insights