Patent Application
20140143102
1. Technical Field
Embodiments of the subject matter disclosed herein relate to methods and systems providing a user interface to facilitate the accessing, the reviewing, and the analyzing of owner asset transaction data.
2. Discussion of Art
Assets that are owned or leased by an entity may need to be managed and tracked for the purposes of billing and payment with respect to the use of those assets. For example, with respect to railroad assets, a first railroad may own its own fleet of rail cars, and may keep track of all rail car assets traveling on its railroad tracks, whether or not the rail car assets are owned by that first railroad. Furthermore, at the end of a billing period (e.g., end of the month), the first railroad may make payment through a central clearing house to other railroads that had their rail cars traveling on the railroad tracks of the first railroad during that billing period. That is, the rail cars are owned by other railroads but traveling on the tracks of the first railroad may be deemed leased by the first railroad. Such payments may be made to compensate the other railroads for use of their rail cars to ship products and materials on the railroad tracks of the first railroad. Each railroad receives payment along with other associated owner asset transaction data (receivables data) corresponding to their rail cars that traveled on railroad tracks of other railroads. The owner asset transaction data may include payment data, mileage rate data, distance traveled data, time of use data, payee information, asset type information, asset cargo type, reclaims information, and shipper/consignee information, for example. The number of transactions and the associated number of assets (e.g., rail cars) can be quite large and mistakes can be made when tracking assets and making payment for use of assets on a railroad's tracks. Therefore, it may be desirable to allow an asset owner (e.g., a railroad or an asset leasing company) to be able to verify the use of its assets and the payments for the use of its assets by analyzing the received owner asset transaction data.
Systems and methods providing a user interface to facilitate at least the accessing, the reviewing, and the analyzing of owner asset transaction data are disclosed. Embodiments of the invention may provide a controller to receive owner asset transaction data and allow a user to view transaction details down to the individual asset level, if desired, and to research one more transactions related to one or more assets. This may be done through a controller having a user interface. The user interface allows a user to investigate asset transactions by category such as, for example, an asset fleet category, an asset type category, or an individual asset category. Other categories are possible as well, in accordance with various embodiments.
In one embodiment, a controller is provided that includes a communication device operable to receive owner asset transaction data for a plurality of owner assets, and a user interface operable to facilitate access of the owner asset transaction data by a user. The user interface may be operable to facilitate access of the owner asset transaction data by a user according to category. The categories may include one or more of an asset fleet category, an asset type category, and an individual asset category. The user interface may facilitate access of the owner asset transaction data by a user at a transaction level for a group of assets or for an individual asset. In accordance with an embodiment, the plurality of owner assets may be leasable and may include vehicles or powered equipment. The vehicles or powered equipment may include at least one of rail cars, construction vehicles or equipment, mining vehicles or equipment, communication vehicles or equipment, shipping vehicles or equipment, or transportation vehicles or equipment, for example. The user interface may be operable to facilitate a comparison of the owner asset transaction data to a set of industry standard transaction data. The user interface may be operable to facilitate investigation of a deviation in the owner asset transaction data from the industry standard transaction data. The user interface may be operable to facilitate a generation of a claim based on the deviation in the owner asset transaction data. The user interface may facilitate a comparison of at least a portion of asset movement data, as recorded in the owner asset transaction data, to asset movement data obtained from a source other than that from the owner asset transaction data, or to asset time and location data.
In one embodiment, a method includes detecting discrepancies between received owner asset transaction data and modeled or empirical transaction data. At least one of the owner asset transaction data, the modeled or empirical data, and discrepancy data associated with the detected discrepancies may be selectably displayed. Details associated with the discrepancy data may be subsequently investigated. A detected discrepancy may relate to one of an asset rate, and asset time of use, and asset distance traveled, or an asset payment. Discrepancy data may be in the form of differential data, for example. Comparison may be provided in contrast to actual data collected or against a rule set.
In one embodiment, received owner asset transaction data is compared to at least one of modeled transaction data or empirical transaction data to identify a discrepancy; and displaying selectably in response to an identified discrepancy at least one of: the owner asset transaction data, the modeled transaction data, or the empirical transaction data in addition to discrepancy data that is associated with the detected discrepancy
A claim may be generated that is associated with the discrepancy data. Details associated with claims history including claims paid, claims outstanding, and claims denied associated with one or more of a plurality of owner assets associated with the owner asset transaction data may be investigated. The owner asset transaction data may include one or more of asset rate data, asset time of use data, asset distance traveled data, asset payment data, payee information, asset type information, asset cargo type, reclaims information, and shipper/consignee information.
In one embodiment, a controller is provided that includes a communication device operable to receive owner asset transaction data for a plurality of owner assets, and a processing device or processor that includes a module to compare the owner asset transaction data to expected transaction data to detect discrepancies. The controller includes a user interface. The user interface can retrieve, organize, and selectively display at least a portion of the owner asset transaction data, the expected transaction data, and discrepancy data associated with the discrepancies.
Reference is made to the accompanying drawings in which particular embodiments of the invention are illustrated as described in more detail in the description below, in which:
Embodiments of the invention may relate to methods and systems for providing a user interface to facilitate accessing, reviewing, and analyzing owner asset transaction data. Such transaction data may include, for example, car hire receivable data.
The term “asset” refers to equipment and materials that may be owned, leased, and transported. Examples of assets include, but are not limited to, rail cars of a railroad or a rail car leasing company, vehicles or powered equipment, wherein the vehicles or powered equipment include at least one of locomotives, construction vehicles or equipment, mining vehicles or equipment, communication equipment, shipping vehicles or equipment, or transportation vehicles or equipment.
A rail vehicle consist is a group of rail vehicles that are mechanically linked together to travel along a track. A train is one example of a rail vehicle consist. Another example is a set of mining ore carts. A vehicle consist, more generally, is a group of vehicles that are mechanically linked together to travel along a route. A powered vehicle consist refers to the interaction of two or more powered vehicles that are mechanically linked together, as may be the case for a locomotive consist (providing multiple powered vehicles to move a train of otherwise unpowered vehicles). Although trains are often referred to herein, certain embodiments are more generally applicable to rail vehicle consists or other vehicle consists.
“Software” or “computer program” as used herein includes, but is not limited to, one or more computer readable and/or executable instructions that cause a computer or other electronic device to perform functions, actions, and/or behave in a desired manner. The instructions may be embodied in various forms such as routines, algorithms, modules or programs including separate applications or code from dynamically linked libraries. Software may also be implemented in various forms such as a stand-alone program, a function call, a servlet, an applet, an application, instructions stored in a memory, part of an operating system or other type of executable instructions. It will be appreciated by one of ordinary skill in the art that the form of software is dependent on, for example, requirements of a desired application, the environment it runs on, and/or the desires of a designer/programmer or the like.
“Computer”, “processor”, “processing device” or “computer device” as used herein includes, but is not limited to, a programmed or programmable electronic device that can store, retrieve, and process data. “Non-transitory computer-readable media” include, but are not limited to, a CD-ROM, a removable flash memory card, a hard disk drive, a magnetic tape, and a floppy disk. “Controller”, as used herein, refers to a system that includes the logic circuitry, memory, and/or processing devices and associated software, modules or programs. The term “communication device” as used herein may refer to any wired or wireless device (e.g., a computer modem) operable to receive and/or transmit signals, data, or information.
The term “transaction data” or “transaction information” as used herein may refer to data or information related to the use of assets by various entities and the monetary payments associated with the use of those assets. The term “user interface” as used herein may refer to the software, the display screens, and the functionality provided by embodiments of the present invention that facilitate at least the accessing, the reviewing, and the analyzing of owner asset transaction data by a user. The term “claim” as used herein may refer to the claims of this patent application or to a computerized demand for correct or corrected payment for use of an asset. The term “Screen shot” is a picture of a screen at a moment in time, and a “User Interface” is a display of a series of Screen Shots, and which may be interactive to display different information depending on user input and underlying information. The User Interface, depending on context, may include the graphical input/output and/or the display hardware.
The system and methods described herein may be discussed in the context of rail car assets and corresponding car hire receivable transaction information. However, embodiments may apply to other assets and owner asset transaction information. Such other assets may include, for example, construction vehicles or equipment, mining vehicles or equipment, communication vehicles or equipment, shipping vehicles or equipment, or transportation vehicles or equipment.
Because the rail cars are owned by the first railroad, the subsequent (i.e., second, third, and fourth) railroads may each (e.g., at the end of the month) owe and pay the first railroad for use of the first railroad's rail cars on the tracks or routes of the other railroads, respectively. Such payments may be made through a central clearing house which accepts the payments and associated rail car data from the various railroad entities. The central clearing house may then process the rail car data and the payments to form car hire receivable information (a type of owner asset transaction data) for the first railroad. The car hire receivable information may be sent to the first railroad or made available to the first railroad via a computer network (e.g., the internet).
Each railroad may keep track of assets owned by other railroads (or equipment of other entities such as leasing companies) traveling on its railroad tracks and subsequently provide payment and associated rail car information to the central clearing house, for example, at the beginning or the end of each month. When a railroad receives or accesses the car hire receivable information for a particular time period as gathered by the central clearing house, the railroad may desire to review the car hire receivable information to check for any errors or discrepancies with respect to use of their rail cars on other railroads and the associated payments.
Such errors or discrepancies may relate to an asset rate, an asset time of use, an asset distance traveled, or an asset payment. An asset rate may correspond to a monetary charge per mile or a monetary charge per hour along a route, for example. An asset time of use may correspond to a total time that a rail car was on another railroad's track, for example. An asset distance traveled may correspond to a total distance that a rail car traveled along another railroad's track, for example. Other types of discrepancies may be possible as well. The parameters listed may be bounded in a determined manner. For example, asset distance traveled may be bounded for a particular trip, for a particular time, or for a particular transaction. Bounding for a particular transaction may be a cumulative distance calculated while in the possession of a user regardless of the actual distance or use or period of time in which the asset is in the possession of the user.
For example, if the transaction data states an asset was in use in a certain time and place, actual time and location data of the asset may be used to confirm the statement. If, on the other hand, there is no precise confirmation available then a rule set may be used. In such an example, one or more known data points (such as the location of the asset at a different time) may be used with a logic set (such as whether the asset could have traveled the distance from the known time/location to the billed transaction location in the time provided as the difference between the billed time and the known time/location).
The controller includes the communication device, the processing device, and a user interface 213. The communication device may be, for example, a computer modem allowing communication between the controller and the communication network. The processing device may be, for example, a software-programmable microprocessor. In accordance with an embodiment, the user interface is a graphical user interface and is a configuration of software functionality and user-interactive screen shots that facilitate the accessing, the reviewing, and the analyzing of owner asset transaction data (e.g., car hire receivable data) by a user. The user interface may allow requests of owner asset transaction data according to category. Categories may include, for example, an asset fleet category, an asset type category, and an individual asset category.
The user interface may be a web-based graphical user interface (GUI) and may include the display hardware in some implementations. Use of the GUI may provide access to owner asset transaction information, including reclaims. Direct access to rolling summaries of car hire information may be provided with one-click drill-down to details. Such details may include payee, asset type, asset cargo type, reclaims, shipper/consignee, and pool. The rolling summaries may be set for determined periods. Such periods may align with, for example, one or two calendar years, fiscal years, current or previous months, and the like. Owner asset transaction data may be compared to estimates based on actual car movements, including mileage and reclaims, for example. Estimates and forecasts may be produced weekly, monthly, or yearly for example.
The user interface provides a claims processing interface that includes a detailed history of claims that includes claims paid, claims outstanding, and claims denied. The processing device may track paid claims, outstanding claims, and denied claims associated with the owner assets. The processing device is further operable to perform claim rectification and to confirm receipt of claims communications associated with the owner assets. The user interface includes ready access to asset movement events and rates for the purpose of researching claims. A large library of reports may be provided to aid in analysis. The ability to create ad-hoc reports is provided and reports may be exported to other applications. The user interface may provide a dashboard view. Such a dashboard view may allow a user to review and analyze trends and problem areas. For example, the processing device may calculate trends of cost over time associated with one or more of the plurality of owner assets. The user interface may present graphical depictions of the trends of cost over time.
The user interface 213 may include a touch-screen display for viewing and interacting with the screen shots, for example. Alternatively or optionally, the system may include a user computer 240 (e.g., a personal computer, tablet, smart phone, and the like) having a display and a mouse, for example, that is used to access, view, and interact with the user interface. The user computer may interface directly to the controller or may have a web browser allowing interfacing via a computer network (e.g., the communication network). In such an alternative embodiment, the controller may be structured in a software-as-a-service (SaaS) configuration. A user may have an account and security authentication to log into the SaaS controller.
The controller may access car hire receivable data from the source via the communication network. A user may then review and analyze the car hire receivable data using the controller as facilitated by the user interface of the controller. In accordance with an embodiment, the user interface is configured to allow a user to review the car hire receivable data at various levels of transaction detail from a highest summary level (e.g., a level corresponding to an entire fleet of assets) down to the level of an individual asset (e.g., an individual rail car). The user interface allows a user to view trends, make sense of transactions, research claims and rates, track rates, and process other transactions such as re-claims and counter re-claims.
In accordance with an embodiment, the control system or controller 210 may detect discrepancies or deviations between owner asset transaction data and industry standard transaction data (or modeled or empirical transaction data), allow a user to investigate the details of the discrepancy, and allow a user to initiate the generation of a claim to correct the discrepancy. For example, if payments by a railroad using a rail car to the owning railroad were made using an incorrect mileage rate for that rail car, the processor can detect that discrepancy, alert the owner to the discrepancy, and allow the owner to investigate details associated with the discrepancy. The processor can generate a claim to correct the discrepancy for that rail car by requesting an adjustment in payment from the other railroad (e.g., through the central clearing house). Further, a follow up module can indicate when a discrepancy is actually rectified.
In accordance with an embodiment, the control system can compare at least a portion of asset movement data as recorded in the owner asset transaction data to asset movement data obtained from a different source other than that from the owner asset transaction data or to asset time and location data. The user interface may facilitate such a comparison. Suitable asset movement data may be, for example, related to the movement of rail cars along routes. Suitable sources of asset movement data may be, for example, global positioning system (GPS) data as acquired for each asset independently of the owner asset transaction data. The interface can be a .NET based application that interacts with a DB2 database.
In step 330, the user may employ the user interface to investigate details associated with the discrepancy data. As an option, in step 340 the user may employ the user interface to initiate the generation of a claim by the processing device, where the claim is associated with the discrepancy data. Furthermore, as an option, in step 350 the user may employ the user interface to facilitate the investigation of details associated with claims history. The claims history may include claims paid, claims outstanding, and claims denied that are associated with one or more of a plurality of owner assets associated with the owner asset transaction data. In accordance with an embodiment, the user interface 213 includes software instructions that are executed on the processing device 212.
As described herein, the user interface 213 may perform various functions at the command of the user. For example, the user interface may retrieve, organize, and selectively display at least a portion of the owner asset transaction data, standard transaction data, expected transaction data, modeled or empirical transaction data, and discrepancy data. The user interface facilitates user interaction with at least a portion of the data to allow investigation of details associated with detected discrepancies and claims. Again, the user interface 213 is configured to allow a user to review the transaction data and any associated discrepancy data at various levels of transaction detail from a highest summary level down to the level of an individual asset. The screen shots described below illustrate various aspects of the user interface 213 of the controller 210.
In one embodiment, the user interface can facilitate user interaction and manipulation of at least a portion of the owner asset transaction data, the expected transaction data, and the discrepancy data to allow investigation of details associated with a detected discrepancy. The processing device may generate a claim associated with the detected discrepancy. The processing device may process claims by tracking paid claims, outstanding claims, and denied claims associated with the plurality of owner assets. The processing device may process claims for claim rectification and to confirm receipt of claims communications associated with the owner assets. The processing device may calculate trends of cost over time associated with one or more of the plurality of owner assets. The user interface present graphical depictions of the trends of cost over time. Such trends may be projected forward based on the empirical data.
Further, cost data and/or discrepancy rate data (preferably in graph form) may be compared for one asset versus another, by one class or group of assets versus another, or by other criteria. Other criteria may include identification of the asset user to investigate if a user's use incurs a different cost or discrepancy rate relative to another user or a user group average. Yet other criteria may include geographical areas to investigate if one region has different costs or discrepancy rates relative to other regions.
Systems and methods providing a user interface to facilitate at least the accessing, the reviewing, and the analyzing of owner asset transaction data are disclosed. Embodiments of the invention provide a controller having a communication device, programming logic, and a user interface. The communication device can receive owner asset transaction data for a plurality of owner assets. The user interface is operable to facilitate access of the owner asset transaction data by a user and the investigation of discrepancies between the owner asset transaction data and, for example, industry standard transaction data.
With reference to the drawings, like reference numerals designate identical or corresponding parts throughout the several views. However, the inclusion of like elements in different views does not mean a given embodiment necessarily includes such elements or that all embodiments of the invention include such elements.
In the specification and claims, reference will be made to a number of terms have the following meanings. The singular forms “a”, “an” and “the” include plural referents unless the context clearly dictates otherwise. Approximating language, as used herein throughout the specification and claims, may be applied to modify any quantitative representation that could permissibly vary without resulting in a change in the basic function to which it is related. Accordingly, a value modified by a term such as “about” is not to be limited to the precise value specified. In some instances, the approximating language may correspond to the precision of an instrument for measuring the value.
In appended claims, the terms “including” and “having” are used as the plain language equivalents of the term “comprising”; the term “in which” is equivalent to “wherein.” Moreover, in appended claims, the terms “first,” “second,” “third,” “upper,” “lower,” “bottom,” “top,” etc. are used merely as labels, and are not intended to impose numerical or positional requirements on their objects. Further, the limitations of the appended claims are not written in means-plus-function format and are not intended to be interpreted based on 35 U.S.C. §112, sixth paragraph, unless and until such claim limitations expressly use the phrase “means for” followed by a statement of function void of further structure. As used herein, an element or step recited in the singular and proceeded with the word “a” or “an” should be understood as not excluding plural of said elements or steps, unless such exclusion is explicitly stated. Furthermore, references to “one embodiment” of the present invention are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features. Moreover, unless explicitly stated to the contrary, embodiments “comprising,” “including,” or “having” an element or a plurality of elements having a particular property may include additional such elements not having that property. Moreover, certain embodiments may be shown as having like or similar elements, however, this is merely for illustration purposes, and such embodiments need not necessarily have the same elements unless specified in the claims.
As used herein, the terms “may” and “may be” indicate a possibility of an occurrence within a set of circumstances; a possession of a specified property, characteristic or function; and/or qualify another verb by expressing one or more of an ability, capability, or possibility associated with the qualified verb. Accordingly, usage of “may” and “may be” indicates that a modified term is apparently appropriate, capable, or suitable for an indicated capacity, function, or usage, while taking into account that in some circumstances the modified term may sometimes not be appropriate, capable, or suitable. For example, in some circumstances an event or capacity can be expected, while in other circumstances the event or capacity cannot occur—this distinction is captured by the terms “may” and “may be.”
This written description uses examples to disclose the invention, including the best mode, and also to enable one of ordinary skill in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to one of ordinary skill in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differentiate from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal language of the claims.
