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 .
Claim Objections
Claims 1, 3-4, 9, 11, 13, and 17 are objected to because of the following informalities:
As per claim 1, “a memory or storage tier” ll 11-12 should be “the memory or storage tier”.
As per claim 3, “an application context, a system context, and a filesystem context, ” ll3-4 should be “the application context, the system context, and the filesystem context”.
As per claim 4, “the Non-volatile Memory Express over Fabric” should be “a Non-volatile Memory Express over Fabric”.
As per claim 9, “receiving, at the remote storage server, and IO storage request” ll4 should be “receiving, at the remote storage server, an IO storage request” “IO storage request” ll4 should be “the IO storage request”.
As per claim 11, see objection on claim 1.
As per claim 13, see objection on claim 4.
As per claim 17, see objection on claim 1.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101. The claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter.
As per claim 1, the claim recites a series of steps, therefore is a process.
The claim recites the limitation of “determining, via execution of the IO classification program, an IO class to be used for the IO storage request”. This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. Thus, the claim recites a mental process.
The limitation of “loading an IO classification program into the system memory . . . forwarding the IO storage request to a device . . . supporting the IO class can be accessed”, amounts to data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g); this limitation is also a mere generic transmission and presentation of collected and analyzed data which is considered to be insignificant extra solution activity (MPEP 2106.05(g). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to the abstract idea.
As discussed above, “loading an IO classification program into the system memory . . . forwarding the IO storage request to a device . . . supporting the IO class can be accessed” amounts to data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g). “implementing a multi-tier memory and storage scheme employing multiple tiers of memory and storage supporting different Input-Output (IO) classes” is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception - see MPEP 2106.05(d) and Berkheimer Memo. See US 2015/0026685. The claim is ineligible.
As per claim 2, see rejection on claim 1. “… IO class is determined …” This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. Thus, the claim recites a mental process.
As per claim 3, see rejection on claim 2. “determining the IO class based on one or more of the application context, the system context, and the filesystem context associated with the IO storage request” This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. Thus, the claim recites a mental process.
“accessing, from at least one of an application, an operating system, and the IO classification program running on the compute platform, one or more of an application context, a system context, and a filesystem context” amounts to data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g); this limitation is also a mere generic transmission and presentation of collected and analyzed data which is considered to be insignificant extra solution activity (MPEP 2106.05(g). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to the abstract idea.
As per claim 4, see rejection on claim 1. “wherein the IO storage request employs the Non-volatile Memory Express over Fabric (NVMeOF) protocol” is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception - see MPEP 2106.05(d) and Berkheimer Memo. See US 2020/0201578. The claim is ineligible.
As per claim 5, see rejection on claim 4. “encapsulating the IO class in an NVMe IO command” is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception - see MPEP 2106.05(d) and Berkheimer Memo. See US 2020/0201578. The claim is ineligible.
As per claim 6, see rejection on claim 1. “wherein the compute platform is running a Linux operating system (OS) including a kernel and wherein the IO classification program is a registered eBPF program in the Linux kernel” is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception - see MPEP 2106.05(d) and Berkheimer Memo. See US 2020/0201578 and Archarya. The claim is ineligible.
As per claim 7, see rejection on claim 1. “downloading the IO classification program from a target in the environment, the target implementing one or more tiers of storage” is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception - see MPEP 2106.05(d) and Berkheimer Memo. See Archarya. The claim is ineligible.
As per claim 8, see rejection on claim 1. “wherein the device to which the IO storage request is forwarded comprises a remote storage server” is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception - see MPEP 2106.05(d) and Berkheimer Memo. See US 2020/0117373. The claim is ineligible.
As per claim 9, see rejection on claim 1. “wherein the remote storage server provides access to a first storage tier associated with a first IO class and a second storage tier associated with a second IO class, further comprising: receiving, at the remote storage server, and IO storage request including the IO class; and storing, via the remote storage server, data associated with the IO storage request in the first storage tier or second storage tier based on the IO class in the IO storage request” is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception - see MPEP 2106.05(d) and Berkheimer Memo. See US 2020/0117373. The claim is ineligible.
As per claim 10, see rejection on claim 1. “wherein the compute platform employs virtualization including one of a virtualization layer, hypervisor, or virtual machine manager (VMM), and wherein the IO classifier program is implemented in the virtualization layer, hypervisor, or VMM” is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception - see MPEP 2106.05(d) and Berkheimer Memo. See Background, Spec The claim is ineligible.
As per claim 11, see rejection on claim 1.
As per claim 12, see rejection on claims 2 and 3.
As per claim 13, see rejection on claims 4 & 5.
As per claim 14, see rejection on claim 6.
As per claim 15, see rejection on claim 11. “a plurality of software components including an initiator, a logical volume driver, and the IO classification program” ” is simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception - see MPEP 2106.05(d) and Berkheimer Memo. See US 2020/0117373 & Li. The claim is ineligible.
As per claim 16, see rejection on claim 10.
As per claim 17, see rejection on claim 1.
As per claim 18, see rejection on claim 1.
As per claim 19, see rejection on claim 6.
As per claim 20, see rejection on claim 10.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 7-8, 11-12, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Sheperek et al (US 2020/0117373) (hereinafter Sheperek) in view of Acharya et al (Acharya, Arup, Xiping Wang, and Charles Wright. "A programmable message classification engine for session initiation protocol (SIP)." Proceedings of the 3rd ACM/IEEE Symposium on Architecture for networking and communications systems. 2007) (hereinafter Acharya).
As per claim 1, Sheperek teaches:
A method, implemented in an environment including a compute platform having system memory, comprising:
implementing a multi-tier memory and storage scheme employing multiple tiers of memory and storage supporting different Input-Output (IO) classes (Sheperek, [0036], [0038]—under BRI, a multi-tier memory and storage scheme can be a scheme that includes low-density storage (e.g., SLC) . . . another type of non-volatile storage, such as high-density storage; different Input-Output (IO) classes can be IO classes require different policies);
for an IO storage request originating from an application running on the compute platform, determining, via execution of a method, an IO class to be used for the IO storage request (Sheperek, [0036], [0038]—under BRI, an IO storage request originating from an application can be an in-progress write operation); and
forwarding the IO storage request to a device implementing a memory (Sheperek, Fig 1, memory element 106, flash channel controller 122, local memory 123, Fig 3 304—under BRI, forwarding can be initiating the write operation; a device can be flash channel controller 122 + local memory 123 + memory element 106; a memory can be memory element 106) or storage tier supporting the IO class or via which a device implementing a memory or storage tier supporting the IO class can be accessed.
Sheperek does not expressly teach:
loading an IO classification program into the system memory;
wherein the method is the IO classification program;
However, Acharya discloses:
loading an IO classification program into the system memory (Acharya, Abstract—under BRI, loading an IO classification program into the system memory exists in order for programmable classification engine to run);
wherein the method is the IO classification program (Acharya, Abstract);
Both Acharya and Sheperek pertain to the art of classifying traffic.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use Acharya’s method to classify requests because it is well-known in the art that requests can have different priorities in a system. A PHOSITA thus would know to use Acharya’s method to handle different priorities.
As per claim 2, Sheperek/Acharya teaches:
The method of claim 1 (see rejection on claim 1), wherein the IO class is determined based on one or more of an application context, a system context, and a filesystem context associated with the IO storage request (Sheperek, [0037]--under BRI, a system context can be low-density storage and high-density storage).
As per claim 3, Sheperek/Acharya teaches:
The method of claim 2, further comprising:
accessing, from at least one of an application, an operating system and the IO classification program running on the compute platform (Acharya, Abstract), one or more of an application context, a system context (Sheperek, [0037]), and a filesystem context; and
determining the IO class based on one or more of the application context, the system context (Sheperek, [0037]), and the filesystem context associated with the IO storage request.
As per claim 7, Sheperek/Acharya teaches:
The method of claim 1 (see rejection on claim 1), further comprising:
downloading the IO classification program from a target in the environment (Archarya, Abstract), the target implementing one or more tiers of storage (Archarya, 5.1 Testbed / Workload Used—under BRI, one or more tiers of storage can be two RAMs in dual Xeon machine) .
As per claim 8, Sheperek/Acharya teaches:
The method of claim 1(see rejection on claim 1), wherein the device to which the IO storage request is forwarded comprises a remote storage server (Sheperek, Fig 1 memory element 106—under BRI, a remote storage server can be memory element 106).
As per claim 11, see rejection on claim 1.
As per claim 12, see rejection on claims 2 and 3.
As per claim 17, see rejection on claim 1.
As per claim 18, see rejection on claim 1.
Claims 4-5, 9, 13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Sheperek/Acharya as applied above, and further in view of Li et al (US 2020/0201578) (hereinafter Li).
As per claim 4, Sheperek/Acharya teaches:
The method of claim 1 (see rejection on claim 1) .
Sheperek/Acharya does not expressly teach:
wherein the IO storage request employs the Non-volatile Memory Express over Fabric (NVMeOF) protocol.
However, Li discloses:
wherein the IO storage request employs the Non-volatile Memory Express over Fabric (NVMeOF) protocol (Li, Background).
Both Li and Sheperek/Acharya pertain to the art of IO transactions.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use Li’s method to classify requests use NVMeOF because it is well-known in the art that NVMeOF provides benefits including microsecond-level latency, massive IOPS, reduced CPU overhead, and improved resource utilization by allowing multiple hosts to access shared, high-speed storage pools.
As per claim 5, Sheperek/Acharya/Li teaches:
The method of claim 4 (see rejection on claim 4), further comprising encapsulating the IO class in an NVMe IO command (Li, Background—under BRI, encapsulating the IO class can be encapsulating cache address).
As per claim 9, Sheperek/Acharya teaches:
The method of claim 1 (See rejection on claim 1), wherein the remote storage server provides access to a first storage tier associated with a first IO class and a second storage tier associated with a second IO class, further comprising:
receiving, at the remote storage server, and IO storage request (Sheperek, [0025]); and
storing, via the remote storage server, data associated with the IO storage request in the first storage tier or second storage tier based on the IO class in the IO storage request (Sheperek, Fig 3 316).
Sheperek/Acharya does not expressly teach:
wherein the IO storage request including the IO class;
However, Li discloses:
wherein the IO storage request including the IO class (Li, Background);
Both Li and Sheperek/Acharya pertain to the art of IO transactions.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use Li’s method to include IO class because it is well-known in the art that IO has different priorities and latencies. A PHOSITA would thus know to use Li’s method to handle these different priorities and latencies.
As per claim 13, see rejection on claims 4 & 5.
As per claim 15, Sheperek/Acharya teaches:
The non-transitory machine-readable medium of claim 11 (See rejection on claim 11), a logical volume driver (Sheperek, Fig 1 flash channel controller 122).
Sheperek/Acharya does not expressly teach:
wherein the instructions comprise a plurality of software components including an initiator and the IO classification program.
However, Li discloses:
wherein the instructions comprise a plurality of software components including an initiator (Li, Abstract—under BRI, initiator can be the source of VoIP, Instant Messaging), and the IO classification program (Li, Abstract) .
Both Li and Sheperek/Acharya pertain to the art of IO transactions.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use Li’s method to use an initiator and IO classification program because it is well-known in the art that IO has different priorities and latencies. A PHOSITA would thus know to use LI’s method to handle these different priorities and latencies.
Claims 6, 14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sheperek/Acharya as applied above, and further in view of Jain et al ( US 2021/0216369 ) (hereinafter Jain)
As per claim 6, Sheperek/Acharya teaches:
The method of claim 1 (see rejection on claim 1), wherein the compute platform is running a Linux operating system (OS) including a kernel (Acharya, Abstract) and wherein the IO classification program is a registered program in the Linux kernel (Acharya, Abstract).
Sheperek/Acharya does not expressly teach:
wherein the program is eBPF;
However, Jain discloses:
wherein the program is eBPF (Jain, [0003]);
Both Jain and Sheperek/Acharya pertain to the art of SW engineering.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use Jain’s method to use eBPF because it is well-known in the art that eBPF offers benefits including enhanced performance, deep observability with low overhead, and robust, kernel-level security, achieved by allowing custom, sandboxed programs to run directly within the Linux kernel without requiring changes to the source code
As per claim 14, see rejection on claim 6.
As per claim 19, see rejection on claim 6.
Claims 10, 16, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sheperek/Acharya as applied above, and further in view of Applicant Admitted Prior Art (Background, Spec) (hereinafter AAPA).
As per claim 10, Sheperek/Acharya teaches:
The method of claim 1 (see rejection on claim 1).
Sheperek/Acharya does not expressly teach:
wherein the compute platform employs virtualization including one of a virtualization layer, hypervisor, or virtual machine manager (VMM), and wherein the IO classifier program is implemented in the virtualization layer, hypervisor, or VMM.
However, AAPA discloses:
wherein the compute platform employs virtualization including one of a virtualization layer, hypervisor, or virtual machine manager (VMM) (AAPA, [0001]), and wherein the IO classifier program is implemented in the virtualization layer, hypervisor, or VMM (AAPA, [0001]).
Both AAPA and Sheperek/Acharya pertain to the art of IO transactions.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to use AAPA’s method to virtualize computing systems because it is well-known in the art that virtualization offers benefits including significant cost savings (hardware, energy, space), improved efficiency & resource utilization, enhanced flexibility & agility (faster provisioning, scaling), better disaster recovery & business continuity, simplified management, increased security (isolation), and greater portability.
As per claim 16, see rejection on claim 10.
As per claim 20, see rejection on claim 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 2023/0229352 teaches a method of classifying memory requests. .
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLIE SUN whose telephone number is (571)270-5100. The examiner can normally be reached 9AM-5PM.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/CHARLIE SUN/Primary Examiner, Art Unit 2198