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 .
Status of Claims
Claims 1-20 are pending. Claims 1, 3, 7, 9, 14, and 16 have been amended as per Applicants' request.
Papers Submitted
It is hereby acknowledged that the following papers have been received and placed of record in the file:
Amended Claims as filed on April 27, 2026
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5, 7-9, 11, 14-16, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Veerla et al. (US 2015/0143164) (hereinafter Veerla) (published May 21, 2014) in view of Pujol et al. (US 2008/0250176) (hereinafter Pujol) (published October 09, 2008), Nehse (US 2008/0120462) (hereinafter Nehse) (published May 22, 2008) and Ashmore (US 2008/0120463) (hereinafter Ashmore) (published May 22, 2008).
Regarding Claims 1, 7, and 14, taking claim 1 as exemplary, Veerla discloses a multipath-plugin-based software Redundant Array of Independent Disks (RAID) data striping system, comprising: a plurality of physical storage devices that are configured to provide a software Redundant Array of Independent Disks (RAID) logical storage system;
“when the logical volume 104 is a Raid Level 1 logical volume, any I/O write request written onto a region of the storage devices 105-1-105-3 is mirrored on the counter part of the Raid Level 1 logical via the storage devices 101-4-101-6” (Veerla [0022])
“The storage controllers 102 are any devices, systems, software, or combinations thereof operable to perform I/O processing to the storage devices 105 of their respective storage nodes 101 and to perform I/O mirroring for the storage nodes 101” (Veerla [0025] the storage controller 102 is a software RAID controller managing storage devices 105)
“The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In one embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.” (Veerla [0041])
a software RAID driver subsystem that is coupled to the plurality of physical storage devices and that is configured to:
“The storage controllers 102 are any devices, systems, software, or combinations thereof operable to perform I/O processing to the storage devices 105 of their respective storage nodes 101 and to perform I/O mirroring for the storage nodes 101” (Veerla [0025] the storage controller 102 is a software RAID controller managing storage devices 105)
“The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In one embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.” (Veerla [0041])
present an active path to a primary controller for the software RAID logical storage system that is provided by a first physical storage device included in the plurality of physical storage devices, and a failover path to a secondary controller for the software RAID logical storage system that is provided by a second physical storage device included in the plurality of physical storage devices;
“FIG. 3 is a block diagram of the clustered storage system 100 implementing I/O mirroring in a persistent reservation configuration. In this persistent reservation embodiment, an example of the I/O processing is presented with the initiator 120-1 transferring an I/O request (1) to the storage controller 102-1 through the communication network 110 for an operation on data residing in the storage volume 104” (Veerla [0032] see fig. 3, the active path connects to controller 102-1 which is connected to storage device 105-1)
“When the storage controller 102-1 fails, as illustrated in FIG. 4, I/O requests to the storage devices 105-1-105-3 cannot be processed. However, as the data on the storage devices 105-4-105-6 is a duplicate of the data on the storage devices 105-1-105-3, the storage controller 102-2 can continue processing I/O requests for the storage volume 104 using the storage devices 105-4-105-6 without corrupting the data” (Veerla [0036] see fig. 4, the failover path connects to controller 102-2 which is connected to storage device 105-4)
But does not explicitly state an operating system kernel subsystem; and a software RAID multipath plugin subsystem that is coupled to the operating system kernel subsystem and the software RAID driver subsystem, wherein the software RAID multipath plugin subsystem is configured to: present, to the operating system kernel subsystem , a software RAID logical controller for the software RAID logical storage system; identify round robin data striping for the software RAID logical storage system; identify a strip size and a respective path to each of the plurality of physical storage devices; configure the round robin data striping based on the strip size; receive, from the operating system kernel subsystem, a primary software RAID data command for the software RAID logical storage system that is directed to the software RAID logical controller; generate, from the primary software RAID data command, respective secondary software RAID data commands for each of the plurality physical storage devices; and transmit, to the software RAID driver subsystem, a first of the respective secondary software RAID data commands according to the round robin data striping and via the active path to the primary controller provided by the first physical storage device, and a second of the respective secondary software RAID data commands according to the round robin data striping and via the failover path to the secondary controller provided by the second physical storage device, to cause the software RAID driver subsystem to forward the first of the respective secondary software RAID data commands to the first physical storage device and the second of the respective secondary software RAID data commands to the second physical storage device.
Veerla and Pujol discloses an operating system kernel subsystem; and
“As illustrated, the storage nodes 101-1 and 101-2 are communicatively coupled to the initiators 120-1 and 120-2 through a communication network 110” (Veerla [0024] initiators represents host computers)
“In use, applications executing on host computer 210, or on one or more client computers coupled to host computer 210, may consume storage resources provided by storage system 250. For example, application I/O requests may be passed from an application 222 executing in the user space 220 of the operating system to the kernel I/O driver stack, and finally through the HBA (Host Bus Adapter) 242 and network 245 to the storage system 250” (Pujol [0027] the initiators of Veerla would be the host computer in Pujol similarly connected to a network to access the storage)
a software RAID multipath plugin subsystem that is coupled to the operating system kernel subsystem and the software RAID driver subsystem, wherein the software RAID multipath plugin subsystem is configured to:
“One example of the storage nodes 101 includes computer network servers that communicate with the initiators 120-1-120-2 through the Internet. The storage nodes 101 can be configured within the same server or within different servers. The storage controllers 102 are any devices, systems, software, or combinations thereof operable to perform I/O processing to the storage devices 105 of their respective storage nodes 101 and to perform I/O mirroring for the storage nodes 101” (Veerla [0025] see fig. 1, the software RAID multipath is the communication network which connects to the initiators and the controllers which form the software RAID driver)
“In use, applications executing on host computer 210, or on one or more client computers coupled to host computer 210, may consume storage resources provided by storage system 250. For example, application I/O requests may be passed from an application 222 executing in the user space 220 of the operating system to the kernel I/O driver stack, and finally through the HBA (Host Bus Adapter) 242 and network 245 to the storage system 250” (Pujol [0027] the host computer with the operating system kernel is connected to the communication network)
present, to the operating system kernel subsystem, a software RAID logical controller for the software RAID logical storage system;
“Each storage node 101 is operable to store and manage data in a storage volume 104 configured from the storage devices 105. In this regard, the storage nodes 101-1 and 101-2 process I/O requests from a variety of initiators 120 to their respective storage devices 105 in the storage volume 104. For example, the storage node 101-1 is operable to process I/O requests via the storage controller 102-1 to the storage volume 104 while the storage node 101-2 is also operable to process I/O requests to the storage volume 104 via the storage controller 102-2” (Veerla [0020] the storage controllers are presented to the initiators to process I/O request to the storage volume)
“In use, applications executing on host computer 210, or on one or more client computers coupled to host computer 210, may consume storage resources provided by storage system 250. For example, application I/O requests may be passed from an application 222 executing in the user space 220 of the operating system to the kernel I/O driver stack, and finally through the HBA (Host Bus Adapter) 242 and network 245 to the storage system 250” (Pujol [0027] the host computer with the operating system kernel is connected to the communication network)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the operating system kernel being part of the host computers as disclosed by Pujol with the system in the Veerla. The motivation for doing so would be for better efficiency by having a central kernel at the OS to mediate the I/O requests from the application rather than having multiple mappings throughout the host computer.
Nehse discloses identify round robin data striping for the software RAID logical storage system;
“A networking technique that is fundamental to the various RAID levels is "striping," a method of concatenating multiple drives into one logical storage unit. Striping involves partitioning each drive's storage space into stripes, which may be as small as one sector (512 bytes) or as large as several megabytes. These stripes are then interleaved in round-robin style, so that the combined space is composed alternately of stripes from each drive” (Nehse [0004])
“SM 228 calculates the number of memory devices 150 in each sub-device group. Based on this value, SM 228 calculates the number of redundancy groups that are required to map the sub-device group for RAID 0 and again for RAID 5. For example, in an eight disk sub-device group, the number of redundancy groups that are required to map clusters for RAID 0 is one (integer power of two=true), and eight redundancy groups are required to map clusters for RAID 5 (integer power of two plus one=false)” (Nehse [0050] the devices are identified to store the data striped in a round robin fashion)
identify a strip size and a respective path to each of the plurality of physical storage devices;
“Each band is further sub-divided into a plurality of RGrps, depending on the type of RAID level defined by the system administrator and the number of devices within a sub-device group 320. RGrp describes the RAID level, stripe size, number of devices, device path used, and location of the data within sub-device group 320a” (Nehse [0036])
configure the round robin data striping based on the strip size;
“Each band is further sub-divided into a plurality of RGrps, depending on the type of RAID level defined by the system administrator and the number of devices within a sub-device group 320. RGrp describes the RAID level, stripe size, number of devices, device path used, and location of the data within sub-device group 320a” (Nehse [0036])
“SM 228 receives a request for a new volume creation, including information about the size of the requested volume, the desired sub-device group, and its RAID level. SM 228 analyzes the sub-device group for bands that are free and bypasses bands that are already allocated to other volumes. SM 228 checks whether there are any free bands left for allocation in the requested sub-device group. If yes, method 500 proceeds to step 550” (Nehse [0053])
“SM 228 allocates to the new volume the first available band that meets the requirements for the requested volume and assigns the requested RAID type to the band. SM 228 continues to scan for free bands, until the entire requested volume size has been satisfied with enough allocated bands from the sub-device groups” (Nehse [0054])
receive, from the operating system kernel subsystem, a primary software RAID data command for the software RAID logical storage system that is directed to the software RAID logical controller;
“In operation, host 110A, for example, generates a read or a write request for a specific volume (e.g., volume 1), to which it has been assigned access rights. The request is sent through communication means 120 to the host ports of RAID controllers 130. The command is stored in local cache in RAID controller 130B, for example, because RAID controller 130B is programmed to respond to any commands that request volume 1 access” (Nehse [0007])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the determining striping information used in RAID and use of round robin to interleave the data as disclosed by Nehse with the system in the combination of Veerla and Pujol. The motivation for doing so would be improve reliability of the storage by having the redundancy of striped RAID storage.
Ashmore and Veerla discloses generate, from the primary software RAID data command, respective secondary software RAID data commands for each of the plurality physical storage devices; and
“The method includes receiving from a host computer a plurality of I/O requests, each specifying user data to be written to the logical disk. The method also includes responsively generating parity data from the user data. The method also includes responsively generating a first plurality of disk commands. Each of the first plurality of disk commands specifies a portion of the user data to be written to one of the physical disks in the redundant array. The method also includes generating a second plurality of disk commands, after generating the parity data. Each of the second plurality of disk commands specifies a portion of the parity data to be written to one of the physical disks in the redundant array” (Ashmore [0017] the disk commands are the secondary software RAID data commands which is generated from the I/O request)
transmit, to the software RAID driver subsystem, a first of the respective secondary software RAID data commands according to the round robin data striping and via the active path to the primary controller provided by the first physical storage device, and a second of the respective secondary software RAID data commands according to the round robin data striping and via the failover path to the secondary controller provided by the second physical storage device, to cause the software RAID driver subsystem to forward the first of the respective secondary software RAID data commands to the first physical storage device and the second of the respective secondary software RAID data commands to the second physical storage device.
“Thus, in the process element 202, the storage node 101-1 is processing first I/O requests to a storage volume 104 via the storage controller 102-1 and, in the process element 203, the storage node 101-2 is processing second I/O requests to the storage volume 104 via the storage controller 102-2” (Veerla [0027] see fig. 1, the commands travel via the active path to controller 102-1 in node 101-1 and via the fallback path to controller 102-2 in node 101-2, the commands are then forwarded to the storage devices)
“The method includes receiving from a host computer a plurality of I/O requests, each specifying user data to be written to the logical disk. The method also includes responsively generating parity data from the user data. The method also includes responsively generating a first plurality of disk commands. Each of the first plurality of disk commands specifies a portion of the user data to be written to one of the physical disks in the redundant array. The method also includes generating a second plurality of disk commands, after generating the parity data. Each of the second plurality of disk commands specifies a portion of the parity data to be written to one of the physical disks in the redundant array” (Ashmore [0017])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the generation of disk commands from the I/O request disclosed by Ashmore with the system in the combination of Veerla, Pujol, and Nehse. The motivation for doing so would be improve efficiency by offloading the generation of disk commands from the processors to the RAID controller.
Regarding Claims 2, 8, and 15, Ashmore further discloses wherein the primary software RAID data command is a primary write command to write data, and wherein each of the respective secondary software RAID data commands is a secondary write command to write a respective subset of the data.
“The method includes receiving from a host computer a plurality of I/O requests, each specifying user data to be written to the logical disk. The method also includes responsively generating parity data from the user data. The method also includes responsively generating a first plurality of disk commands. Each of the first plurality of disk commands specifies a portion of the user data to be written to one of the physical disks in the redundant array. The method also includes generating a second plurality of disk commands, after generating the parity data. Each of the second plurality of disk commands specifies a portion of the parity data to be written to one of the physical disks in the redundant array” (Ashmore [0017])
Regarding Claims 3, 9, and 16, Ashmore further discloses wherein the primary software RAID data command is a primary read command to read data, and wherein each of the respective secondary software RAID data commands is a secondary read command to read a respective subset of the data.
“The method includes receiving from a host computer a plurality of I/O requests, each specifying user data to be read from the logical disk. The method also includes generating a first plurality of disk commands, in response to the receiving. Each of the first plurality of disk commands specifies a portion of the user data to be read from one of the physical disks in the redundant array. The method also includes responsively generating a second plurality of disk commands. Each of the second plurality of disk commands specifies a portion of parity data to be read from one of the physical disks in the redundant array” (Ashmore [0019])
Regarding Claims 5, 11, and 18, Nehse further discloses wherein the identifying the strip size of the plurality of physical storage devices includes either: determining that strip size configuration of the plurality of physical storage devices is set as the strip size; or retrieving, from the software RAID driver subsystem, the strip size and changing a data striping configuration for the software RAID logical storage system to the strip size.
“The type of application environment, I/O or data intensive, determines whether large or small stripes should be used. The choice of stripe size is application dependant and affects the real-time performance of data acquisition and storage in mass storage networks. In data intensive environments and single-user systems which access large records, small stripes (typically one 512-byte sector in length) can be used, so that each record will span across all the drives in the array, each drive storing part of the data from the record” (Nehse [0004])
“Table 2 shows an example of a redundancy group (RGrp) mapping for various numbers (integer power of two only) of devices in a sub-device group for RAID 0 (no parity device is required) for a single band. Each band is further sub-divided into a plurality of RGrps, depending on the type of RAID level defined by the system administrator and the number of devices within a sub-device group 320. RGrp describes the RAID level, stripe size, number of devices, device path used, and location of the data within sub-device group 320a” (Nehse [0036])
Claims 4, 10, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Veerla (published May 21, 2014), Pujol (published October 09, 2008), Nehse (published May 22, 2008), and Ashmore (published May 22, 2008) as applied to claims 1, 7, and 14 above, and further in view of Tatsumi et al. (US 2021/0191623) (hereinafter Tatsumi) (published June 24, 2021).
Regarding Claims 4, 10, and 17, the combination of Veerla, Pujol, Nehse, and Ashmore disclosed the data striping system of claim 1, information handling system of claim 7, and method of claim 14, but does not explicitly state wherein the identifying the round robin data striping for the software RAID logical storage system includes either: determining that the software RAID multipath plugin subsystem is configured to use round robin path selection by default; or changing a path selection configuration for the software RAID multipath plugin subsystem to round robin path selection.
Nehse and Tatsumi discloses wherein the identifying the round robin data striping for the software RAID logical storage system includes either: determining that the software RAID multipath plugin subsystem is configured to use round robin path selection by default; or changing a path selection configuration for the software RAID multipath plugin subsystem to round robin path selection.
“RAID controllers 130 are connected through device ports to a second communication means 140, which is further coupled to a plurality of memory devices 150, including memory device 150A through 150N, where `N` is any integer value and is not representative of any other value `N` described herein” (Nehse [0005])
“At that time, to avoid occurrence of inter-controller data transfer, the I/O-processing program 131200 acquires, from the I/O command management table 132800, the host path number 132830 of a host path through which the I/O has been received, and selects, from the path management table 132400, a drive path number (port number) 132410 of the controller that has received the I/O. In a case where there are a plurality of drive paths, the I/O-processing program 131200 selects a drive path by round robin selection or the like such that there will not be an imbalance of loads on drive paths” (Tatsumi [0095])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the selection of paths using round robin as disclosed by Tatsumi with the system in the combination of Veerla, Pujol, Nehse, and Ashmore. The motivation for doing so would be improve efficiency by use of all the drive paths as disclosed by Tatsumi. “In a case where there are a plurality of drive paths, the I/O-processing program 131200 selects a drive path by round robin selection or the like such that there will not be an imbalance of loads on drive paths” (Tatsumi [0095])
Claims 6, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Veerla (published May 21, 2014), Pujol (published October 09, 2008), Nehse (published May 22, 2008), and Ashmore (published May 22, 2008) as applied to claims 1, 7, and 14 above, and further in view of Henderson (US 2016/0050146) (hereinafter Henderson) (published February 18, 2016).
Regarding Claims 6, 12, and 19, the combination of Veerla, Pujol, Nehse, and Ashmore disclosed the data striping system of claim 1, information handling system of claim 7, and method of claim 14, but does not explicitly state wherein the respective secondary software RAID data commands generated for each of the plurality physical storage devices from the primary software RAID data command are configured such that the respective secondary software RAID data commands provide only stripe-aligned RAID data commands to the software RAID driver subsystem.
Ashmore and Henderson discloses wherein the respective secondary software RAID data commands generated for each of the plurality physical storage devices from the primary software RAID data command are configured such that the respective secondary software RAID data commands provide only stripe-aligned RAID data commands to the software RAID driver subsystem.
“The method includes receiving from a host computer a plurality of I/O requests, each specifying user data to be written to the logical disk. The method also includes responsively generating parity data from the user data. The method also includes responsively generating a first plurality of disk commands. Each of the first plurality of disk commands specifies a portion of the user data to be written to one of the physical disks in the redundant array. The method also includes generating a second plurality of disk commands, after generating the parity data. Each of the second plurality of disk commands specifies a portion of the parity data to be written to one of the physical disks in the redundant array” (Ashmore [0017])
“As previously mentioned file systems including the ext3 and ext4 file systems from Linux are “RAID aware” and will perform stripe aligned accesses. This can be used to advantage in this embodiment” (Henderson [0106] the accesses to the physical disk described in Ashmore would be RAID aware and the disk commands to the disks are stripe aligned)
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the use of ext3 and ext4 file system so that stripe aligned access would be performed on the RAID array as disclosed in Henderson with the system in the combination of Veerla, Pujol, Nehse, and Ashmore. The motivation for doing so would be to maximize I/O performance and to improve integrity of the data by eliminating write penalty and reducing I/O amplification.
Claims 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Veerla (published May 21, 2014), Pujol (published October 09, 2008), Nehse (published May 22, 2008), and Ashmore (published May 22, 2008) as applied to claims 7 and 14 above, and further in view of Tsukamoto et al. (US 2011/0010499) (hereinafter Tsukamoto) (published January 13, 2011).
Regarding Claims 13 and 20, the combination of Veerla, Pujol, Nehse, and Ashmore disclosed information handling system of claim 7 and method of claim 14, but does not explicitly state wherein the software RAID multipath plugin sub-engine is configured to: receive, from the software RAID driver sub-engine, a respective command completion communication for each of the respective secondary software RAID data commands and, in response, generate and transmit a primary software RAID data command completion communication.
Nehse and Tsukamoto discloses wherein the software RAID multipath plugin sub-engine is configured to: receive, from the software RAID driver sub-engine, a respective command completion communication for each of the respective secondary software RAID data commands and, in response, generate and transmit a primary software RAID data command completion communication.
“If volume 1 is a RAID 5 volume and the command is a write request, RAID controller 130B generates new parity, stores the new parity to a parity memory device 150 via communication means 140, sends a "done" signal to host 110A via communication means 120, and writes the new host 110A data through communication means 140 to corresponding memory devices 150” (Nehse [0007])
“Regarding the "write through", upon receipt of a write command from a host, which instructs writing of user data, the RAID apparatus 200 sends back a completion response to the host subsequent to completion of processes of writing user data into the HDD, and upon receipt of a read command from a host, which instructs reading out of user data, the RAID apparatus 200 sends back a completion response to the host subsequent to completion of processes of reading out user data from the HDD” (Tsukamoto [0039])
It would have been obvious before the effective filing date of the invention to one of ordinary skill in the art to combine the returning of a completion to the host subsequent to the completion of the access to the drives as disclosed in Tsukamoto with the system in the combination of Veerla, Pujol, Nehse, and Ashmore. The motivation for doing so would be to improve integrity of the data by making sure that the data is properly stored or retrieved before replying that the access is complete.
Response to Arguments
Claim Objections
Applicant’s arguments, see page 10 of remarks, filed April 27, 2026, with respect to claims 3, 9, and 16 have been fully considered and are persuasive. The objection of claims 3, 9, and 16 has been withdrawn.
Response to Claim Rejections - 35 USC § 112
Applicant’s arguments, see page 10 of remarks, filed April 27, 2026, with respect to claims 3, 9, and 16 have been fully considered and are persuasive. The 112 rejection of claims 3, 9, and 16 has been withdrawn.
Response to Claim Rejections - 35 USC § 103
Applicant’s arguments, see pages 10-17, filed April 27, 2026, with respect to the rejection(s) of claim(s) 1-3, 5, 7-9, 11, 14-16, and 18 under 35 USC § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Veerla et al. (US 2015/0143164), Nehse (US 2008/0120462), and Ashmore (US 2008/0120463). The new reference Veerla discloses the newly added amended limitations with regards to an active path and a failover path.
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIDNEY LI whose telephone number is (571)270-5967. The examiner can normally be reached Monday to Friday 10:00 AM to 6:00 PM.
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, Arpan P Savla can be reached at (571) 272-1077. 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.
/S.L./Examiner, Art Unit 2137
/Arpan P. Savla/Supervisory Patent Examiner, Art Unit 2137
Prosecution Insights