CA2624103A1 - Internet enabled vehicle purchase system and method - Google Patents

Description

INTERNET ENABLED VEHICLE PURCHASE SYSTEM AND
METHOD
FIELD OF INVENTION

[0001] This invention relates to vehicle online searching and purchasing and vehicle data management systems.

BACKGROUND OF THE INVENTION

[0002] Use of the Internet for purchase of vehicles by consumers is growing in popularity due to the ever-expanding placement of information that is accessible on-line through various search tools, such as search engines and specialized consumer vehicle portals. Placement of advertising content on-line has grown in popularity due to advantages in reaching a wider target audience. Further, the Internet is fast becoming the primary information search tool for obtaining information about vehicles and vehicle dealerships. Unfortunately, problems exist in today's vehicle purchasing environments, due to large and often disconnected amounts of dealership vehicle data stored locally (e.g. at the dealership) and the inability of users to find desired vehicles remotely (via a search query over a global network - e.g. the internet) that are relevant to the users, such as near the users' location, in the appropriate price range.

[0003] Further, it is difficult for vehicle retailers to manage their product inventories to coordinate published details of their products in the form of advertisements in a product information aggregated environment. Further, currently it is difficult for retailers to coordinate generation of advertisements and other product descriptions for publication electronically.

[0004] It is an object of the present invention to provide an vehicle information environment to obviate or mitigate at least some of the above-presented disadvantages.
BRIEF DESCRIPTION OF THE DRAWINGS

I

. .,..,. ..w, .h , ,v...., ,..,,.. _ ._ _,..

[0005] Exemplary embodiments of the invention will now be described in conjunction with the following drawings, by way of example only, in which:

[0006] Figure 1 is a block diagram of components of a vehicle purchase and management system; and

[0007] Figure 2 is a block diagram of an example computing device for implementing the components of the system of Figure 1;

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S) Vehicle Purchase and Information Environment 10

[0008] Referring to Figures 1 and 2, shown is a vehicle purchase and information system 10, with respect to the interaction between the online advertisements 107 (e.g.
vehicle definitions/profiles constructed from information obtained from dealer vehicle information) and DMSs of the dealers 114. The Internet enabled vehicle purchase system 10 facilitates the searching of vehicle dealer inventories 115 via an electronic vehicle database (containing vehicles of both on the lot and custom ordered in view of consumer selected options) and for processing of a real-time, nominal down payment by a consumer 104 (e.g. through an on-line credit card transaction) for a vehicle chosen from the dealer inventories 115. A vehicle framework 112 consolidates selected vehicle information from the dealer inventory information 115 from a plurality of dealers 114 in a framework database 110, and then provides this information to the consumers 104 over a network 11 (e.g. the Internet) to facilitate vehicle search and purchase capabilities. Once the down payment is accepted by the framework 112, the consumer 104 would then either in person, or remotely, communicate with the dealership 114 for completing all paperwork necessary to purchase the chosen vehicle. Both the dealers 114 and the consumers 104 can be registered with a Web portal of the framework 112, to facilitate full use of the Web portal vehicle search and payment features.
Once registered, the contact information of the consumers 104 can be sent to respective dealers 114.

[0009] It is recognized that the system 10 can also accommodate service and parts in addition to search and purchase of the entire vehicle, such that the framework , would include service/parts definitions 107 similar to the vehicle definition 107. In any event, it is recognized that searching and purchasing via the framework 112 can include vehicles, parts, and/or service, as further described below, and that discussions of vehicles can also pertain to parts and/or service interaction between the framework 112 and the dealers 114 and the framework 112 and the consumers 104, as desired.

[0010] The framework 112 hosts the Web portal 202, accessed by the consumer 104 via their browser, and is also connected to a plurality of Dealer Management Systems (DMSs) through dealer 114 hosted Web interfaces113. Each of the DMSs upload, for example, through their respective Web interface 113, to the Web portal 202 all information 107 needed about each dealer's inventory 115 to facilitate the consumer purchase (e.g. vehicle window sticker details, leasing/payment options, and vehicle picture(s)). The information for each vehicle in the DMS system can be selected so as to only make available a portion of the total vehicle information to the Web portal (e.g.
using set flags or other indicators). The framework 112 uses the DMSs to provide access by the consumer, via the Web portal, directly to the dealer's inventory of vehicles. There is polled intercommunication between the DMSs (via the Web interfaces) and the Web portal for any information updates available on the vehicles in the vehicle inventories (e.g. changes to existing postings, new postings, and deleted postings). The intercommunication also includes an availability check on the consumer chosen vehicle prior to acceptance of the credit card (or other electronic payment e.g.
Pay Pal) down payment, in the event that the chosen vehicle has recently been sold (or in the process of being sold) onsite at the dealership (or via another on-line transaction).
Further, once the down payment is accepted, the on-line purchase is entered into the respective DMS as if the consumer had physically come into the dealership to see a salesperson that is assigned to the chosen vehicle.

[0011] An example process for the nominal down payment is as follows: 1.
Consumer fills in the credit card details in via the Web portal and clicks a payment button; 2. the dealer Web interface runs a web service that sends the credit card payment data via the Internet to a third party payment processor 120; 3. the payment transaction is posted to the dealer's General Ledger (of the DMS) in real-time, which can be provided by the dealer's DMS and/or the Web interface; and the payment ... __. . _ _ . m__......u..i~...4~...._.~L __- .:........... . ....<...-....wmi . ...a_.....we.,,-~m: . ' . . v.++ee..._.- ......... .. . . ...
............_....

processor validates the consumer's payment and sends the funds to the dealer's bank account (an arrangement set up in advance by the dealer).

[0012] The database 110 is hosted by or otherwise accessed through an information aggregation framework 112, which aggregates vehicle information 108 from various DMS sources (e.g. product manufacturers, product retailers such as vehicle dealerships). This aggregated vehicle information 108 is then made available as the vehicle definitions 107 to the consumers 104 via the database 110. The aggregation of the vehicle information 108 in the electronic database 110 can be applied to any vehicle retailer, vehicle dealerships in a competitive marketplace for similar products through digital aggregation of vehicle information, as further described below. It is recognised that the vehicle information 108, when received by the framework 112, may already contain a formatted vehicle definition 107 (e.g. vehicle advertisement) as part of the vehicle information 108. Further, the framework 112 may make available the formatted vehicle definition 107 to the consumer 104, as received, or may modify the received formatted vehicle definition 107 before making it available to the consumer 104. It is also recognised that the framework 112 can supply the vehicle definition 107 to a third party network interface (e.g. independent web portal), who then makes the product definitions 107 available to the consumers 104 via corresponding ones of the search requests 105 and results 106.

[0013] As further described below, periodic update information 109 (received/obtained from the dealers DMSs) is associated with corresponding vehicle definitions 107, in order to have the vehicle definitions properly reflect the status (e.g.
revised vehicle availability, revised vehicle price, revised vehicle financing, etc.) of the vehicles contained in the vehicle inventories 115 of the dealers 114. Each of the vehicle definitions 107 can be assigned a unique identifier by the framework 112 when they structured and classified for storage in the database 110, whereby this unique identifier is communicated to the dealers 114 for each of the vehicle definitions 107 received in the vehicle information 108. Accordingly, subsequent update information 109 sent by the dealers 114 contains the appropriate unique identifier, such that the framework 112 can match the update information 109 to the appropriate vehicle definition 107. The unique identifier can contain identifier information (e.g. alpha-numeric) assigned by the framework 112, which can include information about the specific dealer and/or retailer associated with the vehicle of the vehicle definition 107.

[0014] Communications between the consumers 104, the framework 112, and the dealers 114 are facilitated via one or more communication networks 11 (such as intranets and/or extranets - e.g. the Internet). The vehicle information system 10 can include multiple consumers 104, one or more frameworks 112 (e.g. each framework directed to a specified vehicle type - such as particular manufactures, particular geographic regions, particular vehicle classifications such as new or used, etc.), multiple dealers 114, respective multiple hosting devices 101, and one or more coupled communication networks 11, as desired. Examples of the devices 101 are provided below.

Searching of the Database 110

[0015] The framework 112 hosts the Web interface 202 for providing published consumer vehicle definitions 107 to a plurality of potential consumers 104, via search results 106, based on one or more search requests 105. One example of the published vehicle definitions 107 is a vehicle advertisement 107 that provides vehicle details such as price, location, and/or vehicle description, as further described below.
The search request 105 of the consumer 104 includes search parameters 99 (e.g. keyword terms, phrases, etc.) for use in helping to identify the search results 106 from the electronic storage 110 (e.g. database) that are relevant to the potential consumer 104 of the vehicle defined in the vehicle definition 107. For example, the consumers 104 could search vehicle "for sale" information in the database 110 of the system 10 to find the sorted (e.g. lowest) advertised new vehicle prices (associated with the corresponding vehicle advertisement 107) in various/selected market(s) across the country.
Accordingly, the search parameters 99 could include parameters such as but not limited to: vehicle type (e.g. vehicle make, manufacturer); vehicle retailer (e.g.
specific dealerships having the desired vehicle); and/or vehicle location (e.g.
physical location of the vehicle dealership). Matches to at least some of these search parameters 99 would be included in the contents of the various vehicle definitions 107 stored in the database 110.

,... ,,

[0016] The consumers 104 can be potential vehicle purchasers (e.g. people, named organizations, etc.) that desire to purchase the vehicle based on vehicle details contained in the vehicle definitions 107 that are available from the framework 112. The vehicle definitions 107 could contain vehicle data such as but not limited to:
image data;
video data; audio data; and/or text/literary data, such that the vehicle data provides information for use by the consumer 104 in making a decision whether to or not to purchase the vehicle. The user 104 submits the search request 105 to the framework 112 over the network 11 in order to find out about the vehicle details and associated price, delivery, and/or location information of the vehicle, through matching of at least some of the search parameters 99 in the request 105 with contents of the vehicle definition 107. For example, the consumer 104 wants to locate all vehicles of a certain make and model and year in the state of New York. These parameters would be part of the search request 105, which is then sent to the framework 112 for matching against the contents of the vehicle definitions 107 stored in the database 110.

Further, it is recognised that the aggregation of the vehicle information 108 in the database 110 (as sourced from various independent physical/virtual vehicle definitions, such as vehicle advertisements, from the dealers 114) can facilitate higher efficiency and data integrity through vertical specialization, such that the vehicle definitions can be organized as vehicle and/or vendor centric (e.g. vehicle and dealership centric input).
Therefore, instead of the consumer 104 typing a vehicle of vendor name for insertion into the search request 105 (e.g. a vehicle or dealership name), the consumer can chose the name from a list that is updated regularly. This list of available vehicles, vendors/retailers 114, and/or location of the vendors/retailers 114 could be provided online by the network interface module 202 of the framework 112, further described below. It is recognized that the information content available of the vehicle definitions 107 in the database 110 is dependent upon the vehicle information 108 obtained from the dealers 114, as well as the periodic updates 109. For example, in the event that a vehicle is sold off the dealership floor, an update message would be sent (either inside or outside of a periodic update cycle) from the dealership 114 to the framework 112 that indicates that this specific vehicle is no longer available. Also, a further example is where in the event that the dealer 114 wishes to change the vehicle pricing or other vehicle information in the vehicle definition 107, the update message could be used to inform the framework 112 to make a corresponding change to the vehicle definition 107 store in the database 110. It is recognized that the update information could be obtained from the DMSs of the dealers 114, and that any interaction (e.g.
definition 107 selected from results 106 list, down payment submitted, etc.) of the consumers 104 with the definitions 107 could also be reported back to the dealer DMSs via the framework 112.

Example Embodiment of the System 10

[0017] It is recognized that the use of online advertisements (e.g. car ads 107) and updating of the advertisements is based on information obtained from the dealerships DMSs. It should be noted that an advertisement 107 searchable by the consumers 104 is in combination with this online system 10, and as such the interaction between DMSs and the online ad content is used to keep the online advertisements 107 current with respect to the details of the respective vehicle available in the DMS.

[0018] The online system 10 of locating a vehicle having specific details in an inventory (actual on the lot and/or virtual as not on the lot but available for purchase through the dealership) represented by the product definitions 107 stored in the framework 112 data base 110. The framework 112 includes a locate client process operable to receive vehicle details data and generate a search request message incorporating the vehicle details data in response to user input, and an inventory database storing vehicle availability data of dealer inventory. A locate server process is operable to receive the search request message from the locate client process, and search the vehicle availability data in the framework 112 for vehicles matching and substantially matching the vehicle details data. The locate server is further operable to generate a search reply message containing the matching vehicles and return the search reply message to the locate client process. In general, a consumer provided with real-time information is contemplated, prior to the placement of an order or purchase by the consumer. The information regards the availability and status of a vehicle in relation to the vehicle's framework 112 inventory. A customer is afforded the opportunity to specify the desired vehicle to search the inventory for availability. The customer may tag a vehicle that is currently anywhere in the inventory that fits his/her criteria for purchase.

[0019] In terms of the vehicle inventory database 110, the framework 112 is configured to receive a search request message having vehicle details data submitted by a user, formulate a search query with search criteria corresponding to the vehicle data, and search an inventory database for a vehicle matching the data. The inventory database can contain vehicles on the order bank, in-production, in-transit, and in-inventory. The search is facilitated using a consumer front end that includes one or more portals or web sites accessible over the World Wide Web (WWW) or the Internet over which consumers can access the framework 112. The portals may also include a web site dedicated to automotive sales of one or more makers, or a web site owned and operated by a dealership selling automobiles of one or more makers.

[0020] In terms of payment options, the consumer may tag a located vehicle, for example, using a customer credit card, checking account number or electronic voucher or gift certificate. The consumer is then notified that a vehicle has been located and tagged, and may be further notified that the actual purchase or delivery of such vehicle may be conditioned, for example, upon payment or credit verification. The consumer may be warned that there is a possibility that the vehicle has been tagged or sold to someone who may have purchased the vehicle prior to the consumer's effort to locate and tag the vehicle. This may occur due to lag time in updating the inventory database 110 via the DMSs. It should be noted that the tag/holding process is to reserve a vehicle, by providing credit and/or other financial information. The consumer is asked to provide a credit card account number from which a predetermined amount or a certain percentage of the vehicle price is charged to hold the selected vehicle, emphasis added. Further, the consumer is able to tag a vehicle only after a down payment has been paid or the consumer's credit has been approved.

[0021] In terms of inventory database 110 updates, the inventory database 110, which contains the updated vehicle definitions 107 from all the dealerships and products in-process (in-transit, in production, and on the order bank). An inventory data importer can perform the inventory data import batch process in a periodic manner, such as nightly, to update the data in inventory database 110. Inventory data importer may use a modem dial-up connection, file transport protocol (FTP) and/or other mechanism to pull inventory records from the dealerships. The inventory database may be batch processed or updated in real-time as necessary so that the most recent data is available for searching by the consumer 104. Weekly full extract may be performed in addition to nightly updates on new data. Further, it is noted that the database can maintain a record of tagged vehicles, as when a vehicle is temporarily tagged, described is that it is not returned in subsequent search results.

[0022] For an example operation of the system, refer to Appendix 3.
Further Example Embodiment of the System 10

[0023] Enabling consumers to buy cars online directly from franchise dealers with a credit card down payment - Buy Direct

[0024] Darwin XE's Buy Direct module of the framework 112 provides a complete and real-time link between the dealer's dealer management system (DMS) and designated auto web portal (e.g. module 202). By doing so it facilitates true ecommerce transactions in real time between the dealership and consumers over the Web.
Such transactions encompass vehicle selling by enabling the consumer to research by viewing the dealer's vehicle inventory and then permit the consumer to complete a vehicle sales transaction in real time. However, the ecommerce is not limited to vehicle sales transactions. The consumer interoperability with a dealer's primary DMS
can be extended to other aspects that occur within the dealership, for example activities such as but not limited to; service appointment scheduling, checking on the status of a vehicle that is in for service, providing an additional service recommendation authorization, checking on outstanding campaigns and recalls, reprinting prior service invoices, placing orders for parts, etc., all may be done in a similar manner to search and purchase of vehicles via the framework 112. Different interfaces can also used via the module 202 for what is wholesale parts customers (body shops and aftermarket parts purchasers and other different make vehicle dealerships) to directly place orders, check parts inventory, confirm shipment status and pay for orders again by directly interoperating with the dealer's primary Darwin XE business system by coming in over the Internet 11.

[0025] Accordingly, the framework 112 (as well as any associated client applications 117 to the framework 112 server application) provides a direct link for the potential purchaser to the dealer management system and vehicle inventory. The framework 112 links the dealer's vehicle inventory data stored in Darwin XE
(e.g. DMS) with a designated auto web portal such as the module 202 and allows the shopper to browse through the dealer's available vehicle inventory.

[0026] An example of the consumer 104 interaction with the framework 112 is as follows. Once the shopper selects a vehicle, the following steps can be completed online:

[0027] STEP 1 - GET STARTED: Select a make and model, then click Search Inventory. This action will search dealership inventory of the database 110.
For example, if the corresponding vehicle match is not within the database 110 (e.g.
because it is not there or those vehicles that do match are not desired by the consumer), then the framework 112 can submit a search query to selected dealerships 114 to request if they have such a vehicle match.

[0028] STEP 2 - CHOOSE A VEHICLE: View a list of available vehicles currently on dealers' lots. Click View Details for more information or Buy Direct to get this vehicle.

[0029] STEP 3- VIEW DETAILS: See more details of a specific vehicle on a dealers' lot, including days the vehicle has been on the lot, odometer reading and complete window sticker information.

[0030] STEP 4- ACCOUNT LOGIN: Login to your pre-existing account or create a new one. You can store your searches here and your finance/credit application under manage account.

[0031] STEP 5 - PURCHASE DETAILS: View and choose from three purchase options, for example: Buy (You have financing or you have cash), Finance, or Lease.
You can adjust monthly payment and deposit amounts here. This can also include 1) submit offer to the dealer via the framework 112; 2) if the offer is below gross profit acceptability parameters in the DMS, a real time (e.g. automatic) counteroffer is sent back to purchaser according to predefined rules (either of the dealer 114 and/or of the framework 112) or the purchaser offer is accepted based on same rules; and 3) once accepted the purchaser proceeds to a shopping cart to enter in personal details and use a Credit Card to submit a deposit to hold the vehicle.

[0032] STEP 6 - FINANCING: If you wish to finance or lease your vehicle, complete the financing application here. You can save this in Manage Account and come back to it later if you choose.

[0033] STEP 7 - PAYMENT INFO: Use a major credit card to place a deposit on your vehicle and the dealer will complete your paperwork. This deposit is applied to the purchase price and can be 100% Refundable should you change your mind. - YOU

x ~.~~,...~ , , .. _..

ARE DONE AT THIS POINT! - View your completed form with dealer contact person.
The dealer will contact you to arrange for vehicle pickup or optional shipping (prices do not include shipping or tax).

[0034] In view of the above described example operation, at Step 1, the consumer's contact information can be written into the dealer's Darwin XE
(e.g. DMS) database (e.g. the consumer's info and vehicle desired is written in to the sales lead tracking section in the DMS via the framework 112). When Step 7 occurs the vehicle is marked as sold in the dealer's Darwin XE (e.g. DMS) database. These DMS
information updates are further described below, in particular with example update programs in Appendix 1.

[0035] Another related process is as follows:

[0036] 1) Purchaser requests a Payment Quote for a specified term;

[0037] 2) credit information is collected and sent to the dealer DMS system via the framework 112;

[0038] 3) a credit check is performed and a score is determined based on predefined criteria;

[0039] 4) Tiered interest rate criteria by financial institution is applied to accurately provide a payment quote which is returned to the purchaser;

[0040] 5) when accepted a deposit is provided [MA] via a Credit Card;

[0041) 6) the purchaser proceeds to the shopping cart; and

[0042] 7) delivery is set up.

[0043] It is recognized that any of the steps performed directly by the dealers 114 can also be performed as configured by the framework 112 and vice versa.

[0044] The framework 112 enables web service calls (WSDLs) on the selling party's primary business system in order to facilitate true eCommerce in real time. The selling party's primary business system can be either Darwin XE or either ADP
or Reynolds & Reynolds' (e.g. DMSs), for example, as the framework 112 can connect the consumer 104 to those systems. The WSDLs then deliver back to the consumer the result of the call (valid inventory listing, acceptable purchase price, available shop time, etc.) and provide the opportunity to transact with the selling party. Such inquiries are also directly logged into the primary business application against the customer record and in various sections of the primary business application for efficient follow up whether the consumer transacts over the Internet or not. Accordingly, the framework 112 provides for a web application in the dealership (Darwin XE's Buy Direct module 117) that is connected via the Internet 11 to the auto portal 202 so that, in effect, consumers are using web portal 202 as an interface to the dealer's 114 business system (e.g. DMS) to submit a down payment by credit card and so buy in real-time the specific, desired vehicle from the dealer's inventory 115.

[0045] Also recognized is that the framework 112 can provide for consolidated accounting, whereby the framework 112 enabled DMS (e.g. via the client application 117) provides a multi franchise and/or multi-location dealer with the ability to submit the required OEM financial statements that adheres to manufacturer standards while enabling the dealer to have consolidated reporting. The configured DMS can include a Consolidated Financial Statement that enables the dealer to view all Franchisee/Companies as a single company at the click of a button. It provides Consolidated accounting view of all activities combined and broken out by department with extensive break down detail. The configured DMS (e.g. via the module 117 or by the DMS itself) uses a consolidation account number that consolidates dealer information (service repairs, inventory, parts, sales) into a common statement. A
consolidation algorithm is used to map incompatible formats and associated information for different car companies based charts to a common consolidated chart. The consolidated chart allows for multiple factory layouts without losing their inherent functionality (i.e. a rationalized combined layout). The consolidation algorithm operates as an extraction routine to extract content from the various charts and to then balance/validate the combined content for output to a predefined customized format, without losing the inherent functionality included in the individual charts.

[0046] Also described are a plurality of potential solution features (e.g.
accounting, payroll, vehicle sales process, vehicle inventory control, repair shop solutions, parts department solutions, dealer OEM communications, and general systems) in Appendix 4 that the DMS can be coupled to, either directly as a fully configured DMS, or a DMS coupled to a remote network service (e.g. offered by the framework 112) hosted on a third party network server (e.g. Darwin enabled) via an appropriately configured interface module 117 that facilitates communication between I

.. . . . . ...: : : . .: .. . ,._ . , the DMS and the desired" Darwin" functionality that is hosted by the remote network service (e.g. offered by the framework 112). It is recognised that the Appendix 4 provides one example configuration of the Darwin features, entitled Neosynergy.

DMS and/or Interface Module 117 functionality - ACCOUNTING SYSTEM
DIFFERENTIATORS

[0047] It is recognised that the dealer DMS can take advantage of the below discussed functionality, either directly as an appropriately fully configured DMS, or a DMS coupled to a remote network service (e.g. offered by the framework 112) hosted on a third party network server (e.g. Darwin enabled) via an appropriately configured interface module 117 that facilitates communication between the DMS and the desired"
Darwin" functionality that is hosted by the remote network service (e.g.
offered by the framework 112).

[0048] The dealer DMS itself, or the DMS in interaction with the interface module 117, makes use of several "clearing" accounts in the general ledger of the dealership 114. It is also recognized that some of the below functionality could be either performed or otherwise shared with the framework 112 capabilities. These functionalities are given below by example only. It is recognized in the below discussion that reference to inventory can relate to the dealership inventory 115 (e.g. available vehicles for sale/lease, service, parts, etc.). It is recognized that the below described functionality could use appropriate update procedures as provided by example in Appendix 1.
Further, all of the below given example mechanisms (including those in Appendix 1) could also be interpreted as an means for doing their function, such that their function could be provided in software, hardware, or a combination thereof as modules (for example see modules described in Appendix 2) of the computer system 101 (see Figure 2).

Work in Process-Labor

[0049] When labor is booked to a RO either manually or via the clocking module, the WIP labor accountis debited with the cost value and the technician payable account is credited with the same amount. When the RO in invoiced to the customer, the WIP
account is credited and the COS account is debited with the same amount.

Work in Process-Parts , _ _ ~ ..r . .

[0050] When a parts or service cash sale is invoiced, the parts or service cash clearing account is debited with the total sales value. When the cashier produces a receipt for the customer, the cash clearing account is credited and a "Cash On Hand" or "Undeposited Cash" account is debited. When the Bank Deposit is processed, the Cash On Hand account is credited and the bank account is debited. What this allows is to easily identify unreceipted cash sales as well as undeposited cash. It also means that the cash deposit amount in the bank account is the actual deposit amount, and not numerous individual receipts which makes bank reconciliation easier.

Daily Cash Control

[0051] See Above.

Accounts Payable Purchases Clearinp

[0052] The account is used for Parts Inventory purchases and returns. When a parts order is released into inventory, the Inventory account is debited with the Qty *
Replacement Cost and the Purchase Clearing account is credited with the same amount. When the Vendor Invoice is processed, the Purchase clearing account is debited with the original amount, and the AP account is credited with the invoice amount. Any additional chares such as Freight are posted to the respective accounts at the same time.

During the Monthly Parts Pricina Update grocess, parts cost values are chanped.

[0053] This causes an appreciation/depreciation condition. Since your Parts on hand (Qty x Cost) always balances with the Parts GL + WIP parts, how and when is the difference accounted for?

[0054] When the Price Tape is run any price change (up or down) will revalue the parts inventory if the is inventory on hand. The parts Inventory account will be debited in the case of a price increase and the Parts Write-up Reserve account will be credited with the same amount. At year end, the dealer can decide what to do about any credit balance (unrealized profit) in this account. It can either be taken as profit or used to adjust cost of sales / parts inventory adjustments etc.

. .. m. , ...

Durina the parts return orocess, parts are removed from inventory several days before a credit is received. How is perpetual inventory and accountina inventory balanced in this case?

[0055] This is handled exactly as an order is handled. When the Parts Return is released, the system will Credit Parts Inventory with the total value and debit the Purchases Clearing account. When the credit note is received, the system will credit the Purchase Clearing and debit the AP control account.

[0056] The above steps facilitate that the physical parts inventory at all times agrees with the general ledger inventory balance, helping to eliminate the need for manual reconciliations to be done, which is a big time-saver for the dealer.

What other "clearing"/"contro!" accounts are there?

[0057] There is a sales inventory reconditioning clearing account. When a purchase order is made out for any outwork / sublets on a vehicle, the option exists for an estimated amount to be entered. Likewise, when desking a deal, and "dealer-fitted"
extras with an estimated cost entered are included on the deal, the system will generate a debit entry to the vehicle inventory account and a credit entry to the reconditioning clearing account. Once the final Vendor Invoice or RO is processed, the system will credit the clearing account with the original amount, and if the final amount is different to the original estimate, any adjustment is automatically done to the Vehicle Inventory Account (or Cost of Sales if the vehicle is sold).

[0058] These clearing accounts are all automatically maintained by the system, and need no manual reconciliation. What they do, is enable the office manager to be confident that the financials are good and in balance. It also means no surprises at the end of the month.

[0059] Some other accounts are:

1. When vehicles are stocked by not issuing a check or floor planning, a vehicle purchase clearing account is used. When the vendor invoice is processed, or a check is cut or the vehicle is floor planned it clears the purchase account.

2. Like the Reconditioning clearing account mentioned before, we have similar functionality for "potential trade-ins". Very often, the dealers start doing work on traded-in vehicles before the deal in finalized. We track these entries in a clearing account (i.e., not to inventory, as this would put the GL and Vehicle Inventory sub-ledger out of balance) and once the deal in finalized and the trade in is stocked, the system transfers the amount from the clearing account to the used vehicle reconditioning account.

3. We have a Bank account and a Statement account. All deposits and checks hit the bank account. Once the Bank Recon is done using our bank reconciliation system, the reconciled entries are automatically moved from the Bank account to the Statement account. So the Statement account always reflects the actual bank balance.

4. Where a dealer has multiple rooftops, we allow for inter-company processing in a number of areas:
a. Centralized bank account - a check can be cut in one dealership to pay for an expense / AP etc in another dealership and the system will generate the necessary inter company accounts b. Centralized sales vehicle inventory where the vehicle is transferred to the selling dealer inventory when the deal is booked to accounting c. Centralized AP accounts d. Centralized AR accounts How is Accounts Receivable aged by statement print date or by calendar month?

[0060] AR's are aged by Accounting month. Statements can be printed at any time. We know of dealers that send statements out twice a month: on the 15th and the 1 St.

Can A/R statements be e-mailed? Can the same customer have more than 1 control number?

[0061] Statements can be emailed to customers. A customer can have multiple AR Accounts e.g., Parts Wholesale, Service, Vehicle etc.

Does DXE sunvort on-line banking? ie.. Pay electronically from dealer's acct to A/P
vendor?

[0062] Darwin currently does not have electronic payments, but it does have credit card payment processing (incoming payments).

How often can I print my Financial Statement? How many months of statements are available for printing on the same day?

[0063] Financial Statements can be printed out as often as you like, whenever you like, for the current accounting month, and any previous accounting month dating back to the first month of the previous year. So, in December 2008 one can print financial statements back to January 2007. However, account transaction detail goes back to day #1 on the system.

Is there a limit to the number of GL accounts that I can have?

[0064] There is no limit to the number of GL accounts or franchises in the same chart of accounts.

Is there a limit to the number of Franchises that can be included in one General Ledaer (GL)?

[0065] There is no limit to the number of rooftops (company as we call it in Darwin). The Company Number is an 8 digit alpha numeric field, for example.
Automatic consolidations are done for multiple rooftop dealer groups.

What is the maximum size of a GL account number?

[0066] The GL account is a 16 digit alpha numeric field. The dealer does not have to use the OEM account number; we have a mapping mechanism for that. So if the OEM has say one account for a particular expense, the dealer can have many accounts mapping to the one OEM account.

Is there a limit to the number of schedules available?

[0067] There is no limit to the number of schedules in the system, but each schedule is limited to 8 GL accounts, for example.

Darwin Control Accounts in the Parts System

[0068] A major problem in DMS systems in the USA is that they do not do proper work in progress (WIP) accounting. They also have weak integration between the inventory applications and the general ledger, which means that they have major manual reconciliations that need to be done every month in order to do accurate financial reporting.

[0069] This document will describe how these areas are handled in the Darwin XE application eliminating many man hours of work needed to be done in the dealerships every month. It is recognized that the Darwin XE application can refer to the interface module 117 that is coupled to an existing dealer DMS or the Darwin XE
application can refer to an appropriately configured DMS.

[0070] Full WIP accounting is maintained between the Service application and the General Ledger, as well as the Parts application and Service. The other DMS
applications do not relieve the physical parts inventory at the time that the parts are issued to the repair orders and handed over to the technicians. There is also no record of the transaction in the general ledger. What this means is that parts have been physically removed from the bin in the parts department and handed over to a technician.

[0071] The reason why the other DMS systems do this is because it is not correct to reflect the sale of the part until the repair order is invoiced, because there is every possibility that the part could be returned to the parts department for any number of reasons. So the sale is only raised once the repair order is invoiced, as it is then the responsibility of the customer to pay for the part.

[0072] There is no account for that part until the repair order has been invoiced, which could be anything from a few hours after the part was taken to many weeks after the part was taken. If one multiplies this by hundreds of repair orders being worked on at any time, the magnitude of the problem is realized.

[0073] Typically, there are hundreds of parts where the on-hand quantity shown by the DMS does not agree with what is in the bin because of this. The parts manager therefore never really knows if he has a problem in the parts inventory or not. Also, the financial statement value shown for parts inventory is never 100% correct.

[0074] This also impacts on the accuracy of parts recommended orders, because the on hand value reflected by the DMS is incorrect. Many man hours are spent every month reconciling the physical inventory to the general ledger. Typically spread sheets are used to do this and the end result is never really 100% accurate.

How Darwin XE handles parts WIP

[0075] When a part is issued to a repair order, the inventory record for that part is relieved immediately in the DMS. Entries are also generated in the general ledger to account for the movement of the inventory. This is done to ensure that the inventory records in the system agree 100% with the inventory value reflected in the general ledger.

[0076] Example: Assume a part where the cost price is $10. The parts inventory account will reflect the $10 as part of the balance. When one part is issued to a repair order, the DMS will generate the following entries:

1. Credit Parts Inventory with $10 2. Debit Parts Work In Progress with $10 3. Reduce the Physical Inventory quantity on the parts inventory record by 1

[0077] Once this has happened, should a parts inventory report be printed, the total value shown on the report would agree with the value reflected in the parts inventory account in the general ledger.

[0078] The on hand quantity shown for the stock record by the DMS will agree with the physical quantity in the bin. There is also a WIP report which reflects all parts in status WIP. The total of this report will agree with the Parts Work In Progress account in the general ledger.

[0079] When the repair order is invoiced, the DMS will create the following entries (in addition to all the other necessary entries):

1. Credit Parts Work In Progress with $10 2. Debit Parts Cost Of Sales with $10 3. All the other related GL entries for the repair order

[0080] By performing the above functions within the DMS, it is no longer necessary for a manual reconciliation to be done every month to adjust the inventory value in the general ledger to reflect the actual inventory.

How Darwin XE handles Parts Inventory Ordering

[0081] Another area in the current DMS applications that causes manual reconciliations is the lack of integration in the parts ordering module. When parts for an order are released into inventory the physical inventory is updated, but the general ledger is only updated when the vendor invoice is processed by the accounting office.
This could take anything from a day to several weeks.

[0082] Multiply this by 100 orders per month and the magnitude of the problem is realized. There is probably never a point in time in the current DMS systems when the physical inventory reflected in the DMS agrees with the balance in the general ledger.

[0083] The Darwin XE application makes use of clearing accounts to circumvent this problem. The Parts Order module uses a Parts Purchases Clearing account.

[0084] Assume a part where the cost price is $10. When a parts order for this part is released into inventory, the DMS will update the physical inventory on hand quantity as well as generate the necessary general ledger entries as follows:

1. Debit Parts Inventory with $10 2. Create Parts Purchase Clearing with $10 3. Increase the Physical Inventory quantity on the parts inventory record by 1

[0085] Once this has happened, should a parts inventory report be printed, the total value shown on the report would agree with the value reflected in the parts inventory account in the general ledger.

[0086] The on hand quantity shown for the stock record by the DMS will agree with the physical quantity in the bin. There is also a report which reflects all parts ordered that have been released into inventory where the vendor invoice has not yet been processed. The total of this report will agree with the Parts Purchase Clearing account in the general ledger.

[0087] When the vendor invoice for the part is processed, the DMS will process the following general ledger entries:

1. Debit Parts Purchase Clearing with $10 2. Create Accounts Payable Control with $10 .~ ~ .~.~

[0088] By utilizing the above process in the Darwin XE DMS the users need not manually reconcile the unprocessed, or not yet received vendor invoices in order to arrive at a true inventory value.

How Darwin XE handles Parts Inventory Adjustments

[0089] Current DMS systems allow for the changing of parts quantities reflected on the inventory records without updating the general ledger. The Darwin XE
DMS will update the general ledger with any change made to an inventory quantity in the system.

[0090] There are legitimate reasons for making changes to inventory quantities, a few are:

1. A "left hand" part is sold using a "right hand" part number (although the correct procedure would be to pass a credit note for the incorrect part and invoice the correct part) 2. The OEM send the wrong part using the part number of the part originally ordered 3. When a physical stock count shows a discrepancy 4. Perpetual or Annual inventory counts

[0091] Assume a part costing $10 and an adjustment is made for +1 part. When a physical inventory adjustment is made the DMS will generate the following entries:

1. Debit Parts Inventory with $10 2. Credit Parts Inventory Adjustment with $10

[0092] Once this has happened, should a parts inventory report be printed, the total value shown on the report would agree with the value reflected in the parts inventory account in the general ledger.

How Darwin XE handles OEM Parts Price Tapes

[0093] Every month, the OEMs send out new price tapes which reflect the latest dealer pricing for the parts inventory. Dealers in the USA value their inventory as replacement cost. Therefore, it the price of a part that the dealer has in inventory changes, this needs to generate entries in the general ledger to the parts inventory account in order for the physical inventory to remain in balance with the general ledger.

[0094] Assume a part where the dealer has two in inventory costing $10 and the replacement cost of the part changes to $12, a $2 increase. When the Price Update routine is run in the Darwin XE DMS the following entries are generated:

1. Debit Parts Inventory with $4 (2 x $2) 2. Credit Parts Inventory Adjustment with $4.00

[0095] Once this has happened, should a parts inventory report be printed, the total value shown on the report would agree with the value reflected in the parts inventory account in the general ledger.

Summary

[0096] The procedures described above facilitates the removal of dealer staff to do lengthy manual reconciliations of WIP parts, unprocessed vendor invoices, physical inventory adjustments and price changes to arrive at a physical inventory value which resembles the value of inventory reflected in the general ledger. It also facilitates the removal of the need to make large inventory write offs at financial year end, which is normal with the other DMS systems in use.

Darwin Control Accounts in the Vehicle Inventory System

[0097] The Darwin XE DMS uses control accounts in the Vehicle Inventory system to manage key areas of cost control that other DMS systems do not do.
This results in cost savings as these are typically areas that are manually reconciled and more often than not, the issues are only discovered after the vehicle has been sold and it is then too late to recover these costs.

Reconditioning on New and Used Vehicles

[0098] This is controlled by using an Estimated Reconditioning control account.
When a purchase order is generated against a vehicle for reconditioning, either in the dealers own service department, or outsourced in the form of sublet work, an estimated amount is entered into the Darwin XE DMS. Assume an amount of $150 being entered.
This amount is used to raise general ledger entries as follows:

1. Debit Vehicle Inventory with $150 2. Credit Estimated Reconditioning with $150 3. Update the Reconditioning Cost on the Vehicle Inventory Record with $150

[0099] The above entries are generated at the point of creating the Purchase Order. The reason for doing this is so that the total potential cost of the vehicle is known even before the work is completed.

[00100] This can be very important should the dealer be in the process of selling the vehicle, in that the true costs are known upfront and no surprise costs appear after the vehicle has been sold and commissions have been paid, when it is not possible to recover the costs.

[00101] If a Vehicle Inventory List is produced, it would balance with the general ledger because of the above actions.

[00102] When the Vendor Invoice for the sublet work is processed, or the repair order is closed in the case of dealer performed reconditioning, the system then finalizes the entries. Assuming in the above example, the final cost is $155.90 the following entries are generated:

1. Credit the Payable with $155.90 2. Debit Vehicle Inventory with $5.90 3. Debit Estimated Reconditioning with $150 4. Update the Reconditioning Cost on the Vehicle Inventory Record with $5.90

[00103] If a Vehicle Inventory List is produced, it would balance with the general ledger because of the above actions.

Potential Trade-In Vehicle Reconditioning

[00104] It is common practice for a dealer to commence with reconditioning on a potential trade-in before the deal has been finalized. In the event that the buyer is unable to secure finance, or for some other reason, the deal might have to be canceled and any money for work done on the potential trade-in needs to be recovered, or written off. It is even possible that the potential trade-in could have been sold.

[00105] Normal Inventory reconditioning GL entries cannot be done in this case, because the potential trade-in vehicle has not yet been stocked and this would cause an imbalance between general ledger and the vehicle inventories.

[00106] When the Vendor Invoice for the sublet work is processed, or the repair order is closed in the case of dealer performed reconditioning, assuming a cost of $200, the system generates the following entries:

5. Credit the Payable with $200 6. Debit Potential Trade-in Reconditioning with $200 7. Update the Reconditioning Cost on the Vehicle Inventory Record with $200

[00107] When the deal on the vehicle being sold is booked into accounting, besides all the normal general ledger entries generated by the sale the following entries are generated:

1. Debit Vehicle Inventory / Reconditioning with $200 2. Credit Potential Trade-in reconditioning with $200 Darwin Control Accounts in the Accountina System

[00108] The Darwin XE DMS utilizes control accounts to manage all cash in the dealership as well as the bank account in the general ledger. Control accounts are maintained for both parts and service cash sales. These accounts make is very easy to cash sales in all departments that have not been receipted as well as all cash and checks that have not been deposited in the bank.

[00109] When either a parts cash invoice or a service cash repair order is invoiced the system will post a debit entry to a Parts or Service Cash Control account.
Assuming a cash sale of $125, when the cashier receipts the money the system will generate the following entries:

1. Credit the Parts / Service Cash Control Account with $125 2. Debit the Cash On Hand Account with $125

[00110] The Parts / Service Cash Control account contains details of all the cash sales that have not been receipted and the Cash On Hand account contains the detail of all receipted cash sales that have not yet been deposited in the bank.

[00111] When the bank deposit is processed, the system will generate the following entries for all the receipted entries that have been selected:

1. Credit the Cash On Hand account with the total being deposited 2. Debit the Bank Account with the total being deposited 3. Optionally print a bank deposit report

[00112] The above step makes reconciling the bank statement to the bank account much easier as the deposit entries on the general ledger bank account agree with the deposit entries on the bank statement.

[00113] The next step in the cash management process is the reconciliation of the bank statement to the bank account in the general ledger. When a check is produced in the DMS or a bank deposit is made, these entries are automatically generated in the general ledger bank account.

[00114] When the bank statement is reconciled in the Bank Reconciliation application in the Darwin XE DMS the system will transfer reconciled entries from the general ledger bank account to the general ledger bank statement account and flag them as paid / reconciled in the bank account.

[00115] This means that the bank statement account will always reflect the detail and the balance of the actual bank statement and the bank account will always reflect the detail of checks and cash that have not yet appeared on the bank statement. The net balances of the two accounts reflect the true cash balance of the dealership.

Darwin XE Fixed Operations 1) Can DXE receive information via Bar Code Scanners for parts both during stock in procedures and sales?

[00116] Yes we can. Remember, in a Windows environment, a bar code reader simply emulates a keyboard. We can use bar code readers for parts inventory, stocking, sales and counting, stocking of vehicle inventory (reading the VIN), and creating a RO
(reading the VIN). Darwin will run on a tablet PC with a bar code reader attached. This facilitates stocking of vehicles when they are delivered or creating ROs on the service drive.

2) When a part that carries core is sold how is the core value handled? When a dirty core is turned in how is that credit handled both with regard to perpetual counts and to accounting entry?

[00117] In Darwin we have what is known as a "core part suffix" (or prefix as is the case with Chrysler). So part number "ABC123" would have a core part "ABC123C".
The core part has a cost price associated with it, and the main part's cost is net of the core. When the part it invoiced, the system automatically includes the core part number on the invoice. If the customer is returning a core, the quantity is simply changed to a credit. When a part is released into inventory from an order, it will automatically update the core part as well. When cores are retuned to the factory, they are processed as a parts return.

3) When the parts department issues a Purchase Order to a local parts store does that information carry through to the RO? How about a sublet PO i.e., radiator?

[00118] When a Parts Purchase Order is created, we have the option of entering a RO number against individual order lines. When the order is released, the system will automatically create a parts invoice with that part against the RO. Depending on a parameter setup, the system will either leave the Parts Invoice in "created"
status, or it will actually post the invoice to the RO. When a Sublet is ordered, the procedure in very similar, the main difference is that the system creates a "part number" using the Order Number and the Line Number (e.g. P0001232-01). At month end, all these parts with a zero on hand balance remain in the system for auditing purposes. Using this method make it easier to control sublets, as they are treated as physical inventory until the RO
is invoiced.

4) When a purchase order for a Rental Car is issued, does that trigger any special alert for the service advisor?

[00119] A Purchase Order is created against a RO for car rental, much like a Sublet (outwork) order. An RO cannot be invoiced without a vendor invoice posted against the PO. We need to do this in order to capture the number of days, and to also handle it correctly on the integration of warranty claims with the OEM where car rental information is required.

5) Does DXE interface with Electronic Parts Catalogs?

[00120] We have done integration for Microcat, Pro Quest and Start Parts (Chrysler) 6) During the installation process, can NeoSynergy transfer Parts History and Vehicle Repair History from the retiring system?

[00121] If the retiring system is REY or ADP, we have written a conversion process that converts Customer records, Vehicle Inventory, Service History and Parts History directly into Darwin without having to dump out data from those systems. This process is automated, and does 95%+ of the work required to set us a new dealership in Darwin. For other systems we need to dump out data in the form of reports etc and convert the data.

7) Many dealers rely upon an annual Parts Department Physical Inventory to verify the accuracy of the balance for Parts and Accessories in the General Ledger.
During the annual process the following is needed:

[00122] Parts Inventory Count Pad in Bin Location Sequence

[00123] Input process for entering the new physical counts

[00124] Report of Count Pad pages not posted

[00125] Variance Report that displays any difference in count/extended value before and after Final Extended Value Report in a variety of sequences. Can DXE accommodate this process?

[00126] Darwin has a very comprehensive parts count module that does all of the above items that you mention and more. We also have a perpetual count procedure where the dealer can specify how many time in a year every part needs to be counted (e.g. at least twice) and whether counts are done daily or weekly. The system then will generate count sheets randomly either daily or weekly for part numbers that need to be counted. Also, when parts are counted, the system uses a date and time stamp on the part number to check for part movement between the time that the part is counted to when the variance report is run. This enables part counts to be done during normal trading hours.

8) Unfortunately for me, I have done way too many parts-to-accounting reconciliations. It is heart wrenching to tell a dealer that the parts on the shelves do not match what he has on his financial statement. There are unlimited reasons why this can happen, but I have found that the most common is that the accounts payable clerk has posted invoices to the wrong account (i.e.: marketing pamphlets posted to parts inventory, etc). How does the DXE logic help in this area?

[00127] When parts are released into inventory, they are always released at Replacement Cost (cost according to the factory parts tape). If there are additional charges on an invoice for example freight, these charges have to be allocated to the appropriate account. Because the Parts Inventory account is a "controlled"
account, it is not possible to manually post anything to that account. Control accounts are all inventory accounts (parts vehicles and service WIP), all Receivable accounts and all Payable account (including sales tax). Entries can only hit the control accounts when they are made in the corresponding sub-ledger (buy a part, sell a part, count a part or buy a vehicle, sell a vehicle, do recon on a vehicle). This is the reason why in Darwin, excepting for a program bug, the parts inventory (or any other inventory or control account) will never be out of balance with the GL. If someone was stealing parts, the inventory would not to match the physical count and would alert management that remedial action and an adjustment was required.

Network Interface Module 202

[00128] The module 202 can be part of the network connection interface 300 (see Figure 2) of the device 101 operating the framework 112. The module 202 can communicate synchronously or asynchronously with the device 101 of the consumer 104 over the network 11 to receive or otherwise structure the search requests 105. For example, the module 202 could be a Web service as a software system designed to support interoperable machine-to-machine interaction over the network 11, between the framework 112 and the consumers 104. The Web service of the framework 112, as facilitated by the module 202 can be configured as a series of Web APIs that can be accessed over the network 11 by the consumer 104 and then executed on the framework 112 hosting the requested services.

[00129] The Web service definition can encompass many different systems, such as clients and servers that communicate using XML messages that follow the SOAP
standard. Also, the module 202 could provide a machine-readable description of the operations supported by the framework 112 written in the Web Services Description Language (WSDL).

[00130] For example, the module 202 provides to the consumer 104 an electronic interface for access to the vehicle definitions 107, as searched in the database 110 through any subset of the vehicle details via the search parameters. For example, the electronic interface can be a Web portal offering a structured vehicle search engine, i.e.
the consumers 104 via their browser access the contents of the electronic database 110 over the network 11 via the framework 112 that hosts the vehicle search engine. For example, the consumers 104 could search vehicle "for sale" information in the database110 to find the lowest advertised new vehicle prices in various markets across the country. The electronic interface can present predefined search parameter selections (e.g. vehicle classifications as selections via suitable user interface control elements) as product and/or vendor centric (e.g. vehicle and dealership centric input).
Therefore, instead of the consumer 104 typing a vehicle of vendor name in the search engine search string (e.g. a vehicle or dealership name), the consumer 104 can chose a name from a list element that is updated regularly. It is recognised that the selections can pertain to the classifications that were assigned to the vehicle definitions 107 via a classification module.

[00131] Examples of user interface control elements of the interface can include such as but not limited to a dropdown list that is similar to a list box, which allows the consumer 104 to choose one or more values from the list. When the dropdown list is inactive it displays a single value. When activated, the dropdown list displays (drops down) a list of values (e.g. classifications), from which the consumer 104 may select.
When the consumer 104 selects a new value the control element reverts to its inactive state, displaying the selected value. The control elements can include, for example, a combo box having an editable entry portion of the list. The navigation field of a web browser is an example of a combo box. A further example of the control elements is a list box or tabs that provide for the selection of one or more classifications at a time by the consumer 104. A further type of example control element is a Pop-up/down menu, whereby pop-ups are used to select a single classification from a list while pop-downs are used to issue commands (e.g. customized search terms) or in cases where multiple classifications can be selected. In any event, it is recognised that the control elements can be used by the consumer 104 to formulate at least some of the search parameters of the search request 105, for example.

[00132] The module 202 can include receipt and transmit sub-modules can be part of the network connection interface module 202, in accordance with the parameters of the search request 105 as well as the generated search results 106, as desired.

[00133] It is recognised that the above described module 202 can also be used for access by the consumer 104 to parts and/or service information made available to the framework 112 via the dealers 114 (e.g. from their inventory 115 and coupled DMSs).
As well, I is recognised that the module 202 can be used to provide for access with dealer staff and the Darwin enabled DMS features that are for example, part of the dealer DMS and/or are hosted remote to the dealer (e.g. via the framework 112).
Computing Devices 101

[00134] Referring to Figures 1 and 2, each of the above-described components of the system 10, i.e. the consumer 104, the framework 112, the dealers 114 can be implemented on one or more respective computing device(s) 101. The devices 101 in general can include a network connection interface 300, such as a network interface card or a modem, coupled via connection 318 to a device infrastructure 304.
The connection interface 300 is connectable during operation of the devices 101 to the network 11 (e.g. an intranet and/or an extranet such as the Internet), which enables the devices 101 to communicate with each other as appropriate. The network 11 can support the communication of the search request 105 and the corresponding search results 106 between the components of the system 10.

[00135] Referring again to Figure 2, the devices 101 can also have a user interface 302, coupled to the device infrastructure 304 by connection 322, to interact with a user (e.g. dealer 114, consumer 104, framework 112 administrator, etc.). For example, the consumer 104 to view and interact with the electronic interface supplied by the interface module 202 uses the user interface 302 of the device 101. The user interface 302 can include one or more user input devices such as but not limited to a QWERTY keyboard, a keypad, a trackwheel, a stylus, a mouse, a microphone and the user output device such as an LCD screen display and/or a speaker. If the screen is touch sensitive, then the display can also be used as the user input device as controlled by the device infrastructure 304. For example, the user interface 302 for the devices 101 used by the consumers 104 can be configured to interact with a web browser (e.g.
applications 307) to formulate the search requests 105 as well as process the received search results 106 (e.g. review the various details of the products offered for sale). For the devices 101 used by the framework 112, the user interfaces 302 can be used by a framework 112 administrator to monitor (e.g. manually or automated through software -e.g. applications 307) the classification of the product definitions 107 and associated update information 109, as well as for the dealer staff to interact with the Darwin enabled features of the dealer DMS.

[00136] Referring again to Figure 2, operation of the devices 101 is facilitated by the device infrastructure 304. The device infrastructure 304 includes one or more computer processors 308 and can include an associated memory 110,115 (e.g. a random access memory). The computer processor 308 facilitates performance of the device 101 configured for the intended task through operation of the network interface 300, the user interface 302 and other application programs/hardware 307 of the device 101 by executing task related instructions. These task related instructions can be provided by an operating system, and/or software applications 307 located in the memory 110,115, and/or by operability that is configured into the electronic/digital circuitry of the processor(s) 308 designed to perform the specific task(s).
Further, it is recognized that the device infrastructure 304 can include a computer readable storage medium 312 coupled to the processor 308 for providing instructions to the processor 308 and/or to load/update client applications 307. The computer readable medium 312 can include hardware and/or software such as, by way of example only, magnetic disks, magnetic tape, optically readable medium such as CD/DVD ROMS, and memory cards.
In each case, the computer readable medium 212 may take the form of a small disk, floppy diskette, cassette, hard disk drive, solid-state memory card, or RAM
provided in the memory module 110,115. It should be noted that the above listed example computer readable mediums 312 can be used either alone or in combination. The device memory 110,115 and/or computer readable medium 312 can be used to store the registration information of the information sources 114,116, such that registration information is used in processing of the product information 108 submitted from the information sources 114,116 to the framework 112.

[00137] Further, it is recognized that the computing devices 101 can include the executable applications 307 comprising code or machine readable instructions for implementing predetermined functions/operations including those of an operating system, a web browser, the framework 112 for example. The processor 308 as used herein is a configured device and/or set of machine-readable instructions for performing operations as described by example above. As used herein, the processor 308 may comprise any one or combination of, hardware, firmware, and/or software. The processor 308 acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information with respect to an output device. The processor 308 may use or comprise the capabilities of a controller or microprocessor, for example.
Accordingly, any of the functionality of the framework 112 and/or Darwin enabled DMS
may be implemented in hardware, software or a combination of both.
Accordingly, the use of a processor 308 as a device and/or as a set of machine-readable instructions is hereafter referred to generically as a processor/module for sake of simplicity. Further, it is recognised that the framework 112 can include one or more of the computing devices 101 (comprising hardware and/or software) for implementing the above described functionality, or subset thereof, of the components of the system 10 as desired.

[00138] It will be understood that the computing devices 101 of the consumers may be, for example, personal computers, personal digital assistants, and mobile phones. Server computing devices 101 can be configured for the framework 112 and the dealers 114 as desired. Further, it is recognised that each server computing device 101, although depicted as a single computer system, may be implemented as a network of computer processors, as desired.

Claims