DETAILED ACTION
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 .
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 (i.e., changing from AIA to pre-AIA ) 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.
Priority
Applicant’s claim for the benefit of prior-filed application 17/934,699, now issued as US 12,346,589, and PCT/CN2021/077840 under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Acknowledgment is made of applicant’s claim for foreign priority based on applications CN 202010220314.8 filed in China on March 25, 2020 and CN 202010574780.6 filed in China on June 22, 2020 under 35 U.S.C. 119 (a)-(d).
The certified copy has been filed in parent Application No. 17/934,699, filed on March 21, 2023 and April 26, 2023.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on May 30, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Examiner recommends utilizing the same title as the parent application.
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-6, 8-15, and 17-21 are rejected under 35 U.S.C. 103 as being unpatentable over Luo et al. (EP 3,525,080) in view of Xu et al. (US 2017/0235499, as presented in applicant’s IDS)
Regarding claim 1, Luo teaches a storage system (Fig. 1 and Fig. 13), comprising:
a client (Fig. 13, shown to communicate with a storage node); and
a storage node comprising a first storage device (Fig. 13, storage node, with Fig. 1 showing storage nodes with NVMe devices, see also [0021];
wherein the client is configured to:
receive, from a metadata node, identifiers of storage devices, wherein each partition of multiple partitions includes at least one of the storage devices (“A correspondence between a partition and an NVMe storage device, to be specific, a mapping relationship between a partition and an NVMe storage device included in the partition, is also referred to as a partition view. As shown in FIG. 3, for example, a partition includes four NVMe storage devices, and a partition view is "P2-(storage node Ni-NVMe storage device 1)-(storage node N.sub.2-NVMe storage device 2)-(storage node N.sub.3-NVMe storage device 3)-(storage node N.sub.4-NVMe storage device 4)". To be specific, the NVMe storage device 1, the NVMe storage device 2, the NVMe storage device 3, and the NVMe storage device 4 form a stripe relationship. When each storage node includes only one NVMe storage device, the partition view shown in FIG. 3 may also be indicated as P2-storage node N.sub.1-storage node N.sub.2-storage node N.sub.3-storage node N.sub.4. Usually, partition division and partition view allocation are implemented by a management serve… To facilitate access of the client and reduce access pressure on the management server, in an implementation, the management server sends the partition view to the client,” [0024]);
obtain a write request that carries first data (“receiving, by a client, a write request, where the write request includes a storage address,”[0004] and “An access request used by the client to access the volume, for example, a write request, includes a storage address and data,” [0024]);
obtain, from the metadata node in response to obtaining the write request, an address of a first storage unit and an identifier of a first partition that is in the multiple partitions (“obtaining, by the client, the first memory address in which the start address of the queue of the first storage device is located,” [0004] and “A data block corresponding to the write request is determined based on the storage address in the write request. The client queries, based on the data block, the partition view in the management server or a partition view locally stored by the client, and determines an NVMe storage device that allocates storage space to the data block,” [0025], teaching that the client queries for the partition view from the management server);
determine, according to the identifier of the first partition and the identifiers of the storage devices, the first storage device corresponding to the first storage unit, wherein first partition comprises the first storage device (““A data block corresponding to the write request is determined based on the storage address in the write request. The client queries, based on the data block, the partition view in the management server or a partition view locally stored by the client, and determines an NVMe storage device that allocates storage space to the data block,” [0025] and “For example, as shown in FIG. 3, a first data block is distributed in the partition P2, and the NVMe storage device 1, the NVMe storage device 2, the NVMe storage device 3, and the NVMe storage device 4 form a stripe relationship, that is, a multi-copying relationship. The client queries the partition view, and determines a logical address that is of an NVMe device and to which the storage address included in the write request is mapped. For example, logical addresses that are of the NVMe storage device 1, the NVMe storage device 2, the NVMe storage device 3, and the NVMe storage device 4 and to which the storage address is mapped are L1, L2, L3, and L4, respectively. During specific implementation, the client queries the partition view for a master storage node, for example, the storage node N1, based on the partition view, and the storage node N1 provides L1, L2, L3, and L4 for the client. The client determines the NVMe storage devices that provide the logical addresses, and obtains memory addresses, in a memory, of start addresses of queues (briefly referred to as the start addresses of the queues below) of the NVMe storage device 1, the NVMe storage device 2, the NVMe storage device 3, and the NVMe storage device 4,” [0026]); and
send a target write request to the first storage device, the target write request comprising the address of the first storage unit and the first data (“sending, by the client, a first remote direct memory access write request to the first storage node, where the first remote direct memory access write request includes the first memory address and the first logical address,” [0004], see also “For specific implementation in which the client obtains the memory addresses, in the memory, of the start addresses of the queues of the NVMe storage devices, refer to the following description. The client sends RDMA write requests to the NVMe storage device 1, the NVMe storage device 2, the NVMe storage device 3, and the NVMe storage device 4, respectively. The RDMA write request sent to the NVMe storage device 1 by the client includes the logical address L1 and the start address of the queue of the NVMe storage device 1, and further includes data that is to be written into L1 and that is in a write request received by the client. The RDMA write request sent to the NVMe storage device 2 by the client includes the logical address L2 and the start address of the queue of the NVMe storage device 2, and further includes data that is to be written into L2 and that is in the write request received by the client. The RDMA write request sent to the NVMe storage device 3 by the client includes the logical address L3 and the start address of the queue of the NVMe storage device 3, and further includes data that is to be written into L3 and that is in the write request received by the client. The RDMA write request sent to the NVMe storage device 4 by the client includes the logical address L4 and the start address of the queue of the NVMe storage device 4, and further includes data that is to be written into L4 and that is in the write request received by the client. During specific implementation, the client respectively sends the RDMA write requests to an interface card of the storage node 1 in which the NVMe storage device 1 is located, an interface card of the storage node 2 in which the NVMe storage device 2 is located, an interface card of the storage node 3 in which the NVMe storage device 3 is located, and an interface card of the storage node 4 in which the NVMe storage device 4 is located,” [0026]); and
wherein the first storage device is configured to:
store, in response to receiving the target write request, the first data to the first storage device ([0045] provides a general process for NVMe commands, where a client writes a request into a submission queue for an NVMe device, and then “The NVMe controller obtains the write request from the SQ, and executes the write request,” [0045]); and
Luo fails to teach where the first storage device is configured to:
establish, in response to receiving the target write request, a mapping relationship between the address of the first storage unit and a physical address of the first data in the first storage device.
While Luo does discuss many mapping relationships, none specifically refer to a physical address where data is stored.
Xu’s disclosure is related to providing a distributed storage system, and as such comprises analogous art for the same field of endeavor.
As part of this disclosure, Xu refers to different levels of mapping, such as a global virtual address space to local virtual address space in an individual storage node, see [0045], and in particular refers to how “After receiving the first access request sent by the network device, the first storage node accesses the target file according to the first access request. Specifically, a mapping relationship between the local virtual address space and local physical storage space used to store a file is stored in the first storage node, and the first storage node may determine, according to an address of local virtual address space in a destination address of the access request, an address of local physical storage space used to store the target file,” [0066].
An obvious modification can be identified: incorporating Xu’s disclosure of a mapping relationship between a logical/virtual address space and a physical address for a storage node into Luo’s system. Such a modification reads upon the limitation of the claim.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to incorporate Xu’s disclosure of a logical to physical mapping within a storage node into Luo’s system, as a logical to physical mapping would aid in helping the individual storage node/device to access data based on the actual physical address.
Regarding claim 2, the combination of Luo and Xu teaches the storage system according to claim 1, and Luo teaches the system further comprising the metadata node (Fig. 9 depicts the storage nodes in communication with the management server that was cited in claim 1), wherein the metadata node is configured to manage one or more storage devices in the storage system (the management server manages the partition division and partition view allocation for the storage nodes, see [0024], manages queue information, see [0026], manages the health of the storage nodes, see [0039], monitors statistics for load balancing purposes, see [0044], as examples of managing the storage devices).
Regarding claim 3, the combination of Luo and Xu teaches the storage system according to claim 2, and Luo teaches wherein the storage devices are storage devices managed by the metadata node (see [0024,0026,0039,0044] as cited in the claim 2 rationale for management of the storage devices by the management server), and the metadata node is configured to divide the storage devices, to obtain the multiple partitions, and each of the multiple partitions includes at least one storage device (“A correspondence between a partition and an NVMe storage device, to be specific, a mapping relationship between a partition and an NVMe storage device included in the partition, is also referred to as a partition view. As shown in FIG. 3, for example, a partition includes four NVMe storage devices, and a partition view is "P2-(storage node Ni-NVMe storage device 1)-(storage node N.sub.2-NVMe storage device 2)-(storage node N.sub.3-NVMe storage device 3)-(storage node N.sub.4-NVMe storage device 4)". To be specific, the NVMe storage device 1, the NVMe storage device 2, the NVMe storage device 3, and the NVMe storage device 4 form a stripe relationship. When each storage node includes only one NVMe storage device, the partition view shown in FIG. 3 may also be indicated as P2-storage node N.sub.1-storage node N.sub.2-storage node N.sub.3-storage node N.sub.4. Usually, partition division and partition view allocation are implemented by a management server,” [0024]).
Regarding claim 4, the combination of Luo and Xu teaches the storage system according to claim 1, and Luo further teaches wherein each partition of the multiple partitions is indicated by an identifier, and different partitions are indicated by different identifiers (as seen in Figs. 3 and 4, the partitions have different numbered identifiers).
Regarding claim 5, the combination of Luo and Xu teaches the storage system according to claim 1, and Luo further teaches wherein the client is configured to:
send, to the metadata node in response to obtaining the write request, an allocation request, where the allocation request indicates to the metadata node to allocate a storage unit to the first data (“sending, by the client, a first query request to the management server, where the first queue query request includes the identifier of the first storage node,” [0005]; “During specific implementation, the client may access a partition view stored by the client, or query a partition view in the management server,” [0042]); and
receive, from the metadata node, an allocation response, wherein the allocation response comprises the address of the first storage unit and the identifier of the first partition (“receiving, by the client, a first query request response from the management server, where the first query request response includes the first memory address,” [0005]; “With reference to FIG. 8, the management server receives the query request from the client, queries a mapping relationship recorded in the entries, and sends a query request response to the client. The response includes the start address Addl of the queue of the NVMe storage device 1 in the storage node 1, a start address Addk of a queue of the NVMe storage device 2 in the storage node 2, a start address Addy of a queue of the NVMe storage device 3 in the storage node 3, and a start address Addz of a queue of the NVMe storage device 4 in the storage node 4. In this embodiment of the present invention, a start address, of a queue, included in the query request response that is sent to the client by the management server includes a start address of an SQ, and may further include a start address of a CQ,” [0042]).
Regarding claim 6, the combination of Luo and Xu teaches the storage system according to claim 1, further comprising the metadata node (Fig. 9, management server in communication with the storage nodes);
wherein the client is further configured to:
send a data volume of the first data to the metadata node (“Fetch-and-add (ptr, len value) is an RDMA atomic operation instruction, and is used to obtain an end address of currently allocated storage space and a length of to-be-written data. len value indicates the length of the to-be-written data. In this embodiment of the present invention, the end address of the currently allocated storage space is 10, and len value is 8 bytes,” [0056]; earlier, Luo also discusses how based on the write request size, the client queries the partition view from the management server in order to determine a storage device to allocate storage space, see [0025]); and
wherein the metadata node is configured to:
generate the address of the first storage unit based on the data volume of the first data (“The storage node receives the fetch-and-add (ptr, 8) command, and reserves a storage address 11-18 for the client. ③,” [0056]; earlier, Luo also discusses how based on the write request size, the client queries the partition view from the management server in order to determine a storage device to allocate storage space, teaching that the management server is able to generate a storage device based on a write request size, see [0025]).
Regarding claim 8, the combination of the combination of Luo and Xu teaches the storage system according to claim 1, wherein the address of the first storage unit is an identity (ID) of the first storage unit and is not a hard disk logical block address (LBA) (“In an implementation, the foregoing mapping relationship is stored as entries in a table shown in FIG. 8. In other words, the mapping relationship may be stored by using an entry structure shown in FIG. 8 or another data structure that can reflect a relationship between an identifier and an address. N1, N2, and N3 indicate identifiers of storage nodes. D11 and D12 indicate identifiers of NVMe storage devices in the storage node 1. Addl indicates a start address of a queue of an NVMe storage device whose identifier is D11. The NVMe storage device whose identifier is D11 may have a plurality of queues. Therefore, in an implementation, Addl indicates a start address of an SQ of the NVMe storage device; in another implementation, Addl may alternatively indicate start addresses of queues (a start address of an SQ and a start address of a CQ) of the NVMe storage device. For meanings of other items in the table shown in FIG. 8, refer to the foregoing description. The mapping relationship between the identifier of the storage node and the start address of the queue is used as the entries in the table shown in FIG. 8. In the storage system, each storage node has a unique identifier. The identifier may be a number allocated to the storage node by the management server, or may be hardware information of the storage node, for example, interface card hardware information, or may be address information of the storage node, for example, an Internet Protocol (Internet Protocol, IP) address. The identifier of the NVMe storage device may be hardware information of the NVMe storage device, or may be an internal number in the storage node in which the NVMe storage device is located. For example, the NVMe storage device in the storage node 1 may be identified by D11 or D12, or may be indicated as N1+NVMe device number, for example, N1+1 or N1+2. The management server establishes a mapping relationship between an identifier of a storage node and a start address of a queue, and the client can obtain queue information of an NVMe storage device from the management server, so that the client can directly access the NVMe storage device, and participation of a CPU of the storage node is not needed. Therefore, performance of the NVMe storage device is brought into full play,” [0038]).
Claim 9 is a method claim identical to the functional configuration of the client and storage nodes of claim 1, and as such is rejected according to the same rationale.
Claims 10, 11, 12, 13, and 14 are rejected according to the same rationale of claims 6, 2, 3, 4, and 5, respectively.
Regarding claim 15, the combination of Luo and Xu teaches the method according to claim 9, and Luo further teaches wherein the first storage device and a network interface card are comprised in a storage node (Figs. 1 and 2 depict separate views of storage nodes, where the NVMe devices are shown in Fig. 1 within the storage node, and Fig. 2 depicts a structure including a network interface card, see also [0022]), and wherein sending, by the client, the address of the first storage unit and the first data to the first storage device comprises:
sending, by the client, the address of the first storage unit and the first data to the network interface card of the storage node (“In this embodiment of the present invention, that the client sends the RDMA write request to the storage node 1 is used as an example for description. The client sends the RDMA write request to an interface card of the storage node 1,” [0045]); and
sending, by the network interface card of the storage node, the address of the first storage unit and the first data to the first storage device (“The interface card of the storage node 1 receives the RDMA write request, and sends, to the memory address Addl of the storage node 1, the logical address L1 and data that is to be written into L1 and that is in a write request received by the client,” [0045]).
Regarding claim 17, Luo teaches a computing node, comprising:
a non-transitory memory (Luo provides for a computer readable storage medium and computer program product in [0016,0017], with for example “The memory 202 stores a computer instruction, and the CPU 201 executes a program instruction in the memory 202 to perform a corresponding operation.” [0022]), and
at least one processor coupled to the non-transitory memory, the non-transitory memory storing instructions that, when executed by the at least one processor (Luo provides for a computer readable storage medium and computer program product in [0016,0017], with for example “The memory 202 stores a computer instruction, and the CPU 201 executes a program instruction in the memory 202 to perform a corresponding operation.” [0022]), cause the computing node perform the operations identical to the functional configurations to the client and storage node of claim 1 and rejected according to the same rationale.
Claims 18, 19, 20, and 21 are rejected according to the same rationales of claims 5, 8, 6, and 15 respectively.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Luo in view of Xu and further in view of Liu et al. (US 2019/0235956).
Regarding claim 7, the combination of Luo and Xu teaches the storage system according to claim 1, but fails to teach the storage system further comprising:
a second storage device, configured to:
store recovered first data to a physical address of the second storage device after the first storage device becomes faulty; and
establish a mapping relationship between the address of the first storage unit and the physical address of the second storage device.
While Luo does contemplate situations where a storage device is faulty, see [0037], as well as disclose a striping relationship including the use of parity specific slices, see [0027], Luo does not disclose any recovery of data.
Liu’s disclosure relates to providing a distributed storage system, and as such comprises analogous art in the same field of endeavor.
As part of this disclosure, Liu discloses that typical distributed storage systems provide for the ability to stripe devices with parity blocks, similar to Luo, see [0004,0005] and Fig. 4, where specifically, “When a storage node in the storage node group becomes faulty, a new storage node is added to the storage node group to replace the faulty storage node, and data in the faulty node is recovered at the new storage node,” [0005].
An obvious modification can be identified: incorporating Liu’s disclosure that distributed storage systems recover data to a new storage node when a faulty storage node is identified into Luo’s system. Such a modification reads upon the limitation of the claim, as this new storage node would have the capabilities discussed in the claim 1 rationale with respect to the mapping, see Xu [0006], and Liu providing the context of recovering data for a faulty storage node.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to incorporate Liu’s data recovery method into Luo’s system, as this helps reduce data loss due to faulty hardware.
Claim 16 is rejected according to the same rationale of claim 7.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-19 of U.S. Patent US 12,346,589 contains every element of claims 1-21 of the instant application, as can be shown in the following table, and as such anticipates claims 1-21 of the instant application. “A later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness-type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus). “ ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
Claim 1, instant application
Claim 1, US 12,346,589
A storage system, comprising:
a client; and
a storage node comprising a first storage device;
wherein the client is configured to:
receive, from a metadata node, identifiers of storage devices, wherein each partition of multiple partitions includes at least one of the storage devices;
obtain a write request that carries first data;
obtain, from the metadata node in response to obtaining the write request, an address of a first storage unit and an identifier of a first partition that is in the multiple partitions;
determine, according to the identifier of the first partition and the identifiers of the storage devices, the first storage device corresponding to the first storage unit, wherein first partition comprises the first storage device; and
send a target write request to the first storage device, the target write request comprising the address of the first storage unit and the first data; and
wherein the first storage device is configured to:
store, in response to receiving the target write request, the first data to the first storage device; and
establish, in response to receiving the target write request, a mapping relationship between the address of the first storage unit and a physical address of the first data in the first storage device.
A storage system, comprising:
a client; and
a storage node comprising a first storage device;
wherein the client is configured to:
receive, from a metadata node, identifiers of multiple partitions, and identifiers of storage devices comprised in each of the multiple partitions, wherein the multiple partitions are partitions managed by the metadata node;
obtain a write request, where the write request carries to-be-written data;
receive, from the metadata node, an allocation response, wherein the allocation response comprises an address of a first storage unit and an identifier of a first partition that is corresponding to the first storage unit and that is in the multiple partitions;
determine, according to the identifier of the first partition and the identifiers of storage devices comprised in each of the multiple partitions, the first storage device corresponding to the first storage unit, wherein the first partition comprises the first storage device; and
send a target write request to the first storage device, the target write request comprising the address of the first storage unit and the to-be-written data; and
wherein the first storage device is configured to:
in response to receiving the target write request, store the to-be-written data to the first storage device; and
in response to receiving the target write request, establish a mapping relationship between the address of the first storage unit and a physical address of the to-be-written data in the first storage device…
Claim 2, instant application
Claim 5, US 12,346,589
The storage system according to claim 1, further comprising the metadata node, wherein the metadata node is configured to manage one or more storage devices in the storage system.
The storage system according to claim 1, further comprising a plurality of metadata nodes, each metadata node of the plurality of metadata nodes being configured to manage one or more storage devices in the storage system.
Claim 3, instant application
Claim 6, US 12,346,589
The storage system according to claim 2, wherein the storage devices are storage devices managed by the metadata node, and the metadata node is configured to divide the storage devices, to obtain the multiple partitions, and each of the multiple partitions includes at least one storage device.
The storage system according to claim 1, further comprising:
a first metadata node, configured to divide storage devices managed by the first metadata node, to obtain a plurality of partitions.
Claim 4, instant application
Claim 7, US 12,346,589
The storage system according to claim 1, wherein each partition of the multiple partitions is indicated by an identifier, and different partitions are indicated by different identifiers.
The storage system according to claim 6, wherein each partition of the plurality of partitions is indicated by an identifier, and different partitions are indicated by different identifiers.
Claim 5, instant application
Claim 1, US 12,346,589
The storage system according to claim 1, wherein the client is configured to:
send, to the metadata node in response to obtaining the write request, an allocation request, where the allocation request indicates to the metadata node to allocate a storage unit to the first data; and
receive, from the metadata node, an allocation response, wherein the allocation response comprises the address of the first storage unit and the identifier of the first partition.
…
in response to obtaining the write request, send, to the metadata node, an allocation request, where the allocation request is used to indicate the metadata node to allocate a storage unit to the to-be-written data;
receive, from the metadata node, an allocation response, wherein the allocation response comprises an address of a first storage unit and an identifier of a first partition that is corresponding to the first storage unit and that is in the multiple partitions;
Claim 6, instant application
Claim 2, US 12,346,589
The storage system according to claim 1, further comprising the metadata node;
wherein the client is further configured to:
send a data volume of the first data to the metadata node; and
wherein the metadata node is configured to:
generate the address of the first storage unit based on the data volume of the first data.
The storage system according to claim 1, further comprising:
a metadata node;
wherein the client is further configured to:
send a data volume of the to-be-written data to the metadata node; and
wherein the metadata node is configured to:
generate the address of the first storage unit based on the data volume of the to-be-written data.
Claim 7, instant application
Claim 4, US 12,346,589
The storage system according to claim 1, further comprising:
a second storage device, configured to:
store recovered first data to a physical address of the second storage device after the first storage device becomes faulty; and
establish a mapping relationship between the address of the first storage unit and the physical address of the second storage device.
The storage system according to claim 1, further comprising:
a second storage device, configured to:
store recovered to-be-written data to a physical address of the second storage device after the first storage device becomes faulty; and
establish a mapping relationship between the address of the first storage unit and the physical address of the second storage device.
Claim 8, instant application
Claim 1, US 12,346,589
The storage system according to claim 1, wherein the address of the first storage unit is an identity (ID) of the first storage unit and is not a hard disk logical block address (LBA).
… wherein the address of the first storage unit is an identity (ID) of the first storage unit and is not a hard disk logical block address (LBA).
Claim 9, instant application
Claim 8, US 12,346,589
A method, comprising:
receiving, by a client, from a metadata node, identifiers of storage devices, wherein each partition of multiple partitions includes at least one of the storage devices;
obtaining, by the client, a write request that carries first data;
obtaining, by the client, from the metadata node in response to obtaining the write request, an address of a first storage unit and an identifier of a first partition that is in the multiple partitions;
determining, by the client, according to the identifier of the first partition and the identifiers of the storage devices, a first storage device corresponding to the first storage unit, wherein first partition comprises the first storage device;
sending, by the client, a target write request to the first storage device, wherein the target write request comprises the address of the first storage unit and the first data;
storing, by the first storage device in response to receiving the target write request, the first data to the first storage device; and
establishing, by the first storage device in response to receiving the target write request, a mapping relationship between the address of the first storage unit and a physical address of the first data in the first storage device.
A method, comprising:
receiving, from a metadata node, identifiers of multiple partitions, and identifiers of storage devices comprised in each of the multiple partitions, wherein the multiple partitions are partitions managed by the metadata node;
obtaining a write request, where the write request carries to-be-written data;
receiving, from the metadata node, an allocation response, wherein the allocation response comprises an address of a first storage unit and an identifier of a first partition that is corresponding to the first storage unit and that is in the multiple partitions;
determining, according to the identifier of the first partition and the identifiers of storage devices comprised in each of the multiple partitions, a first storage device corresponding to the first storage unit, wherein the first partition comprises the first storage device, and wherein a storage system comprises a client and a storage node, and the storage node comprises a first storage device;
sending, by the client, a target write request to the first storage device, wherein the target write request comprises the address of the first storage unit and the to-be-written data;
in response to receiving the target write request, storing, by the first storage device, the to-be-written data to the first storage device; and
in response to receiving the target write request, establishing, by the first storage device, a mapping relationship between the address of the first storage unit and a physical address of the to-be-written data in the first storage device…
Claim 10, instant application
Claim 9, US 12,346,589
The method according to claim 9, further comprising:
sending, by the client, a data volume of the first data to the metadata node; and
generating, by the metadata node, the address of the first storage unit based on the data volume of the first data.
The method according to claim 8, wherein the storage system further comprises the metadata node; and wherein the method further comprises:
sending, by the client, a data volume of the to-be-written data to the metadata node; and
wherein the metadata node generates the address of the first storage unit based on the data volume of the to-be-written data.
Claim 11, instant application
Claim 12, US 12,346,589
The method according to claim 9, further comprising:
managing, by the metadata node, one or more storage devices.
The method according to claim 8, wherein the storage system further comprises a plurality of metadata nodes, each metadata node of the plurality of metadata nodes being configured to manage one or more storage devices in the storage system.
Claim 12, instant application
Claim 13, US 12,346,589
The method according to claim 11, further comprising:
dividing, by the metadata node, storage devices managed by the metadata node, to obtain the multiple partitions, each of the multiple partitions includes at least one storage device.
The method according to claim 8, wherein the storage system further comprises a first metadata node, configured to divide storage devices managed by the first metadata node, to obtain a plurality of partitions.
Claim 13, instant application
Claim 14, US 12,346,589
The method according to claim 9, wherein each partition of the multiple partitions is indicated by an identifier, and different partitions are indicated by different identifiers.
The method according to claim 13, wherein each partition of the plurality of partitions is indicated by an identifier, and different partitions are indicated by different identifiers.
Claim 14, instant application
Claim 8, US 12,346,589
The method according to claim 9, wherein obtaining, by the client, from the metadata node, an address of a first storage unit and an identifier of a first partition comprises: sending, by the client, to the metadata node, an allocation request, where the allocation request is used to indicate the metadata node to allocate a storage unit to the first data; and receiving, by the client, from the metadata node, an allocation response, wherein the allocation response comprises the address of the first storage unit and the identifier of the first partition.
in response to obtaining the write request, sending, to the metadata node, an allocation request, where the allocation request is used to indicate the metadata node to allocate a storage unit to the to-be-written data; receiving, from the metadata node, an allocation response, wherein the allocation response comprises an address of a first storage unit and an identifier of a first partition that is corresponding to the first storage unit and that is in the multiple partitions;
Claim 15, instant application
Claim 10, US 12,346,589
The method according to claim 9, wherein the first storage device and a network interface card are comprised in a storage node, and wherein sending, by the client, the address of the first storage unit and the first data to the first storage device comprises:
sending, by the client, the address of the first storage unit and the first data to the network interface card of the storage node; and
sending, by the network interface card of the storage node, the address of the first storage unit and the first data to the first storage device.
The method according to claim 8, wherein sending, by the client, the address of the first storage unit and the to-be-written data to the first storage device comprises:
sending, by the client, the address of the first storage unit and the to-be-written data to a network interface card of the storage node,
wherein the network interface card of the storage node sends the address of the first storage unit and the to-be-written data to the first storage device.
Claim 16, instant application
Claim 11, US 12,346,589
The method according to claim 9, further comprising:
storing, by a second storage device, recovered first data to a physical address of the second storage device after the first storage device is faulty; and
establishing, by the second storage device, a mapping relationship between the address of the first storage unit and the physical address of the second storage device.
The method according to claim 8, further comprising:
storing, by a second storage device of the storage system, recovered to-be-written data to a physical address of the second storage device after the first storage device is faulty; and
establishing, by the second storage device, a mapping relationship between the address of the first storage unit and the physical address of the second storage device.
Claim 17, instant application
Claim 15, US 12,346,589
A computing node, comprising:
a non-transitory memory, and
at least one processor coupled to the non-transitory memory, the non-transitory memory storing instructions that, when executed by the at least one processor, cause the computing node to:
receive, from a metadata node, identifiers of storage devices, wherein each partition of multiple partitions includes at least one of the storage devices;
obtain a write request that carries first data;
obtain, from the metadata node in response to obtaining the write request, an address of a first storage unit and an identifier of a first partition that is in the multiple partitions;
determine, according to the identifier of the first partition and the identifiers of the storage devices, a first storage device corresponding to the first storage unit, wherein first partition comprises the first storage device; and
send a target write request to the first storage device, wherein the target write request comprises the address of the first storage unit and the first data.
A computing node, comprising:
a memory, and
at least one processor coupled to the memory and configured to:
receive, from a metadata node, identifiers of multiple partitions, and identifiers of storage devices comprised in each of the multiple partitions, wherein the multiple partitions are partitions managed by the metadata node;
obtain a write request, where the write request carries to-be-written data;
receive, from the metadata node, an allocation response, wherein the allocation response comprises an address of a first storage unit and an identifier of a first partition that is corresponding to the first storage unit and that is in the multiple partitions;
determine, according to the identifier of the first partition and the identifiers of storage devices comprised in each of the multiple partitions, a first storage device corresponding to the first storage unit, wherein the first partition comprises the first storage device; and
send a target write request to the first storage device, wherein the target write request comprises the address of the first storage unit and the to-be-written data...
Claim 18, instant application
Claim 15, US 12,346,589
The computing node according to claim 17, wherein the instructions are to further cause the computing node to:
send, to the metadata node in response to obtaining the write request, an allocation request, where the allocation request is used to indicate the metadata node to allocate a storage unit to the first data; and
receive, from the metadata node, an allocation response, wherein the allocation response comprises the address of the first storage unit and the identifier of the first partition.
…
in response to obtaining the write request, send, to the metadata node, an allocation request, where the allocation request is used to indicate the metadata node to allocate a storage unit to the to-be-written data;
receive, from the metadata node, an allocation response, wherein the allocation response comprises an address of a first storage unit and an identifier of a first partition that is corresponding to the first storage unit and that is in the multiple partitions;
Claim 19, instant application
Claim 15, US 12,346,589
The computing node according to claim 17, wherein the address of the first storage unit is an identity (ID) of the first storage unit and is not a hard disk logical block address (LBA).
wherein the address of the first storage unit is an identity (ID) of the first storage unit and is not a logical block address (LBA)
Claim 20, instant application
Claim 16, US 12,346,589
The computing node according to claim 17, wherein the instructions are to further cause the computing node to:
send a data volume of the first data to the metadata node, wherein the address of the first storage unit is generated by the metadata node based on the data volume of the first data
The computing node according to claim 15, wherein the at least one processor is further configured to:
send a data volume of the to-be-written data to the metadata node, the metadata node being in a storage system comprising the computing node; and wherein the address of the first storage unit is generated by the metadata node based on the data volume of the to-be-written data.
Claim 21, instant application
Claim 17, US 12,346,589
The computing node according to claim 17, wherein the first storage device and a network interface card are comprised in a storage node, and wherein the instructions are to further cause the computing node to:
send the address of the first storage unit and the first data to the network interface card of the storage node, so that the network interface card of the storage node send the address of the first storage unit and the first data to the first storage device.
The computing node according to claim 15, wherein the at least one processor is further configured to:
send the address of the first storage unit and the to-be-written data to a network interface card of a storage node.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Theimer et al. (US 2015/0134626) discloses dividing up data streams based on device names/identifiers and directed to storage subsystem nodes,
Singh et al. (US 2019/0079674) discloses a distributed storage system,
Bolkhovitin et al. (US 2019/0294339) discloses providing mapping between storage devices and address ranges,
Schmisseur et al. (WO 2016/209546) discloses storage nodes with the ability to manage partitions based on addresses,
Luo et al. (WO 2019/127017) and Luo et al. (WO 2019/127021) appear to be earlier disclosures identical to or substantially similar to the EP disclosure relied upon in this office action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AARON D HO whose telephone number is (469)295-9093. The examiner can normally be reached Mon-Fri 8:00-4:00 CT.
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, Reginald Bragdon can be reached at (571)272-4204. 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.
/A.D.H./Examiner, Art Unit 2139
/REGINALD G BRAGDON/Supervisory Patent Examiner, Art Unit 2139
Prosecution Insights