DETAILED ACTION
Claims 6, 8-11, and 13-15 have been examined.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 3, 2025, has been entered.
Specification
The title of the invention is no longer sufficiently descriptive given the claim amendments. A new title is required that is clearly indicative of the invention to which the claims are directed.
The specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections/Recommendations
Claim 6 (and similarly claim 11) is objected to because of the following informalities:
On page 3, last paragraph, line 3, it appears that “include” should be replaced with --includes-- (to pair more appropriately with “each”).
On page 3, last paragraph, lines 3-4, is the phrase “each of the one or more register classes include different data types” intended to encompass each of the one or more register classes corresponding to a different data type instead of each class including multiple data types? If so, please use more clear language.
On page 3, last paragraph, lines 3-4, applicant appears to be trying to encompass just one register class (with “one or more register classes” language). When there is just one register class, “different data type” and “different size” do not seem to make sense grammatically since “different” implies a comparison to some other type/size, which would not exist if there is only one class. It appears the “wherein…” limitation sets forth multiple classes, so the examiner recommends rewording to --…8-bit locations of the one or more virtual registers to a plurality of register classes, wherein each of the register classes corresponds to a different data type, each different data type having a different size,…--. Please review any dependent claims for domino effects caused by these changes.
On page 3, 2nd to last line, replace “64-bit” with --a 64-bit virtual register--.
On page 3, 2nd to last line, insert a comma after “locations”.
In claims 6 and 11 (last paragraph, the examiner recommends inserting clear basis for the “char” and “int” abbreviations by inserting --character-- after “first scalar” and “third scalar”, and inserting “integer” after “second scalar”.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
Such claim limitations include:
All of the modules of claims 6 and 11. The examiner could not find any disclosure of corresponding structure for these modules in the specification. Instead, applicant discloses them as generic black boxes (see FIG.2, 242 through 250). Because no structure is disclosed, the examiner cannot properly interpret the claims under 112(f). As such, broadest reasonable interpretation will be taken and 112(a)/(b) rejections are set forth below. The examiner recommends deleting all of the language inserted regarding the modules. Alternatively, applicant could claim the modules as circuits, if they are circuits, since “circuit” does not invoke 112(f) (see MPEP 2181(I)(A), 3rd paragraph).
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 6, 8-11, and 13-15 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Referring to claims 6 and 11, in the last paragraph, applicant now claims that two chars (a and c) are assigned to different register classes (first and third, respectively), despite being the same data type. This conflicts with the paragraph starting at the bottom of page 12 (and continuing on page 13) that assigns char a and char c to the first register class. This is shown in FIG.4B, where a and c are both assigned to 8-bit locations R0 and R1. Thus, it is now new matter to claim that a char (char c) is assigned to an 32-bit location (third register class). The examiner will provide a prior art rejection in case applicant meant --first-- instead of “third” in the 2nd to last line.
Referring to claims 6 and 11, as described above, in relation to the various claimed modules, the disclosure does not provide adequate structure to perform the claimed functions associated with the modules. The specification does not demonstrate that applicant has made an invention that achieves the claimed function because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
All dependent claims are rejected due to their dependence on a claim lacking adequate written description.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6, 8-11, and 13-15 are 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.
Referring to claims 6 and 11, the claimed modules plus their functions invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, as described above, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed functions and to clearly link the structure, material, or acts to the functions. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed functions, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the functions recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the functions so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed functions, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed functions and clearly links or associates the structure, material, or acts to the claimed functions, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed functions. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
The claims recite the following limitations for which there is a lack of antecedent basis:
In claim 11, lines 3 and 5, each instance of “the processor”, since there may be multiple processors per line 2.
All dependent claims are rejected due to their dependence on an indefinite claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 6, 8-11, and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Ashihara et al., EP 0945783 A2, in view of the examiner’s taking of Official Notice, Inagami et al., U.S. Patent No. 5,530,881, and Wikipedia, “C data types”.
Referring to claim 6, Ashihara has taught a system to optimize scalar register allocation, the system comprising:
a processor (FIG.1) configured to:
receive, by a receiving module of the processor, information about one or more available physical registers in a memory of the processor, as input (a processor can only allocate available resources/registers (which is the focus of Ashihara), i.e. a processor cannot allocate that which isn’t available, and, thus, the processor must receive information indicating which registers are available. The receiving module could be at least one input bus).
Ashihara has not taught the receiving module to receive intermediate representation code, as input. However, Ashihara has taught that registers are provided and assigned by a compiler (see paragraph [0034]). Further, Official Notice is taken that translation of high-level code to intermediate representation code, by the processor that will ultimately execute the code, was well known in the art before applicant’s invention. Such translation allows for further analysis, re-arrangement, and other optimization, while executing the compiler on the same processor that executes the compiled program means that only one physical device is needed instead of two, thereby reducing necessary hardware, and increasing convenience since compilation and program execution can occur on the same machine, thereby allowing for quick program updates and re-compilation if necessary. As a result, in order to further optimize the compiled code in a convenient manner with reduced hardware, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ashihara’s receiving module for receiving intermediate representation code, as input.
Ashihara, as modified, has not taught the intermediate representation code including vector instructions and scalar instructions. However, Inagami has taught a mingled-type program including both scalar and vector instructions (see the abstract, and column 1, lines 14-21 and 36-52). Basically, by including instructions of both scalar and vector architectures, general-purpose tasks can be efficiently performed with scalar instructions, and operations on arrays can be rapidly performed using vector instructions. To handle these types of programs, a scalar unit 4/5 with scalar registers 49/59 (FIGs.1-3) and vector unit 3 with vector registers 21 (FIG.1) may be implemented to process the respective instructions efficiently. The intermediate representation thereof would include both types of instructions, as each would have to be allocated the respective type of register. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ashihara to additionally implement vector circuitry for handing vector instructions and for the intermediate representation code to include vector instructions and scalar instructions so as to allow for processing of scalar/vector mixed programs to efficiently process tasks coded for each of the architecture types.
Ashihara, as modified, has further taught a processor configured to allocate, by a virtual register allocator module coupled to the receiving module, one or more virtual registers based on the received information, wherein each virtual register is a size of each of the one or more available physical registers (a compiler executed on the processor generates instructions of that processor’s instruction set, and these instructions include virtual register identifiers (i.e., R0, R1, etc.). Thus, the compiler will assign operations virtual registers (using a virtual register allocator module) based on availability information received as input. The virtual registers are the same size as the physical registers to which they are respectively mapped);
Ashihara has further taught a processor configured to map, by a mapping module coupled to the virtual register allocator module, one or more groups of 8-bit locations of the one or more virtual registers to one or more register classes, wherein each of the one or more register classes include different data types, each different data type having a different size (see FIG.2, which shows at least each 8-bit location of a register being mapped to a byte class, groups of two 8-bit locations being mapped to a halfword class, and a group of four 8-bit locations being mapped to a word class. In other words, the allocator module will allocate a register, e.g. An (in FIG.3), to an instruction, and then the mapping module will map an 8-bit location of that register to the first class (byte). Allocated register Bn would have two 8-bit locations mapped to the second class (halfword));
Ashihara has not taught wherein when the virtual register is 64-bit and includes 8 8-bit locations the mapping module maps 8 8-bit scalar variables to the 8 8-bit locations in the 64-bit virtual register for a first register class, the mapping module maps 4 16-bit scalar variables to 4 16-bit locations in the 64-bit virtual register for a second register class, and the mapping module maps 2 32-bit scalar variables to 2 32-bit locations in the 64-bit virtual register for a third register class. Instead, Ashihara has taught 32-bit virtual registers including four 8-bit locations (FIG.2) that can be mapped to four 8-bit scalar variables for the first register class (FIG.2, B0-B3), two 16-bit variables for the second register class (FIG.2, H0-H1), and one 32-bit variable for the third register class (FIG.2, W0). In other words, because Ashihara teaches half the size that applicant teaches, Ashihara can only map half the variables/locations that applicant maps. However, this amounts to a mere change in size of the register, which is deemed a routine expedient and not a patentable distinction, particularly absent some demonstration of criticality of the size. Official Notice is taken that 64-bit registers were well known in the art before applicant’s invention and that such a size, if used in Ashihara, would allow the system to register more data for operations. That is, the more register memory, the more variable variables could be quickly accessed. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the virtual register of Ashihara to be 64 bits in length instead of 32 so as to double the amount of data that can be registered. With such a modification, one of ordinary skill in the art would understand how FIG.2 would be extended, where B0-B7 could be stored in each of the eight 8-bit locations, H0-H3 could be stored in each of the four 16-bit locations, and W0-W1 could be stored in each of the two 32-bit locations.
Ashihara, as modified, has further taught a processor configured to identify, by a scalar identification module coupled to the receiving module, a plurality of scalar variables from the received intermediate representation code (see FIG.3 and note that the add operation shown would appear in the intermediate code and that at least two source variables (those to be added, in this case an 8-bit value and a 16-bit value) would be identified by a scalar identification module so that registers could be assigned thereto) by analyzing the intermediate representation code to classify each instruction of the intermediate representation code as either a vector instruction of a scalar instruction (in the combined system, vector instructions use vector registers and scalar instructions use scalar registers. As such, each instruction of the intermediate code must be classified as either vector or scalar so as to be assigned the proper register(s)).
Ashihara, as modified, has not taught that analyzing the intermediate representation code comprises analyzing each basic block of the intermediate representation code. However, Official Notice is taken that the concept of a basic block was well known in the art before applicant’s invention. A basic block is simply a block of instructions that has one entry point and one branch exit point. Programs are known to be made up of a number of basic blocks, which include branching to allow the program to jump to different functionality as needed. Additionally, one of ordinary skill recognizes that any instruction (e.g. vector or scalar) can appear in any basic block. As such, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ashihara such that analyzing the intermediate representation code comprises analyzing each basic block of the intermediate representation code. That is, it would be obvious for the compiler to compile the entire program including all basic blocks, so that all basic blocks can execute and access registers as needed.
Ashihara, as modified, has also not taught wherein analyzing each basic block includes analyzing each of LOAD and STORE instructions to classify each instruction as a scalar instruction or a vector instruction, wherein each LOAD instruction is classified as a scalar instruction when information in the LOAD instruction is an absolute or an indirect value, and wherein each STORE instruction is classified as a scalar instruction when sources of the STORE instruction and ALM instruction are not marked as vector instructions. However, Official Notice is taken that scalar and vector load and store instructions that are allocated scalar and vector registers were well known in the art before applicant’s invention. They allow data to be loaded into registers for use in execution and for storing results in registers to longer-term memory. When implemented in Ashihara, as modified, the system detects information in each of the types of load instructions that result in classification as a scalar or vector load instruction. For instance, a scalar load opcode and/or information indicating just a single address from which a single value is loaded would be considered an absolute value that would result in scalar load classification and allocation of a scalar register (as opposed to, e.g. a vector load opcode and/or multiple addresses from which multiple elements are loaded into a vector register). This ensures that both scalars and vectors are loaded to the appropriate registers for processing. Similarly, when a value (source) to be stored by a store instruction is not a vector (i.e., not marked as a vector instruction), then the store is classified as a scalar store and encoded and executed to store only one value instead of multiple values of a vector. Alternatively, because a source operand of a store instruction is not an instruction per se, it will never be marked as a vector instruction, and the store will be a scalar store as long as its source is a scalar register. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ashihara to implement both scalar and vector load and store instructions such that analyzing each basic block includes analyzing each of LOAD and STORE instructions to classify each instruction as a scalar instruction or a vector instruction, wherein each LOAD instruction is classified as a scalar instruction when information in the LOAD instruction is an absolute or an indirect value, and wherein each STORE instruction is classified as a scalar instruction when sources of the STORE instruction and ALM instruction are not marked as vector instructions.
Ashihara has further taught a processor configured to dynamically assigning, by a register assignor module coupled to the scalar identification module and the mapping module, a first scalar variable to the first register class (from FIGs.2-3, any scalar byte variable is assigned to the first/byte register class so that it can be assigned to a single 8-bit location)), a second scalar variable to the second register class (from FIGs.2-3, any 16-bit scalar variable is assigned to the second register class so that it can be assigned to a single 16-bit location)), and a third scalar variable to the first register class (from FIG.2, any scalar byte variable is assigned to the first/byte register class so that it can be assigned to a single 8-bit location). For instance, multiple byte variables may be assigned to different 8-bit locations in the same register (see B0-B3). See paragraph [0025]).
Ashihara has not taught that the first scalar variable is a character variable (char a), the second scalar variable is an integer variable (int b), and the third scalar variable is a character variable (char c). However, Wikipedia has taught known C data types, where chars may be 8 bits and ints may be 16 bits (e.g. from the third paragraph under the table on p.2, “The minimum size for char is 8 bits, the minimum size for short and int is 16 bits”. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Ashihara to compile and execute C programs so as to accommodate programs using both characters and integers and written in a very well-known and popular programming language. With such a modification, the C program’s character variables would be assigned to the first (byte) register class (8-bit location in a register) and the C program’s integer variables would be assigned to the second register class (16-bit location in a register).
Referring to claim 8, Ashihara, as modified, has taught the system as claimed in claim 6, wherein the processor is configured to map one or more groups of 8-bit locations of the one or more virtual registers to one or more register classes based on a size of the one or more available physical registers (the possible groupings in FIG.2 are limited based on the physical size of the registers. Larger registers would have more groups; smaller registers would have fewer groups).
Referring to claim 9, Ashihara, as modified, has taught the system as claimed in claim 6, wherein to assign the one or more available physical registers, the processor is configured to:
allocate the one or more register classes to the identified scalar variables, wherein the one or more register classes are allocated based on associated computer hardware, type of scalar variables, and number of the one or more available physical registers (each of these is a factor in allocation. Class allocation is clearly based on type of variables as shown in FIG.2, i.e., if a byte is being operated on by the code, a byte class will be allocated. The classes that can be allocated are also limited to the computer hardware, i.e., in Ashihara, as modified, the system can only allocate up to a 64-bit class since register size is 64 bits. Finally, classes can only be allocated based on register availability. In other words, if there is register space still available, a class may be allocated. But, if all registers are consumed and space is not available, a class cannot be allocated without first freeing a register); and
assign the one or more available physical registers to each of the identified scalar variables, based on the allocated one or more register classes and type of scalar variable (again, see FIGs.2-3).
Referring to claim 10, Ashihara, as modified, has taught the system as claimed in claim 9, wherein to allocate the one or more register classes to the identified scalar variables, the processor is configured to allocate first available continuous one or more groups of 8-bit locations based on a data type associated with each identified scalar variable, wherein the data type is one of byte (see FIG.2, B0-B3, which are allocated to continuous/consecutive 8-bit locations in a register), short, int (as modified, Ashihara would have 16-bit integers which are allocated to continuous/consecutive locations in a register (e.g. see FIG.2, H0-H1). Each individual integer also occupies continuous locations), long, char (as modified, Ashihara would have 8-bit characters which are allocated to continuous/consecutive 8-bit locations in a register (e.g. see FIG.2, B0-B3)), float, and double.
Claims 11 and 13-15 are rejected for similar reasoning as claims 6 and 8-10, respectively. Note that all processor operations occur in response to executing instructions on a medium.
Response to Arguments
Applicant’s only argument is that the prior art has not taught the claims as amended.
The examiner respectfully disagrees for reasons set forth in the rejections above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to David J. Huisman whose telephone number is 571-272-4168. The examiner can normally be reached on Monday-Friday, 9:00 am-5:30 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jyoti Mehta, can be reached at 571-270-3995. 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.
/David J. Huisman/Primary Examiner, Art Unit 2183
Prosecution Insights