Abstract:
Systems and methods for configurable deployment of transit agency content are provided that allow plug and play functionality modules, based on available transit data required by such functionality modules, to be placed on webpages. Further, content may be developed and published to various transit data sinks from a single dashboard.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims the benefit of U.S. Provisional Application No. 61/623,991 filed Apr. 13, 2012. 
     
    
     COPYRIGHT NOTICE 
       [0002]    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 
       [0003]    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&#39; riders—do not exist. Accordingly the following invention is directed at addressing some of those current limitations. 
       SUMMARY OF THE INVENTION 
       [0004]    In one aspect there is a system for configurable transit agency content management comprising one or more transit data databases containing one or more transit data datasets, one or more functionality modules, each having one or more functionality module user interface components to allow users to interact with the functionality module and processing components for interacting with the one or more transit data databases having datasets required by the functionality module, and each of the one or more functionality modules being configured to interact with one or more transit data databases to provide functionality, and a webpage design module, having a user interface component displaying a webpage, configured to allow one or more of the functionality module user interface components to be placed thereon to create a webpage. 
         [0005]    The one or more transit data databases may comprise one or more of route databases, asset databases, schedule adherence databases and trips databases. The one or more functionality modules may comprise one or more of route planning, asset monitoring, schedule adherence and trip planning modules and may be configured to receive parameters relating to the functionality, query one or more transit data databases based on the parameters, and display one or more results of such query. 
         [0006]    The webpage design module is configured to determine which functionality modules&#39; functionality module user interface components can be placed thereon. The determination is based on whether the one or more transit databases include the datasets required by the functionality modules and may be made in real-time or before functionality module options are presented to a user. 
         [0007]    In a further aspect there is a method for managing transit content, the method comprising selecting a transit content type to create, specifying one or more parameters for the transit content type, determining one or more transit data sinks to receive the transit content, and creating the transit content. 
         [0008]    The creating may further comprise generating draft content based on the specifying, and approving the draft content. The method may further comprise picking what mediums should receive the transit content, and publishing the transit content to those mediums. 
         [0009]    In a further aspect there is a system for configurable transit agency content management comprising one or more transit data databases containing one or more transit data datasets, one or more functionality modules, each being configured to interact with one or more transit data databases and transit data datasets to provide functionality, each having one or more functionality module user interface components to allow users to interact with the functionality module, and a webpage design module, having a design module user interface component displaying a preview webpage, configured to allow one or more of the functionality module user interface components to be placed thereon to create a webpage. 
         [0010]    The webpage design module may be configured to determine which functionality modules&#39; functionality module user interface components can be placed thereon. The determination may be based on whether the one or more transit databases include the transit data datasets required by the functionality modules. The determination may be made in real-time or before functionality module options are presented to a user. 
         [0011]    The one or more functionality modules may be configured to receive parameters relating to the functionality, query one or more transit data databases based on the parameters, and display one or more results of such query. 
         [0012]    The one or more transit data databases may comprise one or more of route databases, asset databases, schedule adherence databases and trips databases. The one or more functionality modules may comprise one or more of route planning, asset monitoring, schedule adherence and trip planning modules. The one or more functionality modules may be configured to receive parameters relating to the functionality, query one or more transit data databases based on the parameters, and display one or more results of such query. 
         [0013]    The design module user interface component has a module selector located thereon, the module selector containing one or more icons representing one of the one or more functionality modules, each icon being selectable or not selectable and wherein, if selectable, the functionality module can be placed on the preview webpage. 
         [0014]    In yet a further aspect there is a method for configurable transit agency content management comprising receiving a request to design a webpage for a transit agency by placing one or more functionality modules on a webpage preview, determining what transit datasets the agency has access to, allowing one or more functionality modules, each functionality module requiring one or more transit datasets for operation, to be selected and placed on the preview webpage based on if the determining indicated the agency has access to the transit datasets required by the functionality module. 
         [0015]    The method may further comprise placing a functionality module on the webpage preview based on a user action. The method may further comprise receiving customization parameters relating to the functionality module and adjusting the appearance and operation of the functionality module based on the parameters. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]    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: 
           [0017]      FIG. 1  is a diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention; 
           [0018]      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; 
           [0019]      FIG. 3  is a screenshot for a configurable transit agency content management system according to a non-limiting embodiment of the present invention; 
           [0020]      FIG. 4  is a screenshot for a configurable transit agency content management system according to a non-limiting embodiment of the present invention; and 
           [0021]      FIG. 5  is a screenshot for a configurable transit agency content management system according to a non-limiting embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0022]      FIG. 1  is a diagram of a system for configurable transit agency content management according to a non-limiting embodiment of the present invention. 
         [0023]    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. 
         [0024]    Transit agency  26  may further have transit agency data sinks or content sinks, that may include user devices  30   a / 30   b  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. 
         [0025]    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. 
         [0026]      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. 
         [0027]    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). 
         [0028]    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 . 
         [0029]    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). 
         [0030]    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  492 A is not operable due to construction and has been moved to a temporary stop  492 T. Service advisory module  100  may then query TDD  22  to see what stops, if any, are currently affected. Receiving back “ 492 A has been moved to  492 T”, 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. 
         [0031]    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. 
         [0032]    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. 
         [0033]    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). 
         [0034]    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 . 
         [0035]      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. 
         [0036]    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). 
         [0037]    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 ). 
         [0038]      FIG. 4  is a screenshot  400  for a configurable transit agency content management system according to a non-limiting embodiment of the present invention. 
         [0039]    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 . 
         [0040]    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. 
         [0041]      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. 
         [0042]    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 . 
         [0043]    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. 
         [0044]    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. 
         [0045]    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 . 
         [0046]    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.