Prosecution Insights
Last updated: April 18, 2026
Application No. 18/296,012

FLEXIBLE OPTIMIZED DATA HANDLING IN SYSTEMS WITH MULTIPLE MEMORIES

Non-Final OA §103§112§DP
Filed
Apr 05, 2023
Examiner
HEBERT, THEODORE E
Art Unit
2199
Tech Center
2100 — Computer Architecture & Software
Assignee
International Business Machines Corporation
OA Round
7 (Non-Final)
74%
Grant Probability
Favorable
7-8
OA Rounds
3y 1m
To Grant
88%
With Interview

Examiner Intelligence

Grants 74% — above average
74%
Career Allow Rate
324 granted / 440 resolved
+18.6% vs TC avg
Moderate +15% lift
Without
With
+14.9%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
28 currently pending
Career history
468
Total Applications
across all art units

Statute-Specific Performance

§101
24.3%
-15.7% vs TC avg
§103
44.2%
+4.2% vs TC avg
§102
5.7%
-34.3% vs TC avg
§112
13.5%
-26.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 440 resolved cases

Office Action

§103 §112 §DP
Le lDETAILED ACTION This office action is responsive to request for continued examination filed on December 18, 2025 in this application Chen et al., U.S. Patent Application No. 18/296,012 (Filed April 5, 2023), claiming priority to Chen et al., U.S. Patent Application No. 17/189,856 (Filed March 2, 2021), now U.S. Patent No. 11,687,369, claiming priority to Chen et al., U.S. Patent Application No. 15/180756 (Filed June 13, 2016), now U.S. Patent No. 10,996,989 (“Chen”). Claims 1 – 10 and 12 – 18, 20, and 21 are pending. Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission of on December 18, 2025 has been entered. Response to Arguments 1. With respect to Applicant’s argument on pgs. 7 - 8 of the Applicant’s Remarks (“Remarks”) stating that the amendments overcome the nonstatutory double patenting rejection, examiner respectfully disagrees. See infra § Claim Rejections – Double Patenting. The argument presented fails to identify particular limitations of the instant claims which are allegedly not taught by the co-assigned patents in light of the cited prior art and thus is conclusory and unpersuasive. 2. With respect to Applicant’s argument on pgs. 8 – 13 of the Remarks stating that prior art reference Chen fails to teach software libraries and also the newly added limitation directed to comparing library costs, examiner respectfully disagrees in part. See infra § Claim Rejections - 35 USC §103 § Claim 1. It is noted initially that the specification does not provide a disclosure for comparing the costs of libraries. See infra § Claim Rejections 112(a). In addition, Chen teaches comparting read and write costs and then selecting, i.e. determining, mapping code for inclusion in the source code which performs operating system function calls, i.e. calls operating system library functions, to optimize the read and write costs of the code. Chen at ¶¶ 0030 – 0034. Therefore, Chen teaches software libraries and comparing their costs. 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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp. 1. Claims 1 – 10 and 12 – 18, 20, and 21 are rejected on the ground of obviousness-type double patenting as being unpatentable over claims 1 - 6 of parent U.S. Patent No. 10,996,989. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the ‘989 Patent anticipate the claims of the instant Application, with the exception of the limitation “rarity of data write access in the data region with multiple data read accesses through the accelerator processor and accelerator memory,” which would be obvious to one having ordinary skill in the art before the effective filing date of the claimed invention in light of the teachings of prior art reference Chen (see infra) which teaches access frequency data properties used to map data to particular active memory devices which include multiple distinct accelerator memory locations interconnected by a network 212 where each accelerator memory includes both a memory and an accelerator processor, such as 210. Id at ¶¶ 0023, 0034, & 0035 and fig. 2 (using attributes to map data to particular memory including to active memory devices); id. at ¶¶ 0011, 0030, 0036 (attributes including access frequency). One of ordinary skill the art would have been motivated to combine the teachings of prior art reference Chen with the Application for the purpose of using data characteristics to optimizing memory locations. 2. Claims 1 – 10 and 12 – 18, 20, and 21 are rejected on the ground of obviousness-type double patenting as being unpatentable over claims 1 - 7 of parent U.S. Patent No. 11,687,369. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the ‘369 Patent anticipate the claims of the instant Application, with the exception of the limitation “rarity of data write access in the data region with multiple data read accesses through the accelerator processor and accelerator memory,” which would be obvious to one having ordinary skill in the art before the effective filing date of the claimed invention in light of the teachings of prior art reference Chen (see infra) which teaches access frequency data properties used to map data to particular active memory devices which include multiple distinct accelerator memory locations interconnected by a network 212 where each accelerator memory includes both a memory and an accelerator processor, such as 210. Id at ¶¶ 0023, 0034, & 0035 and fig. 2 (using attributes to map data to particular memory including to active memory devices); id. at ¶¶ 0011, 0030, 0036 (attributes including access frequency). One of ordinary skill the art would have been motivated to combine the teachings of prior art reference Chen with the Application for the purpose of using data characteristics to optimizing memory locations. Claim Rejections - 35 USC § 112(a) The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1 and 13, are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1 and 13 are rejected under 35 U.S.C. 112(a) because the claim recites “determine, by the compiler, the software libraries to perform the data transfers by comparing the data write cost and the data read coset for the data region, the software libraries including different reusable software mechanisms that characterize the one or more appropriate communication channels.” The specification does not appear to support determining software libraries to use, let alone determining libraries by comparing costs. Claims 2 – 10, 12, 14 – 18, 20, and 21 are rejected as depending on claims 1 and 13 respectively. Claim Rejections 35 U.S.C. §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 of this title, 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claims 1 – 10 and 12 – 18, 20, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al., United States Patent Application Publication No. 2014/0130027 (Published May 8, 2014, filed November 26, 2012) (“Chen”), in view of Megiddo et al., United States Patent No. 5,953,531 (Patented September 14, 1999, filed July 25, 1997) (“Megiddo”). Claims 1 and 13 With respect to claims 1 and 13 Chen teaches the invention as claimed including a computer-implemented method comprising: {A compiler adds codes to create a storage mapping plan as instructions to the runtime to map regions of the code data to particular interconnected memory locations. Chen at ¶¶ 0034 & 0035 (adding attributes to map data to particular memory); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0023 & fig. 2 (multiple distinct memory locations interconnected by a network 212).} selecting a scope from a plurality of scopes in the application, each scope of the plurality of scopes [being defined by] a section of application code; {“In block 302, the compiler divides source code into code sections” and uses code attributes [properties] of the sections to create a storage mapping plan [policies] as instructions to the runtime to map the sections of the code data to particular interconnected memory locations. Chen at ¶¶ 0029, 0034 & 0035 (using attributes to map data to particular memory); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified). The sections of the application code are divided according to their scope, such as global variables. Id. at ¶ 0033.} determining, by a compiler, one or more data handling properties of a data region accessed in a selected scope, the data handling properties including access frequency information that determines rarity of data write access in the data region with multiple data read accesses through the accelerator processor and accelerator memory, determining, by the compiler at compile time, one or more data handling policies to select one or more appropriate communication channels and data placement for the data region based on the one or more data handling properties, wherein the data handling policies perform data transfers implemented by software libraries pushing and pulling the data, based on a determined data access cost savings; determine, by the compiler, the software libraries to perform the data transfers by comparing the data write cost and the data read coset for the data region, the software libraries including different reusable software mechanisms that characterize the one or more appropriate communication channels; 29Attorney Docket 4965-000635-USEP Docket 4035P319-US - TD{“In block 302, the compiler divides source code into code sections” and uses code attributes [properties] of the sections to create a storage mapping plan [policies] as instructions to the runtime to map the sections of the code data to particular interconnected memory locations and to specify when a first code [library] performs a write access to push data to a location from which it may only be written once and from which it is then pulled by a read access of a second code [library] after the write. Chen at ¶¶ 0029, 0034 & 0035 (using attributes to map data to particular memory); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory based on data write and multiple data read accesses); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified). The sections of the application code are divided according to their scope, such as global variables. Id. at ¶ 0033. The code attributes used by the compiler may direct storage [data placement] to specific memory locations, such as a specific memory vault of an active memory device, which when accessing or writing the data would have the effect of directing access to that storage location via a particular communication channel between a main processor and a memory controller of the memory vault of the active memory device, such as a route between the main processor using interconnect 212 as well as the internal route to the particular memory vault controller within the active memory device. Chen at id. at ¶¶ 0023, 0026, & fig. 2 (multiple distinct memory locations interconnected by a network 212 where each memory vault may have its own network access via its own memory controller). The compiler may use the code attributes [properties] to create a storage mapping plan [policies] as instructions, including “calls to an operating system” [libraries] to the runtime to map regions of the code data, such as code blocks identified by the attributes, to particular interconnected memory locations where the memory locations include accelerator memory and accelerator processors in the form of “active memory device 202” having “memory vault 206 and a processing element 210,” and where the code attributes include the frequency of data access such as “accesses to the data structures, type of accesses to the data structures” and gives an example of making a data policy based on the frequency attribute such as when data is rarely accessed, for example when “data structures that are classified as read only,” the data might be placed in the active memory device. Chen at ¶¶ 0034, 0035 (using attributes to map data to particular memory including to active memory devices); id. at ¶¶ 0011, 0030, & 0036 (attributes include access frequency, code region covered by the attribute, layout of data such as “read and write data”); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified); id. at ¶ 0023 & fig. 2 (multiple distinct accelerator memory locations interconnected by a network 212 where each accelerator memory includes both memory and an accelerator process, such as 210).} optimizing, by the compiler, the application by selecting one or memory locations in which to store the data region in accordance with at least the determined one or more data handling properties. {A compiler uses code attributes [properties] to create a storage mapping plan [policies] as instructions to the runtime to map regions [scopes] of the code data, such as code blocks identified by the attributes, to particular interconnected memory locations. Chen at ¶¶ 0034 & 0035 (using attributes to map data to particular memory); id. at ¶ 0011 (attributes include access frequency, code region covered by the attribute, layout of data such as “read and write data”); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified) id. at ¶ 0023 & fig. 2 (multiple distinct memory locations interconnected by a network 212).} However, Chen do not explicitly teach the limitation: [a scope] being defined by [a section of application code]{Megiddo does teach this limitation. Megiddo teaches a compiler optimizing an application by identifying sequences of instructions in the code, such as code loops, that define a region or a scope such that the compiler can determine data setup costs (such as read/write costs) for application data that will use various regions of memory. Id. at Abstract; col. 1 ll. 28 – 40 (compiler identifies a sequence of instructions that comprise a code loop); id. at col. 5 ll. 46 – 52; id. at col. 25 ln. 4 – col. 26 ln. 8. Chen and Megiddo are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of compiler optimizations, and both are trying to solve the problem of how to distribute application data to data storage regions. It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine a compiler optimization for using code region attributes to determine how code region scopes should be assigned to memory locations for execution, as taught in Chen, with the compiler optimizing data setup costs, as taught in Megiddo. Megiddo teaches that data setup costs are important for improving data locality. Id. at col. 3 ll. 55 - 62. Therefore, one having ordinary skill in the art would have been motivated to combine a compiler optimization for using code region attributes to determine how code region scopes should be assigned to memory locations for execution, as taught in Chen, with the compiler optimizing data setup costs, as taught in Megiddo, for the purpose of optimizing memory locations based on data locality improvements.} Claims 2 and 14 With respect to claims 2 and 14, Chen and Megiddo teach the invention as claimed, including: wherein the section of application code is demarcated by syntactic structures in the application code. {A compiler may use code attributes [properties] to create a storage mapping plan [policies] as instructions to the runtime to map regions of the code data, such as code blocks identified by the attributes, to particular interconnected memory locations. Chen at ¶¶ 0034 & 0035 (using attributes to map data to particular memory); id. at ¶ 0011 (attributes include access frequency, code region covered by the attribute, layout of data such as “read and write data”); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified) id. at ¶ 0023 & fig. 2 (multiple distinct memory locations interconnected by a network 212).} Claims 3 and 15 With respect to claims 3 and 15, Chen and Megiddo teach the invention as claimed, including: wherein the software libraries include a first software library and a second software library. {“In block 302, the compiler divides source code into code sections” and uses code attributes [properties] of the sections to create a storage mapping plan [policies] as instructions to the runtime to map the sections of the code data, to particular interconnected memory locations and to specify when a first code [library] performs a write access to push data to a location from which it may only be written once and from which it is then pulled by a read access of a second code [library] after the write . Chen at ¶¶ 0029, 0034 & 0035 (using attributes to map data to particular memory); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified). The sections of the application code are divided according to their scope, such as global variables. Id. at ¶ 0033.} Claims 4 and 16 With respect to claims 4 and 16, Chen and Megiddo teach the invention as claimed, including: wherein the first software library includes a policy to at least push data to a next location if the data is written exactly once in the selected scope. {“In block 302, the compiler divides source code into code sections” and uses code attributes [properties] of the sections to create a storage mapping plan [policies] as instructions to the runtime to map the sections of the code data, to particular interconnected memory locations and to specify when a first code [library] performs a write access to push data to a location from which it may only be written once and from which it is then pulled by a read access of a second code [library] after the write . Chen at ¶¶ 0029, 0034 & 0035 (using attributes to map data to particular memory); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified). The sections of the application code are divided according to their scope, such as global variables. Id. at ¶ 0033.} Claims 5 and 17 With respect to claims 5 and 17, Chen and Megiddo teach the invention as claimed, including: wherein the first software library pushes the data to other locations after a write access by copying the data. {“In block 302, the compiler divides source code into code sections” and uses code attributes [properties] of the sections to create a storage mapping plan [policies] as instructions to the runtime to map the sections of the code data, to particular interconnected memory locations and to specify when a first code [library] performs a write access to push data to a location from which it may only be written once and from which it is then pulled by a read access of a second code [library] after the write . Chen at ¶¶ 0029, 0034 & 0035 (using attributes to map data to particular memory); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified). The sections of the application code are divided according to their scope, such as global variables. Id. at ¶ 0033.} Claims 6 and 18 With respect to claims 6 and 18, Chen and Megiddo teach the invention as claimed, including: wherein the second software library pulls the data from the location where the data was last updated on a read access. {“In block 302, the compiler divides source code into code sections” and uses code attributes [properties] of the sections to create a storage mapping plan [policies] as instructions to the runtime to map the sections of the code data, to particular interconnected memory locations and to specify when a first code [library] performs a write access to push data to a location from which it may only be written once and from which it is then pulled by a read access of a second code [library] after the write . Chen at ¶¶ 0029, 0034 & 0035 (using attributes to map data to particular memory); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified). The sections of the application code are divided according to their scope, such as global variables. Id. at ¶ 0033.} Claim 7 With respect to claim 7, Chen and Megiddo teach the invention as claimed, including: further comprising determining, at compile time, one or more data handling policies for the data region based on the one or more data handling properties. {A compiler uses code attributes [properties] to create a storage mapping plan [policies] as instructions to the runtime to map scopes [data regions in a scope] of the code data, such as code blocks “data structures” identified by the attributes, to particular interconnected memory locations. Chen at ¶¶ 0034 & 0035 (using attributes to map data to particular memory); id. at ¶ 0011 (attributes include access frequency, code region covered by the attribute, layout of data such as “read and write data”); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified) id. at ¶ 0023 & fig. 2 (multiple distinct memory locations interconnected by a network 212).} Claim 8 With respect to claim 8, Chen and Megiddo teach the invention as claimed, including: further comprising determining data setup costs for a plurality of scopes in the application. {The compiler may optimize the application by identifying sequences of instructions in the code, such as code loops, and determining data setup costs (such as read/write costs) for application data that will use various regions of memory. Megiddo at Abstract; col. 1 ll. 28 – 40 (compiler identifies a sequence of instructions that comprise a code loop); id. at col. 5 ll. 46 – 52; id. at col. 25 ln. 4 – col. 26 ln. 8.} Claim 9 With respect to claim 9, Chen and Megiddo teach the invention as claimed, including: wherein the plurality of scopes use the data region in different memory locations based on the one or more data handling properties. {A compiler uses code attributes [properties] to create a storage mapping plan [policies] as instructions to the runtime to map regions [scopes] of the code data, such as code blocks identified by the attributes, to particular interconnected memory locations. Chen at id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified) id. at ¶ 0023 & fig. 2 (multiple distinct memory locations interconnected by a network 212).} Claim 10 With respect to claim 10, Chen and Megiddo teach the invention as claimed, including: wherein optimizing the application includes selecting one or memory locations in which to store the data region in accordance with at least the determined one or more dat handling policies. {A compiler may use code attributes [properties] to create a storage mapping plan [policies] as instructions to the runtime to map regions [scopes] of the code data, such as code blocks identified by the attributes, to particular interconnected memory locations. Chen at ¶¶ 0034 & 0035 (using attributes to map data to particular memory); id. at ¶ 0011 (attributes include access frequency, code region covered by the attribute, layout of data such as “read and write data”); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified) id. at ¶ 0023 & fig. 2 (multiple distinct memory locations interconnected by a network 212). The code attributes used by the compiler may direct storage [data placement] to specific memory locations, such as a specific memory vault of an active memory device, which when accessing or writing the data would have the effect of directing access to that storage location via a particular communication channel between a main processor and a memory controller of the memory vault of the active memory device, such as a route between the main processor using interconnect 212 as well as the internal route to the particular memory vault controller within the active memory device. Chen at id. at ¶¶ 0023, 0026, & fig. 2 (multiple distinct memory locations interconnected by a network 212 where each memory vault may have its own network access via its own memory controller).} Claim 12 With respect to claim 12, Chen and Megiddo teach the invention as claimed, including: wherein the one or more data handling properties further include coverage information. {A compiler may use code attributes [properties] to to identify the regions of the code data covered by the properties such as code blocks identified by the attributes. Chen at ¶¶ 0034 & 0035 (using attributes to map data to particular memory); id. at ¶ 0011 (attributes include access frequency, code region covered by the attribute, layout of data such as “read and write data”); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory).} Claim 20 With respect to claim 20, Chen and Megiddo teach the invention as claimed, including: wherein the one or more data handling properties further include data layout information. {A compiler may use code attributes [properties] to create a storage mapping plan [policies] as instructions to the runtime to map regions of the code data, such as code blocks identified by the attributes, to particular interconnected memory locations. Chen at ¶¶ 0034 & 0035 (using attributes to map data to particular memory); id. at ¶ 0011 (attributes include access frequency, code region covered by the attribute, layout of data such as “read and write data”); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory); id. at ¶ 0031 (compiler formulates plan [policies] based on attributes previously identified) id. at ¶ 0023 & fig. 2 (multiple distinct memory locations interconnected by a network 212).} Claim 21 With respect to claim 21, Chen and Megiddo teach the invention as claimed, including: wherein determining one or more data handling policies further includes analyzing metrics including coherence/consistency options, software and hardware enabled communication mechanisms, data placement in scope, and remote accesses based on specific application and system parameters employed. {“In block 302, the compiler divides source code into code sections” and uses code attributes [properties] of the sections to create a storage mapping plan [policies] as instructions to the runtime to map the sections of the code data, to particular interconnected memory locations. Chen at ¶¶ 0029, 0034 & 0035 (using attributes to map data to particular memory); id. at ¶¶ 0028 – 0030 (parameters and attributes are used by compiler to map regions of the code to memory). The data handling policies are derived from analyzing attributes such as presence of whether data is read/write [coherence/consistency], power budget attributes related to software/hardware communication mechanisms such as available instruction set architectures and device processing power availability, presence of global variable and source code explicit allocations [scope], and remote data access frequency. Id. at ¶¶ 0027, 0028, 0031, 0033; id. at ¶¶ 0023, 0026.} Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to THEODORE E HEBERT whose telephone number is (571)270-1409. The examiner can normally be reached on Monday to Friday 9:00 a.m. to 6:00 p.m.. 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, Lewis Bullock can be reached on 571-272-3759. 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. //T.H./ January 10, 2026 Examiner, Art Unit 2199 /LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Read full office action

Prosecution Timeline

Apr 05, 2023
Application Filed
Dec 15, 2023
Non-Final Rejection — §103, §112, §DP
Mar 13, 2024
Interview Requested
Mar 22, 2024
Examiner Interview Summary
Mar 22, 2024
Applicant Interview (Telephonic)
Mar 27, 2024
Response Filed
Jun 29, 2024
Final Rejection — §103, §112, §DP
Aug 27, 2024
Interview Requested
Sep 05, 2024
Applicant Interview (Telephonic)
Sep 06, 2024
Examiner Interview Summary
Sep 06, 2024
Response after Non-Final Action
Sep 23, 2024
Response after Non-Final Action
Sep 27, 2024
Request for Continued Examination
Sep 29, 2024
Response after Non-Final Action
Sep 29, 2024
Non-Final Rejection — §103, §112, §DP
Dec 09, 2024
Interview Requested
Dec 27, 2024
Response Filed
Mar 07, 2025
Final Rejection — §103, §112, §DP
May 06, 2025
Interview Requested
May 14, 2025
Examiner Interview Summary
May 14, 2025
Applicant Interview (Telephonic)
May 16, 2025
Response after Non-Final Action
Jun 16, 2025
Request for Continued Examination
Jun 20, 2025
Response after Non-Final Action
Jun 27, 2025
Non-Final Rejection — §103, §112, §DP
Sep 12, 2025
Interview Requested
Sep 17, 2025
Examiner Interview Summary
Sep 17, 2025
Applicant Interview (Telephonic)
Sep 23, 2025
Response Filed
Sep 29, 2025
Final Rejection — §103, §112, §DP
Nov 07, 2025
Interview Requested
Nov 19, 2025
Response after Non-Final Action
Dec 18, 2025
Request for Continued Examination
Jan 01, 2026
Response after Non-Final Action
Jan 09, 2026
Examiner Interview (Telephonic)
Jan 10, 2026
Non-Final Rejection — §103, §112, §DP
Mar 25, 2026
Interview Requested
Mar 31, 2026
Applicant Interview (Telephonic)
Mar 31, 2026
Examiner Interview Summary
Apr 07, 2026
Response Filed

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602217
SEAMLESS UPDATE PROVISIONING FOR COMMON CHIPSETS CARRYING DIFFERENT CPU FAMILIES
2y 5m to grant Granted Apr 14, 2026
Patent 12578948
Vehicle Software Upgrade Method and Related System
2y 5m to grant Granted Mar 17, 2026
Patent 12541361
SYSTEM AND METHOD FOR LIFECYCLE MANAGEMENT OPTIMIZATION
2y 5m to grant Granted Feb 03, 2026
Patent 12530175
METHOD AND SYSTEM FOR IMPLEMENTING CUSTOM UI ACTIONS IN A WEB APPLICATION USING HIDDEN CONTAINERS
2y 5m to grant Granted Jan 20, 2026
Patent 12530184
SELECTIVE FIRMWARE UPDATES FOR DENTAL EQUIPMENT
2y 5m to grant Granted Jan 20, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

7-8
Expected OA Rounds
74%
Grant Probability
88%
With Interview (+14.9%)
3y 1m
Median Time to Grant
High
PTA Risk
Based on 440 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month