DETAILED ACTION
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 03/27/2026 has been entered.
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 .
Examiner’s Comment
This Action is in response to the Request for Continued Examination filed on 03/27/2026 with Amended Claims and Applicant's Remarks filed on 03/27/2026.
Applicant has amended claims 2 and 18 according to Amendments filed on 03/27/2026. Claims 2, 4, 5, 7-9, 11, 13, 15, and 17-27 are pending and currently under consideration for patentability.
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 2, 4, 5, 7-9, 11, 13, 15, and 17-27 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 10,885,562. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in U.S. Patent No. 10,885,562 recite the entirety of limitations of claims 2, 4, 5, 7-9, 11, 13, 15, and 17-27 of the instant application. For example, in the instant application independent claims 2 and 18 are anticipated by claims 1, 12, and 14 of U.S. Patent No. 10,885,562 because claims 1, 12, and 14 of U.S. Patent No. 10,885,562 recite additional features such as “an extraction device comprising a plurality of extraction databases that store vehicle records, each of the extraction databases configured to receive data records from corresponding application-specific file source databases; a vehicle alert database that receives the vehicle records from the plurality of extraction databases; at least one hardware processor in communication with the extraction device and the vehicle alert database, the at least one hardware processor configured to execute computer-executable instructions to at least: receive, over a network, vehicle records from the application-specific file source databases, wherein the vehicle records from the application-specific file source databases are associated with source data headings; based on the source data headings of the vehicle records, load the vehicle records into one or more of the plurality of extraction databases under with intermediate data headings corresponding to one or more of the source data headings; selectively remove, based on first qualifying criteria, one or more vehicle records from one or more of the plurality of extraction databases; selectively modify, based on second qualifying criteria, one or more vehicle records in one or more of the plurality of extraction databases; transfer the vehicle records to the vehicle alert database, wherein the vehicle data records comprise: a customer name for a previously sold vehicle and that customer's contact information, the customer name comprising a name of a past customer not currently shopping or looking for a new vehicle; a vehicle identification number of the previously sold vehicle; data from a deal that resulted in a previous sale to the customer, the data sufficient to show or obtain: the customer's current payment, which comprises the customer's monthly payment for the previously sold vehicle; an estimated trade value of the previously sold vehicle; and an estimated payoff amount of the previously sold vehicle; analyze the vehicle records relating to deals that resulted in the previous sales to past customers and automatically analyze a new deal proposal for all of a large set of past customers to determine which past customers are good prospects to offer a new vehicle on favorable terms, where the favorable terms comprise at least the same or lower monthly payment for the replacement vehicle, the analysis comprising: receiving changed internal data and changed external data on a periodic basis wherein the period comprises receiving the changed data dynamically, the changed data comprising data relating to new suggested vehicles for past customers and values related to the previously sold vehicles for past customers; automatically determining for each of the past customers a new suggested vehicle for the previously sold vehicle, wherein the determining comprises algorithmically associating the previously sold vehicle with one or more new suggested vehicles based on category, classification, or grouping; searching an inventory of an automotive dealer for the new suggested vehicle for the customer, thereby limiting use of computer resources by analyzing one new suggested vehicle for the determination of whether that customer is a candidate for outreach; determining a new proposed payments by: obtaining a price of the new suggested vehicle; obtaining a net trade-in equity by combining the estimated trade value with the estimated payoff amount of the previously sold vehicle, wherein the trade-in equity may be either negative equity or positive equity; determining an amount to be financed by combining the price of the new suggested vehicle with any obtained net trade-in equity, whether positive or negative; using the amount to be financed and currently-available rate information for a loan duration to determine the new proposed payment; comparing the customer's current payment and the new proposed payment to determine one or more differences; and analyzing the differences to determine if at least one of them meets a criterion to identify the customer for outreach because a new favorable deal proposal has been identified to get that customer into an upgraded vehicle comprising at least one of the new suggested vehicles; the computer system being configured to adjust at least one changed data parameter for suggested new vehicles; and iteratively analyzing whether the at least one changed data parameter increases the number of customers who can favorably get into an upgraded new suggested vehicle; and identify new revenue opportunities from the past customers that are candidates for new vehicle transactions, even when those candidates are not shopping for a new vehicle, and, for each candidate, identifying at least one specific and available new favorable deal proposal relating to a specific new suggested vehicle; transmit display instructions to a client device configured for use by a vehicle manufacturer, the display instructions configured to initiate a display comprising: a number of good prospects to offer a new vehicle on favorable terms; a budget adjustment tool configured to allow a user to input a maximum allowed budget for making deals, wherein in response to manipulation of the budget adjustment tool, the display is updated to include an updated number of good prospects while preventing access by the user to any customer name or contact information; a geographic display associated with a plurality of geographic regions, each of the plurality of geographic regions associated with a corresponding alert indicator representing a number of available new favorable deal proposals in the corresponding geographic region; and selectively restricted access to the initiated display based on whether the client device receives authorization credentials” wherein in the instant application claims 2 and 18 do not recite these features and are essentially broader than claims 1, 12, and 14 of U.S. Patent No. 10,885,562. Therefore claim 1 of U.S. Patent No. 10,885,562 is in essence a “species” of the generic invention of the instant application claim 2. It has been held that a generic invention is “anticipated” by a “species” within the scope of the generic invention. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Claims 4, 5, 7-9, 11, 13, 15, and 17 (Dependent on Claim 2) and claims 19-27 (Dependent on Claim 18) do not cure the deficiencies of the independent claims. Appropriate correction is required.
Claims 2, 4, 5, 7-9, 11, 13, 15, and 17-27 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-12 of U.S. Patent No. 11,790,420. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in U.S. Patent No. 11,790,420 recite the entirety of limitations of claims 2, 4, 5, 7-9, 11, 13, 15, and 17-27 of the instant application. For example, in the instant application independent claims 2 and 18 are anticipated by claim 1 of U.S. Patent No. 11,790,420 because claim 1 of U.S. Patent No. 11,790,420 recite additional features such as “an extraction device comprising a plurality of extraction databases that store vehicle records, each of the extraction databases configured to receive data records from application-specific file source databases; a vehicle alert database that receives the vehicle records from the plurality of extraction databases; at least one hardware processor in communication with the extraction device and the vehicle alert database, the at least one hardware processor configured to execute computer-executable instructions to at least: receive, over a network, vehicle records from the application-specific file source databases, wherein the vehicle records from the application-specific file source databases are associated with source data headings; based on the source data headings of the vehicle records, load the vehicle records into one or more of the plurality of extraction databases; selectively modify, based on second qualifying criteria, one or more vehicle records in one or more of the plurality of extraction databases; transfer the vehicle records to the vehicle alert database, wherein the vehicle data records comprise: a customer name for a previously sold vehicle and that customer's contact information, the customer name comprising a name of a past customer not currently shopping or looking for a new vehicle; a vehicle identification number of the previously sold vehicle; and data from a deal that resulted in a previous sale to the customer; analyze the vehicle records relating to deals that resulted in the previous sales to past customers and analyze a new deal proposal for each of a set of past customers to determine which past customers are good prospects to offer a new vehicle on favorable terms, where the favorable terms comprise at least the same or lower monthly payment for the replacement vehicle; identify at least one specific and available new favorable deal proposal relating to a specific new suggested vehicle; transmit display instructions to a client device configured for use by a vehicle manufacturer, the display instructions configured to initiate a display comprising: a number of the determined good prospects to offer a new vehicle on favorable terms; a budget adjustment tool configured to allow a user to input a maximum allowed budget for making deals, wherein in response to manipulation of the budget adjustment tool, the display is updated to include an updated number of good prospects while preventing access by the user to any customer name or contact information; a geographic display associated with a plurality of geographic regions, each of the plurality of geographic regions associated with a corresponding alert indicator representing a number of available new favorable deal proposals in the corresponding geographic region; and selectively restricted access to the initiated display based on whether the client device receives authorization credentials” wherein in the instant application claims 2 and 18 do not recite these features and are essentially broader than claim 1 of U.S. Patent No. 11,790,420. Therefore claim 1 of U.S. Patent No. 11,790,420 is in essence a “species” of the generic invention of the instant application claim 2. It has been held that a generic invention is “anticipated” by a “species” within the scope of the generic invention. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Claims 4, 5, 7-9, 11, 13, 15, and 17 (Dependent on Claim 2) and claims 19-27 (Dependent on Claim 18) do not cure the deficiencies of the independent claims. Appropriate correction is required.
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 2, 4, 5, 7-9, 11, 13, 15, and 17-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims are directed to a judicial exception (i.e., a law of nature, natural phenomenon, or abstract idea) without significantly more.
Step 1: In a test for patent subject matter eligibility, claims 2, 4, 5, 7-9, 11, 13, 15, and 17-27 are found to be in accordance with Step 1 (see 2019 Revised Patent Subject Matter Eligibility), as they are related to a process, machine, manufacture, or composition of matter. Claims 2, 4, 5, 7-9, 11, 13, 15, and 17 recite a method and claims 18-27 recite a system. When assessed under Step 2A, Prong I, they are found to be directed towards an abstract idea. The rationale for this finding is explained below:
Step 2A, Prong I: Under Step 2A, Prong I, claims 2 and 18 are directed to an abstract idea without significantly more, as they all recite a judicial exception. Claims 2 and 18 recite limitations directed to the abstract idea including storing vehicle-related data in a standardized format comprising a collection of vehicle-related records; receiving, from a dealer management system data source, an original equipment manufacturer data source, or a lender data source, source data in a non-standardized format; storing the converted data in the standardized format; determining, from at least the vehicle-related data and the converted data, first graphical user interface data; the first graphical user interface comprising a base alerts indicator, a geographic map, an alert indicator for each geographic section of the geographic map, and a plurality of user interface controls, wherein the geographic map is subdivided into a plurality of geographic regions and the alert indicator for each geographic section represents a base alert count for that geographic section computed before an application of an incentive amount; receiving user input corresponding to a selection of a user interface control from the plurality of user interface controls, wherein the user input comprises a transaction parameter comprising an amount or a range for a manufacturer incentive; determining, from at least the vehicle-related data, the converted data, the transaction parameter, additional alerts data; determining, from at least the additional alerts data, second graphical user interface data; the second graphical user interface comprising the base alerts indicator, an additional alerts indicator, the geographic map, an updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls; and the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic map, a further updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls. These further limitations are not seen as any more than the judicial exception. Claims 2 and 18 recite additional limitations including “in one or more non-transitory storage devices”, “via the first graphical user interface”, and “conditioning the source data into the standardized format that results in converted data; causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. The claims are considered to be an abstract idea under certain methods of organizing human activity because the claims are directed to commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) and managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) such as storing vehicle-related data, receiving original equipment manufacturer or lender data, storing converted data, determining data to be presented in a first GUI, receiving user input corresponding to a selection, and determining data to be presented in a second GUI. The claims are also considered to be an abstract idea under mental processes because the claims are directed to concepts performed in the human mind (including an observation, evaluation, judgment, opinion) such as storing data in a format, receiving data in another format, storing the data in the format, determining data to be presented in a first GUI, receiving user input corresponding to a selection, and determining data to be presented in a second GUI. Therefore, under Step 2A, Prong I, claims 2 and 18 are directed towards an abstract idea.
Step 2A, Prong II: Step 2A, Prong II is to determine whether any claim recites any additional element that integrate the judicial exception (abstract idea) into a practical application. Claims 2 and 18 recite additional limitations including “in one or more non-transitory storage devices”, “via the first graphical user interface”, and “conditioning the source data into the standardized format that results in converted data; causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. The limitations reciting – “in one or more non-transitory storage devices” and “via the first graphical user interface”, are seen as adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Accordingly, alone, and in combination, these additional elements are seen as using a computer or tool to perform an abstract idea, adding insignificant-extra-solution activity to the judicial exception. They do no more than link the judicial exception to a particular technological environment or field of use, i.e. non-transitory storage device / GUI, and therefore do not integrate the abstract idea into a practical application. The courts decided that although the additional elements did limit the use of the abstract idea, the court explained that this type of limitation merely confines the use of the abstract idea to a particular technological environment and this fails to add an inventive concept to the claims (See Affinity Labs of Texas v. DirecTV, LLC,). Under Step 2A, Prong II, this claim remains directed towards an abstract idea.
Step 2B: Claims 2 and 18 recite additional limitations including “in one or more non-transitory storage devices”, “via the first graphical user interface”, and “conditioning the source data into the standardized format that results in converted data; causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. The limitations reciting – “in one or more non-transitory storage devices” and “via the first graphical user interface” do not integrate the judicial exception (abstract idea) into a practical application because of the analysis provided in Step 2A, Prong II. Claims 2 and 18 also recite additional limitations including “conditioning the source data into the standardized format that results in converted data; causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”.
With respect to the claim limitation “conditioning the source data into the standardized format that results in converted data”. Merely reciting storing data in one format, receiving data in another format, conditioning that data into that first format, and storing the received data in the first format is seen as electronic recordkeeping and storing and retrieving information in memory. The courts have noted that “electronic recordkeeping” and “storing and retrieving information in memory” are seen as computer functions that are well‐understood, routine, and conventional when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity (See: ‘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); and ‘Storing and retrieving information in memory’, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;). Therefore, storing data in one format; receiving data in another format; conditioning that data into that first format; and storing the received data in the first format is seen as adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) and generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
With respect to the claim limitation “causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. Merely reciting generating an interface that displays interface controls that receive user input in order to display an updated graphical user interface is well-understood, routine, and conventional in the art since 1985 (See Wikipeida: User Interface – “In 1985, with the beginning of Microsoft Windows and other graphical user interfaces, IBM created what is called the Systems Application Architecture (SAA) standard which include the Common User Access (CUA) derivative.”) (See also: Richard, Stéphane. "Text User Interface Development Series Part One – T.U.I. Basics". Archived from the original on 16 November 2014. Retrieved 13 June 2014.) Therefore, causing presentation of data in a first GUI; receiving user selection and/or updated data; and in response to the received data causing presentation of data in a second or third GUI is seen as adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) and generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Claims 2 and 18 do not include additional elements or a combination of elements that result in the claims amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements listed amount to no more than mere instructions to apply an exception using a generic computer component. In addition, the applicant’s specifications describe a “general purpose computer”, ¶ [0271], for implementing the remote computing environment, which do not amount to significantly more than the abstract idea of itself, which is not enough to transform an abstract idea into eligible subject matter. Furthermore, there is no improvement in the functioning of the computer or technological field, and there is no transformation of subject matter into a different state. Under Step 2B in a test for patent subject matter eligibility, these claims are not patent eligible.
Dependent claims 4, 5, 7-9, 11, 13, 15, 17, and 19-27 further recite the method of claim 2 and system of claim 18, respectively. Dependent claims 4, 5, 7-9, 11, 13, 15, 17, and 19-27 when analyzed as a whole are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitation fail to establish that the claims are not directed to an abstract idea:
Under Step 2A, Prong I, these additional claims only further narrow the abstract idea set forth in claims 2 and 18. For example, claims 4, 5, 7-9, 11, 13, 15, 17, and 19-27 describe the limitations for storing vehicle-related data in a standardized format comprising a collection of vehicle-related records; receiving, from a dealer management system data source, an original equipment manufacturer data source, or a lender data source, source data in a non-standardized format; storing the converted data in the standardized format; determining, from at least the vehicle-related data and the converted data, first graphical user interface data; the first graphical user interface comprising a base alerts indicator, a geographic map, an alert indicator for each geographic section of the geographic map, and a plurality of user interface controls; receiving user input corresponding to a selection of a user interface control from the plurality of user interface controls, wherein the user input comprises a transaction parameter; determining, from at least the vehicle-related data, the converted data, the transaction parameter, additional alerts data; determining, from at least the additional alerts data, second graphical user interface data; the second graphical user interface comprising the base alerts indicator, an additional alerts indicator, the geographic map, an updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls; and the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic map, a further updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls – which is only further narrowing the scope of the abstract idea recited in the independent claims.
Under Step 2A, Prong II, for dependent claims 4, 5, 7-9, 11, 13, 15, 17, and 19-27, there are no additional elements introduced. Thus, they do not present integration into a practical application, or amount to significantly more.
Under Step 2B, the dependent claims do not include any additional elements that are sufficient to amount to significantly more than the judicial exception. Additionally, there is no improvement in the functioning of the computer or technological field, and there is no transformation of subject matter into a different state. As discussed above with respect to integration of the abstract idea into a practical application, the additional claims do not provide any additional elements that would amount to significantly more than the judicial exception. Under Step 2B, these claims are not patent eligible.
Claim Rejections - 35 USC § 103
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.
Claim(s) 2, 4, 5, 7-9, 11, 13, and 18-25 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication 2016/0180358 to Battista in view of U.S. Publication 2015/0363838 to Wu and U.S. Publication 2013/0253999 to Pinkus.
With respect to Claim 2:
Battista teaches:
A computer-implemented method comprising: storing vehicle-related data in a standardized format in one or more non-transitory storage devices comprising a collection of vehicle-related records (i.e. storing vehicle related data in DMS server) (Battista: ¶¶ [0045] [0046] “A dealer management system (DMS) 70 is in communication with the network 54 and the computing device 52. The application 50 is integrated with the DMS 70. The DMS 70 may be implemented on the first computing device 52 along with the application 50. The DMS 70 is a software-based management information system created for the automotive dealership 64. The DMS 70 supports different aspects of running the dealership 64, such as, but not limited to tracking sales, parts inventory, finance, and administration involved with the sale of vehicles. The DMS 70 may further provide automatic processing of purchases, warranty claims, price lists and the like…The DMS 70 includes a central server 72 which stores data provided on the DMS (hereinafter DMS data 74) thereby allowing multi-user access for a plurality of client computers.”);
storing the converted data in the standardized format in one or more non-transitory storage devices (i.e. storing commodity data that is written according to standardized format or mapping) (Battista: ¶ [0069] “In one method, the application 50 receives as an input some or all the commodities the dealership 56 sells as well as the attributes associated with each commodity. The input may be in the form of a workbook completed by dealership personnel. The application 50 allows dealership personnel to associate the commodities with different templates or deal types. The templates are mapped with the associated commodities that are set up on the DMS 70. Through this association, the application 50 allows commodities to be written back to the DMS 70 when the commodity is sold. The application 50 may also map payments and attributes of the commodities in the DMS 70.”);
determining, from at least the vehicle-related data and the converted data, first graphical user interface data (i.e. determining presentation of data based on vehicle-related data and converted/extracted data) (Battista: ¶ [0060] “FIG. 3 is a sample workflow illustrating steps surrounding implementation of the system and method. The various steps shown in FIG. 3 are described in detail below. Of course, multiple paths may exist depending on dealer process, personnel, hardware setup, or the like. For example, these steps may include, but are not limited to, extracting historical dealer data using batch extraction techniques and integrating DMS deal pulls. The DMS data 74 is fed into a customized customer interview, initiation of F&I product ratings (FIE) and extraction of vehicle data from the consumer resource. These sources are analyzed to create a combined needs/likelihood determination. The determined needs/likelihood may be used as a basis for a consumer presentation, consumer suggestions for vehicle specific OEM accessories, and/or to update manager prices/rates for the various automotive commodities. The needs/likelihood is inputted into a nexus page of the application 50, which may include dynamic tiles for customizing a product presentation for the consumer, which functions as a sales tool. After presentation, the application 50 may allow consumers to interactively waive and sign off on declining/accepting any of the automotive commodities. Afterwards, continuous integrations and updates and data extractions may occur periodically or real time from the DMS 70.”);
causing presentation, in a first graphical user interface, of the first graphical user interface data, the first graphical user interface comprising a base alerts indicator, [[a geographic map]], an alert indicator for each geographic section [[of the geographic map]], and a plurality of user interface controls (Examiner notes that “alerts” is defined in ¶ [0232] of the Applicant’s specification as “potential customers having a situation meeting the favorable deal criteria”) (i.e. displaying interview prompt, via display interface, base alerts indicator such as potential customers meeting criteria for deals on maintenance/warranty, location of the selection indicators such as maintenance/warranty parts and location including address of user, and interface controls, wherein the selection indicators provide alerts as seen in Fig. 6) (Battista: Figs. 7-9 and ¶ [0103] “The application 50 provides an interview setup interface 110, as shown in FIG. 7. The interview setup interface 110 enables easy configuration of the interview 90. The application 50 may display instructions for setting up the interview 90 and allowing for additional management of the interview 90, such as modifying existing interviews, copying interviews, and accessing the library.” Furthermore, as cited in ¶¶ [0106] [0107] “As shown in FIG. 9, the interview setup interface 110 further enables configuration of the logic values associated with responses to interview 90 questions. The logic values associated with responses to the interview 90 questions are analyzed for determining the probability of sale and value to the consumer. The application 50 analyzes the logic values to determine the importance of a particular commodity to the consumer. By incorporating logic values into the response and analyzing the logic values, the application 50 determines an increase or decrease in consumer need for the commodity or probability of sale for the commodity to the consumer. To illustrate, suppose an interview 90 question asks, "How often do you have maintenance done?" Depending on the response and associated logic values, the application 50 determines whether a prepaid maintenance plan is valuable to the consumer. Logic values associated with the responses may be derived from the numerous electronic inputs available for the interview response, including, but not limited to, numerical input, a multiple choice answer, a drop down selection, a check box selection, a date input, and the like…Based on the responses to the interview 90 questions, the application 50 may monitor value of the interview 90 with respect to tailoring the commodities offered for sale. In one example, usefulness of the interview 90 is determined by analyzing logic values in the responses. The application 50 may display value of the interview 90 on a movable scale.”);
receiving, via the first graphical user interface, user input corresponding to a selection of a user interface control from the plurality of user interface controls (i.e. receiving user selections of parameters via interface control) (Battista: ¶ [0171] “As shown in FIG. 19, the application 50 further provides a consumer options worksheet page 200 wherein the application 50 imports all suggested commodities and presents the commodities and associated payment options on a single page. Here, the application enables selection as to whether or not to present a suggested commodity. The application 50 enables editing of suggested commodity pricing, levels, coverages, and descriptions as needed.” Furthermore, as cited in ¶¶ [0106] [0107] “As shown in FIG. 9, the interview setup interface 110 further enables configuration of the logic values associated with responses to interview 90 questions. The logic values associated with responses to the interview 90 questions are analyzed for determining the probability of sale and value to the consumer. The application 50 analyzes the logic values to determine the importance of a particular commodity to the consumer. By incorporating logic values into the response and analyzing the logic values, the application 50 determines an increase or decrease in consumer need for the commodity or probability of sale for the commodity to the consumer. To illustrate, suppose an interview 90 question asks, "How often do you have maintenance done?" Depending on the response and associated logic values, the application 50 determines whether a prepaid maintenance plan is valuable to the consumer. Logic values associated with the responses may be derived from the numerous electronic inputs available for the interview response, including, but not limited to, numerical input, a multiple choice answer, a drop down selection, a check box selection, a date input, and the like…Based on the responses to the interview 90 questions, the application 50 may monitor value of the interview 90 with respect to tailoring the commodities offered for sale. In one example, usefulness of the interview 90 is determined by analyzing logic values in the responses. The application 50 may display value of the interview 90 on a movable scale.”),
wherein the user input comprises a transaction parameter comprising an amount or a range for a manufacturer incentive (i.e. providing manufacturer/dealer with display interface to allow price edits and/or cost per period or range for manufacturer incentive) (Battista: Fig. 18 and ¶ [0171] “As shown in FIG. 19, the application 50 further provides a consumer options worksheet page 200 wherein the application 50 imports all suggested commodities and presents the commodities and associated payment options on a single page. Here, the application enables selection as to whether or not to present a suggested commodity. The application 50 enables editing of suggested commodity pricing, levels, coverages, and descriptions as needed. The consumer worksheet page imports D MS data 7 4, such as APR and Cash Down information. The application 50 calculates the payment for each suggested commodity. Generally, dealership personnel manipulate the information on the consumer worksheet page.” Furthermore, as cited in ¶ [0173] “The declination page 220 also provides the ability to make edits (e.g., price, name, level, description). To increase the probability of last-minute sales before consumer declination, the declination page 220 further provides a selection of the cost per period for each commodity. As shown in FIG. 21, the cost per period is selected as "per week."”);
determining, from at least the vehicle-related data, the converted data, the transaction parameter, additional alerts data (i.e. determining other consumers or future groups of consumers for a suggested commodity, such as appearance protection, based on interview selection parameters or transaction parameters, vehicle related data, and extracted/converted data) (Battista: ¶¶ [0159] [0160] “In one example, the suggested commodity in the presentation 190 is an appearance protection commodity. The application 50 generates the presentation 190 having text identifying the consumer and the vehicle being purchased. The presentation 190 provides commentary identifying the importance of the appearance protection commodity, i.e., that degraded condition and appearance of the vehicle can cause a loss of value to the vehicle. The presentation 190 suggests to the consumer that purchasing the appearance protection commodity is more likely to preserve the value of the vehicle. The application 50 imports into the presentation 190 consumer resource data 82. Here, the imported consumer resource data 82 is a condition adjustment range for the specific vehicle. The application 50 imports vehicle make, model, and year information and coverage terms from DMS data 74 or interview response data 92. The application 50 is configured to calculate a cost per period of protecting the vehicle using the appearance protection commodity (as configured in the setting)…In another example, the presentation 190 is entitled "consumer needs analysis" for promoting to the consumer that the presentation 190 is customized to the consumer's needs. The presentation 190 presents information about the consumer and the dealership based on imported the DMS data 74. The presentation 190 includes graphics relating to the dealership, such as a dealership logo or trademark.” Furthermore, as cited in ¶ [0115] “Examples of some group consumer data includes, consumers who have previously purchased the vehicle of interest, vehicles similar to the vehicle of interest, or automotive commodities associated with the vehicle of interest. The group consumer data may be indicative of at least one of past needs of the other consumers, historical behavior of the other consumers, and/or demographics of the other consumers. The group consumer data 120 may include past, present, or future data relating to other customers.”);
determining, from at least the additional alerts data, second graphical user interface data (i.e. determining presentation of suggested commodity based on needs of potential consumers) (Battista: ¶¶ [0159] [0160] “In one example, the suggested commodity in the presentation 190 is an appearance protection commodity. The application 50 generates the presentation 190 having text identifying the consumer and the vehicle being purchased. The presentation 190 provides commentary identifying the importance of the appearance protection commodity, i.e., that degraded condition and appearance of the vehicle can cause a loss of value to the vehicle. The presentation 190 suggests to the consumer that purchasing the appearance protection commodity is more likely to preserve the value of the vehicle. The application 50 imports into the presentation 190 consumer resource data 82. Here, the imported consumer resource data 82 is a condition adjustment range for the specific vehicle. The application 50 imports vehicle make, model, and year information and coverage terms from DMS data 74 or interview response data 92. The application 50 is configured to calculate a cost per period of protecting the vehicle using the appearance protection commodity (as configured in the setting)…In another example, the presentation 190 is entitled "consumer needs analysis" for promoting to the consumer that the presentation 190 is customized to the consumer's needs. The presentation 190 presents information about the consumer and the dealership based on imported the DMS data 74. The presentation 190 includes graphics relating to the dealership, such as a dealership logo or trademark.” Furthermore, as cited in ¶ [0115] “Examples of some group consumer data includes, consumers who have previously purchased the vehicle of interest, vehicles similar to the vehicle of interest, or automotive commodities associated with the vehicle of interest. The group consumer data may be indicative of at least one of past needs of the other consumers, historical behavior of the other consumers, and/or demographics of the other consumers. The group consumer data 120 may include past, present, or future data relating to other customers.”);
causing presentation, in a second graphical user interface, of the second graphical user interface data, the second graphical user interface comprising the base alerts indicator, an additional alerts indicator, [[the geographic map]], an updated alert indicator for each geographic section [[of the geographic map]], and the plurality of user interface controls (i.e. display of suggested commodity includes commodity selection parameters, suggested commodity selections, location related to user and commodity, and updated information corresponding to location of suggested commodity) (Battista: Figs. 13-19 and ¶¶ [0162]-[0164] “A third suggested commodity in the presentation 190 may be an appearance protection package. From interview response data 92, the presentation 190 reminds the consumer that the consumer typically does not keep the vehicle under covered parking. From DMS data 72 relating to location of consumer residence and related weather conditions for that location, the presentation 190 informs the consumer of the adverse effects of the local weather on the appearance of the vehicle being purchased. From DMS data 72 relating to the manufacturer warranty of the vehicle being purchased, the presentation 190 informs the consumer that paint is not covered under warranty. From DMS data 72 and interview response data 92, the presentation 190 explains that most consumers who plan to keep their vehicle for at least 5 years are interested in keeping their vehicle is new cosmetic condition to increase resale value. From consumer resource data 82, the presentation 190 informs the consumer that the expected resale of the specific vehicle being purchased could fluctuate up to 61 % depending on physical appearance. The presentation 190 reiterates the suggested appearance protection plan for purchase based on the presented information. Various other combinations of suggestions and underlying integrated data may be utilized or contemplated besides those described herein and shown in FIG. 17…Of course, the application 50 is configured to generate the presentation 190 for any suggested commodity available for sale to the consumer. Other examples of presentations 190 include, but are not limited to, a pre-paid maintenance presentation 190, tire and wheel repair plan, a GAP protection presentation, a security plan presentation, and the like. In the security plan presentation, for example, the application 50 may import consumer resource data 82 regarding vehicle security, such as theft rates per area or most stolen vehicles…Since the presentation 50 is interactive, the application may configure the presentation to have interactive elements such that the consumer can click into the presentation to learn more about certain objects. For example, the presentation may include a "more info" type button to help the consumer learn about the suggested commodity.”); and
in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, [[the geographic map]], a further updated alert indicator for each geographic section [[of the geographic map]], and the plurality of user interface controls (i.e. providing an interface which displays updated information of commodity selections, recommendations, locations related to user and suggested commodities, and interface controls) (Battista: Figs. 13-24 and ¶ [0164] “Since the presentation 50 is interactive, the application may configure the presentation to have interactive elements such that the consumer can click into the presentation to learn more about certain objects. For example, the presentation may include a "more info" type button to help the consumer learn about the suggested commodity. Once the consumer selects this button, the presentation may open, for example, a pop-up window, or redirect the consumer to a separate page having the appropriate information. Such information may be hosted by the application 50 or any suitable server in communication with the application 50 or presentation. The application 50 may allow real time remote implementation wherein the application can take over the customer's device in seconds with the interactive presentation.” Furthermore, as cited in ¶ [0172] “As shown in FIG. 20, the application 50 outputs a commodities summary 210 based on the settings set forth in the consumer options worksheet page 200. The commodities summary 210 is electronically presented by the application 50 and sets forth the suggested commodities and the associated payment options for suggested commodities. In one embodiment, the suggested commodities are dynamic and interactive such that when selected electronically ( clicked) the electronic summary updates and displays the corresponding payment options for the selected commodity. The commodities summary page 210 can have various other configurations.”).
Battista does not explicitly disclose receiving, from a dealer management system data source, an original equipment manufacturer data source, or a lender data source, source data in a non-standardized format; and conditioning the source data into the standardized format that results in converted data.
However, Wu further discloses:
receiving, from a dealer management system data source, an original equipment manufacturer data source, or a lender data source, source data in a non-standardized format (i.e. receiving inventory equipment data and manufacturer data in a variety of formats such as polling or web crawling) (Wu: ¶ [0049] “Inventory companies 140 may be one or more inventory polling companies, inventory management companies or listing aggregators which may obtain and store inventory data from one or more of dealers 130 (for example, obtaining such data from DMS 132). Inventory polling companies are typically commissioned by the dealer to pull data from a DMS 132 and format the data for use on websites and by other systems. Inventory management companies manually upload inventory information (photos, description, specifications) on behalf of the dealer. Listing aggregators get their data by "scraping" or "spidering" websites that display inventory content and receiving direct feeds from listing websites (for example, Autotrader, FordVehicles.com).” Furthermore, as cited in ¶ [0053] “Manufacturers 150 are those entities which actually build the vehicles sold by dealers 130. In order to guide the pricing of their vehicles, manufacturers 150 may provide an Invoice price and a Manufacturer's Suggested Retail Price (MSRP) for both vehicles and options for those vehicles-to be used as general guidelines for the dealer's cost and price. These fixed prices are set by the manufacturer and may vary slightly by geographic region.”); and
conditioning the source data into the standardized format that results in converted data (i.e. data is formatted for use in websites which results in converted data or data is cleansed/conditioned) (Wu: ¶ [0049] “Inventory companies 140 may be one or more inventory polling companies, inventory management companies or listing aggregators which may obtain and store inventory data from one or more of dealers 130 (for example, obtaining such data from DMS 132). Inventory polling companies are typically commissioned by the dealer to pull data from a DMS 132 and format the data for use on websites and by other systems. Inventory management companies manually upload inventory information (photos, description, specifications) on behalf of the dealer. Listing aggregators get their data by "scraping" or "spidering" websites that display inventory content and receiving direct feeds from listing websites (for example, Autotrader, FordVehicles.com).” Furthermore, as cited in ¶ [0103] “Once the desired data is obtained, the obtained data may be cleansed at step 420. In particular, the data obtained may not be useful if it is inaccurate, duplicative or does not conform to certain parameters. Therefore, the vehicle data system may cleanse obtained data to maintain the overall quality and accuracy of the data presented to end users. This cleansing process may entail the removal or alteration of certain data based on almost any criteria desired, where these criteria may, in turn, depend on other obtained or determined data or the evaluation of the data to determine if it conforms with known values, falls within certain ranges or is duplicative. When such data is found it may be removed from the data store of the vehicle data system, the values which are incorrect or fall outside a threshold may be replaced with one or more values (which may be known specifically or be default values), or some other action entirely may be taken.”).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time the invention was made, to add Wu’s receiving, from a dealer management system data source, an original equipment manufacturer data source, or a lender data source, source data in a non-standardized format; and conditioning the source data into the standardized format that results in converted data to Battista’s in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic data, a further updated alert indicator for each geographic section of the geographic data, and the plurality of user interface controls. One of ordinary skill in the art would have been motivated to do so in order to “provide high accuracy of invoice prediction, which can help to improve the data coverage of vehicle inventories” and “help to avoid the risk of third party data reliance, providing a robust solution in generating actionable data.” (Wu: ¶ [0011]).
Battista and Wu do not explicitly disclose causing presentation, in a first graphical user interface, of the first graphical user interface data, the first graphical user interface comprising a base alerts indicator, a geographic map, an alert indicator for each geographic section of the geographic map, and a plurality of user interface controls; causing presentation, in a second graphical user interface, of the second graphical user interface data, the second graphical user interface comprising the base alerts indicator, an additional alerts indicator, the geographic map, an updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic map, a further updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls.
However, Pinkus further discloses:
causing presentation, in a first graphical user interface, of the first graphical user interface data, the first graphical user interface comprising a base alerts indicator, a geographic map, an alert indicator for each geographic section of the geographic map, and a plurality of user interface controls, wherein the geographic map is subdivided into a plurality of geographic regions and the alert indicator for each geographic section represents a base alert count for that geographic section computed before application of an incentive amount (i.e. generating user interface comprising deal alerts for customers, geographic map, and user interface controls, wherein the geographic map is subdivided into regions/sections and number of deals for each geographic section) (Pinkus: ¶¶ [0092] [0093] “Geographic restriction user interface 900 advantageously allows a user to select regions where deals may run, or exclude regions where deals may not run. Geographic restriction interface 900 may permit more than one region of inclusion of exclusion. Geographic restriction user interface 900 may include map element 905. Map element 905 may, in some embodiments, be implemented using a well known mapping tool or API, such as, for example, Google Maps, Falcon View, or any other readily available mapping tool that allows for overlay of graphics. Map element 905 may provide for zoom tools and navigation tools that allows a user to manipulate the map so that they may view the location for where they would like to place a geographic restriction. A user may, for example, select a region of the map with a selection tool and draw border 910 around a region of the map. Once the border has been drawn on the map, the user may select whether the region is to be inclusive or exclusive using radio buttons 920. For example, if the user would like the deal to run only within inside the selected region, then the user would select the "Inclusive" radio button. Geographic restriction interface 900, in some embodiments, may allow for the user to create multiple regions for where deals should be displayed. For example, the user may define a large "inclusive" region, and then define a smaller "exclusive" region inside the large "inclusive" region where the deal would not be offered, if the user (vendor) desired not to present the deal in a particular neighborhood or business area… In one embodiment, once the vendor has completed entering the deal information using the user interfaces of FIGS. 6-9, the deal information may be communicated by vendor system 310 to deal manager 300 where deal definition module 305 may process the deal definition and store it in data store 303. In some embodiments, deals may be updated. The vendor may access a saved deal through user interface similar to the ones illustrated in FI GS. 6-9. The user interface used for creating a new deal definition may also be used for modifying a deal definition by pre-populating the user interfaces with a saved deal definition information. Deal manager 300 may provide a list in the user interface for the vendor that allows the vendor to select from predefined deals, and may allow the vendor to modify those predefined deals. In some embodiments, vendor system 310 may execute an application for updating a deal definition. Vendor system 310 may be, for example, a mobile computing device with a mobile application. The mobile application may provide the ability to alter details of the deal, such as the price, the time the deal should launch, or deal text. In some embodiments, a predefined deal may be launched on demand. For example, the user of vendor system 310 may wish to launch a deal to stimulate business. FIG. 10 shows one embodiment of user interface 1000 for launching a deal on-demand. User interface 1000 allows for the input of the number of deals available in text field 1010 and the price of the deal in text field 1020. The user interface 1000 also provides launch button 103 which will launch the deal "on-demand." In another embodiment the functions of the vendor system 310 may advantageously be made a part of the deal manager 300 and the input from the vendor as well as communication with the vendor's in-house inventory management system may be provided through the internet and a browser interface.”);
causing presentation, in a second graphical user interface, of the second graphical user interface data, the second graphical user interface comprising the base alerts indicator, an additional alerts indicator, the geographic map, an updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls (i.e. generating user interface comprising deal alerts for customers, additional or updated deal alerts for consumers on geographic map, and user interface controls) (Pinkus: ¶¶ [0092] [0093] “Geographic restriction user interface 900 advantageously allows a user to select regions where deals may run, or exclude regions where deals may not run. Geographic restriction interface 900 may permit more than one region of inclusion of exclusion. Geographic restriction user interface 900 may include map element 905. Map element 905 may, in some embodiments, be implemented using a well known mapping tool or API, such as, for example, Google Maps, Falcon View, or any other readily available mapping tool that allows for overlay of graphics. Map element 905 may provide for zoom tools and navigation tools that allows a user to manipulate the map so that they may view the location for where they would like to place a geographic restriction. A user may, for example, select a region of the map with a selection tool and draw border 910 around a region of the map. Once the border has been drawn on the map, the user may select whether the region is to be inclusive or exclusive using radio buttons 920. For example, if the user would like the deal to run only within inside the selected region, then the user would select the "Inclusive" radio button. Geographic restriction interface 900, in some embodiments, may allow for the user to create multiple regions for where deals should be displayed. For example, the user may define a large "inclusive" region, and then define a smaller "exclusive" region inside the large "inclusive" region where the deal would not be offered, if the user (vendor) desired not to present the deal in a particular neighborhood or business area… In one embodiment, once the vendor has completed entering the deal information using the user interfaces of FIGS. 6-9, the deal information may be communicated by vendor system 310 to deal manager 300 where deal definition module 305 may process the deal definition and store it in data store 303. In some embodiments, deals may be updated. The vendor may access a saved deal through user interface similar to the ones illustrated in FI GS. 6-9. The user interface used for creating a new deal definition may also be used for modifying a deal definition by pre-populating the user interfaces with a saved deal definition information. Deal manager 300 may provide a list in the user interface for the vendor that allows the vendor to select from predefined deals, and may allow the vendor to modify those predefined deals. In some embodiments, vendor system 310 may execute an application for updating a deal definition. Vendor system 310 may be, for example, a mobile computing device with a mobile application. The mobile application may provide the ability to alter details of the deal, such as the price, the time the deal should launch, or deal text. In some embodiments, a predefined deal may be launched on demand. For example, the user of vendor system 310 may wish to launch a deal to stimulate business. FIG. 10 shows one embodiment of user interface 1000 for launching a deal on-demand. User interface 1000 allows for the input of the number of deals available in text field 1010 and the price of the deal in text field 1020. The user interface 1000 also provides launch button 103 which will launch the deal "on-demand." In another embodiment the functions of the vendor system 310 may advantageously be made a part of the deal manager 300 and the input from the vendor as well as communication with the vendor's in-house inventory management system may be provided through the internet and a browser interface.”); and
in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic map, a further updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls (i.e. in response to receiving real-time request or data, generating user interface comprising updated deal alerts for customers, geographic map, and user interface controls) (Pinkus: ¶¶ [0092]-[0094] “Geographic restriction user interface 900 advantageously allows a user to select regions where deals may run, or exclude regions where deals may not run. Geographic restriction interface 900 may permit more than one region of inclusion of exclusion. Geographic restriction user interface 900 may include map element 905. Map element 905 may, in some embodiments, be implemented using a well known mapping tool or API, such as, for example, Google Maps, Falcon View, or any other readily available mapping tool that allows for overlay of graphics. Map element 905 may provide for zoom tools and navigation tools that allows a user to manipulate the map so that they may view the location for where they would like to place a geographic restriction. A user may, for example, select a region of the map with a selection tool and draw border 910 around a region of the map. Once the border has been drawn on the map, the user may select whether the region is to be inclusive or exclusive using radio buttons 920. For example, if the user would like the deal to run only within inside the selected region, then the user would select the "Inclusive" radio button. Geographic restriction interface 900, in some embodiments, may allow for the user to create multiple regions for where deals should be displayed. For example, the user may define a large "inclusive" region, and then define a smaller "exclusive" region inside the large "inclusive" region where the deal would not be offered, if the user (vendor) desired not to present the deal in a particular neighborhood or business area… In one embodiment, once the vendor has completed entering the deal information using the user interfaces of FIGS. 6-9, the deal information may be communicated by vendor system 310 to deal manager 300 where deal definition module 305 may process the deal definition and store it in data store 303. In some embodiments, deals may be updated. The vendor may access a saved deal through user interface similar to the ones illustrated in FI GS. 6-9. The user interface used for creating a new deal definition may also be used for modifying a deal definition by pre-populating the user interfaces with a saved deal definition information. Deal manager 300 may provide a list in the user interface for the vendor that allows the vendor to select from predefined deals, and may allow the vendor to modify those predefined deals. In some embodiments, vendor system 310 may execute an application for updating a deal definition. Vendor system 310 may be, for example, a mobile computing device with a mobile application. The mobile application may provide the ability to alter details of the deal, such as the price, the time the deal should launch, or deal text. In some embodiments, a predefined deal may be launched on demand. For example, the user of vendor system 310 may wish to launch a deal to stimulate business. FIG. 10 shows one embodiment of user interface 1000 for launching a deal on-demand. User interface 1000 allows for the input of the number of deals available in text field 1010 and the price of the deal in text field 1020. The user interface 1000 also provides launch button 103 which will launch the deal "on-demand." In another embodiment the functions of the vendor system 310 may advantageously be made a part of the deal manager 300 and the input from the vendor as well as communication with the vendor's in-house inventory management system may be provided through the internet and a browser interface… Returning to FIG. 5, at step 2, deal manager 300 publishes the deal. Deal manager 300 may publish the deal in response to a real-time immediate publication request (such as the one issued by the illustrative embodiment of FIG.10, or it may publish a deal that was defined at an earlier time and stored in data store 303. Deal manager 300 may publish deals by communicating deal information across network 380. In one embodiment, deal manager 300 may publish deals in a broadcast paradigm, that is, deal manager 300 may publish deals without directing the deals to a particular target deal presenter 100, and it is up to deal presenter 100 to determine whether to display the deal. In another embodiment, deal manager 300 may maintain a list of registered deal presenters and may direct deal publication to those deal presenters that satisfy the deal definition. The processes for publishing and displaying deals is discussed further with respect to FIGS. 19 and 20.” Furthermore, as cited in ¶ [0111] “FIG. 19 is a flow chart depicting the process flow of one embodiment of a deal manager 300. At block 1901, deal manager 300 may receive promotional offer data for a deal from a vendor system 310. The promotional offer data may include deal data as described above with respect to FIGS. 6-10. For example, the promotional offer data may include deal information describing the deal, time restrictions, location restrictions, the number available at that price (checked in real time), a retail price, images, or other data that may define a deal.”).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time the invention was made, to add Pinkus’ causing presentation, in a first graphical user interface, of the first graphical user interface data, the first graphical user interface comprising a base alerts indicator, a geographic map, an alert indicator for each geographic section of the geographic map, and a plurality of user interface controls; causing presentation, in a second graphical user interface, of the second graphical user interface data, the second graphical user interface comprising the base alerts indicator, an additional alerts indicator, the geographic map, an updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic map, a further updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls to Battista’s in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic data, a further updated alert indicator for each geographic section of the geographic data, and the plurality of user interface controls. One of ordinary skill in the art would have been motivated to do so in order “for vendors to receive transactional data and convey benefits and or promotional information to one or more promoters in response to receiving such data.” (Pinkus: ¶ [0041]).
With respect to Claim 18:
All limitations as recited have been analyzed and rejected to claim 2. Claim 18 recites “A system comprising: a computer readable storage medium comprising program instructions; and one or more processors configured to execute the program instructions to cause the system to:” (Battista: ¶ [0041]) perform the steps of method claim 2. Claim 18 does not teach or define any new limitations beyond claim 2. Therefore it is rejected under the same rationale.
With respect to Claim 4:
Battista does not explicitly disclose the method of Claim 2, wherein determining the additional alerts data further comprises: identifying a previously sold vehicle with a new suggested vehicle based on category, classification, or grouping for the new suggested vehicle satisfying the transaction parameter.
However, Wu further discloses:
wherein determining the additional alerts data further comprises: identifying a previously sold vehicle with a new suggested vehicle based on category, classification, or grouping for the new suggested vehicle satisfying the transaction parameter (i.e. identifying previously sold vehicles are compared to the specified vehicle or suggested new vehicle based on price parameter satisfying a quality score) (Wu: ¶ [0075] “Referring to FIG. 3 again, at some later point then, at step 372 data pertaining to that dealer may be obtained, such as for example, from a DMS associated with that dealer or manually via follow up surveys or the like. Utilizing the obtained data corresponding to that dealer then, it can be determined if a transaction corresponding to the presented upfront price actually occurred. In other words, it can be determined if a vehicle of the same or a similar configuration was sold to that particular user by that particular dealer. If a corresponding transaction occurred, the transaction price associated with that transaction (the price the user actually paid) may be compared against the upfront price offered by the dealer to that user for the specified vehicle and the comparison used to determine or adjust a quality score corresponding to the dealer at step 382. It will be apparent that almost any algorithm desired may be utilized to generate a quality score from such transaction data and upfront pricing information.”).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time the invention was made, to add Wu’s determining the additional alerts data further comprises: identifying a previously sold vehicle with a new suggested vehicle based on category, classification, or grouping for the new suggested vehicle satisfying the transaction parameter to Battista’s in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic data, a further updated alert indicator for each geographic section of the geographic data, and the plurality of user interface controls. One of ordinary skill in the art would have been motivated to do so in order to “provide high accuracy of invoice prediction, which can help to improve the data coverage of vehicle inventories” and “help to avoid the risk of third party data reliance, providing a robust solution in generating actionable data.” (Wu: ¶ [0011]).
With respect to Claim 19:
All limitations as recited have been analyzed and rejected to claim 4. Claim 19 does not teach or define any new limitations beyond claim 4. Therefore it is rejected under the same rationale.
With respect to Claim 5:
Battista does not explicitly disclose the method of Claim 4, wherein the vehicle-related data comprises an estimated trade value for the previously sold vehicle.
However, Wu further discloses wherein the vehicle-related data comprises an estimated trade value for the previously sold vehicle (i.e. estimating price distribution based on asset identifiers or specified vehicle configuration and date the vehicle was sold) (Wu: ¶ [0122] “These interfaces may serve to communicate the determined data in a variety of visual formats, including streamlined normal distributions and pricing recommendations based on one or more data sets. In some embodiments, a price distribution for a particular data set associated with a specified vehicle configuration can be presented to users as a Gaussian curve 472. Using the normal distribution of transaction data in a given geographic area, the mean and the variance of pricing can be visually depicted to an end user. Visually, the Gaussian curve 472 may be shown to illustrate a normalized distribution of pricing (for example, a normalized distribution of transaction prices). On the curve's X-axis, the average price paid may be displayed along with the determined dealer cost, invoice or sticker price to show these prices relevancy, and relation, to transaction prices. The determined "good," "great," "overpriced," etc. price ranges are also visually displayed under the displayed curve to enable the user to identify these ranges. Incentive data utilized to determine the presented data may also be displayed to the user.” Furthermore, as cited in ¶ [0124] “Interfaces for determined historic trends or forecasts 478 may also be generated. For example, a historical trend chart may be a line chart enabling a user to view how average transaction prices have changed over a given period of time. The Y-axis represents the percentage change over given time periods while the X-axis represents given time periods. The user will also be able to view the average transaction price and average incentives over each given time period. In addition, the user will also be able to see how prices may change in the future based on algorithmic analysis. Other types of interfaces, such as bar charts illustrating specific price points (for example, average price paid, dealer cost, invoice, and sticker price) and ranges (for example, "good," "great," "overpriced," etc.) in either a horizontal or vertical format, may also be utilized.” Furthermore, as cited in ¶ [0107] “In addition, the new car margin (front-end gross) may be adjusted up or down for transactions that have a high or low back-end gross. This adjustment may be a combination of the magnitude of the back-end gross and a factor based on historical analysis (for example, for a dealership having a sales transaction comprising a trade amount of $5000 and an actual trade value of $7000 and thus made $2000 on the vehicle trade, the front-end gross for this sales transaction vehicle would be increased by this $2000 since this dealer would have accepted a lower transaction price).”).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time the invention was made, to add Wu’s vehicle-related data comprises an estimated trade value for the previously sold vehicle to Battista’s in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic data, a further updated alert indicator for each geographic section of the geographic data, and the plurality of user interface controls. One of ordinary skill in the art would have been motivated to do so in order to “provide high accuracy of invoice prediction, which can help to improve the data coverage of vehicle inventories” and “help to avoid the risk of third party data reliance, providing a robust solution in generating actionable data.” (Wu: ¶ [0011]).
With respect to Claim 20:
All limitations as recited have been analyzed and rejected to claim 5. Claim 20 does not teach or define any new limitations beyond claim 5. Therefore it is rejected under the same rationale.
With respect to Claim 7:
Battista teaches:
The method of Claim 5, further comprising obtaining the estimated trade value from a database of third-party industry valuation data (i.e. obtaining trade-in value of vehicle via external or third-party databases) (Battista: ¶¶ [0048] [0049] “A consumer resource 80 is connected to the network 54 and in electronic communication with the application 50. The application 50 is integrated with the consumer resource 80. In one example, the consumer resource 80 is a trusted and credible electronic third-party resource available to consumers independent of the automotive dealership 56. For example, the consumer resource 80 may be an entity or website, such as online resource for automotive information, such as Edmunds®, and the like…The consumer resource 80 is an electronic source of consumer resource data 82. Consumer resource data 82 includes, but is not limited to prices for new and used vehicles, trade-in values, market values, incentives and rebates, dealer and inventory listings, vehicle test drive reviews, and other tips and advice relating to vehicle purchases and ownership.”).
With respect to Claim 21:
All limitations as recited have been analyzed and rejected to claim 7. Claim 21 does not teach or define any new limitations beyond claim 7. Therefore it is rejected under the same rationale.
With respect to Claim 8:
Battista teaches:
The method of Claim 7, wherein determining the additional alerts data further comprises determining an estimated payoff amount by multiplying a customer's current payment with a number of remaining payments derived from information in the database of third-party industry valuation data (i.e. determining approx. monthly base payments by multiplying customers current payment or APR with number of remaining payments or term) (Battista: Fig. 20 and ¶¶ [0171] [0172] “As shown in FIG. 19, the application 50 further provides a consumer options worksheet page 200 wherein the application 50 imports all suggested commodities and presents the commodities and associated payment options on a single page. Here, the application enables selection as to whether or not to present a suggested commodity. The application 50 enables editing of suggested commodity pricing, levels, coverages, and descriptions as needed. The consumer worksheet page imports D MS data 7 4, such as APR and Cash Down information. The application 50 calculates the payment for each suggested commodity. Generally, dealership personnel manipulate the information on the consumer worksheet page…As shown in FIG. 20, the application 50 outputs a commodities summary 210 based on the settings set forth in the consumer options worksheet page 200. The commodities summary 210 is electronically presented by the application 50 and sets forth the suggested commodities and the associated payment options for suggested commodities. In one embodiment, the suggested commodities are dynamic and interactive such that when selected electronically ( clicked) the electronic summary updates and displays the corresponding payment options for the selected commodity. The commodities summary page 210 can have various other configurations.” Furthermore, as cited in ¶ [0160] “From the interview response data 92 relating to expected duration of ownership of the vehicle and average miles historically driven, the application 50 analytically determined that consumer would be left unprotected in the event of mechanical failure after approximately 29 months. The presentation 190 explains this determination to the consumer. The presentation 190 further explains for the specific vehicle being purchased the true cost of ownership repair and maintenance as derived from the consumer resource data 82. Based on the application's 50 analysis of historical DMS data 74 and interview response data 92, the presentation 190 additionally presents that 68% of similarly situated clients opted to purchase the vehicle protection plan. The presentation 190 reiterates the suggested vehicle protection plan for purchase based on the presented information.”).
With respect to Claim 22:
All limitations as recited have been analyzed and rejected to claim 8. Claim 22 does not teach or define any new limitations beyond claim 8. Therefore it is rejected under the same rationale.
With respect to Claim 9:
Battista and Wu do not explicitly disclose the method of Claim 2, wherein the user interface control comprises a slider and the selection of the user interface control comprises a range selection.
However, Pinkus further discloses wherein the user interface control comprises a slider and the selection of the user interface control comprises a range selection (i.e. interface includes slider that allows user to select a range for the deals) (Pinkus: ¶ [0090] “In some embodiments, vendor system 310 may upload media such as images and/or video so that the deal may be more attractive to those that view it. FIG. 8 illustrates one embodiment of media upload interface 800 which advantageously provides user interface elements for uploading media content to deal manager 300 so that the media may be included in the defined deals of the vendor. Media upload interface 800 may include a deal duration slider 810 allowing for the vendor to set the duration for displaying the deal. For example, in the illustrative embodiment of FIG. 8, the slider may be set so that the deal appears for a duration between 0 and 30 seconds. In another embodiment, media upload interface 800 may not include a slider, but rather, may include a text field for entering the duration for displaying the deal. Media upload interface 8 may also include upload element 820. Upload element 820 may be any user interface known in the art permitting upload of files to a server. Upload element 820 may provide a "Select" button. When the user clicks on the "Select" button, a file system dialog block may appear allowing the user to navigate to a directory that may contain a media file for uploading. Once the user selects the appropriate media, the name of the file may appear in text area of upload element 820. In some embodiments, deal manager 300 may only permit files up to a maximum file size. Upload element 820 advantageously informs the user of the max file size. Media upload interface 800 may also include transition drop down block 830. Transition drop down block830 may contain a list of standard transitions from one image of a deal to the next image of the deal. For example, transition drop down block 830 may include transitions such as accordion (simulating the look and feel of an accordion), blinds (simulating the look and feel of horizontal or vertical blinds) or sweep (simulating the look and feel of the deal sweeping in from the top, bottom, left or right). Media upload interface 800 may also include media duration slider 840 that allows a user to enter the display duration for which the media ( as opposed to the entire deal) may be displayed.”).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time the invention was made, to add Pinkus’ user interface control comprises a slider and the selection of the user interface control comprises a range selection to Battista’s in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic data, a further updated alert indicator for each geographic section of the geographic data, and the plurality of user interface controls. One of ordinary skill in the art would have been motivated to do so in order “for vendors to receive transactional data and convey benefits and or promotional information to one or more promoters in response to receiving such data.” (Pinkus: ¶ [0041]).
With respect to Claim 23:
All limitations as recited have been analyzed and rejected to claim 9. Claim 23 does not teach or define any new limitations beyond claim 9. Therefore it is rejected under the same rationale.
With respect to Claim 11:
Battista teaches:
The method of Claim 2, wherein determining the additional alerts data further comprises determining a predicted warranty expiration date for a previously sold vehicle (i.e. determining expiration date for warranty or deal for a pre-owned vehicle) (Battista: ¶ [0124] “The application 50 may determine that some vehicle specific data 150 decreases the probability of purchase and/or the need of the consumer given certain scenarios. In one example, vehicle specific data 150 includes warranty information associated with the vehicle. For example, if the vehicle comes with a manufacturer warranty and consumer plan on keeping the vehicle for a duration less than the coverage period, the application 50 may determine that there is a decreased probability of selling a VSC. If the vehicle comes with pre-paid maintenance and consumer plans to keep the vehicle less that the coverage period, the application 50 may determine that there is a decreased probability of selling a maintenance plan on the vehicle. If the consumer intends to purchase a certified pre-owned vehicle, the application 50 prompts the user with a warranty coverage window to allow the user to input the start dates and expiration mileage for the various warranties of the vehicle.”).
With respect to Claim 24:
All limitations as recited have been analyzed and rejected to claim 11. Claim 24 does not teach or define any new limitations beyond claim 11. Therefore it is rejected under the same rationale.
With respect to Claim 13:
Battista teaches:
The method of Claim 8, wherein the user input indicates an amount or a range for a manufacturer incentive (i.e. providing manufacturer/dealer with display interface to allow price edits and/or cost per period or range for manufacturer incentive) (Battista: Fig. 18 and ¶ [0171] “As shown in FIG. 19, the application 50 further provides a consumer options worksheet page 200 wherein the application 50 imports all suggested commodities and presents the commodities and associated payment options on a single page. Here, the application enables selection as to whether or not to present a suggested commodity. The application 50 enables editing of suggested commodity pricing, levels, coverages, and descriptions as needed. The consumer worksheet page imports D MS data 7 4, such as APR and Cash Down information. The application 50 calculates the payment for each suggested commodity. Generally, dealership personnel manipulate the information on the consumer worksheet page.” Furthermore, as cited in ¶ [0173] “The declination page 220 also provides the ability to make edits (e.g., price, name, level, description). To increase the probability of last-minute sales before consumer declination, the declination page 220 further provides a selection of the cost per period for each commodity. As shown in FIG. 21, the cost per period is selected as "per week."”).
With respect to Claim 25:
All limitations as recited have been analyzed and rejected to claim 13. Claim 25 does not teach or define any new limitations beyond claim 13. Therefore it is rejected under the same rationale.
Claim(s) 15 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Battista, Wu, and Pinkus in further view of U.S. Patent 9,047,616 to Schnabl.
With respect to Claim 15:
Battista, Wu, and Pinkus do not explicitly disclose the method of Claim 2, wherein determining the additional alerts data, further comprises: obtaining a capitalized cost comprising an amount financed for a previously sold vehicle; determining the amount paid so far by a customer toward the capitalized cost; and determining a remainder as an estimated payoff amount by subtracting the amount paid so far from the capitalized cost.
However, Schnabl further discloses obtaining a capitalized cost comprising an amount financed for a previously sold vehicle; determining the amount paid so far by a customer toward the capitalized cost; and determining a remainder as an estimated payoff amount by subtracting the amount paid so far from the capitalized cost (i.e. determining an equity value for the vehicle, determining how much the customer has paid off the vehicle and how much is left on the payment for the vehicle) (Schnabl: Col. 12 Lines 52-61 “The payments remaining value may be related to a summation of a number of payments remaining with regard to the financial transaction of the existing vehicle for each customer 42. For this sample customer 42, at the heading tab 66 a payments remaining value is indicated as "100" (based upon a 100 point scale). In this regard the customer 42 only has three months remaining on the lease and would be presumed to be in need to make a purchase decision prior to the lease expiring. This 60 factor may tend to indicate a motivation to make a purchase based upon the fewer the number of payments remaining.” Furthermore, as cited in Col. 10 Lines 38-52 “The equity value may be related to a financial obligation pay-off amount with regard to the financial transaction of the existing vehicle for each customer. The equity value may further be derived based upon certain "pull forward" programs where the entity leasing the vehicle may offer a forbearance of certain amounts or number of payments if the customer 42 were to purchase another vehicle. Other pull forward programs may be offered from the vehicle manufacturer, financial institution or others. Where the customer 42 is financially obligated under the existing vehicle to pay a certain number of payments remaining under the lease agreement, the greater the amount would be anticipated to be a negative influence as to the customer's willingness or motivation to "break" the existing lease agreement so as to enter into a new financial transaction for a new vehicle.”).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time the invention was made, to add Schnabl’s obtaining a capitalized cost comprising an amount financed for a previously sold vehicle; determining the amount paid so far by a customer toward the capitalized cost; and determining a remainder as an estimated payoff amount by subtracting the amount paid so far from the capitalized cost to Battista’s in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic data, a further updated alert indicator for each geographic section of the geographic data, and the plurality of user interface controls. One of ordinary skill in the art would have been motivated to do so because “Effective utilization of such data may be used to perform predictive analysis to understand customer purchase behavior for targeting customers and generating sales leads.” (Schnabl: Col. 2 Lines 16-18).
With respect to Claim 26:
All limitations as recited have been analyzed and rejected to claim 15. Claim 26 does not teach or define any new limitations beyond claim 15. Therefore it is rejected under the same rationale.
Allowable Subject Matter
Claims 17 and 27 are allowable over the art.
With respect to Claim 17:
The method of Claim 15, wherein determining the additional alerts data further comprises: obtaining a price of a new suggested vehicle;
obtaining a net trade-in equity by combining an estimated trade value with the estimated payoff amount, wherein the net trade-in equity may be either negative equity or positive equity;
determining an amount to be financed by combining the price of the new suggested vehicle with any obtained net trade-in equity, whether positive or negative;
using the amount to be financed and currently-available rate information for a loan duration to determine a new proposed payment;
comparing a current payment of the customer and the new proposed payment to determine one or more differences;
analyzing the one or more differences to determine if at least one of them meets a criterion to identify the customer for outreach;
adjusting at least one changed data parameter for suggested new vehicles; and
iteratively analyzing whether the at least one changed data parameter increases a number of customers for new suggested vehicles.
With respect to Claim 27:
All limitations as recited have been analyzed to claim 17. Claim 27 does not teach or define any new limitations beyond claim 17. Therefore it is analyzed under the same rationale.
Response to Arguments
Applicant’s arguments see page 9 of the Remarks disclosed, filed on 03/27/2026, with respect to the nonstatutory double patenting rejection(s) of claim(s) 2, 4, 5, 7-9, 11, 13, 15, and 17-27 have been considered but are not persuasive. The Applicant has stated “ Applicant respectfully disagrees with each and every implicit and/or explicit characterization of the claims in either application. In order to further the prosecution of the present application, Applicant will consider filing a terminal disclaimer at a time when the claims are otherwise in condition for allowance. Should at any time it be determined that a terminal disclaimer would place the claims in condition for allowance, the Examiner is invited to contact the Applicant’s representative.” Therefore, the rejection(s) of claim(s) 2, 4, 5, 7-9, 11, 13, 15, and 17-27 under the nonstatutory double patenting rejection is maintained above.
Applicant’s arguments see pages 9-15 of the Remarks disclosed, filed on 03/27/2026, with respect to the 35 U.S.C. § 101 rejection(s) of claim(s) 2, 4, 5, 7-9, 11, 13, 15, and 17-27 have been considered but are not persuasive:
The Applicant asserts “In the Office Action, it is alleged that Claim 2 is directed towards certain methods of organizing human activity and mental processes. Office Action at 10. The limitations of claim 2 do not fall under a certain method of organizing human activity. In the Office Action, claim 2 is characterized as involving "commercial or legal interactions" and "managing personal behavior or relationships or interactions between people." However, that characterization is not consistent with the claim language as amended. Claim 2 does not recite making an offer, negotiating a transaction, forming a contract, administering a legal obligation, advertising to a customer, or managing any interpersonal conduct. The recited "transaction parameter" is not claimed as a commercial interaction or legal arrangement; rather, it is an input parameter used by the claimed computer system to recalculate and display region-specific alert information. Likewise, the "base alerts indicator" and other alerts are not human or business interactions, but computer-generated outputs derived from standardized data processing and geographic display operations. The mere fact that the underlying data may relate to vehicle transactions does not convert the claim into a method of organizing human activity. Claim 2 also does not fall under a mental process. In the Office Action, it is asserted that the claim is directed to concepts performed in the human mind. However, claim 2 recites far more than human observation, evaluation, or judgment. For example, claim 2 recites "storing vehicle- related data in a standardized format in one or more non-transitory storage devices comprising a collection of vehicle-related records," "conditioning the source data into the standardized format that results in converted data," and "causing presentation, in a first graphical user interface, of the first graphical user interface data, the first graphical user interface comprising a base alerts indicator, a geographic map, an alert indicator for each geographic section of the geographic map, and a plurality of user interface controls." These operations, particularly in the claimed combination, are not practically performable in the human mind. A human cannot mentally maintain the claimed data collection from the recited machine data sources, condition the data into standardized converted data, compute and present geographically segmented base alerts before application of an incentive amount, and then update the displays in real time as updated source data are received.” The Examiner respectfully disagrees. According to ¶ [0232] of Applicant’s originally filed specification; “The outputs from an AlertOptics system can be a total number of “alerts” (or potential customers having a situation meeting the favorable deal criteria) before and after adjustment of the subsidy.” It is clear that the “alerts” correspond to potential customers meeting a deal criteria which are clearly business interactions between two parties. Furthermore, Claims 2 and 18 recite limitations directed to the abstract idea including storing vehicle-related data in a standardized format comprising a collection of vehicle-related records; receiving, from a dealer management system data source, an original equipment manufacturer data source, or a lender data source, source data in a non-standardized format; storing the converted data in the standardized format; determining, from at least the vehicle-related data and the converted data, first graphical user interface data; the first graphical user interface comprising a base alerts indicator, a geographic map, an alert indicator for each geographic section of the geographic map, and a plurality of user interface controls, wherein the geographic map is subdivided into a plurality of geographic regions and the alert indicator for each geographic section represents a base alert count for that geographic section computed before an application of an incentive amount; receiving user input corresponding to a selection of a user interface control from the plurality of user interface controls, wherein the user input comprises a transaction parameter comprising an amount or a range for a manufacturer incentive; determining, from at least the vehicle-related data, the converted data, the transaction parameter, additional alerts data; determining, from at least the additional alerts data, second graphical user interface data; the second graphical user interface comprising the base alerts indicator, an additional alerts indicator, the geographic map, an updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls; and the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic map, a further updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls. These further limitations are not seen as any more than the judicial exception. Claims 2 and 18 recite additional limitations including “in one or more non-transitory storage devices”, “via the first graphical user interface”, and “conditioning the source data into the standardized format that results in converted data; causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. The claims are considered to be an abstract idea under certain methods of organizing human activity because the claims are directed to commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) and managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) such as storing vehicle-related data, receiving original equipment manufacturer or lender data, storing converted data, determining data to be presented in a first GUI, receiving user input corresponding to a selection, and determining data to be presented in a second GUI. The claims are also considered to be an abstract idea under mental processes because the claims are directed to concepts performed in the human mind (including an observation, evaluation, judgment, opinion) such as storing data in a format, receiving data in another format, storing the data in the format, determining data to be presented in a first GUI, receiving user input corresponding to a selection, and determining data to be presented in a second GUI.
The Applicant also asserts “The present specification identifies precisely such a technological problem. The disclosure explains that OEMs, dealerships, and lenders operate in a technically fragmented data environment, with ineffective data processing, ineffective security, lack of analytical tools, excessive resource consumption, incompatible formats, inconsistent storage and access models, and difficulties in transferring and analyzing data across dealer/OEM/lender systems. Specification at III [0056]-[0060]. In particular, the specification explains that dealership data had become "very large and unwieldy," straining "network and system resources," and that the diversity of DMS providers and storage/access approaches led to "inefficiencies and difficulties for searching and analysis using OEM and dealership data." Id. at III [0057]-[0059]. The specification further explains that data from the DMS source, OEM source, and lender source are often "not compatible or standardized" and "not uniformly formatted," thereby creating "an enormous challenge" for dealer and OEM analysis. Id. at I [0066]. Claim 2 reflects the disclosed technical solution to those technical data-transfer and compatibility problems. The claim does not merely say "collect data" or "display results." Rather, claim 2 recites "storing vehicle-related data in a standardized format in one or more non-transitory storage devices comprising a collection of vehicle-related records," "conditioning the source data into the standardized format that results in converted data," "determining, from at least the vehicle- related data and the converted data, first graphical user interface data," and "causing presentation, in a first graphical user interface, of the first graphical user interface data, the first graphical user interface comprising a base alerts indicator, a geographic map, an alert indicator for each geographic section of the geographic map, and a plurality of user interface controls." That ordered combination directly tracks the technical architecture described in the specification. The specification discloses corresponding data extraction applications for the DMS, OEM, and lender sources, tailored to the specific data formatting of the respective sources. Specification at ¶¶ [0062]-[0063]. It further discloses that the system automatically transforms, conditions, scrubs, normalizes, harmonizes, formats, and reformats incoming automotive data into a common base for handling otherwise incompatible data. Id. at ¶¶ [0072]-[0073]. This is a concrete technological implementation for making incompatible dealer/OEM/lender data interoperable and usable within a unified automotive data-processing system. Claim 2 also integrates any alleged exception into a further practical application through its real-time update architecture. The specification expressly recognizes that, because the system processes large amounts of data, it was "historically challenging to smoothly return dynamic results." Id. at I [0152]. The disclosure then provides a technical solution: making calculations on relevant data in advance, using pre-packaging, pre-calculation, pre-association of parameters and corresponding data sets, and periodic storage of associations "so that when the input controls are adjusted the number of calculations required in real time is minimized," thereby improving real- time functionality and saving system resources. Id. at I [0134]. Paragraph [0134] is especially clear that the system improves technical operation by minimizing the amount of data sorted in real time, making the system "much faster" and "more efficient," and enabling a "smooth or otherwise convenient output on the display." Id. Paragraph [0152] likewise explains that pre-computed information "may help provide a smoother viewing experience."” The Examiner respectfully disagrees. The claims do not recite or make an improvement to “automatically transforms, conditions, scrubs, normalizes, harmonizes, formats, and reformats incoming automotive data into a common base for handling otherwise incompatible data”. The claims do recite “conditioning the source data into the standardized format that results in converted data”, however, this recitation describes how the system conditions the source data at a very high level. Examiner recommends to amends the claims to clarify how the source data is being conditioned in a manner that is rooted in the computer technology. Furthermore, Claims 2 and 18 recite additional limitations including “in one or more non-transitory storage devices”, “via the first graphical user interface”, and “conditioning the source data into the standardized format that results in converted data; causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. The limitations reciting – “in one or more non-transitory storage devices” and “via the first graphical user interface”, are seen as adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Accordingly, alone, and in combination, these additional elements are seen as using a computer or tool to perform an abstract idea, adding insignificant-extra-solution activity to the judicial exception. They do no more than link the judicial exception to a particular technological environment or field of use, i.e. non-transitory storage device / GUI, and therefore do not integrate the abstract idea into a practical application. The courts decided that although the additional elements did limit the use of the abstract idea, the court explained that this type of limitation merely confines the use of the abstract idea to a particular technological environment and this fails to add an inventive concept to the claims (See Affinity Labs of Texas v. DirecTV, LLC,). With respect to the claim limitation “conditioning the source data into the standardized format that results in converted data”. Merely reciting storing data in one format, receiving data in another format, conditioning that data into that first format, and storing the received data in the first format is seen as electronic recordkeeping and storing and retrieving information in memory. The courts have noted that “electronic recordkeeping” and “storing and retrieving information in memory” are seen as computer functions that are well‐understood, routine, and conventional when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity (See: ‘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); and ‘Storing and retrieving information in memory’, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;). Therefore, storing data in one format; receiving data in another format; conditioning that data into that first format; and storing the received data in the first format is seen as adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) and generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). With respect to the claim limitation “causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. Merely reciting generating an interface that displays interface controls that receive user input in order to display an updated graphical user interface is well-understood, routine, and conventional in the art since 1985 (See Wikipeida: User Interface – “In 1985, with the beginning of Microsoft Windows and other graphical user interfaces, IBM created what is called the Systems Application Architecture (SAA) standard which include the Common User Access (CUA) derivative.”) (See also: Richard, Stéphane. "Text User Interface Development Series Part One – T.U.I. Basics". Archived from the original on 16 November 2014. Retrieved 13 June 2014.) Therefore, causing presentation of data in a first GUI; receiving user selection and/or updated data; and in response to the received data causing presentation of data in a second or third GUI is seen as adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) and generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
The Applicant finally asserts “Similarly, the present claims confirm the technological improvement, and, therefore, the additional limitations recite significantly more than the alleged abstract idea itself. Much like the claim from Core Wireless that required "the application summary window list a limited set of data," claim 2, as amended, recites "receiving, via the first graphical user interface, user input corresponding to a selection of a user interface control from the plurality of user interface controls, wherein the user input comprises a transaction parameter comprising an amount or a range for a manufacturer incentive" and "causing presentation, in a second graphical user interface, of the second graphical user interface data, the second graphical user interface comprising the base alerts indicator, an additional alerts indicator, the geographic map, an updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls." Accordingly, claim 2, as amended, recites a particular manner by which the graphical user interface presents a summarized set of alerts data for geographic sections of a geographic map, which amount to more than the alleged abstract idea itself.” The Examiner respectfully disagrees. The recitation of the graphical user interface is recited at a very high level and is merely used to describe the computing environment in which to present data which includes alerts indicators, geographic map, and user interface controls (e.g. causing presentation, in a first graphical user interface, of the first graphical user interface data, the first graphical user interface comprising a base alerts indicator, a geographic map, an alert indicator for each geographic section of the geographic map, and a plurality of user interface controls; causing presentation, in a second graphical user interface, of the second graphical user interface data, the second graphical user interface comprising the base alerts indicator, an additional alerts indicator, the geographic map, an updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data, the third graphical user interface comprising an updated base alerts indicator, an updated additional alerts indicator, the geographic map, a further updated alert indicator for each geographic section of the geographic map, and the plurality of user interface controls). Furthermore, Claims 2 and 18 recite additional limitations including “in one or more non-transitory storage devices”, “via the first graphical user interface”, and “conditioning the source data into the standardized format that results in converted data; causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. The limitations reciting – “in one or more non-transitory storage devices” and “via the first graphical user interface” do not integrate the judicial exception (abstract idea) into a practical application because of the analysis provided in Step 2A, Prong II. Claims 2 and 18 also recite additional limitations including “conditioning the source data into the standardized format that results in converted data; causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. With respect to the claim limitation “conditioning the source data into the standardized format that results in converted data”. Merely reciting storing data in one format, receiving data in another format, conditioning that data into that first format, and storing the received data in the first format is seen as electronic recordkeeping and storing and retrieving information in memory. The courts have noted that “electronic recordkeeping” and “storing and retrieving information in memory” are seen as computer functions that are well‐understood, routine, and conventional when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity (See: ‘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); and ‘Storing and retrieving information in memory’, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;). Therefore, storing data in one format; receiving data in another format; conditioning that data into that first format; and storing the received data in the first format is seen as adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) and generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). With respect to the claim limitation “causing presentation, in a first graphical user interface, of the first graphical user interface data; causing presentation, in a second graphical user interface, of the second graphical user interface data; and in response to receiving updated source data, causing presentation, in real-time, in a third graphical user interface, of third graphical user interface data”. Merely reciting generating an interface that displays interface controls that receive user input in order to display an updated graphical user interface is well-understood, routine, and conventional in the art since 1985 (See Wikipeida: User Interface – “In 1985, with the beginning of Microsoft Windows and other graphical user interfaces, IBM created what is called the Systems Application Architecture (SAA) standard which include the Common User Access (CUA) derivative.”) (See also: Richard, Stéphane. "Text User Interface Development Series Part One – T.U.I. Basics". Archived from the original on 16 November 2014. Retrieved 13 June 2014.) Therefore, causing presentation of data in a first GUI; receiving user selection and/or updated data; and in response to the received data causing presentation of data in a second or third GUI is seen as adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g) and generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). Claims 2 and 18 do not include additional elements or a combination of elements that result in the claims amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements listed amount to no more than mere instructions to apply an exception using a generic computer component. In addition, the applicant’s specifications describe a “general purpose computer”, ¶ [0271], for implementing the remote computing environment, which do not amount to significantly more than the abstract idea of itself, which is not enough to transform an abstract idea into eligible subject matter. Furthermore, there is no improvement in the functioning of the computer or technological field, and there is no transformation of subject matter into a different state. Therefore, the rejection(s) of claim(s) 2, 4, 5, 7-9, 11, 13, 15, and 17-27 under 35 U.S.C. § 101 is maintained above with an updated analysis.
Applicant’s arguments see pages 15-16 of the Remarks disclosed, filed on 03/27/2026, with respect to the 35 U.S.C. § 103 rejection(s) of claim(s) 2, 4, 5, 7, 8, 11, 13, 18-22, 24, and 25 over Battista in view of Wu have been considered but are moot because the arguments do not apply to the new ground(s) of rejection is made in view of U.S. Publication 2013/0253999 to Pinkus.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following references are cited to further show the state of the art:
U.S. Publication 2012/0036033 to Seergy for disclosing A system, methods, and apparatus for performing used automobile transactions are disclosed. In an example embodiment, automobile market data representative of current automobile market characteristics is stored. The automobile market data may include pricing and consumer interest information received from consumers, dealers, and manufacturers. A consumer seller or manufacturer off-lease seller may provide a request for a response regarding a specific used automobile with a specific a vehicle identification number. Automobile market data may be provided to a used automobile buyer based on the request. Bids to purchase the specific used automobile may be requested from used automobile buyers based on the request. Buyer bids may be provided to the consumer seller or manufacturer off-lease seller with prices and a delivery options. The consumer seller or manufacturer off-lease seller may select a bid to sell the specific used automobile based on the bid.
U.S. Patent 9,697,544 to Bayer for disclosing A system and method for generating information relating to a vehicle's history. In one embodiment, the method includes the steps of identifying records in a database, identifying a target record, identifying a trigger record, determining if the target record indicates an ownership transfer based on the identified trigger record, and generating a price adjustment for the vehicle at least partially based on the ownership transfer. In accordance with another aspect, a vehicle history information system is provided including a database having vehicle history records, a vehicle history report module adapted to retrieve vehicle history records, an ownership module adapted to identify a target record, identify a trigger record, and determine whether the target record indicates an ownership transfer based on the identified trigger record, and a pricing module adapted to generate a price adjustment for the vehicle at least partially based on the ownership transfer.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Azam Ansari, whose telephone number is (571) 272-7047. The examiner can normally be reached from Monday to Friday between 8 AM and 4:30 PM.
If any attempt to reach the examiner by telephone is unsuccessful, the examiner's supervisor, Waseem Ashraf, can be reached at (571) 270-3948.
Another resource that is available to applicants is the Patent Application Information Retrieval (PAIR). Information regarding the status of an application can be obtained from the (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAX. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pairdirect.uspto.gov. Should you have questions on access to the Private PAIR system, please feel free to contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Applicants are invited to contact the Office to schedule either an in-person or a telephonic interview to discuss and resolve the issues set forth in this Office Action. Although an interview is not required, the Office believes that an interview can be of use to resolve any issues related to a patent application in an efficient and prompt manner.
/AZAM A ANSARI/
Primary Examiner, Art Unit 3621
June 9, 2026
Prosecution Insights