Patent Description:
The aforementioned problem is solved by the features of the independent claims.

Among other things, one or more systems and/or techniques for estimating parking occupancy are provided herein. In an example of estimating parking occupancy such as for paid periods during the day, a zone encompassing a parking meter may be defined. Parking meter transaction data, for the parking meter, are acquired (e.g., a parking meter identifier, a timestamp of a time with which the parking meter was paid, a paid parking duration for which parking was paid, etc.). The parking meter transaction data are evaluated to determine status data for one or more parking spaces managed by the parking meter. For example, the status data may be calculated, from the parking meter transaction data, as an estimation as to whether one or more parking spaces may be available or occupied and/or an estimated availability time at which one or more occupied parking spaces are estimated to become available. A parking occupancy (e.g., a low occupancy indicating a high likelihood that parking spaces are available, a medium occupancy indicating a moderate likelihood that parking spaces are available, or a high occupancy indicating a low likelihood that parking spaces are available) may be estimated based upon the status data. The parking occupancy may be displayed through a user interface.

In an example of estimating parking occupancy such as for free periods during the night, vehicle flow data (e.g., a location of a vehicle, a speed of the vehicle, a heading of the vehicle, and/or other information such as global positioning system (GPS) data provided by the vehicle), associated with one or more vehicles, are acquired. The vehicle flow data are evaluated to determine a start trip count of vehicles that started trips from the zone. The zone may be defined to encompass a parking meter and/or one or more parking spaces. The zone may overlap with other zones. The zone may be defined accordingly any shape and/or size (e.g., about a <NUM> to about a <NUM> meter zone or any other size around the parking meter). The vehicle flow data may be evaluated to determine an end trip count of vehicles that ended trips in the zone. A net number of vehicles within the zone at a point of time may be determined based upon a difference between the end trip count and the start trip count. The net number of vehicles may be integrated over time to determine a net number of vehicles observed to be remaining in the zone (e.g., parking) compared to leaving the zone. The parking occupancy for the zone may be determined based upon the net number of vehicles observed to be remaining in the zone compared to leaving the zone. In an example, both vehicle flow data and parking meter transaction data may be used to determine the parking occupancy for the zone. For example, the parking meter transaction data may be matched to the vehicle flow data, such as the net number of vehicles observed to be remaining in the zone compared to leaving the zone (e.g., the integration of the net number of vehicles), during a transition between a paid-period and a free period (e.g., <NUM>:00pm) to obtain a scale factor and offset. The scale factor and offset may be used to correctly scale and/or offset the net number of vehicles observed to be remaining in the zone compared to leaving the zone for the free-period.

To the accomplishment of the foregoing and related ends, the following description and annexed drawings set forth certain illustrative aspects and implementations. These are indicative of but a few of the various ways in which one or more aspects may be employed. Other aspects, advantages, and novel features of the disclosure will become apparent from the following detailed description when considered in conjunction with the annexed drawings.

The claimed subject matter is now described with reference to the drawings, wherein like reference numerals are generally used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth to provide an understanding of the claimed subject matter. It may be evident, however, that the claimed subject matter may be practiced without these specific details. In other instances, structures and devices are illustrated in block diagram form in order to facilitate describing the claimed subject matter.

One or more systems and/or techniques for estimating parking occupancy are provided herein. Parking meter transaction data, indicative of when and for how long drivers pay for parking at one or more parking spaces, and/or vehicle flow data, indicative of vehicles remaining/parking within the one or more parking spaces, are evaluated to determine parking occupancy for the one or more parking spaces. The parking occupancy may be displayed through a user interface, such as a smart phone app, a website, a vehicle head-end or navigation unit, a wearable device, or any other device, so that a driver may quickly identify a likelihood that an available parking space is available or not at a location such as street-side parking. In this way, the user may reduce time, fuel consumption, and/or pollution otherwise wasted in searching for an available parking space.

An embodiment of estimating parking occupancy is illustrated by an exemplary method <NUM> of <FIG>. At <NUM>, the method <NUM> starts. At <NUM>, a zone is defined to encompass a parking meter that may service one or more parking spaces. It may be appreciated that the zone may be defined as any shape or size (e.g., about a <NUM> to about a <NUM> meter zone or any other size around the parking meter, which may or may not overlap with other zones defined for other parking meters). At <NUM>, parking meter transaction data for the parking meter are acquired. The parking meter transaction data may comprise a parking meter identifier, a timestamp associated with when the parking meter was paid, and a paid parking duration for which parking was paid. In an example, the parking meter transaction data are received in real-time, such as around a time when or in response to receiving a driver request for parking occupancy information for a location near the parking meter.

At <NUM>, the parking meter transaction data are evaluated to determine status data for the one or more parking spaces. In an example, the status data comprise an estimation as to whether one or more parking spaces are available or occupied, such as based upon the timestamp of when the parking meter was paid and the paid parking duration. In an example, the status data comprise an estimated availability time at which one or more occupied parking spaces are estimated to become available, such as based upon the timestamp of when the parking meter was paid and the paid parking duration (e.g., the parking meter may manage multiple parking spaces, and thus parking meter transactions, specified by the parking meter transaction data, may be tracked over time to estimate how many parking spaces are likely to be occupied).

At <NUM>, a parking occupancy for the zone is estimated based upon the status data (e.g., a likelihood that a parking space is available; an estimated number of available parking spaces; and/or other information indicative of parking availability). In another example of determining the parking occupancy, parking occupancies are estimated for one or more time periods (e.g., every <NUM> minutes or any other time period) based upon total paid parking durations for respective time periods. For example, a total paid parking duration for a first time period (e.g., <NUM> minutes of paid parking out of a <NUM> minute time window) is determined. A first parking occupancy for the first time period may be estimated based upon the total paid parking duration (e.g., a relatively high parking occupancy, indicating a relatively low likelihood of an available parking space, may be determined). At <NUM>, the parking occupancy may be displayed through a user interface. For example, the parking occupancy may be displayed as a textual notification (e.g., a likelihood of available parking spaces) or a visual notification (e.g., a parking space user interface element, representing a parking space within a map, may be color coded based upon the likelihood of available parking spaces). The parking occupancy may be displayed through a mobile device, a wearable device, a vehicle head-end or navigation unit, a website, an app, etc. In an example, the parking meter transaction data may be evaluated to determine a payment rate for the parking meter. The payment rate may be displayed through the user interface.

In an example, a set of parking occupancies may be estimated for one or more zones encompassing portions of a block of parking spaces (e.g., a city block comprising <NUM> parking spaces). A block parking occupancy for the block of parking spaces may be determined based upon the set of parking occupancies. The block parking occupancy may be displayed through the user interface (e.g., a block user interface element, representing the block, may be colored according to a likelihood that parking spaces within the block are available). Responsive to the block parking occupancy corresponding to a high occupancy threshold range (e.g., where little to no parking spaces are estimated to be available), a high occupancy status may be displayed for the block user interface element representing the block through the user interface. Responsive to the block parking occupancy corresponding to a medium occupancy threshold range (e.g., where a few parking spaces are estimated to be available), a medium occupancy status may be displayed for the block user interface element. Responsive to the block parking occupancy corresponding to a low occupancy threshold range (e.g., where numerous parking spaces are estimated to be available), a low occupancy status may be displayed for the block user interface element. Responsive to the block parking occupancy being indicative of a parking obstruction (e.g., construction may have restricted parking for the block), a parking obstruction status may be displayed for the block user interface element. Responsive to the block parking occupancy being indicative of a restriction (e.g., police may have shut off access to parking due to a parade), a restriction status may be displayed for the block user interface element.

In an example, a parking occupancy model may be generated based upon the parking occupancy. For example, the parking occupancy model may be trained based upon parking occupancies associated with various weather conditions, seasons, occurrences of events (e.g., a sporting event), and/or other variables. In this way, future parking occupancies and/or historic parking occupancies, having such conditions/variables, may be predicted for the zone using the parking occupancy model.

In an example, the parking occupancy may be updated based upon vehicle flow data, such as global positioning system (GPS) data provided by a vehicle (e.g., a location of the vehicle, a speed of the vehicle, a heading of the vehicle, etc.). For example, vehicle flow data, associated with one or more vehicles, may be acquired (e.g., through cellular or other communication mediums). The vehicle flow data may be evaluated to determine a start trip count of vehicles that started trips from the zone and an end trip count of vehicles that ended trips in the zone. A net number of vehicles within the zone at a point of time may be determined based upon a difference between the end trip count and the start trip count. The net number of vehicles may be integrated over time to determine a net number of vehicles observed to be remaining in the zone (e.g., parking) compared to leaving the zone. The parking occupancy for the zone may be updated based upon the net number of vehicles observed to be remaining in the zone compared to leaving the zone to create an updated parking occupancy for the zone. In an example, the net number of vehicles observed to be remaining in the zone compared to leaving the zone may be normalized based upon the parking meter transaction data. In an example, the parking meter transaction data may be matched to the net number of vehicles observed to be remaining in the zone compared to leaving the zone), during a transition between a paid-period and a free period (e.g., <NUM>:00pm), to obtain a scale factor and offset. The scale factor and offset may be applied to the net number of vehicles observed to be remaining in the zone compared to leaving the zone.

In an example, the parking occupancy and/or the updated parking occupancy may be adjusted based upon a business type of a business within a threshold distance of the zone. For example, parking spaces near dinner restaurants may have high occupancy at night compared to morning. In another example, parking spaces near a hospital may have varying parking occupancies. In this way, parking occupancy may be estimated and provided to drivers. At <NUM>, the method <NUM> ends.

<FIG> illustrate examples of a system <NUM>, comprising a parking occupancy estimator <NUM>, configured for estimating parking occupancy. <FIG> illustrates the parking occupancy estimator <NUM> defining one or more zones encompassing parking meters near a night club <NUM>, a dinner restaurant (A) <NUM>, and a dinner restaurant (B) <NUM>. For example, the parking occupancy estimator <NUM> may define a first zone <NUM> encompassing a first parking meter <NUM> and one or more parking spaces. The parking occupancy estimator <NUM> may define a second zone <NUM> encompassing a second parking meter <NUM> and one or more parking spaces. The parking occupancy estimator <NUM> may define a third zone <NUM> encompassing a third parking meter <NUM> and one or more parking spaces. The parking occupancy estimator <NUM> may define a fourth zone <NUM> encompassing a fourth parking meter <NUM> and one or more parking spaces. In an example, the one or more zones may be defined as nonoverlapping zones. In another example, the one or more zones may be defined to overlap one another, parking meters, and/or parking spaces.

The parking occupancy estimator <NUM> acquires parking meter transaction data <NUM> for the one or more parking meters. For example, the parking meter transaction data <NUM> may comprise data generated during a paid parking period (e.g., during the day, such as from <NUM>:00am to <NUM>:00am). The parking occupancy estimator <NUM> evaluates the parking meter transaction data <NUM> to determine status data for the parking spaces encompassed by the one or more zones. The status data may indicate a probability that a parking space is available or occupied based upon the parking meter transaction data <NUM> indicating when a parking meter was paid and for how long. Similarly, the status data may indicate an estimated availability time at which an occupied parking space is estimated to become available. The parking occupancy estimator <NUM> may take into account the types of businesses that are within a threshold distance of the one or more zones when determining the status data (e.g., parking spaces may be less likely to be occupied because the night club <NUM> and dinner restaurants are less likely to have patrons during the day). The parking occupancy estimator <NUM> may estimate a parking occupancy <NUM> for the one or more zones based upon the status data. The parking occupancy <NUM> may indicate how likely parking spaces are available within a zone. The parking occupancy estimator <NUM> may estimate a block parking occupancy for a block of parking spaces based upon parking occupancies estimated for the first zone <NUM> and the second zone <NUM> and/or for a second block of parking spaces based upon parking occupancies estimated for the third zone <NUM> and the fourth zone <NUM>.

<FIG> illustrates the parking occupancy estimator <NUM> acquiring vehicle flow data <NUM> associated with one or more vehicles that may be traveling near the one or more zones. The parking occupancy estimator <NUM> may evaluate the vehicle flow data <NUM> to determine start trip counts of vehicles that started trips from the respective zones and/or end trip counts of vehicles that ended trips at the respective zones. The parking occupancy estimator <NUM> may determine net numbers of vehicles within the respective zones at a point of time based upon differences between the end trip counts and the start trip counts for the respective zones. The parking occupancy estimator <NUM> may integrate the net numbers of vehicles over time to determine net numbers of vehicles observed to be remaining in the respective zones compared to leaving the respective zones. The parking occupancy estimator <NUM> may update the parking occupancy <NUM> for the respective zones based upon the net numbers of vehicles observed to be remaining in the respective zones compared to leaving the respective zones to create updated parking occupancies <NUM> for the respective zones.

An embodiment of estimating parking occupancy is illustrated by an exemplary method <NUM> of <FIG>. At <NUM>, the method <NUM> starts. At <NUM>, a zone encompassing a parking meter is defined. The zone encompasses one or more parking spaces managed by the parking meter. At <NUM>, vehicle flow data, associated with one or more vehicles, are acquired. In an example the vehicle flow data are obtained during a free-period where parking at the one or more parking spaces may be free (e.g., parking meter transaction data may be unavailable between <NUM>:00pm and <NUM>:00am because drivers may be allowed to park for free within the one or more parking spaces, and thus the vehicle flow data may be used to determine parking occupancy). At <NUM>, the vehicle flow data are evaluated to determine a start trip count of vehicles that started trips from the zone. At <NUM>, the vehicle flow data are evaluated to determine an end trip count of vehicles that ended trips in the zone. At <NUM>, a net number of vehicles within the zone at a point of time may be determined based upon a difference between the end trip count and the start trip count. At <NUM>, the net number of vehicles may be integrated over time to determine a net number of vehicles observed to be remaining in the zone compared to leaving the zone. At <NUM>, a parking occupancy for the zone may be determined based upon the net number of vehicles observed to be remaining in the zone compared to leaving the zone. In an example, the parking occupancy may be updated based upon parking meter transaction data for the parking meter. At <NUM>, the method <NUM> ends.

<FIG> illustrate examples of a system <NUM>, comprising a parking occupancy estimator <NUM>, configured for estimating parking occupancy. <FIG> illustrates the parking occupancy estimator <NUM> defining a zone <NUM> encompassing a parking meter <NUM> that manage a parking space <NUM> and/or other parking spaces near a hospital <NUM>. The zone <NUM> may be defined as any shape or size. The parking occupancy estimator <NUM> may acquire vehicle flow data <NUM> associated with one or more vehicles, such as from vehicles traveling within a proximity to the zone <NUM>. The vehicle flow data may comprise a location of a vehicle, a speed of the vehicle, a heading of the vehicle, and/or other data that may be derived from global positioning system (GPS) data provided by the vehicle.

The parking occupancy estimator <NUM> may evaluate the vehicle flow data to determine a start trip count of vehicles that started trips from the zone <NUM> (e.g., vehicles that left the parking space <NUM>) and an end trip count of vehicles that ended trips in the zone <NUM> (e.g., vehicles that parked at the parking space <NUM>). The parking occupancy estimator <NUM> may determine a net number of vehicles within the zone <NUM> at a point in time based upon a difference between the end trip count and the start trip count. The parking occupancy estimator <NUM> may integrate the net number of vehicles over time to determine a net number of vehicles observed to be remaining in the zone <NUM> compared to leaving the zone <NUM>. The parking occupancy estimator <NUM> may estimate a parking occupancy <NUM> for the zone <NUM> (e.g., a likelihood that the parking space <NUM> and/or other parking spaces within the zone <NUM> are available) based upon the net number of vehicles observed to be remaining in the zone <NUM> compared to leaving the zone <NUM>. The parking occupancy estimator <NUM> may take into account the types of businesses that are within a threshold distance of the zone <NUM> when determining the parking occupancy <NUM> (e.g., irregular or sporadic parking may occur near the hospital <NUM>).

<FIG> illustrates the parking occupancy estimator <NUM> acquiring parking meter transaction data <NUM> from the parking meter <NUM>. The parking meter transaction data <NUM> may comprise a parking meter identifier of the parking meter <NUM>, a timestamp associated with when the parking meter <NUM> was paid, and a paid parking duration for which parking, such as at the parking space <NUM>, was paid. The parking occupancy estimator <NUM> may evaluate the parking meter transaction data <NUM> to determine status data for the parking space <NUM> and/or other parking spaces within the zone <NUM>. The status data may indicate whether the parking space <NUM> is available or occupied. If the parking space <NUM> is occupied, then the status data may comprise an estimated availability time at which the parking space <NUM> may become available. The parking occupancy estimator <NUM> may update the parking occupancy <NUM> based upon the status data to create updated parking occupancy <NUM> for the zone <NUM>.

<FIG> illustrates an example of a system <NUM>, comprising a parking occupancy estimator <NUM>, for displaying a parking occupancy through a user interface <NUM> associated with a device (e.g., a wearable device, a smart phone, a vehicle head-end, a mobile app, a website, a windshield projection, etc.). The parking occupancy estimator <NUM> may have determined parking occupancies for parking spaces near a mall based upon parking meter transaction data and vehicle flow data.

The parking occupancy estimator <NUM> may display parking space user interface elements corresponding to the parking spaces near the mall. If a parking occupancy for a parking space corresponds to a low occupancy threshold range (e.g., a high likelihood that the parking space will be available for a driver of a vehicle <NUM>), then a low occupancy status may be displayed for the parking space, such as the light dotted fill of a first parking space <NUM>. If a parking occupancy for a parking space corresponds to a medium occupancy threshold range (e.g., a moderate likelihood that the parking space will be available for the driver of the vehicle <NUM>), then a medium occupancy status may be displayed for the parking space, such as the medium dotted fill of a second parking space <NUM>. If a parking occupancy for a parking space corresponds to a high occupancy threshold range (e.g., a low likelihood that the parking space will be available for the driver of the vehicle <NUM>), then a high occupancy status may be displayed for the parking space, such as the dense dotted fill of a third parking space <NUM>. If a parking occupancy for a parking space is indicative of a parking obstruction (e.g., a threshold amount of time where no vehicles are parking within a parking space but other nearby parking spaces have high occupancy), then an obstruction status may be displayed for the parking space, such as the black fill of a fourth parking space <NUM>.

Still another embodiment involves a computer-readable medium comprising processor-executable instructions configured to implement one or more of the techniques presented herein. An example embodiment of a computer-readable medium or a computer-readable device is illustrated in <FIG>, wherein the implementation <NUM> comprises a computer-readable medium <NUM>, such as a CD-R, DVD-R, flash drive, a platter of a hard disk drive, etc., on which is encoded computer-readable data <NUM>. This computer-readable data <NUM>, such as binary data comprising at least one of a zero or a one, in turn comprises a set of computer instructions <NUM> configured to operate according to one or more of the principles set forth herein. In some embodiments, the set of computer instructions <NUM> are configured to perform a method <NUM>, such as at least some of the exemplary method <NUM> of <FIG> and/or at least some of the exemplary method <NUM> of <FIG>, for example. In some embodiments, the set of computer instructions <NUM> are configured to implement a system, such as at least some of the exemplary system <NUM> of <FIG>, at least some of the exemplary system <NUM> of <FIG>, and/or at least some of the exemplary system <NUM> of <FIG>, for example. Many such computer-readable media are devised by those of ordinary skill in the art that are configured to operate in accordance with the techniques presented herein.

Rather, the specific features and acts described above are disclosed as example forms of implementing at least some of the claims.

As used in this application, the terms "component," "module," "system", "interface", and/or the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Of course, many modifications may be made to this configuration without departing from the scope of the claimed subject matter.

<FIG> and the following discussion provide a brief, general description of a suitable computing environment to implement embodiments of one or more of the provisions set forth herein. The operating environment of <FIG> is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the operating environment. Example computing devices include, but are not limited to, personal computers, server computers, handheld or laptop devices, mobile devices (such as mobile phones, Personal Digital Assistants (PDAs), media players, and the like), multiprocessor systems, consumer electronics, mini computers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

Although not required, embodiments are described in the general context of "computer readable instructions" being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media (discussed below). Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions may be combined or distributed as desired in various environments.

<FIG> illustrates an example of a system <NUM> comprising a computing device <NUM> configured to implement one or more embodiments provided herein. In one configuration, computing device <NUM> includes at least one processing unit <NUM> and memory <NUM>. Depending on the exact configuration and type of computing device, memory <NUM> may be volatile (such as RAM, for example), non-volatile (such as ROM, flash memory, etc., for example) or some combination of the two. This configuration is illustrated in <FIG> by dashed line <NUM>.

In other embodiments, device <NUM> may include additional features and/or functionality. For example, device <NUM> may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic storage, optical storage, and the like. Such additional storage is illustrated in <FIG> by storage <NUM>. In one embodiment, computer readable instructions to implement one or more embodiments provided herein may be in storage <NUM>. Storage <NUM> may also store other computer readable instructions to implement an operating system, an application program, and the like. Computer readable instructions may be loaded in memory <NUM> for execution by processing unit <NUM>, for example.

The term "computer readable media" as used herein includes computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions or other data. Memory <NUM> and storage <NUM> are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device <NUM>. Computer storage media does not, however, include propagated signals. Rather, computer storage media excludes propagated signals. Any such computer storage media may be part of device <NUM>.

Device <NUM> may also include communication connection(s) <NUM> that allows device <NUM> to communicate with other devices. Communication connection(s) <NUM> may include, but is not limited to, a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency transmitter/receiver, an infrared port, a USB connection, or other interfaces for connecting computing device <NUM> to other computing devices. Communication connection(s) <NUM> may include a wired connection or a wireless connection. Communication connection(s) <NUM> may transmit and/or receive communication media.

The term "computer readable media" may include communication media. Communication media typically embodies computer readable instructions or other data in a "modulated data signal" such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" may include a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

Device <NUM> may include input device(s) <NUM> such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, and/or any other input device. Output device(s) <NUM> such as one or more displays, speakers, printers, and/or any other output device may also be included in device <NUM>. Input device(s) <NUM> and output device(s) <NUM> may be connected to device <NUM> via a wired connection, wireless connection, or any combination thereof. In one embodiment, an input device or an output device from another computing device may be used as input device(s) <NUM> or output device(s) <NUM> for computing device <NUM>.

Components of computing device <NUM> may be connected by various interconnects, such as a bus. Such interconnects may include a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), firewire (IEEE <NUM>), an optical bus structure, and the like. In another embodiment, components of computing device <NUM> may be interconnected by a network. For example, memory <NUM> may be comprised of multiple physical memory units located in different physical locations interconnected by a network.

Those skilled in the art will realize that storage devices utilized to store computer readable instructions may be distributed across a network. For example, a computing device <NUM> accessible via a network <NUM> may store computer readable instructions to implement one or more embodiments provided herein. Computing device <NUM> may access computing device <NUM> and download a part or all of the computer readable instructions for execution. Alternatively, computing device <NUM> may download pieces of the computer readable instructions, as needed, or some instructions may be executed at computing device <NUM> and some at computing device <NUM>.

Various operations of embodiments are provided herein. In one embodiment, one or more of the operations described may constitute computer readable instructions stored on one or more computer readable media, which if executed by a computing device, will cause the computing device to perform the operations described. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Alternative ordering will be appreciated by one skilled in the art having the benefit of this description. Further, it will be understood that not all operations are necessarily present in each embodiment provided herein. Also, it will be understood that not all operations are necessary in some embodiments.

Further, unless specified otherwise, "first," "second," and/or the like are not intended to imply a temporal aspect, a spatial aspect, an ordering, etc. Rather, such terms are merely used as identifiers, names, etc. for features, elements, items, etc. For example, a first object and a second object generally correspond to object A and object B or two different or two identical objects or the same object.

Claim 1:
A method (<NUM>, <NUM>) for estimating parking occupancy, comprising:
defining a zone encompassing a parking meter;
acquiring parking meter transaction data for the parking meter (<NUM>);
evaluating the parking meter transaction data to determine status data for one or more parking spaces, the status data comprising an estimation as to whether the one or more parking spaces are available or occupied, the status data comprising an estimated availability time at which one or more occupied parking spaces are estimated to become available (<NUM>);
estimating a parking occupancy for the zone based upon the status data (<NUM>);
characterized by
acquiring vehicle flow data associated with one or more vehicles wherein the vehicle flow data are provided by the vehicles (<NUM>);
evaluating the vehicle flow data to determine a start trip count of vehicles that started trips from the zone (<NUM>);
evaluating the vehicle flow data to determine an end trip count of vehicles that ended trips in the zone (<NUM>) ;
determining a net number of vehicles within the zone at a point of time based upon a difference between the end trip count and the start trip count (<NUM>);
integrating the net number of vehicles over time to determine a net number of vehicles observed to be remaining in the zone compared to leaving the zone (<NUM>); and
updating the parking occupancy for the zone based upon the net number of vehicles observed to be remaining in the zone compared to leaving the zone and matching the parking meter transaction data to the net number of vehicles observed to be remaining in the zone compared to leaving the zone to obtain a scale factor and offset and applying the scale factor and offset to the net number of vehicles observed to be remaining in the zone compared to leaving the zone to create an updated parking occupancy for the zone (<NUM>); and
displaying the updated parking occupancy through a user interface.