Detailed Action
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendments
This final office action is in response to amendment filed on 04/16/2026. Claims
1, 3, 4, 11, 13, 14, and 20 have been amended. Claims 2 and 12 have been cancelled. Claims 1, 3-11, and 13-20 remain pending in the application.
Response to Amendment
The amendment filed on 04/16/2026 has been entered. See response to
amendments.
Information Disclosure Statement
The information disclosure statement (IDS) submitted in on 04/16/2026 the
information disclosure statement is being considered by the examiner.
Response to Arguments/Amendment
Examiner’s remark concerning applicant’s claim objection.
Applicant argument regarding (remark page 7) :
“Applicant is amending Claims 4 and 14 to remove the objected functionality. Claims 4 and 14 now recite "evaluating a given destination of the given return instruction." As such, Applicant respectfully requests that the objections be withdrawn.”.
Applicant’s arguments have been fully considered and are persuasive. Thus, claim objection as set forth in the previous office action has been waived.
Examiner’s remarks concerning applicant’s arguments on 35 U.S.C. 102 rejections.
The applicant’s argument regarding (remark pages 7-9):
Applicant’s arguments have been fully considered and are persuasive. However, upon further consideration, arguments are moot in view of new grounds of rejection necessitated by applicant amendments.
Examiner’s remarks concerning applicant’s arguments on 35 U.S.C. 103 rejections.
The applicant’s argument (remark page 9):
“Applicant submits that independent base Claims 1 and 11 are novel and non-obvious in view of Yamada and He. As such, Applicant submits that dependent Claims 3-9 and 13-19 are novel and non-obvious in view of the cited Yamada-He combination at least by virtue of their dependence…. Applicant submits that Claim 10 inherits the patentable features of independent base Claim 1 and Dubrovsky, alone or in combination with the references of record, does not cure the foregoing deficiencies.”.
The applicant is relying on the newly added amendments of the independent claims 1 and 11. Please see Examiner’s response above and the detail of the rejection.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3 - 9 and 11, 13 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yamada et al. (US-20150095628-A1 hereafter Yamada), in further view of Pike et al. (US-20180101565-A1 hereafter Pike).
Regarding claim 1 Yamada teaches a computer-implemented method comprising (see Yamada par.0099: “a computer-implemented method for detecting a return-oriented programming attack includes translating, by a processor component, a portion of a routine comprising a branch instruction based on an address at which the routine is stored in a storage of a computing device”.):
responsive to loading code of an executing application into memory (see Yamada par.0021: “the processor component 350 translates portions of one or both of the main routine 570 and the library 370 into translated portions of one or both that are stored in the translation cache 367 for execution. It is during translation that addresses of variables and targets of branch instructions are generally derived.”): and
based on the identified one or more call instructions, creating a list of one or more legitimate return instruction destinations (See Yamada par.0025: “the translation routine 340 may retrieve target addresses known to be valid from the entry point table 337 and/or the whitelist data 130 prior to translation or execution of one or more routines (e.g., the main routine 570) to pre-load the look-up table 334a with at least some valid target addresses.”), thereby identifying legitimate code paths of the application. (See Yamada par.0011: “to detect a return-oriented programming (ROP) attack by verifying target addresses of particular branch instructions
during execution.”).
Yamada does not disclose (i) causing execution of the application to pause and (ii) after the causing execution of the application to pause, identifying one or more call instructions in the code;
In this instance examiner notes the teaching of reference Pike.
With regards to applicant’s claim limitation element of, (i) causing execution of the application to pause and (ii) after the causing execution of the application to pause, identifying one or more call instructions in the code (see Pike par.0040-0042: “a canonical control flow graph (e.g., such as that built as described herein) is stored for a program. As described herein, the control flow graph can indicate the possible ordinary execution paths for a program. At 330, the stack is observed after interruption of execution of the program. For example, the program can be periodically interrupted during execution (e.g., by an operating system) to perform multiple repeated observations…Observation can include determining contents of the stack (e.g., contents of one or more stack frames)( identifying one or more call instructions).”,furthermore in par.[0058-0068]);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Yamada teaching “Various embodiments are generally directed to techniques to detect a return-oriented programming (ROP) attack by verifying target addresses of particular branch instructions during execution. More specifically, identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed. However, if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid, and possibly an indication of a ROP attack.”, (see Yamada par.0011) with Pike teaching because Pike teaching of, “it may be desirable to interrupt integrity checking (e.g., the method of FIG. 3, FIG. 12, etc.). For example, in the case of a real-time operating system, a limited amount of time may be available for performing integrity checking.”, (see Pike par.0118).
Regarding claim 11 is a system claim that recites similar limitations as the computer-implemented method claim 1 and is rejected based on the same rational as claim 1. a processor (see Yamada par. 0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units, chipsets,”); and
a memory with computer code instructions stored thereon, the processor and the memory, with the computer code instructions, being configured to cause the system to: (see Yamada par. 0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units,.. used in this application, the terms "system" and "component" are intended to refer to an entity of a computing device in which digital processing is carried out, that entity being hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by this depicted exemplary processing architecture. For example, a component can be, but is not limited to being, a process running on a processor
component, the processor component itself, a storage device (e.g., a hard disk drive, multiple storage drives in an array, etc.) that may employ an optical and/or magnetic storage medium, an software object, an executable sequence of instructions, a thread of execution, a program, and/or an entire computing device ( e.g., an entire computer).”).
Regarding claim 20 is a computer program product claim that recites similar limitations as the computer-implemented method claim 1 and is rejected based on the same rational as claim 1. one or more non-transitory computer readable storage devices and program instructions stored on at least one of the one or more storage devices, the program instructions, when loaded and executed by a processor, cause an apparatus associated with the processor to: (See Yamada par.0030-0031: “In various embodiments, the processor component 350 may include any of a wide variety of commercially available processors. Further, one or more of these processor components may include multiple processors, a multi-threaded processor, a multi-core processor (whether the multiple cores coexist on the same or separate dies), and/or a multi-processor architecture… the storage 360 may be based on any of a wide variety of information storage technologies, possibly including volatile technologies requiring the uninterrupted provision of electric power, and possibly including technologies entailing the use of machine-readable storage media that may or may not be removable.”, par. 0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units,.. used in this application, the terms "system" and "component" are intended to refer to an entity of a computing device in which digital processing is carried out, that entity being hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by this depicted exemplary processing architecture. For example, a component can be, but is not limited to being, a process running on a processor component, the processor component itself, a storage device (e.g., a hard disk drive, multiple storage drives in an array, etc.) that may employ an optical and/or magnetic storage medium, an software object, an executable sequence of instructions, a thread of execution, a program, and/or an entire computing device ( e.g., an entire computer).” furthermore par.0070 and 0071).
Regarding claim 3 Yamada in view of Pike disclose the method of Claim 1 Yamada further discloses further comprising, after creating the list of one or more legitimate return instruction destinations:
causing execution of the application to resume (see Yamada par.0026: “Upon determining that there is a match, the translation routine 340 permits that indirect branch instruction to be executed.”); and
controlling the execution of the application based on the created list of one or more legitimate return instruction destinations. (See Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed. However, if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid”, par.0026: “the translation routine 340 replaces an indirect branch instruction in those portions with a stub instruction that causes the flow of execution by the processor component 350 to be directed back to the translation routine 340. Such a stub instruction returns control of the flow of execution to the translation routine 340 to enable the translation routine 340 to check whether the target address to which that indirect branch instruction attempts to jump matches any of the known valid target addresses stored in the look-up table 334a”, par.0026: “It should be noted that in instances where an indirect branch instruction encountered during translation is a "call" instruction ( e.g., a call from a portion of the main routine 570 to a library function of the library 370), the translation routine 340 may additionally derive a known valid target address for the return instruction that is expected to accompany that call instruction, and store that known valid target address for that return instruction in the return look-up table 334b. Then, when the stub instruction associated with a return instruction expected to be associated with that call instruction is executed, the translation routine 340 checks whether the target address of the target to which the return instruction seeks to direct the flow of execution matches the valid target address stored in the return look-up table”).
Regarding claim 13 is a system claim that recites similar limitations as the computer-implemented method claim 3 and is rejected based on the same rational as claim 3. wherein the processor and memory, with the computer code instructions, are further configured to cause the system, (see Yamada par.0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units,.. used in this application, the terms "system" and "component" are intended to refer to an entity of a computing device in which digital processing is carried out, that entity being hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by this depicted exemplary processing architecture. For example, a component can be, but is not limited to being, a process running on a processor component, the processor component itself, a storage device (e.g., a hard disk drive, multiple storage drives in an array, etc.) that may employ an optical and/or magnetic storage medium, an software object, an executable sequence of instructions, a thread of execution, a program, and/or an entire computing device ( e.g., an entire computer).”).
Regarding claim 4 Yamada in view of Pike disclose the method of Claim 3 Yamada further discloses wherein controlling the execution of the application based on the created list of one or more legitimate return instruction destinations (See Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed. However, if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid”, par.0026: “the translation routine 340 replaces an indirect branch instruction in those portions with a stub instruction that causes the flow of execution by the processor component 350 to be directed back to the translation routine 340. Such a stub instruction returns control of the flow of execution to the translation routine 340 to enable the translation routine 340 to check whether the target address to which that indirect branch instruction attempts to jump matches any of the known valid target addresses stored in the look-up table 334a”, par.0026: “It should be noted that in instances where an indirect branch instruction encountered during translation is a "call" instruction ( e.g., a call from a portion of the main routine 570 to a library function of the library 370), the translation routine 340 may additionally derive a known valid target address for the return instruction that is expected to accompany that call instruction, and store that known valid target address for that return instruction in the return look-up table 334b. Then, when the stub instruction associated with a return instruction expected to be associated with that call instruction is executed, the translation routine 340 checks whether the target address of the target to which the return instruction seeks to direct the flow of execution matches the valid target address stored in the return look-up table”) comprises:
upon encountering a given return instruction, evaluating a given destination of the given return instruction (see Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed. However, if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid,”);
responsive to the evaluating determining the given destination is an approved destination, allowing execution of the application to continue (see Yamada par.0011: “during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed”); and
responsive to the evaluating determining the given destination is an unapproved destination (see Yamada par.0011: “during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed… if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid, and possibly an indication of a ROP attack.”): (i)
checking the given destination of the given return instruction against the list of one or more legitimate return instruction destinations (see Yamada par.0011: “a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s)…. if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid,”) and (ii) controlling the execution of the application based on the checking. (See Yamada par.0011: “during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s).”).
Regarding claim 14 is a system claim that recites similar limitations as the computer-implemented method claim 4 and is rejected based on the same rational as claim 4.
Regarding claim 5 Yamada in view of Pike disclose the method of Claim 4 Yamada further discloses wherein:
the approved destination is a destination previously determined to be in the list of one or more legitimate return instruction destinations (see Yamada par.0028: “an indirect branch instruction encountered during translation is a "call" instruction ( e.g., a call from a portion of the main routine 570 to a library function of the library 370), the translation routine 340 may additionally derive a known valid target address for the return instruction that is expected to accompany that call instruction, and store that known valid target address for that return instruction in the return look-up table 334b. Then, when the stub instruction associated with a return instruction expected to be associated with that call instruction is executed, the translation routine 340 checks whether the target address of the target to which the return instruction seeks to direct the flow of execution matches the valid target address stored in the return look-up table.”); and
the unapproved destination is a destination not previously determined to be in the list of one or more legitimate return instruction destinations. (See Yamada par.0050: “The comparison component 344 checks that the target address associated with that return instruction has a match in the return look-up table 334b that was earlier derived and stored therein in response to encountering the call instruction during translation,.. In a manner substantially similar to such checks made of target addresses derived during execution for matches among valid target addresses in the look-up table 334a, a failure to find a match to a target address associated with a return instruction in the return look-up table 334b may result in that target address being deemed an invalid target address, and again, the comparison component 344”).
Regarding claim 15 is a system claim that recites similar limitations as the computer-implemented method claim 5 and is rejected based on the same rational as claim 5.
Regarding claim 6 Yamada in view of Pike disclose the method of Claim 4 Yamada further discloses wherein controlling the execution based on the checking comprises:
responsive to the given destination being in the list of one or more legitimate return instruction destinations, allowing execution of the application to continue (see Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s). If there is a match, then the target address to which the branch instruction would direct the flow of execution is deemed valid and that indirect branch instruction is executed.”); and
responsive to the given destination not being in the list of legitimate return instruction destinations, declaring a security attack. (See Yamada par.0011: “identifiers of targets incorporated into particular indirect branch instructions of portions of routines are used to access table( s) of valid target addresses for targets for one or more routines to obtain known valid target addresses for each during translation and/or execution. Subsequently, during execution, a comparison is made between the target address to which the branch instruction would direct the flow of execution and the known valid target address retrieved from the table(s).if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid, and possibly an indication of a ROP attack.”).
Regarding claim 16 is a system claim that recites similar limitations as the computer-implemented method claim 6 and is rejected based on the same rational as claim 6.
Regarding claim 7 Yamada in view of Pike disclose the method of Claim 6 Yamada further discloses further comprising:
Responsive to declaring the security attack, implementing a protection action. (See Yamada par.0027: “lack of there being a match may be deemed an indication of a ROP attack, and the translation routine 340 may take one or more possible actions in response, those actions possibly specified in the policy data 135. Among those actions may be to attempt to find a match for the target address derived during execution among the valid target addresses in one or both of the entry point table 337 and the whitelist 130.”).
Regarding claim 17 is a system claim that recites similar limitations as the computer-implemented method claim 7 and is rejected based on the same rational as claim 7. wherein the processor and the memory, with the computer code instructions, are further configured to cause the system to: (see Yamada par.0069: “The processing architecture 3000 includes various elements commonly employed in digital processing, including without limitation, one or more processors, multi-core processors, co-processors, memory units,.. used in this application, the terms "system" and "component" are intended to refer to an entity of a computing device in which digital processing is carried out, that entity being hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by this depicted exemplary processing architecture. For example, a component can be, but is not limited to being, a process running on a processor component, the processor component itself, a storage device (e.g., a hard disk drive, multiple storage drives in an array, etc.) that may employ an optical and/or magnetic storage medium, an software object, an executable sequence of instructions, a thread of execution, a program, and/or an entire computing device ( e.g., an entire computer).”).
Regarding claim 8 Yamada in view of Pike disclose the method of Claim 7 Yamada further discloses wherein the protection action is at least one of:
blocking the given destination from being reached (see Yamada par.0011: “if there isn't a match, then the target address to which that indirect branch instruction would direct the flow of execution is deemed invalid.”);
terminating execution (see Yamada par.0027: “the possible actions may simply be to terminate execution of whatever routine that branch instruction belongs to.”); and
logging the given destination. (See Yamada par.0048: “In other embodiments, the comparison component 344 may signal the security routine 140 to perform an analysis of the main routine 570 to determine whether to continue execution of the main routine 570, including the branch instruction associated with the target address for which no match among known valid target addresses was found. Such continued execution may be the response where the main routine 570 is indicated as safe in the whitelist 130 or is in some other way determined by the security routine 140 to not be a security risk.”).
Regarding claim 18 is a system claim that recites similar limitations as the computer-implemented method claim 8 and is rejected based on the same rational as claim 8.
Regarding claim 9 Yamada in view of Pike disclose the method of Claim 6 Yamada further discloses wherein the security attack is a return-oriented programming attack or buffer overflow attack. (See Yamada par.0027: “if the target address derived during execution of the translated portion of whatever routine that was placed in the translation cache 367 has been somehow modified since that portion was translated and placed in the translation cache 367, then there will not be a match for the target address of the target to which that indirect branch instruction would direct the flow of execution with any of the valid target addresses in the look-up table 334a. In various embodiments, this lack of there being a match may be deemed an indication of a ROP attack,”).
Regarding claim 19 is a system claim that recites similar limitations as the computer-implemented method claim 9 and is rejected based on the same rational as claim 9.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Yamada et al. (US-20150095628-A1 hereafter Yamada), in further view of Dubrovsky et al. (US-20190347413-A1 hereafter Dubrovsky).
Regarding claim 10 Yamada in view of Pike disclose the method of Claim 1 do not explicitly teach however Dubrovsky teaches wherein the application is executed utilizing a Dynamic Binary Instrumentation (DBI) tool. (See Dubrovsky par.0033: “Dynamic binary instrumentation (DBI) is a method of analyzing the behavior of a binary application at runtime through the injection of instrumentation code. This instrumentation code executes as part of the normal instruction stream after being injected. Rather than considering what may occur, dynamic binary analysis has the benefit of operating on what actually does occur. While not necessarily exhaustive in terms of exercising all code paths in an application, DBI provides detailed insight into an application's concrete execution state.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Yamada in view of Pike teaching with Dubrovsky teaching because Dubrovsky teaching of, “Using a DBI framework, inserted program code can be used identify that a memory region is currently being allocated. The inserted program code may also access to information relating to all a set of pre-allocated memory that is associated with a certain computer process or set of computer data. As such, the DBI framework maintains visibility on memory regions as they are being written to. The DBI framework may also be aware of a current code execution path. All of this information may be used to identify that a particular memory region is being accessed that was previously written to. In an instance where a memory region has been overwritten since the region has been allocated to a particular process and consequently that same memory region is where the current code execution path reaches, then program code associated with the DBI framework can identify that dynamically unpacked code is being executed.”, (see Dubrovsky par.0038).
Conclusion
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
Lin et al. (US-11500981-B2) Enforcing shadow stack violations for dynamic code. A thread is executed at a processor, which includes generating a portion of dynamic code for execution by the thread, identifying a range of memory addresses where the portion of dynamic code is loaded in memory, and initiating execution of the portion of dynamic code. Based at least on execution of the thread, an exception triggered by a mismatch between a first return address popped from a call stack corresponding to the thread and a second return address popped from a shadow stack corresponding to the thread is processed. Processing the exception includes (i) determining whether the second return address popped from the shadow stack is within the identified range of addresses, and (ii) based on having determined that the second return address is within the range of addresses, initiating a shadow stack enforcement action.
Pan et al. (US-8117660-B2) cross-module detection system and method examine the branch instructions between modules, and build a model for each module which contains all the possible function starting addresses that can be referred to externally. A possible destination of an inter-module transfer is extracted from the binaries directly, and the set of destination addresses is used as the checking models. The extraction process is fast, and can be done either statically or dynamically. At run-time, when an inter-module control transfer is intercepted, it is checked against the checking model to see whether it is a legitimate entrance of the destination module. If the checking is successful, then the transfer continues; otherwise, an alert is generated.
Lotspeicht et al. (US-20210173921-A1) The embodiments disclosed herein propose hijacking program flow in a program binary by insert call checking CFI code before calling a target. Examples of a target can be a function within the program binary, a register, or a memory location. If the call target is a valid call target (e.g., included in a global list of addresses), normal program flow resumes and the program flow is transferred to the target. On the contrary, if the call target is not a valid call target (e.g., not included in a global list of addresses), the program binary is deliberately crashed.
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 DUILIO MUNGUIA whose telephone number is (571)270-5277. The examiner can normally be reached M-F 9:30AM - 5:00Pm.
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, Eleni A Shiferaw can be reached at (571) 272-3867. 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.
/DUILIO MUNGUIA/Examiner, Art Unit 2497 /ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497
Prosecution Insights