DETAILED ACTION
Claims 1-2 and 4-5 are amended. Claims 1-6 are pending.
Priority: 7/30/2020(FP)
Assignee: Information Science Lab
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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-6 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,4 are rejected for reciting a limitation that is unsupported by the spec.
Claim 1 recites, ‘wherein the transmission destination computer records the operation content by reading, in a packet reception interrupt routine, a pointer and a flag in a structure defined by the structure address, and storing the operation content in a buffer area defined by the pointer and the flag’.
The amendment recites reading a pointer and a flag in a structure defined by the ‘structure address’ sent by the source computer, which is used for temporarily ‘recording an operation content in a buffer area’.
But claim 1 in a prior limitation recites that the source computer sends a plain memory address across the network (structure address). The amendment asserts that the receiver's packet reception interrupt routine, introduced in Fig. 6, looks inside that specific network-provided address to find a ‘pointer and a flag’ to manage ‘a buffer’. But the spec provides no bridge between these concepts. The spec does not disclose that the network-transmitted structure address contains a pointer and a flag.
Claim 1 also previously recites that the ‘structure address’ defines ‘a history memory area’. But the amendment does not recite how ‘a history memory area’ is related to ‘a buffer area’.
There is no disclosure detailing how the packet reception interrupt routine uses the pointer and the flag, what states the flag represents, or how the pointer navigates the ‘buffer area’. While pointers and flags are common software concepts, their specific integration into this particular accumulation history structure is not inherent.
The amendment recites that the recording of the operation content occurs via the reading of a pointer and a flag from the structure address in 'a packet reception interrupt routine'. But the spec explicitly states the termination/end of this exact packet reception interrupt routine. In Para-0048, the spec states that after executing the user-authority store instruction, 'Then, the context of the memory space is returned to that at the time of occurrence of the interrupt. The processing in the interrupt routine is completed up to this point’.
After the termination of the packet reception interrupt routine, the spec, in Para-0049 states: 'Next, the operation of the command (MBCF_FIFO) for registering data to the FIFO queue in the parallel and distributed computing system 100 will be described'.
The spec explicitly states that the processing in the interrupt routine 'is completed up to this point' at the end of the direct store sequence, and only after that completion does it introduce and describe the MBCF_FIFO operation as in Fig. 7 (or other operations described in Figs. 8-10).
The spec fails to provide any disclosure showing how the subsequent recording steps, reading a structure address pointer and flag, and logging operation content to a buffer, can occur within the interrupt routine that has already been declared 'completed up to this point'.
Since the spec explicitly terminates the packet reception interrupt routine prior to executing the MBCF_FIFO pointer, flag, the inventor was not in possession of a universal method where operation content logging takes place inside that routine.
In other words, the spec provides no disclosure of a single, unified packet reception interrupt routine where the FIFO mechanism is executed simultaneously or inline with the direct memory store operation.
An inventor cannot be said to have been in possession of a method requiring a specific FIFO sub-routine to execute inside an interrupt, when the inventor’s own disclosure ends that interrupt prior to the sub-routine's execution.
Since claim 1 recites a requirement that the spec explicitly terminates before the FIFO logic is even introduced, the spec fails to demonstrate that the inventor possessed the broad amendment. In essence, the spec lacks written description support for the claimed step of logging operation content within the packet reception interrupt routine. Hence claim 1 is rejected. Claim 4 has the same issue and is also rejected.
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-6 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, 4 are rejected for reciting limitations that is unclear, inconsistent and indefinite.
Claim 1 recites, ‘source computer transmits….information including information of the transmission-side process, and a structure address that defines a history memory area’.
Since the spec does not recite transmitting by the source computer ‘information including information of the transmission-side process’, it is unclear what it represents.
Para-0007 of the spec recites, ‘a transmission source computer…. transmits an operation request packet including an identifier of an operation target process…., an operation target address that defines a memory area of the reception-side process, a data size to be written, a data sequence, and a structure address that defines a history memory area for temporarily recording an operation content history in the reception-side process’.
And the destination computer stores ‘….information of the transmission-side process in the history memory area as operation content’.
Furthermore, Para-0007 of the spec states, ‘destination computer (stores the data sequence in the memory area defined by the reception-side process and the operation target address, and records the operation target address, the data size written), and ((information of the transmission-side process in the history memory area as operation content))’.
Based on this recitation, the memory area defined by the operation target address (stores metadata like data sequence, data size, operation target address) and operation content is stored in the history memory area defined by the structure address. So the buffer area in the phrase ‘storing the operation content in a buffer area’ is unclear.
In addition, reciting ‘recording operation content (???) including the operation target address’ is incorrect because operation content in not stored in the memory area defined by the operation target address. Hence claim 1 is rejected. Claim 4 has the same issue and is also rejected.
2.Amended Claims 2, 5 are rejected for reciting a limitation that is unclear, ambiguous and indefinite.
Dependent Claim 2 recites, ‘wherein….the reception-side process exists activates an asynchronous user function to the reception-side process at a time point when the operation content is accumulated in the history memory area’.
Claim 2 recites that an asynchronous user function is activated 'at a time point when the operation content is accumulated in the history memory area'. When read in light of the spec, this limitation is ambiguous because the boundaries of 'time point' cannot be determined.
According to independent Claim 1, the history accumulation must take place within the packet reception interrupt routine. However, the spec explicitly states that the interrupt routine is 'completed up to this point' prior to the description of the FIFO history accumulation mechanism.
Since the spec states that the interrupt routine terminates before history accumulation occurs, but the claim requires that history accumulation occurs before the interrupt routine terminates, when this 'time point' takes place cannot be determined. Consequently, the scope of claim 2 is indefinite. Claim 5 has a similar issue. Hence claims 2 and 5 are rejected.
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 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Matsumoto (‘A Study on Memory-Based Communications and Synchronization in Distributed-Memory Systems’, Tech Report-Japan, 2001, Pgs. 1-120) in view of Matsumoto et al (‘MBCF: A Protected and Virtualized High-Speed User-Level Memory-Based Communication Facility’, ACM, 1998, Pgs. 259-266, hereinafter Matsumoto-2).
As per Claim 1, Matsumoto discloses a parallel and distributed computing system in which a plurality of computers (Matsumoto, [Figure 2.1: System architecture using Memory-Based Processors/MBPs comprising node 0 ….node N-1]; [Pgs. 72-73, Sec. 6.2, Evaluation using SPARCstation 20s and SSS–CORE Ver.1.x – Operating system of the NOW/Node of the network of workstations, SSS–CORE Ver.1.0 – Parallel and Distributed processing]) including a processor including a translation lookaside buffer (TLB) (Matsumoto, [Pg. 27, Fig. 3.1: Processor, P-TLB]; [Pg. 58, Fig. 5.1(b): An entry of TLB]; [Figure 2.3: TLBs in one node of the MBP system]), a physical memory (Matsumoto, [Pg. 14, Fig. 2.4: Left Node, Physical Address Space 1]; [Pg. 27, Fig. 3.1: Pnode1 Physical Memory]), and a network interface controller (NIC) (Matsumoto, [Pgs. 27-28, Figs. 3.1, 3.2 - Each show a sender node NIC and a receiver node NIC]) directly accessible to the physical memory are interconnected via a data link (Matsumoto, [Pg. 26, Sec. 3.4.1 - The processor on a sender node creates a packet image, which includes its header-routing information, in the NIC-DMA area, which NIC can directly access for sending and/or receiving. The processor then kicks its NIC to start sending the data, using DMA to retrieve it from memory]; [Pg. 72, Para-3 – The OS can simultaneously handle MBCF/Ether, TCP/IP, UDP/IP, ICMP and so forth over an Ethernet link/data link]; [Pg. 74, Para-4 - The 100BASE-TX interface card is used as the NIC for MBCF/Ether communications]), and each of the plurality of computers performs remote memory operations on the others (Matsumoto, [Pg. 13 - Fig. 2.3]; [Pg. 15, Sec. 2.5, Para-4 – Fig. 2.5 shows a network with 16 nodes/computers]; [Pg. 24, Sec. 3.3.1 - In the MBCF system remote memory access is invoked by an explicit system-call for an MBCF function]; [Pg. 65, Para-2 - A node of the MBCF only needs a buffer area which is proportional to the number of target nodes]; [Pg. 96, Para-4 - MBCF provides light-weight methods for direct access to remote memory in user-task spaces]) wherein,
a process (Matsumoto, [Pg. 28, Fig. 3.2: The left task, Pnode1:Ptask3, is the requestor/source of the write operation]) of a transmission source computer (transmission-side process) (Matsumoto, [Pg. 28, Fig. 3.2: Pnode1]) transmits an operation request packet (Matsumoto, [Pg. 29 - Figure 3.3: MBCF WRITE operation – Steps 0,1,2,3,4]; [Pg. 41, Fig. 4.1 – MBCF_FIFO a command for storing data in fifos, Original Request, MBCF_FIFO from Laddr0]) including an identifier of an operation target process (reception-side process) that defines a process of a transmission destination computer (Matsumoto, [Pg. 28 – Fig. 3.2: target task-ID/Ltask1]; [Fig. 6.1: Destination Task ID]; [Pg. 41, Fig. 4.1: Pnode2, Ptask5]), an operation target address that defines a memory area of the reception-side process (Matsumoto, [Pg. 28 – Fig. 3.2: (Pnode2,Ptask5) Logical address space]; [Pg. 51, Fig. 4.8 – Signal Structure at Laddr1; Here Fig. 4.8 is same as Fig. 10 of the spec]), a data size to be written (Matsumoto, [Pg. 28 - The amount of data to be written]; [Pg. 69 - Fig. 6.1: MBCF Data Length at address:48]; [Pg. 68, Para-3 - Data to be stored from address:52 to address:51+N. Here, N is the length of the data]), a data sequence (Matsumoto, [Pg. 71, Para-2 - Every node maintains sequence numbers of two kinds for each remote node: one is the number of packets sent and the other is the number of packets that arrive. Whenever a packet is transmitted to a node, the packets-sent number for that node is incremented. The number sent is attached to the ‘END P’ field/address:21 of the requesting packet. See Fig. 6.1; Since the claim does not define ‘a data sequence’, the citation is a valid interpretation]), information including information of the transmission-side process (Matsumoto, [Fig. 6.1: Source Task ID]), and a structure address that defines a history memory area (Matsumoto, [at least Figs. 4.1-4.3 – FIFO queue of the MBCF; This is similar to Para-0056 of the spec]; [Pg. 41, Fig. 4.1: Memory area pointed by fifo head pointer and fifo tail pointer; Here pointer stores an address]) distinct from the memory area defined by the operation target address (Matsumoto, [Pg. 28 – Fig. 3.2: (Pnode2,Ptask5) Logical address space]; [Pg. 51, Fig. 4.8 – Signal Structure at Laddr1; Here Fig. 4.8 is same as Fig. 10 of the spec]) for temporarily recording operation content history in the reception-side process (Matsumoto, [Pgs. 41-42 - The MBCF FIFO command packet specifies a location/address of the structures, which define fifos. Figure 4.1 shows a fifo structure and buffer in a target node/Pnode2; This shows that with the help of the fifo pointers, a memory area can define the history memory area for temporarily recording an operation content history in the reception-side process of Pnode2]),
the transmission-side process specifies the history memory area in the reception-side process (Matsumoto, [at least Figs. 4.1-4.3, 4.7,4.8 - FIFO queue of the MBCF; Note: Para-0056,Fig. 7 of spec also recites that the FIFO queue of the MBCF is used as the history memory area]),
the transmission destination computer (Matsumoto, [Pg. 30, Fig. 3.4: Pnode2]) receives the operation request packet (Matsumoto, [Pg. 41, Fig. 4.1 shows a received packet in a target node]; [Pg. 26 - The receiving node has a ring buffer for incoming packets in its NIC-DMA area]), stores the data sequence in the memory area defined by the reception-side process and the operation target address (Matsumoto, [Pg. 28 – Fig. 3.2: (Pnode2,Ptask5) Logical address space]; [Pg. 51, Fig. 4.8 – Signal Structure at Laddr1; Here Fig. 4.8 is same as Fig. 10 of the spec]), extracts from the operation request packet ([See 112(a), 112(b)]) the information including the identifier (Matsumoto, [Fig. 6.1: Source Task ID]) of the transmission-side process (Matsumoto, [Pg. 31 – Fig. 3.5, the interrupt causes the MBCF-dedicated interrupt routine in the target node to take control of the processor. The routine then begins to process the MBCF command, thereby implying extracting the parameters from the command]),
and based on the operation request packet (Matsumoto, [Pg. 41, Fig. 4.1 shows a received packet in a target node]), performs (i) storing of the data sequence (Matsumoto, [Pg. 71, Para-2 – In Fig. 6.1, the number of packets sent is attached to the ‘END P’ field, address:21 of the requesting packet. Whenever a packet is received from a node, the packets-arrived number for that node is checked against the sent number in the packet]) in the memory area defined by the operation target address (Matsumoto, [Fig. 4.2]; [Pg. 42, Para-1 - Writes/stores the data to the target address Laddr1]; [Pg. 51 – Fig. 4.8, Signal Structure at Laddr1]), and (ii) recording operation content (Matsumoto, [Pg. 47 - Fig. 4.7: FIFO structure which uses the buffer area for the FIFO; Para-0056 of the spec also recites the same]; [Pg. 51 - Fig. 4.8]) including the operation target address (Matsumoto, [Pg. 42 - target address Laddr1]; [Pg. 47 – Fig. 4.7]; [Pg. 51 - Fig. 4.8, Signal structure at Laddr1]), the data size stored to the memory area (Matsumoto, [Fig. 4.8: Packet Header, n bytes]; [Pg. 22, Para-1 - The size of data which the MBCF system handles at a time is equal to the size of data-packet which the NIC transfers]), and the information including the information of the transmission-side process (Matsumoto, [Pg. 67 - Fig. 6.1, Source Task ID]) in the history memory area (Matsumoto, [at least Figs. 4.1-4.3 – FIFO queue of the MBCF; This is similar to Para-0056 of the spec]; [Pg. 42 - Fig. 4.1 shows a fifo structure and buffer in a target node. Each fifo structure includes four pointers, to the top, head, tail, and end of the data buffer, and status flags]; [Pg. 41 – Fig. 4.1: Operation of the MBCF FIFO(1) command]; [Fig. 4.2: Operation of the MBCF FIFO(2) command]) defined by the structure address (Matsumoto, [Figs. 4.7,4.8 – FIFO structure ptr, FIFO structure]),
wherein the transmission destination computer records the operation content by reading, in a packet reception interrupt routine (Matsumoto, [Pg. 31 – When the packet arrives, the target/destination node’s NIC uses DMA to copy the packet to the ring buffer and generates an interrupt signal to inform the node’s processor of the arrival of the MBCF packet. The interrupt causes the MBCF-dedicated interrupt routine to take control of the processor. The routine then begins to process the MBCF command. First it performs the lowest-level protocol required by the NIC, then it uses the physical task-ID/Ptask5 to find the target task, validates access-key, then changes the context/address space to the target task, writes the data to the target address/Laddr1 under user-level privilege. The interrupt routine then ends]), a pointer and a flag ([See 112(a)]) in a structure defined by the structure address (Matsumoto, [at least Figs. 4.1, 4.2, Pgs. 41-42]; [Fig. 4.1,4.2 show FIFO top ptr pointing to ‘buffer area for a FIFO’, thereby implying that ‘FIFO top ptr’ is the pointer]; [Pg. 42, Para-2 - The status-report option should be used to inform the requesting task/node/sender of this cancellation of the command, thereby implying ‘a flag’ to report the status]), and storing the operation content in a buffer area defined by the pointer and the flag (Matsumoto, [Pg. 42, Para-1 - Each fifo structure has four pointers, to the top, head, tail, and end of the data buffer, and status flags. In the MBCF-interrupt routine, the processor reads the pointers and flags of the target fifo structure first, stores data in the buffer specified by the structure, then updates the structure]).
Matsumoto-2 clarifies the packet reception interrupt routine as follows,
wherein the transmission destination computer records the operation content by reading, in a packet reception interrupt routine (Matsumoto-2, [Pg. 260, Col. 1, Para-1 - the MBCF-dedicated interrupt routine at the target node receives the packet and directly executes the remote access specified in the packet and returns a reply if necessary]), a pointer and a flag in a structure defined by the structure address (Matsumoto-2, [Pg. 260, Col. 2, Sec. 3, Para-2 - In MBCF a requester/sender specifies the logical address of the target location to which some specified operation is applied]), and storing the operation content in a buffer area defined by the pointer and the flag (Matsumoto-2, [Pg. 262, Col. 1 , Sec. 4.1.5 - MBCF-FIFO is a command for storing data in fifos. MBCF-FIFO command packets do not directly specify the location for storing data but include the target location of the structures which define the fifos. In each fifo structure, pointers of data buffers and status flags are stored and maintained. The MBCF interrupt routine reads the pointers and the flags first, and stores data in the buffer corresponding to the specified fifo structure/pointer, and updates the structure]; [Pg. 262, Col. 2, Para-1 - status report option is a flag]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the interrupt routine of Matsumoto-2 into the MBCF/Memory-Based Communication Facility of Matsumoto for the benefit of a user-program prepare an MBCF packet in user-mode and execute the MBCF requesting system-call. Secondly the kernel-level routine of the MBCF-dedicated requesting system-call makes an inter-node communication style packet and transmits it using conventional NICs. Finally the MBCF-dedicated interrupt routine at the target node receives the packet and directly executes the remote access specified in the packet and returns a reply if necessary (Matsumoto-2, Pg. 259, Col. 2, Sec. 2.1).
As per Claim 2, the rejection of claim 1 is incorporated, and Matsumoto discloses,
wherein the transmission destination computer in which the reception-side process exists (Matsumoto, [Pg. 47, Fig. 4.7: Pnode2, Ptask5]) activates, for the reception side process (Matsumoto, (Matsumoto, [Pg. 28 – Fig. 3.2: Laddr1, target address]; [Pg. 69 - Fig. 6.1: Destination Logical Address]; [Pg. 47 – The MBCF_SIGNAL command is thrown to a memory-based signal structure in the target task. See Fig. 4.7]), an asynchronous user function (Matsumoto, [Pgs. 46-47 – MBCF_SIGNAL command is accompanied by a remote invocation of the user-specified program with the privileges of the target task. The invoked program is executed only in the scheduling periods of the target task]; [Pg. 58 - The memory-based signal provides users of the MBCF with a method of asynchronous communication]) at a time point when the operation content history is accumulated in the history memory area (Matsumoto, [at least Figs. 4.1-4.3 – FIFO queue of the MBCF]; [Pg. 45 - Users detect transitions to the cancellation state by use of the status reports]; [Pg. 42 - If the buffer of the specified structure is full, processing of the data in the MBCF_FIFO packet is cancelled. The status-report option should be used to inform the requesting node task of the cancellation of the command, thereby disclosing that the asynchronous user function to the reception-side process is invoked at a time when the operation content history is accumulated/full in the history memory area]).
As per Claim 3, the rejection of claim 1 is incorporated, and Matsumoto discloses,
wherein the transmission destination computer saves (Matsumoto, [Figs. 4.1-4.2 – Pnode2]), in the history memory area (Matsumoto, [at least Figs. 4.1-4.3 – FIFO queue of the MBCF]; [Pg. 42, Fig. 4.1 shows a fifo structure and buffer in a target node. Each fifo structure includes four pointers, to the top, head, tail, and end of the data buffer, and status flags. In the MBCF-interrupt routine, the processor reads the pointers and flags of the target fifo structure first, stores data in the buffer specified by the structure, then updates the structure]), data before being overwritten in the memory area of the reception-side process (Matsumoto, [Pg. 42, Fig. 4.2: Operation of MBCF_FIFO cmd – ‘Unread Data’ + ‘New Data’ = Updated History memory area; Here ‘New Data’ pointed by New head pointer is saved in the history memory area before it is overwritten in the memory area of the reception side process; Since the claim does not recite how ‘overwritten’ is done, it is valid to interpret that the New head pointer pointing to future data is equivalent to ‘overwritten’]).
Claims 4-6 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Matsumoto (‘A Study on Memory-Based Communications and Synchronization in Distributed-Memory Systems’, Tech Report-Japan, 2001, Pgs. 1-120) in view of Matsumoto et al (‘MBCF: A Protected and Virtualized High-Speed User-Level Memory-Based Communication Facility’, ACM, 1998, Pgs. 259-266, hereinafter Matsumoto-2) and Liu et al (20210334105).
As per Claim 4, the rejection of claim 1 is incorporated and Matsumoto discloses,
wherein the transmission-side process (Matsumoto, [Pg. 28, Fig. 3.2: The left task, Pnode1:Ptask3, is the requestor/source of the write operation]) transmits an operation request packet (Matsumoto, [Pg. 29 - Figure 3.3: MBCF WRITE operation – Steps 0,1,2,3,4]; [Pg. 41, Fig. 4.1 – MBCF_FIFO command for storing data in fifos, Original Request, MBCF_FIFO from Laddr0]) including an identifier of an operation target process (Matsumoto, [Pg. 28 – Fig. 3.2: target task-ID/Ltask1]; [Fig. 6.1: Destination Task ID]) (reception-side process) that defines a process of a transmission destination computer (Matsumoto, [Pg. 28, Fig. 3.2 – Pnode2]; [Pg. 41, Fig. 4.1: Pnode2, Ptask5]), an operation target address that defines a table area on a memory of the reception-side process (Matsumoto, [Pg. 28 – Fig. 3.2: Laddr1, target address]; [Pg. 69, Fig. 6.1: Destination Logical Address]; [Pg. 41, Fig. 4.1 – MBCF_FIFO from Laddr0 to (Ltask1, Laddr1) n bytes; Here the fifo pointers can be used to represent a table area, such as fifo tail pointer. See Fig. 4.2]), information of a row and a column in a table (Matsumoto, [Pg. 42, Fig. 4.2: New Head Ptr/address]), a data size to be stored (Matsumoto, [Pg. 28 - The amount of data to be written]; [Pg. 69 - Fig. 6.1: MBCF Data Length at address:48]; [Pg. 68, Para-3 - Data to be stored from address:52 to address:51+N. Here, N is the length of the data]), a data sequence (Matsumoto, [Pg. 71, Para-2 - Every node maintains sequence numbers of two kinds for each remote node: one is the number of packets sent and the other is the number of packets that arrive. The number sent is attached to the ‘END P’ field/address:21 of the requesting packet. See Fig. 6.1; Since the claim does not define ‘a data sequence’, the citation is a valid interpretation]), information including information of the transmission-side process (Matsumoto, [Fig. 6.1: Source Task ID]), and a structure address that defines a history memory area (Matsumoto, [at least Figs. 4.1-4.3 – FIFO queue of the MBCF]; [Pg. 41, Fig. 4.1: Memory area pointed by fifo head pointer and fifo tail pointer; Here pointer shows an address]) distinct from the memory area defined by the operation target address (Matsumoto, [Pg. 28 – Fig. 3.2: (Pnode2,Ptask5) Logical address space]; [Pg. 51, Fig. 4.8 – Signal Structure at Laddr1; Here Fig. 4.8 is same as Fig. 10 of the spec]) for temporarily storing an operation content history in the reception-side process (Matsumoto, [Pgs. 41-42 - The MBCF FIFO command packet specifies a location/address of the structures, which define fifos. Figure 4.1 shows a fifo structure and buffer in a target node, thereby implying that with the help of the fifo pointers a history memory area can be defined in the reception side process of Pnode2]),
and the transmission destination computer (Matsumoto, [Pg. 41, Fig. 4.1: Pnode2]) receives the operation request packet (Matsumoto, [Pg. 41, Fig. 4.1 shows a received packet in a target node]; [Pg. 26 - The receiving node has a ring buffer for incoming packets in its NIC-DMA area]), reads data from an area defining the table area (Matsumoto, [Pg. 69, Fig. 6.1: Destination Logical Address]) defined by the reception-side process and the operation target address (Matsumoto, [Pg. 28, Fig. 3.2 – Pnode2]; [Pg. 41, Fig. 4.1: Pnode2, Ptask5]; [Pg. 41, Fig. 4.1 – MBCF_FIFO from Laddr0 to (Ltask1, Laddr1) n bytes; Here the fifo pointers can be read to determine the defined table area]; [Pg. 51 – Fig. 4.8, Signal Structure at Laddr1]), obtains a memory address corresponding to the row and the column defined in the operation request packet (Matsumoto, [Pg. 68, Para-3 - Data to be stored from address:52 to address:51+N. Here, N is the length of the data]),
and based on the operation request packet (Matsumoto, [Pg. 41, Fig. 4.1 shows a received packet in a target node]), performs (i) storing the data sequence (Matsumoto, [Pg. 71, Para-2 – In Fig. 6.1, the number of packets sent is attached to the ‘END P’ field, address:21 of the requesting packet. Whenever a packet is received from a node, the packets-arrived number for that node is checked against the sent number in the packet]) in the memory area defined by the operation target address (Matsumoto, [Fig. 4.2]; [Pg. 42, Para-1 - Writes/stores the data to the target address Laddr1]; [Pg. 51 – Fig. 4.8, Signal Structure at Laddr1]), and (ii) recording operation content (Matsumoto, [Pg. 47 - Fig. 4.7: FIFO structure which uses the buffer area for the FIFO; Para-0056 of the spec also recites the same]; [Pg. 51 - Fig. 4.8]) including the operation target address (Matsumoto, [Pg. 42 - target address Laddr1]; [Pg. 47 – Fig. 4.7]; [Pg. 51 - Fig. 4.8, Signal structure at Laddr1]), the information of the row and the column (Matsumoto, [Pg. 42, Fig. 4.2: New Head Ptr pointing to New Data]), the data size stored (Matsumoto, [Fig. 4.8: Packet Header, n bytes]; [Pg. 22, Para-1 - The size of data which the MBCF system handles at a time is equal to the size of data-packet which the NIC transfers]), and the information including the information of the transmission-side process (Matsumoto, [Pg. 67 - Fig. 6.1, Source Task ID]) in the history memory area (Matsumoto, [at least Figs. 4.1-4.3 – FIFO queue of the MBCF; This is similar to Para-0056 of the spec]; [Pg. 42 - Fig. 4.1 shows a fifo structure and buffer in a target node. Each fifo structure includes four pointers, to the top, head, tail, and end of the data buffer, and status flags. In the MBCF-interrupt routine, the processor reads the pointers and flags of the target fifo structure first, stores data in the buffer specified by the structure, then updates the structure]; [Pg. 41 – Fig. 4.1: Operation of the MBCF FIFO(1) command]; [Fig. 4.2: Operation of the MBCF FIFO(2) command]) defined by the structure address (Matsumoto, [Figs. 4.7,4.8 – FIFO structure ptr, FIFO structure]),
wherein the transmission destination computer records the operation content by reading, in a packet reception interrupt routine (Matsumoto, [Pg. 31 – When the packet arrives, the target/destination node’s NIC uses DMA to copy the packet to the ring buffer and generates an interrupt signal to inform the node’s processor of the arrival of the MBCF packet. The interrupt causes the MBCF-dedicated interrupt routine to take control of the processor. The routine then begins to process the MBCF command. First it performs the lowest-level protocol required by the NIC, then it uses the physical task-ID/Ptask5 to find the target task, validates access-key, then changes the context/address space to the target task, writes the data to the target address/Laddr1 under user-level privilege. The interrupt routine then ends]), a pointer and a flag ([See 112(a)]) in a structure defined by the structure address (Matsumoto, [at least Figs. 4.1, 4.2, Pgs. 41-42]; [Fig. 4.1,4.2 show FIFO top ptr pointing to ‘buffer area for a FIFO’, thereby implying that ‘FIFO top ptr’ is the pointer]; [Pg. 42, Para-2 - The status-report option should be used to inform the requesting task/node/sender of this cancellation of the command, thereby implying ‘a flag’ to report the status]), and storing the operation content in a buffer area defined by the pointer and the flag (Matsumoto, [Pg. 42, Para-1 - Each fifo structure has four pointers, to the top, head, tail, and end of the data buffer, and status flags. In the MBCF-interrupt routine, the processor reads the pointers and flags of the target fifo structure first, stores data in the buffer specified by the structure, then updates the structure]).
Matsumoto-2 clarifies the packet reception interrupt routine as follows,
wherein the transmission destination computer records the operation content by reading, in a packet reception interrupt routine (Matsumoto-2, [Pg. 260, Col. 1, Para-1 - the MBCF-dedicated interrupt routine at the target node receives the packet and directly executes the remote access specified in the packet and returns a reply if necessary]), a pointer and a flag in a structure defined by the structure address (Matsumoto-2, [Pg. 260, Col. 2, Sec. 3, Para-2 - In MBCF a requester/sender specifies the logical address of the target location to which some specified operation is applied]), and storing the operation content in a buffer area defined by the pointer and the flag (Matsumoto-2, [Pg. 262, Col. 1 , Sec. 4.1.5 - MBCF-FIFO is a command for storing data in fifos. MBCF-FIFO command packets do not directly specify the location for storing data but include the target location of the structures which define the fifos. In each fifo structure, pointers of data buffers and status flags are stored and maintained. The MBCF interrupt routine reads the pointers and the flags first, and stores data in the buffer corresponding to the specified fifo structure/pointer, and updates the structure]; [Pg. 262, Col. 2, Para-1 - status report option is a flag]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the interrupt routine of Matsumoto-2 into the MBCF/Memory-Based Communication Facility of Matsumoto for the benefit of a user-program prepare an MBCF packet in user-mode and execute the MBCF requesting system-call. Secondly the kernel-level routine of the MBCF-dedicated requesting system-call makes an inter-node communication style packet and transmits it using conventional NICs. Finally the MBCF-dedicated interrupt routine at the target node receives the packet and directly executes the remote access specified in the packet and returns a reply if necessary (Matsumoto-2, Pg. 259, Col. 2, Sec. 2.1).
The claim does not define a table area on the memory of the reception side process and how it is represented and accessed. Matsumoto discloses using the MBCF_WRITE and MBCF_FIFO command to implement the table area on the memory of the reception side process.
Liu further clarifies the table area on the memory of the reception side process as follows,
wherein the transmission-side process transmits an operation request packet (Liu, [0043 – In Fig. 1, step S11, generating a descriptor synchronization instruction according to a descriptor of tensor data/table area to be synchronized, where the descriptor synchronization instruction includes an identifier of the descriptor; Here the descriptor synchronization instruction is equivalent to an operation request packet]) including an identifier of an operation target process (hereinafter, a reception-side process) that defines a process of a transmission destination computer (Liu, [0044 – In Fig. 1, step S12, sending the descriptor synchronization instruction to a second processor/destination computer]; [0048 - The descriptor include an identifier and content]; [0053 - If a descriptor indicating the tensor data to be synchronized has been registered in the second processor, then the descriptor synchronization instruction instructs the second processor to synchronize the tensor data according to the identifier of the descriptor; Here the identifier is equivalent to the operation target process]), an operation target address that defines a table area on a memory of the reception-side process (Liu, [0048 – The content of the descriptor includes an address parameter, such as a base address of a datum point, representing an address of the tensor data]), information of a row and a column in a table (Liu, [0048 - The content of the descriptor include a shape parameter, such as a size of each dimension of the tensor, etc., representing the shape of the tensor data]; [0045-0046 - The shape of the 2-dimensional tensor is described by two parameters: the first parameter 2 corresponds to the size of a first dimension/column, and the second parameter 4 corresponds to the size of a second dimension/row]),
and the transmission destination computer receives the operation request packet (Liu, [0093 – In Fig. 2, step S21, parsing a descriptor synchronization instruction received from a first processor]), reads data from an area defining the table area defined by the reception-side process and the operation target address (Liu, [0102 – In Fig. 2, step S22 includes obtaining/reading the tensor data/table area to be synchronized from a shared storage space according to the content of the descriptor of the tensor data to be synchronized]), obtains a memory address corresponding to the row and the column defined in the operation request packet (Liu, [0108 - After receiving the descriptor synchronization instruction, the second processor parses the instruction to obtain the storage address of the content of the descriptor. According to the storage address, the second processor obtains the content of the descriptor of the tensor data to be synchronized from the storage space of synchronized data, and then determines the data address/row-column of the tensor data to be synchronized according to the content of the descriptor, and obtain the tensor data to be synchronized]; [0048 - By using the descriptor to indicate the shape/row-column of tensor data, related information such as the relationship among a plurality of pieces of tensor data can be determined]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the tensor data of Liu into the MBCF/Memory-Based Communication Facility of Matsumoto, Matsumoto-2 for the benefit of improving the efficiency of data synchronization wherein when data needs to be synchronized, by setting a descriptor indicating the shape of tensor data, a descriptor synchronization instruction is obtained according to a descriptor of tensor data to be synchronized and sent to a second processor to obtain the tensor data to be synchronized according to the descriptor synchronization instruction, thereby reducing synchronization overhead, reducing the complexity of data synchronization, and improving the efficiency of data synchronization (Liu, 0027).
As per Claim 5, the rejection of claim 4 is incorporated and Matsumoto discloses,
wherein the transmission destination computer (Matsumoto, [Pg. 47, Fig. 4.7: Pnode2]) activates an asynchronous user function (Matsumoto, [Pgs. 46-47 – MBCF_SIGNAL command is accompanied by a remote invocation of the user-specified program with the privileges of the target task. The invoked program is executed only in the scheduling periods of the target task]; [Pg. 58 - The memory-based signal provides users of the MBCF with a method of asynchronous communication]), for the reception-side process (Matsumoto, (Matsumoto, [Pg. 28 – Fig. 3.2: Laddr1, target address]; [Pg. 69 - Fig. 6.1: Destination Logical Address]; [Pg. 47 – The MBCF_SIGNAL command is thrown to a memory-based signal structure in the target task. See Fig. 4.7]), at a time point when the operation content history is accumulated in the history memory area (Matsumoto, [at least Figs. 4.1-4.3 – FIFO queue of the MBCF]; [Pg. 45 - Users detect transitions to the cancellation state by use of the status reports]; [Pg. 42 - If the buffer of the specified structure is full, processing of the data in the MBCF_FIFO packet is cancelled. The status-report option should be used to inform the requesting task/node of the cancellation of the command, thereby implying that the destination computer activates an asynchronous user function to the reception-side process at a time point when the operation content history is accumulated in the history memory area]).
As per Claim 6, the rejection of claim 4 is incorporated and Matsumoto discloses,
wherein the transmission destination computer saves (Matsumoto, [Figs. 4.1-4.2 – Pnode2]), in the history memory area (Matsumoto, [at least Figs. 4.1-4.3 – FIFO queue of the MBCF]; [Pg. 42, Fig. 4.1 shows a fifo structure and buffer in a target node. Each fifo structure includes four pointers, to the top, head, tail, and end of the data buffer, and status flags. In the MBCF-interrupt routine, the processor reads the pointers and flags of the target fifo structure first, stores data in the buffer specified by the structure, then updates the structure]), data before being overwritten in the table area of the reception-side process (Matsumoto, [Pg. 42, Fig. 4.2: Operation of MBCF_FIFO cmd – ‘Unread Data’ + ‘New Data’ = Updated History memory area; Here ‘New Data’ pointed by New head pointer is saved in the history memory area before it is overwritten in the table area/New head pointer of the reception side process. Since the claim does not recite how ‘overwritten’ is done, it is valid to interpret that the New head pointer pointing to future data is equivalent to ‘overwritten’]).
Response to Arguments
The Applicant's arguments filed on September 17, 2026 have been fully considered, but they are not persuasive.
Applicant argues, ‘The claims have been amended to address the§ 112 concerns’. (Rem, Pg. 5)
Response: This argument is incorrect. Previous issues still exist. Please see the 112(b).
Applicant further argues, ‘The prior art does not suggest the claimed invention’ (Rem, Pg. 5)
Response: This argument is incorrect.
Matsumoto, 2001 NPL, the primary prior art, fully discloses the data transmission format and functional steps recited in the claims.
The inventor publicly disclosed the MBCF packet structure, and communication protocols of the MBCF mechanism for packet communication from a source computer to a destination computer in Matsumoto, 2001 NPL.
Para-0038 of the spec recites, 'The parallel distributed calculation system 100 does not require any special communication synchronous hardware, and uses a general network interface card (NIC) 23 to construct a memory based communication facility (MBCF - Memory Based Communication Facility) that realizes high-speed,….remote memory operation only by software’.
The spec explicitly strips away any claim to specialized hardware acceleration and adopts a generic NIC operating on kernel framework to execute software-driven processes. Since the inventor publicly disclosed this identical software-only MBCF kernel framework in his 2001 dissertation, the claims are unpatentable over the prior art.
As discussed in the 2001 NPL, in the MBCF architecture, the packet reception interrupt routine is generated through a standard hardware-to-software signaling sequence coordinated by the OS kernel. When a NIC receives a packet and transfers it to a ring buffer, it triggers an interrupt that prompts the CPU to route execution to the kernel's specific service routine, as recited in claim 1. Hence the prior art discloses the claimed invention. Please see O/A.
Applicant further argues, ‘The claimed history memory area therefore holds operation metadata, whereas Matsumoto's FIFO holds the transferred data itself’. (Rem, Pg. 6)
Response: This argument is incorrect.
Nowhere does the spec recite ‘operation metadata’.
As required by claim 1, the area defined by the operation target address stores metadata such as data sequence, data size, operation target address. And operation content is data stored in the history memory area defined by the structure address.
Para-0056 of the spec states, ‘the FIFO queue of the MBCF is used as the history memory area for temporarily recording the operation history’.
And Para-0059 of the spec describes rollback as, ‘The usefulness of leaving a log of the write operation in the history memory will be specifically described below……. When the data before the update is left in the history memory, the sum of the rows and the columns can be calculated ….a new numerical value’. This suggests that by logging the write operations in the history memory, a transaction history is created which shows how the data changed over time, ensuring that the final statistical calculations (sums and averages) can be recovered if a crash occurs.
Hence the history memory area functions as a log. It is well-known that an inherent characteristic of a log is that it is an append-only, time-based sequence of records/data. Accordingly, Masumoto discloses the claimed requirement. Please see the O/A.
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
