Pre-Grant Publication Number: 20070220238
Collaborate on the process of community review for this application. Posting will not be forwarded to the USPTO.
Flagging a post as an ACTION ITEM signals further research. Flagging SPAM and ABUSE helps to manage discussion.
Placing double brackets around a reference to a claim or prior art will create a hyperlink to the original
ex. [[claim 1]] and [[prior art 2]].
Facilitator's Comment 
Action Item Show without Noise
0 days left
As a technical professional, I had opportunity to observe a 45 gigabyte file copy from one drive to another on the same machine using Windows Vista Home Basic. Total time was about 65-70 minutes.
During that time, my friend and I passed the time adjusting the base process priority that was executing the copy of files, seeing if raising or lowering would affect the estimated copy time.
We did determine that changing the priority of the process did not change the estimated time by any great amount, but running other programs on the machine had significant effects on the estimated time to complete the copy.
I consider this patent to have been invalidated by considerable prior art available in many venues of computing for at least the last ten years.
Naming this process "interpolation" seems less appropriate then "extrapolation." For example, assume that the baseline machine completed step 1 of a multi-step install in 5 minutes, with step 1 representing 10% of the total multi-step baseline install time of 50 minutes. If subsequently an install is undertaken on some customer's machine and that machine requires 10 minutes to complete step 1, it will be credited with having completed 10% of the install. Implicitly, the process described in this patent will extrapolate from step 1 experience on the customer's machine that the customer's machine will complete the remaining steps in twice the time as the baseline machine.
The advantage of this relativistic process is that the software supplier can create one baseline using some particular machine, but then apply it to many other machines with varied performance characteristics. The potential weakness is that differences in machine configuration or environmental factors can interfere with the extrapolation process. For example, it may be that "step 1" is particularly I/O intensive (or compute intensive or load sensitive), and that the baseline machine and customer machines differ in respects that particularly apply to the early steps, in which case the linear extrapolation will suffer by being too optimisitic or pessimistic.
Note that the process does not depend on any reference to customer machine performance – e.g. tracking number of I/O's per unit of time, CPU load, etc. Consequently, granting this patent would presumably not foreclose other sorts of techniques to forecast wall clock completion.
However, upon more careful examination, the claims do appear to relate specifically to making finely-granulated time estimates by directly interpolating empirically-obtained baseline times, without regard to the actual operations performed by each step. This would exclude algorithmically-determined estimates, like copy progress bars, as well as estimates produced by the Windows OS installer, for example, which are not interpolated even though they calculate a time estimate at each quantum boundary.
It would further appear that the present application does not foreclose the possibility of decimating lengthy single-step operations into arbitrary sub-steps to obtain a smaller and more uniform time quantum per visually-reflected step. In other words, local changes to the underlying quantum of work would appear to obtain similar (albeit rougher) results by a different method, without infringement.
If so, this application is nowhere near as alarming to me.
Various HTML browsing applications, including Internet Explorer and Netscape Communicator, have also employed similar indicators prior to the filing of this patent. These systems used various quantums for updating their progress indicators, the most notable being fixed octet increments that can be found to correspond to the instant patent's broad claim of "points" in a "cumulative point baseline."
In light of the above, it would appear the second independent claim (9) and its children are immediately invalidated by prior art. Since the first independent claim is a direct generalization of the second independent claim, it is automatically invalidated by contradiction of claim 9 (a computer is a signal bearing medium covered by the first claim). The third independent claim (17) is, likewise, not actually independent and is invalidated by same.
Surely the patent examiner will reference something similar to the above. Reading garbage like this makes me pity the poor people who have to read this kind of nonsense for a living.
I imagine this would constitute prior art. I'm sure there is prior art before me as well.
See screen shot here:
http://img.skitch.com/20071230-xw5qfq9dwb97b5rb86t73i9q5h.jpg
Discussion of game here:
http://ballyalley.classicgaming.gamespy.com/ballyalley/two_astrocade_pd_programs.html
How to Use Progress Bars
Sometimes a task running within a program might take a while to complete. A user-friendly program provides some indication to the user that the task is occurring, how long the task might take, and how much work has already been done. One way of indicating work, and perhaps the amount of progress, is to use an animated image.
JProgressBar
A visible component to graphically display how much of a total task has completed. See Using Determinate Progress Bars for information and an example of using a typical progress bar. The section Using Indeterminate Mode tells you how to animate a progress bar to show activity before the task's scope is known.
ProgressMonitor
Not a visible component. Instead, an instance of this class monitors the progress of a task and pops up a dialog if necessary. See How to Use Progress Monitors for details and an example of using a progress monitor.
ProgressMonitorInputStream
An input stream with an attached progress monitor, which monitors reading from the stream. You use an instance of this stream like any of the other input streams described in Basic I/O. You can get the stream's progress monitor with a call to getProgressMonitor and configure it as described in How to Use Progress Monitors.
http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html
http://en.wikipedia.org/wiki/Progress_bar
http://www.webappers.com/progressBar/
attempt to patent something that has been in use since the middle 1960's.
1. Estimate time of completion etc.
2. At pre-defined periods, based on progress so far and knowledge about the application - re-estimate progress.
Am I missing something?
The idea is rather obvious - but just to re-enfoce this: Consider for example estimating the completion time of a race on a circuit. At lap zero, the estimate is the number of laps of the race by some average recorded lap top for the same type of competitors on the circuit. As the race progresses, for various reasons the lap times may be different from the average. Using one of various possible algorithms, which depend on your typical data set, you would modify your completion time based on progress so far. Whist selection of the appropriate time modification algorithm is a significant problem to solve (and is not being claimed in this patent) the concept of feeding back progress to your time estimate is obvious and a necessary component of any real progress indicator.
So - I feel this patent should fail on the "Obviousness" test.
It should also fail due "Prior Invention" since there are many existing tools that implement this approach - most obviously, network transfer indicators that update themselves as the network speed changes. I have written at least two tools that implement the basic scheme myself (through since I am outside the U.S. they do not count).
wage demand.