HK1139230A - Smart meter parking system - Google Patents

Description

Intelligent toll meter parking system

The application is a divisional application with the application number of 200610125788.4, which is filed on 7/13/2006 and is named as an intelligent toll meter parking system.

Technical Field

The intelligent meter parking system of the present invention utilizes a programmable electronic parking meter that accepts input from peripheral devices to reflect arrival and departure events sensed by vehicle detection sensors and works in conjunction with an intelligent communications module having a memory for storing status data relating to the parking system, and also wirelessly transmits signals to other devices in the system as well as to small computer workstations, and is connected to the meter wireless network and to the internet in one or more forms of network.

Background

Vehicle Detection Sensors (VDS) determine vehicle arrival and departure and the on/off status of the inductor coil detectors and pass these status data to the Intelligent Communications Module (ICM) or directly to the Electronic Parking Meter (EPM). The VDS includes a microprocessor that is capable of two-way communication and improves detector status reporting. The VDS is the same as that described in U.S. patent application entitled "electronic parking meter system" having application number 09/866,919, attorney docket to the same assignee as the present application, and incorporated herein by reference.

The ICM queries and receives transaction-related data and audit information from the EPM, and receives messages from the VDS, verifies the information, logs the information, and then passes them to the selected EPM. The ICM may transfer data to other peripheral devices by request from these devices or by internal ICM programming. The ICM may transmit the necessary data and instructions to reprogram either the EPS or VDS.

The ICM is capable of communicating with external devices via a wired connection or with an Intelligent Network Bridge (INB) via a wireless communication system. Such transmission enables the ICM to transfer data between the VDS or EPM and an external device.

The ICM is an electronic device consisting of a microprocessor, a non-volatile memory and a communication port connected to the VDS, the EPM, a device designed to wirelessly transmit signals with other similarly equipped devices through a radio frequency modem or the like, and an external computer terminal. A microprocessor is any processor that can control the flow of data between any and all connected devices. The microprocessor is controlled by code located in a non-volatile memory and the code can be reprogrammed by a computer connected through a wireless network interface or by a directly connected external computer terminal. A preferred type of memory is "flash memory," which does not require a permanent power supply to retain the information stored therein and can be easily reprogrammed with low power requirements.

EPMs store in their own memory a record of events and the current state of operability, store the programming and real-time clock of operability, receive inputs from the ICM or VDS and perform operations based on those inputs. The EPM may be queried to transfer the contents of the memory to the requesting device to allow offloading of transaction data, real-time clock settings, event transactions, and collected audit data for current operating state and taxes. The EPM is the same as that described in U.S. patent application serial No. 09/866,919, but the EPM in the U.S. patent application also has the capability of accepting input from peripheral devices in order to react to arrival and departure events. This reaction adds or enhances the meter functionality currently available.

An INB is essentially a small computer workstation with one or more microprocessors, Random Access Memory (RAM) capable of storing data, and a network connection to the internet through both the meter wireless network, through an RF modem connected to the ICM, and through one or more forms of network. These connections may include a mobile modem connected to a mobile telephone network of any available type (GPRS, GSM, CDMA), a wireless connection based on standard 802.11 protocols, a hard-wired connection through ethernet (100T or gigabit), a hard-wired connection of a fiber optic network, a hard-wired connection to a coaxial cable network and/or a hard-wired connection to a standard telephone system. The INB is powered by any combination of battery, solar, direct connection to AC, and direct connection to DC power.

The basic requirements in terms of microprocessor, RAM and data storage of the INB are sufficient to enable basic disk operations, routing of data flow between any enabled network connections, the INB accessing data storage in the database for up to 500 parking spaces connected to the ICM for up to two weeks, basic data analysis of transactions in the database and submission of basic reports to the querying device. The device also needs to run security software to protect it from internet-based hacking.

The intelligent parking meter system of the present invention utilizes any handheld computing device equipped with a communications port available through serial communications and/or any form of wireless communications that an INB can be equipped with. The full capacity of the device must be able to store up to 200 parking spaces (estimated to require 128MB of total storage space for the handheld device). The choice of actual handheld device ultimately depends on the combination of software/hardware used in the city for conducting and/or servicing the activity. The purpose is to integrate the data streams from the intelligent meter system into the existing enumeration/maintenance system if they are being used. The preferred hardware is defined as a so-called "durable" handheld device built on an Intel Strong Arm for handheld devices with the capabilities described above or other adapted processor running Microsoft Windows Pocket PC2002 or any similar possible operating system.

Additional memory and processing power is necessary for the handheld computer to the extent that it decodes the visual images captured by the equipped camera.

The complete license plate recognition system (LPR) consists of two components: wherein the first unit is a camera collecting visual data and the second unit collects positioning data via a global positioning system. The data collected by these units is then provided to software running on a computer that can compile the collected data for providing license plate numbers and physical location information. This time element can also be used for the observation of the vehicle, since each piece of information is time stamped with the observation time. The location and time, the visual image of the license plate is also stored as proof of decision purpose attached to the license plate number record.

A portable television camera unit, such as a hand-held unit, is controlled by a person riding in a vehicle or patrolling on a road. Units mounted on vehicles patrolling routes may also be used. These units are aligned to the license plate along a line where the digital image of the license plate is collected. The images are collected from the information needed to determine the relative position of the vehicle from the viewing camera unit, which may be distance and direction information. A camera may also be attached to the handheld device to gather the same information.

Global positioning satellite systems (GPS) are currently widely used in various applications to determine current location. They operate on the principle of three or more satellites located in geosynchronous orbit around the earth to determine the relative position of an interrogating device. This information is used to triangulate the exact longitude and latitude of the device. The equipment for such applications requires the correctness of at least one meter.

The client desktop computer needs to have the capability to communicate with any handheld computer on the street that is served to the personnel for implementation and/or maintenance. Desktop computers also need to have the capability to connect to the internet. Such a connection requires not only the transmission of any data collected by the enforcement and/or maintenance personnel, but also the retrieval of reports from the data warehouse. The desktop computer also needs to have sufficient system resources in memory, processor, and data storage for processing the license plate image, GPS data, and relative location data to produce usable observation data for matching the violation data obtained by the data analysis engine located on the computer of the data warehouse.

To the extent that communications from and to devices in the network occur over the internet, a firewall system is required at each end of the communication to reduce the likelihood of security breaches. The firewall system used may be in the form of a hardware-based solution or a strictly software-based solution in case a hardware solution is not feasible. Routers are also needed behind firewalls to interconnect devices sharing a physical network. INBs act as routers for street level network segments.

The network server computer consists of one or more computers equipped with advanced processors, RAM memory, and data storage capacity. These computers are located at remote locations or near personal clients and are accessed for data communications over the internet. One or more of the customer cities, the analysis engine, the web server, the report generator and the map server also serve as a central storage location for the stored data. The server system is scalable in terms of an increase in the amount of data accommodated, the number of visitors and the reporting capacity activated. The data warehouse may operate on any platform that allows SQL relational database execution. The database is paired with a Java analytics engine built by the customer that instructs the database to perform calculations and store results for future report use. The server also hosts a user interface that enables remote and/or local users to interact with the database to generate the reports, perform the entry of new data, and maintain the data needed for the proper calculation of the new data. These user interfaces may be either customized portal interfaces or web-driven interfaces. These servers also have a map service engine that combines data and statistics about geographic locations to produce a map-based interface for system users. These interfaces perform both input and output functions.

The VDS determines the arrival and departure of the vehicle and the operating state of the induction coil. These communications may be communicated to either the ICM or directly to the electronic parking meter. Future plans for detector meters include upgraded microprocessors that are capable of two-way communication and improve detector status reporting. This improvement allows for detector reporting from battery level, actual inductance readings, and other troubleshooting information. The improvement also takes into account the reprogrammed sensing parameters needed when the unit need not be sent back to the factory.

The ICM receives any communications from the detectors and records the information, which is then passed to the EPMs. The ICM acts as a compiler for different types of electronic parking meters, thereby eliminating the need to design multiple detectors. This also enables confirmation of the receipt of information to be performed by the EPMs. The ICM queries and receives data from the electronic parking meters regarding transaction data and audit information. These data are then stored on the ICM until such time as they need to be transferred to other devices. These requests may be initiated by either the external device or by operating parameters predetermined by the ICM. The ICM may also be capable of generating a request for a vehicle detector where two-way communication is enabled. The ICM also performs the transfer of the required data and instructions to reprogram the parking meter or vehicle detector. The ICM communicates with the INB either through a wired connection to an external device or through a wireless communication system. This communication is bidirectional in nature and may be used both to request information from the ICM and to transmit the required instructions and/or data to perform the requested action. The actions also include the transfer of data between the meter and an external device as a detector or electronic parking meter. The electronic parking meter stores in its own storage a record of events and the status of current operability. It also stores running programs and a real time clock, and receives inputs directly from the ICM or vehicle detector and performs actions based on those inputs. These actions include changing the program and/or real time clock of the meter. The meter may also be required to communicate the contents of the memory to the requesting device. This allows for offloading of transaction data, real-time clock settings, event transactions and audit data for current operating conditions and tax collection.

Regardless of the type of information, the network data warehouse server may quickly receive new data. They are also capable of receiving a variety of different data formats and processing the data once it is received.

Data from the meter-ICM-detector is collected or periodically uploaded to the INB by wired connection to an external computer or by wireless technology. In the case of a wired connection, the connected computer is later connected to the internet, and the data is passed through the connection to a networked server as a data repository. When INB is utilized, information is collected wirelessly from the space through the INB and the information is transferred from the INB to the data warehouse through an active internet connection.

Information or maintenance work on changes to system equipment (replacing one equipment with another) is performed and recorded by the individual performing the work. The data is recorded in a handheld device that is thereafter connected to the internet. Once connected to the internet, the device passes the information recorded by the maintenance personnel to the database. The process also applies citation data collected by the enforcement personnel or license plate recognition system.

Each data record contains information about the device to which the information contained in the record pertains. The record also includes a timestamp of when the event occurred. The input engine first groups information by event attached device.

Once this information is grouped, a series of events must be carried out in chronological order. If it is an event, such as the issuance of a citation or maintenance repair, no further processing is required. These items are stored directly for cross-referencing with future relational databases.

Certain event types are paired for generating useful data packets. Examples include arrival/departure and device entry/device troubleshooting. These packets are formed by sequentially examining the records and in each case the initial event forms a pair with the matching event immediately following it. These packets result in spatial state packets.

Once the events are paired to form a spatial state grouping, the data is again examined to match intermediate events to those groupings, especially as it relates to payment events for electronic parking meters. The payment is matched to the appropriate pair of arrival and departure events and recorded.

To generate statistics, the input data is compared with static personal parking space related information. This information includes the following operating parameters:

(1) the number of hours of execution of the parking rules;

(2) number of days of execution of parking rules;

(3) charging a billing rate;

(4) the type of payment accepted and coins accepted;

(5) the type of activation feature (meter reset, free time of arrival, anti-meter supply, and/or progressive rate structure); and

(6) the length of the "prepaid" time (the time period before the start of the hours of fulfillment during which the advance payment is used once the time of fulfillment begins).

Based on these parameters, the events of each group are logged for calculating statistics on system parameters such as occupancy, compliance, revenue, operability, and implementation.

When event records are paired and analyzed, the results and records are recorded in one or more tables, and when applicable, statistics are stored in the tables for each event group. In other cases, certain events (e.g., quotes) are compared to other events or event groupings (e.g., parking space occupancy) to determine additional information that can be logged for generating a later report (e.g., whether to quote a violation).

When a user requests a report from the SOAR system, he or she is provided with an interface to select:

(1) the type of running report;

(2) date/time range of the report;

(3) selection criteria for the space included in the report;

(4) reporting the aspect to be included; and

(5) and selecting a mode for prompting parking space grouping.

The SOAR then reclaims these records when creating the report according to the request criteria.

Once these filtered records are reclaimed, they are first aggregated through the space and then aggregated through groupings of parking spaces according to the needs of the user. The method of aggregating statistics depends on the statistics being processed. The statistical method may be: summing up; averaging; or to establish a maximum or to establish a minimum.

The method of indexing is utilized because the process of collecting, filtering, aggregating, and then providing statistics to the individual space occupiers at each parking space is a very time consuming process. The method stores statistics for each parking space on a daily, weekly and monthly basis. By using a combination of these pre-computed statistics, the process of generating reports is greatly enhanced while maintaining flexibility in the filtering allowed by the system.

The report may be provided as any of the following document types:

(1) portable document format (pdf) developed by Adobe system;

(2) a web page; or

(3) A color coded pattern.

Data analysis uses a combination of static parameters and dynamic data. The data types differ in that static data cannot be dynamically adapted depending on the date or time of day. Although static parameters may be changed, changes typically affect reporting and data analysis.

The spatial information stored on a static basis includes the geographic location based on longitude and latitude, the type of parking space (parallel, angled or vertical), the name used for the description of the parking space and the index number used for data processing purposes.

The information stored for the policy includes the date of operation, the time of operation, the rate structure, the coil evaluation parameters used by the policy, the features activated, the amount of time given free to arrive, and the amount of prepaid time. The information stored for the electronic parking meter includes the manufacturer, meter type and city serial number, new parking lot and manufacturer. Coin parameters include definitions for coins and other accepted payment denominations and the amount of time given for each rate structure. A packet is a definition of the type of packet available to the user and the sub-packets for each packet. For example, it will define groupings of regions and individual regions in the grouping process, and all are user definable.

The correction parameters affect how the correction logic for missing arrival and departure events is handled and applied. When such data gaps are found in the input data, the process uses the statistical mean together with these static data as a threshold for generating estimated arrival and departure times. An example of correction logic and formulas is shown in the following table:

parking meters lose the least square method of departure Sum (p (i) × [ d (i) -c (i) ])/Sum (p (i) ^2),

wherein: p (i) total sum of coins of the current vehicle;

[ D (I) -C (I) ] -the departure time minus the time at which the first coin falls.

Sample transaction table

Code time coin drop P (I) [ D (I) -C (I) ] estimation% error

A 1:00 - - - -

C 1:02 0.25 - - -

C 1:15 0.25 - - -

D 1:30 - 0.5 28 34.19

A 2:00 - - - -

C 2:05 0.1 - - -

D 2:15 - 0.1 10 6.84

Code time coin drop P (I) [ D (I) -C (I) ] estimation% error

A 3:00 - - - -

C 3:05 0.25 - - -

C 3:06 0.25 - - -

C 3:07 0.25 - - -

D 4:00 - 0.75 55 51.29

Numerator denominator

Vehicle 1140.25

Vehicle 210.01

Vehicle 341.250.5625

Total 56.250.8225

Alpha 68.38905775 min/dollar

Drawings

The objects, features and advantages of the present invention will become more apparent from the following description of the preferred embodiments in the best mode for carrying out the invention when taken in connection with the accompanying drawings, wherein:

fig. 1 is a flow chart illustrating a License Plate Recognition (LPR) -based citation process according to the present invention;

FIG. 2 is a block diagram illustrating the Intelligent Communications Module (ICM) operating system of the present invention;

FIG. 3 is a flow chart illustrating a method by which progressive rate payments are assessed by an SOAR analysis engine that is part of a smart meter system;

FIG. 3a illustrates the process of converting a time value to a revenue value over a range of progressive rates;

FIG. 4 is a flow chart of the manner in which data is evaluated by the parking meter system of the present invention;

FIG. 5 is a flow chart illustrating the coin valuation process in the parking meter system of the present invention;

FIG. 6 is a block diagram illustrating wireless recording of handheld data in accordance with the present invention;

FIG. 7 is a block diagram showing a wireless parking meter system of the present invention using a hard-wired connection to the Internet;

FIG. 8 is a block diagram of a complete wireless communication system for parking meter data in accordance with the present invention;

FIG. 9 is a block diagram illustrating a PDA implemented communication system of the present invention;

fig. 10 is a block diagram showing a complete wireless PDA-implemented communication system.

Detailed Description

In the license plate recognition system (LPR) shown in fig. 1, a camera 20, which can be hand-held or mounted on a vehicle associated with a parking meter space identified by an electronic parking meter 24-27, generates video images relating to time parameters of the license plate of the vehicle 21-23 which are communicated to a license plate recognition assembly 28 comprising a computer 29 and a video monitor 30. License plate recognition component 28 compiles the video and time data to provide the license plate number and physical location of the particular vehicle. The time element may also be applied to the observation of the vehicle when each bit of information is time stamped according to the observation time. Data from the electronic parking meters 24-27 relating to the presence and absence of vehicles in the respective parking spaces is transferred to a data storage device 31 used by the meters. The license plate identification data is stored in memory 32 and the data resulting from observing the parking space is collected in a space/time component 33. Data from memory 31 used by the EPM is input into violation component 34, which compares the memory usage data with the space/time data of component 33 by comparator 35 to determine a violation for the parking space, which results in publication of the citation from citation component 36.

The ICM shown in fig. 2 is an electronic device that includes a microprocessor 40, a non-volatile memory chip 41, and a communication port 42 connected to a vehicle detector port 42, an external device port 43, a wireless communication module (RF modem) port 44, and an EPM port 45. Microprocessor 40 is any processor capable of performing data flow control between any and all connected devices, microprocessor 40 being controlled by code residing in a non-volatile memory chip 41. The code can be reprogrammed either by an interface to the wireless network through port 44 or by a computer terminal connected directly to the outside through port 43. The memory storage chip 41 does not require permanent power to retain the information stored therein and is easily reprogrammed with low demand.

Fig. 3 is a flow chart illustrating a method by which progressive rate payments are assessed by an SOAR analysis engine that is part of an intelligent meter system. While the figure is particularly directed to coin payments and uses only three different rate levels, the same or expanded logic may be used for other forms of payments and rate level additional rate levels. The parameters used in the flow chart are defined as follows:

Time_Arrtime of arrival signal;

Time_{Enf Begin}-the start of a predetermined implementation time;

Time_EnfEndend of predetermined enforcement time;

Time_Refa calculation point of a reference progressive rate program;

Time_Currtime of payment date

Time_PcThe time displayed on the electronic parking meter for which the SOAR is used for the calculated representation;

Value_Dropthe denomination or payment of the coin dropped;

Time_ratedetermining a time of a rate interval to be applied to the assessed payment value;

Value_Ratea monetary value for giving extra time on the meter;

Rate₁，Rate₂，Rate₃，Rate₄...Rate_n-predetermined rates for different time intervals; and

Ratebound₁，Ratebound₂，Ratebound₃，...Ratebound_na predetermined time period for a different rate.

In the progressive rate flow chart of fig. 3, comparator 50 determines whether the arrival of the occupant evaluated to pay the amount is after the start of the enforcement time. If so, flow passes to comparator 51 to ensure that the arrival time is also before the end of the enforcement time. If these conditions are met at the same time, the reference point for calculating the cumulative rate is set equal to the time of arrival in process 52. If the comparator 51 or 52 verifies that the result is false, the reference time for price calculation is set by the calculator circuit 53 to be equal to the time at which the implementation started.

The calculation procedure is transferred to Time from the reference point at which the rate interval was set_rateAnd Value_rateProcesses 54 and 54' to set the initial value. In the Time of parking space holder stay, the Time is set_rateSet as the reflection point, the payment will start the time of purchase. . This time is the time of payment plus any time currently displayed by the meter minus the reference time for rate calculation. Value_rateIs set equal to the face value of the payment.

The computing process then enters a logical loop, which is repeatedly executedUntil the full value of the payment has been processed. First pass the verification Time_rateHas been no greater than or equal to Ratebound_nThe time limit of the parking space is defined and the cycle of the comparator and process is started. In FIG. 3, using a three-level rate structure as an example, let Ratebound_nDescribed as Ratebound₃. Likewise, the comparison is shown in comparator 56.

If Time_rateEqual to or exceed Ratebound_nValue if_rateAnd Rate_nMultiplication (step 59), then Value_rateAfter being set to zero, the loop process is exited (step 59').

If Time_rateNot exceeding Ratebound_nThe process will Time_rateAnd Ratebound_n-1，Ratebound_n-2，Ratebound₃And so on until Ratebound₁Compare until one is found that is greater than or equal to one of these rate boundaries (comparators 57 and 56). If Time is found_rateLess than all Rate boundaries, the Rate will be₁For calculating the rate. Also, if the Rate is found first₁Greater than or equal to Ratebound₁Then Rate₂For calculating rates and so on. The process then targets each Rate₁To Rate₂The same comparator and program settings are applied.

First, it is determined when Value is to be held_rateMultiplied by the rate for calculation and then added to the Time_rateWhether the time exceeds the price boundary (for Rate)₁For the comparator 66, for Rate₂For the comparator 63, for Rate₃Is comparator 60).

If the finding result is true, then Time_rateThe difference between and the rate bound is set to Time_rate(n)(for Rate)₁For step 67, for Rate₂For the Rate 64, step₃Step 61). Then, for the rates used for the calculations, the Time is_rate(n)For indicating the amount of money reflected by the time. The Time_rateThe Value is driven from Value_rateMedian subtraction (for Rate)₁For step 67', for Rate₂For step 64', for Rate₃Step 61'). Then will Time_rateRate boundary set equal to current Rate (step 67 "for Rate, for Rate)₂Step 64 ", for the Rate₃Step 61 "), so Value is used when the program loop repeats (loop 55)_rateWill be processed in the next higher tariff.

If the Value is determined to be valid_rateMultiply by rate for calculation and add Time_rateWithout exceeding the Rate boundary for that Rate (for Rate)₁For the comparator 66, for Rate₂For the comparator 63, for Rate₃Comparator 60), Value_rateMultiply the current rate for the calculation to get the Time_rate(n)(for Rate)₁For the Rate 68₂For step 65, for Rate₃Step 62), then Value is added_rateSet equal to "0" to stop the loop step (for Rate)₁For step 68', for Rate₂For step 65', for Rate₃Step 62').

Figure 3a shows how time values are converted to revenue values over a range of progressive rates. The parameters used in the flow chart are as follows:

Time_Caletime value converted to revenue amount;

RateBound_nupper limit value of current rate grade;

RateBound_n-1upper limit value for previous rate level-if the calculation is for the first rate level, the value is set to "0";

Rev_nan income value for the current rate rating;

rev is the cumulative revenue value for all rate ratings.

Process runs from Time_Cale(step 126) and then enters the program loop (at loop start)Between start 127 and end 127') of the cycle), the cycle utilization is based on the slave Rate₁Logic to each of the defined maximum rate levels. Analyzing Time_CaleTo determine if it is greater than the upper limit of the current price minus the upper limit of the previous price. If the calculation applies to the first rate level, the previous upper price limit is defined as "0" (comparator 128).

If Time_CaleIs less than the duration of the current rate interval, which means that all time is applicable to the current rate. Likewise, Time_CaleMultiplied by the current rate (step 129) to calculate the revenue represented by the time value. Due to Time_CaleAll times indicated apply to the current time interval, setting the variable to "0" so that it is not repeatedly calculated when calculating the value of the next rate interval (step 129').

Otherwise, only by Time_CaleThe portion of time indicated applies to the current rate interval. In this case, the duration of the current rate interval is multiplied by the current price to find a revenue value from the current rate interval (step 130). Then when calculating the value of the next rate interval, to ensure that it is not repeatedly calculated, Time_CaleThe duration of the current rate interval is subtracted (step 130').

In either of these cases, the process passes Rev_nThe calculated value of (c) is added to Rev and the process continues (step 131). Likewise, once the rate intervals are calculated as into, for Time_CaleRev represents the total cumulative revenue value. Then Rev will be_nSet to "0" (step 132) so that the step can be repeated for the next rate interval.

FIG. 4 illustrates a process flow for determining how to evaluate a personal transaction if an occupant is defined. This procedure is employed after transactions are grouped and ordered as follows: for a given meter, a slot occupant may be defined as an arrival transaction, an immediately preceding departure, and all payment transactions between them in chronological order. The various parameters used in FIG. 4 are defined as follows:

Time_Remaintime remaining after previous departure meter-it is zero when reset is activated

Time_DepartPrevTime of previous departure

Time_ResetPrevTime reset amount from previous departure

Time_ArrTime of arrival of the current occupant

Time_InhThe amount of time the current occupant inherits. Which reflects the time already on the meter, but is not included in the reset time to "0" upon departure.

Rev_InhBy Time_InhIndicated amount of money

Time_FreeAmount of free time given to current occupant upon arrival

FreeTime_SpaceFree time quantum defined by parking space rule

Paid_LastAmount of time paid at the current transaction time

Time_CurrTime of current transaction

Time_LastTime of last transaction

Viol_UnderpmtTime violation by the current occupant during the stay due to unpaid time

VioNum_UnderpmtNumber of violations due to non-pay time occupier

Time limit for a parking space, defined by the parking space rule TL

Viol_OverLimittime is the time an occupant violates during the time the occupant currently stays because the occupancy space is longer than the allowable time limit

ViolNum_OcerLimitThe number of times an occupant violates a parking space because the occupancy is longer than the allowable time limit

Time_RatenTime associated with current payment and rate rating

Time_ExclCurrTime associated with current payment and rating of rate not authorized by the meter

Time_IllCurrTime associated with current payment and tariff level authorized by the meter but not exceeding the time limit for the parking space

Time_PaidCurrTime associated with current payment and tariff level authorized by the meter for legal payment

Rev_ExclCurr＝Time_ExclCurrValue of

Rev_IllCurr＝Time_IllCurrValue of

Rev_PaidCurr＝Time_PaidCurrValue of

Rate_nRate paid for current interval

Time_RepnTime associated with current payment and rate rating repurchased by previous occupant

Time_RepCumulative time of purchase from previous occupant

Rev_Rep＝Time_RepValue of

Time_PaidAs a legal payment Rev_PaidTime authorized by the meter_PaidValue of

Time_IllAccumulated time authorized by a meter but exceeding a parking space time limit

Rev_Ill＝Time_IllValue of

Time_ExclCumulative time without authorization from a meter

Rev_Excl＝Time_ExclValue of

Time_UnusedTime remaining and authorized for purchase when the occupant leaves

Rev_Unused＝Time_UnusedValue of

Time_ResetTime reset by meter upon departure

Rev_Reset＝Time_ResetValue of

The evaluation process begins with three data elements held by the previous occupant. These data items are the time the occupant left, the time the meter was reset at that time, and the amount of time remaining on the meter after the departure. It must be noted that if the time is reset after leaving, no time will remain on the meter (step 69).

Next, the amount of time that may have been on the meter is determined using the time of arrival of the current occupant in the parking space, the time of the previous departure, and the amount of time that the meter was reset, if any. If the calculation results in a negative amount of time, the value defaults to "0" (step 70). Once the amount of time is defined, its monetary equivalent is determined using the steps shown in FIG. 3a (step 71).

The amount of time given to the occupant as free time is then determined based on the parking space rules (step 72). The amount of time the meter has been displayed is determined after the current occupant arrives (step 73), except to account for the time remaining on the meter after the previous occupant left. When the next occupant is calculated, the data variable storing the remaining amount of time after the previous occupant is cleared in order to avoid repetition of the calculation (step 74).

The process then advances to the next transaction for the current tenant (step 75). At this point, the time between the previous transaction and the current transaction is analyzed to determine whether any violations occurred during this period. The first test is to see if the time elapsed between the previous transaction and the current transaction is greater than the amount of time the meter had been at the end of the last transaction (comparator 76). If so, this indicates that an underpaid violation has occurred (the meter expired at some point during the occupant's stay in the parking space). The amount of time is calculated and recorded (step 77) and the occurrence of violations of this type is recorded (step 77') in order to track the number of meter displays and meter indicia expired.

The time of the current transaction event is then analyzed to determine if it occurred within the predetermined time limit for the parking space (comparator 78). If not, the length of the parking space time deadline is subtracted from the amount of time elapsed due to the arrival of the occupant to determine the length of the out-of-deadline violation procedure (step 79) time deadline, and the counter of the out-of-deadline violation is set to "1" (step 79').

The variable stored amount of time displayed by the meter is then adjusted to represent the amount of time elapsed between the current transaction and the previous transaction (step 80). From this point, the transaction is analyzed in one of two ways. The analysis is determined by the transaction type (step 81). The payment transaction proceeds to a payment analysis (step 82) and a leave transaction for the set of occupant statistics (step 98).

The first step in the payment analysis is to determine the application of payments in different rate intervals defined by progressive rates. The above-described steps (step 82) are implemented using the process outlined in fig. 3. Once the process for defining the payment application in each payment interval is defined, the analysis enters a loop (loop start 83 to loop end 83') that checks each interval separately.

The first step of the loop is to determine if there are any time period recommendations (comparator 84) in the current interval that apply to the payoff portion. If no suggestion is made, the analysis proceeds to a sorting step of the time of payment and monetary value, beginning with step 89.

Otherwise, the analysis continues to determine the characteristics of the time period proposal to pay on the current rate interval. A first check determines whether the amount of time evaluated over the rate interval results in the amount of time displayed by the meter exceeding a predetermined time limit (comparator 86). When the meter does not allow time to be exceeded, the portion of the payment that the meter has excluded must be recorded separately and available temporal adjustments made for the allocation of other classifications. This step is first accomplished by subtracting the time allotted for availability in the classification by the time excluded by the meter (step 87). This amount of time is then added to the time category excluded by the current rate interval (step 87'). The amount of time at the current rate level for the legal purchase time and authorized by the meter is determined to be equal to the remaining time for purchase for the parking space within the time limit (step 88).

It is next determined whether the parking space uses an inverse meter supply routine (step 89). If so, the difference between the time available in the current rate interval allocation and the time of the category legally purchased and authorized is added to the excluded category (step 90). Otherwise the same value is classified as legitimate payment and authorized time (step 91). The different time values for the current rate interval are then converted to monetary values by multiplying them by the current rate (steps 92, 92' and 92 ").

The payment is then analyzed to determine if it accounts for a repurchase of time reset from the previous occupant (step 93) by examining the amount of time that has been purchased before the current payment and the time elapsed since arrival. If time is available for repurchase, the amount of time purchased for the current transaction and authorized by the meter is compared to the time available for repurchase, the lesser of the two being determined as the amount of time actually repurchased at the current rate interval (step 94). This value is then used to increase the total time of the repurchase and its monetary value (step 95).

At this point, the accumulated amount of time and the sorted money for legitimate payment and authorization, illegitimate payment and authorization, and for exclusion are added to those calculated for the current rate interval. (steps 96, 96', and 96 "). The amount displayed by the meter is then summed with the time authorized, legitimate, and illegitimate by the meter (step 97), ending the loop (end loop 83') back to step 75 and the progress of the next transaction.

The set of current occupant statistics occurs when the occupant encounters an away transaction as a final transaction (comparator 81). At the point in time when this transaction occurs, the process begins by sorting the remaining time on the meter as unused time. (step 98). This time is then calculated as a monetary equivalent using the steps outlined in FIG. 3a (step 99). If the reset of the meter is activated (comparator 100), the time not used by the current occupant is added to any available, repurchase time of the previous occupant for the next occupant to be able to repurchase (step 101), and its value is converted to a monetary amount using the steps outlined in FIG. 3a (step 101'). If the reset cannot be activated, the unused time is classified as the remaining time on the meter and the available payment time after the application leaves is provided to the next user (step 102).

The time of the current transaction is then recorded as the time to be used by the next occupant representing the departure time of the previous occupant (step 103). The reset time of the meter is also recorded in the same way for the next occupant (step 104).

The process continues by checking the type of violation that occurred in the current occupant's parking space. If the meter experiences at least one payment but is in violation at some point during the occupant's stay, the under-paid violation is classified as an "due" violation, while for an under-paid violation if no payment is accepted, the meter is shown due during the occupancy (step 105). An out-of-payment violation type is classified as "partial payment" if it is classified as "due," and "paid-off" if no out-of-payment violation occurs, and an out-of-term violation is classified as "never-paid" if the out-of-payment violation is so classified (step 106).

Finally, the cumulative statistics of the occupants are recorded in the database (step 107), and all variables are set to "0" except for the variables needed for the next occupant assessment (step 108). The process then moves to the next set of processes for the tenant transaction event (step 109).

FIG. 5 illustrates in block diagram form a flow chart for providing a handheld collection of parking data. The induction coil vehicle detection system 110 provides data input to an Intelligent Communications Module (ICM)110, which also receives data input from EPMs 112 and includes a microprocessor, a non-volatile memory, and a communications port connected to the induction coil vehicle detection system 110 and the EPM 112. The microprocessor controls the flow of data between the connected devices and is controlled by codes resident in a non-volatile memory, which can be reprogrammed either through an interface connected to a wireless network or through a direct connection to an external computer terminal. The preferred memory type is "flash" because it does not require permanent power to retain the information stored therein and can be easily programmed with low power requirements.

The parking meter system of the present invention utilizes any handheld computing device 113 equipped with available ports for communication via serial communication and/or any form of wireless communication equipped with INB. The device must also be able to store data for up to 200 parking spaces at full capacity (estimated to require 128MB of total storage space for the handheld device). The selection of the actual handheld computer 113 will ultimately depend on the software/hardware combination used in the city for the implementation and/or repair of the activity. The objective is to integrate the data streams they use from the intelligent meter system into the existing citation/maintenance system. The preferred hardware is defined by a so-called "rugged" handset built on an Intel StrongArm or other compatible processor with the above capabilities running the Microsoft Windows Pocket PC2002 or higher operating systems. As shown in FIG. 3, handheld computer 113 communicates with ICM 111 and desktop computer 114.

To the extent that the handheld computer is able to compile video images collected by additional cameras, additional storage capacity and processing power is required.

The client desktop computer 114 requires the ability to communicate with any handheld computer 113 serviced on the street for use by the enforcement and/or maintenance personnel. Desktop computer 114 also requires the ability to connect to a network, such as the internet 115. This connection requires not only the transfer of any data collected by the enforcement and/or maintenance personnel, but also the retrieval of reports from the data warehouse. The desktop computer 114 also requires sufficient system resources in terms of memory, processor, and data storage to process the license plate image, GPS data, and related location data by a data analysis engine resident on the data warehouse computer to generate usable observation data for comparison with violation data.

To the extent that communications from and to devices in the network occur over the internet 115, each end of the communication requires a firewall system 116 to reduce the likelihood of security breaches. The system to be used can be either a hardware-based solution or a strictly software-based solution in case a hardware solution cannot be implemented. Routers are also needed behind firewalls to interconnect devices sharing a physical network. INBs serve as routers for street level network segments.

The server 117 includes a web server 118, a data/analytics engine 119, and a map server 120, and the server 117 is connected to receive data from the router/firewall 116.

The wireless transmission of handheld data shown in fig. 6 is the same as the handheld collection of the parking data system of fig. 5, except that the wireless transmission of the handheld data system of fig. 6 does not include a desktop computer 114 and a handheld computer 113 that communicates wirelessly with the internet 115.

Fig. 7 shows a wireless parking meter system including a hard-wired connection to the internet. The system includes the same coil vehicle detection system 110, ICM 111, EPM112, internet 115, router/firewall 116, and server 117 as shown, for example, in fig. 6 and 7. In the wireless parking meter system shown in fig. 7, ICM 111 communicates with other ICM 121 via wireless communication, and ICM 121 in turn communicates wirelessly with INB 122. As previously described, INB 122 is hardwired to internet 115 and connected to router/firewall 116.

The internet 115 is also hard-wired to an LPR system 123, which consists of three components: the first of them is a portable television camera unit 124 for collecting visual data, and the other unit, i.e., a global satellite positioning terminal 125, collects positioning data by global positioning satellites. The data collected by these units is then provided to software run by desktop computer 114, which can compile the collected information to provide the license plate number and physical location. Since each piece of information is time stamped with the observation time, the time element can be applied to the observation of the vehicle. In addition to the registration of the number, location and time of the license plate, the visual image of the license plate is also stored as proof of decision purpose.

The camcorder unit 124 may be a hand-held unit used when driving a vehicle or patrolling a route for walking. It is also possible to use a combination unit mounted on a vehicle patrolling a route. The units are aligned to the license plate along the lines where the digital image of the license plate is collected. Together with the required information, images are collected from the viewing camera units to determine the relative position of the vehicle. I.e. it may be distance and direction. A camera may also be attached to the handheld device to gather the same information.

Different applications currently use the Global Positioning Satellite (GPS) system to determine the current location. They operate on the principle of three or more satellites located in geosynchronous orbit around the earth to determine the relative position of an interrogating device. This information is used to triangulate the exact longitude and latitude of the device. The equipment for such applications requires an accuracy of within one meter.

Fig. 8 shows the wireless communication of parking meter data integrity, which is the same as the wireless meter system shown and described in fig. 7, except that it utilizes wireless communication, rather than hard-wire communication between INB 122 and internet 115.

FIG. 9 illustrates the use of wireless communication between ICM 111 and other ICMs 121; wireless communication between other ICMs 121 and INB 122; and a block diagram of an embodiment in which PDA-implemented communications are performed via wireless communications between INB 122 and handheld computer 113.

FIG. 10 illustrates the use of wireless communication between ICM 111 and other ICMs 121; wireless communication between INB 122 and other ICMs 121; wireless communication between INB 122 and handheld computer 113; and a block diagram of an embodiment in which wireless communications between the internet 115 and handheld computer 113 are performed to perform fully wireless PDA-implemented communications.

It is therefore contemplated that the present invention is not limited to the particular embodiments described herein, but will be apparent to those skilled in the art from this disclosure, including any and all modifications and variations described herein. It is intended that the scope of the invention be determined by any and all equivalents of the structure of the various terms set forth in the following claims.

Claims (8)

1. A process for calculating progressive payment rates for multiple rate ratings as part of a vehicle parking charging system:

a) determine whether Time is_ARRGreater than Time_EnfBegin(ii) a Wherein Time_ARRIs the Time that an occupant has reached a parking space in a vehicle parking system_EnfBeginIs the start of a predetermined implementation time;

b) if the result of the judgment in the step (a) is YES, then the Time is judged_ArrWhether it is less than Time_EnfEND(ii) a Wherein Time_EnfENDIs a predetermined implementation timeEnd of (1);

c) if the result of the judgment in the step (b) is YES, then judging whether or not Time is present_Ref＝Time_Arr(ii) a Wherein Time_RefA calculation point of a reference progressive rate program;

d) if the result of the judgment in the step (a) is NO, judging whether Time is in_Ref＝Time_EnfBeginWherein Time is_EnfBeginIs the start of a predetermined implementation time;

e) calculating Time if the determination in step (c) or (d) is true_Rate＝Time_Curr+Time_PC-Time_Ref(ii) a Wherein Time_CurrTime of payment date, Time_PCTime displayed on an electronic parking meter that is a representation of SOAR for calculation, and Time_RateIs the time to determine the rate interval to be applied to the assessed payment value;

f) then determine Value_Rate＝Value_Drop(ii) a Wherein Value_RateIs a monetary Value, for giving extra time on a meter_DropIs the denomination or payment amount of the coin dropped;

g) once Value is reached_RateIf it is greater than 0, determine if Time_RateEqual to or greater than RateBound_nWherein RateBound_nIs the highest predetermined time limit for the corresponding rate;

h) if the determination in step (g) is NO, then a determination is made as to whether Time is present_RateEqual to or greater than RateBound_n-1；

i) If the determination in step (h) is NO, then a determination is made as to whether Time is present_RateEqual to or greater than RateBound_n-2；

j) (ii) if the judgment in the step (i) is NO, judging whether Rate is₁ValueRate + TimeRate greater than Rate out₁；

k) If the determination in step (j) is YES, determining the TimeRate₁＝Ratebound₁-Time_Rate；

l) determination of Value_Rate＝Value_Rate-(Rate_n/(RateBound¹-Time_Rate；

m) determiningTime_Rate＝RateBound₁And thus the process of calculating the progressive rate ends, the process returns to step (g).

2. The process for calculating progressive rate contributions according to claim 1, wherein steps (j) to (m) repeat Ratebound₂，Ratebound₃...Ratebound_n。

3. The process for calculating progressive rate contributions according to claim 1, wherein Time is determined if the determination in step (g) is YES_Rate4＝Rate₄XValue_RateAnd Value_RateA process for calculating a progressive rate contribution, and living the process to step (g).

4. A process for converting a time value to a revenue value in the context of a progressive rate in a vehicle parking meter system, comprising:

a) the process starts at Time_Calc, converting the time value into income amount;

b) determining whether Time is_CalcGreater than RateBound_n-RateBound_n-1(ii) a Wherein RateBound_nIs the upper limit value of the current rate rating, RateBound_n-1Is the upper limit value of the previous level;

c) calculating Rev if the judgment in the step (b) is NO_n＝Time_CalcXRate_n(ii) a Wherein Rev_nIs the revenue value for the current Rate level, and Rate_nIs a predetermined rate for a set time interval;

d) setting Time_Calc＝0；

c) Determining Rev ═ Rev + Rev_nWhere Rev is the cumulative revenue value for all rate levels;

f) setting Rev-0 and proceeding to step (a);

g) determining Rev if the result of the determination in step (b) is YES_n＝(RateBound_n-RateBound X Rate_n；-RateBound_n-1) (ii) a And the process proceedsGo to step (e).

5. A process for evaluating personal transactions in the context of selected occupants in a vehicle parking meter system, comprising:

a) use of Time_Remain、Tim_DepartPrevAnd Time_RessPrevArrival transaction of, wherein Time_RemainIs the remaining Time of the meter after the previous departure, Time_DepartPrevIs the Time of the previous departure, and Time_ResetPrevIs the amount of time reset at the previous departure;

b) setting Time_InhGreater than 0 and Time_ResetPrev-(Time_Arr-Time_DepartPrev) Wherein Time is_InhIs the amount of Time inherited by the current occupant of the parking space, Time_ArrIs the time of arrival of the current occupant of the parking space;

c) use of the procedure in claim 40 to derive Time from_InhMiddle calculation of Rev_Inh；

d) Setting Time_Free＝FreeTime_SpaceWherein Time is_FreeIs the amount of free time given to the current occupant at arrival, FreeTime_SpaceIs the amount of free time defined by the parking space rules of the parking system;

e) setting Paid_Last＝Time_FreeAnd (Time)_Remain-Time_Arr)-Time_DepartPrevOf the larger, wherein Paid_LastIs the amount of Time paid for the current transaction Time, Time_RemainIs the remaining time of the meter after the previous departure; and

f) setting Time_Remain＝0.。

6. A process for determining an occupant violation status in a vehicle parking meter system:

a) judge Paid_LastGreater than Time_Curr-Time_LastWherein Paid_LastIs the amount of Time paid for the current transaction Time, Time_CurrIs the Time of the current transaction, and Time_LastIs the time of the previous transaction;

b) if the determination in step (a) is YES, then TL less than Time is calculated_Curr-Time_ArrWhere TL is the Time limit for the parking space, Time_CurrIs the time of the current transaction;

c) setting Viol if the result of the calculation in step (b) is YES_OverLimit＝Time_Curr-Time_Arr-TL, wherein Viol_OverLimitIs the time that the current occupant is in violation during the parking space due to the occupancy exceeding the allowed limit;

d) setting ViolNum_Overlimit1, wherein ViolNum_OverlimitIs the number of violations of the occupancy of the space due to exceeding the allowed time limit;

e) setting Paid_Last＝Paid_Last-(Time_Curr-Time_Last)；

f) Setting Viol if the result of step (a) is NO_UnderPayment＝Time_Curr-Time_Last-Paid_LastWherein Viol_UnderpmtIs the number of violations that the occupant has caused by not paying for the time, an

g) Setting ViolNum_Underpmt＝ViolNum_Underpmt+1 and proceeding to step (b).

7. A process for determining a violation for occupancy of a parking space in a vehicle parking toll system, comprising:

(a) setting Time_Unused＝Paid_LastFor a transaction without payment, wherein Time_UnusedIs the time remaining, Paid, purchased and authorized by the occupant to leave the parking space_LastIs the amount of time purchased at the current transaction time;

(b) use of the procedure in claim 40 to derive Time from_UnusedMiddle calculation of Rev_UnusedWherein Rev_UnusedIs Time_UnusedThe monetary value of;

(c) determining whether a Reset is available;

(d) if Reset is available, set Time_Reset＝Time_Unused+ greater than 0 and (Time)_Inh-(Time_Curr-Time_Arr)-Time_Unused) Wherein Time is_UnusedIs the Time of purchase and authorization left by the occupant upon leaving the parking space, Time_ResetIs the Time that the meter resets when the occupant leaves, Time_ArrIs the Time of arrival of the signal from the parking meter, Time_InhIs the amount of time the current occupant of the parking space inherits;

(e) use of the procedure in claim 40 to derive Time from_ResetMiddle calculation of Rev_ResetWherein Rev_ResetIs Time_ResetMonetary value of, Time_ResetIs the reset time of the meter when the occupant leaves;

(f) setting Time_DepartPrev＝Time_CurrWherein Time is_DeparPrevIs the time of the previous departure;

(g) setting Time_ResetPrev＝Time_ResetWherein Time is_ResetPrevIs the amount reset in time when the occupant of the parking space previously left;

(h) determining and recording a type of infrathan deadline violation;

(i) determining and recording an out-of-term violation type;

(j) recording statistical data for an occupant of the parking space;

(k) except for Time_Remain、Time_DepartPrevAnd Time_ResetPrevAll variables are reset to zero, where Time_DepartPrevIs the Time of the previous departure, Time_ResetPrevIs the amount of time reset at the previous departure;

(l) Move to the next occupant;

(m) if reset was not initiated in step (c), setting Time_Remain＝Time_UnusedWherein Time is_RemainIs the Time remaining on the meter since the previous departure, Time_UnusedIs the remaining time of the time purchased and granted once the occupant of the parking space departs and proceeds to step (f).

8. A process for classifying time and benefits in a vehicle parking system, comprising:

a) using the procedures of claim 37 to derive from Paid_LastFind Time for each rate in the current value paid_RatenWherein Time is_RatenIs the time, Paid, associated with the current payment and the rate level of past payments_LastIs the amount of time paid in the time of the current transaction;

b) determining Time_RatenGreater than TL- (Time)_Curr-Time_Arr)+Paid_LastWherein Time is_CurrIs the Time of the current transaction, Time_ArrIs the arrival time of the current occupant of the parking space;

c) if the judgment in the step (b) is YES, the Time is judged_RatenGreater than TL-Paid_LastWhere TL is a time limit for a parking space specified in a parking policy of the parking charging system;

d) setting Time_ExclCurr＝TL-Paid_LastWherein Time is_ExclCurrIs the time associated with the current payment and rate not allowed by the parking meter;

e) determining Time_ExclCurr＝TL-(Time_Curr-TimeArr)+Paid_Last；

f) If the result in step (b) is NO, the process proceeds to set Time_PaidCurr＝Time_RatenWherein Time is_PaidCurrIs the time of a legitimate payment associated with the current payment and rate rating authorized by the meter;

g) proceeding from the settings in steps (b) and (f) to determining whether anti-meter provisioning is available;

h) setting Time if anti-meter provisioning is available_ExcelCurrr＝Time_ExclCurr+(Time_Raten-Time_PaidCurr)；

i) Determination of Rev_ExclCurr＝Time_ExclCurr Rate_nWherein Rev_ExcelCurrIs Time_ExcclMonetary value of, Time_ExcclIs the current charge and Rate level, Rate, without authorization from the meter_nIs the rate paid for the current interval;

j) determination of Rev_IllCurr＝Time_IllCurr X Rate_nWherein Rev_IllCurrIs Time_IllCurrMonetary value of, Time_IllCurrIs the time associated with the current payment and rate level authorized by the meter, but exceeds the parking space limit;

k) determination of Rev_PaidCurr＝Time_PaidCurr X Rate_nWherein Rev_PaidCurrIs Time_PaidCurrThe monetary value of;

l) determining that Time is greater than (Time)_Curr-Time_Arr)+Paid_LastWherein Time is_InhIs the amount of time inherited by the current occupant of the parking space;

m) if the result of the judgment in the step (I) is YES, determining the Time_RepnIs Time_Inh-(Time_Curr-Time_Arr)-Paid_Last) And (Time)_PaidCurr+Time_IllCurr) The smaller of (1), wherein Time_RepnIs the Time, associated with the current charge and rate level of the previous occupant buys back_IllCurIs the time associated with the current charge and rate rating authorized by the meter, but exceeds the time limit for the parking space;

n) use of Time_RepnIncreasing Time_RepUse (Time)_Repn X Rate_n) Increase Rev_RepnWherein Time is_RepIs the cumulative time of repurchase, Rev, from the previous occupant of the parking space_RepIs Time_PaidMonetary value of, Time_PaidIs the cumulative time authorized by the meter for legitimate payments;

o) use of Time separately_PaidCurrAnd Rev_PaidCurrIncreasing Time_PaidAnd Rev_Paid；

p) use Time separately_IllCurrAnd Rev_IllCurrIncreasing Time_IllAnd Rev_IllWherein Time is_IllIs the accumulated time granted by the parking meter, but exceeds the time limit for the parking space, and Rev_IllIs Time_IllThe monetary value of;

q) use Time separately_ExclCurrAnd Rev_ExclCurrIncreasing Time_ExclAnd Rev_ExclWherein Time is_ExclIs the cumulative time, Rev, without authorization from a meter_ExclIs Time_ExclMonetary value of, Time_ExclCurrIs the cumulative time, Rev, not currently authorized by the parking meter_ExclCurrIs Time_ExclCurrThe monetary value of;

r) set Paid_Last＝Paid_Last+(Time_PaidCurr+Time_IllCurr) And all loop variables are set to 0; and

s) if the judgment result in the step (I) is negative, proceeding to the step (O);

t) if the anti-meter supply is not available, set Time_IllCurr＝Time_Raten-Time_PaidCurrAnd proceeds to step (j).