SYSTEM AND METHOD FOR CONFIGURABLE DEPLOYMENT OF TRANSIT AGENCY CONTENT

Abstract

A system for managing incidents for a transit agency is disclosed, comprising an incident manager, configured to enable establishment and storage of one or more user profiles for one or more users, each profile indicating characteristics of transit incidents the user wishes to be notified of, create a transit incident having one or more incident characteristics, determine which users are to be notified of the transit incident based on their user profiles, and provide one or more notifications to the users that are to be notified.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No. 61/623,991 filed Apr. 13, 2012, the contents of which are herein expressly incorporated by reference.

COPYRIGHT NOTICE

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

BACKGROUND

Although many tools exist for building websites, tools for quickly building and maintaining transit websites—and the data and functionality required to make such websites useful for agencies' riders—do not exist. Accordingly the following invention is directed at addressing some of those current limitations.

SUMMARY OF THE INVENTION

In one aspect there is a system for managing incidents for a transit agency comprising an incident manager, configured to enable establishment and storage of one or more user profiles for one or more users, each user profile indicating characteristics of transit incidents the user wishes to be notified of, create a transit incident having one or more incident characteristics, determine which users are to be notified of the transit incident based on their user profiles, and provide one or more notifications to the users that are to be notified.

The incident manager may be further configured to receive information to create a transit incident having one or more incident characteristics, and such information may be provided by an administrator via one or more user interface elements. The incident manager may be further configured to allow characterizing of the transit incident, by the administrator, according to pre-defined tags.

The notification may be auto-generated from the pre-defined tags.

The system may further comprise one or more transit data servers configured to provide transit functionality, via one or more functionality modules, for the transit agency, and communicate information to create a transit incident with the incident manager.

The one or more transit data servers may be users and have user profiles. Each of the one or more users may have a user type and mediums preference and the notifications may be different for each user type and sent according to the users' mediums preferences.

In another aspect there is a method for managing incidents for a transit agency, the transit agency having an incident manager and one or more transit data servers providing transit functionality to the transit agency, the method comprising enabling establishment and storage of one or more user profiles for one or more users, each user profile indicating characteristics of transit incidents the user wishes to be notified of, creating a transit incident having one or more incident characteristics, determining which users are to be notified of the transit incident based on their user profiles, and providing one or more notifications to the users that are to be notified.

The method may further comprise receiving information to create a transit incident having one or more incident characteristics.

The receiving may be from an administrator via one or more user interface elements.

The method may further comprise characterizing, by the administrator, the transit incident according to pre-defined tags. The notifications may be auto-generated from the pre-defined tags.

The receiving may be from a transit data server.

The one or more transit data servers may be users and have user profiles.

Each of the one or more users may have a user type and mediums preference and the notifications may be different for each user type and sent according to the users' mediums preferences.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is illustrated in the figures of the accompanying drawings which are meant to be exemplary and not limiting, in which like references are intended to refer to like or corresponding parts, and in which:

FIG. 1 is a diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention;

FIG. 2 is a further diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention;

FIG. 3 is a screenshot for a configurable transit agency content management system according to a non-limiting embodiment of the present invention;

FIG. 4 is a screenshot for a configurable transit agency content management system according to a non-limiting embodiment of the present invention;

FIG. 5 is a screenshot for a configurable transit agency content management system according to a non-limiting embodiment of the present invention;

FIG. 6 is a diagram of a system for configurable and automated transit agency content creation and dissemination according to a non-limiting embodiment of the present invention;

FIG. 7 is a diagram of a method of creating incidents according to a non-limiting embodiment of the present invention;

FIGS. 8-12 are screenshots for incident creation, review and dissemination according to a non-limiting embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention.

Transit agency 26 may have one or more data sources 10 that are controlled by the agency and one or more external data sources 12 (such as weather data, general traffic data, GIS data, and the like, that may not be controlled by agency 10). Transit agency 26 further may have one or more vehicles 16 and mobile devices 18 (that may be tablets, phones, etc and may be used by drivers or located on vehicles, etc). Transit agency 26 may also have one or more computing devices 14 that may be used by schedulers, content handlers, supervisors, maintenance staff, and other employees and contractors of the agency.

Transit agency 26 may further have transit agency data sinks or content sinks, that may include user devices 30a/30b and may also include computing devices 14, vehicles 16 and mobile devices 18. Such transit data sinks may receive content from agency 26, such as via websites, social media, SMS messages and the like as described herein.

Transit agency 26 may further have one or more transit data databases 22 (TDD) and transit data servers 24 (TDS) that may interact with TDD 22 to read and write data to perform functionality required by agency 26, and to be provided to transit data sinks Transit data sources and sinks may interact with TDD 22 directly or through one or more TDS 24. Exemplary TDDs 22 may include route databases, asset databases, schedule adherence databases, maintenance databases, user profiles databases, alert category databases, and trips databases. Of course each of these may have many datasets and each may be combined with one another as needed or desired, for performance issues for example.

FIG. 2 is a further diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention.

TDS 24 may have one or more functionality modules 100. Each module may provide different functionality that one or more transit data sinks may need, such as trip planning, service advisories, elevator status (for wheelchair access to transit locations), system maps, client registration and alert configuration, alerts and notification generator and publisher (for example for agency employees such as schedulers or content managers), demand response functionality (such as booking trips, paying for trips, and the like).

Each module may have an identifier 102 one or more UI components 104, processing/TDD integration components 106 (PTDDIC), and customization parameters 108. Identifier may simply identify module 100.

UI components may be the way transit data sinks will see the functionality (size, look, feel, what data is displayed, and through what techniques such as screen shots for web pages, text for SMS messages, the social media view, etc). UI components may be different for each transit data sink that may use such functionality (such as based on screen size, audience, etc, and based on specified parameters).

PTDDIC 106 may allow TDS 24 to interact with TDD 22 to access the data (such as transit datasets) required for the functionality and may further provide the data processing and business logic to carry out the functionality of module 100 (such as accepting inputs from users or the agency to describe the functionality or data requested, building queries to TDD 22, getting the data out of TDD 22, and processing and returning the results to be displayed). For example, module 100 may be a service advisory alert. Data source 10 may provide data to TDD 22 to indicate that bus stop 492A is not operable due to construction and has been moved to a temporary stop 492T. Service advisory module 100 may then query TDD 22 to see what stops, if any, are currently affected. Receiving back “492A has been moved to 492T”, service advisory module 100 may determine which routes may be affected (possibly via interacting again with TDD 22), determine what transit data sinks may be affected, which forms of publishing may be required (such as websites, social media, SMS, etc—where such may be based, for example, on how major the service disruption is, as may be determined by module 100), and which specific users have requested to receive service advisories. Various UI components 104 may then be invoked to publish the service advisory as required.

It is to be understood that modules 100 may be provided pre-programmed to operate when the proper transit database and/or dataset is available to the module requiring it. As such, functionality and modules may be considered plug and play—not requiring major technology development to implement new features for transit data sinks.

Customization parameters may allow a user to specify exactly what data can be served to riders or other transit data sinks, and how that should look and operate.

It should be noted that various modules 100 may be present at agency 26 and may be usable if the proper data is obtained from data sources 10 (and/or stored in TDD 22), as described herein. Further, performance or accuracy of modules 100 may be increased as more data is obtained. For example, if no real-time data is ingested by TDD 22, then a module 100 providing real-time schedule information cannot be used. As such, screenshot 300, and operator module 100, may begin by querying TDD 22 to determine what modules 100 may be offered based on data sources 10 that are available (or possibly were available).

Operator tool module 100 may allow an operator at agency 26 to handle transit data and functionality, such as selectively publishing content, making functionality available to transit data sinks, and the like. Portions of operator tool module 100 may be substantially as shown in FIGS. 3-5.

FIG. 3 is a screenshot 300 for a configurable transit agency content management system according to a non-limiting embodiment of the present invention, which may be described as a webpage design module, or a part thereof.

In FIG. 3, a user of module 100 may be able to select which modules 100 to expose on a web site (external or intranet) of agency 26, via module selector 302. Preview portion 304 may provide a preview of the particular page of the website, as determined by the modules selected in module selector 302, parameters specified (as described herein), by dragging and dropping UI components of the various modules (not shown, but substantially as dragging and dropping is known in the art).

Module selector 302 may include all modules 100 that may be available in general, or may include all modules 100 that may be available to agency 26 based on, for example, the data sources that provide data or datasets to one or more TDD 22. When more data sources 10/12 are plugged into TDD 22 (such as via a “plug and play” type of arrangement), or more TDD 22 become accessible, more functionality modules 100 may become available—resulting in more icons in module selector 302, or more icons being selectable. Such determinations of which functionality can be offered may be made in real-time upon accessing screenshot 300 (such as by querying TDD 22 on the back end before showing screenshot 300).

FIG. 4 is a screenshot 400 for a configurable transit agency content management system according to a non-limiting embodiment of the present invention.

In FIG. 4, further configuration of a particular module may be possible. Module ID 102 may be shown in module name field 402, with configurations for such module shown and selected in configurations screen 404. A user of this screenshot (which may be a transit operator, for example) can select which user inputs to allow (route selection textbox being selected in FIG. 4), which outputs will be provided on the UI component (daily performance stats not being shown), parameters to specify (such as whether to include fixed routes and/or demand response routes when searching for real-time schedule information), and aspects of font and other parameters. Of course the parameters and configurations shown are exemplary only. Different parameters may be possible for the module 100 shown, and for other modules, as required, and between different transit data sinks. Such parameters may affect the specific data from TDD 22 that may be required or accessible by transit data sinks (such as riders). Some parameters may not be available too, if the required data is not present in TDD 22.

Screenshot 400 may be used to alter the currently displayed UI component for a given functionality module 100, which may result in changes to the web page in screenshot 300 (if such module 100 was part of the web page). It is thus to be understood that users can alter parameters (inputs, outputs, fonts, etc) and view all effects such may have.

FIG. 5 is a screenshot 500 for a configurable transit agency content management system according to a non-limiting embodiment of the present invention. Screenshot 500 may then allow a user to add content (where ‘content’ may be considered transit content), or publish content, to one or more sources for consumption by transit data sinks, and may assist in generating the desired content based on data from data sources 10/12 (as described herein). Screenshots may also be considered ‘dashboards’, providing main landing places providing an overview of particular features or functionality.

A user of screenshot 500 may be an operator or content administrator for agency 26. The functionality depicted and described may form part of operator module 100.

The user may specify what type of transit content they wish to publish in content specifier 502 and may then be allowed to define some parameters about that content type in 504 (such as alert priority, picture size, web page expiry date/time, and the like). Screenshot 500 may then provide UI features to allow the user to develop or create the content. In the present example, an alert is selected in 502, causing alert categorization 510 and alert preview 508 to display on screenshot 500. The user may then specify elements that define the alert; such defining may allow alert preview 508 to display auto-generated content, draft content, that alert module 100 (and in particular PTDDIC 106) provides to operator module 100 for display in a content preview portion of screenshot 500. A user may amend the draft content and/or approve or accept it for publishing.

Using content mediums 512 and sink target 514 a user may select which media to publish the content to and which transit sinks should receive the content, respectively. Such selections may dictate statistics about who will, or may, receive or view the created transit content.

FIG. 6 is a diagram of a system for configurable and automated transit agency content creation and dissemination according to a non-limiting embodiment of the present invention.

Incident manager 24a may be responsible for the creation, ingestion, and dissemination of incidents. Incident manager 24a may be configured to allow the creation of incidents by one or more operators of transit system 20, which may be accessed via, or be part of, computing devices 14, as described herein. Incident manager 24 may be configured to ingest incidents from one or more of asset manager functionality 24, trip planning functionality 24, traveler information 24, operations functionality 24 or other transit data servers 24 that may be part of transit system 20.

Incidents, or transit incidents, may include any occurrence having relevance for transit agency 26, such as weather occurrences, car accidents, power outages, buses finishing their runs, drivers changing shifts, supervisors approving new routes or short-turns, and the like. Occurrences or events may only become incidents if they meet one or more thresholds for importance, as described herein.

Incident manager 24a and other transit data servers 24 may cause new incidents to be created, by allowing a user to intentionally create an incident (which may be a user initiated trigger) or by transit data servers 24 creating an incident in response to triggers occurring in the transit data servers 24. Below is a list of exemplary triggers that may lead to an incident being created by various transit data servers 24:

TABLE 1
Exemplary Triggers
Functionality/
Transit
Data Server	Trigger	Description
Asset Manager	Maintenance person	An incident may be created to
Functionality	indicates bus #139 is	indicate that bus #139 cannot be
	out of service.	driven and/or should be
		replaced on its route (such route
		either being in progress of
		scheduled for later).
Incident	Rider sends email	An administrator may
Manager	complaint or “tweets”	determine the email or
	about transit agency	communication to be an
	26.	incident and enter it via incident
		manager 24a.
Traveler	A rider calls the call	A call center agent, which may
Information/	center, or submits via	be a different or the same
Call Center	their mobile device, to	administrator, enters the
	report poor conditions	information in call center
	on board a bus.	software (transit data server 24),
		which may end up in incident
		manager 24a. The mobile
		device may communicate with
		transit data server 24, which
		may result in an incident in
		incident manager 24a.
Operations	A transit supervisor	The supervisor may enter the
Functionality	has witnessed a traffic	information via a Road
	accident.	Supervisor transit data server,
		which may result in an incident
		in incident manager 24a.

Incident manager 24a may, in creating, ingesting, amending and resolving incidents, create incident data structures (not shown) to store data relating to an incident. Incident data structures may include but are not limited to the type of incident (e.g., service disruption, route diversion, planned construction), a description (e.g., bus 123 diverting around King St. due to a watermain break), the priority (e.g., low, medium, high), the status (e.g., pending confirmation, awaiting resolution, resolved), the affected part of the schedule (e.g., bus stops, lines, pattern, blocks), the effective date and time (e.g., Weekday mornings from 6:00 am to 11:00 am, or until resolved), the creator of the incident, the date and time the incident was created, and in what transit data server the incident was created.

Transit data servers 24 provide the functionality required of transit system 20, each may provide one or more aspects of such functionality. Transit data servers 24 may communicate with incident manager 24a, as described herein, for example to communicate incidents.

FIG. 7 is a diagram of method 700 of creating incidents according to a non-limiting embodiment of the present invention.

Method 700 begins at 702 where an event or incident occurs in the real-world of transit agency 26. At 702 the event could be anything that has any relevance for transit agency 26, such as weather occurrences, car accidents, power outages, buses finishing their runs, drivers changing shifts, supervisors approving new routes or short-turns, and the like.

Method 700 then continues to 704 where a query is made whether another transit data server is capturing the event. This may essentially mean that the event will implicate one or more transit data servers 24, and likely that such one or more transit data servers 24 will determine whether the event is an incident (further in method 700). Whether another transit data server 24 is capturing the event may depend on many factors, such as:

• • (a) What transit data servers (or functionality) transit agency 26 has enabled. If real-time bus stop updates are not part of transit data servers 24 then a bus being late is not an event, for example.
  • (b) How severe the event is, where such severity may be determined by any of transit data server 24, incident manager 24a, an operator, and the like. A bus hitting a curb but continuing on its route would be less severe than a bus hitting a car and having to wait for the accident to be handled.

If 704 is affirmative method 700 continues to 706 where the functionality of transit data server 24 is used. As can be imagined, 706 can encompass a very broad range of functionality and transit data servers. Essentially at 706 the particular workflow, use, interaction with, or transaction contemplated by one or more users or one or more transit data servers 24 may be largely completed, or adequately completed to allow method 700 to continue, as described herein. A few examples may include:

• • (a) A supervisor determines that a bus needs to short-turn instead of completing the entirety of the route it was to be driving. Using a scheduling functionality, for example in Transit Planning Functionality, the bus' route is updated, its sign is updated, and any affected electronic stop signs are updated. For the Trip Planning Functionality transit data server 24 the change is largely complete.
  • (b) A driver having a particular license type calls in sick and there is no replacement driver. The scheduler may, for example via Operations Functionality 24, remove the driver from the list of available drivers. Once the driver, and possibly the specialized vehicle, are removed, the change may be largely complete.

Returning to method 700, at 708 a query is made whether the event is an incident that needs to be provided to incident manager 24a. This determination may be based on many factors, which may be different and configurable between transit agencies 26 and transit data servers 24, and may also be subjectively determined by a user/operator. Exemplary factors may include:

• • (a) How significant is the impact of the event? How widespread is the impact?
  • (b) How long will the impact last?
  • (c) Are riders likely to be affected? Transit agency operators?
  • (d) Will stakeholders (operators, drivers, riders, schedulers, etc) benefit from being made aware of the event?
  • (e) Have any stakeholders signed up to receive alerts relating to this type of event?

In one embodiment transit data servers 24 may make the determination, either automatically (based on logic therein) or via an operator of the functionality making a determination. In another embodiment the query may be made by incident manager 24a, meaning that 708 may occur after 710, for example.

If the event is determined to be an incident at 708 then method 700 continues at 710 to create and communicate an incident data structure (as described herein) to incident manager 24a.

Creating the data structure may be substantially as known in the art, assembling various pieces of data and storing them together. The incident data structure definition in each transit data server 24 may be the same or different, and may indicate which fields of the data structure are required or optional. Such requirements may vary between transit data servers 24 or may be the same and may be set by incident manager 24a. It may be preferable for as many fields as possible by inserted into the data structure so that incident manager 24a has a nearly-complete incident upon receipt.

At 712 incident manager 24a may ingest the incident data structure and place it in its queue of incidents. This may put the incident in line to be reviewed, amended or completed. The queue may comprise one or more incidents from one or more transit data servers 24, including incidents being created within incident manager 24a.

At 714 the incident is reviewed and possibly amended. The review may be automatic, such as by logic within incident manager 24a, or may be done by a user of incident manager 24a (such as a administrator) via one or more screens displayed on computing device 14, such as those shown and described herein. In one embodiment incidents may be characterized using one or more pre-defined tags, such as shown in 510.

At 720 the incident is created in incident manager 24a. Prior to this creation, the event may only be a potential incident, and for example not to be distributed or disseminated to content sinks. By 720, amendments to the data stored in the incident data structure may be complete (to the extent required) and accurate (to the extent required and as may have been confirmed by an administrator). Incident manager 24a may amend or enhance the incident at 720, for example using transit data in TDD 22 and accessed via functionality modules 100 of transit data servers 24. In one example, an incident may relate to a bus stop on a particular route. Via transit data servers 24, incident manager 24a can determine the other stops on the route, and mark them as being potentially affected. Further, if the stop is part of more than one route, then other routes (and their stops) may also be marked as being affected. Without transit data servers 24 this may not be possible.

At 722 content sinks, that are to receive notification of the incident, are determined. As described herein, stakeholders may create profiles and “sign up” to receive various content (including alerts, notifications and incidents), where such content may be described using various fields or attributes. Stakeholders' sign ups may be for general messaging (weather, system outages, and the like) or more specific (particular routes, buses, time periods and the like) or other qualities of the incident. When the incident is described and characterized, as described herein, various fields and information that are part of incident data structure may be allow content sinks to be identified—for example by noting which incident fields are part of the content fields that are part of the sink's alerts.

Various content sinks may receive different information about the same incident, for example based on the preferences in their profiles (specifying they want all details or only a few), what type of user stakeholder they are (an executive of transit agency 26 may be entitled to view information relating to remediation, whereas a rider may not), what device the sink is using (PCs may receive more information than bus-stop signs or mobile devices), and the like.

Transit data servers 24 may also be content sinks. For example, an incident may have been created in asset manager functionality 24 (such bus #1234 is undergoing unexpected maintenance), and trip planning functionality 24 may be a content sink for that incident so that it does not insert bus #1234 in a schedule until it is fixed.

At 724, follow-up is performed, if required. This may involve updating the incident, and its data structure, and subsequently updating transit data server 24 that captured the event initially. Although many follow-up options are considered, a few notable examples include:

• • (a) If a rider tweet became an incident, a tweet (or other form of communication) from transit agency 26 may identify that the incident has been noted, or that the incident has been resolved.
  • (b) If a traffic light was out, leading to an incident, but is fixed, then an update may be created. Of course this may lead to another communication to content sinks.

Returning to 708, if the event is not an incident then method 700 ends at 718. This could be substantially similar to the situation if incident manager 24a did not exist and transit data servers 24 simply operated on their own.

Returning to 704, if no transit data server 24 is capturing the event then method 700 continues to 716 where a query is made whether the incident is to be captured in incident manager 24a. Similar assessments may be made at 716 to 704. Alternative ways for the event to be captured may exist at 716, such as phone calls, weather details, events that an administrator (or other stakeholders) may have heard about, and the like. These may then be added as incidents by the administrator, such as via functionality described herein and screenshots herein. While being added in incident manager 24a, transit data servers 24 may also be used to create or specify the incident. By way of example, an administrator may learn that Main St, heading north, is closed, and may add that to a new incident. Incident manager 24a may take the location (address, GPS coordinate, and the like), along with “road closure” and query transit data server 24 providing routing functionality to determine and provide the route numbers that are affected. The administrator may review and accept such routes.

At 716 if the event is not an incident then method 718 ends at 718. Otherwise method 700 continues at 720, then 722 and possibly 724, which all may be substantially as described herein.

The above method 700 was described largely in relation to creation of the incident. It is to be understood however that updating, responding to, and closing incidents may also be part of system 10 and the methods described herein.

FIGS. 8-12 are screenshots 800/900/1000/1100/1200 for incident creation, review and dissemination according to a non-limiting embodiment of the present invention. Such screenshots may be, or comprise, one or more user interface elements that allow a user to interact with system 10, for example to achieve functionality required by transit agency 26.

Screenshot 800 may be a dashboard or landing page for accessing, viewing and initiating functionality of incident manager 24a.

Screenshot 800 may allow a user to search for incidents by inputting text into search box 802 and selecting search button 804. This may perform a full text search of incidents, for example, and return an incident for viewing or other operations.

A user may be able to view one or more incidents in incident display 808. Filter selectors 806 may allow a user to select a filter to apply to the incident queue, such as “view all”, “view live incidents”, “view expired” and “view pending approval”. The “view pending approval” may be the list of events or incidents that either have not had all information entered or have not yet been approved as incidents instead of events, and may be the same or a separate queue from the incidents queue. Different fields from an incident data structure may be displayed, those displayed in 806 are exemplary only.

A user may select an incident from incident display 808 and have the incident details appear in incident details 810. The user may also elect (such as by double-clicking) to jump into a screen (not shown) where they can edit, amend, or update an incident.

From dashboard screen 800 a user may also elect to create a new incident via create incident button 812, where a screen such as screenshot 900 may appear.

In screenshot 900 a user may begin to create an incident, for example by defining the various aspects of the incident, which may be saved into fields of the incident data structure. This may include selecting a type, category and importance level from 902. Exemplary types and categories include:

• • (a) Types: Route Diversion, Service Disruption, Elevator Repair, Service Changes, Bus Repair, and the like.
  • (b) Categories: Bus Stops, Lines, Patterns, Blocks, Geographic Areas, and the like.

Date ranges to capture the duration of the impact may be captured using 906.

Map/route display 904 may allow transit agency 26 routes to be selected as being impacted. Of course other such user interface elements may allow a user to select and specify other aspects of transit agency 26, such as their assets, employees, and the like, to better define the incident.

Selecting the “Next” button 908 (which may also be on screenshots 1000, 1100, and 1200) may allow the user to continue to define the incident in the next screenshot. This may also save the information entered in the various fields into an incident data structure.

In screenshot 1000 the incident may be further defined by entering a description in 1004 (which may be automatically translated between languages), or a predefined message may be selected. In some cases, a description may be all, or substantially all, that may be required or that may be obtained from transit data servers 24 when they provide incident manager 24a a new incident.

In screenshot 1100 various modes of disseminating the incident may be selected and previewed using 1104 and 1106. Different previews may exist based on the different information to be communicated, to different stakeholders for example, as described herein. In another embodiment of screenshot 1100, as the incident is being created and defined the stakeholders that are to receive the information may be determined so that they may be displayed or summarized on screenshot 1100.

In screenshot 1200 a summary of the incident may be seen, with the ability to edit the incident via one or more “Edit” buttons 1206. Each of fields 1202 may be aspects of the incident that have been specified using screenshots, automatically generated by incident manager 24a, or having been received from one or more transit data servers 24. Screenshot 1200 may be used as a starting point for reviewing, amending or following up on an incident, including, for example, when an incident data structure is received for review from transit data servers 24 from 710/712/714. The text entered in description 1004 may be the “Body” field 1204, and may also be part of preview 1106.

It is to be further understood that one of modules 100 may allow users (such as riders) to select which content they wish to receive or be made aware of. In doing so they may “subscribe” to various content types having various parameters or categories. This may also form part of generating the statistics about who will receive or view the created content in 506.

It will be understood that any of the systems or entities that are part of system 10 may have one or more computing devices, such as servers, mobile devices, personal computers and the like, and required network technology, configured to allow the performance of the functionality described herein. Each of such systems or entities, and such computing devices, may have one or more computer-readable storage medium, that may be transitory or non-transitory, that may contain a set of programming instructions that may be executed by the computing devices.

It will be apparent to one of skill in the art that other configurations, hardware etc may be used in any of the foregoing embodiments of the products, methods, and systems of this invention. It will be understood that the specification is illustrative of the present invention and that other embodiments within the spirit and scope of the invention will suggest themselves to those skilled in the art. All references cited herein are incorporated by reference.

Claims

1. A system for managing incidents for a transit agency comprising:

an incident manager, configured to: enable establishment and storage of one or more user profiles for one or more users, each user profile indicating characteristics of transit incidents the user wishes to be notified of; create a transit incident having one or more incident characteristics; determine which users are to be notified of the transit incident based on their user profiles; and provide one or more notifications to the users that are to be notified.

2. The system of claim 1 wherein the incident manager is further configured to receive information to create a transit incident having one or more incident characteristics.

3. The system of claim 2 wherein the receiving further comprises information provided by an administrator via one or more user interface elements.

4. The system of claim 3 wherein the incident manager is further configured to allow characterizing of the transit incident, by the administrator, according to pre-defined tags.

5. The system of claim 4 wherein the notification is auto-generated from the pre-defined tags.

6. The system of claim 2 further comprising one or more transit data servers configured to:

provide transit functionality, via one or more functionality modules, for the transit agency; and

communicate information to create a transit incident with the incident manager.

7. The system of claim 6 wherein the one or more transit data servers are users and have user profiles.

8. The system of claim 1 wherein each of the one or more users has a user type and mediums preference and the notifications are different for each user type and sent according to the users' mediums preferences.

9. A method for managing incidents for a transit agency, the transit agency having an incident manager and one or more transit data servers providing transit functionality to the transit agency, the method comprising:

enabling establishment and storage of one or more user profiles for one or more users, each user profile indicating characteristics of transit incidents the user wishes to be notified of;

creating a transit incident having one or more incident characteristics;

determining which users are to be notified of the transit incident based on their user profiles; and

providing one or more notifications to the users that are to be notified.

10. The method of claim 9 further comprising receiving information to create a transit incident having one or more incident characteristics.

11. The method of claim 10 wherein the receiving is from an administrator via one or more user interface elements.

12. The method of claim 11 further comprising characterizing, by the administrator, the transit incident according to pre-defined tags.

13. The method of claim 12 wherein the notifications are auto-generated from the pre-defined tags.

14. The method of claim 10 wherein the receiving is from a transit data server.

15. The method of claim 14 wherein the one or more transit data servers are users and have user profiles.

16. The method of claim 9 wherein each of the one or more users has a user type and mediums preference and the notifications are different for each user type and sent according to the users' mediums preferences.