US20120303533A1 - System and method for securing, distributing and enforcing for-hire vehicle operating parameters - Google Patents

Abstract

Systems and methods of securing, distribution and enforcing for-hire vehicle operating parameters are described whereby a first computer system maintaining the parameters generates a data packet that is distributed to a second computer system which acts as a meter (such as a taximeter, limousine meter or shuttle meter) for the for-hire vehicle. The first computer system may secure or encrypt the data packet according to a security protocol associated with the second computer system. Once the second computer system receives the data packet, it may validate and extract the operating parameters contained within it. The second computer system may then store the operating parameters and operate according to the parameters by, for example, calculating fares for passengers that make use of the for-hire vehicle associated with the second computer system. The second computer system may include a secure segment that is attached to the for-hire vehicle and a non-secure segment that may be easily removed to prevent theft or for repairs.

Description

BACKGROUND
• The present disclosure relates to the field of for-hire vehicles such as taxis, limousine, shuttles, buses or any other vehicle that provides shared transportation or transports one or more passengers between locations of the passengers' choice.
• A for-hire vehicle (FHV) generally charges fares based on several variables. The variables may include the distance traveled, the time spend traveling, the number of passengers hiring the FHV, etc. The cost associated with each of these variables is often set by a regulatory agency that regulates the for-hire vehicles (“FHVs”) within its jurisdiction of control. Typically, the jurisdiction of control corresponds to a city or metro area, however, in some cases it may be a county, several counties, or even an entire state. Regulatory agencies may also issue licenses to operate FHVs within their jurisdiction of control. The licenses may correspond to a timeframe, such as a year, or they may permit the operation of a FHV only within a particular area within the jurisdiction of control. In some jurisdictions, medallions corresponding to the license may be issued. The medallions may be affixed to the FHV and indicate type of license associated with the FHV.
• The calculation of fares for a trip in a FHV is typically done by a meter. A meter is programmed with the variables used to calculate the fare along with the values associated with those variables that the regulatory agency has determined. When a FHV is hired for a trip, the meter is typically started and then when the trip is over the meter is stopped. In most cases the fare amount is displayed in real time via a display that is part of the meter. Currently meters are separate devices that are affixed to a FHV. FHV meters are programmed by the regulatory agency regulating the FHV to which the meter is affixed.
• Unfortunately, the business of operating for-hire vehicles (“FHVs”) is susceptible to fraud. As a result, regulatory agencies seal FHV meters so that no one may tamper with the meter, or the data within the meter, without detection. Once the regulatory agency sets the fare rates for the meter, the entire meter is then locked with a physical seal that prevents, or shows evidence of, tampering. Once the meter is sealed, all components that are part of the meter, such as fare displays and receipt or trip sheet printers are also sealed. The physical sealing process makes updating rates particularly difficult. If the regulatory agency wishes to change rates, an agent of the regulatory agency must break the seal on each meter in the jurisdiction, perform the necessary updates, then reseal the meter. The update process can be very labor intensive as some regulatory agencies may regulate several thousand FHV meters, each of which needs to be manually opened, updated and resealed when updated. The process can also be rather expensive. Some regulatory agencies pass the cost of opening and resealing the meter onto the FHV fleet operator. In addition, the FHV fleet operator also incurs an opportunity cost by having to remove a FHV from the fleet so that its meter can be updated.
• Since updating meters is time consuming and expensive, it tends to be done as little as possible. In some cases this may lead to missed revenue opportunities. For example, in some jurisdictions, if fuel prices increase substantially above the rate base, fleet owners may be allowed to help offset the fuel price increase by requesting that the regulatory agency permit a fuel surcharge. Fuel surcharges, however, are often temporary since they may only apply when fuel prices are unusually high. Thus, implementing a surcharge often requires two modifications to the meter; one modification to include the fuel surcharge when, fuel prices increase, and a second when fuel prices return to the existing rate base. Thus, since the regulatory agencies generally bear the direct cost of updating the meters, they may resist implementation of fuel surcharges because the cost of implementing the surcharge (updating the meters) is charged against the agency's budget. Further, this cost may eventually be passed on to the consumer through higher regulatory agency fees. In addition, regulatory agencies may also wish to increase fares temporarily as a result of a special event in order to take advantage of period when FHV use may be high. Since a change in fares due to a special event is limited in duration, special event surcharges suffer the same problems as fuel surcharges; the cost of updating the fare information in the meter is often higher than the extra revenue that could be generated by incorporating the surcharge.
• In addition, since the entire meter is sealed by the regulatory agency, repairs to the meter require an agent to reseal the meter before it is returned to service. Often times, the portion in need of repair is not related to the aspects of the meter that are regulated, such as calculation of fares. For example, if the display screen of the meter needs to be repaired or replaced, the meter must be resealed by the regulatory agency before the meter is returned to service even though the display screen may not be the portion of the meter which is subject to fraud. Since the meter must be resealed for every repair, meters are unnecessarily expensive to repair and may out of service longer than needed.
SUMMARY
• The present disclosure focuses on systems and methods for updating the parameters of a for-hire vehicle meter without requiring physically breaking the regulatory seal of the meter and then resealing the entire meter. The present disclosure describes embodiments that would allow for repair of the non-regulated portions of the FHV meter (such as a screen display) without requiring the regulatory agency to physically reseal the meter. In addition, the present disclosure describes embodiments that may allow the non-secure portions of the FHV meters to be moved from one FHV to another without requiring the intervention of a regulatory agency.
• One embodiment of the disclosure describes a for-hire vehicle meter comprising a secured, tamper-evident portion. By separating the portions of the meter under regulatory control from the portions of the meter not under regulatory control, repairs to the meter may not require resealing of the entire meter. The secured, tamper-evident portion may comprise a tamper-evident, tangible, computer-readable medium storing software instructions for receiving updated FHV operating parameters, such as fare information. The received operating parameters may be sealed by the regulatory agency using a security protocol, such as encryption. The FHV meter comprises data for decrypting the operating parameters. Once decrypted, the FHV meter may store the operating parameters and operate according to the updated parameters. The tamper-evident portion of the meter may also comprise a tampering indicator. The tamper indicator may indicate a first state when someone has tampered with the meter, such as when someone has attempted to load non-regulatory, unapproved operating parameters onto the meter. The tamper indicator may also indicate a second state when no one has tampered with the meter.
• The present disclosure also describes a method for updating the operating parameters of a for-hire vehicle (“FHV”) meter or computer system, whereby a computer system for defining FHV operating parameters generates a data packet that is distributed to one or more FHV meters. The computer system may allow for the definition, maintenance, and modification of FHV parameters. The computer system may also maintain data associated with the one or more FHV meters, including data uniquely identifying the meters. The computer system may also have access to a security protocol of the FHV meters that is used by the FHV meters to decrypt data. When the operator of the computer system wishes to update the operating parameters of the FHV meters, it may generate a data packet containing the new parameters. The computer system may then secure the data packet according to the security protocol of the FHV meter. Once the data packet has been generated and secured, it may then be distributed to the FHV meter for which it is intended.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a block diagram showing one embodiment of a parameter maintenance computer system in communication with more than one for-hire vehicle meter.
• FIG. 2 is a block diagram showing one embodiment of a for-hire vehicle meter.
• FIG. 3 is a block diagram showing one embodiment of a parameter maintenance computer system.
• FIG. 4 is a flowchart showing the temporal flow of data for generating a secure data packet of for-hire vehicle parameters in one embodiment of a parameter maintenance computer system.
• FIG. 5 is a flowchart showing the temporal flow of data for processing a secure data packet in one embodiment of a for-hire vehicle meter.
DETAILED DESCRIPTION OF EMBODIMENTS
• Embodiments of the disclosure will now be described with reference to the accompanying figures, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of certain specific embodiments of the disclosure. Furthermore, embodiments of the disclosure may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the embodiments of the disclosure herein described.
• FIG. 1 is a block diagram showing one embodiment of parametermaintenance computer system120 in communication with more than one for-hire vehicle (“FHV”)meter100,101,102. Parametermaintenance computer system120 may be a computer system responsible for the maintenance of FHV parameters. In general, FHV parameters are values defining the operation of for-hire vehicles. A set of FHV parameters may be stored in FHV meters associated with a FHV, such asFHV meter100,101 and102. In general, FHV parameters are configurable and may change over time. Regulatory bodies may set regulations dictating the terms by which for-hire vehicles (“FHVs”) may operate, and FHV parameters may be stored inFHV meter100 reflecting those terms. The regulatory bodies may change the regulations, in some cases temporarily, compared to when the FHV meter was installed on its associated FHV. Accordingly, the FHV parameters require updating from time to time.
• For-hire vehicle (FHV) parameters may include, for example, values defining fees based on time and distance traveled. In one embodiment, the FHV parameters may include a distance increment type value indicating the type of distance increment for which fares should be calculated such as, for example, meters, kilometers, or miles. FHV parameters related to defining fees based on time and distance traveled may also include a distance increment indicating the increment of the distance type to calculate fares. For example, the increment may be 0.5 of a mile, or 100 meters, or alternatively, 0.1 kilometers. The parameters may also include a fee value per distance increment, such as, for example $0.50. Several parameters may be combined to define the fees based on time and distance traveled for a particular trip taken by a FHV. For example, the distance increment type may be miles, the distance increment may be 0.125 of a mile, and the fee per distance traveled may be $0.25. Thus, if a passenger used a FHV vehicle for 0.5 miles, they maybe charged a $1.00 fare.
• FHV parameters defining fees based on time and distance traveled may also include time related parameters. In one embodiment, the FHV parameter may include a time increment type, such as second or minute, that defines the type of time used to calculate time based fares. The FHV parameters may also include a time increment such as 1 second or 0.5 minutes. In one embodiment, a fee per time value may also be among the FHV parameters. For example, a fee per time value (such as $26) may be associated with a particular time increment type (such as hours) and time increment (such as 1 hour), resulting in a fee per time value of $26 per 1 hour. In one embodiment, time based parameters may be used in lieu of distance based parameters. This may occur for example in a FHV that operates based on a fixed tariff such as a limousine. In other embodiments, time based parameters may be used in conjunction with distance based parameters. In other embodiments, time based parameters may only be used during times when a FHV is hired but not moving, and distance based parameters may be used when the vehicle is moving. The FHV parameters may include, in such embodiments, a value indicating how time and distance parameters are to be used in relationship to each other. For example, in one embodiment the time-distance relationship parameter may be “distance only” or it may be “time at idle.” In other embodiments, numeric values may be used instead of string values.
• In some embodiments, regulations affecting for-hire vehicles (“FHVs”) may set special fares based on a geospatial point. The special fare may affect the time and distance-traveled parameters, or it may be an additional flat fare added to the regular time and distance-traveled parameters. For example, in one embodiment, there may be a special rate based on a geospatial point corresponding to the airport. The fee may be, for example, $2.00. Thus, in such embodiments, $2.00 may be added to a fare when a passenger using the FHV is picked up at the airport. In other embodiments, the geospatial point may affect the time and distance-traveled parameters. For example, if a passenger is picked up at the airport, they may be charged a fare of $0.32 per half kilometer as opposed to $0.30 per half kilometer.
• In some embodiments, the FHV parameters define variable operating cost surcharges. In some embodiments, variable operating cost surcharges may be applied by a regulatory agency to help offset an unexpected cost to the FHV operator. For example, a fuel surcharge may be added to fares in order to offset unexpected rise in fuel prices. The FHV parameters may define the surcharge as a flat surcharge (one charge per fare) or as an additional per-distance surcharge (for example, and extra $0.05 per mile). In one embodiment the FHV parameters relating to variable operating cost surcharges may indicate a surcharge type. The surcharge type may in some embodiments be a string, such as “flat” or “per-distance.”
• The FHV parameters may also include a parameter indicating a surcharge for fare initiation or fare termination. A fare initiation fee may be a one time fee that is charged at the start of a fare, or trip. If, for example, the fare initiation fee is $2.35, a passenger might be charged at least $2.35 for the trip. As the trip progresses, the passenger may be charged additional time and distance-traveled fees according to other FHV parameters stored on the FHV meter.
• In some embodiments, for-hire vehicle (“FHV”) parameters may be grouped together. In such embodiments, group-FHV parameters may apply to a collection of FHV parameters to indicate that they are to apply only when the conditions of the group-FHV parameters are met. For example, in some embodiments, it may be desirable to limit the application of FHV parameters to a specific period of time. In such embodiments, there may be additional group-FHV parameter indicating the start time and/or end time for the set of FHV parameters. For example, special rates may apply to weekends, holidays or special events. Accordingly, the FHV parameters may be include a start date and end date that correspond to the weekend, holiday or special event. In other embodiments, it may be desirable to define FHV parameters for mutually exclusive geospatial regions within the FHV's operating region. For example, suppose a FHV serves a north region and south region. The north region may be larger and less developed than the south region. As a result, when a FHV makes a trip from the airport into the north region, there is low likelihood that the FHV will be able to pick up another passenger in the north region to bring back to the airport. Accordingly, fare rates for the north region may be higher than for the south region where the FHV is more likely to pick up another passenger quickly. In this example, FHV parameters for the north region may be different from FHV parameters from the south region. The north region's FHV parameters may be grouped by one group-FHV parameter defining a first geospatial polygon (the north region) and the south region's FHV parameters may be grouped by a different group-FHV parameter defining a second geospatial polygon (the south region).
• Returning toFIG. 1, parametermaintenance computer system120 may be responsible for maintaining the FHV parameters and packaging the FHV parameters in a manner that FHVmeters100,101, and102 can interpret. While certain examples of FHV parameters are provided herein, one skilled in the art can appreciate that other FHV parameters may be defined, maintained and configured by parameter maintenance computer system for deployment onFHV meters100,101, and102, and such parameters should not be deemed limited by the examples provided herein.
• In one embodiment, parametermaintenance computer system120 may be a computer system operated by an entity responsible for the regulation of for-hire vehicles. For example, parametermaintenance computer system120 may be operated by New York City Taxi and Limousine Commission or the Nevada Taxi Cab Authority. In another embodiment, parametermaintenance computer system120 may be operated by a company that operates a fleet of for-hire vehicles (“FHVs”). The company may operate in a jurisdiction that allows the update of for-hire vehicles by fleet companies as opposed to a regulatory agency.
• In one embodiment, the FHV parameters may be distributed overdistribution network130.Distribution network130 may be, in some embodiments, a computer network. Depending on the embodiment,distribution network130 may comprise one or more of any type of network, such as one or more local area networks, wide area networks, personal area networks, telephone network, and/or the Internet, which may be accessed via any available wired and/or wireless communication protocols. Thus,distribution network130 may comprise a secure LAN through whichFHV meter100 and parametermaintenance computer system120 may communicate, anddistribution network130 may further comprise an Internet connection through whichFHV meter100 and parametermaintenance computer system120 communicate. Any other combination of networks, including secured and unsecured network communication links, are contemplated for use in the systems described herein.
• In another embodiment,distribution network130 may utilize manpower and non-transitory tangible computer readable media to distribute FHV parameters fromparameter maintenance system120 toFHV meter100. For example,parameter maintenance system120 may write the FHV parameters to a portable non-transitory computer medium such as a floppy disk, USB flash drive, memory card, portable hard drive, etc. A person may then distribute the FHV parameters to FHVmeters100,101 and102 by physically connecting the computer readable medium to each FHV meter in the network. Once connected,FHV meter100 may then read the FHV parameters from the computer readable medium and configure itself accordingly.
• In one embodiment, security breach messages may be sent fromFHV meters100,101 and102 to parametermaintenance computer system120. In such embodiments,FHV meters100,101 and102 may comprise a wireless transmitter anddistribution network130 may be a wireless network as described above. WhenFHV meters100,101 and102 detect a security breach, they may generate a security breach message and transmit it viadistribution network130 to parametermaintenance computer system120. In some embodiments, parametermaintenance computer system120 may send a “kill” message to a FHV meter from whichparameter computer system120 has received a security breach message, providing an extra layer of security. In other embodiments, parameter maintenance computer system may issue a warning, such as graphical display, email alert, electronic alert, etc, upon receipt of a security breach message. Conditions triggering a security breach message are described in more detail with respect toFIG. 2.
• FIG. 2 is a block diagram showing one embodiment ofFHV meter100. In one embodiment,FHV meter100 may be a dedicated computing device that attaches to, or on, a FHV and has external interfaces for communicating with other computer systems attached to, on, or in the FHV. In other embodiments, FHV meter may be a separate computing module that is part of the existing computer system of the FHV. In such embodiments, the FHV meter may be not be visible from within the interior of the FHV meter, and the FHV meter may make use of existing input/output devices of the FHV for displaying information, such as fare information, to the driver and passenger of the FHV.
• In one embodiment,FHV meter100 is configured to interface with multiple devices and/or data sources, such as in the exemplary network ofFIG. 1.FHV meter100 may be used to implement certain systems and methods described herein. For example, in one embodiment,FHV meter100 may be configured to calculate fares for passengers that hire for-hire vehicles (“FHVs”).FHV meter100 may also be configured to receive and decrypt FHV operating parameters and operate according to those parameters. The functionality provided for in the components and modules ofFHV meter100 may be combined into fewer components and modules or further separated into additional components and modules.
• In one embodiment,FHV meter100 comprises secure tamper evident segment (“secure segment”)205.Secure segment205 represents the components and modules ofFHV meter100 that must be secure from tampering, or show evidence of tampering, in order to abide by the regulations and laws governing for-hire vehicles (“FHVs”). In some embodiments,secure segment205 may be self destructing, that is, if someone tampers withsecure segment205, the components and modules ofsecure segment205 will no longer operate. For example, the storage medium storing software instructions for the modules of secure segment may break, or split, if there is an attempt to remove the storage medium fromFHV meter100. In other embodiments, if someone tampers withsecure segment205,FHV meter100 might send a signal to parametermaintenance computer system120 containing a security breach message. In one embodiment, the degree of tampering detected may advantageously signal different levels of response. For example, if the tampering is physical or certain (for example a secure component is removed or replaced),FHV meter100 might automatically shut down. If the tampering is only likely but not certain (for example a signal security check is invalid) then a security breach message indicating a warning signal might be triggered so that the regulatory agency or fleet owner can inspect the meter.
• In some embodiments,secure segment205 may be fixed to the FHV. In such embodiments, the portions ofFHV meter100 that are not in secure segment205 (“unsecure portion”) may be removed from the FHV for necessary repairs. In some embodiments, the unsecure portion may be housed in one casing allowing for easy removal from the FHV for repair or updates. This may allow, for example, the driver to remove the unsecured portion from the for-hire vehicle when it is not in operation in order to prevent theft. The driver may then reconnect the unsecure portion on his next shift without requiring the oversight of a regulatory agency. In other embodiments, the individual components of the unsecure portion may be removed. In some embodiments, the unsecure portion may be the same for every FHV meter in the exemplary network configuration ofFIG. 1. Such a configuration may allow for easy repair of the components of the unsecure portion without requiring a regulatory agency to reseal the entire meter. In addition, this embodiment may also permit drivers to pick up any of a group of unsecured portions as they start their shift thus rendering the need to pre-assign the unsecured portion of the meter to a particular driver or vehicle.
• In some embodiments,secure segment205 and the unsecure portion may be connected via a custom interface such asinterface255. The interface may comprise, in some embodiments, a unique shape or design such that only an unsecure portion and asecure segment255 of the same make or model may be connected. For example, the unsecure portion may comprise an interface in the shape a male “T” shape and the secure segment may comprise aninterface255 of a female “T” shape.
• In one embodiment, a visual indicator of tampering may be adhered to the components ofsecure segment205 so that if someone tampers withsecure segment205, the indicator will be broken. The visual indicator may indicate one state when no one has tampered withsecure segment205, and another state when someone has tampered with it. For example, self destructing tape may be used to wrap the physical portions ofsecure segment205 so that if they are changed or replaced the tape breaks. The tape may indicate a first state (un-torn) when no tampering withsecure segment205 has occurred. The tape may indicate a second state, (torn) when tampering has occurred. In another embodiment,secure segment205 may be implemented via a software module. The module may monitor reads and writes to and from the modifiable data stores ofsecure segment205 such as operatingparameters data store270. When an unauthorized read or write occurs to operatingparameters data store270, the module may notify another module in FHV meter, or in other embodiments, may trigger a visual indicator that can be visually inspected. For example, if FHV meter is implemented as a dedicated computer system attached to a FHV, FHV meter may have a light that is green when no unauthorized reads or writes has occurred. Upon detection of a unauthorized write, the monitoring module may command the light to change to red, indicating that the secure segment has been compromised.
• In general, the word module, as used herein, refers to logic embodied in hardware or firmware, or to a collection of software instructions stored on a non-transitory, tangible computer-readable medium, possibly having entry and exit points, written in a programming language, such as, for example, C, C++, C#, or Java. A software module may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves, and/or may be invoked in response to detected events or interrupts. Software modules may be stored in any type of computer-readable medium, such as a memory device (e.g., random access, flash memory, and the like), an optical medium (e.g., a CD, DVD, BluRay, and the like), firmware (e.g., an EPROM), or any other storage medium. The software modules may be configured for execution by one or more CPUs in order to causeFHV meter100 to perform particular operations.
• It will be further appreciated that hardware modules may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. The modules described herein are preferably implemented as software modules, but may be represented in hardware or firmware. Generally, the modules described herein refer to logical modules that may be combined with other modules or divided into sub-modules despite their physical organization or storage.
• In one embodiment,FHV meter100, includes a dedicated computer that is IBM, Macintosh or Linux/Unix compatible. In another embodiment,FHV meter100 may be a customized computing device configured only to operate as a meter in a for-hire vehicle. In another embodiment,FHV meter100 may be a module that is part of the internal computing system of the for-hire vehicle.FHV meter100 may, in some embodiments, include one or more central processing units (“CPU”)210, which may include one or more conventional or proprietary microprocessors.FHV meter100 may further includememory215, such as random access memory (“RAM”) for temporary storage of information and read only memory (“ROM”) for permanent storage of information, andgeneral data store220, such as a hard drive, diskette, or optical media storage device. In certain embodiments,general data store220 stores data needed for the basic functioning of FHV meter. In other embodiments,general data store220 might store historical trip information. Embodiments ofgeneral data store220 may store data in databases, flat files, spreadsheets, or any other data structure known in the art. Typically, the modules ofFHV meter100 are in communication with one another via a standards based bus system. In different embodiments, the standards based bus system could be Peripheral Component Interconnect (PCI), Microchannel, SCSI, Industrial Standard Architecture (ISA) and Extended ISA (EISA) architectures, for example. In another embodiment,FHV meter100 leverages computing and storage services available over the Internet (cloud computing).
• In one embodiment,general data store220 contains a data structure, or data element, that uniquely identifies the FHV meter. In some embodiments, the data element may be an integer that represents the serial number of the FHV meter. In other embodiments, the data element may be a string or a character array that is unique to the FHV meter. For example, the data element might be 12345678 or “09GTR67RXY.” In other embodiments, the unique identifier may be an object or a data structure with several elements that when combined represent a unique identifier for the FHV meter. For example, the make and model of the FHV meter, combined with the license plate number and registration state of the FHV may be used in combination to uniquely represent the FHV meter.
• FHV meter100 is generally controlled and coordinated by operating system software, such as the Windows 95, 98, NT, 2000, XP, Vista, Linux, SunOS, Solaris, PalmOS, Blackberry OS, or other compatible operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X. In another embodiment,FHV meter100 may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, and I/O services, and may provide a user interface, such as a graphical user interface (“GUI”) for display, among other things.
• FHV meter100 may include, in some embodiments,device calculation device230 for calculating the distance traveled by the FHV. Device calculation device may be a separate computer system fromFHV meter100, or as in the embodiment depicted inFIG. 2, a module ofFHV meter100. For example,distance calculation device230 may be part of the internal computer system of the for-hire vehicle thatFHV meter100 is connected, or it may be a dedicated computer that is connected to FHV meter via input/output (“I/O”) devices and interfaces240.Device calculation device230 may receive input pulses representing the number of turns of the FHV's wheels. The input pulses, in some embodiments, may be received from I/O devices and interfaces240. The input pulses may be generated by a dedicated device for counting wheel turns, or in some embodiments, the input pulses may be generated by FHV's internal computer system.Distance calculation device230 may send calculated distance values toCPU210 which may then in turn be used to calculate fares based on operating parameters.
• FHV meter100 may include one or more commonly available I/O devices and interfaces240, such as for example, a printer, buttons, a keyboard, a LED display, a monitor, a touchpad, a USB port, a RS 232 port and the like. In one embodiment, I/O devices and interfaces240 include one or more display devices, such as a monitor, that allows the visual presentation of data, such as fare and operation data, to a user. In the embodiment ofFIG. 2, I/O devices and interfaces240 provide a communication interface to various external devices. For example, in thisembodiment FHV meter100 is in communication with a distribution network, such as any combination of one or more LANs, WANs, or the Internet, for example, via a wired, wireless, or combination of wired and wireless, connections via a network interface of I/O devices and interfaces240. The communications interface may also include, for example, ports for sending and receiving data such as a USB port or an RS 232 port. In some embodiments, FHV meter may communicate with one or more external devices such as the FHV internal computer system, a printer, a GPS device, etc. by sending and receiving data on ports such as a USB port or a RS 232 port.
• In one embodiment, the FHV meter may havegeospatial recognition module250.Geospatial recognition module250 may include a GPS receiver for receiving GPS coordinates from GPS satellites. In some embodiments, the GPS coordinates received fromgeospatial recognition module250 may used to calculate fares based on FHV parameters stored in operatingparameters data store270.
• Secure segment205 ofFHV meter100 may, in some embodiments, include aprivate key260.Private key260 may be, in some embodiments, software instructions and/or data used to decrypt data. In one embodiment,private key260 is hard-coded on firmware such as programmable read-only memory (“PROM”) and may be unique to the embodiment ofFHV meter100. In other embodiments,private key260 may not be unique and may be the same in one or more embodiments ofFHV meter100. The PROM storingprivate key260 may be self destructing if tampered with, that is, if the PROM is removed from the FHV, it will snap and self destruct. For example, epoxy may be placed overprivate key260 such that it could not be removed fromsecure segment205 without chipping or damagingprivate key260.
• In one embodiment,secure segment205 of FHV meter may also includecipher engine module270.Cipher engine module270 may, in some embodiments, contain software instructions used to decipher coded or encrypted data packets containing FHV parameters.Cipher engine module270 may useprivate key260 to decrypt data packets received fromdistribution network130.Cipher engine module270 may also include software instructions for extracting FHV parameters and storing them in operatingparameters data store280. In some embodiments,cipher engine module270 may be hard coded to firmware such as PROM. The PROM storingcipher engine module270 may be self destructing if tampered with, that is, if the PROM is removed from the FHV, it will snap and self destruct. For example, epoxy may be placed overcipher engine module270 such that it could not be removed fromsecure segment205 without chipping or damaging it.
• FHV meter100 may also include operatingparameters data store280. Operatingparameters data store280 may, in some embodiments, store the operating parameters by whichFHV meter100 operates. For example,CPU210 may access operatingparameters data store280 when calculating time-distance charges or determining surcharges. Operatingparameters data store280 may be, in some embodiments, a secure data store. In one embodiment, operatingparameter data store280 may only be accessed for writing bycipher engine module270. Thus, whileCPU210 may access operatingparameters data store280 for reading FHV operating parameters,CPU210 would not be able to perform write operations to operatingparameters data store280. Accordingly, FHV parameters cannot be changed by software instructions stored ingeneral data store220 or some other data store connected toFHV meter100. This may, in some embodiments, be accomplished by only wiring the write pins of operatingparameters data store280 to the firmware containing the software instructions forcipher engine module270. For example, operatingparameters data store280 may be a RAM chip whereby onlycipher engine module270 is connected to the write pins of the RAM. In some embodiments, operatingparameter data store280 may self destruct if someone tampers with the configuration. In other embodiments, operatingparameter data store280 may be physically connected to FHV with a tamper evident seal that indicates one state if someone tampers with operatingparameter data store280 and another state if no one has tampered with operatingparameter data store280.
• FHV meter100 may includesecure memory285 andsecure CPU290.Secure memory285 may be a non-transitory, tangible, computer readable medium such as random access memory (“RAM”) for temporary storage of information and read only memory (“ROM”) for permanent storage of information.Secure memory285 may store software instructions that cause secure290 to perform the methods of the embodiments described herein.FHV meter100 may also include, in some embodiments,transmitter295.Transmitter295 may be a wireless transmitter that sends messages over a network, such asdistribution network130. In one embodiment,transmitter295 may only send signals and not receive signals from outside computer systems. In some embodiments,transmitter295 may send signals generated bysecure CPU290 such as security breach messages, or in other embodiments, it may send data to parametermaintenance computer system120 that parametermaintenance computer system120 may process to detect tampering withFHV meter100. In other embodiments,transmitter295 may be able to receive certain security signals, such as a “kill” message sent by parametermaintenance computer system120.
• In one embodiment, the FHV meter may implement security measures to ensure thatsecure segment205 remains in communication with the unsecure portions ofFHV meter100. The security measures may prevent instances of fraud where a person may attempt to replace eithersecure segment205 or the unsecure portions ofFHV meter100 with a device intended to calculate fraudulent fares. In some embodiments, when the implemented security measure fails,CPU210 orsecure CPU290 may initiate a shutdown sequence that causesFHV meter100 to cease operating. In other embodiments, when the implemented security measure fails,CPU210 may send a security breach message via I/O devices240 that may be transmitted back to parametermaintenance computer system120. In some embodiments, the transmission may be a wireless communication. In some embodiments, the security breach message may be transmitted fromsecure segment205 bysecure CPU290 viatransmitter295. In other embodiments, the security breach message may be displayed on the monitor ofFHV meter100.
• In one embodiment, the security measure may be implemented via a software handshake betweensecure CPU290 andCPU210. If the software handshake fails, thenCPU210 will shutdown causingFHV meter100 to cease operation, or in other embodiments may transmit a security breach message toparameter computer system120. The handshake starts withCPU210 generating a key, or hash, that is stored inmemory215 and known to secureCPU290.CPU210 may then send the hash over to secureCPU290.Secure CPU290 may then increment, or otherwise modify the hash, according to an algorithm known both toCPU210 and to secureCPU290.Secure CPU290 may store the incremented hash insecure memory285 before sending it toCPU210. Upon receipt of the incremented data,CPU210 may then access the previously sent hash, increment it according to the algorithm, and compare the result to the data received fromsecure CPU290. If the incremented data matches the result, the handshake continues wherebyCPU210 increments the data received from secure290, stores it inmemory215, and then sends it to secureCPU290. The process will repeat until eitherCPU210 orsecure CPU290 receives a hash it was not expecting.
• One example of the software handshake may be as follows: BothCPU210 andsecure CPU290 are programmed with a handshake algorithm that increases the received hash value by 1.CPU210 starts the handshake by generating “5”, storing “5” inmemory215 and then sending “5” to secureCPU290.Secure CPU290 receives “5” and determines if that is the known starting point for the handshake. Oncesecure CPU290 determines that known starting point is correct, it generates “6” (5+1), stores “6” insecure memory285 and then sends “6” toCPU210. WhenCPU210 receives “6”, it pulls the last sent hash out ofmemory215, specifically, “5.”CPU210 then applies the handshake algorithm to arrive at an expected value of “6.” Since the expected value of “6” matches the received value of “6”,CPU210 repeats the process by generating a “7”, storing a “7” inmemory215 and then sending “7” to secureCPU290.Secure CPU290 receives “7” and pulls the last sent hash (“6”) out ofsecure memory285, applies the algorithm (to arrive at “7”) and then compares the expected value (“7”) with the received value (“7”). If the code matches, the process repeats. If it anytimeCPU210 orsecure CPU290 do not receive the expected value, a shutdown sequence may commence renderingFHV meter100 inoperable.
• In one embodiment, instead of a software handshake, a double polling verification security measure may be employed. In this embodiment,CPU210 may constantly pollsecure CPU290 for a first specific response. IfCPU210 ever receives a value it does not expect, it will cease operations ofFHV meter100. At the same time,secure CPU290 may pollCPU210 for a second specific response. Ifsecure CPU290 does not receive the expected response, it may also contain code that initiates a shut down sequence ofFHV meter100.
• In another embodiment, an odometer check may be done as a security measure. In such embodiments,secure CPU290 may receive data fromdistance calculation device230 andsecure memory285 may store software instructions that estimates the odometer reading of the FHV to whichFHV Meter100 is attached. Also,CPU210 may be programmed to periodically check the odometer of the vehicle to which the FI-IV meter is attached. In other embodiments,CPU210 may be programmed to access odometer information from a third party computer system that maintains odometers readings of vehicles, such as Department of Motor Vehicles computer systems or CARFAX® computer systems.CPU210 may then send the odometer value to secureCPU290.Secure CPU290 may then store the odometer reading insecure memory285. In some embodiments,secure CPU290 may then compare the odometer value received fromCPU210 with an estimated odometer value calculated from the previous odometer received fromCPU210. If the estimated odometer value varies substantially (for example, the difference is greater than 10% or 15%) from the odometer value received fromCPU210,secure CPU290 may then initiate a shutdown sequence, or in other embodiments, send a security breach message to parametermaintenance computer system120 viatransmitter295.
• In some embodiments, data may be sent to parametermaintenance computer system120 and it may use the data to determine if there has been tampering withsecure segment205. Parametermaintenance computer system120 may be configured to receive data from a wireless transmitter connected toCPU210 on the unsecure portion of the FHV meter and fromtransmitter295 connected to secureCPU290. Parametermaintenance computer system120 may then compare the data received to data it was expecting to determine if FHV meter was subject to tampering. For example, parametermaintenance computer system120 may receive a first predetermined numeric value or code fromCPU210 via I/O devices240 and a second predetermined numeric value or code fromsecure CPU290. Parametermaintenance computer system120 may then compare the received values to a matched pair of expected values to determine ifsecure segment205 is attached to the proper unsecure portion. For example, parametermaintenance computer system120 may store the assignment of the unsecure portion to securesegment205 based on theserial number CPU210 and the serial number ofsecure CPU290 as a pair of values. The pair of values indicates the assignment of unsecure portion to securesegment205. On a periodic basis,CPU210 may send to parameter maintenance computer system120 a data message containing the serial number of the CPU via I/O devices240.Secure CPU290 may also send a message to parametermaintenance computer system120 viatransmitter295 containing the serial number ofsecure CPU290. Parametermaintenance computer system120 may then compare the received values to the expected pair of values for the meter. If values do not match, parametermaintenance computer system120, in one embodiment, may generate a “kill” message disabling the for-hire vehicle meter. In another embodiment, parametermaintenance computer system120 may issue a warning message if the values do not match.
• FIG. 3 is a block diagram of one embodiment of parametermaintenance computer system120. In one embodiment, parametermaintenance computer system120 is configured to interface with multiple devices, such as shown in the exemplary network ofFIG. 1. Parametermaintenance computer system120 may be used to implement certain systems and methods described herein. The functionality provided for in the components and modules of parametermaintenance computer system120 may be combined into fewer components and modules, or further separated into additional components and modules.
• In one embodiment, parametermaintenance computer system120 includes, for example, a server or a personal computer that is IBM, Macintosh, or Linux/Unix compatible. In another embodiment, parametermaintenance computer system120 comprises a laptop computer, smart phone, personal digital assistant, or other computing device, for example. In one embodiment, the exemplary parametermaintenance computer system120 includes one or more central processing units (“CPU”)310, which may include one or more conventional or proprietary microprocessors. Parametermaintenance computer system120 further includes amemory315, such as random access memory (“RAM”) for temporary storage of information and a read only memory (“ROM”) for permanent storage of information, and adata store320, such as a hard drive, diskette, or optical media storage device. In certain embodiments,data store320 stores FHV meter data and one or more sets of FHV operating parameter data. Embodiments ofdata store320 may store data in databases, flat files, spreadsheets, or any other data structure known in the art. Typically, the modules of parametermaintenance computer system120 are in communication with one another via a standards based bus system. In different embodiments, the standards based bus system could be Peripheral Component Interconnect (PCI), Microchannel, SCSI, Industrial Standard Architecture (ISA) and Extended ISA (EISA) architectures, for example. In another embodiment, parametermaintenance computer system120 leverages computing and storage services available over the Internet (cloud computing).
• Parametermaintenance computer system120 is generally controlled and coordinated by operating system and/or server software, such as the Windows 95, 98, NT, 2000, XP, Vista, Linux, SunOS, Solaris, PalmOS, Blackberry OS, or other compatible operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X. In another embodiment, parametermaintenance computer system120 may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, and I/O services, and provide a user interface, such as a graphical user interface (“GUI”), among other things.
• The exemplary parametermaintenance computer system120 may include one or more commonly available input/output (I/O) interfaces anddevices330, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O devices and interfaces330 include one or more display devices, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. In the embodiment ofFIG. 3, the I/O devices and interfaces330 provide a communication interface to various external devices. For example, in this embodiment parametermaintenance computer system120 is in communication withdistribution network130, such as any combination of one or more LANs, WANs, or the Internet, for example, via a wired, wireless, or combination of wired and wireless, connections via a network interface of the I/O devices and interfaces330.
• In the embodiment ofFIG. 3, parametermaintenance computer system120 also includes several application modules that may be executed byCPU310. The software code of the modules may be stored on a non-transitory computer-readable medium such as for example, RAM or ROM. More particularly, the application modules includeFHV configuration module340 and datapacket generation module350. In some embodiments, parametermaintenance computer system120 may be operated by a regulatory agency, or in some embodiments, by a FHV fleet operator under the supervision of a regulatory agency. Parametermaintenance computer system120 may, in some embodiments, be secured via a username and password. In other embodiments, parametermaintenance computer system120 may be located in physically secure location such that only authorized personnel may access parametermaintenance computer system120.
• In one embodiment,FHV configuration module340 may comprise software code executable byCPU310 that handles the configuration of for-hire vehicles. In some embodiments, configuration of for-hire vehicles (“FHVs”) is done through the creation and modification of FHV operating parameters. In some embodiments, the FHV operating parameters may be defined as indicated above. In some embodiments, FHV operating parameters may be defined and modified through the use of a user interface generated byFHV configuration module340.FHV configuration module340 may generate a user interface and present it to a user ofparameter maintenance system120 so that the user may assign values to various FHV parameters. Once a user defines the parameters, they may be stored todata store320 or they may be sent to datapacket generation module350.
• In one embodiment, datapacket generation module350 may comprise software code executable byCPU310 that handles the generation of data packets that may be deployed viadistribution network130 to FHV meters such asFHV meter100. The generation of the data packet may be in a format the FHV meter can interpret. For example, the data packet may be an XML file, text file, serialized object, COM object, byte stream, or any other data format known in the art. The datapacket generation module350 may generate a data packet unique to the target FHV meter. In other embodiments, datapacket generation module350 may generate a data packet that may be used by several different FHV meters.
• FIG. 4 shows the temporal flow of data for generating secure data packets for FHV parameters in one embodiment of parametermaintenance computer system120. First, inbox410, parametermaintenance computer system120 receives FHV operating parameters. In general, the FHV operating parameters may be defined by a regulatory agency that controls and regulates for-hire vehicles (“FHVs”). The operating parameters may be received by parametermaintenance computer system120 through the use of a user interface generated byFHV configuration module340. In some embodiments, once parametermaintenance computer system120 receives the FHV parameters, it may store them indata store320.
• Next, inbox420 parametermaintenance computer system120 generates data packets for distribution or deployment toFHV meter100. The data packets generated by parametermaintenance computer system120 may contain the FHV operating parameters received inbox410. In one embodiment, several FHV parameters are included in a data packet. A data packet may be, in some embodiments, the group of FHV operating parameters that are to be distributed to a particular FHV meter. In one embodiment, parametermaintenance computer system120 may generate a different data packet for each FHV meter indistribution network130. In other embodiments, it may generate a data packet for more than one FHV meter in the distribution network. In such embodiments, the FHV meters ofdistribution network130 may share the same private key for decryption purposes.
• In one embodiment, each generated data packet contains a header. The header may contain metadata used by FHV meters indistribution network130 containing a unique identifier corresponding to the FHV meter that should read the data packet. For example, if parametermaintenance computer system120 generates a data packet for FHV meter123456578, the data packet might contain metadata indicating that the data packet is for FHV meter12345678. The metadata of the header may be configured to match the unique identifier scheme of the FHV meters indistribution network130.
• In some embodiments, the data packet may be generated by parametermaintenance computer system120 as an XML file. The root node of the XML file may correspond to metadata. For example, the root node may contain the unique identifier of the FHV meter for which the data packet was generated. The first child nodes of the root node (“second level nodes”) may correspond to one or more group-FHV operating parameters. The second level nodes may, for example, define the validity duration of a group of FHV operating parameters, or in other embodiments, geospatial validity of a group of FHV operating parameters. The child nodes of the second level nodes (“third level nodes”) may contain FHV operating parameters such as time and distance-traveled parameters, geospatial point parameters, variable operating cost surcharge parameters, fare initiation parameters or fare termination parameters. In other embodiments, the data packet may be generated as a text file, serialized object, data stream, or any other data format known in the art suitable for transferring data between computer systems. In some embodiments, the data packet may not be hierarchal, but instead defined in a flat structure with a series of name-value pairs indicating the various FHV parameters and their associated values.
• Inbox430, parametermaintenance computer system120 seals and secures the data packets generated inbox420. In one embodiment, parametermaintenance computer system120 seals and secures the data packets using an asymmetrical encryption means such as public-private key encryption. In such embodiments, parametermaintenance computer system120 may encrypt the data packet based on a public key associated withFHV meter100. In some embodiments, the public key ofFHV meter100 may be unique to the FHV meter. For example, FHV meter with serial number 123 may have a different public key than FHV meter with serial number 987. In other embodiments, the public key for more than one FHV meter may be the same. For example, all of the FHV meters of a particular manufacturer, or for a particular for-hire vehicle fleet operator, may share the same public key. Parametermaintenance computer system120 may seal and secure the data packets by using a standard encryption algorithm such as for example, Data Encryption Standard (DES), Advanced Encryption Standard (ADS), Pretty Good Privacy (PGP), International Data Encryption Algorithm (IDEA), Blowfish, RCS, CAST, etc. One skilled in the art can appreciate that any encryption algorithm may be used to seal and secure the data packets generated by parametermaintenance computer system120.
• Moving tobox440, once the data packet has been sealed and secured, it may be distributed to FHV meters indistribution network130. The distribution of packets may vary depending on the embodiment. For example, in one embodiment data packets may be transferred to a portable non-transient computer readable medium such as CD-ROM, diskette, or USB flash drive. In such an embodiment, an individual under a regulatory agency's authority supervision and control may manually load the sealed and secure data packets to each FHV meter. In some embodiments, one medium may be generated for each FHV meter. This may occur in embodiments where the FHV meter is dedicated computer system. For example, in some embodiments, a data packet may be loaded onto a plurality of USB flash drives, each of the USB flash drives corresponding to one of the FHV meters indistribution network130. An agent of the regulatory agency may insert the USB flash drive into the USB port of the FHV meter intended to be loaded with the data packet stored on the USB flash drive. In such embodiments, the USB flash drive may act as a USB Dongle, that is, the FHV meter may only operate when the USB flash drive is inserted into the FHV meter. The agent may then seal the USB Dongle to the FHV meter using a visual indicator of tampering such as color coded self destructible tape, special plastic tie, special metal tie, or seal. The visual indicator may then act as evidence of tampering; if the visual indicator is broken, it will serve as an indication that the USB Dongle may have been tampered with.
• In other embodiments, distribution of sealed and secure data packets may occur over a wireless network. In such embodiments, each FHV meter indistribution network130 may have a wireless receiver capable of receiving a wireless network signal. Parametermaintenance computer system120 may broadcast, on a periodic basis, data packets for various FHV meters. In some embodiments, the FHV meters may listen for all data packets broadcast by parametermaintenance computer system120. Using the header information of the data packet, the FHV meter may then determine if the data packet should be used to update its parameters by comparing the unique identifier information of the data packet to the unique identifier information stored ingeneral data store220.
• In other embodiments, FHV meters may run server software, such as a telnet server, socket server, or any other means of communicating over a TCP port that allows for communications with parametermaintenance computer system120. In such embodiments, the FHV meters ofdistribution network130 may be assigned a dedicated IP address. Parametermaintenance computer system120 may store, indata store320, the IP address, the unique identifier, and in some embodiments the public key, associated withFHV meter100. The stored data may then be used to distribute the data packet to a specific FHV meter such asFHV meter100. For example, parametermaintenance computer system120 may generate a data packet and include in the header the unique identifier ofFHV meter100. After the data packet is generated, parametermaintenance computer system120 may seal the data packet according to the public key. Then, parametermaintenance computer system120 may use the IP address of the FHV meter to start a session with the FHV meter and open a port for communication. Parametermaintenance computer system120 may then transfer the data packet directly to its intended target FHV meter.
• In other embodiments,FHV meter100 may pull data packets from parametermaintenance computer system120 as opposed to parametermaintenance computer system120 pushing data packets toFHV meter100. For example,FHV meter100 may, via a wireless connection, poll parametermaintenance computer system120 on a periodic basis to determine if any data packets have been generated since the last request. The request may include, for example, the unique identifier of the FHV meter. Parametermaintenance computer system120 may respond to the request by sending a data packet corresponding to the unique identifier of the FHV meter. In some embodiments, parametermaintenance computer system120 may respond with a null message, or a message indicating no data packets were generated since the last request. In some embodiments,FHV meter100 may make an update request daily, every other day, or weekly. In some embodiments, the FHV meters withindistribution network130 may be configured to make update requests at different points during an update period so that network traffic is minimized. For example,FHV meter100 may make an update request daily at 9 AM,FHV meter101 may make an update request daily at 10 AM, andFHV meter102 may make an update request at daily11 AM.
• The distribution methods of sealed and secured data packets described herein with reference tobox440 are meant as examples and should not be interpreted as the sole means for distributing data packets withindistribution network130. It can be appreciated that the distribution of data between the systems ofdistribution network130 may vary according to the needs and limitations of the particular embodiment and the distribution methods described herein may be tailored to satisfy the needs, and work within the limitations, of any particular distribution network.
• FIG. 5 is a flowchart showing the temporal flow of data for processing a secure data packet in one embodiment ofFHV meter100. Starting inbox510,FHV meter100 receives a data packet containing FHV operating parameters. As described above, there are numerous means for receiving the data packet, including but not limited to, receipt from a computer medium directly connected to the FHV meter and receipt of the data packet via a wireless receiver. Once the data packet has been received, FHV meter must process the data packet.
• Processing begins, in one embodiment, by validating the data packet inbox520. Validation of data packets may start, in one embodiment, by examining the metadata header of the data packet for a value representing the unique identifier of the data packet's target FHV meter. If the data packet contains a unique identifier not matching the unique identifier ofFHV meter100, processing stops and the data packet may be discarded, or deleted, frommemory215. If the data packet contains a unique identifier matching the unique identifier ofFHV meter100,FHV meter100 may continue to validate the packet by decrypting it. In other embodiments, the data packet does not contain a metadata header, or the metadata header may not include a unique identifier. In such embodiments, the validation process may begin byFHV meter100 attempting to decrypt the data packet. For example,cipher engine module280 may attempt to decrypt the data packet usingprivate key260. Once decrypted,FHV meter100 may attempt extract operating parameters from the data packet. IfFHV meter100 cannot extract usable operating parameters from the data packet, then the data packet fails validation. In such embodiments, the data packet may then be discarded, or deleted from RAM. In some embodiments, if the data packet fails validation,FHV meter100 may shut down or send a message to parametermaintenance computer system120 that it received a data packet that failed validation.
• Once the packet has been validated,FHV meter100 extracts operating parameters from the data packet inbox530 if it has not already done so during the validation step. The extraction of operating parameters depends on the embodiment. For example, if the data packet was generated as an XML file,FHV meter100 may analyze the XML file to determine the FHV operating parameters. In other embodiments, if the data packet is a serialized object,FHV meter100 may desterilized the object, and then extract the FHV parameters using the object's interface. In other embodiments, the data packet may be implement as a byte stream, in which case,FHV meter100 may parse the byte stream in order to determine the operating parameters.
• Inbox540, once the operating parameters have been extracted, they may be stored in operatingparameters data store270. Inbox550, the stored operating parameters may be accessed by CPU in order to calculate fares. The fares may be calculated based on stored time and distance-traveled parameters, geospatial point parameters, variable operating cost surcharge parameters, fare initiation parameters or fare termination parameters. The stored parameters may be used in conjunction with other modules ofFHV meter100 to calculate fares such as, for example,distance calculation device230 orgeospatial recognition module250.
• All of the methods and tasks described herein may be performed and fully automated by a computer system. The computer system may in some cases include multiple distinct computers or computing devices (e.g., physical servers, workstations, storage arrays, etc.) that communicate and interoperate over a network to perform the described functions. Each such computing devices typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-transitory computer-readable storage medium. The various functions disclosed herein may be embodied in such program instructions, although some or all of the disclosed functions may alternatively be implemented in application-specific circuitry (e.g., ASICs or FPGAs) of the computer system. Where the computer system includes multiple computing devices, these devices may, but need not, be co-located. The results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices such as solid state memory chips and/or magnetic disks, into a different state.
• The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the invention can be practiced in many ways. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the invention with which that terminology is associated. The scope of the invention should therefore be construed in accordance with the appended claims and any equivalents thereof.

Claims (23)

1. A for-hire vehicle computer system comprising:

a first processor;

a tangible first computer-readable-medium storing unique identifier data;

a tamper-evident, tangible, second computer-readable-medium storing:

decryption protocol data;

current for-hire vehicle operating parameter data;

first software instructions that when executed cause the processor to:

access an encrypted data packet comprising one or more updated for-hire vehicle operating parameters;

decrypt the encrypted data packet based on a decryption protocol;

determine if the for-hire vehicle computer system should operate according to the one or more updated for-hire vehicle operating parameters based at least in part on the unique identifier data;

extract the one or more updated for-hire vehicle operating parameters from the data packet; and,

modify the current for-hire vehicle operating parameter data based on the one or more updated for-hire vehicle operating parameters.

2. The for-hire vehicle computer system ofclaim 1, further comprising a removable, non-tamper evident portion.

3. The for-hire vehicle computer system ofclaim 2 wherein the non-tamper evident portion comprises a second processor and a non-transitory, tangible, third computer-readable-medium.

4. The for-hire vehicle system ofclaim 3, wherein the first processor and the second processor execute a security handshake.

5. The for-hire vehicle computer system ofclaim 1, wherein the software instructions further cause the processor to calculate a for-hire vehicle fare based on the modified current for-hire vehicle operating parameter data.

6. The for-hire vehicle computer system ofclaim 1 wherein the data packet is encrypted using an algorithm specific to the for-hire vehicle computer system.

7. The for-hire vehicle computer system ofclaim 1 wherein the tamper-evident, tangible, computer-readable-medium comprises a tampering indicator indicating a first state if the tamper evident, tangible, computer-readable-medium has been tampered with, and a second state if the tamper evident, tangible, computer-readable-medium is tamper free.

8. The for-hire vehicle computer system ofclaim 1 wherein at least one of the one or more updated for-hire vehicle operating parameters indicate a valid time period for the one or more updated for-hire vehicle operating parameters.

9. The for-hire vehicle computer system ofclaim 1 wherein at least one of the one or more updated for-hire vehicle operating parameters indicates a geospatial point based surcharge.

10. The for-hire vehicle computer system ofclaim 1 wherein at least one of the one or more updated for-hire vehicle operating parameters indicates a variable operational surcharge.

11. The for-hire vehicle computer system ofclaim 1 further comprising a USB port.

12. The for-hire vehicle computer system ofclaim 11, wherein the software instructions further cause the processor to access the encrypted data packet by the USB port.

13. A method of modifying the operation of a for-hire vehicle computer system, comprising:

accessing a security protocol associated with a for-hire vehicle computer system;

accessing a plurality of for-hire vehicle operating parameters, the for-hire vehicle operating parameters indicating the rules of operation of the for-hire vehicle computer system;

generating, by a parameter maintenance computer system, a data packet comprising an indication of the for-hire vehicle operating parameters;

securing, by the parameter maintenance computer system, the data packet according to the security protocol thereby creating a secure data packet; and,

transferring the secure data packet to the for-hire vehicle computer system.

14. The method ofclaim 13 wherein the security protocol associated with the for-hire vehicle computer system in an encryption protocol.

15. The method ofclaim 13 wherein the security protocol specifies an algorithm for securing the data packet that is unique to the for-hire vehicle computer system.

16. The method ofclaim 13 wherein the plurality of for-hire vehicle operating parameters comprises a time parameter, the time parameter indicating a period of time for which the for-hire vehicle computer system should operate according to the plurality of for-hire vehicle operating parameters.

17. The method ofclaim 16 wherein the plurality of for-hire vehicle operating parameters comprises mutually exclusive sets of operating parameters, the mutually exclusive sets of operating parameters each indicating a non-overlapping time period for which the for-hire vehicle computer system should operate according to for-hire vehicle operating parameters of each mutually exclusive set of operating parameters.

18. The method ofclaim 13 wherein the plurality of for-hire vehicle operating parameters comprises a geospatial point based surcharge.

19. The method ofclaim 13 wherein the plurality of for-hire vehicle operating parameters comprises a variable operational surcharge.

20. The method ofclaim 13 wherein the transferring is performed wirelessly.

21. The method ofclaim 13 wherein the transferring comprises:

copying, by the parameter maintenance computer system, the secure data packet to a non-transitory, computer readable medium; and

connecting the non-transitory computer readable medium to the for-hire vehicle computer system.

22. A for-hire vehicle computer system comprising:

means for storing a private encryption key;

means for decrypting data packets encrypted with a public key associated with the for-hire vehicle computer system to determine for-hire vehicle operating parameters;

means for detecting evidence of tampering with the storing means and decrypting means;

means for calculating for-hire vehicle fares based on the for-hire vehicle operating parameters.

23. The for-hire vehicle ofclaim 22 further comprising:

means for executing a software security handshake.

Images