Computerized Parcel Shipping System

This invention is directed to improvements in parcel shipping systems wherein parcels to be shipped are tracked or recorded, the invention being concerned with a system of this type wherein a computer is employed to record the transactions on a record medium such as a disc or the like.

In the shipping of parcels, it is frequently desirable to make provision for shipping by more than one carrier. In current shipping practice, provision must be made for the shipping of parcels by two major carriers, such as the United States Postal System (USPS) and the United Parcel Service (UPS), a private carrier, as well as any of a large number of smaller private carriers. In prior tracking or recording systems, various data concerning parcels or groups of parcels to be shipped were entered by an operator, so that the information could be stored in the records of a transaction disc. The "transactions" recorded on the transacting disc include information relating to the shipment, such as, for example, the identification of the carrier, the number of packages in the shipment, the weight, address data, charges, date and time, invoice number, etc. Factors such as weight were entered either manually or automatically by a scale, while other factors such as zip code were generally entered by an operator by way of a keyboard. Such systems contemplated the provision in the programs of routines that determined shipping costs on the basis of the information that was input.

With respect to the major carriers, prior systems made provision for the reservation of space on the transaction disk for each carrier. With respect to such major carrier, it is conventionally the practice to provide a pickup of all parcels at given times, so that all of the transactions for that carrier could be achieved, i.e. stored on an archive disc and deleted from the transaction disk; as a block, to thereby enable the entry of further transactions. As an example, when the USPS picked up a shipment, the shipment generally included all current transactions recorded on the portion of the disc assigned to the USPS, so that archiving the data to an archive disc and deleting the data from the permanent portion of the disc reserved for the USPS was feasible and practical, and enabled the clearing of the relevant portion of the transaction disc for the entry of further transactions in a simple manner.

While UPS and USPS are currently the major carriers for many shippers, there are a large number of carriers that are frequently employed, and a versatile computerized parcel shipping system thereby requires the tracking or recording of data corresponding to shipments to be made by such other carriers. In view of the large number of such other carriers, however, it is not feasible to record the transactions in the same manner as for the major carriers. Thus, reserving a discrete block of disc memory adequate to handle each of the possible transactions concerning such other carriers is not feasible since insufficient memory exists on the discs for treating transactions concerning these smaller carriers in the same manner as the major carriers. Major shippers require the reservation of individually determinable record space for shipments by the major carriers, and adequate recording space may hence not exist for providing separate files of the necessary length for each of the additional carriers, for example, one to two hundred carriers whose services may be employed at various times.

The difficulty in tracking transactions of the other, or minor carriers, is further compounded by the fact that these minor carriers have varying pickup schedules, so that transactions relating to such minor carriers cannot be combined in a single file that is treated in the same manner as the files of the major carriers. In view of the different pickup schedules, for example, it is not possible to archive a complete combined file relating to the minor carriers, since at any given time it can be expected that at least a portion of such a combined file will be current.

The present invention is hence directed to the provision of an improved method and apparatus enabling the tracking and recording of transactions of both major and minor carriers in an efficient manner, and without requiring excessive storage space for the recording of the transactions.

Briefly stated, in accordance with the invention, the disc space of a transaction disc is alloted one or more files for recording the transactions of major carriers and an additional, or "carrier logging" , file alloted in common to all of the minor carriers. In this carrier logging file, the minor carriers are identified by number and the transactions with respect to these other carriers are recorded in records of predetermined length, for example, 80 bytes. As an example, in one embodiment of the invention this carrier logging file may carry record space for 1200 transactions.

In a further feature of the invention, a part of this carrier logging file includes two separate counters for each of the carriers handled by the file. One of the counters contains a count of the total number of transactions in the file relating to the respective carrier, and the other counter contains a total count of the transactions in the file relating to that carrier, which have been shipped. For example, record numbers 3-12 of the file may be reserved for the counters, the counters for each carrier being comprised of three bytes, with the counts being stored in compacted form to save memory space. The sequence of these counters, in the records of the file space, follows the sequence of predetermined identification numbers of the different carriers, so that the counts relating to any carrier can be recovered, or stored, on the basis of their position in the storage space. If desired, additional counters may be provided in the records of the file to store totals of the transactions of the individual carrier records.

The records of the carrier logging file which include the counters, may hence constitute a part of a file header. Additional records of the file, for example records 1 and 2, may include additional useful general data, such as the version of the program employed in recording and archiving, an archive flag, the total number of transactions in the file, the next available record, the last posting date, the last shipping date, the first transaction record, the lowest invoice number, the highest invoice number, etc.

In order that the invention may be more clearly understood, it will now be disclosed in more greater detail with reference to the accompanying drawings, wherein:

FIG. 1 is a block diagram of a computer manifest system that may be employed in the practice of the invention;

FIG. 2 is a flow diagram in accordance with the invention showing the archive logic;

FIG. 3 is a flow diagram in accordance with the invention showing the logic for transaction record counters and closed record counters;

FIG. 4 is a flow diagram showing the file update logic in accordance with the invention; and

FIG. 5 is a chart illustrating the assignment of transaction disc space in accordance with one example of the invention.

Referring now to FIG. 1, therein is illustrated a block diagram of a computer manifest system that may be employed in the practice of the invention. The system incorporates a microcomputer 10 having a first disc 11 containing the programs of the system and the various other data, such as rates, etc. The transactions are recorded on a second disc 12. The number of disc drives employed is a matter of choice, and hence provision is made by any conventional means for enabling archiving of the records on an archive disc, in accordance with a program of the invention. The microcomputer 10 is connected to a terminal 14 including a keyboard 16 for entering operator data and a display 15. The transactions may be recorded on a printer 17 connected to the microcomputer, and, if desired, the microcomputer may be adapted to print adhesive labels for the parcels in a printer 18. Further data input for the microcomputer, such as the weight of a parcel in a given transaction, is received from a platform scale 20 of conventional nature by way of an RS232 Interface 21. Further information for the microcomputer, relating to the parcels to be shipped, may be received from a wand 22 or the like also connected to the RS232 Interface. The scale 20 may also be interfaced to a printer 23 and an electronic postage meter 24 in conventional manner. The transducer 25 of the scale converts the weight of the parcel to electrical signals which are converted to digital form by the CPU 26 therein.

In use of the manifest system of FIG. 1, a parcel to be shipped is weighed by the scale 20 to provide weight information to be recorded on the transaction disc 12, other information for recording the transaction being input by way of the wand 22 and/or the keyboard 16 of the terminal. Data concerning the specific parcel may be printed by a printer 23, and the electronic postage meter 24 may be directed to print the required postage for the parcel. The microcomputer 10 may control the printing of an adhesive label for the parcel by way of the printer 18. The printer 18 may be conventionally employed to provide a complete record of transactions that have occurred, based upon data recorded on the transaction disc 12.

In accordance with the invention, the program of the microcomputer 10 is adapted to record transactions on the transaction disc 12 in one or more major carrier files, such as, for example, a file for the USPS or a file for UPS, and a carrier logging file on which transactions of a plurality of minor carriers are recorded. The major carrier files may be formatted in any convenient manner, the program treating each of these files as a common block for archiving and deleting of data.

The carrier logging file includes space for a determined number of records, for example, 1200 80-byte records, as well as a header including various data for the file and a pair of counters for each minor carrier whose transactions will be recorded in the file. The counters are preferably arranged sequentially in accordance with arbitrary identifying numbers assigned to the carriers, so that the counters for any carrier may be readily located. The records of the transactions in this file include, in addition to data necessary to record the transaction, the identification of the carrier to be employed for shipment of the parcel, and the status of the transaction i.e. whether or not the parcel has been shipped.

The counters assigned to each carrier record the total number of transaction records in the file associated with that carrier, and the number of closed transaction records in the file associated with that carrier. For example, the first counter assigned to carrier A counts the total number Ct(A) of transaction records in the file associated with the carrier A. The second counter assigned to the carrier A counts the number Cc(A) of closed transaction records associated with that carrier A, i.e. transaction records which describe parcels that have been shipped by carrier A. It is thus apparent that the number Ca(A) of active transaction records associated with carrier A, i.e. transaction records assigned to carrier A but which have not yet been picked up by carrier A for shipment, is equal to Ct(A) - Cc(A). The counters in the file header of the carrier logging file enable the selective archiving and data handling in accordance with the invention in a simple and effective manner.

For example, the provision of the counters as above described enable the archiving of records in the file relating to a given carrier, without disturbing records relating to other carriers, so that records of transactions relating to shipped parcels may be deleted and the space used in the recording of further transactions, while not interfering with records of transactions of other carriers not yet shipped. When record space has thus been deleted, it can of course be employed for the recording of further transactions in response to a test of the information in the record.

FIG. 2 shows a method in accordance with the invention for archiving records of the carrier logging file. As shown in FIG. 2, at block 100 the headers of the file are interrogated to obtain the counts Cc(A) and Ct(A) for a given carrier A. If a count Cc(A) is equal to zero, i.e., if there are no closed transaction records in the file associated with carrier A, as tested at block 101, a message routine 102 is invoked to advise the operator that there are no records present for that carrier that require archiving.

If closed transaction records are present for that carrier, however, a record counter is set to zero at block 103. The first transaction is then read at block 104. If an end of file was not found at block 105, a test is then made to determine if the transaction record that was read pertained to the specific carrier A, and, if so, if the transaction record that was read was closed, at block 106. If either of these tests is untrue, the program loops back to read the next transaction record. If both tests were true, however, the transaction record is written to the archive disc at block 107, and the record counter is incremented at block 108. The program then loops back to read the next transaction record. When the end of file has been found at block 105, a test is made at block 109 to determine if the total number of closed transaction records Cc(A) is equal to the record counter. If it is, a normal exit is made from the program at block 110. Otherwise, an error message indicating the inequality is given at block 111.

The program of FIG. 2 hence archives the closed transaction records of a given carrier in a simple and efficient manner. The program of FIG. 2 preferably also purges archived closed records from the carrier logging file. This may be effected, for example, in the exit routine 110, at which time Cc(A) is cleared (set to 0) and Ct(A) is updated. The program thus enables archiving the closed records of any given carrier so that the record space may be subsequently employed for recording a transaction therein of any desired carrier in the carrier logging file, without interfering with transaction records that have not been archived.

The archiving may be preceded by an initial determination if adequate space exists on the archive disk for archiving the closed transaction records. Thus, the Cc(A) counters provide an indication of the amount of memory needed to archive the closed transaction records of a given carrier, thereby enabling the simple comparison of the required space with the actual space remaining on the archive disk (which may be conveniently stored at any desirable location). The counts stored in the counters of the carrier logging file may also be conveniently employed for the determination of the amount of RAM memory that will be required for sorting of the records of the carrier logging file, by comparison of the required space as indicated by the stored counts and the amount of RAM memory that is in fact available.

FIG. 3 is a flow diagram in accordance with the invention for archiving and purging transaction records, and updating the counters (Ct and Cc) associated with a given carrier. As illustrated in FIG. 3, the counts Ct and Cc corresponding to a given carrier are read from the file header at block 200, and the total number Cc of closed transaction records is tested at block 201. If no such closed transaction records exist, indicating that the transaction records for that carrier are up-to-date, the program exits at block 202. Otherwise, the sum Ca of open (active) and closed records for the carrier is computed at block 203. The first transaction record, or next transaction record, is read at block 204, and if no end of file is found at block 205 at 206, a test is made if the read transaction record corresponds to that carrier. If not, the program loops back to read the next transaction record in the file. If, on the other hand, the read transaction record does pertain to the given carrier, the program next tests to determine if the transaction record is closed. If the transaction record is not closed, the record is saved in the carrier logging file at block 208 and the program loops back to read the next transaction file. Otherwise, it is apparent that the transaction record must be archived and the record purged from the carrier logging file as indicated at block 209. Following any steps that have been determined desirable in block 209, the program loops back to read the next transaction record.

If an end of file is found at block 205, the count Ct of total records for that carrier is replaced by the calculated count Ca, and the number Cc of closed transaction records indicated in the counter and the file header is reset to zero, at block 210. The program then exits normally at block 211.

In the file update routine of FIG. 4, the file header is read at block 301 to retrieve a number Cc of closed transaction records and the number Ct of total transaction records for that carrier, and the total number Ca of active transaction records is calculated at block 302, with a record counter being set to zero. The first transaction record is read at block 303 and tested for an end of file at block 304. If it is not the end of the file, a test is made at block 305 to determine if the record is closed. If the record is closed, the program looks back to read the next transaction record. If the record is open (active), however, it is written to a temporary .SAV file on the transaction disk in block 306, and the record counter is incremented at block 307, the program then looping back to read the next transaction record.

When an end of file has been detected, a test is made at block 308 to determine if the calculated sum Ca is equal to the number in the record counter of active transaction records. If the counts are equal, a normal exit is provided at block 309. Otherwise, an error message routine is invoked at block 310.

The program of FIG. 4 thus searches for all open transaction records of the carrier, and writes all of such open transaction records to memory.

One example of the organization of data in the records of the carrier logging file is illustrated in Table I.

As illustrated in Table I, the first byte of the record may store a Flag indicative of the states of the record, i.e. whether it is an active (open) record or whether it is a closed record with the related parcel having been shipped. The second byte of the record identifies the carrier numerically. Accordingly, the record contains information, which when accessed, enables the determination the status of the record, the related carrier number, and any further information that is needed to be recorded with respect to the transaction. It is of course apparent that other formats of data may be employed in the records and that the selection of a record length of 80 bytes is exemplary only. As discussed above, in the example of the invention, the first and second records may contain various useful information for the carrier logging file, such as the version number of the program employed in recording the data, an archive flag indicating if records can be archived, a status flag indicating if the file contains current data, a number indicating the next available record for recording, the last posting date that was used in the file, the last shipment date of a shipment recorded in the file, the location of the first transaction record in the file, the lowest invoice number of any transaction recorded in the file, the highest invoice number of any transaction recorded in the file, and any other useful general information as needed. The third through twelfth record of the file are reserved in accordance with this embodiment of the invention for the counters for the different carriers. It is of course apparent that the number and location of the records for the general information and counters may be varied as desired, the specific example given herein not being limiting.

Continuing with the above discussed example, with ten 80 byte records assigned as counters, the counters for each carrier associated with the file may be comprised of three contiguous fields, the groups of fields being assigned numerically sequentially in accordance with the identification numbers of the carriers so that the counters associated with each carrier can be readily located. In order to simplify indexing, so that each counter appears fully in a record, it is desirable to employ only 78 of the 80 bytes of each record. The records may hence be accessed by simple "put" and "get" instructions. In order to increase the possible count in each counter, the counts may be stored in condensed form in the three fields of the associated carrier, in accordance with any conventional algorithm. The two counters associated with each carrier may hence not be defined by discrete separate storage space.

FIG. 5 illustrates the distribution of records for different carriers on a 700 kilobyte disk in accordance with one embodiment of the subject invention. Files 400 and 410, relating to UPS and USPS transactions respectively, are of a conventional nature and form no part of the subject invention per se and will not be described further here. File 420 is a carrier logging file in accordance with the subject invention as described above. File 420 includes: 2 80 byte records as files one and two for storing additional useful general data such as the program version employed, the archive flag, the total number of transactions in the file, etc.; 10 80 byte records reserved for counters for each minor carrier and 1200 80 byte transaction records. File 430 is a duplicate file used as a temporary file during the file update procedure of FIG. 3 as described above. In accordance with the subject invention upon completion of the file update procedure the names of files 420 and 430 are interchanged to complete the update and provide a new temporary file.

While the invention has been disclosed and described with reference to a limited number of embodiments it is apparent that variations and modifications may be made therein and is therefore intended in the following claims to cover each such variation and modification as falls within the true spirit and scope of the invention.