Ex Parte Ault et al

Board of Patent Appeals and Interferences

Mar 27, 2012

12061719 (B.P.A.I. Mar. 27, 2012)

UNITED STATES PATENT AND TRADEMARK OFFICE
________________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
________________

Ex parte DONALD F. AULT, JOSE R. CASTANO,
JEFFREY P. KUBALA, ROBERT J. MADDISON,
BERNARD R. PIERCE, GARY S. PUCHKOFF,
PETER J. RELSON, ROBERT R. ROGERS,
DONALD W. SCHMIDT, and LESLIE W. WYMAN
________________

Appeal 2011-007616
Application 12/061,719
Technology Center 2100
________________

Before ELENI MANTIS MERCADER, BRADLEY W. BAUMEISTER,
and DENISE M. POTHIER, Administrative Patent Judges.

BAUMEISTER, Administrative Patent Judge.

Opinion Concurring-In-Part filed by POTHIER, Administrative Patent
Judge.

DECISION ON APPEAL

Appeal 2011-007616
Application 12/061,719

2
SUMMARY
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejections of claims 1-14 and 16-60:
(I) Claims 1-9, 16-30, 33-39, and 42-491 stand rejected under 35 U.S.C.
§ 112, ¶ 2, as being indefinite;
(II) Claims 1-7, 9-14, 16-19, and 21-602 stand rejected under 35 U.S.C.
§ 103(a) as obvious over Kranich (US 6,651,163 B1; Nov. 18, 2003)
in view of Hoffman (US 4,394,727; July 19, 1983); and
(III) Claims 8 and 20 stand rejected under 35 U.S.C. § 103(a) as obvious
over Kranich in view of Hoffman and Chellis (US 2002/0120744 A1;
Aug. 29, 2002).

1 The Examiner initially set forth multiple rationales for why claims 1-14,
16-39, and 42-50 stand rejected under 35 U.S.C. § 112, ¶ 2 (Final Rejection,
mailed June 22, 2010). The Examiner subsequently withdrew three
rationales for the § 112, ¶ 2, rejections respectively with respect to (1)
claims 1, 33, 35-39, 42, 44, and 45; (2) claims 46-50; and (3) claims 31-32
(Ans. 3). The heading of the Examiner’s Answer’s §112, ¶ 2, rejection then
states that claims 1-14, 16-30, 33-39, and 42-60 remain rejected (Ans. 4), but
the body of the rejection does not address each of these claims (Ans. 4-5).
The Response section of the Examiner’s Answer provides another overview,
reiterating that “[c]laims 1-14, 16-30, 33-39, 42-60 remain rejected under
35 U.S.C. 112” (Ans. 19). Alternatively, the body of the Response to
Arguments section lists only claims 1-8, 33-39, and 42-49 in relation to the
first remaining basis of rejection and only claims 9 and 16-30 in relation to
the second remaining basis of rejection (Ans. 20-21). Accordingly, we
understand the remaining indefiniteness rejections to apply to only claims 1-
9, 16-30, 33-39, and 42-49 (Ans. 19; Reply Br. 2).
2 The Examiner’s Answer inconsistently sets forth that the rejection over
Kranich and Hoffman applies to (1) claims 1, 3, 5-14, 16, 19-31, 33, 37-40,
and 42 (Ans. 5); and (2) claims 1-7, 9-14, 16-32, 34, and 36-60 (Ans. 5-18).
The Examiner subsequently confirms (Office Communication, mailed
February 16, 2001) that claims 1-7, 9-14, 16-19, and 21-60 are rejected.
Appellants also include these claims in the rejection. See App. Br. 16.
Appeal 2011-007616
Application 12/061,719

3
STATEMENT OF THE CASE
Appellants’ Abstract describes their invention as follows:
Exemplary embodiments include a system and storage
medium for managing computer processing functions in a
multi-processor computer environment. The system includes a
physical processor, a standard logical processor, an assist
logical processor sharing a same logical partition as the
standard logical processor, and a single operating system
instance associated with the logical partition, the single
operating system instance including a switch-to service and a
switch-from service. The system also includes a dispatch
component managed by the single operating system instance.
Upon invoking the switch-to service by standard code, the
switch-to service checks to see if an assist logical processor is
online and, if so, it updates an integrated assist field of a work
element block associated with the task for indicating the task is
eligible to be executed on the assist logical processor. The
switch-to service also assigns a work queue to the work element
block.
Independent claim 1 is illustrative of the claimed subject matter:
1. A system for managing computer processing functions in
a multi-processor computer environment, comprising:
at least one standard processor;
at least one assist processor;
a single operating system instance associated with said
standard processor and said assist processor, said single
operating system instance including a dispatch component; and
a switch-to service operable upon being invoked for
updating an integrated assist field of a work element block
associated with a task running on said standard processor to
indicate that the task is eligible to be dispatched by said
dispatch component for execution on said assist processor when
the task is next dispatched for execution on a processor,
whereby execution of the task is switched from said standard
processor to said assist processor upon dispatching of the task
for execution on the assist processor.
Appeal 2011-007616
Application 12/061,719

4
THE 35 U.S.C. § 112, ¶ 2, REJECTIONS
I.
The Examiner finds claims 1-8, 33-39, and 42-49 to be indefinite
because the claims recite the term “operable” (Ans. 4, 20) (see, e.g., claim 1
(reciting “a switch-to service operable upon being invoked for updating an
integrated assist field . . . ”)). The Examiner concludes
[the term “operable”] renders the claim[s] indefinite because it
is unclear whether [the switch-to service] can actually perform
the function of updating the assist field. Thus [the switch-to
service] cannot switch execution of a task from one processor to
another. In contrast, using a term such as “configured to”
would make the claim definite.
Ans. 4. The Examiner further clarifies the position in the Response section
of the Examiner’s Answer.
[The term “operable”] merely suggest that the switch-to service
is merely capable of performing the function of updating the
assist field of the work element block. Therefore, since the
assist field of the work element block is not actually updated,
the execution of a task cannot be switched from said standard
processor to said assist processor.
Ans. 20.
Appellants contend inter alia that “there is nothing improper with
characterizing a structural element as ‘merely’ being capable of performing
a specified function, nor is it clear why the ‘configured to’ alternative
suggested by the Examiner would be construed any differently in this
respect” (Reply Br. 3).
Appellants’ arguments are persuasive. We find nothing about the
claim term “operable” that would, in the present context, raise a reasonable
question as to the objective metes and bounds of the cited claims. The
Examiner acknowledges that “[t]he term “operable” . . . suggest[s] that the
Appeal 2011-007616
Application 12/061,719

5
switch-to service is merely capable of performing the function of updating
the assist field of the work element block” (Ans. 20). We find the meaning
of such a requirement to be sufficiently clear. Appellants are entitled to
claim their invention broadly. We need not determine whether the term
“operable” is broader than the alternative term suggested by the Examiner,
“configured.”
II.
The Examiner rejects claims 9 and 16-30 as indefinite because “it is
not clearly understood of what is meant by ‘invoking a switch-to service by
code running as a task’” (Ans. 4, 20-21). The Examiner concludes that it is
not reasonably clear whether the recited task corresponds to code running as
a task (Ans. 4) because one of ordinary skill would understand that “code”
and “task” are two different thing (Ans. 20-21).
Appellants respond
There can be no serious uncertainty about the antecedent
for “said task” claims 9 and 16. As a matter of form, the
antecedent for “said task” in the phrase “code running as a task”
is clearly the task that the code is running as, not the code that
is running as a task. However, it hardly matters in this context
which of these terms “said task” refers back to, as the code is
the physical means for running the task. It would be like
arguing, for example, whether a function is performed by a
program or by a CPU executing the program. Here too, the
entities are distinguishable, but no ambiguity results from
considering either of them as the actor. The Examiner has
failed to cite any actual ambiguity in the claimed subject matter
resulting from applicants’ language, nor is any apparent.
Reply Br. 4-5 (emphases omitted).
Appellants’ arguments are persuasive. We find it reasonably clear
that the antecedent for “said task” in the phrase “code running as a task” is
Appeal 2011-007616
Application 12/061,719

6
the task that the code is running as. The Examiner has not established that
the metes and bounds of the cited claims lack reasonable clarity.

THE 35 U.S.C. § 103(A) REJECTIONS
Contentions
The appealed claims include seventeen independent claims: claims 1,
9, 16, 31, 33, 35-40, 42, 44-46, 48, and 50. We understand the Examiner’s
position to be that Kranich discloses all of the limitations of each of the
independent claims (Ans. 5-15) except for “a work element block having a
field for indicating whether a task is eligible” (Ans. 6 (emphasis omitted)).
The Examiner finds that Hoffman teaches this feature, though, and that
motivation existed to combine the references’ teachings (id.).
Appellants assert that all of the independent claims
contain the common recitation of updating an integrated assist
field (306) of a work element block (300) associated with a task
(118) to indicate that the task is eligible to be dispatched for
execution on an assist (or second) processor (108) when it is
next dispatched for execution on a processor, whereby
execution of the task is switched from a standard (or first)
processor (106) to the assist processor upon dispatching of the
task for execution on the assist (or second) processor.
(App. Br. 20-21 (citing claim 31)).
Appellants contend that Kranich does not disclose starting the
execution of a task on a first processor and then switching the execution to a
second processor after the task has already started executing on a first
processor (App. Br. 21-25). Appellants argue that Kranich only discloses
running multi-thread tasks on the two processors in parallel or initiating
individual tasks on the second processor (id.).
Appeal 2011-007616
Application 12/061,719

7
In maintaining that Kranich does contain such a disclosure, the
Examiner explains the following:
Kranich defines “threads” as groups of tasks or instructions
(col. 1, lines 18-22, 46-51) and that “threads” or groups of tasks
can be executed in a serial manner using a single processor
(single-thread) or in a parallel manner using multiple processors
(multi-thread). Additionally, Fig. 3A and 3B; [sic] illustrates
this concept, wherein a master processors [sic] initially executes
all single thread code until it encounters multithreaded
instructions, in response conveys some tasks (to be executed as
thread 2) to a second processor while simultaneously executing
other tasks (as thread 1) (col. 10, line 37-col. 11, line 16).
Therefore, it is evident that some tasks would have to be
switched to the slave processor in order to be executed as thread
2. Further in col. 12, lines 1-2, [sic] includes Wr2Proc
instructions that move data (task data) from the register file of
the master processor to the slave processor.
(Ans. 21-22).
Issues
The main issue before us is whether Kranich discloses or teaches
either a process in which, or an apparatus which causes, a task already
running on a first processor to be switched so as to continue executing on a
second processor.
Resolution of this issue requires first determining the meaning of the
claim term, “task.”
Findings of Fact
The record supports the following Findings of Fact (Fact) by a
preponderance of the evidence:
1. A technical dictionary provides definitions for the following two
computers terms:
Appeal 2011-007616
Application 12/061,719

8
Task – “a stand-alone application or a subprogram that is run as an
independent entity.” MICROSOFT COMPUTER DICTIONARY 512 (5th ed.
2002).
Thread – “In programming, a process that is part of a larger process or
program.” Id. at 518.
2. Kranich discloses the following:
The ICUs 320 of each processor 12 are coupled to thread
control device 300 which facilitates communication between
processors 12A and 12B. In general, one processor 12A serves
as master and the other processor 12B serves as slave. The
master processor 12A runs all single threaded code, sets up and
starts thread execution on the slave processor 12B and
consolidates execution results following thread execution. In
general, processing core 14A executes single threaded code
(block 330) until a multithread setup instruction is encountered.
When processing core 12A encounters a multithread setup
instruction (block 332), processing core 12A conveys thread
setup instructions to ICU 320A which conveys them to FIFO 1
310A. ICU 320B retrieves instructions from FIFO 1 310A and
transfers them to processing core 14B. Subsequently, master
processor 12A conveys a thread 2 startup instruction (block
334) to ICU 320A which places the instruction into FIFO 1
310A. ICU 320B retrieves the thread startup instruction from
FIFO 1 310A and transfers it to processing core 14B.
Processing core 14B then begins fetching and executing the
thread 2 code (block 338). Upon execution and retirement of a
JOIN instruction (blocks 340 and 342) by both processors 12,
slave processor 12B terminates execution of thread 2 and single
threaded execution resumes with master processor 12A. Master
processor 12A may then convey another instruction to
processor 12B which causes slave processor 12B to convey
thread 2 execution results to master processor 12A via FIFO
310B. Master processor 12A may then consolidate execution
results from the separate threads (block 344) and continue
normal execution (block 346). To summarize, master processor
12A sets up a second thread for execution on slave processor
12B. Both the master 12A and slave 12B processors execute
Appeal 2011-007616
Application 12/061,719

9
threads in parallel. Master processor 12A then obtains the
second thread execution results from the slave processor.
(col. 10, l. 49 – col. 11, l. 16; see also Figs. 3A-B).
Analysis
We start our inquiry by determining the meaning of the claim term,
“task.” Neither of Appellants’ Briefs nor the Examiner’s Answer sets forth
any express definition for this term. We therefore look to a technical
dictionary of computers terms, which defines a “task” as “a stand-alone
application or a subprogram that is run as an independent entity” (Fact 1).
Based upon this definition, we next look to see if Kranich discloses
either a process in which, or an apparatus which causes, a task already
running on a first processor to be switched so as to continue executing on a
second processor. That is, does Kranich take a stand-alone application or
subprogram that is already running as an independent entity on a first
processor and switch the assigned processor mid-execution so that the
application or subprogram continues to run on a second processor?
We conclude that the Examiner has not established that Kranich
discloses either such a process or, alternatively, an apparatus containing such
functionality. The independent claims require that the task that is to be
switched to the assist processor must first be already running on the primary
processor. Kranich does disclose threads, and we find it reasonable to
generally interpret the claim term “task” as reading on a thread (Fact 1). In
Kranich, though, when a processing core encounters a multithread setup
instruction, “a master processor 12A sets up a second thread for execution
on a slave processor 12B. Both the master 12A and slave 12B processors
execute threads in parallel. Master processor 12A then obtains the second
thread execution results from the slave processor” (Fact 2). That is, the
Appeal 2011-007616
Application 12/061,719

10
single thread running on the slave (or “assist”) processor cannot be deemed
to correspond to the claimed “task” because this thread first starts running on
the slave processor – not on the master processor.
Nor does the claimed “task” read on the combination of Kranich’s
thread, which is running on the slave processor, together with the associated
thread setup instructions, which run on Kranich’s master processor. By
definition, the thread setup instructions are not part of the thread that is to be
executed on the second processor. Rather, we find it more reasonable to
interpret these two threads as distinct tasks.
Even assuming arguendo that it would have been generally reasonable
to interpret these two distinct threads as corresponding to a single “task,”
these two threads of Kranich still would not satisfy the requirements of the
independent claims. The claims require that the task or thread running on
the standard or master processor be what invokes the switch-to service, and
the switch-to service, in turn, is what causes the claimed task to switch from
running on the first processor to running on the second processor. That is,
the claimed “task” must be running before the switching instructions start.
As such, Kranich’s setup instructions cannot constitute the first portion of
the claimed “task.” Some other task would have to first execute on the
master processor in order to initiate the set-up instructions. To interpret the
term “task” as the set-up instructions would be tantamount to ignoring the
limitation of “switch-to service” because the instructions, in part, instruct the
switching of a task that is already running.
Finally, it is not reasonable to interpret the combination of all of
Kranich’s multithreads, which run in parallel on the master and slave
processors, as reading on the claimed task (Ans. 21-22). As argued by
Appeal 2011-007616
Application 12/061,719

11
Appellants (App. Br. 21-25), running threads in parallel does not constitute
switching the execution of a thread from one processor to another. Running
threads in parallel instead constitutes sharing the processing resources.
For the foregoing reasons, Appellants have persuaded us of error in
the Examiner’s obviousness rejection of each of independent claims 1, 9, 16,
31, 33, 35-40, 42, 44-46, 48, and 50. Accordingly, we do not sustain the
Examiner’s rejection of those claims, or of claims 2-7, 10-14, 17-19, 21-30,
32, 34, 41, 43, 47, 49, and 51-60 which depend from these claims.
With respect to the remaining rejection of dependent claims 8 and 20,
Chellis does not cure the deficiency of the obviousness rejection explained
above. Accordingly, we likewise do not sustain the rejections of these
claims.

CONCLUSIONS
We do not sustain the Examiner’s rejection of claims 1-9, 16-30, 33-
39, and 42-49 under 35 U.S.C. § 112, ¶ 2.
We do not sustain the Examiner’s rejections of claims 1-14 and 16-60
under 35 U.S.C. § 103.

DECISION
The Examiner’s decision rejecting claims 1-14 and 16-60 is reversed.

REVERSED

Appeal 2011-007616
Application 12/061,719

12
POTHIER, Administrative Patent Judge, CONCURRING-IN-PART.
I concur with the Majority’s decision concerning the indefiniteness
rejection under 35 U.S.C. § 112, second paragraph, but write separately to
dissent on the obviousness rejections under 35 U.S.C. § 103. Particularly, I
disagree that Kranich fails to teach or suggest “a switch-to-service . . . with a
task running on said standard processor . . . whereby execution of the task is
switched from said standard processor to said assist processor upon
dispatching of the task for execution on the assist processor” as recited in
independent claim 1 and similarly recited in other independent claims.
The Majority correctly indicates (see Op. 7) that the main issue in this
case first requires us to determine what the broadest reasonable construction
of the recited “task” is. While Appellants point to element 118 as a task (see
App. Br. 6), Appellants do not define a task in the disclosure (see generally
Spec.). Nor do Appellants sufficiently explain what a task is in the Briefs.
See App. Br. 22-25; Reply Br. 5-8. Also, the disclosure distinguishes
between tasks, processes, and work in some passages (see Spec. ¶ 0019) and
uses the terms, work and task, interchangeably in other portions (see Spec. ¶
0031). Appellants further state that Kranich’s thread 1 code 336 and thread
2 code 338 are separately executed in arguing that these threads are separate
tasks (see App. Br. 24-25) and, thus, indicate that a thread or process can be
a task. Thus, I accept the Majority’s definition of “task” as a stand-alone
application or a subprogram that runs as an independent entity (see FF 1) to
be a reasonable and customary meaning of the term. See Op. 8 (citing
MICROSOFT COMPUTER DICTIONARY (5th ed.)). Additionally, since a
subprogram can be a group of processes, threads, or instructions, the recited
Appeal 2011-007616
Application 12/061,719

13
“task” may include not only a single thread but also multiple processes,
threads, or instructions that collectively define a function.
Kranich discusses that the master processor 12A conveys thread setup
instructions and thread 2 startup instructions at block 334, after encountering
a multithread setup instruction at block 332. See FF 2. The startup
instruction is then retrieved by the processing core 14B of the slave
processor 12B. See id. These setup and startup operations for thread 2
perform separate operations from the execution of thread 1 running on the
master processor or the execution of thread 2 running on the slave processor.
See id. Kranich further states that the processor core 14B of the slave
processor 12B also begins to fetch the thread 2 code at block 338. See id.
Thus, Kranich teaches and suggests a function for setting up or starting a
thread (e.g., thread 2) that involves multiple processes (e.g., a task of setting
up thread 2 for operation). See id.
More specifically, Kranich discusses that the master processor sets up
a second thread for execution (e.g., thread 2) on the slave processor by
conveying Wr2Proc instructions to the slave processor 12 B, which moves
data from a register file of the master processor to the slave processor. See
FF 2; see also col. 11, l. 66 – col. 12, l. 8; Ans. 22 (discussing Wr2Proc
instructions). Additionally, Kranich discusses a Fork instruction (i.e., FORK
Thread2Addr in Fig. 3B at step 334) that is conveyed by the master
processor to the slave processor and is used to fetch the instructions for the
second thread from the thread address conveyed by the Fork instruction.
Col. 12, ll. 2-8. Also, MICROSOFT COMPUTER DICTIONARY (5th ed.) defines
“fork” as “[t]o initiate a child process in a multitasking system after a parent
Appeal 2011-007616
Application 12/061,719

14
process has been started.”3 As such, Kranich’s FORK Thread2Addr
instruction, which is part of the function of setting up thread 2 for execution,
teaches and suggests a sub-operation that begins as a parent process running
on the master processor and then initiates a child process on or switches to
the slave processor to continue setting up thread 2 for execution.
Kranich therefore discloses at least two processes (e.g., Wr2Proc and
Fork instructions) that collectively are part of the setup task for thread 2’s
operation that begin on the master processor and move to the slave processor
for further set up operations. See col. 11, l. 66 – col. 12, l. 8. Contrary to
Appellants’ contentions (see App. Br. 23-25), Kranich therefore teaches and
suggests that this “task” of setting up thread 2 for operation starts on a
master processor (e.g., a standard processor) and moves to a slave processor
(e.g., an assist processor) or switches from one processor to another while
performing the setting up thread 2’s processes.
These setup routines discussed above also run independently of other
operations (e.g., threads 1 and 2) as shown in Figure 3. Furthermore,
concluding that Kranich’s setup and startup routines are a task is not
“tantamount to ignoring the limitation of ‘switch-to-service’ . . . .” Op. 10.
Rather and as explained above, Kranich’s Multi Thread Setup instruction
332 commences the switch-to-service (see col. 10, ll. 56-65), and the
switching of a task for setting up and starting up a thread (e.g., thread 2)
from the master to the slave processor is a separate function from the actual
thread setup and startup operations. Also, Appellants’ switch-to-service
operates in a similar manner and is invoked by a code or instruction. See

3 MICROSOFT COMPUTER DICTIONARY (5th ed.) 221 (second definition).
Appeal 2011-007616
Application 12/061,719

15
Spec. ¶¶ 0009, 0026 (indicating the switch-to-service is invoked by a
standard code).
Lastly, I respectfully disagree with the Majority that claim 1 requires
that the task running on the standard processor be what invokes the switch-
to-service. See Op. 10 (stating “[t]he claims require that the task or thread
running on the standard or master processor be what invokes the switch-to-
service . . . ”). Rather, claim 1 recites
a switch-to-service operable upon being invoked for
updating an integrated assist field of a work element block
associated with a task running on said standard processor . . .
whereby execution of the task is switched from said standard
processor to said assist processor upon dispatching of the task
for execution on the assist processor
(emphases added). As emphasized above, claim 1 states the switching of the
switch-to-service occurs upon dispatching the task for execution on the
assist processor – not upon running of the task on the standard processor.
I therefore agree with the Examiner (see Ans. 5-6, 22) that Kranich
teaches and suggests some tasks are switched to the slave processor in order
to set up and start up thread 2 for execution or “a switch-to-service . . . with
a task running on said standard processor . . . whereby execution of the task
is switched from said standard processor to said assist processor upon
dispatching of the task for execution on the assist processor” as recited in
claim 1. Independent claims 9, 16, 31, 33, 35, 36-40, 42, 44-46, and 48 have
limitations similar to the above-quoted language. For the above reasons,
Kranich also teaches and suggests these similar limitations found in those
claims. Also, notably, independent claim 50 differs in a scope from the
other independent claims and fails to recite switching the execution of task
Appeal 2011-007616
Application 12/061,719

16
from a standard processor to an assist processor, but only that “the work
element block [is] to be queued for execution on the assist processor.”

babc