Ex Parte Ault et alDownload PDFBoard of Patent Appeals and InterferencesMar 27, 201212061719 (B.P.A.I. Mar. 27, 2012) Copy Citation 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 Copy with citationCopy as parenthetical citation