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 .
DETAILED ACTION
This office action is in response to amendment/reconsideration filed 12/26/2025, the amendment/reconsideration has been considered. Claims 1-20 are pending for examination.
Response to Arguments
Applicant's arguments are moot in light of the new ground of rejections set forth below.
Claim Rejections - 35 USC § 112
3. 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.
4. 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.
5. Claims 4-7, 11-13, 15 and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
a) Claim 4 recites “retrieving, from stored context information associated with the first I/O command maintained by the network adapter, the first address information and the first length information to obtain retrieved first address information and retrieved first length information.” The scope of the claimed limitation cannot be definitely determined because it is unclear regarding the relationship between the recited stored context information, the first address/length information, and the retrieved first address/length information. Applicant is required to clarify. For the sake of the examination, Examiner assumes any relationship. Claims 5-7 and 12-15 and 20 are similarly rejected.
b) Claim 5 recites “determining, based on the first ID, 1/0 context information to obtain a plurality of groups of address information and length information that are of the first data and that are to be written to the VM; and further determining, from the groups of address information and length information and based on the offset information, target address information and target length information.”
First of all, it is unclear how the recited limitations relate to the response processing recited in the parent claim 4. Since parent claim 4 already completes the response processing by “storing in the local server, based on the retrieved first address information and the retrieved first length information, the first data directly to the VM memory via direct memory access (DMA)”, it is unclear what is the purpose of the steps recited in claim 5 regarding processing the same “first I/I read response message” by determining “groups of address information and length information that are of the first data” and by determining “target address information and target length information”. Applicant is required to clarify. For the sake of the examination, Examiner assumes any relationship.
Secondly, the relationship between the recited entities are unclear. For example, the relationship between the parent claim 4’s “retrieved first address/length information” and the entities recited in this claim 5 such as “groups of address/length information”, target address/length information.” Applicant is required to clarify. For the sake of the examination, Examiner assumes any relationship. Claim 13 is similarly rejected.
c) Claim 6 recites “wherein the first I/O read response message comprises response address information, response length information, and second information about the VM that is in the local server and that delivers the first I/O command, and wherein the data processing method further comprises, based on the first address information, the first length information, and based on the second-information comprised in the first I/O read response message, the response address information and the response length information that are validated to write the first data.”
First of all, the recited “the response address information and the response length information that are validated to write the first data” lacks sufficient antecedent basis. For the sake of the examination, Examiner interprets as any response address information and response length information. In addition, it is unclear regarding the relationship between the response address/length information comprised in the first I/O read response message and “the response address information and the response length information that are validated to write the first data”. Applicant is required to clarify. For the sake of the examination, Examiner assumes any relationship.
Secondly, it is unclear how the recited limitations relate to the response processing recited in the parent claim 4. Since parent claim 4 already completes the response processing by “storing in the local server, based on the retrieved first address information and the retrieved first length information, the first data directly to the VM memory via direct memory access (DMA)”, it is unclear what is the purpose of the steps recited in claim 6 regarding processing the same “first I/I read response message” by determining “based on the first address information, the first length information, and based on the second-information comprised in the first I/O read response message, the response address information and the response length information that are validated to write the first data”. Applicant is required to clarify. For the sake of the examination, Examiner assumes any relationship.
Thirdly, the relationship between the recited entities is unclear. For example, the relationship between the parent claim 4’s “retrieved first address/length information” and the entities recited in this claim 6 such as “response address/length information”, Applicant is required to clarify. For the sake of the examination, Examiner assumes any relationship. Claim 14, 7, and 15 are similarly rejected.
Claim Rejections - 35 USC § 103
6. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
7. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
8. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
9. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kanevsky et al (US 2010/0083247) in view of Cherian et al (US 20160188527 A1).
As to claim 1, Kanevsky discloses a data processing method implemented by a host RMDA controller, comprising:
obtaining a first input/output (I/O) command instructing to store first data in at least one remote server to a local server, wherein the first I/O command comprises first address information of the first data and first length information of the first data ([0051], “The RDMA techniques described herein can be used to transfer data between host memory in the processing system 2 (e.g., memory 22) and the NVSSM subsystem 26. Host RDMA controller 25 includes a memory map of all of the memory in the NVSSM subsystem 26.” See Figure 2A, indicating that the processing system 2 and NVSSM subsystem 26 are connected via a network 6 therefore are remote from each other. See [0076]. “a single RDMA STag can be generated to specify multiple segments in different subsets of non-volatile solid-state memory in the NVSSM subsystem 26, at least some of which may have different access permissions (e.g., some may be read/write or as some may be read only”; [0077], “As noted above, the hypervisor 11 includes an NVSSM data layout engine 13, which can be implemented in an RD MA controller 53 of the processing system 2, as shown in FIG. 5. RDMA controller 53 can represent, for example, the host RDMA controller 25 in FIG. 2A…….an NVSSM data layout engine 46 within a virtual machine 4 can combine multiple data access requests from its host file system manager 41 (FIG. 4) or some other source into a single RDMA access.”; [0079], “In the embodiment of FIGS. 2Aand3A, the single RDMA read or write is decomposed into multiple data access operations (reads or writes) within the processing system 2 by the host RDMA 25 controller, and these multiple operations are then executed in parallel or sequentially on the NVSSM subsystem 26 by the host RDMA 25 controller”. Here, “to specify multiple segments in different subsets of non-volatile solid-state memory” indicates that the I/O command comprises first address information of the requested first data and first length information of the requested first data);
splitting, based on the first address information and the first length information, the first I/O command to obtain a plurality of I/O read messages without storing the first data in a memory of the RMDA controller, wherein each of the I/O read messages comprises first information that is of each piece of the first data (see citation above, wherein the I/O read messages to comprise first information that is of each piece of the first data is implied in order to read the corresponding part of the first data, and also indicated by “different subsets of non-volatile solid-state memory”. Also see Fig. 6; Fig. 8 and claim 38); and
separately sending, via a network protocol processing engine of the RMDA controller and to the at least one remote server, the I/O read messages for retrieving the first data from the at least one remote server to be written directly to a memory associated with a virtual machine (VM), without storing the first data in the memory of the RMDA controller (see citation above, e.g., [0079], “the single RDMA read or write is decomposed into multiple data access operations (reads or writes) within the processing system 2 by the host RDMA 25 controller, and these multiple operations are then executed in parallel or sequentially on the NVSSM subsystem 26 by the host RDMA 25 controller”. See [0051], Figure 2A, abstract, wherein the host memory is associated with any virtual machine running on the processor).
However, Kanevsky does not expressly disclose that the above-disclosed host controller RMDA functions can be implemented by a network adapter. Cherian discloses a concept for all RMDA functions to be implemented by an RMDA network adapter bypassing the operating system kernels of the host and guest operating systems, said RMDA functions including (but not limited to) obtaining I/O read packets/messages without storing the requested first data in a memory of the network adapter and sending via a network protocol processing engine of the network adapter and to the at least one remote server, the I/O read messages/packets for retrieving the first data from the at least one remote server to be written directly to a virtual machine (VM) memory without storing the first data in the memory of the network adapter ([0119], “Otherwise, the process, by the RDMA NIC, uses (at 1625) the memory region information in the RDMA data packets to directly move the data into the requesting VM's memory buffers 1580”; [0120], “As can be seen from FIGS. 4, 6, and 8-13, the commands for address resolution, connection creation, and QP creation are handled through the RDMA stack. As can be seen from FIGS. 14-16, the actual RDMA data transfer is done directly to/from the VMs' memory buffers and the RDMA NICs bypassing the operating system kernels of the host and guests operating systems.”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Kanevsky with Cherian. The suggestion/motivation of the combination would have to bypass the operating system kernels of the host and guest operating systems (Cherian, [0120]). It is to be noted that it is the concept of Cherian that discloses moving ALL RMDA functions into the RDMA NIC bypassing the operating system kernels of the host and guest operating systems that is being combined with Kanevsky, not a mechanical combination of the two systems. As a result of the combination, all RMDA functionality implemented by the host RMDA controller of Kenevsky would be moved to the RMDA NIC of Cherian.
As to claim 9, see simi rejection to claim 1.
As to claim 17, see similar rejection to claim 1.
As to claim 2, Kanevsky-Cherian discloses the data processing method of claim 1, wherein the first information comprises second address information of each piece of the first data, second length information of each piece of the first data, and second information about the VM that is in the local server and that delivers the first 1/0 command (See citation in rejection to claim 1, e.g., Kanevsky, [0076]. “a single RDMA STag can be generated to specify multiple segments in different subsets of non-volatile solid-state memory in the NVSSM subsystem 26”; Cherian, ([0119], “Otherwise, the process, by the RDMA NIC, uses (at 1625) the memory region information in the RDMA data packets to directly move the data into the requesting VM's memory buffers 1580”, wherein address information and length information are implied and also indicated by “different subsets of tnon-volatile solid-state memory”, and wherein “the destination VM’s memory buffers 1580” indicates second information about the VM. It is to be noted that the claimed does not require a specific relationship between the second address information, second length information, and second information, therefore Examiner interprets as any relationship).
As to claim 10, see similar rejection to claim 2.
As to claim 18, see similar rejection to claim 2.
As to claim 3, Kanevsky-Cherian discloses the data processing method of claim 1, wherein the first information comprises second address information of each piece of the first data and second length information of each piece of the first data (see citation and explanation in rejection to claims 1 and 2).
As to claim 11, see similar rejection to claim 3.
As to claim 19, see similar rejection to claim 3.
As to claim 4, Kanevsky-Cherian discloses the data processing method of claim 1, further comprising:
receiving, from the remote server, a first I/O read response message comprising the first
data (see citation in rejection to claim 1);
retrieving, from stored context information associated with the first I/O command maintained by the network adapter, the first address information and the first length information to obtain retrieved first address information and retrieved first length information (See 112 rejection and Examiner’s interpretation above. See Kanevsky, [0051], “The RDMA techniques described herein can be used to transfer data between host memory in the processing system 2 (e.g., memory 22) and the NVSSM subsystem 26. Host RDMA controller 25 includes a memory map of all of the memory in the NVSSM subsystem 26”; See [0072], “some or all of memory of DIMM 28 is mapped to an RDMA STag for each processing system 2 and shared data stored in that memory is used to determine which subset of memory is owned by which processing system 2”. See Fig. 12, “Store the address mapping information included in the queue pair”. See Cherian, Fig. 15; Fig. 16 and [ 0119], “Otherwise, the process, by the RD MA NI C, uses ( at 1625) the memory region information in the RDMA data packets to directly move the data into the requesting VM's memory buffers 1580”, indicating that the address and length are obtained/retrieved by the RDMA NIC in order to move the data to correct memory location and in correct size. It is to be noted that the received data packets are associated with the first I\/O command as being a response to the command, and the data packets in the RDMA NIC’s memory in order to be processed. It is to be noted that the claimed does not require persistent storage or pre-storing for the context information); and
storing, in the local server based on the retrieved first address information and the retrieved first length information, the first data directly to the VM memory via direct memory access (DMA) (see citation in rejection to claims 1 and 2, Kanevsky, [0051]; [0072]; [0076]; Cherian, [0119]).
As to claim 12, see similar rejection to claim 4.
As to claim 20, see similar rejection to claim 4.
As to claim 5, Kanevsky-Cherian discloses the processing method of claim 4, wherein the first I/O read response message comprises a first identifier (ID) of the first data and offset information of the first data (see citation in rejection to claim 1, e.g. Cherian, Fig. 16 and [ 0119], “Otherwise, the process, by the RD MA NI C, uses ( at 1625) the memory region information in the RDMA data packets to directly move the data into the requesting VM's memory buffers 1580”, wherein the memory region information that enables moving data packets directly into the requesting VM’s memory buffers indicates a VM ID/location/offset, and data length to be put in buffer is implied), and wherein the data processing method further comprises:
determining, based on the first ID, I/O context information to obtain a plurality of groups of address information and length information that are of the first data and that are to be written to the VM (see 112 rejection and Examiner’s interpretation therein. See citation in rejection to the previous limitation, wherein the buffer location is equivalent to a address information, and offset/length of data packet is equivalent to length information, and wherein “buffers” indicates groups) and
further determining, from the groups of address information and length information and
based on the offset information, target address information and target length information (see 112 rejection and Examiner’s interpretation therein. See citation in rejection to the preceding limitation).
As to claim 13, see similar rejection to claim 5.
As to claim 6, Kanevsky-Cherian discloses the data processing method of claim 4, wherein the first I/O read response message comprises response address information, response length information, and second information about the VM that is in the local server and that delivers the first I/O command, and wherein the data processing method further comprises, based on the first address information, the first length information, and based on the second information comprised in the first I/O read response message, the response address information and the response length information that are validated to write the first data (see 112 rejection and Examiner’s interpretation therein. See citations in rejection to claims 2 and 4).
As to claim 14, see similar rejection to claim 6.
As to claim 7, Kanevsky-Cherian discloses the data processing method of claim 6, further comprising determining that the response address information and the response length information comprised in the first I/O read response message fall within a permission table that comprises a plurality of groups of address information in the local server and length information of written data in the local server (see 112 rejection and Examiner’s interpretation therein. See citation in rejection to claim 4; and Cherian, Fig. 15 and Fig. 16, wherein moving the data to the corresponding VM buffers according to the memory region information indicates that the memory region information fall within a permission table of all buffers allowed).
As to claim 15, see similar rejection to claim 7.
As to claim 8, Kanevsky-Cherian discloses the data processing method of claim 1, further comprising:
determining, based on context information of the first I/O command, whether a plurality of
pieces of the first data are all written to the local server, wherein the context information comprises
a storage complete state of the pieces of the first data in the local server; and sending, to the local server through an interface, an I/O read complete message when the pieces of the first data are all written to the local server (Kanevsky, Fig. 11B, Steps 1124-1125, “ROMA controller moves data from
flash and NV DRAM according to gather list into scatter list buffers of destination memory. ROMA controller signals 11completion" status to operating system for last read in the sequence”). As to claim 16, see similar rejection to claim 8.
Conclusion
10. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
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, Umar Cheema can be reached at 571-270-3037. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUA FAN/ Primary Examiner, Art Unit 2458