DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the application filed on 01/27/2025.
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure Statement(s) filed 01/27/2025 have been considered. Initialed copies of the Form 1449 are enclosed herewith.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 7-10 and 17-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 7-10 and 17-20 of US Patent No. 11,593,875, with independent claim 17 being directed towards the corresponding method which the system of claim 7 performs. Although the claims at issue are not identical, they are not patentably distinct from each other. The claims differ in that the limitations of claim 8, and 18 of the instant application were claimed in the independent claims of claims 7, and 17 of US Patent No. 11,593,875, outside of this difference, while the claims of the ‘875 patent are narrower, the claims can be mapped as follows in which the following limitations of ‘875 patent anticipate the instant application:
Instant Application 19037706 Claim 7
US Patent 11,593,875
A computing system, comprising:a processor; anda memory coupled to the processor, the memory storing computer-executable instructions that, when executed by the processor, configure the processor to:
7. A computing device, comprising:a processor;a communications module coupled to the processor; anda memory coupled to the processor, the memory storing instructions that, when executed, configure the processor to:
generate a code associated with one or more preferred rates of resource borrowing;
generate a first code associated with one or more preferred rates of resource borrowing; and
provide, on a client user interface on a client device, the generated code and selectable options for a rate of resource borrowing;
input received via a first user interface on the client device…
provide the first code via the first user interface and selectively enable first user interface elements corresponding to the one or more preferred rates of resource borrowing on the first user interface;
receive, via the client user interface, client selection of one of the options corresponding to a first preferred rate of resource borrowing; and
receive, via the client device, a dealer lead input including a selection of a vehicle, a selection of one of the first user interface elements corresponding to a first preferred rate of resource borrowing, and an identifier of a dealer for the selected vehicle;
in response to receiving input of the generated code via the dealer user interface, enable, on the dealer user interface, selection of the first preferred rate of resource borrowing for a resource request in connection with the client.
in response to receiving the dealer lead input, control display of resource request parameter data on the second user interface, the controlling including... in response to the authorizing, selectively enable, via the second user interface, a second user interface element corresponding to the first preferred rate of resource borrowing for the resource request, the second user interface element being enabled only upon input of the first code via the second user interface.
Therefore, since the independent claims of US Patent No. 11,593,875 anticipates every limitation of the instant application’s independent claims, the claims are rejected as being double-patenting (see MPEP 2144.04). Dependent claims 9-10, and 19-20 of the instant application recite substantially similar limitations to those of claims 2-3, 18, and 20, respectively, and therefore are anticipated US Patent No. 11,593,875.
Claims 7-10 and 17-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 7-10 and 18-20 of copending Application No. 18156491 (reference application), with independent claim 17 being directed towards the corresponding method of which the system performs. Although the claims at issue are not identical, they are not patentably distinct from each other. The claims can be mapped as follows, in which the following limitations of reference patent application anticipate the instant application:
Instant Application 19037706 Claim 7
US Patent Application 18156491
A computing system, comprising:a processor; anda memory coupled to the processor, the memory storing computer-executable instructions that, when executed by the processor, configure the processor to:
Claim 7. A computing system, comprising: a processor; and a memory coupled to the processor, the memory storing computer-executable instructions that, when executed by the processor, configure the processor to:
generate a code associated with one or more preferred rates of resource borrowing;
Claim 7 generate a first code associated with one or more preferred rates of resource borrowing;
provide, on a client user interface on a client device, the generated code and selectable options for a rate of resource borrowing;
Claim 7 cause to be displayed, via a first user interface on a client device, the first code and selectable user interface elements corresponding to the one or more preferred rates of resource borrowing;
receive, via the client user interface, client selection of one of the options corresponding to a first preferred rate of resource borrowing; and
Claim 7 receive, via the client device, a dealer lead input indicating a selection of a vehicle, a selection of a first user interface element corresponding to a first preferred rate of resource borrowing, and an identifier of a dealer for the selected vehicle;
in response to receiving input of the generated code via the dealer user interface, enable, on the dealer user interface, selection of the first preferred rate of resource borrowing for a resource request in connection with the client.
Claim 7 enabling, via the second user interface, selection of a second user interface element corresponding to the first preferred rate of resource borrowing for generation of the resource request using the second user interface based on changing a visibility status of the second user interface element, the second user interface element being enabled only upon input of the first code via the second user interface.
Therefore, since the independent claims of reference application anticipates every limitation of the instant application’s independent claim 7, and 17 for the substantially similar method, the claims are provisionally rejected as being double-patenting (see MPEP 2144.04). Dependent claims 8-10, and 18-20 of the instant application recite substantially similar limitations to those of claims 8-10 and 18-20 of the reference application, respectively, and therefore are anticipated.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7-10 and 17-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 7 recites the limitation "the dealer user interface" in 11th line of the claim. There is insufficient antecedent basis for this limitation in the claim.
Claim 17 recites the limitation "the dealer user interface" in 8th line of the claim. There is insufficient antecedent basis for this limitation in the claim.
Claims 8-10, and 18-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, by virtue of being dependent on claims 7 and 17, respectively.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more, and fails step 2 of the analysis because the focus of the claims is not on the devices themselves or a practical application but rather directed towards an abstract idea, the analysis is provided below.
Step 1 (Statutory Categories) - The claims pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a pair of related systems, and methods.
Step 2A – Prong One (Do the claims recite an abstract idea?)
Claims 1, and 11 recite an idea, in part, by:
receiving, via a client, input of a dealer lead including a selection of a vehicle and an identifier of a dealer for the selected vehicle;
in response to receiving the dealer lead input: providing, a client, selectable options for a rate of resource borrowing in connection with the dealer lead;
receiving, via the client, selection of one of the options corresponding to a first preferred rate of resource borrowing; and
enabling, a dealer, selection of the first preferred rate of resource borrowing for a resource request in connection with the dealer lead.
While varying in scope, claims 7, and 17, recite a related idea, in part, by:
generating a code associated with one or more preferred rates of resource borrowing;
providing, a client, the generated code and selectable options for a rate of resource borrowing;
receiving, via the client, client selection of one of the options corresponding to a first preferred rate of resource borrowing; and
in response to receiving input of the generated code via the dealer, enabling, the dealer, selection of the first preferred rate of resource borrowing for a resource request in connection with the client.
The steps recited above under Step 2A Prong One of the analysis under the broadest reasonable interpretation covers commercial or legal interactions (including agreements marketing or sales activities or behaviors) but for the recitation of generic computer components for coordinating sales activities between a client and dealer to allow the client to select a preferred rate of borrowing for a selected vehicle for purchasing a vehicle. That is other than reciting a processor, memory, client device, client user interface, and dealer user interface nothing in the claim elements are directed towards anything other than commercial or legal interactions as described above. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Accordingly, the claims recite an abstract idea.
Step 2A – Prong Two (Does the claim recite additional elements that integrate the judicial exception into a practical application?) - This judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of a processor, memory, client device, client user interface, and dealer user interface. The aforementioned additional elements are recited at a high level of generality such that they amount to no more than mere instructions to apply the exception using generic computer components and limit the judicial exception to the particular environment of networked computers. The claim limitations reciting enabling/providing the user interfaces to providing/selecting the preferred rate of resource borrow are claimed at a high level of generality, amounting to no more than sending and receiving data between computers over a network and tailoring information to the user for performing the abstract idea in the computer environment. Courts have recognized such operations to be insignificant extra-solution activity (see MPEP §§ 2106.04(d)(I), 2106.05(d)(ii) and MPEP 2106.05(g) as well as cases cited therein, including buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and are merely invoking the computers as tools for performing the abstract process similar to requiring the use of software to tailor information and provide it to the user on a generic computer, Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015);. Further, mere instructions to apply the judicial exception using generic computer components and limiting the judicial exception to a particular environment are not indicative of a practical application (see MPEP 2106.05(f) and MPEP 2106.05(h)). The specification does not provide any indication that the above forementioned additional elements are other than generic computer components, see [0061-0065] describing highly generic computer components used to implement the abstract idea. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed towards an abstract idea.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, with respect to integration of the abstract idea into a practical application, using the additional elements of a processor, memory, client device, client user interface, and dealer user interface t to perform the steps recited in Step 2A Prong One of the analysis amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular computer environment. Mere instructions to apply an exception using generic computer components and limiting the judicial exception to a particular environment does not provide an inventive concept. The additional elements have been considered separately, and as an ordered combination, and do not add significantly more (also known as an “inventive concept”) to the judicial exception. As explained above, controlling the display of and enabling the selection of options on user interfaces amount to sending and receiving data between computers over a network, which courts have recognized to be insignificant extra-solution activity and that is well-understood, routine and conventional (see MPEP § 2106.05(g), § 2106.05(d)(II)(i), and invoking the computers as tools for performing the abstract idea and cases cited therein. For example, MPEP 2106.05(d)(ii) provides that receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); are well-understood routine and conventional operations, similar to the instant application’s claim limitations which recite and sending and receiving data over a network to allow customers to shop for vehicles and loans for purchasing a vehicle of interest with a dealership and communicate this information to the dealership. Further, the Examiner is interpreting the providing via the interface selectable options for selection, to be akin to a displaying steps, and as discussed above, the displaying step fails to transform the claims into patent eligible material, as this is part of the field of use and technical environment in which the abstract idea is being implement and does not result in an improvement to additional elements (see MPEP 2106.05(h) Electric Power Group court decision). The claims are not patent eligible.
The dependent claims have been given the full analysis including analyzing the additional limitations both individually and in combination as a whole. For instance, the dependent claim 2 recites detect a trigger action… a trigger action is defined in [0107] of the specification as “Examples of trigger actions which may be detected by the server include, but are not limited to: receiving via the client device a pre-qualification request for qualifying to borrow a first quantity of resources from a resource lender entity…”, this is merely receiving and analyzing information, and aside from using the client device to send the request, the trigger action is akin to providing the information needed for the sales activity for acquiring a loan to purchase a product. Claims 3, 5-6, and 8-10 (and their counterparts in the method claims) further describe commercial and legal interactions but for the recitation of generic components. Claims 4 and 14 further describe the technical environment with use of digital channels to identify the origin of the dealer lead. The dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 based on the same reasoning as above and the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional limitations of the dependent claims do not amount to significantly more than the abstract idea.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-4, 6-9, 11-14, 16-19 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Sundaram, et al. (US Application Publication 2020/0372576 with priority to US Provisional Application 62/852,202 filed May 23, 2019), “Sundaram”.
As per claim 1 (and substantially similarly claimed as a method in claim 11), Sundaram discloses:
A computing system, comprising: [0098] (0139-0143 of provisional)
a processor; and [0098] (0139-0143 of provisional)
a memory coupled to the processor, the memory storing computer-executable instructions that, when executed by the processor, configure the processor to: [0102-0103] (0142-0143 of provisional)
receive, via a client device, input of a dealer lead including a selection of a vehicle and an identifier of a dealer for the selected vehicle; [0045], [0071], [0085] (0034, 0051, 0064 of provisional) In either case, whenever the selection of a product such as a vehicle intended for purchase from a user is received, the Buyer UI 101 application may encrypt the information associated with the selected vehicle (e.g., make, model, mileage, year, dealership, geographic location and/or the like) in the same universal encrypted non-lender-specific format, and transmit the information associated with the selected vehicle along with a product eligibility request to the multi-lender layer 105, via the Buy/Sell API 106 to the API Passthru 107…If all of the criteria are satisfied for a particular lender by the user's information, the lender may appear as a selectable option in the GUI 1106 of the Buyer UI 101 for a specific vehicle or vehicles… Finally, after the user is shown the offer in offer repository 204 in GUI 1006, as described above, and the user accepts the offer, the lender has two options to originate the loan from said offer. First, if there is an administrator lender associated with the multi-lender architecture, then any specific lender can opt to use an administrator lender provided API 112, and a loan origination system 112a within said administrator lender provided API 112, to generate the loan for the user.
in response to receiving the dealer lead input: provide, on a client user interface on the client device, selectable options for a rate of resource borrowing in connection with the dealer lead; [0045], [0071], [0085] (0034, 0051, 0064 of provisional) In either case, whenever the selection of a product such as a vehicle intended for purchase from a user is received, the Buyer UI 101 application may encrypt the information associated with the selected vehicle (e.g., make, model, mileage, year, dealership, geographic location and/or the like) in the same universal encrypted non-lender-specific format, and transmit the information associated with the selected vehicle along with a product eligibility request to the multi-lender layer 105, via the Buy/Sell API 106 to the API Passthru 107…If all of the criteria are satisfied for a particular lender by the user's information, the lender may appear as a selectable option in the GUI 1106 of the Buyer UI 101 for a specific vehicle or vehicles… Finally, after the user is shown the offer in offer repository 204 in GUI 1006, as described above, and the user accepts the offer, the lender has two options to originate the loan from said offer. First, if there is an administrator lender associated with the multi-lender architecture, then any specific lender can opt to use an administrator lender provided API 112, and a loan origination system 112a within said administrator lender provided API 112, to generate the loan for the user.
receive, via the client user interface, selection of one of the options corresponding to a first preferred rate of resource borrowing; and [0045], [0071], [0085] (0034, 0051, 0064 of provisional) If all of the criteria are satisfied for a particular lender by the user's information, the lender may appear as a selectable option in the GUI 1106 of the Buyer UI 101 for a specific vehicle or vehicles… Finally, after the user is shown the offer in offer repository 204 in GUI 1006, as described above, and the user accepts the offer, the lender has two options to originate the loan from said offer. First, if there is an administrator lender associated with the multi-lender architecture, then any specific lender can opt to use an administrator lender provided API 112, and a loan origination system 112a within said administrator lender provided API 112, to generate the loan for the user.
enable, on a dealer user interface, selection of the first preferred rate of resource borrowing for a resource request in connection with the dealer lead. [0039], [0045], [0071], [0085], [0096] (0034, 0050-0051, 0064, 0101 of provisional) A user may interface with Buyer UI 101, Seller UI 102, or Digital Retailer 103, in an attempt to obtain pricing information for a loan for an automobile or other good/property. In one embodiment, the Buyer UI 101, Seller UI 102, or Digital Retailer 103 application may each render different graphical user interfaces (GUIs) 1006, 1010, and 1012, respectively, as shown in the computing environment shown in FIG. 10, configured to receive input from the user which may be transmitted to the multi-lender layer 105 for further processing, for example to obtain pricing information for a loan for an automobile. The input information may be transmitted to the multi-lender layer 105 through the Buy/Sell API 106… The results are further passed back through the Multi-Lender Layer in this manner back to the Buy/Sell API in the Experience layer 104, which further passes the results back to the end-user interfaces of Buyer UI 101, Seller UI 102, or Digital Retail 103 respectively, where the encrypted data cannot be read or interpreted. Information may be communicated from the multi-lender layer 105 to the Buyer UI 101, Seller UI 102, or Digital Retailer 103 applications through the Buy/Sell API 106, to be rendered via the respective GUI. Finally, at the respective end-user interface, such as Buyer UI 101, Seller UI 102, or Digital Retailer 103, encrypted results are segregated by individual user session, wherein each such session is able to decrypt and display the contents of the encrypted outputs from the vault, to the user of said session, and thus inform a user of the lenders that they may be eligible to borrow under, the types of vehicles financed by said lenders that they may borrow for, as well as pricing-specific information such as the APR, loan term, and the like, of a prospective loan.
As per claim 2 (and substantially similarly claimed as a method in claim 12), Sundaram discloses:
wherein the instructions, when executed, further configure the processor to detect a trigger action initiated on the client device and wherein the selectable options for the rate of resource borrowing are provided via the client user interface in response to detecting the trigger action. [0075], [0090] (0056, 0068 of provisional), wherein the Examiner is interpreting the user-session to be akin to the digital channel for accessing data via the API, The API calling is driven by user action in the GUI 1006, wherein when the user chooses to explore the option of lending with a specific lender, then through the Buy/Sell API 106 a call is made to the API passthru 107, wherein an onwards call is made to the vault, wherein without a user or associate accessing the vault internally, the prequalification, product eligibility, and pricing microservices 108a, 108b, and 108c, respectively, may be run… As explained above, the data of the outputs of the microservices 108a, 108b, and 108c, resulting in the offer terms, may only be decrypted by the Buy/Sell API 106, inside each individual user-session, leaving access to said data only with said user, wherein when such a usersession is terminated, the data is associated with said user, and can only be accessed by said user.
As per claim 3 (and substantially similarly claimed as a method in claim 13), Sundaram discloses:
wherein detecting the trigger action comprises one of:
receiving, via the client device, a pre-qualification request for qualifying to borrow a first quantity of resources from a resource lender entity;
receiving, via the client device, a user input indicating an association of a selected vehicle with a dealer; [0045], [0071], [0085], (0034, 0051, 0064 of provisional) In either case, whenever the selection of a product such as a vehicle intended for purchase from a user is received, the Buyer UI 101 application may encrypt the information associated with the selected vehicle (e.g., make, model, mileage, year, dealership, geographic location and/or the like) in the same universal encrypted non-lender-specific format, and transmit the information associated with the selected vehicle along with a product eligibility request to the multi-lender layer 105, via the Buy/Sell API 106 to the API Passthru 107
receiving, via the client device, a request to perform a credit check for the entity; [0041], [0045], [0059] (0043, 0092, 0104 of provisional) With respect to a single lender as shown in FIG. 3, the user in the user-facing application 101, through the GUI 1006, may disclose their financial credentials and apply for lender prequalification under the Applicant Opts In step 302…If basic requirements for the lender are met, then the second factor assessed when executing the prequalification microservice (e.g. 108a) against provided user data is the applicant's credit score. Commonly accepted proprietary credit score models such as FICO, Equifax, Xperian, etc., may be used. In assessing the user's credit score, the Prequalification microservice (e.g. 108a) may interface with a third party service, querying external databases, such as, for example, that of Credit Bureaus, a lending terms database, a risk assessment database, or an employment confirmation database, wherein said interfacing may take place through an API call, external server FTP access, etc., to obtain information about the user's credit score, and may be reported in XML format from the external database query.
receiving, from a loan origination system, an indication of approval for resource borrowing in connection with the selected vehicle;
determining that the entity has referred a new user to a service administered via the computing system; or
receiving, via the client device, a request to access the selected vehicle.
As per claim 4 (and substantially similarly claimed as method in claim 14), Sundaram discloses:
identify a first digital channel through which the dealer lead input is received from the client device; and wherein the Examiner is interpreting the user session to read on the digital channel, [0032], [0069] (0025, 0050 of provisional) In FIG. 2, the offer repository 204 is tied to a particular user application in the application repository 203, where both repositories 203 and 204 are segregated by user session for different users. For example, for a particular user application in application repository 203, when pricing conditions are determined by the Pricing microservice 108c, these may be output to pricing repository 202. From here, the Buy/Sell API 106 may decrypt the lender-specific information associated with a particular application as lender-agnostic output from the offer repository 204, application repository 203, or pricing repository 202 to display inside of a user-session in a GUI 1009 of the Buyer UI 101, as shown in FIG. 10… The API passthru 107 then relays the standardized encrypted information to the Buy/Sell API 106, where it may then be decrypted by the Buy/Sell API only within the pricing repository 202, application repository 203, or offer repository 104, segregated by user session and corresponding to a particular application of application repository 203, such that only an individual user of the UI can read the offer details, and these details are not accessible to anyone else using or administrating the system, including the system administrator of the multi-lender architecture.
verify that the first digital channel is approved for the first preferred rate of resource borrowing. wherein the particular offer is accessible only for the session linked to the user, the Examiner is interpreting by using the session to limit what details are accessible, this is akin to verifying the session (digital channel) is approved for receiving the loan details [0069], [0090] (0025, 0050, and 0068 of provisional) the data of the outputs of the microservices 108a, 108b, and 108c, resulting in the offer terms, may only be decrypted by the Buy/Sell API 106, inside each individual user-session, leaving access to said data only with said user, wherein when such a user-session is terminated, the data left in the repositories of FIG. 2 (e.g. the application, offer, pricing terms, etc.) is associated with said user per e.g. the reference number scheme described above, and can only be accessed by said user… The API passthru 107 then relays the standardized encrypted information to the Buy/Sell API 106, where it may then be decrypted by the Buy/Sell API only within the pricing repository 202, application repository 203, or offer repository 104, segregated by user session and corresponding to a particular application of application repository 203, such that only an individual user of the UI can read the offer details, and these details are not accessible to anyone else using or administrating the system, including the system administrator of the multi-lender architecture.
As per claim 6 (and substantially similarly claimed as a method in claim 16), Sundaram discloses:
receive, via the dealer user interface, a request to generate the resource request in connection with the selected vehicle, wherein the first preferred rate of resource borrowing is enabled for submission with the resource request to a resource lender entity. [0091] (with support in [0068] of the provisional application) In an embodiment, the data outputs constituting an offer may be deleted after a pre-determined time interval. Further, when the user accepts an offer, a reference number with the terms of the offer, but without microservices outputs, can also be sent to the lender, via a third party lender API 111, the lender portal 109, or in any other known manner. Alternatively, the reference number may be presented to the user in the form of a QR code, wherein offers may be stored securely on a blockchain ledger repository or other central database hosted by the multi-lender architecture as part of the offer repository 204, which may be accessed by the dealer, through e.g. the lender portal 109, to view the terms of the offer.
As per claim 7 (and substantially similarly claimed as a method in claim 17), Sundaram discloses:
A computing system, comprising: [0098] (0139-0143 of provisional)
a processor; and [0098] (0139-0143 of provisional)
a memory coupled to the processor, the memory storing computer-executable instructions that, when executed by the processor, configure the processor to: [0099-0104] (0142-0143 of provisional)
generate a code associated with one or more preferred rates of resource borrowing; [0089] (0067 of provisional) In an embodiment, the offers portion of the pricing 108c microservice for lender specific brokers 114 within the Vault 108 may generate a reference number to correspond with a generated offer for the automobile loan. The generated offers and corresponding reference number for a plurality of lenders may be stored in one or more databases, such as the offers repository 204 in the experience layer 104. All of the offers generated during a single user session may correspond to a single reference number.
provide, on a client user interface on a client device, the generated code and selectable options for a rate of resource borrowing; [0032], [0065], [0075], [0081], [0089-0091] (0036, 0056, 0060, 0067-0068 of provisional), For example, the Buy/Sell API 106 and may use the terms output by the Pricing microservice 108c as present in the pricing repository 202 for a particular user application, to populate the fields of an offer from the offer repository 206 corresponding to the same application, inside of a GUI 1006 of the Buyer UI 101 as shown in FIG. 10, so that a user may see the terms of a potential loan by a lender, or plurality of lenders, for a specific product… displaying of the dynamically updated available lenders in the GUI 1006 for a user facing application such as the Buyer UI 101, as detailed above (e.g. greyed out if deemed ineligible, selectable and not greyed out if deemed eligible)… In an embodiment, the offers portion of the pricing 108c microservice for lender specific brokers 114 within the Vault 108 may generate a reference number to correspond with a generated offer for the automobile loan… Alternatively, the reference number may be presented to the user in the form of a QR code
receive, via the client user interface, client selection of one of the options corresponding to a first preferred rate of resource borrowing; and [0045], [0071], [0085] (0034, 0051, 0064 of provisional) In either case, whenever the selection of a product such as a vehicle intended for purchase from a user is received, the Buyer UI 101 application may encrypt the information associated with the selected vehicle (e.g., make, model, mileage, year, dealership, geographic location and/or the like) in the same universal encrypted non-lender-specific format, and transmit the information associated with the selected vehicle along with a product eligibility request to the multi-lender layer 105, via the Buy/Sell API 106 to the API Passthru 107…If all of the criteria are satisfied for a particular lender by the user's information, the lender may appear as a selectable option in the GUI 1106 of the Buyer UI 101 for a specific vehicle or vehicles… Finally, after the user is shown the offer in offer repository 204 in GUI 1006, as described above, and the user accepts the offer, the lender has two options to originate the loan from said offer. First, if there is an administrator lender associated with the multi-lender architecture, then any specific lender can opt to use an administrator lender provided API 112, and a loan origination system 112a within said administrator lender provided API 112, to generate the loan for the user.
in response to receiving input of the generated code via the dealer user interface, enable, on the dealer user interface, selection of the first preferred rate of resource borrowing for a resource request in connection with the client. [0085], [0091] (with support in [0064], [0068] of the provisional application) In an embodiment, the data outputs constituting an offer may be deleted after a pre-determined time interval. Further, when the user accepts an offer, a reference number with the terms of the offer, but without microservices outputs, can also be sent to the lender, via a third party lender API 111, the lender portal 109, or in any other known manner. Alternatively, the reference number may be presented to the user in the form of a QR code, wherein offers may be stored securely on a blockchain ledger repository or other central database hosted by the multi-lender architecture as part of the offer repository 204, which may be accessed by the dealer, through e.g. the lender portal 109, to view the terms of the offer…… Finally, after the user is shown the offer in offer repository 204 in GUI 1006, as described above, and the user accepts the offer, the lender has two options to originate the loan from said offer. First, if there is an administrator lender associated with the multi-lender architecture, then any specific lender can opt to use an administrator lender provided API 112, and a loan origination system 112a within said administrator lender provided API 112, to generate the loan for the user.
As per claim 8 (and substantially similarly claimed as a method in claim 18), Sundaram discloses:
detect a trigger action initiated on the client device and wherein the selectable options for the rate of resource borrowing are provided via the client user interface in response to detecting the trigger action. [0075], [0090] (0056, 0068 of provisional), wherein the Examiner is interpreting the user-session to be akin to the digital channel for accessing data via the API, The API calling is driven by user action in the GUI 1006, wherein when the user chooses to explore the option of lending with a specific lender, then through the Buy/Sell API 106 a call is made to the API passthru 107, wherein an onwards call is made to the vault, wherein without a user or associate accessing the vault internally, the prequalification, product eligibility, and pricing microservices 108a, 108b, and 108c, respectively, may be run… As explained above, the data of the outputs of the microservices 108a, 108b, and 108c, resulting in the offer terms, may only be decrypted by the Buy/Sell API 106, inside each individual user-session, leaving access to said data only with said user, wherein when such a usersession is terminated, the data is associated with said user, and can only be accessed by said user.
As per claim 9 (and substantially similarly claimed as a method in claim 19), Sundaram discloses:
wherein detecting the trigger action comprises one of:
receiving, via the client device, a pre-qualification request for qualifying to borrow a first quantity of resources from a resource lender entity;
receiving, via the client device, a user input indicating an association of a selected vehicle with a dealer; [0045], [0071], [0085] (0034, 0051, 0064 of provisional) In either case, whenever the selection of a product such as a vehicle intended for purchase from a user is received, the Buyer UI 101 application may encrypt the information associated with the selected vehicle (e.g., make, model, mileage, year, dealership, geographic location and/or the like) in the same universal encrypted non-lender-specific format, and transmit the information associated with the selected vehicle along with a product eligibility request to the multi-lender layer 105, via the Buy/Sell API 106 to the API Passthru 107
receiving, via the client device, a request to perform a credit check for the entity; [0041], [0045], [0059] (0043, 0092, 0104 of provisional) With respect to a single lender as shown in FIG. 3, the user in the user-facing application 101, through the GUI 1006, may disclose their financial credentials and apply for lender prequalification under the Applicant Opts In step 302…If basic requirements for the lender are met, then the second factor assessed when executing the prequalification microservice (e.g. 108a) against provided user data is the applicant's credit score. Commonly accepted proprietary credit score models such as FICO, Equifax, Xperian, etc., may be used. In assessing the user's credit score, the Prequalification microservice (e.g. 108a) may interface with a third party service, querying external databases, such as, for example, that of Credit Bureaus, a lending terms database, a risk assessment database, or an employment confirmation database, wherein said interfacing may take place through an API call, external server FTP access, etc., to obtain information about the user's credit score, and may be reported in XML format from the external database query.
receiving, from a loan origination system, an indication of approval for resource borrowing in connection with the selected vehicle;
determining that the entity has referred a new user to a service administered via the computing system; or
receiving, via the client device, a request to access the selected vehicle.
As per claims 10-14 and 16-19, claims 10-14 and 16-19 recite substantially similar limitations to those found in claims 1-4 and 6-9, respectively. Therefor claims 10-14 and 16-19 are rejected under the same art and rationale as claims 1-4 and 6-9. Furthermore, Sundaram discloses a processor implemented method [0015] (0017 of provisional).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Sundaram in view of Buerger, et al. (US Patent Application Publication 2016/0171555), “Buerger”.
As per claim 5 (and substantially similarly claimed as a method in claim 5), Sundaram does not expressly disclose the following, Buerger, however discloses:
determine a geographic region associated with the client device, and see claim 21, [0036], [0054] said home agent communicating offers to the mobile unit of one or more pre-approved loan products to the one or more clients of said financial institution, said home agent receiving and processing acceptances of said pre-approved offers from said mobile unit and facilitating fund transfer to said one or more clients on an immediate, real-time basis, said home agent processes location and proximity information received from said mobile unit to determine the type of notification message to provide to the mobile unit regarding the pre-approved loan products that are being offered to the one or more clients
wherein selection of the first preferred rate of resource borrowing is enabled on the dealer user interface in response to determining that an entity associated with the client device is associated with a first geographic region. [0090], [0136] The system preferably uploads data either directly or through an intermediate transfer means to the user's customer account database. Codes corresponding to offer tracking can be associated with customer accounts. Tracking code data can be utilized to populate a cross sell/redemption interface for use by phone center and retail sales personnel. Lending criteria may be communicated from the system to a user redemption interface to allow offer modifications based on customer redemptions… In the case of the cross-sales module (cplXsell): the FI's sales person interacts with the web-based cross sales module. The first step is to look up the customer in the system, which is done either by account number query or name query, at which point the SQL database is contacted and queried. The query returns the customer's personalized set of pre-approved offers (if any) and presents them within the user interface. The sales person may then review the offer(s), and if the sales person is successful in cross-selling a particular product, they simply click the “Accept” button to accept an offer and activate the loan.
It would have been obvious to one having ordinary skill in the finance art at the time the invention was filed to modify Sundaram with the ability to allow the retailer the option of cross-selling the loan product as taught by Buerger, doing so that the retailer has the ability to cross-sell a product and if successful accept and activate the loan [Buerger, 0090].
As per claim 15, claim 15 recites substantially similar limitations to those found in claim 5. Therefor claim 15 is rejected under the same art and rationale as claim 5. Furthermore, Sundaram discloses a processor implemented method [0015] (0017 of provisional).
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sundaram in view of Forrester (US Patent Application Publication 2015/0039490), “Forrester”.
As per claim 10 (and substantially similarly claimed as a method in claim 20), Sundaram does not expressly disclose the following, Forrester, however discloses::
receive the resource request from a first computing system associated with the identified dealer, the resource request including an indication of a first code; and [0061], [0064], [0071] Buyer system 120 may provide an approval code to the selected dealer system 130, or financial service system 110 may forward the code to system 130 along with a link to the approved financing information… In other embodiments, the buyer system 120 and/or dealer system 130 may indicate modifications to the provided sales agreement, particularly if late edits are made to the approved financing by buyer system 120 using the mobile link to the financing website discussed previously. Upon execution of the sales agreement, buyer system 120, dealer system 130, and financial service system 110 may approve the agreement and store finalized forms in their respective memory devices. Dealer system 130 may then transfer physical possession of the car to buyer system 120, and may further transmit documents and information relating to title and collateral to financial service system 110. In some embodiments, financial service system 10 may then contact buyer system 120 to configure a payment account for setting up monthly payments on the loan.
verify that the first code included in the resource request matches the generated code. [0045, 0061] The resources and information may include, as non-limiting examples, a maximum financing amount for which the prospective buyer is approved, a value or range of values of potential interest rates for a financed loan (which may be expressed in terms of annual percentage rate (APR %)), and an indicia which the prospective buyer may provide to a dealer system 130 to indicate approval. The indicia may be presented as an approval code, and may serve as a reference number for the approved financing within, for example, memories 112, 122, and 132 of the various components of system environment 100. In some embodiments, the maximum financing amount for which the buyer is approved may vary from the actual amount eventually lent to the buyer based on the particular vehicle chosen by the prospective buyer… Dealer system 130 may confirm the information associated with buyer system 120 (Step 520). For example, dealer system 130 may contact the prospective buyer to confirm personal information, verify income, confirm the time of appointment, etc. Dealer system 130 may confirm that the desired car is indeed located within inventory database 135 and is physically situated on the dealership's lot. Additionally, dealer system 130 may confirm that the desired options, trim packages, etc. are present in the specified car. The specific car may be referenced by its Vehicle Identification Number (VIN), a CarFax.RTM. reference number, or a reference number associated with the car within inventory database 135. In some embodiments, dealer system 130 may associate the specified car with the approval indicia or code associated with buyer system 120, to effectively "reserve" the car for buyer system 120 pending the buyer's appointment.
It would have been obvious to one having ordinary skill in the finance art at the time the invention was filed to modify Sundaram with the ability to provide an approval code for the customer to use to complete the purchase of a vehicle to the dealer as taught by Forrester, doing so allows the dealer to use the approval code to verify the vehicle and loan information using the approval code [Forrester, 0045, 0061, 0064].
As per claim 20, claim 20 recites substantially similar limitations to those found in claim 10. Therefor claim 20 is rejected under the same art and rationale as claim 10. Furthermore, Sundaram discloses a processor implemented method [0015] (0017 of provisional).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett Sigmond can be reached at 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
GREGORY S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694