DETAILED ACTION
Claims 1 and 4 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 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 a limitation that is unclear, inconsistent and indefinite.
Amended Claim 1 recites, ‘a process of a transmission source computer ….transmits an….packet including an identifier of an operation target process…., …, ….a data sequence, information including an identifier of the transmission-side process….’
The spec does not recite this limitation.
Spec, Para-0004 recites, ‘….transmits an operation request packet including an identifier of an operation target process….’.
According to the spec, only one identifier is transmitted and the identifier is associated with the target process of the destination computer.
Hence, ‘information including an identifier of the transmission-side process’ being inconsistent with the spec, is unclear. Hence claim 1 being unclear is indefinite and rejected. Claim 4 has the same issue.
Note: This issue was mentioned in the previous O/A. But it is unresolved. Hence the rejection has been maintained.
2.Amended Claims 1,4 are rejected for reciting a limitation that is unclear, repetitive and indefinite.
Amended Claim 1 recites, ‘stores the data sequence in the memory area defined by the reception-side process and the operation target address’, and later recites, ‘(i) a write of the data sequence to the memory area defined by the operation target address’.
Since ‘store’ and ‘write’ mean the same thing, the latter recitation is repetitive, superfluous without adding clarity or impact. Hence claim 1 is rejected. Claim 4 has the same issue.
3.Amended Claims 1,4 are rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Amended Claim 1 recites, ‘(ii) recording operation content history…. in the history memory area’.
The spec does not recite this limitation.
Para-0007 of the spec recites, ‘information of the transmission-side process in the history memory area as operation content’.
‘history’ is a function of time. But Claim 1 recites one transaction, from source to target, with one packet. Therefore what is recorded for that transaction is ‘operation content’, not operation content history. Hence it is unclear how ‘operation content history’ is recorded in the destination computer for a single transaction. Accordingly claim 1 is rejected. Claim 4 has the same issue.
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 limitations that are unsupported by the spec.
Amended Claim 1 recites, ‘a process of a transmission source computer ….transmits ….packet including an identifier of an operation target process…. information including an identifier of the transmission-side process,….’,
Nowhere does the spec recite the limitation. The spec does not recite transmitting ‘an identifier of the transmission-side process’ by the source computer.
Claim 1 further recites, ‘the transmission destination computer receives the…. packet, stores…. the information including the identifier of the transmission-side process in the history memory area’.
The spec does not recite that ‘the identifier of the transmission-side process’ is received by the destination computer and stored in the history memory area.
For example, Para-0007 of the spec recites, ‘the transmission destination computer receives the operation request packet, stores ….information of the transmission-side process in the history memory area as operation content’. The identifier is not included for storage in the history memory area.
The spec does not disclose ‘extracts from the ….packet….the identifier of the transmission….’. The spec does not disclose how the destination computer performs parsing of the received packet to ‘extract’ the identifier of the transmission-side process or other parameters or data. For example, the spec does not disclose a receiver for obtaining the received packet and a ‘parser’ configured to extract and store the designated parameters based on the transmitted packet.
In other words, the claim sets forth a desired result of storing parameters from a received packet based on a transmitted packet, but fails to convey that the inventor had possession of the specific details of the parsing process(es) and extraction mechanism(s) required to arrive at those parameters. Therefore the recitation, ‘extracts from the operation request packet the information including the identifier of the transmission-side process’, demonstrates lack of possession at the time of filing.
Since amended claim 1 recites a scope that is unsupported by the spec, it recites new matter. Claim 4 has the same issue.
2.Amended Claims 1,4 are rejected for reciting a limitation that is unsupported by the spec.
Amended Claim 1 recites, ‘a process of a transmission source computer ….transmits an operation request packet including….a structure address that defines a history memory area distinct from the memory area defined by the operation target address’.
The ‘structure address’ and the ‘operation target address’, both addresses, are transmitted to the destination computer. The spec recites that ‘operation target address defines a memory area of the reception-side process’, and ‘structure address defines a history memory area’.
The claim further recites ‘extracting’ the parameters at the destination computer. But the spec does not disclose how the two addresses are distinguished during the ‘extraction’ at the destination computer.
The claim sets forth a desired result of storing the two addresses from a received packet based on a transmitted packet, but fails to convey that the inventor had possession of the details of specific parsing process(es) and extraction mechanism(s) required to distinguish the two addresses and use them to represent two distinct memory areas. Therefore the recitation, ‘a structure address that defines a history memory area distinct from the memory area defined by the operation target address’, demonstrates lack of possession at the time of filing.
Since amended claim 1 recites a scope that is unsupported by the spec, it recites new matter. Claim 4 has the same 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 are rejected under AIA 35 U.S.C. 103 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 Sabetto (20200304431).
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 an identifier ([See 112(a), 112(b)]) 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]),
and 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) a write 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]) to 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 ([See 112(b)]) history (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 written 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 identifier ([See 112(a), 112(b)]) 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]).
Matsumoto discloses receiving a packet by the destination system from the transmission system.
Sabetto further clarifies the packet processing,
extracts from the operation request packet (Sabetto, [0063 - Fig. 5 shows a process executed upon the reception of a packet]; [0048 - Figs. 4,8 show the format of the packet]) the information including the identifier (Sabetto, [0029 - The VID is included in virtual local area network/VLAN tag added to the packet]) of the transmission-side process (Sabetto, [0049 - The packet includes a destination address/DA, a source address/SA, a VLAN tag, a type, a payload, and a frame check sequence/FCS]; [0045 - The VLAN tag includes a tag protocol identifier/TPID, a priority value, a canonical format identifier/CFI, and a VID]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the VID of Sabetto into the MBCF/Memory-Based Communication Facility of Matsumoto for the benefit of packet processing by the queue manager in the target, wherein in the VID table, VIDs of stored packets are registered in the order in which the packets have been input for each of queue IDs identifying the high-priority queues and the low-priority queues based on the priority values. Thus, the queue manager manages the VIDs of the packets stored in the high-priority queues and the low-priority queues (Sabetto, 0055).
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 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 Sabetto (20200304431) 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 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. 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 an identifier ([See 112(a), 112(b)]) 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]), stores the data sequence (Matsumoto, [Fig. 6.1]) from the memory address (Matsumoto, [Fig. 4.2]; [Pg. 42, Para-1 - Writes/stores the data to the target address Laddr1]; [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) a write 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]) to 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 ([See 112(b)]) history (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 written (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 identifier ([See 112(a), 112(b)]) 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]).
Matsumoto discloses receiving a packet by the destination system from the transmission system.
Sabetto further clarifies the packet processing,
extracts from the operation request packet (Sabetto, [0063 - Fig. 5 shows a process executed upon the reception of a packet]; [0048 - Figs. 4,8 show the format of the packet]) the information including the identifier (Sabetto, [0029 - The VID is included in virtual local area network/VLAN tag added to the packet]) of the transmission-side process (Sabetto, [0049 - The packet includes a destination address/DA, a source address/SA, a VLAN tag, a type, a payload, and a frame check sequence/FCS]; [0045 - The VLAN tag includes a tag protocol identifier/TPID, a priority value, a canonical format identifier/CFI, and a VID]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the VID of Sabetto into the MBCF/Memory-Based Communication Facility of Matsumoto for the benefit of packet processing by the queue manager in the target. The queue manager manages the VIDs of the packets stored in the high-priority queues and the low-priority queues (Sabetto, 0055).
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, Sabetto 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 April 13, 2026 have been fully considered, but they are not persuasive. The MPEP advises that while the specification provides important context and definitions, it is crucial to avoid importing limitations from the spec into the claims that are not explicitly stated in the claim language.
Applicant argues:‘This amendment is fully supported by the specification's disclosure that the destination computer records information of the transmission-side process in the history memory area as operation content, together with the packet-format disclosure including Fig. IO' s Source Task ID (the identifier of the transmission-side process) and Structure Address (Laddr2)’. (Rem, Pg. 5)
Response: This argument is incorrect. Please see the 112(b) and 112(a).
Fig. 10 of the spec does not clearly align with the claims. Fig. 10 shows a high-level ‘original request’, a high level received ‘packet header’, task table and a logical address space, without clear explanation how each parameter of the ‘original request’, the received ‘packet header’, task table and logical address space are represented by the claims.
Specifically, the Para-0064 recitation, ‘In the MBCF reception routine in the interrupt routine, the processor of the transmission destination computer 2 (2Y) reads the pointer and the flag in the FIFO structure as the operation target, and stores the operation target address (Laddr1), the information of the row (row1) and the column (col1), the written data size (n), and the information of the transmission-side process (Ltask4) in the buffer area (history memory area) defined by the pointer and the flag as the operation content (LOG DATA)’, cannot be interpreted to represent the claims.
Fig. 10 of the spec does not disclose ‘Source Task ID’, aka ‘the identifier of the transmission-side process’. In fact, nowhere does the spec recite the phrase ‘Source Task ID’ or that ‘Source Task ID’ is transmitted to the destination computer. Though Fig. 10 shows ‘Laddr2’ as a command parameter, Fig. 10 does not show what ‘Laddr2’ represents, .i.e. if Laddr2 holds the memory address of the entire data block including ‘LOG Data’. The spec does not disclose lookup tables, connection handshakes and/or memory registration between the source and the target to describe how the source determines the two addresses in target address space. So how ‘Laddr1’ is determined from the command to represent a separate memory area and its value stored in the history memory area, lacks clear written description support.
In other words, the spec takes an undisclosed giant leap in IPC and memory mapping and without disclosing details recites sending a packet with ‘parameters’ which are extracted and stored at the receiver. This silence of the spec shows lack of possession.
Therefore, Fig. 10, Para-0064 of the spec does not clearly represent the claims.
As an aside, though the claims recite transmitting and receiving a packet, Fig. 10 shows the transmitted and received ‘custom’ commands with parameters. Though packet parsing is well known in the art, it is a key feature of the claims because a packet containing a ‘custom’ command with specific parameters is transmitted from the source to the target. After receiving the packet, how the target extracts the parameters, understands the ‘custom’ command, and executes it, is undisclosed.
Applicant further argues:‘Claim I….recites that a transmission destination computer receives the operation request packet, extracts information including an identifier of the transmission-side process from the operation request packet, and, based on the operation request packet….’ (Rem, Pg. 5)
Response: Please see the 112(b) and the 112(a).
As mentioned in 112’s, the spec does not disclose how ‘extracting’ of information is performed from the received packet so that the parameters can be identified and stored. The lack of disclosure shows lack of possession.
As mentioned above, the spec does not disclose transmitting and/or receiving ‘the identifier of the transmission-side process’. Neither does the spec disclose how the destination computer or any destination process performs parsing of the received packet to ‘extract’ the identifier of the transmission-side process or other parameters.
Because the spec fails to disclose any corresponding structure such as a specific parsing algorithm, pseudocode, or flowchart that corresponds to the claimed step of ‘extracting’ required information from the packet, the scope of the claim is impermissibly broad and non-enabling.
Applicant further argues: ‘Matsumoto's disclosure of FIFO structures relates to buffering and communication control and does not teach recording operation content history including an identifier of a transmission-side process in a separate memory area defined by a structure address in the packet’. (Rem, Pg. 6)
Response: This argument is incorrect.
As mentioned above, the spec does not disclose transmitting and/or receiving ‘the identifier of a transmission-side process’.
For example, Para-0007 of the spec recites, ‘wherein a process of a transmission source computer (hereinafter, a transmission-side process) transmits an operation request packet including an identifier of an operation target process’. Please see 112(a) and 112(b).
Para-0056 of the spec recites, ‘the FIFO queue of the MBCF is used as the history memory area for temporarily recording the operation history’. And Para-0064 recites, ‘the FIFO structure at the address of Laddr2 defines the FIFO queue as the history memory area’.
Accordingly, Matsumoto, at least Figs. 4.1-4.3, 4.7,4.8 show the FIFO queue of the MBCF. Hence the FIFO structures (shown in the above figures) are used as history memory area. Furthermore, Matsumoto, Fig. 4.8 is similar to Fig. 10 of the spec, wherein Matsumoto, Fig. 4.8 discloses the ‘Signal Structure at Laddr1’ to represent the operation target address, which is a memory area distinct from the history memory area. Hence Matsumoto and the spec recite the same concept.
Applicant further argues: ‘There is no motivation to combine Matsumoto and Sabetto in the manner proposed by the Examiner. Matsumoto is directed to remote memory operations in a distributed computing system, whereas Sabetto is directed to packet scheduling within a network switch’. (Rem, Pg. 7)
Response: This argument is incorrect.
In Para-0001, the spec recites, ‘The present invention relates to a parallel and distributed computing system….’. The spec discloses packet processing.
Spec, Para-0036 recites, ‘As illustrated in FIG. 1 (a), a parallel and distributed computing system 100 of the present embodiment is obtained by interconnecting a plurality of computers 2 to each other via a data link 3 and a switching hub device 4’.
Matsumoto discloses the claimed invention as a parallel, distributed system, while processing packets, as required by the claims and the spec. Sabetto discloses packet processing (in detail) which basically uses a parallel and distributed approach. Packet processing systems like switches, routers, etc., use concurrency to process multiple packets at once. To achieve load balancing, work is distributed across different computing units to prevent bottlenecks. Therefore the combination of Matsumoto, Sabetto disclose the same architecture and functions as required by the claims and the spec, and are valid prior art.
The motivation to combine Matsumoto and Sabetto is valid because Sabetto discloses the details of processing/parsing the received packet to extract and determine the parameters and store them accordingly. Sabetto explains the significance of the parameters as packets are transmitted and processed, between nodes in the parallel and distributed system.
On the other hand, the processing/parsing of the received packet is missing in the spec. The spec recites transmitting a packet, receiving a packet, and storing the parameters in the packet without any disclosure of determining the significance of the parameters. It is well-known that a plurality of parameters can be transmitted via packets and stored in various data structures in the target. There is no novelty in transmitting and storing the plurality of parameters in the packet. In essence, the disclosure lacks an inventive concept.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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