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 .
DETAILED ACTION
This office action is responsive to Applicant’s reply filed on 04/02/2026.
Claims 1, 5 – 7, 9, 11, 14 – 16, and 19 – 20 are pending; wherein:
Claims 1, 5 – 7, 9, 11, 14, 16, and 19 – 20 have been amended; and
Claims 2 – 4, 8, 10, 12 – 13, and 17 – 18 have been canceled.
Claims 1, 5 – 7, 9, 11, 14 – 16, and 19 – 20 have been examined and are being finally rejected.
Response to Amendment
Claim objections and 35 USB 112(b) rejections for claims 1 – 20 are withdrawn in view of Applicant’s amendments.
Response to Arguments
Applicant’s arguments, filed on 04/02/2026, with respect to claims 1, 5 – 7, 9, 11, 14 – 16, and 19 – 20 have been considered but are moot in view of new ground(s) of rejection as necessitated by amendments.
Regarding 101 rejections, Applicant argues that “As amended, claim 1 recites features that are integrated into a practical application for generating a release note using a generated LLM prompt, performing complex processing, and generating useful output data that amounts to more than merely mathematical concepts, mental processes, and methods of organizing human activity” (Remark; p. 8: first full paragraph.)
Applicant alleges that the claims perform complex processing and generate useful output data. However, examiner fails to find any limitations that reflect the complex processing and useful output data.
Applicant points out “… During the February 20 interview, the examiner indicated that such claim language, which incorporates claims 5 and 10 which includes intervening claim 8, would potentially overcome the 101 rejection…” (Remark; p. 8: last half paragraph – p. 9: first half paragraph.)
Examiner stated during interview dated 02/20/2026 that the incorporating claims 5 and 10 and their intervening claims into all independent claims may overcome 101 rejections. However, examiner needs to consult with primary examiner. (Emphasis added. Interview summary mailed on 02/24/2026.)
After further consideration and consultation with supervisor, such amendments are determined to not overcome 101 rejections. Therefore, the claims remain rejected under 35 USC 101.
Claim Objections
Claims 1, 5 – 7, 9, 11, 14 – 16, and 19 – 20 are objected to because of the following informalities:
Claim 1
Lines 3 – 4; change “a alt tag” to --an alt tag--.
Line 10; insert --in-- before “place”
Line 17; change “an image” to --the image--.
Line 18; change “a LLM” to --the LLM--.
Last line; insert --received from the LLM-- after “the release note”.
Claims 5 – 7, 9, 11, and 14 – 15
These claims are dependent claims of claim 1 either directly or indirectly; therefore, they inherit issues of claim 1.
Claim 16
Lines 6 – 7; change “a alt tag” to --an alt tag--.
Line 19; change “an image” to --the image--.
Line 20; change “a LLM” to --the LLM--.
Last line; insert --received from the LLM-- after “the release note”.
Claim 19
The claim is dependent claim of claim 16; therefore, it inherits issues of claim 16.
Claim 20
Lines 3 – 4; change “a alt tag” to --an alt tag--.
Line 16; change “an image” to --the image--.
Line 17; change “a LLM” to --the LLM--.
Last line; insert --received from the LLM-- after “the release note”.
Appropriate correction is required.
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 a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1
Step 1
The claim is statutory because it is directed to a method.
Step 2A, prong 1
The claim recites steps of:
“finding an item in the source data …;
checking criteria by … analyze the alt tag and, in response to results from the LLM indicating the alt tag is inadequate, determining that the criteria are met;
in response to the criteria being met, generating … a large language model (LLM) prompt comprising an image associated with the alt tag …”
These steps fall into the category of mental process within the realm of abstract ideas because they rely on human observing item and criteria, evaluating the criteria, and offering opinion by generating a prompt with an aid of paper and pen. Thus, these steps recite a mental process.
Step 2A, prong 2
The claim further recites additional steps of
“accessing source data …;
the alt tag is associated with an image such that when the image cannot be displayed the alt tag is displayed place of the image, wherein the finding comprises finding alt tags in the source data;
inputting … the LLM prompt into the LLM;
receiving … a release note in response to the prompt;
updating the source data …; and
modifying the source code …”, and additional elements “a computing device and a large language model (LLM).”
These additional steps are insignificant extra solution activity elements, and the additional elements are just high level of generality as tool for performing the abstract idea. Therefore, they do not integrate the exception into a practical application.
Steps 2B
The claim as a whole is not amounted to significantly more than the judicial exception. In other words, claim 1 is directed to an abstract idea. Therefore, claim 1 and its dependent claims are not patent eligible.
Analysis of claims 5 – 7, 9, 11, 14, and 15 as follow
Claim 5
The claim recites limitations “the role is a technical writer role, prompting the LLM with writing style.”
These limitations, as drafted, define writer role and writing style. Thus, these limitations are insignificant extra solution activity elements which can be selected by human, and they are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea. So, they do not include any additional element that is sufficient to amount to significantly more than the judicial exception.
Claim 6
The claim recites limitations “prior to prompting the LLM with the alt tag, removing personal data from the alt tag.”
These limitations, as drafted, remove data. Thus, these limitations are insignificant extra solution activity elements, and they are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea. So, they do not include any additional element that is sufficient to amount to significantly more than the judicial exception.
Claim 7
The claim recites limitations “the LLM is adapted by training the LLM with content from an enterprise which produces the source data.”
These limitations, as drafted, merely trains LLM. Thus, these limitations are a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind, and they are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea. So, they do not include any additional element that is sufficient to amount to significantly more than the judicial exception.
Claim 9
The claim recites limitations “in response to determining the criteria are met, where the prompt comprises the alt tag, source code around the alt tag and a request to improve the alt tag.”
These limitations, as drafted, updating source data with technical data. Thus, these limitations are insignificant extra solution activity elements, and they are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea. So, they do not include any additional element that is sufficient to amount to significantly more than the judicial exception.
Claim 11
The claim recites limitations “in response to the results from the LLM indicating the alt tag is adequate, determining the criteria are not met and finding a next item in the source data.”
These limitations, as drafted, find next item after determining that criteria are not met. Thus, these limitations are a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind, and they are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea. So, they do not include any additional element that is sufficient to amount to significantly more than the judicial exception.
Claim 14
The claim recites limitations “only storing the release note or only updating the source data with the release note received from the LLM, in response to input from an operator.”
These limitations, as drafted, stores data. Thus, these limitations are insignificant extra solution activity elements, and they are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea. So, they do not include any additional element that is sufficient to amount to significantly more than the judicial exception.
Claim 15
The claim recites limitations “adding a command token in the LLM prompt where the command token triggers the LLM to call a search engine using a query comprising key words from the LLM prompt.”
These limitations, as drafted, searches data. Thus, these limitations are insignificant extra solution activity elements, and they are not integrated into a practical application because they do not impose any meaningful limits on practicing the abstract idea. So, they do not include any additional element that is sufficient to amount to significantly more than the judicial exception.
Claim 16
The claim is statutory because it is directed to a device.
The claim recites limitations in the same manner as claim 1; therefore, it is rejected for the same reasons.
The claim recites additional elements of “processor”, “memory”, and “a large language model (LLM).” These additional elements are just high level of generality as tool for performing the abstract idea.
Analysis of claim 19 as follow
Claim 19 recite limitations in the same manner as claim 5; therefore, claim 19 is also rejected for the same reasons.
Claim 20
Step 1
The claim is statutory because it is directed to a method.
Step 2A, prong 1
The claim recites steps of:
The claim recites steps of:
“finding an item in the source data …;
checking criteria by … analyze the alt tag and, in response to results from the LLM indicating the alt tag is inadequate, determining that the criteria are met;
in response to the criteria being met, generating … a large language model (LLM) prompt comprising an image associated with the alt tag …”
These steps fall into the category of mental process within the realm of abstract ideas because they rely on human observing item and criteria, evaluating the criteria, and offering opinion by generating a prompt with an aid of paper and pen. Thus, these steps recite a mental process.
Step 2A, prong 2
The claim further recites additional steps of
“accessing source data comprising source code or data about source code;
the alt tag is associated with an image …;
prompting the LLM with the prompt;
receiving a release note … in response to the prompt;
updating the source data …;
modifying the source code …”, and additional element “a large language model (LLM).”
These additional steps are insignificant extra solution activity elements, and additional element is just high level of generality as tool for performing the abstract idea. Therefore, they do not integrate the exception into a practical application.
Steps 2B
The claim as a whole is not amounted to significantly more than the judicial exception. In other words, claim 20 is directed to an abstract idea. Therefore, claim 20 is not patent eligible.
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 1, 5, 7, 9, 11, 14 – 16, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over JIN et al. (NPL “InterFix: End-to-End Program Repair with LLMs”; hereinafter Jin; IDS filed on 08/05/2024) in view of LEINONEN, et al. (NPL “Using large language models to enhance programming error messages”; hereinafter Leinonen; IDS dated 08/05/2024), ISHIKAWA (JP 2010128527 A; hereinafter Ishikawa), Kharbanda et al. (Pub. No. US 2024/0378236 A1; hereinafter Kharbanda), and Smith et al. (Pub. No. US 2024/0273291 A1; hereinafter Smith)
Claim 1
Jin teaches a computer-implemented method comprising:
accessing source data comprising source code (Jin; p. 2: right column: third full paragraph – p. 3: left column: first half paragraph; Figure 1 illustrates a typical software development workflow at Microsoft Developer Division in presence of InferFix. As a pull request proposing code changes (source data, source code) is created, continuous integration pipeline (CI) triggers unit testing, build, and Infer static analysis steps… Our approach combines a static analyzer to detect, localize, and classify bugs with a powerful LLM …
p. 5: left column: second full paragraph – third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs… Infer performs automated program analysis over this graph and produces compositional method summaries in order to determine whether there are defects (data, error) present in the source code (source data).);
finding an item in the source data, where the item is an alt tag in the source code (Jin; p. 2: right column: third full paragraph – p. 3: left column: first half paragraph; Figure 1 illustrates a typical software development workflow at Microsoft Developer Division in presence of InferFix. As a pull request proposing code changes (alt tag) is created, continuous integration pipeline (CI) triggers unit testing, build, and Infer static analysis steps… Our approach combines a static analyzer to detect, localize, and classify bugs with a powerful LLM …
p. 5: left column: second full paragraph – third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs… Infer performs automated program analysis over this graph and produces compositional method summaries in order to determine whether there are defects (data, error) present in the source code (source data, data, alt tag).), wherein:
; and
checking criteria by prompting a large language model (LLM) to analyze the alt tag (Jin; p. 5: left column: first full paragraph; Instruction learning is a prompt augmentation technique that introduces a natural language description of the task. To approach program repair, we prepare prompts following a template: We utilize OpenaAI GPT-3 Davinci model, a 175 billion parameter language model and a close sibling of ChatGPT, to complete the prompts…) and in response to results from the LLM indicating the alt tag is inadequate, determining that the criteria are met (Jin; p. 5: left column: third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs… Infer performs automated program analysis over this graph and produces compositional method summaries in order to determine whether there are defects (data, error) present in the source code (source data, data, alt tag);
p. 3: left column: last half paragraph; Infer is an open-source static analysis tool originating from program analysis research on separation logic … It computes program specifications to detect errors related to memory safety, concurrency, security, and more (compare with specification) …
p. 3: right column: right column: third full paragraph – last half paragraph; … we provide details on how we executed Infer over the change histories of software projects in order to detect introduced and fixed bugs.
Given as input the current commit curr and the previous commit prev, we begin by computing a git diff to identify the files involved in the change performed by the developer in the commit curr. Next, we analyze the status of the files at commit prev… we build the system using the project-specific build tool. During the build process, the infer capture command intercepts calls to the compiler to read source files and translates them into an intermediate representation which will allow Infer to analyze these files. Next, we invoke the infer analyze command specifying the files to be analyzed (i.e., the files diff involved in the commit). This analysis produces a report reportPrev detailing (completeness, quality) the bugs (error, item) identified within the specified files.
Subsequently, we move to the current commit curr and perform the same steps described for the commit prev, that is: checking out the commit, building system while capturing the source files, and analyzing the diff files in order to detect bugs.
Finally, with the infer reportdiff command, we compute the differences between the two infer reports reportPrev and reportCurr. The output bugs (error, item) contain three categories (criteria) of issues:
• introduced: issues found in curr but not in prev;
• fixed: issues (ticket thread) found in prev but not in curr;
• preexisting: issues (ticket thread) found in both prev and curr …);
in response to the criteria being met, generating, by a computing device, a large language model (LLM) prompt comprising (Jin; p. 2: right column: last full paragraph – p.3: left column: first half paragraph; Our approach combines a static analyzer to detect, localize, and classify bugs with a powerful LLM (finetuned 12 billion parameter Codex model) to generate fixes.
… The context preprocessing module utilizes the information provided by the analyzer to extract the buggy method, and retains surrounding context most relevant to fixing the bug … The retrieval augmentation engine then searches for semantically similar buggy code snippets in the historic database, prepending similar bug-fixes to the prompt. Finally, the augmented prompt is sent to the finetuned Codex model for inference …;
p. 5: left column: third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs … (iii) generator module – a large language model finetuned on a dataset of prompts enriched with the information provided by the static analyzer and the retriever to generate fixes (technical data).
p. 4: right column: last full paragraph; Demonstration learning is a prompt augmentation technique in which a few answered prompts are prepended to the context with the purpose of demonstrating how a language model should approach a downstream task. For program repair, we introduce a prefix constructed of two answered prompts as, followed by the actual buggy code snippet [X], as shown in Figure 3…; see Figs. 3 & 4;
p. 5: left column: first full paragraph; Instruction learning is a prompt augmentation technique that introduces a natural language description of the task. To approach program repair, we prepare prompts following a template: We utilize OpenaAI GPT-3 Davinci model, a 175 billion parameter language model and a close sibling of ChatGPT, to complete the prompts…; see Figs. 3 & 4),a release note pertaining to the item (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches … The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix) …)
inputting, by the computing device, the LLM prompt to the LLM, (Jin; p. 5: left column: second full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool …, (ii) retrieval module …, and (iii) generator module – a large language model finetuned on a dataset of prompts enriched with the information provided by the static analyzer and the retriever to generate fixes.), prompt was inputted to LLM;
receiving from the LLM, a release note in response to the LLM prompt (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches … The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix) …);
updating the source data using the release note received from the LLM (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches … The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix). The developer has the option to accept (update) or decline the recommended fix.), wherein the release note received from the LLM is programmatically inserted into a source code repository in a database configured to store a plurality of release notes (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches … The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix) …;
p. 2: left column: last full paragraph; … (iii) we introduce a dedicated prompt augmentation technique for program repair task, which leverages dense retrieval from an external database of historic bugs and fixes, bug type annotations, and syntactic hierarchies across the entire source code file affected by a bug …; bug, fixes, bug annotation, hierarchies == parts of release note and they are stored in database.); and
modifying the source code by adding the release note to the alt tag (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches. Each candidate patch is packaged as a separate Pull Request… The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note, technical data) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix). The developer has the option to accept or decline the recommended fix.)
But Jin does not explicitly teach the LLM prompt instructing an LLM to generate a release note pertaining to the item.
However, Leinonen teaches the LLM prompt instructing an LLM to generate a release note pertaining to the item (Leinonen; p. 564: left column: last half paragraph; Large Language Models (LLMs), particularly pre-trained transformer models … One such model is GPT-3 … GPT-3 also powers several other tools such as Codex …;
p. 564: right column: last half paragraph – p. 565: left column: second full paragraph; Programming error messages were generated using the most recent and performant Codex model … We evaluated a number of prompts to identify a version that seemed to provide useful explanations (release note) …; prompt instructs LLM to generate explanations;
p. 566: left column: section “5.1 Are Error Message Explanation Useful?”; Our results suggest that using large language models to explain programming error messages (PEMs) is feasible and shows promise…, See picture below. Also see code example 2 & 3 on p. 567.)
PNG
media_image1.png
401
470
media_image1.png
Greyscale
Jin and Leinonen are in the same analogous art as they are in the same field of endeavor, utilizing LLM for processing data. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Leinonen teachings into Jin invention to allow Jin to use LLM to enhance programming error messages with explanations of the errors and suggestions on how to fix them as suggested by Leinonen (abstract.)
But Jin and Leinonen do not explicitly teach the alt tag is associated with an image such that when the image cannot be displayed the alt tag is displayed place of the image, wherein the finding comprises finding alt tags in the source data.
However, Ishikawa teaches the alt tag is associated with an image such that when the image cannot be displayed the alt tag is displayed place of the image, wherein the finding comprises finding alt tags in the source data (Ishikawa; [0040] … FIG. 4 shows an example of description data (source data) written in HTML. The alternative text determining unit 41 detects (find) from this description data an <img> tag, which is an image display element for displaying an image, and determines whether or not alt attribute text (alt tag) is included in the <img> tag.
The alt attribute text is the character portion of “ALT attribute text” described by “alt=“ALT attribute text”” (alt tag) shown in FIG. 4, and is text that takes the place of an image.
[0045] … In FIG. 5A, text 51, “Text Near Image,” is displayed adjacent to the left side of an image 50 shown as a rectangle, and explains the contents of the image 50.
The alt attribute text 52 is displayed in place of the image 50 when loading of the image 50 fails, when the image 50 cannot be displayed, when the image 50 is not displayed, etc., and the display at that time will be as shown in Figure 5(b).)
Jin, Leinonen, and Ishikawa are in the same analogous art as they are in the same field of endeavor, processing source data. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Ishikawa teachings into Jin/Leinonen invention to allow Jin to process source data comprising image and alt tag, where the alt tag is displayed when the image in the source data cannot be displayed, as suggested by Ishikawa ([0040 & 0045,) to arrive at invention.
But Jin, Leinonen, and Ishikawa do not explicitly teach a large language model (LLM) prompt comprising an image associated with the alt tag.
However, Kharbanda teaches a large language model (LLM) prompt comprising an image associated with the alt tag (Kharbanda; [0104] FIG. 8 depicts a flow chart diagram of an example method 800 to provide visual search information derived from documents that include images retrieved based on a visual similarity with a query image…
[0107] In prior to processing the query image, the operations comprise obtaining the query image from the user computing device. For example, a user can utilize the user computing device to capture an image that depicts an unfamiliar object. To learn more about the object, the user can use a visual search service by providing the image and an associated prompt (e.g., “what is this object”, etc.) to the computing system. Alternatively, in some implementations, the computing system can receive the image and an associated prompt from an automated service or software program …; See Fig. 4 for visual search example.
[0108] At 804, the computing system can identify a plurality of source documents. Each of the plurality of source documents can include a result image of the plurality of result images and textual content associated with the result image…)
Jin, Leinonen, Ishikawa and Kharbanda are in the same analogous art as they are in the same field of endeavor, utilizing LLM for processing data. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Kumar teachings into Jin/Leinonen/Ishikawa invention to remove user’s personal data before inputting those into the LLM as suggested by Kumar (col. 7: 47 – 56 and col. 9: 11 – 21.)
But Jin, Leinonen, Ishikawa and Kharbanda do not explicitly teach the LLM prompt including a role.
However, Smith teaches the LLM prompt including a role (Smith; [0294] FIG. 18 is a flow diagram of an example method 1800 for prompt and content generation…
[0296] At operation 1802, the processing device creates a first set of title prompts by applying a first set of title prompt templates to a seed…; [0301] At operation 1804, the processing device, in response to input of the first set of title prompts to a first generative language model, outputs, by the first generative language model, based on the first set of title prompts, a first set of document titles…
[0112] To produce generated prompt 304, prompt generation subsystem 302 applies a prompt template to the seed. A prompt template includes a format (style) and/or specification (style) for arranging data and/or instructions, including the seed, for input a generative language model so that the generative language model can read and process the inputs and generate corresponding output…”
[0163] The following is an example of how a prompt can be refined based on pre-publication feedback and/or post publication feedback. Suppose a prompt template includes the following: “write an article about [title] in the style of the Harvard Business Review,” …) “Harvard Business” == role.
Jin, Leinonen, Ishikawa, Kharbanda and Smith are in the same analogous art as they are in the same field of endeavor, creating prompt for language model. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Smith teachings into Jin/Leinonen/Ishikawa/Kharbanda invention to generate and refines prompt by formatting the prompt to improve likelihood the desired output is produced as suggested by smith ([0039].)
Claim 5
Smith teaches the role is a technical writer role, further comprising prompting the LLM with writing style (Smith; [0294] FIG. 18 is a flow diagram of an example method 1800 for prompt and content generation…
[0296] At operation 1802, the processing device creates a first set of title prompts by applying a first set of title prompt templates to a seed…; [0301] At operation 1804, the processing device, in response to input of the first set of title prompts to a first generative language model, outputs, by the first generative language model, based on the first set of title prompts, a first set of document titles…
[0112] To produce generated prompt 304, prompt generation subsystem 302 applies a prompt template to the seed. A prompt template includes a format (style) and/or specification (style) for arranging data and/or instructions, including the seed, for input a generative language model so that the generative language model can read and process the inputs and generate corresponding output…”
[0163] The following is an example of how a prompt can be refined based on pre-publication feedback and/or post publication feedback. Suppose a prompt template includes the following: “write an article about [title] in the style of the Harvard Business Review,” …) “Harvard Business” == role. Motivation for incorporating Smith into Jin/Leinonen/Ishikawa/Kharbanda is the same as motivation in claim 1.
Claim 7
Jin also teaches the LLM is adapted by training the LLM with content from an enterprise which produces the source data (Jin; p. 1: left column: last full paragraph; To train and evaluate our approach, we curated InferredBugs, a novel, metadata-rich dataset of bugs extracted by executing the Infer static analyzer on the change histories of thousands of Java and C# repositories. Our evaluation demonstrates that InferFix outperforms strong LLM baselines …)
Claim 9
Jin also teaches in response to determining the criteria are met, where the prompt comprises the alt tag, source code around the alt tag and a request to improve the alt tag (Jin; p. 4: right column: last full paragraph; Demonstration learning is a prompt augmentation technique in which a few answered prompts are prepended to the context with the purpose of demonstrating how a language model should approach a downstream task. For program repair, we introduce a prefix constructed of two answered prompts as, followed by the actual buggy code snippet [X], as shown in Figure 3…; (see picture below);
p. 5: left column: first full paragraph; Instruction learning is a prompt augmentation technique that introduces a natural language description of the task. To approach program repair, we prepare prompts following a template: We utilize OpenaAI GPT-3 Davinci model, a 175 billion parameter language model and a close sibling of ChatGPT, to complete the prompts…; (see picture below)); and
PNG
media_image2.png
150
488
media_image2.png
Greyscale
PNG
media_image3.png
144
494
media_image3.png
Greyscale
)
Claim 11
Jin also teaches in response to the results from the LLM indicating the alt tag is adequate, determining the criteria are not met and finding a next item in the source data (Jin; p. 5: left column: third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs… Infer performs automated program analysis over this graph and produces compositional method summaries in order to determine whether there are defects (data, error) present in the source code (source data, data, alt tag);
p. 3: left column: last half paragraph; Infer is an open-source static analysis tool originating from program analysis research on separation logic … It computes program specifications to detect errors related to memory safety, concurrency, security, and more (compare with specification) …
p. 3: right column: right column: third full paragraph – last half paragraph; … we provide details on how we executed Infer over the change histories of software projects in order to detect introduced and fixed bugs.
Given as input the current commit curr and the previous commit prev, we begin by computing a git diff to identify the files involved in the change performed by the developer in the commit curr. Next, we analyze the status of the files at commit prev… we build the system using the project-specific build tool. During the build process, the infer capture command intercepts calls to the compiler to read source files and translates them into an intermediate representation which will allow Infer to analyze these files. Next, we invoke the infer analyze command specifying the files to be analyzed (i.e., the files diff involved in the commit). This analysis produces a report reportPrev detailing (completeness, quality) the bugs (error, item) identified within the specified files.
Subsequently, we move to the current commit curr and perform the same steps described for the commit prev, that is: checking out the commit, building system while capturing the source files, and analyzing the diff files in order to detect bugs.
Finally, with the infer reportdiff command, we compute the differences between the two infer reports reportPrev and reportCurr. The output bugs (error, item) contain three categories (criteria) of issues:
• introduced: issues found in curr but not in prev;
• fixed: issues (ticket thread) found in prev but not in curr;
• preexisting: issues (ticket thread) found in both prev and curr …)
Claim 14
Jin also teaches only storing the release note or only updating the source data with the release note received from the LLM, in response to input from an operator (Jin; p. 8: right column: second full paragraph – p. 9: left column: first half paragraph; …If bugs are detected, the InferFix patch generation module is invoked to propose a fix… The InferFix module proposes a (configurable) set of candidate patches… The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request … The developer has the option to accept (update) or decline the recommended fix (technical data).) Update only when developer accepts the recommended fix.
Claim 15
Jin also teaches adding a command token in the LLM prompt where the command token triggers the LLM to call a search engine using a query comprising key words from the LLM prompt (Jin; p. 5: left column: third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs, (ii) retrieval module – a large index of historic bugs and fixes, equipped with a facility to efficiently search and retrieve “hints” – semantically-similar source code segments – given a query…)
Claim 16
This is an apparatus version of the method version in claim 1; therefore, it is rejected for the same reasons. Furthermore, Jin implicitly teaches an apparatus comprising a processor and a memory storing instructions (Jin’s method is to be performed by a computer. Therefore, the computer is implicitly disclosed, wherein the computer comprises a processor and memory storing instructions.)
Claim 19
This limitation is already discussed in claim 5; therefore, it is rejected for the same reasons.
Claim 20
Jin teaches a computer-implemented method comprising:
accessing source data comprising source code (Jin; p. 2: right column: third full paragraph – p. 3: left column: first half paragraph; Figure 1 illustrates a typical software development workflow at Microsoft Developer Division in presence of InferFix. As a pull request proposing code changes (source data, source code) is created, continuous integration pipeline (CI) triggers unit testing, build, and Infer static analysis steps… Our approach combines a static analyzer to detect, localize, and classify bugs with a powerful LLM …
p. 5: left column: second full paragraph – third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs… Infer performs automated program analysis over this graph and produces compositional method summaries in order to determine whether there are defects (data, error) present in the source code (source data).);
finding an item in the source data, where the item is an alt tag in the source code (Jin; p. 2: right column: third full paragraph – p. 3: left column: first half paragraph; Figure 1 illustrates a typical software development workflow at Microsoft Developer Division in presence of InferFix. As a pull request proposing code changes (alt tag) is created, continuous integration pipeline (CI) triggers unit testing, build, and Infer static analysis steps… Our approach combines a static analyzer to detect, localize, and classify bugs with a powerful LLM …
p. 5: left column: second full paragraph – third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs… Infer performs automated program analysis over this graph and produces compositional method summaries in order to determine whether there are defects (data, error) present in the source code (source data, data, alt tag).), wherein:
; and
checking criteria by prompting a large language model (LLM) to analyze the alt tag (Jin; p. 5: left column: first full paragraph; Instruction learning is a prompt augmentation technique that introduces a natural language description of the task. To approach program repair, we prepare prompts following a template: We utilize OpenaAI GPT-3 Davinci model, a 175 billion parameter language model and a close sibling of ChatGPT, to complete the prompts…) and in response to results from the LLM indicating the alt tag is inadequate, determining that the criteria are met (Jin; p. 5: left column: third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs… Infer performs automated program analysis over this graph and produces compositional method summaries in order to determine whether there are defects (data, error) present in the source code (source data, data, alt tag);
p. 3: left column: last half paragraph; Infer is an open-source static analysis tool originating from program analysis research on separation logic … It computes program specifications to detect errors related to memory safety, concurrency, security, and more (compare with specification) …
p. 3: right column: right column: third full paragraph – last half paragraph; … we provide details on how we executed Infer over the change histories of software projects in order to detect introduced and fixed bugs.
Given as input the current commit curr and the previous commit prev, we begin by computing a git diff to identify the files involved in the change performed by the developer in the commit curr. Next, we analyze the status of the files at commit prev… we build the system using the project-specific build tool. During the build process, the infer capture command intercepts calls to the compiler to read source files and translates them into an intermediate representation which will allow Infer to analyze these files. Next, we invoke the infer analyze command specifying the files to be analyzed (i.e., the files diff involved in the commit). This analysis produces a report reportPrev detailing (completeness, quality) the bugs (error, item) identified within the specified files.
Subsequently, we move to the current commit curr and perform the same steps described for the commit prev, that is: checking out the commit, building system while capturing the source files, and analyzing the diff files in order to detect bugs.
Finally, with the infer reportdiff command, we compute the differences between the two infer reports reportPrev and reportCurr. The output bugs (error, item) contain three categories (criteria) of issues:
• introduced: issues found in curr but not in prev;
• fixed: issues (ticket thread) found in prev but not in curr;
• preexisting: issues (ticket thread) found in both prev and curr …);
in response to the criteria being met, generating, by a computing device, a large language model (LLM) prompt comprising (Jin; p. 2: right column: last full paragraph – p.3: left column: first half paragraph; Our approach combines a static analyzer to detect, localize, and classify bugs with a powerful LLM (finetuned 12 billion parameter Codex model) to generate fixes.
… The context preprocessing module utilizes the information provided by the analyzer to extract the buggy method, and retains surrounding context most relevant to fixing the bug … The retrieval augmentation engine then searches for semantically similar buggy code snippets in the historic database, prepending similar bug-fixes to the prompt. Finally, the augmented prompt is sent to the finetuned Codex model for inference …;
p. 5: left column: third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs … (iii) generator module – a large language model finetuned on a dataset of prompts enriched with the information provided by the static analyzer and the retriever to generate fixes (technical data).
p. 4: right column: last full paragraph; Demonstration learning is a prompt augmentation technique in which a few answered prompts are prepended to the context with the purpose of demonstrating how a language model should approach a downstream task. For program repair, we introduce a prefix constructed of two answered prompts as, followed by the actual buggy code snippet [X], as shown in Figure 3…; see Figs. 3 & 4;
p. 5: left column: first full paragraph; Instruction learning is a prompt augmentation technique that introduces a natural language description of the task. To approach program repair, we prepare prompts following a template: We utilize OpenaAI GPT-3 Davinci model, a 175 billion parameter language model and a close sibling of ChatGPT, to complete the prompts…; see Figs. 3 & 4),a release note pertaining to the item (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches … The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix) …)
prompting the LLM with the prompt (Jin; p. 2: right column: last full paragraph – p.3: left column: first half paragraph; Our approach combines a static analyzer to detect, localize, and classify bugs with a powerful LLM (finetuned 12 billion parameter Codex model) to generate fixes.
… The context preprocessing module utilizes the information provided by the analyzer to extract the buggy method, and retains surrounding context most relevant to fixing the bug … The retrieval augmentation engine then searches for semantically similar buggy code snippets in the historic database, prepending similar bug-fixes to the prompt. Finally, the augmented prompt is sent to the finetuned Codex model for inference …;
p. 5: left column: third full paragraph; InferFix program repair framework is composed of three following key modules: (i) a static analysis tool that detects, localizes, and classifies bugs … (iii) generator module – a large language model finetuned on a dataset of prompts enriched with the information provided by the static analyzer and the retriever to generate fixes (technical data).
p. 4: right column: last full paragraph; Demonstration learning is a prompt augmentation technique in which a few answered prompts are prepended to the context with the purpose of demonstrating how a language model should approach a downstream task. For program repair, we introduce a prefix constructed of two answered prompts as, followed by the actual buggy code snippet [X], as shown in Figure 3…; (see picture below);
p. 5: left column: first full paragraph; Instruction learning is a prompt augmentation technique that introduces a natural language description of the task. To approach program repair, we prepare prompts following a template: We utilize OpenaAI GPT-3 Davinci model, a 175 billion parameter language model and a close sibling of ChatGPT, to complete the prompts…; (see picture below));
PNG
media_image2.png
150
488
media_image2.png
Greyscale
PNG
media_image3.png
144
494
media_image3.png
Greyscale
receiving a release note from the LLM in response to the LLM prompt (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches … The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix) …);
updating the source data using the release note received from the LLM (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches … The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix). The developer has the option to accept (update) or decline the recommended fix.), wherein the release note received from the LLM is programmatically inserted into a source code repository in a database configured to store a plurality of release notes (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches … The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix) …;
p. 2: left column: last full paragraph; … (iii) we introduce a dedicated prompt augmentation technique for program repair task, which leverages dense retrieval from an external database of historic bugs and fixes, bug type annotations, and syntactic hierarchies across the entire source code file affected by a bug …; bug, fixes, bug annotation, hierarchies == parts of release note and they are stored in database.); and
modifying the source code by adding the release note to the alt tag (Jin; p. 8: right column: last half paragraph – p. 9: left column: first half paragraph; The InferFix module proposes a (configurable) set of candidate patches. Each candidate patch is packaged as a separate Pull Request… The validated fix is then provided to the developer within the feature branch of the developer’s Pull Request… We implemented a GitHub action which receives a validated patch from InferFix and surfaces it to the developer in form of a GitHub comment (release note, technical data) in the PR. The comment provides detailed information about the bug (i.e., extracted by Infer), and the resolution (i.e., served by InferFix). The developer has the option to accept or decline the recommended fix.)
But Jin does not explicitly teach the LLM prompt instructing an LLM to generate a release note pertaining to the item.
However, Leinonen teaches the LLM prompt instructing an LLM to generate a release note pertaining to the item (Leinonen; p. 564: left column: last half paragraph; Large Language Models (LLMs), particularly pre-trained transformer models … One such model is GPT-3 … GPT-3 also powers several other tools such as Codex …;
p. 564: right column: last half paragraph – p. 565: left column: second full paragraph; Programming error messages were generated using the most recent and performant Codex model … We evaluated a number of prompts to identify a version that seemed to provide useful explanations (release note) …; prompt instructs LLM to generate explanations;
p. 566: left column: section “5.1 Are Error Message Explanation Useful?”; Our results suggest that using large language models to explain programming error messages (PEMs) is feasible and shows promise…, See picture below. Also see code example 2 & 3 on p. 567.)
PNG
media_image1.png
401
470
media_image1.png
Greyscale
Jin and Leinonen are in the same analogous art as they are in the same field of endeavor, utilizing LLM for processing data. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Leinonen teachings into Jin invention to allow Jin to use LLM to enhance programming error messages with explanations of the errors and suggestions on how to fix them as suggested by Leinonen (abstract.)
But Jin and Leinonen do not explicitly teach the alt tag is associated with an image such that when the image cannot be displayed the alt tag is displayed place of the image, wherein the finding comprises finding alt tags in the source data.
However, Ishikawa teaches the alt tag is associated with an image such that when the image cannot be displayed the alt tag is displayed place of the image, wherein the finding comprises finding alt tags in the source data (Ishikawa; [0040] … FIG. 4 shows an example of description data (source data) written in HTML. The alternative text determining unit 41 detects (find) from this description data an <img> tag, which is an image display element for displaying an image, and determines whether or not alt attribute text (alt tag) is included in the <img> tag.
The alt attribute text is the character portion of “ALT attribute text” described by “alt=“ALT attribute text”” (alt tag) shown in FIG. 4, and is text that takes the place of an image.
[0045] … In FIG. 5A, text 51, “Text Near Image,” is displayed adjacent to the left side of an image 50 shown as a rectangle, and explains the contents of the image 50.
The alt attribute text 52 is displayed in place of the image 50 when loading of the image 50 fails, when the image 50 cannot be displayed, when the image 50 is not displayed, etc., and the display at that time will be as shown in Figure 5(b).)
Jin, Leinonen, and Ishikawa are in the same analogous art as they are in the same field of endeavor, processing source data. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Ishikawa teachings into Jin/Leinonen invention to allow Jin to process source data comprising image and alt tag, where the alt tag is displayed when the image in the source data cannot be displayed, as suggested by Ishikawa ([0040 & 0045,) to arrive at invention.
But Jin, Leinonen, and Ishikawa do not explicitly teach a large language model (LLM) prompt comprising an image associated with the alt tag.
However, Kharbanda teaches a large language model (LLM) prompt comprising an image associated with the alt tag (Kharbanda; [0104] FIG. 8 depicts a flow chart diagram of an example method 800 to provide visual search information derived from documents that include images retrieved based on a visual similarity with a query image…
[0107] In prior to processing the query image, the operations comprise obtaining the query image from the user computing device. For example, a user can utilize the user computing device to capture an image that depicts an unfamiliar object. To learn more about the object, the user can use a visual search service by providing the image and an associated prompt (e.g., “what is this object”, etc.) to the computing system. Alternatively, in some implementations, the computing system can receive the image and an associated prompt from an automated service or software program …; See Fig. 4 for visual search example.
[0108] At 804, the computing system can identify a plurality of source documents. Each of the plurality of source documents can include a result image of the plurality of result images and textual content associated with the result image…)
Jin, Leinonen, Ishikawa and Kharbanda are in the same analogous art as they are in the same field of endeavor, utilizing LLM for processing data. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Kumar teachings into Jin/Leinonen/Ishikawa invention to remove user’s personal data before inputting those into the LLM as suggested by Kumar (col. 7: 47 – 56 and col. 9: 11 – 21.)
But Jin, Leinonen, Ishikawa and Kharbanda do not explicitly teach prompting the LLM with the prompt and a role
However, Smith teaches prompting the LLM with the prompt and a role (Smith; [0294] FIG. 18 is a flow diagram of an example method 1800 for prompt and content generation…
[0296] At operation 1802, the processing device creates a first set of title prompts by applying a first set of title prompt templates to a seed…; [0301] At operation 1804, the processing device, in response to input of the first set of title prompts to a first generative language model, outputs, by the first generative language model, based on the first set of title prompts, a first set of document titles…
[0112] To produce generated prompt 304, prompt generation subsystem 302 applies a prompt template to the seed. A prompt template includes a format (style) and/or specification (style) for arranging data and/or instructions, including the seed, for input a generative language model so that the generative language model can read and process the inputs and generate corresponding output…”
[0163] The following is an example of how a prompt can be refined based on pre-publication feedback and/or post publication feedback. Suppose a prompt template includes the following: “write an article about [title] in the style of the Harvard Business Review,” …) “Harvard Business” == role.
Jin, Leinonen, Ishikawa, Kharbanda and Smith are in the same analogous art as they are in the same field of endeavor, creating prompt for language model. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Smith teachings into Jin/Leinonen/Ishikawa/Kharbanda invention to generate and refines prompt by formatting the prompt to improve likelihood the desired output is produced as suggested by smith ([0039].)
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Jin, Leinonen, Ishikawa, Kharbanda and Smith as applied to claim 1 above, and further in view of Kumar et al. (Patent. No. US 11,855,860 B1; hereinafter Kumar.)
Claim 6
Jin, Leinonen, Ishikawa, Kharbanda and Smith do not explicitly teach prior to prompting the LLM with the al tag, removing personal data from the alt tag.
However, Kumar teaches prior to prompting the LLM with the alt tag, removing personal data from the alt tag (Kharbanda; Fig. 1; col. 7: 47 – 56; The ticket processor 121 may also be configured to remove any personal information of the user 105, such as name, email address, or phone number…Thus, the ticket processor 121 may perform processing as simple as word and character counting, or as complex as having a separately trained natural language processing (NLP) and/or natural language understanding (NLU) model used to recognize and characterize included ticket content.
Col. 9: 11 – 21; Thus, through the operations of the training manager 102 as described above, and provided in more detail, below, raw incident ticket data in the ticket data repository 109 may be transformed into high-quality training data in the processed training data 124. Consequently, the training engine 126 may be enabled to quickly and efficiently generate one or more domain-specific LLMs…)
Jin, Leinonen, Ishikawa, Kharbanda, Smith and Kumar are in the same analogous art as they are in the same field of endeavor, utilizing LLM for processing data. Therefore, it would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention, to incorporate Kumar teachings into Jin/Leinonen/Ishikawa/Kharbanda/Smith invention to remove user’s personal data before inputting those into the LLM as suggested by Kumar (col. 7: 47 – 56 and col. 9: 11 – 21.)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CUONG V LUU whose telephone number is (571)270-1733. The examiner can normally be reached 6:30 AM - 3:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S. Sough can be reached on (571) 272-6799. 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.
/CUONG V LUU/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights