Systems and methods for transit industry vehicle rider accessory capacity monitoring

#A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

#Transit agencies have begun offering their riders the ability to bring their bikes, and other accessories (“rider accessories”), with them on trips on the transit agencies' network of transit vehicles (such as buses, trains, and the like). In some cases the rider accessories are brought directly onto the transit vehicle. Sometimes there are designated areas for the rider accessories, such as bike racks on the front of the transit vehicles (“accessory storage”) or inside them. However there is a limited amount of accessory storage for a particular rider accessory (i.e. each transit vehicle has a “rider accessory storage capacity” for each rider accessory, even if it's zero or presumed to be zero in the absence of an explicit rider accessory storage capacity). As rider accessories become more prevalent, especially to assist in addressing the challenges of “the last mile” for transit riders, or last minute decisions to take transit, it is increasingly important to know, in advance whether a particular transit vehicle can (or is likely to be able to) accommodate a particular rider accessory. As such, some are attempting to connect a wired sensor to a vehicle mobile data terminal (“MDT”). While reliable for communication, these approaches are cumbersome, difficult to install, and expensive. Further existing approaches do not allow acceptance and dissemination of information related to rider accessory storage capacity (“rider accessory storage capacity information”).

#There thus remains a need for a solution that addresses the shortcomings in current rider accessory capacity monitoring systems.

#FIG. 1 is a diagram of a system for rider accessory capacity monitoring systems according to a non-limiting embodiment;

#FIG. 2A is a diagram of a bicycle storage accessory with the arm in a retracted position according to a non-limiting embodiment;

#FIG. 2B is a diagram of a bicycle storage accessory with the arm in an extended position according to a non-limiting embodiment;

#FIG. 1 is a diagram of a system 10 for transit industry vehicle accessory capacity monitoring comprising transit industry vehicle (TIV) 12, further comprising vehicle area network 14, router 16, next stop display 18, one or more TIV inputs/outputs (TIV IO) 20, mobile data terminal (MDT) 22 (which may traditionally have both a display and the ‘computer’ and processor, or MDT 22 may be more akin to a two-part solution having a display and a separate ‘computer’ which may be an integrated vehicle logic unit “IVLU”) and accessory storage 70, communication network 26, transit agency server 40, transit stop 30 and transit information sign 32, rider computing devices (RCD) 50 for rider 52 who has an accessory 54 (such as a bike, not shown).

#TIV 12 may be a bus, train, car, paratransit vehicle, and the like. TIV may be operated by a driver of a transit agency, or a third party, such as a third party contractor, or even individuals who are driving such vehicles, or may be operated without a driver. TIV 12 may have a schedule (such as arriving at various fixed stops such as transit stop 30) and may be part of a schedule of various transit agency services (such as other buses, trains and the like) that offer rides to riders 52, optionally with accessories. TIV 12 has many systems running thereon (with various inputs and outputs “I/O” 20), as known in the art, such as engines, brakes, audio announcement technology (such as transit stop announcements that may be displayed via next stop display 18 or announced via an audio announcement), signage, passenger counting, and the like (each a “TIV System”, some not shown) and may have a vehicle area network 14 to assist in communication between I/O, TIV Systems and MDT 22, including via router 16. Each TIV 12 may have one or more capacities for each of a one or more accessory type. For example TIV001 may have total capacity for 2 bikes and 1 scooter (and may have available capacity of 1 bike and 0 scooters if the other spots are already used), while TIV002 may have total capacity for 3 bikes (and may have available capacity of 2 bikes as 1 bike is already stored thereon). Such capacity information may be stored on transit server and/or MDT 22 (for example MDT 22 may only store accessory capacity information for itself, to save memory) and may be exchanged therebetween (via communication network 26 for example) for further dissemination, as described herein.

#MDT 22 is an on-board computing device used by a driver of TIV 12 to access or perform transit functionality (GPS and route information, vehicle diagnostics, schedule information and adherence, accessory capacity monitoring and information storage, and the like). Exemplary MDTs 22 may include tablets running MDT applications 22a that provide transit functionality and may include Ranger™, CMDTII™, and Touch MDT™ by Trapeze™, and ‘two-part’ on-board computing devices such as Pentium™ IVLU, C-IVLU, VE-IVLU, VI-IVLU and V8-IVLU. MDT 22 may include (or system 10 may separately have) an RFID tag (“MDT RFID tag” or reader tag, not shown) or RFID gateway (not shown) such that RFID tag 220 can communicate with MDT 22 (either directly or via the separate MDT RFID tag or RFID gateway, and in a wired or wireless fashion) and MDT 22 can then use the information in the RFID signal, as described herein. MDT 22 may be placed near the driver of the vehicle and may be oriented such that communication with RFID tag 220 is possible.