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 .
Examiner Notes
Examiner has not made a 101 rejection regarding the “computer program product” of claim 17 because Applicant’s specification states that a computer readable medium is not a signal. (Applicant’s Specification, [0024], A computer readable storage medium, as that term is used in the present disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through a fiber optic cable, electrical signals).
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Arguments
Applicant’s arguments with respect to the 35 USC § 103 rejections have been fully considered but are not persuasive. Applicant’s argue that the claims are allowable because:
Applicant’s arguments filed April 22, 2026 have been fully considered but are not persuasive. Applicant argues that the claims are allowable because:
“the training data in Khosrowpour is organized around workload behavior and system performance under different configurations, rather than a dataset comprising registered storage profiles paired with corresponding performance data for those storage profiles. In other words, Khosrowpour is workload-centric, whereas the amended claim requires a storage-profile-centric training dataset derived from registered storage and its measured performance” (Applicant’s Remarks, Pgs. 8-9).
Examiner respectfully disagrees. The amended claims require the following:
“wherein the storage profile for the storage is determined using a storage machine learning model trained using training data comprising registered storage profiles and corresponding performance data for the registered storage profiles.”
Khosrowpour teaches utilizing registered profiles and performance data along with a machine learning model that is trained with the storage profile information and performance data (Column 3, Lines 22-25, executing a classifier (e.g., a machine learning algorithm) that gathers data associated with an application and selects a profile to configure resources of the computing device; and Column 4, Lines 56-67, create a classifier using a machine learning algorithm such as, for example, Random Forest, Neural Network, or the like. Combinations of different hardware platforms and different storage configurations are used to execute different types of workloads using different types of profiles and data associated with the workload characteristics is gathered. The data is used to train the classifier to identify which profile (among multiple profiles that were tested) provides the highest performance (e.g., fastest execution time) for a particular workload executing on a particular hardware platform having a particular storage configuration).
Applicant’s remaining arguments are related to newly amended claim language and have been fully addressed in the rejections below.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Litke et al. (US 20220350490) in view of Watson et al. (US 20240134526), Khosrowpour et al. (US 10771580), and Young et al. (US 20240004711 A1).
As per claim 1, Litke teaches the invention substantially as claimed including a computer implemented method for managing storage for an application, the computer implemented method comprising:
receiving, by a number of processor units, a request for a storage for the application ([0023], the processing logic receives a request for a first persistent storage volume claims (PVC) from an application in a first namespace; Examiner Note: Litke’s “processor logic” comprises a number of processor units: [0021], Method 400 may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, a processor, a processing device, a central processing unit (CPU), a system-on-chip (SoC), etc.), software (e.g., instructions running/executing on a processing device), firmware (e.g., microcode), or a combination thereof), wherein application storage requirements for the application is identified in response to receiving the request for storage of the application ([0023], the processing logic receives a request for a first persistent storage volume claims (PVC) from an application in a first namespace, the request including storage requirements of the first PVC; and [0024], the processing logic generates a second PVC in a second namespace in view of the storage requirements of the first PVC....The second namespace may be a temporary namespace generated on the fly when a user or application creates a PVC (e.g., the first PVC) in the user's own namespace. The second PVC may be created within the second namespace with properties that match the storage requirements of the first PVC (e.g., same size, storage class, etc.)); and
returning, by the number of processor units, the storage ([0016], user PVC 222 may include an indication of data source 224 to be used to populate the PVC 222; and [0025], the processing logic determines a type of the data source from the data source reference and instantiates a pod with instructions to populate the physical storage volume using the data source) having a storage profile for use by the application to access the storage ([0017], processing logic to identify a type of data source that the data source 224 includes. For example, the populator controller 212 may determine whether the data source 224 is an http endpoint, a database, a network server, local storage, etc. The populator controller 212 may then instantiate populator pod 214 based on the determined type of the data source 224.. one or more processes of the populator pod 214 for populating the persistent volume 230 may be specific for the determined type of the data source 224), wherein the storage profile ... is identified based on the application storage requirements for the application ([0016], user PVC 222 may include an indication of data source 224 to be used to populate the PVC 222. The indication of the data source 224 may be a database, an http end point, local storage, network or cloud storage, or any other type of persistent storage, memory, etc.; and [0017], populator controller 212 may include processing logic to identify a type of data source that the data source 224 includes. For example, the populator controller 212 may determine whether the data source 224 is an http endpoint, a database, a network server, local storage, etc. The populator controller 212 may then instantiate populator pod 214 based on the determined type of the data source 224).
Litke fails to specifically teach, wherein the storage profile describes the storage for use by the application; and wherein the storage has a number of functions that match functionality requirements from the application storage requirements.
However, Watson teaches, wherein the storage profile describes the storage for use by the application ([0072], To allow initial provisioning of a persistent storage volume, vCSI controller 400 can intelligently choose the type of storage array best suited to an application. In one or more illustrative embodiments, this can be accomplished by utilizing a generic storage class that specifies only class of service attributes that could be interpreted across different array types. By way of example, these class of service attributes may comprise: (i) required volume performance expressed in terms of desired input-output operations per second (TOPS) or host read-write bandwidth; (ii) facilities required for data protection (e.g., replication to a given target array); (iii) features that can be array specific such as deduplication, compression, thin or thick volumes, and the like; (iv) preferred host transport protocol (e.g., NVME/TCP, FC, iSCSI, NFS, SMB/CIFS)), ....and wherein the storage has a number of functions that match functionality requirements from the application storage requirements ([0040], provides generic storage facilities that are selected by the attributes of the storage desired such as, by way of example only, class of service, types of data protection, storage interconnect fabric, and type of storage (e.g., block, file, or object); and [0072], intelligently choose the type of storage array best suited to an application. In one or more illustrative embodiments, this can be accomplished by utilizing a generic storage class that specifies only class of service attributes that could be interpreted across different array types. By way of example, these class of service attributes may comprise: (i) required volume performance expressed in terms of desired input-output operations per second (TOPS) or host read-write bandwidth; (ii) facilities required for data protection (e.g., replication to a given target array); (iii) features that can be array specific such as deduplication, compression, thin or thick volumes, and the like; (iv) preferred host transport protocol (e.g., NVME/TCP, FC, iSCSI, NFS, SMB/CIFS)).
Watson also teaches, returning, by the number of processor units, the storage having the storage profile for use by the application to access the storage ([0034], facilitating the Kubernetes provisioning models that automatically deploy infrastructure (including storage) based on application profiles and storage requirements expressed as code by the application developers; [0072], To allow initial provisioning of a persistent storage volume, vCSI controller 400 can intelligently choose the type of storage array best suited to an application) wherein the storage profile...is identified based on the application storage requirements for the application ([0072], To allow initial provisioning of a persistent storage volume, vCSI controller 400 can intelligently choose the type of storage array best suited to an application. In one or more illustrative embodiments, this can be accomplished by utilizing a generic storage class that specifies only class of service attributes that could be interpreted across different array types; and [0076], uses the storage application requirements, such as performance and redundancy requirements, to make the best selection among available storage types).
Litke and Watson are analogous because they are each related to container provisioning. Litke teaches a method for container provisioning including storage provisioning based on application storage requirements. ([0023], processing logic receives a request for a first persistent storage volume claims (PVC) from an application in a first namespace, the request including storage requirements of the first PVC. The first namespace may be a sandbox (i.e., allocated set of resource) of a container-orchestration system (e.g., Kubernetes™) in which one or more applications may be executed. In one example, the container-orchestration system may provide an application programming interface (API) for a user or application to provide information, such as storage requirements, a data source, etc. for the first PVC. The processing logic may then generate the first PVC in the first namespace with the provided information, a data source, and a namespace transfer request to transfer a persistent storage volume to the first PVC from a different namespace). Watson teaches a method of container provisioning including provisioning a particular storage class that is appropriate for the container. ([0034], An overall goal of our CSI plugins and CSM modules is to make capabilities of storage arrays available to Kubernetes applications, while facilitating the Kubernetes provisioning models that automatically deploy infrastructure (including storage) based on application profiles and storage requirements expressed as code by the application developers; and [0048], allowing intelligent volume placement to choose from storage arrays of different types). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the provisioning method of Litke would be modified with the Watson’s mechanism for storage class selection during container provisioning resulting in a system that provisions containers with appropriate storage. Therefore, it would have been obvious to combine the teachings of Litke and Watson.
The combination of Litke-Watson fails to specifically teach wherein the storage profile for the storage is determined using a storage machine learning model trained using training data comprising registered storage profiles and corresponding performance data for the registered storage profiles, and wherein the registered storage profiles and the corresponding performance data are clustered into storage classes that are used as labels for the training data.
However, Khosrowpour teaches, wherein the storage profile for the storage is determined using a storage machine learning model trained using training data comprising registered storage profiles and corresponding performance data for the registered storage profiles (Column 3, Lines 22-25, executing a classifier (e.g., a machine learning algorithm) that gathers data associated with an application and selects a profile to configure resources of the computing device; and Column 4, Lines 56-67, create a classifier using a machine learning algorithm such as, for example, Random Forest, Neural Network, or the like. Combinations of different hardware platforms and different storage configurations are used to execute different types of workloads using different types of profiles and data associated with the workload characteristics is gathered. The data is used to train the classifier to identify which profile (among multiple profiles that were tested) provides the highest performance (e.g., fastest execution time) for a particular workload executing on a particular hardware platform having a particular storage configuration).
The combination of Litke-Watson and Khosrowpour are analogous because they are each related resource provisioning. Litke teaches a method for container provisioning including storage provisioning based on application storage requirements. Watson teaches a method of container provisioning including provisioning a particular storage class that is appropriate for the container. Khosrowpour teaches storage allocation including using machine learning models to select a storage profile. (Abstract, After gathering the data, a classifier may analyze the data and determine a particular workload type from a predefined set of workload types associated with the selected application. The computing device may select a particular profile from a plurality of predefined profiles based at least in part on the particular workload type, and modify, based on the particular profile, a plurality of parameters to create a plurality of modified parameters. The modified parameters may reduce an execution time of performing the operations to the input/output stack; and Column 2, Lines 62-67, data is used to train the classifier to identify which profile (among multiple profiles that were tested) provides the highest performance (e.g., fastest execution time) for a particular workload executing on a particular hardware platform having a particular storage configuration). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the provisioning methods of the combination of Litke-Watson would be modified with the Khosrowpour’s predictive storage allocation mechanism resulting in a system that provisions storage in accordance with storage profiles determined by applying machine learning models. Therefore, it would have been obvious to combine the teachings of the combination of Litke-Watson and Khosrowpour.
The combination of Litke-Watson and Khosrowpour fails to specifically teach, wherein the registered storage profiles and the corresponding performance data are clustered into storage classes that are used as labels for the training data.
However, Young teaches, wherein the registered storage profiles and the corresponding performance data are clustered into storage classes that are used as labels for the training data ([0005], for each resource class, the resource utilization system may determine resource usage metrics for a past month, or another past time period; [0049], The resource class data may be label data for data within field 503 and field 506. That is, given training utilization data in field 503 and corresponding periodic training threshold data in field 506, the correct output for a machine learning model may be resource class data in field 509).
The combination of Litke-Watson-Khosrowpour and Young are analogous because they are each related resource provisioning. Litke teaches a method for container provisioning including storage provisioning based on application storage requirements. Watson teaches a method of container provisioning including provisioning a particular storage class that is appropriate for the container. Khosrowpour teaches storage allocation including using machine learning models to select a storage profile. Young teaches a method of resource allocation using machine learning based on resource classes that include labels. ([0045], The machine learning model may have been trained using training utilization data, periodic training threshold data and labelled resource class data (e.g., labelled with oversubscribed resource classes and corresponding supplemental resource classes). Machine learning model 402 may take input 404 (e.g., utilization data and periodic threshold data described above) and may output supplemental resource classes 406 for each oversubscribed class; and [0049], the resource class data may be label data for data within field 503 and field 506. That is, given training utilization data in field 503 and corresponding periodic training threshold data in field 506, the correct output for a machine learning model may be resource class data in field 509). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention that based on the combination, the provisioning methods of the combination of Litke-Watson- Khosrowpour would be modified with the Young’s predictive storage allocation mechanism that utilizes resource class labels resulting in a system that provisions storage in accordance with storage profiles determined by applying machine learning models. Therefore, it would have been obvious to combine the teachings of the combination of Litke-Watson-Khosrowpour and Young.
As per claim 2, Watson teaches, further comprising:
creating, by the number of processor units, a new storage meeting the application storage requirements in response to an absence of the storage profile meeting the application storage requirements ([0074], a class of service change is desired, it can be handled in a similar manner to volume migration, by updating the storage class with different class of service parameters in the aspirational state 410, and leaving a blank storage system selection in the storage class so that the system would select a new appropriate storage system; and [0075], vCSI controller 400 can be configured to dynamically enable or disable replication. In such a use case, a new storage class name is supplied that matches aspirational state 410, either adding replication parameters, or removing existing replication parameters); and
creating, by the number of processor units, a new storage profile meeting the application storage requirements in response to the absence of the storage profile meeting the application storage requirements ([0075], vCSI controller 400 can be configured to dynamically enable or disable replication. In such a use case, a new storage class name is supplied that matches aspirational state 410, either adding replication parameters, or removing existing replication parameters).
As per claim 3, Litke teaches, wherein receiving, by the number of processor units, the request for the storage for the application comprises:
receiving, by the number of processor units, the request from an application deployment process that deploys the application in a container in a container orchestration environment ([0002], Container-orchestration system may provide an image-based deployment module for creating containers; and [0023], the container-orchestration system may provide an application programming interface (API) for a user or application to provide information, such as storage requirements, a data source, etc. for the first PVC).
As per claim 4, Litke teaches, wherein the request is a persistent volume claim ([0023], the processing logic receives a request for a first persistent storage volume claims (PVC) from an application in a first namespace) and wherein the application is used in a container orchestration environment ([0023], the container-orchestration system may provide an application programming interface (API) for a user or application to provide information, such as storage requirements, a data source, etc. for the first PVC).
Litke fails to specifically teach, wherein returning, by the number of processor units, the storage having the storage profile for use by the application to access the storage comprises: returning, by the number of processor units, a modified persistent volume claim with a recommended storage class for the storage having the storage profile.
However, Watson teaches, wherein returning, by the number of processor units, the storage having the storage profile for use by the application to access the storage comprises:
returning, by the number of processor units, a modified persistent volume claim with a recommended storage class for the storage having the storage profile ([0038], reconfiguration requires a restart of the pods within the application to reference new persistent volume claims (PVCs) and PVs. PVCs are storage requests that enable developers to dynamically request storage resources without being aware of the implementation of underlying storage devices; [0043], the virtual container storage interface driver, according to one or more illustrative embodiments, is configured to isolate pods and persistent volume claims (PVCs) from the actual storage used for them. In one or more illustrative embodiments, this is accomplished by using a generic storage class (SC) and persistent volume (PV) that can represent any driver. The volume handle in the persistent volume of the virtual container storage interface driver is a globally unique identifier (GUID), which can only be interpreted by the virtual container storage interface driver. Once a volume placement algorithm has been completed (that can select from all of the available drivers), storage can be provisioned by a specific CSI driver and array; and [0076], application developers do not need to consider the specific capabilities or limitations of each type of storage array. Instead, they delegate the choice of storage array type, and characteristics to an intelligent agent (i.e., vCSI controller 400) that uses the storage application requirements, such as performance and redundancy requirements, to make the best selection among available storage types).
The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 5, Litke teaches, wherein the storage is a physical storage connected to the persistent volume ([0018], the namespace transfer controller 242 may provide the user PVC 222 with a storage pointer of the persistent volume 230 to allow the application access to the persistent volume 230 via the user PVC 222) and wherein the application uses the persistent volume for the storage class to access the storage ([0018], once the transfer of the persistent volume 230 to the user PVC 222 is complete, the volume population controller may update a status of the user PVC 222 and the application from a pending state to an active state. The container-orchestration system 240 may then schedule the application to be executed).
As per claim 6, Watson teaches, wherein identification of the storage profile comprises:
predicting, by the number of processor units, a storage class using the application storage requirements in the request ([0076], application developers do not need to consider the specific capabilities or limitations of each type of storage array. Instead, they delegate the choice of storage array type, and characteristics to an intelligent agent (i.e., vCSI controller 400) that uses the storage application requirements, such as performance and redundancy requirements, to make the best selection among available storage types); and
selecting, by the number of processor units, the storage profile from the storage class meeting the application storage requirements the storage machine learning model trained to predictor model ([0076], application developers do not need to consider the specific capabilities or limitations of each type of storage array. Instead, they delegate the choice of storage array type, and characteristics to an intelligent agent (i.e., vCSI controller 400) that uses the storage application requirements, such as performance and redundancy requirements, to make the best selection among available storage types).
The combination of Litke-Watson fails to specifically teach, predicting, by the number of processor units, a storage class using… a storage solution predictor model trained to predict storage classes using the application storage requirements.
However, Khosrowpour teaches, predicting, by the number of processor units, a storage class (Column 2, Lines 60-65, the operations may include performing an analysis of the data and determining, by a classifier and based at least in part on the analysis, a particular workload type from a predefined set of workload types that is associated with the selected application) using… the storage machine learning model trained to predict storage classes using the application storage requirements (Column 2, Line 57-Column 3, Line 3, operations may include gathering, over a predetermined interval of time, data associated with the selected application that is performing the operations to the input/output stack. After gathering the data, the operations may include performing an analysis of the data and determining, by a classifier and based at least in part on the analysis, a particular workload type from a predefined set of workload types that is associated with the selected application. The classifier may be trained using multiple hardware platforms, multiple storage configurations, multiple workloads, and the predefined plurality of profiles to classify a workload based on input/output operations performed by a particular application and to identify a profile to increase performance of the input/output operations).
The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 7, Khosrowpour teaches, further comprising:
training, by the number of processor units, the storage solution predictor model using storage profiles and performance data for a plurality of storage (Column 2, Line 65-Column 3, Line 3, classifier may be trained using multiple hardware platforms, multiple storage configurations, multiple workloads, and the predefined plurality of profiles to classify a workload based on input/output operations performed by a particular application and to identify a profile to increase performance of the input/output operations; Column 4, lines 56-67, system and techniques create a classifier using a machine learning algorithm such as, for example, Random Forest, Neural Network, or the like. Combinations of different hardware platforms and different storage configurations are used to execute different types of workloads using different types of profiles and data associated with the workload characteristics is gathered. The data is used to train the classifier to identify which profile (among multiple profiles that were tested) provides the highest performance (e.g., fastest execution time) for a particular workload executing on a particular hardware platform having a particular storage configuration).
As per claim 8, Litke teaches, wherein the application storage requirements comprise storage requirements ([0020], The PVC request 313 may include PVC storage requirements 324 that the first PVC 320 is to satisfy), [and] function requirements ([0020], The PVC request 313 may include PVC storage requirements 324 that the first PVC 320 is to satisfy).
Litke fails to specifically teach, wherein the application storage requirements comprise… performance requirements.
However, Watson teaches, wherein the application storage requirements comprise … performance requirements ([0076], they delegate the choice of storage array type, and characteristics to an intelligent agent (i.e., vCSI controller 400) that uses the storage application requirements, such as performance and redundancy requirements, to make the best selection among available storage types).
The same motivation used in the rejection of claim 1 is appliable to the instant claim.
As per claim 9, this is the “system claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 10, this claim is similar to claim 2 and is rejected for the same reasons.
As per claim 11, this claim is similar to claim 3 and is rejected for the same reasons.
As per claim 12, this claim is similar to claim 4 and is rejected for the same reasons.
As per claim 13, this claim is similar to claim 5 and is rejected for the same reasons.
As per claim 14, this claim is similar to claim 6 and is rejected for the same reasons. The same motivation used in the rejection of claim 6 is applicable to the instant claim.
As per claim 15, this claim is similar to claim 7 and is rejected for the same reasons.
As per claim 16, this claim is similar to claim 8 and is rejected for the same reasons.
As per claim 17, this is the “computer program product claim” corresponding to claim 1 and is rejected for the same reasons. The same motivation used in the rejection of claim 1 is applicable to the instant claim.
As per claim 18, this claim is similar to claim 2 and is rejected for the same reasons.
As per claim 19, this claim is similar to claim 3 and is rejected for the same reasons.
As per claim 20, this claim is similar to claim 4 and is rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure and is as follows:
Selegean et al. (US 20220058100) -Teaches resource allocation based on storage profiles which are determined using machine learning models: [0028], storage parameters and/or properties included in the storage profile 118 (e.g., schedules of resource allocation, resource provisioning, and/or compression/decompression) may be determined using a method of machine learning or artificial intelligence. For example, the storage profile 118 may be determined or updated based at least in part on the monitored usage of the stored data 128, 130; and [0033], DSMS 112 may determine characteristics of the infrastructure associated with the system 104a,b and/or application 110a,b (e.g., the processing, memory, and network infrastructure included in the system 104a,b or allocated to the application 110a,b) and use these characteristics to determine the initial storage profile 118. For example, the initial storage profile 118 may be determined based on an anticipated file size, data transfer rate, and/or downstream use of the data 106a,b received from the new data source 102a,b. For example, the storage profile 118 may include an amount of storage space anticipated to be needed to store the data 106a,b provided by the new data source 102a,b); and
Khan et al. (US 11068296)- Teaches storage allocation using storage profiles: Column 2, Lines 64-67, a storage management component providing data for defining a data storage profile of characteristics of data storage for the infrastructure, the profiles collectively defining an application profile for the software application; Column 3, Lines 8-16, one or more data storage profiles, so as to classify a profile for which optimization will provide improved application performance; training the classifier to generate a set of third classifications using training data sets based on each of: one or more application profiles; ...and one or more data storage profiles, so as to classify a profile for which additional infrastructure resource is required to provide improved application performance.
Applicant's amendment necessitated the new grounds 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 MELISSA A HEADLY whose telephone number is (571)272-1972. The examiner can normally be reached Monday- Friday 9-5:30pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/MELISSA A. HEADLY/
Examiner Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights