Patent Application
20160125374
The present invention relates to verifying notes, such as but not necessarily limited to circumventing standard mode operations to permit a note-verify mode where verification is performed prior to return of the note.
Safes, automated teller machines (ATMs), vending machines, video gaming units and other devices may receive bank notes, coins, paper money or other valuables for safekeeping. More and more of these secure storage apparatuses are being manufactured with various electronically controllable operations, including capabilities to verify notes prior to storage. U.S. Pat. Nos. 5,918,720, 7,063,252 and 8,794,420 and U.S. patent application Ser. Nos. 13/248,000, 13/648,503 and 14/046,764, the disclosures of which are hereby incorporated by reference in their entireties, describe safes having such electronically controllable operations, amongst others.
As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.
The apparatus 10 may include a shutter 24 mounted or otherwise affixed to a door 25 to permit servicing of the bill validator 12 while maintaining security of the stored items. The shutter 24 may be movable positionable relative to a first opening 26 in a substantially enclosed housing 28 forming a body of the apparatus 10. The first opening 26 may be sufficiently shaped within a side of the housing 28 to permit removal of the bill validator 12, one or more of the bill validator heads 20, 22 or other component of the validator 12, therethrough. The door 25 may be movable positioned relative to a second opening 30 in the side of the housing 28. The second opening 30 may be shaped to permit removal of the cassettes 16, 18 or other storage container configured to receive the deposit therethrough. The shutter 24 may be movable positioned between a closed position and an opened position to respectively prevent and permit removal of the bill validator. The door may be movable between a closed position (see
A door lock 34 may be included to lock the door 25 to the housing independently of a shutter lock 36. (While shown on the door, the door lock need not be included on the door may and may be positioned elsewhere to secure the door when in the closed position.) Like the shutter lock 36, the door lock 34 may be an electronically operable lock operable between a locked state and an unlocked state in response to messages and/or electronic signal. The door lock 34 is shown to include two bars that extend into a wall of the housing 28 when in the locked state to lock the door 25 in the closed position and that retract when in the unlocked state to permit opening of the door 25. The door lock 34 may be separately controllable from the shutter lock 44 such that individuals having capabilities may to open the shutter 24 may not necessarily have capabilities to open the door 25. A human-machine interface (HMI), touch-screen, display or other interface 40 (see
The HMI 40 may include a network interface (not shown) sufficient to facilitate remote control and networking of the apparatus 10 and the housing 28 may be enclosed in a sleeve (not shown), such as in the manner described in U.S. patent application Ser. No. 13/648,503, the disclosure of which is hereby incorporated by reference in its entirety, and the applications and patents noted above. A switch 48 may be included to facilitate electronically controlling the shutter lock 44. The switch 48 may be a magnetic switch operable to indicate whether the shutter 24 is in one of the closed position and the opened position depending on whether a first magnet mounted to the shutter 24 is aligned with a second magnet mounted to the door 25. The magnetic switch 48 may be configured to facilitate closing a circuit to indicate the shutter 24 being in the opened position when the first magnet aligns with the second magnet and to facilitate breaking the circuit to indicate the shutter 24 being in the closed position when the first magnet is misaligned with the second magnet. While not shown, wires may extend from the shutter lock 36, the door lock 34 and/or the switch 48 to facilitate electronic communications therewith and/or these components may include wireless communication capabilities. A printer 50, such as but not necessarily limited to a thermal printer, may be configured, such as with a printing element and a paper feed system, to facilitate printing receipts 52. The printer 50 is shown to be on the face the pullout tray but may be positioned elsewhere, such as on a top of the tray next to the HMI 40 in order to provide a closer proximately and ease of use when interacting therewith.
Block 62 relates to verification process beginning with one or more notes being fed into the validator 12. While the validator 12 shown in
Block 64 relates to determining whether the validator 12 has been programmed to operate in a standard mode or a note-verify mode. The standard mode may correspond with typical or normal operation where the validator 12 is being used to verify and process submitted notes for storage within the secure storage area 14. The note-verify mode may correspond with a non-typical or temporary mode of operation where the validator 12 is being used to verify and process submitted notes for the purposes of returning it to the cashier rather than storing it in the secure storage area 14. While only the standard and note-verify modes are described, the present invention fully contemplates the safe 10 or other device having the validator 12 being operable in any number of additional operational modes. The determination of whether the validator 12 is operating in the standard mode or the note-verify mode may be based on control signals or user inputs thereto. The HMI 40 may be operable to display a button sufficient for switching between the standard and note-verify modes. One non-limiting aspect of the present invention contemplates a scenario where the cashier instigates a single manipulation of a mode-switch button included on the HMI 40 to switch from the standard mode to the note-verify mode and/or from the note-verify mode back to the standard mode. Optionally, a timer or other default control may be implemented to automatically revert from the note-verify mode back to the standard mode.
Block 66 relates to the standard mode being currently active upon receipt of the note. The validator 12 may include a sensor or other feature capable of sensing presence of the bill prior to beginning a feed-in/escrow process so as to facilitate determining presence of the note prior to the note being mechanics driven into the validator 12. Block 68 relates to the validator 12 performing a verification process where the note is determined to be valid or invalid. A valid determination may occur when the node is determined to be genuine and an invalid determination may occur when the note is determined to be fake or incapable of being scanned/process for the purposes of assessing validity, e.g., in the event the note distorted, ripped or otherwise defective. The valid and invalid determinations are described for exemplary non-limiting purposes as illustrative of various operations capable of being performed with the bill validator 12 to adjudicate or otherwise assess the received note. Additional operations and/or processes may be performed in the standard mode and/or the note-verify mode without deviating from the scope and contemplation of the present invention. The verification process may include the note being escrowed entirely within the validator 12 such that it is out-of-sight of the user or otherwise entirely lodged within the validator 12, such as to enable a scanner or other device to assess authenticity.
Block 72 relates to the validator 12 facilitating delivery of a note determined to be valid for safekeeping. Block 74 relates to the validator 12 returning a note determined to be invalid. The validator 12 may include a first interface through which a user feeds the note and a second, different interface through which the note may be delivered for storage such that returned notes may be delivered back through the first interface and accepted notes may be delivered through the second interface. At the conclusion of the verification process, an audit report or other information may be generated by the validator 12 and/or information may be provided from the validator 12 to a controller for use in monitoring the corresponding transaction. The exemplary description of the standard mode may include any number of other operations and processes to be performed by the validator 12 or other device associated with the safe 10. The standard mode may be generally characterized by an intention to keep or otherwise prevent return of the submitted note to the user if found to be valid, authenticated or otherwise suitable for safekeeping. While described with respect to keeping valid notes, the notes may also be retained or kept even if found to be invalid, such as to prevent its continued circulation.
Block 76 relates to determining to the note-verify mode being currently active upon receipt of the note.
Block 88 relates to transmitting shutdown message upon detecting presence of the note to prevent other validators 12 or validator mechanisms 20, 22 from simultaneously operating according to the note-verify mode. The ability to prevent other validators or validator mechanism, particularly those in proximity to the first one being fed the note or those connected to a common networked infrastructure, may be beneficial in preventing user confusion when multiple users contemporaneously attempt to implement the note-verify mode. The shutdown message may be sufficient to prevent any subsequent validators from feeding or accepting notes, and thereby act as notification to the corresponding user that the note-verify mode has not been implement at the corresponding validator. Optionally, the shutdown message may prevent the other validators from processing any notes or to enable other validators to operate according to other modes besides the note-verify mode. The shutdown message may be transmitted locally within the safe 10 to prevent one of the other one of the mechanisms 20, 22 from operating and/or through a network interface to prevent other network-connected validators from operating.
Block 90 relates to the validator 12 escrowing the received note and assessing it to be one of valid and invalid in the manner described above with respect to the standard mode. Optionally, the verify-mode may deem notes to be valid or invalid according to other metrics than those utilized in the standard mode, e.g., the standard mode may be limited to processing only certain type of notes suitable for storage, such as paper currency and not checks, while the note-verify mode may perform other valid and invalid assessments for notes incapable of being stored in the safe 10 due to the notes being subsequently returned to the user regardless of validity. The note-verify mode may be operable with any type of note capable of being processed through the validator even if the safe is unable to store it. Blocks 92, 94 relate to the return of valid and invalid notes to the user, such as with delivery of the note following escrow back through the first interface. Block 96 relates to a verification message being generated to indicate whether the note was determined to be valid or invalid. The verification message be displayed via the HMI 40 or other display in communication with the safe and/or the verification message may be transmitted to a centralized network controller for the purposes of generating an audit for the note. Optionally, the verification message may be used to control to open a cashier till if valid and to prevent the cashier till from opening if invalid, which may be useful in providing cashiers with a secondary notification of validity.
The foregoing standard and note-verify modes are predominately described with respect to processing a single note for verification purposes. This is done without necessarily intending to limit the scope and contemplation of the present invention as multiple notes may be processed prior to determining validity and/or validity may be determined individually for multiple notes passing through the validator 12 in succession, i.e., the valid and invalid screens may display serial numbers or other identifiers sufficient for individually identifying each note as being valid and/or invalid. The note-verify mode may verify a currency note as a valid note by extending the functionality of a bill validator for purposes of recognition and identification of the paper note currency inserted with the bill validator. A function may place the bill validator in a state known as escrow where the paper currency note can be read but not acted upon by the system. The function may then return the note without accepting the note to the presenting user and the function may read the state of the note and any potential value of said note. The function may then provide one of two responses to the user. An example of the first response is to inform the user via a user interface that the note could not be validated by the bill acceptor. An example of the second possible response would inform the user via a user interface that the note was validated and display the value of the note.
Builder Step [A]—Idle Screen
The call to start the process will come from the idle screen. This is the logged out idle screen that the system is normally at when no users are logged in.
Builder Step [B]—Process Initiated
Once the process is initiated from the idle screen, the builder starts. It is not the responsibility of this builder to check to see if there are validators in the Local Node that the MCU is a part of. That logic is to be performed by the calling builder.
At this point in the process, any validators in the Local Node that are not part of a User Lock process should be enabled. As the Verify Note process does not accept any Money into the system or modify any Fund totals, any Note Acceptor in the Local Node system can be used no matter what Fund it is associated with.
Builder Step [C]—Verify Note Screen
There may be only one screen for the Verify Note process that is used throughout. This screen at this stage in the process flow only has two actions available for the user.
It is assumed that any Note Acceptors in any other state are known to the user and will continue to function in that other state while this process is going on.
Builder Step [D]—User Inserts a Note
As soon as a Note Acceptors recognizes that a Note has been inserted, all Note Acceptors associated with the Verify Note process should cease acceptance of Notes. Only the first Note put into a Note Acceptor should attempt to be validated.
Builder Step [E]—Validating the Note
After all other Note Acceptors have been disabled from accepting new Notes; the Note that was entered should now be in an escrow state in the Note Acceptor that it was inserted into. The state of the Note should be read from the Note Acceptor.
Builder Step [F]—Return Note to User
At this point the note should be rejected no matter the outcome of the validation process. The Verify Note process should never stack or accept a Note past the point of escrow.
Builder Step [G]—User Inserts a Note
Here the state of the Note that was read should be examined. A decision point exists here that is based on whether the Note was read as valid or not. This decision point affects the next two steps.
Builder Step [H]—Verify Note Screen with Warning
At this point in the process a Note has been read and it was unable to be validated by the Note Acceptor. The user has two options at this point:
Builder Step [I]—Verify Note Screen with Valid Note message and Note value been read and it was read and validated by the Note Acceptor. The user has two options at this point in the process:
Builder Step [J]—User Input Needed
This step just indicates that the process is dependent on the user making a selection at this point. The process will not continue until a selection is made.
Builder Step [K]—‘Re-Verify’ Button press
Here the user has selected the ‘Re-Verify’ button. This event in analogous to starting the process from the beginning and the process flow should start again at step [B].
Builder Step [L]—‘Back’ Button press
Here the user has selected the ‘Back’ button. This event exits this process and takes the user back to the idle screen and completes the Verify Note process.
Additional Verify Note Module Considerations
The Verify Note process has a few additional considerations that need to be taken into account during the development of the module. These considerations are defined in the sections below.
Verify Note Process Error Handling
No specific error handling logic is needed for this process. The first Note Acceptor that registers that a Note has been submitted for validation is the one that will be used for the validation process. This will eliminate conditions where simultaneous notes are put into different Note Acceptors to try and game the system.
Verify Note Process Accounting
The Verify Note process is not associated with any Funds or Fund Totals. At no point in the Verify Note process should any Note ever be stacked in a Note Acceptor. At no point in the Verify Note process should any totals be queried or modified.
Verify Note Process Auditing
Every time a Note is read for validation in the Verify Note process an audit is created in the System Audit. This audit record will contain the default audit timestamp. Because no user login precedes running the Verify Note process the system has no way of knowing what user is performing the process, therefore the user for the audit is the ‘System’. The audit record will contain the results of the validation and, if valid, the value of the validated Note. The specific audit data can be found in Appendix E—Ascent Platform Audit Detail.
Verify Note Process Screen Timeouts
The screens used in the Verify Notes process will have associated screen timeouts. These screen timeouts will be settings based, and reflect the global settings ‘screen_timeout_active’ and ‘screen_timeout_time’. If the setting ‘screen_timeout_active’ is set to ‘Y’ then all screens in this process need to timeout after x seconds, with x being an integer value represented in the setting ‘screen_timeout_time’. If ‘screen_timeout_active’ is set to ‘N’ then no screen timeouts will occur in this process.
The screen timeout is a timer that resets on any user interaction with the system. This could be in the form of touch on a touchscreen, or inserting a Note into an activated Note Acceptor, or causing a sensor to trigger. The latter could be something like closing a Vault door. Upon reset, the timer will start counting seconds again. If the timer reaches the ‘screen_timeout_time’ then the screen timeout action occurs. The screen timeout action for the Verify Note process is to close the process and pass navigation back to the idle screen.
Note that if a screen timeout occurs during the part of the process where any Note Acceptors are in use, any Note Acceptors associated with this Verify Note process should be disabled and placed back into an idle state.
Verify Note Process Help Button
In the top navigation bar on the screen used for the Verify Note process, there is a circular button with a ‘?’ inside it. That button will bring up the Help overlay for this module. No matter when the button is pressed during this process, the help overlay will display the same instructions for the process and will not change depending on what part of the process the user is in. The Help overlay will contain 2 buttons, a ‘Close’ button and a ‘Print’ button. The ‘Print’ button can be used to print a copy of the help navigation. The ‘Close’ button can be used to close the Help overlay and continue on in the Verify Note process.
Note that the Help section is referred to as an overlay meaning that it will ride on top of the existing screen with the underlying process still ongoing. Therefore screen timeouts will also apply to the Help overlay as well as the underlying screen.
Verify Note Process Navigation Cost
The navigation cost for an expected run through the Verify Note Process alone is 1+t1+1+t2+1. The first 1 indicates the button press to start the process. The value of t1 is the amount of time for a user to insert a Note into a Note Acceptor. The second 1 indicates an estimated length of time for the Note Acceptor to read the Note and then pass the Note back out of the Note Acceptor. The value of t2 is the amount of time for a user to take the note and read the results of the verification process onscreen. The final 1 denotes the single button press to complete the process.
Consolidating the navigation cost down to 3+t1+t2 gives a condensed cost. Assuming a trained user of the system taking anywhere from 1-10 seconds for both t1 and t2, we get a theoretical best-worst case navigation cost for a trained user of 5-23 seconds to complete the Verify Note process.
There is master audit data stored for every audit in the system. This master data comprises the user information for each audit, a timestamp, an audit type, and a master data field that stores the xml for the master audit. The master audit data also stores a master id which is an auto-incrementing field that stores a consecutive counting number that indicates the position of the audit against all others in the system. This piece of data is even more important than the timestamp in that it represents an ordering of the data sequentially and will exist even if the realtime clock in the system is not operating correctly or is tampered with.
Master Audit XML Format
The master audit XML format is as follows:
System Audit Data:
While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.
