DETAILED ACTION
This action is responsive to Remarks and Claim amendments filed on February 24, 2026.
Claims 3-5, 7, 10-12, 15-17 and 20 have been amended.
Claims 1-20 are pending and are presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicants have argued that Chakraborty along with the remaining art of record, do not teach the newly added limitations of independent claims 1, 8, 13 and 18 (Remarks, pages 8-13). Applicants' arguments have been fully considered and are persuasive. Therefore, the rejection is withdrawn. However, upon further consideration, a new ground of rejection is made as set forth in details below. See Jonathan Corbet (“C11 atomic variables and the kernel”) and Bor-Yeh Shen et al. (“LLBT: An LLVM-based Static Binary Translator”), arts being made of record as applied herein.
Response to amendments
The objection of claims 3-5, 7, 10-12 and 15-17 is withdrawn in view of applicant’s amendments.
The rejection of claim 20 under 35 U.S.C. 101 is withdrawn in view of applicant’s amendments.
Claim Objections
Claims 5, 12 and 17-19 are objected to because of the following informalities: Claim 5 (and similar for claims 12 and 17) recites “converting the inline assembly code suitable for the source architecture into an abstract syntax tree; or converting, based on semantics of each branch in the abstract syntax tree, each branch into inline assembly code or a compiler built-in function suitable for the target architecture.”. Claim 5 depends on claim 3, claim 3 introduces to alternatives “converting the inline assembly code” or “a compiler built-in function”, therefore by limiting claim 5 using “and” implies both alternatives exist when claim 3 requires just one. Claim 18 recites “A non-transitory computer-readable storage medium that stores a computer program, which when executed by one or more processors, causes the one or more processors to perform a method, the method comprising:” in lines 1-3. Claim 19 recites “The non-transitory computer-readable storage medium according to claim 18, wherein the method further comprises:” in lines 1-2. Please amend the claim language as indicated in bold. Appropriate correction is required.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 6, 8-9, 13-14 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Soham Chakraborty (“On Architecture to Architecture Mapping for Concurrency”, hereinafter Chakraborty – IDS 01/10/2025 – previously presented) in view of Jonathan Corbet (“C11 atomic variables and the kernel”, hereinafter Corbet).
With respect to claim 1(original), Chakraborty teaches a code processing method in a hardware memory order architecture (Chakraborty teaches a code processing method in a hardware memory order architecture context, comprising a compilation pipeline implemented as modifications to LLVM that processes concurrent C11 programs and generates executable code targeted to a specified hardware memory order architecture (see sections 1; 8.1 and figures 9, 12, 13)), comprising: obtaining a first file in a compilation process, wherein the first file is associated with a source file (Chakraborty teaches obtaining an LLVM intermediate representation (IR) during compilation of a C11 source program. Specifically, Chakraborty modifies the LLVM code generation phases for x86, ARMv7, and ARMv8 to operate on a C11-source-derived IR (see section 8.1: "We have modified the x86, ARMv7, and ARMv8 code generation phases in LLVM to capture the effect of mapping schemes on C11 programs"). The LLVM IR satisfies the claimed "first file" and it is associated with the C11 source file from which it is generated). performing compilation processing on the second file, to obtain an executable file suitable for a target architecture, wherein the target architecture is a strong memory order architecture or a weak memory order architecture (Chakraborty teaches performing further compilation processing on the IR through LLVM’s back-end code generation pipeline to produce executable code for a target architecture (see sections 4; 8.1 and figures 9, 12, 13). Chakraborty’s target architectures include x86, ARMv7, and ARMv8. The Specification at paragraph [0008] confirms that x86 is a strong memory order architecture and ARM (including ARMv7 and ARMv8) is a weak memory order architecture. Accordingly, Chakraborty teaches performing compilation processing on the IR to obtain an executable file suitable for a target architecture that is a strong memory order architecture (x86) or a weak memory order architecture (ARMv7/ARMv8)).
Chakraborty is silent to disclose, however in an analogous art, Corbet teaches converting volatile memory access code in object code of the first file into atomic memory access code, to obtain a second file, wherein the object code is memory access code related to concurrency control (The specification at paragraphs [0077]–[0078] defines "volatile" as a C/C++ keyword whose function is to prevent compiler optimization, and defines "atomic" as the C11/C++11 atomic keyword that ensures order-consistent memory accesses. The Specification at paragraph [0016] defines "memory access code related to concurrency control" as code other than driver code, i.e., the user-space or kernel-space code that performs concurrency operations.
Chakraborty teaches processing memory access code related to concurrency control during compilation, distinguishing C11 atomic accesses from non-atomic accesses and selectively introducing fences to preserve memory ordering across architectures (Chakraborty, sections 2.4; 4.2; 4.6; 4.8 and figures 9b; 13b). Chakraborty thus operates on memory access code related to concurrency control within the LLVM IR (the "first file"). However, Chakraborty assumes that the input C11 program already uses C11 atomic types where required for synchronization (Chakraborty, section 2.4: "C11 uses atomic accesses to achieve synchronization and avoid data race on non-atomics"). Chakraborty does not expressly teach a transformation step that converts pre-existing volatile-qualified memory accesses into C11 atomic memory accesses prior to the architecture mapping.
Corbet teaches that pre-existing concurrency-control code in C/C++ commonly uses non-atomic memory accesses guarded by explicit memory barriers, and teaches replacing such accesses with C11 atomic memory accesses with explicit memory ordering. Corbet provides the explicit substitution example (Corbet, page 1):
smp_store_release(&x, new_value); → atomic_store(&x, new_value, memory_order_release);
Corbet further teaches that the C11 atomic substitution is desirable because the resulting C11 atomic code "causes the desired code to be emitted directly by the compiler" rather than relying on "tricky, architecture-specific code" (Corbet, page 2). Corbet thus teaches the conceptual operation of converting volatile/non-atomic concurrency-control memory accesses to C11 atomic memory accesses. Performing this conversion within the compilation pipeline produces a transformed IR (the claimed "second file") that contains C11 atomic memory accesses in place of volatile-qualified memory accesses.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chakraborty’s compilation pipeline to incorporate, as a preliminary transformation, the volatile-to-atomic memory access conversion taught by Corbet. The motivation for the combination is supplied directly by Corbet and aligns with the express purpose of Chakraborty: (a) Corbet expressly teaches that, in pre-existing C/C++ concurrency-control code, replacing volatile/barrier-guarded memory accesses with C11 atomic memory accesses enables the compiler to emit architecture-appropriate ordering code automatically rather than relying on hand-written, architecture-specific barrier sequences (Corbet, page 2). This rationale is precisely the rationale that motivates Chakraborty’s entire architecture-to-architecture mapping framework, which is implemented in the compiler and aims to "generate target binary code" that preserves observable behaviors across architectures (Chakraborty, sections 1; 9). (b) Chakraborty’s pipeline as described operates on programs that already use C11 atomic accesses, but real-world C/C++ programs intended for cross-architecture migration commonly contain volatile-qualified concurrency-control code (Corbet, pages 1–2, discussing Linux kernel practice). To enable Chakraborty’s pipeline to operate on such pre-existing real-world code, a person of ordinary skill in the art would have been motivated to add a frontend conversion step that converts volatile concurrency-control accesses to C11 atomic accesses, as taught by Corbet, before the architecture mapping passes operate on the IR. (c) The combination is a predictable application of well-understood techniques: Corbet’s teaching of the volatile-to-atomic substitution operates at the source/IR level on memory access expressions, and Chakraborty’s pipeline already operates on the LLVM IR through compiler passes. Inserting Corbet’s substitution as an additional LLVM pass preceding Chakraborty’s mapping passes does not alter the underlying mechanics of either reference and yields a predictable result: the combined pipeline accepts a broader class of input programs (those using volatile for concurrency) and processes them through the architecture mapping to produce executables for the target architecture. With respect to claim 2 (original), Chakraborty teaches deleting a separate memory fence in the object code, wherein the separate memory fence is a separate inline assembly instruction in the object code, and the separate inline assembly instruction is a memory fence instruction (Chakraborty expressly teaches deleting redundant separate memory fence instructions from the object code following the architecture mapping. Chakraborty’s section 6 sets out fence-elimination algorithms implemented as LLVM passes that identify and delete redundant fence instructions on the program control-flow graph (see sections 6 and figure 16). Specifically: (a) Procedure X86FELIM (see figure 16, lines 1–7) identifies and deletes redundant MFENCE instructions in x86 object code that are not necessary to order an intervening store-load pair on different memory locations. (b) Procedure ARMV8FELIM (see figure 16) identifies and deletes redundant DMBFULL, DMBLD, and DMBST fence instructions in ARMv8 object code, including across the multiple intermediate steps described in section 6.2. (c) Procedure ARMV7FELIM (see figure 16, lines 8–13) identifies and deletes redundant DMB fence instructions in ARMv7 object code, including the redundant trailing DMB fences that arise after ARMv8→ARMv7 mapping (see section 6.3).
The fence instructions deleted by these procedures (MFENCE on x86; DMB, DMBFULL, DMBLD, DMBST on ARM) are each separate inline assembly memory-fence instructions emitted by the compiler into the object code. Examiner notes: Deletion of any one such fence by the corresponding fence-elimination pass therefore reads on the limitation requirement. With respect to claim 6 (original), Chakraborty teaches wherein the source file is a C/C++ source file (Chakraborty expressly teaches operating on C11 source programs (Chakraborty, section 8.1)). With respect to claim 8, the claim is directed to a computer device that corresponds to the method recited in claim 1, respectively (see the rejection of claim 1 above; wherein Chakraborty also teaches such device. Chakraborty implements its compilation pipeline as software running on a computer system that includes one or more processors and a memory storing the program code (Chakraborty, section 8)).
With respect to claim 9, the claim is directed to a computer device that corresponds to the method recited in claim 2, respectively (see the rejection of claim 2 above).
With respect to claim 13, the claim is directed to a chip system that corresponds to the method recited in claim 1, respectively (see the rejection of claim 1 above; wherein Chakraborty also teaches such system. Chakraborty implements its compilation pipeline as software running on a computer system that includes one or more processors and a memory storing the program code (Chakraborty, section 8)).
With respect to claim 14, the claim is directed to a chip system that corresponds to the method recited in claim 2, respectively (see the rejection of claim 2 above).
With respect to claim 18, the claim is directed to a non-transitory computer-readable storage medium that corresponds to the method recited in claim 1, respectively (see the rejection of claim 1 above; wherein Chakraborty also teaches such system. Chakraborty implements its compilation pipeline as software running on a computer system that includes one or more processors and a memory storing the program code (Chakraborty, section 8). The non-transitory limitation of claim 18 is satisfied by ordinary persistent computer-readable storage media that store the LLVM-based compiler implementation described in Chakraborty).
With respect to claim 19, the claim is directed to a non-transitory computer-readable storage medium that corresponds to the method recited in claim 2, respectively (see the rejection of claim 2 above).
With respect to claim 20, the claim is directed to a computer program that corresponds to the method recited in claim 1. Chakraborty implements its compilation pipeline as software running on a computer system that includes one or more processors and a memory storing the program code (Chakraborty, section 8)).
Claims 3, 7, 10 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Soham Chakraborty (“On Architecture to Architecture Mapping for Concurrency”, hereinafter Chakraborty) in view of Jonathan Corbet (“C11 atomic variables and the kernel”, hereinafter Corbet) and further in view of Bor-Yeh Shen et al. (“LLBT: An LLVM-based Static Binary Translator”, hereinafter Shen). With respect to claim 3 (currently amended), Chakraborty in view of Corbet is silent to disclose, however in an analogous art, Shen teaches converting the inline assembly code suitable for the source architecture into inline assembly code or a compiler built-in function capable of running in the target architecture, wherein the source architecture and the target architecture are two different hardware memory order architectures (Chakraborty’s pipeline accepts C11 source as input and emits target-architecture executables; Chakraborty does not describe how source-architecture instruction-level constructs bound to one ISA are translated to instruction-level constructs for a different ISA during compilation. Corbet addresses high-level C/C++ memory-access primitives only. Shen’s frontend disassembles an ARM binary in ELF format to an ARM assembly file, and the LLBT IR converter takes the disassembled source-architecture instructions as input (Shen, section 3, stage 1: “An ARM input binary is disassembled to an assembly file, and then an IR converter will translate these ARM assembly instructions into LLBT’s internal IR” and figure 1) — these source-architecture instructions reading on “inline assembly code suitable for a source architecture” as recited in the claim. Shen translates each such source-architecture instruction into a corresponding sequence of LLVM IR operations based on the documented semantics of the source instruction (Shen, section 4.3: “The instruction translation is a one-to-many mapping process between ARM and LLVM instructions” and figures 3, 4 illustrating the translation of andsne r1, r1, r2 through conditional execution check, instruction body, and conditional flags update sequences). Shen subsequently lowers the LLVM IR through the LLVM optimizer (opt), the LLVM static compiler (llc), and the target assembler and linker to emit target-architecture instruction-level output for ISAs that differ from the source ARM ISA, including x86 (IA32), x86–64, MIPS, and other ARMs such as ARMv7 (Shen, abstract; section 1; section 3, stages 3–6 and figure 1) — the emitted target-architecture instruction-level output reading on “inline assembly code … capable of running in the target architecture” as recited in the claim. Where Shen’s source architecture is ARM and the target architecture is x86 (or x86–64), the source and target architectures are two different hardware memory order architectures, since x86 is a strong memory order architecture and ARM is a weak memory order architecture (Specification paragraph [0008]; Shen, abstract identifying ARM→x86 migration) — satisfying the recited “wherein the source architecture and the target architecture are two different hardware memory order architectures”. Further, the first file (the LLVM IR mapped to the “first file” in claim 1 above) is associated with a source file that comprises source code containing the source-architecture inline assembly being converted, satisfying the recited “the first file associated with the source file comprises source code, the source file comprises inline assembly code suitable for a source architecture”. Examiner notes: In a typical compiler context, the term “inline assembly code” refers to assembly fragments embedded within a high-level language source file (e.g., asm("…") or __asm__ blocks in C/C++). The Specification does not provide an express lexicographic definition of this term. The mapping above relies on the broader reading that source-architecture instruction-level constructs translated by an LLVM-based front end fall within the scope of “inline assembly code suitable for a source architecture.” It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Chakraborty + Corbet compilation pipeline of claim 1 to incorporate the source-architecture-instruction-to-target-architecture-instruction translation taught by Shen, in order to enable the pipeline to handle source-architecture inline assembly encountered in real-world C/C++ programs intended for cross-architecture migration. (a) Both Chakraborty and Shen build their respective contributions on top of the LLVM compiler infrastructure (Chakraborty, section 8.1, modifying x86, ARMv7, and ARMv8 code-generation phases in LLVM; Shen, sections 1, §3, leveraging the LLVM optimizer, llvm-as, and llc). A person of ordinary skill in the art seeking to extend Chakraborty’s C-source / LLVM-IR pipeline to handle source-architecture inline assembly inputs would have looked to Shen, which expressly demonstrates how to lift source-architecture assembly into LLVM IR and lower it back out to target-architecture instruction-level output via that same LLVM infrastructure. (b) Corbet expressly identifies that pre-existing C/C++ concurrency-control code intended for cross-architecture use commonly relies on “tricky, architecture-specific code” (Corbet, pages 1–2). A person of ordinary skill in the art reading Chakraborty + Corbet would have recognized that real-world C/C++ programs intended for cross-architecture migration commonly contain source-architecture inline assembly that cannot be executed on a target architecture without conversion, and would have been motivated to look to Shen for the conceptual technique of source-architecture-instruction → LLVM IR → target-architecture-instruction translation that addresses this need (Shen, abstract; section 1, third bullet contribution: “translate an instruction set to a target-independent compiler IR”). (c) Adding Shen’s instruction-level lifting and lowering technique to the Chakraborty + Corbet pipeline is a predictable application of a known technique to solve a recognized problem. Shen’s technique already operates on LLVM IR — the same intermediate representation used by Chakraborty’s pipeline. Inserting an LLVM IR-level pass that converts source-architecture instruction-level constructs to target-architecture instruction-level constructs along the lines of Shen does not alter the underlying mechanics of either reference and produces a predictable result: a combined pipeline that accepts a broader class of input programs (those containing source-architecture inline assembly) and emits target-architecture executable form for a target architecture having a different hardware memory order model than the source architecture. With respect to claim 7 (currently amended), Chakraborty teaches wherein the source architecture is a strong memory order architecture, and the target architecture is the weak memory order architecture (Chakraborty’s figure 1 depicts the full set of bidirectional mappings between x86, ARMv8, and ARMv7/ARMv7-mca, including: (i) Strong→Weak — x86→ARMv8 (Chakraborty, section 4.1 and figure 9a) and x86→ARMv7 via Chakraborty’s ARMv8 intermediate model (Chakraborty, section 2.5)) or the source architecture is a weak memory order architecture, and the target architecture is the strong memory order architecture ((ii) Weak→Strong — ARMv8→x86 (Chakraborty, section 4.3 and figure 12b) and ARMv7→x86 via the intermediate model (Chakraborty, section 2.5)) or the source architecture is a strong memory order architecture, and the target architecture is the strong memory order architecture ((iii) Strong→Strong — the x86→x86 round-trip taught by Chakraborty’s bidirectional mapping framework, in which Chakraborty teaches that x86→ARMv8→x86 produces output equivalent to direct x86 compilation (Chakraborty, section 2.5; section 4.1; section 4.3)) or the source architecture is a weak memory order architecture, and the target architecture is the weak memory order architecture ((iv) Weak→Weak — ARMv7→ARMv8 (Chakraborty, section 4.4 and figure 12a) and ARMv8→ARMv7 (Chakraborty, section 4.5 and figure 13a)).
With respect to claim 10, the claim is directed to a computer device that corresponds to the method recited in claim 3, respectively (see the rejection of claim 3 above).
With respect to claim 15, the claim is directed to a chip system that corresponds to the method recited in claim 3, respectively (see the rejection of claim 3 above).
Allowable Subject Matter
Claims 4-5, 11-12 and 16-17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights