The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1, 11, and 19 are independent claims and are amended.
Claim 9 is canceled.
Claims 1-8, and 10-20 are pending in this application.
This Action has been made FINAL.
Continuity
The present application has a provisional application 63/385,519 filed on 11/30/2022.
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, 11, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Dageville et al., US Pub. No. 2021/0064503 A1 (hereinafter as “Dageville”) in view of Durand et. al. Patent No. 12,184,504 (hereinafter as “Durand”), and further in view of Cheru et al., US Pub. No. 2020/0159706 A1 (hereinafter as “Cheru”).
Regarding claim 1, Dageville teaches: a system comprising:
at least one hardware processor (Fig. 15, element 1502 – Processor(s)); and
a memory storing instructions that cause the at least one hardware processor to perform operations (Fig. 15, elements 1504 – Memory Device(s)) comprising:
receiving a transaction, the transaction associated with an account (Fig. 12, element 1202, receiving a query directed to database data from a client Account; and par. [0007] discloses a list of all sale transactions in database; and pars. [0043] and [0045] “a query request received from a client, a request to generate a materialized view, a request to calculate an aggregation, and so forth.”, and par. [0097] “an individual client account associated with a set of data may send all data retrieval and data storage requests through a single virtual warehouse and/or to a certain subset of the databases 506a-506n.” teaches the retrieval transaction inherited the reading set of data stored in warehouse);
generating a tag to associate the transaction with a capacity group corresponding to the account (pars. [0041] teaches the capacity group (e.g., “each micro-partition may contain between 50 MB and 500 MB of uncompressed data (note that the actual size in storage may be smaller because data may be stored compressed). Groups of rows in tables may be mapped into individual micro-partitions organized in a columnar fashion”, [0043], wherein the tasks for execution is also interpreted as the transaction, [0044-45] e.g., “internal” tasks and “external” tasks for a client account is interpreted as tag, [0077] “authentication of keys used during authentication and authorization tasks”; and [0090 and 97] disclose the client accounts; and pars. [0090, 95] teaches the capacity group, e.g., “a larger cache capacity”, and “…new processing capacity for new users…”);
generating a request to determine a read version of the transaction, the request including the tag (pars. [0029] “Databases may include one or more tables that include or reference data that can be read, modified, or deleted using queries.”, [0049] teaches “read” in the query transaction; and pars. [0097] as explained above to “retrieval set of data” implies the reading version, and [0114] “The unique identification number enables the requesting user and/or client account to access and read the query and the query results”); and
sending, to a database interface provided by a distributed database, the request to determine the read version of the transaction (Fig. 5 is shown the distributed database, par. [0079] “sends received jobs to the appropriate services or systems for compilation, optimization, and dispatch to the execution platform 116”, par. [0097] teaches the distributed database, e.g., “each virtual warehouse 504a-504n can communicate with all databases 506a-506n. In some embodiments, each virtual warehouse 504a-504n is configured to communicate with a subset of all databases 506a-506n. In such an arrangement, an individual client account associated with a set of data may send all data retrieval and data storage requests through a single virtual warehouse and/or to a certain subset of the databases 506a-506n.”, par. [0114] teaches the read query version, par. [0128] teaches the “Interface(s) 1506”)
Dageville teaches assigned execution cache resources if the tasks=transactions (see Applicant’s Specification at paragraph [0038], e.g., “… the compute service manager 108 may divide the job into multiple discrete tasks (or transactions as discussed further herein) and may determine what data is needed to execute each of the multiple discrete tasks…”) performed by the execution node require a larger cache capacity (Dageville: see par. [0090]), the additional of new processing capacity for new users without impacting the performance observed by the existing users (Dageville: par. [0095]). However, Dageville does not explicitly teach that “the capacity group providing intra-account workload isolation and comprising a set of users from a single account for which a quota is configured and enforced for Online Transaction Processing (OLTP) database transactions from the set of users within the account to manage utilization of resources from a distributed database data cluster;” and “the quota being enforced based on tracking a total load of the capacity group across a set of storage servers of the distributed database data cluster.”
In the same field of endeavor (i.e., data processing), Durand teaches: the capacity group providing intra-account workload isolation (col. 12, lines 35-45: e.g., “organization 304 represented in FIG. 3 includes seven accounts 302 that are organized into four organizational units (OUs) 308” which is interpreted as the capacity group, and “batch/transactional workloads/accounts”; col. 13, lines 30-31, e.g., “transactional workload”; and col. 15, lines 4-10: e.g., “isolated set of account”) and comprising a set of users from a single account (Fig. 3 is shown set of user in each of organizational unit in one single Organization 304; and col. 16, line 48 “a single provider network account”) for which a quota is configured and enforced for Online Transaction Processing (OLTP) database transactions from the set of users within the account (Fig. 3 is also set of accounts and/or set of users; col. 2, lines 58-63: “Such business teams may also benefit from explicit security boundaries and mechanisms to have direct control and visibility of their service limits and any corresponding throttling (service quotas, API limits) of those, as well as a complete billing separation to directly map costs to underlying projects.”; col. 16, line 34 “the service quotas allowed for those specific jobs”; and col. 17, lines 3-9: e.g., “As an online transaction processing (OLTP) system, it is used to build customer transaction application programs. In another example, IBM Information Management System (IMS) is a hierarchical database management software system for online transaction processing (OLTP) and online batch processing.”) to manage utilization of resources from a distributed database data cluster (col. 18, lines 53-55: “Then, the graph may be provided as input to a graph cluster analysis algorithm to isolate groups of resources that are authorized for a given group of users.“).
Accordingly, it would have been obvious to one of ordinary skill in the data processing art before the effective filing date of the claimed invention to combine the teachings of the cited references because the teachings of Durand would have provided Dageville with the above indicated limitation for allowing a skill artisan in motivation to perform the capacity group of entities/tenants corresponding to the account in the reservation zone(s) to manage utilization of resources (Durand: Figs. 1-3; and pars. [0008-9], [0032, 42, and 58]).
Dageville and Durand do not explicitly teach the amended limitation: “the quota being enforced based on tracking a total load of the capacity group across a set of storage servers of the distributed database data cluster.” (*** Examiner’ note: this amended limitation is shown in Applicant’s Figure 4B, element 486, and Figure 8; and instance Specification, paragraph [0090-101])
In the same field of endeavor (i.e., data processing), Cheru teaches: “the quota being enforced based on tracking a total load of the capacity group across a set of storage servers of the distributed database data cluster” (Fig. 5, element 522-Account Identifiers, and element 528-Quota Assignment; pars. [0005], and [0007] “Various aspects for quota enforcement, particularly, object storage systems and methods with control entity quota usage monitoring are described”; par. [0011]; and par. [0014] “hardware and/or software with functionality to improve data object access control for enforcing quota limits, such as by monitoring quota usage for various control entities associated with object data access requests”, par. [0031] “several storage nodes 30 can be grouped together” (see in Fig. 1 and par. [0035] “According to the exemplary embodiment of FIG. 1 and in the event that storage nodes 30.2-30.40 are identical to storage node 30.1 and each comprise a storage capacity of 36 TB, the distributed storage system 1 would then have a total storage capacity of 1440 TB, and wherein the “different data centers” are also embedded the set of storage servers in different regions; and pars. [0052] “…Quota assignments 528 may include a maximum usage value for an aggregate object usage value for all objects associated with that control entity. For example, a maximum storage capacity usage quota value may be set of an account identifier that means the aggregate storage capacity usage of all data objects associated with that account may not exceed the quota value…”, [0053] “quota assignments 528 for each account may include a storage capacity quota, a number of objects quota, a number of operations quota, and/or other object usage quotas…”, and further in [0057-59, 66, 87, and 92], wherein the read and/or write/storage operations are implemented workload)
Accordingly, it would have been obvious to one of ordinary skill in the data processing art before the effective filing date of the claimed invention to combine the teachings of the cited references because the teachings of Cheru would have provided Dageville and Durand with the above indicated amended limitation for allowing a skill artisan in motivation to use the quota enforcement for tracking a total load of the capacity group across a set of storage servers in distributed database systems (Cheru: Figs. 7-8; and pars. [0005-7], [0011, 14, 31, 35, 42] and [0057-59, 66, 87, and 92]).
Claims 11 and 19 are also rejected in the same analysis of above claim 1; and therefore, the claims are rejected on that basis.
Claims 2-8, 10, 12-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Dageville, Durand, and Cheru, and further in view of Yu et al., US Pub. No. 2017/0272475 A1 (hereinafter as “Yu”).
Regarding claim 2, the claim is rejected by the same reasons set forth above to claim 1. Furthermore, Dageville, Durand, and Cheru, in combination, teach: wherein the operations further comprise:
receiving, by the database interface (Durand: col. 17, lines 3-9: e.g., “a hierarchical database management software system for online transaction processing (OLTP) and online batch processing.” and lines 63-67: “a security manager database 512 that stores a set of user, group, and profile information. In some embodiments, the database 512 is accessible through the system interface 506 to all subsystems in the operating system (e.g., z/OS) environment.” which is inherited the database interface), the request to determine the read version of the transaction (Dageville: pars. [0029] “Databases may include one or more tables that include or reference data that can be read, modified, or deleted using queries.”, [0049] teaches “read” to retry the query transaction; and par. [0114] “The unique identification number enables the requesting user and/or client account to access and read the query and the query results”; and Cheru: teaches the read version of the transaction in pars. [0054, 75-77, and 90]);
determining, based on the request, that the transaction is associated with the tag included in the request (Dageville: pars. [0043], wherein the tasks for execution, [0044-45] e.g., “internal” tasks and “external” tasks for a client account, and [0077] “authentication of keys used during authentication and authorization tasks”; and Cheru: see par. [0044] e.g., “(…metadata tags)”, and par. [0076] “Object storage configurations may also define what metadata is collected and stored, as well as whether it is stored in a metadata database, such as object metadata 562 in metadata store 560, in object metadata tags stored in the data objects, and/or a combination thereof”);
generating a sequence number for the request (Dageville: Fig. 7 via query queue log 704, and par. [0067] “One or more jobs may be stored in the queue 204 in an order of receipt and/or an order of priority, and each of those one or more jobs may be communicated to the compute service manager 102 to be scheduled and executed”, wherein the technique of “an order of receipt and/or an order of priority” equals to the sequence number);
placing the request in a queue associated with the tag based on the sequence number (Dageville: again Fig. 7, element 704 – Query Queue; and pars. [0043] e.g., “the resource manager 802 transfer the query by placing the query in the queue of the compute service manager 102.”, [0067] “One or more jobs may be stored in the queue 204 in an order of receipt and/or an order of priority, and each of those one or more jobs may be communicated to the compute service manager 102 to be scheduled and executed”, wherein the technique of “an order of receipt and/or an order of priority” equals to the sequence number, [0106] teaches the “external” and “internal” tasks in query which is interpreted as tag), the queue including a set of requests to determine a particular read version of a particular transaction (Dageville: par. [0075] “data processing platform 200 processes multiple jobs received from the queue 204”; and par. [0098] “the queue 204 sends data retrieval, data storage, and data processing requests to the virtual warehouse manager 502,…” wherein the “data retrieval” algorithm implies to read version; and Cheru: teaches the read version of the transaction in pars. [0054, 75-77, and 90]).
Dageville teaches placing the request in queue in priority order/sequence order (Fig. 7, element 704 – Query Queue, and par. [0067] “One or more jobs may be stored in the queue 204 in an order of receipt and/or an order of priority, and each of those one or more jobs may be communicated to the compute service manager 102 to be scheduled and executed”, wherein the technique of “an order of receipt and/or an order of priority” equals to the sequence number). Cheru further teaches the metadata tags and bucket (pars. [0044, and 76], and [0080]), and filtering the requests based on policy (see par. [0075]). Durand teaches “throttling” relates to “quotas” (col. 2, lines 60-61).
However, Dageville, Durand, and Cheru do not explicitly teach the request should be “throttled based on information related to a quota for the tag stored in a distributed database key store.”
In the same field of endeavor (i.e., data processing), Yu teaches the request should be “throttled based on information related to a quota for the tag stored in a distributed database key store” (see Figs. 1-2 for throttling based on information related a quota for such acceptance or rejection; Fig. 4B as shown the tag at columns in table element 452 as key store; Fig. 5, element 506 and elements 522-530; par. [0035] e.g., “quotas or quota limits 124 (e.g., quotas 124a) for some or all clients from whom the gateway server may receive requests for controlled resources 130…”; and par. [0036] “…if a quota is applied to limit the number of queries or requests that may be submitted to a controlled resource 130 per unit of time (e.g., one second, multiple seconds), gateway server 122a will update quota usage store 126a every time a new call is approved and sent to the resource, for or on behalf of a client that has an associated quota, and will start rejecting additional calls (or will throttle them) if and when the threshold is met during a current time period. In this example, the gateway server can determine (from its quota usage store) whether the requesting client has already met or exceeded its quota, or whether it would do so if the request was approved, and can enforce the corresponding quota immediately”).
Accordingly, it would have been obvious to one of ordinary skill in the data processing art before the effective filing date of the claimed invention to combine the teachings of the cited references because the teachings of Yu would have provided Dageville, Durand, and Cheru with the above indicated limitation for allowing a skill artisan in motivation to perform the controlling resources with the throttling/restricting/filtering/limiting request for enforcing resource quotas (Yu: Abstract, pars. [0016-18, and 35-36]).
Regarding claim 5, Dageville, Durand, Cheru, and Yu, in combination, teach: wherein the operations further comprise:
throttling the request in the queue by forgoing processing of the request in the queue and keeping the request in the queue (Dageville: see again in Fig. 7, element 704 – Query Queue, wherein the requests/queries place in queue in priority order sequentially, par.[0067] for keeping the request for tasks in queue; and see Yu: Fig. 2 and par. [0035-36] teaches the throttling the request by forgoing processing that meets the quota of resource).
Regarding claim 6, Dageville, Durand, Cheru, and Yu, in combination, teach: wherein the operations further comprise:
determining a first global quota for a first account; (Dageville: pars. [0049] and [0106] “client account”; and see Yu: at pars. [0035] and [0036] for quota sets for limiting resource rate/capacity, and par. [0053] in different client associated with account)
determining that the first account is consuming a first amount of computing resources on a first storage server that is less than the first global quota; (Dageville: see pars. [0034] and [0036-37] for computing resources consuming to client account(s); and see Yu: e.g., amount of storage space (e.g., GB, MB) of bandwidth, see par. [0006] “the quota is exceeded or to once again accept requests when the quota is no longer exceeded)”, par. [0016]; and pars. [0037] and [0093] for further amount of computing resources as well, and pars. [0024 and 35-36] for quotas’ limits; and [0093] “cannot exceed the limit 464” implies to less than the quota); and
determining a second global quota for a second account (Yu: pars. [0035] and [0036] “if a quota is applied to limit the number of queries or requests that may be submitted to a controlled resource 130 per unit of time (e.g., one second, multiple seconds), gateway server 122a will update quota usage store 126a every time a new call is approved and sent to the resource, for or on behalf of a client that has an associated quota, and will start rejecting additional calls (or will throttle them) if and when the threshold is met during a current time period. In this example, the gateway server can determine (from its quota usage store) whether the requesting client has already met or exceeded its quota, or whether it would do so if the request was approved, and can enforce the corresponding quota immediately.”);
determining that the second account is consuming a second amount of computing resources on the first storage server that is greater than the second global quota, the second amount being smaller than the first amount (Yu: par. [0092] “The ‘latency percentile in milliseconds’ entry indicates that the client's request(s) for the sub-resource will violate the quota restriction if they experience latency greater than the X.sup.th percentile (X %) (e.g., a standard percentile such as 50%, 95%, 99%) over the period of time indicated by window duration 468 (e.g., 60 seconds). In other words, whatever value the X.sup.th percentile corresponds to within a distribution of response times for client requests for the sub-resource (e.g., 15 ms, 50 ms) during some historical time period, this quota type will be violated when the latency experienced by requests exceeds that value”); and
throttling a set of transactions associated with the second account, the throttling comprising causing a delay in executing the set of transactions by a set of execution nodes (Yu: Figs. 1-2 for technique of the quotas and throttling, e.g. reject/accept that causes the delay in processing/executing; par. [0006] “The central entity collects the usage statistics, and disseminates the statistics and/or quota statuses to all controller entities so that they all act in unison to deny access to clients that have exceeded their quotas. In these schemes, there is measurable delay in correctly enforcing a given requester's quota (either to deny requests when the quota is exceeded or to once again accept requests when the quota is no longer exceeded)”).
Regarding claim 7, Dageville, Durand, Cheru, and Yu, in combination, teach: wherein the first global quota is configured based on a first set of parameters, the first set of parameters comprising a first reserved throughput, a first total throughput, and a first value in bytes per second of throughput (Dageville: par. [0029] “… storing petabytes of data. Querying very large databases and/or tables might require scanning large amounts of data. Reducing the amount of data scanned for database queries is one of the main challenges of data organization and processing. When processing a query against a very large sum of data, it can be important to use materialized views to reduce the amount of time and processing resources required to execute the query…”, and par. [0070] discloses the “parameters from the client account” and “provide parameters concerning how many time a task may be re-executed…”, and par. [0104]; and see Yu: Fig. 1 and pars.[0035-36] disclose the “quota”, and further in Fig. 4B for the value in bytes for total throughput at element 464, and element 468).
Regarding claim 8, Dageville, Durand, Cheru, and Yu, in combination, teach: wherein the second global quota is configured based on a second set of parameters, the set of parameters comprising a second reserved throughput, a second total throughput, and a second value in bytes per second of throughput, and the first set of parameters is different than the second set of parameters (Dageville: par. [0029] “… storing petabytes of data. Querying very large databases and/or tables might require scanning large amounts of data. Reducing the amount of data scanned for database queries is one of the main challenges of data organization and processing. When processing a query against a very large sum of data, it can be important to use materialized views to reduce the amount of time and processing resources required to execute the query…”, and par. [0070] discloses the “parameters from the client account” and “provide parameters concerning how many time a task may be re-executed…”, and pars. [0089] via different cache resources and computing resources for tasks execution, and [0104]; and see Yu: Fig. 1 and pars.[0035-36] disclose the “quota”, and further in Fig. 4B for the value in bytes for total throughput at element 464, and element 468).
Regarding claim 10, Dageville, Durand, Cheru, and Yu, in combination, teach: wherein the operations further comprise: determining, by a quota enforcement component, a total load of the capacity group across a set of storage servers (Cheru: Fig. 5 see element 528-Quota Assignment; pars. [0005], and [0007] “Various aspects for quota enforcement, particularly, object storage systems and methods with control entity quota usage monitoring are described”; par. [0011]; and par. [0014] “hardware and/or software with functionality to improve data object access control for enforcing quota limits, such as by monitoring quota usage for various control entities associated with object data access requests”, par. [0031] “several storage nodes 30 can be grouped together” (see in Fig. 1 and par. [0035] “According to the exemplary embodiment of FIG. 1 and in the event that storage nodes 30.2-30.40 are identical to storage node 30.1 and each comprise a storage capacity of 36 TB, the distributed storage system 1 would then have a total storage capacity of 1440 TB, and wherein the “different data centers” are also embedded the set of storage servers in different regions; and pars. [0052-53], and further in [0057-59, 66, 87, and 92], wherein the read and/or write/storage operations are implemented workload; and also in Yu: see Fig. 4B, elements 462 and 470 as shown quota enforcement component, a total load of the capacity across a set of storage servers, Fig. 1; par. [0003] “ Demand exceeds capacity in many data centers and other computing environments, thereby requiring consumers of the resources to share them.”, par. [0024] “a quota limit store” equivalent to capacity; and pars. [0035-36]).
Claims 12, 15-18, and 19 are rejected in the analysis of above claims 2, 5-10; and therefore, the claims are rejected on that basis.
Claims 3-4, 13-14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Dageville, Durand, Cheru, and Yu and further in view of Wuest et al., US Pub. No. 2020/0336489 (hereinafter as “Wuest”).
Regarding claim 3, the claim is rejected by the same reasons set forth above to claims 1 and 2. Dageville, Durand, Cheru, and Yu, in combination, teach: wherein determining that the request in the queue should be throttled (Dageville: Fig. 7, element 704 – Query Queue, wherein the quest/query is placed in queue; Cheru: pars. [0002-3, and 47-48]; and Yu: Fig. 2 for quotas; and pars. [0035-36] for throttling the request for processing). However, Dageville, Durand, Cheru, and Yu do not explicitly teach: “using token bucket” and/or “determining that the token bucket is absent of a particular token corresponding to the tag, or determining that the token bucket does not include a sufficient number of tokens corresponding to the tag.”
In the same field of endeavor (i.e., data processing), Wuest teaches: “using token bucket” (Wuest: par. [0075] “a filter on a policy on a service and/or resource, assigned through granting access to a role in a same account, another account or even another cloud” for accessing data stored in cloud/data centers; and pars. [0080-82] teach “a ListBuckets”, “tokens” and “token tracing”). And further comprises: “determining that the token bucket is absent of a particular token corresponding to the tag, or determining that the token bucket does not include a sufficient number of tokens corresponding to the tag” (Wuest: Figs. 16-17, and pars. [0075], [0080-82], and [0087] e.g., “eliminating users from group that are not using group permissions, by moving users with direct-attached permissions to groups with the same permissions, identifies users with similar permissions and creating a group for those users, while removing their direct-attached permissions.”).
Regarding claim 4, the claim is rejected by the same reasons set forth above to claims 1-3. Furthermore, Yu, and Wuest, in combination, teach: “wherein the sufficient number of tokens corresponding to the tag is based on a limiting rate of the tag” (Wuest: pars. [0081-82] e.g., “tokens” and “token tracing” inherited number of tokens; and Yu: Fig. 2, par. [0007] “Such a system may set a maximum rate at which a client may submit queries to a data repository, for example….”, [0016 and 67-68]; and pars. [0035-36])
Claims 13-14, and 19 are rejected in the analysis of above claims 3-4; and therefore, the claims are rejected on that basis.
Response to Arguments
Referring to claim rejections under 35 U.S.C. 103, Applicant's arguments (Applicant’s Remarks, pages 8-9) to the amended limitations recites in respective claim 1 (same as to independent claims 11 and 19) have been considered but are moot in view of the new grounds of rejection necessitated by applicant's amendment to the claims. Applicant's newly amended features are taught implicitly, expressly, or impliedly by the prior art of record.
Prior Arts
The prior art made of record on form PTO-892 and not relied upon is considered pertinent to applicant's disclosure. Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
It is noted that any citation to specific, pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275,277 (CCPA 1968)); Merck & Co. v. Biocraft Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert. denied, 493 U.S. 975 (1989).
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 Jessica N. Le whose telephone number is (571)270-1009. The examiner can normally be reached M-F 9:30 am - 5:30 pm (EST).
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, SHERIEF BADAWI can be reached on (571) 272-9782. 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.
/Jessica N Le/Examiner, Art Unit 2169
/SHERIEF BADAWI/Supervisory Patent Examiner, Art Unit 2169
Prosecution Insights