Appeal 2007-2127
Reexamination Control No. 90/006,621
two (or more) sets of instructions are executing at some point between their
start and end points (either at the same time if each set of instruction has its
own processor or by taking turns executing on a single processor), as in the
top figure, not just that the sets of instructions execute closely in time. In the
1982 application (and all later applications because they share the same
"Detailed Description"), the editor executes until it is completely finished, so
the compiler can never execute at the same time as the editor even if another
CPU was available. And, when the compiler executes, the editor is not
executing because it is not at some point between its beginning and end.
That is, the editor and compiler do not take turns executing successive
incremental portions of their subtasks.
c. Since editor is not interruptible, it is not a thread
The '604 patent's definition of "multithreading" requires "preemptive
time-sliced execution of a plurality of threads of instructions located within
the same software program," which requires that a plurality of threads are
subject to "preemptive time-sliced execution"; i.e., a plurality of threads are
capable of being preempted (they are "interruptible") to execute for a fixed
timeslice. While we find that one of ordinary skill in the art would interpret
a "plurality of threads" to mean "all of the threads," it is sufficient to decide
this appeal that two or more threads have to be preempted. Patent Owner's
definition of "thread" requires that "when interrupted, a thread's context
must be saved and retrievable when a thread is reassigned control of the
CPU and resumes execution." Thus, the attributes of the "plurality of
threads" in a "preemptive time-sliced multithreading" environment are:
73
Page: Previous 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 Next
Last modified: September 9, 2013