DETAILED ACTION
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 .
Claims 1, 3-16, 21, 36, 38-51, and 56 have been examined.
The specification objections in the previous Office Action have been addressed and are withdrawn.
Information Disclosure Statement
The applicant's submission of the Information Disclosure Statements dated October 23, 2025, January 19, 2026, and January 26, 2026 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending. Copies of the PTOL-1449s initialed and dated by the examiner are attached to the instant office action.
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, 3-16, 21, 36, 38-51, and 56 are rejected under 35 U.S.C. 103 as being unpatentable over US Publication No. 2003/02210355 by Adams (hereinafter referred to as “Adams”) in view of US Publication No. 2016/0357657 by Zhang et al. (hereinafter referred to as “Zhang”).
Regarding claim 1, Adams discloses:
a method for executing new instructions used in a processor, comprising (Adams discloses, at the Abstract, a method for executing new instructions used in a processor.):
receiving an instruction (Adams discloses, at Figure 5 and related description, receiving instructions.);
generating an unknown instruction exception when the received instruction is an unknown instruction (Adams discloses, at Figure 5 and related description, generating an invalid opcode interrupt in response to an unrecognized instruction.);
in response to the unknown instruction exception, entering a …mode… (Adams discloses, at Figures 5 and 8 and related description, invoking an invalid operation code handler that translates and executes invalid operations, which discloses in response to the unknown instruction exception, entering a …mode….);
in the …mode…executing the following steps through a conversion program: (i) determining whether the received instruction is a new instruction (Adams discloses, at Figure 8 and related description, the invalid operation code handler determining if the instruction is a newer instruction that is supported.);
(ii) simulating execution of the received instruction by executing at least one old instruction when the received instruction is a new instruction (Adams discloses, at Figure 8 and related description, the invalid operation code handler dynamically translating operations into instructions recognized by the CPU and executing the operations.); and
processing the received instruction when the receiving instruction is an old instruction, but not entering the system management mode (Adams discloses, at Figure 5 and related description, normal processing of instructions that are recognized, which discloses, processing the received instruction when the receiving instruction is an old instruction, but not entering the system management mode.).
Adams does not explicitly disclose the aforementioned mode is a system management mode, wherein interrupts are disabled in the system management mode.
However, in the same field of endeavor (e.g., analyzing code) Zhang discloses:
system management mode (SMM) with interrupts disabled (Zhang discloses, at ¶ [0019], disabling interrupts in SMM.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Adams to include SMM, as disclosed by Zhang, in order to provide a transparent and easily isolated environment. See, Zhang, ¶ [0013].
Regarding claim 3, Adams discloses the elements of claim 1, as discussed above. Adams also discloses:
decoding the at least one old instruction into at least one microinstruction; and executing the at least one microinstruction (FIG. 5, FIG. 8).
Regarding claim 4, Adams, as modified, discloses the elements of claim 1, as discussed above. Adams also discloses:
writing an emulation flag into a microarchitecture register in response to the unknown instruction exception; and generating ..[an] interrupt ([0070] "an ID flag 162 may be used to determine if the processor 12 supports the CPUID instruction" which in turn triggers an interrupt as per FIG. 5 that leads to the CPU Life Extension Module).
Adams does not explicitly disclose the aforementioned interrupt is a system management interrupt.
However, in the same field of endeavor (e.g., analyzing code) Zhang discloses:
system management interrupts (SMI) (Zhang discloses, at ¶ [0019], using SMIs to enter SMM.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Adams to include SMM, as disclosed by Zhang, in order to provide a transparent and easily isolated environment to analyze and debug code. See, Zhang, ¶ [0013].
Regarding claim 5, Adams, as modified, discloses the elements of claim 4, as discussed above. Adams also discloses:
wherein the emulation flag is a first value, which is used to indicate that the received instruction is a new instruction to be processed by a simulator, otherwise not processing the received instruction by the simulator (FIG. 8, [0070], and [0062] if the CPUID instruction is supported, i.e. first value, then it is simulated as per [0062], otherwise not).
Regarding claim 6, Adams, as modified, discloses the elements of claim 1, as discussed above. Adams also discloses:
obtaining an emulation flag, information of the received instruction and the operating environment information of the received instruction from a microarchitecture register; storing the emulation flag, the information of the received instruction, and the operating environment information in a system management memory (FIG. 7, [0064], [0075] states are saved as part of moving to the handling mechanism/CPU Life Extension Module).
Regarding claim 7, Adams, as modified, discloses the elements of claim 6, as discussed above. Adams also discloses:
wherein the information of the received instruction comprises an instruction pointer of the received instruction and a machine code of the received instruction; and in the system management mode, the method further comprises: reading the emulation flag from the system management memory; and determining whether the received instruction is a new instruction according to the machine code when the emulation flag is the first value, wherein the first value indicates that the received instruction is an instruction to be simulated (FIG. 8 e.g. CPUID instruction as per [0062]/[0070] Also, FIG. 7, [0064], [0075] states are saved as part of moving to the handling mechanism/CPU Life Extension Module).).
Regarding claim 8, Adams, as modified, discloses the elements of claim 6, as discussed above. Adams also discloses:
wherein in the system management mode and when the received instruction is a new instruction, the method further comprises: generating a conversion result where there is a decoding exception, wherein a result field of the conversion result is a second value, which means the conversion failed (FIG. 5 leads to FIG. 8).
Regarding claim 9, Adams, as modified, discloses the elements of claim 6, as discussed above. Adams also discloses:
storing the emulation flag, the information of the received instruction, and the operating environment information into the microarchitecture register when the received instruction is an unknown instruction (FIG. 7, [0064], [0075] states are saved as part of moving to the handling mechanism/ CPU Life Extension Module).
Regarding claim 10, Adams, as modified, discloses the elements of claim 1, as discussed above. Adams also discloses:
wherein in the system management mode, the method further comprises: obtaining information of the received instruction from a system management memory; wherein the information of the received instruction comprises an instruction pointer of the received instruction: reading the machine code of the received instruction from the system management memory according to the instruction pointer of the received instruction obtaining the operation code of the received instruction according to the machine code of the received instruction: and determining whether the received instruction is a new instruction according to the operation code (FIG. 5, FIG. 8, also FIG. 7, [0064], [0075] states are used as part of moving to and from the handling mechanism/ CPU Life Extension Module).
Regarding claim 11, Adams, as modified, discloses the elements of claim 10, as discussed above. Adams also discloses:
wherein in the system management mode and when the received instruction is a new instruction, the method further comprises: converting the receiving instruction into the at least one old instruction according to the operation code; and executing the at least one old instruction (FIG. 8 steps 136 and 138 dynamic translation of the operation into "instructions recognized by the CPU 12" [old instructions]).
Regarding claim 12, Adams, as modified, discloses the elements of claim 10, as discussed above. Adams also discloses:
decoding the machine code to obtain other decoding information of the received instruction, wherein the other decoding information comprises a source operand and a destination operand; and executing the at least one old instruction according to the other decoding information (FIG.2, 386 instruction set architecture, FIG. 8. The 80386 ("386") ISA provides various instructions, for example ADD, that have a source and destination operand (e.g. "ADD r/m8, r8" adds R8 to m8 and stores it in m8)).
Regarding claim 13, Adams, as modified, discloses the elements of claim 1, as discussed above. Adams also discloses:
wherein in the system management mode and when execution of the received instruction fails, the method further comprises: generating an exception code of an unknown instruction exception; and storing the exception code in the system management memory, and setting an exception flag in the system management memory (FIG. 8, "no" from step 134 and step 142).
Regarding claim 14, Adams, as modified, discloses the elements of claim 1, as discussed above. Adams also discloses:
wherein in the system management mode, the method further comprises: reading a machine code of the received instruction from the system memory according to an instruction pointer of the received instruction; decoding the machine code of the received instruction to obtain an operation code of the received instruction; and determining whether the received instruction is a new instruction according to the operation code (FIG. 5, FIG. 8).
Regarding claim 15, Adams, as modified, discloses the elements of claim 1, as discussed above. Adams also discloses:
wherein when the received instruction is a new instruction, the method further comprises: in the system management mode, storing a simulation execution result in a system management memory, wherein the simulation execution result is obtained by executing the at least one old instruction, and the final instruction in the at least one old instruction is a jump instruction or a call instruction (FIG. 8, step 138 and step 140 and FIG. 5).
Regarding claim 16, Adams, as modified, discloses the elements of claim 15, as discussed above. Adams also discloses:
wherein when the received instruction is a new instruction, the method further comprises: writing a value in a storage space stored in the system management memory into an architecture register when exiting the system management mode (FIG. 8, step 138, execution would involve output to a destination, e.g. as part of an XADD, a new instruction in 486).
Regarding claim 21, Adams, as modified, discloses the elements of claim 1, as discussed above. Adams also discloses:
in the system management mode: obtaining an emulation flag from a system management memory; and executing the conversion program when the emulation flag is the first value, wherein the first value indicates that the received instruction is an instruction to be simulated (FIG. 8).
As to claims 36, 38-51, and 56, these claims are the system claims corresponding to the method claims 1, 3-16, and 21.
Response to Arguments
On page 25 of the response filed January 19, 2026, (“response”), the Applicant argues, “The combination of Adams and Zhang fails to establish a prima facie case of obviousness. Specifically, Adams explicitly teaches implementing instruction translation at the operating system (OS)/driver level, which teaches away from the System Management Mode (SMM) implementation required by Claim 1. Furthermore, a person having ordinary skill in the art would lack the motivation to combine these references due to the technical complexity and performance penalties associated with SMM. Claim 1 recites, in pertinent part:"...in response to the unknown instruction exception, entering a system management mode (SMM)... in the system management mode... simulating execution of the received instruction..." Adams explicitly discloses that its "CPU life-extension module" operates as a software driver within the operating system environment, not in SMM. Paragraph [0055] of Adams states:"In certain embodiments, a CPU life-extension module 80 may be installed as a driver 94 to achieve a privilege level equal to that of the operating system 82." Paragraphs [0054] and [0060] of Adams confirm that the handler is stored in "system memory 14" (RAM) and modifies the "interrupt vector table," which are standard OS-level structures. Adams relies on the operating system to load and manage the driver. It does not disclose or suggest placing this logic within the System Management Mode (SMM), which is a completely distinct, hardware-protected execution environment isolated from the OS.”
Though fully considered, the Examiner respectfully disagrees. MPEP § 2145 discusses “teaching away.” Generally, a reference teaches away if it criticizes, disparages, or excludes a particular solution. Here, Adams does not criticize, disparage, or exclude an SMM implementation. Adams is silent regarding an SMM implementation. Adams’s disclosure of an alternative implementation, i.e., an OS based implementation, does not teach away from other alternative implementations, such as an SMM implementation represented by the proposed combination. Accordingly, the Applicant’s arguments are deemed unpersuasive.
On page 26 of the response the Applicant argues, “Next, while Zhang describes the general properties of SMM (e.g., entering via SMI, disabling interrupts), it does not teach utilizing SMM for the specific purpose of instruction emulation or handling invalid opcode exceptions.”
Though fully considered, the Examiner respectfully disagrees. Zhang is not cited for teaching instruction emulation or handling invalid opcode exceptions. Instead, Adams is cited as teaching these elements. As noted at MPEP § 2145, “One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references.” Accordingly, the Applicant’s arguments are deemed unpersuasive.
On page 26 of the response the Applicant argues, “Even though Adams and Zhang theoretically contain all elements, there is no motivation for a person having ordinary skill in the art to combine them to arrive at the specific arrangement of claim 1.”
Though fully considered, the Examiner respectfully disagrees. As discussed above, using SMM provides a trusted environment. See, e.g., Zhang, ¶ [0013]. This improves security for performing certain system operations. Accordingly, the Applicant’s arguments are deemed unpersuasive.
On page 26 of the response the Applicant argues, “In fact, significant technical barriers suggest the contrary. Adams "Teaches Away" from the claimed invention. Adams provides a complete, functioning solution implemented as an OS Driver. An OS Driver is easier to develop, debug, and update compared to SMM code (which resides in Firmware/BIOS). By explicitly defining the module as a "driver" having "OS privilege levels" (Adams, [0055]), Adams directs the person having ordinary skill in the art towards software-based solutions and away from the firmware/hardware level implementation (SMM) recited in Claim 1.”
Though fully considered, the Examiner respectfully disagrees. Regarding the Applicant’s purported technical barriers or complexity, Adams discloses using x86 processors, which include SMM as a standard feature. Using SMM is within common knowledge of those in the art, as admitted at, for example, ¶ [0048] of Applicant’s specification as filed.
As discussed above, Adams does not disparage SMM in any way. It is only the Applicant’s arguments that propose SMM would be an unsuitable alternative. Therefore, Adams does not teach away from the proposed combination. Adams’s disclosure of one alternative implementation does not teach away from alternative implementations. Accordingly, the Applicant’s arguments are deemed unpersuasive.
On page 26 of the response the Applicant argues, “Persons having ordinary skill in the art following the teachings of Adams would have no reason to discard the efficient driver architecture to adopt the restrictive and complex SMM architecture described in Zhang. Since executing code in SMM freezes the entire operating system (OS Transparency), if the instruction emulation described in Adams were moved to SMM, every "new instruction" encountered would trigger a System Management Interrupt (SMI). Frequent SMIs cause significant system latency and performance degradation. Therefore, persons having ordinary skill in the art would be discouraged from moving high-frequency tasks (like instruction translation) into SMM. The claimed invention overcomes this counter-intuitive hurdle to achieve OS independence, which is a non-obvious design choice.”
Though fully considered, the Examiner respectfully disagrees. As noted above, SMM provides a useful set of features that provide a trusted environment. While there may be a cost associated with using SMM, this is true of essentially all aspects of processor technology. While it is possible to describe various features in terms of their costs, that does not mean that the benefits do not exist. In this case, there may be a latency penalty that comes with using SMM. However, that penalty may be offset by the benefit of providing a secure environment to perform system operations. Circumstances dictate which choice to make regarding the tradeoff.
Furthermore, as noted at MPEP § 2145, attorney argument cannot take the place of evidence in the record. The Applicant’s arguments are not based in the written description. The written description discloses SMM implementations, e.g., at Figure 3, and non-SMM implementations. The alternatives are both shown, and there is no discussion of the SMM implantation as being counter-intuitive, or any description of problems overcome in arriving at an inventive solution of using SMM for the claimed operations. Accordingly, the Applicant’s arguments are deemed unpersuasive.
On page 27 of the response the Applicant argues, “In addition, claim 1 requires that an unknown instruction exception triggers entry into SMM. Adams discloses that an invalid opcode triggers a standard Exception/Fault (handled by the OS via the Interrupt Vector Table). Zhang discloses that the only way to enter SMM is via a System Management Interrupt (SMI) (Zhang, paragraph [0019]). Adams and Zhang fail to teach how to bridge this gap. Standard x86 architecture does not automatically convert an "Invalid Opcode Fault" (software event) into an "SMI" (hardware signal). Bridging a software fault to SMM requires specific, non-trivial hardware logic or chipset configuration. Simply combining the "Instruction Translation" of Adams with the "SMM environment" of Zhang does not inherently result in the claimed triggering mechanism.”
Though fully considered, the Examiner respectfully disagrees. As previously discussed, using SMM, including entering and exiting, is common knowledge for those having ordinary skill in the art. There are any number of ways to trigger an SMI, as is known in the art.
Furthermore, the conversion, logic, or chipset the Applicant argues are required are neither claimed not described in the specification. Accordingly, the Applicant’s arguments are deemed unpersuasive.
On page 27 of the response the Applicant argues, “The proposed combination is based on impermissible hindsight. Adams teaches a driver- based approach, and Zhang merely defines the SMM environment. There is no teaching, suggestion, or motivation in the prior art to relocate the driver-based emulation of Adams into the SMM environment of Zhang. On the contrary, doing so would increase complexity and latency. Therefore, claim 1 is non-obvious.”
Though fully considered, the Examiner respectfully disagrees. As discussed previously, one would have been motivated to combine the references to provide a trusted environment for system operations, as disclosed by Zhang. While doing so may incur certain costs, circumstance would dictate whether those costs were outweighed by possible benefits. Accordingly, the Applicant’s arguments are deemed unpersuasive.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAWN DOMAN whose telephone number is (571)270-5677. The examiner can normally be reached on Monday through Friday 8:30am-6pm Eastern Time.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jyoti Mehta can be reached on 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.
/SHAWN DOMAN/
Primary Examiner, Art Unit 2183