MOBILE TICKETING
Embodiments of a transit ticket system are provided. The transit ticket system may include a mobile computing device configured to (i) download a mobile ticketing application from a ticket management server, the mobile ticketing application including a graphical data sheet, a ticket dictionary, and ticket strings, (ii) receive ticket rendering instructions from the ticket management server in response to completion of a ticket purchase process via the mobile computing device, and (iii) render for display an active ticket on the mobile computing device with data stored on the mobile computing device based on the ticket rendering instructions, the graphical data sheet, ticket dictionary, and ticket strings in response to an activation input command.
This application claims priority to U.S. Provisional Patent Application No. 61/744,886, filed Oct. 3, 2012 entitled “MOBILE TICKETING” the entire contents of which are hereby incorporated herein by reference for all purposes.
FIELDThe present disclosure relates generally to apparatus, systems and methods for transit mobile ticketing.
BACKGROUND AND SUMMARYTransit agencies typically issue traditional paper tickets that may be validated once a rider boards a bus, train, or other transportation mode operated by the transit agency. The widespread use of mobile computing devices, such as smart phones, has provided an additional platform on which transit tickets may be issued. However, the technology for implementing such mobile transit tickets may be costly, unreliable, and inefficient.
The inventors have recognized these problems and developed a transit ticket system including a mobile computing device configured to (i) download a mobile ticketing application from a ticket management server, the mobile ticketing application including a graphical data sheet, a ticket dictionary, and ticket strings, (ii) receive ticket rendering instructions from the ticket management server in response to completion of a ticket purchase process via the mobile computing device, and (iii) render for display an active ticket on the mobile computing device with data stored on the mobile computing device based on the ticket rendering instructions, the graphical data sheet, ticket dictionary, and ticket strings in response to an activation input command. In this way, the local application is able to render and present the ticket for use regardless of the mobile device's connectivity with the ticket management server. As a result, the user can use the ticket in offline locations, including tunnels, out-of-range locations, etc.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
Aspects of this disclosure will now be described by example and with reference to the illustrated embodiments. Components and other elements that may be substantially the same in one or more embodiments are identified coordinately and are described with minimal repetition. It will be noted, however, that elements identified coordinately may also differ to some degree. It will be further noted that the drawings included herein are schematic and generally not drawn to scale. Rather, the various drawing scales, aspect ratios, and numbers of components shown in the figures may be purposely distorted to make certain features or relationships easier to see. Therefore, the figures are not intended to be technically precise, but are drawn to ease understanding.
Embodiments are disclosed herein relating to creating, managing, and dispersing mobile transit tickets. The transit ticket system may include a rider application configured to operate on a mobile device of a user, a tickets operation management system to create, allocate, and disperse the transit tickets, and a fare inspector system for validating the tickets. The rider application may be more generally referred to as a mobile ticketing application.
The transit tickets may be created by the tickets operation management system using a Transit Ticket Designer that receives input from a user indicative of one or more images the user desires to include as part of the ticket design. The Ticket Designer provides a platform in which the user may change multiple aspects of the images, including color, position, and animation, in order to create an individualized transit ticket. The ticket may then be stored and, upon a request from the mobile device of the user, be made available for rendering on the user's mobile device. The rendered ticket may then be presented when the user boards a transit vehicle.
As shown in
In addition to providing a system for designing transit tickets, the present disclosure may also provide for embedding clickable advertisements into the transit tickets. Additional information may also be provided along with the transit ticket when the user requests a ticket in order to board a transit vehicle. For example, information regarding the user's location, approximate wait time until a desired transit vehicle arrives, etc., may also be presented with the ticket. Further, a virtual inventory management system may be provided to allocate, track, and reconcile the issuance of the transit tickets.
The ticket operations management system (TOMS) may enable administrators to interact with the system and create custom tickets, connect with customers, track activity, and enhance operations. The TOMS may be configured to track mobile ticket sales and transactions and ties those reports into an existing accounting system. Using the geo-analytics platform and time slider, you can view activity on a map for a particular period, and better understand who is buying and using mobile tickets, where and when. Additionally, the TOMS may include various functions accessible to a user (e.g., an administrator) through a graphical user interface, including but not limited to an analytics function, illustrated in
Specifically,
A rider statistics tab may also be displayed on the dashboard shown in
a.) The users in the system (e.g., the new vs. returning users including a breakdown of number of rides and frequency of riding for return users).
b.) Total, peak, base, and/or average volume of ridership per day, hour, minute.
c.) Breakdown of riders by type (e.g., adult, youth, etc.).
d.) Overall ridership increase/decrease percentage since previous timeframe.
e.) How long after purchase riders activate tickets (would validate/contradict the assumption that most people are buying right before boarding).
f.) Rider sentiment (e.g., as submitted through the ticketing application), both overall and filterable by specific meta-data (e.g., line, time of day, stop, etc.).
g.) Social media feed pulling keywords, hash tags, etc., from an application program interface (API).
h.) Wordle based on aforementioned social media feed (e.g., a prevalence tag cloud).
i.) Overall brand health—% breakdown of satisfaction and overall sentiment as expressed via the in-app satisfaction rating and comments, as well as social media culling.
The ticket statistical tab may include statistical data relating to all the tickets in the system. The data may include:
a.) Total number of tickets purchased with ability to filter by fare, rider, or a combo of both.
b.) Ridership spending—Total ticket sales with same filter ability as above.
c.) Number of tickets used (with ability to see when/where, as well as how many are currently activated).
d.) Most activated ticket types in descending order.
e.) Frequency of individual ticket vs. multiple tickets activation.
f.) Number of people who purchase a single-use ticket (e.g., day ticket, 2 hour ticket) vs. a bundle (e.g., 7 day ticket, month ticket, year ticket, etc.).
g.) Purchase frequency heat mapping by date or location.
h.) How quickly riders activate a ticket after purchasing.
i.) How quickly riders activate a ticket after purchasing.
j.) Number of fare operator check-ins (e.g., all, approved, rejected) with associated meta-data (e.g., line, inspector, time of day, ticket type, etc.).
k.) Ticket sales in application vs. online.
l.) Order history.
The TOMS may also include a ticketing function illustrated in
The TOMS may also include a promotions function illustrated in
The ticketing function, which will be described in more detail below, may provide a platform for the transit agency to design and distribute tickets, and/or may provide a platform for the user to purchase and create tickets. The enforcement function may provide data regarding the number of validated tickets, mechanism of validation, and other information. The promotion and loyalty functions may provide for tracking user ticket purchases in order to grant the user various benefits. While each function of the ticket operations management system may be accessible to all users, in some embodiments certain functions may be restricted to a subgroup of users. For example, the enforcement function may only be accessible to the transit agency.
TOMS may support the use of various languages, including JavaScript, HTML 5, CSS, SQL, Objective C, Java, and PHP, implemented by various tools, such as Titanium Studio (Eclipse), XCode, Dreamweaver, and JIRA.
As explained above, the ticketing function of the TOMS may include a Transit Ticket Designer that provides tools to create transit tickets that contain selected animation, color, and design elements. Additionally, these tickets provide an alternative authentication method to visual authentication via QR Codes. These QR Codes are created using meta-data associated with the ticket and activities relating to the ticket (i.e., purchased, used, scanned).
The Ticket Designer provides the ability to upload a grouped set of images to create a transit ticket. Once a set of images is chosen, each of the images and their associated properties (color, height, width, etc.) may be manipulated to create a unique looking ticket. In addition to changing the look of the images, the images may also be placed at specific locations with a frame (e.g., HTML canvas) when the image is rendered and then moved (via animation) to new specific locations at a given speed. Once a ticket is rendered, an encrypted QR Code may be generated using meta-data about when the ticket was purchased and/or validated, along with information about the rider and the ticket type.
Example graphical user interfaces of the ticketing function including the Ticket Designer are illustrated in
The user may edit the appearance of the tickets by adjusting animation (as illustrated in
The user may adjust the ticket design on a one-time basis, or may adjust the tickets periodically, as illustrated in
1.) The art components are created. The art components include but are not limited images, text, and animations.
2.) The components are loaded into the spritesheet maker. This loads all components as images and then draws them to a canvas element, and keeps track of the rect (x, y, width, height) that each component occupies, and each component's name.
3.) The rect and names are then compiled into a dictionary object, which is then sent to a server and stored in a database.
4.) A user then launches the Ticket Designer and specifies which spritesheet to use and the Ticket Designer asks the server for the dictionary.
5.) The components are laid out in the Ticket Designer and the user may use the design tool to layout the components, change the color of one or more of the components, and/or apply animation.
i.) To layout the components, the Ticket Designer utilizes a canvas element and updates a component's rect by tracking mouse movement (e.g., movement of the user's mouse) within the canvas.
ii.) To change a color of a component, the canvas grabs the pixel data for the component and then changes the RGBA values based on user input.
iii.) At least four types of animations may be used, including velocity, scaling, rotation, and opacity. All rotations allow for repeat values, with −1 being constantly repeating, a delay, and a “ping-pong,” meaning the animation will be run forward and then backward.
-
- a.) Velocity animations have a user set a start point, end point, and a duration. The Ticket Designer then calculates the x-component and y-component of the component's velocity based on the duration and the delta between x and y values from the start point to the end point.
- b.) Scaling animations have a user set a start scale, an end scale, and a duration and calculates a step based on the duration to add or subtract from the current scale (with 1.0 as the base scale).
- c.) Rotation animations have a user set a start rotation, an end rotation, and a duration, and a step number of radians is calculated for each iteration of the animation.
- d.) Opacity animations have a user set a start opacity, an end opacity, and a duration. A step is calculated for opacity based on duration.
6.) The Ticket Designer allows for previewing of the ticket as a whole.
7.) Once the ticket has been created, the user submits the ticket to the server as a string representing the ticket object.
i.) The ticket object is an array of objects called layers with an additional object containing data specific to the ticket.
ii.) The first index in the array has the name of the spritesheet image used for the tickets.
iii.) Subsequent indices are the layers of the ticket.
-
- a.) Each layer has the color of the ticket as RGBA values.
- b.) Each layer has the name of the component used for the layer.
- c.) Each layer has the starting position of the layer.
- d.) Each layer has an array of animation objects.
- I.) Each animation object has the type of animation.
- II.) Each animation object has the beginning parameters, ending parameters, duration, repeat, delay, and ping pong values.
8.) A rider (e.g., the user) purchases a ticket and a new ticket entry is created in the databases with a reference to a previously submitted ticket design.
9.) The rider application on the rider's computing device (e.g., smart phone, tablet, laptop computing, etc.) downloads the ticket object as well as any relevant information it may not have i.e. spritesheet and dictionary.
10.) The application creates three canvas elements, one that is a first buffer for individual components, a second that is a buffer for the whole ticket, and the third which renders the ticket.
11.) The application loads the spritesheet into an image element then draws those to the first buffer and then grabs the pixel data from that canvas for each layer in the ticket.
12.) After the layer components, the application renders the text components that display ticket information like expiration, rider type, and daycode.
13.) The top unanimated layers are all combined into a single layer to assist performance.
14.) Once all components have been loaded, the application draws them onto the first canvas based on their rect and then puts the image data of the first buffer onto the second buffer. Once all components have been drawn to the second buffer, the context for the third canvas is adjusted to fit the proportions of the rendering screen and the completed ticket image is drawn to scale to the screen.
15.) All animations created with the parsing of the ticket object are now started and an interval is called to update the state of the ticket and then render the ticket via the process in step 13.
16.) When the QR button is pressed a QR code is generated using encrypted text with information about the ticket and given an opacity animation in order to fade in and out.
17.) This QR code is added as an additional layer to the end of the ticket object.
Another example process for creating and/or editing a ticket using the Ticket Designer according to the present disclosure includes:
1.) The Ticket Designer allows for users to create and edit designs for visually authenticated tickets. The creation of tickets may use a variety of predefined elements from a supplied library, or new assets that the user uploads. These designs can be used for transit, events, and advertisements.
2.) Upon loading, the Ticket Designer may consult a Rules Engine to populate a library of predefined assets.
3.) User selects assets to use in the project.
4.) A graphical data sheet (e.g., spritesheet), ticket dictionary, and ticket object are created referencing this collection of assets. These are stored in the Rules Engine.
5.) The user will then have the ability to upload new components, such as text or images, which will then update the graphical data sheet (e.g., spritesheet), ticket dictionary, and ticket object.
6.) Each component is drawn to a canvas, rendering the ticket.
7.) A menu of layers is populated from each component. Each layer contains references to initial properties that can be edited.
8.) Users add ticket states (e.g. tapped/untapped screen). This updates the ticket object.
9.) Users select a layer to edit from the menu. If applicable user can select which state to edit.
10.) Users can edit multiple properties of the selected layer.
11.) Through mouse or keyboard manipulation, which will update the ticket object.
12.) The user adds or edits animations. This can be done by modifying values within each layer's menu, or by modifying the animation timeline. The timeline features a visual reference to the speed and duration of each animation.
13.) Saving the ticket encrypts the graphical data sheet (e.g., spritesheet), ticket dictionary, and ticket object.
14.) Encrypted information is sent to the rules engine for storage.
15.) The new ticket can be edited at a later time by loading the ticket from the Rules Engine, or can be scheduled to use at a specific time or date using the Ticket Scheduler.
Example graphical user interfaces that may be presented to a user when interacting with the rider application are illustrated in
The rider application may provide a user with the ability to purchase a specific transit ticket for a particular rider as well as allow the user to display the purchased ticket on his or her mobile device for validation. For example,
After selecting the “use” button, the desired ticket will be validated and the animated ticket will appear.
Thus,
While
Additionally, a ticket purchasing interface may display various buttons, tabs, or other interface objects for purchasing tickets.
As described above, the Transit Ticket Designer provides tools to create transit tickets that contain unique animation, color and advertising design elements, and which provide an alternative authentication method to visual authentication via QR Codes. Additionally, advertising may be embedded in the transit tickets designed by the Ticket Designer. For example,
When a ticket and animation scheme that contain advertising images are chosen, then when a rider enters a geo-fenced area, the rider is alerted to open an active ticket and the animation is activated.
In one example, a process for embedding advertising in a transit ticket includes performing the steps 1-16 as described above and additionally includes:
17.) Once an animation with an embedded advertising is viewed or clicked, then this data is recorded and synced with a server for reporting and analytics.
Thus, the Ticket Designer allows a user to select and/or modify a group of images to be presented as part of an electronic, mobile transit ticket. The transit ticket may then be retrieved by a transit application of the user's mobile device when the user wishes to board a transit vehicle. In order to manage the number, type, etc., of electronic transit ticket issued by the transit agency, a system, described below, is provided for allocating the tickets.
The Virtual Inventory Transit Ticket system allows for “virtual” tickets to be allocated by a transit agency. The allocation provides a unique number, the fare type, number of tickets, associated prices, and other key data. The virtual inventory system provides a means of financial accountability for the transit agency and the inventory management system owner. Tickets may be allocated via a web interface or Web Services.
Each fare type is created as a product type in the inventory system with associated warning and emergency threshold levels set. A transit agency manager logs into the system and allocates a number of tickets for each fare type and sets the threshold limits. When a rider requests a new ticket, an allocated ticket of the appropriate fare type is removed from inventory and assigned to the purchasing rider. This movement from inventory to purchased status is tracked via the unique identification assigned to each allocated ticket.
When the inventory levels of each ticket reach the assigned warning level, an email is sent to the transit agency administrator requesting an allocation of additional tickets. If a response is not received within a specified time period or the inventory level gets to a critical stage, then another email is sent to a broader team and a pre-set amount of inventory is automatically allocated.
All inventory transactions are reconciled with the payment processors records and the reports are exportable in PDF, CSV and XML format.
At 5602 the method includes downloading a rider application from one or more application stores. Next at 5604 the method includes launching the rider application. At 5606 the method includes installing a Spritesheet containing ticket images, animation, text, graphics on the mobile device. The Sprite Sheet images may be used to provide the visual identifiers for authenticating the tickets. In some examples, the Sprite Sheet may be encrypted to prevent unauthorized access to the images used for the visual identifiers.
Next at 5608 the method includes generating a unique ID for the rider application. The unique ID associates the rider application with the mobile device. At 5610 the method includes capturing mobile device information. The mobile device information may include screen size and density, operating system type, operating system version, and network carrier. Additionally, capturing the mobile device information may include storing the mobile device information on the phone file system for later retrieval by an application code. At 5612 the method includes creating databases for offline use and analytics. In one example, ticket information and user activity may be stored in local and remote databases. At 5614 the method includes creating a default product catalog for storage on the mobile device. At 5616 the method includes setting an update interval that instructs the rider application on the frequency of validating changes with the server. In this way, the rider application may “phone home” periodically to retrieve validation. It will be appreciated that the update request may be implemented automatically without user interaction, in one example. Furthermore, the update request may be implemented regardless of the tickets purchased via the rider application, in one example.
At 5702 the method includes selecting a valid rider type. Next at 5704 the method includes selecting a valid fair type. The valid rider type and/or valid fair type may be selected from an installed product catalog on the mobile device.
At 5706 the method includes checking out by selecting a valid payment instrument or providing payment information. Next at 5708 the method includes verifying inventory is available on the server. In this way, it is assured that inventory is available.
At 5710 the method includes processing payment with a processor. In one example, the payment may be processed via a PCI compliant API or other known payment system. Next, at 5712, the method includes generating a ticket at the server. Generating a ticket may include creating a ticket record. At 5714 the method includes updating the inventory with the purchased ticket. Updating the inventory may include assigning a serial number to the ticket for inventory, in one example.
At 5716 the method includes retrieving ticket meta-data from the server. The meta-data may include latest designs such as colors, animation schemes, etc. Such meta-data may be added to the Sprite Sheet. Next at 5718 the method includes updating a user account with ticket(s) purchase info and meta-data. The meta-data may be stored on the local mobile device as part of the application. Thus, with purchase, the ticket may be rendered based on the mobile device application. Additional data exchange with a server is not necessary.
At 5802, the method includes downloading ticket information to the mobile device which may be considered part of the purchase. In some embodiments, an application refresh may further be provided. Additionally, the application refresh may be initiated during a login process and/or via a pull-to-download feature, in one example. In another example, the downloaded ticket information may be encrypted and stored in a database in the mobile device. Next at 5804, in some examples, the method includes storing ticket meta-data (e.g. if there have been changes) on the mobile device.
At 5806 the method includes updating the server with the download information. In one example, the download information may include date/time, latitude, longitude, and/or app ID associated with the mobile device. Next at 5808 the method includes determining ticket parameters and storing the ticket parameters in the device. The ticket parameters may include a HTML canvass positioned, image colors, animation duration, animation path, and/or animation speed. The ticket parameters may be used to dictate how a ticket looks and acts upon activation (e.g., ticket launch). Additionally in one example, ticket meta-data, such as ticket type, may be analyzed to determine expiration times, isotypes, and appropriate informational and warning messages. The meta-data, expirations times, isotypes, informational messages, and/or warning messages may be stored in the local database. As noted above, this download may occur during purchase, at a set interval after purchase or at another time.
At 5902 the method includes tapping a use button in the rider application to begin using a ticket. It will be appreciated that the rider application may be executed via a mobile device. Additionally, tapping the use button may mark the ticket as validated, in one example.
Next at 5904 the method includes capturing key ticket information and storing the information locally. The key ticket information may include validation date/time, latitude, and/or longitude and may be stored in a local database in the mobile device. It will be appreciated that the key ticket information may be used during the generation of a QR code.
At 5906 the method includes reading ticket meta-data and launching ticket animation. Reading the ticket meta-data may initiate retrieval and/or display of a ticket expiration time, ticket type, rider type, DayCodes, and ticket name. Images from the Sprite Sheet may be displayed as visual identifiers.
At 5908 the method includes adjusting the ticket canvass based on device capability. For instance, the size of the displayed ticket and/or animation sequence may be adjusted based on mobile device features, such as a screen size, operating system version, screen density, etc.
At 5910 the method further may include clicking a Daycode button and at 5912 the method includes generating a QR code in response to clicking the Daycode button. The QR code or other code which may be generated when the user taps a DayCode button via the rider application. The QR code may be encrypted, in one example. Furthermore, the QR code may be generated using ticket meta-data such as validation date/time, ticket type, rider type and validation latitude and longitude.
As provided above, information such as the Daycode or meta-data may be sent to the mobile device on a pre-set schedule or other schedule. For example, the system may update the Daycode and meta-data information on a 72 hour schedule or other select schedule. Such updates may be automated and/or preset and may occur without request or selection by the user.
Again, it should be appreciated that use of the ticket and presentation of the ticket and visual identifiers may be based on the pre-loaded information which occurred during purchase. In such examples, no data files or other information needs to be sent to the local application after purchase for use of the ticket. Instead, the local application is able to render and present the ticket for use based on the purchase information. Such an example enables a user to use the ticket in offline locations, including tunnels, out-of-range locations, etc.
At 6002 at the rider application, reading the update interval value and securely calling the server to check for validation updates. The rider application may provide information regarding the version of the application and the time and date of the last update. At 6004 it is determined if updates are available at the server. It updates are not available (NO at 6004) the method ends. However, if updates are available (YES at 6004) the method proceeds to 6006. At 6006 the method includes automatically downloading data objects, meta data, images, etc., to the mobile device without any user interaction. At 6008 the method includes applying the update to the rider application. It will be appreciated that information needed to place ticket images in exact positions on the HTML canvass, determine image colors, animation duration, animation path, and/or animation speed is stored on the mobile device. This information dictates how the ticket looks and acts upon activation (e.g., ticket launch). This information may be downloaded to the mobile device during a ticket purchase or when the rider application is installed.
At 6102 the method includes starting the rider application and at 6104 the method includes searching for purchased tickets during application loading. Next, at 6106 the method includes selecting a ticket for use via an input command. The input command may be a voice command, an interaction with a visual component displayed in the mobile device, a laser scan, a command sent via a remove device (e.g., a Bluetooth command). Specifically in one example, the user may select a “my tickets” button displayed via the mobile ticketing application and a “use” button via the mobile ticketing application. This functionality may be implemented regardless of network connectivity of the mobile device. In one example, a user may be prompted with a confirmation alert in response to selection of a “use” button. The confirmation alert may ask the user if they are sure they want to use the ticket and provide a yes or no response choice via the user interface.
At 6108 the method includes retrieving ticket data and coupling the ticket data with ticket visualization instructions to render a valid ticket. The ticket data may include ticket type, user type, and/or other tokens stored on the mobile device. The ticket data may also include expiration time. Step 6108 may also include grabbing a lowest identification of the type of ticket used, checking if a daycode is current (if not update), grab ticket string, decode ticket string, grab user location, and/or caching the ticket data for re-launching, in one example. It will be appreciated that the data generated or retrieved in the aforementioned steps may be sent to the ticket management server when network connectivity is available. Further in one example, if a user modifies the time on the mobile device the mobile ticketing application may send a message to the user and/or lock the mobile device. In one example, the mobile ticketing application may be locked and unlocked remotely by the ticket management server.
At 6110 the method includes rendering the ticket and displaying ticket components based on display instructions. The ticket components may include a 1 or 2 dimensional bar codes, text, images, animations, and/or video. In one example, the method 6100 may be implemented regardless of network connectivity of the mobile device. However, in another example the tickets may be unlaunchable if the mobile device does not have network connectivity. In such an example, the mobile device is not locked per se. However, the state of the ticket may be modified. Once network connectivity is re-established the mobile device may “phone home” and the ticket may be usable again.
At 6202 the method includes inspecting tickets via visual review, barcode scan, and/or near field communication (NFC). This inspection process determines whether a ticket is valid for a given person, date, time, and/or location. Additionally, it will be appreciated that the barcode scan and NFC inspection may be implemented via a mobile computing device of a ticket inspector. It will be appreciated that the mobile computing device may execute an inspector application.
At 6204 the method includes capturing the identity of the person's via drivers license image capture, magnetic strip swipe, or manual capturing identity via an inspector's mobile application. It will be appreciated that manual input may include typing the information into the application via a keyboard included in the device. In one example, the identity information may be stored locally on the mobile device executing the inspector application. The stored identity information may be used to provide a citation history and for synchronization with a ticket management server.
At 6206 the method includes generating a citation using government forms and the captured identification information. It will be appreciated that the forms may be mandated via local and/or state governments. The generated citation may be stored in the inspector's mobile computing device. In one example, the citation may be a uniform citation that includes the identification information captured via the inspector application at steps 6204.
At 6208 the method include at the inspector's mobile application sending the citation information to an appropriate legal entity. The citation information may be sent via API's, periodic downloads, and/or intermediate batch processes. In one example, the citation information may be sent to a court system via a web-service.
At 6210 the method includes sending the citation information to a local printer. In this way, all the parties may be provided with hard copies of the citation information. In one example, the method may further include sending citation information to the ticket management server. In this way, citation data may be gathered for providing real time analytics.
In another example method, an inspector application may be used to search for users (e.g., riders) in a database to determine if a citation should be issued. First, search criteria (e.g., partial names, names, phone number, and/or other unique identification data) may be entered into the inspector application to prompt display of the user's history for previous citations, warnings, and/or bans. Next, the inspector using the inspector application may review the results, if any are returned, and determine if a citation should be issued to the user. If it is determined that a citation should be issued the citation generation process may be implemented via the inspector application.
At 6302 the method includes downloading, encrypting, and storing in a database, ticket information in a mobile device after completing a ticket purchase process. This process may also be implemented at application refresh points such as a “pull-to-download” point and/or during a login process. The ticket information may include ticket meta-data.
At 6304 the method includes updating the server with the date/time, latitude, longitude, and/or application id associated with the device. It will be appreciated that step 6304 may be implemented after the ticket information has been fully downloaded.
The method includes at 6402 downloading a mobile ticketing application from a ticket management server, the mobile ticketing application including a graphical data sheet, ticket dictionary, and ticket strings, the graphical data sheet including a plurality of rendered graphical objects corresponding to a plurality of different tickets. In this way, graphical data which may correspond to a plurality of ticket types may be downloaded during installation of a rider application. As a result, the rider application has the information available to render a ticket without an extensive amount of additional data transfer between the mobile computing device and the ticket management server. As a result, the efficiency of subsequent communication with the server may be increased. Additionally, it will be appreciated that at least two of the graphical objects included in the plurality of graphical objects are associated with different types of tickets. Further in one example, the ticket purchase process includes exchange of payment data with the ticket management server. Further in one example, the ticket dictionary determines the position of graphical objects included in the graphical data sheet and the graphical data sheet includes animation sequences. In one example, the ticket string includes instructions for animating graphical elements in the graphical data sheet. The instructions for animation may include dynamic instructions related to velocity of an object, fading of an object, path of an object, rotation of a object, brightness of an object, resizing an object, geometry of an object, object color, etc. In another example, the ticket strings includes color data, transparency data, and scale data related to the graphical elements in the graphical data sheet.
At 6404 the method includes receiving ticket rendering instructions from the ticket management server in response to completion of a ticket purchase process via the mobile computing device. The ticket rendering instructions may include data, command, etc., for selecting graphical objects in the graphical data sheet.
Next at 6406 the method includes rendering for display an active ticket on the mobile computing device with data stored on the mobile computing device based on the ticket rendering instructions, the graphical data sheet, ticket dictionary, and ticket strings in response to an activation input command. It will be appreciated that the activation input command may be a command initiated by a user via interaction with the mobile computing device. For example, the user may select an “activate” or “use” button on a touch interface. Additionally, rendering an active ticket for display may include selecting one or more graphical objects for display from the plurality of rendered graphical objects, in one example.
At the ticket management server the method includes at 6408 automatically sending updates of one or more of the graphical data sheet, ticket dictionary data, and ticket string at predetermined time intervals to the mobile computing device independent of ticket purchase processes implemented by the mobile computing device. In one example, automatically sending updates includes adding, overwriting, or deleting data in the graphical data sheet, ticket dictionary, or ticket strings. In this way the ticketing graphics may be updated regardless of ticket purchase or activation. As a result, the reliability of the ticketing graphics updates is increased. Further in one example, rendering the active ticket includes selecting one or more graphical objects for display from the plurality of rendered graphical objects. Still further in another example, the selected graphical objects are layered for display.
At 6502 the method includes gathering ticket user data via a ticket management server in communication with a plurality of mobile computing devices executing a mobile ticketing application. At 6504 the method includes generating analytical ticket data based on the ticket use data, the analytical ticket data including one or more of total ticket sales, total number of riders, peak ridership, base ridership, average ridership, ridership percentage trends, number of approved tickets, most activated ticket type, frequency of ticket activation, time of activated tickets, new system users, or location of activated ticket. Next at 6506 the method includes at the ticket management server, displaying the analytical ticket data in an analytic dashboard. In one example, the ticket user data is gathered in real time. Further in one example, the analytical ticket data is applied to a map. In such an example the map may be a heat map. Still further in one example, the analytical ticket data is further gathered from a plurality of ticket inspection mobile computing devices. In one example, the analytic data may be manipulated in real-time using on screen interactive tools such as time sliders, data picker, and metadata drop down. Additionally in one example, the analytic data applied to the map may be manipulated in real-time to show different rider and ticket types over a chosen period of time.
Further in one example, the analytic data, after chosen time frames and meta factorings, may be exported in multiple data formats. Still further in one example, the analytic data may be rendered in different styles of graph chosen by the user. In another example, the analytic data may be viewed in selected time/date ranges such as a week over week, month over month, year over year view, etc. Further in one example, the analytic data presented on a map may show points of interest and nearest transit stop data. In another example, the analytic data on a map may be animated through chosen date range to show user activity over time visually.
Further in one example, the analytic data may be sorted based on column value. In another example, the analytic data may be filtered by on-screen selections. Still further in another example, the analytic data may be drilled down into by interacting with the display. In this way, the analytic data may be viewed an manipulated in a variety of ways. Enabling a user of the analytic dashboard to easily comprehend the analytic data as well as quickly and efficiently manipulate the analytic data according to their predilection.
The mobile computing device executing the inspector application may receive ticket information via a camera, a laser scan, near field communication (NFC), Bluetooth, airdrop, etc. Specifically, in one example the device executing the inspector application may be configured to input the ticket information via camera, NFC, and Bluetooth. In this way, a variety of techniques may be used to gather ticket information, thereby expanding the device's capabilities. The location and time of the mobile device executing the inspector application may be determined and stored or otherwise recorded when the ticket information is received. Thus, ticket information (e.g., ticket tokens) may be scanned or otherwise uploaded into the device executing the inspector application. After the inspector application receives the ticket information (e.g., token data) the application may decrypt and parse the ticket information (e.g., token data) and may send this information to the ticket management server for validation. The information may be sent to the server in real-time, in one example. Additionally, the time and location data of the scan or information upload may also be sent to the ticket management server. In this way, ticket analytics may be gathered via the transit ticket system. Additionally or alternatively, the inspector application may locally determine token validity.
After the token data is displayed, the mobile computing device may synchronize scan data or other uploaded ticket information with the ticket management server. In one example, this synchronization may be implemented in real time. Additionally, the inspector application may support local and server-side blacklisting to flag accounts, tokens, and/or other data points specific to a token. Additionally, a visual element 6702 indicates the status of the token check. In one example, the inspector application is configured to constantly refresh. However, when the inspector application looses network connectivity, a refresh request, and/or other data slated to be sent to the server may be stored locally.
In an example method for inspecting a ticket (e.g., checking a tickets validity) first a token stored in a rider application may be scanned or otherwise uploaded (e.g., NFC, Bluetooth, picture upload) to an inspector application. Next, the token may be synced to the backend via the inspector application. Syncing to the backend may include sending token information to a ticket management server. Next, the validity of the token information may be checked via the ticket management server and/or the inspector application. Next, validity information corresponding to the ticket may be presented via the inspector application. It will be appreciated that the ticket management server may send validity data to the inspector application prior to presentation of the validity information. Next, the token and other data uploaded to the inspector application are stored in the inspector's device via the inspector application. In one example, the inspector application may access the stored data via a graphical user interface. The stored data presented in the graphical user interface may include the type of token that was scanned (e.g., adult/youth, 2-hour/1 day, etc.), the token′ status (e.g., valid/invalid), token scan time, token scan location, etc. It will be appreciated that the token data displayed via the inspector application may include alphanumeric symbols, images, graphics, animation, etc.
Further in one example, token lookup via the inspector application may be supported through use of the token purchaser's account, such as mobile number, driver's license number, email address, and/or other identification information. Information provided by the account owner may be displayed in the inspector application when looking up a token to allow positive identification of the person presenting the token vs. the token owner.
In one example, the inspector application may be configured to display available tokens for a giver user in response to receiving token information. The token information may include a phone number, barcode data, or other identification information uploaded via NFC, Bluetooth, manual input, a camera, a laser scan, etc.). Additionally, the uploading action executed via the inspector application may be logged by the ticket management server (e.g., on the backend).
Still further in one example, the inspector application may be made aware of the graphical layout, animation, color, etc., of valid tickets. In this way, another layer of ticket verification is provided in the ticketing system.
In the process flow 6900 shown in
At 6906 tickets may be recalled via the TOMS. This feature allows a user (e.g., rider) to “remove” tickets from a device and make them available for download again. Recalling a ticket may be initiated and completed by the user (e.g., rider) without the need for agency assistance, if desired. Recalling the tickets may include the following steps, first a user (e.g., rider) logs into their account via a network (e.g., the Internet) connected to the ticket management server and navigates to a “my tickets” interface. Next the user selects a “recall my unused tickets” button. The mobile ticketing application (e.g., rider application) associated with the recalled tickets then becomes “locked”. The recalled ticket may become available again after a predetermined period of time (e.g., 24 hours, 48 hours, 72 hours, etc.). Once the tickets are available for download the user can open the mobile ticketing application via a device and select a “pull to refresh” button to download the tickets. It will be appreciated that the ticket may be downloaded to another device executing the mobile ticketing application. In one example, if the user has a device with unused tickets they can bypass the aforementioned waiting period and immediately make the tickets available on the server by selecting a “pull to refresh” button on that device, in one example. The device will then be locked. The locked device may be unlocked through user selection of an unlock button. The unlock button may be presented in the same graphical interface as the pull to refresh button. After the device is unlocked the tickets are available for download. Again, the user may log into the mobile ticketing application and select a “pull to refresh button” to download the recalled tickets. The user may access their account via a network browsing application to recall, replace, and/or transfer unused tickets, in one example. The network browsing application may access the user's account via the ticket management server.
At 6908 the user may obtain a new phone or other suitable mobile computing device. It the user has access to their old device, the user may use the recall method at 6906 for ticket transfer. However, if the user does not have access to their old phone the process flow proceeds to 6910. In one example, if the old device was lost the user may contact the ticket issuer if they have existing tickets of value (e.g., unused tickets, time left).
At 6910 the user installs a new mobile ticketing application on their new device. The application may have a new unique identification number. Next at 6912 the process flow includes retrieving missing tickets. The missing ticket may be retrieved via the user selecting the “pull to refresh” button on the mobile ticketing application. In response to selection of the “pull to refresh” button it is determined if the user has any unused tickets. If the user does have unused tickets, the process flow proceeds to 6906 where the ticket recalling steps are implemented. However, if the user does not have any unused tickets a courtesy ticket may be issued at 6914. The courtesy ticket may be issued by the TOMS. The user may contact an administrator in the TOMS to request a courtesy ticket, in one example. In one example, the user may send a courtesy ticket request to the TOMS through a refund interface. In one example, if the user has an active ticket that still has value (e.g., a 30 day ticket, a 1 year ticket) the user may request a courtesy ticket. However, if the courtesy ticket request is denied the user may purchase a ticket at 6916.
As shown, a user may work in a tapped mode and an untapped mode. The tapped mode may show an intended graphical configuration of the ticket when the ticket is selected for use via the mobile ticketing application. On the other hand, the untapped mode shows an intended graphical configuration of the ticket when the ticket has not been selected for use. In this way, a designer can quickly view different states of the ticket. It will be appreciated that the ticket designer may store and retrieve data from a rules engine, described in greater detail herein with regard to
Additionally, the mobile ticketing application may communicate with the rules engine to request metadata in response to application launch, application wake-up, and/or application pause. In response to a metadata request the rules engine sends metadata to the mobile ticketing application. The device state may be updated to the current ticket in response to receiving the metadata. Additionally, a TOMS scheduler may send a ticketing schedule to the rules engine. The ticketing schedule may define the time period when the graphical data sheets (e.g., spritesheets) and ticket dictionary are to be used. In this way, the ticket scheduler coordinates data with the rules engine regarding when to release a new ticket design. Furthermore, the mobile device may periodically check the rules engine to see if ticket data has been updated via the ticket designer.
It will be appreciated that each of the computing devices described above with regard to
It is to be understood that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense, because numerous variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. As such, various acts illustrated may be performed in the sequence illustrated, in other sequences, in parallel, or in some cases omitted. Likewise, the order of the above-described processes may be changed.
The subject matter of the present disclosure includes all novel and non-obvious combinations and sub-combinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.
Claims
1. A transit ticket system comprising:
- a mobile computing device configured to (i) download a mobile ticketing application from a ticket management server, the mobile ticketing application including a graphical data sheet, a ticket dictionary, and ticket strings, (ii) receive ticket rendering instructions from the ticket management server in response to completion of a ticket purchase process via the mobile computing device, and (iii) render for display an active ticket on the mobile computing device with data stored in the mobile computing device based on the ticket rendering instructions, the graphical data sheet, ticket dictionary, and ticket strings in response to an activation input command.
2. The transit ticket system of claim 1, where the graphical data sheet includes a plurality of rendered graphical objects.
3. The transit ticket system of claim 2, where at least two of the graphical objects are associated with different types of tickets.
4. The transit ticket system of claim 2, where rendering the active ticket includes selecting one or more graphical objects for display from the plurality of rendered graphical objects.
5. The transit ticket system of claim 1, where the ticket management server is configured to automatically send updates of one or more of the graphical data sheet, ticket dictionary data, and ticket string at predetermined time intervals to the mobile computing device independent of ticket purchase processes implemented by the mobile computing device.
6. The transit ticket system of claim 5, where the update includes adding, overwriting, or deleting data in the graphical data sheet, ticket dictionary, or ticket strings.
7. The transit ticket system of claim 1, where the ticket purchase process includes exchange of payment data with the ticket management server.
8. The transit ticket system of claim 1, where the ticket string includes instructions for animating graphical elements in the graphical data sheet.
9. The transit ticket system of claim 1, where the ticket strings includes color data, transparency data, and scale data related to the graphical elements in the graphical data sheet.
10. The transit ticket system of claim 1, where the graphical data sheet includes animated graphical objects.
11. A method for managing a transit ticket system, comprising:
- at a mobile computing device, downloading a mobile ticketing application from a ticket management server, the mobile ticketing application including a graphical data sheet, ticket dictionary, and ticket strings, the graphical data sheet including a plurality of rendered graphical objects corresponding to a plurality of different tickets;
- receiving ticket rendering instructions from the ticket management server in response to completion of a ticket purchase process via the mobile computing device; and
- rendering for display an active ticket on the mobile computing device with data stored on the mobile computing device based on the ticket rendering instructions, the graphical data sheet, ticket dictionary, and ticket strings in response to an activation input command.
12. The method of claim 11, further comprising at the ticket management server, automatically sending updates of one or more of the graphical data sheet, ticket dictionary data, and ticket string at predetermined time intervals to the mobile computing device independent of ticket purchase processes implemented by the mobile computing device.
13. The method of claim 12, where automatically sending updates includes adding, overwriting, or deleting data in the graphical data sheet, ticket dictionary, or ticket strings.
14. The method of claim 11, where rendering the active ticket includes selecting one or more graphical objects for display from the plurality of rendered graphical objects.
15. The method of claim 14, where the selected graphical objects are layered for display.
16. A method for gathering analytic information from a transit ticket system, comprising:
- gathering ticket use data via a ticket management server in communication with a plurality of mobile computing devices executing a mobile ticketing application;
- at the ticket management server, generating analytical ticket data based on the ticket use data, the analytical ticket data including one or more of total ticket sales, total number of riders, peak ridership, base ridership, average ridership, ridership percentage trends, number of approved tickets, most activated ticket type, frequency of ticket activation, time of activated tickets, new system users, or location of activated ticket; and
- at the ticket management server, displaying the analytical ticket data in an analytic dashboard.
17. The method of claim 16, where the ticket user data is gathered in real time.
18. The method of claim 16, where the analytical ticket data is applied to a map.
19. The method of claim 18, where the map is a heat map.
20. The method of claim 16, where the ticket use data is further gathered from a plurality of ticket inspector applications, each inspector application executed on a different mobile computing device.
Type: Application
Filed: Dec 20, 2017
Publication Date: Apr 26, 2018
Inventors: Nathaniel Parker (Portland, OR), Michael L. Gray (Portland, OR), Matthew S. Rotter (Portland, OR), Isaac Elliott (Vancouver, WA), Zachary Babb (Portland, OR), Kurt Griffith (Portland, OR), Alex Peter (Portland, OR), Scott Schaus (Portland, OR)
Application Number: 15/849,510
