SYSTEM AND METHOD FOR SOCIAL-MEDIA GENERATED TRANSIT AGENCY CONTENT

Abstract

There is a system for social media content for a transit agency, the system comprising a social media manager configured to detect a social media event (SME) relevant to the transit agency, add the SME to a queue of SMEs, characterize the SME, and store the characterized SME.

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.

In addition, social media is becoming a more prevalent source of data, feedback, and communication for transit agencies. However, most social media management is performed on an ad-hoc basis by agencies—without tools to help identify, characterize, assess and respond to the social media events.

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 social media content for a transit agency, the system comprising a social media manager configured to detect a social media event (SME) relevant to the transit agency, add the SME to a queue of SMEs, characterize the SME, and store the characterized SME.

The social media manager may further be configured to respond to the SME if the SME is respondable.

The characterizing may comprise applying a transit agency taxonomy.

The social media manager may further be configured to analyze the SMEs, using the transit agency taxonomy, to determine trends relating to the transit agency.

The social media manager may further be configured to display one or more subsets of the queue, depending on a filter applied to the queue based on the taxonomy.

The social media manager may further be configured to elevate the SME to an incident, and transmit the incident to one or more transit agency stakeholders.

In a another aspect there is a method for handling social media content for a transit agency, the method comprising detecting a social media event (SME) relevant to the transit agency, adding the SME to a queue of SMEs, characterizing the SME, and storing the characterized SME.

The method may further comprise responding to the SME if the SME is respondable.

The characterizing comprises applying a transit agency taxonomy.

The method may further comprise analyzing the SMEs, using the transit agency taxonomy, to determine trends relating to the transit agency.

The method may further comprise displaying one or more subsets of the queue, depending on a filter applied to the queue based on the taxonomy.

The method may further comprise elevating the SME to an incident, and the incident being transmitted to one or more transit agency stakeholders.

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 social-media generated transit agency content according to a non-limiting embodiment of the present invention;

FIG. 7 is a diagram of a method for social-media generated transit agency content according to a non-limiting embodiment of the present invention; and

FIGS. 8-9 are screenshots for a social media manager interface, 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 databased, 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 useable 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 social-media generated transit agency content according to a non-limiting embodiment of the present invention.

External data 12 may be social media generated events, data or content (such as SME 50), such as “tweets”, Facebook™ updates, LinkedIn™ events, Instagram™ pictures, and the like. Such SMEs 50 may be created by any stakeholder of transit agency 26.

As used herein, stakeholders may be operators, drivers, riders, schedulers, or any party that is affected by transit agency 26.

Social media manager 24a is an exemplary transit data server 24 that is configured to help an operator obtain, monitor, characterize, and respond to SMEs. Social media manager 24a may perform some or all of the following functionality:

• • (a) Locating SMEs: Searching, observing or monitoring various social media sites, technologies and users/accounts to determine when transit agency 26 (or anything related thereto, such as routes, buses, employees and the like) is mentioned, creating, or otherwise involved in SMEs. SMEs 50 may be pushed to transit agency 26 (such as by using one or more hashtags) or pulled (such as by monitoring “tweets” for keywords).
  • (b) Storing SMEs: Enabling SMEs to be ingested and stored by TDD 22.
  • (c) Viewing: Providing a list of all SMEs from (a) above, allowing it to be filtered and viewed in many ways.
  • (d) Characterizing: Allowing a user to characterize the SME, such as applying tags or descriptors and the like, as described herein. In particular, tying SMEs to transit data (bus routes, buses, operators, and schedules for example). Transit agency 26 may provide one or more hashtags that stakeholders can be used to create SMEs directed to particular transit agencies 26, or its routes, buses, drivers, and the like. Such hashtags may even specify characteristics of SMEs that can help social media manager 24a. For example “#AgencyRoute12 #Bus4 #Late” may indicate that the Agency's Bus 4, on Route 12 may be late. Characterizing may also include simple categories such as positive, neutral, negative, or important (such as in 912, with icons being used for such categories).
  • (e) Elevating: If an SME is important or has broader relevance to stakeholders, creating an alert or incident for dissemination.
  • (f) Distributing: Social media manager may provide information to, or update, other transit data servers 24 based on the SMEs. If an SME 50 indicates a bus is late, social media manager 24a may update scheduling functionality 24 and schedule adherence databases 22.
  • (g) Responding: Responding to SMEs via one or more social media (such as tweets on behalf of transit agency 26), or other, forms of communication (such as alerts) and sending the responses to the appropriate stakeholders (such as those whose profile requests alerts relating to the SMEs or responses thereto).
  • (h) Analyzing: Performing the SMEs, and responses thereto, to perform business intelligence analysis to improve the operation and performance of transit agency 26.
  • (i) Reporting: Generating and disseminating reports, based on the SMEs, to stakeholders.

FIG. 7 is a diagram of a method 700 for social-media generated transit agency content according to a non-limiting embodiment of the present invention.

Method 700 begins at 702 where a relevant SME occurs. Relevance may be very subjective and may vary between transit agencies 26. However, anything that transit agency 26 deems relevant may be considered relevant.

At 704 the relevant SME 50 is detected by social media manager 24a and at 706 the SME 50 is added to a queue of SMEs for review, response, and the like, as described herein.

At 708 SME 50 is characterized or categorized. This may allow SME 50 to be thoroughly and efficiently used to improve transit agency 26.

SMEs 50 may be characterized according to the following transit agency taxonomy, or others:

First Level
Characterization/	Second Level Characterization/	Third Level Characterization/
Category	Category	Category
Commendation	Employee, Service, Alerts, Website
Suggestion	Fare Gate/Fare Box, Fare Policy,
	Lost and Found, Maintenance,
	Parking, Privacy Policy, Service,
	Alerts, Website
Inquiry	Monthly passes & Tickets,	Service: Air Conditioner, Early,
	Disability ID Cards, Fare Gate/Fare	Heat, Late, Lighting, Need
	Box, Fare Policy, Lost and Found,	Translation Services, No Public
	Parking, Privacy Policy, Refunds,	Announcements, No signage on
	Senior ID Cards, Service, Alerts,	bus/train, Passenger Bypass,
	Trip Planner, Website	Other
Complaint	Monthly passes & Tickets,	Employee: Failure to Assist
	Elevator/Escalator, Employee, Fare	customer, Harassing Passenger,
	Gate/Fare Box, Fare Policy, Lost	Improper Behavior, Insensitive
	and Found, Maintenance, Parking,	to Customer Needs, No Public
	Privacy Policy, Refunds, Schedules,	Announcements, On Cell Phone,
	Service, Alerts, Trip Planner,	Rude/Abrasive, Other.
	Website, Other	Maintenance: Air Conditioner,
		Heat, Lighting, No signage on
		bus/train.
		Service: Air Conditioner, Early,
		Heat, Late, Need Translation
		Services, No Public
		Announcements, No signage on
		bus/train, Passenger Bypass,
		Other.
Schedule-related	Mode, bus stops, train stations,	Mode: Subway, Train, Bus,
	terminals.	Lightrail, Streetcar, Paratransit
		vehicle.

Characterization, and transit agency taxonomies, may further include connecting information directly to transit agency 26 data/routes/assets/employees/etc. For example where SME 50 identifies a frustrating experience with a driver on a particular route, but does not specify the actual driver, social media manager (perhaps via an administrator) can consult with transit data servers 24 to determine which driver (or drivers) was driving that route so the comment can be connected. Similarly, if there is a complaint about a bus' seat, but the bus is not identified, other characteristics about SME 50, in combination with transit data servers 24, can be used to identify the bus, and then have maintenance functionality and maintenance database alerted. In one embodiment, the below taxonomy may allow such further characterization.

At 710 a query is made whether SME 50 should be elevated to be considered an incident having broader interest to stakeholders of transit agency 26—for example that may be transmitted to some of such stakeholders (for example whose profile indicates they want to know about such an SME 50) as described herein. 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 SME 50? 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 SME/event?

In one embodiment social media manager 24a 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 other transit data servers 24.

If the SME 50 is to be elevated at 710 then at 712 content sinks, that are to receive notification of the incident (including other transit data servers 24), are determined. As described herein, stakeholders may create profiles and “sign up” to receive various content (including alerts and notifications), where such content may be described using various fields or attributes. When SME 50 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.

At 712 SMEs may be delegated to transit agency 26 employees to investigate or respond to, apart from any response via social media manager 24a. For example, a CEO may want to be made aware of serious SMEs so they may issue a response as CEO.

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 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.

If SME 50 is not to be elevated at 710, or after 712, method 700 continues to 714. At 714 a response to SME may be prepared and sent, for example by an administrator who is monitoring SMEs in social media manager. A response may be provided if a response is available (for example there is an answer to a question that was posed in SME 50), an apology is to be issued, and the like (such SME being “respondable”). Any response SMEs, by any stakeholder, may be tracked and associated with the original SME 50 (and handled similarly to an originating SME, and perhaps treated as part of a “conversation” or part of the same topic). As a result of characterization at 708, and connection to transit data, responses at 714 may provide further detail than the original SME contained. For example, a rider (say @Rider117) may tweet “This driver is great, I wonder who she is? #Agency #Route14”. Having characterized and associated the tweet, the response may be “Great to hear! Sheila is your driver today on #Route14, she is a star! @Rider117”.

At 716 SMEs may be analyzed, and results reported at 718, possibly in conjunction with other data, for example from TDD 22 via one or more transit data servers 24. The analysis at 716 may only be possible because social media manager has ingested, and importantly characterized the data in a transit agency way, and tied SMEs 50 to transit agency 26 data. Exemplary analysis may include:

• • (a) How many complaints have we had about a particular: route, vehicle, driver, etc.
  • (b) How many inquiries have we had relating to a route? Perhaps a new sign is required?
  • (c) How many times are broken seats reported as SMEs 50, compared to being observed by maintenance? Perhaps maintenance is under-staffed?
  • (d) How many suggestions have we received to increase service frequency at particular bus stops being serviced by particular routes?

FIGS. 8-9 are screenshots 800/900 for a social media manager interface, according to a non-limiting embodiment of the present invention.

Screenshots 800/900 may allow a user (such as an administrator) to access and interact with the functionality of social media manager 24a, as described herein.

Screenshot 800 depicts social media manager 24a having three primary tabs 802 to select what aspect to display. Twitter™ manager is currently selected, while Facebook™ manager and incident manager are options. In the embodiment shown in FIG. 8 various social media options are interacted with separately, while in FIG. 9 they are more integrated. Many approaches, to this and other user interface design considerations, are considered within the scope of the present invention.

The user is able to compose a tweet in tweet area 804, and effect or cause the tweet via tweet button 806. These may be substantially similar to social media area 902 and post button 906, but in screenshot 900 social media selector 904 allows a user to select which social media to post to.

Returning to screenshot 800, filter display 808 allows a user to see at least a subset of SMEs 50 that are relevant to transit agency 26 or to search SMEs 50. Filtering may be, for example, by mentions or direct tweets at transit agency 26. Of course many other filtering is contemplated, including based on any of the characterization at 708.

Create Incident button 810 may allow a user to elevate SME 50 (the currently selected one), as described herein, while Add Details button 812 may allow for further characterization or editing of SME 50.

Turning to screenshot 900, SME display 912 may present SME queue, or one or more subsets thereof, and include various fields in displaying such SMEs, such as what social media SME 50 is from, how it is characterized or categorized, when it occurred, the most recent contributor to SME 50 or the related conversation, and the like. The subset, or subsets of the queue may be based on selecting one or more characterizations from the taxonomy of characterizations employed by transit agency 26. The selected SME or conversation may then be shown in detail display 910, where further details may be shown.

SME display 912 may show live SMEs 50 and/or SMEs pending approval (which may require one or more levels of approval, and may be for approval of outgoing tweets or approval of characterizing incoming tweets), depending on which tab 908 is selected.

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 social media content for a transit agency, the system comprising:

a social media manager configured to: detect a social media event (SME) relevant to the transit agency; add the SME to a queue of SMEs; characterize the SME; and store the characterized SME.

2. The system of claim 1 wherein the social media manager is further configured to allow responding to the SME if the SME is respondable.

3. The system of claim 1 wherein the characterizing comprises applying a transit agency taxonomy.

4. The system of claim 3 wherein the social media manager is further configured to analyze the SMEs, using the transit agency taxonomy, to determine trends relating to the transit agency.

5. The system of claim 4 wherein the social media manager is further configured to display one or more subsets of the queue, depending on a filter applied to the queue based on the taxonomy.

6. The system of claim 1 wherein the social media manager is further configured to elevate the SME to an incident, and transmit the incident to one or more transit agency stakeholders.

7. A method for handling social media content for a transit agency, the method comprising:

detecting a social media event (SME) relevant to the transit agency;

adding the SME to a queue of SMEs;

characterizing the SME; and

storing the characterized SME.

8. The method of claim 7 further comprising responding to the SME if the SME is respondable.

9. The method of claim 7 wherein the characterizing comprises applying a transit agency taxonomy.

10. The method of claim 9 further comprising analyzing the SMEs, using the transit agency taxonomy, to determine trends relating to the transit agency.

11. The method of claim 10 further comprising displaying one or more subsets of the queue, depending on a filter applied to the queue based on the taxonomy.

12. The method of claim 7 further comprising elevating the SME to an incident, and the incident being transmitted to one or more transit agency stakeholders.