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 .
DETAILED ACTION
Response to Arguments
Applicant's arguments filed 7/27/26 have been fully considered but they are not persuasive.
Applicant states: These limitations define the specific manner in which the computer system performs API selection and therefore cannot be ignored when evaluating eligibility. The Office's summary omits these technological limitations and therefore fails to evaluate the claim as a whole, as required under the Alice framework and the Office's current eligibility guidance. Consequently, Applicant respectfully submits that claim 1 does not recite, and has not been shown to recite, an abstract idea. For at least this additional reason, claim 1 is patent eligible under Step 2A, Prong One.
Examiner states: Examiner respectfully disagrees. Upon review of the limitations, it does not appear that these limitation cannot be performed in the mind as there are no additional limitations that make these identified abstract ideas significantly more. For example, assigning weight based upon a condition and comparing a condition with a type in order to perform a recommendation does not amount to significantly more. Therefore, Examiner maintains the 101 rejection.
Applicant states: Here, amended claim 1 does not merely invoke a machine learning model as a generic decision-making tool. Rather, the claims require assigning weights to performance metrics based on a condition of the subsequent request and determining an API recommendation based on the weighted metrics together with a comparison between the condition of the subsequent request and a type of the API. These limitations define a specific technological technique for improving automated API selection in a computer system. As in Desjardins, the claimed advance is directed to improving the manner in which the computer system performs its technical operation, not merely to automating a human decision. Accordingly, the claims are integrated into a practical application and are patent eligible under Step 2A, Prong Two.
Examiner states: Examiner respectfully disagrees. It is not clear as to how outputting instruction for performing a recommendation improves upon the functioning of a computer. The claims merely assign values to metrics and further recommend an API further based upon a comparison. No details regarding how these steps relate to the functioning and improvement of the technical arts. The actual call to the API is not performed to improve the functioning of the computer. The limitations, as a result, merely outputs instructions for performing the recommendation.
Applicant states: Here, claim 1 includes "receiving a request from a client device," "selecting an application programming interface (API) of a plurality of APIs for performance of the request based on a condition of the request," "storing performance metrics related to the performance of the request by the API in a performance index," "receiving a subsequent request," "assigning, using a machine learning model, one or more weights to the performance metrics based on a condition of the subsequent request," "determining, using the machine learning model, a recommendation on calling the API for performance of the subsequent request based on the performance metrics including the one or more weights and by comparing the condition of the subsequent request and a type of the API," and "outputting instructions for performing the recommendation on calling the API." Applicant respectfully submits that these features are not well-understood, routine, or conventional with the other claimed features and that the claimed combination of specific features clearly recites an inventive concept.
Examiner states: Examiner respectfully disagrees. Upon consideration of other elements in the claim, the claims do not appear to recite significantly more that the abstract ideas of selecting, assigning, determining, comparing. Limitation directed to receiving, storing, and outputting, the courts have identified mere data gathering is well-understood, routine and conventional activity. See MPEP 2106.05(d) (Ex. iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;). Therefore, Examiner maintains the 101 rejection.
Applicant states: Accordingly, the combination of Ahuja and Savalle fails to disclose, teach, or in any way suggest the subject matter of claim 1, particularly as amended. As such, Applicant requests that the § 103 rejection of claim 1 be withdrawn.
Examiner states: New mapping provided to the newly added limitations as taught by Ahuja as shown below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-17,19-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Regarding independent claims the limitations select an API, determines a recommendation, analyzes metrics, as drafted, recites functions that, under its broadest reasonable interpretation, covers a function that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations as cited above as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process.
Thus, these limitation falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, this judicial exception is not integrated into a practical application. The claim recites the following additional limitations: memory, device, machine learning model, storage medium, outputting instruction. The additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, MPEP 2106.05(f), and steps of receiving and storing do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering data. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(g) (Ex. v. Consulting and updating an activity log, Ultramercial, 772 F.3d at 715, 112 USPQ2d at 1754).
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of memory, device, machine learning model, storage medium, outputting instruction, amount to no more than mere instructions, or generic computer/computer components to carry out the exception. Furthermore, the limitations directed to receiving and storing the courts have identified mere data gathering is well-understood, routine and conventional activity. See MPEP 2106.05(d) (Ex. iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;).
The recitation of generic computer instruction and computer components to apply the judicial exception, and mere data gathering do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Regarding claim 3-4, 6-8, 11, 12, 14, 15, 19, 20-22 the limitations of adjusting values, merely using weights and metrics for training, updating a recommendation, analyzing events, determining a type, comparing values, are functions that can be reasonably performed in the human mind, thus, additional mental process defined in the claims. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding claim 5, 9, 13, 16 the limitation of what metrics measure, what a recommendation is based off of, are considered mere instructions, or generic computer/computer components to carry out the exception Accordingly, the additional element recited in claim 3 fails to provide a practical application under prong 2, or amount to significantly more under step 2B.
Claim Interpretation - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Claims limitation 10-16 has/have been interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because it uses/they use a generic placeholder “processing device” and “machine learning model” coupled with functional language without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not preceded by a structural modifier. Since the claim limitation(s) invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, claim 13 has/have been interpreted to cover the corresponding structure described in the specification that achieves the claimed function, and equivalents thereof.
A review of the specification, Fig. 10 [0106] shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitation.
If applicant wishes to provide further explanation or dispute the examiner’s interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not intend to have the claim limitation(s) treated under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112 , sixth paragraph, applicant may amend the claim(s) so that it/they will clearly not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, or present a sufficient showing that the claim recites/recite sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
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.
Claim/s 1, 4-10, 13-17, 20-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ahuja (Pub. No. US 2021/0406383) in view of Savalle (Pub. No. US 2024/0394121).
Claim 1, 10, 17, Ahuja teaches “a method, comprising: receiving a request from a client device; selecting an application programming interface (API) of a plurality of APIs for performance of the request based on a condition of the request ([0054] The method 300 begins at step 302 where the API machine learning processor 122 receives a request from the user 114 to determine an API 150 to perform a particular task 124. In some embodiments, the user 114 may specify the request to the API machine learning processor 122 from, for example, a user interface, a command console, etc. of the API machine learning processor 122 as described in FIG. 1. For example, the user 114 may request an API 150 to retrieve email addresses of clients of the organization from client IDs from 100 to 110. The user 114 may specify the input and output parameters of the API 150 by query statements. For example, a query statement for the request above, may be such as: SELECT email from clients WHERE client ID is from 100 to 110. In another example, the user 114 may specify the input and output parameters of the API 150 by feeding them to the API machine learning processor 122 via inputs and outputs fields in its user interface.); storing performance metrics related to the performance of the request by the API in a performance index ([0026] The API machine learning processor 122 then invokes each API 150 from among the set of APIs 150 to performs the particular task 124. By doing so, the API machine learning processor 122 determines the performances associated with the APIs 150. The API machine learning processor 122 then determines performance values 152-3 based on the performances of the set of APIs 150.); receiving a subsequent request ([0069] In step 324, the API machine learning processor 122 monitors the particular API 150-1 performing the particular task 124, e.g., by generating a tracking ticket 118 as described in FIG. 1. The API machine learning processor 122 generates a separate tracking ticket 118 every time a different user 114 invokes the particular API 150-1 to perform the particular task 124.); assigning, using a machine learning model, one or more weights to the performance metrics based on a condition of the subsequent request; determining, using the machine learning model, a recommendation on calling the API for performance of the subsequent request based on the performance metrics (i.e. fulfills security requirement) including the one or more weights and by comparing the condition of the subsequent request and a type of the API ([0039] Now, consider a second case where the user 114 wishes to retrieve the email addresses of clients of the organization. Assume that in the second case, the user 114 uses the below statement to define the query in the API 150. [0040] (i.e. API selected based upon conditions in query) string email=“client@mail.com”; [0041] string output=“SELECT*from clients WHERE email is?”. In the second case, the email address is parametrized in the query statement, which makes the query statement immune to malicious attacks and SQL injections. Thus, in such cases, the source code security scanner 128 determines that this portion of the source code of the API 150 is not vulnerable to data leakage. [0048] The source code security scanner 128 is also configured to scan the source code of the API 150 and determine security information of the security mechanism associated with the API 150, such as type, version, strength, etc. of the security mechanism. In some embodiment, the source code security scanner 128 may assign different values or weights to different security information of the security mechanism associated with the API 150 based on their priorities. For example, the source code security scanner 128 may determine that the strength of the security mechanism associated with the API 150 has a higher priority over the type of the security mechanism. Thus, the source code security scanner 128 may assign a higher value (e.g., 7 out of 10) to the strength of the security mechanism; and assign a lower value (e.g., 2 out of 10) to the type of the security mechanism. As such, the security associated with the API 150 may be determined by calculating a sum of the different values assigned to the security information of the security mechanism associated with the API 150. Examiner notes, Savalle teaches subsequent requests may be analyzed when selecting an API. Therefore it would be obvious to one ordinarily skilled in the art, Ahuja may receive subsequent requests and maintain API selection based upon score for the purposes of improved resource utilization [0136] At step 715, as detailed above, the device may identify, based on the trace data, a set of calls among the application programming interface calls that are frequently co-occurring. In some embodiments, the device may do so by disregarding application performance monitoring trace data associated with the sessions, when the real user monitoring trace data is available for the sessions.); and outputting instructions for performing the recommendation on calling the API ([0071] For this particular example, assume that the particular API 150-1 had the highest API score value 154-1 from among the set of APIs 150 as determined by the API machine learning processor 122. Thus, the API machine learning processor 122 recommends to the user 114 to use this particular API 150-1 to perform the particular task 124.)”.
Claims 4, 20, the combination teaches the claim, wherein Ahuja teaches “the method of claim 1, further comprising updating the recommendation on calling the API for the performance of the subsequent request based on detecting whether the performance of the subsequent request meets a threshold level of performance ([0071] In step 328, the API machine learning processor 122 hosts another API 150 that has the highest API score value 154 from among the set of APIs 150. For example, consider a case where the API score value 154-1 associated with the particular API 150-1 has been determined to be 7 to perform the particular task 124 in step 316. For this particular example, assume that the particular API 150-1 had the highest API score value 154-1 from among the set of APIs 150 as determined by the API machine learning processor 122. Thus, the API machine learning processor 122 recommends to the user 114 to use this particular API 150-1 to perform the particular task 124.)”.
Claim 5, 13, the combination teaches the claim, wherein Ahuja teaches “the method of claim 1, wherein the performance metrics measure response success, system stability, error rate, or load capacity related to the performance of the request by the API ([0044] In some examples, the quality associated with the API 150 may depend on a testability of the source code of the API 150, where the testability of the source code of the API 150 is represented by how easily potential defects or errors in the source code of the API 150 may be found by test cases and test points. One method that increases the testability of the source code of the API 150 is by implementing classes and methods to define each of the input and output parameters of the API 150. With this approach, if the user 114 wishes to change, e.g., a format of the output parameter of the API 150, he/she may only change the format of the output parameter in its class. Thus, if the source code security scanner 128 determines that classes are used in defining input and output parameters, it may determine that the quality associated with this portion of the source code of the API 150 is high. The testability of the source code of the API 150 may be impacted by the size and the complexity of the source code of the API 150.)”.
Claim 6, 14, the combination teaches the claim, wherein Ahuja teaches “the method of claim 1, further comprising analyzing events related to the performance of the request by the API to capture the performance metrics ([0063] The API machine learning processor 122 may assign the performance values 152-3 to the APIs 150 after it determines and compares the response times of the set of APIs 150 with each other. If the API machine learning processor 122 determines that the response time of the API 150 is longest compared to other APIs 150, it assigns a low performance value 152-3 (e.g., 1, where 1 is the lowest performance value 152-3) to the API 150. On the other hand, if the API machine learning processor 122 determines that the response time of the API 150 is shortest compared to other APIs 150, it assigns a high performance value 152-3 (e.g., 1, where 3 is the lowest performance value 152-3) to the API 150. [0064] In step 316, the API machine learning processor 122 determines the API score value 154 of the API 150 based on the combination of the quality value 152-1, security value 152-2, and performance value 152-3. In some embodiments, the API machine learning processor 122 determines the API score value 154 by calculating the sum of the quality value 152-1, security value 152-2, and performance value 152-3 assigned to the API 150. For example, if the quality value 152-1, security value 152-2, and performance value 152-3 assigned to the API 150 are 1, 3, and 3, respectively, the API score value 154 of the API 150 will be 7.)”.
Claim 7, 15, the combination teaches the claim, wherein Ahuja teaches “the method of claim 1, further comprising determining a type of the API based on the condition of the request ([0012] FIG. 1 illustrates one embodiment of a system 100 configured to determine an API 150 to perform a particular task 124. [0048] The source code security scanner 128 is also configured to scan the source code of the API 150 and determine security information of the security mechanism associated with the API 150, such as type, version, strength, etc. of the security mechanism.)”.
Claim 8, the combination teaches the claim, wherein Ahuja teaches “the method of claim 7, wherein the recommendation on calling the API is based on a comparison between a condition of the subsequent request and the type of the API ([0072] After a while, when the user 114 uses the particular API 150-1 for a few times, he/she may notice that a newer version of the security mechanism associated with the source code of the particular API 150-1 is now available on the Internet. Thus, the user 114 may indicate in the tracking ticket 118 that the security mechanism associated with the source code of the particular API 150-1 is no longer up to date. The API machine learning processor 122 then recommends another API 150 that has the highest API score value 154 to be hosted or deployed in the web application 140 to perform the particular task 124. The API machine learning processor 122 also updates the security value 152-2a associated with the particular API 150-1 based on the feedback of the user 114 in the tracking ticket 118. The API machine learning processor 122 may also flag the particular API 150-1 indicating that its security mechanism needs to be updated.)”.
Claim 9, 16, the combination teaches the claim, wherein Ahuja teaches “the method of claim 1, wherein the recommendation on calling the API is based on a composite score of the performance metrics in the performance index ([0064] In step 316, the API machine learning processor 122 determines the API score value 154 of the API 150 based on the combination of the quality value 152-1, security value 152-2, and performance value 152-3. In some embodiments, the API machine learning processor 122 determines the API score value 154 by calculating the sum of the quality value 152-1, security value 152-2, and performance value 152-3 assigned to the API 150. For example, if the quality value 152-1, security value 152-2, and performance value 152-3 assigned to the API 150 are 1, 3, and 3, respectively, the API score value 154 of the API 150 will be 7.)”.
Claim 21, the combination teaches the claim, wherein Ahuja teaches “the method of claim 1, wherein the recommendation on calling the API involves comparing the API and an additional API ([0063] The API machine learning processor 122 may assign the performance values 152-3 to the APIs 150 after it determines and compares the response times of the set of APIs 150 with each other. If the API machine learning processor 122 determines that the response time of the API 150 is longest compared to other APIs 150, it assigns a low performance value 152-3 (e.g., 1, where 1 is the lowest performance value 152-3) to the API 150. On the other hand, if the API machine learning processor 122 determines that the response time of the API 150 is shortest compared to other APIs 150, it assigns a high performance value 152-3 (e.g., 1, where 3 is the lowest performance value 152-3) to the API 150.)”.
Claim/s 3, 11, 12, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ahuja, Savalle, in view of Dhondse (Pub. No. US 2022/0261299).
Claim 11, the combination may not explicitly teach the limitation.
Dhondse teaches “the method of claim 1, wherein the machine learning model adjusts weights of the performance metrics based on a condition of the subsequent request ([0031] In 290, the API simulation handler 126 performs simulations on the selected API to determine whether the API works for the particular solution identified by the user. As used herein, a “solution” refers to the entire application and includes not only input/output associated with the API but also binding API's specific to the application. The solution also includes self-adjusting recommendations for tuning parameters specific to the application. The API simulation handler 126 is configured to perform cognitive binding based on a particular application and identify a type of simulation to be leveraged and recommended to the user/enterprise. The simulations performed on the selected API(s) are not limited. For example, the API simulation handler 126 can performed a data-based simulation or a scenario-based simulation. A data-based simulation can involve using training/test data. A scenario-based simulation involves using a user-based scenario, which involves using the API in the manner intended by the user. Based on feedback 128 regarding a particular API during the process of building the application for user, the feedback 128 can be leveraged for adjusting a relevancy score of a particular API and/or adjusting the API interchangeability index.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Dhondse with the teachings of Ahuja, Savalle in order to provide a system that teaches details of tuning recommendations. The motivation for applying Dhondse teaching with Ahuja, Savalle teaching is to provide a system that allows for design choice. Ahuja, Savalle, Dhondse are analogous art directed towards API selection. Together Ahuja, Savalle, Dhondse teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Dhondse with the teachings of Ahuja, Savalle by known methods before the effective filing date of the claimed invention and gained expected results.
Claim 3, 12, 19, the combination may not explicitly teach the limitation.
Dhondse teaches “the method of claim 1, wherein the machine learning model is trained on selections of APIs based on varied weights of the performance metrics for performance of previous requests ([0031] In 290, the API simulation handler 126 performs simulations on the selected API to determine whether the API works for the particular solution identified by the user. As used herein, a “solution” refers to the entire application and includes not only input/output associated with the API but also binding API's specific to the application. The solution also includes self-adjusting recommendations for tuning parameters specific to the application. The API simulation handler 126 is configured to perform cognitive binding based on a particular application and identify a type of simulation to be leveraged and recommended to the user/enterprise. The simulations performed on the selected API(s) are not limited. For example, the API simulation handler 126 can performed a data-based simulation or a scenario-based simulation. A data-based simulation can involve using training/test data. A scenario-based simulation involves using a user-based scenario, which involves using the API in the manner intended by the user. Based on feedback 128 regarding a particular API during the process of building the application for user, the feedback 128 can be leveraged for adjusting a relevancy score of a particular API and/or adjusting the API interchangeability index.)”.
Rationale to claim 2 is applied here.
Claim/s 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ahuja, Savalle, in view of Susman (Pub. No. US 2023/0004478).
Claim 22, the combination may not explicitly teach load capacity. Ahuja does teaches utilizing performance metrics in comparing APIs.
Susman teaches “the method of claim 21, wherein the comparing the API and the additional API involves comparing error rate or load capacity of the API and the additional API ([0010] Current APMs typically monitor two sets of performance metrics. The first set of performance metrics relates to the performance experienced by end users of the application (e.g., average response times under peak load), and the second set of performance metrics measures the computational resources used by the application for the load, indicating whether there is adequate capacity to support the load, as well as possible locations of a performance bottleneck. Ahuja [0063] The API machine learning processor 122 may assign the performance values 152-3 to the APIs 150 after it determines and compares the response times of the set of APIs 150 with each other. If the API machine learning processor 122 determines that the response time of the API 150 is longest compared to other APIs 150, it assigns a low performance value 152-3 (e.g., 1, where 1 is the lowest performance value 152-3) to the API 150. On the other hand, if the API machine learning processor 122 determines that the response time of the API 150 is shortest compared to other APIs 150, it assigns a high performance value 152-3 (e.g., 1, where 3 is the lowest performance value 152-3) to the API 150.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Susman with the teachings of Ahuja, Savalle in order to provide a system that teaches details of performance metrics. The motivation for applying Susman teaching with Ahuja, Savalle teaching is to provide a system that allows for design choice. Ahuja, Savalle, Susman are analogous art directed towards API selection. Together Ahuja, Savalle, Susman teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Susman with the teachings of Ahuja, Savalle by known methods before the effective filing date of the claimed invention and gained expected results.
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 WYNUEL S AQUINO whose telephone number is (571)272-7478. The examiner can normally be reached 9AM-5PM EST M-F.
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, Lewis Bullock can be reached at 571-272-3759. 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.
/WYNUEL S AQUINO/Primary Examiner, Art Unit 2199
