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 . Claims 1-20 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 7/24/26 has been entered.
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.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03
Per Step 1, claim 1 is directed to a system (i.e., a machine), claim 8 to a computer program product comprising a non-transitory computer readable medium (i.e., a manufacture), and claim 15 to a method (i.e., a process). Thus, the claims are directed to statutory categories of invention. However, the claims are rejected under 35 U.S.C. 101 because they are directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application or are significantly more.
The analysis proceeds to Step 2A Prong One.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04.
Claims 1, 8, and 15 recite the following abstract idea (claim 15 being representative):
determining, in a first process flow, given a manufacturer suggested retail price (MSRP) for a vehicle and manufacturer rules, a plurality of candidate option combinations for the vehicle, wherein the first process flow comprises:
receiving input vehicle data comprising a vehicle identification number (VIN), trims, a target option MSRP for the vehicle, option codes, invoice data, and manufacturer rules, wherein the manufacturer rules include a rule setting a limit of possible option combinations of the vehicle, wherein the invoice data includes the MSRP for the vehicle;
sorting the input vehicle data by descending option MSRP values corresponding to the option codes to generate an ordered search sequence;
constructing a search tree representing all possible option combinations for the vehicle arranged according to the ordered search sequence, the search tree having a plurality of nodes, each node in the search tree representing a combination of one or more options for the vehicle;
conducting a depth-first search of the search tree to identify nodes that match the target option MSRP for the vehicle, wherein conducting the depth-first search comprises:
dynamically pruning subtrees from the search tree by calculating a constraint value representing a sum of currently-selected options and a relax value representing a sum of remaining options; and
ignoring a subtree when the constraint value exceeds the target option MSRP or when the constraint value plus the relax value is less than the target option MSRP, wherein ignoring the subtree structurally limits a total number of nodes evaluated during the depth- first search;
responsive to a value associated with the node matching the target option MSRP for the vehicle, recording an option combination represented by the node and stop searching any subtrees of the node matching the target option MSRP for the vehicle;
generating an option invoice price and an invoice price for each recorded option combination of the vehicle without using a manufacturer-set invoice price;
performing a second process flow based on the option invoice prices and the invoice prices for the vehicle determined in the first process flow, wherein the second process flow comprises:
determining a predicted invoice price based on the option invoice prices and the invoice prices generated by the first process flow for the recorded option combinations of the vehicle by:
determining a most frequent invoice price or a weighted average of the invoice prices generated by the first process flow for the recorded option combinations of the vehicle; and
selecting the most frequent invoice price or the weighted average of the invoice prices generated by the first process flow for the recorded option combinations of the vehicle as the predicted invoice price for the vehicle in lieu of the manufacturer-set invoice price for the vehicle, thereby determining the predicted invoice price without relying on the acquisition of additional third-party data;
determining an upfront price for the vehicle based on the option invoice prices and the invoice prices for each recorded option combination of the vehicle.
The abstract idea steps recited above are those which could be performed mentally, including with pen and paper. Applicant has broadly claimed receiving vehicle data, constructing a hierarchical data structure in the form of a search tree with a plurality of nodes, and determining an upfront price based on the search tree. These steps amount to ones that can be accomplished, for example, by an administrator working at a car dealership. (Examiner notes that the search tree need not necessarily be complicated, as seen in applicant’s Fig. 26.) If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the Mental Processes – Concepts Performed in the Human Mind grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Additionally and alternatively, the claim recites the abstract steps pertaining to constructing a search tree and conducting a depth-first search that includes dynamically pruning subtrees and ignoring subtrees based on criteria, as described in para. [0191]-[0199] of applicant’s specification. If a claim limitation, under its broadest reasonable interpretation, covers mathematical concepts, including mathematical relationships, mathematical formulas or equations, mathematical calculations, then it falls within the Mathematical Concepts grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Additionally and alternatively, the claim recites the abstract steps pertaining to determining an upfront price for a vehicle, i.e. a commercial interaction, as described in para. [0004] of applicant’s specification. If a claim limitation, under its broadest reasonable interpretation, covers sales activities or behaviors, then it falls within the Certain Methods of Organizing Human Activity – Commercial or Legal Interactions grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Additionally and alternatively, the claim recites the abstract steps pertaining to determining an upfront price for a vehicle according to a hierarchy of rules, as described in para. [0190] of applicant’s specification. If a claim limitation, under its broadest reasonable interpretation, covers following rules or instructions, then it falls within the Certain Methods of Organizing Human Activity – Managing Personal Behavior Relationships, Interactions Between People grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
(Examiner notes the minor differences in claim language, where claims 1 and 8 recite:
performing a first process flow, given a manufacturer suggested retail price (MSRP) for a vehicle and manufacturer rules, the first process flow producing a plurality of candidate option combinations for the vehicle, wherein the first process flow comprises.
Whereas claim 15 recites:
determining, in a first process flow, given a manufacturer suggested retail price (MSRP) for a vehicle and manufacturer rules, a plurality of candidate option combinations for the vehicle, wherein the first process flow comprises.
Both variations are abstract and part of the highlighted abstract idea.)
Step 2A Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
This judicial exception is not integrated into a practical application because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP 2106.05(f).
The claims recite the following additional elements:
Claim 1: vehicle data system; processor; non-transitory computer memory; instructions stored on the non-transitory computer memory and translatable by the processor; generating an interface and providing the generated interface over a computer network, wherein the interface comprises the determined upfront price.
Claim 8: computer program product; non-transitory computer-readable medium storing instructions translatable by a processor; generating an interface and providing the generated interface over a computer network, wherein the interface comprises the determined upfront price.
Claim 15: by a vehicle data system; the vehicle data system having a server machine operating in a network computing environment; generating an interface and providing the generated interface over a computer network, wherein the interface comprises the determined upfront price.
These elements are merely instructions to apply the abstract idea to a computer, per MPEP 2106.05(f). Applicant has only described generic computing elements in their specification, as seen in para. [0203] to [0211]. The combination of these elements is nothing more than a generic computing system, applied to the tasks of the abstract idea.
Therefore, per Step 2A Prong Two, the additional elements, alone and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B involves evaluating the additional elements to determine whether they amount to significantly more than the judicial exception itself. The examination process involves carrying over identification of the additional element(s) in the claim from Step 2A Prong Two and carrying over conclusions relating to MPEP 2106.05(f) from Step 2A Prong Two.
The additional elements and their analysis are therefore carried over: applicant has merely recited elements that instruct the user to apply the abstract idea to a computer or other machinery, per MPEP 2106.05(f).
Further, the combination of these elements is nothing more than a generic computing system, applied to the tasks of the abstract idea. When the claim elements above are considered, alone and in combination, they do not amount to significantly more.
Therefore, per Step 2B, the additional elements, alone and in combination, are not significantly more. The claims are not patent eligible.
The analysis takes into consideration all dependent claims as well:
Claims 2-4, 6-7, 9-11, 13-14, 16-18, and 20 further narrow the abstract idea, by providing additional abstract steps. This narrowed abstract idea falls into the same groupings above. Simply narrowing the abstract idea does not integrate it into practical application and is not significantly more.
Claims 5, 12, and 19 recite further additional elements (wherein the input vehicle data is obtained from one or more external data sources, wherein the one or more external data sources comprise a dealer management system (DMS), an inventory management system, a government database, a financial institution database, a sales data company database, and a manufacturer database.). Similar to above, these additional elements are simply facilitating the tasks of the abstract idea, per MPEP 2106.05(f). Whether viewed alone or in combination, this does not integrate the abstract idea into practical and/or add significantly more.
Accordingly, claims 1-20 are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
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 1, 8, and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8, and 15 of U.S. Patent No. 12,198,164 B2 in view of Computer Algorithms by Horowitz et al. (NPL attached; hereinafter Horowitz).
App. No. 18/970,568
U.S. Patent No. 12,198,164
Claims 1, 8, and 15 (Claim 1 Representative)
A vehicle data system, comprising:
a processor;
a non-transitory computer memory; and
instructions stored on the non-transitory computer memory and translatable by the processor for performing a first process flow, given a manufacturer suggested retail price (MSRP) for a vehicle and manufacturer rules,
the first process flow producing a plurality of candidate option combinations for the vehicle, wherein the first process flow comprises:
receiving input vehicle data comprising a vehicle identification number (VIN), trims, a target option MSRP for the vehicle, option codes, invoice data, and manufacturer rules,
wherein the manufacturer rules include a rule setting a limit of possible option combinations of the vehicle, wherein the invoice data includes the MSRP for the vehicle;
sorting the input vehicle data by descending option MSRP values corresponding to the option codes;
constructing a search tree representing all possible option combinations for the vehicle, the search tree having a plurality of nodes, each node in the search tree representing a combination of one or more options for the vehicle;
conducting a depth-first search of the search tree to identify nodes that match the target option MSRP for the vehicle;
responsive to a value associated with the node matching the target option MSRP for the vehicle, recording an option combination represented by the node and stopping searching any subtrees of the node matching the target option MSRP for the vehicle;
generating an option invoice price and an invoice price for each recorded option combination of the vehicle without using a manufacturer-set invoice price;
wherein the instructions when translated by the processor further perform a second process flow based on the option invoice prices and the invoice prices for the vehicle determined in the first process flow, wherein the second process flow comprises:
determining a predicted invoice price based on the option invoice prices and the invoice prices generated by the first process flow for the recorded option combinations of the vehicle by:
determining a most frequent invoice price or a weighted average of the invoice prices generated by the first process flow for the recorded option combinations of the vehicle; and
selecting the most frequent invoice price or the weighted average of the invoice prices generated by the first process flow for the recorded option combinations of the vehicle as the predicted invoice price for the vehicle in lieu of the manufacturer-set invoice price for the vehicle;
determining an upfront price for the vehicle based on the option invoice prices and the invoice prices for each recorded option combination of the vehicle; and
generating an interface and providing the generated interface over a computer network, wherein the interface comprises the determined upfront price.
Claims 1, 8, and 15 (Claim 1 Representative)
A vehicle data system, comprising:
a processor;
a non-transitory computer memory; and
stored instructions translatable by the processor […] wherein the stored instructions, when translated by the processor, perform a first process flow, given a manufacturer suggested retail price (MSRP) for a vehicle and manufacturer rules […]
the first process flow producing a plurality of candidate option combinations for the vehicle, wherein the first process flow comprises:
receiving the input vehicle data from a plurality of modules […] the input vehicle data including at least a vehicle identification number (VIN), trims, a target option MSRP for the vehicle, option codes, invoice data, and the manufacturer rules
which include a rule setting a limit of possible option combinations of the vehicle, wherein the invoice data includes the MSRP for the vehicle;
sorting the input vehicle data by descending option MSRP values corresponding to the option codes;
constructing a search tree representing all possible option combinations for the vehicle, the search tree having a plurality of nodes, each node in the search tree representing a combination of one or more options for the vehicle;
conducting a depth-first-search of the search tree, the depth-first-search including: comparing a node in the search tree with the target option MSRP for the vehicle […]
responsive to the value associated with the node matching the target option MSRP for the vehicle, recording a matching option combination represented by the node and ignoring any child of the node such that the depth-first-search returns the plurality of option combinations each of which matches the target option MSRP for the vehicle without having to search the search tree in its entirety based at least on the ignored child of the node; and
generating option invoice prices and invoice prices for the vehicle, the generating including generating an option invoice price and an invoice price for each of the plurality of matching option combinations of the vehicle without using a manufacturer-set invoice price;
wherein the stored instructions when translated by the processor further perform a second process flow based on the option invoice prices and the invoice prices for the vehicle determined in the first process flow, wherein the second process flow comprises:
determining a predicted invoice price based on the option invoice prices and the invoice prices generated by the first process flow for the plurality of matching option combinations of the vehicle by:
determining a most frequent invoice price or a weighted average of the invoice prices generated by the first process flow for the plurality of matching option combinations of the vehicle; and
selecting the most frequent invoice price or the weighted average of the invoice prices generated by the first process flow for the plurality of matching option combinations of the vehicle as the predicted invoice price for the vehicle in lieu of the manufacturer-set invoice price for the vehicle;
determining an upfront price for the vehicle based on the predicted invoice price;
generating an interface of the website, the interface providing a representation of the determined upfront price and the vehicle […].
Examiner notes that while there are slight differences in the claim language –
1) recorded option(s);
2) determining an upfront price for the vehicle based on the option invoice prices and the invoice prices for each recorded option combination of the vehicle;
3) responsive to a value associated with the node matching the target option MSRP for the vehicle, stop/stopping searching any subtrees of the node matching the target option MSRP for the vehicle;
4) sorting the input vehicle data by descending option MSRP values corresponding to the option codes to generate an ordered search sequence;
5) constructing a search tree representing all possible option combinations for the vehicle arranged according to the ordered search sequence;
6) thereby determining the predicted invoice price without relying on the acquisition of additional third-party data;
– the features are still found in the claims of U.S. Patent No. 12,198,164.
U.S. Patent No. 12,198,164 articulates in claims 1, 8, and 15 that the matching combination represents a recorded option {See: recording a matching option combination represented by the node and ignoring any child of the node such that the depth-first-search returns the plurality of option combinations each of which matches the target option MSRP for the vehicle without having to search the search tree in its entirety based at least on the ignored child of the node}.
U.S. Patent No. 12,198,164 also articulates in claims 1, 8, and 15 that the predicted upfront price is based on the option invoice prices and the invoice prices for each recorded option combination of the vehicle {See: determining a predicted invoice price based on the option invoice prices and the invoice prices generated by the first process flow for the plurality of matching option combinations}.
U.S. Patent No. 12,198,164 also articulates in claims 1, 8, and 15 that responsive to a value associated with the node matching the target option MSRP for the vehicle, stop/stopping searching any subtrees of the node matching the target option MSRP for the vehicle {See: responsive to the value associated with the node matching the target option MSRP for the vehicle, recording a matching option combination represented by the node and ignoring any child of the node such that the depth-first-search returns the plurality of option combinations each of which matches the target option MSRP for the vehicle without having to search the search tree in its entirety based at least on the ignored child of the node. Examiner notes that searching until a particular matching condition, ignoring child nodes, and subsequently returning results is equivalent to stop/stopping searching.}.
U.S. Patent No. 12,198,164 also articulates in claims 1, 8, and 15 that sorting the input vehicle data by descending option MSRP values corresponding to the option codes [generates] an ordered search sequence {See: sorting the input vehicle data by descending option MSRP values corresponding to the option codes. Examiner notes that sorting the input vehicle data by descending option MSRP values corresponding to the option codes necessarily, performed in a search tree, entails the [generation of] an ordered search sequence.}.
U.S. Patent No. 12,198,164 also articulates in claims 1, 8, and 15 that constructing a search tree representing all possible option combinations for the vehicle arranged according to the ordered search sequence {See: constructing a search tree representing all possible option combinations for the vehicle, the search tree having a plurality of nodes, each node in the search tree representing a combination of one or more options for the vehicle. Examiner notes that constructing a search tree with all possible combinations necessarily entails [arranging] according to the ordered search sequence.}.
U.S. Patent No. 12,198,164 also articulates in claims 1, 8, and 15 thereby determining the predicted invoice price without relying on the acquisition of additional third-party data {Examiner notes that this limitation describes an outcome (determining the predicted invoice price) rather than a physical structure or specific processing step. Accordingly, it is given little patentable weight.}.
U.S. Patent No. 12,198,164 doesn’t explicitly or implicitly suggest or disclose, however, Horowitz, which pertains to tree traversal and relevant to the problem at hand, teaches:
wherein conducting the depth-first search comprises {Page 348: Algorithm 7.1 presents a recursive formulation of the backtracking technique, which represents a traversal of a tree.}:
dynamically pruning subtrees from the search tree by calculating a constraint value representing a sum of currently-selected options {Page 359: SumOfSub guards each recursive call with a bounding function, and when the bound fails, the recursive call is not made and the subtree rooted at that node is never expanded. Page 359: Parameter s of SumOfSub. By its definition in 7.3, s equals the sum of w[j] over all j with x[j] = 1 and j < k, i.e., the sum of all weights currently selected along the path from root to the current node.} and a relax value representing a sum of remaining options {Page 359: Parameter r of SumOfSub. By its definition in 7.3, r equals the sum of w[j] for j >= k, i.e., the sum of all weights not yet considered.}; and
ignoring a subtree when the constraint value exceeds the target option MSRP or when the constraint value plus the relax value is less than the target option MSRP, wherein ignoring the subtree structurally limits a total number of nodes evaluated during the depth-first search {Page 359: The bounding inequality is enforced before the “include” recursion in SumOfSub: recurse on the include-branch only if s + w[k] + w[k+1] <= m, where m represents a target option, and the calculation results in [limiting] a total number of nodes evaluated during the depth-first search. Examiner notes that MSRP is simply a labeling term that doesn’t distinguish functionally and/or structurally, per MPEP 2111.05.}.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify U.S. Patent No. 12,198,164 to include the features of Horowitz, in order to facilitate traversing a state-space tree and using pruning to ignore paths that cannot meet the target sum {Pages 357-359 of Horowitz}.
Claims 1, 8, and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8, and 15 of U.S. Patent No. US 11,410,206 B2 in view of Horowitz.
App. No. 18/970,568
U.S. Patent No. 11,410,206
Claims 1, 8, and 15 (Claim 1 Representative)
A vehicle data system, comprising:
a processor;
a non-transitory computer memory; and
instructions stored on the non-transitory computer memory and translatable by the processor for performing a first process flow, given a manufacturer suggested retail price (MSRP) for a vehicle and manufacturer rules,
the first process flow producing a plurality of candidate option combinations for the vehicle, wherein the first process flow comprises:
receiving input vehicle data comprising a vehicle identification number (VIN), trims, a target option MSRP for the vehicle, option codes, invoice data, and manufacturer rules, wherein the manufacturer rules include a rule setting a limit of possible option combinations of the vehicle, wherein the invoice data includes the MSRP for the vehicle;
sorting the input vehicle data by descending option MSRP values corresponding to the option codes;
constructing a search tree representing all possible option combinations for the vehicle, the search tree having a plurality of nodes, each node in the search tree representing a combination of one or more options for the vehicle;
conducting a depth-first search of the search tree to identify nodes that match the target option MSRP for the vehicle;
responsive to a value associated with the node matching the target option MSRP for the vehicle, recording an option combination represented by the node and stopping searching any subtrees of the node matching the target option MSRP for the vehicle;
generating an option invoice price and an invoice price for each recorded option combination of the vehicle without using a manufacturer-set invoice price;
wherein the instructions when translated by the processor further perform a second process flow based on the option invoice prices and the invoice prices for the vehicle determined in the first process flow, wherein the second process flow comprises:
determining a predicted invoice price based on the option invoice prices and the invoice prices generated by the first process flow for the recorded option combinations of the vehicle by:
determining a most frequent invoice price or a weighted average of the invoice prices generated by the first process flow for the recorded option combinations of the vehicle; and
selecting the most frequent invoice price or the weighted average of the invoice prices generated by the first process flow for the recorded option combinations of the vehicle as the predicted invoice price for the vehicle in lieu of the manufacturer-set invoice price for the vehicle;
determining an upfront price for the vehicle based on the option invoice prices and the invoice prices for each recorded option combination of the vehicle; and
generating an interface and providing the generated interface over a computer network, wherein the interface comprises the determined upfront price.
Claims 1, 8, and 15 (Claim 1 Representative)
A vehicle data system, comprising:
a processor;
a non-transitory computer memory; and
stored instructions translatable by the processor, wherein the stored instructions, when translated by the processor, perform a first process flow, given a manufacturer suggested retail price (MSRP) for a vehicle and manufacturer rules,
the first process flow producing a plurality of option combinations for the vehicle, wherein the first process flow comprises:
receiving input vehicle data from a plurality of modules internal to the vehicle data system, the plurality of modules including a price adjustment module of the vehicle data system and a refiner module of the vehicle data system, the input vehicle data including at least a vehicle identification number (VIN), trims, a target option MSRP for the vehicle, option codes, invoice data, and the manufacturer rules which include a rule setting a limit of possible option combinations of the vehicle, wherein the invoice data includes the MSRP for the vehicle;
sorting the input vehicle data by descending option MSRP values corresponding to the option codes;
constructing a tree representing all possible option combinations for the vehicle, each node in the tree representing an option or an option combination for the vehicle […];
conducting a depth-first-search of the tree, the depth-first-search including: comparing a node in the tree with the target option MSRP for the vehicle; determining whether a value associated with the node is greater than the target option MSRP for the vehicle; and
responsive to the value associated with the node matching the target option MSRP for the vehicle, recording an option combination represented by the node and ignoring any child of the node such that the depth-first-search returns the plurality of option combinations each of which matches the target option MSRP for the vehicle without having to search the tree in its entirety based at least on the ignored child of the node; and
generating option invoice prices and invoice prices for the vehicle, the generating including generating an option invoice price and an invoice price for each of the plurality of option combinations of the vehicle without using a manufacturer-set invoice price;
wherein the stored instructions when translated by the processor further perform a second process flow based on the option invoice prices and the invoice prices for the vehicle determined in the first process flow, wherein the second process flow comprises:
predicting a predicted invoice price based on the option invoice prices and the invoice prices generated by the first process flow for the plurality of option combinations of the vehicle by:
determining a most frequent invoice price or a weighted average of the invoice prices generated by the first process flow for the plurality of option combinations of the vehicle; and
selecting the most frequent invoice price or the weighted average of the invoice prices generated by the first process flow for the plurality of option combinations of the vehicle as the predicted invoice price for the vehicle in lieu of the manufacturer-set invoice price for the vehicle;
determining an offer for the vehicle based on the predicted invoice price;
generating an interface providing a representation of the determined offer and the vehicle; and providing the generated interface with the determined offer over a computer network.
Examiner notes that while there are slight differences in the claim language –
1) recorded option(s);
2) the tree being a search tree;
3) determining a predicted invoice price based on the option invoice prices and the invoice prices generated by the first process flow;
4) conducting a depth-first search of the search tree to identify nodes that match the target option MSRP for the vehicle;
5) responsive to a value associated with the node matching the target option MSRP for the vehicle, stop/stopping searching any subtrees of the node matching the target option MSRP for the vehicle;
6) determining an upfront price;
7) sorting the input vehicle data by descending option MSRP values corresponding to the option codes to generate an ordered search sequence;
8) constructing a search tree representing all possible option combinations for the vehicle arranged according to the ordered search sequence;
9) thereby determining the predicted invoice price without relying on the acquisition of additional third-party data;
– the features are still found in the claims of U.S. Patent No. 11,410,206.
U.S. Patent No. 11,410,206 articulates in claims 1, 8, and 15 that the matching combination represents a recorded option {See: recording an option combination represented by the node and ignoring any child of the node such that the depth-first-search returns the plurality of option combinations each of which matches the target option MSRP for the vehicle without having to search the tree in its entirety based at least on the ignored child of the node}.
U.S. Patent No. 11,410,206 also articulates in claims 1, 8, and 15 the tree being a search tree {See: conducting a depth-first-search of the tree}.
U.S. Patent No. 11,410,206 also articulates in claims 1, 8, and 15 determining a predicted invoice price based on the option invoice prices and the invoice prices generated by the first process flow {See: predicting a predicted invoice price based on the option invoice prices and the invoice prices generated by the first process flow. Examiner notes that determining a predicted invoice and predicting a predicted invoice are equivalent.}.
U.S. Patent No. 11,410,206 also articulates in claims 1, 8, and 15 conducting a depth-first search of the search tree to identify nodes that match the target option MSRP for the vehicle {See: responsive to the value associated with the node matching the target option MSRP for the vehicle, recording an option combination represented by the node}.
U.S. Patent No. 11,410,206 also articulates in claims 1, 8, and 15 that responsive to a value associated with the node matching the target option MSRP for the vehicle, stop/stopping searching any subtrees of the node matching the target option MSRP for the vehicle {See: responsive to the value associated with the node matching the target option MSRP for the vehicle, recording an option combination represented by the node and ignoring any child of the node such that the depth-first-search returns the plurality of option combinations each of which matches the target option MSRP for the vehicle without having to search the tree in its entirety based at least on the ignored child of the node. Examiner notes that searching until a particular matching condition, ignoring child nodes, and subsequently returning results is equivalent to stop/stopping searching.}.
U.S. Patent No. 11,410,206 also articulates in claims 1, 8, and 15 determining an upfront price {See: determining an offer. Examiner notes that an upfront price and offer are equivalent, given the context evident in the claim.}.
U.S. Patent No. 11,410,206 also articulates in claims 1, 8, and 15 that sorting the input vehicle data by descending option MSRP values corresponding to the option codes [generates] an ordered search sequence {See: sorting the input vehicle data by descending option MSRP values corresponding to the option codes. Examiner notes that sorting the input vehicle data by descending option MSRP values corresponding to the option codes, performed in a search tree, necessarily entails the [generation of] an ordered search sequence.}.
U.S. Patent No. 11,410,206 also articulates in claims 1, 8, and 15 that constructing a search tree representing all possible option combinations for the vehicle arranged according to the ordered search sequence {See: constructing a search tree representing all possible option combinations for the vehicle, the search tree having a plurality of nodes, each node in the search tree representing a combination of one or more options for the vehicle. Examiner notes that constructing a search tree with all possible combinations necessarily entails [arranging] according to the ordered search sequence.}.
U.S. Patent No. 11,410,206 also articulates in claims 1, 8, and 15 thereby determining the predicted invoice price without relying on the acquisition of additional third-party data {Examiner notes that this limitation describes an outcome ("determining the predicted invoice price") rather than a physical structure or specific processing step. Accordingly, it is given little patentable weight.}.
U.S. Patent No. 11,410,206 doesn’t explicitly or implicitly suggest or disclose, however, Horowitz, which pertains to tree traversal and relevant to the problem at hand, teaches:
wherein conducting the depth-first search comprises {Page 348: Algorithm 7.1 presents a recursive formulation of the backtracking technique, which represents a traversal of a tree.}:
dynamically pruning subtrees from the search tree by calculating a constraint value representing a sum of currently-selected options {Page 359: SumOfSub guards each recursive call with a bounding function, and when the bound fails, the recursive call is not made and the subtree rooted at that node is never expanded. Page 359: Parameter s of SumOfSub. By its definition in 7.3, s equals the sum of w[j] over all j with x[j] = 1 and j < k, i.e., the sum of all weights currently selected along the path from root to the current node.} and a relax value representing a sum of remaining options {Page 359: Parameter r of SumOfSub. By its definition in 7.3, r equals the sum of w[j] for j >= k, i.e., the sum of all weights not yet considered.}; and
ignoring a subtree when the constraint value exceeds the target option MSRP or when the constraint value plus the relax value is less than the target option MSRP, wherein ignoring the subtree structurally limits a total number of nodes evaluated during the depth-first search {Page 359: The bounding inequality is enforced before the “include” recursion in SumOfSub: recurse on the include-branch only if s + w[k] + w[k+1] <= m, where m represents a target option, and the calculation results in [limiting] a total number of nodes evaluated during the depth-first search. Examiner notes that MSRP is simply a labeling term that doesn’t distinguish functionally and/or structurally, per MPEP 2111.05.}.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify U.S. Patent No. 11,410,206 to include the features of Horowitz, in order to facilitate traversing a state-space tree and using pruning to ignore paths that cannot meet the target sum {Pages 357-359 of Horowitz}.
Response to Arguments
Applicant’s arguments filed 7/24/26 have been fully considered. Examiner’s response follows, with applicant’s headings used for consistency.
Rejections under 35 U.S.C. § 101
Applicant offers (citations to specification amended claim(s) omitted for purposes of brevity):
Even if the claims were found to recite an abstract idea under Step 2A, Prong 1 (which Applicant does not concede), amended Claim 1 integrates any alleged abstract idea into a practical application. Under Step 2A, Prong 2 of the 2019 PEG, a claim that is directed to an abstract idea is eligible if it improves the functioning of a computer or other technology. Software claims are patent- eligible when they are directed to a specific asserted improvement in computer capabilities, rather than on a process that qualifies as an abstract idea for which computers are invoked merely as a tool. Enfish, LLC v. Microsoft Corp.
As amended, Claim 1 recites a specific improvement to the functioning of the computer system itself. The specification explains that processing vehicle options using conventional external queries creates a risk of strong third party data dependency and is both time and money consuming. See [0007]. To overcome these technical limitations, the specification discloses a " algorithm can smartly avoid searching unnecessary configurations and directly move along the search tree to the configurations which match the vehicle's MSRP while conforming to the required chrome logic. With the BuildX algorithm, embodiments can exhaustively search all the option combination space without actually exploring each of them specifically." See Specification at [0008].
Amended Claim 1 captures this specific technical solution by explicitly reciting the structural data manipulation and programmatic efficiencies that improve the computer system. In particular, Claim 1 recites "sorting the input vehicle data by descending option MSRP values corresponding to the option codes to generate an ordered search sequence; constructing a search tree representing all possible option combinations for the vehicle arranged according to the ordered search sequence."
By structurally limiting the node evaluation, the algorithm bypasses the computational complexity of checking every option combination, directly improving processor efficiency. Thus, the defined algorithmic data structure and pruning methodology improves the computer's processing speed while reduces network data dependency. Therefore, Claim 1 is patent-eligible under both Step 2A, Prong 2, and Step 2B, at least because Claim 1 is integrated into a practical application.
Because Claim 1, as amended, recites specific technological improvements to computer functionality that cannot practically be performed mentally, the claim is patent-eligible under 35 U.S.C. § 101. Claims 8 and 15 have been similarly amended. The dependent claims are also eligible at least by virtue of their respective dependencies. Withdrawal of the rejection is respectfully requested.
In the instant application, applicant is attempting to solve a problem related to invoice prediction, as plainly described in para. [0011]. Thus, while applicant may have arrived at an improvement to an abstract idea (i.e., the “BuildX” algorithm), this is not necessarily a technological one, as compared to Enfish. The task that applicant is attempting to accomplish, as reflected in the claims, merely relies upon a computer/computing elements used in their “ordinary capacity.” Based on MPEP 2106.05(f), this does not integrate the abstract idea into practical application.
Examiner previously highlighted para. [0203] to [0211] to showcase that the additional elements – e.g. processor, non-transitory computer memory, plurality of modules internal to the vehicle data system, computer network, etc. – are recited at a high level of generality. Applicant has listed off-the-shelf computing elements that facilitate the tasks of the abstract idea, highlighted in Step 2A Prong One. Examiner is further supported by MPEP 2106.05(a), which states:
If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology.
Based on this explanation, examiner concludes that the claim does not improve technology or improves “the functioning of a computer system itself,” as argued by applicant.
For these reasons, examiner maintains the rejections under 35 U.S.C. § 101.
Double Patenting Rejection
The Double Patenting rejections are maintained. Applicant is directed to examiner’s analysis above.
In summary, examiner has responded to all of applicant’s arguments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
“Constraint-based Vehicle Configuration: A Case Study” (NPL attached), which teaches: The existence of powerful constraint satisfaction algorithms is not the sole reason of the wide success of the CSP framework. The interest of this framework is also that it offers a generic and simple way for the modeling of real world applications. Nevertheless these applications call for tasks that often differ from a classical search for a solution. The aim of the present paper is not to provide the AI community with new and efficient algorithms, but with new requests and more generally new needs. All of them are issued from the analysis of the business needs that arise around the design and exploitation of the vehicle range at Renault, the French car manufacturer. Viewing this application as a fruitful source of research problematics for the community, we present a formalization and a theoretical study, in terms on complexity, of the series of requests risen by the application.
US 20040138771, which teaches: [0037] With reference again to FIG. 3, the process 33 determines whether a conclusion has been reached 39 (i.e., a determination is made as to whether the product 20 has been fully articulated). When uncombined components yet remain, the process 33 essentially repeats itself to facilitate the generation of additional corresponding structured product coding system entries. To illustrate, FIG. 5 depicts the complete assembly instructions for the exemplary product 20 in the form of a binary assembly tree 50 (in fact, in such an embodiment, the tree more appropriately comprises a binary assembly/disassembly tree as the information presented is relevant to a disassembly process as well as to an assembly process). In particular, in seriatim and hierarchical fashion, each component becomes eventually added to the growing product platform via a specified assembly operation. In general, it can be seen that such a binary assembly tree 50 readily defines and presents the sequence by which components are merged and the types of operations that are used to effect the merging of components.
US 20070282713, which teaches: [0138] If the style identification manager 130 determines 816 that an alternative model designation has been found, then it accesses style data 140 to find 818 the set of styles jointly matching the year, make, alternative model, and trim designation values. In essence, step 818 repeats step 802 now that a standard model designation is available to the venue 122 that may enable the style identification manager 130 to return to the trim node of the taxonomy to search for the taxonomically closest relevant set of styles to which the vehicle 110 may correspond. If 820 one or more matching styles are found, it populates 822 the SCL2 with that set styles and, retaining it, invokes process 900.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN SAMUEL WASAFF whose telephone number is (571)270-5091. The examiner can normally be reached Monday through Friday 8:00 am to 6:00 pm.
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, SARAH MONFELDT can be reached at (571) 270-1833. 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.
JOHN SAMUEL WASAFF
Primary Examiner
Art Unit 3629
/JOHN S. WASAFF/Primary Examiner, Art Unit 3629
Prosecution Insights