Validation approach for auditing a vendor-based transaction

Information

  • Patent Grant
  • 8396811
  • Patent Number
    8,396,811
  • Date Filed
    Friday, March 17, 2000
    24 years ago
  • Date Issued
    Tuesday, March 12, 2013
    11 years ago
Abstract
A computer processing system for auditing transaction information between vendors and service providers servicing a third party's needs. The system also includes those transactions involving shippers and carriers. The system is particularly suited to efficiently and automatically audit and effect payment of a transaction and to efficiently provide access to relevant transaction and subscription information. According to one example embodiment, the system includes a processor arrangement that helps vendors validate transactions between service providers and third party customers. In some cases the system is able to monitor transactions initiated by the service provider, for the benefit of the customer, committing the vendor to certain actions not readily known by vendor. However, this is acceptable if the service provider uses a service quotation generating system, provided by the vendor, that has pre-determined parameters that vendor is willing to be committed to in order to immediately secure the new subscriber.
Description
FIELD OF THE INVENTION

The present invention relates to a computer processing system for shipment transactions involving a shipper and a carrier or a vendor and service providers where the transaction involves services.


BACKGROUND OF THE INVENTION

Processing shipment transactions between a shipper and a carrier has been a manually intensive effort and has experienced little change. Generally, the shipment transaction process involves a goods transport path and a payment process path. The goods transport path typically starts when a carrier picks up the goods at the shipper's warehouse dock. The carrier receives a copy of a transaction document, sometimes referred to as a bill of lading (BOL), from the shipper. This type of transaction document includes information associated with the shipment transaction that is used by the shipper and carrier to track the shipment of goods. The carrier transports the goods to the receiver where the receiver signs a copy of the BOL to verify receipt of the goods. After the carrier has delivered the goods to the receiver, the carrier also submits the receiver's signed copy of the BOL to the carrier's headquarters.


At this point, records are generated that contain information about requested pick-up and delivery times, origin and destination, and type of load. The first problem in the process can occur when the carrier arrives to pick up the load. If the shipment is not ready or there are delays at the loading dock, accessorial charges may be imposed by the carrier. Because they are not part of the original BOL, the shipper may dispute these charges later, and this can cause payment delays down the line. Back at the loading dock, a second problem is created when manual changes are made on the BOL. Unfortunately, these changes rarely get recorded in the shipper's permanent electronic records causing a difference between the shipper's and the carrier's paperwork for the same load.


Now on the road, the driver needs to send the paperwork back to headquarters. Because the primary job of the driver is to get the shipment to its destination in a timely manner, paperwork can sometimes be delayed, and it may be days before the carrier headquarters receives a copy of the BOL.


The driver reaches the destination and delivers the shipment. At the point of delivery, the driver is supposed to provide notification of delivery. Again, this may or may not happen. When it does not, vital information is delayed or missing in the supply chain.


When the original and delivery copies of the BOL finally reach the clerk at the carrier's offices, the clerk sends out an invoice for the original shipment. A clerk at the shipper's office receives the invoice, often amid a pile of invoices for many carriers, and attempts to match the invoice with a copy of the original BOL. If a billing error is discovered, the clerk might send a check for a partial payment or simply hold the entire payment until the corrected invoice is provided. The carrier clerk receives this check and must then track down the original BOL and delivery copy to know why the check is for less than the total amount due. It is only after communicating with the shipper directly that the carrier finds out a mistake was made in the original paperwork. The carrier sends the shipper an amendment to the original invoice, and the shipping clerk must then organize and file all the paperwork together.


The payment process path starts when the carrier picks up the goods from the shipper. The carrier sends a copy of the BOL to the carrier's headquarters for processing. The carrier headquarters rates the BOL. Rating involves determining the shipment cost that takes into the account various shipment parameters such as the size, weight, type of material, and destination of the shipment. The carrier creates an invoice, sets up an accounts receivable, and sends the invoice to the shipper's accounts payable department. The shipper, either internally or via a third party, audits the invoice to ensure the final cost is proper.


One of the more burdensome aspects of the traditional process involves reaching agreement as to the final cost. If there is a dispute as to final cost, the shipper and carrier begin a burdensome and sometimes lengthy negotiation process in an attempt to settle the dispute. If the dispute is resolved, the shipper sets up an accounts payable for the transaction. The shipper will then send payment to the carrier and clear the accounts payable. The traditional process for paying the carrier and clearing the accounts payable involves several manually intensive steps. Upon receipt of payment, the carrier clears the accounts receivable. The traditional process for clearing an accounts receivable includes the carrier manually inputting final payment information into the accounts receivable system.


The traditional approach can lead to many disadvantages for a transaction between one shipper and one carrier. Typically, however, there are multiple carriers and shippers involved in multiple transactions, which makes the situation more complex, and that much more slow and inefficient. The process is manually intensive in that it relies on the hard copy of the BOL for proof of delivery and payment, resulting in a series of repetitive and time-consuming steps. Also, each BOL is often rated multiple times by multiple parties creating excessive redundancy.


Traditional shipment transaction systems are also highly susceptible to billing errors and fraud. For example, there is no connection between the delivery of goods and when the shipper is billed for delivery. This may result in double billing, no billing at all, or over-billing the shipper for freight delivery charges. Also, auditing error may occur which results in incorrect billing or payment. In addition, the carrier waits a disproportionately long time for payment while the invoice is being audited and/or disputed. For example, traditionally, a delivery takes about five days whereas payment takes about thirty days. This unnecessary delay adversely affects the carrier's working capital resources.


Additional costs arise as a result of the existing inefficiencies. Many of the costs are individually small, but very large in the aggregate. For example, the carrier incurs administrative costs including: the cost to create and deliver the initial invoice, costs of resolving billing disputes, costs of providing a signed copy of the BOL to the shipper, and costs of posting accounts receivable. The shipper incurs similar administrative costs.


Another disadvantage of traditional shipment transaction systems is that they have a tendency to strain relationships. Because carriers and shippers do not always have an effective way to communicate about the shipment, business partnerships can be strained when there are disputes. Continuous inaccuracies in either the shipment or invoice process cerate unnecessary tension along the entire supply chain for both shippers and carriers.


An additional disadvantage involves the inability to obtain immediate information regarding a shipment. Since the process is largely conducted manually, it is very difficult to track a shipment. To learn of the status of shipment or payment, there are various manual steps involved. For example, if the shipper wants to know if the carrier delivered the goods and if the payment has been made, the shipper must call the carrier and the appropriate financial institution.


There have been numerous attempts to improve the existing shipment and payment process. Some improvements have been made to each separate step of completing a shipment transaction, but the entire method remains relatively unchanged. For example, freight agents are used by shippers to schedule shipments and to process the invoice from the carrier. Also, third party service providers have taken over the role of managing the shipper's accounts payable department.


Another attempt to improve this burdensome transaction process involves the use of the Internet. Carriers have offered Internet access to their shipment information. Shippers access the carrier's Internet address and find out the immediate status of the shipment. A disadvantage of this system arises when, as in many applications, the shipper is using multiple carriers. In this typical situation, the shipper separately accesses the address of each carrier in order to find out the status of each shipment. This is unduly time-consuming.


Another disadvantage of traditional systems is that the shipper's reference number and the carrier's reference number are not compatible. The carrier maintains the shipment data, so the shipper accesses the data using the carrier's reference number rather than the shipper's reference number. The shipper and carrier track each shipment using multiple reference numbers.


These various attempts to improve the overall process have fallen short of providing a convenient and cost effective system to process a shipment transaction.


SUMMARY OF THE INVENTION

The present invention is directed to a shipment transaction system for processing transaction information related to goods shipped from a shipper by a carrier. According to one example implementation of the present invention, the system includes a processor arrangement that maintains shipper credit data for shippers and to process the transaction information in response to control data communicatively coupled between the processor arrangement and users of at least one type. The processor arrangement is linked with various users via a communications channel, and is programmed to receive control data from the users, to verify that the received control data is from an authorized source, and to evaluate the shipper credit data and the control data. In response, the processor arrangement determines whether to generate data that authorizes payment to the appropriate carrier(s).


According to another example implementation of the present invention, a shipment transaction system includes a processor arrangement programmed and configured to maintain shipper credit data of said one of a plurality of shippers, to process the transaction information in response to control data communicatively coupled between the processor arrangement and users of at least one type, and to automatically audit shipment transactions between shippers and carriers. The system further includes at least one communication channel communicatively linking the processor arrangement with the users of said at least one type, with the processor arrangement being further programmed to receive control data from the users, to verify that the received control data is from an authorized source, and to evaluate the shipper credit data and the control data and, in response, to determine whether to generate authorization data that authorizes payment to one of a plurality of carriers.


More specific implementations of one or both of the above systems involving the following. The processor arrangement permits authorized ones of the shippers and authorized ones of the carriers to review audit discrepancies using a communication channel communicatively coupled with the processor arrangement. The processor arrangement permit authorized ones of the shippers to approve payment to selected ones of the carriers without adversely impacting credit data of the authorized shippers, and permits authorized ones of the carriers to delay shipment for selected ones of the shippers without adversely impacting credit data of the authorized carriers.


In yet another embodiment, a shipment transaction system includes a processor arrangement programmed and configured to maintain shipper credit data of a shipper, to process the transaction information in response to control data communicatively coupled between the processor arrangement and users of at least one type, and to maintain a database of shippers and carriers, the database having a main parameter set for validating ones of the shippers and carriers that are qualified as users thereof and having respective data sets for the validated shippers and carriers indicating varying communication access levels for communicators of each respective validated shipper and carrier. At least one communication channel communicatively links the processor arrangement with the users of said at least one type, and the processor arrangement is audits shipment transactions and reports thereon to at least one of the validated shippers and carriers according to one of the varying communication access levels for communicators of the validated shipper and/or carrier.


Another more specific embodiment involve the above shipment transaction system with the processor arrangement further programmed and configured to audit shipment transactions and report thereon to at least one of the validated shippers and carriers according to different communication access levels, each being defined based on data provided by a respective one of the validated shippers and carriers. Further, the processor arrangement can be configured and arranged to permit and block access to shipment transaction information according to information stored in the database, and the database can include information defining payment authorization levels for communicators, wherein the processor arrangement permits approval for payment to carriers for shipment transactions according to the information defining payment authorization levels. As enhancements to this implementation, the information defining payment authorization levels for communicators in the database is defined by a specified type of user, and the information defining payment authorization levels for communicators is downloaded into the database from the user at a remote site.


According to one application, the present invention is directed to a transaction validation system for auditing transaction information related to services provided by one of a plurality of vendors and processed by one of a plurality of service providers. The system comprises a central processor arrangement programmed and configured to maintain data relating to an authorized profile list criterion that includes information about authorized users empowered to authorize payment by the vendor, and programmed and configured to process the transaction information by determining whether the transaction information satisfies the authorized profile list criterion, and using the authorized profile list criterion to generate information for auditing a transaction between one of a plurality of vendors and one of a plurality of service providers.


According to another application, the present invention is directed to a transaction validation system for auditing transaction information related to services provided by a vendor and a plurality of subvendors and processed by one of a plurality of subvendor controlled service providers. The system comprises a central processor arrangement, coupled to vendor and subvendor, programmed and configured to maintain data relating to an authorized profile list criterion that includes information about authorized users empowered to authorize payment by the vendor, and programmed and configured to process the transaction information by determining whether the transaction information satisfies the authorized profile list criterion, and using the authorized profile list criterion to generate information for auditing a transaction between the vendor and both of the plurality of subvendors and plurality of subvendor controlled service providers.


According to another application, the present invention is directed to a transaction validation system for auditing transaction information related to services provided by a vendor, the transaction information being generated by one of a plurality of service providers prior to processing by the vendor. The system comprises a central processor arrangement programmed and configured to maintain data relating to an authorized profile list criterion that includes information about authorized users empowered to authorize payment by the vendor to service provider, and programmed and configured to process the transaction information by determining whether the transaction information satisfies the authorized profile list criterion, and using the authorized profile list criterion to generate information for auditing a transaction between the vendor and one of a plurality of service providers.


Other aspects of the present invention are directed to methods for implementing the computer operations at a central control center, and to arrangements and methods for configuring and operating the coordination of the above-characterized shipment transaction system at the shipper's station and with respect to the carrier.


The above summary of the present invention is not intended to describe each illustrated embodiment, or every implementation, of the present invention. This is the purpose of the figures and of the detailed description that follows.





BRIEF DESCRIPTION OF THE DRAWINGS

Other aspects and advantages of the invention will become apparent upon reading the following detailed description and upon reference to the drawings in which:



FIG. 1 is a block diagram illustrating a specific embodiment that incorporates principles of the present invention;



FIG. 2 is a block diagram illustrating an example flowchart for programming the shipper processor 24 of FIG. 1 according to the present invention;



FIG. 2
a is a block diagram illustrating an example flowchart for programming the BOL rating engine 30 of FIG. 1 according to the present invention;



FIG. 3 is a block diagram illustrating an example flowchart for programming the data processing device 34 of FIG. 1 according to the present invention;



FIG. 4 is a block diagram illustrating an example flowchart for programming the central processor 40 of FIG. 1 manipulating the transaction information according to the present invention;



FIG. 5 is a block diagram illustrating an example flowchart for programming the issuing processor 45 of FIG. 1 authorizing a transaction according to the present invention;



FIG. 6 is a block diagram illustrating an example flowchart for programming the VRU unit 48 according to the present invention;



FIG. 7 is a block diagram illustrating an example flowchart for programming the central processor 40 of FIG. 1 generating a deposit file according to the present invention;



FIG. 8 is a block diagram illustrating an example flowchart for programming the paying processor 54 of FIG. 1 according to the present invention;



FIG. 9 is a block diagram illustrating an example flowchart for programming the issuing processor 45 of FIG. 1 crediting a transaction according to the present invention;



FIGS. 10A-10C are flow diagrams depicting an example operation of implementing ship transaction using the data processing flow addressed herein, according another aspect of the present invention;



FIG. 11 illustrates a communication path from an architectural perspective in which an array of computers and data routers are used in an example implementation of a system and method, according another aspect of the present invention;



FIG. 12 is a block diagram illustrating another embodiment of the invention directed to services that incorporates principles of the present invention;



FIG. 13 is a block diagram illustrating another embodiment directed to services and having a modified relationship between vendor and service provider; and;



FIG. 14 is a block diagram illustrating another embodiment having a modified relationship between a vendor, subvendors and service providers.





While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that it is not intended to limit the invention to the particular forms disclosed. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.


DETAILED DESCRIPTION

The present invention is generally applicable to a computer processing system for a shipment transaction involving a shipper and a carrier. The present invention has been found to be particularly advantageous for a system which efficiently automates the payment of a shipment transaction and efficiently provides access to shipment information.


The present invention is generally directed to a system that automates the shipment transaction process to thereby provide a convenient transaction protocol between the delivery, billing, and payment aspects of the transaction.


In one embodiment of the present invention, a computer arrangement includes a main CPU communicatively coupled via the Internet to provide around the clock access of shipment transaction data to authorized shippers, carriers, operators of the main CPU and, in more specific implementations, a separate financial institution and/or an auditor that is independent of the shippers, carriers, and CPU operators (and if applicable the separate financial institution). As is conventional with Internet communications, electronic notes can be included for supplemental communication with anyone in the shipment transaction chain. The main CPU maintains a database of all information relating to the shipments of the carriers and shippers, and the main CPU is used to analyze the shipments for auditing purposes, effect payments, to facilitate changes to the rating systems, and to facilitate resolution of audit discrepancies.


When a problem arises with a shipment, for example, the shipper (or the carrier if preferred) can change the rating via the Internet. Moreover, the shipper can instruct the main CPU to delay payment. Similarly, the carrier can inform the main CPU that a delivery of a shipment is being delayed due to its problems in receiving payments from the shipper.


By permitting the shipper access to analysis of the information database, the shipper can inquire of the main CPU data useful in assisting the shipper address issues, such as: which carrier has the best on-time delivery record, and which carrier has the most cost-effective service between two locations. Carriers can also use such data to addresses issues such as to identify the shipper that generates the most business in a target region. Further, all users of the system have the potential to access an abundance of historical data including, for example, approval history, and delivery and payment information.


As shown in FIG. 1, a shipper processor 24 initiates the shipment transaction by acting in conjunction with a BOL rating engine 30 to generate a rated BOL. The shipper processor sends the rated BOL to a data processing device 34 of a shipper access terminal 32. The data processing device 34 generates transaction information and sends the transaction information to a central processor 40. The central processor 40 identifies and centrally tracks the transaction information. A carrier processing device 46 receives proof of delivery information and sends this information to the central processor 40. The central processor 40 processes and stores all pertinent shipment information in a data storage unit 42 and allows immediate access to this information by the shipper 20, the carrier 22, and other authorized users. This reduces the administrative costs of the shipper 20 and the carrier 22. The central processor 40 interfaces with an improved payment system including an issuing institution 44 and a paying institution 52. An issuing processor 45 of the issuing institution 44, maintains a credit account for the shipper 20 and debits the shipper's account for the cost of the shipment. A paying processor 54 of the paying institution 52 tenders payment to the carrier 24.



FIG. 2 is a block diagram illustrating an example flowchart for programming the shipper processor 24 of FIG. 1 according to the present invention. According to this example flowchart, the shipper processor 24 receives 200 an input of relevant purchase order information for storage and processing using an adequate input device 202. Using a conventional desktop PC for example, a keyboard and mouse are adequate input devices. Using a more complex computer arrangement, a digital retrieving device, such as an information scanner, is used to offset some of the labor associated with this inputting effort.


The shipper processor 24 processes 204 the purchase order information including referencing inventory control and customer information systems to generate 206 shipment parameters. In a particular application, the shipment parameters include the identity of the carrier, identity of the receiver, the number of units, the weight of the shipment, the destination of the shipment, the date of shipment, and the estimated date of delivery. The shipper processor 24 is located at the shipper's premises so that the shipper processor 24 receives accurate information resulting in further reliability and efficiency of the system.


The shipper processor 24 electronically sends 208 the shipment parameters to the BOL rating engine 30. The transmission is accomplished conventionally. The BOL rating engine 30 of the illustrated embodiment of FIG. 1, is designed to suit the needs of the particular shipper, the type of goods shipped, and to provide an interface to the shipper processor 24. Conventionally, BOL rating engines, which are in use today, are implemented using a computer processing device such as a stand-alone personal computer, a personal computer connected to a network, or a conventional mainframe.



FIG. 2
a is a block diagram illustrating an example flowchart for programming the BOL Rating Engine 30 of FIG. 1 according to the present invention. The BOL rating engine receives 216 the shipment parameters and processes 218 the shipment parameters. The BOL Rating Engine 30 generates 220 a rated BOL. The BOL rating engine 30 is programmed to an agreed upon rate structure by the shipper 20 and carrier 22. As a result, the BOL rating engine 30 produces consistently rated BOL's. This has the further advantage that the shipper 20 and the carrier 22 do not have to audit the engine often. Existing systems require frequent auditing of the results of the BOL rating engine. With no post audit adjustments, the payment to the carrier 22 is definite.


The BOL rating engine 30 sends 222 the rated BOL to the shipper processor 24. In a particular application, the BOL rating engine 30 is included in the shipper processor 24. The shipper processor 24 performs the rating function of the BOL rating engine 30 so that there is no need to send the shipment parameters to an external BOL rating engine. The shipment parameters are processed and a rated BOL is generated solely by the shipper processor 24.


Another advantage associated with the process in which a rated BOL is produced is that only one BOL rating engine 30 is needed for the entire shipment transaction system. This saves duplicate efforts by the carrier 22 and ensures exact payment. A significant benefit of this illustrated embodiment of FIG. 1 is that the cost depicted on the BOL is the final cost of shipment. Therefore, the shipper 20 and carrier 22 will immediately know the final cost of shipment before the goods are delivered. The BOL rating engine 30 removes ambiguity from the shipment transaction payment process which significantly offsets time-consuming payment disputes.


The shipper processor 24 receives 212 the rated BOL and sends 214 the rated BOL to a shipper access terminal 32 located at the shipper's premises. In an alternative embodiment, the BOL rating engine 30 is located off the shipper's premises so that the shipper processor 24 can access the BOL rating engine 30 on an as-needed basis. One advantage is that one standardized BOL rating engine could be electronically linked to multiple shipper processors thereby reducing the cost to each individual shipper.



FIG. 3 is a block diagram illustrating an example flowchart for programming the data processing device 34 of FIG. 1 according to the present invention. The shipper access terminal 32 contains a data processing device 34 that receives 300 the rated BOL. The data processing device 34 validates 312 the rated BOL to ensure that the rated BOL contains data that is complete, error-free, and properly formatted. The data processing device 34 processes 312 the rated BOL and generates 316 a list of transaction information. The transaction information includes the information as seen in table 1 below. The columns in Table 1 represent the following: Data Element is the data that will reside in that particular element location, Length is the length of the data element; type is the type of data element which is either numeric or alpha-numeric, and Description simply describes the function of the data element if necessary.









TABLE 1







Transaction Information










Data Element
Length
Type
DESCRIPTION













Shipper ID
10
N
Record ID


Dock ID
3
N
Record ID


Bill of Lading #
15
AN
Record ID


Ship Date
8
N
Record ID, reporting


SCAC
4
A
Standard Carrier Alpha Code,





a national standardized





carrier identification code.


Carrier Vendor
10
N
Alternate index, allows


Number


Shipper 20 to specify its





vendor number for a given





carrier 22


Customer Number
10
N
Alternate index, allows





shipper 20 to specify it's





customer number for a





given receiver


Customer PO #
15
AN
Alternate index, reporting


Shipper Order #
15
AN
Alternate index


Vendor Order
15
AN
Reporting, alternate locator,


Number


carrier 22 PO associated





with shipment


Shipper Name
35
AN



Shipper Contact
20
A



Person





Shipper Phone #
15
AN



Origin Designator
10
AN



City
20
AN



State
2
A



ZIP Code
9
N



Division Code
2
AN



Reference B/L #1
15
AN
Consolidated Shipments


Reference B/L #2
15
AN
Consolidated Shipments


Reference B/L #3
15
AN
Consolidated Shipments


Bill of Lading Type
1
AN
Reporting


Shipment Mode
3
AN
Less than Truck Load(LTL),





Truck Load (TL), Rail (RAI),





AIR


Inbound, Outbound
1
AN



Flag





Prepaid, Collect Flag
1
AN



COD Flag
1
N



COD Amount
9.2
N



Shipment Value
9.2
N



Driver Name
20
AN



Trailer/Car #
15
AN



Trailer/CarSeal #
15
AN



Import, Export Flag
1
AN



# Stops
2
N



Stop Off Charges
7.2
N



Rated Freight Charges
9.2
N



Cube Dimensions
5
N



Shipment “as weight”
7.2
N



Accessorial Charges
7.2
N



Total Freight Chgs
9.2
N



Destination Name
25
AN



Destination City
20
AN



Destination State
2
A



Destination Zip Code
9
N



Destination Area
3
N



Code





Destination Prefix
3
N



Destination Phone
4
N



Mileage
5
N









The data processing device 34 sends the transaction information to a central processor 40. In one embodiment, the data processing device 34 is implemented using a conventional personal computer programmed to operate under the control of an operating system stored in the memory. These types of computer arrangements are not presently programmed to conventionally interface with a central processing center and a processing device located at a shipper's premises. One advantage of interfacing the central processor 40 with shipper access terminal 32 is that the shipper access terminal 32 can control the quantity, quality, and timing of information that is transmitted between the shipper processor 24 and the central processor 40. The access terminal 32 can also control the communication sessions between the shipper processor 24 and the central processor 40. The shipper access terminal 32 is designed so that the shipper 20 may directly access the transaction information. The shipper 20 will not be allowed to make changes to the transaction information, but is able to add additional information. This ensures the integrity of the transaction information. An additional advantage of the access terminal 32 is that the data processing device 34 can receive real-time information from the shipper processor 24 regarding the shipment transaction.


In an alternative embodiment, the shipper access terminal 32 is linked to a magnetic stripe card reader. The card reader accepts a card and transmits the data contained therein to the data processing device 34 of the shipper access terminal 32. The magnetic stripe card reader accepts an identification card from a user of the system. The identification card contains relevant user information. In an alternative application, the access terminal 32 is linked to a bar code reader that is designed to receive information from a bar code and input the bar code information into the data processing device 34. The bar code is printed on the BOL or on a carrier identification card.


The data processing device 34 sends 318 the transaction information to the central processor 40. The design of the central processor 40 is dictated by the desired speed, the number of users, and the amount of data to be processed.



FIG. 4 is a block diagram illustrating an example flowchart for programming the central processor 40 of FIG. 1 to manipulate the transaction information according to the present invention. The central processor 40 receives 402 the transaction information and performs 404 an integrity check on the incoming information to ensure that the information is correctly formatted and contains no errors. If the integrity check is unsuccessful, the transaction information is stored in a suspense file in a data storage unit 42. Once the error is corrected, the corrected transaction may be sent into the normal process flow. If the integrity check is successful, the central processor 40 retrieves 406 authorized user profile lists from the data storage unit 42.


The data storage unit 42 is essentially a memory unit that stores information relevant to the shipping transaction. The design of the data storage unit 42 is dictated by the amount of data needed to be stored.


The authorized user profile lists represent the users and combination of users that are authorized to use the system. Authorized user profile lists include a shipper profile list, a carrier profile list, a carrier/shipper profile list, and a shipper access terminal profile list. The profile lists provide the cross-reference between the payment ID (assigned by central processor 40), an account ID (assigned by an issuing processor 45), and a merchant number (assigned by a paying processor 54).


An authorized shipper profile list identifies information regarding the shipper and the shipment as can be seen below in Table 2.









TABLE 2







Shipper Profile










DATA ELEMENT
WIDTH
TYPE
DESCRIPTION





Shipper ID
10 
N
Uniquely identifies a legal





entity using a single BOL





system, assigned by the CP 40.


Account ID
16 
N
Account # assigned to shipper





20 by issuing processor 54.


Shipper Name
32 
A/N



Shipper Address 1
32 
A/N
Headquarters Address


Shipper Address 2
32 
A/N



Shipper City
28 
A/N



Shipper
3
A/N



State/Province





Shipper Country
3
A/N



Shipper Contact
32 
A/N



Shipper Phone
10 
N



Open Date
8
N
Supplied by CP 40 when





record is built.





YYYYMMDD format


Date of First Activity
8
N
Automatically supplied by





CP 40 when first BOL





record is received by CP 40 -





YYYYMMDD format


Date of Last Activity
8
N
Automatically updated by





CP 40 every time a BOL





record is processed


Current Status
4
A
Valid values are OPEN, CLSD,





HOLD. Automatically updated





on effective date if effective





date was pre-entered or as





part of on-line transaction





when effective date is set to





today.


Current Status Date
8
N
Automatically updated by system





when current status field





is updated, YYYYMMDD





format


Pending Status
4
A
User will key status, valid





values are OPEN,





CLSD, HOLD


Effective Date
8
N
Default to today's date with





user ability to override to





a future date. YYYYMMDD





format


Last update date
8
N
Automatically stamped





by CP 40


Last update time
4
N
Automatically stamped





by CP 40. HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile by CP 40.









An authorized carrier profile list identifies information regarding the carrier 22 and the shipment transaction as can be seen below in table 3. Included in the carrier profile is a merchant number that a paying processor 54 assigns to the carrier 22. Each carrier 22 can have multiple merchant numbers if desired. This allows carrier flexibility to assign different merchant numbers for different regions or different shippers. This flexibility facilitates the carrier's business management process. It is not known of existing systems that provide such flexibility.









TABLE 3







Carrier Profile











DATA
DATA



COLUMN NAME
WIDTH
TYPE
DESCRIPTION





SCAC
4
A/N
4 character code that uniquely





identifiesa Carrier 22.


Merchant Number
10 
N
Paying processor 54 assigns





to each carrier.


Carrier 22 Name
32 
A/N
DBA name of Carrier HQ


Carrier Address 1
32 
A/N



Carrier Address 2
32 
A/N



Carrier City
28 
A/N



Carrier
3
A/N



State/Province





Carrier Country
3
A/N



Carrier Contact
32 
A/N
Name of primary contact





at Carrier HQ


Carrier Phone
10 
N
Phone number of primary





contact at Carrier HQ


Open Date
8
N
Automatically supplied by





CP 40 when record is





built. YYYYMMDD format


Date of First
8
N
Automatically supplied by


Activity


CP 40 when first BOL





record is received by system





on this Carrier 22 -





YYYYMMDD format


Date of Last Activity
8
N
Automatically updated by





system every time a BOL





record is processed for this





Carrier 22


Current Status
4
A
Valid values are OPEN,





CLSD, HOLD. Automatically





updated on effective date





if effective date was





pre-entered or as part of





on-line transaction when





effective date is set to today.


Current Status Date
8
N
Automatically updated by





CP 40 when current status





field is updated,





YYYYMMDD format


Pending Status
4
A
User will key status


Effective Date
8
N
Default to today's date with





user ability to override





to a future date.





YYYYMMDD format


Last update date
8
N
Automatically stamped





by CP 40


Last update time
4
N
Automatically stamped by





CP 40 HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile lists by CP 40









An authorized shipper/carrier profile list identifies information regarding valid shipper carrier combinations as can be seen below in table 4.









TABLE 4







Shipper/Carrier Profile











DATA
DATA



COLUMN NAME
WIDTH
TYPE
DESCRIPTION





Shipper ID
10 
N



Carrier SCAC
4
A/N



Merchant Number
10 
N
Assigned by Paying processor





54. If blank, use default





value from carrier profile.


Proof of Delivery
1
A
“Y” for POD to be required,


(POD)


“N” for POD not required


Type of POD
4
A
Identifies in what manner the





POD is to be received.


Auto close days
2
N
Number of days after which the





transaction will close and be





paid to the Carrier 22 regardless





of whether or not POD has





been posted.


Open Date
8
N
Automatically supplied by





CP 40 when record is built.





YYYYMMDD format


Date of First
8
N
Automatically supplied by


Activity


CP 40 when first BOL record





is received by system -





YYYYMMDD format


Date of Last
8
N
Automatically updated by


Activity


CP 40 every time a BOL





record is processed


Current Status
4
A
Valid values are OPEN, CLSD,





HOLD. Automatically updated





on effective date if effective





date was pre-entered or as part





of on-line transaction when





effective date is set to today.


Current Status Date
8
N
Automatically updated by





CP 40 when current status





field is updated, YYYYMMDD





format


Pending Status
4
A
User will key status


Effective Date
8
N
Default to today's date with





user ability to override





to a future date. YYYYMMDD





format


Last update date
8
N
Automatically stamped by CP 40


Last update time
4
N
Automatically stamped by





CP 40 HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile lists









An authorized shipper access terminal profile identifies the shipper 20 as well as the shipping dock. A shipper has a separate shipper access terminal profile for each dock. The central processor 40 assigns a different dock ID for each dock. The information included in the access point profile is listed below in table 5.









TABLE 5







Access Terminal Profile










COLUMN NAME
WIDTH
TYPE
DESCRIPTION





Shipper ID
10 
N
Uniquely identifies a legal





entity using a single





BOL system


Dock ID
3
N
Uniquely identifies a





particular physical dock





location with a shipper ID.


Account ID
16 
N
Issuing Processor 54 assigns.





Defaults from shipper profile,





can be overridden by shipper.


Dock Name
32 
A/N
DBA name of dock





originating BOL


Dock Address 1
32 
A/N
Street address of dock





originating BOL


Dock Address 2
32 
A/N



Dock City
28 
A/N



Dock State/Province
3
A/N



Dock Country
3
A/N



Dock Contact
32 
A/N



Dock Phone
10 
N
To be used for reporting against





completion transaction


Open Date
8
N
Automatically supplied by





CP 40 when record is





built. YYYYMMDD format


Date of First
8
N
Automatically supplied by


Activity


CP 40 when first BOL





record is received by system -





YYYYMMDD format


Date of Last
8
N
Automatically updated by


Activity


CP 40 every time a BOL





record is processed


Current Status
4
A
Automatically updated by





CP 40 on the effective date





if effective date was pre-entered





or as part of the on-line





transaction if the effective date





is changed to today. Valid





values are OPEN, CLSD, HOLD


Current Status Date
8
N
Automatically updated by





CP 40 when current





status field is updated,





YYYYMMDD format


Pending Status
4
A
User will key status


Effective Date
8
N
Default to today's date with





user ability to override to





a future date. YYYYMMDD





format


Last update date
8
N
Automatically stamped





by CP 40


Last update time
4
N
Automatically stamped by





CP 40 HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile lists









The central processor 40 authenticates 408 the transaction information by comparing elements of transaction information with the authorized user profile lists. The elements of the transaction information used for authentication include; the identity of the shipper, the identity of the shipper's dock, and the identity of the carrier. If the authentication is successful, the central processor 40 assigns 410 a payment identification number (payment ID) to the transaction information and stores 412 the transaction information in the data storage unit 42. The payment ID is a unique key for the transaction record which the central processor 40 uses to centrally track the transaction. The payment ID includes specific information regarding the shipment transaction including; the shipper identification number, the BOL number, and the shipping date. The advantage of the payment ID is that it allows the central processor 40 to more efficiently and accurately track the different actions occurring within the system. The payment ID can be referenced to the specific identification numbers that any of the users may assign. The payment ID is now considered “open”. Open is a term used to signify that the shipper 20 has transferred the goods to the carrier 22, and the carrier 22 has not yet completed the shipment.


If the authentication is unsuccessful, the central processor 40 stores 414 the invalid transaction in a suspense file in the data storage unit 42. When an invalid transaction is stored, a notification is sent which indicates that an error has occurred and is in need of further review and correction. Once the error is corrected, the corrected transaction may be sent into the normal process path.


The central processor 40 sends the authenticated transaction information, including the shipper identity and the cost of the shipment, to an issuing institution 44 for authorization. FIG. 5 is a block diagram illustrating an example flowchart for programming the issuing processor 45 of FIG. 1 to perform an authorization check according to the present invention. The issuing institution 44 contains an issuing processor 45. The issuing processor 45 maintains accounts for one or more shippers. Each account includes information regarding credit limits, open authorizations, unpaid balances, and the resulting open-to-buy. Open-to-buy measures the unused credit limit.


The issuing processor 45 receives 502 the authorization request from the central processor 40. The issuing processor 45 compares 504 the authorization request to the open-to-buy of the shipper and attempts to approve 506 the request. If the shipper 20 has enough open to buy, the issuing processor 45 approves the authorization request. The issuing processor 45 stores 507 the approved authorization request and decreases 508 the open-to-buy. The issuing processor 45 sends 510 the authorization approval to the central processor 40 and the central processor 40 updates the records in the data storage unit 42. If the authorization is successful, the payment ID is considered “authorized”. If the authorization is unsuccessful, the issuing processor 45 sends 512 an authorization decline to the central processor 40.


After the goods are delivered to a receiver, the payment ID must be “closed”. Closed refers to providing proof of delivery (POD) of the shipment in order to complete the shipment transaction. POD includes the identity of the shipper, the BOL number, the carrier invoice number, the delivery date and time, the person acknowledging receipt, and the condition of the shipment. A carrier processor 46 receives the POD and sends the information to the central processor 40.


In one embodiment, the carrier processor 46 is a conventional bar code reader. The bar code reader is used by the carrier 22 to read a bar code on the shipment. The bar code reader sends the POD information to the central processor 40.


In an alternative embodiment, the carrier processor 46 is a voice response unit 48 (VRU). FIG. 6 is a block diagram illustrating an example flowchart for programming the VRU 48 according one embodiment of the present invention. In this embodiment, the central processor 40 extracts an open payment ID from the data storage unit 42. The central processor 40 sends information relating to the open payment ID, including the BOL number and the shipper ID, to the VRU 48. The VRU 48 receives 602 the open BOL number.


A standard touch-tone telephone is used to access the VRU 48. While the location of the telephone is not critical, locating it at the receiver's premises promotes efficiency, convenience, and accuracy. It is convenient and efficient because the carrier 22 can call the VRU 48 at the exact time the shipment is delivered. It is accurate in that the phone number of the receiver, automatically captured by the VRU 48, will identify where and when the call was made.


The VRU 48 prompts 604 the carrier 22 for the shipper ID. The VRU 48 receives 606 the shipper ID and attempts to match 608 the entered shipper ID with an open shipper ID. If the shipper ID is matched, the VRU 48 prompts 610 the carrier 22 for the BOL number. The VRU 48 receives 612 the entered BOL number and attempts to match 614 the combination of the entered BOL number and shipper ID with an open BOL number and Shipper ID. If the BOL number and shipper ID combination is matched, the VRU 48 prompts 616 the carrier 22 for condition of shipment. The VRU 48 receives 618 the condition of shipment and sends 620 the POD information which includes BOL number, the shipper ID, and the condition of the shipment to the central processor 40.


If the VRU 48 cannot match either the shipper ID and the BOL number, the VRU 48 prompts 622 the carrier 22 to either try again or routes 624 the carrier 22 to customer service where the problem can be resolved.



FIG. 7 is a block diagram illustrating an example flowchart for programming the central processor 40 of FIG. 1 generating a deposit file according to the present invention. The central processor 40 receives 702 the matched BOL number, the shipper ID, and the condition of the shipment from the carrier processor 46. The central processor 40 validates 704 the incoming data to ensure that it is error free and properly formatted. The central processor 40 extracts 706 the open payment ID from the data storage unit 42. The central processor 40 authenticates 708 the matched BOL number with an open payment ID. If the BOL number and payment ID are authenticated, the payment ID is considered complete. The central processor stores 710 the completed transaction and corresponding payment ID in the data storage unit 42. If authentication is unsuccessful, the central processor 40 stores 712 the information in a suspense file where the problem can be manually resolved as discussed above.


A payment ID can be completed by the above manner or a payment ID can expire. A payment ID expires when a pre-programmed number of days have elapsed since the shipping date. This preprogrammed number of days is defined as auto close days in the data storage unit 42. A particular transaction is identified by the shipper and carrier to expire on a specific date, the effective date, whether or not the proof of delivery is received. On the effective date, the payment process begins. This has the advantage that the carrier 22 will be paid for every shipment carried. Payment to the carrier 22 is expedited if proof of delivery is received.


The central processor 40 periodically extracts 714 from the data storage unit 42 the transactions that are listed as “completed and authorized” or “expired and authorized.” The central processor 40 sorts and batches 716 the transactions by the merchant number. The central processor 40 generates 718 a deposit file 50 for those authorized transactions that are completed or expired and which have not been previously extracted. In a particular application, one deposit file 50 is created for all transactions completed by each carrier. The deposit file 50 is formatted so that it is compatible with the paying processor's 54 format. The deposit file 50 includes the payment ID, the account ID, the carrier identity, the BOL number, the destination city, the destination state, the destination zip code, and the cost of shipment. The cost of the shipment represents the amount that is owed by the shipper 20 and payable to the carrier 22.


The central processor 40 performs 720 a general integrity check on the deposit file 50. The integrity check includes: ensuring that the payment ID has been authorized, ensuring that the BOL is completed or expired, and ensuring that payment has not yet occurred for the particular payment ID.


If the central processor 40 validates the deposit file 50, the processor 40 sends 722 the deposit file 50 to a paying processor 54 of a paying institution 52. In a particular application, the deposit file 50 is conventionally sent via a telephone transmission. The paying institution has a paying processor 54 which processes financial information and maintains financial accounts for the carrier 22. The paying processor 54 is generally designed to process financial information. The paying institution 52 maintains one or more accounts for each carrier 22.



FIG. 8 is a block diagram illustrating an example flowchart for programming the paying processor 54 of FIG. 1 according to the present invention. The paying processor 54 receives 802 the deposit file 50 and sends 804 a confirmation message to the central processor 40 that the deposit file 50 was received.


The paying processor 54 validates 806 the incoming deposit file and generates 808 payment to the carrier 22. The paying processor 54 tenders 810 payment to the carrier 24 and sends 812 this information to the central processor 40 so that the central processor 40 can update the data storage unit 42. In a particular application, the paying processor 54 tenders payment by directly paying the carrier 22. In an alternative embodiment, the paying processor 54 sends the payment to the carrier's bank conventionally through the Federal Reserve's Automated Clearing House.


One advantage associated with the generation of payments to the carrier 22 is that the carrier 22 is paid relatively soon after the carrier 22 has completed the shipment. This provides the carrier 22 with improved cash flow and reduces the carrier's working capital requirements. Another advantage is that the carrier 22 does not have to audit or rate the payment that saves time and money. This streamlined approach reduces the carrier's administrative costs associated with processing a payment.


The paying processor 54 generates 814 a systems bill for the carrier 22. This systems bill represents the amount the carrier 22 owes for the service provided by the system of the present invention. The paying processor 54 sends 816 the systems bill to the carrier 22. The paying processor 54 sends 818 the systems bill information to the central processor 40 where the information is stored in the data storage unit 42. The paying processor 54 delivers 820 the paid shipment transactions to the issuing processor 45 of the issuing institution 44.


The issuing institution 44 maintains one or more accounts for the shipper 20 and extends and manages credit to the shipper 20. The issuing processor 45 maintains the amount paid to each carrier 22 on behalf of each shipper 20. FIG. 9 is a block diagram illustrating an example flowchart for programming the issuing processor 45 of FIG. 1 to credit a transaction according to the present invention. The issuing processor 45 receives 902 the paid transactions from the paying processor 54. The issuing processor 45 retrieves 904 the approved authorization list and compares 906 the authorization list with the paid transactions. The issuing processor 45 attempts to match 908 the paid transactions with an authorized transaction. If a match is made, no change is made to the open to buy. If a match is not made, the issuing processor 45 decreases 910 the open to buy.


The issuing processor 45 posts 912 the cost of shipment for all paid transactions to the shipper's account thereby increasing the balance due from the shipper 20. The issuing processor 45 periodically bills 914 the shipper 20 for the posted financial transactions paid on behalf of the shipper 20 and periodically receives 916 payment from the shipper 20. When the issuing processor 45 receives payment, the processor 45 posts payment to the shipper's account and increases 918 the open-to-buy.


The issuing processor 45 communicates with the central processor 40 and sends information regarding shipper 20 payment and billing. The central processor 40 updates the data storage unit 42 with this information.


In an alternative embodiment, the paying institution 52 is incorporated into the issuing institution 44. This results in one processor performing the functions of the issuing processor 45 and the paying processor 54.


A further advantage of the computer processing system for a shipment transaction involving a shipper and a carrier is that the data storage unit 42 and central processor 40 interface to store and provide value-laden information to the users of the system. The central processor 40 provides a security check for all information entering and leaving the data storage unit 42. The central processor edits incoming files and provides on-line alarms for duplicate files, stale dated files, out of balance files, and files with corrupt data. The central processor 40 maintains a suspense file in the data storage unit 42 where incoming invalid transaction information and unmatched proof of delivery information are stored. With a centrally located suspense file, the problem resolution process is more efficient.


The central processor 40 maintains data views and tables and stores this information in the data storage unit 42. The central processor 40 maintains a BOL Header Table for each BOL number that generally includes a summary of all information relating to that shipment transaction. This information is shown in the table 6 below. The source of the particular data element is indicated in column four of table 6.









TABLE 6







BOL Header Data Elements











Data Element
Length
Type
Source
Purpose














Shipper ID
10
N
CP 40
Record ID


Dock ID
3
N
CP 40
Record ID


Account ID
16
N
CP 40
Record ID; reporting


Bill of Lading #
15
AN
Shipper
Record ID


Ship Date
8
N
Shipper
Record ID, reporting


SCAC
4
A
Shipper
Alternate index, identifies






Carrier


Merchant #
10
N
CP 40
Alternate index, for CP 40






usage


Vendor #
10
N
Shipper
Alternate index, allows






Shipper to specify its






vendor number for a






given carrier


Customer Number
10
N
Shipper
Alternate index, allows






Shipper to specify it's






customer number for a






given receiver


Customer PO #
15
AN
Shipper
Alternate index, reporting


Shipper Order #
15
AN
Shipper
Alternative Index


Vendor Order
15
AN
Shipper
Reporting, alternate locator


Number






Shipper Name
35
AN
Shipper
Reporting


Shipper Contact
20
A
Shipper
Claims


Person






Shipper Phone #
15
AN
Shipper
Claims


Origin Designator
10
AN
Shipper
Reporting


City
20
AN
Shipper
Reporting


State
2
A
Shipper
Reporting


ZIP Code
9
N
Shipper
Reporting


Division Code
2
AN
Shipper
Reporting


Reference B/L #1
15
AN
Shipper
Consolidated Shipments


Reference B/L #2
15
AN
Shipper
Consolidated Shipments


Reference B/L #3
15
AN
Shipper
Consolidated Shipments


Bill of Lading Type
1
AN
Shipper
Reporting


Shipment Mode
3
AN
Shipper
LTL, TL, RAI, AIR.


Inbound, Outbound
1
AN
Shipper
Reporting


Flag






Prepaid, Collect
1
AN
Shipper
Reporting


Flag






COD Flag
1
AN
Shipper
Reporting


COD Amount
9.2
AN
Shipper
Reporting


Shipment Value
9.2
AN
Shipper
Reporting; claims


Driver Name
20
AN
Shipper
Reporting; Claims


Trailer/Car #
15
AN
Shipper
Reporting; claims


Trailer/Car Seal #
15
AN
Shipper
Reporting; claims


Import, Export Flag
1
AN
Shipper
Reporting


# Stops
2
N
Shipper
Reporting


Stop Off Charges
7.2
AN
Shipper
Reporting


Rated Freight
9.2
AN
Shipper
Payment, reporting


Charges






Cube Dimensions
5
N
Shipper
Reporting


Shipment “as
7.2
N
Shipper
Reporting; claims


weight”






Accessorial Charges
7.2
AN
Shipper
Payment, reporting


Total Freight Chgs
9.2
AN
Shipper
Payment, reporting


Destination Name
25
AN
Shipper
Reporting


Destination City
20
AN
Shipper
Reporting


Destination State
2
A
Shipper
Reporting


Destination Zip
9
N
Shipper
Reporting


Code






Destination Area
3
N
Shipper
Reporting, verification


Code






Destination Prefix
3
N
Shipper
Reporting, verification


Destination Phone
4
N
Shipper
Reporting, verification


Mileage
5
N
Shipper
Reporting


Voucher/Check #
12
AN
CP 40
Inquiry


Ship Date
8
N
Shipper
Life cycle tracking


CP 40 Receipt Date
8
N
CP 40
Life cycle tracking


Storage Insert Date
8
N
CP 40
Life cycle tracking


VRU Extract Date
8
N
CP 40
Life cycle tracking


Authorization Date
8
N
CP 40
Life cycle tracking


Authorization #
6
AN
Issuing
From authorization





Proc. 45
response feed


Auth Response
2
AN
Issuing
From authorization


Code


Proc.45
response feed


Delivery Date
8
N
CP 40
Life cycle tracking


Completion Date
8
N
CP 40
Life cycle tracking


Deposit Extract Date
8
N
CP 40
Life cycle tracking


Settlement Date
8
N
Paying
From Settlement record





Proc. 54



Settlement DDA #
12
AN
Paying
From Settlement record





Proc.54



Shipper Billing Date
8
N
Issuing
From statement billing file





Proc. 45
feed for life cycle tracking


Delivery Area Code
3
N
Carrier
POD tracking, claims





Proc



Delivery Prefix
3
N
Carrier
POD tracking, claims





Proc. 46



Delivery Phone
4
N
Carrier
POD tracking, claims





Proc. 46



Receiver Name
20
A
Carrier
POD tracking, claims


Receipt Condition
1
A
Carrier
Quality of service tracking,





Proc. 46
claims


POD ID
15
AN
Carrier
Provided by carrier





Proc. 46
22(such as FedEx,






UPS) who has






accepted POD system









In addition, the central processor 40 maintains BOL line item details from the transaction information. The BOL line item details generally consist of information relating to the goods of the shipment as can be seen below in table 7.









TABLE 7







BOL Line Item Detail Data Elements











Data Element
Length
Type
Source
Purpose














Shipper ID
16
N
CP 40
Record ID


Bill of Lading #
15
AN
Shipper
Record ID


Ship Date
8
N
Shipper
Record ID


Product Description
28
AN
Shipper
Reporting, claims


Product ID
8
AN
Shipper
Reporting, claims


Product Value
7.2
$N
Shipper
Claims


Haz Mat Flag
1
AN
Shipper
Reporting, claims


Item Weight
7.2
N
Shipper
Reporting, claims


Total Pcs
5
N
Shipper
Reporting, claims


Item “as weight”
7.2
N
Shipper
Reporting


Unit of Measure
4
AN
Shipper
Reporting, claims


Accounting Code
25
AN
Shipper
Reporting


Item Freight
7.2
N
Shipper
Reporting, claims


Charges









In the example system application of FIG. 1, the carrier 22 will not have access to the BOL line item product value, but will be able to see the line item freight charges.


A further advantage of the shipment transaction system of FIG. 1 is that the system allows multiple users to obtain information about the same shipment from the same source. Since the system supplies information from the same source, all users will obtain the same information at the same time. This advantage of timeliness does not exist in current systems. Existing systems are not known to provide a single source of up-to-date information regarding multiple shipment transactions.


In an alternative embodiment, multiple users access the shipment information via the central processor 40. The shipment information is stored in the data storage unit 42. The central processor 40 is electronically linked to a multitude of user stations. The link between the central processor 40 and a user station allows for conventional two-way communication. The user station is a standard personal computer comprising of a video display, a keyboard, a central processor, and a modem link. A user initiates a request for information by accessing the central processor 40 using the personal computer. When the user is logged into the central processor 40, the central processor 40 prompts the user to enter a password.


The central processor 40 provides a security check on all information requests. The security check is programmed such that the shipper 20 and carrier 22 are restricted to accessing only their own data. In addition, the processor 40 is programmed such that unauthorized parties are denied access.


The central processor 40 receives informational requests from the user. The central processor 40 accesses the data storage unit 42 and extracts the requested information and transmits the information to the user's station. The advantage of such an information service is clear. Users will be able to obtain current information regarding a shipment transaction.


In a particular application, once a user has access to the system, the central processor 40 will prompt the user for a range of dates of interest including the current day, the previous day, monthly total, yearly total, or a specified date range. The central processor 40 displays the transaction information, freight amounts, shipment costs, total weight, and cost per pound for various types of transactions including: transactions added to the data storage unit, transactions with proof of delivery, transactions that have expired, transactions in the suspense file, transactions paid to carrier, transactions in transit, transactions declined, and transactions approved.


The central processor 40 allows user's to request a particular transaction by entering any one of a multitude of transaction elements. The central processor 40 identifies a particular transaction with reference to the BOL number, the shipper's customer number for the receiver 22, the payment ID, the carrier's customer number for the shipper 20, the merchant number, the account ID, the receiver's order number for the shipper 20, the shipper's order number for the BOL number, or the shipping date. This ensures compatibility between the user reference numbers such that the user can access information using their unique reference number assigned to the transaction.


The example application has additional advantages. The central processor 40 provides to all authorized users the ability to generate custom analysis of their own data. This has the advantage of giving the carrier 22 the ability to extract payment data needed to automatically post his accounts receivable system. This is an advantage over existing systems that rely on manual distribution of payment against the account receivable system. Similarly, the shipper can extract payment data and automatically post his accounts payable which closes out the individual accounts payable due to each carrier. An advantage stemming from this automated system is that the shipper 20 does not need a paper invoice in order to have proof of delivery. The shipper 20 accesses the central processor 40 and verifies which shipments have been delivered by a particular carrier 22. Similarly, the carrier 22 accesses the central processor 40 to find out which transactions have been paid out by the shipper 20. This informational system removes much uncertainty from the shipment process that promotes more efficient use of available resources such as working capital, transportation, and personnel.


In a particular application, the central processor 40 generates standard shipment transaction summary reports and provides appropriate access to the reports by various users. These reports include a transaction inventory control report, an open aging summary report, a suspense inventory control by source report, and a suspense inventory aging summary report. The central processor 40 uses the security profiles to determine which subset of transaction records will be summarized for each user. For example, the shipper 20 has access only to that shipper's reports.


The inventory control report provides control totals of BOL numbers, merchandise value, and freight value. There are key control points including: starting inventory position, new BOL's from shippers, BOL's closed since the last report by the different methods discussed for closing BOL numbers, BOL's re-opened since the last report by manual proof of delivery override via customer service, BOL's canceled since the last report, and the ending inventory position.


The open aging summary report contains those BOL numbers that have not been delivered. In addition, the freight value and merchandise value for each shipper ID and Dock ID are supplied for distinct age groups. The age groups include groupings by consecutive days since the shipping date and one group for 10 days past the shipping date. The suspense inventory control by source report includes merchandise and freight value amounts of transactions in the suspense file. Several control points for the suspense inventory control include: starting inventory position, new inventory added since last report, inventory cleared since last report, inventory deleted since last report, inventory undeleted since last report, and ending inventory position. The suspense inventory aging summary report provides an aged summary of suspense files including the merchandise and freight value of items that are in the suspense file by original receipt date.


The central processor 40 generates detailed reports including: the inventory aging detail report, the suspense inventory aging detail report, and the declined item aging detail report. The detail reports are viewed by either the shipper ID/Dock ID/account ID combination or by the carrier ID/merchant number combination. The inventory aging detail report lists the open BOL numbers sorted by the days in inventory, the shipper ID combination, and the BOL number. The inventory detail report lists the merchandise and freight value associated with each open BOL number. The suspense inventory aging detail report lists open BOL numbers by source and receipt date. Several fields are displayed including: shipper ID, dock ID, account ID, BOL number, carrier ID, freight value, and the merchandise value. The declined item aging detail report allows users to research the cause of exception items and lists the shipper ID combination, ship date, authorization time, BOL number, shipper invoice number, merchant number, and freight value. The declined item aging detail report is viewed by either shipper ID/dock ID/account ID combination, or by carrier ID/merchant number combination.


The central processor 40 generates two reports that reference declined authorizations. These reports include the declined item summary report and the declined item aging report. The declined item summary report summarizes information regarding the declined authorization. The declined item aging report summarizes the information regarding the declined authorization by the shipping date.


Referring now to FIGS. 10A-10C, according to the present invention, example transactional processes for implementing ship transactions are shown in the form of flow diagrams. FIG. 10A illustrates a manner in which accounts for shippers and carriers can be set up in a database for processing shipment transactions by the main CPU system running the operations.


The approach shown in FIG. 10A includes five levels, with each level applicable to both the shipper and the carrier. At level 1010, an account is merely established for the shipper/carrier. Setting up the account and defining the company profile is administered by the central operators. For instance, if a credit institution, such as a bank with a credit division, owns and/or is operating the main CPU and defining communication access to the system, an agent of the credit institution administers these tasks. At level 1014, a company profile is established on the main CPU for the shipper/carrier. A typical company profile includes, among other particulars, contact information, facility locations, invoicing/debit/credit agreements for system use, and security information. Defining a company profile permits the shipper/carrier to be a user of the system with access to information processed by the main CPU for the shipper/carrier. At level 1016, a profile for the system administration is established to refine the shipper/carrier's access to the information associated within its company (the shipper or carrier) and organizational unit. At levels 1020 and 1024, the shipper/carrier's administrator defines operational profiles to define how the company will use the shipment transaction system.


According to a more specific implementation, there are specific operational profiles and specific user profiles used by the main CPU to execute operations. These specific operational profiles fall into five categories: approval policies to define the monetary limits for each particular approver of bills; floor limits to define any rule for automatic approval of bills; G/L charts of accounts that are used in the process of allocating freight expenses to particular accounts within the company's general ledger system; operational filters to define characteristics of the rights of each user of the system within the company; and data filters that define business rules that are used to limit the transactions such a user can see.


The specific user profiles, which are issued and managed by the company using the system, are used by the system to enforce business rules with the company. These rules may include, for example, that every user ID: be unique, associated with only one organizational unit within only one company, and have only one operational filter and only one data filter associated with it. Examples of other such business rules include establishing that actions performed by the company are binding and that updates to the company's profiles be made regularly.


At levels 1026 and 1028, the main CPU uses the previously defined information to establish the user relationships (depicted at level 1026) and to define carrier vendors or shipper customers, respectively, for the shipper-type company or the carrier-type company.


Using the above information, the main CPU then begins to define trading partners and trading parameter data for each shipper and for each carrier. This is depicted at level 1034 of FIG. 10A.


For additional examples of ways to implement the above-characterized levels, as well as other aspects and examples of the various example embodiments, reference may be made to the attached Appendix A (Training Guide) and to the attached Appendix B (Users Guide). For example, for information relating to the example setup information of FIG. 10A, reference may be made to Chapter 1 of attached Appendix B (Users Guide).



FIG. 10B illustrates an example relationship that may be used in the shipment transaction system for processing freight payments. As discussed above in connection with FIGS. 1, 2 and 2A, upon receipt of the BOL (block 1040), the main CPU receives notification of delivery (block 1042) and the creditor (e.g., financial institution or bank) approves transaction 1044 and authorizes payment (block 1046). Payment is then made to the carrier as indicated in block 1048.



FIG. 10C illustrates example processes for transactional flow, between a carrier and a shipper, in an example shipment transaction system referred to as “PowerTrack”.® As illustrated in FIG. 10C, work transactions 1050 occur in response to activity input to the system from equipment, such as computers or other data input/output devices, operated by the shipper and the carrier. Such equipment is depicted as shipper items 1052a, 1052b and carrier items 1054a, 1054b. The main CPU 1056 processes the data via Internet communication links, and interfaces with a payment-center CPU 1058 operated by the creditor/bank. As illustrated, the main CPU 1056 and the payment-center CPU 1058 exchange data with each other and the items 1052a, 1052b, 1054a, 1054b to effect proper payment in response to cleared shipment transactions.



FIG. 11 illustrates an example communication path from an architectural perspective in which an array of computers and data routers are used in an example implementation of a system and method, according another aspect of the present invention. The computers include gateway-implemented firewalls 1064, 1066 and 1068, and data routers in the form of hubs H1-H6 (available from 3Com). Each of the firewalls 1064, 1066 and 1068, and data routers H1-H6, along with other accessible stations in FIG. 11, have unique Internet addresses. The operators controllers 1076 of the main CPU 1078 access tier II, which is used to maintain databases for the system, via a path through the firewall 1066 and directly back through hub H3, or via a path out toward hub H2 and back through hub H3. The financial institutional (not shown) accesses the system, along with access by the shippers and carriers, via the Internet at block 1080. An outside entity, for example, an auditor can also be setup and authorized by the system to access information, and this typically occurs via a path through the Internet or the firewall 1064.


Within tier II, database/servers are maintained in a dual manner to permit for execution of programs for actual system use and for user acceptance testing. Business logic database/servers 1081 and 1083 store an object oriented program that is used to execute the processing in the actual system (1081) and for user acceptance testing (1082). Also for the actual system (1082) and for user acceptance testing (1084), database/servers 1082 and 1084 provide web server functions for the Internet access at block 1080. Database/server 1085 is used as a background tool and is useful, for example, for sending and receiving information between tier II components and the main CPU 1078. Database/servers 1089 and 1090 store shipment transaction information for processing in the actual system (1089) and for processing the same data for analytical purposes, for example, in response to inquiries made by the shipper, the carrier, the bank, or an outside entity (e.g., an auditor).


Database/servers 1088, 1089 and 1090 can be used to duplicate the functionality of database/servers 1085, 1086 and 1087 for testing purposes.


Database/servers 1091 and 1092 can be used as interactive voice response units adapted to be used by carriers to receive information such as delivery notification, as discussed previously.


As mentioned above, for additional details concerning example implementations and aspects, and alternative embodiments of the present invention, reference may be made to the attached Appendix A (Training Guide) and to the attached Appendix B (Users Guide), each of which forms part of the instant patent application.


This invention need not be limited to scenarios involving shipment of product and the use of physical carriers for transportation of the product or equipment, since an important advantage of the invention is to provide the parties involved a mechanism for auditing transaction information to validate that a transaction occurred properly and as agreed upon by the parties involved. The present invention also provides for application of the validation system in other areas, by way of example only, but should not be limited to these transaction scenarios. Telecommunications service vendors or telephone operating companies (TELCOs) are interested in providing their services to third party customers but do not wish to add additional infrastructure (more personnel and equipment) in order to engage more customers for their services. The TELCO can engage the services of an independent system manager that installs the necessary hardware and software at the location of the third party customer and is then responsible for ongoing service and maintenance of the equipment and software. In return, the system manager is paid a fee by the TELCO for the initial set up and ongoing service calls that may be made by the third party customer. These transactions are validated to ensure that they were properly completed and then payment is sent to the system manager for services rendered.


In the area of services, vendors that provide a particular service usually secure customers through a network of agents or service providers that work directly with the customers to sign them up for the service. As shown in FIG. 12, a vendor 1220 through his vendor processor 1224 initiates the service transaction by acting in conjunction with a Service Quotation or Bidding engine (such as a computer-run programmed task) 1230 to generate a quote for the cost of the service. Vendor processor 1224 sends the quote to a data processing device 1234 of a vendor access terminal 1232. Similar to the shipping scenario, the data processing device 1234 generates transaction information and sends the transaction information to a central processor 1240. The central processor 1240 identifies and centrally tracks the transaction information. A service provider processing device 1246 receives proof of delivery or confirmation that the customer has received the service or is now subscribed to the service and this information is sent back to the central processor 1240. The central processor 1240 processes and stores all pertinent service subscription information in a data storage unit 1242 and allows immediate access to this information by the vendor 1220, the service provider 1222, and other authorized users. The central processor 1240 interfaces with an improved payment system including an issuing institution 1244 and a paying institution 1252. An issuing processor 1245 of the issuing institution 1244 maintains a credit account for the vendor 1220 and debits the vendor's account for the service provider's fee (cost of setting up the customer to be able to deal directly with the vendor; or cost of getting the customer subscribed to the service, etc. . . . ) when authorized to do so. A paying processor 1254 of the paying institution 1252 tenders payment to the service provider 1222.


In a specific example, a communications services provider assumes the role of the vendor for services ranging from telephone to cable (this includes wireless, satellite, video conferencing, interne services, video of demand, etc.) and an authorized agent assumes the role of the service provider that helps the vendor sign up customers for a fee. The rest of the transaction is similar to the transaction characterized in connection with FIG. 12 for auditing and payout purposes. Finally, tables comparable to Tables 1-7 (see also Table 1A and Tables 11-15) can be developed for the service provider locations and identifying information, as well as authorized users profiles, so that the auditing and payment operations pursuant to the transactions can be conducted as described in earlier embodiments.



FIG. 13 illustrates an example in which the service provider 1320 initiates the transaction, pursuant to customer 1321A request for quote, and generates the transaction information that commences the entire transaction. With this system, vendor 1322 can verify that the transaction entered into by the service provider has indeed taken place and that the customer is satisfied before payment is authorized to the service provider. Specifically, the purchase order is processed through processor 1324 that acts in conjunction with quotation generating engine 1330 (such as a computer-run programmed task). Processor 1324 can simultaneously conduct a credit check of customer 1321A as per instructions of vendor before any transaction is formally entered in the system. Quotation generating engine 1330 generates a quote for the customer with the parameters of the service (which may also include a product purchase as part of the package) that he is subscribing to. By way of example, if the transaction is for cellular phone service, engine 1330 generates a quote for the cost of the monthly service, rate per minute, cost of the initial phone purchase, any weekend discounts, etc. Typically, the quotation engine may be a combination of application software and hardware (local PC or server; or a server that is remotely accessed) that contains the quotation algorithm and database that the user (service provider or vendor/subvendor) needs to generate a formal quote for the customer while initiating part of the transaction in the system. The engine 1320 accepts data like: name of prospect customer, address, phone number, # of users, type of service desired, billing particulars, credit history evaluation, social security numbers, etc. The next step can include the generation of a customer profile (which can include information on the service provider and his location) and identification/customer number that can be used for tracking purposes by the vendor (or subvendor). This customer I.D. number can be used later to track payment to service provider. The quotation algorithm and database within engine 1330 (usable by service provider 1320) can remain static for a fixed period of time, can be changed at regular or agreed upon intervals or can be coupled real-time to the vendor's database to allow for up to the minute rate changes, special discounts or promotional programs that may be applicable. Line 1331 indicates the coupling that can exist between engine 1330 and vendor 1322, that may be hardwired, wireless, through a network, internet, satellite or any other mechanism or system that will allow for one or two way coupling and communication between the vendor and the service provider.


Assuming that all details of the initial transaction are in order, processor 1324 sends the complete purchase information to data processing device 1334 of access terminal 1332; processing device 1334 then sends the transaction information to central processor 1340. Vendor processing device 1346 receives proof of delivery of service provided, or confirmation that the subscriber of the service has met all of the acceptance criteria, and that he is now ready to be connected to the system (e.g. cellular phone system). Central processor 1340 processes and stores all pertinent transaction information in data storage unit 1342, which allows for immediate access to the information by the vendor 1322, the service provider 1320 and any other authorized users for verification of data integrity and tracking purposes. The remainder of the transaction is similar to embodiments already described, wherein the paying institution 1352 and the issuing institution 1344 are involved in processing the payment to the service provider once it has been authorized by vendor. Further, the paying and issuing institution may be one and the same and can charge its fees to the vendor and service provider in the system as it is receiving payments from vendor 1322 and tendering payments to service provider 1320.


As an example of the type of information that could be used in the vendor/service provider scenario, reference is made to the following Tables:









TABLE 1A







Transaction Information


(Vendor/Service Provider)










Data Element
Length
Type
DESCRIPTION





Vendor ID
10
N
Record Vendor ID


Vendor Office ID
 3
N
Record Vendor Office ID


Quotation #
15
AN
Record ID; also customer





PO#


Ship Date
 8
N
Record ID, reporting


Service Provider
 4
AN
Payment period


Terms





Consolidated invoice
 1
N
1 = Yes; 2 = No


Customer Number
10
N
Alternate index, allows





Vendor 1220 to specify





it's customer number


Customer PO #
15
AN
Alternate index, reporting


Order #
15
AN
Alternate index


Service Provider
15
AN
Reporting, PO associated with


Order Number


service provided


Service Provider
35
AN
Name of service provider


Name
















TABLE 11







Vendor Profile










DATA ELEMENT
WIDTH
TYPE
DESCRIPTION





Vendor ID
10
N
Uniquely identifies a legal





entity using a single





quotation system (e.g. engine





1230), assigned





by the CP 1240.


Account ID
16 
N
Account # assigned to Vendor





1220 by issuing processor 1245.


Vendor Name
32 
A/N



Vendor Address 1
32 
A/N
Headquarters Address.


Vendor City
28 
A/N



VDR. State/Province
3
A/N



VDR. Country
3
A/N



VDR. Contact
32 
A/N



VDR. Phone
10 
N



Open Date
8
N
Supplied by CP 1240





when record is built.





YYYYMMDD format


Date of First Activity
8
N
Automatically supplied by





CP 1240 when first quote





record is received by CP 1240 -





YYYYMMDD format


Date of Last Activity
8
N
Automatically updated by





CP 1240 every time a





quote record is processed


Current Status
4
A
Valid values are OPEN,





CLSD, HOLD. Automatically





updated on effective date if





effective date was pre-entered





or as part of on-line transaction





when effective date is set to





today.


Current Status Date
8
N
Automatically updated by





system when current status field





is updated, YYYYMMDD





format


Pending Status
4
A
User will key status, valid values





are OPEN, CLSD, HOLD


Effective Date
8
N
Default to today's date with





user ability to override to





a future date. YYYYMMDD





format


Last update date
8
N
Automatically stamped





by CP 1240


Last update time
4
N
Automatically stamped by CP





1240. HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile by CP 1240.
















TABLE 12







Vendor/Service Provider Profile











DATA
DATA



COLUMN NAME
WIDTH
TYPE
DESCRIPTION





Vendor ID
10 
N



Service Provider ID
4
A/N



Merchant Number
10 
N
Assigned by Paying processor





1254. If blank, use default





value from service provider





profile.


Proof of Service
1
A
“Y” for POD to be required,


Delivery (POD)


“N” for POD not required


Type of POD
4
A
Identifies in what manner





the POD is to be received.


Auto close days
2
N
Number of days after which





the transaction will





close and be paid to the





Service Provider 1222





regardless of whether or not





POD has been posted.


Open Date
8
N
Automatically supplied by





CP 1240 when record is built.





YYYYMMDD format


Date of First
8
N
Automatically supplied by


Activity


CP 1240 when first quote





record is received by system -





YYYYMMDD format


Date of Last
8
N
Automatically updated by


Activity


CP 1240 everytime a quote





record is processed


Current Status
4
A
Valid values are OPEN,





CLSD, HOLD. Automatically





updated on effective date if





effective date was pre-entered





or as part of on-line transaction





when effective date is set





to today.


Current Status Date
8
N
Automatically updated by





CP 1240 when current status





field is updated, YYYYMMDD





format


Pending Status
4
A
User will key status


Effective Date
8
N
Default to today's date with





user ability to override to





a future date. YYYYMMDD





format


Last update date
8
N
Automatically stamped by





CP 1240


Last update time
4
N
Automatically stamped by





CP 1240 HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile lists
















TABLE 13







Service Provider Profile











DATA
DATA



COLUMN NAME
WIDTH
TYPE
DESCRIPTION





SP
4
A/N
4 character code that uniquely





identifies a Service Provider





(SP) 1222.


Merchant Number
10 
N
Paying processor 1254





assigns to each SP.


SPp 22 Name
32 
A/N
DBA name of SP HQ


SP Address 1
32 
A/N



SP Address 2
32 
A/N



SP City
28 
A/N



SP State/Province
3
A/N



SP Country
3
A/N



SP Contact
32 
A/N
Name of primary contact





at SP HQ


SP Phone
10 
N
Phone number of primary





contact at SP HQ


Open Date
8
N
Automatically supplied by CP





1240 when record is built.





YYYYMMDD format


Date of First
8
N
Automatically supplied by


Activity


CP 1240 when first quote





record is received by system





on this SP 1222 -





YYYYMMDD format


Date of Last Activity
8
N
Automatically updated by





system every time a





quote record is processed





for this SP 1222


Current Status
4
A
Valid values are OPEN,





CLSD, HOLD.Automatically





updated on effective date





if effective date was pre-entered





or as part of on-line transaction





when effective date is





set to today.


Current Status Date
8
N
Automatically updated by





CP 1240 when current status





field is updated,





YYYYMMDD format


Pending Status
4
A
User will key status


Effective Date
8
N
Default to today's date with





user ability to override





to a future date. YYYYMMDD





format


Last update date
8
N
Automatically stamped





by CP 1240


Last update time
4
N
Automatically stamped by





CP 1240 HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile lists by CP 1240
















TABLE 14







Vendor/Service Provider Access Terminal Profile










COLUMN NAME
WIDTH
TYPE
DESCRIPTION





Vendor ID
10 
N
Uniquely identifies a legal





entity using a single quotation





system (e.g engine 1230)


SP ID
3
N
Uniquely identifies a particular





physical location with a





Service Provider ID.


Account ID
16 
N
Issuing Processor 1254 assigns.





Defaults from SP profile, can





be overridden by vendor


SP Name
32 
A/N
DBA name of SP





originating quote


SP Address 1
32 
A/N
Street address of SP





originating quote


SP Address 2
32 
A/N



SP City
28 
A/N



SP State/Province
3
A/N



SP Country
3
A/N



SP Contact
32 
A/N



SP Phone
10 
N
To be used for reporting against





completion transaction


Open Date
8
N
Automatically supplied by





CP1240 when record is built.





YYYYMMDD format


Date of First
8
N
Automatically supplied by





CP 1240 when


Activity


first quote record is





received by system -





YYYYMMDD format


Date of Last
8
N
Automatically updated by


Activity


CP 1240 every time a





quote record is processed


Current Status
4
A
Automatically updated by





CP 1240 on the effective date





if effective date was pre-





entered or as part of the on-line





transaction if the effective date





is changed to today. Valid values





are OPEN, CLSD, HOLD


Current Status Date
8
N
Automatically updated by





CP 1240 when current status





field is updated, YYYYMMDD





format


Pending Status
4
A
User will key status


Effective Date
8
N
Default to today's date with





user ability to override to a





future date. YYYYMMDD





format


Last update date
8
N
Automatically stamped





by CP 1240


Last update time
4
N
Automatically stamped by





CP 1240 HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile lists
















TABLE 15







Service Quotation Data Elements











Data Element
Length
Type
Source
Purpose





Vendor ID
10
N
CP 1240
Record ID


SP ID
 3
N
CP 1240
Record ID


Account ID
16
N
CP 1240
Record ID; reporting


Quotation #
15
AN
SP
Record ID


Service Date
 8
N
SP
Record ID, reporting


SPAC
 4
A
SP
Alternate index, identifies






Service Provider


Merchant #
10
N
CP 40
Alternate index, for CP 1240






usage


Vendor #
10
N
SP
Alternate index, allows SP to






specify its vendor number for






a given vendor


Customer Number
10
N
Vendor/
Alternate index, allows





SP
Vendor or SP to specify it's






customer number


Customer PO #
15
AN
SP
Alternate index, reporting


(Quote #)






SP Order #
15
AN
SP
Alternative Index


Vendor Order
15
AN
SP
Reporting, alternate locator


Number






Vendor Name
35
AN
SP
Reporting


Vendor Contact
20
A
SP
Claims


Person






Vendor Phone #
15
AN
SP
Claims


Origin Designator
10
AN
SP
Reporting


City
20
AN
SP
Reporting


State
 2
A
SP
Reporting


ZIP Code
 9
N
SP
Reporting


Division Code
 2
AN
SP
Reporting
















TABLE 16







Service Quotation Line Item Detail Data Elements











Data Element
Length
Type
Source
Purpose





Vendor ID
16
N
CP 1240
Record ID


Quotation/PO #
15
AN
SP
Record ID


Service Date
 8
N
SP
Record ID


Service Description
28
AN
SP
reporting, claims


Serrvice Program ID
 8
AN
SP
reporting, claims









The above-described system can be used by authorized representatives (or agents) to help customers subscribe to other types of services for a fee. Travel agents are already commission-based when they assist customers in making reservations for lodging, air and land transportation; however, they can now be tied to this system for faster processing of payments back to them in return for a fee that can be charged by the banking institution for this service.


The system can also be used in the area of providing wireless communications services (or entertainment services such as satellite programming or satellite communications) to third party customers, via authorized or empowered representatives, to verify that customers have the correct equipment and software to receive the service from the communications vendor. The representative is involved in preliminary issues of credit checks and programming selection and is the normal contact for the customer if any service issues arise. The representative is paid a fee for the initial set up and ongoing support of the customer using the transaction validation system described to ensure that the work was properly done and that payment is issued to the authorized representative by an authorized user of the system. This system is also applicable in the area of video conferencing services, where a third party customer is interested in working with the communication services vendor through a communications consultant. The consultant helps to set up the equipment and software required to connect to the video conferencing network and is there to service the customer's needs on an ongoing basis. The consultant provides all of the services for a fee to be paid by the communications service vendor.


Software or information technology (IT) developers also benefit from this system when using IT consultants that work closely with third party customers, specifically when such customers need help in upgrading and maintaining their systems. The IT consultants are paid using the transaction validation system described for services rendered. Companies selling products through online (Internet) agents such as Buy.com, eBay.com or eToys.com or via a normal telephone (such as florists, catalog purchases, QVC, Home Shopping Network, etc.) also benefit from this system.


The role of a “vendor” is becoming blurred as more companies start to shift their manufacturing of products to companies that specialize in the manufacture of that type of product in response to the customer's demand for lower cost, shorter lead times and better technology. This is especially true in the area of computers and consumer electronics. OEM companies like IBM and HP, in the computer area, and Ericsson and Qualcomm, in the mobile communications area, have shifted much of their manufacturing to contract manufacturers such as Solectron and Flextronics. Contract manufacturers have the capability of taking the engineered designs of these customers and manufacturing them at the lowest possible cost due to their purchasing strength and logistic capabilities. They in turn will ship the completed product to the end customer (e.g. Circuit City, Best Buy, and etc.) on behalf of the OEM and invoice that customer if the OEM chooses that method. Here the contract manufacturer has control of the carrier that will be shipping the product to the OEM's customer. In the eyes of the customer the vendor is still the OEM that is the party receiving the P.O. and whom they are holding responsible if the product has a problem or is not shipped on time. The emerging vendor/subvendor relationship, including the service provider (providing transportation services in this case) who is involved in this type of transaction, requires the banking institution to ultimately pay the service provider and subvendor when it is authorized by the vendor to do so. This is another opportunity for the banking institution to expedite auditing and financial negotiations due to the presence of the subvendor in this equation.


Referring now to the example process depicted in connection with FIG. 14, vendor/OEM 1420 receives a purchase order through vendor processor 1424A from a customer for product/equipment with a requested shipping date. Processor 1424A initiates a transaction by acting in conjunction with subvendor processor 1424B and quotation generating engine 1430 to generate a quote for the equipment and shipping date for the customer. Subvendor processor 1424B sends the quotation to vendor processor 1424A and to a data processing device 1434 of the subvendor access terminal 1432. Vendor can now add their markup before advising customer of equipment ship date but now knows what it owes the subvendor if the entire transaction occurs as planned. The data processing device 1434 generates the transaction information and sends the transaction information to the central processor 1440, which in turn identifies and centrally tracks the transaction information. A service provider device 1446 receives proof of delivery information and sends this information to the central processor 1440. Central processor 1440 processes and stores all pertinent information in a data storage unit 1442 and allows immediate access to their information by the vendor, subvendor and the service provider. When vendor processor 1424A receives confirmation or proof of delivery then it, or its authorized agent/user, will authorize payment to subvendor. This is also a signal to subvendor that the subvendor controlled service provider 1422 can now be paid. Service provider's 1422 notice to central processor 1440 that delivery is confirmed reaches both vendor and subvendor simultaneously through central processor 1440 to ensure a closed loop system. The issuing processor 1445, of the issuing institution 1444, maintains a credit account for both the vendor 1420 and subvendor 1421 and debits the vendor's account for the cost of the entire project (which was calculated with a different algorithm initially to avoid disclosing cost information to the end customer) when payment to subvendor is authorized by vendor. Subvendor's account is debited by issuing processor 1445 for cost of service provider's 1422 service when authorized by subvendor. The remaining part of the auditing and payment system is substantially similar to embodiments described above.


Referring briefly to Tables 1-7, the content of these tables for the subvendor is similar to that of the shipper/carrier scenario described earlier since the service provider is acting like a manufacturer of goods that needs to ship product to a customer via a carrier. Additional profiles similar to Table 1B (Transaction Information-Vendor/Subvendor/Service Provider), Table 8 (Vendor Profile) and Table 9 (vendor/subvendor profile) would be developed for a particular transaction. The subvendor can provide part of the service package that the vendor has contracted him to do and have the package delivered to the end customer through another party that will act as a service provider. For instance, IBM contracts with a subvendor to install a software update for a global IBM customer with a presence in Costa Rica. The subvendor in turn contracts with a local Costa Rican software consultant (service provider) to perform the actual software update at the customer site. Once the tables have been established and put into the system (and the authorized users identified) the auditing and payment operations can be performed substantially the same as described in earlier embodiments.









TABLE 1B







Transaction Information


(Vendor/Subvendor/Service Provider)










Data Element
Length
Type
DESCRIPTION





Vendor ID
10
N
Record Vendor ID


Vendor Office ID
 3
N
Record Vendor Office ID


Quotation #
15
AN
Record ID; also customer PO#


Ship Date
 8
N
Record ID, reporting


Subvendor Terms
 4
AN
Payment period


Consolidated invoice
 1
N
1 = Yes; 2 = No


Customer Number
10
N
Alternate index, allows Vendor





1420 to specify it's customer





number for a given receiver


Customer PO #
15
AN
Alternate index, reporting


Order #
15
AN
Alternate index


Subvendor Order
15
AN
Reporting, PO associated


Number


with shipment


Service Provider
35
AN
Name of service provider or


Name


shipping company
















TABLE 8







Vendor Profile










DATA ELEMENT
WIDTH
TYPE
DESCRIPTION





Vendor ID
10 
N
Uniquely identifies a legal





entity using a single quotation





system (e.g.engine 1430),





assigned by the CP 1440.


Account ID
16 
N
Account # assigned to Vendor





1420 by issuing processor 1445.


Vendor Name
32 
A/N



Vendor Address 1
32 
A/N
Headquarters Address


Vendor City
28 
A/N



VDR. State/Province
3
A/N



VDR. Country
3
A/N



VDR. Contact
32 
A/N



VDR. Phone
10 
N



Open Date
8
N
Supplied by CP 1440 when





record is built. YYYYMMDD





format


Date of First Activity
8
N
Automatically supplied by





CP 1440 when first quote





record is received by CP 1440 -





YYYYMMDD format


Date of Last Activity
8
N
Automatically updated by





CP 1440 every time a quote





record is processed


Current Status
4
A
Valid values are OPEN,





CLSD, HOLD. Automatically





updated on effective





date if effective date was





pre-entered or as part of on-





line transaction when effective





date is set to today.


Current Status Date
8
N
Automatically updated by system





when current status field is





updated, YYYYMMDD format


Pending Status
4
A
User will key status, valid values





are OPEN, CLSD, HOLD


Effective Date
8
N
Default to today's date with user





ability to override to a future date.





YYYYMMDD format


Last update date
8
N
Automatically stamped by CP 1440


Last update time
4
N
Automatically stamped by





CP 1440. HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile by CP 1440.
















TABLE 9







Vendor/Subvendor Profile











DATA
DATA



COLUMN NAME
WIDTH
TYPE
DESCRIPTION





Vendor ID
10 
N



Subvendor ID
4
A/N



Merchant Number
10 
N
Assigned by Paying processor





1454. If blank, use default





value from subvendor profile.


Proof of Delivery
1
A
“Y” for POD to be required,


(POD)


“N for POD not required


Type of POD
4
A
Identifies in what manner the





POD is to be received.


Auto close days
2
N
Number of days after which the





transaction will close and be





paid to the Subvendor 1422





regardless of whether or





not POD has been posted.


Open Date
8
N
Automatically supplied by





CP 1440 when record is built.





YYYYMMDD format


Date of First
8
N
Automatically supplied by





CP 1440 when first quote


Activity


record is received by system -





YYYYMMDD format


Date of Last
8
N
Automatically updated by


Activity


CP 1440 every time a





quote record is processed


Current Status
4
A
Valid values are OPEN,





CLSD, HOLD. Automatically





updated on effective date if





effective date was pre-entered





or as part of on-line transaction





when effective date is set to today.


Current Status Date
8
N
Automatically updated by





CP 1440 when current status





field is updated, YYYYMMDD





format


Pending Status
4
A
User will key status


Effective Date
8
N
Default to today's date with user





ability to override to a future date.





YYYYMMDD format


Last update date
8
N
Automatically stamped by CP 1440


Last update time
4
N
Automatically stamped by CP 1440





HHMM format


Last Update User
8
A/N
Automatically pulled from





user profile lists









In another embodiment it is envisioned that the different users of the system may be located remotely from the transaction validation system and are accessing the system and its database through system processors or computer-like mechanism. For instance, the vendor, subvendor or service provider may be in a foreign country but accessing the transaction system and the central processor arrangement in the U.S. via a computer or a network that connects that user with the transaction system that may be in the U.S. The transaction system and its users need not be co-located. Specifically in FIGS. 12 and 13, vendor processor 1224 or service provider processors may be tapped into remotely, but to the system these users may appear to be local and using their processors locally to access and use the system.


Accordingly, the present invention provides, among other aspects, a computer processing system for a shipment transaction involving a shipper and a carrier. Further, the present invention provides a computer processing system and method for auditing a transaction between a vendor and a service provider in the area of services. Finally, the present invention provides a computer processing system and method for auditing a transaction between a vendor, subvendor and a service provider. Other aspects and embodiments of the present invention will be apparent to those skilled in the art for consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and illustrated embodiments be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims
  • 1. A method for validating a service transaction, the method comprising: generating transaction information prior to processing by a subvendor, the transaction information related to a remotely-processed transaction that occurs between a vendor and a merchant-offering provider controlled by the subvendor, the remotely-processed transaction occurring entirely separate from a local processing arrangement;providing an authorized profile list criterion that includes information about authorized users, wherein the authorized users are empowered by the vendor to authorize payment;maintaining, by the local processing arrangement, data relating to the authorized profile list criterion,processing the transaction information by determining whether the transaction information satisfies the authorized profile list criterion, andusing the authorized profile list criterion to generate information for auditing the remotely-processed transaction.
  • 2. A transaction validation system for auditing, the transaction validation system comprising: a central processor arrangement configured to: maintain data relating to an authorized profile list criterion and data relating to business rules, the business rules defined according to the authorized profile list criterion;process a business transaction submitted by an authorized user, the business transaction processed by using the authorized profile list criterion to determine that the user is authorized to perform the business transaction and by applying the business rules to perform the business transaction, the business transactions occurring entirely separate from the central processor arrangement; andgenerate information for auditing the business transaction.
  • 3. The transaction validation system for auditing, according to claim 2, wherein the authorized profile list criterion includes multiple levels of authorization.
  • 4. The transaction validation system for auditing, according to claim 3, wherein at least two of the multiple levels of authorization respectively correspond to two different payment-authorization levels.
  • 5. The transaction validation system for auditing, according to claim 3, wherein the central processor arrangement is further configured to provide correspondence between at least one of the levels of authorization and the business transaction.
  • 6. The transaction validation system for auditing according to claim 2, wherein the business transaction is completed after correspondence is provided between at least one of the levels of authorization and the business transaction.
  • 7. The transaction validation system for auditing according to claim 2, wherein the authorized profile list criterion includes a plurality of attributes associated with the authorized user.
  • 8. The transaction validation system for auditing according to claim 2, wherein the authorized profile list criterion includes a plurality of attributes associated with the authorized user.
  • 9. A processor arrangement configured to: maintain data relating to an authorized profile list criterion that includes information about authorized users, wherein the authorized users are empowered by a vendor to authorize payment;determine whether transaction information satisfies the authorized profile list criterion, the transaction information related to a remotely-processed transaction occurring entirely separate from the processor arrangement, the remotely-processed transaction being between a vendor and a merchant-offering provider; anduse the authorized profile list criterion to generate information for auditing the remotely-processed transaction.
  • 10. The processor arrangement of claim 9, further configured to use the authorized profile list criterion to generate information for auditing in response to the processor arrangement determining that the transaction information satisfies the authorized profile list criterion.
  • 11. The processor arrangement of claim 10, further programmed and configured to effect payment for the remotely-processed transaction in response to the transaction information.
RELATED PATENT DOCUMENTS

The instant application is a continuation-in-part of U.S. patent application Ser. No. 09/259,657, filed Feb. 26, 1999, entitled “Shipment Transaction System And Method” now U.S. Pat. No. 6,571,149 issued May 27, 2003, and a continuation-in-part of U.S. patent application Ser. No. 09/310,711, filed May 12, 1999, with the same title now U.S. Pat. No. 6,704,612 issued Mar. 9, 2004, both of which are continuations of U.S. patent application Ser. No. 08/748,243 and are incorporated herein by reference.

US Referenced Citations (474)
Number Name Date Kind
4114027 Slater et al. Sep 1978 A
4270042 Case May 1981 A
4305059 Benton Dec 1981 A
4412287 Braddock, III Oct 1983 A
4507778 Tan Mar 1985 A
4567359 Lockwood Jan 1986 A
4713761 Sharpe et al. Dec 1987 A
4725719 Oncken et al. Feb 1988 A
4750119 Cohen et al. Jun 1988 A
4799156 Shavit et al. Jan 1989 A
4926325 Benton et al. May 1990 A
4949272 Vanourek et al. Aug 1990 A
4960981 Benton et al. Oct 1990 A
4992940 Dworkin Feb 1991 A
4995112 Aoyama Feb 1991 A
4996662 Cooper et al. Feb 1991 A
5008827 Sansone et al. Apr 1991 A
5017766 Tamada et al. May 1991 A
5025372 Burton et al. Jun 1991 A
5040132 Schuricht et al. Aug 1991 A
5043908 Manduley et al. Aug 1991 A
5054096 Beizer Oct 1991 A
5077694 Sansone et al. Dec 1991 A
5117364 Barns-Slavin et al. May 1992 A
5151948 Lyke Sep 1992 A
5153842 Dlugos, Sr. et al. Oct 1992 A
5159667 Borrey et al. Oct 1992 A
5161109 Keating et al. Nov 1992 A
5168444 Cukor et al. Dec 1992 A
5175416 Mansvelt et al. Dec 1992 A
5208446 Martinez May 1993 A
5218188 Hanson Jun 1993 A
5220501 Lawlor et al. Jun 1993 A
5222018 Sharpe et al. Jun 1993 A
5231569 Myatt et al. Jul 1993 A
5238349 Grace, Sr. Aug 1993 A
5285383 Lindsey et al. Feb 1994 A
5293310 Carroll et al. Mar 1994 A
5329589 Fraser et al. Jul 1994 A
5334823 Noblett, Jr. et al. Aug 1994 A
5334824 Martinez Aug 1994 A
5337246 Carroll et al. Aug 1994 A
5357563 Hamilton et al. Oct 1994 A
5393963 Thomas et al. Feb 1995 A
5426281 Abecassis Jun 1995 A
5440634 Jones et al. Aug 1995 A
5483445 Pickering Jan 1996 A
5485369 Nicholls et al. Jan 1996 A
5500513 Langhans et al. Mar 1996 A
5631821 Muso et al. May 1997 A
5631827 Nicholls et al. May 1997 A
5652749 Davenport et al. Jul 1997 A
5666493 Wojcik et al. Sep 1997 A
5671362 Cowe et al. Sep 1997 A
5677955 Doggett et al. Oct 1997 A
5694334 Donahue et al. Dec 1997 A
5694551 Doyle et al. Dec 1997 A
5699528 Hogan Dec 1997 A
5712990 Henderson Jan 1998 A
5717989 Tozzoli et al. Feb 1998 A
5719771 Buck et al. Feb 1998 A
5732400 Mandler et al. Mar 1998 A
5754854 Kanamori et al. May 1998 A
5770844 Henn Jun 1998 A
5774170 Hite et al. Jun 1998 A
5790790 Smith et al. Aug 1998 A
5794207 Walker et al. Aug 1998 A
5799286 Morgan et al. Aug 1998 A
5806063 Dickens Sep 1998 A
5842178 Giovannoli Nov 1998 A
5845283 Williams Dec 1998 A
5870719 Maritzen et al. Feb 1999 A
5892900 Ginter et al. Apr 1999 A
5893080 McGurl et al. Apr 1999 A
5896530 White Apr 1999 A
5897645 Watters Apr 1999 A
5910896 Hahn-Carlson Jun 1999 A
5917830 Chen et al. Jun 1999 A
5918216 Miksovsky et al. Jun 1999 A
5918229 Davis et al. Jun 1999 A
5920847 Kolling et al. Jul 1999 A
5924082 Silverman et al. Jul 1999 A
5924089 Mocek et al. Jul 1999 A
5930363 Stanford et al. Jul 1999 A
5931917 Nguyen et al. Aug 1999 A
5943670 Prager et al. Aug 1999 A
5956690 Haggerson et al. Sep 1999 A
5956700 Landry Sep 1999 A
5960407 Vivona Sep 1999 A
5970475 Barnes et al. Oct 1999 A
5973685 Schaffa et al. Oct 1999 A
5978567 Rebane et al. Nov 1999 A
5982891 Ginter et al. Nov 1999 A
5987506 Carter et al. Nov 1999 A
5991728 Debusk et al. Nov 1999 A
5991801 Rebec et al. Nov 1999 A
5995976 Walker et al. Nov 1999 A
6012041 Brewer et al. Jan 2000 A
6016477 Ehnebuske et al. Jan 2000 A
6021202 Anderson et al. Feb 2000 A
6026374 Chess Feb 2000 A
6029140 Martin et al. Feb 2000 A
6029150 Kravitz Feb 2000 A
6043819 LeBrun et al. Mar 2000 A
6044362 Neely Mar 2000 A
6047268 Bartoli et al. Apr 2000 A
6055519 Kennedy et al. Apr 2000 A
6058380 Anderson et al. May 2000 A
6070150 Remington et al. May 2000 A
6085200 Hill et al. Jul 2000 A
6097834 Krouse et al. Aug 2000 A
6115649 Sakata Sep 2000 A
6115711 White Sep 2000 A
6119163 Monteiro et al. Sep 2000 A
6128602 Northington et al. Oct 2000 A
6131087 Luke et al. Oct 2000 A
6141653 Conklin et al. Oct 2000 A
6151588 Tozzoli et al. Nov 2000 A
6157924 Austin Dec 2000 A
6167378 Webber, Jr. Dec 2000 A
6169542 Hooks et al. Jan 2001 B1
6199046 Heinzle et al. Mar 2001 B1
6204763 Sone Mar 2001 B1
6209095 Anderson et al. Mar 2001 B1
6223168 McGurl et al. Apr 2001 B1
6236972 Shkedy May 2001 B1
6246994 Wolven et al. Jun 2001 B1
6254000 Degen et al. Jul 2001 B1
6260024 Shkedy Jul 2001 B1
6266640 Fromm et al. Jul 2001 B1
6267292 Walker et al. Jul 2001 B1
6275813 Berka Aug 2001 B1
6285916 Kadaba et al. Sep 2001 B1
6317737 Gorelik et al. Nov 2001 B1
6323894 Katz et al. Nov 2001 B1
6324522 Peterson et al. Nov 2001 B2
6324551 Lamping et al. Nov 2001 B1
6330550 Brisebois et al. Dec 2001 B1
6338044 Cook et al. Jan 2002 B1
6357042 Srinivasan et al. Mar 2002 B2
6366289 Johns Apr 2002 B1
6381587 Guzelsu Apr 2002 B1
6389402 Ginter et al. May 2002 B1
6418441 Call Jul 2002 B1
6421691 Kajitani Jul 2002 B1
6442533 Hinkle Aug 2002 B1
6477510 Johnson Nov 2002 B1
6486899 Bush et al. Nov 2002 B1
6490567 Gregory Dec 2002 B1
6493685 Ensel et al. Dec 2002 B1
6499036 Gurevich Dec 2002 B1
6505169 Bhagavath et al. Jan 2003 B1
6505172 Johnson et al. Jan 2003 B1
6507826 Maners Jan 2003 B1
6510383 Jones Jan 2003 B1
6510384 Okano Jan 2003 B2
6526443 Goldsmith et al. Feb 2003 B1
6539360 Kadaba Mar 2003 B1
6571149 Hahn-Carlson May 2003 B1
6598026 Ojha et al. Jul 2003 B1
6607081 Graef et al. Aug 2003 B2
6629081 Cornelius et al. Sep 2003 B1
6673479 McArthur et al. Jan 2004 B2
6684384 Bickerton et al. Jan 2004 B1
6687713 Mattson et al. Feb 2004 B2
6697702 Hahn-Carlson Feb 2004 B1
6704612 Hahn-Carlson Mar 2004 B1
6721613 Yamamoto et al. Apr 2004 B1
6721715 Nemzow Apr 2004 B2
6741968 Jacoves et al. May 2004 B2
6751630 Franks et al. Jun 2004 B1
6785661 Mandler et al. Aug 2004 B1
6789252 Burke et al. Sep 2004 B1
6792459 Elnozahy et al. Sep 2004 B2
6820038 Wetzer et al. Nov 2004 B1
6829590 Greener et al. Dec 2004 B1
6832212 Zenner et al. Dec 2004 B1
6833865 Fuller et al. Dec 2004 B1
6850900 Hare et al. Feb 2005 B1
6873963 Westbury et al. Mar 2005 B1
6873997 Majjasie et al. Mar 2005 B1
6879962 Smith et al. Apr 2005 B1
6882983 Furphy et al. Apr 2005 B2
6882986 Heinemann et al. Apr 2005 B1
6889194 Kadaba May 2005 B1
6895438 Ulrich May 2005 B1
6915268 Riggs et al. Jul 2005 B2
6937992 Benda et al. Aug 2005 B1
6941281 Johnson Sep 2005 B1
6944595 Graser et al. Sep 2005 B1
6973258 Yoo et al. Dec 2005 B1
6983278 Yu et al. Jan 2006 B1
6988111 Chow et al. Jan 2006 B2
6999943 Johnson et al. Feb 2006 B1
7047210 Srinivasan May 2006 B1
7054841 Tenorio May 2006 B1
7069234 Cornelius et al. Jun 2006 B1
7069248 Huber Jun 2006 B2
7076652 Ginter et al. Jul 2006 B2
7079176 Freeman et al. Jul 2006 B1
7099304 Liu et al. Aug 2006 B2
7110959 Hahn-Carlson Sep 2006 B2
7110979 Tree Sep 2006 B2
7113964 Bequet et al. Sep 2006 B1
7117170 Bennett et al. Oct 2006 B1
7120871 Harrington Oct 2006 B1
7124150 Majjasie et al. Oct 2006 B2
7130822 Their et al. Oct 2006 B1
7131069 Rush et al. Oct 2006 B1
7133835 Fusz et al. Nov 2006 B1
7136467 Brockman et al. Nov 2006 B2
7143058 Sugimoto et al. Nov 2006 B2
7146337 Ward et al. Dec 2006 B1
7149744 Tenorio Dec 2006 B1
7162458 Flanagan et al. Jan 2007 B1
7177836 German et al. Feb 2007 B1
7181017 Nagel et al. Feb 2007 B1
7203662 Das et al. Apr 2007 B2
7206768 DeGroeve et al. Apr 2007 B1
7222081 Sone May 2007 B1
7243139 Ullman et al. Jul 2007 B2
7254588 Sung et al. Aug 2007 B2
7257560 Jacobs et al. Aug 2007 B2
7263506 Lee et al. Aug 2007 B2
7324976 Gupta et al. Jan 2008 B2
7327952 Enomoto Feb 2008 B2
7340433 Kay et al. Mar 2008 B1
7346575 Ahles et al. Mar 2008 B1
7363261 Whitehead et al. Apr 2008 B2
7373365 Varadarajan et al. May 2008 B2
7386502 Butcher, III Jun 2008 B1
7392934 Hahn-Carlson et al. Jul 2008 B2
7415471 Coleman Aug 2008 B1
7415617 Ginter et al. Aug 2008 B2
7433845 Flitcroft et al. Oct 2008 B1
7437310 Dutta Oct 2008 B1
7448063 Freeman et al. Nov 2008 B2
7475024 Phan Jan 2009 B1
7496519 Hahn-Carlson et al. Feb 2009 B2
7499875 May et al. Mar 2009 B1
7529706 Kulasooriya et al. May 2009 B2
7536354 DeGroeve et al. May 2009 B1
7536362 Starr et al. May 2009 B2
7548884 Thomas Jun 2009 B1
7558793 Topolovac et al. Jul 2009 B1
7574363 Bodin Aug 2009 B2
7574386 Hahn-Carlson et al. Aug 2009 B2
7587363 Cataline et al. Sep 2009 B2
7590575 Yu et al. Sep 2009 B2
7617146 Keaton et al. Nov 2009 B2
7627499 Hahn-Carlson Dec 2009 B2
7634455 Keene et al. Dec 2009 B1
7640195 Von Zimmermann et al. Dec 2009 B2
7660788 Clark Feb 2010 B1
7693791 Hahn-Carlson et al. Apr 2010 B2
7702563 Balson et al. Apr 2010 B2
7725372 Hahn-Carlson May 2010 B2
7765136 Northington et al. Jul 2010 B2
7822653 Hahn-Carlson et al. Oct 2010 B2
7890395 Phelan Feb 2011 B2
7925551 Hahn-Carlson et al. Apr 2011 B2
7970671 Hahn-Carlson et al. Jun 2011 B2
8050938 Green et al. Nov 2011 B1
8060410 Hahn-Carlson Nov 2011 B2
8069054 Hahn-Carlson et al. Nov 2011 B2
8103575 Hinkle Jan 2012 B1
8126785 Hahn-Carlson et al. Feb 2012 B2
20010009002 Logan et al. Jul 2001 A1
20010011241 Nemzow Aug 2001 A1
20010014878 Mitra Aug 2001 A1
20010025262 Ahmed Sep 2001 A1
20010032154 Schummer Oct 2001 A1
20010032171 Brink et al. Oct 2001 A1
20010032183 Landry Oct 2001 A1
20010039522 Saxon Nov 2001 A1
20010047311 Singh Nov 2001 A1
20010056395 Khan Dec 2001 A1
20020007302 Work et al. Jan 2002 A1
20020016765 Sacks et al. Feb 2002 A1
20020026374 Moneymaker et al. Feb 2002 A1
20020032649 Selvarajan Mar 2002 A1
20020035488 Aquila et al. Mar 2002 A1
20020038277 Yuan Mar 2002 A1
20020038305 Bahl et al. Mar 2002 A1
20020040304 Shenoy et al. Apr 2002 A1
20020042782 Albazz et al. Apr 2002 A1
20020046081 Albazz et al. Apr 2002 A1
20020046125 Speicher et al. Apr 2002 A1
20020046147 Livesay et al. Apr 2002 A1
20020046169 Keresman et al. Apr 2002 A1
20020048369 Ginter et al. Apr 2002 A1
20020049622 Lettich et al. Apr 2002 A1
20020055850 Powell et al. May 2002 A1
20020059122 Inoue et al. May 2002 A1
20020059134 Ebbs et al. May 2002 A1
20020062278 Ingram et al. May 2002 A1
20020065736 Willner et al. May 2002 A1
20020065738 Riggs et al. May 2002 A1
20020069177 Carrott et al. Jun 2002 A1
20020072956 Willems et al. Jun 2002 A1
20020077978 O'Leary et al. Jun 2002 A1
20020087344 Billings et al. Jul 2002 A1
20020087455 Tsagarakis Jul 2002 A1
20020095355 Walker et al. Jul 2002 A1
20020103661 Albazz et al. Aug 2002 A1
20020107761 Kark et al. Aug 2002 A1
20020107794 Furphy et al. Aug 2002 A1
20020111886 Chenevich et al. Aug 2002 A1
20020116288 Nakajima Aug 2002 A1
20020116334 Bennett et al. Aug 2002 A1
20020116348 Phillips et al. Aug 2002 A1
20020120570 Loy Aug 2002 A1
20020123919 Brockman et al. Sep 2002 A1
20020123973 Eccles et al. Sep 2002 A1
20020143858 Teague et al. Oct 2002 A1
20020147655 Say Oct 2002 A1
20020156797 Lee et al. Oct 2002 A1
20020161719 Manning et al. Oct 2002 A1
20020174034 Au et al. Nov 2002 A1
20020184527 Chun et al. Dec 2002 A1
20020194174 Calkins et al. Dec 2002 A1
20020198829 Ludwig et al. Dec 2002 A1
20020198833 Wohlstadter Dec 2002 A1
20030004823 Sagy Jan 2003 A1
20030005876 Boswell Jan 2003 A1
20030014325 Biffar et al. Jan 2003 A1
20030018563 Kilgour et al. Jan 2003 A1
20030026404 Joyce et al. Feb 2003 A1
20030033205 Nowers et al. Feb 2003 A1
20030033240 Balson et al. Feb 2003 A1
20030041008 Grey et al. Feb 2003 A1
20030046089 Menninger et al. Mar 2003 A1
20030050876 Tawara et al. Mar 2003 A1
20030055675 Klein Twennaar Mar 2003 A1
20030055779 Wolf Mar 2003 A1
20030055783 Cataline et al. Mar 2003 A1
20030074206 Hoffman et al. Apr 2003 A1
20030074298 Daum Apr 2003 A1
20030093320 Sullivan May 2003 A1
20030097318 Yu et al. May 2003 A1
20030115129 Feaver Jun 2003 A1
20030117446 Esposito-Ross et al. Jun 2003 A1
20030126047 Hollar et al. Jul 2003 A1
20030135425 Leavitt Jul 2003 A1
20030135435 Aharoni Jul 2003 A1
20030139985 Hollar et al. Jul 2003 A1
20030144901 Coultier et al. Jul 2003 A1
20030154163 Phillips et al. Aug 2003 A1
20030158811 Sanders et al. Aug 2003 A1
20030163431 Ginter et al. Aug 2003 A1
20030187796 Swift et al. Oct 2003 A1
20030191711 Jamison et al. Oct 2003 A1
20030195815 Li et al. Oct 2003 A1
20030200172 Randle Oct 2003 A1
20030200185 Huerta et al. Oct 2003 A1
20030212617 Stone et al. Nov 2003 A1
20030220863 Holm et al. Nov 2003 A1
20030225883 Greaves et al. Dec 2003 A1
20030233252 Haskell et al. Dec 2003 A1
20030233286 Hahn-Carlson et al. Dec 2003 A1
20030233292 Richey et al. Dec 2003 A1
20030233321 Scolini et al. Dec 2003 A1
20040010463 Hahn-Carlson et al. Jan 2004 A1
20040019562 Viberg Jan 2004 A1
20040034578 Oney et al. Feb 2004 A1
20040039696 Harmon et al. Feb 2004 A1
20040049446 Seljeseth Mar 2004 A1
20040068431 Smith et al. Apr 2004 A1
20040095237 Chen et al. May 2004 A1
20040098350 Labrou et al. May 2004 A1
20040098663 Rey et al. May 2004 A1
20040107123 Haffner et al. Jun 2004 A1
20040107125 Guheen et al. Jun 2004 A1
20040117383 Lee et al. Jun 2004 A1
20040123129 Ginter et al. Jun 2004 A1
20040139032 Rowan Jul 2004 A1
20040153389 Lortscher Aug 2004 A1
20040153403 Sadre Aug 2004 A1
20040153407 Club et al. Aug 2004 A1
20040158510 Fisher Aug 2004 A1
20040172360 Mabrey et al. Sep 2004 A1
20040172368 Johnson et al. Sep 2004 A1
20040181468 Harmon et al. Sep 2004 A1
20040184163 Nishioka et al. Sep 2004 A1
20040186806 Sinclair et al. Sep 2004 A1
20040187075 Maxham et al. Sep 2004 A1
20040201074 Khandros et al. Oct 2004 A1
20040225574 Arnold et al. Nov 2004 A1
20040230536 Fung et al. Nov 2004 A1
20040230601 Joao et al. Nov 2004 A1
20040243690 Hancock et al. Dec 2004 A1
20040254808 Bennett et al. Dec 2004 A1
20040260634 King et al. Dec 2004 A1
20050015332 Chen Jan 2005 A1
20050021363 Stimson et al. Jan 2005 A1
20050021527 Zhang et al. Jan 2005 A1
20050027613 Takekuma et al. Feb 2005 A1
20050027651 DeVault et al. Feb 2005 A1
20050033660 Solomon Feb 2005 A1
20050033760 Fuller et al. Feb 2005 A1
20050055306 Miller et al. Mar 2005 A1
20050075964 Quinn et al. Apr 2005 A1
20050119980 Kohavi et al. Jun 2005 A1
20050125260 Green et al. Jun 2005 A1
20050131839 Cordery et al. Jun 2005 A1
20050137947 Schaub et al. Jun 2005 A1
20050149378 Cyr et al. Jul 2005 A1
20050165699 Hahn-Carlson Jul 2005 A1
20050177435 Lidow Aug 2005 A1
20050177507 Bandych et al. Aug 2005 A1
20050192896 Hutchison et al. Sep 2005 A1
20050216368 Wechsel Sep 2005 A1
20050234820 MacKouse Oct 2005 A1
20050240592 Mamou et al. Oct 2005 A1
20050246192 Jauffred et al. Nov 2005 A1
20050251478 Yanavi Nov 2005 A1
20050256802 Ammermann et al. Nov 2005 A1
20050274792 Hahn-Carlson et al. Dec 2005 A1
20050278220 Hahn-Carlson et al. Dec 2005 A1
20050278221 Hahn-Carlson et al. Dec 2005 A1
20050278244 Yuan Dec 2005 A1
20050278251 Hahn-Carlson Dec 2005 A1
20050278255 Hahn-Carlson et al. Dec 2005 A1
20050283434 Hahn-Carlson et al. Dec 2005 A1
20050283437 McRae et al. Dec 2005 A1
20050289023 Hahn-Carlson et al. Dec 2005 A1
20050289024 Hahn-Carlson Dec 2005 A1
20060004670 McKenney et al. Jan 2006 A1
20060010058 D'Hers et al. Jan 2006 A1
20060015454 Hahn-Carlson Jan 2006 A1
20060036476 Klem Feb 2006 A1
20060116957 May et al. Jun 2006 A1
20060167762 Hahn-Carlson Jul 2006 A1
20060167791 Hahn-Carlson Jul 2006 A1
20060167792 Hahn-Carlson Jul 2006 A1
20060233334 Bingaman et al. Oct 2006 A1
20060287953 Chauhan Dec 2006 A1
20070022021 Walker et al. Jan 2007 A1
20070055582 Hahn-Carlson Mar 2007 A1
20070136278 Grazioli et al. Jun 2007 A1
20070156584 Barnes et al. Jul 2007 A1
20070192178 Fung et al. Aug 2007 A1
20070208635 Van Luchene et al. Sep 2007 A1
20070214065 Kahlon et al. Sep 2007 A1
20070214077 Barnes et al. Sep 2007 A1
20070246528 Kubo et al. Oct 2007 A1
20070262140 Long Nov 2007 A1
20070271160 Stone et al. Nov 2007 A1
20070282724 Barnes et al. Dec 2007 A1
20070282744 Barnes et al. Dec 2007 A1
20070299769 Fowler et al. Dec 2007 A1
20080082374 Kennis et al. Apr 2008 A1
20080086396 Hahn-Carlson Apr 2008 A1
20080103972 Lanc May 2008 A1
20080172314 Hahn-Carlson Jul 2008 A1
20080215456 West et al. Sep 2008 A1
20080249940 Hahn-Carlson et al. Oct 2008 A1
20090171727 Hahn-Carlson Jul 2009 A1
20090192922 Hahn-Carlson Jul 2009 A1
20090259576 Hahn-Carlson Oct 2009 A1
20090265274 Hahn-Carlson et al. Oct 2009 A1
20090287590 Hahn-Carlson Nov 2009 A1
20090287598 Hahn-Carlson Nov 2009 A1
20090292630 Hahn-Carlson et al. Nov 2009 A1
20090307114 Hahn-Carlson Dec 2009 A1
20100017315 Hahn-Carlson Jan 2010 A1
20100049650 Keaton et al. Feb 2010 A1
20100070397 Hahn-Carlson et al. Mar 2010 A1
20100138325 Hahn-Carlson Jun 2010 A1
20100185540 Hahn-Carlson et al. Jul 2010 A1
20100205054 Hahn-Carlson et al. Aug 2010 A1
20110004544 Baum Jan 2011 A1
20110029404 Hahn-Carlson et al. Feb 2011 A1
20120158558 Hahn-Carlson et al. Jun 2012 A1
Foreign Referenced Citations (21)
Number Date Country
0339850 Feb 1989 EP
0407026 Jan 1991 EP
0425421 May 1991 EP
0779587 Jun 1997 EP
2543327 Sep 1984 FR
2398894 Sep 2004 GB
2001312680 Nov 2001 JP
WO 9707468 Feb 1997 WO
WO 9908218 Feb 1999 WO
WO 0062225 Oct 2000 WO
WO 0109782 Feb 2001 WO
WO 0135570 May 2001 WO
WO 0148659 Jul 2001 WO
WO 0182193 Nov 2001 WO
WO 0188813 Nov 2001 WO
WO 0126017 Dec 2001 WO
WO 02021405 Mar 2002 WO
WO 02006920 Sep 2002 WO
WO 2005124635 Dec 2005 WO
WO 2006071881 Jul 2006 WO
WO 2008045793 Apr 2008 WO
Non-Patent Literature Citations (21)
Entry
Spencer et al., “JIT Systems and external logistics suppliers ,” International Journal of Operations & Production Management, v14, n6, pp. 60-74, 1994.
White, How Computers Work, Sep. 1999, 93 pp.
Professional Builder (1993) www.highbeam.com, Contracts & Law: Part III, 8 pp.
South China Morning Post, Hong Kong, Buying “Products over the Net,” Jul. 2000, 2 pp.
Xcitek Press Release, “U.S. Bank Selects Xcitek for Corporate Actions Data and XSP for Corporate Actions Automation,” NY, NY, Dec. 2003, 1 pp.
Berhad, “Fueling financial oil for the economy,” The New Straits Times Press (Malaysia), Dec. 10, 2001, 3 pp.
Singh, “A new road to recovery,” Risk, pp. 108-110, Sep. 2004.
“Credit Derivatives and Mortgage-backed Bonds in Capital Adequacy Requirements for Market Risk,” http://www.rahoitustarkastus.fi/Eng/Regulation/FSA—standards/FSA—interpretations/4—2005.html, Apr. 2005, 5 pp.
Brochure: SAP Supplier Relationship Management—At a Glance, SAP, 2003, 16 pp.
Brochure: Self-Service Procurement: Slashing Costs and Saving Time, SAP, 2003, 12 pp.
Electronic Commerce News, “Sarbanes-Oxley Continue to be Key Issue in Corporate Payments Space,” Sep. 1, 2003, v8, issue 18, 7 pp.
Fletcher, “Limits on reinsurance offsets sought by California regulator,” Business Insurance, May 8, 1995 4 pp.
Denver Business Wire, “JD Edwards Continues to drive network-centric applications delivery with OneWorld enhancements,” Jun. 16, 1997, p. 06160089.
Notice from the European Patent Office concerning business methods, dated Oct. 1, 2007, 2 pp.
Egan, “Administrative Orders from the Office of the Governer of Alaska,” Jul. 18, 1972, 3 pp. http://www.gov.state.ak.us/admin-orders/018.html.
Bodnar, “Estimating Exchange Rate Exposure: Issues in Model Structure,” Financial Management v32, n1, pp. 35-67, 2003.
Plewka, “Germany seizes the Emu initiative,” International Tax Review, v8, n5, pp. 43-46, May 1997.
Huang, “Exchange Risk and Exchange Rate Pass-Through,” v67/02-A of Dissertation Abstracts International, 2005.
McKeefry, “Seeking microcontrollers desperately,” Electronic Buyers News, n972, Sep. 11, 1995, 6 pp.
Mallory, Great Plains Accounting v.7 (Great Plains Software's accounting software) (Product Accouncement), Apr. 22, 1993, 3 pp.
Russell, “Kitting out is now in (Use of component kits is expanding as distributors develop added-value activities),” Electronic Times (online), n 852, Apr. 17, 1997, 4 pp.
Continuation in Parts (2)
Number Date Country
Parent 09259657 Feb 1999 US
Child 09527717 US
Parent 09310711 May 1999 US
Child 09259657 US