DETAILED ACTION
This action is made in response to the communication filed on April 05, 2024. This action is made non-final.
Claims 1-20 are pending. Claims 1, 11 and 16 are independent claims.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on April 05, 2024 is/are in compliance with the provisions of 37 CFR 1.97 and has/have been considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
6. Claim 5 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 5 recites the limitation "the function mapping table”. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 102
7. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
8. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
9. Claim 1, 2, 10, 11, 12, 16 and 17 are rejected under 35 U.S.C. § 102 (a)(2) as being anticipated by Le et al. (US 2023/0069035 A1), hereafter Le.
Regarding claim 1, Le discloses a method comprising: obtaining an input request to fence one or more program objects in a program code, wherein the program objects are disabled; {Le [Para. 0023] “FIG. 3 is a diagram depicting a basic block manager acting as a runtime agent that overwrites code in unneeded code blocks to thwart malevolent code reuse attacks.” [Para. 0024] “When the threshold is exceeded, the runtime agent determines which basic blocks to inactivate from memory 320.” [Para. 0025] “When the runtime agent inactivates a basic block from memory, a set of trap code (instructions) are written to the memory area where the inactivated block resided.” [Para. 0049] “Aspects may be embodied as a system, method...”} As indicated in Le, a runtime agent deactivates a basic code block in memory, and then overwrites that area with trap code. Code within an inactive code block serves as an example of disabled program objects.
identifying, based on the input request, code areas of the one or more disabled program objects that should be fenced off; {Le [Para. 0025] “When the runtime agent inactivates a basic block from memory, a set of trap code (instructions) are written to the memory area where the inactivated block resided.” [Para. 0035] “The process determines as to whether the selected basic block is the starting block (decision 530).” [Para. 0037] “When the selected basic block is not the starting block then, at step 550, the process writes trap code at selected block's starting address. This trap code, when executed, traps back to the basic block manager to inform the manager that the block has been called and the basic block manager takes care of writing the correct code to the memory space.”} The runtime agent identifies the starting address of the inactive code block in memory to insert a trap code, subsequently writing it at that location.
and inserting hard fencing code for fencing the code areas to generate fenced code areas, wherein hardware cannot execute code within the fenced code areas. {Le [Para. 0025] “When the runtime agent inactivates a basic block from memory, a set of trap code (instructions) are written to the memory area where the inactivated block resided. In one embodiment, the remainder of the memory area where the inactivated block resided is written over (e.g., writing zeros to all memory in the memory area except for the trap code, etc.).” [Para. 0037] “When the selected basic block is not the starting block then, at step 550, the process writes trap code at selected block's starting address.” [Para. 0045] “Step 680 and 685 are performed when the number of types of code in the active basic blocks exceeds the threshold. At step 680, the process identifies one or more types of code to remove from memory area 320 so that the number of types of code found in memory area 320 is within the allowed threshold. At step 685, the process removes the basic blocks associated with identified types of code by writing trap code to the memory spaces of the basic blocks being inactivated and further marks each of these basic blocks as being ‘inactive’ in basic block metadata 310.”} A runtime agent disables a code block in memory, then overwrites it with trap code. Inserting this trap code creates fenced area, and this is analogous to applying hard fencing to the inactive code block.
Claim 2:
Regarding claim 2, Le discloses the elements of claim 1 as outlined above.
Le further teaches wherein obtaining the input request further comprises receiving the input request from one of a parameter library, a command line, a Graphical User Interface (GUI), an automation function, or system interrupt. {Le [Para. 0025] “When the runtime agent inactivates a basic block from memory, a set of trap code (instructions) are written to the memory area where the inactivated block resided.” [Para. 0040] “At predefined process 580, the process performs the Enforce Thresholding routine… If the threshold is breached, then this routine operates to inactivate one or more basic blocks so that the number of “active” types of program instructions does not exceed the threshold. “ [Para. 0045] “At step 680, the process identifies one or more types of code to remove from memory area 320 so that the number of types of code found in memory area 320 is within the allowed threshold. At step 685, the process removes the basic blocks associated with identified types of code by writing trap code to the memory spaces of the basic blocks being inactivated and further marks each of these basic blocks as being ‘inactive’ in basic block metadata 310.”} A runtime agent disables a code block in memory, then overwrites it with trap code. The runtime agent performs this process without direct human intervention.
Claim 10:
Regarding claim 10, Le discloses the elements of claim 1 as stated.
Le further discloses receiving an input request to unfence one or more program objects in the program code; and applying hard fencing code to unfence the fenced code areas, enabling execution of program instructions within the unfenced code areas. {Le [Para. 0041, FIG. 6] “A trap is encountered when an actively running basic block makes a call to a basic block that has been inactivated with the code at the inactivated block being trap code that calls the basic block manager so that the basic block manager can load the code into the memory space of the requested basic block and then execute the basic block.” [Para. 0042] “At step 610, the process retrieves the metadata and the basic block code for the basic block that is being requested.” [Para. 0043] “At step 650, the process writes the basic block code to the assigned memory address area in memory area 320 that is used for running basic blocks with the writing overwriting the trap code that was previously found at the starting address location of the requested basic block. At step 660, the process marks block as ‘active’ in the metadata which is stored in memory area 310.” [Para. 0046] “At step 690, the process executes the requested basic block.”} Also see para. 0026. A runtime agent disables a code block in memory and overwrites it with trap code. Later, when another active code block attempts to call the now-inactive code block, the runtime agent loads the original code back into memory, overwrites the trap code, activates the inactive code block , and then executes the active block.
Claims 11 and 12 :
Regarding claims 11 and 12, the claims are directed to a computer system that performs the operation recited by claims 1 and 2. Therefore, the rejection applied to claims 1 and 2 also applies to claims 11 and 12. Claims 1 and 2 are rejected under the same rationale as claims 11 and 12.
Claims 11 further recites a system, one or more computer processors; and a memory containing a program which when executed by the one or more computer processors performs an operation, the operation recited by claim 1. {Le [Para. 0016] “Information handling system 100 includes one or more processors 110 coupled to processor interface bus 112. Processor interface bus 112 connects processors 110 to Northbridge 115. Northbridge 115 connects to system memory 120 and provides a means for processor(s) 110 to access the system memory.”}
Claims 16 and 17:
Regarding claims 16 and 17, the claims are directed to a computer readable storage medium containing instructions for performing the operation recited by claims 1 and 2. Therefore, the rejection applied to claims 1 and 2 also applies to claims 16 and 17. Claim 1 and 2 are rejected under the same rationale as claims 16 and 17.
Claim 16 further recites a computer program product comprising a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code executable by one or more computer processors to perform an operation comprising: the operations recited by claim 1. {Le [Para. 0049] “Present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.” [Para. 0050]. “A computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.”}
Claim Rejections - 35 USC § 103
10. 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.
11. 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.
13. Claims 3, 7, 8, 13, 14, 18 and 19 are rejected under 35 U.S.C. § 103 as being unpatentable over Le as applied to claim 1, 11 and 16 and further in view of Gupta (US 2018/0004950 A1), hereafter Gupta.
Regarding claim 3, Le teaches the elements of claim 1 as outlined above.
Le further teaches wherein identifying, based on the input request, the code areas to be fenced of the one or more disabled program objects comprises… {Le [Para. 0025] “When the runtime agent inactivates a basic block from memory, a set of trap code (instructions) are written to the memory area where the inactivated block resided.” [Para. 0037] “When the selected basic block is not the starting block then, at step 550, the process writes trap code at selected block's starting address.”} The runtime agent identifies the starting address of an inactive code block in memory to insert a trap code, subsequently writing it at that location.
However, Le does not teach identifying registered functions and tagging code modules related to the registered functions for the one or more disabled program objects.
However, Gupta teaches identifying registered functions and tagging code modules related to the registered functions for the one or more disabled program objects. {Gupta [Para. 42] “As specific functionality for a computer application is exercised, the host system, in turn, executes the code blocks corresponding to the functionality. The instrumentation engine captures the generated instructions (e.g., assembly code instructions) for each code block. As shown in FIG. 4, the instrumentation engine records an enumeration for each executed code block in the golden table. Further, the instrumentation engine records the start memory address and end memory address for the range of captured instructions for the respective code block.” [Para. 43] “In this embodiment the golden table contains memory addresses for all the active code blocks, however, in other embodiments, the golden table may instead contain the memory addresses for all the inoperative code blocks.”} Gupta’s system identifies unused software functionalities and disables the corresponding code. In one embodiment, the golden table stores the memory addresses for code blocks associated with unused software functionalities.
Gupta is analogous art because each of Le and Gupta pertains to implementing a fencing method to block malware. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le to include Gupta’s teaching of identifying registered functions and tagging code modules related to the registered functions for disabled program objects. Doing so would “reduce the attackable code surface of the application” (Gupta, para. 0035).
Claim 7:
Regarding claim 7, Le teaches the elements of claim 1 as outlined above.
However, Le does not teach wherein inserting hard fencing code for fencing the code areas further comprises testing the code areas of the one or more program objects to identify sensitive code in the code areas to be fenced; and identifying a fencing method based on identifying sensitive code in the code areas to be fenced.
However, Gupta teaches wherein inserting hard fencing code for fencing the code areas further comprises testing the code areas of the one or more program objects to identify sensitive code in the code areas to be fenced; and identifying a fencing method based on identifying sensitive code in the code areas to be fenced. {Gupta [Para. 0049] “Based on the functionality testing 520, the instrumentation engine may perform negative testing 540 to further capture instructions related to the need functionality for the organization. Negative testing 540 tests the handling of invalid input or unexpected behavior in regards to the needed functionality (e.g., exception handling).” [Para. 0034] “In some embodiments, the instrumentation engine permanently changes the instructions to inoperative, and in other embodiments, the instrumentation engine temporarily changes the instructions to inoperative. The instrumentation engine may change the respective instructions to inoperative by overwriting the instructions with inoperative instructions during runtime or during load time. In some embodiments, the instrumentation engine may determine to overwrite the respective instructions at either runtime or load time based on the source code being self-generating or interpretive source code. The instructions engine may change the respective instructions to inoperative by overwriting the instruction with an inoperative instruction (or NOP) or equivalent inoperative instruction.” [Para. 0052] “The instrumentation engine 570 may be configured in online lockdown mode 575 for overwriting unused instructions for the application. The instrumentation engine 570 may be configured to temporarily or permanently overwrite each unused instruction.” [Para. 0053] “If the application does contain self-generating or interpretive code, then the instrumentation engine 570 may perform the application lockdown during runtime (i.e., in real time).”} Gupta’s system identifies unused software functionalities and disables the corresponding code. The instrumentation engine may permanently or temporarily overwrite unused code with inoperative instructions. It may perform the overwriting during runtime or load time depending on whether the source code contains self-generating and interpretive code. An application that has self-generating or interpretive code has a higher chance of being exploited compared to an application that does not.
Gupta is analogous art because each of Le and Gupta pertains to implementing a fencing method to block malware. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le to include Gupta’s teaching of the limitations of claim 7, listed above. Doing so would “reduce the attackable code surface of the application” (Gupta, para. 0035).
Claim 8:
Regarding claim 8, Gupta teaches the elements of claim 7 as outlined above.
Le further teaches wherein the code removal fencing method comprises one of using encryption fencing method for encrypting the code in the code areas, or using an overwriting fencing method for overwriting the code in the code areas. {Le [Para. 0025] “When the runtime agent inactivates a basic block from memory, a set of trap code (instructions) are written to the memory area where the inactivated block resided. In one embodiment, the remainder of the memory area where the inactivated block resided is written over (e.g., writing zeros to all memory in the memory area except for the trap code, etc.).”}
However, Le does not teach wherein identifying the fencing method further comprises identifying a code removal fencing method, based on identifying sensitive code in the code areas to be fenced.
However, Gupta teaches wherein identifying the fencing method further comprises identifying a code removal fencing method, based on identifying sensitive code in the code areas to be fenced; [Para. 0034] “In some embodiments, the instrumentation engine permanently changes the instructions to inoperative, and in other embodiments, the instrumentation engine temporarily changes the instructions to inoperative. The instrumentation engine may change the respective instructions to inoperative by overwriting the instructions with inoperative instructions during runtime or during load time. The instructions engine may change the respective instructions to inoperative by overwriting the instruction with an inoperative instruction (or NOP) or equivalent inoperative instruction.” [Para. 0053] “If the application does contain self-generating or interpretive code, then the instrumentation engine 570 may perform the application lockdown during runtime (i.e., in real time).”} The instrumentation engine may permanently or temporarily overwrite unused code with inoperative instructions. It may perform the overwriting during runtime or load time depending on whether the source code contains self-generating and interpretive code. An application that has self-generating or interpretive code has a higher chance of being exploited compared to an application that does not.
Gupta is analogous art because each of Le and Gupta pertains to implementing a fencing method to block malware. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le to include Gupta’s teaching of the limitations of claim 8, listed above. Doing so would “reduce the attackable code surface of the application” (Gupta, para. 0035).
Claims 13 and 14 :
Regarding claims 13 and 14, the claims are directed to a computer system that performs the operation recited by claims 7 and 8. Therefore, the rejection applied to claims 7 and 8 also applies to claims 13 and 14. Claims 7 and 8 are rejected under the same rationale as claims 13 and 14.
Claims 18 and 19:
Regarding claims 18 and 19, the claims are directed to a computer readable storage medium containing instructions for performing the operation recited by claims 7 and 8. Therefore, the rejection applied to claims 7 and 8 also applies to claims 18 and 19. Claim 7 and 8 are rejected under the same rationale as claims 18 and 19.
14. Claims 4, 5 and 6 are rejected under 35 U.S.C. § 103 as being unpatentable over Le and Gupta as applied to claims 1 and 3, and further in view of Boling et al. (US 2022/0309134 A1), hereafter Boling.
Regarding claim 4, Gupta teaches the elements of claim 3 as stated.
However, Le and Gupta do not teach creating a code path mapping table for each registered function, based on identifying registered functions and tagging the object code modules, comprising code areas of code modules corresponding to registered functions for the one or more program objects.
However, Boling teaches creating a code path mapping table for each registered function, based on identifying registered functions and tagging the object code modules, comprising code areas of code modules corresponding to registered functions for the one or more program objects. {Boling [Para. 0088] “As the compiler 205 translates source code into executable code,.. mark a boundary between one or more instructions of a function and one or more instructions that implement calling convention operations. Such boundaries may be used, during initialization to tag certain instructions as function prologue or function epilogue.” [Para. 0093] “The policy linker 225 may be programmed to process object code, policy code, and/or a target description, to output an initialization specification.”[Para. 0094] “The target description may include descriptions of… named entities. A named entity may represent a software component, such as a function, a module, a driver, a service routine, etc.” [Para. 0095] “The policy linker 225 may identify descriptions of those entities from the target description, and use the descriptions to annotate, with appropriate metadata symbols, the object code output by the linker 210.” [Para. 0096] “The policy compiler 220 may match an entity name in an “init” statement of a policy to be enforced to an entity description in the target description.” [Para. 0097] “The loader 215 may load data and/or instructions into the application memory 120, and may use the initialization specification to identify metadata labels associated with the data and/or instructions being loaded into the application memory 120.” [Para. 0100] “The loader 215 may create an entry in the tag map table 142 that maps an application memory address where an instruction is stored in the application memory 120, to a metadata memory address where metadata associated with the instruction is stored in the metadata memory 125. Alternatively, the loader 215 may store metadata in the tag map table 142 itself.”} Boiling’s system generates a metadata table (e.g., tag map table 142) that associates specific metadata tags with application memory addresses for functions in an object code file.
Boling is analogous art because each of Le, Gupta and Boling pertains to implementing security measures to detect and prevent malicious 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 Le and Gupta to include Boling’s teaching of the limitations of claim 4, listed above. Doing so would “prevent malicious attacker code from loading an illegitimate binary image” (Boling, para. 202).
Claim 5:
Regarding claim 5, Boling teaches the elements of claim 4 as outlined above.
However, Le and Gupta do not teach creating a fence-code table, based on the function mapping table, comprising the code areas of the code modules of each registered function and a status of fenced or not fenced.
However, Boling teaches creating a fence-code table, based on the function mapping table, comprising the code areas of the code modules of each registered function and a status of fenced or not fenced. {Boling [Para. 0063] “By mapping application memory addresses to metadata memory addresses, the tag map table 142 may create an association between application data and metadata that describes the application data. Metadata stored at the metadata memory address Y and thus associated with application data stored at the application memory address X may indicate that the application data may be readable, writable, and/or executable.” [Para. 0100] “Alternatively, the loader 215 may store metadata in the tag map table 142 itself.” [Para. 0095] “The policy linker 225 may identify descriptions of those entities from the target description, and use the descriptions to annotate, with appropriate metadata symbols, the object code output by the linker 210. For instance, the policy linker 225 may apply a Read label to a .rodata section of an Executable and Linkable Format (ELF) file,… and an Execute label to a .text section of the ELF file. Such information may be used to enforce a policy for memory access control and/or executable code protection (e.g., by checking read, write, and/or execute privileges).”} Boiling’s tag map table 142 associates specific metadata tags with application memory addresses for functions in an object code file. An “Execute” metadata tag on an application memory address indicates the function can run. Consequently, the function’s status is not fenced.
Boling is analogous art because each of Le, Gupta and Boling pertains to implementing security measures to detect and prevent malicious 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 Le and Gupta to include Boling’s teaching of the limitations of claim 5, listed above. Doing so would “prevent malicious attacker code from loading an illegitimate binary image” (Boling, para. 202).
Claim 6:
Regarding claim 6, Boling teaches the elements of claim 5 as outlined above.
However, Le and Boling do not teach wherein inserting hard fencing code for fencing the code areas to provide fenced code areas further comprises applying hard fencing code to the code areas of the code modules of each disabled registered function that is not fenced.
However, Gupta teaches wherein inserting hard fencing code for fencing the code areas to provide fenced code areas further comprises applying hard fencing code to the code areas of the code modules of each disabled registered function that is not fenced. {Gupta [Para. 0028] “The method 200 begins at step 220 by an instrumentation engine determining a set of instructions from the available instructions for the computer application.” [Para. 0030] “As the code blocks corresponding to the functionality are executed, the instrumentation engine studies the behavior of the code and captures the generated instructions (e.g., assembly code instructions) for the code. For each code block, the instrumentation engine may store the memory addresses for the generated instructions in tables, such as in golden tables of an instrumentation database.” [Para. 0033] “At step 240, for each available instruction not in the set of instructions, the instrumentation engine changes the respective instruction to inoperative. The instrumentation engine retrieves the memory addresses for the set of instructions determined in step 220. The instrumentation engine may then traverse the complete range of memory addresses for the application. If a traversed memory address does not correspond to a memory address retrieved for the set of active instruction, then the instrumentation engine changes the respective instruction to inoperative.” [Para. 0034] “The instructions engine may change the respective instructions to inoperative by overwriting the instruction with an inoperative instruction (or NOP) or equivalent inoperative instruction.”} Also see para. 44 and 52. Gupta’s system identifies unused software functionalities and disables the corresponding code.
Gupta is analogous art because each of Le, Boling and Gupta pertains to implementing security measures to detect and prevent malicious 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 Le and Boling to include Gupta’s teaching of applying hard fencing code to code areas of code modules of each disabled registered function that is not fenced. Doing so would “reduce the attackable code surface of the application” (Gupta, para. 0035).
15. Claims 9, 15 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Le and Le as applied to claims 1, 7, 11, 13, 16 and 19 and further in view of Duale et al. (US2018/0173880 A1), hereafter Duale.
Regarding claim 19, Le and Gupta teaches the elements of claim 7 as stated.
However, Le and Gupta do not teach wherein identifying the fencing method further comprises identifying, based on not identifying sensitive code in the code areas to be fenced, a fencing method using a processor hardware based function that sets a non-executable state for the fenced code areas, where the processor hardware based function comprises using Instruction Execution Protection (IEP).
However, Duale teaches wherein identifying the fencing method further comprises identifying, based on not identifying sensitive code in the code areas to be fenced, a fencing method using a processor hardware based function that sets a non-executable state for the fenced code areas, where the processor hardware based function comprises using Instruction Execution Protection (IEP). {Duale [Para. 0004] “A computer-implemented method includes executing one or more tests on a computing device. The computing device has Instruction Execution Protection (IEP), and each test of the one or more tests includes selectively setting one or more IEP bits of one or more page tables, where each IEP bit prevents code in a respective storage block from being executed.”} Paras. 0020 and 0023 provide additional details about the IEP disclosed in Duale.
Duale is analogous art because each of Le, Gupta and Duale pertains to implementing a fencing method to block malware. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le and Gupta to include Duale’s teaching of a fencing method using a processor hardware based function that sets a non-executable state for fenced code areas using IEP. Doing so could “ensure that IEP is operating as expected on each computing device onto which is incorporated” (Duale, para. 0018).
Conclusion
16. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIN QING ZHENG whose telephone number is (703)756-1535. The examiner can normally be reached on M-F 9:30 am - 05:30 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip J. Chea can be reached on 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BIN QING ZHENG/
Examiner, Art Unit 2499
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights