HK1022967B - Apparatus for issuing documents of value - Google Patents

Description

Device for producing value documents

This invention relates to a dispenser for value deeds, and in particular to an apparatus and method for automatically generating negotiable instruments.

Distribution instrument dispensers, such as money order dispensers, are well known and the money order dispenser ("MODS"), also known as "automatic money order dispenser" or "AMARDS" or "RMODS" or "Deltas", are suitable for distributing and selling money orders in a wide range of convenient locations. MODS, for example, are commonly located in convenience stores, check and cash agencies, food stores, financial institutions, and other retail and service outlets. The issuing entity of the money order typically authorizes an agent (e.g., grocery store) to operate the MOD at each location.

When a MOD is installed in a particular location, a blank draft form (which is a negotiable instrument, sometimes referred to as a negotiable stock) is periodically loaded into a compartment within the MOD. When a customer purchases a money order, the operator enters the corresponding information (e.g., quantity), and the MOD then prints the information on the money order form and issues the complete money order. The tables are typically numbered sequentially, and when a MOD is loaded, the operator loading the tables enters the serial number of the first set of tables. When a money order is purchased, the MOD increments a count to record which form is printed. Such MOD machines also provide MOD run reports, either electronically or in printed form.

Issuers typically must strictly manage their MOD machines. MODs typically include some mechanical components and thus typically fail. And each MOD includes currency notes for the issuer to undertake financial debts. To facilitate management of the widely used MOD machine system, the MOD machine should have the following features.

The MOD machine should be user friendly, with little or no technical training on the personnel (e.g., convenience store staff) operating the MOD machine, and good interface is more important for a large number of employees at an establishment (e.g., a retail store) operating a MOD machine (e.g., a retail chain). Training of each person operating an MOD machine is impractical for the issuer. Unfortunately, many conventional MOD machines are not easy to use, such as installing a stock in a MOD machine, which is generally difficult. Conventional MOD machines are often bulky and difficult to install.

The MOD machine should also include security features to prevent unauthorized use and reduce the risk of counterfeit money orders. Most conventional MODs have relatively basic and limited security measures. Such as a compartment containing a blank currency note, is locked and only unlocked by a key. This security measure may prevent some unauthorized access, but is free to access for anyone holding the key. It also does not provide any record of the person accessing the negotiable instrument, nor does it record which operations were performed in this visit. Therefore, it is difficult to timely determine whether the data is deleted or not and whether a misuse condition occurs.

The MODS should have a mechanism by which the issuer can monitor MOD usage. Most conventional MOD machines are provided with mechanisms that provide easy monitoring and must rely on information provided by the user to the issuer or the device itself. For example, a conventional MOD machine does not verify the sequence of items occurring during the sale process, but only relies on the initial data input by the operator as described above, and when the deed is not in sequence, the MOD machine records the desired serial number and cannot verify the corresponding deed being printed.

Some MODs use the original sequence check technique, i.e. every third contract contains a recognizable, detectable mark (i.e. a sequence mark). When MOD detects a sequence number, it is determined whether the credit value is divisible by 3. If so, the deem is in the sequence. The disadvantage of this technique is that all types of sequence errors cannot be found. For example, the system will not detect this problem by removing 3 consecutive deeds from the sequence.

Also, prior art devices may require the issuer to actually check the MOD, obtain various types of information or use techniques such as making very large hypothetical sequence notations. Conventional MOD machines typically require either a reconciliation report to be printed on a blank draft form or require an additional purchase of a printer. These reports are either difficult to understand, have poor format, require the use of a blank currency document, or require additional hardware purchase.

In summary, it is desirable to devise a better system for issuing written deeds than previous systems.

This invention provides an advanced system for issuing value deeds. Embodiments of the present invention provide a more convenient, secure and efficient means for issuing currency notes, or other value notes, that can also be used in loading, selling, reporting and dispenser-related situations.

Embodiments of the present invention have many advantages, including the following:

(I) an account is allowed for each instrument in the printer for which an audit trail is to be made.

(ii) Allowing easy loading of the machine, facilitating the decision of what to load.

(iii) And (4) the method is user-friendly.

(iv) Providing secure storage of money orders.

(v) And manual saving and document work are reduced.

(vi) A report of all transactions may be printed daily.

(vii) Providing rapid and efficient money order printing.

(viii) Allowing the use of standard bar code, MICR and/or OCR techniques.

(ix) An audit can be traced of who and when the printer was accessed.

Numerous advantages of the present invention will be apparent to those skilled in the art in view of the disclosure herein.

A full appreciation of the invention can be gained by taking the following detailed description in conjunction with the accompanying drawings.

Figure 1 illustrates one embodiment of a negotiable instrument dispenser according to the present invention.

Fig. 2(a)2(b)2(c) and 2(d) show a flow chart of a contract loading process of a negotiable instrument dispenser according to an example of the present invention.

Fig. 3(a)3(b)3(c) and 3(d) illustrate a flow chart of a sales or vendor payment process using a currency note dispenser, according to an example of the present invention.

Figure 4 illustrates a flow chart of an exemplary power cycle for a currency note dispenser in accordance with the present invention.

Fig. 5 shows a flow chart of an exemplary download notification and callback process according to the present invention.

In a preferred embodiment of the invention, the operator uses a control terminal to operate a distribution of deeds, particularly a currency ticket distributor, thereby providing a more convenient, secure and user-friendly and efficient means for loading, selling and reporting information relating to currency deeds. The control terminal is connected to the printer and the safe with the circulating stock. A signal is sent to print the money order and if necessary, the safe can be opened and the blank money order form is packaged (using MICR, OCK or other encoding techniques) in a predefined package with a bar code serial number and stored in the security unit of the printer. The control terminal keeps track of which deeds are printed and other information used. The activity of the negotiable instrument dispenser is automatically recorded in an "electronic log" (memory) by the control terminal and the record is periodically reported to the central computer.

Figure 1 shows an example of an automated draft dispenser embodying the present invention. (see fig. 1) MOD10 includes 2 independent parts: the control terminal 12 and printer/safe 14 are installed at an agent/user site by simply connecting the two together and connecting them to telephone lines for data transmission and to a power outlet for power.

The control terminal has 3 main functions 1) to communicate with the central computer (i.e. host) of the issuer; 2) controlling the printer/safe 14 according to predefined rules and user instructions; 3) controlling all other system behaviors. From the user's perspective, it includes a keypad 16, a display 18, and an optional telephone handset 20. MOD10 uses a conventional telephone line to transmit data to a central computer to quickly and efficiently maintain records. The control terminal 12 also records in its memory a "log" or activity log of information that tracks usage, as will be discussed further herein.

The control terminal 12 tracks all transactions until information is automatically "uploaded" to a host located at the issuer central control facility at the end of each work day or at various times during each work day. Transaction data is preferably stored in internal non-volatile memory (either by battery backed-up volatile memory or conventional non-volatile memory). The control terminal also contains conventional programmable processor hardware, programmed to perform the processes to be described below:

the operator initiates any transaction with MOD10 using keypad 16 located on control terminal 12. The steps that must be completed for each transaction are relatively simple. The instructions to complete all transactions are described in the guidelines provided to the agent.

The operator enters commands by pressing keys on the keypad 16. The keypad 16 has 3 types of keys.

(1) Function keys. These keys are used to initiate the type of transaction desired (e.g., sell, invalidate, report, cancel, etc.)

(2) A number key. From "0" to "9" are numeric keys that can be pressed by the user when the user desires to enter a number or code.

(3) Alphanumeric keys. These keys are used for vendor payment transactions. The keypad 16 may be implemented by one skilled in the art using any conventional keyboard technology, including, for example, soft key technology.

The display 18 provides important information to the user, and prompts the user at each step of each procedure, which may be accomplished using alphanumeric display technology.

The display 18 is typically located in a "status screen," which is the starting point for all functions available to all terminals. If the display screen shows different information before the user begins the transaction, or if the user is confused in the transaction, the user can return to the status screen by pressing "CANCEL". The status screen displays the current time and date, the contract data in the printer, and the number of transactions for different product applications on the same terminal in the file for the current day. (e.g., money orders, remittance, phone cards, payroll, and gift certificates).

The printer/safe 14 preferably includes a printer portion consisting of a conventional MOD printer and a safe locked to the printer. The blank money order is stored in the safe portion of the printer/safe 14 and the printer/safe 14 is activated by the control terminal 12. The money orders are printed out automatically in the stated number by the control terminal 12 and transmitted to the operator by commands entered by the operator. The printer 14 preferably includes a bar code reader and the blank draft forms are preferably bar coded, MICR technology being used for this purpose in a conventional manner. It is clear that conventional OCK technology can also meet the requirements.

1 Loading procedure

In order for the system to determine whether a blank contract is in the beginning, middle or back of a pack of contracts, the blank contracts are packed in a predetermined number (e.g., 400 contracts), the pack is given a starting sequence number (e.g., 400, 800, 1200, etc.), and the remaining contracts are arranged in sequence (e.g., 400-799 in a pack). The system can determine the location of a particular compact in a package and also know how many compacts are in the package.

The printer/safe 14 of MOD10 is installed in the agent/user area along with the circulating stock. At installation, the terminal requires a security number, which the user can enter through the terminal 12, and only after the security number is verified is installation authorized. If the user is currently authorized to install, the control terminal 12 sends a signal to the printer/safe 14 to open the safe (typically using a solenoid or conventional electromechanical lock) and disconnect it from the printer so that the user can move the safe. The display 18 prompts the user to move the safe. If the user fails to remove the safe within the prescribed time, the printer unit will relock the safe. If the authorization code is not re-entered, the safe cannot be re-entered.

When the safe is removed from the printer unit, the user may place a package of currency notes into the safe and reconnect the safe to the printer. When the two are reconnected, the control terminal 12 signals the printer to load the first form of the signature and read the bar code pre-printed on the signature. The pre-printed bar code preferably includes numbers or letters. After reading the pre-printed bar code, the printer sends the data (or letters or alphanumerics) to the control terminal 12, and the control terminal 12 determines whether the returned value is correct and gives an appropriate response.

As will become more apparent, the printer begins installing a list after the control terminal 12 sends a load list to the printer and reads the pre-printed bar code. If the head of the contract is not recognized, the printer tells the control terminal that no contract is recognized. The control terminal displays error information that no deed is detected, and requires the user to reload deed.

When the head of the receipt is recognized, the printer checks the receipt lower edge indicating the position of the barcode printed in advance, and if the lower edge cannot be positioned within a predetermined number of steps, the printer returns information that the barcode cannot be found to the control terminal 12. The terminal display shows that the wrong information is loaded, requiring the user to reload the form. In this way, the terminal can identify whether the compact is inverted or inverted. The control terminal 12 will send a signal to the printer to return the form to the vault.

Once the bottom bar is checked, the printer attempts to read the pre-printed bar code on the form. If the bar code data is successfully read, the printer returns the corresponding value to the terminal. The terminal calculates the residual number of the package deems that the user puts in a complete package or only a part of the package deems that the data format is correct or not. The terminal verifies that the value passes the corresponding bit check, and displays the information that the loading has been successful to the user. Signals the printer to return the form to the safe and enters the relevant contents in the job record (e.g. who has turned the printer on, when, fully loaded or partially loaded).

Once the key is read, the control terminal 12 compares the current serial number with the desired serial number. If they are different, the terminal then determines whether the current sequence number is in the same packet as the desired sequence number. If in the same packet, the terminal records in its memory a sequence number or a range of sequence numbers indicating that these items have been lost from the packet. If not in the same packet, the terminal records the loss range from the desired sequence number to the end sequence number of the packet. The terminal will also determine if there is a missing entry in the packet starting with the current sequence number. If an entry from the new packet to the current sequence number is lost, the terminal will record the loss of the sequence number from the start sequence number of the new packet to the current sequence number.

The terminal also determines whether the current sequence number is the beginning of a packet, or is an intermediate portion of a packet, or whether the sequence number has already been entered in the working record. If the current item is at the start of a new package, the terminal records that the entire package has been loaded, (if the current item is in the middle of a package, the terminal records that a portion of the package has been loaded), e.g., the sequence number was recorded in the working log, the compact is printed "invalid" to indicate obsolescence, and the process is logged to the working log.

The process of loading the compact is described in detail in connection with fig. 2(a) -2 (d).

2. Issue(s)

When issuing the circulation contract, the terminal sends a signal to the printer 14 to load a sheet, and the printer 14 subsequently loads a sheet. If the beginning of the ticket is not recognized within a specified number of printer steps, the printer will tell the terminal that the ticket was not found. The terminal displays error information without fitting, and requests the user to fit a new form or replay the current form. The terminal signals the printer to remove the signature and return it to the safe.

Once the beginning portion is identified, the printer checks for a lower edge bar indicating the location of the preprinted bar. If the lower bar is not detected within the specified number of steps, the printer returns a message to the terminal indicating that the lower bar is not found, and the terminal displays information that the barcode is not found in the form and requests the user to reload the form. The terminal signals the printer to return the escrow to the vault.

Once the bottom bar is detected, the printer performs the predetermined steps and reads the pre-printed bar code on the form. If the bar code is read out, the printer sends the corresponding value to the terminal. And the terminal corrects whether the bar code format is correct or not and verifies that the data passes all corresponding bit verification. The terminal also compares the current sequence number with the desired sequence number, if they are different, the terminal determines if they are in the same packet, if they are, the terminal records the loss range from the desired sequence number to the last sequence number of the packet. The terminal checks in the packet whether there are missing items starting from the current sequence number. If there is an entry loss from the new packet to the current sequence number, the terminal will record the loss range from the starting sequence number of the new packet to the current sequence number.

If the barcode is not read within the specified number of steps, the printer notifies the terminal that no value has been obtained from the pre-printed barcode. The terminal displays an error message that the "barcode is unreadable" and then sends a signal to the printer to print an "invalid" word on the remainder of the item and record the desired serial number as invalid. The terminal then instructs the printer to load a form to attempt the transaction. This process continues until a readable form is identified in the printer or a predetermined number of entries are invalidated from being read.

When a readable form is identified, the control terminal instructs the printer to print the specified data on the bond and make the appropriate log record, MOD then dispatches the bond.

The distribution circulation bond will be further described with reference to FIGS. 3(a) -3(b)

3. Other features

The control terminal records a series of security codes and related rights in the memory. The control terminal allows the user to define a security profile with uniquely configurable permissions to increase the flexibility of device security. For example, some operators may perform all functions while others may only allow some functions to be performed, such as sold or disabled.

In the case of vendor payment, the draft is used to pay the vendor of the agent, and this option is given to certain agents who are authorized to allow employees to pay the vendor without having to prepare large amounts of cash in advance. If the agent is authorized for this alternative vendor payment method, the operator can use the letter keys to enter any vendor name in the plurality of systems. In other systems, the operator is limited to selecting only certain predetermined vendor names. In this system, vendor names are stored in the terminal's memory for printing on a line of the recipient of the circulation contract.

The memory of the control terminal 12 records a billing list associated with the dollar value range. The user may configure the terminal to calculate the charge as a percentage of the desired amount or as a percentage of the account amount. The terminal will record 4 different price ranges associated with a charge.

The reading of the specific bar code for each item ensures the normal transaction processing for each item sold. The check for lost items allows for reliable audit trails.

The present invention uses software based on predetermined rules to unlock or lock the safe. For example, the safe may be opened only after the correct security code is entered. The software monitors the safe. If the safe cannot be unlocked within the set time, the safe can be locked again. This software locking/unlocking feature helps provide a tracking audit related to printer access. This flexible, fully configurable security parameter allows the user to define employee accessible rights operations.

The software determines the interruptions in the order of the deeds and registers them as missing items. These are printed on all reports as an early indication of possible fraud.

The security code that allows the operator to enter the sensitive application domain is dynamic. The algorithms based on the prior art are subject to change every day. Such an algorithm may be a function of the date or a predefined identification code. This prevents the agent from acquiring a day code when resolving the failure and reusing it at a later time.

The process of using bar code logic to load a contract is described in connection with fig. 2(a)2(b)2(c)2 (d).

Initially, the system is in idle mode, showing a "status" or blank screen, as shown at step 100. At step 102, the user enters a code (e.g., function "9") indicating that it is desired to load the compact into the printer/vault. The system displays the "enter user code" at step 104 and the user enters the user access code (single or multiple characters) at step 106. At step 108, the system determines whether the user has the right to load the deed (not all users have the right). If the user does not have this authority, the system will display the word "no entry" as shown in step 110 and then return to the empty screen as shown in step 112. If the system determines from the access code that the user is authorized to load the warranty at step 108, the warranty vault is opened at step 114 and the system indicates "printer unlocked, please remove m.o. vault" at step 116. At the same time, the system will log the relevant information.

After the above information is displayed, a configurable timer (typically 5 seconds) is set, as shown at step 118, allowing the user to move out of the safe. At step 120, the system senses whether the safe has been removed within a predetermined time. If not, the safe is relocked to the printer and the system returns to step 104 to instruct the user to re-enter his user code in the display and retry. If the user moves out of the safe as shown by step 122, the system displays "put money order, return to safe" at step 124. At step 126, the user places the warranty and returns the safe to the home position. The system will determine in step 128 whether the idle timer has timed out or whether the user has pressed the "cancel" key. If so, the system returns to the blank screen state again. If not, the system determines whether the safe is returned and if not returns to step 124, indicating that the user should load the money order. If the safe is returned, the system moves from node 132 (as shown in figures 2(a) and 2 (b)) to step 134.

At step 134, the compact is sent under the print head and the bar code is read. If the header of the ticket is not located at step 136, the system displays the "printer error-unreadable barcode" at step 138, returns the ticket to the vault (sets vault empty flag) at step 140, and returns to the empty screen at step 141.

If the start of the contract is detected at step 136, the system determines at step 142 whether the lower bar of the bar code has been positioned, and if not, displays at step 144 a "printer error-unreadable bar code" (or "no U-code found"), and moves to steps 140 and 141 as previously described. This detects evidence that it has not been properly placed (either upside down or reversed) in the printer or safe.

If the bottom bar has been positioned at step 142, the system will determine whether the bar code can be read correctly at 146. If not. The system will determine in step 148 whether the barcode exceeds a configurable predetermined retry limit, if not, return to step 134; if so, the system displays "Printer error-unreadable barcode" at step 150, and returns to steps 140 and 141, as previously described.

If at step 146 the system believes that the bar code has been read correctly, the system checks at step 152 to determine if the bar code d.o. number matches the predetermined number. (the D.O number is the first two digits of the contract sequence number). If there is no match, the system displays "Printer error-D.O. not match" at step 154 and returns to steps 140 and 141. If the two do match, the system checks at step 156 to determine if the detected bit is correct, e.g., incorrect, and the system displays "printer error-detected bit is incorrect" at step 158 and then returns to steps 140 and 141.

If the check bit is correct at step 156, the system will display "successful load in contract" at step 160, confirm that the safe flag is not set to null at step 162, and move from node 164 to step 166.

At step 166, the system determines whether the serial number of the instrument most recently issued as a draft is the last item in the previous bundle of instruments. If so, the system will determine at step 176 whether the new compact (the compact just read) is the first serial number of a package compact. If so, the system sends a "full pack" message to its memory (or called a work log) at step 178 and then returns to the blank screen state at step 180. If the current contract is not the first sequence number in the packet, the system will send a "partial load" message to the log at step 182 and move to step 186 by node 184.

If the system determines that the just-sent contract was not the last item in the previous packet at step 166, the system checks the memory at step 168 to determine if any items were lost in the previous packet. If no item is lost, step 176 is reached. If there was an item missing in the previous packet, the system checks at step 170 to determine if there was more than one sequence number missing in the previous packet, and if only one sequence number was missing, the system will send a message that only a single item was missing at step 172, and return to step 176. If more than one sequence number is missing in the previous packet, the system will send 174 a missing range entry indicating the beginning and end sequence numbers. After sending the loss range in step 174, the system returns to step 176. Information on these missing ranges is printed on all reports and sent to the host.

At step 186, the system determines if the sequence number is missing in the current packet. If not, the system returns to the blank screen state at step 188; if a loss occurs, the system checks to see if more than one sequence number is missing from the current packet at step 190. If only one sequence number is missing, the system sends a single missing item with that sequence number in step 192 and then returns to step 188. If more than one sequence number is missing, the system sends the missing range item with the head and tail sequence numbers in step 194 and returns to step 188.

In connection with fig. 3(a)3(b)3(c)3(d), a sales and vendor payment activity with barcode logic is described.

At step 200, the system displays an empty screen. At step 202, the user types a function key, representing "sell/vendor pay". At step 204, the system displays "enter user code" and, accordingly, the user enters his or her user code at step 206. At step 208, the system checks to determine if the user has the right to conduct a sale or vendor transaction, and if not, the "no access" is displayed at step 210, and the system then returns to the blank screen state at step 212.

If at step 208 the system determines that the user is authorized to conduct the sell/sell transaction, the system and the user obtain the necessary information to conduct the transaction in accordance with the previously established functions, which are performed at step 214, after which the system moves from node 216 to step 218. At step 218, a compact is submitted to the printer. At step 220, the system checks to determine if the title header has been located. If not, the system unloads the contract from under the print head and sets the safe empty flag at step 222, displays "printer error start, please check and reload" at step 224, and then returns to the empty screen state 226. If the header of the ticket is located at step 220, the system checks to determine if the trailer is located at step 228, and if not, unloads the ticket from under the print head and sets the safe empty flag at step 230. At step 232, the system displays "printer error strake, please check and reload" and then returns to step 226.

If the bottom strip is positioned at step 228, the system moves to step 236 via node 234.

At step 236, the compact is sent under the print head and the bar code is read. If the system determines at step 238 that the barcode was not read correctly, the system checks at step 240 to determine if the barcode exceeded a retry limit, and if not, the system returns to step 236; if so, the system displays an unreadable, invalid item at step 244, prints a "failure" on the bond, records the failure bond in memory, i.e., an electronic log, and checks to determine if a predetermined maximum number of unsuccessful bar code readings has been reached; if the maximum number is not exceeded, the system moves to step 218 via nodes 215 and 216; if so, the system displays "unreadable item please check and reload" or "unreadable item please apply for help" at step 252, sets the m.o. safe empty flag at step 254, and returns to the empty screen state at step 256.

If the bar code is successfully read at step 238, the system returns to step 258 via node 251.

At 258, the system determines D.O if the number matches the predetermined value on the terminal. If there is no match, the system displays "printer error-D.O. not match" at step 260. And the deed is unloaded from the printing head in step 262, the safe is set to be an empty mark, and the state of the empty screen is returned in step 264. If the D.O number does match the terminal at 258, the system determines if the data bit is correct, e.g., incorrect, indicates "printer error," checks that the data bit is incorrect "at 266, and returns to 262.

If the check data bits are correct, the system determines whether the sequence number is the next sequence number desired at step 270. If so, the compact is written to the log as a sale at step 276, the remainder of the compact is printed at step 280, and the blank screen status is returned at step 264.

If the system determines that the sequence number is not the next expected sequence number at step 270, the system checks to see if more than one sequence number is missing at step 272. If not, a single missing item is logged in step 274 along with the sequence number and moved to step 276. If more than one sequence number is missing at step 272, the system will log the missing range of items representing the head and tail sequence numbers at step 278 and move to step 276.

Power cycling with bar row code logic is described in connection with fig. 4.

At step 300, the system is turned on. At step 302, the system determines whether the printer power has been cycled and, if not, returns to the blank screen at step 304. If the printer power has been cycled, the data is sent under the print head at step 306 to read the barcode, and if the barcode is successfully read at step 316, the system checks at step 318 to determine if the d.o. number matches the terminal number. If so, a determination is made as to whether the data bits are correct in step 322. If the check data bits are correct, the system cancels the safe empty flag at step 326, removes the compact from the print head (and optionally checks for missing items) at step 314, and returns to the empty screen for a corresponding log record.

If the barcode was not successfully read in step 316, the system checks in step 308 to determine if the barcode exceeds a retry limit, and if not, the system returns to step 306; if the limit has been exceeded, the system displays "printer error-unreadable barcode" at step 310, sets the safe to empty flag at step 312, unloads the instrument from under the print head at step 314, and returns to idle screen at step 304.

If the d.o. number does not match the terminal at step 318, the system displays "printer error-D.O not match" at step 320 and moves to step 312.

If the check data bit is not correct at step 322, the system displays "printer error-check data bit is not correct" at step 324 and moves to step 312.

The download notification and callback process is described in connection with fig. 5. The terminal transfers all data stored on the working log to the host system in step 400.

The host processes the sales data online at 402, and the host performs device i.d. and "notification list" matching at 404. The host system determines if the current device i.d is on a "notification list" at step 408, and if not, sends a recorded response and disconnects the call at step 410. If the device ID is in the notification list at step 408, the system sends a recorded response with the notification at step 412 and disconnects the call. The terminal checks to determine whether the notification is for a scheduled or immediate callback at step 414, and if the notification is an immediate callback, the system proceeds to step 420 as further described. If the notification is for a scheduled callback, the terminal will loop through 416 and check the current time to equal the scheduled time, and when the current time equals the scheduled time, step 420 at 418.

At step 420, the terminal determines whether the notification is for initialization, loader, or printer load. If the notification is for a printer loader, the terminal calls the host system to introduce printer enhancement software at step 422 and disconnects at step 428 after the download is complete.

If the terminal determines that the notification is for a loader at step 420, the terminal calls the host system and downloads the terminal enhancement software at step 424, and after downloading is complete, the call is disconnected at step 428.

Notifications may also be used for multiple processes (e.g., initialization and download). Notifications may also depend on the unique code or version associated with each MOD that is communicated to the host system during the invocation.

If the terminal determines that the notification is for initialization at step 420, the terminal calls the host system and downloads a modification of the terminal equipment at step 426 and then disconnects the call at step 428.

Previously issued deeds may also be reinserted by the user to invalidate them. The barcode reader will verify that the corresponding credential is being invalidated.

Note that the current invention is applicable to the issuance of any value deed, whether or not the deed is currency.

It is also noted that previously issued deeds may be reinserted into the printer to be invalidated upon command by the user. The barcode reader will verify the serial number to determine that the correct credential is being invalidated.

The present invention includes all subject matter within the scope of the claims. Accordingly, the present invention is not limited to the above-described embodiments.

Claims (38)

1. An apparatus for generating a value document, comprising:

a compartment for holding a plurality of blank tickets, wherein a plurality of codes are associated with the plurality of blank tickets such that each blank ticket of the plurality of blank tickets is associated with a particular code of the plurality of codes;

a code reader that reads a plurality of codes associated with the plurality of blank bills from the blank bills;

a printer that generates a value ticket by printing information on each of the plurality of blank tickets; and

a control terminal for controlling the code reader and the printer, the terminal being configured to communicate between the code reader and the terminal, and the terminal being configured to detect and record each specific code of the plurality of codes, wherein the control terminal detects and records deviations from an expected order of the plurality of codes.

2. The apparatus of claim 1 wherein the printer generates the value ticket includes being configured to generate a money order.

3. The apparatus of claim 1, wherein the code reader reading a plurality of codes associated with the plurality of blank tickets from the blank tickets comprises being configured to read the plurality of codes from paper, and the printer generating the value ticket by printing information on the blank ticket comprises being configured to print the information on the paper.

4. The apparatus of claim 1, wherein the code associated with the blank tickets is continuous, and the apparatus further comprises means for recording which of the previously continuous blank tickets has been printed.

5. An apparatus according to claim 1, characterised in that the control terminal is arranged to perform a predefined action upon detection of a blank ticket with an incorrect code.

6. An apparatus according to claim 5, characterised in that the control terminal is configured to perform the predefined action by invalidating the blank ticket.

7. The apparatus of claim 5, wherein the control terminal detecting a blank ticket with an incorrect code includes being configured to detect a blank ticket with a code that deviates from a desired order.

8. The apparatus of claim 5, wherein the control terminal detecting a blank ticket with an incorrect code includes being configured to detect a blank ticket with a code that does not fit a predefined type of value ticket.

9. The apparatus of claim 1, wherein the code reader reading a code associated with a blank document from the blank document comprises a code configured to read a code printed on the blank document.

10. The apparatus of claim 1 wherein the code reader reading a code associated with a blank document from the blank document comprises a code reader configured to read a blank document encoded with a barcode.

11. The apparatus of claim 1 wherein the blank document code utilizes MICR.

12. An apparatus as claimed in claim 1, characterized in that the code reader reads the code with OCR.

13. The apparatus of claim 1 further comprising a memory, wherein the memory stores information indicating that a blank ticket has been read by the code reader.

14. The apparatus of claim 1, wherein the terminal is configured to detect and record deviations from an expected order of codes uniquely associated with the blank ticket based on a received command to generate a value ticket to produce a value ticket.

15. The apparatus of claim 1 further comprising means for detecting that a blank document has been removed from the apparatus.

16. The apparatus of claim 15 further comprising means for detecting which blank document is removed and when.

17. The apparatus of claim 1, further comprising a printer access controller, the access controller allowing a user to access at least a portion of the printer based on the received access code.

18. The apparatus of claim 17, wherein the printer access controller is configured to associate the access code with a limited number of users.

19. The apparatus of claim 18, wherein the printer access controller is configured to associate each access code with a single individual.

20. The apparatus of claim 19, further comprising a memory, wherein the access code for obtaining access to the printer is stored in the memory.

21. The apparatus of claim 20, wherein the time of access to the printer is recorded in the memory.

22. The apparatus of claim 1, wherein the compartment includes a lock, the lock being controlled by the control terminal.

23. The apparatus of claim 22 further comprising a memory, wherein the memory stores information indicating whether the printer is accessed.

24. The apparatus of claim 23, wherein the memory is non-volatile.

25. The apparatus of claim 23, wherein the memory stores a time at which the printer has been accessed.

26. The apparatus of claim 23, wherein the memory stores information on which access code is used to access the printer.

27. An apparatus for generating a value document, comprising:

a printer for printing a value document, the printer comprising a compartment for receiving a blank document for printing a value document;

a printer access controller in communication with a printer, said access controller allowing physical access to at least said compartment of said printer upon receipt of an access code from an individual.

28. The apparatus of claim 27 wherein the printer access controller is configured to identify an individual desiring access to the printer from the access code.

29. The apparatus of claim 28, wherein the printer is configured to record the time at which the printer was accessed.

30. The apparatus of claim 29, wherein the printer is configured to automatically generate a periodic report indicating the number of times the printer has been accessed and the operator accessing the printer.

31. The apparatus of claim 30, wherein the access code and the number of accesses are stored in a non-volatile memory.

32. The apparatus of claim 31, wherein the non-volatile memory comprises volatile memory and a battery backup.

33. The apparatus of claim 27, wherein the printer access controller is further configured to confirm whether the access code allows access to the printer.

34. The apparatus of claim 27, wherein the printer access controller permits access to at least a portion of the printer based on any one of the received plurality of control access codes.

35. The apparatus of claim 27, wherein said printer access controller is further configured to change said access code.

36. The apparatus of claim 35 wherein said printer access controller is configured to periodically change said access code.

37. The apparatus of claim 36 wherein said printer access controller is configured to automatically change said access code.

38. The apparatus of claim 36, wherein the printer access controller is configured to change the access code using one or more of a function of a date and a unique code identifying the machine.