DETAILED ACTION
This action is in response to the claims filed October 8, 2025. Claims 1-20 are pending. Claims 1, 8, and 15 are independent claims. Claims 1, 4, 5, 7, 8, 11, 12, 14, 15, 18, and 19 have been amended.
The 35 U.S.C. 101 rejections to claims 1-20 are withdrawn in view of Applicant’s arguments and amendments to the 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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-10, 12-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 5901308 A (hereinafter “Cohn”) in view of US 5822787 A (hereinafter “Zucker”), further in view of US 5960198 A (hereinafter “Roediger”), further in view of “Profiling Concurrent Programs” by Denda (hereinafter “Denda”).
Regarding claim 1, Cohn discloses:
A method comprising (Fig. 4):
compiling human-readable source code to generate hardware-executable program code (Column 4, lines 37-42, “The compiler of FIG. 1 is shown to include 3 functional units: a translator 16a, an optimizer unit 16b and a scheduler unit 16c. The translator 16a uses information about the instruction set of the CPU to translate the application from a high level language representation into an instruction stream executable by the CPU [compiling human-readable source code to generate hardware-executable program code]”);
receiving, by a processing device, the hardware-executable program code comprising a plurality of program code instructions, wherein the plurality of program code instructions comprises at least one profiling instruction (Abstract, “The executable file is run using a number of representative data sets to profile information identifying those instructions that result in exceptions…”; Column 3, lines 32-37, “During execution of the compiled application with the representative data sets, instructions causing exceptions are identified, and the translation table is updated to indicate which of the individual instructions caused exceptions during the execution. The profile data stored in the translation table is then used to guide the compiler during recompilation of the application… [receiving, by a processing device, the hardware-executable program code comprising a plurality of program code instructions, wherein the plurality of program code instructions comprise at least one profiling instruction…]”), …
…
- identifying a memory location in the persistent memory region in view of a profiling identifier included in the at least one profiling instruction (Column 3, lines 30-32, “Each entry of the translation table identifies location of the corresponding instruction in a memory. During execution of the compiled application with the representative data sets, instructions causing exceptions are identified, and the translation table is updated to indicate which of the individual instructions caused exceptions during execution”; Column 7, lines 43-45, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated” [identifying a memory location in the persistent memory region in view of a profiling identifier included in the at least one profiling instructions]) [Examiner’s remarks: Profiling instructions include finding lines with exceptions, and updating the program counter at the location, which associates the profiling instruction with a profiling identifier.];
- storing profiling information corresponding to the at least one profiling instruction at the memory location (Column 7, lines 43-45, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated [storing profiling information corresponding to the at least one profiling instruction at the memory location]”[Examiner’s remark: The profiling information (the counter) is stored back where it was retrieved.]);
- …updating the profiling information based on … the at least one profiling instruction (Column 7, lines 43-45, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated […updating the profiling information based on … the at least one profiling instruction]”[Examiner’s remark: The counter is updated based on the profiling instruction (there being an exception).]);
- accessing the profiling information at the memory location in the persistent memory region; and generating optimized program code based on the profiling information (Column 7, lines 6-16, “Once the instructions likely to cause exceptions have been detected, the method, according to this invention, reduces the occurrence of speculative exceptions by identifying those instructions most likely to cause exceptions, and precluding the re-scheduling of those instructions. Referring again to FIG. 1, upon completion of the initial compilation process, the compiler 16 outputs an executable file 25, representing the optimized application in scheduled, instruction set format. In addition, the compiler outputs a translation table 20. The translation table 20 includes an entry for each instruction”; Column 7, lines 43-45, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated”; Column 7, Lines 55-63, “After the PC logs have been merged, the speculation table 19 is then addressed using the program counters in the PC Log 23 to cross reference the translation table 20 to provide the appropriate instruction tags. The number of exceptions caused by each instruction in the profiling run are stored in the speculation table with the corresponding instruction tag An example entry in the speculation table is shown in FIG. 2B to include a TAG field 34 an Exception Count 35, and Speculation Semaphore 36”) [Examiner’s remarks: Profiling information is accessed and used to generate an executable file of the optimized code.].
Cohn does not explicitly disclose:
…
… wherein the hardware-executable program code is loaded from an executable program file that specifies an address of a persistent memory region;
verifying that profiling is enabled for the hardware-executable program code based on the address of the persistent memory region; and
executing the at least one profiling instruction concurrently in multiple runs, wherein executing the at least one profiling instruction concurrently in multiple runs comprises:
…
- concurrently … the multiple runs …;
However, Zucker discloses:
…wherein the hardware-executable program code is loaded from an executable program file that specifies an address of a persistent memory region (Column 8, lines 5-9, “The program 44 comprises at least one executable file that conventionally begins at program base of 32 megabytes. The virtual address space between 32 megabytes and 2 gigabytes is utilized by the program [wherein the program code is loaded form an executable program that specifies a persistent memory region]”) [Examiner’s remarks: The executable file specifies the region beginning at 32 megabytes as it’s memory region and address.];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zucker into the teachings of Cohn to include “… wherein the program code is loaded from an executable program file that specifies an address of a persistent memory region”. As stated in Zucker, “to execute properly, a module containing position dependent machine code must be loaded at a specific virtual address, in order to make the program’s absolute addresses coincide with the processor’s virtual address” (Column 1, lines 58-61). The ability to translate from virtual address space to an address in persistent memory is important given differences between processors and addressing conventions. Using a virtual memory space gives programs more flexibility in running, and determining the location of the persistent memory block helps to calculate save locations in persistent memory. Thus, it would be obvious to one of ordinary skill in the art of compilers to combine a profiler with the ability to locate a code block in persistent memory and use virtual addressing to determine a location to save data.
The combination of Cohn and Zucker disclose the address of the persistent memory region. The combination of Cohn and Zucker does not explicitly disclose:
verifying that profiling is enabled for the hardware-executable program code based on the address of the persistent memory region; and
executing the at least one profiling instruction concurrently in multiple runs, wherein executing the at least one profiling instruction concurrently in multiple runs comprises:
…
- concurrently … the multiple runs …;
However, Roediger discloses:
verifying that profiling is enabled for the hardware-executable program code based on the address of the persistent memory region (Column 2, line 63-Column 3, line 2, “The above may be accomplished by having the enabling mechanism insert at least one instruction into the second instruction stream that causes a control bit in a condition register to be examined to determine if the instrumentation code should or should not be executed. The instruction(s) can then cause program control to branch past the instrumentation code if the control bit is not enabled [verifying that profiling is enabled for the hardware-executable program code]”; Column 7, lines 19-30, “In the preferred embodiment, the profile enabling bit 11 is implemented from a condition register 21 in the processor used for executing instrumented program 28. It should be recognized however, that while a condition register 21 is used for the preferred embodiment, any globally dedicated register could likewise be used as a substitute as long as it is addressable during execution by both the program 28 being executed and the profile control mechanism 20. Moreover, the bit need not be part of a register, but may comprise any memory space that is available and addressable by both the program 28 and the control mechanism 20 [based on the [address]]”) [Examiner’s remarks: The combination of Cohn and Zucker discloses executable code saved at a specific address in persistent memory. Roediger discloses verifying that profiling is enabled based on an address, which may include any address in memory that the program has access to. One of ordinary skill in the art may combine the memory address of Cohn and Zucker with that of Roediger to put the control bit in the specified memory region as both are locations in memory.]; and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Roediger into the combined teachings of Cohn and Zucker to include “verifying that profiling is enabled for the hardware-executable program code based on the address of the persistent memory region”. As stated in Roediger, “Because operating systems must fulfill a variety of tasks (e.g., booting the system, launching application programs, interfacing with hardware devices, etc.), the continuous collection of profile data may be inappropriate when attempting to examine the performance characteristics of specific tasks” (Column 2, lines 26-31). Verifying that profiling is enabled allows for finer control on when profiling is performed. It allows profiling instructions to be skipped when the system is not in a state where profiling is appropriate, or may generate false profiling data. Thus, it would be obvious to one of ordinary skill in the art of compilers to combine a profiler with the ability to verify that profiling is enabled for a particular piece of executable code.
The combination of Cohn, Zucker, and Roediger does not explicitly disclose:
executing the at least one profiling instruction concurrently in multiple runs, wherein executing the at least one profiling instruction concurrently in multiple runs comprises:
…
- concurrently … the multiple runs …;
However, Denda discloses:
executing the at least one profiling instruction concurrently in multiple runs, wherein executing the at least one profiling instruction concurrently in multiple runs comprises (Page 9, “The counter is represented by a data structure named “Count", which is incremented before the thread of control traverses the code segment”; Page 9, “When profiling concurrent programs in shared memory, additional issues have to be considered. If the profiler uses shared data structures for the inserted primitives, the primitives must provide mutual exclusion to avoid corruption of the data”; Page 17, “In this case, the inserted instrumentation consists of only basic instrumentation primitives and their corresponding profiling data structures, the locations of which are known by the monitoring profiler. According to the selected profiling metric, these primitives operate on their data structures, and the profiler periodically reads the data structures' values. This approach allows sampling data structures internal to the profiled program, because the sampled state information is available to the profiled threads, which execute the instrumentation primitives and update their corresponding profiling data structures”) [Examiner’s remarks: Profiling may be done on concurrent programs with multiple threads. The same profiling instructions may be run on all the threads with consideration for thread safety.]:
- - concurrently … the multiple runs … (Page 9, “The counter is represented by a data structure named “Count", which is incremented before the thread of control traverses the code segment”; Page 9, “When profiling concurrent programs in shared memory, additional issues have to be considered. If the profiler uses shared data structures for the inserted primitives, the primitives must provide mutual exclusion to avoid corruption of the data”; Page 17, “In this case, the inserted instrumentation consists of only basic instrumentation primitives and their corresponding profiling data structures, the locations of which are known by the monitoring profiler. According to the selected profiling metric, these primitives operate on their data structures, and the profiler periodically reads the data structures' values. This approach allows sampling data structures internal to the profiled program, because the sampled state information is available to the profiled threads, which execute the instrumentation primitives and update their corresponding profiling data structures”) [Examiner’s remarks: The profiling information (profiling data structures) are updated based on multiple runs of a profiling instruction (inserted instrumentation) in a concurrent program.];
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Denda into the combined teachings of Cohn, Zucker, and Roediger to include “executing the at least one profiling instruction concurrently in multiple runs, wherein executing the at least one profiling instruction concurrently in multiple runs comprises” and “concurrently … the multiple runs …;”. As stated in Denda, “This process of performance optimization encompasses different aspects and involves the application of several methodologies, the main one being profiling. In addition to performance optimization, profiling serves many other purposes: for example, it can help understand the underlying concurrent algorithm of a program, help discover faulty execution behaviour, and thereby, provide support for debugging, or supply information for a coverage analysis” (Page 2). Profiling concurrent programs helps to mitigate runtime bottlenecks, and my also assist in debugging difficult to debug concurrent code. Thus, it would be obvious to one of ordinary skill in the art of compilers to combine a profiler with concurrent programming.
Regarding claim 2, the rejection of claim 1 is incorporated; and Cohn does not explicitly disclose:
- receiving, from an operating system kernel, a pointer to the persistent memory region.
However, Zucker discloses:
- receiving, from an operating system kernel, a pointer to the persistent memory region (Column 1, lines 27-31, “In order to set out the background of the present invention, for illustrative purposes, the following description relates to a Motorola PowerPC 601 Reduced Instruction Set Computer (RISC) microprocessor running under the UNIX System C, Release 4, operating system…”; Column 9, lines 64-67, “For the PowerPC microprocessor 10, the symbol _GLOBAL_OFFSET_TABLE_ may be used to access the table 112. The value of this symbol is the absolute base address of the table 112 in virtual memory [receiving, from an operating system kernel, a pointer to the persistent memory region]”) [Examiner’s remarks: The PowerPC is connected to an UNIX operating system which uses _GLOBAL_OFFSET_TABLE_ as the pointer to a persistent memory region (base address).].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zucker into the teachings of Cohn to include “receiving, from an operating system kernel, a pointer to the persistent memory region”. As stated in Zucker, “to execute properly, a module containing position dependent machine code must be loaded at a specific virtual address, in order to make the program’s absolute addresses coincide with the processor’s virtual address” (Column 1, lines 58-61). The ability to translate from virtual address space to an address in persistent memory is important given differences between processors and addressing conventions. Using a virtual memory space gives programs more flexibility in running, and determining the location of the persistent memory block helps to calculate save locations in persistent memory. Thus, it would be obvious to one of ordinary skill in the art of compilers to combine a profiler with the ability to locate a code block in persistent memory and use virtual addressing to determine a location to save data.
Regarding claim 3, the rejection of claim 2 is incorporated; and Cohn further discloses:
wherein identifying the memory location in the persistent memory region comprises (Column 3, lines 30-32, “Each entry of the translation table identifies location of the corresponding instruction in a memory. During execution of the compiled application with the representative data sets, instructions causing exceptions are identified, and the translation table is updated to indicate which of the individual instructions caused exceptions during execution”; Column 7, lines 43-45, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated”):
Cohn does not explicitly disclose:
- determining the memory location as a sum of the pointer to the persistent memory region and an offset determined in view of the profiling identifier.
However, Zucker discloses:
- determining the memory location as a sum of the pointer to the persistent memory region and an offset determined in view of the profiling identifier (Column 2, lines 28-32, “The global offset table stores the absolute virtual addresses of these data, and data within it is references by adding the absolute base addresses of the global offset table (GOT pointer) and the index or relative offset of the data into the table [determining the memory location as a sum of the pointer to the persistent memory region and an offset determined in view of the profiling identifier]”) [Examiner’s remarks: Zucker discloses adding a base address (pointer to the persistent memory) to an index or relative offset of the data in the table (offset). Cohn teaches a hash table associated with the profiling identifier.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Zucker into the teachings of Cohn to include “determining the memory location as a sum of the pointer to the persistent memory region and an offset determined in view of the profiling identifier”. As stated in Zucker, “to execute properly, a module containing position dependent machine code must be loaded at a specific virtual address, in order to make the program’s absolute addresses coincide with the processor’s virtual address” (Column 1, lines 58-61). The ability to translate from virtual address space to an address in persistent memory is important given differences between processors and addressing conventions. Using a virtual memory space gives programs more flexibility in running, and determining the location of the persistent memory block helps to calculate save locations in persistent memory. Thus, it would be obvious to one of ordinary skill in the art of compilers to combine a profiler with the ability to locate a code block in persistent memory and use virtual addressing to determine a location to save data.
Regarding claim 5, the rejection of claim 1 is incorporated; and Cohn further discloses:
wherein the at least one profiling instruction is associated with a parameter that specifies a particular memory location (Column 3, lines 32-37, “During execution of the compiled application with the representative data sets, instructions causing exceptions are identified, and the translation table is updated to indicate which of the individual instructions caused exceptions during the execution. The profile data stored in the translation table is then used to guide the compiler during recompilation of the application…”), and wherein the method further comprises:
- reading a value of the particular memory location (Column 7, lines 43-48, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated. A hash table is maintained to locate the appropriate program counter in the PC log file, although other methods, known to those of skill in the art, may be used [reading the value of the particular memory location]”) [Examiner’s remarks: The memory location is located via hash table, and the value associated with the location is read in order to update the counter value.];
- generating at least one result value in view of the value of the particular memory location (Column 7, lines 43-45, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated [generating at least one result value in view of the value of the particular memory location]”) [Examiner’s remarks: A new counter value is generated, in view of the previous counter value at the memory location.]; and
- storing the at least one result value at the identified memory location (Column 7, lines 43-48, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated. A hash table is maintained to locate the appropriate program counter in the PC log file, although other methods, known to those of skill in the art, may be used [storing the at least one result value at the identified memory location]”) [Examiner’s remarks: The regenerated counter value is saved back into the identified memory location].
Regarding claim 6, the rejection of claim 5 is incorporated; and Cohn further discloses:
- wherein storing the at least one result value at the identified memory location further comprises (Column 7, lines 40-42, “The PC log file 23 is actually a data structure stored in memory, where each entry of the data structure includes a program counter and a count [wherein storing the at least one result value at the identified memory location]”):
- responsive to determining that a condition associated with the at least one profiling instruction is satisfied, storing the at least one result value at the identified memory location (Column 7, lines 43-48, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated. A hash table is maintained to locate the appropriate program counter in the PC log file, although other methods, known to those of skill in the art, may be used [responsive to determining that a condition associated with the at least one profiling instruction is satisfied, storing the at least one result value at the identified memory location]”) [Examiner’s remarks: The profiling instruction relates to the condition that an exception has occurred. When the condition is satisfied, it updates the program counter at the identified memory location].
Regarding claim 7, the rejection of claim 1 is incorporated; and Cohn further discloses:
wherein the profiling information comprises a plurality of counter values (Column 7, lines 40-42, “The PC log file 23 is actually a data structure stored in memory, where each entry of the data structure includes a program counter and a count [wherein the profiling information item contains a plurality of counter items]”), and wherein generating the profiling information further comprises:
- incrementing each counter value of the plurality of counter values in response to a condition associated with the respective counter value being satisfied (Column 7, lines 43-45, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated [incrementing each counter value in the plurality of counter values in response to a condition associated with the respective counter value being satisfied]”).
Claims 8-10 and 12-14 are systems claims corresponding to the method claims hereinabove (claims 1-3 and 5-7 respectively). Therefore, claims 8-10 and 12-14 are rejected for the same reasons as set forth in the rejections of claims 1-3 and 5-7 respectively.
Claims 15-17 and 19-20 are computer-readable medium claims corresponding to the method claims hereinabove (claims 1-3 and 5-6 respectively). Therefore, claims 15-17 and 19-20 are rejected for the same reasons as set forth in the rejections of claims 1-3 and 5-6 respectively.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US 5901308 A (hereinafter “Cohn”) in view of US 5822787 A (hereinafter “Zucker”), further in view of US 5960198 A (hereinafter “Roediger”), and further in view of “Profiling Concurrent Programs” by Denda (hereinafter “Denda”), and further in view of US 6397379 B1 (hereinafter “Yates”).
Regarding claim 4, the rejection of claim 1 is incorporated; and Cohn discloses:
- wherein identifying the memory location in the persistent memory region comprises (Column 3, lines 30-32, “Each entry of the translation table identifies location of the corresponding instruction in a memory. During execution of the compiled application with the representative data sets, instructions causing exceptions are identified, and the translation table is updated to indicate which of the individual instructions caused exceptions during execution”):
determining a product of the profiling identifier… (Column 7, lines 43-48, “Each time an exception occurs, the PC log file 23 is searched for the appropriate program counter, and the counter corresponding to the program counter is updated. A hash table is maintained to locate the appropriate program counter in the PC log file, although other methods, known to those of skill in the art, may be used”).
Cohn discloses “the profiling information”. The combination of Cohn, Zucker, Roediger, and Denda does not explicitly disclose:
- and a size of the profiling information.
However, Yates discloses:
- and a size of [profile packet] (Column 67, lines 11-13, “After the collected profile packet is stored at the location indicated by R15, R15 is postincremented by the size of a profile packet [and the size of the [profile packet]]”) [Examiner’s remarks: Yates discloses having determined a size of a packet so that the size can be used to increment the location indicator.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Yates into the teachings of Cohn, Zucker, Roediger, and Denda to include “and the size of [profile packet]”. As stated in Yates, “Each different architecture of computer represents instructions differently” (Column 1, lines 18-20). Using logical memory space rather than physical gives programmers more flexibility in computer usage. Knowing the size of data to be stored into memory helps in determining where and how much memory needs to be stored. Thus, it would be obvious to one of ordinary skill in the art of compilers to combine a profiler with the ability to determine data size for memory storage.
Claim 11 is a system claim corresponding to the method claim hereinabove (claim 4). Therefore, claim 11 is rejected for the same reasons as set forth in the rejections of claim 4.
Claim 18 is a computer-readable medium claim corresponding to the method claim hereinabove (claim 4). Therefore, claim 18 is rejected for the same reasons as set forth in the rejections of claim 4.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191