DETAILED ACTION
Remarks
Applicant presents a communication dated 29 July 2026 in response to the 29 April 2026 non-final Office action (the “Previous Action”).
With the communication:
claims 1, 8 and 15 are amended;
claims 5-7, 12-14 and 19-20 are cancelled;
new claims 21-28 are added;
the title of the invention is amended; and
paragraphs [0003], [0081] and [0085] of the specification are amended.
Claims 1-4, 8-11, 15-18 and 21-28 are pending. Claims 1, 8 and 15 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below. Any new ground(s) of rejection were necessitated by Applicant’s amendments.
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 .
37 C.F.R. § 1.121
It is noted to clarify the record that Applicant’s claim listing incorrectly shows the “by a unit testing generation module” language claim 1 deleted twice from the claim when it in fact only appeared once in that claim. The claims are nonetheless examined in the interests of compact prosecution.
Examiner Notes
Examiner cites particular columns, paragraphs, figures 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 their 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.
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 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.
Response to Arguments
Applicant argues that Alves does not teach monitoring a refactoring operation in real-time. (Remarks, pp. 21-22).
This argument is moot in view of the new ground(s) of rejection below, necessitated by Applicant’s amendments.
Applicant also argues with respect to claim 1 that Alves does not describe “automatically generating” unit testing because Alves describes test case prioritization as opposed to generating “new testing.” (Remarks, p. 23 pars. 1-2).
Examiner respectfully disagrees and submits that the prioritized test cases Alves are a “unit testing” as claimed at least because the prioritized test cases include Junit test cases. As noted in the Previous Action, Junit test cases are unit tests, which Applicant does not dispute, and a prioritized set of test cases is both generated and “new” in the sense that the test cases were not prioritized before. Alves also teaches that obsolete test cases can be discarded (Alves at p. 404 par. 3), meaning the remaining tests would be a newly generated set of tests as well. Note that the specification is silent as to what a “unit testing” actually comprises.
Applicant then argues with respect to claim 1 that the additional limitations integrated into amended claim 1 are not taught by Alves because the queries of Ref-Finder (see Kim et al.) referred to in Alves and cited as teaching the claimed “second rule library” are not “for generating or selecting unit testing.” (Remarks, p. 23 par. 2 – p. 24 par. 1).
Examiner respectfully submits in response that Ref-Finder is not cited as teaching generating or selecting unit testing and the claim does not require any library “for generating or selecting unit testing.” Limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant then argues with respect to claim 1 that Alves fails to describe a “unit testing generation model” because Alves does not teach a trained computational model that takes code differences as input and produces unit testing as output. (Remarks, p. 24 par. 2)
Examiner respectfully disagrees that claim 1 requires any trained computational model that takes code differences as input and produces unit testing as output. Again, limitations from the specification are not read into the claims.
Applicant’s arguments with respect to the remaining claim by virtue of their dependence from claim 1, similarity with claim 1 or dependence from a similar claim are unpersuasive and/or moot for the same reasons.
Specification
The objections to the specification are withdrawn in view of Applicant’s specification amendments.
Claim Objections
Claims 1-4, 8-11, 15-18 and 21-28 are objected to for the following informalities:
Claim 1 refers to “the unit testing comprising” in the 3rd to last line of the claim which appears to be a typographical error that should perhaps read -the unit testing comprises- instead.
Claims 2-4 and 21-24 are objected to via dependency from claim 1.
Claims 8-11, 15-18, 25-28 are objected to for the same reasons as claim 1-4 and 21-24.
Claim Interpretation
The Previous Action’s interpretation of certain limitations in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph is moot in view of Applicant’s claim amendments.
Claim Rejections - 35 USC § 112
The Previous Action’s § 112 rejection of claim 7 is withdrawn in view of Applicant’s claim amendments.
Claim Rejections - 35 USC § 101
The Previous Action’s § 101 rejections are withdrawn in view of Applicant’s claim amendments.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Alves et al., “Prioritizing test cases for early detection of refactoring faults” (art of record – hereinafter Alves) in view of Howe et al. (US 7,370,318) (art made of record – hereinafter Howe).
As to claim 1, Alves discloses a unit testing generation method, wherein the method comprises:
determining, by a processor, a type of the refactoring operation performed by the user on the source code; (e.g., Alves, p. 418 par. 2: PriorJ [instructions, necessarily stored in memory] was run in a MacBook Pro Core i5 2.4 Ghz and 4GB RAM, running Mac OS [i.e., the steps of Alves are performed by a processor. Note this applies to the other steps below as appropriate]; p. 409 par. 2: Ref-Finder identifies which refactoring edits were applied. Ref-Finder’s output is parsed into ref-strings—simplified string patterns that describe type and location of refactoring edits. Ref-strings for the five refactoring types currently supported are described in Table II—for instance, PullUpMethod(B, A, k(int i)) in the guiding example) and
automatically generating, by the processor based on the type of the refactoring operation, the source code, and refactored code, unit testing corresponding to the refactored code, (e.g., Alves, p. 402 Summary: this article proposes refactoring-based approach (RBA); p. 404 par. 2 first bullet: RBA is integrated into an open source tool, PriorJ [unit testing generation module]; p. 409 par. 2: Ref-Finder identifies, from two consecutive versions of a Java program [the source code and the refactored code], which refactoring edits were applied. Ref-Finder’s output is parsed into ref-strings; p. 409 par. 4: for each collected ref-string [which includes the type of the refactoring operation, see above], a set of methods—the affected set (AS)—is built. AS contains the methods whose behavior is potentially modified; p. 16 pars. 8-9: next, the graphs are processed for sorting out the most relevant test cases [unit testing], using as criterion the AS set. For example, methods A.k (int i), B.m and B.sum are in both AS and the call graphs; thus, these test cases get selected; p. 414 Sec. 6.1 par. 2: three opensource Java projects were selected as experimental objects: XM-Security, JMock described and used in Section 2; and EasyAccept. JMock’s suite comprises 504 Junit test cases [Junit test cases are unit tests]) comprising:
obtaining, by the processor, a difference between the refactored code and the source code, (e.g., Alves, p. 407 Sec. 4 Inputs and outputs: original and refactored versions of a program. The base version and the delta version; p. 409 par. 2: Ref-Finder identifies, from two consecutive versions of a java program, which refactoring edits were applied) and
determining, by the processor, whether a rule matching the type of the refactoring operation and the difference between the refactored code and the source code exists in a second rule library, (e.g., Alves, p. 409 par. 2: Ref-Finder identifies, which refactoring edits were applied [and see Kim et al. “Ref-Finder: A Refactoring Reconstruction Tool based on Logic Query Templates at p. 371 right col. par. 3: it invokes pre-defined logic queries (a rule library, queries being rules) to identify program differences that match the constraints of each refactoring type (i.e., determining whether a query that matches the type and difference exists). See also p. 372 left col. par. 1 of Kim, in order to identify a replace_conditionals_with_polymorphism(oldmethod, subclass) refactoring, ref-finder invokes a query to check that a type check was performed in the conditional and that the new method body is similar to the original])
if it is determined that the rule matching the type of the refactoring operation and the difference between the refactored code and the source code exists, using unit testing corresponding to the matched rule as the unit testing corresponding to the refactored code; (See rejection of claim 1 above, Ref-Finder returns a re-string with the refactoring type [i.e., the query matching the type and difference exists] and unit testing correspond to that refactoring type is determined]).
if it is determined that the rule matching the type of the refactoring operation and the difference between the refactored code and the source code does not exist, inputting the difference between the refactored code and the source code into a unit testing generation model, to obtain the unit testing corresponding to the refactored code; (see rejection of claim 6 above, ref-finder invokes multiple logic queries, so if one does not match, another will be invoked. Invoking each query is inputting the difference into a unit testing generation model because as shown at p. 372 left col. par. 1 and Figure 1 of Kim, a query checks that a type check was performed in the conditional and that the new method body is similar to the original method [i.e., the differences are input into the query] and fills in portions of the query with portions of the changed code. This is also done to generate a unit testing as noted above) and
wherein the refactored code is code obtained by performing the refactoring operation on the source code by the user, (e.g., Alves p. 408 Figure 6 and associated text, p. 407 Sec. 4 Guiding example: suppose a developer performs a pull up method edit as shown in Figure 6 [see the original code and code after pulling up k(int) in the figure]; p. 412 Sec. 5.2 par. 1: the pull up method refactoring) the unit testing comprising a section of code that checks whether a function of a smallest testable unit in software is correct, and the unit testing corresponding to the refactored code is used to test the refactored code (e.g., Alves, p. 14 last par.: in 53% of the cases, RBA enabled fault detection after running a single test case [and see above, the test cases include Junit test cases which are unit test cases. As noted in the specification in paragraph [0003], unit testing by definition tests whether a smallest testable unit in software is correct]).
Alves does not explicitly disclose monitoring, in real time by a processor of a computing device, a refactoring operation performed by a user on source code.
However, in an analogous art, Howe discloses:
monitoring, in real time by a processor of a computing device, a refactoring operation performed by a user on source code; (e.g., Howe, col. 3 ll. 46-47: a particular source module is refactored “(e.g., by a developer)”; col. 15 ll. 43-45: when the refactoring is performed, meta information about the refactoring is collected; col. 18 ll. 61-67: the information about the refactoring could be caught in real-time and streamed to others that would be interested in the original refactoring).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the refactoring of Alves such that it is monitoring in real time, as taught by Howe, as Howe would provide the advantage of a means of avoiding delays between the time when the refactoring is made and its processing. (See Howe, col. 18 ll. 61-67).
As to claim 8, it is a device claim having limitations substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons. Further limitations, disclosed by Alves, include:
a memory storing instructions; (e.g., Alves, p. 418 par. 2: PriorJ [instructions, necessarily stored in memory] was run in a MacBook Pro Core i5 2.4 Ghz and 4GB RAM, running Mac OS) and
a processor coupled with the memory, the processor configured to execute the instructions, causing the computing device to perform operations, (see immediately above) comprising (see rejection of claim 1 above).
As to claim 15, it is a medium claim having limitations substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons. Further limitations, disclosed by Alves, include:
a non-transitory computer readable storage medium, having instructions stored thereon, which when executed by a processor of a computing device, cause the computing device to perform operations, (e.g., Alves, p. 418 par. 2: PriorJ [instructions, necessarily stored in a non-transitory computer readable storage medium if run] was run in a MacBook Pro Core i5 2.4 Ghz and 4GB RAM, running Mac OS) comprising: (see rejection of claim 1 above).
Claims 2-4, 9-11, 16-18 and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Alves (“Prioritizing test cases for early detection of refactoring faults”) in view of Howe (US 7,370,318) in further view of Bowdidge et al. (US 2008/0052684) (art of record – hereinafter Bowdidge).
As to claim 2, Alves/Howe discloses the method according to claim 1 (see rejection of claim 1 above, but Alves does not explicitly disclose wherein the determining the type of the refactoring operation performed by the user on the source code comprises: determining whether a code refactoring tool is used for the refactoring operation performed by the user on the source code; and if it is determined that the code refactoring tool is used, determining the type of the refactoring operation based on the code refactoring tool; or if it is determined that the code refactoring tool is not used, determining the type of the refactoring operation based on the refactored code.
However, in an analogous art, Bowdidge discloses:
wherein the determining the type of the refactoring operation performed by the user on the source code (see below) comprises:
determining whether a code refactoring tool is used for the refactoring operation performed by the user on the source code; (e.g., Bowdidge, par. [0029]: refactoring UI 200 includes a selection control that allows a user to select a refactoring transformation to be performed) and
if it is determined that the code refactoring tool is used, determining the type of the refactoring operation based on the code refactoring tool; (e.g., Bowdidge, par. [0029]: here control 202 shows the “Encapsulate” refactoring transformation that the user selected in the menu; par. [0026]: the encapsulate transformation replaces instances of the variable with the “setter” function) or
if it is determined that the code refactoring tool is not used, determining the type of the refactoring operation based on the refactored code.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the determination of types of refactoring taught by Alves such that the determined refactoring is made by determining whether a code refactoring tool is used for the refactoring operation performed by the user on the source code and if it is determined that the code refactoring tool is used, determining the type of the refactoring operation based on the code refactoring tool, as taught by Bowdidge, as Bowdidge would provide the advantage of a means of automatically performing the manipulation of source code to implement a desired type of refactoring. (See Bowdidge, par. [0002]).
As to claim 3, Alves/Howe/Bowdidge discloses the method according to claim 2 (see rejection of claim 2 above), Alves further discloses:
wherein the determining the type of the refactoring operation based on the refactored code (see below) comprises:
obtaining the refactored code; (e.g, Alves, p. 409 par. 2: Ref-Finder identifies, from two consecutive versions of a Java program [the source code and the refactored code], which refactoring edits were applied)
determining that a rule matching the refactored code exists in a first rule library; (e.g., Alves, p. 409 par. 2: Ref-Finder identifies, which refactoring edits were applied [and see Kim et al. “Ref-Finder: A Refactoring Reconstruction Tool based on Logic Query Templates at p. 371 right col. par. 3: it invokes pre-defined logic queries (a rule library, queries being rules) to identify program differences that match the constraints of each refactoring type (i.e., determining whether a query that matches the code differences exists)]) and
using a refactoring operation type corresponding to the matched rule as the type of the refactoring operation (e.g., Alves, p. 409 par. 2: Ref-Finder identifies, from two consecutive versions of a Java program [the source code and the refactored code], which refactoring edits were applied [i.e., refactoring types matching rules]. Ref-Finder’s output is parsed into ref-strings—simplified string patterns that describe type and location of refactoring edits).
As to claim 4, Alves/Howe/Bowdidge discloses the method according to claim 2 (see rejection of claim 2 above), Alves further discloses:
wherein the determining the type of the refactoring operation based on the refactored code (see below) comprises:
obtaining the refactored code; (e.g, Alves, p. 409 par. 2: Ref-Finder identifies, from two consecutive versions of a Java program [the source code and the refactored code], which refactoring edits were applied) and
inputting the refactored code into a refactoring operation identification model for identification, to obtain the type of the refactoring operation (e.g., Alves, p. 409 par. 2: Ref-Finder identifies, which refactoring edits were applied [and see Kim et al. “Ref-Finder: A Refactoring Reconstruction Tool based on Logic Query Templates at p. 371 right col. par. 3: it takes two program versions as input. It then invokes queries to identify differences that match constraints (a model) of each refactoring type under focus; p. 372 left col. par. 1, a query checks that a type check was performed in the conditional and that the new method body is similar (Such characteristics are a model of the type of refactoring to be found]).
As to claim 9, it is a device claim having limitations substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
As to claim 10, it is a device claim having limitations substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
As to claim 11, it is a device claim having limitations substantially the same as those of claim 4. Accordingly, it is rejected for substantially the same reasons.
As to claim 16, it is a medium claim having limitations substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
As to claim 17, it is a medium claim having limitations substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
As to claim 18, it is a medium claim having limitations substantially the same as those of claim 4. Accordingly, it is rejected for substantially the same reasons.
As to claim 23, Alves/Howe discloses the method according to claim 1 (see rejection of claim 1 above),but does not explicitly disclose wherein the determining the type of the refactoring operation comprises determining whether a code refactoring tool is used for the refactoring operation performed by the user on the source code, and if it is determined that the code refactoring tool is not used, determining the type of the refactoring operation by using a first rule library that is distinct from the second rule library.
However, in analogous art, Bowdidge discloses:
wherein the determining the type of the refactoring operation comprises determining whether a code refactoring tool is used for the refactoring operation performed by the user on the source code, (e.g., Bowdidge, par. [0029]: refactoring UI 200 includes a selection control that allows a user to select a refactoring transformation to be performed [i.e., the user’s selection is detected]; par. [0008]: the refactoring transformation engine is configured for refactoring the source code using the specified refactoring transformation) and if it is determined that the code refactoring tool is not used, determining the type of the refactoring operation by using a first rule library that is distinct from the second rule library (these limitations are not required under the broadest reasonable interpretation, see M.P.E.P. § 2111.04(II)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the determination of types of refactoring taught by Alves such that the determined refactoring is made by determining whether a code refactoring tool is used for the refactoring operation performed by the user on the source code, as taught by Bowdidge, as Bowdidge would provide the advantage of a means of automatically performing the manipulation of source code to implement a desired type of refactoring. (See Bowdidge, par. [0002]).
As to claim 24, Alves/Howe discloses the method according to claim 1 (see rejection of claim 1 above) but does not explicitly disclose wherein the determining the type of the refactoring operation comprises determining whether a code refactoring tool is used for the refactoring operation performed by the user on the source code, and if it is determined that the code refactoring tool is not used, inputting the refactored code into a refactoring operation identification model for identification, to obtain the type of the refactoring operation.
However, in an analogous art, Bowdidge discloses:
wherein the determining the type of the refactoring operation comprises determining whether a code refactoring tool is used for the refactoring operation performed by the user on the source code, (e.g., Bowdidge, par. [0029]: refactoring UI 200 includes a selection control that allows a user to select a refactoring transformation to be performed [i.e., the user’s selection is detected]; par. [0008]: the refactoring transformation engine is configured for refactoring the source code using the specified refactoring transformation) and if it is determined that the code refactoring tool is not used, inputting the refactored code into a refactoring operation identification model for identification, to obtain the type of the refactoring operation (these limitations are not required under the broadest reasonable interpretation, see M.P.E.P. § 2111.04(II)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the determination of types of refactoring taught by Alves such that the determined refactoring is made by determining whether a code refactoring tool is used for the refactoring operation performed by the user on the source code, as taught by Bowdidge, as Bowdidge would provide the advantage of a means of automatically performing the manipulation of source code to implement a desired type of refactoring. (See Bowdidge, par. [0002]).
Claims 21, 25 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Alves (“Prioritizing test cases for early detection of refactoring faults”) in view of Howe (US 7,370,318) in further view of Dai et al. (US 2026/0111340) (art made of record – hereinafter Dai).
As to claim 21, Alves/Howe discloses the method according to claim 1 (see rejection of claim 1 above), and further discloses unit testing and refactored code and (see rejection of claim 1 above) but does not explicitly disclose wherein the unit testing generation model is trained via supervised learning using a second sample set comprising differences between known refactored code and corresponding known source code, and wherein known unit testing corresponding to the differences is used as a reference during the supervised learning to train the unit testing generation model.
However, in an analogous art, Dai discloses:
wherein the testing generation model is trained via supervised learning using a second sample set comprising differences between known code and corresponding known source code, and wherein known testing corresponding to the differences is used as a reference during the supervised learning to train the testing generation model (e.g., Dai, par. [0069]: the selection to add the one or more tests [known testing] and the unit of work delivery is stored in the data set; par. [0063]: a unit of work delivery may be a particular instance of revisions made to source code [revisions being differences between known revised code and corresponding known unrevised code]; par. [0069]: the system 420 may train the machine-learning model using the collected data set. Thus, the model is trained to generate an output of Test A, Test B and Test C any time a unit of work delivery including function X is inputted into the model or evaluated by the model; par. [0065]: machine learning techniques may include one or more machine-learning algorithms, such as an ensemble of multi-label classifiers “(e.g., supervised or unsupervised learning)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the code changed via refactoring and determination of unit testing corresponding to the changed code via a testing generation model taught by Alves, use a testing generation model trained via supervised learning using a second sample set comprising differences between known changed code and corresponding known source code, and wherein known testing corresponding to the differences is used as a reference during the supervised learning to train the testing generation model, as taught by Dai, as Dai would provide the advantage of means of determining tests based on previous testing history and a means for the model to be continuously improved over time. (See Dai, pars. [0070] and [0008]).
As to claim 25, it is a device claim having limitations substantially the same as those of claim 21. Accordingly, it is rejected for substantially the same reasons.
As to claim 27, it is a medium claim having limitations substantially the same as those of claim 21. Accordingly, it is rejected for substantially the same reasons.
Claims 22, 26 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Alves (“Prioritizing test cases for early detection of refactoring faults”) in further view of Bünder, “Decoupling Language and Editor – The Impact of the Language Server Protocol on Textual Domain-Specific Languages” (art made of record – hereinafter Bunder).
As to claim 22, Alves/Howe discloses the method according to claim 1 (see rejection of claim 1 above) and further discloses monitoring the refactoring operation in real-time and the refactoring operation (see rejection of claim 1 above) but does not explicitly disclose wherein the monitoring the refactoring operation in real time comprises encoding and parsing information that changes the source code and that is introduced by the refactoring operation based on a language server protocol within a development environment.
However, in an analogous art, Bunder discloses:
wherein the monitoring the operation comprises encoding and parsing information that changes the source code and that is introduced by the operation based on a language server protocol within a development environment (e.g., Bunder, p. 131 Figure 1 and associated text, right col. par. 2: on the left-hand side, the Development Tool is shown. The user edits [an operation] the document which is again forwarded to the server. The server now analyzes [parses] the changes within the document; p. 132 left col. Sec. 3.2 par. 1: The Language Server Protocol separates messages into header and content part. JSON-RPC 2.0 is used to describe messages, responses and notifications [i.e., messages, responses and notifications are encoded in that format]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the monitoring of refactoring operations in real time to include encoding and parsing information that changes the source code and that is introduced by the operation based on a language server protocol within a development environment, as taught by Bunder, as Bunder would provide the advantage of a means of accessing language-specific smarts separate from the editor. (See Bunder, p. 131, left col. par. 2).
As to claim 26, it is a device claim having limitations substantially the same as those of claim 22. Accordingly, it is rejected for substantially the same reasons.
As to claim 28, it is a medium claim having limitations substantially the same as those of claim 22. Accordingly, it is rejected for substantially the same reasons.
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 TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM 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, Hyung S Sough can be reached at (571)272-6799. 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2192
