Patent Grant
9611686
The present invention relates generally to systems and methods for cashbox security. More particularly, the present invention relates to tracking and monitoring cashboxes that are removably located in transit vehicles.
Cashboxes are used on transit vehicles to collect fares from riders paying using cash. Cashboxes must be removed from vehicles and deposited, for example in vaults. The safety, monitoring and resetting (to indicate the cash has been removed from the cashbox such that it now contains no cash) of such cashboxes is thus important.
Existing approaches to cashbox safety and security may involve mechanical keys for removing the cashbox, mechanical restraints to tether cashboxes, probes that people handling the cashboxes (“Handlers”) may keep that store information about the cashbox and allow removal of the cashbox, depositing, resetting, and the like.
Such systems, however, do not provide adequate flexibility, automation, redundancy, and advanced notice of rogue actions.
There thus remains a need for systems and methods to safely and securely remove cashboxes from transit vehicles and monitor them effectively until their contents are deposited in vaults.
There is a for secure cashbox removal from a transit vehicle and emptying in a vault at a transit site, the system comprising: a cashbox, removably attached to a transit vehicle driven by a transit operator, that receives cash from one or more riders during operation of the transit vehicle and can be removed from the transit vehicle and taken to a vault to deposit the cash located in the cashbox, the cashbox comprising a cashbox tag configured to: broadcast a cashbox tag present signal; one or more secure zones inside the transit site, created and defined by one or more cashbox signal transceivers, the one or more cashbox signal transceivers defining the secure zones configured to: receive a cashbox tag present signal if the cashbox is within communicable range of the secure zone; and communicate one or more secure zone signals, representing the presence of the cashbox in the secure zone, to the monitoring system if the cashbox tag present signal is received; one or more alarm zones inside the transit site, created and defined by one or more cashbox signal transceivers, the one or more cashbox signal transceivers defining the alarm zones configured to: obtain a cashbox tag present signal if the cashbox is within communicable range of the alarm zone; and provide one or more alarm zone signals, representing the presence of the cashbox in the alarm zone, to the monitoring system if the cashbox tag present signal is obtained; a monitoring system for a transit site, the monitoring system configured to: accept the one or more alarm zone signals and the one or more secure zone signals; determine, using the one or more alarm zone signals and the one or more secure zone signals, whether any cashbox rules have been violated; and trigger a cashbox alarm if any cashbox rules have been violated; and a vault, located at the site, for accepting a deposit of the cash from the cashbox.
The cashbox rules may comprise cashbox tracking rules and cashbox monitoring rules and the cashbox alarms comprise cashbox tracking alarms and cashbox monitoring alarms.
The secure zone signal may include a cashbox signal transceiver identifier and a timestamp of when the cashbox tag present signal was received by the cashbox signal transceiver.
The first secure zone may be a secure pathway and the monitoring system may receive a first set of secure zone signals from the cashbox signal transceivers in the secure pathway as the cashbox is moved towards the vault, and may determine whether any cashbox tracking rules have been violated based on the cashbox signal transceiver identifiers and timestamps of the first set of secure zone signals.
The cashbox tag may further comprise a cash present flag that indicates whether there is cash in the cashbox.
The cash present flag may set to true when cash is received by the cashbox and set to false when a deposit from the cashbox is received by the vault.
The cashbox alarms are deactivated when the cash present flag is set to false.
The cashbox may be removable when one or more cashbox removal conditions are met.
The one or more cashbox removal conditions may comprise: the presence of one or more mechanical keys or one or more electronic keys; the presence of an authorized handler, the cashbox tag does not receive any alarm zone present signal; and the cashbox tag receives at least one secure zone present signal.
The monitoring system may further be configured to: receive the one or more handler signals; determine, using the one or more handler signals, the one or more alarm zone signals, and the one or more secure zone signals, whether any handler rules have been violated; and trigger a handler alarm if any handler rules have been violated.
There is further a method for securely removing a cashbox from a transit vehicle and emptying in a vault at a transit site, the method comprising: removing the cashbox from the transit vehicle; broadcasting a cashbox tag present signal; receiving a cashbox tag present signal if the cashbox is within communicable range of a secure zone; and communicating one or more secure zone signals, representing the presence of the cashbox in the secure zone, to a monitoring system if the cashbox tag present signal is received; obtaining a cashbox tag present signal if the cashbox is within communicable range of an alarm zone; providing one or more alarm zone signals, representing the presence of the cashbox in the alarm zone, to the monitoring system if the cashbox tag present signal is obtained; accepting the one or more alarm zone signals and the one or more secure zone signals; determining, using the one or more alarm zone signals and the one or more secure zone signals, whether any cashbox rules have been violated; and triggering a cashbox alarm if any cashbox rules have been violated.
The cashbox rules may comprise cashbox tracking rules and cashbox monitoring rules and the cashbox alarms comprise cashbox tracking alarms and cashbox monitoring alarms.
The secure zone signal may include a cashbox signal transceiver identifier of a cashbox signal transceiver that received the cashbox tag present signal and a timestamp of when the cashbox tag present signal was received by the cashbox signal transceiver.
The secure zone may be a secure pathway and the one or more secure zone signals may comprise a first set of secure zone signals from the cashbox signal transceivers in the secure pathway as the cashbox is moved towards the vault.
The method may further comprise setting a cash present flag to true when cash is received by the cashbox and to false when a deposit from the cashbox is received by the vault.
The method may further comprise deactivating the cashbox alarms when the cash present flag is set to false.
The removing may further comprise checking that one or more cashbox removal conditions are met. The one or more cashbox removal conditions may comprise: the presence of one or more mechanical keys or one or more electronic keys; the presence of an authorized handler; the cashbox tag does not receive any alarm zone present signal; and the cashbox tag receives at least one secure zone present signal.
The method may further comprise: getting one or more handler signals; deciding, using the one or more handler signals, the one or more alarm zone signals, and the one or more secure zone signals, whether any handler rules have been violated; and raising a handler alarm if any handler rules have been violated.
Embodiments will now be described, by way of example only, with reference to the attached Figures, wherein:
System 10 uses one or more gateways 38b and reference tags 38a to implement various alarms and tracking rules to allow cashbox 36 to be removed from farebox 34 on vehicle 30 and emptied at vault 22 without being stolen. Gateways 38b and reference tags 38a (each a cashbox signal transceiver or CST) may communicate via RFID with tag 32 that may be part of cashbox 36 to carry out the implementation of cashbox alarms. RFID communication between tag 32, gateways 38b and reference tags 38a may eventually reach a gateway 38b and may be communicated to monitoring system 44, such as via communication network 42. Thus monitoring system 44 may implement the logic of the various cashbox alarms, as described herein—though it is to be understood that such logic, or portions thereof, may be implemented by gateways 38b, MDTs 40, or even tags 32 if need be (for example alarm zones may be configured to provide alerts, such as audible alarms, independent of any communication beyond the CST that has identified the cashbox alarm triggering or non-adherence.
Vehicles may enter site 12 via entrance 26 on driving lane 16 and may be destined for one or more of bay 14 or parking spots 18 before being sent back out to perform more work, exiting site 12 via exit 28. Upon entry tag 32 may be registered by a CST so that tag 32 may be triggered to be monitored (though other cashbox monitoring triggers are possible, such as when cashbox 36 is removed from farebox 34). Cashbox 36 may only be removable from farebox 34 if certain cashbox removal conditions are met, as described herein, such as one or more of via a mechanical key, when tag 32 is within one or more secure zones, or the presence of a Handler is detected (such as via a CST on the Handler's person, such as on their mobile phone, badge or MDT 34). Once removed from farebox 34 cashbox 36 may need to i) adhere to one or more cashbox tracking rules to avoid triggering one or more cashbox tracking alarms, ii) adhere to one or more cashbox location rules to avoid triggering one or more cashbox location alarms (such cashbox tracking alarms and cashbox monitoring alarms being referred to herein as cashbox alarms), and handler may need to adhere to one or more handler rules to avoid triggering one or more handler alarms (such as handler may not leave site until cashbox 36 is fully processed and the cash present flag is reset, handler must always be in communicable range of cashbox tag 32, and the like) as described herein. Such cashbox alarms may be initiated or activated whenever cashbox 36 is being monitored or whenever it is removed from farebox 34 or vehicle 30, possibly in conjunction with system 10 knowing that cashbox 36 is not empty (ie it contains cash, such as via a cash present flag being set to true on tag 32, monitoring system 44 or MDT 40). When cashbox 36 is removed from farebox 34 or otherwise prepared to be emptied, it may be taken to a vault for emptying or other processing may occur. During such time it must not set off cashbox alarms; if it (or its handler more accurately) does it may be given time to take corrective action, as described herein, such that the required processing (emptying in vault 22, fixing farebox 34 in bay 14, etc) may be performed.
At a high level, and as further described herein, cashbox 36 may not set off or trigger cashbox alarms if it is located within at least one secure zone 22, is moving through any secure zones that are secure paths (such as secure zone 22c) appropriately, not in any alarm zones 24, and following farebox removal rules, cashbox removal rules, handler rules, and cashbox processing rules. Secure zones and alarm zones may be configured (both their number, location and size) in each implementation of system 10. Exemplary secure zones may include: a portion of bay 14, parking spots 18, wash bays, maintenance areas and fueling areas (not shown) and secure pathways to vault (such as secure zone 22c demarcated by dashed lines in
Cashbox alarms may be deactivated upon one or more deactivation triggers, such as reattaching to farebox 34, emptying its cash at vault 22, and the like. Different cashbox alarms may then be activated for its return to farebox 34 or vehicle 30 returning to perform another run and exiting site 12 via exit 28.
Site 12 may be any location where transit vehicles stop to empty cashboxes 36. Examples may include bus depots, banks, vehicle storage sites, shipping container storage areas (including on ships or on land), and the like. Site 12 may comprise outdoor areas and/or indoor areas in which moveable assets may be placed or kept. In a transit application, for example and as shown in
Moveable assets 30 (or simply ‘assets’ or vehicles) may be vehicles (such as buses, trains, streetcars or fleet vehicles) or other moveable assets. Assets 30 may enter site 12 via entrance 26 and may then be parked in a parking spot 18 or in bay 14 until they exit via exit 28 to perform another run.
Vehicle 30 may comprise mobile data terminal (MDT) 34 thereon or therein, though possibly being removable therefrom. MDT 40 may be computing devices that may take user input (such as keystrokes, clicks, touch inputs, and the like) and provides the user interface to functionality relating to, for example, the provision of transit services, driver or vehicle evaluation, and acceleration monitoring, and interacting with monitoring system 44 and the software located thereon. MDT 40 may have software running thereon to accept inputs as described herein, provide outputs as described herein, and communicate with other elements of system 10 as described herein. MDT 40 may have features of many tablets, smartphones, rugged PCs, and the like, such as one or more screens, memory, processors, cameras, communication modules (Bluetooth, RFID, cellular, WiFi, NFC, etc), and user inputs (touchscreens, buttons, etc). Vehicle 30 may comprise other components and systems (not shown) including, but not limited to, electrical, mechanical and computer systems and sensors, various of such systems requiring or being capable of monitoring.
MDT 34 may be able to communicate with other elements of system 10 to implement aspects of the invention described herein (such as farebox 34, cashbox 36, tags 32, RTs 38a, gateways 38b, monitoring system 44 and the like), for example by communication network 42, or directly such as may be the case with other systems of vehicle 30. One exemplary MDT 32 may be Ranger 4™, made by Trapeze Software™.
Vehicle 30 may further comprise one or more RFID asset tag 32 (referred to herein interchangeably as “tag 32”, “asset tag 32” or “AT 32”), including one or more tags 32a located in/on cashbox 36. Tag 32 may communicate via RFID (or similar communication that allows local communication, including in various frequency bands as required) with other assets 30, RTs 38a, gateways 38b, and monitoring system 44 (that may have or be RT 38a).
Tags 32, or cashbox tag 32, may be located thereon or therein, and may be removably attached. Tags 32 may operate in one or more “states” that govern their functioning. Tags 32 may transmit or broadcast a beacon signal (a cashbox tag present signal) for a particular duration (transmission duration) every few seconds (or other transmission interval) and may listen for other signals (such as alarm zone present signal, that may cause local processing on the tag 32 such as enabling a lockout for opening cashbox 32 or removing cashbox 32, or a secure zone present signal) for a particular duration (reception duration) every few seconds (reception interval). The location of asset tag 32 on asset 30 may be used to optimize communication ranges, reduce power consumption, and increase the ease of locating and sequencing (for example, placing tag 32 at the front of asset 30 may be more helpful than placing it somewhere between the front and back; and placing tags 32 at the same general location on each asset may also be assistive). Each asset 30 may have one or more tag 32 (such as the front of asset 30 and at the back of asset 30, on farebox 34 and cashbox 36).
Cashbox tag 32 on a farebox 34 may be able to retrieve and/or determine information relevant to asset 30 (status information), for example its cash holdings (via a cash present flag for example), location or information from other components (not shown) of assets 30, site 12, or gateways 38, for example from one or more sensors, and transmit that information to other assets 30, gateways 38, CSTs, or monitoring system 44 when they are within communicable range, allowing asset 30 to communicate with system 10 (for example providing status information to monitoring system 44) to provide the functionality described herein. ATs 32 (and RTs 38) may comprise a processor, memory or storage, and other features typical of RFID tags and gateways, that may allow accomplishing of functionality described herein.
Parking spots 18 may substantially be any parking spot in site 12. Parking spots 18 may be pre-determined or ad-hoc (for example just being where asset 30 stops), may be part of a parking lane 24 or separate, may be in a bay 14 or anywhere else in site 12. Each parking spot 18 may be uniquely identified or identifiable in monitoring system 44.
Driving lanes 16 may allow assets 30 to be driven through site 12 in order to arrive at a parking spot 20 or exit 28. Driving lanes 16 may have one or more configurations that may be set up, for example, in monitoring system 44.
Reference tag 38 (referred to herein interchangeably as “reference tag 38” or “RT 38”) communicates via RFID with other gateways 46 and tags 32. RTs 38 may be similar to ATs 32 but may have permanent power sources and be located in a fixed position in site 12. RT 38 may initiate communication or tag 32 may initiate communication. RTs 38 may be placed throughout site 12 so that they can communicate information with assets 30, and provide/gather information assisting in the processes described herein.
Gateways 46 may be similar to RTs 38 and further able to bridge the communication between RTs 38 and tags 32 into other networks (such as communication network 42)—essentially acting as a gateway between two modes of communication that otherwise may not inter-communicate.
All CSTs (as defined herein) may have identifiers that may be unique to them. Such identifiers may be communicated in various signals and for various purposes, as described herein.
Secure zones 22 may be an area within which cashbox 36 may be allowed to be removed from farebox 34. This area may be defined geographically though practically it may be defined by the communicable ranges of the various CSTs (RTs/gateways 38a/38b) that create secure zone 22. Once cashbox 36 is within a secure zone 22 it must remain within communicable range of at least one of the secure zone's CSTs for cashbox to be considered in the secure zone. Secure zones may include vaults, pathways, rooms within site 12 (such as a supervisor room), maintenance areas, wash areas, etc. Each CST in a secure zone 22 (or in an alarm zone 24) may receive a cashbox present signal and forward the cashbox present signal, optionally with a timestamp of when such cashbox present signal was received by the particular CST from cashbox 36 (as a secure zone signal or alarm zone signal as applicable) and transmit a CST present signal that may include a CST identifier and may be an alarm zone present signal or a secure zone present signal depending on what zone or area the CST is to define or demark (such signals may be received by cashbox tag 32 and acted upon locally, for example by enabling a mechanical lock if an alarm zone signal present signal is received by cashbox tag 32).
Alarm zones 24 may be an area within which cashbox 36 may not be allowed to be removed from farebox 34. This area may be defined geographically though practically it may be defined by the communicable ranges of the various CSTs (RTs/gateways 38a/38b) that create alarm zone 24. Once cashbox 36 is within an alarm zone 24 if it remains within communicable range of at least one of the alarm zone's CSTs it remains in the alarm zone. It is to be understood that any elements of system 10 that are called “tags” (such as tag 32, RT 38, and the like) may be tags in the sense that they may generally be able to receive and transmit via RFID. Of course all such elements may simply be readers. Hence tags (such as RT 38 and AT 32) may generically be referred to as nodes, where nodes may be either tags or readers. Also, all of such elements may comprise components as known to those of skill in the art of RFID systems.
Monitoring system 44 may be a component of system 10 that provides functionality described herein, using information obtained from various components in system 10. Monitoring system 44 may compile information from one or more gateways 38b, RTs 38a, or assets 30, via communication network 42 or RFID, with other information, for use in providing functionality of system 10 and monitoring system 44. Monitoring system 44 may be implemented via one or more pieces of software and may be operated by one or more users. Though it is shown in the figure as one computer, it can be composed of one or more computing and data storage devices and its functionality can be split up across these devices as appropriate. Of course monitoring system 44 may provide functionality not related to monitoring and tracking of cashbox deposits. Monitoring system 44 is shown as within site 10, but may be located anywhere, including remote from site 10 (though possibly still accessible from within site 10). Monitoring system 44 may comprise components as described herein, and may include storage (for example to store data communicated with and between RTs 38 and ATs 32).
Communication network 42 may enable communication of information between various components of system 10 including, but not limited to, RT 38 and monitoring system 44. Communication network 42 allows for a plurality of signals or information to be sent through its network simultaneously. Communication network 42 may be any public or private network, wired or wireless, and may be substantially comprised of one or more networks that may be able to communicate with each other. Communication network 42 may use a variety of mediums, such as cellular and WiFi networks. Communication networks 42 may not be required, for example, if components of system 10, such as RT 38 and monitoring system 44 are able to communicate directly, such as via RFID communications.
Components that communicate wirelessly in system 10, for example tag 32a, RT 38a and gateway 38b, have both a transmission range and a reception range. The transmission range denotes the distance which a component can transmit a signal to any other components within system 100, while the reception range of a component denotes the distance within which the component can hear signals. Components of system 10 are said to be in communicable range of each other when the reception range of a first component overlaps with the transmission range of a second, or the transmission range of the first component overlaps with the reception range of the second. When this is not true, the components are said to be out of communicable range of each other. If the reception ranges of both components overlap with the other component's transmission range, the components are said to be in bi-directional communicable range. Generally, the further two components are from each other, the weaker the signals exchanged may be—allowing gateways 38 and tags 32 to estimate the distance from, and importance, of signals being received. Each of RT 38 and AT 32 can configure their settings and components to adjust the strength of receiving and transmitting abilities, as required by the particular implementation. As such cashbox 36 may be within communicable range of particular tags 32, RTs 38a and gateways 38b at particular times as it continues to vault 22 and when it moves out of such range (for example if it does not enter within range of the next required zone demarker) then an alarm may be triggered, as described herein.
In one embodiment, as shown in
In a further embodiment, as shown in
Of course there may be overlap between secure zones, alarm zones and secure pathways (for example in that there may be overlap of the communicable ranges between such zones and cashbox tag 32). The correct interpretation (ie whether the presence of tag 32 in a particular overlap will cause an alarm or not) may be performed by the logic processors, such as monitoring system 44, as described herein.
Method 300 may be implemented whenever a transit vehicle 30 begins a run (a run beginning when transit vehicle 30 is pulled out of a bay or site and ending when transit vehicle 30 is pulled back into a bay or site, generally having completed part or all of one or more routes). Method 300 may allow a cashbox to properly be assigned to a particular vehicle driver that may perform end of run operations, as described in method 400. Of course it is to be understood that method 400 may be performed by users other than the driver/operator of transit vehicle 30 and may thus be considered a separate method from method 300, or a combined method with method 400.
Method 300 begins at 302 where transit vehicle 30 is to start a run. At 302 transit vehicle 30 may be in site 12 or other parking or storage facility.
At 304 cashbox 36 is serialized or associated to the vehicle operator of transit vehicle 30. This may involve, for example, the vehicle operator logging into MDT 32, which may already be associated with farebox 34 and hence cashbox 36. In particular, serializing may involve storing an operator ID, which may be unique for each authorized operator, with a farebox 34 or cashbox 36 or transit vehicle 30 ID (all of which may be unique for the farebox/cashbox/vehicle). Such pairing (of operator ID with another ID) may be stored in memory of one or more of non-volatile storage 260, RAM 248 of vehicle 30, cashbox 36, tags, and/or other components of system 10.
At 306 transit vehicle 30 may be in operation, driving routes, picking up passengers, and the like.
Each time a new passenger boards, they may pay their fare. At 308 a query is made whether any cash fare is received. This query may be made by farebox 34 and/or MDT 32, alone or in combination. If no cash fare is received then for the purpose of method 300 the method returns to 306 (for example if no cash enters into cashbox 36 then method 300 may simply return to normal ‘vehicle in operation’ status at 306). If cash is received at 308 then the cash will enter cashbox 36, via entry into farebox 34 (as is known in the art of fareboxes) and method 300 will continue to 312.
At 312 steps may be performed to acknowledge that cash has been input into cashbox 36, such as setting a “cash present” flag in software on MDT or in memory of farebox 34 as applicable (noting that such flag may be “set” the first time cash is deposited, and subsequent cash deposits, before a resetting of such flag, may simply be to confirm the “cash present” flag is set to “true”). Farebox 34 may also increment the cash total contained within cashbox 36 such that an accurate cash amount or cash balance in cashbox 36 is maintained). Note that such data (the cash present flag, cash total, and the like) may be stored, for example, within memory/databases on MDT 32. Of course MDT 32 may not be required in some embodiments of the invention and thus such cash present flag may be stored elsewhere within an exemplary system 10 that does not include MDT 32—such as on tag 32a, which could then communicate the status of such cash present flag throughout system 10, such as to monitoring system 44, to allow proper operation thereof. In such case cashbox 36 may reset the flag, possibly at the direction or upon confirmation from another aspect of system 10 such as vault 22.
At 314 a query is made whether a vehicle operator change has occurred. Of course if a vehicle operator changes then the previous vehicle operator need not continue to be responsible for the cash in cashbox 36, such that method 300 proceeds to 304 to re-serialize cashbox 36 with the new vehicle operator. If, at 314, there is no vehicle operator change then at 316 a query is made whether an end of run has occurred (which may indicate that a deposit of money in cashbox 36 into vault 22 is to occur). If so, end of run operations are performed (which may include method 400). If not, then method 300 continues at 306.
Method 400 may be performed whenever cashbox 36 is to be emptied, which may generally be when transit vehicle 30 is pulled into a site and stops, for example at the end of a run. Method 400 may allow an operator of transit vehicle 30 or other handler to safely get cash from cashbox 36 from transit vehicle 30 into a vault or other deposit facility in a secure and traceable manner, and allow any disturbances to be addressed. Of course method 400 may be performed at all times so that cashbox 36 is not removed when it is not supposed to be (or noticed and dealt with if it is removed at such a time).
Method 400 begins at 402 with transit vehicle 30 pulling in to site 12 (such as on driving lane 14 entering entrance 26) or otherwise being prepared for cashbox 36 to be emptied. Then at 404 cashbox 36 is removed from transit vehicle 30 and farebox 34; if successfully removed then it ought to have been removed by an authorized depositor of cash or handler within cashbox 36. Aspects of 404 are described in method 500 but may involve one or more of mechanical keys, software keys that unlock mechanical aspects of farebox 34, RFID based keys, and the like.
At 406 cashbox 36 has been removed from farebox 34 and transit vehicle 30 by a valid or authenticated depositor or handler; cashbox 36 begins its journey to vault 22—such as by first exiting transit vehicle 30. Exiting from transit vehicle may be determining via one or more RTs 38 located at the doors of transit vehicle 30. Such exiting may trigger method 400 to enable tracking rules and alarms referred to herein.
It is to be understood, with respect to 406/408/410/412/418, that such processes may continue until cashbox 36 arrives at vault 22 or some other final intervention or outcome is achieved (such as cashbox 36 being return to transit vehicle 30, cashbox 36 being lost or leaving site 12 without approval, etc).
At 408 tracking rules and alarms (cashbox alarms) are monitored to see if any rules are not being adhered to and alarms are being triggered. Exemplary tracking rules and alarms may include timers (for example for cashbox 36 to reach vault 22 or one or more checkpoints along a secure pathway or secure zones 24), being in safe or secure zones 24 (where cashboxes 36 may be found separate from transit vehicle 30 and/or farebox 34), being in alarm zones 24 (where an alarm will be triggered if cashbox 36 is located therein), crossing alarm checkpoints (such as near exits 16 to ensure cashboxes do not leave an exit 28) and following defined paths 20 (ie being detected by or in communicable range of the proper next CST after, or simultaneously with, being in communicable range with a current CST, where secure zones along defined path 20 may be demarcated by hashed lines 46). Tracking rules and alarms are described in more detail in method 600.
If, at 408, an adherence is returned (no alarms were triggered, or rules violated) then method 400 continues at 410 to query whether cashbox 36 is at vault 22. If it is then method 400 continues to 414 to perform ‘at vault processing’. Cash vault processing may involve, for example, putting cashbox 36 into vault 22 where a process is invoked to safely remove the cash from the cashbox. This typically involves locking the cashbox into an apparatus where the door is opened and the cash extracted. In some cases this is a fully automated process, others involve a mechanical lock and lever mechanism operated by a person and some may involve an accountant or some certified person who has a key to open the cashbox and extract money. For the present invention it may be most important to confirm that cashbox 36 has been delivered either to the correct area or locked into vault 22 and that the cash was removed, the latter being triggered by an event of some sort. The event may be a user identifying themselves and saying that they are the one who removed the cash, a message from an external system, or part of system 10 that tells that the cash was removed, a sensor that detects that the vault mechanism was engaged while the cashbox was in the vault, and the like. In one embodiment vault 22 may have coin and/or bill counters (not shown—referred to as a vault fare deposit counter) and a tag. The vault fare deposit counter may count the fare deposited by a particular cashbox 36 (cashbox deposit amount). This counted amount may then be compared to the cash balance (as determined by, and optionally stored memory in, cashbox 36) to determine that the right amount of cash was deposited in vault 22 from cashbox 36. Such comparison may be made between tag 32 in vault 22 and tag 32a, or via providing cash balances and cashbox deposit amounts to other elements of system 10 and allowing such comparisons. In any event, confirming the right amount was deposited may be required to continue in method 400. System 10 could also identify cashbox 36 being in vault 22 and assuming that the box was emptied.
At 416 cashbox 36 is reset (which may be part of ‘at vault processing’) and at some point it is returned to farebox 34.
If at 408 no adherence is returned then method 400 continues at 418 to invoke corrective or defensive actions (that may depend on the alarm or trigger that caused the non-adherence) in hopes that cashbox 36 will return to adherence and continue to move towards vault 22.
Method 500 may use any number or combination of mechanical keys, electronic keys and CST or RFID based keys.
Method 500 begins at 504 to query whether there are any mechanical keys required. These may be standard mechanical keys as are known in the art.
If mechanical keys are required and presented method 500 proceeds to 506 to query for electronic keys. These may include PINs or passwords that may be typed into farebox 34 and/or MDT 40, a card swiped through a card reader either separate from or integrated into farebox 36, or the like. These may be particular to a Handler, a vehicle 30, a farebox 34 or a cashbox 36.
If electronic keys are required and presented method 500 proceeds to 508 to query for the proper presence of one or more CSTs. These may include CSTs in a secure zone or pathway, having passed a CST at entrance 26 to site 12, lack of presence of alarms, and presence of Handler CSTs, for example.
If proper CST presence is detected then method 500 proceeds to 510 to allow removal of the cashbox 36 and the Handler physically removes it. Registration of the removal then occurs at 512, for example by CSTs passing such event to monitoring system 44 and/or MDT 40. This may trigger tag 32a to be monitored.
Returning to any of 504/506/508, if such type of key or presence is not required method 500 may proceed via the “yes” path. Otherwise method 500 may proceed to 514 where removal of cashbox 36 is prevented. This may lead to method 500 terminating or simply waiting for the required keys/presence to eventually be presented.
Of course it is to be understood that other aspects of system 10 may be used to ensure only timely removal of cashbox 36 occurs. For example, i) if maintenance is to be performed then proper presence of (or confirmation of) the proper parts may be required, ii) if no cash is present removal may be rejected, and the like.
Method 600 may operate substantially continuously from the time a particular cashbox 36 is to be monitored (as initiated by one or more monitoring triggers as described herein) until, for example, a monitoring completed trigger occurs (such as cashbox 36 being emptied into vault 22 and/or its cash present flag being reset, and as otherwise described herein). Method 600 may be performed by monitoring system 44, MDT 40, gateways 38b and the like, alone or together, with various aspects handling various portions and communicating therebetween.
Turning to method 600 it begins from 408 at 602 and continues to 604 to query whether cashbox 36 (and hence tag 32) is in a prohibited zone. If so method 600 proceeds to 616. If not, method 600 proceeds to 606.
At 606 method 600 queries whether cashbox 36 is missing a proper CST. If so method 600 proceeds to 616. If not, method 600 proceeds to 608. Missing a proper CST may include: missing the presence of a Handler, having missed an entrance CST (which may not be a problem but may cause confusion and require an alarm to resolve), and the like.
At 608 method 600 queries whether any improper CSTs are detected. If so method 600 proceeds to 616. If not, method 600 proceeds to 610. Detecting an improper CST may include: detecting being in an alarm or prohibited zone, being close to a checkpoint, and the like.
At 610 method 600 queries whether any CST being detected is out of order. If so method 600 proceeds to 616. If not, method 600 proceeds to 612. Detecting a CST out of order may include: detecting a CST along a secure pathway before an earlier CST is detected (ie a CST was skipped), a CST in a secure zone is detected without an entrance CST being detected, a vehicle CST not being detected before a bay 14 CST is detected, detecting a secure pathway CST before a Handler CST is detected, and the like. There is no particular limitation to what ordering and sequencing may be applied and may be appropriate for a particular monitoring and deposit implementation, and the like.
At 612 method 600 queries whether any timers have expired. If so method 600 proceeds to 616. If not, method 600 proceeds to 614. Timers may include: overall timers to get cashbox 36 emptied, timers along secure pathway 24c (ie every 30 seconds a new CST should be detected), excessive time where a Handler is unsuccessfully trying to remove cashbox 36, and the like.
At 614 method 600 queries whether cashbox 36 is in a secure zone. If not method 600 proceeds to 616. If so, method 600 returns to 602 to continue monitoring.
Returning to 616, if the result of any queries lead to 616 then the alarm is returned and provided, as required. This may have any number of effects, not limited to: communicating with Handler, shutting exits 28 and entrances 26, audible or visual warnings, dispatching security, and the like. These measures may all be taken to prevent loss and to get cashbox 36 moving effectively again.
After 616 method 600 continues to query, at 618, whether the alarm has been dealt with on time and/or effectively. Clearly this will depend on the nature of the alarm(s). For example, a Handler may quicken their pace so timers are reset and no longer are a problem, Handler CST may be detected (they had dropped their badge), and the like. Of course certain alarms (near an exit 28 for example) might not lead to delays for rectification though monitoring may be recommenced after a security intercept for example.
It is to be understood that all of 604/606/608/610/612/614 are depicted as separate, in parallel, and ordered. They need not be any of those things. Further, one may trump another (ie lack of Handler CST may be trumped, and thus no alarm returned, if cashbox 36 is in a secure zone 22—depending on the implementation and preferences of the system users and owners). Each of these permutations are considered within the scope of the present invention.
This concludes the description of the presently preferred embodiments of the invention. The foregoing description has been presented for the purpose of illustration and is not intended to be exhaustive or to limit the invention to the precise form disclosed. It is intended the scope of the invention be limited not by this description but by the claims that follow.
| Number | Name | Date | Kind |
|---|---|---|---|
| 20040135308 | Frank | Jul 2004 | A1 |
| 20090160646 | Mackenzie et al. | Jun 2009 | A1 |
| 20160010384 | Zhang | Jan 2016 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20160290029 A1 | Oct 2016 | US |
