DETAILED ACTION
This action is responsive to the application filed on August 01, 2024.
Claims 1-20 are pending and 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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submission of the Information Disclosure Statement dated December 30, 2025 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Drawings
The drawings filed on August 01, 2024 are acceptable for examination purposes.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,442,714 in view of Marathe et al. US Pat. No. 10,262,807 in view of Jiang et al. (US Pat. No. 9,280,395). Miller claims systems, methods, and computer-readable storage media for executing compiled code containing a plurality of parallel code fragments. Miller’s independent claims recite: (i) obtaining/storing executable code containing a plurality of parallel code fragments, where each parallel code fragment represents an alternative executable path through a code stream; (ii) the code stream is in a non-native instruction set architecture relative to the host computing system; (iii) determining a code-level/feature characteristic supported by the host; (iv) translating the executable code from the non-native instruction set architecture into native machine-readable code, including selecting a code fragment from among the plurality of parallel code fragments based on the code-level/feature characteristic; and (v) executing the translated machine-readable code within the hosted computing environment. Miller further claims runtime feature changes via an identifier-based fragment-replacement mechanism, including selection of an alternative parallel code fragment when the identifier changes.
The present independent claims (claims 1, 8, and 16) recite the same framework as Miller’s claims — an executable object containing a parallel code fragment, a selection-mask metadata identifying the parallel code fragment, translation of the executable, and selection of the parallel code fragment based on the selection mask — with the addition of a heterogeneous-dispatch element: the parallel code fragment contains a foreign code segment associated with a second instruction architecture distinct from the first instruction architecture, and a second processor (also referred to as the target processor) having a different instruction architecture executes that foreign code segment.
The heterogeneous foreign-code-dispatch addition does not render the present claims patentably distinct from Miller’s claims, because the addition would have been obvious to one of ordinary skill in the art before the effective filing date of the present application in view of well-known heterogeneous-computing practice as expressly disclosed by Marathe. Marathe expressly teaches that a single executable file can contain host code portions executed by a CPU and device code portions embedded within the host code, where the device code portions are executed exclusively by a GPU of a different instruction architecture (CUDA-based instruction architecture) (Marathe paragraphs [0003], [0006]–[0008], [0040], [0048], [0055]). Combining Miller’s selection-mask-driven enablement of parallel code fragments with Marathe’s heterogeneous CPU/GPU executable structure yields the present claimed configuration: a parallel code fragment carrying foreign code in a second instruction architecture for execution by a second processor.
For present claims 3 and 18, an additional secondary reference. Jiang expressly teaches a runtime scheduler that detects individual processors of a heterogeneous group based on their capabilities (Jiang paragraphs [0020], [0058]–[0059], [0061]) and that concurrently dispatches distinct binary versions of code to distinct processors for parallel execution (Jiang paragraphs [0063]–[0064]).
Claim Rejections - 35 USC § 112
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 4-5 and 8-15 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.
Claim 4 recites "wherein the method further comprises obtaining, from the second processor, a result of executing the foreign code". There is insufficient antecedent basis for this limitation in the claim. For purpose of examination, the examiner will interpret it as “the foreign code segment”.
Claim 8 recites the limitations "translating the parallel code fragment including the foreign code into machine-readable code in a second instruction architecture associated with a target processor; and causing the target processor to execute the foreign code." in lines 10-13. There is insufficient antecedent basis for this limitation in the claim. For purpose of examination, the examiner will interpret it as “the foreign code segment”.
Claim 9 recites "wherein the processing device further performs the operations comprising resuming execution of the application at a merge point encoded in the executable object in response to obtaining a result of executing the foreign code from the target processor". There is insufficient antecedent basis for this limitation in the claim. For purpose of examination, the examiner will interpret it as “the foreign code segment”.
Claim 10 recites "wherein the processing device and the target processor are components of the hosted computing environment.". There is insufficient antecedent basis for this limitation in the claim. For purpose of examination, the examiner will interpret it as “a hosted computing environment.”. Claim 11 recites "wherein the processing device further performs the operations comprising causing an operating system and firmware of the hosted computing environment to perform a handshake operation to determine the parallel code fragment is executable by the hosted computing environment.". There is insufficient antecedent basis for this limitation in the claim.
Claim 12 recites "wherein the processing device further performs the
operations comprising causing the operating system to update a user interface to indicate that the parallel code fragment is executable by the hosted computing environment". There is insufficient antecedent basis for this limitation in the claim.
Claim 13 recites " wherein executing the application based on an executable object further comprises translating instructions included in the executable code into machine code to be executed by the processing device". There is insufficient antecedent basis for this limitation in the claim. For purpose of examination, the examiner will interpret it as “the executable object”.
Dependent claims 5 and 14-15 do not overcome the deficiency of the base claim and, therefore, are rejected for the same reasons as the base 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.
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, 4-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Miller et al. (US Pub. No. 2022/0107795, hereinafter Miller – IDS 12/30/2025) in view of Marathe et al. (US Pub. No. 2013/0305234, hereinafter Marathe).
With respect to claim 1, Miller teaches a method (Miller discloses methods performed by a host computing system for processing executable code that includes parallel code fragments (Miller paragraph [0006]: “a method for executing compiled code having parallel code fragments is provided”)) comprising: obtaining an executable object associated with a first instruction architecture, the executable object including a parallel code fragment [[including a foreign code segment associated with a second instruction architecture;]] (Miller discloses obtaining executable code that includes parallel code fragments and that is encoded in a first (non-native) instruction set architecture (Miller paragraph [0007]: “the instructions cause the computing system to: store executable code having a plurality of parallel code fragments, each of the plurality of parallel code fragments representing alternative executable paths through a code stream, the code stream written in a non-native instruction set architecture with respect to the computing system”; Paragraph [0064]: “the applications 420 may be written in any language, or compiled in an instruction set architecture, which is compatible with execution within the hosted environment 410. … The applications 420 may be provided to the computing system 400 as executable code including a plurality of parallel code fragments”)).
obtaining a selection mask including metadata for identifying the parallel
code fragment [[including the foreign code segment;]] (Miller discloses that the parallel code fragments are identified using metadata, and that feature bits (which read on the recited “selection mask” under the broadest reasonable interpretation) are included within and obtained from the executable code (Miller paragraph [0073]: “The parallel code fragments may be identified using metadata within the compiled code that identifies the code fragment and a code level required for compatibility with that code fragment”; Paragraph [0079]: “the hosting firmware 412 will perform a process 604 to establish feature bits included within the received executable code having the parallel code fragments”; Paragraph [0089]: “a list header for an entry in the list is emitted (operation 806) including feature bits as may be required”)) and in response to detecting the selection mask in the executable object, enabling execution of the parallel code fragment by at least: translating the executable object into machine-readable code executable by a first processor (Miller discloses that detection of the feature bits / selection mask in the executable code triggers translation of the executable code into native machine-readable code for the host computing system’s processor 402, which reads on the recited “first processor” (Miller paragraph [0063]: “the hosting firmware 412 translates instructions stored in the hosted environment 410 for execution from an instruction set architecture of the hosted environment 410 to a native instruction set architecture of the host computing environment, i.e., the instruction set architecture of the processor 402”; Paragraph [0077]: “Upon determination of the code level supported by the processor executable and/or hosted environment, the code may be translated and executed according to the selected code level”)). selecting the parallel code fragment including the foreign code
segment based at least in part on the selection mask (Miller discloses selecting, based on the feature bits / selection mask, which parallel code fragment to include in the translated executable (Miller paragraph [0005]: “Translating the executable code includes selecting a code fragment from among the plurality of parallel code fragments for execution based on the code level supported by the host platform”; Paragraph [0098]: “a first feature assessment operation may determine if a first feature is enabled (at operation 1106); if the feature is enabled, then it will be translated accordingly”)). Miller is silent to disclose, however in an analogous art, Marathe teaches:
including a foreign code segment associated with a second instruction architecture (Marathe discloses that a single executable file can contain a host code portion and a device code portion embedded within the host code, where the device code portion is associated with the GPU’s instruction architecture (a CUDA-based instruction architecture) which is distinct from the CPU’s instruction architecture. Marathe paragraph [0003]: “host systems including a CPU and a graphics processing unit (GPU) have begun to take advantage of the parallel processing capability of the GPU … The GPU executes device code, whereas the CPU executes host code. The device code is typically embedded in the host code as a single file, thus creating a heterogeneous compiler environment.” Marathe paragraph [0006]: “the device code portion is written in a version of a Compute Unified Device Architecture programming language (CUDA).” Marathe paragraph [0007]: “the plurality of host code portions comprises instructions to be executed by a central processing unit (CPU) and the plurality of device code portions comprises instructions to be exclusively executed by a graphics processing unit (GPU).” Marathe’s device code portion embedded within the host code reads on the recited “foreign code segment associated with a second instruction architecture” (the GPU’s CUDA-based instruction architecture)). including the foreign code segment (The recitation “foreign code segment” refers to the same embedded code element addressed above. Marathe’s device code, embedded within the host executable as set forth above (Marathe paragraphs [0003], [0007]), reads on the recited “foreign code segment.”).
causing a second processor to execute the foreign code segment, the
second processor capable of executing operations included in the second instruction architecture (Marathe discloses that the GPU — a processor of a different type from the CPU and having the capability to execute operations in the GPU’s instruction architecture — executes the device code portion embedded within the host executable. Marathe paragraph [0007]: “the plurality of device code portions comprises instructions to be exclusively executed by a graphics processing unit (GPU).” Marathe paragraph [0040]: “computer system 100 comprises at least one CPU 101, a system memory 115, and at least one graphics processor unit (GPU) 110.” Marathe paragraph [0048]: “the host linker program generates a file that contains an executable form of linked device code that is capable of being executed by the GPU of a computer system as well as an executable form of linked host code that is capable of being executed by the CPU of a computer system.” Marathe paragraph [0055]: “these executable forms may then be placed and packaged within the same executable file where a CPU and GPU may access their respective files and perform their respective tasks.” Marathe’s GPU reads on the recited “second processor capable of executing operations included in the second instruction architecture,” and the GPU’s execution of the device code reads on the recited “causing a second processor to execute the foreign code segment.”).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation.
With respect to claim 2, Miller teaches wherein the method further comprises determining a hosted computing environment includes the second processor and the executable object includes the parallel code fragment executable [[by the second processor]] (Miller discloses a pre-scanning operation in which the hosted environment and hosting firmware determine whether parallel code fragments are present in the executable code and whether the hosted environment supports execution of those parallel code fragments (Miller paragraph [0091]: “the pre-scanning method 900 includes determining whether the hosted environment 410 and hosting firmware 412 are aware of the parallel code fragments included in the executable code (operation 902) and whether the hosted environment 410 supports processing of the parallel code fragments (operation 904)”; Paragraph [0101]: “if the host computing system is aware of the existence of parallel code fragments in the executable code, a further assessment is performed as to whether the hosted environment supports the use of parallel code fragments”)).
Miller is silent to disclose, however in an analogous art, Marathe teaches: by the second processor (Marathe discloses that the hosted computer system includes a second processor in addition to the CPU — specifically, a GPU — within the same computer system (Marathe paragraph [0040]: “computer system 100 comprises at least one CPU 101, a system memory 115, and at least one graphics processor unit (GPU) 110”; Paragraph [0042]: “The CPU 101 and the GPU 110 can also be integrated into a single integrated circuit die”). Marathe’s GPU reads on the recited “second processor” that the hosted computing environment is determined to include and by which the parallel code fragment is executable.)
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation. With respect to claim 4, Miller teaches wherein the method further comprises obtaining, [[from the second processor]], a result of executing [[the foreign code]] (Miller discloses collection of the result of executing the parallel code fragment at the merge point (Miller paragraph [0086]: “if a parallel code fragment at the next code level is emitted, a merge point code location is marked using metadata”; Paragraph [0098]: “translation of the merge point code”)).
Miller is silent to disclose, however in an analogous art, Marathe teaches:
from the second processor (Marathe’s GPU as the second processor providing the result of execution is set forth in the rejection of claim 1 (Marathe paragraphs [0003], [0007], [0048], [0055])).
the foreign code (Marathe’s device code as the foreign code is set forth in the rejection of claim 1 (Marathe paragraphs [0003], [0007])).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation. With respect to claim 5, Miller teaches wherein the method further comprises continuing execution of the executable object at a merge point based on the result (Miller discloses a merge point in the executable code at which execution continues following execution of the selected parallel code fragment (Miller paragraph [0086]: “if a parallel code fragment at the next code level is emitted, a merge point code location is marked using metadata”; Paragraph [0098]: “a first feature assessment operation may determine if a first feature is enabled …; if the feature is enabled, then it will be translated accordingly (at operation 1108) followed by a translation of the merge point code (operation 1122)”; Paragraph [0101]: “merge point code is translated as well, merging all portions of the translated code (operation 1210)”). With respect to claim 6, Miller teaches wherein the machine-readable code associated with the parallel code fragment encodes [[a payload comprising instructions in the second instruction architecture executable by the second processor]] (Miller discloses translation of the parallel code fragment into machine-readable code that is emitted as a list header including a code substitute and substitution locations (Miller paragraph [0089]: “a list header for an entry in the list is emitted (operation 806) including feature bits as may be required. The parallel code fragment issuance list code substitute is then issued (operation 808)”)). Miller is silent to disclose, however in an analogous art, Marathe teaches:
a payload comprising instructions in the second instruction architecture executable by the second processor (Marathe discloses that the executable file contains an executable form of linked device code that is in the GPU’s CUDA-based instruction architecture and is executable by the GPU (the second processor) (Marathe paragraph [0006]: device code “written in a version of a Compute Unified Device Architecture programming language (CUDA)”; Paragraph [0048]: “the host linker program generates a file that contains an executable form of linked device code that is capable of being executed by the GPU of a computer system”). Marathe’s linked device code, in the form of executable instructions in the CUDA-based instruction architecture executable by the GPU, reads on the recited “payload comprising instructions in the second instruction architecture executable by the second processor.”).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation. With respect to claim 7, Miller teaches wherein the executable object includes a plurality of parallel code fragments that are enabled by the selection mask (Miller discloses that the executable code includes a plurality of parallel code fragments that are enabled by the feature bits / selection mask (Miller paragraph [0006]: “the executable code having a plurality of parallel code fragments”; Paragraph [0098]: “the compiled executable code including the parallel code fragments can be assessed to determine if particular features are enabled … a first feature assessment operation may determine if a first feature is enabled …; a second feature assessment operation may be executed …; the nth feature assessment”)).
With respect to claim 8, Miller teaches one or more computer storage media having executable instructions embodied thereon, which, when executed by a processing device, cause the processing device to perform operations comprising (Miller discloses a computer-readable storage device storing computer-executable instructions executable by a processor of the computing system (Miller paragraph [0007]: “a computer-readable storage device is disclosed, and has computer-executable instructions stored thereon which are executable by a processor of a computing system”)): executing an application based on an executable object encoded in a first
instruction architecture, the executable object including a parallel code fragment [[containing a foreign code segment]] (Miller discloses executing application code derived from executable code encoded in a first (non-native) instruction architecture that contains parallel code fragments (Miller paragraphs [0007], [0064])).
enabling the parallel code fragment based on a selection mask (Miller discloses enablement of parallel code fragments based on feature bits / selection mask (Miller paragraphs [0079], [0098])) and
in response to detecting the selection mask in the executable object,
executing the parallel code fragment by at least: translating the parallel code fragment [[including the foreign code into machine-readable code in a second instruction architecture associated with a target processor;]] (Miller discloses that in response to detecting the feature bits / selection mask, the parallel code fragment is translated for execution (Miller paragraph [0098]: assessment of enabled features triggers translation; Paragraph [0101]: “if the host computing system is aware of the existence of parallel code fragments in the executable code, a further assessment is performed as to whether the hosted environment supports the use of parallel code fragments”)).
Miller is silent to disclose, however in an analogous art, Marathe teaches:
containing a foreign code segment (Marathe discloses that the parallel code fragment may contain a foreign code segment in the form of device code embedded within the host executable (Marathe paragraph [0003]: “The device code is typically embedded in the host code as a single file”; Paragraph [0007]: “the plurality of device code portions comprises instructions to be exclusively executed by a graphics processing unit (GPU)”)).
foreign code (The recitation “foreign code” in the translating step refers to the same device code element addressed above. Marathe’s device code (Marathe paragraphs [0003], [0007]) reads on the recited “foreign code.”).
including the foreign code into machine-readable code in a second instruction architecture associated with a target processor (Marathe discloses that the device code is written in the CUDA-based instruction architecture associated with the GPU as the target processor, and that the executable file contains an executable form of linked device code that is executable by the GPU (Marathe paragraph [0006]: “the device code portion is written in a version of a Compute Unified Device Architecture programming language (CUDA)”; Paragraph [0048]: “the host linker program generates a file that contains an executable form of linked device code that is capable of being executed by the GPU of a computer system”). Marathe’s executable form of linked device code in the CUDA-based instruction architecture reads on the recited “machine-readable code in a second instruction architecture associated with a target processor.”). causing the target processor to execute the foreign code (Marathe discloses that the GPU — the target processor — executes the device code embedded within the host executable (Marathe paragraph [0007]: device code portions “to be exclusively executed by a graphics processing unit (GPU)”; Paragraph [0048]: “an executable form of linked device code that is capable of being executed by the GPU of a computer system”; Paragraph [0055]: “the same executable file where a CPU and GPU may access their respective files and perform their respective tasks”)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation.
With respect to claim 9, Miller teaches wherein the processing device further performs the operations comprising resuming execution of the application at a merge point encoded in the executable object in response to obtaining a result of executing [[the foreign code]] [[from the target processor]] (Miller discloses a merge point in the executable code at which execution resumes following execution of the selected parallel code fragment, with collection of the result at that merge point (Miller paragraph [0086]: “a merge point code location is marked using metadata”; ¶ [0098]: “translation of the merge point code (operation 1122)”; Paragraph [0101]: “merge point code is translated as well, merging all portions of the translated code (operation 1210)”).
Miller is silent to disclose, however in an analogous art, Marathe teaches:
the foreign code (Marathe’s device code as the foreign code is set forth in the rejection of claim 8, (Marathe paragraphs [0003], [0007])). from the target processor (Marathe’s GPU as the target processor providing the result of execution is set forth in the rejection of claim 8, (Marathe paragraphs [0007], [0048], [0055])).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation. With respect to claim 10, Miller teaches wherein the processing device [[and the target processor]] are components of the hosted computing environment (Miller discloses the hosted computing environment that includes the processing device as a component (Miller paragraphs [0035], [0061]–[0062]: hosted environment hosted on a computing system including a processor and memory)).
Miller is silent to disclose, however in an analogous art, Marathe teaches:
the target processor (Marathe discloses that the GPU (target processor) and the CPU (processing device) are both components of the same computer system / hosted computing environment (Marathe paragraph [0040]: “computer system 100 comprises at least one CPU 101, a system memory 115, and at least one graphics processor unit (GPU) 110”; Paragraph [0042]: “The CPU 101 and the GPU 110 can also be integrated into a single integrated circuit die”)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation. With respect to claim 11, Miller teaches wherein the processing device further performs the operations comprising causing an operating system and firmware of the hosted computing environment to perform a handshake operation to determine the parallel code fragment is executable by the hosted computing environment (Miller discloses that the hosting firmware and the hosted environment (operating system) perform a handshake operation to establish feature bits and determine support for the parallel code fragments (Miller paragraph [0079]: “the hosting firmware 412 will perform a process 604 to establish feature bits … the hosted environment 410 will trigger an initialization and handshaking process 606 with the hosting firmware 412. The handshaking process 606 may indicate to the hosting firmware 412 that an assessment of which features are enabled for a particular code level should be performed”; Paragraph [0081]: “the hosting firmware 412 and hosted environment 410 cooperate during execution of the code, and will assess the feature bits”; Paragraph [0147]: “A handshake operation 1508 is performed between a hosted operating system 410 and processor executable 412 to establish feature bits”)). With respect to claim 12, Miller teaches wherein the processing device further performs the operations comprising causing the operating system to update a user interface to indicate that the parallel code fragment is executable by the hosted computing environment (Miller discloses a display of the computing system that displays a user interface for viewing executing tasks on the computing system and within the hosted environment (Miller paragraph [0062]: “a display 409 can be used for viewing a local version of a user interface, e.g., to view executing tasks on the computing system 400 and/or within the hosted environment 410”). Miller further discloses user-driven selection of parallel-code-fragment features through the user interface (Miller paragraph [0153]: “a user may select to incorporate or exclude debugging breakpoints”), which entails the user interface indicating to the user the availability of parallel code fragments executable by the hosted computing environment). With respect to claim 13, Miller teaches wherein executing the application based on an executable object further comprises translating instructions included in the executable code into machine code to be executed by the processing device (Miller discloses translation of instructions in the executable code into native machine code for execution by the processor of the host computing system (Miller paragraph [0063]: “the hosting firmware 412 translates instructions stored in the hosted environment 410 for execution from an instruction set architecture of the hosted environment 410 to a native instruction set architecture of the host computing environment, i.e., the instruction set architecture of the processor 402”; Paragraph [0077]: “the code that is executed has been translated to the native machine language of the host computing system”)). With respect to claim 14, Miller teaches wherein the selection mask includes metadata [[indicating a type associated with the target processor]] (Miller discloses that the selection mask / feature bits include metadata that identifies the parallel code fragment and indicates a corresponding compatibility characteristic (Miller ¶ [0073]: “The parallel code fragments may be identified using metadata within the compiled code that identifies the code fragment and a code level required for compatibility with that code fragment”)).
Miller is silent to disclose, however in an analogous art, Marathe teaches: indicating a type associated with the target processor (Marathe discloses that the executable file distinguishes host code portions (associated with the CPU as one processor type) from device code portions (associated with the GPU as another processor type), and that each device code portion is uniquely identified to indicate that it is to be exclusively executed by the GPU (Marathe paragraph [0005]: “uniquely identifying a device code portion associated with each host object fileset”; Paragraph [0007]: “the plurality of host code portions comprises instructions to be executed by a central processing unit (CPU) and the plurality of device code portions comprises instructions to be exclusively executed by a graphics processing unit (GPU)”). Marathe’s identification of code as device code reads on metadata indicating the type (GPU) associated with the target processor).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation.
With respect to claim 15, Miller teaches wherein the metadata further indicates at least one of: [[processor capabilities of the target processor, streaming instructions, and the second instruction architecture]] (Miller discloses metadata that further indicates compatibility-related characteristics for the parallel code fragment (Miller paragraph [0073]: metadata “that identifies the code fragment and a code level required for compatibility”)).
Miller is silent to disclose, however in an analogous art, Marathe teaches: the second instruction architecture (Marathe expressly discloses that the device code is written in the second instruction architecture associated with the GPU as target processor, namely the Compute Unified Device Architecture (CUDA) (Marathe paragraph [0006]: “the device code portion is written in a version of a Compute Unified Device Architecture programming language (CUDA)”; Paragraph [0012]: “the plurality of device code portions is written in a version of a Compute Unified Device Architecture programming language (CUDA)”). Combined with Miller’s metadata identification of parallel code fragments by their compatibility characteristics, Marathe’s CUDA-based identification of the device code reads on metadata indicating the second instruction architecture). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation. With respect to claim 16, Miller teaches a system comprising: a processor; and a memory coupled to the processor storing instructions that, as a result of being executed by the processor, cause the processor to (Miller discloses a computing system comprising a processor and a memory storing executable instructions (Miller paragraph [0005]: “a computing system is disclosed that includes a processor and a memory. When instructions stored in the memory are executed by the processor, the instructions cause the computing system to perform”)):
execute a set of operations encoded in an executable object
including a parallel code fragment, where the parallel code fragment [[includes foreign code associated with an instruction architecture corresponding to a target processor;]] (Miller discloses execution of operations encoded in executable code that includes parallel code fragments (Miller paragraphs [0007], [0064])).
determine the parallel code fragment within the executable object is
enabled based at least in part on a selection mask associated with the parallel code fragment (Miller discloses determining that a parallel code fragment is enabled based on feature bits / selection mask (Miller paragraph [0079]: “establish feature bits included within the received executable code having the parallel code fragments”; Paragraph [0098]: “the compiled executable code including the parallel code fragments can be assessed to determine if particular features are enabled”)). translate the parallel code fragment [[including the foreign code;]] (Miller discloses translation of the parallel code fragments (Miller paragraph [0098]: “if the feature is enabled, then it will be translated accordingly”; Paragraph [0101]: “the platform optimized … code can be executed natively on the host computing system”)). Miller is silent to disclose, however in an analogous art, Marathe teaches: includes foreign code associated with an instruction architecture corresponding to a target processor (Marathe discloses that the parallel code fragment includes device code (foreign code) associated with the GPU’s CUDA-based instruction architecture corresponding to the GPU as the target processor (Marathe paragraphs [0003], [0006]: “device code portion is written in a version of a Compute Unified Device Architecture programming language (CUDA)”; Paragraph [0007]: “device code portions comprises instructions to be exclusively executed by a graphics processing unit (GPU)”)).
Including the foreign code (The recitation “foreign code” in the translating step refers to the same device code element addressed above. Marathe’s device code (Marathe paragraphs [0003], [0007]) reads on the recited “foreign code.”). provide to the target processor the foreign code encoded in the instruction architecture (Marathe discloses that the device code (foreign code) encoded in the GPU’s CUDA-based instruction architecture is included in the executable file, from which the GPU (target processor) accesses and executes it (Marathe paragraph [0048]: “the host linker program generates a file that contains an executable form of linked device code that is capable of being executed by the GPU of a computer system”; Paragraph [0055]: “these executable forms may then be placed and packaged within the same executable file where a CPU and GPU may access their respective files and perform their respective tasks”)) and obtain a result of executing the foreign code from the target processor (Marathe discloses that the GPU (target processor) executes the device code (foreign code) and performs its respective task, yielding a result that is obtained from the GPU for further use by the host system (Marathe paragraph [0003]: “host systems including a CPU and a graphics processing unit (GPU) have begun to take advantage of the parallel processing capability of the GPU to perform tasks that would otherwise be performed by the CPU”; Paragraph [0055]: “perform their respective tasks”)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation. With respect to claim 17, Miller teaches wherein translating the parallel code fragment further [[comprises generating machine code executable by the target processor]] (Miller discloses generating machine-readable code as the result of translating the parallel code fragment (Miller paragraph [0098]: “if the feature is enabled, then it will be translated accordingly”; Paragraph [0101]: “the platform optimized … code can be executed natively on the host computing system”)).
Miller is silent to disclose, however in an analogous art, Marathe teaches comprises generating machine code executable by the target processor (Marathe discloses that the device code, after the linking and embedding operations described in Marathe, exists in the executable file in an executable form that is capable of being executed by the GPU as the target processor (Marathe paragraph [0048]: “the host linker program generates a file that contains an executable form of linked device code that is capable of being executed by the GPU of a computer system”)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation.
With respect to claim 19, Miller teaches wherein determining the parallel code fragment within the executable object is enabled further comprises obtaining the selection mask in response to a user enabling the parallel code fragment in a user interface (Miller discloses a user interface displayed on the computing system (Miller paragraph [0062]: “a display 409 can be used for viewing a local version of a user interface”), user-driven enablement of parallel-code-fragment features via that user interface (Miller paragraph [0153]: “a user may select to incorporate or exclude debugging breakpoints”), and triggering of the handshake process to reestablish the feature bits / selection mask in response to detected changes in enabled features (Miller paragraph [0081]: “If a change to the enabled features is detected, the handshaking process 606 may be triggered to cause feature bits to be reestablished”)). With respect to claim 20, Miller teaches wherein, prior to obtaining the selection mask, the processor executes the set of operations encoded in the executable object without executing the parallel code fragment (Miller discloses that the executable code includes a default (“neutral”) execution path that is used when the parallel code fragments are not enabled (Miller paragraph [0073]: “The executable code will further include a default execution path that may be used in the event none of the parallel code fragments is associated with a compatible code level”; Paragraph [0084]: “the method 700 is initialized and establishes a neutral code level e.g., a default execution path”; Paragraph [0101]: “If parallel code fragment support is not provided, only the neutral (default path) code requires translation … the platform optimized (in this case, default path) code can be executed natively on the host computing system”)).
Claims 3 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Miller et al. (US Pub. No. 2022/0107795, hereinafter Miller – IDS 12/30/2025) in view of Marathe et al. (US Pub. No. 2013/0305234, hereinafter Marathe) in view of Jiang et al. (US Pub. No. 2015/0095896, hereinafter Jiang).
With respect to claim 3, Miller teaches wherein the method further comprises determining [[the second processor]] is capable of executing [[the foreign code segment]] [[based at least in part on a capability of the second processor]] (Miller discloses determining whether the hosted environment is capable of executing the parallel code fragments via the pre-scanning and capability-assessment operations (Miller paragraph [0091]: “whether the hosted environment 410 supports processing of the parallel code fragments”; Paragraph [0101]: “whether the hosted environment supports the use of parallel code fragments”)).
Miller is silent to disclose, however in an analogous art, Marathe teaches: the second processor (Marathe’s GPU as the second processor is set forth in the rejection of claim 1 (Marathe paragraphs [0040], [0042])). foreign code segment (Marathe’s device code as the foreign code segment is set forth in the rejection of claim 1 (Marathe paragraphs [0003], [0007])).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation.
Miller in view of Marathe is silent to disclose, however in an analogous art, Jiang teaches based at least in part on a capability of the second processor (Jiang discloses runtime detection of individual processors within a heterogeneous group of processors and runtime determination of each processor’s capability to execute its corresponding binary version of computing-unit code (Jiang paragraph [0020]: “heterogeneous group of processors 142/144/146 may include CPU 142, GPU 144, and/or GPU 146”; Paragraph [0058]: “scheduler module 130 may detect individual processors of heterogeneous group of processors 142/144/146 based at least in part on the load data”; Paragraph [0059]: “scheduler module 130 may compile a first binary version and a second binary version of the computing unit source code. In some examples, the first binary version of the computing unit source code may be compatible with the first processor and the second binary version of the computing unit source code may be compatible with the second processor”; Paragraph [0061]: “dispatch module 140 may determine when one of the first processor and/or second processors become available based at least in part on load data from heterogeneous group of processors 142/144/146”). Jiang’s scheduler thus determines whether a given processor is capable of executing its corresponding binary version of the code based at least in part on a capability of that processor).
It would have been further obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Miller and Marathe with Jiang because: (i) Jiang is in the same field of computer-implemented runtime management of code execution on heterogeneous processors as Miller and Marathe (Jiang paragraph [0014]); (ii) Jiang expressly addresses the recognized need to determine, at runtime, which heterogeneous processor is capable of executing a corresponding code variant (Jiang paragraphs [0002], [0015]–[0018]); and (iii) incorporating Jiang’s capability-based determination into the Miller-and-Marathe combination yields the predictable result of ensuring that the foreign code segment is dispatched to the second processor only when the second processor’s capability supports executing that foreign code segment. With respect to claim 18, Miller teaches wherein the processor continues execution of the executable object [[asynchronously]] during execution [[of the foreign code]] [[by the target processor]] (Miller discloses continued execution of the executable object by the processor during execution of the selected, translated parallel code fragments (Miller paragraph [0081]: “the hosting firmware 412 and hosted environment 410 cooperate during execution of the code”; Paragraph [0098])). Miller is silent to disclose, however in an analogous art, Marathe teaches foreign code (Marathe’s device code as the foreign code is set forth in the rejection of claim 16, (Marathe paragraphs [0003], [0007])).
by the target processor (Marathe’s GPU as the target processor is set forth in the rejection of claim 16, (Marathe paragraphs [0007], [0040], [0048])).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine the teachings of Miller with the teachings of Marathe because: (i) both references are directed to the same field of computer-implemented generation and execution of executable code containing code variations targeted at different execution conditions; (ii) Miller expressly contemplates that its parallel code fragments may correspond to extensions of an instruction set architecture (Miller paragraph [0036]: “by extending an instruction set architecture to improve performance using extended operators”), inviting a skilled artisan to consider parallel code fragments targeted at alternative instruction architectures; (iii) Marathe expressly addresses the recognized need for executable files to contain code portions targeted at fundamentally different processor types in a heterogeneous CPU/GPU computing environment (Marathe paragraphs [0003]–[0004]); and (iv) applying Miller’s selection-mask-driven enablement of parallel code fragments to the heterogeneous CPU/GPU executable structure of Marathe yields the predictable result of dynamically enabling, at translation time, code fragments containing foreign code targeted at execution by a second processor having a distinct instruction architecture, allowing flexible deployment of heterogeneous workloads from a single executable file without recompilation.
Miller in view of Marathe is silent to disclose, however in an analogous art, Jiang teaches asynchronously (Jiang discloses asynchronous concurrent execution of distinct binary versions of code by distinct processors of a heterogeneous group, in which a first processor executes a first binary version while a second processor concurrently executes a second binary version (Jiang paragraph [0063]: “the transferring of the first binary version of the computing unit source code and the first context data to the first processor and the second binary version of the computing unit source code and the second context data to the second processor may be performed via dispatch module 140 in response to the first processor and/or second processors becoming available”; Paragraph [0064]: “the first binary version of the computing unit source code may be executed via the first processor consistent with the first context data and the second binary version of the computing unit source code may be executed via the second processor consistent with the second context data”). The concurrent execution by the first and second processors of distinct binary versions of code reads on the recited asynchronous execution).
It would have been further obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Miller and Marathe with Jiang because: (i) Jiang is in the same field of computer-implemented runtime management of code execution on heterogeneous processors as Miller and Marathe (Jiang paragraph [0014]); (ii) Jiang expressly addresses the recognized need to determine, at runtime, which heterogeneous processor is capable of executing a corresponding code variant (Jiang paragraphs [0002], [0015]–[0018]); and (iii) incorporating Jiang’s capability-based determination into the Miller-and-Marathe combination yields the predictable result of ensuring that the foreign code segment is dispatched to the second processor only when the second processor’s capability supports executing that foreign code segment.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Murphy et al. (US Pub. No. 2013/0305233) presents a novel solution that supports the separate compilation of host code and device code used within a heterogeneous programming environment. Embodiments of the present invention are operable to link device code embedded within multiple host object files using a separate device linking operation. Embodiments of the present invention may extract device code from their respective host object files and then linked them together to form linked device code. This linked device code may then be embedded back into a host object generated by embodiments of the present invention which may then be passed to a host linker to form a host executable file. As such, device code may be split into multiple files and then linked together to form a final executable file by embodiments of the present invention. (see abstract).
Marisetty et al. (US Pub. No. 2007/0061634) discloses methods and architectures for performing hardware error handling using coordinated operating system (OS) and firmware services. In one aspect, a firmware interface is provided to enable an OS to access firmware error-handling services. Such services enable the OS to access error data concerning platform hardware errors that may not be directed accessed via a platform processor or through other conventional approaches. Techniques are also disclosed for intercepting the processing of hardware error events and directing control to firmware error-handling services prior to attempting to service the error using OS-based services. The firmware services may correct hardware errors and/or log error data that may be later accessed by the OS or provided to a remote management server using an out-of-band communication channel. In accordance with another aspect, the firmware intercept and services may be performed in a manner that is transparent to the OS. (see abstract).
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