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

FLEXIBLE OPTIMIZED DATA HANDLING IN SYSTEMS WITH MULTIPLE MEMORIES

Final Rejection §103§112§DOUBLEPATENT
Filed
Apr 05, 2023
Priority
Jun 13, 2016 — continuation of 10/996,989 +1 more
Examiner
HEBERT, THEODORE E
Art Unit
2199
Tech Center
2100 — Computer Architecture & Software
Assignee
International Business Machines Corporation
OA Round
8 (Final)
74%
Grant Probability
Favorable
9-10
OA Rounds
0m
Est. Remaining
88%
With Interview

Examiner Intelligence

Grants 74% — above average
74%
Career Allowance Rate
336 granted / 453 resolved
+19.2% vs TC avg
Moderate +14% lift
Without
With
+14.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
30 currently pending
Career history
490
Total Applications
across all art units

Statute-Specific Performance

§101
20.5%
-19.5% vs TC avg
§103
57.4%
+17.4% vs TC avg
§102
6.3%
-33.7% vs TC avg
§112
9.1%
-30.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 453 resolved cases

Office Action

§103 §112 §DOUBLEPATENT
DETAILED ACTION This office action is responsive to amendment filed on April 7, 2026 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 were pending. Claims 1, 4 – 8, 13, 16 – 18, and 21 are amended. Claim 22 is new. Claims 1 – 10, 12 – 18, 20, and 22 are pending. Applicants' arguments have been carefully and respectfully considered and found not persuasive. Accordingly, this action has been made FINAL. Response to Arguments 1. With respect to Applicant’s argument on pgs. 9 – 11 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 limitations presented in the argument are either disclosed in the cited claims of the references, for example, claims 1 and 5 of 10,996,989 or in the citation to the prior art reference used in the double patenting rejection such as Chen’s teaches of access frequency. Therefore, the claims remain rejected under double patenting. 2. With respect to Applicant’s argument on pgs. 13 – 16 of the Remarks stating that prior art reference Chen fails to teach the newly added limitations, examiner respectfully. See infra § Claim Rejections - 35 USC §103 § Claim 1. Chen teaches using attributes to map data to particular memory including to active memory devices where the attributes include access frequency, code region covered by the attribute, layout of data such as “read and write data.” Chen at ¶¶ 0034, 0035; id. at ¶¶ 0011, 0030, & 0036. Chen further may 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). Therefore, Chen teaches the newly added limitations. 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 - 22 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 - 22 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) In light of Applicant’s amendments the rejections made under 35 USC 112(a) are withdrawn. 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, and 20 - 22 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 the 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 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 elements of the data region, based on determined data access cost savings, wherein the compiler selects the one or more data handling policies by: weighing costs and benefits of different data handling policies for the data region, the selected one or more data handling policies including using one of the software libraries to perform the data transfers based on the access frequency information of the data region, and wherein the software libraries represent different software mechanisms that characterize the one or more communication channels; and29Attorney 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).} Claims 21 and 22 With respect to claims 21 and 22, Chen and Megiddo teach the invention as claimed, including: wherein determining one or more data handling policies further includes analyzing metrics including coherence and 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 THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. 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./ September 24, 2026 Examiner, Art Unit 2199 /LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Read full office action

Prosecution Timeline

Show 33 earlier events
Jan 01, 2026
Response after Non-Final Action
Jan 09, 2026
Examiner Interview (Telephonic)
Jan 20, 2026
Non-Final Rejection mailed — §103, §112, §DOUBLEPATENT
Mar 25, 2026
Interview Requested
Mar 31, 2026
Applicant Interview (Telephonic)
Mar 31, 2026
Examiner Interview Summary
Apr 07, 2026
Response Filed
Oct 06, 2026
Final Rejection mailed — §103, §112, §DOUBLEPATENT (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12762398
VEHICLE SENSOR DATA ACQUISITION
3y 12m to grant Granted Oct 13, 2026
Patent 12748588
PACKAGE MAINTENANCE ARCHITECTURE
4y 2m to grant Granted Sep 29, 2026
Patent 12748582
USER ENVIRONMENT MANAGEMENT
3y 11m to grant Granted Sep 29, 2026
Patent 12737159
DATA SCIENCE WORKFLOW EXECUTION PLATFORM WITH AUTOMATICALLY MANAGED CODE AND GRAPH-BASED DATA JOB MANAGEMENT
3y 10m to grant Granted Sep 15, 2026
Patent 12705038
CODE PACKAGING FOR FLEXIBLE DEPLOYMENT WITHIN A MULTI-TENANT SYSTEM
3y 6m to grant Granted Aug 11, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

9-10
Expected OA Rounds
74%
Grant Probability
88%
With Interview (+14.2%)
3y 0m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 453 resolved cases by this examiner. Grant probability derived from career allowance 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