The present application generally relates to determining a bus arrival time at each bus stop of a plurality of bus stops. More particularly, the present application relates to predicting a bus arrival time based on prior travel times between bus stops and real-time data representing a current journey.
Predicting arrivals of buses and/or other transportation vehicles at bus stops or designated locations is important in making a public transporting system more appealing and more efficient for passengers. With accurate bus arrival predictions communicated or presented to passengers, the passengers can make informed decisions about how to travel.
Improving a public transporting system is critical for reducing congestions on urban roadways. Providing timely accurate predictions about bus arrivals at bus stops along bus routes is one important step to improve public transporting system. Current systems for predicting arrival times of buses at bus stops rely on GPS (Global Positioning System) location information of the buses. While those current systems represent improvements over prior systems that have no available information of predicting bus arrival times, predictions of the current systems are not accurate, e.g., buses arrive more than 5 min later from the predictions. What occurs then is that the passengers, having perceived the predictions to be inaccurate, can no longer rely on the predictions at all. Thus, in many cities, such current systems have been abandoned for this reason, i.e., inaccuracies.
There may be several reasons why the current systems predict inaccurately bus arrival times: 1. The current systems use algorithms that may need further improvements; 2. Input data to the current system is not rich enough to permit an accurate estimation of bus arrival times. For example, the current systems use GPS information of bus positioning only to obtain data of bus travel time on segments that the bus already traversed. The GPS information does not provide information on traffic in an upcoming route.
The present disclosure describes a system, method and computer program product for predicting a bus arrival time at each bus stop of each bus line or route.
In one embodiment, there is provided a system for determining a vehicle arrival time. The system comprises a memory device and a processor being connected to the memory device. The system receives information representing prior travel times of vehicles between vehicle stops along a vehicle route. The system receives real-time data representing a current journey. The current journey refers to a movement of a vehicle currently traveling along the route. The system calculates a regular trend representing the current journey based on the received prior travel times information and the received real-time data. The system computes a deviation from the regular trend in the current journey. The system determines a future traffic status in subsequent vehicle stops in the current journey. The system estimates, for the vehicle, each arrival time of each subsequent vehicle stop based on the calculated regular trend, the computed deviation and the determined future traffic status.
In a further embodiment, to calculate the regular trend, the system performs a trend analysis or clustering on the received prior travel times information and the received real-time data.
In a further embodiment, to compute the deviation, the system performs a regression analysis on the received prior travel times information and the received real-time data.
In a further embodiment, to determine the future traffic status, the system obtains future traffic condition information of the subsequent vehicle stops from a traffic prediction tool. The future traffic condition information of the subsequent vehicle stops is integrated in the estimated arrival time.
The accompanying drawings are included to provide a further understanding of the present invention, and are incorporated in and constitute a part of this specification.
As referred to herein, a “bus” refers to any transportation vehicle (e.g., a truck, a carrier, a subway car, etc.) that travels between designated stops along a designated route. In one embodiment, a computing system (e.g., a computing system 400 in
GPS simulator 315 is a device to emulate the GPS device 310 when the GPS device 310 is unavailable to send the real-time bus location information. Operations of the GPS simulator 315 are described in detail below in conjunction with
The computing system 400 operates according to method steps described in
As shown in a box 700 in
Returning to
Returning to
At step 150 in
Alternatively, the computing system 400 estimates each bus arrival time at each subsequent bus stop along a bus route based on the calculated regular trend, the computed deviation, and the real-time GPS data of bus locations without using the future traffic status.
In a further embodiment, to perform the analysis (method steps 120-150 in
The computing system 400 matches the real-time and/or historical GPS data to a corresponding bus route and converts the real-time and/or historical GPS data to a distance with respect to an immediate next bus stop. In addition to a scheduled report of the real-time GPS data of a bus location, e.g., by every one minute interval, the GPS device 310 may send additional reports of the real-time GPS data of a bus location whenever the bus enters and/or leave a bus stop.
In a further embodiment, in addition to the historical GPS data, the computing system 400 retrieves transaction data for a pre-determined time interval (e.g., transaction data for at least recent two months), e.g., from the database 340. The database 340 may regularly update the transaction data to assist re-computing the analysis off-line and/or in real-time. The computing system 400 deduces historical bus arrival times at a bus stop from the transaction data. For example, a smartcard transaction data (e.g., banking card transaction history) that reflects when a particular passenger paid a bus fee to board a particular bus at a particular location reflects an arrival time of the particular bus at the particular location. Data captured in a smartcard includes, but is not limited to: smartcard ID (Identification), transaction date and time, bus stop ID, bus route number, bus route direction, etc.
The TPT 320 provides the future traffic condition information to the computing system 400. As the TPT 320 provides the future traffic condition information more stably or steadily, the computing system 400 improves more accuracy of the estimated arrival time at each bus stop.
The GPS simulator 315 receives historical bus arrival times and/or prior bus travel times from the database 340, and emulates actual GPS data of bus locations, e.g., with one minute time interval or other time interval.
For a case when real-time GPS data of bus location may not arrive at the computing system 400 according to an anticipated reporting time schedule, e.g., once per minute, in a real-time data stream, the computing system 400 may need the GPS simulator 315 to estimate the missing real-time GPS data of bus locations. To emulate the real-time GPS data of bus locations, the GPS simulator 315 may need a distance (e.g., a distance 1220 in
The GPS simulator 315 ensures stable real-time GPS data input to the computing system 400 and reduces an occurrence of missing output (e.g., the estimated bus arrival time 330) due to possible missing real-time GPS data. In one embodiment, the GPS simulator 315 simulates a would-be location (a distance toward a target bus stop) of bus upon receiving the historical GPS data of bus arrival times to bus stops from the database 340. More specifically, in this embodiment, the GPS simulator 315 assumes a bus travels between two consecutive stops with three stages: accelerate, cruise, and decelerate. The GPS simulator 315 estimates a speed vs. time curve (not shown) in order to match a travel time and a distance between the two consecutive stops. From the speed vs. time curve, the GPS simulator 315 infers whereabouts of this bus according to the anticipated reporting time schedule (e.g., once per minute). In another embodiment, the GPS simulator 315 runs method steps described in
In one embodiment, if the GPS device 310 is not available to send the real-time GPS data of bus locations to the computing system 400 for a certain period time or according to a pre-determined schedule, the GPS simulator 315 emulates the real-time GPS data, for example, as described in
In one embodiment, the computing system 400 receives the emulated real-time GPS data of bus locations as input and estimates a bus arrival time at a next bus stop, e.g., as shown in
In one embodiment, from prior bus travel times and/or historical bus arrival times, the computing system 400 finds when a bus used to arrive at a certain bus stop. The database 340 may additionally store distance information that indicates how far bus stops are from each other. Based on the prior bus travel times, historical bus arrival times and/or the distance information between bus stops, the computing system 400 analyzes the relationship between bus travel times and the distance information. Graphs 800-810 in
However, even though a bus has a stable travel behavior within a journey, an overall average speed between different journeys may differ due to different traffic conditions, e.g., driver's behavior, etc. The graph 720 in
In one embodiment, the computing system 400 fits each journey to a linear model (e.g., the linear slope 710),
T=S*D+I+R,
where T represents an estimated bus travel time, S represents the fitted slope (e.g., the slope 710), D represents a travel distance, I represents a fitted interception term (e.g., a constant term), R represents a fitted deviation. The computing performs this fitting, e.g., by using a linear regression technique. Graphs 1100-1110 in
In one embodiment, prior bus travel times may reflect journeys with different trends. Thus, in this embodiment, the computing system 400 divides the prior bus travel times into different data set. For example, the computing system 400 divides the prior bus travel times according to a day of a week (e.g., Monday, Tuesday-Thursday, Friday, Saturday-Sunday) and/or a time of a day (e.g., 6 AM, 6:15 AM, 6:30 AM . . . , 12 PM, 12:15 PM, etc.). In the time of a day case, a start time of a journey belongs, for example, between (journey start time−7.5 minutes) and (journey start time+7.5 minutes). Thus, the computing system 400 may use same time period and same case (e.g., a time of a day case) data to estimate a current journey. Since prior journeys with a particular time period and a particular case characteristic have a similar trend and deviation with the current journey that also occurs at the particular time period and with the particular case characteristic, the computing system 400 computes the regular trend and deviation from the regular trend for the current journey as follows:
Spredict=w1S1+w2S2+ . . . +wnSn
Rpredict=w1R1+w2R2+ . . . +wnRn,
where Spredict represents an estimated slope for the current journey, Rpredict represents an estimated deviation for the current journey, S1, S2 . . . Sn represents slopes for prior journeys, R1, R2 . . . Rn represents prior deviations for prior journeys, w1, w2 . . . wn represents weights for the prior journeys' slopes and deviations, and n represents the number of prior journeys. The weights give different value to different prior journeys. In one embodiment, the computing system 400 give larger weights to prior journeys whose travel dates are closer to the current journey and give smaller weights to prior journey whose travel dates are further away from the time of the current journey.
In one embodiment, the computing system 400 can use the latest real-time GPS data of bus locations and the calculated parameters (e.g., Spredict, Rpredict, etc.) of the current journey to estimate bus arrival times at upcoming bus stops. For example, the computing system solves the following equation to estimate a bus arrival time at a bus stop:
Ap=Ar+Trp, where Ap represents an estimated bus arrival time (e.g., the estimated bus arrival time 920 in
In a further embodiment, the computing system 400 expands the previous equation (i.e., Ap=Ar+Trp) as follows:
Ap=Ar+Spredict*Drp+Rppredict−Rrpredict (0),
where Spredict represents an estimated slope for the current journey as described above, Rppredict represents an estimated deviation for the current journey at a subsequent bus stop and is equivalent to Rpredict above. Rrpredict represents a deviation for the current trip at reference time point location and is calculated similarly to Rpredict above. Drp represents a distance from reference time point location to the subsequent bus stop. The computing system 400 calculates Drp based on the latest real-time GPS data of the reference time point and map data of the corresponding bus route. Specifically, the computing system 400 calculates the distance Drp, e.g., by matching the reference time point location to a location on the map data. Drp may not be a straight line distance between the reference time point location and the location on the map data. Instead, Drp may be a distance along the bus route.
In one embodiment, the GPS simulator 315 operates based on patterns or trends, e.g., graphs 800-810 in
Let x(t) be a distance of a bus location from its departure at time point t. Reporting time points are represented by a set of integers: 1, 2, 3, etc. At step 200 in
Denote by fk(t) the kth smooth curve factor. At step 220, the GPS simulator 315 obtains a basis function and weights (see formula (1) below) from the fitted smoothing curve model:
xi(t)=βi1f1(t)+ . . . +βikfk(t)+òi(t) (1),
where òi(t) is a random error, βi1, . . . , βik are the weights for the curve factor. K is the number of smooth curve factors. The value of K is smaller than m, which is the number of time points observed in a prior complete journey. This model (i.e., formula (1)) can be fitted, for example, sequentially to the time series. More specifically, the first smooth curve factor is obtained by a penalized least square fitting:
where n is the number of prior journeys with similar starting times, λ is a smoothing parameter, and i and j are indices for summations. Xij represents an element of a matrix X whose elements include xi(t) described in formula (1). The second term in formula (2) represents a penalty for roughness of the fitted smoothing curve. Subsequent smooth curve factors fi(t) and their corresponding weights βi can be obtained, e.g., by fitting equations similar to formula (2) successively to data representing deviations, e.g., a matrix whose elements are in Xij−βif(tj). A solution to the formula (2) has an analytical form. More specifically, let β=(βi1, . . . , βik)T, X=(Xij)εRn×m, and f=(f1, . . . , fn)T where fj:=f(tj), a solution denoted by {circumflex over (f)}(.) of the formula (2) is a natural cubic spline (i.e., a spline constructed with piecewise polynomials which pass through a set of data points; a spline refers to a mathematical function used for smoothing) with data points at {tj: j=1, . . . , m} and its value at these data points are obtained by solving the following optimization problem:
where ∥ ∥F is the Frobenius norm of a matrix, and Ω=QR−1QT. Auxiliary matrices Q and R are defined as follows:
where k and j are generic indices ranging from 1 to m−1 where m was defined above, h is a symbol for a bus interval width, Ω is a symbol for a matrix and it is further defined through Q and R by the relationship Ω=QR−1QT, and jvk represents a maximum value of j and k.
For a given weight β, the GPS simulator 315 acquires the solution to the formula (3), e.g., by computing {circumflex over (f)}=(I+λΩ)−1YTβ. On the other hand, for a given f, the GPS simulator 315 acquires the solution to the formula (3), e.g., by computing
where f represents a smooth curve factor, I represents an identity matrix, and fT represents a transpose of f. These solutions lead to the following iterative approach to solve the formula (3).
1: Initialize f in the s=0 step.
2: In the s>0 th iteration, do the following:
3: Terminate iteration if ∥fs−fs-1∥2+∥βs−βs-1∥2<predefined threshold, otherwise set s←s+1 and return to step 2.
s refers to herein an index. The choice of smoothing parameter λ can be made, e.g., by a cross-validation technique. Cross-validation technique refers to a technique to assess how results of statistical analysis generalize an independent data set.
In one embodiment, the GPS simulator 315 groups prior journeys with similar starting times and fit the grouped prior journeys to the smooth curve to obtain the basis function of fk(t) for k=1, . . . , K and the respective weights {circumflex over (β)}1, . . . , {circumflex over (β)}K. The same basis function and weights can be applied to future journeys which share similar starting time characteristics:
{circumflex over (x)}(t)={circumflex over (β)}1f1(t)+ . . . +{circumflex over (β)}KfK(t) (4)
Returning to
In one embodiment, the GPS simulator 315 predicts the smoothing curve, for example, according to two different scenarios. First, the curve to be predicted may have no observed data at all (e.g., the bus journey has not even started yet). The GPS 315 handles this scenario, e.g., by solving formula (4) with proper choice of training data for an estimation of the weights and basis function. Another scenario is that the GPS simulator 315 has observed data from an initial segment of the smoothing curve to be predicted. For example, in the middle of the current journey, the GPS simulator 315 may want to predict the curve that corresponding to the remaining route of the current journey. In one embodiment, the GPS simulator 315 integrates information already collected from the initial segment of the curve, e.g., by computing formula (5) below. In one embodiment, the computing system updates the fitted smoothing curve in real-time upon receiving additional data (e.g., new data representing additional prior travel times, etc.).
Assume that the GPS simulator 315 selects n prior journeys (with similar starting time characteristics) and obtains their “K” number of basis functions fk(t) and weights {circumflex over (β)}k. The GPS simulator 315 also receives current journey's initial segment {xn+1(t0), xn+1(t1), . . . , xn+1(t{tilde over (m)})} where {tilde over (m)}<m and t0<t1< . . . , t{tilde over (m)}, from the GPS device 310. Thus, if the GPS device 310 becomes unavailable after sending partial real-time GPS data (e.g., bus location information in the current journey's initial segment) to the computing system 400, the GPS simulator 315 updates the weights of the basis functions based on the partial real-time GPS data. In other words, the GPS simulator 315 fits the same basis functions with slightly adjusted weights to a smoothing curve from which the partial real-time GPS data is observed. In this scenario, the GPS 315 solves a similar objective function according to a penalized least square fitting as follows:
where λ is a smoothing parameter. The second term in the formula (5) functions as a regularizer which ensures that a new β stay close to the prior weights. In one embodiment, when solving the formula (5), the computing system 400 assumes that the basis functions fk(t) have been estimated and their values at data points tj are known.
Having obtained the updated weights adjusted to the real-time GPS data up to time point t{tilde over (m)} in the current journey, the GPS simulator 315 may apply the formula (4) (substitute with the updated weights) to predict a distance from a departure at subsequent time points after t{tilde over (m)}. The graph 1200 in
The GPS simulator 315 allows the computing system 400 to predict bus arrival times without using the GPS device 310. The GPS simulator 315 obtains a smoothing curve that predicts remaining segments of the current journey after the reference time point t{tilde over (m)}, for example, {circumflex over (x)}(t)={circumflex over (β)}1f1(t)+ . . . +{circumflex over (β)}KfK; (t) where t{tilde over (m)}<t<m. A distance from a departure to a current bus location is x(t{tilde over (m)}). For any subsequence bus stop with distance xs>x(t{tilde over (m)}), the computing system 400 predicts a bus arrival time based on the predicted distance, the updated weights and the basis functions, e.g., by the solving the following optimization problem:
where δ>0 is a constant associated with a bus arrival at a bus stop. Since all the basis functions are continuous and monotone, the computing system 400 solves the formula (6), e.g., by using a binary search algorithm or other equivalent search algorithm. Wim Feijen, et al., “The Binary Search Revisited,” AvG127/WF214, 1995, http://www.mathmeth.com/wf/files/wf2xx/wf214.pdf, whose contents are wholly incorporated by reference as if set forth herein, describes the binary search algorithm in detail.
Bus arrival times to subsequent bus stops from a current bus is closely related to future traffic conditions on the remaining segments of the current journey, and less related to past or current traffic conditions. Traditional systems that cannot receive accurate prediction of future traffic conditions rely on travel records and traffic conditions up to a current time point. In one embodiment, the computing system 400 integrates output (future traffic condition information on the remaining segments) from the TPT 320 into a bus arrival prediction model (e.g., formula (7) below).
In one embodiment, the computing system 400 computes a time duration between a bus arrival time to a current bus stop (index by c) and the one to be predicted (index by c+h; “h-stop” ahead bus arrival time), e.g., by solving the formula (7). Denote this time duration by Ac,c+h. Assume that μAc,c+h is a predicted duration from other models (e.g., formula (6), etc.) based on prior travel times and traffic information up to the current time point. The formula (7) presents a framework which integrates future traffic conditions on the remaining segments in a coherent way with the other models (e.g., the forecasting model in
where Vkc,c+h is a predicted traffic quantity on a segment (index by k) between the stops c,c+h, and μVkc,c+h is a historical average of traffic quantity. The summation of the second term is over all segments (where traffic predictions are available) between the stop c,c+h and all relevant time intervals. More specifically, by assuming the current time is t{tilde over (m)}, the maximum value of Ac,c+h is AMc,c+h. The computing system 400 may include time interval(s) between t{tilde over (m)} and t{tilde over (m)}+AMc,c+h.
The formula (7) includes several properties. First, it adds an improvement over other prediction models (e.g., μAc,c+h), e.g., by considering future traffic conditions. The logarithm transformation in the formula (7) translates an adjustment to μAc,c+h, e.g., by relative percentage. Second, the formula (7) adapts to varying length of each bus route segment. In other words, an impact on this duration time is varying to each bus route segment. Specifically, αk in the formula (7) represents a weight of each (different) segment that reflects this varying length of each route. Third, the formula (7) differs fundamentally from traditional bus arrival prediction model: Rather than focusing on travel times on individual segments, the formula (7) reflects a deviation from the estimated arrival time over a whole bus route, and correlates the deviation from the estimated arrival time with a deviation from the future traffic status (e.g., the future traffic condition information) on a subset of the whole bus route where the traffic prediction tool (TPT) is installed. Due to correlations among different bus route segments, the deviation from the future traffic status on a subset of segments in a bus route can reflect that over the other subset of segments in the same route. Therefore the second term in the formula (7) integrates the impact of deviations from the regular trend in a collective manner. Vkc,c+h in the formula (7) can be traffic volume and/or road occupancy as well as traffic speed.
In a further embodiment, the formula (7) can reflect relevant passenger/bus behaviours, e.g., passenger activities at certain bus stops during a certain time of a day, spatial characteristics of a bus travel speed, etc, by reflecting these behaviours in the term μAc,c+h. Multiple prediction models (e.g., μAbc,c+h) can also be included in an additive manner, for example:
where μAbc,c+h represents a predicted bus travel time by other models (e.g., formula (0), etc.) between a bus stop c and a target bus stop c+h.
In one embodiment, the computing system 400 combines various bus arrival time prediction models (e.g., a model described in
subject to constraint
Let Σ be a covariance matrix of the vector e=(e.,1, . . . , e.,B)T from a sample of n observations. An optimal choice of linear coefficients {lb: b=1, . . . , B} can be obtained by solving the following optimization problem:
which finds a minimum value of (a transpose of l×Σ×l).
The computing system 400 may obtain the solution of formula (9), e.g., by using Lagrange multiplier. Lagrange multiplier finds a maximum and minimum of a function according to a constraint
Karl Hahn, “Lagrange Multiplier Method for finding Optimums,” 2008, http://www.karlscalculus.org/pdf/lagrange.pdf, whose contents and disclosure are wholly incorporated by reference as if fully set forth herein, describes Lagrange multiplier in detail.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with a system, apparatus, or device running an instruction.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with a system, apparatus, or device running an instruction.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may run entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which run via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which run on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more operable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be run substantially concurrently, or the blocks may sometimes be run in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Number | Name | Date | Kind |
---|---|---|---|
20030148761 | Gaal | Aug 2003 | A1 |
20080035784 | Meserole et al. | Feb 2008 | A1 |
20080103751 | Hsiung et al. | May 2008 | A1 |
20080114707 | Steiner | May 2008 | A1 |
20080175161 | Amemiya et al. | Jul 2008 | A1 |
20100063715 | Wynter et al. | Mar 2010 | A1 |
20100235077 | Chan | Sep 2010 | A1 |
20100253542 | Seder et al. | Oct 2010 | A1 |
20110004496 | Erb | Jan 2011 | A1 |
20120010803 | Min et al. | Jan 2012 | A1 |
20120056758 | Kuhlman et al. | Mar 2012 | A1 |
Entry |
---|
Newell, C.J., et al., “Appendix A.2: Statistical Trend Analysis Methods,” Feb., 2007, Air Force Center for Environmental Excellence, AFCEE Monitoring and Remediation Optimization System Software, Version 2.2, pp. A.2-1 to A.2-11. |
Jain, A.K., et al., “Data Clustering: A Review,” ACM Computing Surveys, Sep. 1999, vol. 31, No. 3. |
Gerstman, B., “15: Regression,” Mar. 2004, http://www.sjsu.edu/faculty/gerstman/StatPrimer/regression.pdf. |
Murphy, K. P., “Linear regression,” Mar. 13, 2007, pp. 1-34. |
Feijen, W., et al., “The Binary Search Revisited,” AvG127/WF214, 1995, http://www.mathmeth.com/wf/files/wf2xx/wf214.pdf. |
Hahn, K., “Lagrange Multiplier Method for finding Optimums,” 2008, http://www.karlscalculus.org/pdf/lagrange.pdf. |
Alford, B., et al., “An Analysis of Various Spline Smoothing Techniques for Online Auctions Amsc 689,” Dec. 2004. |
Number | Date | Country | |
---|---|---|---|
20120010803 A1 | Jan 2012 | US |