Patent Application
20130275180
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.
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.
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.
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:
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.
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
In
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).
In
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.
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.
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:
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:
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:
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:
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
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.
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.
| Number | Date | Country | |
|---|---|---|---|
| 61623991 | Apr 2012 | US |
