Method and device for detecting vehicle travel

Abstract

A method for detecting a trip of a vehicle. The method includes: generating seat data indicating whether a vehicle occupant occupies the seat using a seat sensor associated with a seat located in the vehicle. The method further includes: receiving the seat data from the seat sensor; and receiving telematics data indicating one or more attributes of the movement of the vehicle. The method also includes: determining whether a trip has occurred based on the seat data and the telematics data; and if it is determined that a trip has occurred, generating trip output data indicating attributes of the trip.

Description

Technical Field

[0001] The present disclosure relates to a method and apparatus for detecting the travel of a vehicle, for example, using a seat sensor. Background Art

[0002] Recently, such as and So-called e-hailing applications (sometimes also referred to as ride-sharing, ride-hailing applications, or transportation network carriers) have become increasingly common, allowing users to reserve, call, and pay for a ride in a vehicle such as a taxi, a limousine, and more recently, a scooter or other vehicle. For example, a user may use an e-hailing application on their portable device, such as a smartphone, to reserve a taxi to pick them up at their location. The taxi may then take the user to the user's desired drop-off point on a particular trip and payment for the trip may be automatically completed via the application.

[0003] Further, a transportation network company (TNC) may operate a fleet of vehicles, such as taxis and limousines, for use by users. In some jurisdictions, the vehicles may be privately owned and operated by the individuals operating the ride-hailing applications. In other jurisdictions, the vehicles may be owned and / or operated by the TNC under the authority of an appropriate authority, such as a local municipality or licensing bureau. In such cases, operating terms and associated fees may be agreed upon between the TNC and the authority (e.g., municipality). In other words, the operation of the vehicles used by the ride-hailing applications may be regulated by appropriate authorities.

[0004] For example, the TNC may operate a database storing trip data such as pickup time, drop-off time, pickup location, and drop-off location for one or more trips of the vehicles it operates. For example, the TNC may share the cost of a trip between a passenger and the TNC.

[0005] As part of the regulatory framework, TNCs can report trip data to authorized agencies (such as local municipalities) to help provide an overview of the TNC's footprint in the city. However, this data may be open to error or manipulation, which may result in a loss of municipal revenue if, for example, the regulator imposes a predetermined percentage of the fee paid to the municipality as part of the license fee for allowing the TNC to operate in the city.

[0006] Further, as the number of vehicles increases, the likelihood of error in the amount of billed charges or the difference between the expected (estimated) charges and the charges reported by the TNC increases. Accordingly, the revenue to the authority may be incorrect. This may also cause problems for the TNC when trying to comply with the regulatory framework that has been agreed upon with the authority (e.g., municipality).

[0007] Embodiments of the present disclosure attempt to solve or at least alleviate the above-mentioned problems. Summary of the invention

[0008] In a first aspect, a method for detecting a trip of a vehicle is provided, the method comprising: generating seat data indicating whether a vehicle occupant occupies the seat using a seat sensor associated with a seat located in the vehicle; receiving seat data from the seat sensor; receiving telematics data indicating one or more attributes of movement of the vehicle; determining whether a trip has begun based on the seat data and the telematics data; and generating trip output data indicating attributes of the trip if it is determined that the trip has begun.

[0009] In a second aspect, a device for detecting a trip of a vehicle is provided, the device comprising: a seat sensor associated with a seat located in the vehicle, the seat sensor being operable to generate seat data indicating whether a vehicle passenger occupies the seat; a seat data receiving module being operable to receive seat data from the seat sensor; a telematics module being operable to receive telematics data indicating one or more attributes of the movement of the vehicle; a processing module being operable to: determine whether a trip has started based on the seat data and the telematics data; and generate trip output data indicating attributes of the trip if it is determined that the trip has started.

[0010] Further aspects and features are defined in the dependent claims.

[0011] Embodiments of the present disclosure may help to automatically detect a vehicle's itinerary by using seat data provided by a seat sensor. For example, a user may use an electronic call application to call a taxi to a user-specified pickup point. Upon entering a taxi and sitting on a seat, the seat sensor may detect that the user has entered a taxi and is sitting on a seat. The processing module may then use the vehicle's seat data and telematics data (such as speed, location, time) to determine whether the trip has begun. For example, when a user sits on a seat, if the taxi is moving (the vehicle is in motion), the trip may be considered to have begun. For example, when the taxi stops and the user leaves, the seat data may indicate that the seat is no longer occupied. Thus, the trip may be considered to have ended and trip output data indicating, for example, the start time of the trip, the end time of the trip, the pickup location, and the drop-off location may be generated.

[0012] Thus, the trip output data can be used by the authorizing body to determine whether the TNC is reporting the correct charges for the trip. Further, for example, the TNC can use the trip output data to determine whether it is complying with the terms agreed with the authorizing body to ensure that it is operating within the required regulatory framework. The trip output data can also be used to automatically generate charges to the user or charges associated with the trip data provided by the electronic calling application to check for consistency.

[0013] Accordingly, the potential for revenue loss to authorized institutions can be reduced and TNCs can operate more consistently within the regulatory framework. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Embodiments of the present disclosure will now be described by way of example only with reference to the accompanying drawings, wherein like reference numerals refer to like parts, and wherein:

[0015] Figure 1 It is a schematic diagram of the ticket generation system;

[0016] Figure 2 It is a schematic diagram of the data transmission process;

[0017] Figure 3 is a flow chart of a method for automatically generating a ticket;

[0018] Figure 4 yes Figure 3 Flowcharts for further details of the methods in;

[0019] Figure 5 is a schematic diagram of a device for detecting the travel of a vehicle;

[0020] Figure 6 is a flow chart of a method for detecting a trip of a vehicle;

[0021] Figure 7 is a flow chart of a method for detecting whether a trip is activated; and

[0022] Figure 8 It is a schematic diagram of a computer system. DETAILED DESCRIPTION

[0023] A ticket generation method and system for automatically generating tickets are disclosed. In the following description, in order to provide a comprehensive understanding of the embodiments of the present disclosure, a number of specific details are presented. However, it is obvious to those skilled in the art that these specific details do not need to be adopted in order to implement the embodiments of the present disclosure. On the contrary, for the purpose of clearly presenting the embodiments, specific details known to those skilled in the art are omitted.

[0024] Figure 1 1 is a schematic diagram of a ticket generation system 100. The ticket generation system can automatically generate tickets related to a transportation network associated with a transportation network company. In an embodiment, the ticket generation system 100 includes an electronic call data source 102, a vehicle telematics data source 104, an electronic call database 106, a supervisory monitoring system 108, a violation module 110, and a user interface device 112.

[0025] In an embodiment, the ticket generation system 100 includes a seat sensor 114 associated with a seat located in the vehicle. The seat sensor can generate seat data indicating whether a vehicle occupant is occupying the seat. The seat data can be included as part of the data provided by the vehicle telematics data source 104. However, in other embodiments, the seat sensor can be omitted. The use of the seat data will be described in more detail later.

[0026] In an embodiment, the electronic call data source 102 may provide trip data, such as electronic call telematics data generated by an electronic call provider (also referred to herein as a transportation network company), to the electronic call database 106. For example, a user may use an electronic call application on a portable device, such as a smart phone, to book a taxi ride. During the taxi ride, the electronic call application may measure attributes of the vehicle's location, such as location, speed, and direction, based on a positioning sensor of the mobile device (e.g., a global positioning system (GPS) sensor), and generate electronic call telematics data from the measured attributes. In an embodiment, the electronic call application may generate electronic call cost data related to charges billed to the user. In an embodiment, the electronic call data source 102 may provide the electronic call cost data to the electronic call database 106 for storage by the electronic call database 106.

[0027] More generally, a transportation network company may provide an e-call application for use on a user's mobile device. The e-call application may generate trip data related to one or more trips of one or more vehicles. The trip data may include e-call telematics data and / or e-call cost data. In other words, in an embodiment, the e-call database 106 is operable to receive trip data related to trips of a vehicle from a transportation network company and store the trip data.

[0028] In an embodiment, supervisory monitoring system 108 is operable to receive real-time vehicle data related to vehicles within the transportation network. For example, supervisory monitoring system 108 may receive vehicle data from vehicle telematics data source 104.

[0029] In an embodiment, the violation module 110 is operable to generate violation data by analyzing real-time vehicle data and trip data stored in a database to detect whether a violation has occurred, and generate a ticket based on the violation data.

[0030] Thus, for example, the violation data may be used to monitor whether the transport network company is complying with the regulatory framework and, if a violation occurs, to impose fines accordingly. Subsequently, the operation of the ticket generation system 100 will be described in more detail below.

[0031] Figure 2Schematic diagram of a data transmission process according to an embodiment of the present disclosure. Figure 2 In the illustrated embodiment, a vehicle 202 associated with a transportation network company (TNC) may wirelessly communicate with a regulatory monitoring system (RMS) 108 via, for example, a mobile telecommunications network 204. However, it should be appreciated that other communication methods may be used. In an embodiment, a user's mobile device, such as a passenger in a vehicle 202, may communicate with a regulatory monitoring database 108 via the telecommunications network 204. In other words, for example, a vehicle 202 may be used as a telematics data source 104 to provide real-time vehicle data, and a transportation network carrier driver device may be used as an electronic call data source 102. For example, referring to Figure 2 , the vehicle 202 may send data via the network 204 using a dedicated gateway 208. The electronic call database 106 and / or the RMS may communicate with the vehicle via the network 204 using the security layer 206.

[0032] Reference Figure 3 and Figure 4 An embodiment of the operation of the ticket generation system 100 is described in more detail.

[0033] refer to Figure 3 At step s302, the supervisory monitoring system 108 receives real-time vehicle data related to vehicles (such as vehicle 202) within the transportation network. Figure 4 , at step s402, the vehicle 202 may send telematics data to the RMS 108. In an embodiment, step s302 may include step s402 to enable the RMS 108 to receive vehicle data from the vehicle. In other words, in an embodiment, the vehicle data includes telematics data indicating one or more attributes of the location of the vehicle. For example, it should be appreciated that the telematics data may include one or more of the following: vehicle location, vehicle speed, vehicle direction, and vehicle acceleration, although other data may be included.

[0034] return Figure 3 In step s304, trip data related to one or more trips of the vehicle is received from the TNC. Figure 4 , at step s404 , the TNC may share trip data, such as data related to one or more trips of the vehicle 202 .

[0035] At step s306, the trip data is stored in a database. In some embodiments, the RMS 108 includes an RMS database operable to store vehicle data. In these embodiments, at step s406, the vehicle data sent by the vehicle 202 (e.g., at step 402) and the trip data shared by the TNC at step s404 are stored in associated databases. For example, the trip data may be stored in the electronic call database 106 and the vehicle data may be stored in the RMS database. However, it should be appreciated that other databases may be used and that the trip data may be stored in the same or different databases as the vehicle data. In an embodiment, the RMS database and / or the electronic call database may be a NoSQL database for receiving real-time streaming data from the TNC and / or the vehicle. For example, it should be appreciated that data sent by the TNC may be provided in a CSV (comma separated values) format, or a JavaScript Object Notation (JSON) format, or an MQTT (message queue telemetry transport) format, although other suitable formats may be used.

[0036] In step s308, violation data is generated by analyzing the real-time vehicle data and the trip data stored in the database to detect whether a violation has occurred. For example, in step s408, this operation can be achieved by a ticket algorithm implemented by the violation module 110.

[0037] At step s310, a ticket may be generated based on the violation data. For example, at step s410, the violation data may be automatically sent to a server or other system provided by the municipality, for example, for output by the user interface device 112. At step s412, if a violation is determined to have occurred, a ticket may be applied to the TNC. For example, steps s410 and s412 may be implemented as part of step s310.

[0038] For example, the vehicle data may include one or more of the following: location (e.g., latitude / longitude), trip start time, trip end time, passenger boarding / disembarking (i.e., whether the passenger is in the vehicle). The vehicle data may be streamed to the RMS database in real time and cached in a message queue. For example, the message queue may be a streaming service that sends vehicle data from one or more vehicles to a cache server (e.g., implemented by RMS), where the data may be stored and classified, and then sent to a cloud-based virtual machine. The virtual machine may then send the cached vehicle data to the violation module 110. In an embodiment, the violation module 110 may function as a ticket automation engine (FAE).

[0039] Although it has been described in sequence Figure 3 Steps s302 to s310 in Figure 4However, this should not be construed as implying that steps s402 to s412 must be performed in the order described. Figure 3 and Figure 4 For example, the order of steps s302 and s304 may be reversed, or these steps may be performed simultaneously with each other.

[0040] In an embodiment, the violation module 110 is operable to implement one or more rules to determine whether a violation has occurred. As mentioned above, the real-time vehicle data and the trip data provided by the TNC can be analyzed by the violation module 110. For example, the violation module 110 can generate estimated fare data. The estimated fare data may be related to the trip of a vehicle going forward, such as vehicle 202. In an embodiment, the estimated fare data is generated from the real-time vehicle data.

[0041] In embodiments, it should be appreciated that the violation engine may implement pre-built rules based on the rates allowed for a vehicle, for example, based on trip parameters such as time of day, day of the week, pickup location, drop-off location, and type of vehicle, although other parameters may be used. It should be appreciated that the violation engine may set cost-dependent aspects such as cost per distance (e.g., AED / km), wait time (e.g., AED / minute), and location (e.g., based on geo-fences - if a vehicle is within a geo-fenced area, insurance may be billed), although other cost-dependent aspects may be used. In embodiments, the cost-dependent aspects may be based on trip parameters. Here, it should be appreciated that the currency AED refers to the United Arab Emirates currency, Dirham, although any other currency may be used.

[0042] In an embodiment, it should be appreciated that the violation engine 110 may determine whether a violation has occurred based on one or more violation parameters, such as one or more of the following: location start and end times, trip start and end times, trip duration, trip time, wait time, driver behavior score, and vehicle type, although other violation parameters may be used.

[0043] In an embodiment, the estimated cost data includes an estimated cost based on one or more estimation parameters. In an embodiment, the estimation parameters may be calculated according to Equation 1:

[0044] Equation 1:

[0045] EstimatedAmount=(Estimated_Booking_Fee+Estimated_Start_Fare+Estimated_Distance_Charge+Estimated_Time_Charge+Estimated_Toll_Charge+Estimated_Waiting_Charge+Estimated_CityChange_Charg e+Estimated_Specialevent_Charge+EstimatedExtra_Charge-Estimated_Discount+Drone_Delivery_Charge+Altitude_Counter+Drone_Vector_Charge+Scooter_Charge+Scooter_Counter)*Multiplier_factor

[0046] However, it should be appreciated that one or more parameters in Equation 1 may be omitted or modified as desired.

[0047] Referring to Equation 1, the estimated parameters can be defined as follows:

[0048] Estimated_Booking_Fee-The fee may be calculated based on the transportation type and the period according to a matrix (e.g., a lookup table). It should be appreciated that the transportation type may be a vehicle type such as a taxi, limousine, bus, scooter, or drone, although other vehicle types may be used.

[0049] Estimated_Start_Fare-The fee can be calculated based on one or more of the transportation type, location, and detection time period. The location can be based on location coordinates received from vehicle telematics data such as GPS data provided by the vehicle. The detection time period (e.g., current / time of day) can be based on the trip start time. In some embodiments, for example, if the vehicle is picked up at a location where a special event is occurring, such as a horse race or car race, the estimated start fee is based on the special event location. In an embodiment, for example, the estimated start fee can be based on a geographic fence defined by a municipality. For example, additional charges (e.g., a fixed starting price) can be added for trips starting from a specific location such as an airport and / or port. In an embodiment, the Estimated_Start_Fare can include a reservation fee, for example, pre-booking transportation for a vehicle (e.g., arranging a ride) in advance of the trip.

[0050] Estimated_Distance_Charge-The charge may be calculated based on one or more of vehicle type, location, cycle (travel time), and special event location.

[0051] Estimated_Time_Charge - A charge may be calculated based on the duration of the trip, for example, as indicated by vehicle telematics data. In embodiments, the charge may be based on whether the trip occurred during a specific time period of the day, for example, during congestion hours, or at night (e.g., between a start and end time such as 07:00-10:00 and 17:00-19:00 during congestion hours, or between 23:00-06:00 during night time).

[0052] Estimated_Toll_Charge - For example, when the vehicle is detected to pass through one or more toll booths, the charge can be included based on the vehicle location coordinates. In an embodiment, Estimated_Toll_Charge can be based on toll booth data provided by the vehicle. For example, each time the vehicle passes through a toll booth where a charge is generated, the charge can be included in the estimated amount.

[0053] Estimated_Waiting_Charge-It should be appreciated that the charge may be calculated based on the mean estimated speed of the vehicle, for example, at predetermined time periods such as every 1 s, 5 s, 10 s, 15 s, 20 s, 60 s, although other suitable time periods may be used. For example, if the mean average speed during the predetermined time period is less than the low speed threshold, then the low speed time charge may be accumulated. In an embodiment, a rate where the mean average speed is less than the low speed threshold is allocated based on 25 AED / hr. However, it should be appreciated that other suitable rates may be used.

[0054] Estimated_CityChange_Charge-When a border or change of city is detected based on the vehicle's location data, a charge may be applied. For example, if a change of city is detected and / or the destination is one or more of the predetermined destinations, such as an emirate in the United Arab Emirates.

[0055] Estimated_Extra_Charge - The charge may be based on a driver behavior score. For example, it should be appreciated that the driver behavior score may be based on detection of events such as speeding (exceeding a speed limit), hard braking (deceleration greater than a hard braking threshold), and hard acceleration (acceleration greater than a hard acceleration threshold), although it may be generated by other suitable means.

[0056] Estimated_Discount-It will be appreciated that the fare reduction may be applied based on, for example, the passenger's status (eg, membership level), or a special offer, or promotional discount, although other discounts may be applied.

[0057] Drone_Delivery_Charge - This charge may be applied, for example, if the vehicle is a drone or other aerial vehicle. A charge may be calculated relating to the cost of delivering / transporting / moving the drone from the drone's previous location to the pickup location.

[0058] Altitude_Counter - This fee may be applied, for example, if the vehicle is a drone or other aerial vehicle. The fee may be based on the maximum altitude reached by the drone during the trip. Alternatively, the fee may be based on the total change in altitude during the trip.

[0059] Drone_Vector_Charge - For example, if the vehicle is a drone or other aerial vehicle, this charge may be applied. Drone vector charging may be a charge based on a vector route (e.g., a three-dimensional route) that the drone is traveling. For example, some routes may be premium routes and have tolls associated with them (e.g., air charges).

[0060] Scooter_Charge - For example, if the vehicle is a scooter, this charge may be applied. For example, if the vehicle is a scooter, a fixed charge may be added.

[0061] Scooter_Counter_Charge - For example, if the vehicle is a scooter, a charge may be applied. For example, the charge may be included based on the number of scooters available.

[0062] Multiplier_Factor - For example, a multiplier factor of 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, or other values ​​may be applied. The multiplier factor may be zero or negative.

[0063] In equation 1, the estimated cost can be considered as calculated based on the mentioned parameters, however, the multiplication factor is omitted.

[0064] More generally, in an embodiment, the vehicle data includes one or more of the following: toll booth data, vehicle type data, engine parameter data, passenger counting data, and driver identification data. In an embodiment, more generally, the estimated amount (and / or estimated cost) can be based on the vehicle data.

[0065] In an embodiment, the trip duration may be based on a trip start and end time. In an embodiment, the vehicle data includes seat data generated using seat sensors associated with seats located in the vehicle, such as seat sensors 114, the seat data indicating whether a vehicle passenger occupies a seat. For example, the start and end times may be measured based on seat sensor data received from seat sensors 114 (e.g., including data related to seat sensor events). In an embodiment, the start and end times may be based on seat sensor events received within a + / - 2 minute time span of the start time as indicated by the start time data received from the electronic call application. In an embodiment, the location may be determined from the seat sensor based on passenger boarding / disembarking events, where, for example, passenger boarding / disembarking refers to whether a person occupies a seat. Subsequently, trip detection using seat sensors will be described in more detail below.

[0066] As mentioned above, violation data can be generated by analyzing real-time vehicle data with trip data stored in a database to detect whether a violation has occurred. In an embodiment, the trip data includes reported cost data about a trip reported by a transportation network company, for example, from an electronic calling application on a user's portable device. For example, the reported cost data may include reported costs for a trip indicated by reported cost data provided by a TNC. In an embodiment, generating the violation data includes comparing the reported costs indicated by the reported cost data with the estimated costs indicated by the estimated cost data. In an embodiment, generating a ticket includes generating a ticket if predetermined conditions regarding the reported costs and the estimated costs are met. In an embodiment, the predetermined condition refers to the estimated costs being a threshold amount different from the reported costs. For example, the reported costs can be compared with the estimated amount, and if the difference therebetween is greater than a cost violation threshold, a ticket can be generated.

[0067] Given below are some examples of instances in which tickets may be generated.

[0068] ID: Itinerary A

[0069] Electronic call charging fee = 135 AED

[0070] Assumptions:

[0071] Vehicle Type = 5-seat limousine

[0072] The time period when the trip starts = the night peak time period (e.g., 19:00-22:00)

[0073] Starting location = Dubai Mall, Dubai

[0074] End location = Dubai Airport, DXB, Dubai

[0075] Passed toll booths: 2

[0076] Travel distance: 50km

[0077] Duration: 80 minutes

[0078] Waiting time for detection: 10 minutes

[0079] calculate:

[0080] Estimated booking cost: 6AED

[0081] Estimated starting cost: 4AED

[0082] Time charge: 5AED

[0083] Distance charge: 90AED

[0084] Toll fee: 10AED

[0085] City change charge: 30AED

[0086] Additional cost: 0AED

[0087] Estimated cost = 145AED

[0088] Violation rules:

[0089] Violation = Rule ID: Trip B is based on estimated cost * 1.3 > cost of electronic call billing

[0090] Electronic call billing fee = AED1400

[0091] Assumptions:

[0092] Vehicle Type = 2-Seat Drone

[0093] Trip start time = traffic jam time (e.g. 07:00-10:00) Start location = Dubai Mall, Dubai

[0094] Finishing location = Godolphin Racecourse, Dubai

[0095] Passed toll booths: 2

[0096] Travel distance: 80km

[0097] Duration: 90 minutes

[0098] Waiting time for detection: 5 minutes

[0099] calculate:

[0100] Estimated booking fee: 30AED

[0101] Estimated starting cost: 95AED

[0102] Time charge: 30AED

[0103] Distance charge: 900AED

[0104] 3D Toll Fee: 150AED

[0105] City change charge: 0AED

[0106] Drone_Delivery_Charge: 40AED

[0107] Additional cost: 0AED

[0108] Estimated cost = 1245AED

[0109] Violation rules:

[0110] Violation = Rule based on estimated charges * 1.3 > charges for electronic call billing

[0111] In the embodiments of trip A and trip B, the estimated cost is calculated using equation 1, but the multiplication factor is omitted. In these embodiments, the multiplication factor is 1.3. In other words, for example, if the estimated amount is greater than the reported cost, it is determined that a violation has occurred. For example, a predetermined condition indicating that a violation has occurred and a ticket should be generated may refer to the estimated cost multiplied by the multiplication factor being greater than the reported cost. However, it should be recognized that a violation may be determined to have occurred based on other factors. For example, whether a violation is deemed to have occurred may be based on one or more of the following: location start and location end positioning, trip start time and trip end time, trip duration, trip time (time of day when the trip is started), waiting time, driver behavior score, and vehicle type.

[0112] In other embodiments, one or more of the following may be used to determine whether a violation has occurred:

[0113] 1. Trip start time = f (based on 1. Trip date 2. Trip vehicle type rate start fee)

[0114] 2. Trip start location = f (rate start fee based on whether the location is a high traffic location such as an airport)

[0115] 3. Travel time = f (the duration of the trip and the time fee)

[0116] 4. Trip distance = f (trip distance and distance-based fee)

[0117] 5. Waiting time = f (if the car does not move, a surcharge is charged)

[0118] 6. Driving behavior score = f (how well the driver drives, and the speed can be adjusted based on this)

[0119] 7. Vehicle type = f (number of seats can be used to set the rates for items 1-4)

[0120] In the lists enumerated above, for example, the term f(...) denotes a function of the parameters mentioned within the brackets.

[0121] In an embodiment, for example, charges may be reported from multiple vehicles and from multiple devices running the e-call application. In other words, for example, the techniques described herein may be applied to more than one vehicle and to multiple different types of vehicles.

[0122] For example, the user interface device 112 may be configured to provide an output indicating violations of a vehicle associated with the TNC, e.g., a vehicle operated by the TNC. The user interface device 112 may be configured with a filtering function to allow an operator of the user interface device 112 to view multiple different violations, e.g., filtering according to desired requirements. For example, a municipality may provide a regulatory framework within which the TNC must operate. The municipality may operate the user interface device 112 to view, for example, an indication of the difference in charges between charges reported by the TNC and an estimated charge for the vehicle generated from real-time vehicle data, violations of terms of the regulatory framework. The municipality may then track the TNC to help ensure that the TNC complies with the regulatory framework.

[0123] In an embodiment, the violation module 110 is operable to predict the number of violations that may occur on a particular day, or within a particular time period, based on, for example, previous violation history (related to, for example, the same or similar previous times or dates). For example, the violation module 110 may predict that a particular number of violations may occur during the morning traffic rush hour on the last day of the week based on previously recorded violations for that time period.

[0124] In some embodiments, for example, the techniques described herein may be applied to more than one TNC so that a municipality can monitor all TNCs operating in a particular area, such as within an urban area, the United Arab Emirates, or a rural area. Thus, for example, a municipality may use the techniques described herein to monitor individual TNCs in real time and perform grading, for example, based on real-time vehicle data. Thus, for example, this may help improve safety and help improve revenue monitoring and billing. Further, for example, by automatically generating tickets based on violation data, TNCs may be encouraged to automatically and more strictly comply with regulatory frameworks without incurring additional costs and administrative burdens on the municipality. Thus, a more efficient system and method for automatically generating tickets related to a transportation network associated with a transportation network company may be provided.

[0125] As mentioned above, in some embodiments, seat data from seat sensors may be used to determine that a trip has begun. Figures 5 to 7 This function is described in more detail.

[0126] Figure 5 is a schematic diagram of an apparatus 500 for detecting a travel of a vehicle such as vehicle 202 according to an embodiment of the present disclosure. Apparatus 500 includes seat sensors 502, seat data receiving module 504, telematics module, and processing module 508. In an embodiment, vehicle 202 may include apparatus 500.

[0127] In an embodiment, the seat sensor 502 is associated with a seat located in a vehicle, and the seat sensor 502 is operable to generate seat data indicating whether a vehicle occupant occupies the seat. In other embodiments, although it may be different, however, in an embodiment, the seat sensor 502 is associated with the seat above relative to Figure 1 The seat sensor 502 is the same as the seat sensor 114 mentioned above. In an embodiment, the seat sensor 502 includes a pressure-sensitive sensor located under the seat that generates seat data. For example, if the detected weight indicated by the seat sensor 502 is greater than a threshold weight, the seat sensor 502 may generate seat data indicating that a vehicle occupant is occupying the seat.

[0128] In an embodiment, the seat sensor 502 is a roughly square planar sensor of approximately 38 cm by 38 cm operable to detect the pressure and / or weight of an object on the seat. In an embodiment, the seat sensor 502 can be positioned relative to the seat to couple to a seat surface on which a user can sit. For example, if the seat sensor 502 detects that an object (e.g., a user) on the seat is heavier than a threshold weight of 15 kg, the seat is determined to be occupied and corresponding seat data is generated. However, it should be appreciated that other configurations and threshold weights are possible.

[0129] In other embodiments, the seat sensor 502 may include a camera and associated processing elements that operate to determine whether the seat is occupied based on image analysis of images captured by the camera. In some embodiments, the seat sensor 502 may include a photosensitive element located within the seat, so that occupancy of the photosensitive element causes a change in the output signal of the seat sensor 502. For example, it may be determined that the seat is occupied based on a change in the output signal.

[0130] In an embodiment, the seat sensor 502 is operable to generate a binary output indicating whether the seat is occupied. For example, "occupied seat" = 1, and "seat not occupied" = 0, although different binary values ​​may be assigned. However, it should be appreciated that other suitable seat sensors for determining whether a seat is occupied may be provided.

[0131] Although relative to Figure 5 One seat sensor is described, however, it should be appreciated that one or more seat sensors may be provided. For example, each seat may be provided with a corresponding seat sensor having similar or identical functionality to seat sensor 502. However, the seat sensors may be different from one another. Further, not every seat may be provided with a seat sensor. For example, the seat sensor associated with the driver's seat may be omitted.

[0132] In an embodiment, the seat sensor 502 is operable to send seat data to the seat data receiving module 504. In an embodiment, the seat data receiving module 504 may be implemented by the supervisory monitoring system 108. However, in other embodiments, for example, the seat data receiving module 504 may be implemented by a suitable circuit within the vehicle. In some embodiments, the seat data receiving module 504 may be implemented by a virtual machine running on a cloud server connected to the seat sensor 502 via a network. In other words, the seat data receiving module 504 is operable to receive seat data from the seat sensor 502.

[0133] In an embodiment, the telematics module 506 is operable to receive telematics data indicating one or more attributes of the movement of a vehicle, such as the vehicle 202. In some embodiments, the telematics module may be used as described above with respect to Figure 1 The telematics data source 104 described above. For example, it should be appreciated that the vehicle's motion attributes may be related to one or more of the following: vehicle position, vehicle speed, and vehicle acceleration, although other attributes may be used. Further, it should be appreciated that telematics data may include information such as those described above with respect to Figure 1 Other data described by the referenced telematics data sources. In an embodiment, the telematics module 506 may send telematics data to the processing module 508 .

[0134] The processing module may receive telematics data from the telematics module 506 and seat data sent by the seat data receiving module 504. The processing module 508 may be operable to determine whether a trip has been started based on the seat data and the telematics data. If it is determined that a trip has been started, the processing module may be operable to generate trip output data indicating attributes of the trip. Thus, for example, detection of a trip may be performed automatically.

[0135] In embodiments, it should be appreciated that processing module 508 may be implemented by supervisory monitoring system 108, although it may be implemented in other suitable ways. For example, processing module 508 may be implemented by a processor within a vehicle, and trip output data may be sent from the vehicle to supervisory monitoring system 108 via a suitable network. In other embodiments, for example, trip output data may be sent to a TNC so that charges may be automatically generated by the TNC, for example, via an electronic calling application.

[0136] Figure 6 is a flow chart of a method for detecting a trip of a vehicle according to an embodiment of the present disclosure. In step s602, seat data indicating whether a vehicle passenger occupies a seat is generated using a seat sensor (such as seat sensor 502) associated with a seat located in a vehicle (such as vehicle 202). In step s604, seat data is received from the seat sensor, for example, by seat data receiving module 504. In step s606, telematics data indicating one or more attributes of the movement of the vehicle is received, for example, by processing module 508 from telematics module 506. In step s608, based on the seat data and telematics data, it is determined whether a trip has begun. For example, as mentioned above, processing module 508 can determine whether a trip has begun. In step s610, if it is determined that a trip has begun, trip output data is generated, and the trip output data indicates the attributes of the trip. As mentioned above, it should be recognized that although the trip output data can be generated by other methods, in an embodiment, processing module 508 can generate the trip output data. Although steps s602 to s610 have been described in sequence, this should not be taken as implying that they must be performed in the order described. Figure 6 For example, the order of executing steps s604 and s606 may be reversed, or these steps may be executed simultaneously with each other.

[0137] In an embodiment, the trip output data may include properties of the trip, such as one or more parameters used to calculate, for example, the estimator described above with reference to Equation 1. However, it should be appreciated that the trip output data may include other suitable data related to the trip detected using, for example, seat sensor 502 or seat sensor 114.

[0138] The techniques described herein may allow for automatic detection of a trip and generation of corresponding trip output data based on, for example, the vehicle's seat sensor data and telematics data. However, it should be recognized that once a passenger enters a vehicle, they may not be seated in the same seat for the duration of the trip. To help address this issue, for example, one or more thresholds may be implemented for whether a seat is occupied and whether the vehicle is in motion. Figure 7 Describe the function.

[0139] Figure 7 is a flowchart of a method for detecting whether a trip is activated according to an embodiment of the present disclosure.

[0140] In an embodiment, when the seat data changes from false (0) indicating that the seat is not occupied to true (1) indicating that the seat is occupied, the trip may be considered to have started. For example, the timestamp of the seat data changing from false to true may be temporarily stored in the memory of the seat data receiving module 504.

[0141] refer to Figure 7 In step s702, the seat sensor 502 detects whether the seat is occupied. For example, the seat data generated by the seat sensor 502 may be sent to the processing module 508 via the seat data receiving module 504. In an embodiment, for example, the seat sensor 502 may be operable to continuously send the seat data to the processing module 508 so that the processing module 508 can monitor whether the seat is occupied.

[0142] If the seat is occupied, as indicated by the seat data, at step s704, the processing module 508 determines whether the trip is activated. If the trip is not considered to be active, the process proceeds to step s706.

[0143] In step s706, the processing module 508 determines whether the seat is occupied within a time greater than or equal to the first threshold time T1. In an embodiment, the first threshold time T1 is 60 seconds, although other values ​​such as 0s, 10s, 20s, 30s, 40s, 50s, or any other length of time may be used. If the seat is occupied within a time less than the first threshold time T1, the process proceeds to step s702. If the seat is occupied within a time greater than or equal to the first threshold time T1, the process proceeds to step s708.

[0144] In step s708, the processing module 508 determines whether the vehicle moves within a time greater than or equal to the second threshold time T2 indicated by the telematics data. Although other values ​​such as 0s, 30s, 60s, 90s, 180s, or any other length of time can be used, in an embodiment, the second threshold time T2 is 2 minutes (120s). If the vehicle moves within a time less than the second threshold time T2, the processing proceeds to step s702. If the vehicle moves within a time greater than or equal to the second threshold time T2, the processing proceeds to step s710. In step s710, the travel signal is set to activate. Then, the processing proceeds to step s702. In other words, in an embodiment, if the seat data indicates that the seat is occupied within a time greater than or equal to the first threshold time, and the vehicle moves within a time greater than or equal to the second threshold time indicated by the telematics data, the travel signal is set to activate. For example, when there is a change from false to true in the seat sensor data (i.e., a change from the seat being unoccupied to the seat being occupied may occur when a passenger enters the vehicle and sits down), the trip signal may be set to activate if the seat is occupied for longer than 60 seconds and the vehicle is in motion for more than two minutes.

[0145] In an embodiment, if the vehicle speed indicated by the telematics data is greater than a threshold vehicle speed, the vehicle is determined to be in motion. In an embodiment, the threshold vehicle speed is 16 kph, although other values ​​such as 0 kph, 5 kph, 10 kph, 12 kph, 14 kph, 18 kph, 20 kph, or any other speed may be used. For example, when the vehicle's speed is above 16 kph, the vehicle may be considered to be in motion.

[0146] In an embodiment, trip start data indicating a start time of a trip is generated in response to setting the trip signal to active. The trip start data may be based on telematics data. For example, the start time of a trip may be considered to be the time at which a seat sensor detects that a passenger is sitting on a seat (e.g., a change from a seat being unoccupied (false) to a seat being occupied (true) such as may occur when a passenger enters the vehicle and sits down).

[0147] However, in other embodiments, although this may result in underreporting of the trip duration, the trip start time may refer to the time when the trip signal is set to active. Therefore, in an embodiment, the trip start data may be based on the timestamp of the seat data change from false to true stored in the memory of the seat data receiving module 504. This may help to more accurately reflect the actual start time of the trip.

[0148] Returning to step s704 , if trip is active (ie, the trip signal indicates that trip is active), processing proceeds to step s712 .

[0149] In step s712, the processing module 508 determines whether the trip is activated within a time greater than or equal to a third threshold time T3 (the trip signal indicates that the trip is activated). In an embodiment, although other values ​​such as 0s, 30s, 60s, 90s, 180s, or any other length of time may be used, the third threshold time T3 is 120s.

[0150] If the seat data indicates that the seat is not occupied and the trip signal indicates that the trip is active for a time greater than or equal to the third threshold time T3, the trip signal is maintained to be active. In other words, for example, if the trip is active for a time greater than or equal to the third threshold time T3 and the seat signal becomes false (the seat is not occupied), the trip is still considered to be active. Then, the process proceeds to step s714.

[0151] However, at step s712, if the trip is not activated (trip signal = "inactive") or the trip signal has been activated for less than the third threshold time T3, processing proceeds to step s702. At step s702, if the seat is detected to be unoccupied, processing proceeds to step s712.

[0152] Thus, for example, once the trip signal is set to active, and the trip is longer than the third threshold time T3, the passenger can move around in the vehicle and still consider the trip to be active. This can help improve the accuracy of detecting whether a trip has started, and help provide passengers with greater flexibility when deciding to change seats during a trip, for example.

[0153] In some embodiments, because it is impossible for a passenger to leave the vehicle while the vehicle is moving, the trip signal can be maintained activated when the vehicle is moving (i.e., the speed of the vehicle is above the threshold vehicle speed). However, if the vehicle stops, for example, at a traffic light or due to traffic congestion, the trip can be considered no longer active because the vehicle is not moving. Therefore, in step s714, the processing module 508 determines that the vehicle is not moving for a period greater than or equal to a fourth threshold time T4. In an embodiment, although other values ​​such as 0s, 5s, 10s, 20s, 30s, 60s, 90s, 180s, or any other length of time can be used, the fourth threshold time T4 is 30s.

[0154] If the vehicle is not moving for less than the fourth threshold time T4, the process proceeds to step s702. However, if the vehicle is not moving for greater than or equal to the fourth threshold time T4, the process proceeds to step s716.

[0155] In step s716, the processing module 508 detects whether the seat is not occupied for a time greater than or equal to a fifth threshold time T5 based on, for example, the seat data. For example, if the vehicle is not moving for a time greater than the fourth threshold time T4, and the seat data indicates that the seat is not occupied for a time greater than or equal to the fifth threshold time T5, the passenger may have left the vehicle and the trip is over. In an embodiment, although other values ​​such as 0s, 10s, 20s, 30s, 40s, 50s, 90s, 180s, or any other length of time can be used, however, the fifth threshold time T5 is 60s.

[0156] Therefore, in an embodiment, if the trip signal has been set to active, in step s718, if the vehicle does not move for a time greater than or equal to a fourth threshold time T4, and the seat data indicates that the seat is not occupied for a time greater than or equal to a fifth threshold time T5, the trip signal is set to inactive.

[0157] Accordingly, embodiments of the present disclosure may facilitate automatic detection of one or more trips of a vehicle. More generally, in an embodiment, if a trip signal is set from active to inactive, it is determined that a trip has begun.

[0158] In an embodiment, trip end data indicating the end time of the trip is generated in response to setting the trip signal to inactive. For example, in step s718, when the trip signal is set to "inactive", trip end data can be generated by the processing module 508. In an embodiment, the processing module 508 can generate trip output data. The trip output data may include trip duration data based on the difference between the trip start time and the trip end time indicated by the trip start data and the trip end data. In other words, the trip duration data may indicate the duration (length of time) of the trip. In an embodiment, the trip output data may include trip distance data. The trip distance data may indicate the distance traveled by the vehicle between the start time and the end time of the trip based on, for example, telematics data. In some embodiments, a machine learning algorithm may be used to determine whether a trip has begun based on seat data and a previously trained model.

[0159] For example, by automatically detecting whether a trip has already started, the need for dispatch systems or fare systems in the vehicle can be reduced.

[0160] In an embodiment, the processing module 508 may determine whether the time between the trips is less than the adjacent trip time threshold. If the time between the trips is less than the adjacent trip time threshold, the processing module 508 may merge the adjacent trips together so that they are considered to be the same trip.

[0161] In an embodiment, the trip output data comprises a trip data record. In an embodiment, the trip data record comprises one or more of the following:

[0162] Location data - e.g. latitude, longitude with up to 4m accuracy;

[0163] Speed ​​data - in kph and m / s, accurate to 3 decimal places;

[0164] Direction data - direction in degrees from 0 to 360 degrees;

[0165] Accuracy of location data - accuracy in the range from 4m to 10m;

[0166] Time data - in UTC time, accurate to milliseconds;

[0167] · Fee amount data - local currency accurate to 4 decimal places;

[0168] Rapid braking data - in meters / s^2 or kph / s, accurate to 3 decimal places;

[0169] Rapid acceleration data - in meters / s^2 or kph / s, accurate to 3 decimal places;

[0170] · Sharp turn data - in meters / s^2 or kph / s, accurate to 3 decimal places;

[0171] Speeding data - in meters / s^2 or kph / s, accurate to 3 decimal places;

[0172] · Continuous driving time data - in hours, accurate to 3 decimal places;

[0173] Engine parameter data - for example, based on CANBUS (Controller Area Network Bus) data as PID (Parameter ID);

[0174] Passenger count data - for example, the number of passengers in the vehicle for the duration of the trip, as an integer from 0-7 (although this may vary depending on the size of the vehicle); and

[0175] • Driver details data (if available) - for example, data relating to telephone number, name, and driver's license details.

[0176] In some embodiments, the trip output data may be sent from the processing module 508 to the RMS 108. In other embodiments, the RMS 108 and the processing module 508 may work together to generate the trip output data. In an embodiment, the RMS 108 may use the trip output data to generate an estimated fare based on, for example, Equation 1. For example, as described above with reference to Figures 1 to 4As described, the estimated fare generated from the trip output data can be compared to the fare for the trip provided by the TNC to determine whether a violation has occurred. In some embodiments, the trip output data for one or more trips can be accumulated and shared with the transportation network company as a trip profile. In addition, it should be recognized that the trip output data can be generated according to the techniques described herein with respect to multiple vehicles (such as those operated by a TNC).

[0177] For example, a passenger may enter a vehicle (such as a taxi, a car operated by TNV, a limousine, or a bus) at an airport and sit on a seat in the taxi. Figures 5 to 7 The seat data is processed as described to detect the occurrence of a trip. For example, a trip may start at Dubai Airport at 8 a.m. and end at Sharjah Airport at 10 a.m. In this embodiment, the taxi may be a premium sport utility vehicle (SUV) and therefore additional premium charges may be included in the fare. RMS 108 may check the pickup location (airport), type of vehicle (SUV), and pickup time (8 a.m.) based on the trip output data and calculate an appropriate estimated fare based on this data and the ride occurring at a congested time (8 a.m.) and drop the passenger off at a location outside the geofenced area (i.e., in a different urban area than the location where the ride occurred), thereby generating a higher rate fare.

[0178] For example, the RMS may estimate that the cost of the trip should be 110.50AED. In this embodiment, the TNC charges 110.45AED. Therefore, the violation module may determine that a violation has occurred and the TNC may be fined accordingly. For example, the municipality may have agreed with the TNC that if the difference between the estimated cost generated from the real-time vehicle data and the cost of the trip data reported by the TNC is greater than 0.01AED, a violation is deemed to have occurred. In this embodiment, if the estimated cost and the reported cost are different from each other and are greater than the violation amount, a violation may be deemed to have occurred. Although other values ​​such as 0.1AED, 1AED, 5AED, 10AED, or any other amount may be used, however, in this embodiment, the violation amount is 0.01AED. In some embodiments, the multiplier factor mentioned above with respect to equation 1 may be the time to determine that a violation has occurred.

[0179] Figure 8 The computer system for implementing the method in the embodiment of the present disclosure is schematically shown. Specifically, Figure 8An embodiment of a computing device 2000 is shown that may be arranged to implement one or more embodiments of the methods described herein. For example, the computing device may implement the functionality of the RMS 108 and / or the violation module 110. The computing device 200 may implement the functionality of the user interface device 112.

[0180] In an embodiment, computing device 2000 includes main unit 2002. Main unit 2002 may include processor 2004 and system memory 2006. In an embodiment, processor 2004 may include processor core 2008, cache 2010, and one or more registers 2012. In an embodiment, processor core 2008 may include one or more processing cores and may include multiple cores running multiple threads. It should be appreciated that processor 2004 may be any suitable type such as a microcontroller, a microprocessor, a digital signal processor, or a combination thereof, although other types of processors may be used.

[0181] In an embodiment, processor core 2008 may include one or more processing units. It should be appreciated that, although other processing units may be used, in an embodiment, processor core 2008 includes one or more of the following: a floating point unit, an arithmetic unit, a digital signal processing unit, or a combination thereof, and / or a plurality of other processing units. It should be appreciated that, although other suitable cache arrangements may be used, in an embodiment, cache 2010 may include a plurality of caches such as a first level cache and a second level cache.

[0182] In an embodiment, the processor 2004 includes a memory controller 2014 operable to allow communication between the processor 2004 and a system memory 2006 via a memory bus 2016. The memory controller 2014 may be implemented as an integrated part of the processor 2004 or it may be implemented as a separate component.

[0183] In embodiments, system memory 2006 may be of any suitable type, such as non-volatile memory (e.g., flash memory or read-only memory), volatile memory (e.g., random access memory (RAM)), and / or a combination of volatile and non-volatile memory. In embodiments, system memory 2006 may be arranged to store code executed by processor 2004 and / or data associated with the execution. For example, system memory may store operating system code 2018, application code 2020, and program data 2022. In embodiments, application code 2020 may include code that implements one or more of the exemplary methods described herein, for example, implementing the above description of the operating system code 2018. Figures 3 to 7The application code 2020 may be arranged to cooperate with program data 2022 or other media, for example, to allow processing of trip output data, telematics data, real-time vehicle data, trip data, and violation data.

[0184] In an embodiment, the computing device 2000 may have additional features, functions, or interfaces. For example, the main unit 2002 may cooperate with one or more peripheral devices to implement methods such as those described herein. In an embodiment, the computing device 2000 includes an output interface 2024, a peripheral interface 2026, a storage device 208, and a communication module 2030 as peripheral devices. In an embodiment, the computing device includes an interface bus 2032 arranged to facilitate communication between the main unit 2002 and the peripheral devices. For example, the storage device may store data in an electronic call database or an RMS database.

[0185] In an embodiment, the output devices 2024 may include output devices such as a graphics processing unit (GPU) 2034 and an audio output unit 2036, for example, arranged to communicate with external devices such as a display and / or speakers via one or more suitable ports such as an audio / video (A / V) port. In an embodiment, the peripheral interface 2026 may include a serial interface 2038, a parallel interface 2040, and an input / output port 2042, which may be operable to cooperate with the main unit 2002 to allow communication with one or more external input and / or output devices via the I / O port 2042. For example, the I / O port 2042 may communicate with one or more input devices such as a keyboard, a mouse, a touchpad, a voice input device, a scanner, an imaging capture device, a camera, etc., and / or with one or more output devices such as a 2D printer (e.g., a paper printer), or a 3D printer, or other suitable output devices.

[0186] In an embodiment, the storage device may include a removable storage medium 2044 and / or a non-removable storage medium 2046. For example, the removable storage medium may be a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), a flash memory, or other storage technology, an optical storage medium such as a compact disk (CD), a digital versatile disk (DVD), or other optical storage medium, a magnetic storage medium such as a floppy disk, a tape, or other magnetic storage medium. However, it should be appreciated that any suitable type of removable storage medium may be used. It should be appreciated that, although any suitable non-removable storage medium may be used, the non-removable storage medium 2046 may include a magnetic storage medium such as a hard disk drive, or a solid state hard drive, or other suitable medium. The storage device 2028 may allow the main unit 2002 to access to implement, for example, the methods described herein.

[0187] In an embodiment, the communication module may include a wireless communication module 2048 and a wired communication module 2050. For example, the wireless communication module may be arranged to communicate wirelessly via a suitable wireless communication standard such as wifi, bluetooth, near field communication, optical communication (such as infrared), acoustic communication, or via a suitable mobile telecommunication standard. The wired communication module may allow communication via a wired or optical link such as Ethernet or an optical cable. However, it should be appreciated that any suitable communication module may be used. For example, the computing device 2000 may be used as a server that communicates with the vehicle via a suitable network. The computing device may be used as a network connection device, a thin client, and / or configured to implement one or more virtual machines.

[0188] In an embodiment, it should be recognized that one or more of the telematics module 506 and the processing module 508 may be implemented by the main unit 2002, although other suitable implementations may be used. In an embodiment, the seat data receiving module 504 may be implemented by the communication module 2030 or the peripheral interface 2026. In some embodiments, for example, the functions of the electronic call database 106, RMS 108, violation module 110, user interface device 112, seat data receiving module 504, telematics module 506, and processing module 508 may be distributed among more than one computing device (such as computing device 2000) by communicating through a suitable network. In some embodiments, the functions may be implemented by running one or more virtual machines implemented in a cloud computing environment. In addition, it should be recognized that one or more elements and modules described herein may be implemented using dedicated hardware running appropriate code.

[0189] It should be appreciated that although processing module 508 is described as implementing at least reference Figure 6 and Figure 7 Some elements of the steps mentioned, however, may be implemented in other suitable apparatuses such as a distributed computing environment, or dedicated hardware and software, for example.

[0190] It should be appreciated that in the embodiments of the present disclosure, the computing device (such as the one referenced above) may be used in any suitable manner. Figure 8 The disclosed method may be implemented in a computing device described herein) or in a conventional computing device. For example, a conventional computing device may be adapted to perform one or more of the methods described herein by programming / adapting one or more processors of the computing device. Thus, in an embodiment, programming / adaptation in the form of a computer program product may be implemented, including computer-implemented instructions stored on a data carrier and / or carried by a signal-bearing medium, or sent via a network such as a wireless network, Ethernet, the Internet, or any other combination of these or other networks, such as a floppy disk, a hard disk, an optical disk, a solid-state drive, a flash memory, a programmable read-only memory (PROM), a random access memory (RAM), or any combination of these or other storage media or signal-bearing media.

[0191] In other words, in an embodiment, the computer program may include computer-readable instructions that, when implemented on a computer (or processor), cause the computer to perform a method according to an embodiment of the present disclosure. In an embodiment, for example, a storage medium may include the computer program mentioned above. For example, the computer program may include software that, when implemented on the processing module 508, causes the apparatus 500 to perform one or more methods described herein. In some embodiments, although they may be implemented on different computing devices, the RMS 108, the electronic call database 106, and the violation module 110 may all be implemented on the same computing device.

[0192] It will also be appreciated that other suitable computer architectures, such as those based on one or more parallel processors, may be used.Furthermore, at least some of the processing may be implemented on one or more graphics processing units (GPUs) as desired.

[0193] The techniques of the present disclosure may be applied to one or more vehicles of any type. For example, the vehicle may be a taxi, a limousine, an automobile, a bus, a sport utility vehicle (SUV), an off-road vehicle (4x4), a scooter, a bicycle, a motorcycle, an unmanned aerial vehicle (UAV), or other aircraft, such as a passenger drone for carrying passengers (e.g., a so-called flying taxi), a helicopter, or other aircraft, or any other suitable type of vehicle. Further, it should be appreciated that the techniques described herein may be applied to a variety of different types of vehicles associated with a TNC or with more than one TNC and which need not all be of the same vehicle type (where more than one vehicle is contemplated).

[0194] Other embodiments and features of the disclosure are set forth in the following numbered clauses.

[0195] 1. A ticket generation method for automatically generating a ticket related to a transportation network associated with a transportation network company, the method comprising:

[0196] receiving, by a supervisory monitoring system, real-time vehicle data relating to vehicles within a transportation network;

[0197] receiving trip data related to one or more trips of the vehicle from a transportation network company;

[0198] Store the trip data in a database;

[0199] Generating violation data by analyzing real-time vehicle data and trip data stored in a database to detect whether a violation has occurred; and

[0200] Generate tickets based on violation data.

[0201] 2. The method of clause 1, comprising: generating estimated fare data from real-time vehicle data.

[0202] 3. The method of clause 1 or clause 2, wherein the trip data includes reported fare data for trips reported by a transportation network company.

[0203] 4. A method according to clause 3, wherein:

[0204] Generating the violation data includes: comparing the reported expenses indicated by the reported expense data with the estimated expenses indicated by the estimated expense data; and

[0205] Generating a ticket includes generating a ticket if predetermined conditions regarding the reported expense and the estimated expense are met.

[0206] 5. The method of clause 4, wherein the predetermined condition is that the estimated cost is different from the reported cost by a threshold amount.

[0207] 6. A method as described in any preceding clause, wherein the vehicle data includes telematics data indicating one or more attributes of the location of the vehicle.

[0208] 7. The method of clause 6, wherein the telematics data includes one or more of: vehicle location, vehicle speed, vehicle direction, and vehicle acceleration.

[0209] 8. A method according to clause 6 or clause 7, wherein the vehicle data comprises seat data generated using seat sensors associated with seats located in the vehicle, the seat data indicating whether a vehicle occupant is occupying the seat.

[0210] 9. A method according to any preceding clause, wherein the vehicle data comprises one or more of: toll booth data, vehicle type data, engine parameter data, passenger count data, and driver identification data.

[0211] 10. A ticket generation system for automatically generating a ticket related to a transportation network associated with a transportation network company, the ticket generation system comprising:

[0212] a supervisory monitoring system operable to receive real-time vehicle data relating to vehicles within the transportation network;

[0213] a database operable to receive trip data relating to trips of the vehicle from the transportation network company and to store the trip data; and

[0214] The violation module is operable to generate violation data by analyzing the real-time vehicle data and the trip data stored in the database to detect whether a violation has occurred, and to generate a ticket based on the violation data.

[0215] 11. A computer program comprising software which, when implemented on a processor, causes the processor to perform a method according to any one of clauses 1 to 9.

[0216] 12. A storage medium comprising a computer program according to clause 11.

[0217] Although various embodiments have been described herein, these embodiments are provided by way of example only and many variations and modifications of the embodiments will be apparent to those skilled in the art and are within the spirit and scope of the invention as defined by the appended claims and their equivalents.

Claims

1. A method for detecting a vehicle's range, the method comprising: generating seat data indicating whether a vehicle occupant is occupying the seat using a seat sensor associated with a seat located in the vehicle; receiving seat data from the seat sensor; receiving telematics data indicative of one or more attributes of movement of the vehicle; determining whether a trip has occurred based on the seat data and the telematics data; and If it is determined that a trip has occurred, generating trip output data indicating attributes of the trip, wherein if the seat data indicates that the seat was occupied for a time greater than or equal to a first threshold time and the vehicle was in motion for a time greater than or equal to a second threshold time indicated by the telematics data, setting a trip signal to active; If the trip signal is set to active, the method includes setting the trip signal to inactive if the vehicle is not moving for a time greater than or equal to a fourth threshold time and the seat data indicates that the seat has not been occupied for a time greater than or equal to a fifth threshold time.

2. The method according to claim 1, comprising: In response to the trip signal being set to active, trip start data is generated indicating a start time of the trip, the trip start data being based on the telematics data.

3. The method according to claim 1 or 2, comprising: If the seat data indicates that the seat is unoccupied and the trip signal indicates that the trip is active for a time greater than or equal to a third threshold time, the trip signal is maintained as active.

4. The method according to claim 1, comprising: In response to setting the trip signal to inactive, end-of-trip data is generated indicating an end time of the trip.

5. The method according to any one of claims 1 to 4, wherein: The trip output data comprises trip duration data based on a difference between a trip start time and a trip end time indicated by the trip start data and the trip end data.

6. The method according to any one of claims 1 to 5, wherein: If the trip signal is set from active to inactive, it is determined that a trip has occurred.

7. The method according to any one of claims 1 to 6, wherein: If the vehicle speed indicated by the telematics data is greater than a threshold vehicle speed, the vehicle is determined to be in motion.

8. The method according to any one of claims 1 to 7, wherein: The seat sensor includes a pressure-sensitive sensor located below the seat for generating the seat data.

9. The method according to claim 8, comprising: If the detected weight indicated by the seat sensor is greater than a threshold weight, seat data is generated indicating that the vehicle occupant is occupying the seat.

10. A device for detecting a vehicle's travel, the device comprising: a seat sensor associated with a seat located in the vehicle, the seat sensor being operable to generate seat data indicative of whether a vehicle occupant is occupying the seat; a seat data receiving module operable to receive the seat data from the seat sensor; a telematics module operable to receive telematics data indicative of one or more attributes of movement of the vehicle; A processing module operable to: determining whether a trip has occurred based on the seat data and the telematics data; and If it is determined that a trip has occurred, generating trip output data indicating attributes of the trip, wherein if the seat data indicates that the seat was occupied for a time greater than or equal to a first threshold time and the vehicle was in motion for a time greater than or equal to a second threshold time indicated by the telematics data, setting a trip signal to active; If the trip signal is set to active, the method includes setting the trip signal to inactive if the vehicle is not moving for a time greater than or equal to a fourth threshold time and the seat data indicates that the seat has not been occupied for a time greater than or equal to a fifth threshold time.

11. A storage medium comprising a computer program, the computer program comprising software, the computer program causing an apparatus to perform a method according to any one of claims 1 to 9.

12. A vehicle comprising the device according to claim 10.

Images