WO2022032229A1 - Mass transportation ridership information collection - Google Patents

Abstract

A system may include an interface/application that allows collection of information. The interface may be integrated with other district systems that allow validation of student information. The interface may be integrated with third-party-provided map/address information that validates address information prior to that information being transmitted from the interface. The interface may be integrated with routing software so that information collected in the interface gets sent: to the routing software. The routing software may accept the data transmitted from the interface, which then proceeds through a routing decision tree.

Description

MASS TRANSPORTATION RIDERSHIP INFORMATION COLLECTION

PRIORITY CLAIM

[0001] This application claims priority to U.S. Provisional Patent Application Serial No. 63/063,140 filed August 7, 2020, the entirety of which is hereby incorporated by reference as if folly set forth herein.

BACKGROUND

[0002] Efficient planning of school bus routes requires input from parents and guardians whose students are not only eligible for transportation to/from school, but who also request transportation service - that is, they opt in to district-provided transportation. School districts have used mailers and, more recently, web surveys to implement opt-in transportation. Transportation needs have also been collected when the school district organizes start-of-school orientation programs.

[0003] Previous approaches have suffered from a variety of different issues, including: insufficient data, inefficiency, and lack of security.

[0004] Manual (including paper-based) approaches often do not collect sufficient data. While they are able to record whether or not a parent wants/needs transportation for their child, they cannot collect pickup or drop-off address information, because there is no direct integration of manual (i.e., paper) methods with the backend routing system. A school district might be able to collect address information through manual means, but they have no way to effectively or efficiently enter that into a routing system. While “yes/no” responses can be manually entered into a routing system without an overly significant level of difficulty or delay, manual entry of addresses, usually requiring numbers, capital letters, and punctuation is very inefficient and error-prone. [0005] Web surveys (such as a Google document or HTML web forms, or for this purpose, a student infonnaiion system), while digital, suffer from the same issues as mailers if unintegrated with a routing system. When there is no integration with the routing system, the usefulness of the data collected through web surveys is limited in the same way as data collected through manual means, including but not limited to the lack of any data validation steps to help assure data accuracy and validity (e.g_, student identity, location information, etc.) Inefficiency in the tool leads to inefficiencies and introduces the potential for errors to be introduced when the data is transferred to the routing system. An added problem with web surveys not integrated with a routing system is that there is limited data integrity, security or quality control, in the worst, case, ail survey information is accessible to the public and ean be edited, intentionally or otherwise, by persons who would not be considered authorized. In other cases, data security relies on whatever security was built into the business process.

DRAWING FIGURES

[0006] FIG. 1 illustrates a system according to an embodiment of the invention;

[0007] FIGS. 2-4 are flowcharts illustrating processes according to an embodiment of the invention; and

[0008] FIG, 5 illustrates a screenshot showing an application according to an embodiment of the invention.

DETAILED DESCRIPTION

[0009] This patent application is intended to describe one or more embodiments of the present invention. It is to be understood that the use of absolute terms, such as “must,” “will,” and the like, as well as specific quantities, is to be construed as being applicable to one or more of such embodiments, but not necessarily to all such embodiments. As such, embodiments of the invention may omit, or include a modification of, one or more features or fimctionalities described in the context of such absolute terms,

[0010] Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a processing device having specialized functionality and/or by computer-readable media on which such instructions or modules can be stored. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

[0011] Embodiments of die invention may include or be implemented in a variety of computer readable media. Computer readable media can be any available media that can be accessed by a computer and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by a computer. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a earner wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media. In some embodiments, portions of the described functionality may be implemented using storage devices, network devices, or spec ial -purpose computer systems, in addition to or instead of being implemented using general-purpose computer systems. The term "computing device," as used herein, refers to at least all these types of devices, and is not limited to these types of devices and can be used to implement or otherwise perform practical applications. [0012] According to one or more embodiments, the combination of software or computer-executable instructions with a computer-readable medium results in the creation of a machine or apparatus. Similarly, the execution of software or computer-executable instructions by a processing device results in the creation of a machine or apparatus, which may be distinguishable from the processing device, itself, according to an embodiment,

[0013] Correspondingly, it is to be understood that a computer-readable medium is transformed by storing software or computer-executable instructions thereon. Likewise, a processing device is transformed in the course of executing software or computer-executable instructions. Additionally , it is to be understood that a first set of data input to a processing device during, or otherwise in association with, the execution of software or computer- executable instructions by the processing device is transformed into a second set of data as a consequence of such execution. This second data set may subsequently be stored, displayed, or otherwise communicated. Such transformation, alluded to in each of the above examples, may be a consequence of, or otherwise involve, the physical alteration of portions of a computer-readable medium. Such transformation, alluded to in each of the above examples, may also be a consequence of, or otherwise involve, the physical alteration of, for example, the states of registers and/or counters associated with a processing device during execution of software or computer-executable instructions by the processing device.

[0014] As used herein, a process that is performed “automatically” may mean that the process is performed as a result of machine-executed instructions and does not, other than the establishment of user preferences, require manual effort.

[0015] An embodiment of the invention provides a mobile application executable on an electronic device, such as a smart phone 130 (FIG. 1) that allows schools to survey parents for opt-in transportation and direct integration with a routing system executable on a processing device such as a server 110 (FIG. 1) for opt-in transportation. Due to resource shortages, including shortages in vehicles, drivers, and routing staff, and because not all families utilize transportation services provided by their school district, school districts need new tools and methods that help them accurately project transportation needs instead of offering transportation for all eligible students by default. Typically, school transportation plans are based on eligibility, which means that districts often plan to provide transportation services to more students than just those who plan to ride. Consequently, more buses are deployed than are actually needed to satisfy transportation-service demands. Asking parents to opt-in for transportation allows a district to route for actual transportation needs. Routing extra students who don’t plan to ride causes many compounding inefficiencies, including: (I) extra work for routing staff who waste time routing for phantom riders, (2) creation of extra stops for students who don’t ride, distorting runs and routes and often causing runs and routes to be longer than necessary, wasting time and fuel, and (3) inefficient planning for vehicle occupancy, leading many vehicles to operate below capacity.

[0016] An embodiment, which may be referred to herein as “ride registration,” helps school districts collect the data necessary to implement opt-in transportation; the challenge of collecting sufficient information from parents, caregivers, guardians, or other responsible parties was one major obstacle that prevented many school districts from implementing opt-in transportation. An embodiment collects a parent’s request for transportation for their child along with critical pickup and drop-off information that is necessary for school districts to accurately plan their routes. Student addresses maintained in student information systems (SIS) are often not accurate enough for transportation, and do not reflect when a student should be picked up at or dropped off at an address other than the address of record in the SIS, and transportation departments at school districts often need to look to alternative approaches to acquiring accurate addresses. These approaches are usually manual and inefficient, but an embodiment allows the districts to crowdsource updating addresses to the parents, by providing a means whereby a parent may request updates to pick-up and drop-off information in the application.

[0017] In an embodiment, parents can enter address information into the application, and such information can be validated by an address lookup function connected to a third- party map provider so there are minimal mix-ups caused by some people abbreviating things differently (St. vs. Str., or Ave. vs Avn, etc.)

[0018] ) To use an embodiment of ride registration, the student optionally advantageously already exists in the SIS (because to sign up for the app, the student record should already exist in the SIS), so there is no question of mismatches between students entered in the application vs. "real” students as they appear in the system of record. For example, unintegrated systems allow Sam Bull and Samuel Bull and ST Bull to exist simultaneously, but an embodiment of the present invention allows only one of those identifying names to be stored, and for that name to be the same as in the district’s system of record.

[0019] If there are discrepancies or questions/problems with the data despite these safeguards, the application allows the district to communicate to the parent to request clarification and collections easily inside the application. Collections may be entered directly into the application, which then transmits directly into the routing system without introducing human error from one or more manual entry steps.

[0020] An embodiment integrates with routing software executable on server 110 to minimize the time school district routers need to spend on data entry and preparation. Transportation departments are often starved for staff and time, so setting up existing staff to be more efficient is advantageous.

[0021] One or more embodiments may include the mobile parent application and back-office routing software. The mobile parent application provides parents with an easy way to opt-in to transportation services from the district and to provide the district, with pickup and drop-off address information. The back-office routing software is used to create and plan routes for the school district. Integration between the mobile parent application and the routing software enables implementing opt-in transportation.

[0022] Complex business processes can be used in order to collect accurate opt-in information from parents and to effectively use it for routing. An embodiment includes a tool used by transportation consultants to help a school plan and implement transportation opt-in. Successful implementation of opt-in transportation at a school district saves the district money by limiting over-routing.

[0023] One or more embodiments include advantages primarily in accuracy (digitized opt-in status and address collection), simplicity for communication with parents, and in direct integration with the routing system. Simplicity of communication may be made possible by messaging capabilities within the Parent Portal application and by integrations with the routing system.

[0024] FIG. 2 illustrates a process 200 according to an embodiment of the invention and from the point of view of a parent-user using the mobile application. [0025] At a step 210, the user accesses a Student Details screen 500 as seen in FIG. 5 and presented by the mobile application on smart phone 130. At a step 220, the user can tap on a transportation request section of the screen 500.

[0026] At a step 230, screen 500 displays a text field into which the user can enter an address at a step 240. In an embodiment, the screen 500 can automatically display one or more stored addresses that match the alphanumeric characters entered by the user. In an embodiment, if the student is already assigned transportation, (e.g,, data exists about assigned transportation from the previous year), then the mobile application will prepopulate the address field with his/her pickup and drop off address, so that the parent does not have to do so. If there is no data about previously assigned transportation, then the address field can be prepopulated with the current location of the smart phone 130, as long as the application is allowed to access the phone’s location information.

[0027] At a step 250, the user can submit wirelessly through WIFI or cellular network 120 the ride registration to the server 110 by selecting, for example, a ‘"register” button 510 (FIG. 5) presented by the mobile application. At a step 270, the routing system executed by server 110 makes a determination as to whether or not the ride registration is received and whether the ride registration is approved or rejected. Whether a specific registration is approved or denied is determined based on parameters set by the district based on, among other things, its transportation schedule and eligibility policies. For example, a rider attempting registration may request transportation to or from an address from which transportation is not provided (e.g., if the address is too close to school or outside the transportation area, if the requester is not authorized to request registration, etc.). At a step 260, the screen 500 displays to the user the status of this determination.

[0028] FIG. 3 illustrates a process 300 according to an embodiment of the invention and from the point of view of an operator administering the routing system executed by server 110. In this embodiment, upon receipt of a new ride registration, school district, staff work through mobile-application administration software and system management (SM) to determine whether or not the ride registration should be approved. Upon approval or rejection, the status of the ride registration is updated in SM. The parent can track their ride registration status in real time in the mobile application. If the ride registration is approved, then it is sent on to the back-office routing software, for example Edulog eSQL, so that the student can be assigned transportation.

[0029] At a step 310, server 110 and the routing software directly receives from a user via the mobile application and network 120 a student ride registration as discussed above with reference to FIG, 2. At a step 320, the routing software executed by server 110 reviews all received ride registrations. At a step 330, the routing software determines whether the status of a request is “received.’ If the request has not been recei ved by the routing software, the process 300 proceeds to step 360, At a step 340, the routing software determines whether the status of the request is “approved.” If the request is rejected, and thus not approved, the process 300 proceeds to step 360, If the request is approved, then at a step 350 the user who made the student ride registration is notified that the request is approved. At steps 360 and 370, the approved, inactive and rejected ride registrations are exported to a comma-separated- value (CSV) file. “Inactive” requests may be requests that are cancelled but not rejected. Usually, they are cancelled by the parent, but they may be cancelled by district staff if they do not want to reject, e.g., they have spoken with the parent and intend on satisfying the request outside of transportation. Finally, at a step 380 the CS V file is imported to eSQL as a batch student upload to set up the roundtrips for each approved ride registration.

[0030] FIG. 4 illustrates a process 400 according to an embodiment of the invention and from the point of view of an operator administering the routing system executed by server 110. In this embodiment, all new ride registrations are exported from SM and imported into eSQL. The router will use eSQL to determine whether or not to approve, reject, and ultimately assign transportation to the student, Once the router has made a final decision on whether or not to approve or reject the ride registration, the ride registration status is updated in SM to update the status of the ride registration in the parent portal app. In this embodiment, eSQL provides the ride registration reviewer (in this case the router) with all of the information they need to accurately determine whether or not the ride registration should be accepted. Even though it adds extra steps to the process before feedback can be provided to the parent, it is worth it to wait for review by a router using eSQL to prevent mistakes.

[0031] At a step 410, server 110 receives from a user via the mobile application and network 120 a student ride registration as discussed above with reference to FIG. 2. At a step 420, all received ride registrations are exported to a conima-separated-value (CSV) file. At a step 430, the CSV file is imported to cSQL as a batch student upload to set up the roundtrips for each approved ride registration. At a step 440, the routing software verifies eligibility before creating trips and determines whether the requested ride/trip has been set up successfully. If the requested trip has not been set up successfully by the routing software, then at a step 460 the status of the requested trip is set to “rejected” and the process 400 proceeds to step 470. If the requested trip has been set up successfully by the routing software, then at a step 450 the status of the requested trip is set to ‘"approved” in the process 400 proceeds to step 470. At step 470, an updated CSV file is submitted to system management so as to effectively update the status of each of the received ride registrations. Finally, at a step 480 the user who made the student ride registration is notified as to whether the request is approved or rejected.

[0032] One or more embodiments may include an interface/application that allows collection of information. The interface may be integrated with other district systems that allow validation of student information. The interface may be integrated with third-party- provided map/address information that validates address information prior to that information being transmitted from the interface. The interface may be integrated with routing so that information collected in the interface gets sent to the routing software. The routing software may be any generic routing software. Alternatively, the routing software may accept the data transmitted from the interface, which then proceeds through a routing decision tree.

[ 0033] While the preferred embodiment of the invention has been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the invention. One or more embodiments may include a mobile application with integration with a routing system. Such may include a mobile-first web form developed specifically for ride registration that would be available on common platforms, be designed with security in mind, and can integrate directly with a routing system. Such may further include an SMS survey using parents’ mobile phone information from SIS that may only ask for opt-in confirmation and does not collect address information. Accordingly, the scope of the invention is not limited by the disclosure of the preferred embodiment. Instead, the invention should be determined entirely by reference to the claims.

Claims

What is claimed is:

1 . A system, comprising: a user interface provided by an application that allows collection of rider information, the interface being integrated with systems that allow validation of rider information, the interlace being integrated with at least one of third-party -provided map and address information that validates address information prior to that information being transmitted from the interface; and routing software, the interface being integrated with the routing software so that information collected in the interface is sent to the routing software.