System and method for calculating and displaying price distributions based on analysis of transactions
21 claims: 12 independent, 9 dependent
- 1システムであって、該システムは、 プロセッサと、 命令を記録した コンピュータ可読記憶媒体と を備え、 該命令は、該プロセッサに該命令を実行させ、該命令は、 データ収集モジュールであって、 該データ収集モジュールは、 ネットワーク上において 該 システムに結合される 1つ以上 のデータ源から 該ネットワーク上で 履歴取引データを 検索し、該履歴取引データをデータ記憶装置に記憶するように構成され 、該履歴取引データは、 複数の車両に対する 車両取引に関するデータを含 み、該車両取引に関するデータは、該複数の車両に対するインボイス価格を含む 、データ収集モジュールと、 処理モジュールであって、該処理モジュールは、 該ネットワーク上で該システムに通信的に接続されたユーザデバイスを介して、ユーザから該ネットワーク上で指定の車両構成を受信することと、 該指定の車両構成に基づいて、該 履歴取引データ 内の複数の取引を識別 すること と 、 少なくとも該複数の取引を評価することにより、該 指定の車両構成に対応する価格設定データを決定することであって、該価格設定データは 、取 引価格と 、1 つ以上の価格範囲とを含む、ことと を行うように構成され てい る、処理モジュールと、 セールスジェネレーションモジュール と を備え、 該セールスジェネレーションモジュールは、 複数の要因を評価することにより、該指定の車両構成に対する1つ以上の属性を有するか、該指定の車両構成に対する1つ以上の属性において同様である車両を有する1つ以上のディーラの各々に対して、該ユーザから受信された 該指定の車両構成 に 対応する 正直 価格を決定するように構成され 、該正直価格は、ディーラが、該指定の車両構成を有するか、該指定の車両構成と同様である該車両に対して、該ユーザに提案しようとする最安価格を表し、該複数の要因は、該ユーザの地理的位置、該1つ以上のディーラの地理的位置、該1つ以上のディーラの在庫、該複数の車両に対する該インボイス価格、またはそれらの組み合わせを含む 、システム。
- 2インターフェースモジュールをさらに備え、該インターフェースモジュールは、前記正直価格を提示するインターフェースを前記ユーザデバイス上に表示させるように構成されている 、請求項1に記載のシステム。
- 3前記 命令 は、 少なくとも部分的に、個々のディーラによって提案された車両価格と、該車両価格が提案された買い手に車両が販売された実際の価格との間の相互関係に基づいて、複数のディーラの各個々のディーラに対する 品質スコアを 計算 するようにさらに構成され てい る、請求項 1 に記載のシステム。
- 4前記命令は、前記ディーラによって提案された前記車両価格と、該車両価格が提案された前記買い手に前記車両が販売された前記実際の価格との間の差異に基づいて、 前記品質スコア を減少させるようにさらに構成されている 、請求項3に記載のシステム。
- 5前記 命令 は、 各個々の ディーラ の 前記品質スコアまたは該 個々の ディーラに関連する在庫に基づいて 、前記複数のディーラから前記1つ以上のディーラを 選択 するようにさらに構成されている 、請求項 3 に記載のシステム。
- 6前記 命令 は、 個々の ディーラ の 前記品質スコアを使用して 、該個々のディーラによって提案された前記正直価格を 調整 するようにさらに構成されている 、請求項 3 に記載のシステム。
- 7前記ユーザデバイス上に表示された 前記インターフェースは、 入力手段を含み、該入力手段は、前記 ユーザが、 個々のディーラによって提案された 前記 正直 価格と併せて個人情報を提供することを可能に し 、 該 ユーザが該個人情報を提供すると 、 該ユーザに 該個々の ディーラ に関する情報 を 提示する 、請求項 2 に記載のシステム。
- 8コンピュータによって実行される方法であって、該方法は、 該コンピュータが、1つ以上 のデータ源から 該ネットワーク上で 履歴取引データを 検索 すること と 、 該コンピュータが、該履歴取引データをデータ記憶装置に記憶することであって 、該履歴取引データは、 複数の車両に対する 車両取引に関するデータを含 み、該車両取引に関するデータは、該複数の車両に対するインボイス価格を含む 、ことと、 該コンピュータが、該ネットワーク上で該コンピュータに通信的に接続されたユーザデバイスを介して、ユーザから該ネットワーク上で指定の車両構成を受信することと、 該コンピュータが、該指定の車両構成に基づいて、該 履歴取引データ 内の複数の取引を識別 すること と 、 該コンピュータが、少なくとも該複数の取引を評価することにより、該 指定の車両構成に対応する価格設定データを決定することであって、該価格設定データは 、取 引価格と 、1 つ以上の価格範囲とを含む、ことと、 該コンピュータが、複数の要因を評価することにより、該指定の車両構成に対する1つ以上の属性を有するか、該指定の車両構成に対する1つ以上の属性において同様である車両を有する1つ以上のディーラの各々に対して、該ユーザから受信された 該指定の車両構成 に 対応する 正直 価格を決定する ことであって、該正直価格は、ディーラが、該指定の車両構成を有するか、該指定の車両構成と同様である該車両に対して、該ユーザに提案しようとする最安価格を表し、該複数の要因は、該ユーザの地理的位置、該1つ以上のディーラの地理的位置、該1つ以上のディーラの在庫、該複数の車両に対する該インボイス価格、またはそれらの組み合わせを含む、 ことと、 該コンピュータが 、相互に連携している 該 価格範 囲お よび該 正直 価格を 含む該価格設定データを 提示する インターフェースを該ユーザデバイス上に表示させる ことと を含む、方法。
- 9前記 コンピュータが 、 複数の ディーラ から前記1つ以上のディーラ を選択することを さらに 含む、請求項8に記載の方法。
- 10前記 コンピュータが 、 少なくとも部分的に、個々のディーラによって提案された車両価格と、該車両価格が提案された買い手に車両が販売された実際の価格との間の相互関係に基づいて、前記複数のディーラの各個々のディーラに対する 品質スコアを 計算すること をさらに含む、請求項9に記載の方法。
- 11前記コンピュータが、前記ディーラによって提案された前記車両価格と、該車両価格が提案された前記買い手に前記車両が販売された前記実際の価格との間の差異に基づいて、 前記品質スコア を減少させることをさらに含む 、請求項10に記載の方法。
- 12前記ディーラは、 各個々の ディーラ の 前記品質スコアまたは該 個々の ディーラに関連する在庫に基づいて 、前記コンピュータによって 選択される、請求項 10 に記載の方法。
- 13前記 コンピュータが 、 個々の ディーラ の 前記品質スコアを使用して 、該個々のディーラによって提案された 前記 正直 価格を調整することをさらに含む、請求項 10 に記載の方法。
- 14前記ユーザデバイス上に表示された 前記インターフェースは、 入力手段を含み、該入力手段は、前記 ユーザが、 個々のディーラによって提案された 前記 正直 価格と併せて個人情報を提供することを可能に し 、 該 ユーザが該個人情報を提供すると 、 該ユーザに 該個々の ディーラ に関する情報 を提供す る、 請求項8に記載の方法。
- 15コンピュータ命令を記録した コンピュータ可読媒体であって、 該命令は、コンピュータの プロセッサによって実行可能 であり 、該命令は、 該コンピュータが、1つ以上 のデータ源から 該ネットワーク上で 履歴取引データを 検索 すること と 、 該コンピュータが、該履歴取引データをデータ記憶装置に記憶することであって 、該履歴取引データは、 複数の車両に対する 車両取引に関するデータを含 み、該車両取引に関するデータは、該複数の車両に対するインボイス価格を含む 、ことと、 該コンピュータが、該ネットワーク上で該コンピュータに通信的に接続されたユーザデバイスを介して、ユーザから該ネットワーク上で指定の車両構成を受信することと、 該コンピュータが、該指定の車両構成に基づいて、該 履歴取引データ 内の複数の取引を識別 すること と 、 該コンピュータが、少なくとも該複数の取引を評価することにより、該 指定の車両構成に対応する価格設定データを決定することであって、該価格設定データは 、取 引価格と 、1 つ以上の価格範囲とを含む、ことと、 該コンピュータが、複数の要因を評価することにより、該指定の車両構成に対する1つ以上の属性を有するか、該指定の車両構成に対する1つ以上の属性において同様である車両を有する1つ以上のディーラの各々に対して、該ユーザから受信された 該指定の車両構成 に 対応する 正直 価格を決定する ことであって、該正直価格は、ディーラが、該指定の車両構成を有するか、該指定の車両構成と同様である該車両に対して、該ユーザに提案しようとする最安価格を表し、該複数の要因は、該ユーザの地理的位置、該1つ以上のディーラの地理的位置、該1つ以上のディーラの在庫、該複数の車両に対する該インボイス価格、またはそれらの組み合わせを含む、 ことと、 該コンピュータが 、相互に連携している 該 価格範 囲お よび該 正直 価格を 含む該価格設定データを 提示する インターフェースを該ユーザデバイス上に表示させる ことと のための命令である、 コンピュータ可読 媒体。
- 16複数の ディーラ から前記1つ以上のディーラ を選択する ための、前記プロセッサによって実行可能なコンピュータ命令 を さらに 含む、請求項15に記載のコンピュータ可読媒体。
- 17少なくとも部分的に、個々のディーラによって提案された車両価格と、該車両価格が提案された買い手に車両が販売された実際の価格との間の相互関係に基づいて、前記複数のディーラの各個々のディーラに対する 品質スコアを 計算 する ための、前記プロセッサによって実行可能なコンピュータ命令 をさらに含む、請求項16に記載のコンピュータ可読媒体。
- 18前記ディーラによって提案された前記車両価格と、該車両価格が提案された前記買い手に前記車両が販売された前記実際の価格との間の差異に基づいて、 前記品質スコア を減少させるための、前記プロセッサによって実行可能なコンピュータ命令をさらに含む 、請求項17に記載のコンピュータ可読媒体。
- 19前記ディーラは、 各個々の ディーラ の 前記品質スコアまたは該 個々の ディーラに関連する在庫に基づいて 、前記コンピュータによって 選択される、請求項 17 に記載のコンピュータ可読媒体。
- 20個々の ディーラ の 前記品質スコアを使用して 、該個々のディーラによって提案された 前記 正直 価格を調整する ための、前記プロセッサによって実行可能なコンピュータ命令 をさらに含む、請求項 17 に記載のコンピュータ可読媒体。
- 21前記ユーザデバイス上に表示された 前記インターフェースは、 入力手段を含み、該入力手段は、前記 ユーザが、 個々のディーラによって提案された 前記 正直 価格と併せて個人情報を提供することを可能に し 、 該 ユーザが該個人情報を提供すると 、 該ユーザに 該個々の ディーラ に関する情報 を提供す る、 請求項 15 に記載のコンピュータ可読媒体。
Independent claims21
152 paragraphs, as filed
(Mutual reference of related applications) This application is a US provisional patent application No. 61 / 095,550 by Taira et al. (Name "SYSTEM AND METHOD FOR AGGREGATION, ANALYSIS, and monetization of pricing distribution data for Vehicles and other commodities", September 2008. 9th application) (TCAR1110) and Taira et al., US provisional patent application No. 61 / 095,376 (named "SYSTEM AND METHOD FOR CALCULATING AND DISPLAYING complex product price distributions based on aggregation and analysis of individual transactions", September 9, 2008. Claiming the priority interests of Application) (TCAR1120), these applications are fully incorporated herein by reference for all purposes.
(Field of Invention) The present disclosure relates generally to sales generation. More specifically, the present disclosure relates to sales generation related to the presentation of product pricing data.
Consumers are at a disadvantage in serious negotiations, especially when they do not have or understand information about the desired product. Complex for consumers due to various factors such as the interdependence between local demand and the availability of products or product characteristics, the time points in the product life cycle in which transactions occur, and the interrelationships of various transactions with each other. The fact that negotiated transactions can be difficult to understand exacerbates this problem. For example, a seller may sacrifice a margin on one side of a transaction and recover that margin from another transaction with the same (or different) customer.
Moreover, the data currently available for complex transactions is a single dimension. To illustrate with a given example, the recommended price (eg $ 1,000) takes into account how sensitive the price is ($ 990 is a good or bad price)? It does not have to be. The recommended price will also gradually become inaccurate as the product, location, and availability of the specified product are defined with higher specificity. Dealers may also use different pricing for the same product sold to different people, and therefore do not disclose this pricing to consumers. These situations can be seen in various situations. In particular, the automobile trading process can involve this kind of complexity. This complexity is reflected in the lead generation tactics used in conjunction with the car trading process, especially in the online car trading scene. Traditionally, lead generation in the online car retail setting has been the main way for dealers to find buyers for their vehicles. Lead generation is based on the premise that the consumer provides the details of the personal information, which in turn is provided to the dealer who offers the price for the desired vehicle. This model of lead generation has caused disappointment for both customer bases. That is, dealers instead prefer to have potential buyers to visit the showroom and have the ability to maximize their margins by charging different prices for the same vehicle depending on the buyer. The dealer keeps the consumer<u style="single">Honesty</u>Contrary to reluctance to offer prices, dealers generally get low conversions for leads because buyers are generally hired from websites that are duplicated or have no market deals.
Therefore, there are many unmet demands when it comes to sales generation in the context of vehicle sales.
<p> Embodiments of sales generation using vehicle data systems and methods are presented herein. Specifically, embodiments of the present invention may include reverse read generation, whereby the vehicle data system may have one or more dealer prices associated with the specified vehicle or vehicle configuration. .. The user may use the vehicle data system to obtain pricing data corresponding to the desired vehicle configuration. Provided by the dealer in addition to the user when the pricing data associated with the given vehicle configuration is presented to the user<u style="single">Honesty</u>Prices may be offered and by providing their personal information, the user,<u style="single">Honesty</u>You may get the name of the dealer who is proposing the price, in addition,<u style="single">Honesty</u>Further offers may be offered for the opportunity to purchase the desired vehicle at a price. Sales generation may then be determined by an auction model with a unique price stated only by the designated dealer, as seen in some embodiments. Therefore, unlike traditional lead generation, leads remain of high quality as they are not distributed across multiple dealers.</p><p> Specifically, an embodiment of a vehicle data system is used to determine desired pricing data related to a desired vehicle configuration, including average prices, pricing distributions, price ranges, etc. associated with the desired vehicle configuration. You may have access to historical transaction data that may be processed. Then, to the user, of the selected dealer<u style="single">Honesty</u>Along with pricing, a display showing the desired pricing data can be presented. In this case, by presenting the dealer's pricing information, the dealer price may be known to the user at the relevant time when the potential buyer is likely to purchase, and the price (in other words, the user). Is presented at the end of the purchasing funnel (eg, when the user has a specified desired vehicle configuration to obtain pricing data).</p><p> In addition, the dealer price may be offered in a contextually attractive and overall reassuring manner based on the fact that the dealer price is not offered, and the dealer price may be offered instead of being offered in isolation. The buyer is presented in a complete situation where he recently paid for the same (or similar) vehicle in the local market. This type of sales generation is offered only to well-qualified leads, which is advantageous for dealers, and they are offered before reaching the dealer.<u style="single">Honesty</u>It is advantageous for consumers as it may be offered at a price. The effectiveness of such embodiments may be characteristic. In fact, while traditional reed generation has an average price per lead of about $ 20, conversions for such reeds can be less than 6%, resulting in a cost per sale of about $ 300. Using the system and method embodiments presented in the book, it is estimated that conversions on leads are about 20% and costs per sale can be less than $ 300.</p><p> These and other aspects of the invention will be better understood and interpreted when considered in conjunction with the following description and accompanying drawings. The following description is provided for illustration purposes, not limited purposes, showing various embodiments of the present invention and many specific details thereof. Many substitutions, modifications, additions, or rearrangements may be made within the scope of the present invention, and the present invention includes all such substitutions, modifications, additions, or rearrangements. (Item 1) A vehicle data system including one or more computing devices and a vehicle data system coupled to the one or more computer devices on the network is provided, and the vehicle data system is a data collection module and is on the network. Data collection configured to obtain historical transaction data from a set of data sources coupled to the vehicle data system, wherein the historical transaction data includes data relating to the vehicle transaction. A module and a processing module, wherein the processing module determines a plurality of sets of historical transaction data, and each of the plurality of sets of historical transaction data is related to a vehicle configuration. It is to determine the pricing data corresponding to the specified vehicle configuration, which is determined based on a set of transaction prices and the set of historical transaction data related to the specified vehicle configuration. A processing module and a sales generation module that are configured to do so, including one or more price ranges to be made, the sales generation module corresponding to the specified vehicle configuration and dealer.<u style="single">Honesty</u>A sales generation module and an interface module configured to determine pricing, receiving the specified vehicle configuration from a user on a computing device and generating an interface based on the pricing data. The interface is configured to do so, the pair of transaction prices, the price range, and the interlocking.<u style="single">Honesty</u>A system with an interface module that is configured to offer a price. (Item 2)<u style="single">Honesty</u>The system according to item 1, wherein determining the price comprises selecting the dealer. (Item 3) The system according to item 2, wherein the sales configuration module is further configured to determine the associated quality score for the dealer. (Item 4) The system according to item 3, wherein the quality score is based on the historical transaction data related to the dealer. (Item 5) The system of item 4, wherein the dealer is selected based on the quality score associated with the dealer or the inventory associated with the dealer. (Item 6)<u style="single">Honesty</u>The system of item 4, wherein the price is adjusted using the quality score associated with the dealer. (Item 7) The interface is provided by the user.<u style="single">Honesty</u>The item 1 is configured to provide an input means that allows the personal information to be provided in conjunction with the price, and to provide the dealer to the user when the user provides the personal information. system. (Item 8) Acquiring historical transaction data from a set of data sources, the historical transaction data includes data related to vehicle transactions, and determining a plurality of sets of historical transaction data. Each of the plurality of sets of historical transaction data is related to the vehicle configuration, and the computing device receives the specified vehicle configuration from the user and sets the price corresponding to the specified vehicle configuration. To determine the data, the pricing data is a set of transaction prices and one or more price ranges determined based on the set of historical transaction data associated with the specified vehicle configuration. Including and corresponding to the specified vehicle configuration and dealer<u style="single">Honesty</u>Determining a price and generating an interface based on the pricing data, the interface is interlocking with the set of transaction prices, the price range, and the said.<u style="single">Honesty</u>Methods, including that, are configured to offer prices. (Item 9)<u style="single">Honesty</u>8. The method of item 8, wherein determining the price comprises selecting the dealer. (Item 10) The method of item 9, further comprising a quality score associated with the dealer. (Item 11) The method of item 10, wherein the quality score is based on the historical transaction data associated with the dealer. (Item 12) The method of item 11, wherein the dealer is selected based on the quality score associated with the dealer or the inventory associated with the dealer. (Item 13) Using the quality score associated with the dealer,<u style="single">Honesty</u>The method of item 11, further comprising adjusting the price. (Item 14) The interface is provided by the user.<u style="single">Honesty</u>Item 8 is configured to provide an input means that allows the personal information to be provided in conjunction with the price, and to provide the dealer to the user when the user provides the personal information. The method described. (Item 15) A computer-readable medium comprising computer instructions that can be executed by a processor, the instructions being to obtain historical transaction data from a set of data sources, the historical transaction data being vehicle transactions. Including data about, and determining multiple sets of historical transaction data, each of the multiple sets of historical transaction data is relevant to the vehicle configuration and, in the computing device, the user. Receiving a specified vehicle configuration from and determining pricing data corresponding to the specified vehicle configuration, the pricing data relating to a set of transaction prices and the specified vehicle configuration. Includes one or more price ranges determined based on historical transaction data and corresponds to the specified vehicle configuration and dealer<u style="single">Honesty</u>Determining a price and generating an interface based on the pricing data, the interface is interlocking with the set of transaction prices, the price range, and the said.<u style="single">Honesty</u>A medium, which is an instruction for and to be configured to offer a price. (Item 16)<u style="single">Honesty</u>The computer-readable medium according to item 15, wherein determining the price comprises selecting the dealer. (Item 17) The computer-readable medium of item 16, further comprising determining a quality score associated with the dealer. (Item 18) The computer-readable medium of item 17, wherein the quality score is based on the historical transaction data associated with the dealer. (Item 19) The computer-readable medium of item 18, wherein the dealer is selected based on the quality score associated with the dealer or the inventory associated with the dealer. (Item 20) The said using the said quality score associated with the dealer<u style="single">Honesty</u>The computer-readable medium according to item 18, further comprising adjusting the price. (Item 21) The interface is provided by the user.<u style="single">Honesty</u>The computer readable according to item 16, configured to provide an input means that allows the personal information to be provided along with the price, and to provide the dealer to the user when the user provides the personal information. Medium.</p>
The drawings that accompany and form a portion of this specification are included to illustrate aspects of the designation of the invention. A clearer impression of the present invention, as well as the components and behavior of the systems provided in the present invention, is an exemplary embodiment, and thus non-limiting, illustrated in drawings in which the same reference number specifies the same component. It will become clearer by referring to various embodiments. It should be noted that the properties shown in the drawings are not necessarily shown at a constant scale.<figref num="1">FIG. 1 shows an embodiment of the topology of a vehicle data system.</figref><figref num="2">Figure 2 shows pricing data and<u style="single">Honesty</u>An embodiment of a method for determining and presenting pricing information is shown.</figref><figref num="3">Figure 3 shows<u style="single">Honesty</u>An embodiment of a method for determining pricing information is shown.</figref><figref num="4A">Figures 4A and 4B show<u style="single">Honesty</u>An embodiment of an interface for presenting pricing information and dealer information is shown.</figref><figref num="4B">Figures 4A and 4B show<u style="single">Honesty</u>An embodiment of an interface for presenting pricing information and dealer information is shown.</figref><figref num="5A">5A and 5B show an embodiment of a method for determining and presenting pricing data.</figref><figref num="5B">5A and 5B show an embodiment of a method for determining and presenting pricing data.</figref><figref num="6">FIG. 6 shows an embodiment of the vehicle data system architecture.</figref><figref num="7A">7A and 7B show an embodiment of a method for determining and presenting pricing data.</figref><figref num="7B">7A and 7B show an embodiment of a method for determining and presenting pricing data.</figref><figref num="8">FIG. 8 shows an embodiment of a method for determining and presenting pricing data.</figref><figref num="9">Figure 9 shows the distribution associated with the determination of the equation.</figref><figref num="10A">Figures 10A and 10B show embodiments of the interface for presenting pricing data.</figref><figref num="10B">Figures 10A and 10B show embodiments of the interface for presenting pricing data.</figref><figref num="11A">11A and 11B show embodiments of the interface for presenting pricing data.</figref><figref num="11B">11A and 11B show embodiments of the interface for presenting pricing data.</figref><figref num="12A">12A-12D show embodiments of the interface for obtaining the presentation of vehicle configuration information and pricing data.</figref><figref num="12B">12A-12D show embodiments of the interface for obtaining the presentation of vehicle configuration information and pricing data.</figref><figref num="12C">12A-12D show embodiments of the interface for obtaining the presentation of vehicle configuration information and pricing data.</figref><figref num="12D">12A-12D show embodiments of the interface for obtaining the presentation of vehicle configuration information and pricing data.</figref><figref num="13A">Figures 13 to 17 illustrate the creation of pricing data using a graph.</figref><figref num="13B">Figures 13 to 17 illustrate the creation of pricing data using a graph.</figref><figref num="14">Figures 13 to 17 illustrate the creation of pricing data using a graph.</figref><figref num="15">Figures 13 to 17 illustrate the creation of pricing data using a graph.</figref><figref num="16">Figures 13 to 17 illustrate the creation of pricing data using a graph.</figref><figref num="17">Figures 13 to 17 illustrate the creation of pricing data using a graph.</figref><figref num="18">Figures 18-21 show embodiments of the interface for presenting pricing data.</figref><figref num="19">Figures 18-21 show embodiments of the interface for presenting pricing data.</figref><figref num="20">Figures 18-21 show embodiments of the interface for presenting pricing data.</figref><figref num="21">Figures 18-21 show embodiments of the interface for presenting pricing data.</figref><figref num="22">FIG. 22 shows an embodiment of a method for determining dealer prices.</figref>
The present invention and its various properties and advantageous details will be described more fully with reference to non-limiting embodiments illustrated in the accompanying drawings and described in detail in the following description. Descriptions of known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the details of the invention. However, it should be understood that while showing preferred embodiments of the present invention, detailed description and specific examples are given for illustration purposes only and not for limiting purposes. Various alternatives, modifications, additions and / or rearrangements within the spirit and / or scope of the basic invention concept will be apparent to those skilled in the art from this disclosure. The embodiments described herein can be implemented in a suitable computer executable instruction present on a computer readable medium (eg, HD), a hardware circuit or equivalent, or any combination.
Prior to explaining specific embodiments, embodiments of a hardware architecture for implementing certain embodiments will be described herein. One embodiment may include one or more computers that are communicatively coupled to the network. As is known to those of skill in the art, a computer is a central processing unit (CPU), at least one read-only memory (ROM), at least one random access memory (RAM), and at least one hard drive (RAM). "HD"), and can include one or more input / output ("I / O") devices. I / O devices can include keyboards, monitors, printers, electronic pointing devices (mouse, trackball, stylist, etc.), or equivalents. In various embodiments, the computer has access to at least one database on the network.
ROM, RAM and HD are computer memories for storing computer instructions that can be executed by the CPU (in other words, can be executed directly or created executable by, for example, compiling, translating, etc.). The term "computer-readable medium" in the present disclosure is not limited to ROM, RAM, and HD, and may include any type of data storage medium that can be read by a processor. In some embodiments, the computer-readable medium is a data cartridge, data backup magnetic tape, floppy (registered trademark) diskette, flash memory drive, optical data storage drive, CO-ROM, ROM, RAM, HD, or equivalent. You may point to.
At least some of the functionality or processes described herein can be implemented in suitable computer executable instructions. Computer-executable instructions can be one or more computer-readable media (non-volatile memory, volatile memory, DASD array, magnetic tape, floppy (registered trademark) diskette, hard drive, optical storage device, etc., or any other suitable. It may be stored as a software code component or module on a computer-readable medium or storage device. In one embodiment, the computer executable instructions may include a set of compiled C ++, Java®, HTML, or any other programming or scripting code.
Also, the functionality of the disclosed embodiments may be implemented on one computer or shared / distributed among one or more computers within or through the network. Communication between computers that implement the embodiments can be achieved using any electronic, optical, radio frequency signal, or other suitable methods and tools of communication that follow known network protocols.
As used herein, the terms "provide," "provide," "include," "include," "have," "have," or any other variation thereof. , Intended to include comprehensive inclusion. For example, a process, article, or device with a list of elements does not necessarily limit only those elements, but is not explicitly described, or other process, article, or device specific to such process, article, or device. Elements may also be included. Moreover, unless explicitly stated on the contrary, "or" refers to inclusive or rather than exclusive or. For example, states A or B are satisfied by one of the following: A is true (or exists), B is false (or does not exist), and A is false (or does not exist). Or does not exist, and B is true (or exists), and both A and B are true (or exist). Moreover, any example or figure provided herein shall never be deemed to limit, limit, or represent the definition of any term or terms used with them. To do. Instead, these examples or figures are described with respect to one embodiment and are considered as illustrations only. Those skilled in the art will appreciate that any term or term used in these examples or figures may or may not be provided in the specifications or elsewhere. It will be appreciated that all such embodiments are intended to be contained within the scope of a term or a plurality of terms. Languages that specify such non-limiting examples and diagrams include "eg (for example)", "eg (for instance)", "eg (eg)", and "one embodiment". , Not limited to these.
The present invention and its various properties and advantageous details will be described more fully by reference to non-limiting embodiments illustrated in the accompanying drawings and described in detail in the following description. These embodiments were filed on September 9, 2009 (TCAR1110-1) in the US patent by Taira et al., No. / Title "SYSTEM AND METHOD FOR AGGREGATION, ANALYSIS, PRESENTATION AND MONETIZATION OF PRICING DATA FOR VEHICLES AND OTHER COMMODITIES And the US patent No. __ / _____ by Taira et al., Filed on September 9, 2009 (TCAR1120-1), entitled "SYSTEM AND METHOD FOR CALCULATING AND DISPLAYING PRICE DISTRIBUTIONS BASED ON ANALYSIS OF". It may be better understood by reference to "TRANSACTIONS", which are incorporated herein by reference in their entirety for all purposes. Descriptions of well-known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the details of the present invention, however, with reference to preferred embodiments of the present invention. It should be understood that the specific examples are for illustration purposes only and are not given for limiting purposes. Various substitutions, modifications, additions, and / or rearrangements within the spirit and / or scope of the concepts of the invention will be apparent to those skilled in the art from this disclosure. For example, although embodiments of the present invention have been shown using merchandise as an example of a vehicle, it should be understood that other embodiments may be applied equally effectively to other merchandise.
As mentioned above, the lead generation strategy used in conjunction with the automotive trading process can be a problem. Traditionally, lead generation in the case of online car retailers has been a major way for dealers to find buyers for their vehicles. Lead generation is based on the premise that the consumer provides the details of the personal information, which in turn is provided to the dealer who offers the price for the desired vehicle. This model of lead generation is problematic for a variety of reasons. Consumers generally do not want to provide personal information because of privacy concerns and the fact that providing this personal information invites annoying and selfish trade solicitations from dealers. In addition, due to the low conversion rates of these types of leads, dealers may be reluctant to pay significant fees for such leads (this fee increases overall marketing costs per vehicle sold). To let you). Therefore, such lead providers typically use a "shotgun" approach, thereby obtaining multiple leads, including consumer personal information and personal information that may include the desired vehicle configuration. Provided to the dealer. Dealers are also openly accessible (eg on the website)<u style="single">Honesty</u>Reluctant to provide pricing information, it may be concerned that by offering such a price to one customer, it may unwillingly offer the same price to all customers. Because. This may be the case where a law may require the dealer to comply with publicly announced prices. This can be a problem for dealers as they may want to keep their margins high while retaining the ability to charge the same vehicle for different prices due to their ability to negotiate with designated consumers. Therefore, dealers are ready to purchase consumers to increase the conversion rate of such data presentations.<u style="single">Honesty</u>I want a way to present pricing information. Consumers, on the other hand, want to present pricing data in highly relevant cases, without necessarily having to provide any personal information.
In order to achieve these results, particular attention is currently focused on sales generation embodiments using the vehicle data systems and methods presented herein. Specifically, embodiments of the present invention may include reverse read generation, whereby the vehicle data system may have one or more dealer prices associated with the specified vehicle configuration. The user may use the vehicle data system to obtain pricing data corresponding to the desired vehicle configuration. The user is suggested by the dealer when the pricing data associated with the vehicle configuration specified by the user is presented.<u style="single">Honesty</u>Prices may be further offered, and by providing their personal information, the user can<u style="single">Honesty</u>You may get the name of the dealer who proposes the price, plus that<u style="single">Honesty</u>Opportunities may be offered to purchase the desired vehicle (or vehicle having a structure similar to the desired vehicle) at a price (eg, when the user visits the dealer). Sales generations then offer a designated dealer or a set of dealers (suggesting the lowest dealer price or paying the highest amount to the lead and displaying their), as can be seen in some embodiments.<u style="single">Honesty</u>One dealer or one who proposes to have a price or currently has the highest quality score with the desired or similar vehicle inventory, or offers some combination of the listed factors or other factors. It may be determined by an auction model with a unique price stated (which may be more than one dealer). Therefore, unlike traditional lead generation, leads remain of high quality as they are not distributed across multiple dealers.
Specifically, an embodiment of a vehicle data system is used to determine desired pricing data related to a desired vehicle configuration, including average prices, pricing distributions, price ranges, etc. associated with the desired vehicle configuration. You may have access to historical transaction data that can be processed. The user then selects the dealer<u style="single">Honesty</u>A display showing the desired pricing data can be presented along with the pricing. By presenting the dealer's pricing information in this regard, the dealer price is a reasonable vehicle configuration that potential buyers are likely to purchase (eg, the desired vehicle configuration for the user to obtain pricing data once). Is presented at the time (determined) and at the end of the purchasing funnel where the price may be unknown to the user (eg, when the user has the desired vehicle configuration specified to obtain pricing data).
In addition, dealer prices are not presented in isolation, but are associated with a general overview of what other buyers have recently paid for the same (or similar) vehicle in the local market. It may be presented in a contextually attractive and overall reassuring manner. This type of sales generation is advantageous for dealers as only well-qualified leads are shown, and consumers are offered before reaching the dealer.<u style="single">Honesty</u>It is advantageous for consumers as the price can be offered.
The same or similar historical transaction data obtained from the dealer and used by the system to determine vehicle configuration pricing data is provided to the user.<u style="single">Honesty</u>The dealer who offered the price may be further used to determine whether or not the vehicle was actually sold to any of those users. If such a sale occurs, it will be suggested to the user by the vehicle data system along with its dealer and vehicle.<u style="single">Honesty</u>The relationship between the price and the actual price at which the vehicle was sold to the user can be determined. was suggested<u style="single">Honesty</u>The relationship of price to the actual price at which the vehicle was sold may be used to determine or adjust the dealer's quality rating, and the various dealer quality grades are then which<u style="single">Honesty</u>The price may be incorporated into the decision to present the price to the user by the vehicle data system.
The data obtained from the dealer by the vehicle data system may also include inventory data corresponding to the dealer, in other words, which vehicle configuration the dealer currently has in inventory. The desired structure of the vehicle (not just the vehicle name and model, but also, for example, color, powertrain, number of doors, etc.) can be important to the user and is currently desired in the desired vehicle configuration or specified attributes. It may be desirable for a dealer with a vehicle configuration similar to the vehicle configuration to offer a price to the user. Therefore, the dealer's inventory, which includes vehicles similar to the user's desired vehicle configuration in the dealer's current inventory, is the dealer's throat.<u style="single">Honesty</u>It may be used alone or in addition to the dealer's quality score and other factors to determine whether to offer the price to the user. As noted, in many cases the dealer does not have a vehicle with the exact desired structure of the user in certain embodiments, thus addressing each possible vehicle configuration.<u style="single">Honesty</u>Instead of offering a price, the dealer provides, for example, the dealer and an invoice offset that may be associated with the vehicle name of the specified vehicle, the vehicle name and model of the specified vehicle, the vehicle name model and trim, etc. You may. Therefore, by leveraging the fact that the vehicle data system may have access to invoice pricing data, the dealer's<u style="single">Honesty</u>Prices are for the specified vehicle configuration associated with that dealer<u style="single">Honesty</u>To determine the price, it may be calculated by determining the invoice price for the user's desired structure and adding (or subtracting) the deline voice offset from the determined invoice price. .. As mentioned above, the dealer price (or invoice offset) for each dealer is for which dealer<u style="single">Honesty</u>Note that it may be used alone or in addition to the dealer's quality score and other factors to determine whether to offer the price to the user.
Embodiments of the systems and methods of the invention may be further described with reference to FIG. 1, which shows one embodiment of a topology that may be used to implement embodiments of the systems and methods of the invention. Good. Topology 100 goes through network 170 to computing devices 110 (eg, computer systems, personal data assistants, kiosks, designated terminals, mobile phones, smartphones, etc.) and one or more computing devices in inventory company 140. Connected vehicle data system 120 (also referred to herein as TrueCar system), counterparty trademark product manufacturing (OEM) 150, sales data company 160, financial institution 182, external source 184, Land Transport Authority (DMV) Includes a set of entities, including 180, and one or more related sales position points, in this embodiment, the automotive dealer 130. Network 170 may be, for example, the Internet or Wide Area Network (WAN), Public Switched Telephone Network (PTSN), or any other type of electronic or non-electronic communication link such as mail, courier (registered trademark), or equivalent. It may be a wireless or wired communication network.
The vehicle data system 120 is a central processing unit that executes instructions that are incorporated on one or more computer-readable media in which the instructions are configured to perform at least some of the functionality associated with embodiments of the present invention. It may include one or more computer systems having. These applications are configured to implement the interface module 192, data acquisition module 194, processing module 196, and sales generation module 198 used by the vehicle data system 120, one or more applications (on computer readable media). May include a vehicle data application 190 that includes an instruction) incorporated in. In addition, the vehicle data system 120 provides dealer information, dealer inventory, and dealer information.<u style="single">Honesty</u>Obtained data 124 such as pricing, data 126 determined during operation such as quality score for dealers, model 128 which may include a set of dealer cost or price ratio models, or implementation of the invention. It may include a data storage device 122 capable of storing any other type of data related to the embodiment or determined during the implementation of these embodiments. More specifically, in one embodiment, the data stored in the data storage device 122 may include a set of dealers corresponding to dealer information such as the name and location of the dealer, the name of the vehicle sold by the dealer, and the like. Good. Each set of dealers is a list of one or more vehicle configurations and associated<u style="single">Honesty</u>May be price related and related to vehicle composition<u style="single">Honesty</u>The price is related to the lowest price that the dealer will offer to the user for its vehicle configuration. The data in the data storage device 122 may also include, for each dealer, an inventory list associated with each of the set of dealers, which currently includes the vehicle configuration in inventory. The quality score may also be associated with each of the set of dealers in the data storage device 122.
The vehicle data system 120, for example, in the computing device 110 to receive a query from a user and obtain the corresponding data, is an inventory company 140, a manufacturer 150, a sales data company 160, a financial institution 170, a DMV 180, or a dealer. Data that interfaces with 130 or is acquired or determined by the vehicle data system 120 can be stored in inventory company 140, manufacturer 150, sales data company 160, financial institution 182, DMV180, external data source 184, or dealer 130. A wide range of functionality may be provided, including the use of one or more interfaces 192 configured to provide for any of. The designated interface 192 used in a given case is the functionality performed by the vehicle data system 120, the type of network 170 used to communicate with any designated entity, obtained or presented. It should be understood that it may vary depending on the type of data, the time interval in which the data is obtained from the entity, the type of system used by the various entities, and so on. Therefore, the interface is, for example, a web page, web service, data entry or database application that can be accessed by the operator, or in any case it is desirable to use it. Other types of interfaces may be included.
Generally, then using these interfaces 192, the vehicle data system 120 is one of an inventory company 140, a manufacturer 150, a sales data company 160, a financial institution 182, a DMV 180, an external data source 184 or a dealer 130. Data can be acquired from various sources including the above and such data can be stored in the data storage device 122. This data is then grouped, analyzed, or otherwise processed by the vehicle data system 120 to determine the desired data 126 or module 128 that is also stored in the data storage device 122. The user may access the vehicle data system 120 through the provided interface 192 in the computing device 110 and specify specified parameters such as the desired vehicle configuration. The vehicle data system 120 can select or generate data using the processing module 196 and using the sales generation module 198.<u style="single">Honesty</u>Further pricing information may be generated. The interface is processed and processed using the selected dataset, interface module 192.<u style="single">Honesty</u>It can be generated from the data determined from the pricing information and from these interfaces presented to the user on the user's computing device 110. More specifically, in one embodiment, interface 192 may visually present this data to the user in a very intuitive and useful way.
Specifically, in one embodiment, the visual interface is a quantifiable price or price range (eg, invoice price, MSRP, dealer cost, market average, internet average, etc.) for a reference pricing data point. For example, at least a portion of the selected dataset may be presented as a price curve, bar chart, histogram, etc. that reflects (eg, "average", "good", "excellent", "too high", etc.). The visual interface is also<u style="single">Honesty</u>Pricing information is relevant and contextually presented (in other words, for a given vehicle configuration<u style="single">Honesty</u>Pricing information may be presented in the case of pricing data related to the specified vehicle configuration) along with the selected dataset.<u style="single">Honesty</u>Pricing information may be presented.
With reference to various other entities in Topology 100, the dealer 130 may be a retailer of vehicles manufactured by one or more OEM 150s. The dealer 130 may use the dealer management system (DMS) 132 to track or otherwise manage the need for sales, finance, parts, services, inventory and administration. Since many DMS 132s are based on the Active Server Page (ASP), the transaction data 134 has a "key" (eg, set permission within the DMS system 132) that allows the data to be retrieved from the DMS system 132. ID and password) may be obtained directly from DMS132. Many dealers 130 may also have one or more websites that may be accessed over network 170, where any pre-determined pricing, or<u style="single">Honesty</u>Pricing data for dealer 130s, including pricing, may be presented on their websites. This price is generally a "non-negotiated" (non-negotiated price) price and may be considered a "reasonable" price by the vehicle data system 120.
In addition, the dealer's current inventory may be obtained from DMS132 and associated with that dealer's information in data storage 122. The dealer 130 also has one or more operators of the vehicle data system 120 (either in some other electronic format or some non-electronic format via the network 170).<u style="single">Honesty</u>Prices may be offered. these<u style="single">Honesty</u>Each of the prices is related to vehicle composition<u style="single">Honesty</u>The list of prices may be related to the vehicle configuration so that it may be related to the dealer in the data storage device 122. As mentioned above, in one embodiment, this<u style="single">Honesty</u>The price may include the difference from the inventory price of the vehicle configuration.<u style="single">Honesty</u>Note that prices may be offered at almost any level of desired particle size. For example, a single<u style="single">Honesty</u>Prices correspond to all vehicles with the specified vehicle name sold by the dealer, all vehicles with the specified vehicle name and model sold by the dealer, the specified vehicle name, model and trim sold by the dealer, etc. You may.
The inventory company 140 may obtain and store inventory data from one or more dealers 130 (eg, obtain such data from DMS 132), one or more inventory polling companies, inventory management companies, or listings. It may be an aggregator. Inventory polling companies are generally entrusted by dealers to extract data from DMS132 and format the data for use on websites and by other systems. The inventory management company manually uploads inventory information (photos, descriptions, specifications) on behalf of the dealer. Listing collectors retrieve their data by "scraping" or "spidering" websites displaying inventory and receiving feeds directly from listing websites (eg Autotrader, FordVehicles.com). To do.
The DMV180 may collectively include any type of government entity for which the user provides vehicle-related data. For example, when a user purchases a vehicle, he or she must register with the state (eg, DMV, Secretary of Internal Affairs and Communications, etc.) for tax and titling purposes. This data generally includes vehicle attributes (eg, year, vehicle name, model, mileage, etc.) and sales transaction prices for tax purposes.
The financial institution 182 may be any entity, such as a bank, savings loan, credit union, etc., that provides any type of financial services to participants involved in the purchase of a vehicle. For example, when a buyer buys a vehicle, they may use a loan from an institution, where the loan process usually requires two steps: applying for a loan and contracting for a loan. .. These two steps may use vehicle and consumer information for financial institutions to properly assess and understand lending risk factors. In general, both the loan application and the loan agreement include the suggested and actual selling prices of the vehicle.
Sales data company 160 may include any entity that collects vehicle sales data of any kind. For example, a syndicated sales data company aggregates new and used car sales transaction data from the designated dealer 130's DMS132 system. These companies allow them to retrieve data from dealers 130 in order to aggregate the data they collect for the purposes of internal analysis or external purchase of data by other data companies, dealers, and OEMs. You may have a formal contract with your dealer 130.
Manufacturer 150 is the entity that actually manufactures the vehicles sold by the dealer 130. To guide their vehicle pricing, Manufacturer 150 has invoice prices and manufacturers for both vehicles and these vehicle options to use as a general guideline for dealer costs and pricing. A suggested price range (MSRP) may be provided. These fixed prices are set by the manufacturer and may vary slightly depending on the geographic area.
External Source 184 relates to any number of other sources, online or otherwise desired data of other types, such as vehicles, pricing, vital statistics, economic conditions, markets, regions, consumers, etc. It may include a source that provides the data.
Here, all of the various entities shown in Topology 100 are not necessary or desirable in the embodiments of the present invention, and the designated functionality described with respect to the entities shown in Topology 100 is single. Note that it may be combined with the entity or eliminated altogether. Also, in some embodiments, other data sources not shown in Topology 100 may be used. Therefore, Topology 100 is for illustrative purposes only and should not be construed as any limitation of embodiments of the present invention.
Before exploring the details of the various embodiments of the invention, it is helpful to once again use the vehicle as an example to provide a general overview of the embodiments of the invention with respect to the aforementioned embodiments of the topology. Maybe. At regular intervals, the vehicle data system 120 then collects data from one or more of the inventory company 140, the manufacturer 150, the sales data company 160, the financial institution 182, the DMV180, the external data source 184, or the dealer 130. May be obtained by This data comes from various vehicle configurations, inventory data, registration data, financial data, vehicle data, and dealers.<u style="single">Honesty</u>It may include sales or other historical transaction data such as prices (various types of data obtained will be described in more detail later). This data may be processed to generate a dataset corresponding to the specified vehicle configuration.
Then, at some point, the user may access the vehicle data system 120 in the computing device using one or more interfaces 192, such as a set of web pages provided by the vehicle data system 120. Using this interface 192, a user set of vehicle attributes (car make, model, trim, power train, options, etc.) other related, such as the value or geographic location of by defining the communication information, The vehicle configuration may be specified. Information related to the specified vehicle configuration may then be presented to the user via interface 192. This information includes pricing data corresponding to the specified vehicle configuration and the specified vehicle proposed to the user by the dealer.<u style="single">Honesty</u>Including price,<u style="single">Honesty</u>Pricing information may be included.
Specifically, pricing data and<u style="single">Honesty</u>Pricing information may be determined and visually presented to the user. Specifically, in one embodiment, a price curve representing actual transaction data associated with a given vehicle configuration, along with a visual reference representing one or more price ranges and one or more reference price ranges. It may be visually displayed to the user. These visual indicators may be displayed so that the user can easily determine what percentage of consumers have paid a certain price or price distribution within a price range.
in addition,<u style="single">Honesty</u>Pricing information may be presented visually in the case of this pricing data. In this case, of the vehicle specified by the user<u style="single">Honesty</u>By presenting pricing information, the user can such<u style="single">Honesty</u>It may be better to determine how pricing information relates to the actual price paid for the same vehicle.
further,<u style="single">Honesty</u>The interface used to present pricing data to the user may allow or provide the ability for the user to enter personal information (name, address, telephone number, comments, etc.). Presented to the user when the user provided such personal information<u style="single">Honesty</u>The name, address, etc. of the dealer offering the price may be provided. In addition, the dealer may be given the user's personal information by the operator of the vehicle data system. User provided<u style="single">Honesty</u>In this way, the user does not provide the personal information, as it is unlikely to provide such personal information unless he is completely interested in buying the vehicle at a price.<u style="single">Honesty</u>You may actually get the price and quality leads offered to the dealer. Besides, the dealer is a single dealer<u style="single">Honesty</u>Low because only the price may be presented to the user<u style="single">Honesty</u>Offering and suggested<u style="single">Honesty</u>You may be advised to actually sell the vehicle at a price,<u style="single">Honesty</u>The dealer whose price is presented to the user<u style="single">Honesty</u>The price itself (eg, lowest price, highest inventory offset, etc.), the quality score associated with the dealer, the dealer's inventory, the amount the dealer pays the lead (eg, consumer information) or is willing to display the dealer's price. , A combination of these factors, or all of the other factors.
From now on, proceeding to FIG. 2 presents an embodiment of a method for operating a vehicle data system to include sales generation. In step 252, the vehicle data system may receive the specified vehicle configuration via the provided interface. In one embodiment, for example, the user may select a specified vehicle configuration using one or more menus on a web page provided by the vehicle data system 120, or provide a specified vehicle configuration. You may navigate through a series of web pages to do so. This specified vehicle configuration may include a set of desired vehicle attribute values such as vehicle name, model, trim level, and one or more options. The user may also specify the geographic location where the user is located or will purchase the vehicle of the specifications provided.
Pricing data associated with the specified vehicle configuration may then be determined by the vehicle data system 120 in step 262. This data may include adjusted transaction prices, averages, centers, and probability distributions of pricing data related to the specified vehicle configuration within the specified geographic area (eg, the specified geographic location). Calculating a set of quantifiable price ranges or ranges (eg, prices or price ranges such as "average", "good", "excellent", "overpriced"), historical price trends or pricing forecasts Determine, or determine any other type of desired data. In one embodiment, the data associated with the specified vehicle configuration may be determined using a price ratio model and historical transaction data associated with the specified vehicle configuration described below.
<u style="single">Honesty</u>Pricing information may be determined for the designated vehicle and user in step 272. this<u style="single">Honesty</u>Pricing information is for a vehicle configuration similar to the one specified in the specified vehicle configuration or one or more attributes.<u style="single">Honesty</u>The price may be included.<u style="single">Honesty</u>Pricing information decisions are provided by the dealer and the user's geographic location, the quality score associated with the dealer, the dealer's inventory, and the dealer.<u style="single">Honesty</u>It may be based on one or more of various factors, including price, or any of many other factors. like that<u style="single">Honesty</u>Embodiments of determining pricing information will be described in more detail later.
Then related to the determined pricing data and the specified vehicle configuration<u style="single">Honesty</u>An interface for presenting pricing information may be generated in step 282.
These interfaces are, for example, for bar charts, histograms, Gaussian curves with indicators for a specified price range, graphs with trend lines showing historical trends or price forecasts, dialog boxes, pop-up windows, or visual presentation of data. It may include a visual presentation of such data using any other desired format of. Specifically, in one embodiment, the determined data, along with visual indicators above or below the curve indicating the determined price range or range, are the actual transactions associated with the specified vehicle configuration. It may match and be displayed as a Gaussian curve showing the data. One of these visual indicators was determined for the designated dealer<u style="single">Honesty</u>Will correspond to the price. Also, the window will automatically pop up or pop up so that the user may provide personal information.<u style="single">Honesty</u>It may pop up when the mouse hovers over the price. Here, the interface detailed in connection with the presentation of data to the user, along with the specified embodiment, is a visual interface, but voice, tactile, some combination, or entirely other method. Note that other interfaces that use may be used in other embodiments to present such data.
The interface may be distributed via various channels in step 292. Channels are applications based on consumer facing networks (eg, they may be accessed on the network by computing devices such as computers or mobile phones, and are adapted for use by the consumer's request or by them. , A set of web pages provided by the vehicle data system 120), text or multimedia messaging services, widgets for use in websites or other application settings such as mobile phone applications, accessible via the phone Voice application, or any other desired channel.
The distribution of this data across these various channels may be monetized in step 294. Specifically, with respect to sales generation, the dealer or other entity is on the interface presented by the vehicle data system.<u style="single">Honesty</u>You may pay the operator of the vehicle data system for the ability to provide pricing data, or in conjunction with their sales generation, to have the user's personal information provided to them. Note that many other monetization opportunities may come to vehicle data system operators in conjunction with sales generation. Here, it may be useful to be more detailed with respect to sales generation using vehicle data system embodiments. See Figure 3 for the specified vehicle<u style="single">Honesty</u>An embodiment of a method for generating pricing data is presented. At step 312, the vehicle configuration may be received. This vehicle configuration may again receive the specified vehicle configuration via the provided interface. In one embodiment, for example, in a web page provided by the vehicle data system 120, to use one or more menus to select a specified vehicle configuration or to provide a specified vehicle configuration. You may navigate to a set of web pages. This specified vehicle configuration may include values for a set of desired vehicle attributes such as vehicle name, model, trim level, one or more options. The user may also specify the geographic location where the user is located or will purchase the vehicle of the specifications provided.
Then, in step 322, a set of dealers may be determined using the specified vehicle configuration. This selected set of dealers may be determined based on a wide variety of factors. One of these factors may be geography, for example any dealer within a distance of a user's specified geographic location may be selected. The decision of a set of dealers may also be based on the inventory of selected dealers. For example, in one embodiment, only dealers with the vehicle name and model of the vehicle, or dealers with vehicles of the specified vehicle name, model and trim may be selected. In another embodiment, the match ratio may be with vehicles in stock at each dealer, and only dealers who currently have vehicles that match the vehicle configuration specified by the user over a percentage are selected. May be done. Other factors, combinations of factors, and algorithms for applying these factors to select a dealer may also be used.
In one designated embodiment, the quality score may be used at least partially to select the dealer. More specifically, the quality score may be associated with each dealer, and the quality score was proposed by the dealer.<u style="single">Honesty</u>The price is determined based on the interrelationship between the price and the actual price at which the vehicle was actually sold to the proposed user. Specifically, the dealer who published the "decoy sale" price has a reduced quality score (in other words, the quality score was proposed.<u style="single">Honesty</u>Price and<u style="single">Honesty</u>The price-related vehicle is reduced when there is some threshold amount difference from the price actually sold to the user). This quality score may then be used in the algorithm used to select the dealer.
Then the excellence from the selected pair of dealers<u style="single">Honesty</u>The price may be determined in step 332. Which user<u style="single">Honesty</u>Criteria for determining whether a price is excellent are proposed by, for example, a dealer.<u style="single">Honesty</u>It may be fully accompanied by various factors including price, quality score associated with the dealer, geographical proximity of the dealer to the user, or some other factor. In one embodiment, as described above, in many cases the dealer will accommodate each possible vehicle configuration, as in certain embodiments it is not necessary to have a vehicle with the exact desired structure of the user. To do<u style="single">Honesty</u>Instead of offering a price, the dealer provides, for example, an invoice offset that may be associated with the dealer, as well as the vehicle name of the vehicle, the vehicle name and model of the designated vehicle, the vehicle name, model and trim of the vehicle, etc. You may. Therefore, leveraging the fact that the vehicle data system may have access to invoice pricing data, for dealers with specified vehicle configurations.<u style="single">Honesty</u>The price is calculated by determining the invoice price for the specified vehicle configuration and adding (or subtracting) the invoice offset from the specified vehicle configuration (or some attribute thereof) provided by that dealer. May be good. Then the cheapest<u style="single">Honesty</u>The price is excellent<u style="single">Honesty</u>It may be selected as the price.
Excellent in one embodiment<u style="single">Honesty</u>Calculated for the selected set of dealers using the dealer's quality score before choosing a price<u style="single">Honesty</u>Adjust the price and which dealer's<u style="single">Honesty</u>Use the dealer's quality score to help determine if the price is excellent<u style="single">Honesty</u>The price may be adjusted. For the sales generation embodiment described, the quality score selects the dealer,<u style="single">Honesty</u>It should be noted that pricing may be determined and used for some combination of both, or the dealer's quality score may not be used at all in conjunction with certain embodiments. In one designated embodiment, which dealer and<u style="single">Honesty</u>The decision on whether a price will be chosen is how much each dealer is willing to pay the lead or display the price (the higher amount is for that dealer).<u style="single">Honesty</u>Price is chosen, may bring higher possibility),<u style="single">Honesty</u>Price (cheapest<u style="single">Honesty</u>The price is likely to be selected by the dealer or the dealer quality score (higher quality score is the dealer's)<u style="single">Honesty</u>The price may be determined using a combination of sizes) (which increases the likelihood that the price will be selected).
excellence<u style="single">Honesty</u>Once the price is determined, it may be presented to the user at 342. In one embodiment, this<u style="single">Honesty</u>Pricing was presented in the case of pricing data related to the specified vehicle configuration and presented by the user.<u style="single">Honesty</u>Users may be provided with an interface for providing personal information if they wish to be presented with information about the dealer offering the price. like that<u style="single">Honesty</u>Price suggested by dealer<u style="single">Honesty</u>It should be noted that while pricing can be accurate according to pricing, pricing can still lead to consumer disappointment (eg, certain attributes are very important to the user). Shown to consumers to improve this<u style="single">Honesty</u>Pricing information can include the percentage of vehicle fit with the vehicle actually available at the distributor (potentially including a complete breakdown of vehicle attributes).
Here, it may be useful if embodiments of such an interface are described in more detail and concisely. Figure 4A shows the user with the specified vehicle configuration, along with the presentation of pricing data for the specified vehicle configuration.<u style="single">Honesty</u>An embodiment of an interface for presenting pricing information is shown. A Gaussian curve 1410 may be shown to illustrate a normalized pricing distribution (eg, a normalized transaction price distribution). On the X-axis of the curve, the average price paid may be displayed with the determined dealer price, invoice, or over-the-counter price to show the relevance and relationship of these prices to the transaction price. .. Determined price ranges such as "good", "excellent", "too high", etc. are also visually displayed below the displayed curve to allow the user to identify these ranges. The curve.
in addition,<u style="single">Honesty</u>The price 1420 is for the user<u style="single">Honesty</u>It may be displayed as a visual indicator on the x-axis so that you can see if the price 1420 fits into this relationship with the offered price or price range. In addition, window 1430 allows the user to do so<u style="single">Honesty</u>If you wish to get information about the dealer who offers the price 1420, it may be presented where users may enter their personal information.
Returning to FIG. 3, if such user information is received in step 352, the dealer information may be presented in step 362. Figure 4B is presented<u style="single">Honesty</u>An embodiment of one interface for presenting price-related dealer information is shown. This interface was proposed by dealer information, pricing data, vehicle configuration data, and dealers.<u style="single">Honesty</u>It may include instructions for obtaining the price.
With reference to FIG. 3 again, at least at some point thereafter, in step 372, data about the dealer may be obtained manually, for example, from the DMS associated with the dealer, or via follow-up or equivalent. It was then presented using the data obtained corresponding to that dealer.<u style="single">Honesty</u>It is possible to determine whether or not the transaction corresponding to the price actually occurred. In other words, the designated dealer can determine whether a vehicle of the same or similar construction has been sold to the designated user. If a corresponding transaction occurs, the transaction price associated with that transaction (the price actually paid by the user) was proposed to the user by the dealer for the specified vehicle.<u style="single">Honesty</u>It may be compared to the price and the comparison used to determine or adjust the quality score corresponding to the dealer in step 382. Almost all algorithms, as desired, include such transaction data and<u style="single">Honesty</u>It will be clear that it may be used to generate a quality score from pricing information.
From now on, other embodiments of the vehicle data system that may be used in conjunction with the sales generation embodiments described above will be described in more detail. From now on, returning to FIGS. 5A and 5B, one embodiment of specifying a method for operating a vehicle data system is illustrated. First, referring to the embodiment of FIG. 5A, in step 210, the data is coupled to the vehicle data system 120 to one or more data sources (inventory company 140, manufacturer 150, sales data company 160, financial institution 182). , DMV180, external data source 184, dealer 130, etc.), and the obtained data can be stored in the associated data storage device 122. Specifically, the data to be obtained may include the step of collecting the data by requesting or receiving the data from the data source. With respect to the data obtained from the data sources, different data are obtained from different data sources at different intervals, and previously obtained data are new data of the same type obtained and stored in the data storage device 122. Please note that it may be archived before.
In some cases, some of the operators of these data sources provide the specified type of data, especially when such data contains personal information or certain vehicle information (VIN number, license plate number, etc.). You don't have to want that. However, it may be desirable to have such information in order to correlate with data corresponding to the same person, vehicle, etc., obtained from different data sources. To address this issue, operators of these data sources may send and store sensitive information in the data provided to the vehicle data system 120 as hash values into the data storage device 122. The operator of the vehicle data system 120 may provide the specified hashing algorithm and key. Because each data source uses the same hashing algorithm to hash the provided data, the same data value has the same hash value and was obtained from different (or the same) data sources. Facilitates matching or correlation between data. Therefore, the operator's concerns of the data source can be addressed while simultaneously avoiding adverse effects on the operation of the vehicle data system 120.
Once the data has been obtained and stored in the data storage device 122, the obtained data may be cleansed in step 220. Cleansing of this data may include evaluation of the data to determine if it matches, falls within a specified range, or overlaps with known values. Values that may be removed from data storage 122 when such data is found and are ineligible or out of threshold are one or more values (specifically known). , Or may be the default value), or some other action may be taken entirely.
The cleansed data may then be used in step 230 to form and optimize the sample dataset. This information and optimization process is applied to the dataset according to the region (eg, some other definition of geographic area such as national, local, regional, state, country, zip code, DMA, location within 500 miles). It may include a step of grouping the data and a step of optimizing these geographic datasets for a given vehicle configuration. This optimization process may result in one or more datasets corresponding to a set of vehicle attributes corresponding to a given vehicle or group or type of vehicle, vehicle and associated geography.
A set of models may be generated in step 240 using the dataset resulting from the optimization process. These models may include a set of dealer cost models corresponding to one or more datasets resulting from the optimization process described above. The average price ratio (eg, price paid / dealer cost) model for the dataset may also be generated using the data obtained. It should be noted that these models may be updated at specified intervals, such as the interval at which each dealer cost model or average price ratio model is generated, the interval at which data is obtained from various data sources, or others. It may or may not be related to the rate at which the model of is generated. Moving on to some of the embodiments illustrated in FIG. 5B, in step 250, the vehicle data system may receive the specified vehicle configuration via the provided interface. In one embodiment, for example, the user may select a specified vehicle configuration using one or more menus on a web page provided by the vehicle data system 120, or a specified vehicle configuration. You may navigate a set of web pages to provide. This specified vehicle configuration may include values for a set of attributes of the desired vehicle, such as vehicle name, model, trim level, and one or more options. The user may also specify the geographic location where the user is located or where he intends to purchase the vehicle of the provided specifications.
Other information that may be provided by the user may include incentive data for the specified vehicle configuration. In one embodiment, when the user specifies a specified vehicle configuration, the vehicle data system 120 is presented to the user with a set of incentives associated with the specified vehicle configuration, if any is available. Will be. The user may select zero or more of these incentives to apply.
Pricing data associated with the specified vehicle configuration may then be determined by the vehicle data system 120 in step 260. This data is the adjusted transaction price, mean, center, and probability distribution for pricing data related to the specified vehicle configuration within a geographic area (eg, including the specified geographic location). , Steps to calculate a set of quantifiable price ranges or ranges (eg, prices or price ranges such as "average", "good", "excellent", "overpriced"), and historical price trends or pricing expectations It may include a step of determining the desired data of any other kind and a step of determining the desired data. In one embodiment, the data associated with the specified vehicle configuration may be determined using the price ratio model and historical transaction data associated with the specified vehicle configuration described below.
An interface for presenting determined pricing data related to the specified vehicle configuration may then be generated in step 270. These interfaces are, for example, bar charts, histograms, Gaussian curves with indicators in a specified price range, graphs with trend lines showing historical trends or price forecasts, or any other desired for visual display of data. It may include a visual presentation of such data using the format of. Specifically, in one embodiment, the determined data is one or more quantifiable prices or one reference price point (eg, invoice price, MSRP, dealer cost, market average, dealer). Consistent with the Gaussian curve, which shows the actual transaction data related to the specified vehicle configuration, with a visual display on or below the curve showing the determined price range or range, such as cost, internet average, etc.) , May be displayed as it. The user may also be presented with data on any incentive data used to determine pricing data. Therefore, using such an interface, the user can easily determine a price range, what percentage of consumers have paid a price or a distribution of prices within a price range. Here, in conjunction with one embodiment, the interface described with respect to the presentation of data to the user is a visual interface, and other interfaces that use audio, tactile, some combination, or entirely other methods. Note that in other embodiments, it may be used to present such data.
The interface may be distributed through various channels in step 280. Channels are vehicle data that may be accessed over the network by consumer facing network-based applications (eg, in computing devices such as computers or mobile phones, and adapted to the consumer's wishes or uses. A set of web pages provided by System 120), a dealer facing network-based application (a set of web pages provided by Vehicle Data System 120, suitable for Dealer's request or use), text or multimedia messaging services. , Websites, or widgets used in other application settings such as mobile phone applications, voice applications accessible over the phone, or almost any other channel desired. The channels described elsewhere in this disclosure in relation to the data distribution may also be used to receive the data, and some combinations of the same or different channels may receive the data and the data. Note that it may be used to distribute.
The distribution of this data across these various channels may be monetized in step 290. This monetization was provided by selling displays or text ads, text links, sponsorships, etc. in conjunction with one or more interfaces (web pages, etc.) provided by the vehicle data system 120, one or more. Through the interface, it provides the user's ability to purchase vehicles from the dealer and charges the dealer, the user, or both to use this service, provides a berth auction system, thereby designated by the dealer. The price of the vehicle may be presented to the user and the dealer may be charged for this ability and charge the dealer or user for the obtained or determined data for permission or provision to the dealer or user. Recognize applications, features, or data related to vehicle data system 120, or in many ways, including requesting access to tools for manufacturers, dealers, financial institutions, leasing groups, and other end users. It may be achieved in almost any way desirable to achieve. As is clear from the overview of the above description, embodiments of the vehicle data system 120 may involve many processes occurring at substantially the same time or at different intervals, and many computing devices 110 are located anywhere. It may be desirable to access the vehicle data system 120 at the given time. Therefore, in some embodiments, the vehicle data system 120 may be implemented using an architecture or infrastructure that promotes cost savings, performance, fault tolerance, efficiency and scalability of the vehicle data system 120. An embodiment of such an architecture is illustrated in FIG. Specifically, one embodiment of the vehicle data system 120 is on a network that includes a web page that allows a user to specify a desired vehicle configuration and receive pricing data corresponding to the specified vehicle configuration. Access It may be operational to provide a network-based interface, including a set of capable web pages. Such a vehicle data system 120 uses a content delivery network (CDN) that is distributed over one or more networks and includes a data processing and analysis server 310, a service server 320, an origin server 330, and a server farm 340. Each server of the data processing and analysis server 310, the service server 320, the origin server 330, and the server farm 340 may be loaded with multiple network frameworks, or as the servers are known in the art. It may be placed in multiple locations using a network that may be balanced.
The data processing and analysis server 320 may obtain data from one or more data sources 350 at specified time intervals (eg, daily, weekly, hourly, certain ad hoc variation time intervals, etc.). Examples may interact with (described above) and process this obtained data as described above and in more detail later herein. This process includes, for example, cleansing the obtained data, determining and optimizing the sample set, generating a model, and the like.
The origin server 330 may add a web cache on each of the server farms 340 to the content for provisioning web pages of the interface to the user on the computing device 360 (the embodiment of which is described above). .. The server farm 340 uses the web cache of each server farm 340 to provide a set of web pages to the user on the computing device 110. More specifically, in Computing Device 360, a user is designated on a network so that he or she can interact with the web page to send and receive data through the provided web page. Connect to server farm 340. In connection with the user's use of these web pages, the user's request for content may be algorithmically directed to the designated server farm 340. For example, when optimizing the execution position to deliver content to the user, the minimum hop position to optimize delivery on the network, the minimum number of requests to the customer. It may be selected by choosing the maximum availability (both current and historical) with respect to the network or server features of the.
The designated web page, or other interface provided by the vehicle data system 120, is a server farm 340 where the user requests data that is not stored in the web cache of the server farm 340, or an analysis that is not performed within the server farm 340. It may be possible to request services, interfaces or data that cannot be provided by. User requests that cannot be serviced by server farm 340 may go through one of the service servers 330. These requests include, in some cases, requests for complex services that may be performed by service server 330 using data retrieved or determined using data processing and analysis server 310. But it may be.
From now on, it may be useful to review in more detail the embodiments of the method for the operation of the vehicle data system, which may be configured according to all embodiments of the architecture described above or another architecture. 7A and 7B illustrate one embodiment of such a method alone. First, referring to FIG. 7A, in step 410, data can be acquired from one or more data sources coupled to the vehicle data system and the acquired data stored in the data storage. Data obtained from these various sources may be aggregated and normalized from multiple sources. Various data sources and each data obtained from these data sources are DMS data 411, inventory data 412, registration or other government (DMV, Secretary of State, etc.) data 413, financial data 414, syndicated sales data. 415, incentive data 417,<u style="single">Honesty</u>It may include some combination of pricing data 418, OEM pricing data 419, or economic data 409.
DMS data 411 may be obtained from DMS at the dealer. DMS is a system used by vehicle dealers to manage the need for sales, finance, parts, services, inventory, or administrative management. Therefore, data that tracks all sales transactions for both new and used cars sold by dealers at retail or wholesale stores may be stored within the DMS and obtained by the vehicle data system. Specifically, this DMS data 411 is a sales transaction completed by the dealer, including identification of the vehicle name, model, trim, etc. and the associated transaction price at which the vehicle was purchased by the consumer (history sales transaction and). It may include the above data. In some cases, the sales transaction data may also have the corresponding dealer price for that vehicle. Since most DMSs are ASP-based, in some embodiments sales transactions or other DMS data 411 may be obtained daily or weekly by the vehicle data system or DMS polling company in one embodiment. It can be obtained directly from the DMS or DMS provider using a "key" that allows you to retrieve good DMS data 411 (eg, an ID and password that has set permissions). Inventory data 412 may be detailed data about the vehicle that is currently in the dealer's inventory or will be in the dealer's inventory at some point in the future. Inventory data 412 can be obtained from DMS, inventory polling companies, inventory management companies, or listing collectors.
Inventory polling companies are generally entrusted by the dealer to extract data from the dealer's DMS and format the data for use on websites and by other systems. The inventory management company manually uploads inventory information (eg, photos, descriptions, specifications, etc. regarding the dealer's inventory) to the desired location on behalf of the dealer. Listing collectors obtain data by "scraping" or "spidering" websites that display dealer inventory (eg, photos, descriptions, specifications, etc. regarding dealer inventory), or listing websites. You may also receive feeds directly from (for example, FordVehicles.com). Registration or other government data 413 may also be obtained in step 410. When a buyer purchases a vehicle, he / she must register with the state (eg, DMV, Secretary of Defense, etc.) for tax, titling or inspection purposes. The registration data 413 may include a vehicle description (eg, model year, vehicle name, model, mileage, etc.) and a sales transaction price that may be used for tax purposes.
Financial and contract data 414 may also be obtained. When purchasing a vehicle using a loan or lease process from a financial institution, the loan or lease process typically requires two steps: applying for a loan or lease and contracting for a loan or lease. These two steps use vehicle and consumer information for financial institutions to properly assess and understand risk factors for loans or leases. This financial application or contract data 414 may also be obtained in step 410. In many cases, both the application and the contract include the proposed and actual selling price of the vehicle.
Syndicated sales data 415 is also available through the vehicle data system in step 410. Syndicated sales data companies aggregate new or used sales transaction data from their partner or contracted dealer DMS. These syndicated sales data companies with dealers allow them to search transaction data in order to synthesize transaction data for analysis or purchase purposes from other data companies, dealers or OEMs. You may have a formal contract.
Incentive data 416 can also be obtained through the vehicle data system. OEMs use manufacturer-dealer, manufacturer-consumer incentives or rebates to allocate additional financial support to dealers to help lower vehicle transaction prices or stimulate sales. .. These rebates are often large (2% -20% of vehicle price), so they can have a dramatic effect on vehicle pricing. These incentives can be distributed to consumers or dealers on a national or regional basis. Since the incentives may be vehicle or region specific, their interaction with pricing can be complex and an important tool for understanding transaction pricing. This incentive data can be obtained entirely from OEMs, dealers, or other sources so that it can be used by the vehicle data system to determine the exact transaction price or other price for a given vehicle.
In step 410, this is because dealers may have the opportunity to pre-determine the pricing of their vehicle.<u style="single">Honesty</u>Pricing data 418 can be useful once it is available. For companies such as Zag.com Inc., the dealer decides in advance or<u style="single">Honesty</u>Allows you to enter pricing for consumers. this<u style="single">Honesty</u>The price is generally a "non-negotiable" (non-negotiable price) price. Many dealers also have their on the website<u style="single">Honesty</u>Present prices and even build a complete business model for the concept of "no price negotiation" pricing. These values may be used for a variety of reasons, including a step that provides a check of the transaction price associated with the historical transaction data obtained.
Also, OEM pricing data 419 can be obtained in step 410. This OEM pricing data may provide an important reference point for transaction prices for vehicle and dealer prices. OEMs typically set two important numbers that are used as general guidelines for dealer costs and prices in the case of vehicle sales, invoice prices and MSRPs (also known as sticker prices). These are fixed prices set by the manufacturer and may vary slightly depending on geographic location. The invoice price is the price that the manufacturer charges the dealer for the vehicle. However, this invoice price does not include discounts, incentives, or holdbacks that usually make the dealer's actual cost lower than the invoice price.
According to the American Automobile Association (AAA), MSRPs differ by an average of 13.5% from what dealers actually pay for their vehicles. Therefore, MSRP is almost always open to negotiations. OEMs may also be defined as known as dealer holdbacks or simply holdbacks. Holdback is a payment from the manufacturer to the dealer to subsidize the vehicle dealership. Holdback is generally a percentage of MSRP (2-3%).
The MSRP does not have to match the actual transaction price, but the invoice price can be used to determine the estimate of the actual cost of the dealer as the dealer cost is accidental to the invoice. .. The actual dealer cost can be defined as an invoice price that is less than the incentive or holdback between any applicable manufacturer and the dealer. Therefore, the vehicle data system can be defined as a "preemptive" margin (which can be defined as a transaction price less than the dealer's cost and is available in the "final stage" including finance, insurance, guarantees, accessories and other ancillary products You may use the invoice price of the vehicle associated with the historical transaction to determine the estimate of the actual cost of the dealer, which allows you to determine (which may not include margins).
Data also includes current, past, or present, past, or almost any aspect of the economy, including demographic data such as gas prices, household income, markets, regions, consumers, or almost any other type of data desired. It may be obtained from a wide variety of other data sources, including economic data 409, related to future conditions. Economic data may be specific to or associated with a designated geographic area. The economic data may also include an internet index, which may be determined from the average price of the vehicle reported by the designated internet research site as the average price of the vehicle. These internet research sites are generally consumer-focused, but sell ads and leads to dealerships, and therefore their payments to consumers are dealerships and these Prices on the site tend to indicate a higher cap size to favor dealerships.
Once the desired data is obtained, the obtained data may be cleansed in step 420. Specifically, the data obtained may not be useful if it is inaccurate, duplicated, or does not match the specified parameters. Therefore, the vehicle data system may cleanse the data obtained to maintain the overall quality and accuracy of the data presented to the end user. This cleansing process may involve the removal or modification of specified data based on almost any desired criteria, which are then obtained or determined by other data, or it. May depend on the evaluation of the data to determine if is consistent with, within the specified range, or duplicated with known values. When such data is found, it may be removed from the data storage of the vehicle data system, and values that are ineligible or out of threshold are one or more values (specifically well known or well known). It may be replaced by (which may be the default value), or it may take some other action altogether. In one embodiment, a VIN decryption 428 may be performed during this cleansing process, and the VIN number associated with the data (eg, historical transactions) may be decrypted.
Specifically, all vehicles sold must have a vehicle identification number (VIN), or serial number, to distinguish them from other vehicles. VIN consists of 17 characters, including manufacturer, model year, vehicle attributes, plant, and unique identification code. The vehicle data system determines vehicle attributes (eg, vehicle name, model year, vehicle name, powertrain, trim, etc.) based on the VIN of each vehicle, from which the VIN is obtained. External services may be used to associate with sales transactions. Note that in some cases this data may be provided with historical transaction data and may not have to occur for one or more historical transactions.
Also, inaccurate or incomplete data may be removed422. In one embodiment, the vehicle data system may be used to determine one or more values associated with the transaction (eg, preemptive margin, vehicle name, model, or trim, etc.). Any historical transaction data that does not contain the important fields of may be removed. Other high-level quality checks may be performed to remove inaccurate (including defective quality) historical transaction data. Specifically, in one embodiment, the cost information associated with the historical transaction (eg, the dealer expense) is related to the vehicle name, model, or trim of the vehicle with which the historical transaction data is associated. It may be evaluated to determine if it is compatible with a well-known or determined cost value. If there is a discrepancy (eg, the cost information deviates from a known or determined value by a certain amount), the cost information may be replaced with a known or determined value or is related to the transaction. Historical transaction data may be removed from the data storage.
In one embodiment, the following actions may be taken in each of the obtained history transactions. The dealer cost of the transaction is expected to be within the specified range of the expected vehicle MSRP corresponding to the historical transaction (for example, 60% to 140% of the MSRP of the base vehicle). The total margin of historical transactions (pre-emption + final margin) is acceptable (eg, vehicle basics) to ensure that it is within the range of (eg, 70% to 130% of the base vehicle invoice-holdback). Make sure it is within -20% to 50% of MSRP) or make sure the type of sale (new / used) is within the number of miles of the vehicle (for example, vehicles over 500 miles should not be considered new) Make sure they are consistent.
Also, the new car margin may be adjusted up or down for transactions with high or low final margins. This adjustment has a final margin size and factors based on historical analysis (eg, a sales transaction with a transaction value of $ 5000 and an actual transaction value of $ 7000, and therefore in a dealership that generated $ 2000 in vehicle transactions. , The pre-emptive margin of this sales trading vehicle may be a combination of this (which will increase by as much as $ 2000 as this dealer can tolerate low trading prices). The prepayment margin may also be adjusted based on a rebate or incentive from the manufacturer who goes directly to the dealer as this percentage of the rebate goes to the customer. The exact factors to use in a given example may be determined based on historical analysis and current market conditions. For example, if the manufacturer offers the dealer $ 5000 in marketing assistance, the dealer does not need to give this amount to the end consumer, but this monetary percentage (eg 50% -80%) is usually Given to consumers in the form of low transaction prices. In addition, the prepayment margin can be adjusted according to a number of trivial factors that change the prepayment margin based on the accounting practices of the individual dealership. For example, several dealers adjust pre-emptive margins to affect salesperson commissions, and these adjustments are removed when possible.
Duplicate data may also be removed 424. In many cases, duplicate historical transaction data may be obtained because there may be many historical transaction data sources. Since such duplicated data can distort the output result of the vehicle data system, it may be desirable to remove such duplicated data. The process is straightforward where uniquely specifiable attributes such as VIN are available (eg, VINs associated with historical transactions may match to specify duplicates). If the transaction data does not have its own attributes (in other words, attributes that can only be associated with one vehicle, such as VIN), the combination of available attributes determines if there are duplicates. May be used for. For example, the date of sale, the type of trade, the status of the trade, whether or not there was a trade-in in the trade, the vehicle transaction price or the combination of reported margins may all be used to specify duplicates. In either case, if duplicates are specified, transaction data containing most of the attribute sources may be retained, while duplicates are discarded. Alternatively, the data from duplicate historical transactions may be combined into a single historical transaction in several ways.
Outlier data may also be removed 426. Outlier data is defined as data that may not appear in order to properly represent a transaction. In one embodiment, historical transaction data for transactions with high negative margins (dealers lose a lot of money) or high positive margins (dealers appear to make a lot of money) may be removed. In one embodiment, removing outlier data at different geographic levels may remove different sets of transaction data, so removing outlier data is national, regional, regional, of the data. Alternatively, it may be achieved by removing outlier data for other geographic groups. Relevant or absolute trimming may also be used such that a specified percentage of transactions that exceed a specified standard deviation may be removed from the top and bottom of historical transactions.
After step 420, the cleansed data may be stored in the data storage associated with the vehicle data system, the cleansed data includes a set of historical transactions, and each historical transaction is at least one set of vehicles. Related to attributes (eg, vehicle name, model, engine type, trim, etc.) and transaction price or pre-emptive margin.
Then, in step 430, the cleansed data may be grouped within the dataset using these geographic datasets optimized for the binning process and the specified vehicle configuration according to geography. .. This optimization process may result in one or more datasets corresponding to a given vehicle, or group or type of vehicle, vehicle trim level or set of attributes, and associated geography.
In one embodiment, the permutation of attributes may be iteratively repeated to determine the attributes that have the greatest impact on the margin. The iteration may continue until a stack ranking list of attributes that has the largest to least impact on the margin is determined. Then, when grouping transactions for a given location and vehicle, use this ranking list to ignore or disregard the attribute that has the least impact on the margin, making it significant and relevant. Can generate a dataset with.
It may be important to maintain the timeliness or relevance of the data presented or used in order to make the vehicle pricing data more accurate. Then, in one embodiment, the total number of recent (within desired time periods) and related transactions may be optimized for the cleansed data. The relevant data for the designated geographic area and the designated vehicle may be binned to optimize the amount of data available for each vehicle within each geographic area. This amount of data corresponds to the trim level of the specified type of vehicle (a set of attributes corresponding to the vehicle) and the associated geography, using the geographic allocation of data 432, as well as the attribute classification and mapping for trim 436. It may be optimized to provide a bin of historical transaction data.
During the geographic allocation of data 432, the data is labeled with one or more of the national (all data), local, state, or DMA definitions. Attribute classification and trim mapping 436 may also occur. Vehicle data can be sorted by trim level (eg, using data about vehicles obtained from VIN decoding or other sources). This allows accurate presentation of relevant pricing based on similar vehicles within a given time frame (optimizing the latest). In some cases, the determination may be made so that there is no threshold amount of data for the specified vehicle at the trim level to determine statistically significant data corresponding to the time period. The vehicle data system analyzes the vehicle at the model (eg Accord, Camry, F-150) level to determine if there is consistency (interrelation between attributes and trim) at the attribute level. , Attribute level (eg drivetrain, powertrain, body type, cab type, bet length, etc.). Attribute-level binning may be used in place of trim-level binning in these situations, as there are more transactions when binning at attribute-level, thereby specifying a dataset. It brings more historical transactions (with respect to trim level binning only), but the relevant dataset is still used for processing. Note that for these datasets, the data in the specified dataset may correspond to different vehicle names, models, trim levels, or attributes based on the interrelationships between the determined attributes. For example, the specified dataset may have data corresponding to different vehicle names or models if it is determined that there is an interrelationship between the two vehicles.
Similarly, a given dataset may have data that corresponds to or has different attributes, where interrelationships exist between these different trim levels or attributes.
Using the historical transaction dataset, a set of models may be generated in step 440. This model generation process may include analyzing individual aspects of historical transaction data to understand attributes, geography, or seller margins at the time of sale. Understanding the margins of individual historical transactions means that these historical transactions are grouped into statistically significant samples that are most relevant to the individual user, based on their specifically configured vehicles and locations. Allows to be transformed.
Therefore, the generated model may include a set of dealer cost models corresponding to each of one or more datasets. From the historical transaction data associated with these dealer cost models and datasets, the average price ratio (eg, price paid / dealer cost) is of the dataset corresponding to the specified vehicle configuration using the price ratio model. May be generated for These models will be described in more detail later in this disclosure.
Moving on to some of the embodiments illustrated in FIG. 7B, in step 450, the vehicle data system may receive the specified vehicle configuration 452 via the provided interface. In one embodiment, for example, the user may select a specified vehicle configuration using one or more menus on a web page provided by the vehicle data system, or provide a specified vehicle configuration 452. You may navigate on a set of web pages to do so. The user may also specify the geographic location where the user is located or will purchase the vehicle in the provided specifications, or may wish the user to use it for potential purchases. You may choose one or more consumer incentives. The interface provided may also be used to obtain other data, including incentive data for the specified vehicle configuration. In one embodiment, when the user specifies a specified vehicle configuration, an interface having a set of incentives associated with the specified vehicle configuration is the user if any of such incentives are available. May be presented to. The user may select zero or more of these incentives to apply.
The data associated with the specified vehicle configuration then provided by the user may be determined by the vehicle data system in step 460. Specifically, in one embodiment, the vehicle data system relates to one or more datasets (eg, a specified vehicle configuration) in order to determine the specified data corresponding to the user's specified vehicle. Related to the vehicle configuration specified by the user (eg, specified) to process historical transaction data (grouped by vehicle name, model, trim or attribute, various geographic areas, etc.) of the vehicle. You may use one or more of the model 462 (which may be determined as described above for step 440) related to the vehicle name, model, trim level, or one or more attributes of the vehicle. .. The determined data corresponding to the specified vehicle configuration may also include adjusted transaction prices and average, central, or probability distributions 464 associated with the specified vehicle at the national, local, or regional geographic level. Good. The dataset corresponding to the specified vehicle may also be bucket 466 (eg, percentile bucket) to create a histogram of national, regional, and regional level data. "Good", "excellent", or other prices and the corresponding price range 468 are also determined by the average minimum price setting (the lowest transaction price of the dataset corresponding to the specified vehicle configuration) or algorithm. For example, it may be determined based on "good", "excellent", or "too high" range). Each price or price range may be determined at the national, local, and regional geographic level. These prices or price ranges may be based on statistical information determined from the dataset corresponding to the specified vehicle. For example, the "good" and "excellent" prices or price ranges may be based on various standard deviations from the average price associated with the sale of the dataset corresponding to the specified vehicle. For example, the "excellent" price range is below the average price, even if it is any price that is more than half the standard deviation. Well, the "good" price range may be any price that is between the mean price and half the standard deviation below the mean. The "too high" range may be the average price or above average, or any price above the "good" price range.
Historical average transaction prices and forecasts 469 corresponding to the specified vehicle configuration may also be determined at the national, regional, and regional geographic levels, and the expected pricing is the data corresponding to the specified vehicle. It can be determined based on historical trends within the set, as well as expected inventory, model year cycles, incentives or other variables.
Then, based on the determined data, an interface for presenting the determined data may be generated in step 470. The generated interface may be determined in response to a user request received by the vehicle data system, based on the user's interaction with other interfaces provided by the vehicle data system. In this way, the user may also "navigate" through the interface provided by the vehicle data system to obtain the desired data about the specified vehicle configuration presented in the desired manner. Good.
These interfaces may function to communicate with determined data in various visual formats, including a simplified normal distribution and pricing recommendations based on one or more datasets. In some embodiments, the price distribution for the specified dataset associated with the specified vehicle configuration can be presented to the user as a Gaussian curve 472. A normal distribution of transaction data in a given geographic area can be used to visually illustrate the mean and variance of pricing to the end user. Visually, the Gaussian curve 472 may be shown to illustrate the normalized distribution of pricing (eg, the normalized distribution of transaction prices). On the X-axis of the curve, the average price paid may be displayed along with the determined dealer cost, invoice, or sticker price to show the relevance and relationship of these prices to the transaction price. Determined price ranges such as "good", "excellent", "too high", etc. are also visually displayed below the displayed curve to allow the user to specify these ranges. The curve. The incentive data used to determine the presented data may also be displayed to the user.
Histogram 474 may also be created for display for the user. A histogram is a graphical representation of a tabulated frequency of a dataset or determined data, including a set of bars, where the height of the bars indicates the percentage of frequency and the width of the bars is the price. Represents a range. The average price paid, dealer costs, invoices, and sticker prices may be displayed on the X-axis of the histogram to show their relevance and relationship to these transaction prices. Determined "good", "excellent", etc. prices or ranges may also be displayed visually using a histogram to allow the user to recognize these ranges. Incentive data used to determine the presented data may also be presented to the user.
Determined historical trends or expectations 478 may also be generated. For example, the historical trend chart may be a line chart that allows the user to see how the average transaction price has changed over a given period of time. The Y-axis represents the rate of change over a given period and the X-axis represents a given period. The user will also be able to see the average transaction price and average incentive over a given period. In addition, users will also be able to see how future prices may change based on algorithm analysis. Specified price range (eg, average price paid, dealer cost, invoice, and sticker price) and range (eg, "good", "excellent", "too high", etc.) in either horizontal or vertical format. Other types of interfaces, such as bar charts illustrating)), may also be used.
The use of these types of visual interfaces may also allow the user to intuitively understand the price distribution based on the relevant information of those designated vehicles, which in turn, in pricing. You may provide these users with powerful fact-based data to understand and negotiate how much change exists and what constitutes a good price. In addition, displaying datasets related to different vehicles in substantially the same format may allow the user to easily compare pricing data related to multiple vehicles or vehicle configurations. ..
The generated interface can be distributed through various channels in step 480. In many cases, the channel through which the interface is distributed is the channel through which the user initially interacted with the vehicle data system (eg, the interface that allowed the user to specify the vehicle). It will be clear that it may be a channel distributed through. However, it may also be possible to distribute these interfaces through different data channels. Therefore, datasets and interfaces that present the processing results of these datasets may be accessed or viewed using multiple interfaces, with the user using multiple types of devices and through multiple channels. Will be distributed over multiple channels, allowing access to the desired data in multiple formats. These distribution methods include, but are not limited to, consumer and dealer facing internet-based applications 482. For example, users can use the World Wide Web (eg, www.truecar.) Through a browser. It may be possible to access the address on com) and enter the specified vehicle and geographic information via its web tools. Data about the designated vehicle and geographic information may then be displayed to the user by presenting an interface in the user's browser. Data and online tools for accessing or manipulating such data may also be distributed to other automotive websites and social networking tools on the web. These internet-based applications are also provided by third parties to allow access to some or all of the functionality of the vehicle data system through widgets on third party websites. It may be embedded in the site, for example, it may include a widget. Other internet-based applications include applications that are accessible through one or more social networking or media sites such as Facebook or Twitter, or through one or more APIs or web services. But it may be.
The user may also use messaging channel 484 to send a VIN message for the specified vehicle to the vehicle data system (eg, using text, photo or voice messages). The vehicle data system responds to a message (eg, text, photo or voice message) containing pricing information for a given vehicle. Further, in certain embodiments, the geographic location used to determine the pricing information presented is the area code of the telephone number used by the user to submit a message or the location of the user's computing device. It may be based on the area code. In some cases, if the geographic location cannot be determined, one may be asked for the location or may be offered a national average.
In one embodiment, the user may be able to call the vehicle data system and use voice instructions to use the phone-based application 486 to provide the specified vehicle configuration. .. Based on the information given, the vehicle data system will be able to verbally present pricing data to the user. Geography may be based on the user's area code. If the area code cannot be determined, the user may be asked to confirm their location by showing the zip code or other information. Such a telephone-based application 486 may be automatic in nature or may be accompanied by a live operator who communicates directly with the user, who may use the interface provided by the vehicle data system. Please note that it is good.
Since vehicle data systems may provide access to different types of vehicle data in multiple formats over multiple channels, there are numerous opportunities for monetizing vehicle data systems such systems. May be presented to the operator of. Therefore, the vehicle data system may be monetized by its operator in step 490. More specifically, as an aggregated dataset, the results on the dataset or other data or the processing performed on it, or the benefits provided by the vehicle data system, may be beneficial and the vehicle data system. Operators may monetize their data or benefits through various access and distribution channels, such as by using the websites provided, distributed widgets, data, data analysis results, etc. For example, monetization may be achieved using vehicle (vehicle, finance, insurance, etc.) related advertisements 491, where vehicle data system operators use display advertisements, contextual links, sponsorships, etc. on an OEM basis. It may be sold to automotive advertisers, including local marketing groups, dealers, financial companies or insurance providers.
In addition, the vehicle data system is pre-determined<u style="single">Honesty</u>It may be monetized by promoting the expected Generation 493 based on pricing. When the user checks the interface of the vehicle data system, they also<u style="single">Honesty</u>Have the option to approve the price (eg, it may be included in the offered "good" or "excellent" price range). This price allows users to buy a car without negotiation.
The operator of the vehicle data system may also monetize its operation by conducting a reverse auction 496 based on the dealer bidding system or equivalent. Dealer to user via vehicle data system<u style="single">Honesty</u>You may have the opportunity to bid on presenting pricing. The lower the price, the more the dealer bids, and the higher the priority, the more they are in the vehicle data system (eg, priority placement and first price presented to the user) or some other. Priority schemes may be used. The user can see the bidders within the radius selected by the user in the user's zip code or other geographic area and select the winning bidder.
The operator of the vehicle data system may also license the data, the results of data analysis, or the specified application to an application provider or other website. Specifically, the operator of the vehicle data system may license the data or application for use on or with a designated dealer tool, including inventory management tools, DMS, dealer website marketing companies, etc. .. The operator of the vehicle data system may also grant access to the data and use of the tool on a consumer facing website (eg, Yahoo! Autos or equivalent).
Monetization of vehicle data systems may also be achieved by enabling OEMs to purchase contextual advertising 495 on certain applications such as distributed widgets or equivalents. The user may view such an advertisement as "another vehicle to consider" on the widget. Operators may also deploy and sell access to online tool 497 for OEMs, financial companies, leasing companies, dealer groups, and other logical end users. These tools 497 allow customers to perform customized analysis reports that may not be available on consumer facing websites such as statistical analysis toolsets or equivalents. Since the accuracy and specificity of the pricing information may be a significant advantage of the vehicle data system embodiments presented herein, how such pricing information is determined from now on. For illustration purposes, it may be useful to be presented with an overview of embodiments of analytical theory that may be used by the vehicle data system. Specifically, in one embodiment, the data feed from the source may be leveraged into model variables to build multivariate regression. More specifically, in one embodiment, using one set of historical data, a set of dealer cost models may be determined as an expression based on invoice and MSRP data, a second set. Using historical data from, the price ratio regression model uses these determined dealer cost models and price ratio regression models in the calculation of pricing data corresponding to the user-specified vehicle configuration. It may be determined so that it can be configured as such. When such a designated vehicle configuration is received, historical transaction data related to the designated vehicle configuration can be obtained. The transaction price associated with the historical transaction data can be adjusted for the incentives provided to determine the desired data to present to the user and for the dealer cost model and price ratio model. Specifically, one In embodiments, the user may use the interface provided by the vehicle data system to provide the vehicle data system with such a designated vehicle configuration. The user may also select one or more currently available incentives to apply the currently available incentives to the location associated with the specified vehicle configuration. The specified vehicle configuration is a set of attributes of the desired structure (eg, transmission type, MSRP, invoice price, engine displacement, engine cylinders, number of doors, body type, geographic location, available incentives, etc. The values of these attributes may be defined by the user, using the values of the attributes specified by the user, or may be obtained by the vehicle data system. Based on the values of these attributes, the bin of the specified vehicle may be identified. In one embodiment, the bin for the vehicle has the same model year, vehicle name, model, and body type for which historical transaction data within a specified period (eg, the last 4 weeks, or other period) exists. Defined as a vehicle group.
Using the pricing information associated with the historical transaction in the bin corresponding to the specified vehicle, the steady-state price may be determined by removing the incentive from the price in the historical transaction data. Once the exact transaction price has been determined, the average price and average cost of the specified vehicle may be calculated using the historical transaction data associated with the bin of the specified vehicle. The average price and average cost determined at this bin level were then specified to determine the average price ratio of the specified vehicle by applying these values to the price ratio regression model and resolving them. It may be used with the vehicle configuration. The specified price range may be calculated using this average price ratio and the price paid (eg, adjusted for incentives), which corresponds to the historical transaction data in the bin of the specified vehicle (eg, adjusted for incentives). , Based on the standard deviation from the price range (eg, mean). The Gaussian curve can then be parameterized to match the results visually displayed to the user along with the actual price distribution and calculated price range corresponding to the bin's historical transaction data.
With reference to FIG. 8, one embodiment of a method of determining accurate and relevant vehicle pricing information is illustrated. At step 510, the data may be obtained and cleansed as described above. This data may include a set of historical transaction data, the historical transaction data may include data regarding a set of transactions that have occurred, and the specified historical transaction data may include, for example, invoice prices, dealer costs, MSRP, etc. One or more prices associated with a vehicle actually sold to a consumer, including a price paid by the consumer (also referred to as a transaction price), and a set of attributes corresponding to the vehicle sold (eg, for example). The value of vehicle name, model, transmission type, number of doors, power train, etc.) may be included. This historical transaction data may then be cleansed. This cleansing is related to the elimination of specified historical transactions based on data values (eg, transactions with a selling price of $ 5,021 may be considered too low and the sales transactions are excluded), or related to historical transactions. It may involve substitution of a specified value.
In certain embodiments, as will be described later, this dealer cost can be important to the user in determining pricing data, so it is desirable to be able to accurately determine the dealer cost associated with historical transactions. possible. While some data sources may provide gross profit data in conjunction with the historical transaction data provided, this gross profit field may be used to determine dealer costs and this gross profit data is , Often uncertain. Then, in one embodiment, when the historical transaction data is cleansed, the dealer cost corresponding to each of the set of historical transactions is the dealer cost model associated with the vehicle data system and the dealer cost associated with the historical transaction. It may be determined using the determined dealer costs associated with the corresponding historical transaction if it does not have. Also, the dealer costs associated with the historical transactions received are determined to deviate some threshold from the original dealer costs determined, or are otherwise determined to be inaccurate. If so, it may be assessed using the determined dealer cost corresponding to the transaction so that the original dealer cost can be replaced by the determined dealer cost. An embodiment of the method for determining dealer costs for use in this type of cleansing will be described in more detail later with reference to FIG.
Once the historical transaction data has been obtained and cleansed, the dealer cost model can be determined in step 520. More specifically, in one embodiment, the dealer cost model is for each of the set of manufacturers by analyzing the invoice data (which may be received from the dealer) corresponding to that manufacturer. May be generated in. Specifically, the invoice data may be analyzed to determine the holdback equation from which the dealer cost relationship is derived (eg, dealer cost = invoice-holdback).
Invoice data, typically provided with each vehicle invoice, includes, among other data, holdback prices, invoice prices, fares, and MSRPs. Therefore, assuming that each vehicle invoice is taken as a separate finding and the formulas take similar form, the various forms of formulas are plotted to see which formulas are most consistent across the findings. can do. The formula that maintains maximum consistency can be considered to be the manufacturer's holdback formula (also known as the Dealer Cost model).
Temporarily returning to Figure 9, we present a graphical illustration of a holdback plot that applies to the vehicle invoice price of one designated manufacturer (Ford). Here, holdback = 0.03 * (configured msrp-fare) at this designated manufacturer, as holdback is the only form that maintains consistency across Ford-related invoices. Can be determined as.
The determination of these dealer cost models may be made at almost any desired time interval, even if the time interval differs from the time interval used to obtain data from any of the data sources. Often, it should be noted that these dealer cost models do not need to be re-determined when new data are available. Therefore, the determination of the dealer cost model is described herein with respect to the embodiment illustrated in FIG. 8, but this step is not a necessary part of the embodiment of the method described, and either at all or in this embodiment. Note that it does not have to occur in the order shown with respect to. For example, dealer cost models may be determined offline and the vehicle data system is configured to be used with these provided dealer cost models.
Returning to FIG. 8, in addition to the dealer cost model, the price ratio regression equation may be determined using historical transaction data in step 530. Then, in one embodiment, using global multivariate regression, the price ratio equation is:
<maths num="1"><img file="JP5538397B2_D0001.tif" /></maths>May be in the form of, in the formula, X<sub>i</sub>Represents a global variable, X<sub>bk</sub>Represents a bin-level variable in the specified bin b, β<sub>i</sub>'Is a coefficient. In one embodiment, for example, the Price Ratio equation is Price Ratio = a0 + al * PRbin + a2 * PRbin * dealercost + a3 * PRbin * cylinders + a4 * PRbin * drive + a5 * PRbin * daysinmarket + Σ ( a<sub>k</sub>* PRbin * state<sub>k</sub>), And in the formula, a<sub>i</sub>= Factor, PRbin is the 4-week average price ratio of all transactions in the bin associated with a given vehicle, and dealercost is the dealer cost of a given vehicle's steady state (adjusted incentive). Yes, cylinder is the number of cylinders a given vehicle has, drive is the number of drivetrain drive wheels (eg two-wheel or four-wheel drive), daysinmarket is the required vehicle model on the market. The number of days spent, state is a set of index variables that specify the geographical purchase state. Using this price ratio formula, it is possible to calculate the average price paid for a given vehicle, and the average price paid (Avg Price Paid) is DealerCost (the dealer of the manufacturer of the given vehicle). Equivalent to Price Ratio (determined from the price ratio regression equation) multiplied by (determined from the cost model), or Avg Price Paid = Price Ratio (Dealer Cost).
In one embodiment, it may be desirable to model price ratios at the regional level. Therefore, the specification embodiment of the price ratio formula may occupy a proportion of this request by incorporating postal code level modeling. For example, in the above price ratio equation, a variable for capturing a zip code may be included instead of a series of index variables for identifying a state. However, in the case of vehicle pricing data, incorporating a set of index variables that identify the zip code may be less effective due to the data sparseness problem, while straight continuous mapping of the zip code Also, it may be less effective than desired due to the overly constrained implicit numerical relationships of zip codes.
Therefore, indirect continuous mapping may be used in the specified embodiment, specifically where intermediate parameters can be specified. For example, continuous variables such as average income and average home price can be effectively leveraged as an intermediary. Given that zip codes are directly related to these effects (often referred to as proxy variables), it makes sense to use these types of continuous variables as intermediate mediators.
To achieve this, in one embodiment, we first develop a model related to zip codes for average income. This model could be, for example, a reference table of average income by zip code (eg, which can be obtained from the latest survey data). Then, the average income is, for example, in the above price ratio equation, the variable X<sub>i</sub>Used as. The price ratio formula may have components of a6 * est_median_income or a6 * PRbin * est_median_income, in the formula, est_median_income =: f (zip code) (in the formula, f (zip code) is the postal code. Refers to the value in the reference table that corresponds to). Therefore, this kind of price ratio formula is PriceRatio = aO + al * PRbin + a2 * PRbin * dealercost + a3 * PRbin * cylinder + a4 * PRbin * drive + a5 * PRbin * daysinmarket + a6 * PRbin * est_median_income. Also well, in the ceremony, a<sub>i</sub>= Coefficient, PRbin is the 4-week average price ratio of all transactions in the bin associated with a given vehicle, and dealercost is the dealer cost of the required vehicle's steady state (adjusted incentive). , Cylinder is the number of cylinders a given vehicle has, drive is the number of drivetrain drive wheels (eg, two-wheel drive or four-wheel drive), and daysinmarket is the number of models of a given vehicle. The number of days in circulation, f (zip code) refers to the value in the reference table corresponding to the zip code. A similar approach with any other such potential central parameter, which should be used in conjunction with central home prices, or any kind of region-level variable (zip code, district, area code, etc.). Note that you can take.
The determination of the price ratio formula for use may be made at almost any desired time interval, which is different from the time interval used to obtain data from any of the data sources. It may be noted that the price ratio formula does not need to be newly determined when new data is available. Thus, while pricing formula determination is described herein with respect to the embodiment illustrated in FIG. 8, it should be noted that this step is not a necessary part of the embodiment of the method described. For example, the price ratio formula may be determined offline and the vehicle data system is configured to use this provided price ratio formula. Once the data has been collected and the dealer model and price ratio regression equation to be used have been determined, the specified vehicle configuration may be received and the corresponding bins are determined in steps 540 and 550, respectively. The specified vehicle configuration may include values for a set of vehicle attributes (eg, in one embodiment, the year, vehicle name, model, and vehicle body type attributes may be used). Therefore, the bin corresponding to the specified vehicle configuration may contain historical transaction data from a specified period (eg, 4 weeks) associated with the value of a set of attributes corresponding to the specified vehicle.
The bin corresponding to the designated vehicle may be used to determine steady-state pricing for historical transaction data in the bin in step 560. Steady-state prices can be determined by removing incentives from transaction prices in historical data. More specifically, the transaction price is Price_ss (steady state price) = Price (transaction price) + I<sub>c</sub>+ λl<sub>d</sub>Can be adjusted for incentives using the formula in the formula, I<sub>c</sub>= Consumer incentives applied to transactions, I<sub>d</sub>= Dealer incentive available for trading, λ = Dealer incentive pass-through rate. Therefore, if the historical transaction price includes $ 500 in the consumer incentive and $ 1000 in the available dealer incentive for a dealer determined to have a 20% dealer cash passthrough rate, that price will be that price. It will be adjusted $ 700 higher to take into account the incentives offered at the time. For example, Honda The $ 15,234 paid price (transaction price) for Civic's historical sales transactions may have been artificially lowered due to incentives. Since incentives are known at the time the historical transaction takes place, which incentives were available at that time and how they affect the price corresponding to the historical transaction (eg, what percentage of these incentives). Can be passed through to consumers). Since the dealer incentive is generally known to consumers and can or cannot be passed through, historical transaction data is evaluated to determine the appropriately adjusted dealer incentive percentage based on the historical average. can do.
For example, a $ 1500 consumer incentive and a $ 1000 dealer incentive may be available, Honda Use the Civic trading example. Consumer incentives are 100% pass-through to consumers, so that $ 1500 can be added to the historical transaction price to adjust the price of the transaction to $ 16734. For this designated vehicle type, the incentive pass-through rate from the manufacturer to the dealer may have been determined to be 54%. Therefore, this amount can be determined to be deducted from the price paid by the consumer on average for this vehicle. Therefore, this amount may also be added to the price of the transaction to reach the figure of $ 17274 as the transaction price without incentives for this transaction. Similar calculations may be performed for other historical transactions in the designated vehicle bin. After the steady-state price has been determined, in step 570, the average dealer cost corresponding to the specified vehicle is the historical transaction data in the bin (including the adjusted transaction price corresponding to the historical transaction) and the specified vehicle. It may be determined using the dealer cost model corresponding to the manufacturer of. The price ratio corresponding to the specified vehicle can then be determined using the low price ratio formula by fitting the value corresponding to the specified vehicle to the bin-level variable of the price ratio formula and solving it. Good.
Using the determined price ratio, the average price paid for the specified vehicle is determined using the formula Avg Price Paid = PriceRatio * DealerCost. May be good.
In one embodiment, at this time, if there are any incentives currently available for the designated vehicle, the transaction price adjusted for historical transactions and the average price paid will be these. Can be scaled based on incentives. Specifically, using the presented interface, the user may select one or more customer incentives offered in conjunction with the specified vehicle configuration. These designated customer incentives may be used to adjust the transaction price. More specifically, these transaction prices may be further adjusted based on a process similar to the process used in determining steady-state pricing, which accounts for a percentage of the current incentive. Therefore, the formula is Price (transaction price) = Price_ss (steady state) -I<sub>c</sub>-λI<sub>d</sub>May be, in the formula, I<sub>c</sub>= Consumer incentives applied to transactions, I<sub>d</sub>= Dealer incentives available for trading, λ = Dealer incentive pass-through rate, or Ave Price Paid<sub>final</sub>= Ave Price Paid<sub>computed</sub>-I<sub>c</sub>-λI<sub>d</sub>Is. In this way, incentives can fluctuate based on geography, so how much the user can negotiate, rather than displaying the entire price range that is overly affected by the changes in available incentives. As a method for determining, it is possible to display a price that matches the user's regional market price. Note that in some embodiments, it may be desirable to reduce and adjust the determined average dealer cost by the full amount of consumer and dealer incentives at this time.
Once the average price paid for the specified vehicle has been determined, one or more price ranges may be determined in step 580. These price ranges may be determined using standard deviations determined from historical transaction data, including the adjusted transaction price of the bin. For example, the upper limit of the "good" price range may be calculated as Good = Avg Price Paid + 0.15 * stddev, and the upper limit of the "excellent" price range may be determined as Great = Avg Price Paid-0.50 * stddev. While possible, the "overpriced" price range may be defined as any price above the "good" transaction price. Alternatively, the "good" price is standard below the average price determined based on the bin's historical transaction data, from the minimum central transaction price and average transaction price, including the adjusted transaction price corresponding to the specified vehicle. It may reach up to half of the deviation. Any other fraction of the standard deviation may be used to determine the "good", "excellent", "overpriced" price range, or some other method is used entirely. Please note that it may be done.
The display may then be generated in step 590. In one embodiment, this display matches the Gaussian curve to the adjusted transaction price distribution corresponding to the historical pricing data for bins associated with the specified vehicle and formats the results for visual display. Can be generated by doing. The visual display may also have one or more indicators displayed relative to the displayed pricing curve, indicating where one or more pricing ranges or price ranges are located.
Here, it may be helpful to illustrate embodiments for the designated vehicle. To continue with the above example, it is assumed that the vehicle specified to the Ford manufacturer is a 2009 Ford Econoline Cargo Van, E-150 Commercial with no options. In this case, Ford's dealer cost model may specify that the dealer cost is calculated from the base MSRP-fare. The MSRP for this vehicle from the data obtained from the data source is $ 26,880 and the fare can be determined to be $ 980. Therefore, the holdback of the specified vehicle is Holdback = α.<sub>0</sub>+ α<sub>1</sub>Calculated as (MSRP-Freight), α in the formula<sub>0</sub>= 0, α<sub>1</sub>= .03 (from the dealer model above for Ford). Therefore, Holdback = .03 * (26880-980) = 777. The base invoice price can be determined from the data obtained to be $ 23,033, therefore factory invoice = base invoice + advertising costs + freight = $ 23,033 + $ 428 + $ 980 = $ 24,441, and dealer costs = factory invoices. Voice-Holdback = $ 24,441- $ 777 = $ 23,664.
The average price ratio may be determined using prices from historical transaction data corresponding to the 2009 Ford Econoline Cargo Van, E-150 Commercial, with no options (bins). As mentioned above, these prices may be adjusted for incentives.
Here, 2009 Ford Econoline Cargo Van, E-150 Commercial with Price Ratio = f (x) =
<maths num="2"><img file="JP5538397B2_D0002.tif" /></maths>Assuming = 1.046, in this case Average Price Paid = DealerCost * 1.046 = $ 24,752. At this point, adjustments can be made if there are any currently available incentives available for the 2009 Ford Econoline Cargo Van, E-150 Commercial with no options. In this example, it does not have to be done. However, for example, if there is $ 1,500 for consumer incentives and $ 500 for dealer incentives, prices can be rescaled based on these incentives. Therefore, in this situation, the adjusted average price paid = $ 24,752- $ 1,500-.30 (500) = $ 23,102, assuming the vehicle had a pass-through rate of 30% in the past. Briefly returning to FIGS. 10A and 10B, an embodiment of an interface that may be used by a vehicle data system to present such pricing information to the user is illustrated. Specifically, Figure 10A shows a domestic-level 2009 Ford. Figure 10B shows regional levels, while an interface showing determined actual dealer costs, factory invoices, average payments (average prices paid), and sticker prices for the Econoline Cargo Van, E-150 Commercial. It is an interface that shows the same data of.
Therefore, in this designated example, in the case of the 2009 Ford Econoline Cargo Van, E-150 Commercial, the price breakdown is "good", and the upper limit of the price can be calculated here as "good". The "excellent" range is calculated as follows: "good" ranges from the lower limit (center (P), average (P)) to half the standard deviation below the average price over recent transactions. The "excellent" price range extends below the mean from half the standard deviation to further down. Therefore, in this example Econoline with no options, the national average price = $ 24,752, the "good" price range upper limit = $ 24,700 (center of the data in this example) and the "excellent" price range upper limit = 24752- 0.5 * σ<sub>b b</sub>= 24752-0.5 (828) = $ 24,338.
The Gaussian curve then parameterically matches the actual price distribution of the historical transaction data corresponding to the Ford Econoline Cargo Van, E-150 Commercial, to generate the visual display examples illustrated in Figures 11A and 11B. can do. Here, Figure 11A shows the 2009 Ford Econoline Cargo Van, E-150 Commercial price range "Actual Dealer Cost", "Factory Invoice", and "Average paid (" "Average Paid" and "Sticker Price" are shown against the price curve showing the pricing distribution of the 2009 Ford Econoline Cargo Van, E-150 Commercial. 2009 Ford Econoline Cargo Van, E-150 after the matching process An interface that visually shows the domestic price distribution of Commercial. Also, "good" and "excellent", as well as "overpriced" price ranges are shown with respect to the presented pricing curve. Figure 11B shows a similar pricing curve for regional level data for the same vehicle.
A more detailed description of various interface embodiments that may be used in connection with vehicle data system embodiments may be an illustration of the capabilities and effectiveness of the embodiments of the present invention.
Referring to FIGS. 12A-12D, it is an embodiment of an interface for obtaining presentation of vehicle configuration information and pricing data. Specifically, first referring to Figure 12A, at this point the user may have selected the 2009 Dodge Charger 4dr Sedan R / T AWD, where the user has selected one or more attributes. An interface 1500 is presented through which allows the user to specify the desired vehicle configuration in more detail. Note that Interface 1500 presents the user with both the invoice and sticker prices associated with each of the attributes the user can select.
When the user selects one of the desired attributes, the user may be presented with an embodiment of interface 1510, such as that illustrated in FIG. 12B, and the user may be presented with the selected vehicle configuration (in this case, the 2009 model). It may be possible to select one or more currently available incentives related to the Dodge Charger 4dr Sedan R / T AWD). In certain embodiments, the vehicle data system allows the user to access any currently available incentives corresponding to the user's specified vehicle configuration and select zero or more of the available incentives for the user. To do so, interface 1510 may be presented using the currently available incentives obtained. Note that one of the incentives offered here includes a cash amount of $ 4500. Suppose the remaining purpose of this example is for the user to choose this $ 4500 incentive.
Moving on to Figure 12C, we now illustrate an embodiment of an interface that presents pricing information related to the selected vehicle configuration (in this case, the 2009 Dodge Charger 4dr Sedan R / T AWD). It will be appreciated that the interface specifically notes that the price shown includes $ 4500 in the consumer incentive selected by the user for interface 1510 in this embodiment.
For Figure 12D, an interface showing the determined actual dealer costs, factory invoices, average paid (average price paid), and sticker price for the 2009 Dodge Charger 4dr Sedan R / T AWD at the regional level. It will be found that one embodiment is shown. With respect to this interface, users can view these price ranges, including not only the specified price range, but also how the $ 4500 consumer incentive was applied to determine dealer costs and the average price paid. You will find that data on how was determined is presented. By understanding incentive information, and how such incentive information and other data may relate to dealer costs and the average price paid by others, users can use their desired vehicle configuration. It may be possible to better understand and evaluate pricing and pricing data for.
It may be more useful to present a graphed illustration of the generated data that can be presented via such interfaces. As mentioned above, the bin of the specified vehicle configuration may contain a set of historical transaction data. From this historical transaction data, a histogram of the dealer margin (transaction price-dealer cost), as well as other relevant statistics such as mean and standard deviation can be calculated. For example, Figure 13A shows 6003 transactions and 18 buckets (the first bucket contains any transaction with a standard deviation of less than 2 from the mean, 16 buckets contain a standard deviation of 0.25, and the last bucket contains. A domestic-level histogram of the Honda Accord, corresponding to bins with a large sample set (including any trade with a standard deviation of 2 or more from the mean), is illustrated graphically. FIG. 13B graphically illustrates another embodiment of the Honda Accord histogram.
FIG. 14 illustrates the conversion of the histogram of FIG. 13A to a graph. FIG. 15 graphically illustrates the overlap of the histogram curve illustrated in FIG. 14 with the normalized curve by adjusting the average of the histogram and the normal curve and the values on the X-axis. Once the true curve is abstracted from the simplified normal distribution, then the recommended pricing range can be overlaid on the normal curve to capture some of the complexity of the actual curve. ..
FIG. 16 graphically illustrates the "good" and "excellent" price ranges determined based on the margin range determined based on the percentile of the person who bought the car below that price. One algorithm could be: the upper limit of the range on the side of the "good" price range = MIN (50th percentile trading margin, average margin), the lower limit of the "good" range / " The upper limit of the "excellent" range can be the 30th percentile trading point if less than 20% of transactions have a negative margin, or the 32.5th percentile trading point if transactions above 20% have a negative margin. And the lower limit of the "excellent" price range is the 10th percentile trading point if less than 20% of the transaction is below the dealer cost (has a negative margin), or if the transaction of less than 20% has a negative margin. It can be the 15th percentile trading point. The entire data range can be used for display, or the data range may be clipped at some point in the actual data to simplify the curve. In the embodiment illustrated in FIG. 16, the dataset is clipped at the bottom of the "excellent" range 1302.
Once the dealer cost is established for the specified vehicle, the dealer cost is added to each bucket along the X axis of the histogram of margins for this position and vehicle specifications, and the margin curve is graphed in Figure 17. Use to move parallel to the illustrated price curve. The price histogram is then combined with the determined "good" / "excellent" price range (which can also be scaled by adding dealer costs), as well as other pricing ranges such as dealer costs, factory invoices, and MSRP. Can be stacked. This improved histogram may be presented to the user in a variety of formats, eg, the histogram is illustrated in FIG. 20 as a simplified curve illustrated in FIG. 18 and as a bar chart illustrated in FIG. It may be presented as actual data or as historical trend data illustrated in FIG.
As mentioned above, in order to determine accurate pricing information for a given vehicle, it is important to have accurate pricing information related to historical transaction data associated with that vehicle. Therefore, in many cases, when retrieving historical transaction data from a data source, it is desirable to check the dealer costs provided with the historical transactions or determine the dealer costs to associate with the historical transactions. possible. Since the dealer cost model is built for each manufacturer (see step 520), you can accurately build the dealer cost for one or more historical transactions and check the dealer cost offered, or It may be possible to leverage these dealer cost models to associate historical transactions with determined dealer costs.
FIG. 22 illustrates an embodiment of a method for determining the exact dealer cost for a historical transaction.
First, in step 910, a historical transaction of the obtained historical data with accurate trim mapping can be identified. In most cases, the vehicle associated with the historical transaction can be mapped to the specified trim based on the vehicle identification number (VIN) associated with the historical transaction. However, it is often not possible to complete a one-to-one VIN mapping because the VIN may not contain all the information needed to perform the mapping. In other words, the specified VIN can accommodate many trim levels of the vehicle. In these cases, the data provider may provide many mappings to one and multiple trims associated with a single historical transaction. This is then a problem because the actual sales transaction may then have multiple historical transactions in the historical transaction data, and each historical transaction is associated with a different trim, only one of which is actually accurate. It becomes. Given that there is often no way to identify which of these historical transactions are accurate, a good modeling approach is to weight these transactions differently or map them potentially incorrectly. Exclude such transactions from the model building dataset. Thus, in one embodiment, these potential mismapped transactions are identified and then identified, for example, by determining if there are multiple historical transactions associated with a single VIN. Historical transactions may be excluded from the historical dataset (for the purposes of this method).
Within the remaining historical transactions, these historical transactions with accurate information can then be identified in step 920. As mentioned earlier, the invoice and dealer cost fields in historical transaction data can be inaccurate. Since one purpose of determining the dealer cost is accuracy, it is important that the dealer cost is determined only for these historical transactions that can be determined with relative accuracy. Since accurate trim information or option information can be leveraged to determine dealer cost, this Accurate trim mapping or identifiable option information is to further improve the history transactions to determine the history transactions these It can be desirable.
Having obtained a set of historical transactions with accurate trim mapping and identifiable option information, the MSRP may be determined for each of these historical transactions in step 930. Considering again that the data associated with historical transactions does not have to be reliable and that alignment with the configuration data (eg, dealer cost model or price ratio formula) is important, using known data, It may be desirable to determine certain data related to historical transaction data. Therefore, the MSRP for historical transactions can be determined, even if the MSRP is provided or otherwise available. First, the basic MSRP may be determined. Specifically, the base MSRP may be determined based on the data provided by the data source, using the model year, vehicle name, model, and trim specifically identified from the VIN. Manufacturers who have proposed retail pricing for these options, using additional options identified by historical transaction data, can then be added to the base MSRP to form a transaction MSRP. More specifically, in each history transaction, there may be a field containing a set of option codes indicating which options are installed in the factory on the designated vehicle corresponding to the history transaction. Analyzing this information, the option code can be used in conjunction with option pricing information obtained from the data source to identify the MSRP for each factory installation option. To summarize each of the manufacturer prices for an option, a comprehensive option MSRP is generated to generate a transaction MSRP for that specified history transaction and can be added to the base MSRP (Transaction MSRP (Transaction MSRP)). ) = Base MSRP + Total Options MSRP).
Invoice pricing for each of the historical transactions may be determined in step 940 after the transaction MSRP has been determined for the historical transactions. Trading invoices can be generated similar to trading MSRPs. First, the basic invoice price can be determined. Specifically, the base invoice price may be determined based on the data provided by the data source, using the model year, vehicle name, model, and trim identified from the VIN. Pricing for these options can then be added to the base invoice price to form the transaction invoice price, using additional options identified by historical transaction data. More specifically, for each history transaction, there may be a field containing a set of option codes indicating which options are installed in the factory on the designated vehicle corresponding to the history transaction. Analyzing this information, the option code can be used in conjunction with option pricing information to assign option invoice prices for each factory-installed option. To summarize each of the option invoice prices for an option, a comprehensive option invoice price can be generated and added to the base invoice price to generate a transaction invoice price for that specified historical transaction. (Transaction Invoice = Base invoice + Total Options Invoice).
Using the determined MSRP and invoice price, the dealer cost for each historical transaction may be determined in step 950. This dealer cost can be determined by algorithmically determining using a dealer cost model associated with the vehicle manufacturer associated with the historical transaction. More specifically, each vehicle name (manufacturer) of the vehicle has the above-mentioned holdback type. In a given history transaction, the vehicle name of the vehicle to which the history transaction is associated, the transaction invoice price and transaction MSRP determined for that history transaction, and the fare (from the data source as well as the base invoice and base MSRP determination). Using a holdback formula that corresponds to (which may be determined based on the information obtained), the holdback formula is a dealer cost (dealer cost = invoice-holdback). Can be applied to determine.
In the aforementioned specifications, the present invention is described with reference to designated embodiments. However, one of ordinary skill in the art will appreciate that various modifications and modifications can be made without departing from the scope of the invention as defined in the claims below. Therefore, the specifications and figures are to be considered for illustration purposes rather than for limited purposes, and all such modifications are intended to be within the scope of the present invention. Benefits, other benefits, and solutions to problems are described above for designated embodiments. However, any benefit, benefit, solution to a problem, and any component that may give rise to, or make it more obvious, any benefit, benefit, or solution is of any or all of the claims. It should not be construed as a necessary or essential feature or component.
33 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2006268635A | Cites | Japan |
| JP2001256356A | Cites | Japan |
| JP2002132827A | Cites | Japan |
| JP2007122197A | Cites | Japan |
| JP2003108811A | Cites | Japan |
| JP2003108847A | Cites | Japan |
| JP2001306851A | Cites | Japan |
| JP2004213065A | Cites | Japan |
| JP200324387A | Cites | Japan |
84 members in 6 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 61095550 | United States of America | – | |
| 61095376 | United States of America | – | |
| 9555008 | United States of America | P | |
| 9537608 | United States of America | P | |
| 2009056317 | United States of America | W |
Members84
| Document | Office | Kind | |
|---|---|---|---|
| CA2736477A1 | Canada | A1 | |
| CA2736869A1 | Canada | A1 | |
| US2010070343A1 | United States of America | A1 | |
| US2010070344A1 | United States of America | A1 | |
| US2010070382A1 | United States of America | A1 | |
| WO2010030632A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2010030633A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2010030634A1 | World Intellectual Property Organization (WIPO) | A1 | |
| US2011022525A1 | United States of America | A1 | |
| WO2010030634A8 | World Intellectual Property Organization (WIPO) | A8 | |
| US7945483B2 | United States of America | B2 | |
| EP2342662A1 | European Patent Office (EPO) | A1 | |
| EP2347377A1 | European Patent Office (EPO) | A1 | |
| US2011191264A1 | United States of America | A1 | |
| CN102203772A | China | A | |
| CN102203814A | China | A | |
| JP2012502375A | Japan | A | |
| JP2012502376A | Japan | A | |
| EP2342662A4 | European Patent Office (EPO) | A4 | |
| EP2347377A4 | European Patent Office (EPO) | A4 | |
| US8219464B2 | United States of America | B2 | |
| US2012259728A1 | United States of America | A1 | |
| US8521615B2 | United States of America | B2 | |
| US2013311319A1 | United States of America | A1 | |
| US8612314B2 | United States of America | B2 | |
| US2014058957A1 | United States of America | A1 | |
| JP5538396B2 | Japan | B2 | |
| JP5538397B2This record | Japan | B2 | |
| US2014229240A1 | United States of America | A1 | |
| US2014229241A1 | United States of America | A1 | |
| US2014358719A1 | United States of America | A1 | |
| US9020843B2 | United States of America | B2 | |
| US9020844B2 | United States of America | B2 | |
| US2015193800A1 | United States of America | A1 | |
| US2015206162A1 | United States of America | A1 | |
| US9111308B2 | United States of America | B2 | |
| EP2913790A1 | European Patent Office (EPO) | A1 | |
| US9129325B2 | United States of America | B2 | |
| US2017109769A1 | United States of America | A1 | |
| US2017109833A1 | United States of America | A1 | |
| CN106910117A | China | A | |
| US9727904B2 | United States of America | B2 | |
| US9754304B2 | United States of America | B2 | |
| US9767491B2 | United States of America | B2 | |
| US2017286983A1 | United States of America | A1 | |
| US9818140B2 | United States of America | B2 | |
| US2017372381A1 | United States of America | A1 | |
| US9904933B2 | United States of America | B2 | |
| US9904948B2 | United States of America | B2 | |
| US2018158086A1 | United States of America | A1 | |
| US10217123B2 | United States of America | B2 | |
| US10262344B2 | United States of America | B2 | |
| US10269030B2 | United States of America | B2 | |
| US10269031B2 | United States of America | B2 | |
| US2019139065A1 | United States of America | A1 | |
| US2019172103A1 | United States of America | A1 | |
| US2019180305A1 | United States of America | A1 | |
| US2019180306A1 | United States of America | A1 | |
| US10489809B2 | United States of America | B2 | |
| US10489810B2 | United States of America | B2 | |
| US10515382B2 | United States of America | B2 | |
| US2020005344A1 | United States of America | A1 | |
| US2020034862A1 | United States of America | A1 | |
| US2020051102A1 | United States of America | A1 | |
| US10679263B2 | United States of America | B2 | |
| US2020265480A1 | United States of America | A1 | |
| US10810609B2 | United States of America | B2 | |
| US10846722B2 | United States of America | B2 | |
| US10853831B2 | United States of America | B2 | |
| US2021035138A1 | United States of America | A1 | |
| US2021081979A1 | United States of America | A1 | |
| US2021150555A1 | United States of America | A1 | |
| US11107134B2 | United States of America | B2 | |
| US2021342896A1 | United States of America | A1 | |
| US2021350397A1 | United States of America | A1 | |
| US11182812B2 | United States of America | B2 | |
| US11244334B2 | United States of America | B2 | |
| US11250453B2 | United States of America | B2 | |
| US2022138789A1 | United States of America | A1 | |
| US11580567B2 | United States of America | B2 | |
| US11580579B2 | United States of America | B2 | |
| US11663644B2 | United States of America | B2 | |
| US2023186365A1 | United States of America | A1 | |
| US11869059B2 | United States of America | B2 |
16 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written submission of copy of amendment under article 19 pctJAPANESE INTERMEDIATE CODE: A524A524 | A524 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 5538397
- Application
- 2011526298
Titles2
- Japanese
- 車両データシステムと連携したセールスジェネレーションのためのシステムおよび方法
- English
- Systems and methods for sales generation in conjunction with vehicle data systems
Classification
- CPC, 20
- G06Q30/0206
- G06Q30/0629
- G06Q30/0627
- G06Q30/02
- G06Q30/0207
- G06Q30/0278
- G06Q30/0282
- G06Q30/0283
- G06Q30/0601
- G06Q30/0605
- G06Q30/0609
- G06Q30/0611
- G06Q30/0621
- G06Q30/0623
- G06Q30/0641
- G06Q30/0643
- G06Q30/08
- G06Q40/12
- G06Q30/0205
- G06Q10/067
- IPC, 1
- G06Q30 06
