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 .
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.
Drawings
The drawings are objected to because:
In FIG. 2, the I’s in “switchIng” and “traversIng” are capitalized for no apparent reason. To avoid confusion, these capital I’s should be made lowercase.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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. Such claim limitation(s) is/are:
In claim 8 line 2, “a pin information acquisition module for obtaining pin information...”. For step A), “a pin information acquisition module” is a generic placeholder with no structural meaning; for step B), the generic placeholder is modified by the functional language “for obtaining pin information...”; and for step C) the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Therefore, this claim limitation requires interpretation pursuant to 35 U.S.C. 112(f). Examiner reviewed the specification, specifically Specification [0051], [0052], and [0061], but no structure is described with respect to the pin information acquisition module. Please see the corresponding 35 U.S.C. 112(b) rejection below.
In claim 8 line 4, “an automatic verification process generation module for generating an automatic verification process...”. For step A), “an automatic verification process generation module” is a generic placeholder with no structural meaning; for step B), the generic placeholder is modified by the functional language “for generating an automatic verification process...”; and for step C) the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Therefore, this claim limitation requires interpretation pursuant to 35 U.S.C. 112(f). Examiner reviewed the specification, specifically Specification [0051], [0053], and [0061], but no structure is described with respect to this module. Please see the corresponding 35 U.S.C. 112(b) rejection below.
In claim 8 line 7, “a pin verification module for automatically verifying the pins...”. For step A), “a pin verification module” is a generic placeholder with no structural meaning; for step B), the generic placeholder is modified by the functional language “for automatically verifying the pins...”; and for step C) the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Therefore, this claim limitation requires interpretation pursuant to 35 U.S.C. 112(f). Examiner reviewed the specification, specifically Specification [0051], [0054], and [0061], but no structure is described with respect to this module. Please see the corresponding 35 U.S.C. 112(b) rejection below.
In claim 9 lines 1-2, “the pin information acquisition module is further configured to automatically extract the pin information...”. For step A), “the pin information acquisition module” is a generic placeholder with no structural meaning; for step B), the generic placeholder is modified by the functional language “is further configured to automatically extract the pin information...”; and for step C) the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Therefore, this claim limitation requires interpretation pursuant to 35 U.S.C. 112(f). Examiner reviewed the specification, specifically Specification [0051], [0052], and [0061], but no structure is described with respect to the pin information acquisition module. Please see the corresponding 35 U.S.C. 112(b) rejection below.
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.
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 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 8-13 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.
The following claim limitations invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
In claim 8 line 2, “a pin information acquisition module for obtaining pin information...”.
In claim 8 line 4, “an automatic verification process generation module for generating an automatic verification process...”.
In claim 8 line 7, “a pin verification module for automatically verifying the pins...”.
In claim 9 lines 1-2, “the pin information acquisition module is further configured to automatically extract the pin information...”.
However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Here, the disclosure is devoid of any structure that performs the function in the claim. 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 function, 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 function 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 function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, 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 function and clearly links or associates the structure, material, or acts to the claimed function, 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 function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
With respect to claims 9-13, claims 9-13 incorporate by reference the indefinite language of claim 8. Therefore, these claims are also rejected under 35 U.S.C. 112(b).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to patent ineligible subject matter.
To determine if a claim is directed to patent ineligible subject matter, the Court has guided the Office to apply the Alice/Mayo test, which requires:
1. Determining if the claim falls within a statutory category;
2A. Determining if the claim is directed to a patent ineligible judicial exception consisting of a law of nature, a natural phenomenon, or abstract idea; and
2B. If the claim is directed to a judicial exception, determining if the claim recites limitations or elements that amount to significantly more than the judicial exception.
(See MPEP 2106).
Step 2A is a two-prong inquiry, (see MPEP 2106.04(II)(A)). Under the first prong, examiners evaluate whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Abstract ideas include mathematical concepts, certain methods of organizing human activity, and mental processes, (see MEPEP 2106.04(a)(2)). The second prong is an inquiry into whether the claim integrates a judicial exception into a practical application. MPEP 2106.04(d).
During examination, examiners should apply the same eligibility analysis to all claims regardless of the number of exceptions recited therein. Unless it is clear that a claim recites distinct exceptions, such as a law of nature and an abstract idea, care should be taken not to parse the claim into multiple exceptions, particularly in claims involving abstract ideas. Accordingly, if possible examiners should treat the claim for Prong Two and Step 2B purposes as containing a single judicial exception. See MPEP 2106.04(II)(B).
With respect to claim 1, applying step 1, the preamble of claim 1 claims a method so this claim falls within the statutory category of a process. In order to apply step 2A, a recitation of claim 1 is copied below. The limitations of the claim that describe an abstract idea are bolded.
A method for automatically verifying full chip pin multiplex, comprising:
obtaining pin information that comprises a pin functional attribute and pin multiplex information;
generating an automatic verification process for pins based on the pin information; and
automatically verifying the pins one by one according to the automatic verification process generated for the pins.
Under step 2A prong one, the bolded limitations, “generating an automatic verification process for pins based on the pin information; and automatically verifying the pins one by one according to the automatic verification process generated for the pins” are describing a process of “verifying”, which refers to a mental process that can be performed manually or using a pencil and paper. For example see specification:
As for chip verification, manually writing a verification case based on design requirements may result in a significant workload and errors.
(Specification [0004] lines 1-2]).
The design requirements as referred to above refer to a design specification. A verification case as referred to above can be interpreted under a broadest reasonable interpretation in light of the specification to refer to an assertion, which is a complex Boolean expression. In formal verification, an exhaustive list of these assertions are derived from the design specification, and the state space is explored for counterexamples (a set of values for which an assertion would fail). As currently claimed, this process can be performed entirely mentally using truth tables.
Similar limitations have been determined by the courts to be mental processes because such language (i.e., defining, determining, processing, and analyzing) can practically be performed in the human mind. For example:
a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016)
An application program interface for extracting and processing information from a diversity of types of hard copy documents – Content Extraction, 776 F.3d at 1345, 113 USPQ2d at 1356.
(see MPEP 2106.04(a)(2)(III)).
Under step 2A prong two, the judicial exception has not been integrated into a practical application. Here, the claim recites one additional limitation: (1) obtaining pin information that comprises a pin functional attribute and pin multiplex information. This limitation falls within the category of mere data gathering (see MPEP 2106.05(g)) because obtaining/extracting information does not add a meaningful limitation the mental process of verifying a design specification.
If the claim as a whole integrates the recited judicial exception into a practical application, then it would be patent eligible. Although not specifically mentioned in the claims, the claim is generally linked to a field designing and fabricating a System on Chip, (see Specification [0002]). However, the claim itself is directed to verifying, which is a mathematical process that can be performed in the human mind, and is not a practical application.
Moving on to step 2B of the analysis, Examiner must consider whether each claim limitation individually or as an ordered combination amounts to significantly more than the abstract idea. This analysis includes determining whether an inventive concept is furnished by an element or a combination of elements that is beyond the judicial exceptions. For limitations that were categorized as “apply it” or generally linking the use of the abstract idea to a particular technological environment or field of use, the analysis is the same. The limitations that were determined to be extra-solution activity will require further analysis.
The only additional limitations are not significantly more because they are well-known, understood, and conventional in the art (WURC). The courts have found the following categories to be WURC:
Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims.")
iv. Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93
(see MPEP 2106.05(d)(II)).
The act of obtaining information is similar in nature to performing repetitive calculations to collect alarm limits and gathering statistics. Furthermore, the specification admits that this step can be performed manually, (see Specification [0004] lines 1-2). Therefore, these limitations are not significantly more.
After reviewing the specification and looking at the claim as a whole, there is no indication that this claim is directed to a combination of known elements arranged or organized in an unconventional manner. As drafted and under a broadest reasonable interpretation, generic computer components may be arranged in the conventional manner to perform the claimed limitations. Therefore, looking at the claim as an ordered combination, the limitations do not amount to significantly more than the abstract idea.
For the foregoing reasons, claim 1 is rejected under 35 U.S.C. 101 as being directed to patent ineligible subject matter.
With respect to claim 2, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein obtaining pin information comprises automatically extracting the pin information from a pin multiplex design table. The limitation of extracting is not an abstract idea. Under step 2A prong one, this additional limitation is a further limitation on the obtaining limitation of the independent claim, which is merely performing data gathering for performing a judicial exception, (see MPEP 2106.05(g)). The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are well-known, understood, and conventional in the art (WURC). The courts have found the following categories to be WURC:
Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims.")
iv. Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93
(see MPEP 2106.05(d)(II)).
Here, the act of extracting specific information (pin information) from a specific data location (pin multiplex design table) is similar in nature to performing repetitive calculations to collect alarm limits and gathering statistics. Therefore, these limitations are not significantly more. For the foregoing reasons, claim 2 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 3, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein the automatic verification process comprises a test sequence process for testing the functional attributes of the pins. The limitation is modifying “the automatic verification process”. In that context, placing further limitations on a mental process does not change the nature of the limitation. In this particular limitation, the claim is further claiming a test sequence, which is a way further defining the data in the verification process. A test sequence is still a mental process. This judicial exception is not integrated into a practical application because there are no additional limitations outside of the abstract idea other than what has already been considered. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the same reason. For the foregoing reasons, claim 3 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 4, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein the automatic verification process further comprises a check sequence process for checking multiplex information of the pins. The limitation is modifying “the automatic verification process”. In that context, placing further limitations on a mental process does not change the nature of the limitation. In this particular limitation, the claim is further claiming a check sequence, which is a way further defining the data in the verification process. A check sequence is still a mental process. This judicial exception is not integrated into a practical application because there are no additional limitations outside of the abstract idea other than what has already been considered. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the same reason. For the foregoing reasons, claim 4 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 5, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein the test sequence process and the check sequence process are executed synchronously. The limitation is modifying “the automatic verification process”. In that context, placing further limitations on a mental process does not change the nature of the limitation. In this particular limitation, the claim is further claiming that the test sequence and the check sequence are synchronous, which is a way further defining the data in the verification process. The fact that the two sequences are synchronized (such as with a clock), does not change that the verification can still be performed mentally. This judicial exception is not integrated into a practical application because there are no additional limitations outside of the abstract idea other than what has already been considered. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the same reason. For the foregoing reasons, claim 5 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 6, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein automatically verifying the pins one by one according to the automatic verification process generated for the pins comprises: assigning each pin to a test sequence number; and performing the test sequence process on a pin and the check sequence process on the remaining pins if the test sequence number of the pin is the same as the current test sequence number; and performing the check sequence process on the pin if the test sequence number of the pin is different from the current test sequence number, wherein the current test sequence number indicates the test sequence number of the pin which is selected currently to undergo the test sequence process. The limitation is modifying “automatically verifying pins”. In that context, placing further limitations on a mental process does not change the nature of the limitation. In this particular limitation, the claim is further claiming an algorithm that can be performed mentally by comparing one ID number with another ID number and determining whether they are equal. Depending on the ID different signals (check sequence or test sequence) are applied to the verification analysis of the pins, which is still a mental process. This judicial exception is not integrated into a practical application because there are no additional limitations outside of the abstract idea other than what has already been considered. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the same reason. For the foregoing reasons, claim 6 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 7, the claimed invention is directed to an abstract idea without significantly more. The claim recites: determining whether the pin multiplex design table is updated; and reexecuting the foregoing method if the pin multiplex design table is updated. The determining step is a mental process because “determining” can be performed in the human mind. Re-executing the mental process is also a mental process. This judicial exception is not integrated into a practical application because there are no additional limitations outside of the abstract idea other than what has already been considered. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the same reason. For the foregoing reasons, claim 7 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 8, applying step 1, the preamble of claim 8 claims a device so this claim should fall within the statutory category of a machine. However, a machine has a specific definition:
A machine is a "concrete thing, consisting of parts, or of certain devices and combination of devices." Digitech, 758 F.3d at 1348-49, 111 USPQ2d at 1719 (quoting Burr v. Duryee, 68 U.S. 531, 570, 17 L. Ed. 650, 657 (1863)). This category "includes every mechanical device or combination of mechanical powers and devices to perform some function and produce a certain effect or result." Nuijten, 500 F.3d at 1355, 84 USPQ2d at 1501 (quoting Corning v. Burden, 56 U.S. 252, 267, 14 L. Ed. 683, 690 (1854)).
(see MPEP 2106.03).
In this particular case, the device as claimed has no physical/concrete parts. Instead, all that is claimed are modules that can be implemented in software (see Specification [0061]). Therefore, claim 8 cannot be considered a machine. Claim 8 is actually directed to software per se:
Products that do not have a physical or tangible form, such as information (often referred to as "data per se") or a computer program per se (often referred to as "software per se") when claimed as a product without any structural recitations;
(see MPEP 2106.03).
Therefore, claim 8 is rejected under 35 U.S.C. 101 for not being directed to a statutory category.
Dependent claims 9-13, depend on claim 8, and do not contain any further structural limitation. Therefore these claims also directed to software per se, and a further rejected under 35 U.S.C. 101 for not being directed to a statutory category.
With respect to claim 14, applying step 1, the preamble of claim 14 claims a non-transitory computer readable storage medium so this claim falls within the statutory category of a manufacture.
Regarding the rest of claim 14, incorporating the rejection of claim 1, claim 14 is rejected for a substantially similar rationale.
With respect to claim 15, incorporating the rejections of claim 14 and claim 2, claim 15 is rejected for a substantially similar rationale.
With respect to claim 16, incorporating the rejections of claim 14 and claim 3, claim 16 is rejected for a substantially similar rationale.
With respect to claim 17, incorporating the rejections of claim 16 and claim 4, claim 17 is rejected for a substantially similar rationale.
With respect to claim 18, incorporating the rejections of claim 17 and claim 5, claim 18 is rejected for a substantially similar rationale.
With respect to claim 19, incorporating the rejections of claim 18 and claim 6, claim 19 is rejected for a substantially similar rationale.
With respect to claim 20, incorporating the rejections of claim 14 and claim 7, claim 20 is rejected for a substantially similar rationale.
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-6 and 8-19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by “An Efficient Formal Verification Method in I/O Multiplexing Module Based on VC Formal CC” (2020-Duan)
With respect to claim 1, Duan teaches A method for automatically verifying full chip pin multiplex, comprising (see “B. The verification Flow of CC Tools”, [pages 114-115]; comprises four steps: 1) extract and generate CSV file, starts at [page 114 col 1 paragraph 3]; 2) prepare to execute and run CC script, which generates the assertions, starts at [page 114 col 1 paragraph 5]; 3) view CC results, which performs the assertion checks verifying connectivity, starts at, [page 115 col 1 paragraph 1]; and 4) collect CC coverage data, which refers to toggle coverage, starts at [page 115 col 2 paragraph 1]):
obtaining pin information that comprises a pin functional attribute and pin multiplex information (Extract and generate the CSV file required by the CC tool according to the design specification of the I/O multiplexing module. Before starting the project, you need to prepare a CSV file, which is the input format used by the CC tool for connection verification. This file is a table of CC test plan, which includes source signal, destination signal, enable condition, reset, different delay settings, etc., [page 114 col 1 paragraph 3 lines 1-5]; see the bottom panel of FIG. 5, which shows the spreadsheet/table, [page 114]; for pin functional attribute see the “from” and “to” columns bottom panel of FIG. 5, which give the direction, [page 114], and for the mux information see the "enable" column, [page 114]; each enable line sets a condition for the mux, see the enable line in FIGS. 2-3 for an example, [page 113]);
generating an automatic verification process for pins based on the pin information (After compiling register transfer level (RTL) code and CSV file, the VC Formal tool will generate assertions for each connection verification defined in the CSV file. If the CSV file describes n connection checks, there will be n assertions generated, [page 115 col 1 paragraph 1]); and
automatically verifying the pins one by one according to the automatic verification process generated for the pins (The "check_fv" command can automatically perform these assertion checks, [page 115 col 1 paragraph 2]; these are connectivity checks, which are previously describes as PAD to IP or IP to PAD, "verify either the connectivity from IPs through pinmux module to PAD or the connectivity from PAD through pinmux module to IPs", [page 114 col 1 paragraph 1 lines 4-6]; note the “n assertions”, from [page 115 col 1 paragraph 1], are generated by passing “all input combinations through mathematical theory” to “generate a complete test vector to verify the verification object, which greatly improves the exhaustive completeness of the verification”, [page 113 col 2 paragraph 4 lines 16-19]; so executing each of the n assertions that represent all input combinations is the “one-by-one”).
With respect to claim 2, Duan teaches all of the limitations of claim 1, as noted above. Duan further teaches wherein obtaining pin information comprises automatically extracting the pin information from a pin multiplex design table (Extract and generate the CSV file required by the CC tool according to the design specification of the I/O multiplexing module, [page 114 col 1 paragraph 3]; see the bottom panel of FIG. 5, which shows the spreadsheet/table, and the top of FIG. 5 which shows %1% and %2% for source and destination, respectively, [page 114]; these correspond to the “from” and “to” columns in the bottom panel of FIG. 5, which gives the direction, [page 114]).
With respect to claim 3, Duan teaches all of the limitations of claim 1, as noted above. Duan further teaches wherein the automatic verification process comprises a test sequence process for testing the functional attributes of the pins (test sequence process is the source to destination connectivity check, FIGS. 2-3 give a source to destination path, [page 113], the CSV file provides the signal information, “This file is a table of CC test plan, which includes source signal, destination signal”, [page 113 col 1 paragraph 3 lines 1-4]; converted in to assertions, see FIG. 9 showing source and destination expressions in table form, [page 115]).
With respect to claim 4, Duan teaches all of the limitations of claim 3, as noted above. Duan further teaches wherein the automatic verification process further comprises a check sequence process for checking multiplex information of the pins (check sequence process are all the other settings and conditions for the mux; FIGS. 2-3 give an enable to destination path, [page 113], the CSV file provides the enable, reset, and delay settings, “This file is a table of CC test plan, which includes ... enable condition, reset, different delay settings, etc.”, [page 113 col 1 paragraph 3 lines 1-5]; converted in to assertions, see FIG. 9 showing enable condition in table form, [page 115]).
With respect to claim 5, Duan teaches all of the limitations of claim 4, as noted above. Duan further teaches wherein the test sequence process and the check sequence process are executed synchronously (refers to setting the clock, so the enable path and src-dest path are synchronized: "The CC tool can abstract the clock and reset information automatically", [page 114 col 2 paragraph 2 lines 3-4]; see FIGS. 2-3, which shows circuits that require a clock in both the en_des_path and the src_des_path to test the mux logic with a certain delay, [page 113]; for example in FIG. 2, you can see two flip flopx in the en_des_path before the mux, and three flip flops in the src_des_path before the mux, where a clock is required to keep the signal introduced at each line synchronized).
With respect to claim 6, Duan teaches all of the limitations of claim 5, as noted above. Duan further teaches wherein automatically verifying the pins one by one according to the automatic verification process generated for the pins comprises (checking each of the n assertions, where the "check_fv" command can automatically perform these assertion checks, [page 115 col 1 paragraphs 1-2]; refers to performing each assertion, where each assertion is a connectivity check either from PAD to IP or IP to PAD as previously described, [page 114 col 1 paragraph 1 lines 4-6]): assigning each pin to a test sequence number (Each pin is assigned to one of the n assertions, "After compiling register transfer level (RTL) code and CSV file, the VC Formal tool will generate assertions for each connection verification defined in the CSV file. If the CSV file describes n connection checks, there will be n assertions generated", [page 115 col 1 paragraph 1]; these n assertions are numbered as shown in FIG. 9, [page 115]); and performing the test sequence process on a pin and the check sequence process on the remaining pins if the test sequence number of the pin is the same as the current test sequence number (test sequence refers to defining the source and destination expressions based on the assertion number, see source expression and destination expression columns in FIG. 9, [page 115]; check sequence refers to setting the enable condition for the mux, see enable column in FIG. 9, [page 115]); and performing the check sequence process on the pin if the test sequence number of the pin is different from the current test sequence number (if the assertion number n is for a different connectivity check (i.e., PAD to IP CORE/FUNCTION), then the configuration for mux needs to be changed to reflect that configuration, "When I/O is switched to other functions, the selection of function control, input and output direction control logic, etc. are all realized through the configuration of related registers", [page 113 col 2 paragraph 2 lines 4-7]; enable pin will still get the clock signal even if the source and destination of a different assertion are being tested), wherein the current test sequence number indicates the test sequence number of the pin which is selected currently to undergo the test sequence process (the CSV file provides the signal information, “This file is a table of CC test plan, which includes source signal, destination signal”, [page 113 col 1 paragraph 3 lines 1-4]; checking each of the n assertions, where the "check_fv" command can automatically perform these assertion checks, [page 115 col 1 paragraphs 1-2]; refers to performing each assertion, where each assertion is a connectivity check either from source-PAD to dest-IP or source-IP to dest-PAD as previously described, [page 114 col 1 paragraph 1 lines 4-6]).
With respect to claim 8, Duan teaches A device for automatically verifying full chip pin multiplex, comprising (device is the software tool called VC formal running on a computer/server: “This article proposes to use the static verification tool VC Formal CC to complete I/O multiplexing intellectual property (IP)’s function verification and SoC-level connectivity verification, without the need to build up a new verification bench and write a verification case”, [page 112 col 2 paragraph 2 lines 1-5]; screenshots of the tool appear in FIGS. 8-10, [page 115]; there is particular mention of setting the maximum memory for tasks on the server, so the server is the device, [page 114 col 2 paragraph 1 bullet 3]: “Set task management (server): the maximum memory and number of tasks”): a pin information acquisition module for obtaining pin information that comprises a pin functional attribute and pin multiplex information (the code of the CC tool that accepts input of the CSV file: Extract and generate the CSV file required by the CC tool according to the design specification of the I/O multiplexing module. Before starting the project, you need to prepare a CSV file, which is the input format used by the CC tool for connection verification. This file is a table of CC test plan, which includes source signal, destination signal, enable condition, reset, different delay settings, etc., [page 114 col 1 paragraph 3 lines 1-5]; see the bottom panel of FIG. 5, which shows the spreadsheet/table, [page 114]; for pin functional attribute see the “from” and “to” columns bottom panel of FIG. 5, which give the direction, [page 114], and for the mux information see the "enable" column, [page 114]; each enable line sets a condition for the mux, see the enable line in FIGS. 2-3 for an example, [page 113]); an automatic verification process generation module for generating an automatic verification process for pins based on the pin information (the code of the CC tool that generates assertions from the CSV file: After compiling register transfer level (RTL) code and CSV file, the VC Formal tool will generate assertions for each connection verification defined in the CSV file. If the CSV file describes n connection checks, there will be n assertions generated, [page 115 col 1 paragraph 1]), wherein the automatic verification process comprises a test sequence process and/or a check sequence process (assertions are generated from the CSV file, [page 115 col 1 paragraph 1], where “This file is a table of CC test plan, which includes source signal, destination signal, enable condition, reset, different delay settings, etc.”, [page 114 col 1 paragraph 3]; test sequence process is the portion of the connectivity check specifically focused on the source signal and destination signal, see FIG. 8 and FIG. 9 showing source and destination expressions in graphic and table form, [page 115] and compare with FIG. 2-3 showing the src_dest_path that is being verified, [page 113]; check sequence process is the portion of the connectivity check focusing on the conditions for the enable pins, see FIG. 8 and FIG. 9 showing enable conditions in graphic and table form, [page 115] and compare with FIG. 2-3 showing the en_dest_path that is being verified, [page 113]); and a pin verification module for automatically verifying the pins one by one according to the automatic verification process for the pins (the code of the CC tool that performs the assertion checks after they are generated: The "check_fv" command can automatically perform these assertion checks, [page 115 col 1 paragraph 2]; these are connectivity checks, which are previously describes as PAD to IP or IP to PAD, "verify either the connectivity from IPs through pinmux module to PAD or the connectivity from PAD through pinmux module to IPs", [page 114 col 1 paragraph 1 lines 4-6]; note the “n assertions”, from [page 115 col 1 paragraph 1], are generated by passing “all input combinations through mathematical theory” to “generate a complete test vector to verify the verification object, which greatly improves the exhaustive completeness of the verification”, [page 113 col 2 paragraph 4 lines 16-19]; so executing each of the n assertions that represent all input combinations is the “one-by-one”).
With respect to claim 9, Duan teaches all of the limitations of claim 8, as noted above. Duan further teaches wherein while obtaining the pin information the pin information acquisition module is further configured to (the code of the CC tool that accepts input of the CSV file: Extract and generate the CSV file required by the CC tool according to the design specification of the I/O multiplexing module. Before starting the project, you need to prepare a CSV file, which is the input format used by the CC tool for connection verification. This file is a table of CC test plan, which includes source signal, destination signal, enable condition, reset, different delay settings, etc., [page 114 col 1 paragraph 3 lines 1-5]; see the bottom panel of FIG. 5, which shows the spreadsheet/table, [page 114]; for pin functional attribute see the “from” and “to” columns bottom panel of FIG. 5, which give the direction, [page 114], and for the mux information see the "enable" column, [page 114]; each enable line sets a condition for the mux, see the enable line in FIGS. 2-3 for an example, [page 113]) automatically extract the pin information from a pin multiplex design table (Extract and generate the CSV file required by the CC tool according to the design specification of the I/O multiplexing module, [page 114 col 1 paragraph 3]; see the bottom panel of FIG. 5, which shows the spreadsheet/table, and the top of FIG. 5 which shows %1% and %2% for source and destination, respectively, [page 114]; these correspond to the “from” and “to” columns in the bottom panel of FIG. 5, which gives the direction, [page 114]).
With respect to claim 10, incorporating the rejections of claim 8 and claim 3, claim 10 is rejected for a substantially similar rationale.
With respect to claim 11, incorporating the rejections of claim 10 and claim 4, claim 11 is rejected for a substantially similar rationale.
With respect to claim 12, incorporating the rejections of claim 11 and claim 5, claim 12 is rejected for a substantially similar rationale.
With respect to claim 13, incorporating the rejections of claim 12 and claim 6, claim 13 is rejected for a substantially similar rationale.
With respect to claim 14, Duan teaches A non-transitory computer readable storage medium storing a computer instruction for enabling a computer to execute a method for automatically verifying full chip pin multiplex, the method comprises (the non-transitory computer readable storage medium is the software tool called VC formal running in the memory of a computer/server: “This article proposes to use the static verification tool VC Formal CC to complete I/O multiplexing intellectual property (IP)’s function verification and SoC-level connectivity verification, without the need to build up a new verification bench and write a verification case”, [page 112 col 2 paragraph 2 lines 1-5]; screenshots of the tool appear in FIGS. 8-10, [page 115]; there is particular mention of setting the maximum memory for tasks on the server, so the memory is the non-transitory CRM, [page 114 col 2 paragraph 1 bullet 3]: “Set task management (server): the maximum memory and number of tasks”.
Regarding the rest of claim 14, incorporating the rejection of claim 1, claim 14 is rejected for a substantially similar rationale.
With respect to claim 15, incorporating the rejections of claim 14 and claim 2, claim 15 is rejected for a substantially similar rationale.
With respect to claim 16, incorporating the rejections of claim 14 and claim 3, claim 16 is rejected for a substantially similar rationale.
With respect to claim 17, incorporating the rejections of claim 16 and claim 4, claim 17 is rejected for a substantially similar rationale.
With respect to claim 18, incorporating the rejections of claim 17 and claim 5, claim 18 is rejected for a substantially similar rationale.
With respect to claim 19, incorporating the rejections of claim 18 and claim 6, claim 19 is rejected for a substantially similar rationale.
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.
Claim(s) 7 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “An Efficient Formal Verification Method in I/O Multiplexing Module Based on VC Formal CC” (2020-Duan) in view of “A Method to Make SoC Verification Independent of Pin Multiplexing Change” (2013-Ghosh)
With respect to claim 7, Duan teaches all of the limitations of claim 1, as noted above. Duan does not teach determining whether the pin multiplex design table is updated; and reexecuting the foregoing method if the pin multiplex design table is updated.
However, Ghosh teaches determining whether the pin multiplex design table is updated; and reexecuting the foregoing method if the pin multiplex design table is updated (see FIG. 5, [page 3], along with the following description: “For example due to pinmux changes, the “func_i2c_scl” is moved to new I/O pad “pin_IFC_AVD” instead of previously connected I/O pad “pin_UART_CTS_B[1]”. In this case as the name of the function remains unchanged (i.e. func_i2c_scl), hence no more changes required in testbench for bfm connectivity. And also the select signal name (i.e”ctrl_i2c_scl”) remains unchanged in the testbench. But select signal will move to new pad’s (i.e “pin_IFC_AVD”) appropriate position of tb-de-mux as per new pinmux option. This is done automatically in “Function Mapping” layer. When pinmux changes happen, all “Function mapping” layer files generated automatically and all control/function signals for the associated tb-de-mux are mapped accordingly. Hence it becomes transparent to user. Because user selects the ctrl_i2c_scl signal from the testcase, the i2c operation becomes available from testbench side. This makes the testbench and test case independent of pinmux changes for reuse category. And for new category, one time testbench connection made can be used for rest of the time in same SoC or across SoCs. It can also be used if there is multiple occurrence of same protocol interface”, [page 3 col 2 paragraph 3]-[page 4 col 1 paragraph 1]; meaning, the assigned pins can change, and the testbench is updated automatically to reflect the changes).
It would have been obvious to one skilled in the art before the effective filing date to combine Duan with Ghosh because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Duan discloses a system and method that teaches all of the claimed features except for determining when the pinmux table is updated and re-executing the method. Ghosh teaches a function mapping layer that automatically updates, and explains the benefit:
This makes the testbench and test case independent of pinmux changes for reuse category. And for new category, one time testbench connection made can be used for rest of the time in same SoC or across SoCs. It can also be used if there is multiple occurrence of same protocol interface.
(Ghosh [page 4 col 1 paragraph 1 lines 5-10])
A person having skill in the art would have a reasonable expectation of successfully reusing assertions/test cases when the SoC changes which pins are used for a particular IP core/function in the system and method of Duan by modifying Duan with the automatically updated function mapping of Ghosh. Therefore, it would have been obvious to combine Duan with Ghosh to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 20, incorporating the rejections of claim 14 and claim 7, claim 20 is rejected for a substantially similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230177244 A1 (Das) - A method of verifying connectivity in a circuit design, includes, in part, receiving a netlist of the circuit design; designating a plurality of destination nodes associated with the netlist; for each of the plurality of destination nodes, identifying one or more source nodes that are traversed from the destination node; for each source node identified as traversed from the destination node: transforming the netlist by including a first multiplexer having a first input terminal receiving a first variable logic value and an output terminal coupled to the source node; and enabling the first multiplexer to pass the first variable value to the destination node from the source node in order to check for connectivity between the source node and the destination node, [Abstract].
US 8,074,192 B2 (Kanazawa) - The circuit volume of a system under design is reduced by a circuit conversion involving consolidation (sharing) of common parts in the system by a representative part. The design data of the system post-conversion is used to verify operation of the system. However, the verification results for the system post-conversion express signals (e.g., signal X) of plural modules (e.g., modules a to c) as one signal waveform thereby making debugging difficult when a bug is found. Given this situation, from the verification results of the system post-conversion, signal-generation-use data is generated for generating the signal waveforms (here, respective signal waveforms for the modules a to c) of the system before conversion. After verification is complete, a signal waveform for each of the modules a to c is generated using the verification results for the system under design and the signal-generation-use data, [Abstract].
JP 2001356930 A (Swoboda) - Connectivity between an emulation controller and a plurality of target devices can be automatically detected. After the target devices (Chip1, ChipN) and the emulation controller (12) tri-state respective terminals thereof, one of the target devices drives a predetermined logic level on each of the aforementioned terminals thereof in sequence, while maintaining the remainder of the aforementioned terminals thereof tri-stated. These driving (33) and maintaining (31) operations are thereafter performed by each of the remaining target devices in sequence. During each driving step, all of the target devices and the emulation controller read logic levels at their aforementioned terminals (34, 43), [Abstract].
CN 113868046 A - The application discloses a function verification method of a PAD control unit, which comprises the following steps: establishing a form verification environment, and determining a design file and an inspection mechanism file of the PAD control unit; reading a design code corresponding to the PAD control unit from the design file, and inputting random values in all input ports of the PAD control unit according to the design code so as to carry out formal verification on the PAD control unit; and checking the output result of the PAD control unit according to the checking mechanism file to obtain a function verification result of the PAD control unit. The PAD control unit function verification method and device can improve function verification efficiency and completeness of the PAD control unit. The application also discloses a function verification system of the PAD control unit, an electronic device and a storage medium, which have the beneficial effects, [Abstract].
“Case Study : Re-visiting SoC Verification Challenges and Best Practices” (2015-Ghosh) - The size and complexity of system-on-chip (SoC) design is growing rapidly as more and more IPs/features/functions are put into single die to reduce overall system development cost. It significantly increases SoC verification challenges in recent time due to high degree of integration of complex IPs. In this paper we will be discussing different verification strategies in different areas of verification and some of the best practices that we have followed in our SoCs. We have applied all these verification methodologies and productivity measures on top of existing conventional methodologies in our SoC T1024 and the result is remarkable. We achieved first pass silicon and it reduced post silicon cycles significantly. As a result the organization has pulled in the final production qualification cycle by almost three months. These methodologies also became huge success for our previous product C293, [Abstract].
“Formal Verification of Connections at SoC-level” (2017-Yang) - Abstract-Verification of connections at SoC (System on Chip) level is a fundamental requirement to ensure correct operation. It is a significant challenge for verification engineers to cover every scenario because simulation patterns in whole chip environment are usually fewer and thus corner case bugs are very difficult to find. Formal verification, on the other hand, exhaustively explores the mathematical representation of the design to uncover all possible incorrect behaviors. However, the state space explosion issue caused by design complexity becomes the most challenging problem in formal world. Since an SoC consists of several millions of sequential logics, the complexity issue is more critical for convergence. Therefore, months of manual efforts are needed to do abstraction to verify connectivity problems. This paper describes the experience of using connectivity checking (CC) application in a productized formal verification tool, VC Formal, to reduce manual efforts and save run time, [Abstract].
“A Tutorial on Lava: A hardware Description and Verification System” (2000-Claessen) – In Lava, we can do this by verify not just one question, but a whole list of questions. For example, to verify that two circuits have the same output, we can prove this pin-by-pin instead of at one go. To do this we have to define one-by-one inequality, [page 21 paragraph 1]; but read the whole section, which shows how to build the assertions for each pin of an adder of n size, [pages 18-22].
“Connectivity and Beyond” (2019-Ikram) - Abstract-This paper presents an innovative workflow to deploy connectivity tools in various phases of SOC design. The process starts with designers creating connectivity specifications at the full-chip and partition level. These specifications are used to auto-generate connectivity checks on the evolving RTL (register transfer language). A weekly regression test-suite based on formal tools ensures that as chip design evolves, the connectivity remains intact. Furthermore, the workflow also verifies the completeness of the connectivity specification through fault injection verification. Next, the formal connectivity results are used to generate toggle coverage. This saves time during the integration of blocks to the full-chip closure. Finally, we process these specifications to generate higher level connectivity checks. These checks include circularity absence, one-to-many, many-to-one, and many-to-many connections. The designers review these derived high-level checks for any unexpected surprises. These high-level specifications are verified using Static tools. A number of bugs were found and fixed. The flow is now a regular part of our SOC-design process, [Abstract]; this paper describes not only checks for structural and functional properties, but also includes assertions that “the source and destination are not connected to any other port”, [page 3 paragraph 1 bullets (1)(A)-(C)].
“SoC Security Verification Using Assertion-Based and Information Flow Tracking Techniques” (2021-Achyutha) – Section 3.2 shows how a parameterized assertion is built. Step 1: creating Boolean expressions; Step 2: generated sequences from the Boolean expressions; Step 3 is creating properties from the sequences; and Step 4 is instantiating properties in assertions, [pages 37-40]; in this example, the first sequence corresponds to the “test sequence” of the claims, and the second sequence corresponds to the “check sequence” which are combined into a single property in order to create assertions based on that property.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL MILLER whose telephone number is (408) 918-7548. The examiner can normally be reached on Monday-Friday from 11am to 5pm (PT). If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jack Chiang, can be reached at telephone number 571-272-7483. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/D.M./Examiner, Art Unit 2851
/JACK CHIANG/Supervisory Patent Examiner, Art Unit 2851
Prosecution Insights