DETAILED ACTION
Claims 1,3,6-7,11-14,16-17,19-20 are amended. Claim 2,4,15 were previously canceled. Claims 1,3,5-14,16-20 are pending.
Priority: 12/5/2022(FP)
Assignee: RESEARCH & BUSINESS FOUNDATION SUNGKYUNKWAN UNIVERSITY
Claim Rejections - 35 USC § 112
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.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim(s) 1-12, 20 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.
1.Amended Claims 1,20 are rejected for reciting limitations that are unsupported by the spec.
Amended Claim 1 recites, ‘…….a heterogeneous system that includes a CPU and a GPU….and performs data migration between a CPU memory and a GPU memory…’.
Claim 1 recites a GPU memory and a CPU memory. The spec describes GPU as the device and recites a 'device memory' and a 'system memory' with distinct functions. The spec does not explicitly recite ‘GPU memory’ and ‘CPU memory’.
That said, claim 1 does not recite which component is the device memory and which component is the system memory. By failing to identify the device and the individual memories, claim 1 encompasses multiple, contradictory interpretations, rendering a scope unsupported by the spec and reciting new matter.
Claim 1 further recites, ‘performing page migration based on the frame-group number….’. Claim 1 does not recite the direction of the migration. However spec, Para-0007 recites, ‘performing page migration to the system memory….’.
Without reciting the migration direction, claim 1 covers all possible, even contradictory, methods of moving data, rendering a scope unsupported by the spec and reciting new matter. Accordingly, claim 1 is rejected for reciting limitations that are overly broad and unsupported by the spec. Claim 20 has the same issue.
Note: Claim 13 correctly recites page migration to the system memory/CPU memory only. But Claims 1,20 recite page migration in both directions, which is unsupported by the spec. The bidirectional page migration makes the scope overly broad.
2.Amended Claims 1,13,20 are rejected for reciting a limitation that is unsupported by the spec.
Amended claim 1 recites, ‘performing page migration…., without software intervention’.
Here, the recitation, ‘….without software intervention’, lacks written description support in the spec.
Spec, Para-0028 recites, ‘a page may be migrated without software intervention, and a page fault and software processing are offloaded to hardware’.
The spec does not explicitly recite detecting when the page fault occurs. For example, Fig. 3, step S102 detects a TLB miss but not a page fault. A TLB miss is not the same as a page fault. There is also no recitation of detecting ‘software processing’.
Since the page fault and software processing are not detected, how the page fault and software processing are offloaded to hardware, lacks written description support.
Therefore by reciting, ‘performing migration ….without software intervention’, the claim 1 is directed to a result without describing the necessary steps that achieve that result. Hence claim 1 is rejected for reciting new matter because the limitation, ‘performing migration….without software intervention’, is not described in the spec in sufficient detail to show that the inventor possessed the claimed subject matter, at the time of filing. Claims 13,20 have the same issue.
3.Amended Claims 1,13,20 are rejected for reciting a limitation that is unsupported by the spec.
Amended Claim 1 recites, ‘performing page migration based on the frame-group number using the inverted page group table….’.
Spec, Fig. 1, Para-0053 recites, ‘A free flag, a P-flag, a context ID CID, and a virtual page group number VPgN are stored in each table entry of the inverted page group table 210’. Here the spec does not recite storing the frame-group number in an entry/row of the inverted PG-table 210.
But spec, Para-0063 recites, ‘The…frame manager 114 may select the frame-group number required for the migration from the inverted page group table 210…..’. Here the spec assumes that the frame-group number is stored in the inverted PG-table.
The two paragraphs contradict each other. Contradictory paragraphs do not demonstrate possession. The contradiction shows that the inventor did not possess the full scope of the invention, at the time of filing.
Furthermore, the assumption that the frame-group number is stored in the inverted PG-table, without providing concrete evidence (steps, algorithm etc.) or a working example to show its generation and storage in an entry/row of the inverted PG-table, constitutes new matter. Hence claim 1 is rejected for reciting a limitation that is unsupported by the spec. Claims 13,20 have the same issue.
4.Amended Claims 1,13,20 are rejected for reciting a limitation that is unsupported by the spec.
Amended Claim 1 recites, ‘wherein the inverted….table indicates whether there is a page group allocated to a frame-group and ….table refers to a page group number allocated to the frame-group’.
A group of pages can be contiguous in virtual memory but dispersed across non-contiguous frames in physical memory. A page-group (a set of contiguous virtual pages) is allocated to a frame-group (a set of physical memory frames) by mapping virtual addresses to non-contiguous physical addresses via the page table. A page number (or group of pages) is allocated to a frame-group through a mapping managed by the OS, using a page table. The MMU translates the virtual address into a physical frame number, allowing pages to reside in any available frame. Therefore virtual memory addressing fundamentally requires knowledge of mapping.
But the spec does not provide any written description support for the recited mappings, ‘whether…..a page group allocated to a frame-group’, and ‘a page group number allocated to the frame-group’. The mapping is claimed as a function (what to map) without the corresponding structure/steps or method (how to map).
In short, the limitation recites a result without providing details or a working example with clear pictorial representations (like flowcharts or diagrams) of the mappings. Mapping between pages, frames, page-groups, frame-groups, page-group numbers and frame-group numbers are key to the disclosure but the spec and drawings lack relevant information and instead rely on high-level, conceptual definitions, without reciting how the mappings are determined and implemented for page migration. The spec contains no description of a mapping algorithm for the transformation. The lack of specific mapping details demonstrates that the applicant's possession of the claimed subject matter at the time of filing was incomplete. Hence claim 1 is rejected. Claims 13, 20 have the same issue.
5.Amended Claims 3,16 is rejected for reciting a limitation that is unsupported by the spec.
Amended claim 3 recites, ‘selecting a first frame-group number corresponding to a frame-group number of the free frame-group by accessing the inverted page group table in response to the free-frame group existing….’.
The spec does not provide written description support to show how ‘a frame-group number of the free frame-group’ is determined. Though claim 3 recites, ‘selecting….’, the spec does not recite a selection algorithm to select an available/free frame-group number of the free frame-group.
Spec, Para-0082 recites, ‘When the frame region of 2 MB having the free frame-group is found by searching the frame region available bitmap 116, all ‘free and not protected’ frame-group numbers in the frame region of 2 MB are stored in the destination candidate queue 112’.
The spec does not disclose how ‘all free and not protected’ frame-group numbers are determined from the ‘not-free ones’. The spec does not disclose ‘selecting’ a ‘free and not protected’ frame-group number and marking it as unavailable because it is selected as the first frame-group number. The spec also does not disclose why the ‘selecting….’ requires access to the inverted PG-table.
In essence, the spec does not disclose ‘selecting a first frame-group number….’. The spec fails to support the scope of the amendment, making the amendment overly broad and encompassing subject matter not described. This shows that the applicant's possession of the claimed subject matter at the time of filing was incomplete. Hence claim 3 is rejected. Claim 16 has the same issue.
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.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim(s) 1-20 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.
1.Amended Claims 1, 13, 20 are rejected for reciting limitations that are unclear, vague and indefinite.
Amended Claim 1 recites, ‘generating a frame-group number….’, ‘performing page migration based on the frame-group number using the inverted page group table’, ‘wherein the inverted….table indicates whether there is a page group allocated to a frame-group and ….table refers to a page group number allocated to the frame-group’.
Based on the last limitation, claim 1 does not recite storing the generated frame-group number in an entry/row of the inverted PG-table. Neither does claim 1 recite if the generated frame-group number is associated with a particular entry/row of the table.
In essence, claim 1 recites two unrelated entities, the inverted PG-table and the generated frame-group number. The lack of meaningful connection between them causes uncertainty in the scope of claim 1.
Furthermore, since claim 1 does not recite any structural and/or functional relationship between the inverted PG-table and the generated frame-group number, the limitation ‘performing page migration based on the frame-group number using the inverted page group table….’, is indefinite.
Hence claim 1 is rejected. Claims 13,20 have the same issue.
2.Amended Claims 1,13,20 are rejected for reciting a limitation that is unclear, vague and indefinite.
Amended Claim 1 recites, ‘generating a frame-group number…….based on an inverted page group table stored in the GPU memory’.
As mentioned above, the spec does not recite storing the frame-group number in the inverted PG-table, 210.
Spec, Fig. 3, step S200 recites ‘generating the frame-group number based on the inverted PG-table’. And Para-0075 refers to Fig. 4 to recite the ‘steps’ of generating the frame-group number.
But Fig. 4 recites ‘steps’ related to the destination candidate queue filling process and generating the (pseudo) frame-group number via a PRNG so that it can be stored in the destination queue. Fig. 4 is not related to storing the frame-group number in the inverted PG-table.
For example, spec, Para-0081 recites, ‘First, the available frame manager 114 searches the frame region available bitmap 116 to confirm whether the free frame-group exists. When the free frame-group does not exist, the available frame manager 114 accesses the pseudo-random number generator 118 to generate the random frame-group number, and stores the random frame-group number in the destination candidate queue 112’.
This recitation clearly shows that generating the frame-group number is dependent on the frame region available bitmap 116 and not the inverted PG-table 210.
Since the usefulness of the inverted PG-table is unclear, the limitation, ‘generating a frame-group number…….based on an inverted page group table’, is indefinite. As a result, claim 1 is rejected. Claims 13, 20 also have the same issue.
Note: Spec, Fig. 4, Para-0085 assumes that the frame-group number already exists. The spec does not explicitly recite the steps involved in generating the frame-group number based on the inverted PG-table, showing lack of possession, as mentioned earlier.
3.Amended Claims 1,13,20 is rejected for reciting a limitation that is unclear, vague and indefinite.
Claim 1 recites, ‘wherein the inverted page group table indicates whether there is a page group allocated to a frame-group and the inverted page group table refers to a page group number allocated to the frame-group’.
The goal of claim 1 is page migration which depends on the generated frame-group number and the physical address. But claim 1 recites other parameters such as: page group, frame group, and page group number.
Since the spec does not recite the details of how the frame-group number is generated, it is unknown how these parameters are used. Therefore the functional relationship of these parameters with the frame-group number is not established by the spec.
Since the spec fails to identify their significance in page migration, these parameters are extraneous and merely lengthen claim 1 without providing any technical distinction in a meaningful way.
The inverted PG table does not store the frame-group number. Though claim 1 recites, ‘….based on the inverted PG-table’ in every limitation, the spec does not disclose the relevance of the table. Therefore it is merely a table, without utility. The inclusion of the inverted PG-table table in claim 1 has no added value.
Being functionally irrelevant, the inverted PG-table, page group, frame group, and page group number, fail to define the true scope of the disclosure and make the metes and bounds unclear. Hence claim 1 is rejected. Claims 13,20 have the same issue.
4.Amended Claim 3 is rejected for reciting a limitation that is unclear, vague and indefinite.
Amended claim 3 recites, ‘selecting a first frame-group number corresponding to a frame-group number of the free frame-group by accessing the inverted page group table in response to the free-frame group existing….’
Since the frame-group number is not stored in the inverted PG-table (cannot be stored in destination queue), it is unclear why the inverted PG-table is accessed for the selection.
Though the spec recites a bitmap to determine if the free-frame group exists, the spec does not explicitly disclose how ‘a frame-group number of the free frame-group’ is determined and tracked, suggesting lack of possession.
Claim 3 submitted as part of the original disclosure recites, ‘selecting a first frame indentification corresponding to a frame indentification of the free frame’. But the claim took an undisclosed mapping leap from ‘frame’ to ‘frame-group’ and ‘frame number’ to ‘frame-group number’, without providing any written description of how ‘a frame’ maps to ‘a frame-group’ and ‘a frame number’ maps to ‘a frame-group number’, with regards to page migration. The spec does not recite any mapping information. This lack of mapping information shows lack of possession.
Furthermore, ‘selecting’ means searching and choosing a particular, unused value. But the spec does not disclose any selection algorithm.
Given the above issues, the limitation ‘selecting a first frame-group number corresponding to a frame-group number….by accessing the inverted page group table’, is indefinite.
4.Amended Claims 6-7 are rejected for reciting a limitation that is unclear, vague, inconsistent and indefinite.
Amended Claim 6 recites, ‘selecting a second frame-group number corresponding to a random pseudo-frame number by accessing the inverted page group table’. This recitation is inconsistent with the spec.
Spec, Para-0086 recites, ‘a step of receiving the random pseudo-frame-group number from the pseudo-random number generator 118 when the free frame-group does not exist (S212), a step of selecting the second frame-group number corresponding to the random pseudo-frame-group number by accessing the inverted page group table 210’.
It is undisclosed how the PRNG generates ‘a random pseudo-frame-group number’, when the free frame-group does not exist, suggesting lack of possession. The tracking algorithm is undisclosed.
Since the frame-group number is not stored in the inverted PG-table, it is unclear why the selection requires inverted PG-table table access.
Given the above issues, the limitation (after correction), ‘selecting the second frame-group number corresponding to the random pseudo-frame-group number by accessing the inverted page group table’, is indefinite, and claims 6-7 are rejected.
4.Amended Claims 14,16 are rejected for reciting a limitation that is unclear, vague and indefinite.
Claim 14 recites, ‘select a frame-group number required for migration from the inverted page group table and store the frame-group number’.
As mentioned above, Para-0053 of the spec recites that the inverted PG-table stores two flags (a free flag, a P-flag), a context ID CID, and a virtual page group number VPgN. The frame-group number is not stored in the inverted PG-table. Therefore how an un-stored frame-group number is selected from the inverted PG-table and stored (in dest queue), is indefinite.
The spec does not recite any search/selection algorithm to ‘select’.
Hence the recitation, ‘select a frame-group number required for migration from the inverted page group table….’, is indefinite and claim 14 is rejected. Claim 16 has a similar issue.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 5-6, 8-10, 12-14, 16-20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Cheng et al (20160378674) in view of Ganapathy et al (6182089), Schimmel et al (6112286) and Breslow (20200320016).
As per Claim 1, Cheng discloses a processor-implemented method for managing a virtual memory in a heterogeneous system (Cheng, [0006 - Fig. 1 shows a processor that employs the same virtual address space for heterogeneous processing units]; [0012 - Fig. 7 is a method of maintaining coherency between data copies for heterogeneous processing units]) that includes a CPU (Cheng, [Fig. 1: CPU 102]) and a GPU (Cheng, [Fig. 1: GPU 104]) in a computing environment and performs data migration (Cheng, [Fig. 4: migration control module 425]; [0027 - Migration can occur in either direction; See 112(a)]; [0027 - In response to the CPU 102 attempting to access a corresponding portion of the data 121, the memory controller 115 executes a reverse migration by copying the data 122/GPU memory to the data 121/CPU memory]) between a CPU memory (Cheng, [Fig. 1: Memory 105/system memory]; [0018]) and a GPU memory (Cheng, [Fig. 1: Memory 110]), the method comprising:
receiving a request for accessing a page in the heterogeneous system (Cheng, [Fig. 7: step 702, Receive memory access from CPU for page copies to GPU memory]; [0044 – In Fig. 7, step 702, memory controller 115 receives a memory access request from CPU 102]);
performing page migration (Cheng, [Fig. 7: step 708, Migrate page from GPU memory to CPU memory, as recited by the spec]; [See 112(a)]), without software intervention (Cheng, [0023 - The entity that controls the migration is a program executing at the CPU 102, a set of instructions executing at the GPU 104, or a DMA engine, suggesting hardware-based migration; Since the migration/data movement is invisible to the developer and application code, it suggests no software intervention]);
Ganapathy further clarifies the page migration in the heterogeneous system as follows,
receiving a request for accessing to a page in the heterogeneous system (Ganapathy, [Col. 11, lines 33-36 – In Fig. 8, step 804, the operating system/OS receives a memory allocation request from a process. The request includes a memory page size; Since the claim does not define ‘request’, the citation is a valid interpretation]);
determining a physical address corresponding to an address of the page (Ganapathy, [Col. 1, lines 34-42 – Once a memory page is allocated for a particular process, an entry is added to a page table. The page table entry maps a physical memory page to the virtual address space associated with the process. So, when the process needs to access the allocated memory page, the page table entry is consulted to find the corresponding physical address for the requested memory page]; [Col. 8, lines 43-45 - In Fig. 4, each TLB entry comprises a virtual address 408, a corresponding physical address 410, a valid bit 412, a page size 414 and a process TLB ID/PID 416, thereby implying determining a physical address corresponding to an address of the page in the device memory]);
generating a frame-group number (Ganapathy, [Col. 5, lines 48-55 – OSs generate data structures that represent physical memory pages. These data structures are called page frame data structures/PFDATs/frame-group number]; [Col. 6, lines 1-6 – In Fig. 1, main memory 108 is divided into page frames, or memory pages 110-124. Each memory page 110-124 is represented by a corresponding PFDAT 128-142. The OS uses each PFDAT 128-142 to store information related to the associated memory page 110-124 and to locate the physical pages 128-142 represented by each PFDAT 128-142]) of a migration destination (Ganapathy, [Col. 5, lines 12-13 - Fig. 16 implements memory migration]; [Col. 9, lines 22-24 – In a NUMA system, one bitmap is constructed for each node in the NUMA system, thereby implying that each node can be a migration destination]) of the GPU memory based on an inverted page group table stored in the GPU memory (Ganapathy, [Col. 6, lines 35-43 – In Fig. 2, PFDAT 128 comprises two reverse map fields 202 and 204. The reverse map field 202 points to the page table entry/PTE 206 in page table 210. Similarly, reverse map field 204 points to PTE 208 in page table 212. These reverse maps are used to update page tables, such as the page tables 210 and 212, when migrating memory pages that are currently mapped to one or more processes; [Col. 5, lines 66-67 - In Fig. 1, main memory 108 is divided into a number of page frames, or memory pages 110-124. Each memory page 110-124 is represented by a corresponding PFDAT 128-142, thereby implying that the inverted page group table is stored in device memory]),
in response to the determined physical address (Ganapathy, [Col. 6, lines 7-10 - The address of a page of memory that a PFDAT represents is stored implicitly by noting the relative position of the PFDAT in memory. From the relative position of the PFDAT, the physical page address can be computed]) indicating an address allocated to the CPU memory (Ganapathy, [Col. 3, lines 18-22 - In a multi-node NUMA system, a set of freelists are generated for each node. Each freelist comprises a linked list of data structures that represent and store data related to physical memory pages, thereby implying that the determined physical address indicates an address allocated to system/CPU memory]);
performing page migration (Ganapathy, [Fig. 16]) based on the frame-group number using the inverted page group table (Ganapathy, [Col. 4, lines 47-49 - Fig. 2 shows the relationship between PFDATs and page table entries/PTEs, via reverse map fields within the PFDAT]; [Col. 6, lines 31-33 - The reverse map fields point to particular PTEs associated with each process currently mapped to the PFDAT's associated memory, thereby implying that the table maps and stores the frame and the page of device memory, as required by Para-0017 of the spec]) and the physical address (Ganapathy, [Col. 17, lines 28-34 - Fig. 16 shows a method for migrating a list of pages for the Coalescing Daemon as needed in the mild and strong policies. First the Coalescing Daemon creates a list of PFDATs, that represents the base pages that need to be migrated in order to free up a chunk of memory. See line 1603]; [Col. 17, lines 55-62 - A new page frame number/PFN is retrieved so that the method can update the associated PTEs with the proper physical page address associated with the new PFDAT in lines 1616-1617. The new PFDAT is next inserted into a new PFDAT list. The new PFDAT list is a linked list comprising all of the new PFDATs that have been migrated from their original locations according to the current PFDAT list from line 1603]),
without software intervention (Ganapathy, [Col. 19, lines 35-38 - Fig. 17 is implemented primarily in hardware using hardware components such as application specific integrated circuits/ASICs, thereby implying that since the processing is done in hardware, functions like page migration are performed without software intervention; This is similar to Para-0028 of the spec]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the page-frame data structure of Ganapathy into the heterogeneous system of Cheng, for the benefit of each PFDAT containing one or more fields referred to as reverse maps. These reverse map fields are used to identify the process or processes that are currently mapped to the physical memory page associated with the PFDAT. The reverse map fields point to particular PTEs associated with each process currently mapped to the PFDAT's associated memory (Ganapathy, Col. 6, lines 26-33).
Schimmel clarifies the inverted page group table and migration to system memory as follows,
generating a frame-group number (Schimmel, [Col. 15, lines 53-55 - Fig. 10 is implemented by operating system 1510 and reverse mapping module 1512 shown in Fig. 15]; [Fig. 10: after step 1010, step 1012 – Is a data structure/PFDAT referencing a page frame? Yes, go to Fig. 11-A]; [Fig. 11-A: step 1110 – Generate a new reverse map entry]; [Col. 2, 65-67&Col. 3, lines 1-3 - A page frame data structure/PFDAT is a data structure that stores identification and state information for a page of memory. Each reserved field of the PFDAT can store a reverse map entry for pointing to a data structure reference, such as a page table entry/PTE, that references the page of memory]) of a migration destination of the GPU memory based on an inverted page group table (Schimmel, [Col. 3, lines 6-12 - Where a number n of references to the page of memory is greater than the number m of reserved fields, a reverse map table is generated for storing additional reverse map entries. When a reverse map table is generated, one of the reverse map entries in the page frame data structure is moved to the reverse map table. A pointer to the reverse map table is then placed in the now vacant reserved field]; [Col. 10, lines 51-57 - A reverse page table is employed where the number of page table entries equals the number of virtual pages that are stored in physical memory. Reverse page tables are implemented with a hash table; Since the claim does not define ‘inverted page table’, and how it is determined and represented, the citations are valid interpretation]) stored in the GPU memory (Schimmel, [Col. 15, lines 22-25 - Fig. 15 shows a reverse mapping module 1512 which is an integral part of OS 1510]; [Col. 9, lines 13-15 - PFDATs that are associated with memory objects are organized into a data structure, called a page cache]; [Claim 4 - wherein the first page of memory is located in a first processing node; The citations thereby imply that the reverse map table/inverted page table is stored in the device memory]),
performing page migration based on the frame-group number using the inverted page group table and the physical address (Schimmel, [Col. 9, lines 9-10 - From the PFDAT, the physical address of the page can be determined]; [Claim 4 - Using the first reverse map entry to identify the page table entry in a multi-processor system, wherein the first page of memory is located in a first processing node and data that is stored in the first page of memory is migrated to a second page of memory that is located in a second processing node/system memory; Since the claim does not recite the location of the system memory, the citation is a valid interpretation]),
wherein the inverted page group table (Schimmel, [Col. 18, lines 47-50 - In Fig. 7, page frame data structure 128 includes reverse map entry 510 that points to page table entry 318. Pointer 714 identifies reverse map table 718 that includes additional reverse map entries 614 and 716]) indicates whether there is a page group allocated to a frame-group (Schimmel, [Col. 9, lines 63-65 – In Fig. 3, a virtual memory mapping function 312 maps data associated with virtual memory addresses 310 to memory 108, which is divided into a number of page frames 110-124. A forward page table 316 provides virtual memory address-to-physical memory address translations]) and the inverted page group table refers to a page group number allocated to the frame-group (Schimmel, [Col. 10, lines 30-32 – In Fig. 3, page table 316 is as an array that is indexed by the virtual page number of the desired mapping. The virtual page number is the virtual address divided by the page size]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the reverse map table of Schimmel into the heterogeneous system of Cheng,Ganapathy, for the benefit of using it as an inverted page table where when a number n of references to the page of memory is greater than the number m of reserved fields, a reverse map table is generated for storing additional reverse map entries. When a reverse map table is generated, one of the reverse map entries in the page frame data structure is moved to the reverse map table. A pointer to the reverse map table is then placed in the now vacant reserved field (Schimmel, Col. 3, lines 6-12).
Breslow clarifies the page-group, frame-group, page-group number mapping as follows,
wherein the inverted page group table (Breslow, [Fig. 3: page table 311 + free lists 312]; [0033 – In Fig. 5A, the SELECT circuit 304 performs the SELECT function with bit vector 423 as the input bit vector v and the 5 bits of the virtual subpage number 405 as the input index, and outputs the index of the physical subpage 440 within the 4 MB physical memory region 430/frame-group/PFN]) indicates whether there is a page group allocated to a frame-group (Breslow, [0016 – In Fig. 1, the 16-page physical memory region 101/frame-group can be allocated to a maximum of two 8- page superpages 102 and 103/page-group]) and the inverted page group table refers to a page group number allocated to the frame-group (Breslow, [0035 - In Fig. 6A, an entry 620 in the TLB 303 associates a virtual page number 621 with a mapping, i.e., bit vector 622, and a physical region number 623/frame-group/PFN]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the memory mapping of Breslow into the heterogeneous system of Cheng,Ganapathy,Schimmel for the benefit of virtual memory addressing where for each virtual page number specified in a virtual address, a mapping indicating which subpages in the backing physical memory region are allocated for the virtual page number. The mapping is stored as a bit vector that has an asserted bit for each subpage in the physical memory page that is allocated for backing the virtual page number (Breslow, 0017).
As per Claim 3, the rejection of claim 1 is incorporated, and Cheng,Ganapathy,Schimmel,Breslow disclose,
wherein the storing of the frame-group number in the destination candidate queue (Ganapathy, [Fig. 16]) includes:
determining whether a free frame-group exists in a frame region (Ganapathy, [Col. 10, lines 13-15 - Suppose a process requests a 64 KB memory page. In this case, the operating system checks the 64 KB freelist 604 for a free memory page]),
selecting a first frame-group number corresponding to a frame-group number of the free frame-group by accessing the inverted page table in response to the free frame-group existing in the frame region (Ganapathy, [Col. 17, lines 47-54 – In Fig. 16, lines 1610-1611, the current PFDAT is removed from its memory object cache and the new PFDAT is inserted into the memory object cache. In line 1612 the reverse map field, see Fig. 2, 202, in the current PFDAT is used to identify entries in page tables that are using the PFDAT that is being migrated. Next, those PTEs are invalidated and the reverse maps fields are copied from the current PFDAT to the new PFDAT in lines 1614-1615, thereby implying selecting a first frame-group number corresponding to a frame-group number of the free frame by accessing the inverted page table when the free frame exists in the frame region]),
filling the destination candidate queue with the first frame-group number (Ganapathy, [Col. 17, lines 58-59 - The new PFDAT is then inserted/stored into a new PFDAT list/destination candidate queue]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the bitmap of Ganapathy into the heterogeneous system of Cheng,Schimmel,Breslow for the benefit of using the bitmap data structure for searching and documenting base sized memory pages that are free (Ganapathy, Col. 9, lines 9-12).
As per Claim 5, the rejection of claim 3 is incorporated, and Cheng,Ganapathy Schimmel,Breslow disclose,
wherein the filling of the destination candidate queue with the first frame-group number includes setting a flag of the destination candidate queue to 0 (Ganapathy, [Figs. 5,6,7]; [Col. 9, lines 25-34 - Each 16 KB portion of memory is represented by a single bit/flag in the bitmap. As shown in Fig. 5, free pages are represented by set bits and busy pages are represented by cleared bits; This implies that since the free frame existed, the bit will be set to ‘0’]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the bitmap of Ganapathy into the heterogeneous system of Cheng,Schimmel,Breslow for the benefit of using the bitmap data structure for searching and documenting base sized memory pages that are free (Ganapathy, Col. 9, lines 9-12).
As per Claim 6, the rejection of claim 3 is incorporated, and Cheng,Ganapathy,Schimmel,Breslow disclose,
wherein the storing of the frame-group number in the destination candidate queue (Ganapathy, [Figs. 8, 16]) includes:
selecting a second frame-group number corresponding to a random number (Ganapathy, [Col. 14, lines 19-22 - In Fig. 11, lines 1102-1108 define global variables used by the Coalescing Daemon. So the base page size, the largest page size 1102, the first PFN 1104 and the last PFN are defined]; [Col. 15, lines 1-4 - In Fig. 12, the coalesce_engine first sets a pointer, the ‘current chunk’ to the first page frame number/PFN, i.e. page 1 in Fig. 5, in line 1205. This is where the search though the bitmap 502a begins]; [Col. 15, lines 10-18 – In Fig. 12, the while loop beginning on line 1206 proceeds until the ‘current chunk’ is less than or equal to the last PFN, i.e. page N in Fig. 5. That is, until all of the bitmap 502a is searched. In addition, if all high watermarks are reached, the coalesce_engine breaks out of the while loop and returns to the main function, lines 1209-1210. In the while loop, coalesce_chunk is called. See Fig. 13. Upon return from coalesce_chunk, the current chunk pointer is incremented so that it points to the next chunk of the largest page size, thereby selecting a second frame identification corresponding to a random pseudo-frame number. Pseudo random numbers are used in watermark technology. Since the claim does not recite ‘random pseudo-frame number’ and how it is determined, the citation is a valid interpretation]) by accessing the inverted page group table (Ganapathy, [Col. 6, lines 26-33 - Each PFDAT contains one or more fields referred to as reverse maps. These reverse map fields are used to identify the processes that are currently mapped to the physical memory page associated with the PFDAT. The reverse map fields are used to point to particular page table entries/PTEs associated with each process currently mapped to the PFDAT's associated memory]) in response to the free frame not existing in the frame region (Ganapathy, [Fig. 8: After steps 804, 806, step 810 - Entry found ? No, step 822 – Wake Coalesce Daemon, as cited above]),
filling the destination candidate queue with the second frame-group number (Ganapathy, [Col. 11, lines 40-44 – In Fig. 8, step 810, if an entry exists control passes to step 812. In step 812, the OS returns the associated PFDAT to the process making the request; Here the presence of the loop/repeat in Fig. 8 implies determining and filling the destination queue with the second frame-group number]; [Col. 11, lines 63-64 – In Fig. 16, the next/second PFDAT in the current PFDAT list is set to current_pfdat variable, and lines 1608-1619 are repeated]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the bitmap of Ganapathy into the heterogeneous system of Cheng,Schimmel,Breslow for the benefit of using the bitmap data structure for searching and documenting base sized memory pages that are free (Ganapathy, Col. 9, lines 9-12).
As per Claim 8, the rejection of claim 6 is incorporated, and Cheng, Ganapathy,Schimmel,Breslow disclose,
wherein the filling of the destination candidate queue with the second frame-group number (Ganapathy, [Col. 11, lines 40-44 – In Fig. 8, step 810, if an entry exists control passes to step 812. In step 812, the OS returns the associated PFDAT to the process making the request; Here the presence of the loop/repeat in Fig. 8 implies determining and filling the destination queue with the second frame-group number]; [Col. 11, lines 63-64 – In Fig. 16, the next/second PFDAT in the current PFDAT list is set to current_pfdat variable, and lines 1608-1619 are repeated]) includes allocating a flag of the destination candidate queue to 1 (Ganapathy, [Col. 9, lines 25-34 - Each 16 KB portion of memory is represented by a single bit/flag in the bitmap. As shown in Fig. 5, free pages are represented by set bits and busy pages are represented by cleared bits; This implies that since the free frame did not exist, the page was busy and hence the flag is set to ‘1’]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the bitmap of Ganapathy into the heterogeneous system of Cheng,Schimmel,Breslow for the benefit of using the bitmap data structure for searching and documenting base sized memory pages that are free (Ganapathy, Col. 9, lines 9-12).
As per Claim 9, the rejection of claim 1 is incorporated, and Cheng, Ganapathy,Schimmel,Breslow disclose,
wherein the determining of the physical address in the device memory (Schimmel, [Col. 5, lines 1-4 - Fig. 2 shows a relationship between a page of memory that stores a portion of a memory object, an associated page frame data structure and a data structure that represents the memory object]) includes:
determining a page table entry (Schimmel, [Col. 10, lines 2-5 - Each page table 316 includes a set of page table entries/PTEs 318-326 for storing physical addresses and control information such as a valid bit, permission bits, etc.]) corresponding to the address of the page from a page table of the device memory (Schimmel, [Col. 10, lines 35-38 – In Fig. 3, the PTE for page 0×10 is found by looking at index 0×10 in the page table array. The starting address of the array is maintained by the OS in device memory]; [Col. 13, lines 1-3 – In Fig. 8, reverse map table 864 includes reverse map entry 862 that points to PTE 826, reverse map entry 874 that points to PTE 880 and reverse map entry 876 that points to PTE 834]; [Col. 14, lines 49-51 – In Fig. 9, when TLB ID 924 is found in page frame data structure/PFDAT 910, TLB ID 924 is used to identify TLB 932 as having a copy of PTE from page table 810]),
determining the physical address of the page using the determined page table entry (Schimmel, [Col. 10, lines 9-11 - In Fig. 3, PTEs 318-326 can be referenced by a physical address at which each PTE is stored]; [Col. 9, lines 58-60 - A physical address of a mapped page of data can be retrieved from a page table entry that is associated with an implied virtual address]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the reverse map table of Schimmel into the heterogeneous system of Cheng,Ganapathy,Breslow for the benefit of using it as an inverted page table where when a number n of references to the page of memory is greater than the number m of reserved fields, a reverse map table is generated for storing additional reverse map entries (Schimmel, Col. 3, lines 6-12).
As per Claim 10, the rejection of claim 9 is incorporated, and Cheng, Ganapathy,Schimmel,Breslow disclose,
updating the page table entry after the page migration is performed (Schimmel, [Col. 1, lines 30-36 - Activity that can affect a page of memory includes moving the data in the memory to another location, such as hardware-based page migration. If the data is moved from a first page of memory to a second page of memory, any references to the page, such as page table entries that referenced/mapped the first page of memory must be updated to reference the second page of memory]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the reverse virtual memory mapping scheme of Schimmel into the heterogeneous system of Cheng,Ganapathy,Breslow for the benefit of a virtual memory mapping scheme for identifying and updating page table entries when a page of mapped data is migrated from a first page of memory to a second page of memory (Schimmel, Col. 3, lines 28-32).
Cheng clarifies,
updating the page table entry after the page migration is performed (Cheng, [Fig. 7: step 710, Update GPU page tables]);
returning the updated page table entry to an entity transmitting the request for accessing to the page (Cheng, [0045 – In Fig. 7, after step 710, go to step 706, Execute memory access at CPU memory, thereby implying returning the updated PTE to the CPU]).
As per Claim 12, the rejection of claim 1 is incorporated, and Cheng, Ganapathy,Schimmel,Breslow disclose,
wherein the page migration is performed in units of a page or in units of a page group (Schimmel, [Col. 1, lines 30-36 - Activity that can affect a page of memory includes moving the data in the memory to another location, such as hardware-based page migration. If the data is moved from a first page of memory to a second page of memory, any references to the page, such as page table entries that referenced, or mapped, the first page of memory must be updated to reference the second page of memory]; [Col. 7, lines 60-63 - The PFDAT includes a logical offset which identifies a portion of the memory object, relative to the beginning of the memory object, thereby implying that the offset can be used to determine a page group]), and the heterogeneous system performs memory management in units of the page (Schimmel, [Fig. 3]) or in units of a frame or a frame group (Schimmel, [Figs. 3-7]; [Col. 6, lines 25-26 - A virtual memory mapping environment where page table entries reference pages of memory]; [Col. 9, lines 21-25 - A page cache is generated by organizing PFDATs that are associated with memory objects into a searchable data structure. PFDATs can be organized as linked lists, hash tables, tree structures, etc., thereby implying mapping and searching for pages, frames or a frame group]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the page cache of Schimmel into the heterogeneous system of Cheng,Ganapathy,Breslow for the benefit of efficient searching or translation of memory object identification and logical offsets into the corresponding PFDAT, PFDATs that are associated with memory objects are organized into a data structure, called a page cache (Schimmel, Col. 9, lines 11-15).
As per Claim 13, Cheng discloses an apparatus for managing a virtual memory management device in a heterogeneous system (Cheng, [0006 - Fig. 1 shows a processor that employs the same virtual address space for heterogeneous processing units]; [0012 - Fig. 7 is a method of maintaining coherency between data copies for heterogeneous processing units]) includes a CPU (Cheng, [Fig. 1: CPU 102]) and a GPU (Cheng, [Fig. 1: GPU 104]) in a computing environment and performs data migration (Cheng, [Fig. 4: migration control module 425]) between a CPU memory and a GPU memory (Cheng, [0027 - In response to the CPU 102 attempting to access a corresponding portion of the data 121, the memory controller 115 executes a reverse migration by copying the data 122/GPU memory to the data 121/CPU memory]), the apparatus comprising:
the CPU memory (Cheng, [Fig. 1: Memory 105/system memory]);
the GPU memory (Cheng, [Fig. 1: Memory 110]);
and a processor configured to execute the one or more instructions (Cheng, [0017 - The processor 100 is configured to execute instructions, organized in the form of one or more computer programs]) stored in the processor memory (Cheng, [0015 - The processor can employ memory modules of different types]), wherein the instructions, when executed by the processor, cause the processor to:
Ganapathy clarifies,
the CPU memory (Ganapathy, [Claim 10 - The computer system is a multi-node computer system comprising a plurality of nodes, thereby implying that a remote node can be used as system memory during migration; Since the claim does not recite the location of ‘system memory’, the citation is a valid interpretation]);
the GPU memory configured to store an inverted page table (Ganapathy, [Col. 18, lines 39-41 – In Fig. 17, computer system 1702 includes a main memory 1706/RAM, and secondary memory 1708]; [Col. 6, lines 35-43 – In Fig. 2, PFDAT 128 comprises two reverse map fields 202 and 204. The reverse map field 202 points to the page table entry/PTE 206 in page table 210. Similarly, reverse map field 204 points to PTE 208 in page table 212. These reverse maps are used to update page tables, such as the page tables 210 and 212, when migrating memory pages that are currently mapped to one or more processes]; [Col. 5, lines 66-67 - In Fig. 1, main memory 108 is divided into a number of page frames, or memory pages 110-124. Each memory page 110-124 is represented by a corresponding PFDAT 128-142, thereby implying that the inverted page table is stored in GPU memory; Since the claim does not recite how the table is populated, the citation is a valid interpretation]);
a processor memory configured to store one or more instructions (Ganapathy, [Col. 1, lines 46-47 - A cache system is a TLB]; [Col. 8, lines 29-30 - A TLB is found in a MIPS R10000 microprocessor]);
a processor configured to execute the one or more instructions stored in the processor memory (Ganapathy, [Col. 18, lines 30-31 - The computer system 1701 includes processor 1704]), wherein the instructions, when executed by the processor, cause the processor to:
The remaining limitations are similar to claim 1 and therefore the same rejections are incorporated.
As per Claim 14, it is similar to claim 6 and therefore the same rejections are incorporated.
As per Claim 16, it is similar to claim 3 and therefore the same rejections are incorporated.
As per Claim 17, the rejection of claim 16 is incorporated, and Cheng,Ganapathy,Schimmel,Breslow disclose,
determine a frame region in units of 2 MB (Ganapathy, [Figs. 6-7]; [Col. 12, lines 50-53 - Fig. 10 is an initialization routine, in an OS kernel, to construct a base page size freelist and set up the high water marks for memory pages of various sizes]; [Col. 1, lines 30-33 - In a system with 16KB memory pages, when an application requests 256 KB of memory, the OS reserves 16 pages of physical memory for the application program making the request, thereby implying that with 2MB memory pages, if application requests 4 MB of memory, the OS reserves 2 pages of physical memory]; [Col. 4, lines 24-32 - A splitting algorithm is used to allocate a memory page associated with a request for a page other than the largest page size. The splitting algorithm is used when there are no entries in the freelist associated with the requested page size, but there is at least one entry in a freelist of a larger page size. The splitting algorithm removes the entry from the freelist in the larger page size and creates multiple entries in the freelist of smaller page sizes]) in which the free frame-group (Ganapathy, [Fig. 5, bitmap 502a]) exists from an available bitmap in the frame region (Ganapathy, [Fig. 5]; [Col. 11, lines 38-46 - In Fig. 8, step 806, the OS searches the freelist, such as freelist 604, for an entry. In step 810, if an entry exists control passes to step 812. In step 812, the OS returns the associated PFDAT to the process making the request. Next, in step 814 the bitmap entry associated with the memory page is cleared]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the bitmap of Ganapathy into the heterogeneous system of Cheng,Schimmel,Breslow for the benefit of using the bitmap data structure for searching and documenting base sized memory pages that are free (Ganapathy, Col. 9, lines 9-12).
As per Claim 18, it is similar to claim 5 and therefore the same rejections are incorporated.
As per Claim 19, it is similar to claims 6 and therefore the same rejections are incorporated.
As per Claim 20, it is similar to claims 1, 13 and therefore the same rejections are incorporated.
Claims 7, 11 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Cheng et al (20160378674), in view of Ganapathy et al (6182089), Schimmel et al (6112286), Breslow (20200320016) and Jacob et al (‘Virtual Memory: Issues of Implementation’, IEEE, 1998, Pgs. 33-43).
As per Claim 7, the rejection of claim 6 is incorporated, and Cheng,Ganapathy,Schimmel,Breslow disclose generating and selecting the second frame-group number.
Jacob further discloses,
wherein the selecting of the second frame-group number (Jacob, [Pg. 38, Col. 1, Para-2 – Fig. 6 shows the inverted page table’s lookup algorithm, which either the OS or hardware can perform. In step 1, the faulting virtual page number is hashed, indexing the hash anchor table. The corresponding anchor-table entry is loaded and points to the chain head for that hash value. In step 2, the indicated PTE is loaded, and its virtual page number is compared with the faulting virtual page number. If the two match, the algorithm terminates. The mapping, composed of the virtual page number and the page frame number which is the PTE’s index in the inverted page table, is placed into the TLB in step 3a. Otherwise, the PTE references the next entry in the chain in step 3b, or indicates that it is the last in the chain. If there is a next entry, it is loaded and compared. If the last entry fails to match, the algorithm terminates and causes a page fault]) includes receiving the random pseudo-frame number from a random number generator (Jacob, [Pg. 37, Col. 2, Para-2 - The hash anchor table/HAT is indexed by the hash value and points to the chain head in the inverted table corresponding to each value; Since a hash function can be used to generate a pseudo-random number generator, the citation is a valid interpretation]) in response to the free frame-group not existing in the frame region (Jacob, [Pg. 37, Col. 1, Sec. Inverted page tables, Para–2 – As per Fig. 5, the inverted table also uses a hashed index based on the virtual page number. Since different virtual page numbers might produce identical hash values, a collision-chain mechanism is used to let these mappings exist in the table simultaneously, thereby implying that the free frame does not exist]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the hash anchor table of Jacob into the heterogeneous system of Cheng,Ganapathy,Schimmel,Breslow for the benefit of lookup efficiency as the hash anchor table is indexed by the hash value and points to the chain head in the inverted table corresponding to each value. Doubling the size of the hash anchor table reduces the average collision-chain length by half, without having to change the size of the inverted page table. Since the entries in the hash anchor table are smaller than the entries in the inverted table, it is more memory efficient to increase the size of the hash anchor table to reduce the average collision-chain length (Jacob, Pg. 37, Col. 2, Para-last).
As per Claim 11, the rejection of claim 1 is incorporated, and Cheng,Ganapathy,Schimmel,Breslow disclose an inverted page group table because the page-group is justified by extending the page number by using more bits for the index and reducing the number of bits used for the offset.
Jacob further clarifies,
wherein the inverted page group table (Jacob, [Pg. 40 - Fig. B : The PowerPC 604 uses a hardware-managed TLB and a variant on the
inverted page table, thereby implying an inverted page group table]) maps and stores a frame-group (Jacob, [Pg. 33, Col. 2, Para-4 - The physical memory is divided into uniform page frames/frame-group]) and the page group of the GPU memory (Jacob, [Pg. 40, Col. 1, Para-1 – Fig. B shows the PowerPC 604, which maps an application’s effective addresses onto a global flat virtual address space much larger than each per-application address space. Segments are 256-Mbyte contiguous regions of virtual space, and 16 segments make up an application’s 4-Gbyte address space. The top 4 bits of the 32-bit effective address select a segment identifier from a set of 16 hardware segment registers. The segment identifier is concatenated with the bottom 28 bits of the effective address to form an extended virtual address that indexes the caches and is mapped by the TLBs and page table; The page-group is justified by the need to cover a larger contiguous memory region with a single TLB entry to reduce TLB misses and improve performance; Since the spec does not describe how the page-group maps the frame-group, the citation is a valid interpretation]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the inverted page table variant of Jacob into the multi-node system of Cheng,Ganapathy,Schimmel,Breslow for the benefit of using the PowerPC 604 which uses a hardware-managed TLB and a variant on the inverted page table—an eight-way software cache for PTEs. The cache index is the same size as the page offset, effectively making the caches physically indexed (Jacob, Pg. 40, Fig. B).
Response to arguments
The indicated allowability of claim(s) 1,3,5-14,16-20 is withdrawn in view of the newly discovered reference(s) to Cheng et al (20160378674), Ganapathy et al (6182089), Schimmel et al (6112286) and Breslow (20200320016). Rejections based on the newly cited reference(s) are above.
The Applicant's arguments filed on January 22, 2026 have been fully considered, but moot in view of the new ground of rejection.
The applicant's attempt to resolve the 112(b)'s via amendments and arguments are inadequate.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARVIND TALUKDAR whose telephone number is (303)297-4475. The examiner can normally be reached M-F, 10 am-6pm EST.
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, Hosain Alam can be reached at 571-272-3978. 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.
Arvind Talukdar
Primary Examiner
Art Unit 2132
/ARVIND TALUKDAR/Primary Examiner, Art Unit 2132
Prosecution Insights