DETAILED ACTION
This action is responsive to the application filed on August 07, 2024, which is continuation in part of 18/791,723 filed on August 01, 2024 and claims priority from Provisional Application 63/657,362 filed on June 07, 2024.
The preliminary amendments filed on August 13, 2024 have been acknowledged and considered.
Claims 1-20 are pending and presented to examination.
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 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.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submission of the Information Disclosure Statement dated November 13, 2024 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Drawings
The drawings filed on August 13, 2024 are acceptable for examination purposes.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because it contains more than 150 words in length, also begins with “one embodiment of the present invention related to”, this section should be discarded. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Objections
Claims 4, 15-20 are objected to because of the following informalities: Claim 4 (and similar for claim 16) recites “wherein (B) comprises using a large language model (LLM) embedding model to generating the plurality of generated semantic embeddings.”. Replace “generating” to –generate--. Claims 15-20 begins as “The method of claim 14…” and should be “The system of claim 14…”. Replace “method” to –system--. Appropriate correction is required. Please amend the claim language indicated in bold.
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 recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-13 are directed to methods and fall within the statutory category of processes and Claims 14-20 are directed to systems and fall within the statutory category of machines. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 1 and 14 as drafted, recite a process that, under its broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations: Claim 1 (and similar for claim 14)
a) “(A) chunking subject source code into a plurality of source code chunks;” – Mental Process, See MPEP 2106.04(a)(2), III. For example, dividing a document (e.g. source code) into sections.
b) “(B) generating, for each of the plurality of source code chunks, a corresponding plurality of semantic embeddings, thereby generating a plurality of generated semantic embeddings, wherein each of the plurality of generated semantic embeddings corresponds to a corresponding segment of source code in the plurality of source code chunks;” – Mental Process, See MPEP 2106.04(a)(2), III. For example, characterizing semantics of each section to indicate what the code does.
c) “(D) comparing the plurality of generated semantic embeddings with the plurality of baseline semantic embeddings to generate comparison output.” – Mental Process, See MPEP 2106.04(a)(2), III. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, (i.e., “chunking”, “generating”, “comparing”) can be performed in the human mind though observation, evaluation, judgment, opinion with the aid of pen and paper. Thus, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Therefore, Yes, claims 1 and 14 recite judicial exceptions.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
This judicial exception is not integrated into a practical application. The claims
recite the following additional elements: “at least one computer processor”, “at least one non-transitory computer-readable medium”, “a database” and “a system”. The additional elements are merely instructions to implement an abstract idea on a computer, or merely using a generic computer or computer components as a tool to perform the abstract idea (see MPEP 2106.05(f)). There is an additional element in the claim.
Additional element 1 - “(C) retrieving a plurality of baseline semantic embeddings from a database, wherein the plurality of baseline semantic embeddings correspond to a plurality of previously analyzed segments of reference source code;” -insignificant extra-solution activity (Data Gathering), See MPEP 2106.05(g).
Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, thus failing to integrate the abstract idea into a practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1 and 14 not only recites a judicial exception but that the claim is directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
As discussed above with respect to integration of the abstract idea into a
practical application, the additional elements “at least one computer processor”, “at least one non-transitory computer-readable medium”, “a database” and “a system” are generic computer components used as tools to perform the abstract idea.
Accordingly, the additional elements recited in the claims cannot provide an inventive concept. In addition, after further evaluation the claim as a whole doesn’t improve any function of a computer or to any other technology or technical field. Thus, the claims are not patent eligible.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claims 1 and 14 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 2 (and similar for claim 15) adds the limitation that the chunking of subject source code is performed “based on a predetermined grain size.” This additional limitation merely specifies a numerical parameter (the predetermined number of lines per chunk) of the partitioning operation already recited in claim 1. Partitioning data into uniformly sized pieces according to a predetermined size parameter is itself a mathematical concept (a mathematical relationship between input length and chunk count) and a mental process (a person could mentally divide a code listing into fixed-size sections). The added limitation therefore falls within the same abstract idea grouping (mathematical concept and mental process) as claim 1, and does not add additional elements that integrate the exception into a practical application.
Claim 3 adds the limitation that “each of the plurality of source code chunks has a size that is equal to the predetermined grain size.” This further specifies the uniformity of the partitioning recited in claim 2 and does not add any element outside the abstract idea. The limitation continues to recite a mathematical concept (a uniform-size partitioning relationship between input data and resulting partitions) and remains within the mental-process grouping as well.
Claim 4 (and similar for claim 16) adds the limitation that limitation (B) of claim 1 comprises “using a large language model (LLM) embedding model” to generate the semantic embeddings. The LLM is recited at a high level of generality, without any specification of architecture, training methodology, or implementation detail, and is invoked as a generic computational tool to perform the previously recited mathematical embedding operation. Under MPEP § 2106.05(f), reciting a generic computer component or artificial-intelligence model as a tool to implement an abstract idea (“apply it” language) does not integrate the judicial exception into a practical application. The use of pre-trained LLM embedding models for code-vectorization tasks was further well-understood, routine, and conventional in the field as of the effective filing date, as evidenced on the face of the prior art relied upon for the §§ 102/103 rejections (Ebrahim § 3.2.1 expressly identifies CodeBERT, GraphCodeBert, UnixCoder, CodeT5, CodeGPT, PLBART, and CodeBERTa as pre-trained models then available from HuggingFace), and therefore additionally falls under MPEP § 2106.05(d).
Claim 5 (and similar for claim 17) adds the limitation that “each of the plurality of generated semantic embeddings has at least 100 dimensions.” This limitation specifies a numerical property (the dimensionality) of the mathematical vector objects produced by the embedding operation. Specifying the dimensionality of a vector is a mathematical concept and does not add any additional element outside the abstract idea. The claim therefore remains within the mathematical-concept grouping and does not integrate the exception into a practical application.
Claim 6 adds the limitation that “each of the plurality of generated semantic embeddings has 768 dimensions.” This further narrows the numerical dimensionality of the mathematical vector objects to a specific value (768). For the same reasons set forth above for claim 5, the limitation remains within the mathematical-concept grouping and does not integrate the exception into a practical application.
Claim 7 (and similar for claim 18) adds the limitation that limitation (B) of claim 1 “comprises not generating semantic embeddings for binary code in the plurality of source code chunks.” This limitation recites a pre-solution data-selection step in which input data (chunks containing binary code) is filtered out before the main abstract operation (embedding) is performed on the remaining chunks. Under MPEP § 2106.05(g), pre-solution data selection or filtering of inputs to the abstract operation is insignificant extra-solution activity that does not integrate the judicial exception into a practical application. The claim accordingly remains directed to the same abstract idea as claim 1.
Claim 8 adds the limitation that limitation (B) of claim 1 “further comprises compressing the plurality of generated semantic embeddings.” Compressing vector embeddings (which the present specification at paragraph [0076] expressly defines to include dimensionality reduction, vector quantization, lossy compression, sparse representation, and entropy encoding) is itself a mathematical operation applied to mathematical objects (vector embeddings), and as such falls within the mathematical-concept grouping. The limitation does not introduce any additional element outside the abstract idea and does not integrate the exception into a practical application.
Claim 9 (and similar for claim 19) adds the limitations of “extracting metadata from the plurality of source code chunks” and using that metadata “to assist in comparing” the embeddings. The extraction of metadata (such as filename, line number, and chunk size, per Specification paragraph [0077]) from the input source code chunks is a pre-solution data-gathering step that supplies ancillary information accompanying the main abstract operation. Under MPEP § 2106.05(g), pre-solution data gathering is insignificant extra-solution activity that does not integrate the judicial exception into a practical application. The downstream “using the metadata to assist in comparing” step does not transform the abstract comparison into a practical application either, as it merely supplies additional data inputs to the same mental/mathematical comparison operation.
Claim 10 (and similar for claim 20) adds the limitations of “extracting metadata from the plurality of generated semantic embeddings” and using that metadata “to assist in comparing” the embeddings. The extraction of metadata from the generated semantic embeddings themselves (such as cluster centroids, cluster statistical properties, or other statistical summaries derived from analyzing the vector embeddings) is itself a mathematical operation applied to mathematical objects. The limitation therefore remains within the mathematical-concept grouping. Using the extracted statistical/cluster metadata in the comparison computation is part of the same mathematical comparison operation and does not integrate the exception into a practical application.
Claim 11 adds the limitations of “measuring distances between the plurality of generated semantic embeddings and the plurality of baseline semantic embeddings” and “generating the comparison output based on the distances.” Measuring a distance between two vectors is a mathematical concept (a mathematical calculation using a distance formula such as cosine, Euclidean, or Manhattan distance). The limitation therefore falls within the mathematical-concept grouping and does not add any additional element outside the abstract idea.
Claim 12 adds the limitation that “the comparison output includes the distances.” This limitation merely specifies that the calculated distance values are included in the post-solution output of the abstract comparison operation. Under MPEP § 2106.05(g), including a calculated result of the abstract operation in its output is insignificant post-solution output activity that does not integrate the judicial exception into a practical application.
Claim 13 adds the limitations of “computing a metric based on the distances” and “including the metric in the comparison output.” The computation of a metric from the distances is itself a mathematical operation (the metric is a mathematical function of the distance values) and falls within the mathematical-concept grouping. To the extent claim 13 separately recites “including the metric in the comparison output,” that sub-limitation is post-solution output activity that is insignificant extra-solution activity under MPEP § 2106.05(g). The limitation as a whole does not integrate the exception into a practical application.
Therefore, Claims 1-20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
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.
Claims 1, 4 and 11-16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Fahad Ebrahim et al. (“Source Code Plagiarism Detection with Pre-Trained Model Embeddings and Automated Machine Learning”, hereinafter Ebrahim).
With respect to claim 1, Ebrahim teaches a method performed by at least one computer processor executing computer program instructions stored on at least one non-transitory computer-readable medium (Ebrahim describes a computer-implemented method utilizing pre-trained machine learning models (CodePTMs) executed via Python tooling including the Sentence Transformers library and the AutoSklearn AutoML library (Ebrahim section 3.2, Page 3: “The embeddings are created using Sentence Transformers with mean pooling”; Section 3.4, Page 5: “The library selected for this work is AutoSklearn”). The full training, embedding, similarity-computation, and classification pipeline is executed on computing hardware (Ebrahim Figure 1, Page 6). A computer-implemented method utilizing executable software libraries inherently requires storage of computer program instructions on a non-transitory computer-readable medium and execution of those instructions by at least one computer processor (MPEP § 2112). The preamble is therefore disclosed by Ebrahim), the method comprising: (A) chunking subject source code into a plurality of source code chunks (Ebrahim discloses processing subject source code organized as a plurality of files (Ebrahim section 3.1, Page 3: “The SOCO dataset contains training and testing data written in C++ and Java. The training set in C++ included 79 files with 26 reuse cases, while there were 259 files with 84 reuse cases written in Java. For the testing set, in C++, there were 19,895 files with 322 reuse cases, while in Java, there were 12,080 files with 222 reuse cases”). Each file is processed as an independent unit (Ebrahim section 3.2, Page 3: “The source code was written in different files and had to be arranged into a suitable data structure”). Under the broadest reasonable interpretation in light of the present specification, which expressly defines chunking to include file-level segmentation (Specification paragraph [0055]: “the chunking module 304 … chunks the subject source code 302 (e.g., each of a plurality of files within the subject source code 302) into source code chunks 306”), Ebrahim’s file-level segmentation reads on the recited chunking). (B) generating, for each of the plurality of source code chunks, a corresponding plurality of semantic embeddings, thereby generating a plurality of generated semantic embeddings, wherein each of the plurality of generated semantic embeddings corresponds to a corresponding segment of source code in the plurality of source code chunks (Ebrahim discloses generating, for each chunk of source code, a corresponding semantic embedding using pre-trained models (Ebrahim Abstract, Page 1: “Source codes should be converted to vector representations that capture both the syntax and semantics of the text, known as contextual embeddings. These embeddings would be generated using source code pre-trained models (CodePTMs)”; Section 3.2, Page 3: “Embeddings are vector representations of source code that can be created with pre-trained models. The embeddings are created using Sentence Transformers with mean pooling”). Each file processed by the CodePTMs yields its own corresponding embedding (Ebrahim Figure 1, Page 6, showing Code 1 and Code 2 each independently embedded into Embedding 1 and Embedding 2 by the CodePTM models). The CodePTMs used to generate the embeddings are identified at Ebrahim section 3.2.1, Page 4: “The three pre-trained models that yielded acceptable similarity scores were UnixCoder, PLBART and CodeBERTa.” Each generated embedding corresponds to its originating source code file (chunk), satisfying the wherein clause.). (C) retrieving a plurality of baseline semantic embeddings from a database, wherein the plurality of baseline semantic embeddings correspond to a plurality of previously analyzed segments of reference source code (Ebrahim discloses use of the SOCO source code reuse dataset as a structured corpus of previously analyzed reference source code, organized in defined scenarios (Ebrahim section 2.1, Page 2: “This work uses the SOCO dataset and the approach followed will be compared to the other approaches based on the same dataset”; Section 3.1, Page 3: “The SOCO dataset contains training and testing data written in C++ and Java … There were six different scenarios per language, labelled A1, A2, B1, B2, C1, and C2”). The system retrieves reference source code files from the SOCO corpus and independently embeds them via the CodePTMs to produce baseline embeddings against which the embeddings of the query source code are compared (Ebrahim Figure 1, Page 6, illustrating the testing pipeline). Under the broadest reasonable interpretation in light of the present specification, the term “database” encompasses any structured collection of data from which items are retrieved for processing; the SOCO corpus, organized by scenario and accessed for retrieval of reference source code, reads on “a database.” The embeddings produced by the CodePTMs from the retrieved reference source code are the recited “baseline semantic embeddings” that “correspond to a plurality of previously analyzed segments of reference source code.” (D) comparing the plurality of generated semantic embeddings with the plurality of baseline semantic embeddings to generate comparison output (Ebrahim discloses computing cosine similarity scores between the generated semantic embeddings and the baseline semantic embeddings as the comparison operation (Ebrahim section 3.3, Page 5: “Cosine similarity is a common measurement of similarity used in NLP. It represents the angle between two vectors, and the angle (θ) is equal to the dot product of the two vectors (A and B) over the product of their norms”; Equation 1 setting forth the cosine similarity formula; “The three features of the model would be the cosine similarity scores between the three generated embeddings per source code”). The cosine similarity scores are then provided to a classifier to generate the comparison output (Ebrahim section 3.4, Page 5: “For testing, the similarity scores are fed to the selected algorithms to create prediction probabilities that are compared to a dynamic threshold determining whether the files are plagiarised or not”).
With respect to claim 4, Ebrahim teaches wherein (B) comprises using a large language model (LLM) embedding model to generating the plurality of generated semantic embeddings (Ebrahim discloses the limitations of claim 1, as set forth above, and additionally discloses the limitation of claim 4. Specifically, Ebrahim expressly identifies the CodePTMs used to generate the embeddings as including CodeBERT, GraphCodeBert, UnixCoder, CodeT5, CodeGPT, PLBART, and CodeBERTa (Ebrahim section 3.2.1, Page 4: “The models available in Huggingface are CodeBert (Feng et al., 2020), GraphCodeBert (Guo et al., 2020), UnixCoder (Guo et al., 2022), CodeT5 (Wang et al., 2021), CodeGPT (Lu et al., 2021), PLBART (Ahmad et al., 2021), and CodeBERTa (Wolf et al., 2019)”), and ultimately uses UnixCoder, PLBART, and CodeBERTa (Ebrahim section 3.2.1, Page 4: “The three pre-trained models that yielded acceptable similarity scores were UnixCoder, PLBART and CodeBERTa”). These CodePTMs are large-language-model-based transformer architectures pre-trained on substantial code corpora, and read on the term “large language model (LLM) embedding model” under the broadest reasonable interpretation in light of the present specification (Specification paragraph [0064]: “LLMs like BERT, GPT, or XLNet may be employed”).
With respect to claim 11, Ebrahim teaches wherein (D) comprises: measuring distances between the plurality of generated semantic embeddings and the plurality of baseline semantic embeddings; and generating the comparison output based on the distances (Ebrahim discloses the limitations of claim 1, as set forth above, and additionally discloses the limitation of claim 11. Specifically, Ebrahim discloses measuring distances between the generated semantic embeddings and the baseline semantic embeddings in the form of cosine similarity, which represents the angular relationship between two vectors and is expressly within the scope of “distances” under the broadest reasonable interpretation in light of the present specification (Ebrahim section 3.3, Page 5: “Cosine similarity is a common measurement of similarity used in NLP. It represents the angle between two vectors, and the angle (θ) is equal to the dot product of the two vectors (A and B) over the product of their norms”). Ebrahim further discloses generating the comparison output based on the distances (Ebrahim section 3.4, Page 5: “the similarity scores are fed to the selected algorithms to create prediction probabilities that are compared to a dynamic threshold determining whether the files are plagiarised or not”)). With respect to claim 12, Ebrahim teaches wherein the comparison output includes the distances (Ebrahim discloses the limitations of claim 11, as set forth above, and additionally discloses that the comparison output includes the distances. Specifically, Ebrahim discloses that the cosine similarity scores computed between the embeddings are explicitly used as the features of the model and are thus included in the comparison output (Ebrahim section 3.3, Page 5: “The three features of the model would be the cosine similarity scores between the three generated embeddings per source code … The classifier would figure out which combination of these three features would be better in terms of evaluation”)).
With respect to claim 13, Ebrahim teaches wherein generating the comparison output based on the distances comprises: computing a metric based on the distances; and including the metric in the comparison output (Ebrahim discloses the limitations of claim 11, as set forth above, and additionally discloses computing a metric based on the distances and including the metric in the comparison output. Specifically, Ebrahim discloses computing a prediction probability from the cosine similarity scores via a trained AutoML classifier, and including that prediction probability in the comparison output (Ebrahim section 3.4, Page 5: “For testing, the similarity scores are fed to the selected algorithms to create prediction probabilities that are compared to a dynamic threshold determining whether the files are plagiarised or not”). The prediction probability is the metric computed based on the cosine similarity distances, and is included in the comparison output that resolves the plagiarism determination). With respect to claim 14, the claim is directed to a system that corresponds to the method recited in claim 1, respectively (see the rejection of claim 1 above; wherein Ebrahim also teaches such system. Ebrahim’s pipeline is implemented via executable software libraries (Sentence Transformers, AutoSklearn) and is executed on computing hardware (Ebrahim section 3.2, Page 3; section 3.4, Page 5; Figure 1, Page 6). A computer-implemented method utilizing executable software libraries necessarily entails the storage of computer program instructions on a non-transitory computer-readable medium and the execution of those instructions by at least one computer processor. Under MPEP § 2112, the system-form embodiment recited in claim 14 is inherent in Ebrahim’s computer-implemented disclosure).
With respect to claim 15, the claim is directed to a system that corresponds to the method recited in claim 2, respectively (see the rejection of claim 2 above).
With respect to claim 16, the claim is directed to a system that corresponds to the method recited in claim 4, respectively (see the rejection of claim 4 above).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2-3, 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Fahad Ebrahim et al. (“Source Code Plagiarism Detection with Pre-Trained Model Embeddings and Automated Machine Learning”, hereinafter Ebrahim) in view of Wong et al. (US Pub. No. 2012/0042361, hereinafter Wong).
With respect to claim 2, Ebrahim is silent to disclose, however in an analogous art, Wong teaches wherein chunking the subject source code into the plurality of source code chunks comprises chunking the subject source code into the plurality of source code chunks based on a predetermined grain size (Ebrahim discloses chunking source code at the file level (Ebrahim section 3.1, Page 3) and acknowledges finer-granularity chunking as a desirable refinement of the pipeline to overcome the input-size limitations of the pre-trained models (Ebrahim section 5, Page 7: “Also, chunking can be used to overcome the limited input size of the pre-trained models”). Ebrahim does not expressly disclose chunking of subject source code into chunks of a predetermined grain size. Wong expressly discloses dividing source-code-containing text into a plurality of segments, where each segment is of a predetermined size measured in lines of text (Wong paragraph [0030]: “At 104, the message in the memory is divided into one or more segments, wherein each segment includes a predetermined number of lines of text from the message”; Paragraph [0035]: “the message may be divided into one or more segments, each segment including a predetermined number of lines”; Paragraph [0038]: “Each segment 210 includes a predetermined number of lines of text from the message 200. The predetermined number of lines may be represented by a configurable parameter ‘segment_size’. In this example, the segment_size is set to be 4”; Paragraph [0039]: “The plurality of text segments 210 is determined by using a sliding window 220 to slide the message 200 into the plurality of text segments 210. In this example, as the segment_size is set to be 4, the size of the sliding window 220 may be 4 lines of text, such that each text segment 210 includes 4 lines of text from the message 200”). Under the broadest reasonable interpretation in light of the present specification (paragraph [0051]: “This granularity may, for example, be defined in terms of the number of lines of code to be analyzed in each chunk of source code, also referred to herein as ‘grain size’”), Wong’s “predetermined number of lines of text” (configurable as the parameter “segment_size”) reads on the claimed “predetermined grain size.”). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Ebrahim with Wong because: (i) Ebrahim itself expressly identifies finer-granularity chunking as a desirable refinement of its source-code-embedding pipeline to overcome the input-size limitations of the pre-trained models (Ebrahim section 5, Page 7); (ii) Wong is in the same field of computer-implemented analysis of source code and provides an express, well-defined technique for segmenting source-code-containing input into chunks of a predetermined number of lines of text using a configurable size parameter and a sliding window (Wong paragraphs [0030], [0038]–[0039]); and (iii) applying Wong’s predetermined-line-count chunking to the source-code input of Ebrahim yields the predictable result of obtaining uniformly sized source-code chunks suitable for embedding by the CodePTMs of Ebrahim. With respect to claim 3, Ebrahim is silent to disclose, however in an analogous art, Wong teaches wherein each of the plurality of source code chunks has a size that is equal to the predetermined grain size (Wong paragraph [0038] discloses: “Each segment 210 includes a predetermined number of lines of text from the message 200. The predetermined number of lines may be represented by a configurable parameter ‘segment_size’. In this example, the segment_size is set to be 4.” Wong paragraph [0039] further discloses: “as the segment_size is set to be 4, the size of the sliding window 220 may be 4 lines of text, such that each text segment 210 includes 4 lines of text.” Each of Wong’s segments thus has a size equal to the predetermined grain size (segment_size)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Ebrahim with Wong because: (i) Ebrahim itself expressly identifies finer-granularity chunking as a desirable refinement of its source-code-embedding pipeline to overcome the input-size limitations of the pre-trained models (Ebrahim section 5, Page 7); (ii) Wong is in the same field of computer-implemented analysis of source code and provides an express, well-defined technique for segmenting source-code-containing input into chunks of a predetermined number of lines of text using a configurable size parameter and a sliding window (Wong paragraphs [0030], [0038]–[0039]); and (iii) applying Wong’s predetermined-line-count chunking to the source-code input of Ebrahim yields the predictable result of obtaining uniformly sized source-code chunks suitable for embedding by the CodePTMs of Ebrahim.
With respect to claim 7, Ebrahim is silent to disclose, however in an analogous art, Wong teaches wherein (B) comprises not generating semantic embeddings for binary code in the plurality of source code chunks (The present specification describes the limitation of claim 7 at paragraph [0065]: “The embedding module 308 may skip over (i.e., not embed) binary chunks in the source code chunks 306. For example, for each of the source code chunks 306, the embedding module 308 may determine whether that chunk contains binary code. If the chunk is determined to contain binary code, then the embedding module 308 may not embed that chunk. If the chunk is not determined to contain binary code, then the embedding module 308 may embed that chunk. The embedding module 308 may discern text from binary data using any of a variety of techniques, such as either or both of: (1) a byte-order mark (BOM) check; and (2) by attempting to convert the bytes in the chunk into text … and determining whether the conversion completes successfully.” Under the broadest reasonable interpretation, claim 7 requires a per-chunk determination of whether the chunk contains binary code, and selective non-generation of an embedding for chunks so determined; the detection technique itself is open-ended (“such as”). Thus, the limitation concept is a per-chunk text-versus-binary discrimination step that selectively passes only non-binary, source-code-containing chunks to the downstream embedding step and excludes binary chunks from the embedding step. Ebrahim discloses the embedding step (B) applied to source-code chunks (Ebrahim section 3.2, Page 3; section 3.2.1, Page 4), but does not address per-chunk text-versus-binary discrimination because Ebrahim’s experimental input is pre-curated to contain only C++ and Java source files (Ebrahim section 3.1, Page 3). Wong expressly contemplates input that may contain a mixture of plain-text content and binary content, and teaches a per-segment selective filter that distinguishes source-code content from non-source-code content. Wong paragraph [0034] expressly states: “the message may be in the form of plain text or binary documents, such as a MICROSOFT.RTM. VISUAL STUDIO.RTM. integrated development environment project file or MICROSOFT.RTM. WORD.RTM. word processor document, which may contain source code. The message may be an encoded or encrypted message. Accordingly, the message may be decoded first before performing the determination of whether the message includes source code.” Wong applies, for each segment, a per-segment determination in which syntax rules of a programming language are applied to determine whether that segment contains source code (Wong paragraph [0031]: “At 106, for each segment, one or more syntax rules of a programming language is applied to the segment … to determine which of the syntax rules of the programming language are matched in the segment”). Wong further expressly applies a probability-threshold determination per segment, in which segments with a computed ratio P below a threshold T are not determined to contain source code (Wong paragraph [0075]: “the ratio value P may be compared with a predetermined threshold value T to determine the existence of source code. If the ratio value exceeds the threshold value, it may be determined that the source code for a particular programming language is present in the message”). When the ratio of a given segment is below the threshold, that segment is not identified as source code and is excluded from being treated as source code in downstream processing. Wong’s per-segment filter operates as a text-versus-non-source-code discriminator. Content that does not conform to programming-language syntax rules — which includes binary content, since binary content does not conform to programming-language syntax — is excluded from being treated as source code. When Wong’s per-segment filter is applied within the embedding pipeline of Ebrahim, embeddings are generated only for chunks identified as source code, and embeddings are not generated for chunks (including binary chunks) that fail the per-segment source-code determination. This satisfies the limitation that “(B) comprises not generating semantic embeddings for binary code in the plurality of source code chunks.”.
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Ebrahim with Wong because: (i) Wong is in the same field of computer-implemented analysis of source code, and expressly addresses the practical reality that input subject to source-code analysis may contain a mixture of plain-text and binary content (Wong paragraph [0034]); (ii) Wong’s per-segment selective filter that excludes non-source-code content from being treated as source code (Wong paragraphs [0031], [0075]) provides a known and predictable mechanism for ensuring that downstream source-code analysis is performed only on segments that contain source code; and (iii) applying Wong’s per-segment filter within the embedding pipeline of Ebrahim yields the predictable result of avoiding embedding generation for binary content that the pre-trained CodePTMs of Ebrahim are not designed to process and that would otherwise consume computational resources without producing meaningful semantic embeddings, as expressly recognized by the present specification (paragraph [0066]: “By skipping these binary chunks, the system 300 can save substantial computational resources”).
With respect to claim 18, the claim is directed to a system that corresponds to the method recited in claim 7, respectively (see the rejection of claim 7 above).
Claims 5-6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Fahad Ebrahim et al. (“Source Code Plagiarism Detection with Pre-Trained Model Embeddings and Automated Machine Learning”, hereinafter Ebrahim) in view of Zhangyin Feng et al. (“A Pre-Trained Model for Programming and Natural Languages”, hereinafter Feng).
With respect to claim 5, Ebrahim is silent to disclose, however in an analogous art, Feng teaches wherein each of the plurality of generated semantic embeddings has at least 100 dimensions (The limitation requires the numerical dimensionality of the vector embeddings produced by the embedding model. Ebrahim expressly identifies the CodePTMs used to generate the embeddings, including CodeBERT, but does not numerically recite the output dimensionality of those CodePTMs (Ebrahim section 3.2.1, Page 4). Feng expressly discloses that CodeBERT shares the architecture of RoBERTa-base and produces 768-dimensional hidden-state embeddings (Feng section 3.1: “we develop CodeBERT using exactly the same model architecture as RoBERTa-base”; Feng section B.3: “768 dimensional hidden states”). Because Ebrahim expressly cites Feng as the originating reference for CodeBERT (Ebrahim section 3.2.1, Page 4: “CodeBert (Feng et al., 2020)”), Feng’s express disclosure of the 768-dimensional output of CodeBERT supplies the numerical dimensionality of the embeddings produced by the CodePTMs used in Ebrahim. A vector embedding of 768 dimensions satisfies the claim limitation of “at least 100 dimensions.”. It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Ebrahim with Feng because: (i) Ebrahim expressly cites Feng as the originating reference for CodeBERT, one of the CodePTMs employed in Ebrahim’s embedding pipeline (Ebrahim section 3.2.1, Page 4); (ii) a skilled artisan implementing Ebrahim’s embedding pipeline would naturally consult the originating Feng reference for architectural details, including the hidden-state dimensionality of CodeBERT (Feng section 3.1; Feng section B.3); and (iii) the combination yields the predictable result of an embedding pipeline producing 768-dimensional vector embeddings, which is well within the range of “at least 100 dimensions.”.
With respect to claim 6, Ebrahim is silent to disclose, however in an analogous art, Feng teaches wherein each of the plurality of generated semantic embeddings has 768 dimensions (Ebrahim in view of Feng teaches the limitations of claim 5, as set forth above. The additional limitation of claim 6 — that each generated semantic embedding has 768 dimensions — is expressly taught by Feng. Feng section 3.1 discloses: “we develop CodeBERT using exactly the same model architecture as RoBERTa-base.” Feng section B.3 expressly recites: “768 dimensional hidden states.” The 768-dimensional output is therefore the express output dimensionality of CodeBERT, which Ebrahim expressly employs in its embedding pipeline (Ebrahim section 3.2.1, Page 4: “CodeBert (Feng et al., 2020)”).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Ebrahim with Feng because: (i) Ebrahim expressly cites Feng as the originating reference for CodeBERT, one of the CodePTMs employed in Ebrahim’s embedding pipeline (Ebrahim section 3.2.1, Page 4); (ii) a skilled artisan implementing Ebrahim’s embedding pipeline would naturally consult the originating Feng reference for architectural details, including the hidden-state dimensionality of CodeBERT (Feng section 3.1; Feng section B.3); and (iii) the combination yields the predictable result of an embedding pipeline producing 768-dimensional vector embeddings, which is well within the range of “at least 100 dimensions.”.
With respect to claim 17, the claim is directed to a system that corresponds to the method recited in claim 5, respectively (see the rejection of claim 5 above).
Claims 8-10 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Fahad Ebrahim et al. (“Source Code Plagiarism Detection with Pre-Trained Model Embeddings and Automated Machine Learning”, hereinafter Ebrahim) in view of Wildsmith et al. (US Pub. No. 2025/0112936, hereinafter Wildsmith).
With respect to claim 8, Ebrahim is silent to disclose, however in an analogous art, Wildsmith teaches wherein (B) further comprises compressing the plurality of generated semantic embeddings (The present specification describes the limitation of claim 8 at paragraph [0074]: “The system 300 may include a compression module 314, which may receive some or all of the plurality of semantic embeddings 310 as inputs … and compress those semantic embeddings.” The specification expressly includes dimensionality reduction within the scope of “compressing” at paragraph [0076]: “such techniques include … vector quantization, dimensionality reduction, lossy compression, sparse representation, and entropy encoding.” Under the broadest reasonable interpretation, dimensionality reduction of semantic embeddings reads on “compressing the plurality of generated semantic embeddings.”. Thus, the claim requires reduction of the dimensionality of semantic vector embeddings of source code to produce compressed vector embeddings used in similarity comparison. Ebrahim teaches generating semantic embeddings via CodePTMs (Ebrahim section 3.2, Page 3; section 3.2.1, Page 4) and using cosine similarity over those embeddings (Ebrahim section 3.3, Page 5), but does not teach a compression step applied to the generated embeddings. Wildsmith expressly discloses applying dimensionality reduction to vector embeddings of code segments via a trained IsoMap dimensionality reduction model (Wildsmith paragraph [0022]: “training an IsoMap dimensionality reduction model”; paragraph [0100]: “The Feature Matrices are applied against the trained scaler and IsoMap embedding model to produce one or more Vectors”; Paragraph [0167]: “This single flattened vector then undergoes a scaling and dimensionality reduction process where the trained Scaler and IsoMap dimensionality reduction models are applied to produce the final vector”). Wildsmith’s dimensionality reduction step takes the higher-dimensional flattened vector and produces a lower-dimensional final vector used for similarity comparison via distance computation against a knowledge base of stored vectors (Wildsmith paragraph [0024]: “performing code similarity detection by searching the knowledge database for known vector objects by matching the one or more test vector objects within a threshold”). Under the broadest reasonable interpretation in light of the present specification, Wildsmith’s IsoMap dimensionality reduction of semantic vector embeddings reads on “compressing the plurality of generated semantic embeddings.”).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Ebrahim with Wildsmith because: (i) Wildsmith is in the same field of vector-embedding-based code similarity searching and operates in the same conceptual framework (vector embeddings of code segments compared in a vector space via distance measures) as Ebrahim (Wildsmith paragraph [0024]); (ii) Wildsmith expressly teaches dimensionality reduction of the vector embeddings via IsoMap as a means to enable practical, scalable similarity searching over a knowledge base of stored vector embeddings (Wildsmith paragraphs [0100], [0167]); and (iii) applying Wildsmith’s dimensionality reduction step to the CodePTM-generated embeddings of Ebrahim yields the predictable result of producing compressed semantic embeddings of reduced storage footprint and accelerated comparison time, as expressly recognized by the present specification (paragraph [0075]: “Compressing these embeddings to a smaller size drastically reduces the amount of storage needed … Compressed embeddings can be compared, indexed, and retrieved more quickly”).
With respect to claim 9, Ebrahim is silent to disclose, however in an analogous art, Wildsmith teaches further comprising: extracting metadata from the plurality of source code chunks, and wherein (D) comprises using the metadata to assist in comparing the plurality of generated semantic embeddings with the plurality of baseline semantic embeddings (The present specification describes “metadata” extracted from source code chunks at paragraph [0077]: “Examples of the metadata 312 include, for each chunk, the filename of the file from which the chunk was extracted, the line number in the source file where the chunk begins, and the size of the chunk (e.g., in bytes or lines).” The specification further describes the use of such metadata to assist comparison at paragraph [0089]: “the comparison module 322 may retrieve and leverage the metadata 312 to improve the accuracy and relevance of the comparison process. The retrieved metadata, which may include information such as the origin file, line numbers, and/or chunk size of the source code / source code chunks corresponding to the retrieved embeddings 320, may perform one or more of the following functions in the comparisons …: Alignment of Code Segments … Focused Comparisons … Granularity Control … Efficiency Enhancements.” Under the broadest reasonable interpretation, the limitation is satisfied where metadata identifying the location and identity of each chunk relative to its source is extracted from the chunks and used to track and align the comparison. Thus, the claim requires extraction, for each chunk, of identifying metadata describing the location of the chunk relative to its source, and use of that metadata during the comparison step to track the correspondence between embeddings and their underlying chunks. Ebrahim teaches the comparison step (D) via cosine similarity over generated embeddings (Ebrahim section 3.3, Page 5) but does not expressly disclose extracting per-chunk metadata or using such metadata to assist in the comparison. Wildsmith expressly discloses extracting metadata from each code-segment chunk, in the form of a location descriptor that identifies the location of the code segment within its originating source, and a Benchmark ID that uniquely associates that code segment with its corresponding vector embedding (Wildsmith paragraph [0088]: “The indexer uploads one or more location descriptors to the ScanDB which can be used to locate the selected code segments”; Paragraph [0091]: “The compute service uses the location descriptor to collect the respective PE Binary for the NFS File System”; Paragraph [0092]: “The compute service uses the location descriptor to identify the Code Segment in the PE Binary”; Paragraph [0102]: “The vector is uploaded in the Milvus Database, with the associated infection label and Benchmark ID. The Benchmark ID also serves as the Vector’s Vector ID in the database”). Wildsmith further expressly uses this per-chunk metadata during the comparison step to associate colliding (matching) vectors with their originating benchmarks for reporting and analysis (Wildsmith paragraph [0136]: “The API Gateway returns colliding Vectors, associated Benchmarks & infection label”; Paragraph [0138]: “the meta-data associated to the colliding benchmarks is also queried and rendered to the user as a textual report”). The Benchmark ID and location descriptor are metadata extracted from the source code chunks and used to assist the comparison by tracking, aligning, and identifying the correspondence between each embedding and its originating chunk during the similarity-search and reporting steps).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Ebrahim with Wildsmith because: (i) Wildsmith is in the same field of vector-embedding-based code similarity searching as Ebrahim; (ii) Wildsmith’s per-chunk metadata (Benchmark ID and location descriptor) expressly enables traceability between vectors and their originating code segments and supports comparison reporting (Wildsmith paragraphs [0102], [0136], [0138]); and (iii) incorporating Wildsmith’s per-chunk metadata extraction and use into the embedding-and-comparison pipeline of Ebrahim yields the predictable benefit of allowing the system to identify, for each comparison result, the originating source code chunk, thereby improving the utility of the comparison output, as recognized in the present specification (Paragraph [0089]).
With respect to claim 10, Ebrahim is silent to disclose, however in an analogous art, Wildsmith teaches further comprising: extracting metadata from the plurality of generated semantic embeddings, and wherein (D) comprises using the metadata to assist in comparing the plurality of generated semantic embeddings with the plurality of baseline semantic embeddings (The present specification contemplates that metadata may be extracted from the generated semantic embeddings themselves (paragraph [0077]: “the embedding module 308 may extract the metadata 312 from the source code chunks 306 and/or the plurality of semantic embeddings 310”) and used to assist in the comparison (paragraph [0089]). Under the broadest reasonable interpretation, claim 10 is satisfied where metadata derived from the generated semantic embeddings themselves (such as statistical or cluster-based properties of the embeddings) is computed and used in the comparison step. Thus, the claim requires derivation of metadata from the generated semantic embeddings (such as cluster centroids and cluster statistical properties obtained by analyzing the embedding vectors), and use of that metadata to assist in the comparison between generated embeddings and baseline embeddings. Ebrahim teaches the comparison step (D) via cosine similarity over generated embeddings (Ebrahim section 3.3, Page 5) but does not expressly disclose deriving metadata from the generated embeddings themselves and using such metadata in the comparison. Wildsmith expressly discloses extracting metadata from the generated semantic vector embeddings via cluster analysis, where the extracted metadata includes the cluster’s centroid (a vector position computed from the embeddings within that cluster) and the cluster’s maliciousness density (a statistical property computed from the labels of the embeddings within that cluster) (Wildsmith paragraph [0181]: “In order to leverage the discovered relationships to estimate a maliciousness score, the cluster metadata includes (but is not limited to):”; Paragraph [0182]: “The cluster’s maliciousness density, defined as the number of vectors originating from a malicious sample divided by the total number of vectors belonging to the cluster”; Paragraph [0183]: “The cluster’s centroid”). The cluster centroids are produced by the Centroid Tracker service of Wildsmith, which performs cluster analysis of the vector embeddings stored in the vector database (Wildsmith Table 1: “Centroid Tracker … performs passive and periodic clustering of the vectors in the Milvus Vector Database to identify classifications of known code-segments in the knowledge base and update related classification meta-data (cluster centroids & weight))”.
Wildsmith further expressly uses this embedding-derived metadata in the comparison computation. For each generated vector Vi, the distance Di from the cluster’s centroid Ci is computed and combined with the cluster’s maliciousness density Mi to produce the final comparison output (Wildsmith paragraph [0184]: “For each vector (Vi), the distance (Di) from the corresponding cluster’s centroid (Ci) is calculated. It is possible to use any measure of distance (x) for this step, such as L1, L2, or cosine distance”; Paragraph [0185]: “A sample’s final maliciousness score (Pm) is then estimated as the average of each collided cluster’s maliciousness density (Mi), weighted by each vector’s distance from the corresponding cluster’s centroid (Di)”). The cluster centroid and cluster maliciousness density are metadata extracted from the generated semantic embeddings via cluster analysis, and are used to assist (and indeed directly participate in computing) the comparison output between generated embeddings and baseline embeddings). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to combine Ebrahim with Wildsmith because: (i) Wildsmith is in the same field of vector-embedding-based code similarity searching as Ebrahim; (ii) Wildsmith expressly teaches a known and practical mechanism for extracting metadata from the generated vector embeddings (via cluster analysis producing cluster centroids and cluster statistical properties) and using that metadata to compute a similarity-based comparison output (Wildsmith paragraphs [0181]–[0185]); and (iii) incorporating Wildsmith’s embedding-derived cluster metadata into the comparison step of Ebrahim yields the predictable result of an improved comparison output informed by the structural organization of the embedding space, consistent with the general purpose of the present specification of leveraging metadata to improve comparison accuracy and relevance (paragraphs [0089]–[0090]).
With respect to claim 19, the claim is directed to a system that corresponds to the method recited in claim 9, respectively (see the rejection of claim 9 above).
With respect to claim 20, the claim is directed to a system that corresponds to the method recited in claim 10, respectively (see the rejection of claim 10 above).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. McCormick (US Pub. No. 2019/0317879) discloses a neural network for identifying defects in source code of computer software. The neural network comprises: at least one convolutional layer configured to generate a one or more feature abstractions associated with an input segment associated with the source code; at least one recurrent layer configured to identify within the one or more feature abstractions a pattern indicative of a defect in the source code; and at least one mapping layer configured to generate a mapping between the identified pattern and a location of the indicated defect in the source code. (see abstract).
Rudenko et al. (US Pub. No. 2025/0004915) discloses a method that involve forming a set of prompts for a generative model to generate a set of patches to fix a detected flaw in a program code body. The code fragment corresponding to the detected flaw, contextual code for the code fragment, a flawed reference code, and a fixed reference code are arranged with delineating markers to form the prompt. The generative model is fine-tuned to constrain a generated response to a modification of the code fragment. The generative model is run on the set of prompts, where the first generated patch is applied from the generative model to the program code body. The fixed reference code is provided as a patched version of the flawed reference code. (see abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6: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 at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights