DETAILED ACTION
Claims 1, 2, 4, 5 are amended. Claims 1-6 are pending.
Priority: 7/30/2020
Assignee: Information Sc. Lab
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/10/2025 has been entered.
Claim objections
1.Amended Claim 4 is objected for reciting a limitation that is inconsistent with the spec.
Amended claim 4 recites, ‘the destination computer…. stores….and information of the transmission-side process ….as operation content history’.
But spec, Para-0008 recites, ‘the destination computer…. stores information of the transmission-side process ….as operation content.
The spec does not recite that ‘operation content’ is synonymous with ‘operation content history’.
2.Amended Claim 1 is objected for reciting limitations that lacks clarity due to missing words like ‘stores’, ‘history memory area’ etc.
Amended Claim 1 recites, ‘….and ????? information including an identifier ….in the history memory area, and ???? is configured to record a plurality of….’.
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.
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 Claim 1 is rejected for reciting a limitation with antecedent basis issues.
Amended claim 1 recites, ‘the transmission destination computer ….and is configured to record ….for a same operation target address’.
But claim 1 previously recites, ‘the transmission destination computer receives the operation request packet, stores the data sequence ….and the operation target address’.
Here it is unclear if ‘the operation target address’ is the same as ‘a same operation target address’. For examination, the spec is followed.
1.Amended Claim 1 is rejected for reciting a limitation that is unclear, misleading and indefinite.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Amended Claim 1 recites, ‘the transmission destination computer receives the operation request packet, ..…., and information including an identifier of the transmission-side process as operation content history in the history memory area,….’.
The spec does not recite this limitation.
Claim 1, which is based at least on spec, Para-0007, recites that the transmission-computer transmits an operation request packet including an identifier of destination process, an operation target address, a data size, a data sequence, and a structure address that defines a history memory area in the reception-side. That’s all.
As recited, the transmission-computer only transmits a destination-identifier (string, number etc.), addresses, data size (number), and data sequence (number). No transmission-process identifier is transmitted. So it is unclear how the destination-computer receives the identifier of the transmission-side process.
Without being transmitted, the identifier cannot be received. Claim 1 does not clearly recite (the steps) how the identifier of the transmission-side process is included in the packet, transmitted and received via the same packet, at the destination-computer. As a result, claim 1 is incomplete.
Furthermore, history is linked with time. A transmission-side ‘identifier’, which is just a value, stored in the history memory area, of the destination-computer, during a single transmission does not constitute ‘operation content history’. The recitation is misleading.
Therefore claim 1 is rejected for reciting a limitation that is unclear, misleading and indefinite. Claims 2-6 are also rejected for failing to cure the deficiency from their parent claim by dependency. For examination, the spec is followed.
2.Amended Claim 1 is rejected for reciting a limitation that is unclear, speculative and indefinite.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Amended claim 1 recites, ‘the transmission destination computer……, and is configured to record a plurality of operation content histories generated by a plurality of transmission-side processes….’. The spec does not recite the amendment.
Claim 1 (and spec) recites communication between two computers, a source and destination computer. Claim 1 recites a one-to-one relationship between ‘a transmission-side process’ and ‘a transmitted packet’. Claim 1 recites the transmission of only one packet.
The history memory area is a temporary storage. History is linked with time but the spec lacks clear, detailed steps to show how ‘operation content’ becomes ‘operation content history’, with time, for the single transmission-side process and one transmitted packet.
It is undisclosed how the single destination-computer interacts and handles a ‘plurality of transmission-side processes’. It is undisclosed how the same history memory area is shared for all transmission-side processes. Hence it is unclear how the history memory area or any other storage area in the destination computer, stores operation content histories generated by a plurality of transmission-side processes. The limitation is an unproven, undisclosed leap in function and structure, unsubstantiated by the spec.
Accordingly, claim 1 recites a hypothetical limitation that suggests new matter. Hence claim 1 is rejected for reciting a limitation is unclear, hypothetical and indefinite. Claims 2-6 are also rejected for failing to cure the deficiency from their parent claim by dependency. For examination, the spec is followed.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3 are rejected under 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: 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]), 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]) 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]) 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]; [Pg. 52, Sec. 4.2 - Reply with a status report - If a reply is to be returned, it is stored at the location which has been specified by the requestor/source and is included in both the requesting packet and the replying packet. The requestor uses the stored status to recognize the completion of the MBCF command or the occurrence of some failure at the target task, thereby disclosing that the source computer provides the structure address of the history memory area]),
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, [Fig. 4.2]; [Pg. 42, Para-1 - Writes/stores the data to the target address Laddr1]), records the operation target address (Matsumoto, [Pg. 42 - target address Laddr1]; [Pg. 47 – Fig. 4.7]; [Fig. 4.8]; [Pg. 48, Para-1 - In all configurations of the signal structure the information Ltask/Laddr1/operation target address, Pnode and Ptask of the requestor on the received MBCF SIGNAL packet is stored in the buffer/fifo/history memory area where the carried data is stored, thereby implying that the operation target address is stored in the history memory area of the receiver-side process]),
the data size written to the memory area (Matsumoto, [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]; [Pg. 42 - Stores data in the buffer specified by the fifo structure, then updates the fifo structure]), and information including an identifier ([See 112(b)]) of the transmission-side process (Matsumoto, [Pg. 30-31: Packet Header]; [Pg. 26, Sec. 3.3.3 - The Ltask notation for an MBCF applications is the local and virtual identifier for that task/process, while the (Pnode:Ptask) notation is used in MBCF inter-node packets. Therefore, in each MBCF packet, the notation for a global address is (Pnode:Ptask:Laddr)]) as operation content 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]) 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]; [Pg. 52, Sec. 4.2 - Reply with a status report]; [Pg. 32 - Optional parameters are available for the MBCF_WRITE command, e.g., an address for status-return]),
Matsumoto discloses a history memory area in each MBCF packet.
Sabetta further clarifies,
information including an identifier (Sabetta, [0029 - A packet to be transferred in the path Pa is identified by a virtual local area network identifier/VID. The VID is included in virtual local area network/VLAN tag added to the packet]) of the transmission-side process ([Fig. 7: node # 1]; [See 112(b)]) as operation content history in the history memory area (Sabetta, [0048 - Fig. 4 shows the format of the packet]; [Fig. 8]; [0049 – In Fig. 4, the packet includes a destination address/DA/destination-computer, a source address/SA/transmission-computer, a VLAN tag, a type, a payload, and a frame check sequence/FCS]; [0050 – In Fig. 4, The VLAN tag includes a tag protocol identifier/TPID, a priority value, a canonical format identifier/CFI, and a VID; The claim does not recite the format of the identifier. So it is valid to interpret that the packet received by the destination-computer has information about the source and VID/identifier of transmission-side]),
and is configured to record a plurality of operation content histories (Sabetta, [Fig. 12: VID table; The table is stored in each node, thereby storing identifiers of each transmission process to represent operation content history]; [Fig. 4: Each packet has a timestamp parameter]; [See 112(b)]) generated by a plurality of transmission-side processes (Sabetta, [Fig. 1: nodes #1….#6]; [Fig. 3: queue manager 147 of each node manages queues/processes from different nodes/transmission-computers]) for a same operation target address (Sabetta, [0046 – In Fig. 3, a VID table is stored in the storage section 148/history area, in each node; This implies that the VID table is stored in the destination-computer, node # 2 and like the history memory area stores temporary information]; [0049 – In Fig. 4, the packet includes a destination address/DA/destination-computer]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the VID of Sabetta 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 (Sabetta, 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 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]), 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]) 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. There is no patentable weight in manipulating fifo pointers to define memory regions]),
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]), 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 from the memory address (Matsumoto, [Fig. 4.2]; [Pg. 42, Para-1 - Writes/stores the data to the target address Laddr1]), and stores the operation target address (Matsumoto, [Pg. 42 - target address Laddr1]), 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, [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]; [Pg. 42 - Stores data in the buffer specified by the fifo structure, then updates the fifo structure]), and information of the transmission-side process in the history memory area as operation content history (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: Operation of the MBCF_FIFO(1) command]; [Fig. 4.2: Operation of the MBCF_FIFO(2) command]; [Pg. 42, Para-1 - 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, thereby implying that the transmission destination computer stores information of the transmission-side process in the history memory area as operation content]).
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, Sabetta 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 December 10, 2025 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: ‘Claim I recites "records ….and information including an identifier of the transmission-side process as operation content history in the history memory area’. (Rem, Pg. 4)
Response: Please see the 112(b). The transmission-computer only transmits the destination-process identifier, addresses, data size, and data sequence. Claim 1 does not clearly recite how the destination-computer ‘receives’ the transmission process identifier. In a source-destination system, reception of a value cannot happen without transmission.
Though spec, Paras:0053-0056 recite the transmission of the MBCF_WRITE_wLOG operation request packet, the transmitted information from the transmission-computer is similar to spec Paras:0007, 0040, 0045, 0054, 0061, which applies to all commands and packets. And no transmission-side identifier is transmitted.
Though spec Para-0056 recites, ‘However, the content registered in the FIFO queue as the history memory area is not data loaded in the operation request packet’, the transmission-computer in claim 1, does not recite the difference. The required identifier is not transmitted in claim 1. The spec makes an unsubstantiated ‘receive’ statement without providing the supporting steps.
Since data size and data sequence are transmitted, it suggests that the transmission-side transmits data. If ‘data is not loaded’ into the packet, then the contents of the transmitted packet must be different. But the ‘different packet’ is unrecited in the spec. As a result, claim 1 is incomplete, misleading and the spec fails to meet the written description requirement.
Figs. 8-10 of the spec and the written description do not show how the identifier of the transmission-side process is represented and stored in the history memory area.
In short, the amendment incorporates teachings from separate embodiments in the spec. And the key issue is that the spec does not provide a direct, unambiguous link or clear written description for combining the embodiments.
Applicant further argues: ‘Claim I further recites "configured to record a plurality of operation content histories generated by a plurality of transmission-side processes for a same….target address’. (Rem, Pg. 4)
Response: The amendment recites a hypothetical limitation that suggests new matter. Please see the 112(b).
The spec does not recite ‘transmission-side processes’. So it is unclear, and undisclosed how they are associated with the single transmission-computer and destination-computer. Claim 1 does not recite any parallel processes in the transmission-computer.
Claim 1 and spec recite that the history memory area, defined by the structure address, is provided by the transmission-computer/process. But the spec does not recite that the same history memory area can be shared with other ‘transmission side processes’.
Whether it is the history memory area or any other (undisclosed) memory area in the destination-computer, the spec does not support the amendment.
Claim 1 recites communication between a (single) transmission-side process and a (single) reception-side process, to transmit one packet. Multiple packet processing is undisclosed.
Furthermore, there is no written description support clearly explaining how ‘a plurality of transmission-side processes’ would be handled (sequentially or simultaneously) by the single reception-side process, especially with respect to storing and building with time the ‘operation content’ to ‘operation content history’, for each ‘transmission-side process’. Spec, Fig. 10 uses a different command and the written description does not provide any clarity in handling multiple processes. In other words ‘recording operation content histories’, at the destination computer, is undisclosed.
Though claim 1 recites ‘a parallel and distributed system’, parallel, distributed processing is a complex field of technology and the complexity arises from managing multiple, simultaneous processes. Neither claim 1 nor the spec provide adequate written description support to handle multiple, simultaneous processes in the claimed system.
The limitation makes a functional and structural leap to cover this entire field of complex technology. However due to lack of adequate written description support in the spec, the limitation lacks patentable weight.
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