Patent ID: 12211079

DETAILED DESCRIPTION OF THE INVENTION

FIG.1is a high-level diagram showing an embodiment of a system10for handling recycled part information in accordance with principles of the present invention, illustrating the components that handle recycled part information and the flow of part information through the system. In one embodiment, the illustrated systems are connected and communicate with an XMPP (extensible Messaging and Presence Protocol) instant messaging infrastructure, supported by instant message clusters. For the purposes of simplicity and clarity the XMPP servers (for example, 10 IM clusters embracing 60 or more servers) are considered a background infrastructure available for all services and not independently illustrated inFIG.1. In alternative embodiments of the invention the messaging infrastructure connecting the systems described herein could be other than XMPP instant messaging, e.g., intercommunication could use email, small message service (SMS aka text messaging), social networking (e.g., Twitter) or any other communications platform/medium. As used herein “instant messaging” and related terms such as “broadcast” and “message” should be understood to refer to any platform that supports message passing not limited to the particular embodiment disclosed herein.

At the core of the system is a search database12, which contains a database of recycled parts compiled from disparate auto recycler part inventory management systems (IMSs) such as IMS14. As is known in the art, the search database12is compiled on a regular, e.g., nightly basis, by the operation of an upload utility15which gathers a full or incremental image of the database of parts in IMS14and delivers this database image to an upload server in a server farm16. This activity is performed nightly for numerous disparate IMS's across a wide geographical area, each using an appropriate upload utility15to gather the requisite data in a form appropriate for that IMS. Data is gathered by upload servers16which, among other functions, harmonizes the collected data to a standard format (including without limitation compiling information from vehicle records which contain part information that may be relevant in the locating, verification, and/or procurement of parts). The data is then assembled by a collector server18which aggregates part tables built from uploaded data and loads the data into the search database. Notably, the tables in the search database can include several elements of information not found in the original source data from the disparate IMS platforms; for example, delivery time prediction information can be compiled into the database to enable searches to be performed with a delivery time criterion; this functionality is elaborated extensively in the above-referenced and incorporated US patent application of the assignee.

Parts and inventory entries logged into search database12are presented to users as search results via one of several interfaces, including, for example, a web server22hosting a web site such as the assignee's public web site car-part.com, assignee's subscription web site “Car-Part Pro”, and/or individual recycler websites using inventory results provided by the assignee. Additional venues where search results may be presented to users include parts provider inventory and/or point of sale systems, estimating, or repair shop management systems24, third party systems including claims work flow systems which are loaded with or access recycled part inventory data from the search database12, typically via access to a web server, for the purpose of estimating vehicle repairs, managing vehicle repairs, coordinating the sale, brokering or delivery of parts, managing insurance claims relating to vehicle repairs, and other functions. These various applications work in conjunction with customer information (such as log-in data, search preferences/filters, or subscription, contact and payment information) stored in a customer database21.

The present disclosure is directed to the implementation of a real time part (RTP) verification protocol that runs in parallel with the regular/nightly upload of part data by the systems described above, to overcome the latency (nightly build/load) in the search database12that is described above. This protocol is implemented through an RTP server30which links (directly or indirectly) to additional servers at part supplier locations, as well as instant messaging clients at potential buyer and seller locations (used to display verification information), as will be described in greater detail below.

Specifically, the RTP Server30connects via an HTTP or HTTPS global link interface to web server20to receive a request for part verification. This request may be in response to an explicit user action, e.g., the user may be presented with a button to request verification of current availability of a part, or an executable script or program may run which verifies current availability of parts upon user activity such as adding a part to an estimate, adding a part to a repair order, inclusion of a part in a third party system such as a claims workflow, movement of parts to a virtual shopping cart or the initiation of checkout of such a cart. Alternatively, or in addition, verification could be automatically performed for parts that are likely to be purchased, for example for the first n results in a search performed by a professional buyer, where for example n=8 or n=20. The RTP server passes instructions46to the part supplier's IMS14(or software that operates on behalf of the IMS), using the verification iCPM platform32as a pass-through entity which maintains the active connection to the IMS or surrogate software. The instructions46indicate that a verification needs to be performed and include all relevant fields.

The verification result, or a failure to verify notification, flows back from IMS (or software that operates on behalf of the IMS)14to instant messaging platform32, and then to RTP server30, which delivers that verification or failure notice over the HTTP/HTTPS channel to the web server20so that it may be presented to the user via the browser22or management system24that originated the request.

Further, in the illustrated embodiment, after a verification event, the RTP server initiates a broadcast protocol in connection with a broadcast server34to provide audit and follow-up information to the involved part seller and part purchaser. Finally, the broadcast server forwards this information to the potential buyer's iCPM client36(for example, to a shop or insurance appraiser) and/or to the seller's iCPM client(s)38(for example, to a recycler's sales people).

As noted above, a number of brokering relationships may be formed such that parts from a given supplier are available directly and/or through brokers. In that case, part verification as described above is done with the part supplier's IMS14, not the part broker, since the part supplier has the accurate and current information on the part. However, in the case where a potential part buyer has selected a brokered part (typically because of a relationship between the potential buyer and broker that simplifies the potential buyer's logistics) when the verification result is broadcast as described above, it is delivered to the sales staff of the part broker, rather than the staff of the part supplier, so that the broker can fulfill the traditional relationship of brokering the part and handling for the potential buyer any part quality or delivery variances that caused a verification failure.

Turning now toFIG.2, a more detailed description can be provided of the data and control flow involved in a real time verification in accordance with the disclosed particular embodiment of the invention.FIG.2illustrates the components and systems ofFIG.1which are involved in a real time verification, but for the purpose of clarity arranged in a process flow arrangement rather than a geographical or system topography arrangement. The data flow events are labeled with reference numerals to facilitate the following discussion.

A customer can initiate RTP verification from search results displayed by web server20on a web browser22, through an integrated system24, or through an instant messaging client such as iCPM client36/38. The former is initiated from a search result, which is obtained, e.g., when a customer performs a manual part search through their web browser22, obtaining search results. Alternatively, search results from web server20can be viewed through an integration interface in an estimating/repair/work flow system24of the kind used to estimate repair of a damaged vehicle or manage the vehicle repair process. In either case, on the search results, a part verification link (in the form of a button) is written to the page for each part record. When the customer activates this link, a part verification is initiated by a verification message41. Verification could also occur automatically in response to user activity such as adding a part to an estimate or a repair order, selecting a part for inclusion into a third-party system, movement of a part into a cart, initiation of checkout, or the like, or could be performed automatically, for example, for some search results such as the first n. In a responsive communication42, the search web server then sends a verification request to the RTP server, including key information: part GUID (globally unique ID), checksum, checksum version, broker ID, and supplier ID. Search details are also included, as well as some other identifier fields, as will be elaborated below with respect to the global part link specification in Table I attached to this specification.

A verification request can also “re-verify” a previous part request; for example, a “re-verify” request42′ could be generated by an instant message application at, for example, a recycler or repair shop, to follow up on a verification result previously broadcast to that shop. This functionality is provided to permit the re-affirmation of verified parts which appear in an audit trail generated by the process about to be described (e.g., through a “verify” tab in an instant message application which shows previously completed part verification results). The verification request42or42′, whether generated from part search results or through a re-verify request, uses a universal part identifier to identify the part of interest, having the data fields elaborated below and in Table I. Re-verify requests differ from verify requests in that they contain a transaction reference to previous verification(s) to enable the re-verify to be related to its predecessor verification(s).

Responding to a verification request42or re-verify request42′, the RTP server30first reconfirms the verified part in the search database12via a database query43. As the customer search could have been performed substantially before the verification is initiated, the RTP server contacts the part database with query43to make sure the part being verified still exists in the search database. The query response44will either confirm the part and part details, or indicate the part is no longer in the database. If the part does not exist, the RTP server immediately returns that the part is unavailable, skipping all other steps. In the case that the request42or42′ identifies a valid part to verify, the responsive message44to the RTP server communicates additional part information from the search database that enables complete verification; the specific data exchange is elaborated below and in Tables IIA and IIB.

After receipt of search database information, the RTP server also retrieves additional information about the recycler and the customer (end user) from the customer database21using a message exchange45; the specific data is elaborated in the RTP to IMS (via iCPM) field specification in Table IIA attached to this specification. This information includes the verification and broadcast JIDs (instant messaging user IDs) required for the remainder of the process. Verification JID(s) indicate which messaging accounts are used to do the verification. Broadcast JID(s) are used to identify the user messaging accounts which receive verification results in the broadcast steps.

RTP server30further communicates, via an instant messaging protocol such as XMPP, with a recycler's verification-enabled instant messaging platform32(also known as an instant Car-Part messaging platform or iCPM) that is in communication with the recycler's IMS14. Alternatively, the recycler's iCPM communicates with software that operates on behalf of the IMS (e.g., for those IMS systems that do not natively support real time part verification functions such as checksum computation). In the case where alternative software is used in conjunction with the IMS, messaging will communicate with that software using the same principles as discussed herein referencing direct communication with the IMS. Specifically, the RTP server30passes instructions46required to perform the verification. These instructions are delivered to the IMS/surrogate software via iCPM-iCPM acts as a pass-through entity, passing on the information as an instruction46bto the IMS/surrogate software14. iCPM32maintains a persistent connection to the centralized servers, which provides access to software within the recycler facility. Additionally, iCPM32manages the interface and persistent connection to the IMS/surrogate software14, which is unique to the type of IMS. Once contacted by the RTP server30, iCPM32then performs a query46bat the recycler IMS/surrogate software14to collect information needed to verify the continued availability of the identified part, without changes as compared to the presentation of the part in the search database12(e.g., no price, condition or location changes). The key part verification fields supplied to the IMS/surrogate software14are GUID and checksum version. In one example of the iCPM to IMS connection, applicable to the assignee's “Checkmate” Inventory Management System, the instant message platform32leverages JDBC to make a stored procedure call at the recycler IMS14, which performs a query against the IMS database to gather information which is used to calculate the checksum of the part being verified.

The IMS/surrogate software14finds the part specified by the GUID and uses the designated checksum version to compute a checksum, and returns the checksum to iCPM platform32, in a message47(see Table IIB attached to this specification). iCPM again acts as a pass-through entity, managing the connection to the RTP server, and forwards the result message47bon to the RTP server30.

The RTP server30uses the information to make a determination on the verification, with one of four possible results:The part is available (part is available and nothing critical, such as price, has changed)The part is unavailableThe part is “probably” available (part is available but something potentially important has changed), orThe verification service is unavailable (the part verification failed to complete successfully).

The RTP server30returns this result in a result message48or48′. In the case of an initial verification, the result48is delivered to the web server20, which then returns the results back to the end user (at a browser or estimating/repair/work flow/inventory system) in a derivative results report48b. Alternatively, in the case of a re-verify, such as one issued from an iCPM instant messenger platform38at a recycler or shop, the RTP server returns a results report48′ back to the issuing iCPM platform38. Re-verify responses48′ differ from initial verify responses48in that re-verify responses48′ contain a transaction reference to previous verification(s) to enable the re-verify to be related to its predecessor verification(s).

In addition to the above reporting steps, the RTP server30sends two requests49-1,49-2to the Broadcast server34, to broadcast the verification results out to the iCPM platforms at the selling recycler, and to the iCPM platforms at the potential buyer, e.g., the requesting repair shop. Specifically, using a RTP broadcast API, which in this particular embodiment is implemented with HTTP, a broadcast message regarding the (successful or failed) verification is delivered to a Broadcast Server34, along with the appropriate instant messaging identities to be notified at the prospective part purchaser and part seller. The broadcast server issues a corresponding instant message with the details of the part search and part verification to the one or more instant messaging accounts at the prospective part buyer and seller, and in appropriate cases to a support representative (in the event of a failed verification). The potential part buyer thus has information in the form of an audit trail of parts that have been verified and the context in which this was done, for later follow-up in the event a part is not purchased. Also, the part seller staff has information on specific inquiries about that seller's listed parts and an indication of the context of the inquiry to enable follow-up in the event a part is not sold. Most particularly, this information permits seller staff to proactively attempt to make a sale to the potential buyer, potentially through actions such as communication of a decreased price or increase in the available service level (such as faster delivery time), or informing the potential buyer that, despite a discouraging verification result such as “probably available” or “not available”, the seller can possibly still provide an acceptable part and level of service. The seller can also react to failures indicating technical faults in the verification process to get service restored. (Particular types of verification results are described in greater detail below.) Broadcast messages to the potential buyer and part seller also differ in the event the verification was a re-verify in that re-verify broadcasts contain a transaction reference to previous verification(s) to enable the re-verify to be related to its predecessor verification(s).

The same set of fields is used for broadcasts49-1and49-2; however, different fields are populated in the two broadcasts, as some information is not displayed to the seller or potential buyer (such as seller/buyer contact information) and thus not used in broadcast49-1or49-2, respectively. After the broadcast server34sends the verification results49-1and49-2to the corresponding seller's iCPM client(s)38and potential buyer's iCPM client36, these display the verification results for audit and follow-up, e.g., in a verification tab within iCPM. In the event the verification was initiated from iCPM as a re-verify, the existing verification entry is updated to reflect the updated status and indicates multiple verifications have occurred. A part can be re-verified numerous times, if necessary.

The communications described above utilize a construct known as a Universal Part Link (UPL) to securely transfer part, search, and search result information from one application to another. The primary source of data in a part link construct is a search result, but a part link can also be created from any source that has the required information. The objectives of the UPL are:Neatly and securely pack the relevant data necessary for transfer to another applicationStore any information specific to the search result itself-such as the delivery time of the part, which can change from one minute to the next, or the total part price, which is a complex aggregate, resulting from the combination of many prices, such as part price, delivery fee, warranty fee, broker fee, etc. These price components, which are not visible on the search result, are also stored. This data is stored in the link displayed so that another application call (such as a part verification) does not generate new values, which may not match the values presented to the userStore relevant information about the part, the potential buyer, the supplier, and the broker-such as the part GUID, the potential buyer exchange rate, the supplier ID, and the broker ID, respectivelyStore information about the search parameters, that may be valuable to present elsewhere (for example, when a part is verified, the seller broadcast includes the search parameters, so that the seller is aware of the needs of the potential buyer)

Table I attached hereto provides the field specifications for the UPL.

A second construct used in the communications described above is known as the RTP-IMS (via iCPM) messaging construct. The fields of this construct are shown in the attached Table II; the key fields are a GUID and a checksum version. These fields are passed to an iCPM platform as an arguments string used to make a call to the IMS. The call into the IMS, in the case of a Checkmate IMS, forms a query from the GUID, and returns the checksum for the part with the supplied GUID, using the appropriate checksum logic based on the checksum version supplied with the message. Additional fields may also be included in future implementations such as the quantity of parts (when multiple identical parts are inventoried together with a quantity field).

A final construct used in communication is known as the RTP-iCPM broadcast message, which is delivered as message49-1or49-2to broadcast verification results. These broadcasts include the verification result (yes, no, probably, service unavailable), potential buyer and seller contact information (if appropriate), as well as information about the part, the search results (such as number of delivery days displayed at the time of the search), and in the case of the seller, the search parameters, the price breakdown, and brokering information. Note that “service unavailable” messages are also broadcast to support representatives. Support broadcasts only occur when there is a service failure, not in the expected case of a successful verification.

Version control/management is a significant challenge in the verification system described herein. There are two aspects in which version incompatibility may arise: interface versions and checksum versions.

Issues with interface versions arise from the fact that the RTP server, iCPM platforms and the IMS/surrogate software may all be upgraded independently of each other. The iCPM and IMS/surrogate software upgrade processes are heavyweight processes and thus are completed over a period of time, rather that instantaneously. This means there will not be version consistency across the enterprise of computing hardware/systems in which the present invention operates. Notably, interface versions, not the software versions, are the focus of the concern with the independent platforms, but because interface updates occur with software updates, the software version on a platform can be used as a proxy for the interface version.

As to checksum versions, the information and logic used to calculate the checksum of a part changes over time. A checksum for a part will be different for different versions of the checksum logic, even if all the part information is the same. With multiple sources of data-IMS databases of parts, and the central database of parts—it is critical to track and manage the checksum version used to compute the checksum of parts so that those checksums are compatible.

The following steps explain, at a high level, how these different versions are managed.

Periodically (e.g., every 20 seconds), each iCPM32coupled to an IMS or surrogate software checks its connection by requesting the IMS/surrogate software14version. Less periodically (e.g., every 1 hour), each IMS-connected iCPM checks in to an iCPM web services server and provides the IMS/surrogate software version as well as the iCPM version. In response to this communication, the iCPM web services server updates the customer database21with the iCPM and IMS version information.

When a verification request is initiated, RTP server30obtains the iCPM32and IMS/surrogate software14version information from the customer database21as part of message exchange45(FIG.2). Before constructing the message46it will send to iCPM, the RTP server must consider the RTP version, the iCPM version, and the IMS/surrogate software version, to identify the minimum interface version supported by all three. There is also a minimum version level that is still allowed to be used by the system as a whole-older versions may not be allowed for any number of reasons (security, lack of required functionality, etc.). Assuming all software/interface versions are sufficient to complete a request, the RTP server30will construct a verification message46, including the interface version to be used. The RTP server keeps multiple sets of logic, to allow it to construct older request formats, to handle cases when iCPM platform32or the IMS14are not up to date with the RTP server. The RTP server also supplies, in message46, the checksum version that was used to compute the checksum at the time it was uploaded to the search database12.

The iCPM platform32also maintains multiple sets of logic, to allow it to handle older request formats, and uses the interface version supplied by the RTP server30to identify which set of logic is needed to make the correct procedure call, to pass the information to the IMS/surrogate software14. The information is then appropriately sent to the IMS/surrogate software.

The IMS/surrogate software14also maintains multiple sets of communication logic (for communication to/from iCPM platform32), to allow it to handle older request formats. Additionally, the IMS/surrogate software must maintain multiple versions of checksum computation logic, as the version of the interface used for communication and the version of the checksum logic can change independently. The IMS/surrogate software computes the checksum of the part, using the supplied checksum version, and then uses the appropriate version of the interface to return the information back to iCPM platform32in message47.

Finally, iCPM32uses the appropriate version of the interface to return the information in message47bback to the RTP server30.

If the iCPM platform32or the IMS/surrogate software14is too dated to complete a procedure call, or if there is a version mismatch resulting from the slight delays in the propagation of version information, the RTP server30delivers the version mismatch information through iCPM, per an instant message, to the appropriate support technician so that the problem can be resolved. Additionally, the RTP server logs this information back to the customer database21.

For illustration purposes, here are some examples of scenarios and how they are handled by this version control logic:

The RTP server30, iCPM32and the IMS/surrogate software14are all on the same version, in which new checksum logic was implemented. The IMS/surrogate software was just updated today, so the part in the search database was uploaded yesterday using the old checksum logic. Even though all parties can all support the latest checksum logic, the RTP server has to pass down part information with a checksum compatible with the checksum version in the customer database21. The IMS/surrogate software maintains the old checksum logic, and therefore is able to compute the checksum for the part using the old logic, allowing the system to determine whether anything has changed on the part.

The RTP server30is updated with a new version of the RTP software, which includes an updated version of the interface with a useful new field. iCPM32and the IMS/surrogate software14are still on the old version of the interface. When an RTP verification comes through, constructing a message with the new field would result in an error when iCPM processes the message. However, RTP checks the database, determines iCPM and the IMS/surrogate software are on the older version, RTP constructs the message with the older version, allowing for a successful verification.

The RTP server30has been updated with the new version of RTP software for some time. Additionally, the roll out of the new iCPM32version has been completed. However, one recycler has not updated its IMS/surrogate software14in a year. The new version of RTP server and iCPM software includes a new interface version, which has a vital new field added. If the RTP server were to construct a message on the current version, it would fail when iCPM tried to communicate with the IMS/surrogate software. If the RTP server were to construct a message using the older version, the call could succeed, but vital information, which is required for a quality user experience in the current environment, would be missing. When the RTP server checks the customer database21and determines the IMS/surrogate software does not meet the minimum standards, RTP informs a Car-Part support technician of the problem, allowing them to contact the customer to fix the problem, which allows full RTP functionality to be restored relatively quickly.

FIG.3illustrates the four tables which contain numerous entries for each recycler and part type to enable the identification of a delivery time for a particular part to a particular buyer given a particular search time.FIGS.5-66illustrate the process for gathering and storing data for these four tables. Regarding these four tables:

SLA_SEARCH_DELIVERY provides information on which particular buyer types are provided delivery of which part types, and under which conditions (e.g., minimum order requirement, delivery charges). This table includes multiple entries for each supplier or broker of parts, each entry stating, for one combination of buyer type, zip code, and delivery zone, whether the zone is fully or only partially eligible for delivery, whether there is a minimum order size, and whether there is a delivery charge.

SLA_SEARCH_DELIVERY_PARTS provides information on which types of parts a broker will deliver to each delivery zone. It includes multiple entries for each broker of parts, each entry stating, for one combination of buyer type, zone, and part code, whether there is conditional delivery of the item if sufficient other items are also being delivered.

SLA_SEARCH_PARTS provides information on the time it takes to get a part to a delivery truck from its location in the recycler yard, which may be, e.g., in the warehouse, unbolted but with the vehicle, or still on the vehicle. There is an entry for each combination of source, supplier and broker, part type, and location category (e.g., on vehicle, unbolted with vehicle, or warehouse), each entry identifying the total time for the part to be placed on the delivery truck departing the part source. Notably, the location categories supported include the three location codes that are standard in the industry ([Y] ard, [U] nbolted, and [W] arehouse), and also include a fourth category [dis] a.k.a. [V] which is supported by inventory systems provided by the assignee of this application. The [dis] or [V] code is used to designate parts (such as engine subassemblies) that are impractical to dismantle except in the context of dismantling the rest of the car or a large subassembly of the car. The distinction between [V] and [Y], where both are supported, is that [Y] parts do not implicate dismantling the entire vehicle or a larger portion of the vehicle, which is typically a much longer process than just disassembling a part off the vehicle.

SLA_SEARCH_TIME provides information on the total delivery days required to deliver a part given the search day and time and the time the part will take to get to the truck at the source's loading dock, accounting for travel distance, delivery days, location of delivery and the like. There is an entry for each combination of a part source, supplier and broker, buyer type and delivery zone, location category and time to truck, and search day and time; the entry identifies the number of days it takes to deliver the part given this combination of factors.

FIG.3illustrates that the process of computing Total Delivery Days for a part that is found in a part search, begins by the use of the SLA_SEARCH_DELIVERY table 1 to identify a delivery zone for the particular buyer, buyer zip code and seller. If there are conditions applicable to this Zone, such as delivery only to a part of the zone (partial delivery), a minimum order requirement, or a delivery charge, this is reported with the search result.

The seller's Zone for the delivery is fed to the SLA_SEARCH_DELIVERY_PARTS table 2 along with the part code, broker identifier, and buyer type, to determine if delivery is available or only conditionally available for that zone. Parts which do not have available delivery will not be displayed, and parts with conditional delivery may only be displayed if desired by the user.

The SLA_SEARCH_PARTS table 3 is used to determine the seller's time to place the part onto a delivery truck, based upon the location of the part, the part type, and based upon the seller's identity, and whether there are brokers or intermediaries involved in the transaction as identified by Part Source ID, Supplier ID and Broker ID. The output of this process is the total time to truck (TTT) for the part. TTT is computed on an hour and minute basis using the parameters of work days, times etc. provided by the part source. TTT is fed, along with the sellers Zone for the delivery, to the SLA_SEARCH_TIME table 4, along with the time of the search and part, seller and buyer information, to identify the total delivery days for the part, which is displayed to the buyer. The SLA_SEARCH_PARTS table answers the question whether, given the time to get the part to a truck, what day it will make it on the delivery truck, and thus what day it will come off that truck or a subsequent truck (after one or more transfers) when it arrives at the buyer's location. Normally, the buyer seeks only a commitment as the day of delivery and not time of day, however, in another and more detailed embodiment of the invention, the time of day of delivery could be identified by collecting details of the routing of delivery trucks.

One or more examples are provided below to illustrate the use(s) of the entries in these tables. For example, a shop may be looking for an engine from a recycler directly (no brokering). Assume the following broker/supplier/part source information:1001 Foreign Auto Salvage is the Broker, Supplier, and Part SourceBusiness Hours: 9:00 a.m.-5:00 p.m.Dismantle Days: Monday-Friday (for all categories)Zip code: 41001 configured for delivery in Green zone for buyer types “Shop” and “Insurance”Delivers to Green Zone same day if part is on loading dock by 12:30 p.m.Delivery to Green Zone delivers Monday-FridayDelivery charge to Green Zone is $0.00 delivery fee but had a minimum order of $75.00Delivers Engines to Green ZoneWarehouse parts have a 1 hour lead timeEngines in the warehouse have a 1 hour pull time

An engine in inventory is being searched by a buyer, has a price of $200.00, and is in the Warehouse. In this example, the following are the relevant table entries:

SLA_SEARCH_DELIVERY (there would be more entries for 1001, one for each buyer type, zip code, and zone they have configured):

BrokerBuyerZipMinimumIDTypeCodeZonePartialCostOrder1001Shop41001GreenNo$0.00$75.00

SLA_SEARCH_DELIVERY_PARTS (there would be more records for 1001, one for each buyer type, zone, part code they have configured.)

BuyerBroker IDTypeZonePart CodeConditional1001ShopGreenEngineNo

SLA_SEARCH_PARTS (there would be more records for 1001, one for each part code and location category they have configured)

Part SourceSupplierIDIDBroker IDPart CodeLOC_CATTTT100110011001EngineWarehouse2

SLA_SEARCH_TIME (there would be more records for 1001, one for each buyer type, zone, location category, time to truck, search day of the week, and search time slot)

SearchSearchBuyerSearchTimeTimeIDTypeZoneLOC_CATTTTDayStartEndTotal1001ShopGreenWarehouse2Sunday12:00 am11:59 pm11001ShopGreenWarehouse2Monday12:00 am10:30 am01001ShopGreenWarehouse2Monday10:31 am11:59 pm11001ShopGreenWarehouse2Tuesday12:00 am10:30 am01001ShopGreenWarehouse2Tuesday10:31 am11:59 pm11001ShopGreenWarehouse2Wednesday12:00 am10:30 am01001ShopGreenWarehouse2Wednesday10:31 am11:59 pm11001ShopGreenWarehouse2Thursday12:00 am10:30 am01001ShopGreenWarehouse2Thursday10:31 am11:59 pm11001ShopGreenWarehouse2Friday12:00 am10:30 am01001ShopGreenWarehouse2Friday10:31 am11:59 pm31001ShopGreenWarehouse2Saturday12:00 am11:59 pm2

In a first example, the buyer type may be a shop and may have a zip code of 41001. System information may indicate a day of search of Tuesday and a time of search of 11:07 a.m. The buyer is a Shop searching for an engine to be delivered to zip code 41001 on Tuesday at 11:07 a.m. The seller has an engine in the Warehouse and delivers to zip code 41001 the same day (Green Zone with Shop buyer type). The seller has a 2-hour time to truck and can deliver parts the same day if they make it to the loading dock by 12:30 p.m. The part will take 2 hours to get to the loading dock from the point of search. Since the search happens at 11:07 a.m., the part will be on the loading dock at 1:07 p.m. This misses the 12:30 p.m. time needed to be at the loading dock to make the truck that day, so the part will be delivered the next delivery day, which is Wednesday, and the buyer will receive it Wednesday by end of day. This is 1 delivery day. The part costs $200.00, which exceeds the $75.00 minimum charge and qualifies for delivery.

In a second example, assume the same information for the buyer and seller as indicated above, but with different system information, resulting in a different delivery time. For example, the system information may indicate that the day of search is Saturday and the time of search is 3:30 p.m. This is the same search as Example 1, but on Saturday at 3:30 p.m. The recycler does not work on Saturday, so the part could be at the loading dock 2 hours after the start of business (Monday, 9:00 a.m.); therefore, the part could be ready by 11:00 a.m. Monday, which makes the 12:30 p.m. time needed to be at the loading dock in order to make the truck that day. With 0 delivery days configured (part arrives same day it is loaded on the truck), this search (or the same search any time on Saturday) will result delivery by the end of day Monday, which is 2 delivery days.

The tables shown inFIG.3are created by an initialization process, which includes:

Summarizing of general delivery preferences of a broker (collected by the process shown inFIGS.5-66) to create SLA_SEARCH_DELIVERY table 1.

Summarizing part-specific preferences of a broker (collected by the process shown inFIGS.5-66) to create SLA_SEARCH_DELIVERY_PARTS table 2.

Summarizing the part source's dismantling process, work hours and other internal timing (collected by the process shown inFIGS.5-66) to create SLA_SEARCH_PARTS table 3.

Computing threshold times of arrival at the part source's truck or subsequent delivery trucks, at which a delivery day can be gained or lost, which is required for determining each entry of the SLA_SEARCH_TIME table 4. The process for this part of the initialization is set forth in pseudo code as shown below:define function performDismantlingStep-performs the dismantling step of the delivery processinputs:time ToTruck (time it takes, in hours of work required, to get a part on the truck—this is the sum of load/dismantle time and lead time)searchDay (day the search was performed)searchMinute (time of day the search was performed)businessHours (contains values for each day-2 values, start of day, and end of day)daysWorked (contains true/false values for each day, and for each category field, based on which days the recycler has a person available to dismantle/load parts for each category)categoryField (the categoryField of the part being used)outputs:loadDay (day the part is loaded on the truck)loadMinute (time of day that the part is loaded on the truck)logic:define CWM (day, category) (this is an intermediate result (“category work minutes”) that contains the minutes that can be worked per day, by category)for i in [0 to 3], for j in [0 to 6]if daysWorked (day=j, category=i) is trueCWM (day=j, category=i)=businessHours (day=j, time=endOfDay)-businessHours (day=j, time=startOfDay)elseCMW (day=j, category=i)=0endfordefine tempJobTime=timeTo Truck (this is an intermediate result used to track the time left on the job)//this is simply a normalization—so that in the main logic below, we can always assume we are starting at the beginning of the dayif (searchMinute>businessHours(day=searchDay % 7, time=startOfDay) && CWM (day=searchDay % 7, category=categoryField))if (searchMinute>businessHours (day=searchDay % 7, time=endOfDay))tempJobTime=tempJobTime+CWM (day=searchDay %7, category=categoryField)elsetempJobTime=tempJobTime+ (searchMinute-businessHours (day=searchDay % 7, time=startOfDay))define loadDay, loadMinutedefine tempCurDay=searchDay//this is the core logic, it steps through day by day taking work hours off the total, until we have enough hours left to finishwhile (tempJobTime>0)if (tempJobTime>CWM (day=tempCurDay % 7, category=categoryField))tempJob Time=tempJobTime-CWM (day=tempCurDay % 7, category=categoryField)tempCurDay++;elseloadDay=tempCurDay;loadMinute=businessHours (day=tempCurDay %7, time=startOfDay)+tempJobTimetempJobTime=0;endifendwhilereturn (loadDay, loadMinute)//end of function performDismantlingStepdefine function performDeliveryStep-performs one delivery step of the delivery process inputs:startDay (day the delivery step started, i.e. when the part was ready to load on a truck)startMinute (time of day the delivery step started, i.e. when the part was ready to load on a truck)deliveryZone, consisting of:deliveryDays (the number of delivery days it takes to deliver to the zone)deliverableDays (true/false values representing the days of the week the recycler is willing to deliver to this zone)cutoffTime (the time in minutes at which point you must have a part ready to load, to get it on the truck that day)arrivalTime (used for brokering only, this is the time in minutes that the truck is unloaded at the brokers location. arrivalTime will be null in a non broker zone)outputs:deliveryDay (day the part arrived at the location)deliveryTime (time of day the part arrived at the location)logic:if (arrivalTime!=null && arrivalTime<cutoffTime && deliveryDays==0)deliveryDays=1define totalDays=0if (startMinute>cutoffTime && deliverableDays (day=startDay %7)==true)totalDays=totalDays+1;totalDays=totalDays+deliveryDays;define currentDay=startDay//step through day by day, counting each delivery day against the total number of delivery days until they matchwhile (totalDays!=0)if (deliverableDays(day=currentDay % 7)==true)totalDays=totalDays-1currentDay++endwhileif (arrivalTime=null)return (currentDay, 24*60-1)elsereturn (currentDay, arrivalTime)//end of function performDeliveryStepdefine function computeDeliveryTime (computes the total delivery time, in days, for a given case)inputs:businessHoursData (contains all the data on business hours for every recycler)daysWorkedData (contains all the data on days worked for every recycler)consumerZoneData (contains all the end user delivery zone data, has every zone for every buyer type defined by each recycler)brokerZoneData (contains all the broker delivery zones, has delivery data for every supplier and broker combination)seachDay (day of the search)searchMinute (time of day of the search)partSourceID (ID number of the entity who is the part source)supplierID (ID number of the entity supplying the part)brokerID (ID number of the entity who is serving the customer, i.e. the recycler whose name is on the part)buyer Type (the type of the buyer, e.g. body shop)deliveryZone (the end user delivery zone that contains the zip code of the buyer)categoryField (the category field of the part)time ToTruck (time it takes, in hours of work required, to get a part on the truck—this is the sum of load/dismantle time and lead time)outputs:businessDays (the number of business days that it will take for the part to be delivered) logic:define loadDay, loadMinute(loadDay, loadMinute)=perform DismantlingStep (timeToTruck, searchDay, searchMinute, businessHourData (recycler=partSourceID), daysWorkedData (reycler=partSourceID), categoryField)//dismantling step is the same regardless of is this delivery includes a brokering relationship or not. however, if the part is being brokered, two delivery steps must be performed instead of onedefine deliveryDay, deliveryMinuteif (partSourceID==supplierID==brokerID)(deliveryDay, deliveryMinute)=performDeliveryStep (loadDay, loadMinute, consumerZoneData (broker=brokerID, buyer=buyerType, zone=zone))else if (partSourceID==supplierID && supplierID!=brokerID)(deliveryDay, deliveryMinute)=performDeliveryStep (loadDay, loadMinute, brokerZoneData (supplier=supplierID, broker=brokerID))(deliveryDay, deliveryMinute)=performDeliveryStep (loadDay, loadMinute, consumerZoneData (broker=brokerID, buyer=buyerType, zone=zone))else if (partSourceID!=supplierID && supplierID==brokerID)(deliveryDay, deliveryMinute)=performDeliveryStep (loadDay, loadMinute, brokerZoneData (supplier=partSourceID, broker=brokerID))(deliveryDay, deliveryMinute)=performDeliveryStep (loadDay, loadMinute, consumerZoneData (broker=brokerID, buyer=buyerType, zone=zone))else if (partSourceID!=supplierID && supplierID=brokerID)(deliveryDay, deliveryMinute)=performDeliveryStep (loadDay, loadMinute, brokerZoneData (supplier=partSourceID, broker=supplierID))(deliveryDay, deliveryMinute)=performDeliveryStep (loadDay, loadMinute, brokerZoneData (supplier=supplierID, broker=brokerID))(deliveryDay, deliveryMinute)=performDeliveryStep (loadDay, loadMinute, consumerZoneData (broker=brokerID, buyer=buyerType, zone=zone))endif//now, we need to get the number of business days it takes for delivery, which we display on the search results. current, we just know the start day and the delivery day//here, we normalize for weekendsdefine businessDays=0if (search Day is Saturday)businessDays=1search Day=searchDay+2endifif (searchDay is Sunday)businessDays=1search Day=searchDay+1endif//finally, we step through day by day, counting business days, until we get to the delivery daywhile (searchDay<deliveryDay)if (search Day is Monday through Friday)businessDays=businessDays+1search Day=searchDay+1endwhilereturn businessDays//end function computeDelivery Timedefine function createOutputTable (creates the table output for a single case. to create the complete table used by the search script, this function must be called for every valid supplier, broker, buyerType, deliveryZone, categoryField, and timeToTruck combination) inputs:partSourceID (ID number of the entity who is the part source)supplierID (ID number of the entity supplying the part)brokerID (ID number of the entity who is serving the customer, i.e. the recycler whose name is on the part)buyer Type (the type of the buyer, e.g. body shop)deliveryZone (the end user delivery zone that contains the zip code of the buyer)categoryField (the category field of the part)time ToTruck (time it takes, in hours of work required, to get a part on the truck—this is the sum of load/dismantle time and lead time)table (the table to write result data to)outputs: none (results are written to table)data written to table consistent of the inputs, plus:search Day (the day of the search that this record is applicable for)rangeStart (the start of the time range on the day of the search, that this record is applicable for)rangeEnd (the end of the time range on the day of the search, that this record is applicable for)deliveryDays (the number of business days it will take to deliver the part)logic://we essentially will try every minute of every day to find out the delivery days displayed for any search time, and collapse the same values into ranges, so the DB table is not too large to work with//we also use a speedup to skip an hour ahead, to make this calculation faster. its true that at any point in the day, the number of delivery days it takes a minute later (until the end of the day), can only increase, or stay the same.//therefore, we know that if at some point in time later in the day, there are still the same # of delivery days, then there are the same # of delivery days for all minutes in betweenfor (searchDay in [Sunday through Saturday])define rangeStart=0, rangeEnd=0, attemptedSpeedup=define deliveryDays=computeDeliveryTime (businessHoursData, daysWorkedData, consumerZoneData, brokerZoneData, searchDay, rangeStart, partSourceID, supplierID, brokerID, buyerType, deliveryZone, categoryField, timeToTruck)for (searchMinute in [0 to 24*60−1])define tempDays=computeDeliveryTime (businessHoursData, daysWorkedData, consumerZoneData, brokerZoneData, searchDay, searchMinute, partSourceID, supplierID, brokerID, buyerType, deliveryZone, categoryField, timeToTruck)if (tempDays!=deliveryDays)rangeEnd=searchMinute−1table.writeRow (partSourceID, supplierID, brokerID, buyerType, deliveryZone, categoryField, timeToTruck, searchDay, rangeStart, rangeEnd, deliveryDays)deliveryDays=tempDaysrangeStart=searchMinuteendifelse if (attemptedSpeedup<=searchMinute)attemptedSpeedup=min (searchMinute+60, 24*60−1)tempDays=computeDelivery Time (businessHoursData, daysWorkedData, consumerZoneData, brokerZoneData, searchDay, attemptedSpeedup, partSourceID, supplierID, brokerID, buyerType, deliveryZone, categoryField, timeToTruck)if (deliveryDays=tempDays)searchMinute=attemptedSpeedupendifendforrangeEnd=24*60−1table.writeRow (partSourceID, supplierID, brokerID, buyerType, deliveryZone, categoryField, timeToTruck, searchDay, rangeStart, rangeEnd, deliveryDays)endfor//end function createOutputTable

FIG.4illustrates several sample scenarios of part supply to two repair shops (Shop56and Shop58), each involving different criteria/filters to select parts.

The following definitions are helpful to understanding the diagram inFIG.4:

A broker (60,64) is an entity that actually sells a part to a buyer (Shop56and/or Shop58);

A supplier (62,66) provides a part to a broker (in circumstances where a broker sells a part out of its own physical inventory, a broker is also a supplier (See Broker60)); and

A part source supplies a part to a supplier (in circumstances where a broker sells a part out of its own physical inventory, a broker is also a part source (See Broker60), and in circumstances where a supplier is providing a part out of its own physical inventory, a supplier is also a part source (See Supplier62)).

SCENARIO 1: Parts Sold from a Broker's Own Physical Inventory.

When Broker60is selling parts to Shop68out of its own physical inventory, Broker60is filling the roles of broker, supplier, and part source inFIG.4. Broker60has one or more parts such as 24 in its own physical inventory that meet the requirements of Shop58. While these parts meet the requirements designated by Shop58, they may have different delivery times because they are at different stages of Broker60's dismantling and inventorying workflow. Also, because each part is unique and potentially has a different condition, each part that meets Buyer58's criteria is displayed. At different time frames, some parts may be in Broker60's warehouse, some parts may have already been unbolted from the vehicle but are stored in the vehicle, some parts may still be attached to the vehicle and require some unbolting work before they can be delivered to Shop58, and other parts may still be on the vehicle but require extensive production work, e.g. the whole vehicle to be dismantled before that part is available to deliver to Shop58. Accordingly, the stages that a part is at in Broker60's dismantling and inventorying workflow, together with certain of Broker60's business practices (e.g., the days and hours which Broker60performs dismantling activities, the days and hours which Broker60retrieves parts stored in vehicles, and Broker60's lead times to retrieve and/or dismantle parts and vehicles, days and hours which Broker60delivers parts to various portions of its delivery area, and cut off times), all impact the delivery times for the part in Broker60's physical inventory.

SCENARIO 2: Parts Brokered from a Supplier's Physical Inventory. Broker60has a brokering relationship with Supplier66so that Broker60can sell parts to Shop58that come from Supplier62's physical inventory, such as part52. As to that transaction, Broker60is filling the role of broker and Supplier66is filling the role of supplier and part source. Because of its brokering relationship with Supplier66, Broker60may be able to sell to Shop58one or more parts from Supplier66's physical inventory that meet the requirements of Shop58. The amount of time that it will take Broker60to deliver a part obtained from Supplier66's physical inventory to Shop58will be impacted by (1) the factors that affect Supplier66's delivery time to Broker60; (2) the factors that Broker60determines are different when Supplier66is delivering parts to Broker60instead of Supplier66's own buyers, such as lead and priority times for dismantling parts and vehicles, and delivery days and arrival times (for example, Broker60may not be open to accept deliveries on Saturday even though Supplier66delivers to brokers on Saturday); and (3) the factors that affect Broker60's delivery time to Shop58after it receives the part from Supplier66. The factors that affect Supplier66's delivery time to Broker60include those discussed in Scenario 1 above (e.g., the stage of the part in Supplier66's dismantling and inventory workflow, days and hours which Supplier66performs dismantling activities, days and hours which Supplier66retrieves parts stored in vehicles, Supplier66's lead times, days and hours which Supplier66delivers parts to various portions of its broker delivery area, and cut-off times). The factors that affect Broker60's delivery time to Shop58after it receives the part from Supplier66include the day and hour of the arrival time of a part from Supplier66, Broker60's handling times, days and hours which Broker60delivers parts to various portions of its delivery area, cut-off times, and whether Broker60is delivering other parts to Shop60along with a part that it obtained from Supplier66.

SCENARIO 3: Parts Brokered from Multi-Tier Supply Chain. When Broker60has a brokering relationship with Supplier66and Broker60is selling parts to Shop58that Supplier66obtains from Part Source68's physical inventory (Inventory50), Broker60is filling the role of broker, Supplier66is filling the role of supplier, and Part Source68is filling the role of part source. Because of its brokering relationship with Supplier66, Broker60may be able to sell to Shop58one or more parts from Supplier66's “inventory” that meet the requirements of Shop58; however, Supplier66will need to obtain the part(s) from Part Source68before it can deliver the part(s) to Broker60(because the part(s) is/are not in Supplier66's physical inventory). The amount of time that it will take Broker60to deliver a part obtained from Supplier66to Shop58will be impacted by (1) the factors that affect Part Source68's delivery time to Supplier66, (2) the factors that affect Supplier66's delivery time to Broker60after it receives the part from Part Source68; (3) the factors that Broker60determines are different when Supplier66is delivering parts to Broker60instead of Supplier66's own buyers such as lead and priority times for dismantling parts and vehicles, and delivery days and arrival times; and (4) the factors that affect Broker60's delivery time to Shop58after it receives the part from Supplier66. The factors that affect Part Source68's delivery time to Supplier66include those discussed in Scenario 1 above (e.g., the stage of the part in Part Source68's dismantling and/or inventory workflow, days and hours which Part Source68performs dismantling activities, days and hours which Part Source68retrieves parts stored in vehicles, Part Source68's lead times, days and hours which Part Source68delivers parts to various portions of its delivery area, and cut off times). The factors that affect Supplier66's delivery time to Broker60after it receives the part from Part Source68include the day and hour of the arrival time of a part from Part Source68, Supplier66's handling times, days and hours which Supplier66delivers parts to various portions of its delivery area, delivery cut-off times, and whether Supplier66is delivering other parts to Broker60along with a part that it obtained from Part Source68. The factors that affect Broker60's delivery time to Shop58after it receives the part from Supplier66include the day and hour of the arrival time of a part from Supplier66, Broker60's handling times, days and hours which Broker60delivers parts to various portions of its delivery area, delivery cut-off times, and whether Broker60is delivering other parts to Shop58along with a part that it obtained from Supplier66. Many calculations regarding delivery times are made in real time because they change based on the time of day that the buyer (Shop58) performs the search and/or purchases a part.

NOTE REGARDING SCENARIOS 1, 2, AND 3: When Shop58conducts a search for parts, Broker60may have part search results that come through one or more of the supply channels described in Scenarios 1, 2, and 3 above (some of the parts may come from Broker60's own physical inventory (SCENARIO 1), some of the parts may come from the physical inventory of a supplier with which Broker60maintains a brokering relationship (SCENARIO 2), and some of the parts may come through a multi-tier supplier chain (SCENARIO 3)). Each of such parts may reflect different delivery times from Broker60to Shop58based on the factors discussed in Scenarios 1, 2, and 3 above.

SCENARIO 4: Brokered Parts Available through Multiple Brokers. Often, suppliers will maintain brokering relationships with several brokers. In the diagram above, both Broker60and Broker64broker Supplier66's parts. Depending on the requirements that Shop58designates, it may see:(1) part search results from only one of the brokers which broker parts from Supplier66; e.g., Shop58only sees Supplier62's parts as brokered through Broker60because Shop58's designated requirements caused Broker64's parts to be excluded from the search results;(2) part search results from more than one broker which broker parts from Supplier66; e.g., because both brokers met the requirements designated by Shop58, Shop58would see Supplier66's parts as brokered through Broker60and Broker64—the same part may show up multiple times in the part search results (potentially with different delivery times and/or differences in other services such as warranties)—once displayed under Broker60's name and once displayed under Broker64's name; or(3) only see the best brokered part designated as a search requirements, in which case it will only see parts of a supplier as brokered by one broker determined based on priorities established by the part source of the subject part; e.g., even though Supplier66's part as brokered through either Broker60or Broker64would meet the requirements designated by Shop58, Shop58only sees the part as brokered by Broker64in the part search results because Supplier66has Broker64listed higher in its priority list of brokering partners. Broker priority lets Supplier66to designate the order of priority of its broker partners that will show its brokered parts after the brokers have met all other buyer requirements (such as warranty levels, delivery times, etc.). Supplier-based priorities are applied as a way to reduce multiple entries for the same unique part to one entry after all other buyer designated requirements are applied and met. Note, however, that Buyer criteria could result in one of the presentations of the part being filtered from the results, in which case, the buyer would see (1) above, i.e. results from only one of the brokers.

The present invention encompasses broad aspects which are capable of implementation in a number of forms and embodiments. All embodiments contemplated hereunder that achieve the benefits of the invention therefore have not been shown in complete detail. For example, principles of the present invention may be applied to supply chain management outside of the context of vehicle parts, salvage yards, part warehouses, and the like. Other supply chains facing similar challenges can also take advantage of the inventive concepts. Examples may include collectible items, artwork, and components used for custom manufacturing, among others. Other embodiments may therefore be developed without departing from the spirit of the invention.