DETAILED ACTION
Claims 1-9 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 5, 2024, has been entered.
Notes
The examiner again requests that applicant formally submit only black font color going forward. Anything that is not in true black (e.g. applicant’s amendments to the claims) is converted to a lower-quality, pixelated version, which is harder to read and which, at times, doesn’t lend itself to good optical character recognition. This could result in increased examining time and/or potential misprinting in the issued patent. As such, even if applicant wishes to use different coloring for their own purposes, the examiner asks that applicant have an all true black and white version for formal submission. “In order to enhance readability of electronic submissions, the USPTO strongly recommends use of a black colored font for text on a white background” (MPEP 608.01). Also, see 37 CFR 1.52(a)(1)(v).
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections/Recommendations
Claim 1 is objected to because of the following informalities:
In part d, line 2, delete “processor” from before “contents” to match language in part c, line 1.
In part e, lines 2 and 5, delete “processor” from before “contents” to match language in part c, line 1.
In part e, lines 2 and 5, replace “processor second” with --second processor--.
In part f, replace “processor second” with --second processor--.
In part f, remove “processor” from before “contents”.
Claim 2 is objected to because of the following informalities:
The examiner asserts that it is not the hardware result register per se that is pushed onto the stack, but the result in the result register (from claim 1, part e). Please amend to clarify this.
Claim 3 is objected to because of the following informalities:
In line 2, insert --software-- before “parameters” to match claim 1.
In line 2, delete “to”.
In line 3, insert --processor-- after ‘second”.
In line 5, insert --software-- after “more”.
In claim 3, the examiner recommends replacing each instance of “is directly” with the correct one of --comprises pushing directly-- and --comprises popping directly--.
Claim 5 is objected to because of the following informalities:
In line 1, insert --processor-- before “method”.
Claim 7 is objected to because of the following informalities:
Replace both instances of “serial processor” with --processor serial-- to match language in claim 5.
Appropriate correction is required.
Claim Interpretation
Claim 6 recites that the first and second stacks are in substantially simultaneous operation. From paragraphs [0060] and [0099], “substantially simultaneously” in this context is interpreted to mean that there is at least some overlap in time of the operation of the first and second stacks.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-9 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Referring to claim 1, parts b-c set forth that each stack has its own processor control and processor registers. The control is now claimed to include a base register and a limit register. Thus, applicant is claiming that each stack has its own base register (first register), limit register (second register), and processor registers (at least two more registers). Thus, each stack is claimed to have at least four registers. However, FIG.10 shows only three registers per stack. Each stack has a base register and limit register, but does not contain other plural registers. Thus, claiming that each stack has multiple processor registers in addition to its control including base and limit registers is deemed to be new matter not supported by the original disclosure. Applicant can either amend or point the examiner to the relevant support.
All dependent claims are rejected due to their dependence on a claim lacking adequate written description.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-9 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The claims recite the following limitations for which there is a lack of antecedent basis:
In claim 1, part d, line 1, “the one or more processor parameters”. Does applicant instead mean --the one or more software parameters-- from part b?
In claim 1, part f, “the processor contents of all the processor registers”. Applicant only previously set forth contents of the plurality of registers (part c, line 1) and did not set forth contents of registers of the first stack (parts b-c), nor contents of registers of the second stack (parts b-c). The examiner recommends replacing “the processor registers” in part f with --the plurality of registers--.
In claim 3, last three lines, “the contents of all the processor registers” for similar reasoning. The examiner again recommends replacing “the processor registers” with --the plurality of registers--.
All dependent claims are rejected due to their dependence on an indefinite claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-8 are rejected under 35 U.S.C. 103 as being unpatentable over Takayama et al., U.S. Patent No. 6,212,630, in view of McAuley, U.S. Patent No. 5,187,799, Tremblay et al., U.S. Patent No. 6,138,210, and the examiner’s taking of Official Notice. Furthermore, Venners (“Inside the Java Virtual Machine”) is cited as extrinsic evidence showing how various stack portions would be used in Tremblay.
Referring to claim 1, Takayama has taught a processor method comprising:
a) invoking a call operation in software (see FIG.11, instruction 121, where the main function calls function f);
c) pushing contents of a plurality of processor registers onto a second processor stack (see FIG.11, instruction 122, which stores/pushes contents of registers R2 and R3 to a stack (see the stm- instruction in FIG.6)) the second processor stack having its own unique processor control and processor register (see FIGs.5 and 11 and note the stack pointer (SP) register, which points to the top of the stack to indicate where to push to (or pop from). The unique control would include at least instructions that indicate SP so as to uniquely address this stack, as well as signals to the hardware itself);
e) performing processor-register-to-processor-register operations on the plurality of processor registers whose processor contents were pushed onto the processor second stack, and storing a result of the processor-register-to-processor-register operations in a processor result register (see FIG.11 and note the add instructions, in code block 125, that are processor-register-to-processor-register operations involving registers R2 and R3, whose contents were pushed to the stack by instruction 122. A result of the operations is stored in result register R0 by the last add instruction block 125);
f) popping off the processor second stack the processor contents of all the processor registers of the second stack into their respective processor registers from which they came (see FIG.11, instruction 128. R2 and R3 are restored with the previously-pushed contents of R2 and R3. Note the description of the ldm instruction in FIG.7); and
g) returning processor control to an instruction following the call operation in software (see FIG.11, instruction 129. Note the description of this return instruction in FIG.6, which returns to the instruction following the call (located at PC+4, which was stored in the link register (LR)) (FIG.6 and column 1, lines 45-49)).
Takayama has not taught the second stack having its own processor registers (plural), wherein the second processor stack control comprises a base register and a limit register. As stated above, only one register (stack pointer (SP)) is taught. However, McAuley has taught a base register (TB) and a limit register (TT) and that these two registers can be used to set the top and bottom boundaries of a stack so as to detect underflow and overflow errors when an access outside of the boundaries occurs (see column 9, lines 15-32, and FIG.8). As a result, in order to detect and handle faults (and potential security concerns) resulting from popping and pushing data outside of defined stack boundaries, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Takayama such that the second processor stack control comprises a base register and a limit register. After modification, a stack will have its own processor registers (e.g. base register, a limit register, and a stack pointer register).
Takayama has also not taught b) pushing one or more software parameters onto a first processor stack, the first processor stack having its own unique processor control and processor registers, where the second processor stack control and processor registers are independent of the first processor stack control and processor registers. However, the examiner first notes that one of ordinary skill in the art understands that code can be written in many different ways to accomplish the same task. If you put many programmers in a room to write a program to accomplish task X, the many different programs could reasonably be expected. For example, FIG.11 of Takayama shows performing some work (including obtaining values from memory at global addresses i0, i1, i2, and i3) in function f. However, this work could alternatively be shifted into the main function and then the main function could pass the values to function f to realize the same final result as original FIG.11. Such would be recognized by one of ordinary skill in the art as substitutable with predictable results, i.e., function f still adds four values together as originally intended (it is simply a matter of which function obtains the values). Furthermore, this would be recognized as a mere re-arrangement of software parts (shifting functionality from one function to another) without modifying the system’s realization of the desired end result. Such re-arrangement is deemed a routine expedient and not a patentable distinction, particularly absent some demonstration of criticality of the re-arrangement (see MPEP 2144.04, including section (VI)(C)). As a result, it would have first been obvious to modify Takayama to re-arrange parts of the code such that the retrieval of values at addresses i0, i1, i2, and i3, is moved from function f to the main function.
Given this modification, there needs to be a way to send the retrieved results from the main function to function f. Tremblay has taught passing parameters to a function via a stack (e.g. stack 310, in portion 432 of Tremblay’s FIG.4B) that is separate from the operand stack (e.g. stack 320, in portion 434 of FIG.4B), which is used during processing of the function. See the abstract and FIGs.4A-B and their descriptions, for instance. Note, from column 2, lines 15-18, this is explained in the context of JAVA, and Venners (see attached) explains the different types of stack portions for JAVA, with the operand stack being the workspace for the function (see pp.4-5). As a result, in order to pass parameters from the main function to function f for an obvious re-arrangement of Takayama’s code in FIG.11, and in a manner that allows for simultaneous access to multiple frames in different stacks (see the first paragraph in the detailed description), which may speed up access and, therefore, execution, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Takayama for b) pushing one or more software parameters onto a first processor stack separate from the second stack that is used to store values in R2, R3, and LR by the function.
Furthermore, since the first stack and second stack are different stacks, the first stack would also require its own unique stack pointer register (to track the next entry at which to push/pop a value in only the first stack) and, for reasoning given above, it is also obvious for the first stack’s control to comprise its own base register and limit register (separate from the second stack’s control) to track the stack boundaries for underflow and overflow. Thus, for these reasons, the unique control and registers of each stack would be independent of one another.
To summarize the proposed combination, Takayama’s FIG.11 code would be modified so that the retrieval of values, which is performed by the alternating ld/st sequence at the beginning of block 125 is instead performed by the main function. The following code is an example of what the FIG.11 code could be modified to in order to utilize two stacks (with their respective stack pointers):
main:
…
ld (i0), R0 //obtain 1st parameter from memory address in i0
st R0, (SP_first_stack) //push the obtained value to the first stack
ld (i1), R0 //obtain 2nd parameter from memory address in i1
st R0, (4, SP_first_stack) //push the obtained value to the first stack
ld (i2), R0
st R0, (8, SP_first_stack)
ld (i3), R0
st R0, (12, SP_first_stack)
call- f //this call would adjust SP_second_stack
…
f:
stm- [R2, R3] //push values in R2 and R3 to second stack
st LR //push return address to second stack
ld (SP_first_stack), R0 //pop 1st parameter from first stack into R0
ld (4, SP_first_stack), R1 //pop 2nd parameter from first stack into R1
ld (8, SP_first_stack), R2
ld (12, SP_first_stack), R3
add R1, R0
add R2, R0
add R3, R0
call- g
ld+ LR //pop return address from second stack
ldm [R2, R3] //pop R2 and R3 values from second stack
rts+ //return to instruction after call- f
Takayama, as modified, has further taught the first stack located in processor memory and the second stack located elsewhere in processor memory (the first and second stacks in the combination are different stacks; thus, they cannot physically be in the same memory locations. As such, they are separate in memory. This is also why they require different base, limit, and stack pointer registers);
Takayama, as modified, has further taught wherein the first processor stack control and the second processor stack control are physically different entities from each other (again, in the combination, there are two stacks, each with its own control (including its own base and limit registers) and its own stack pointer register. Thus, they are physically different controls);
With respect to the limitation of the two stack controls being physically different entities “allowing parallel operations on each stack at an exact same time”, this is not patentable for multiple reasons;
First, allowing parallel operation does not mean that the parallel operation actually occurs. Since the proposed combination of prior art implements different, separately-controllable stacks, access to both at the same time is allowed/possible, i.e., the stacks are capable of being operated in parallel because their independence means control of one does not exclude control of the other (this is supported by the first paragraph in the detailed description of Tremblay, which states “In one embodiment of the invention, the conventional stack of the stack-based computing system is divided into multiple stacks to provide simultaneous access to multiple frame components, such as the operand stack and the arguments and local variable area of the current method frame.”
Alternatively, if this limitation were narrow enough to require that parallel operations on each stack actually occur, Takayama, as modified, has not taught this limitation. However, Official Notice is taken that parallelizing independent operations was well known in the art before applicant’s invention. Also well-known is memory with multiple ports and control lines so as to perform multiple memory operations at the same time. One of ordinary skill in the art would have recognized in Takayama, as modified, that there are ways to speed up execution by parallelizing instructions. This can be done, for instance, with a superscalar architecture with multiple load/store units and/or multiple threads. As an example, in the examiner’s modified code example above, the stm- instruction, which stores R2 and R3 to the second stack, could be at least partially performed at the same time as one of the loads into R0 and R1 from the second stack. This would allow for a speed-up in execution, as opposed to executing all instruction serially. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify Takayama such that parallel operations are performed on each stack at an exact same time.
Takayama, as modified, has further taught d) popping off the first processor stack at least one of the one or more processor parameters into at least one of the plurality of processor registers whose processor contents were pushed onto the second processor stack (as, modified, Takayama would pop two values from the first stack into R2 and R3, whose values were previously pushed to the stack in the modified main function);
Takayama has also not taught the processor result register being one of the plurality of processor registers whose processor contents were pushed onto the processor second stack. Instead, R0 was chosen to be the result register (see the last add instruction in code 125). However, one of ordinary skill in the art would have recognized that any register could store the destination, including register R2 and R3, because the contents of either of these is not needed again in function f. The examiner again notes that there are many different ways to write software to accomplish the same task. Official Notice is also taken that a destructive write which writes to a register that is used as an input operand was well known in the art before applicant’s invention. For instance, the three add instructions could instead have been programmed destructively as add R0, R1 (R1 = R0+R1); add R1, R2 (R2 = R1+R2, where R1 = R0+R1 from the first add); and add R2, R3 (R3 = R2+R3, where R2 = R1+R2 from the second add). This sequence performs the exact calculation as the three add instructions in block 125 with the only difference being the result is in R2 instead of R0. One of ordinary skill in the art would clearly recognize the substitutability of these options while receiving the same results. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Takayama such that the processor result register being one of the plurality of processor registers whose processor contents were pushed onto the processor second stack.
Referring to claim 2, Takayama, as modified, has taught the processor method of claim 1, but has not taught between e) and f) pushing the processor result register onto the processor first stack. Instead, Takayama stores the result to memory at address j (see last st instruction in code 125), which occurs between the add instructions (step e) and the popping of R2 and R3 (instruction 128) (step f). However, Official Notice is taken that pushing a result to a stack for access by the calling function was well-known in the art before applicant’s invention (and is supported by Venners, e.g. p.8, 2nd to last paragraph, and also FIG.5-12 and the description thereof). Again, these teachings would have been recognized by one of ordinary skill in the art as substitutable with predictable results, i.e., the result is still obtainable (either through the stack or through address j). As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Takayama for, between e) and f), pushing the processor result register onto the processor first stack.
Referring to claim 3, Takayama, as modified, has taught the processor method of claim 1 wherein the pushing one or more parameters onto the first processor stack is directly onto to the first processor stack; wherein the pushing contents of the plurality of processor registers onto the second stack is directly from the plurality of processor registers to the second processor stack; wherein the popping off the first processor stack at least one of the one or more parameters into at least one of the plurality of processor registers whose contents were pushed onto the second processor stack is directly from the first processor stack to the at least one of the plurality of processor registers whose contents were pushed onto the second processor stack; and wherein the popping off the second processor stack the contents of all the processor registers into their respective processor registers from which they came is directly from the second processor stack to the processor registers from which they came (from FIGs.6-7 the modified operation of FIG.11, stores/pushes and loads/pops occur directly to and from stacks and registers).
Referring to claim 4, Takayama, as modified, has taught the processor method of claim 1 but has not taught wherein the processor-register-to-processor-register operations are performed in a set of parallel processor operations. However, Official Notice is taken that parallelizing operations to increase speed was well-known in the art before applicant’s invention. One of ordinary skill in the art would have recognized that you can also add four numbers together (like Takayama does in FIG.11) by performing R1 = R0+R1 and R3 = R2+R3 in parallel (at the same time, because they are completely independent operations that share no operands/destinations), and then following that with R3 = R1+R3. This would save one instruction cycle since each add in FIG.11 takes one cycle (see FIG.2 and column 1, lines 40-44), thereby causing the adds in block 125 to take as many as three cycles. However, with a set of parallel operations, two instructions execute in one cycle and the third instruction in a second cycle. As a result, in order to increase speed, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Takayama to include multiple ALUs (FIG.5, 14) such that the processor-register-to-processor-register operations are performed in a set of parallel processor operations.
Referring to claim 5, Takayama, as modified, has taught the method of claim 1 but has not taught wherein the processor-register-to-processor-register operations are performed in a plurality of serial processor operations not overlapping in time and in a set of parallel processor operations. However, for similar reasons as set forth for claim 4, it is obvious to parallelize where possible. In addition, while FIG.11 shows an example of adding four numbers, any function could be performed. For instance, the function could add five numbers where necessary. When five numbers need to be added, one of ordinary skill in the art would have recognized the system could perform A = V+W and B = X+Y in parallel. This would then be followed, serially, by C = A+B, which would then be followed, serially, by D = C+Z. Thus, there would be a set of parallel operations at the beginning followed by multiple serial operations. As a result, in order to add five numbers in an efficient manner using the system of Takayama, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Takayama to include two ALUs (FIG.5, 14) such that the processor-register-to-processor-register operations are performed in a plurality of serial processor operations not overlapping in time and in a set of parallel processor operations.
Referring to claim 6, Takayama, as modified, has taught the processor method of claim 1 wherein the first processor stack and the second processor stack are in substantially simultaneous operation (again, see the rejection of claim 1 (2nd bullet). Furthermore, since the stacks are in memory and memory is powered up during processing, the stacks can be said to be in simultaneous operation, i.e., they are both powered on).
Referring to claim 7, Takayama, as modified, has taught the processor method of claim 1 but has not explicitly taught wherein the processor-register-to-processor-register operations are performed in a set of one or more processor serial operations, the one or more processor serial operations not overlapping in time. However, note the three adds in block 125 and also FIG.5 and note the single ALU. Official Notice is taken that an execution resource accommodating only a single instruction at a time (i.e., serial execution) was well known in the art before applicant’s invention. While this is slower, the hardware design is simplified because extra buses/ports are not required to handle multiple instructions at once. Dependency checking could also be reduced between ALU instructions since there is no worry about improper results if an instruction executes before a previous instruction finishes. As a result, in order to reduce hardware, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Takayama such that the processor-register-to-processor-register operations are performed in a set of one or more processor serial operations, the one or more processor serial operations not overlapping in time.
Referring to claim 8, Takayama, as modified, has taught the processor method of claim 1 wherein at any step b) through g) another step a) of claim 1 is performed (see FIG.11. Between claimed steps e) and f) another call operation (step a)) is performed (see “call- g”). This is the call to g() in FIG.10).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Takayama in view of McAuley, Tremblay, the examiner’s taking of Official Notice, and Poplingher, U.S. Patent No. 6,170,054.
Referring to claim 9, Takayama, as modified, has taught the processor method of claim 8 but has not taught wherein the another step a) of claim 1 is performed as long as there remains processor stack space on both the first processor stack and the second processor stack. However, Poplingher has taught allowing nested calls until a stack runs out of room. When the stack is full, if any other nested call were allowed to proceed, the stack would overflow and complicated recovery procedure would need to be performed. See column 1, line 65, to column 2, line 4. As a result, in order to eliminate complicated processing due to overflow, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Takayama such that the another step a) of claim 1 is performed as long as there remains processor stack space on both the first processor stack and the second processor stack.
Response to Arguments
All arguments of 103 rejections spanning p.9 through most of p.17 of applicant’s response are duplicated from the arguments filed on September 5, 2024. As such, these are not persuasive for reasoning set forth in the previous Office Action and/or because the rejections have been updated for purposes of trying to simplify the rejection and provide increased clarity.
On page 17 of applicant’s response, applicant argues that there is no indication of any unique control or instructions that indicate SP because there is only a single SP.
Applicant is arguing against the references individually. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The combination of prior art teaches multiple stacks, each with their own control (including base and limit registers) and stack pointer register to track where to write in the stack. Additional control would include instructions to push to and pop from the stack by referencing the desired SP. For instance, the ld, st, stm, and ldm instructions all manipulate the SP. When there are multiple stacks and SPs, the appropriate SP would need to be indicated to control the particular stack being pushed/popped (see FIGs.6 and 11, which would identify and update the appropriate SP).
On page 19 of applicant’s response, applicant argues that Lambrache has not taught a second stack.
The examiner is not relying on Lambrache to teach a second stack. The examiner is relying on Tremblay to teach the second stack. Furthermore, Lambrache is no longer used in the rejection. It has been replaced with McAuley due to applicant’s claiming of both a base and limit register.
On page 19 of applicant’s response, applicant notes that the examiner has failed to supply a requested affidavit of personal knowledge of Takayama’s “second stack”.
No affidavit can be provided for a statement that was not made. Again, Takayama alone does not teach a second stack. The examiner is modifying Takayama in view of Tremblay to include a second stack.
On page 19 of applicant’s response, applicant argues that Tremblay does not teach a second stack.
This assertion contradicts the language quoted in the previous sentence, which states “via a separate stack from the operand stack”. It is the examiner’s position that Tremblay does teach two stacks (FIG.4B shows two stacks).
On page 20 of applicant’s response, applicant appears to argue that Venners does not disclose a second hardware-based stack because Venners relates to a JAVA virtual machine.
A virtual machine still uses hardware resources. In the end, a stack is a series of memory locations used to store data. A virtual machine would simply be allocated hardware to create the stack. Without storage hardware, a stack could not be created. Additionally, the examiner is not proposing making Takayama a virtual machine. The examiner is merely bringing in two simultaneously-accessible stacks to improve processing.
On pages 20-21 of applicant’s response, it is not clear how applicant concluded that Venners and Tremblay do not disclose a second stack because Venners’ operand stack is an array of words, the JVM uses the operand stack as a work space, and the JVM has no registers. Please clarify.
On pages 22-23 of applicant’s response, applicant again argues there is no teaching of a second stack.
The examiner disagrees for reasoning given above. No further arguments related to the second stack will be individually addressed. Instead, each argument is generally responded to with the assertion that Takayama alone does not teach multiple stacks, but the combination of prior art does teach multiple stacks.
On pages 26-28 of the response, applicant argues the combination based on Lambrache. Lambrache has been eliminated from the rejection due to amendment; thus, the arguments relating to Lambrache are moot.
On page 28 of the response, applicant responds to the examiner’s statement about passing a parameter from a calling function by stating that the separate stack and operand stack are not indicated to operate simultaneously.
The examiner asserts that the bolded language on page 28 does not relate to simultaneous operation and, therefore, this argument is not relevant to the examiner’s rejection of the bolded language. In addition, the simultaneous operation is addressed in the rejection of claim 1.
On pages 29-43 of the response, applicant’s arguments have already been addressed in the previous office action. The responses still apply where the rejection has not been changed.
On page 44 of the response, applicant argues the examiner’s response in paragraph 22 of the previous action, stating that the examiner has not laid out any rationale for modification.
The examiner respectfully disagrees. Please review the portion of the rejection of claim 1 that combines Takayama and Tremblay.
On pages 44-45, the argument related to Lambrache is moot due to replacement of Lambrache with McAuley.
On pages 45-46 of the response, applicant notes that claim 1 has been amended to set forth simultaneous operations.
For reasons explained in the rejection, the claim does not yet require simultaneous operation. It merely needs to be allowed. The examiner asserts that the combination of prior art allows it (or is capable of it) because separate stacks exist with separate controls/registers. However, even if it were required, it is obvious.
On page 47 of the response, applicant argues that Takayama and Tremblay do not teach the base register or limit register.
The examiner agrees and this is the reason McAuley has been added to the rejection.
On page 48 of the response, applicant argues that global variables can be used instead of passing parameters to a function on a stack.
The examiner agrees and this is what Takayama teaches without modification. However, Tremblay teaches the passing, and the examiner asserts that this is an obvious substitution. There are multiple ways apparent to one of ordinary skill in the art of programming to get needed values into a function.
On pages 48-49 of the response, the examiner’s response in paragraph 30 of the previous action stands. Further, while applicant may have found definitions that show distinction between cache and stack, Tremblay literally refers to stack cache that provides standard pushing and popping. Thus, the stack cache is a stack; it is merely implemented for faster access to some stack data than if it were to be popped from a regular stack in memory. The examiner also notes that the stack cache(s) is/are not an essential part of the combination. Thus, they have been removed for simplification.
On page 50, the examiner does not understand applicant’s argument. The examiner fails to see where the examiner has conflated software structures with hardware, let alone conflated them in a way that makes the rejection improper. Please note the update to the rejection.
On page 51 of the response, the examiner notes that Lambrache is no longer relied on in the rejections. In general, however, Lambrache, and now McAuley, teach one stack with corresponding control and registers. Thus, in a system with two stacks (like Takayama in view of Tremblay), because a second stack is implemented, it is only natural to implement control and registers for that second stack. Two separate stacks located in different locations in memory cannot be controlled by a single set of registers because multiple bases, multiple limits, and multiple stack pointers would be required to manipulate and define multiple stacks.
On page 52 of applicant’s response, applicant argues that use of, for example, “can”, “may”, and “could” language constitutes conjecture.
Applicant is reading too much into the terminology used. Takayama certainly doesn’t have to pass variables through a stack to a function. But Takayama could be modified to pass in this manner. And such passing is taught (and thus no affidavit is needed). It is an alternative to that taught in FIG.11 of Takayama.
On page 53 of the response, applicant is not persuaded by paragraph 38 of the previous action, and states that pushing a value onto a stack doesn’t mean popping will return it to the register from which it came. Applicant stated that the address can come from the ALU, not the SP.
This is incorrect. Applicant is encouraged to review the code of FIG.11 and how it works based on the operations of FIG.6. The stm- instruction 122 stores R2 and R3 to the stack. At the end, the values of R2 and R3 on the stack are returned to R2 and R3 via the ldm instruction 128. The instructions in between store to different locations on the stack and do not affect the restoration of R2 and R3. This may become more clear below when the examiner simulates FIG.11 and the corresponding stack contents.
On pages 54-55 of the response, applicant argues that the examiner is trying to re-engineer the reference when the reference states that i2 and i3 are not maintained as they are consumed in the calculation. Applicant also argues that the examiner is proposing for alleged software operations to be equivalent to what has been claimed in hardware.
The examiner does not understand this argument. What software operations is alleging in place of applicant’s hardware? Software can pass parameters in the combination of prior art, but the appropriate hardware is needed to perform the functionality.
On page 55 of the response, applicant argues that there is no teaching that contents are popped off the second stack into registers from which they came. Applicant’s basis for this is that the ldm instruction 128 in FIG.11 can specify any register.
This is not persuasive. While the examiner agrees that an ldm instruction can specify any register and thus could be encoded in a way that contents are not popped into registers from which they came, FIG.11 explicitly shows ldm 128 specifying registers R2 and R3, which means contents of the stack are popped into R2 and R3. The contents pushed onto the stack are from R2 and R3 (instruction 122). Perhaps it would assist applicant to show how the stack looks when executing FIG.11. Assume SP = 100 when function f is called by instruction 121. The stm- instruction 122 pushes values from R2 and R3 onto the stack with the stack pointer (SP) decremented by 4 for each push. After instruction 122, the stack appears as follows:
SP stack contents100 R2 value
96 R3 value
92
Then the link register (LR) value (return address for the function) is stored in the next location on the stack with instruction 123 such that the stack looks as follows:
SP stack contents100 R2 value
96 R3 value
92 LR value (return address)
Instruction 124 then subtracts 16 from the stack pointer such that SP = 92-16 = 76. The following alternating sequence of ld/st instructions retrieves variables from memory and stores them to the stack. The first ld loads the value at address i0 in memory into register R0 and then pushes that value from R0 onto the stack at the location pointed to by SP, so the stack looks as follows:
SP stack contents100 R2 value
96 R3 value
92 LR value (return address)
88
84
80
76 value at memory address i0
The remaining ld/st in that sequence cause the stack to appear as follows with each st/push pushing data to an address that is 4 larger than the address previously pushed to:
SP stack contents100 R2 value
96 R3 value
92 LR value (return address)
88 value Z at memory address i3
84 value Y at memory address i2
80 value X at memory address i1
76 value W at memory address i0
In the next series of four consecutive loads, the four values most recently pushed onto the stack are loaded into four consecutive registers, such that R0=W, R1=X, R2=Y, and R3=Z. The following add instructions set R0 first to W+X, second to (W+X)+Y, and third to (W+X+Y)+Z, i.e., to the accumulation of all four values retrieved from memory. This accumulated value is then stored to memory at address j. Subsequently, add instruction 126 adds 16 to SP so that SP = 76+16 = 92, which is the address in the stack of the link register value. Hence, instruction 127 serves to pop the LR value from address 92 in the stack back into the link register so that a return can be properly performed at instruction 129. However, in one final step with instruction 128, the original values of R2 and R3, which were pushed into addresses 100 and 96 respectively, are loaded back into R2 and R3 before function return. As such, FIG.11 very clearly shows that all contents of registers R2 and R3 are popped off into the registers R2 and R3.
On page 56 of applicant’s response, applicant argues that a hardware stack has a LIFO architecture where a register has a RAM architecture. Applicant follows by stating that software cannot replace a hardware keyboard.
The examiner does not understand how this is relevant to the rejection or Takayama. Applicant claims a result register. The examiner pointed to R0 in FIG.11. R0 is a register, not a stack. One of ordinary skill in the art understands that the Rx identifiers in FIG.11 are for identifying registers. The examiner also does not understand applicant’s example analogy. What software is applicant referring to that the examiner is substituting for hardware, and why can’t such a replacement occur? Also, the examiner disagrees that software cannot replace a hardware keyboard. Smart-phones have been doing this for many years.
On page 57 of the response, applicant argues that the examiner has not addressed the rejection of claim 2 and also that a virtual construct cannot implement a hardware result.
The examiner respectfully disagrees. The examiner gave a detailed explanation in the rejection of claim 2. Furthermore, the examiner notes two things about the “virtual” argument: (1) the examiner is not asserting that Takayama is to be made into a virtual machine. Instead, the examiner is merely bringing in a second stack from Tremblay and further detailed by Venners so as to pass parameters to a function; and (2) even if Takayama was implemented as a virtual machine, it appears that applicant is arguing that a virtual machine does not use hardware. This is incorrect. A virtual machine sits on top of the hardware and uses the hardware to implement that virtual machine.
Applicant’s argument for the claim 3 rejection on page 58 of the response is not persuasive because the quoted limitation is not missing. From the examiner’s stack example above, the instructions directly pop R2 and R3 values from the second stack back into R2 and R3.
On page 58 of applicant’s response, applicant’s argument is not persuasive for reasoning already given.
On page 59 of applicant’s response, the examiner asks applicant to point out which arguments have not been addressed by the examiner.
On page 59 of applicant’s response, applicant refers to Abus and Bbus and SP, and how a lack of isolation from the bus results in register-to-register operations not being performed. Applicant states that Takayama fails to add registers and the ALU does not have registers.
The examiner does not understand this argument or its relevance as it does not appear to address the rejection itself. The SP is not a concern of the rejection of claim 4. Takayama doesn’t need to add registers because Takayama already includes registers (e.g. registers R0 through R3 in FIG.11 and in FIG.5, register file 11, which feeds operands to the ALU).
On page 60 of the response, applicant argues that adding ALUs does not guarantee parallel operation of register-to-register operations, especially because values would be overwritten.
While adding an ALU does not guarantee parallel operation, it is obvious for it to result in parallel operation. That is, if there are two execution resources, it is obvious to use them at the same time to improve execution speed. The system would be appropriately modified in a way to accommodate such execution and handle multiple results at once so that results are not lost. Many systems perform operations in parallel in a correct manner such that results are not lost.
On page 60 of the response, applicant does not agree that the adds in parallel are register-to-register operations.
An add instruction in FIG.11 reads data to be added from registers and stores the addition result to a register. How is this not a register-to-register operation?
On page 61 of the response, applicant argues that the examiner, by pointing out that an add in FIG.11 adds data from registers and stores a result in a register, is conflating hardware with software. Applicant states that FIG.5 of the ALU is devoid of registers because it takes inputs from Abus and Bbus and outputs to Cbus.
This is not persuasive. First, the claim does not require an ALU, let alone an ALU that comprises registers. However, even if it did, FIG.5 of Takayama very clearly shows an ALU 14 that comprises register file 11. The register file 11 sends register values to the inputs of the ALU and the output of the ALU is sent to the register file. This is how an add instruction is carried out in FIG.11. For instance, the instruction “add R1, R0” receives the value from register 11a on one of Abus and Bbus, receives the value from register 11b on the other of Abus and Bbus, adds the two together, and sends the result to register 11a via the Cbus. This is understood by one of ordinary skill in the art of computer architecture.
On page 62 of the response, applicant argues that Tremblay is dealing with data caches and not registers.
The examiner fails to see how this is relevant to the rejection.
On page 62 of the response, applicant argues that Tremblay can access multiple portions of a stack which is different from multiple stacks.
FIGs.3B-4B explicitly show multiple stacks with portions that are said to be simultaneously accessible in the first paragraph of the detailed description section. Thus, this argument is not persuasive.
On page 62 of the response, applicant argues the response in paragraph 61 of the previous action, stating that Tremblay is dealing with caches, not stacks.
The examiner disagrees that Tremblay is not dealing with stacks. See FIG.4B.
On page 63 of the response, applicant argues that Tremblay teaches multiple accesses to a single stack with multiple frame components.
The examiner respectfully disagrees. Tremblay provides a way to access multiple frames of the stack by dividing the stack into multiple stacks. See the paragraph from which a portion was quoted by applicant. FIG.4B clearly shows two stacks, and the paragraph describes accessing two portions in two different stacks simultaneously.
On page 64 of the response, applicant maintains that the rejection of claim 7 is inconsistent with the rejection of claims 4-5, and asks the examiner if Takayama is teaching parallel operations or serial operations not overlapping in time.
First, the examiner notes the updated rejection to claim 7 so that the examiner is no longer relying on inherency. However, the overall idea behind these dependent claim rejections remains. For claim 7, Takayama only teaches one ALU. It is obvious, to simplify the ALU hardware (and buses thereto), to only execute the add instructions one at a time (serially) such that they do not overlap. For claims 5-6, the examiner is proposing adding another ALU so that multiple adds can occur at the same time. There is no inconsistency. These are different claims in different branches and one can use the existing ALU of Takayama for serial operation, or alternatively add a second ALU to try to parallelize operations.
On page 65 of the response, applicant argues that call- g only occurs at the end of block 125 and therefore it cannot be after the ld (SP), R0 instruction.
Claim 8 states “wherein at any step b) through g) another step a) of claim 1 is performed”. This means another call needs to be performed between when a parameter is pushed onto the first stack (step b) and when processor control is returned to the instruction following the initial call (step g). Pushing a parameter onto the first stack happens at the beginning of the code. As modified, it happens in the main function. The return is the very last instruction in FIG.11. “call- g” is between the two.
On pages 66-67 of the response, applicant requests an affidavit because the examiner is relying on personal knowledge.
The examiner is not relying on personal knowledge, and no affidavit is necessary. Poplingher explicitly states that going beyond the max of 12 requires complicated procedures for stack overflow. Thus, to not add complicated procedures, the system can just stop at the max.
On page 67 of the response, applicant argues that nowhere in Poplingher is it disclosed that an instruction can be stopped.
The examiner disagrees and again directs applicant to the cited passage, which states that you can’t do more than the stack can accommodate without resorting to complicated procedures. Therefore, it is obvious to stall at that point.
On page 67 of the response, applicant argues that the examiner is making a circular argument with respect to overflow.
The examiner respectfully disagrees. The stack of the combination could allow overflow if one were to implement complicated procedures. However, the examiner asserts that it is obvious to reduce complication by not allowing the overflow to occur.
On page 68 of the response, applicant inadequately traverses the examiner’s Official Notice for claim 2 because applicant did not explain why the noticed feature is not considered to be common knowledge (MPEP 2144.03(C)). As such, the examiner is not required to provide a supporting reference. However, the examiner has already provided a supporting reference in the rejection itself (see Venners).
On pages 68-69 of the response, applicant inadequately traverses the examiner’s Official Notice for claim 4 because applicant did not explain why the noticed feature is not considered to be common knowledge. As such, the examiner is not required to provide a supporting reference. Nevertheless, please note the Wikipedia entry for “superscalar” (cited herewith), which even gives an example of multiple adds operating in parallel.
On page 69 of the response, applicant inadequately traverses the examiner’s Official Notice for claim 5 because applicant did not explain why the noticed feature is not considered to be common knowledge. As such, the examiner is not required to provide a supporting reference. Nevertheless, note the Wikipedia entry for “superscalar”, which even gives an example of multiple adds operating in parallel. This same entry even compares superscalar to scalar, which can execute at most one instruction per cycle (and would perform serial execution). Dependent operations are also shown to be serialized.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to David J. Huisman whose telephone number is 571-272-4168. The examiner can normally be reached on Monday-Friday, 9:00 am-5:30 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jyoti Mehta, can be reached at 571-270-3995. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/David J. Huisman/Primary Examiner, Art Unit 2183