Patent Application
20070150336
The present invention relates to automated parking lot management systems, and is more particularly concerned with a system and method for controlling passage through a gate at en entry or exit for a parking lot.
It is well known in the art to use computer technology, computing devices and networks in systems and methods to manage toll parking lots, and in particular to control passage of a customer in a vehicle through a gate of a parking lot. For example, US patent application US2003/0004792 discloses a system for controlling access to a parking lot using computing devices and a network to control a gate to permit or deny customers to pass therethrough to use the parking lot. However, most such systems and methods require, to install the network, purchase of new and additional components compatible with the computing devices, as well as purchase and installation of wiring adapted to be used with computing devices and other components of system.
To circumvent this problem, some systems and methods for parking lots have adopted use of Echelon® networks, using Echelon® Neuron® microprocessors and connectors provided by Echelon® corporation of San Jose, Calif. Echelon® networks typically allow connection of many different types of devices, for control thereof, to computing devices by using existing and/or inexpensive cabling, such as twisted pairs of copper wires (twisted pairs), found in many parking lots and building structures. Accordingly, use of such Echelon® networks facilitate and reduce cost. For example, US patent application 2003/0078677 discloses use of an Echelon® network to control, among other things, lighting in a parking lot. Unfortunately, Echelon® networks, when implemented using certain types of cables or wires, such as twisted pairs, to connect components thereof, do not provide sufficient levels of bandwidth to allow for transmission of video camera feed thereover to provide images of parking lot to a user of a computing device connected to the Echelon® network for surveillance of the parking lot. Thus, use of Echelon® networks, while practical for installation of network and cost effective, often means that another, separate network must be installed as part of system for capturing images of parking lot for security purposes.
In addition, while many parking lot control systems and methods allow for remote management and control of gate and provide for customer's use of access documents, such as radio frequency identifier (RFID) tags, to validate passage therethrough, these systems often require a user to visit an office and/or attendant at the parking lot to obtain the access document. Alternatively, the access document is ordered by the customer and then subsequently delivered, for example by mail, to the customer at a location specified thereby. In either case, obtaining the access document may require the customer to wait for delivery of the access document and/or may require customer to visit the parking lot between fixed hours when the office is open and/or an attendant is on duty, both of which can be inconvenient.
Accordingly, there is a need for an improved system and method for controlling passage through a gate of a parking lot that facilitates obtaining of access documents and capture of images for surveillance purposes, while still allowing use of inexpensive wiring and existing components typically found in many parking lots.
It is therefore a general object of the present invention to provide an improved system and method of controlling movement of a gate of a parking lot for controlling passage of a customer therethrough in a vehicle.
An advantage of the present invention is that the system and method permit use of inexpensive wires, such as twisted pairs, typically already found in the parking lot to connect components used in the system and method.
Another advantage of the present invention is that the many of the components used in system are typically already found in parking lots and/or are inexpensive.
A further advantage of the present invention is that the system and method provide for capture and transmission of images of parking lot using such inexpensive/existent wires and equipment.
Still another advantage of the present invention is that the system and method provided allows customers to easily obtain access documents, with minimal delay, for use at parking lot to obtain passage through gate and use parking lot.
According to a first aspect of the present invention, there is provided a system for controlling passage through at least one electronic gate of a parking lot, the system comprising:
In a second aspect of the present invention, there is provided a method for controlling passage through at least one electronic gate of a parking lot with an access control module connected to the gate and a lot control device connected to the access control module by a first network, the method comprising the steps of:
Other objects and advantages of the present invention will become apparent from a careful reading of the detailed description provided herein, with appropriate reference to the accompanying drawings.
Further aspects and advantages of the present invention will become better understood with reference to the description in association with the following Figures, in which similar references used in different Figures denote similar components, wherein:
With reference to the annexed drawings, the preferred embodiments of the present invention will be herein described for indicative purpose and by no means as of limitation.
Reference is now made to
As shown in
ACM 14 is connected to lot control device (LCD) 20, which provides control of ACM 14 within parking lot, and thereby movement of gate 12. In addition, LCD 20 also controls and manages most other components of system 10, including user interface (UI) 22 which provides for customer input and output and displays messages on display thereof, not shown, for customer, radio frequency (RF) identifier (RFID) reader (RFIDR) 26 for reading radio frequency identifiers, camera control means (CCM) 28 and cameras 30 connected thereto for capturing images of the parking lot and gates thereof, cash receiving means (CRM) 32 for receiving coins and banknotes from customer, and satellite telephony modules (STM) 34 and master telephony module (MTM) 36 which together provide for telephone communication between a customer and an attendant responsible for assisting customers. In general, CRM 32, STM 34, and UI 22 will be located in close proximity to ACM 14, possibly in the same housing as ACM 14. However, these components 22, 32, 34 may also be situated separately from ACM 14 in parking lot if desired.
LCD 20 is further connected to local data base (LDB) 44. LDB 44 contains, among other things, tariff information for access rights for passing through gate 12 and using parking lot, access identifiers which are associated with access rights records specifying access rights for a customer, records on entry and exit from parking lot for identifying movement of gate 12 between first and second positions 16, 18, and payments effected in parking lot for access rights. In general, there is one LCD 20 per parking lot, with the LCD 20 typically being situated therewithin. LDB 44 is also situated in parking lot and may, if desired, be co-located with LCD 20 in the same housing, i.e. as part of LCD 20.
LCD 20 is further connected to computing devices (CD) 38, 40, 42 from which, respectively, customers, attendants, and cluster administrators may effectuate operations relating to the use of parking lot and management thereof. CDs are generally of three categories. Attendant computing devices (ACD) 38 are generally used by attendants to monitor the parking lot, to provide assistance to customers, and to configure parking lot devices such as ACM 14 and LCD 20. Customer computing devices (CCD) 40 allow customers to remotely procure access rights and access documents corresponding thereto for using parking lot. Cluster administrator computing devices (CLCD) 42 are used by cluster administrators to monitor parking lot, assist customers as required, configure parking lot components such as ACM 14 and LCD 20, set costs for access rights, and verify transactions. In general, CLCDs 42 are connected to a remote database (RDB) 46, which remotely stores and archives all of the information found in LDB 44 and provides information thereto, the two databases 44, 46 updating each other in response to changes therein. RDB 46 may contain information on a plurality, i.e. a cluster, of parking lots, in which case the RDB 46 is connected to the respective LDB 44 of each parking lot in cluster via the respective LCD 20 for that parking lot. Thus, CLCD 42 connected to RDB 46 can be used to administrate and control any parking lot in the cluster. ACDs 38 also may access RDB 46 and may also be used to access and control multiple parking lots. However, the rights of attendants using ACDs 38 to administrate and control any parking lot via RDB 46, and LCD 20 connected thereto, are defined and controlled by a cluster administrator using CLCD 42. In general, an attendant can accomplish any task from an ACD 38 that can be accomplished by a customer from a CCD 40. A cluster administrator can accomplish any task from a CLCD 42 that may be executed by an attendant from an ACD 38. RDB 46 may be incorporated into a given CLCD 42 or may exist on a standalone computing device connected to CLCD 42.
Reference is now made to
Referring now to
Echelon® network 48 advantageously allows use of existing and/or inexpensive wiring, such as twisted pairs, to connect components and to provide control thereof by communication of data and commands using Echelon® protocol, which is an open device control protocol. Thus, use of Echelon® network 48 and Echelon® protocol allows for programmable configuration and use of existing and/or inexpensive infrastructure for connecting and implementing control of components 14, 20, 22, 26, 28, 32, 36 of system 10, as well as other components of system 10 connected to components 14, 20, 22, 26, 28, 32, 36. Accordingly, reductions in cost for material, such as wiring, can be achieved by deploying Echelon® network 48. Further, reductions in time for installation and implementation of system 10 are also gained, as Echelon® network 48 provides easy connection between myriad devices and a protocol for communication therebetween. Complete information on Echelon® technology, including FTT-10, Neuron® processors 60, and Echelon® protocol is available from Echelon® corporation at Internet URL: http://www.echelon.com.
Referring again to
In general, Internet network 52 enables a number of operations, including control of LCD 20 and gate 12 from ACD 38 or CLCD 42, to assist customers. In addition, Internet network 52 allows entry, modification, and maintenance from CDs 38, 40, 42 of customer information, including access rights, in RDB 46 for subsequent updating of corresponding information in LDB 44. Further, Internet network 52 is also connected to a credit card processing network (CCPN) 69 to permit payment from computing devices 36, 38, 40, as payment receiving means, by credit card for access rights to parking lot by transmitting therefrom a customer's credit card number and respective expiry date to CCPN 69. In general, access to LDB 44, RDB 46, and LCD 20 is limited to users, i.e. customer, attendant, or cluster administrator, who have the requisite authorization credentials, typically a username and password assigned to user that must be entered from a computing device 38, 40, 42. In general, only attendants and cluster administrators will have authorization credentials permitting access to LCD 20 and LDB 44. Optionally, and for additional security, users may be restricted to use of authorization credentials from a specific CD 38, 40, 42. Communications between LDB 44, RDB 46, LCD 20, and CDs 38, 40, 42 are effected using 128 bit encryption for additional security, as are communications between CDs 38, 40, 42, LCD 20 and CCPN 69 over Internet network 52.
Referring now to
To aid the reader in understanding the functioning of ACM 14, reference is made to
ACM 14 may also be connected to receipt printer 132 for printing out receipts, optional RFID writer (RFIDW) 106 for writing RFID to RFID transponders 112 on RFID tags, and RFID tag distributor (RFIDD) 108,.which distributes RFID tags with RFIDs written thereupon by RFIDW 106 to customers. As explained below, RFID tags with RFID transponders, which broadcast RFIDs as access identifiers 82, serve as access documents 80. Finally, ACM 14 is also connected to credit card reader (CCR) 102 for reading credit card information, such as credit card numbers and expiry dates, from credit cards inserted therein by customers. Finally, ACM 14, which also has Neuron® microprocessor 60, is connected via Echelon network 48® to LCD 20, RFIDR 26, CRM 32, CCM 28, UI 22, and MTM 36, each of which also has a Neuron® microprocessor® 60, and can communicate with them via Echelon® protocol for processing and generating messages and commands. ACM 14 is also connected to Internet network 52 via LCD 20, hub 62, and router 64.
Reference is again made to
It should be noted that acquisition of access rights 86 by customer does not automatically imply that an amount due 100 will be incurred. For example, as will be explained below, customers may be subscribers to parking lot, in which case customer may be billed on a periodic basis for access rights 86 procured and associated with access identifier 82 in access rights record 84. It should also be noted, as will also be explained in detail below, that CDs 38, 40, 42 can also be used in conjunction with a credit card of a customer as payment receiving means and for procuring access identifiers 82 and access rights 86 associated therewith, as well as for procuring access documents 80 associated with access identifier 82.
Reference is again made
Access document 80 may also be a bar code document, i.e. a ticket or card having a bar code inscribed thereupon, the access identifier 82 typically being an alphanumeric string encoded as bar code. When access document 80 is bar code document, access document reading means is BCR 78, connected to ACM 14. BCR 78 can read bar code when bar code document is presented by customer thereto and translate bar code into the alphanumeric string representing access identifier 82. After reading bar code, BCR 78 transmits access identifier 82 encoded in bar code to ACM 14 connected to BCR 78. As noted previously, ACM 14a may also have BCP 76 connected thereto for printing access identifier 82 as bar code on bar code document, which can then be used as access document 80. Thus, customer can procure access document 80, i.e. bar code document, at parking lot. For example, BCP 76 may be activated by customer using ACM 14a or UI 22 situated at entry of parking lot which causes a message to be sent to ACM 14, the Neuron® processor 60 of which then instructs bar code printer 76 to print bar code on bar code document, as access document 80, which is then taken by customer. ACM 14a at entry to parking lot then causes gate 12a to move from first position 16 into second position 18, to allow user to pass therethrough to enter the parking lot. However, customer will have to present bar code document to BCR 78 connected to ACM 14b situated at exit of park for reading of bar code and pay any amount due 100 for access rights 86 associated with bar code as access identifier 82 in access rights record 84 before ACM 14b will move gate 12b from first position 16 into second position 18 to allow user to pass therethrough and exit parking lot.
BCP 76 may be, for example, a printer capable of printing a bar code on a paper, cardboard, or plastic ticket using the CODE 128C standard. The bar code, as access identifier 82, may contain, for example, twenty-four characters indicating, for example, the year, date, time, hour, minute, and second of entry into the parking lot, as well as an additional 6 characters. In such case, time of entry would therefore be stored directly on access document 80 and could be used, notably when LDB 44 and LCD 20 are unavailable, by ACM 14b in conjunction with BCR 78 to calculate amount due 100. Alternatively, BCP 76 could encode different data, such as a credit card number, as bar code for use as access identifier 82. BCR 78 must be able to read bar codes using the bar code standard chosen. Thus, for the purposes of this example, BCR 78 would have to be able read a twenty-four character bar code encoded using the CODE 128C standard. BCP 76 and BCR 78 may also have RS-232 ports for RS-232 communications with, respectively, ACM 14a, 14b.
Referring still to
It should be noted that, regardless of type of access document, access identifier 82 inscribed thereupon may be credit card number of credit card of customer. Further, customer may have multiple access identifiers 82 which are associated with each other for designating the same access rights record 84. For example, a customer could have an RFID as a first access identifier 82a and a credit card number as a second access identifier 82b associated with the same access rights record 84. The customer could then use either credit card, having credit card number inscribed thereon as access identifier 82b, or RFID tag, having RFID inscribed as access identifier 82a, as access document 80 for the same access rights record 84.
In general, when RFIDW 106, RFIDD 108, and/or BCP 76 are present, alpha numeric string of alpha numeric characters for access identifier 82 and access rights record 84 may be generated by a number of methods. Firstly, Neuron® processor 60 of ACM 14 may generate access identifier 82, as an alphanumeric string, and transmit it to RFIDW 106 or bar code printer 76 for writing as, respectively, bar code or RFID. Neuron processor 60 of ACM 14 may also, based on customer selections entered by customer into UI 22 and parking tariffs calculated by ACM 14 and/or LCD 20, generate or modify access rights record 84 including access rights 86 and amount due 100, for access identifier 82, which is then transferred to LCD 20 over Echelon® network 48 for storage in LDB 44. Alternatively, alphanumeric string for access identifier 82 can be generated by Neuron® micrprocessor of LCD 20 and transmitted in Echelon® protocol over Echelon® network 48 to Neuron® microprocessor 60 of ACM 14, which then transmits access identifier 82 to RFIDW 106 or BCP 76 for writing as, respectively, RFID or bar code. In this case, Neuron® microprocessor 60 of LCD 20, based on customer selections at UI 22 and tariffs calculated by LCD 20 and/or ACM 14, generates and/or modifies access rights record 84, including access rights 86 and amount due 100 and transmits access rights record 84 to LDB 44. Typically, RDB 46 is subsequently updated with all information stored in LDB 44.
Alphanumeric string for access identifier 82, as well as access rights record 84 including access rights 86 and amount due 100, may also be generated and modified by requesting RDB 46, from CD 38, 40, 42, to generate and/or update access identifier 82 and access rights record 84. In such case, RDB 46, based on information entered into CD 38, 40, 42 for access rights 84 and type of access document 80, i.e. credit card, RFID tag, or bar code document, generates and/or modifies access rights record 84, including access identifier 82, and transmits the access rights record 84 over internet network 52 to LCD 20 which in turn transmits the record 84 to LDB 44. Once access rights record 84 is present on LDB 44, access identifier 82 thereof may be transferred by LCD 20 to ACM 14, which may then transmit access identifier 82 to RFIDW 106 or BCP 76 for writing as, respectively, bar code on bar code document or RFID on RFID transponder 112 of RFID tag. Thus, customers can procure access rights 86 and access identifier 82 outside of parking lot and/or in advance of customer's arrival at parking lot, and thereby obtain a subscription to parking lot, i.e. become a subscriber to parking lot, and/or reserve a parking space in parking lot prior to arrival therein. Access document 80, i.e. bar code document or RFID tag, may then be distributed to customer at parking lot using BCP 76 or RFIDW 106, in conjunction with RFIDD 108, or may be distributed to customer outside of parking lot, for example, by mailing RFID tag or bar code document to customer.
Further, and advantageously, when requesting creation and/or update of access rights record 84 from, respectively, CD 38, 40, 42, attendants, customers, and cluster administrators may enter a credit card number and, optionally, a respective expiry date of a credit card of customer as access identifier 82 for access rights record 84. Since CCR 102 may be used as access document reading means, customer may thus instantly obtain an access document 80, i.e. credit card already in customer's possession. As many credit card readers 102 can generally read debit cards issued by financial institutions, a debit card number for a debit card held by customer could similarly be entered into CD 38, 40, 42 as access identifier 82 to allow customer to instantly use debit card as access document. As with credit card when used as access document 80, customer would then, upon arrival at parking lot, insert debit card into CCR 102, as access document reading means, which would transmit debit card number, as access identifier 82, to LCD 20 to identify access rights record 84 associated therewith in LDB 44. Based on access rights 86 and amount due 100, customer could then pass through gate 12.
In addition, since customer may have more than one access document 80 and more than one access identifier 82 associated with access rights record 84, CD 38, 40, 42 can be used to request that credit card number be assigned as access identifier 82 for use with credit card as access document 80 on a temporary basis, if desired, i.e. as a temporary access identifier 82b and temporary access document 84. At the same time, CD 38, 40, 42 can be used to request that an additional access document 80, such as a bar code document and/or RFID tag be assigned to customer, perhaps as permanent access document 80 having a permanent access identifier 82, and this additional access document 80 be subsequently distributed to customer. For example, customer could have access rights record 84 created or modified on CD 38, 40, 42 using credit card number as access identifier 82b and credit card as a first, perhaps temporary, access document 80 and also request a bar code document or RFID tag, as a second, perhaps permanent, access document 80 to be picked up by customer from ACM 14 at parking lot. Access rights record 84, as requested from CD 38, 40, 42, would then be created or modified on RDB 46 and transferred to LDB 44. Customer could then, upon arrival at parking lot, insert credit card as access document 80 into CCR 102. CCR 102 would then read credit card number, and possibly expiry date, and this credit card information would be transferred by Neuron® microprocessor 60 of ACM 14 to LCD 20 over Echelon® network 48. LCD 20, and notably Echelon® microprocessor 60 thereof, would then look up credit card number in LDB 44, which would be identified therein as first, possibly temporary, access identifier 82b for access rights record 84. LCD 20, notably Neuron® processor 60 thereof, would then consult access rights record 84, which would include second, possibly permanent, access identifier 82a and access document distribution information 300 specifying that bar code document or RFID tag is to be distributed as second, possibly permanent, access document 80 to customer. LCD 20 would then transmit access rights 86, as well as any amount due 100, second access identifier 82a, whether the same or different than credit card number, along with message to distribute second access document 80, i.e. bar code document or RFID document, to ACM 14. In response, ACM 14 would prompt user to pay any amount due 100 via UI 22. Once amount due 100 is paid, or if there is no amount due 100, ACM 14 would then send a message containing second access identifier 82a to BCP 76 or RFID writer 102, depending, respectively, on whether second access document 80 designated in access document distribution information 300 is specified as bar code document or RFID tag. If second access document 80 is RFID tag, RFIDW 106 writes RFID encoding second access identifier 82a to transponder 112 of RFID tag and RFID tag is distributed to customer by RFIDD 108. If second access document 80 is bar code document, BCP 76 prints bar code on bar code document, which is then retrieved from BCP 76 by customer. Customer may then use bar code document or RFID tag as access document 80.
It should be noted that tariff information 126 for parking lot is stored in LDB 44, RDB 46, ACM 14, and LCD 20, thus ensuring that LCD 20 and ACM 14 are always capable of calculating amount due 100. Further, ACM 14 and LCD 20 each have, respectively, ACM memory unit 128 and LCD memory unit 130 for temporarily storing access rights record 84 in the event that LDB 44 and RDB 46 are unavailable, thus allowing ACM 14 and LCD 20 to temporarily act as standalone devices, the access rights records 84 being temporarily stored thereon and transferred to LDB 44, and eventually RDB 46, when LDB 44 and RDB 46 become available. It should further be noted that attendants and cluster administrators may be able to directly modify and create access rights records 84 on LDB 44 from, respectively, ACD 38 and CLCD 42. However, in all cases of creation or modification of any data on either LDB 44 or RDB 46, the data modified or created thereupon relative to any parking lot associated with a given LDB 44 will eventually be synchronized on LDB 44 and RDB 46.
It is also important to note that many other technologies may be used as access documents 80 having access identifiers 82 for reading by access document reading means. For example, access document 80 could be a so-called “smart card” having an electronic chip with access identifier 82 inscribed thereon for reading by a “smart” card reader. Access document 80 could also be a document or mechanism encoding access identifier 82 in a format readable by an optical reader or infra-red signal detector/reader, in which case, respectively, the optical reader or infra-red signal detector/reader would serve as access document reading means. Access document 80 could also be, similar to the case of credit card/debit card, a magnetic card having a magnetic strip in which access identifier 82 is encoded for reading by a magnetic card reader. In brief, any media capable of encoding an access identifier 82 that is readable by a machine or device, as access document reading means, for transmission to LCD 20 may be deployed as access document 80.
Referring still to
Generally, to effect payment within parking lot, customer presents access document 80 to access document reading means, i.e. CCR 102, RFIDR 26, or BCR 78. Access identifier 82 is then transmitted to LCD 20 which calculates amount due 100 based on time and date of entry and/or exit and by consulting access rights record 84 in LDB 44, if LDB 44 is available, which may indicate that an amount due 100 is payable based on a variety of factors, such as: whether access rights 86 have been pre-paid in advance, whether user is billed by mail for surplus use at home or work, etc. For example, access rights record 84 may indicate that customer is a subscriber that is billed on a periodic basis for access rights 86 at a home address or to a credit card number of customer. In such case, access rights record 84 in LDB 44 would indicate that there is no amount due 100 for access rights 86 used for parking in parking lot. However, in this example, any use of parking lot not covered by the access rights 86 that are indicated in access rights profile 86 as already being paid would nevertheless be recorded for eventual billing to customer. Alternatively, as another example, access rights record 84 could indicate that customer is a subscriber that has pre-paid for a subscription conferring unlimited access for a given time period in which customer used parking lot, in which case there would also be no amount due 100 and no further billing would be undertaken. Access rights record 84 could also indicate, for example, that customer has no subscription, i.e. is not a subscriber, that the subscription does not confer access rights 86 for the period in which parking lot is used, or that a payment for a subscription conferring access rights 86 for use of parking lot is immediately due, in which case an amount due 100 will be payable using payment receiving means and calculated by LCD 20 in conjunction with LDB 44. Should LDB 44 be unavailable, LCD 20 will calculate and require payment of an amount of money as amount due 100 based on tariff information 126, stored on ACM 14, LCD 20, and LDB 44, time of entry and, if applicable, time of exit, time of entry being temporarily stored in association with access identifier 82 either on access document 80, LCD 20, or ACM 14 and time of exit, if applicable, being stored temporarily on ACM 14 and/or LCD 20. Once LDB 44 is available again, time of entry, time of exit, and amount paid 304 as amount due 100 are transferred thereto and credited to access rights record 84. Similarly, should LCD 20 be unavailable, ACM 14 will calculate an amount of money to be paid as amount due 100 based on tariff information 126 stored on ACM 14, time of entry and, if applicable, time of exit, time of entry being temporarily stored in association with access identifier 82 either on access document 80 or ACM 14 and time of exit, if applicable, being stored temporarily on ACM 14. Once LCD 20 is available again, time of entry, time of exit, and amount paid 304 as amount due 100 are transmitted thereto for storage thereby in access rights record in LDB 44 when LDB 44 is available. In this fashion, system 10 always ensures that access rights 84 are paid for, even if LCD 20 and LDB 44 are unavailable.
If there is an amount due 100, i.e. an amount due 100 calculated by ACM 14 and/or LCD 20 is greater than zero, LCD 20 or, if LCD 20 is unavailable, ACM 14 will transmit amount due 100 to UI 22 which displays amount due 100 and requests payment thereof. Customer may then use payment receiving means, namely CRM 32 or CCR 102, to pay amount due 100. Once payment of amount due 100 is successfully effected, payment thereof is recorded by LCD 20 in LDB 44 as amount paid 304 in access rights record 84 associated with access identifier 82 and LCD 20 sends message to ACM 14 over Echelon® network 48 authorizing passage of customer in vehicle through gate 12. Again, if LDB 44, but not LCD 20, is unavailable when payment is effected, amount paid 304 for payment of amount due 100 will be temporarily stored on LCD 20 and forwarded to LDB 44 for storage in access rights record 84 as soon as LDB 44 again becomes available. If LCD 20, and therefore LDB 44 as well, is unavailable for ACM 14 when payment of amount due 100 is effected, ACM 14 causes gate 12 to move from first position 16 to second position 18 to allow passage therethrough and will temporarily store amount paid 304 for payment of amount due 100 in association with access identifier 82, which will be forwarded to LCD 20 for storage in LDB 44 as soon as connection to LDB 44 via LCD 20 becomes available. After passage of customer in vehicle through gate 12, ACM 14 returns gate 12 to first position 16 to prevent unauthorized passage therethrough. Payment of amount due 100 and amount paid 304 are forwarded to RDB 46 from LDB 44, via LCD 20 and Internet network 52 for storage therein in association with access identifier 82 to update RDB 46.
If user selects CRM 32 for payment of amount due 100, customer inserts coins and banknotes into CRM 32 which records the amount paid 304 therein and transmits the amount paid 304 to LCD 20 or, if LCD 20 is unavailable, to ACM 14. Once the amount paid 304 at CRM 32 is equal to the amount due 100, ACM 14 causes gate 12 to move from first position 16 into second position 18 to allow customer to pass therethrough. Payment of amount due 100 is transferred to LDB 44, as described above, via LCD 20 for storage in association with access identifier 82 in access rights record 84. Access rights record 46 on RDB 46 is then updated with payment of amount due 100 from LDB 44.
Should customer elect to pay amount due 100 using CCR 102, user inserts credit card into CCR 102, which serves as payment receiving means. CCR 102 reads credit card number and respective expiry date of credit card, which are transmitted thereby, through Neuron® microprocessor 60 of ACM 14, to LCD 20 in Echelon® protocol over Echelon® network 48. LCD 20, i.e. Neuron® microprocessor 60 thereof, receives credit card number and expiry date and, if LDB 44 is available, consults LDB 44 to determine whether credit card is inscribed on an invalid card list 132 of invalid credit card numbers. If so, LCD 20 instructs ACM 14 to refuse credit card, which is either returned to customer or retained by CCR 102 for fraud prevention purposes. If credit card is not on invalid card list 132, LCD 20 further consults LDB 44 to determine whether there is an access rights record 84 associated with credit card number, i.e. whether credit card number is an access identifier 82 for customer, in which case credit card is, in itself, an access document 80. If credit card is an access document 80, LCD 20 will check, again for fraud prevention purposes, whether expiry date for credit card was entered as part of access rights record 84 and, if so, whether expiry date read by CCR 102 matches that in access rights record 84. If these expiry dates are not the same LCD 20 instructs ACM 20 to refuse credit card, which is either returned to customer or retained by CCR 102 for fraud prevention purposes. If expiry dates are the same, then LCD 20 transmits amount due 100 with credit card number and respective expiry date through hub 62 and modem 64 to CCPN 69 connected to Internet network 52. CCPN 69, typically maintained by financial institutions for credit cards such as Mastercard®, Visa®, American Express® or the like, receives the amount due 100, credit card number, and expiry date, and processes payment of amount due 100 by either authorizing or declining the payment of the amount due 100 and sending respectively either a payment authorized message or payment declined message back to LDC 20. If payment of the amount due 100 is declined by CCPN 69, LCD 20 instructs ACM 14 to refuse credit card, which is either returned to customer or retained by CCR 102 for fraud prevention purposes. If the payment is authorized by CCPN 69, then LCD 20 records, in LDB 44, amount paid 304 and records the amount due 100 as paid in LDB 44, along with an authorization number transmitted as part of authorization message. LCD 20 then instructs ACM 14 to allow passage through gate 12. If credit card is not an access document 80 or the expiry date was not previously recorded in association with credit card number in LDB 44, LCD 20 conducts the same steps as for when credit card is an access document 80, except that credit card and expiry date are not verified in LDB 44. It should be noted that credit card numbers and respective expiry dates, can be recorded in RDB 46 and LDB 44 in association with access identifier 82 as part of access right record 84 to allow LCD 44 to obtain payment of amount due automatically by transmitting the credit card number and expiry date along with amount due 100 to CCPN 69, without requiring customer to insert credit card into CCR 102, thus saving customer time and effort.
It should be noted that, if CCPN 69 is also able to process debit card transactions, customer could also use CCR 102 to pay amount due 100 with a debit card. In such case, user would insert debit card into CCR 102 and then enter the customers Personal Identification Number (PIN) using UI 22. Debit card number of debit card would be read by CCR 102 and transmitted, along with PIN entered into UI 22 and amount due 100, to CCPN 69 for processing, very much in the same manner as for credit cards, except that expiry date for debit card would not need to be verified. If CCPN 69 is not able to process debit card payments, system 10 could nevertheless be connected to a debit card payment network, not shown, by Internet network 52, in which case debit card network would function in the same manner as just described for CCPN 69 with regard to debit card payments to enable use of debit cards for paying amount due 100.
When customer is not present in parking lot, CDs 38, 40, 42 may be used as payment receiving means, in conjunction with credit card number and expiry date of credit cards held by customer, to pay amount due 100, arrange pre-payment of access rights for a subscription, and to purchase new access rights 84. In such case, credit card number, and possibly respective expiry date thereof, are entered from CD 38, 40, 42 along with access identifier 82, which identifies access rights record 84 in RDB 46. As mentioned previously, credit card number and expiry date may also be registered in association with access identifier 82 as part of access rights record 84 in RDB 46, and transferred therefrom to LDB 44, in which case only access identifier will need be entered from CD 38, 40, 42 and user of CD 38, 40, 42 will be able to select any credit card number associated therewith for payment of amount due 100. Credit card number, whether directly entered from CD 38, 40, 42 or provided by RDB 46 is then checked against invalid card list 132. If the credit card number is not on invalid card list 132, credit card number, expiry date, and amount of payment, for example amount due 100, are transmitted over Internet network 52 to CCPN 69. Payment is then authorized or declined by CCPN 69, as described above for use of CCR 102. If payment is declined by CCPN 69, then a message to this effect is displayed by CD 38, 40, 42 and, if user of CD 40, 42 is an attendant or cluster administrator to which customer has physically presented credit card for payment, attendant or cluster administrator may retain credit card for fraud prevention purposes. If payment is authorized by CCPN 69, payment is then recorded in RDB 46 and, if required, LDB 44 is subsequently updated to reflect payment. Notably, if amount due 100 is paid, access rights record 84′ in LDB 44 will be updated to reflect that amount due 100 is zero. For example, such payments may be effected by customers over the telephone or in person by communicating with attendants or administrators who could effectuate the payment by entering credit card number and expiry date, as well as amount due 100 from, respectively, an ACD 38 or CLCD 42. If payment is effected in person to attendant or administrator, payment may also be made in cash and/or any other form for which attendant and administrator are equipped to receive payment, in which case attendant and/or administrator receive payment of amount due 100 and enter payment thereof into RDB 46 and transferred therefrom to LDB 44.
Access rights record 84, including access rights 86, access identifier 82, access document distribution information 300, access document type information 302 specifying types of access documents associated with access identifiers 82 for access rights record 84, credit card number and expiry date, reservations 322 for parking lot, as well as any other information desired or required for access rights record 80, may be created and modified by customer, attendant, or cluster administrator respectively from CCD 40, ACD 38, and CLCD 42. Typically, creation or modification of access rights record 84 is effected from CD 38, 40, 42 by accessing RDB 46 over Internet network 52. The access rights record 84, or at least access identifier 82, amount due 100, and access rights 86, type of access document 80, access document distribution information 300, access document type information 302 and any reservations 322 associated with access identifier 82 for parking spaces in parking lot, are then transferred to LDB 44 for storage in access rights record 84′ thereof. Administrators and attendants can also issues commands from, respectively, ACD 38 and CLCD 42 to ACM 14, via LCD 20, to instruct ACM 14 to allow passage through gate 12, namely by causing gate 12 to move from first position 16 to second position 18, or to deny passage through gate 12 by moving gate 12 or maintaining gate 12 in first position 16.
To provide the reader with a better understanding of use of system 10 from a customer's perspective, reference is now made to
If customer decides not to create or modify access rights record 84 outside of parking lot or away from ACM 14, or once this operation is completed, customer arrives, at step 208 at parking lot, typically at ACM 14 thereof. If customer does not have access document 80, evaluated at step 210, then customer proceeds to step 212. Otherwise, customer proceeds to step 216. At step 214, customer procures an access document 80, typically a bar code document having access identifier 82 printed thereon by BCP 76 as a bar code. The bar code document is typically obtained at ACM 14a, i.e. at entry to parking lot. Simultaneously, still referring to step 214, an access rights record 84′ having the access identifier 82 and access rights 86 acquired therewith is created in LDB 44 and eventually transferred therefrom to RDB 46. Customer then proceeds to step 228. At step 216, customer presents an access document 80, temporary or permanent, which, as previously stated, may be either a credit card, bar code document, or an RFID tag, to access document reading means, which reads access identifier 82 from access document 80 and forwards it to LCD 20, which consults LDB 44. At step 218, by consulting access rights record 84′ in LDB 44, LCD 20 determines whether another access document 80, for example a permanent access document 80, is to be delivered to customer at this time, based on contents of access document distribution information 300. If not, then the next step is step 228. Otherwise, at step 220, access document 80 is distributed to customer at ACM 14, typically by printing from bar code printer 78 or by writing access identifier to transponder 112 by RFIDW 106 and subsequent distribution of RFID tag to customer from RFIDD 108. This is usually the case when customer, at step 204, elects to use credit card as access document 80 with credit card number as access identifier as an initial access document 80, either temporary or permanent, prior to obtaining an RFID tag or bar code document as access document 80. At step 222, following distribution of access document 80, access rights record 84′ in LDB 44 is updated to reflect that access document 80 has been delivered. Access rights record 84 for the same access identifier 80 in RDB 46 is, subsequently, also updated with this information. The process then proceeds to step 224.
At step 224, LCD 20 consults LDB 44 to determine whether, for access identifier 82 of access document 80 presented or distributed, access rights 86 have been inscribed in corresponding access rights record 84′ for parking lot where document 80 is presented. If yes, then step 228 is next. Otherwise, at step 226, access rights 86, generally at request of customer using UI 22, are created/accorded for parking lot, and step 228 is next.
At step 228, either ACM 14 or LCD 20 calculates, as described previously, whether there is an amount due 100 and the actual amount of amount due 100. If there is no amount due, i.e. amount due 100 is zero, then ACM 14 causes, at step 232, movement of gate 10 to allow passage through gate 12 and LDB 44 is updated, at step 234, to record passage, including time thereof, in association with access identifier 82, of customer through gate 10. RDB 46 is subsequently updated in the same fashion, based on information in LDB 44, to record therein passage of customer through gate 12. The process, now at step 234, ends. From step 228, if amount due is greater than zero, then, at step 230, customer is given the opportunity to pay amount due 100 using payment receiving means at parking lot, namely CCR 102 or CRM 32. If customer successfully pays amount due, then the next steps are, respectively, steps 232 and 234, as previously described. Otherwise, customer is refused passage, at step 238, through gate 12. Refusal of passage, including time of refusal, is recorded in LDB 44 in association with access identifier 82 in LDB 44 at step 236, at which point the process ends. The refusal of passage through gate 12 is also recorded in RDB 46, based on information provided thereto from LDB 44.
Referring again to
To better explain the method by which images are captured for surveillance, reference is now made to
CCM 28 can capture, save on CCM memory unit 224, and transmit across Echelon® network 48 one compressed image every 3 seconds, thus permitting a series of images from one camera 30 to be transmitted every three seconds to provide an image record of occurrences in parking lot. It should be noted that bandwidth provided by Echelon® network when implemented using Echelon® network links 58 consisting twisted pairs, namely 78 Kbps, is insufficient for transmitting NTSC video or an uncompressed digital video stream. Thus, digitization and compression of NTSC video stream into JPEG compressed images by CCM 28 advantageously allows conventional NTSC video cameras 30, used in many parking lots, to be readily adapted for use with system 10 on Echelon® Network where Echelon network links 58 are twisted pairs of wires. Otherwise, use of such NTSC video cameras 30 with Echelon® network across twisted pairs of wires would be difficult, if not impossible.
In general, image capture requests are automatically generated by an ACM 14 when vehicle sensor 74 detects a vehicle in proximity to the ACM 14, the image capture request designating the camera 30 closest to ACM 14. Similarly, image capture requests are also generated by ACM 14 when. a user presents access document 80 for reading by access document reading means, with the ACM 14 transmitting access identifier 82 associated with access document 80, and read by access document reading means, as part of image capture request. Also, should an alarm or assistance request be activated by a customer by using UI 22, UI 22 will also generate an image capture request. ACM 14 may also generate an image capture request if an irregularity is detected, such as gate 12 being moved into second position 18 without a vehicle being detected by vehicle sensor 74, in which case an alarm will also be generated and transmitted to attendant on ACD 38 and/or attendant telephone 54. Generally, when image capture request is generated in conjunction with an alarm or assistance request, images are captured at pre-determined intervals until an attendant deactivates the alarm. Generally, each camera 30 will be associated with a certain portion or zone of parking lot, with CCM 28 capturing image of camera 30 associated with zone in which the ACM 14 or UI 22 that generates the image capture request is associated. A specific camera 30 may also be designated as designated camera 30 in image capture request. Finally, it should be noted that image capture requests, designating designated camera, may also be sent from LCD 20. This latter situation is typically the case where a user, i.e. attendant or cluster administrator of respectively ACD 38 or CLCD 42 issues the request therefrom for viewing of image thereupon, the request being transmitted from ACD 38 or CLCD 42 to LCD 20 on Internet network 52 and then broadcast from LCD 20 to CCM 28 in Echelon® protocol over Echelon® network 48.
To aid the reader in understanding STM 34 and MTM 36, reference is now made to
It should be noted that LCD 20 can also simultaneously cause to be sent, to the ACD 38 of attendant, information about the ACM 14 connected to UI 22 from which customer activates STM 32, UI 22 itself, status of parking lot, and customer derived from access rights record 84 associated with access identifier 82 of access document 80, if any, presented by customer. In addition, attendant may also consult RDB 46, and possibly LDB 44, using ACD 38, to obtain information on customer. In addition to telephone communication, STM 34 may play, using speakers 72, pre-recorded audio messages in response to audio message commands, which contain an audio message number associated with a given audio message, sent to STM 34 from LCD 20, ACM 14 or CRM 32 over Echelon® network 48. The audio messages are typically stored, in association with their respective audio message numbers, on audio message memory unit 280 of STM 34. Audio message memory unit 280 may be a disk drive, a removable flash memory card, or any other type of memory capable of storing audio files. Audio messages are typically created by recording audio on ACD 38 or CLCD 42 into a WAV audio file in WAV format, and then converting the WAV file into a compressed audio format in which audio is saved as audio message. Audio message is then transferred from ACD 38 or CLCD 42 to audio message memory unit 280. For example, if audio message memory unit 280 is a removable flash memory card, audio message memory unit 280 could be initially connected to ACD 38 or CLCD 42 for saving of audio messages thereupon, disconnected from ACD 38 or CLCD 42, and then connected to STM 34 to transfer audio messages thereto.
To aid the reader in better understanding databases LDB 34 and RDB 46, reference is again made to
RDB 46 maintains and archives all access rights records 84 found on every LDB 46 of cluster of parking lots associated with RDB 46. Typically, each access rights record 84 in RDB 46 has at least one access identifier 82, such as credit card number or another alpha numeric string for RFID or a bar code, associated therewith and which serves to identify access rights record 84 in database 46. For example, an access rights record in RDB 46 could have a primary access identifier 82a and a number of associated secondary access identifiers 82b, all identifying the same access record 84. It should be noted that all access identifiers 82 must be unique. Each access rights record 84 designates a collection of access rights 86, and any amount due 100 associated therewith, for one or more parking lots in cluster, as well as one or more access documents 80 with which access identifiers 82 are inscribed. Any amount paid 304 for amount due 100 and the payment receiving means, i.e. CRM 32 or CCR 102, used to pay amount paid 304 is also stored as part of payment information 308 in access rights record 84. Access rights record 84 also stores access document type information 302, which details the various types of access documents 80, such as credit cards, RFID tags, or bar code documents, associated with access identifiers 82 for access rights record 84. When credit card is used to effect payment, credit card number and expiry date are also stored as part of payment information 308. These data elements 82, 86, 100, 302, 304, 308 are, typically, the minimum stored in RDB 46 in a given access rights record 84, such as in the case of a visitor, e.g. a customer who is not a subscriber, who obtains a bar code document as access document 80 in parking lot and pays amount due using CRM 32.
In addition, each access rights record 84 may contain personal information 306 such as the customer's address, telephone number, language preference, or the like. Further, access rights record 84 may also contain access document distribution information 300 indicating whether an access document 80 is to be distributed to a customer, as described previously, in parking lot or at another location and whether such access document 80 has, in fact, been distributed. In addition, payment information 308 may also contain, notably for subscribers: information relating to frequency of billing for access rights 86, i.e. frequency of calculation of amount due 100, whether amount due can be automatically paid by billing a given credit card number inscribed as part of payment information 308 with expiry date, history of payments, or the like. Reservations 322 of spaces in parking lots are also stored in access rights record 86 as part of access rights 86. RDB 46 also contains tariff information 126 for every parking lot in cluster, which is used by RDB 46 for calculating amount due, as well as invalid card list 132 of invalid credit card numbers.
Similar to RDB 46, LDB 44 also contains access rights record 84′, with each access rights record 84′ having at least one access identifier 82, such as credit card number or another alpha numeric string for RFID or a bar code, associated therewith and which serves to identify access rights record in LDB 44. LDB 44 generally also contains the data elements 82, 86, 100, 300, 302, 304 for access rights record 84′, as well as reservations 322 and access document distribution information 300 where applicable. The method by which payment is effected, using either cash with CRM 32 or CCR 102, is also stored on LDB 44 as payment information 308, including credit card number and expiry date when credit card is used to pay with CCR 102. LDB 44 only stores these data elements 82, 86, 100, 300, 302, 304, 308, 322 for the parking lot where LCD 20 to which LDB 44 is connected is situated. Accordingly, when changes are effected on RDB 46 to an access rights record 84, such as a creation or modification thereof and/or reservation 322 of a parking space, these changes are periodically transferred from RDB 46 to LDB 44 to effect changes in access rights record 84′ on LDB 44, thus synchronizing LDB 44 and RDB 46 with regard to data elements 82, 86, 100, 300, 302, 304, 308, 322. For example, reservations 322, as part of access rights 86, are regularly transferred, in association with access identifiers 82, from RDB 46 to LDB 44. LDB 44 also contains tariff information 126 for parking lot for calculating amount due 100, notably when this information is not provided by RDB 46 or is out of date. For example, when customer uses parking lot by obtaining a bar code document as access document 80 and has not previously had access rights 86 and access rights record 84′ created from CD 38, 40, 42 and entered in LDB 44, then access rights record 84′, including amount due 100 and any amount paid 304, will typically be initially entered by LCD 20 in LDB 44 and then subsequently transferred to RDB 46 for recording as a corresponding access rights record 84 therein. Further, even when access rights record 84′ in LDB 44 is transferred from access rights record 84 in RDB 86, such as in the case of a reservation 322, access rights 86 associated therewith, amount due 100, and amount paid 304 may have to be recalculated if use of parking lot by customer exceeds access rights 86 initially recorded in RDB 46. Once again, these modifications will be effected in LDB 44 to access rights record 84′ and then transferred to RDB 46 for storage in corresponding access rights record 84 therein. Typically, such updates from LDB 44 to RDB 46 occur on a periodic basis, say once per week, after which any information in access rights record 84′ on LDB 44 not required for ongoing use by LCD 20 and RDB 44, such as expired reservations 322, access document distribution information 300 for access documents 300 that have been distributed, and amounts paid 304, may be deleted from LDB 44. Entry and exit information stored in association with an access identifier 82 may also be deleted from LDB 44 once transferred to RDB 46. Like RDB 46, LDB 44 contains invalid card list 132, which is periodically updated from RDB 46.
LDB 44, for the embodiment shown is implemented using a scaled down version of MS-SQL server, MS-SQL (SMDE). However, as in the case of RDB 46, LDB 44 can be implemented in any database management system that can be queried and accessed form computing devices 38, 40, 42 over Internet network 52.
As RDB 46 archives information from LDB 44, by querying RDB 46 from ACD 38 or CLCD 42, an attendant or cluster administrator may therefore obtain information on all entries and exits from each parking lot administrated using RDB 46. Information on all amounts paid 304 as well as the payment receiving means used will similarly be accessible. As well, LCD 20 will also transfer information tracking each attendant access to LCD 20 and/or LDB 44 from ACD 36 to RDB 44, which also records each access to RDB 46 for security purposes.
Although the present invention has been described with a certain degree of particularity, it is to be understood that the disclosure has been made by way of example only and that the present invention is not limited to the features of the embodiments described and illustrated herein, but includes all variations and modifications within the scope and spirit of the invention as hereinafter claimed.
