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 .
Claims 1-20 are presented for examination.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “cause the processing device to perform the steps of …” in claim 1, “wherein, upon a second condition where the language of the code segment is not known, the processing device, causes the processing device to perform the steps of” in claim 2.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 2, 9 and 16 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2, 9 and 16 recites the limitation "the convolutional neural network" in “wherein the convolutional neural network is a hierarchical stacked convolutional network configured to repetitively reduce the code segment and extract features at each repetition”. There is insufficient antecedent basis for this limitation in the claim. Earlier in the claim it is introduced as “a convolution neural network” (note the missing “al” in “convolutional”), which could be interpreted as a different term due to inconsistency in wording.
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.
Claim(s) 1, 6, 8, 13, 15 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami (US 2023/0106226 A1) in view of Clement (US 2023/0162040 A1), further in view of Siu (US 20250285171 A1), Chen (US 20240346634) and Hufnagl (US 20240062621 A1).
Regarding Claim 1, Bahrami (US 2023/0106226 A1) teaches
A system for identification, tokenization, and dependency mapping of source code in a network environment, the system comprising: a processing device; a non-transitory storage device containing instructions when executed by the processing device, causes the processing device to perform the steps of:
retrieving a code segment from a code repository; (Para [0028], "The one or more data sources 104 may include a web-based code hosting server, a database server, a file server, a web server, a Really Simple Syndication (RSS) feed, a server that hosts website(s) and web application(s) related to repositories (which store software code).") Examiner Comments: Bahrami teaches retrieving source code from repositories as a basis for analysis, directly mapping to the claimed retrieval step in a network environment.
determining a language of the code segment (Para [0039], "AST data may correspond to a tree representation of the abstract syntactic structure of the blocks of code in a particular programming language, such as Python, Java®, or JavaScript."; Para [0066], In an embodiment, the abstraction of the nodes of the AST data may be performed by iteratively selecting a node of the AST data and determining a type of the selected node. Based on the type of the node and an abstract grammar for the programming language (e.g., Python) used in the source code data 302, the level of abstraction may be selected) Examiner Comments: Bahrami determines the programming language for AST parsing (e.g., Python, Java), and handles known languages for transformation to abstracted form, aligning with the claimed determination and transformation to a common base.
generating [a feature vector] by extracting features of the code segment using an abstract syntax tree based neural network, wherein the feature vector is a reduced dimension; (Para [0039], "The extraction of the set of features may be performed by parsing the blocks of code using Abstract Syntax Tree (AST) data of the blocks of code. AST data may correspond to a tree representation of the abstract syntactic structure of the blocks of code in a particular programming language, such as Python, Java®, or JavaScript. Each node of the tree may denote a construct that may occur in the block of code.") Examiner Comments: Bahrami uses AST for feature extraction from code, resulting in abstracted/reduced representations for training, matching the claimed feature vector generation with dimension reduction.
storing the [feature vector] in a feature vector database comprising stored feature vectors; (Para [0073], "The database may include package metadata associated with source codes of a plurality of code packages. Such packages may be identified by parsing the AST data associated with the blocks of code.") Examiner Comments: Bahrami stores extracted features and metadata in a database, directly teaching storage of feature vectors.
Bahrami did not specifically teach
wherein upon a first condition where the language of the code segment is known, the code segment is transformed via a transformer neural network to a common code base;
a feature vector
retrieving, from the feature vector database based on metadata of the feature vector, a plurality of similar stored feature vectors;
establishing, using a Euclidean distance, a level of similarity between the feature vector and the plurality of similar stored feature vectors;
tokenizing, upon a third condition of the level of similarity is below a predetermined threshold, the feature vector as a non-fungible token
inserting the non-fungible token into a directed acyclic graph as a node, wherein the directed acyclic graph comprises edges between a plurality of related nodes as a representation of dependencies between a plurality of related non-fungible tokens.
However, Clement (US 2023/0162040 A1) teaches
wherein upon a first condition where the language of the code segment is known, the code segment is transformed via a transformer neural network to a common code base; (Para [0109], "The custom model learns to generate source code of a target domain given source code of a first domain; Para [0017], “In the context of code generation, the encoder-decoder neural transformer model is trained to translate a source code snippet of a first domain into a source code snippet of a second domain”) Examiner Comments: Clement transforms code from one domain/language representation to another using neural transformer, mapping to transforming known code to a common base.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Li’s teaching into Clement’s in order to to standardize code across languages for consistent feature extraction, as Clement enables domain transformation with neural transformers for efficient code processing through a neural transformer model with attention is trained on a large corpus of unlabeled source code and associated natural language text to learn to predict candidate method bodies given a method docstring, method signature, and one or more method usage examples; The transformer model improves code generation and translation across domains, allowing Bahrami's code retrieval and AST parsing to benefit from standardized representations for better feature extraction accuracy and efficiency (Clement [Summary]).
Bahrami and Clement did not specifically teach
a feature vector
retrieving, from the feature vector database based on metadata of the feature vector, a plurality of similar stored feature vectors;
establishing, using a Euclidean distance, a level of similarity between the feature vector and the plurality of similar stored feature vectors;
tokenizing, upon a third condition of the level of similarity is below a predetermined threshold, the feature vector as a non-fungible token
inserting the non-fungible token into a directed acyclic graph as a node, wherein the directed acyclic graph comprises edges between a plurality of related nodes as a representation of dependencies between a plurality of related non-fungible tokens.
However, Siu (US 20250285171 A1) teaches
a feature vector (Para 0031, “extracting feature vectors from within the detected boundary via a feature extraction algorithm”)
retrieving, from the feature vector database based on metadata of the feature vector, a plurality of similar stored feature vectors (Para [0046], “The item identification algorithm 138 may reference the catalog 140 to perform feature vector matching between the feature vectors generated by the feature extraction algorithm 136 and feature vectors of items in the catalog. A “match” in this context thus refers to the feature vectors of the detected object, as output by the feature extraction algorithm 136, being the same as feature vectors for an item in the catalog, such as via a similarity measurement technique.”);
establishing, using a Euclidean distance, a level of similarity between the feature vector and the plurality of similar stored feature vectors; (Para [0066], " The item identification algorithm 138 matches the feature vectors 216 to an item in the catalog 140. By way of example, the item identification algorithm 138 may compare the feature vectors 216 with feature vectors for items in the catalog 140 using a similarity measurement. The similarity measurement may use a Euclidean distance, a cosine similarity measurement, and/or a correlation coefficient, for example. For instance, a smaller Euclidean distance may indicate a higher similarity value, and thus a closer match between the feature vectors 216 of the detected object 214 and the item in the catalog 140. Additionally or alternatively, a similarity threshold may be used.")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami and Clement’s teaching into Siu’s in order to enable precise feature matching and similarity assessment for code segments, as Siu describes using feature vectors and Euclidean distance for accurate identification and matching in catalogs (Siu, para [0066]: "The item identification algorithm 138 may compare the feature vectors 216 with feature vectors for items in the catalog 140 using a similarity measurement. The similarity measurement may use a Euclidean distance... a smaller Euclidean distance may indicate a higher similarity value...", This passage from Siu provides the motivation by illustrating how Euclidean distance enhances similarity detection in feature-based systems, allowing Bahrami and Clement's code transformation and extraction to incorporate robust comparison mechanisms for identifying unique or similar code elements, improving overall system efficiency in network environments).
Bahrami, Clement and Siu did not specifically teach
tokenizing, upon a third condition of the level of similarity is below a predetermined threshold, the feature vector as a non-fungible token;
inserting the non-fungible token into a directed acyclic graph as a node, wherein the directed acyclic graph comprises edges between a plurality of related nodes as a representation of dependencies between a plurality of related non-fungible tokens.
However, Chen (US 20240346634) teaches
tokenizing, upon a third condition of the level of similarity is below a predetermined threshold, the feature vector as a non-fungible token; (Para [0055], " The verification result 118 can be considered normal if there exists no image with similarity exceeding a threshold value among the re-ranked candidate images. If the verification result 118 of verifying the virtual avatar 110 is normal, a non-fungible token for the virtual avatar is generated for use as a virtual asset of the user.")
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement and Siu’s teaching into Chen’s in order to ensure tokenization only for unique items, preventing duplication in asset management (Chen, para [0055]: "The verification result 118 can be considered normal if there exists no image with similarity exceeding a threshold value... If the verification result 118 of verifying the virtual avatar 110 is normal, a non-fungible token for the virtual avatar is generated...", This passage from Chen motivates the combination by showing. how similarity thresholds verify uniqueness before NFT generation, allowing Bahrami, Clement, and Siu's feature extraction and similarity assessment to condition tokenization on low similarity, enhancing intellectual property protection in code dependency systems).
Bahrami, Clement, Siu and Chen did not specifically teach
inserting the non-fungible token into a directed acyclic graph as a node, wherein the directed acyclic graph comprises edges between a plurality of related nodes as a representation of dependencies between a plurality of related non-fungible tokens.
However, Hufnagl (US 20240062621 A1) teaches
inserting the non-fungible token into a directed acyclic graph as a node, wherein the directed acyclic graph comprises edges between a plurality of related nodes as a representation of dependencies between a plurality of related non-fungible tokens. (Para [0062], “one or more non-fungible tokens are implemented in accordance with a directed acyclic graph protocol … the directed acyclic graph protocol enables the storing of the non-fungible token or a reference to the non-fungible token but without the utilization of blocks. Specifically, the directed acyclic graph of this embodiment employs a finite directed graph that includes an infinite amount of edges and vertices, wherein each edge is directed from one vertex to another without having to start at any one particular vertex or follow a consistent or directed sequence of edges to loop back to the same vertex again”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement, Siu and Chen’s teaching into Hufnagl’s in order to represent dependencies among tokenized assets efficiently without traditional blockchains (Hufnagl, para [0062]: "one or more non-fungible tokens are implemented in accordance with a directed acyclic graph protocol... the directed acyclic graph protocol enables the storing of the non-fungible token or a reference to the non-fungible token but without the utilization of blocks. Specifically, the directed acyclic graph of this embodiment employs a finite directed graph that includes an infinite amount of edges and vertices, wherein each edge is directed from one vertex to another...", This passage from Hufnagl motivates the combination by highlighting DAG's advantages in storing NFTs with dependencies via edges and vertices, allowing Bahrami, Clement, Siu, and Chen's code tokenization to use DAG for mapping interdependencies, improving scalability and efficiency in network-based code environments).
Regarding Claim 6, Bahrami, Clement, Siu, Chen and Hufnagl teach
The system of Claim 1.
Bahrami, Clement, and Siu did not specifically teach
wherein upon a fourth condition of the level of similarity being above a predetermined threshold, the code segment is not tokenized.
However, Chen teaches
wherein upon a fourth condition of the level of similarity being above a predetermined threshold, the code segment is not tokenized. (Para [0055], " The verification result 118 can be considered abnormal if there exists an image with similarity exceeding a threshold value among the re-ranked candidate images. The verification result 118 can be considered normal if there exists no image with similarity exceeding a threshold value among the re-ranked candidate images. If the verification result 118 of verifying the virtual avatar 110 is normal, a non-fungible token for the virtual avatar is generated for use as a virtual asset of the user. ") Examiner Comments: Items that are abnormal and exceed a threshold are not tokenized.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement and Siu’s teaching into Chen’s in order to ensure tokenization only for unique items, preventing duplication in asset management (Chen, para [0055]: "The verification result 118 can be considered normal if there exists no image with similarity exceeding a threshold value... If the verification result 118 of verifying the virtual avatar 110 is normal, a non-fungible token for the virtual avatar is generated...", This passage from Chen motivates the combination by showing. how similarity thresholds verify uniqueness before NFT generation, allowing Bahrami, Clement, and Siu's feature extraction and similarity assessment to condition tokenization on low similarity, enhancing intellectual property protection in code dependency systems).
Regarding Claim 8, is a product claim corresponding to the system claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Regarding Claim 13, is a product claim corresponding to the system claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of claim 6.
Regarding Claim 15, is a method claim corresponding to the system claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of claim 1.
Regarding Claim 19, is a method claim corresponding to the system claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of claim 6.
Claim(s) 2, 9 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami (US 2023/0106226 A1) in view of Clement (US 2023/0162040 A1), Siu (US 20250285171 A1), Chen (US 20240346634) and Hufnagl (US 20240062621 A1) further in view of Gong (US 2023/0067033 A1).
Regarding Claim 2, Bahrami, Clement, Siu, Chen and Hufnagl teach
The system of Claim 1.
Bahrami, Clement, Siu, Chen and Hufnagl did not specifically teach
wherein, upon a second condition where the language of the code segment is not known, the processing device, causes the processing device to perform the steps of: pre-processing the code segment, wherein pre-processing includes processing the code segment to a predetermined input length; identifying, using a convolution neural network, the language of the code segment, wherein the convolutional neural network is a hierarchical stacked convolutional network configured to repetitively reduce the code segment and extract features at each repetition; and transforming the code segment via the transformer neural network to the common code base.
However, Gong (US 2023/0067033 A1) teaches
wherein, upon a second condition where the language of the code segment is not known, the processing device, causes the processing device to perform the steps of: pre-processing the code segment, wherein pre-processing includes processing the code segment to a predetermined input length; (Para [0043], "The model depicted in FIG. 2 can focus on language identification from a text line. Each text line can include a sub-image cropped from a document image using a corresponding line bounding box. Line bounding boxes can be a result of text detection/localization methods. The image area contained in the bounding box can be cropped and resized to have a fixed height. A height of each text line can be normalized to 22 pixels.") Examiner Comments: Gong teaches pre-processing text lines (analogous to code segments as structured text) by resizing to a fixed predetermined height/length for consistent CNN input, directly mapping to processing to a predetermined input length to standardize unknown inputs for language identification.
identifying, using a convolution neural network, the language of the code segment, wherein the convolutional neural network is a hierarchical stacked convolutional network configured to repetitively reduce the code segment and extract features at each repetition; (Para [0027], "In one implementation, the language identification system uses a ML model that combines a convolutional neural network (CNN) and a recurrent neural network (RNN)."; Para [0028], “In certain embodiments, given an input image comprising multiple pixels, the language identification system is capable of using the ML model to determine a language corresponding to the characters represented by the pixel values in the input image. In certain implementations, the CNN portion of the ML model used by the language identification system extracts visual features from image pixels in the input image and converts the input image to a sequence of feature vectors along with writing direction”; Para [0045], " The CNN architecture can be designed with a selection of convolutional strides and pooling layers so that height is reduced from input 22 to 1, or we can add a global pooling layer as the last layer of the CNN.."; Para [0047], " The RNN 110 can include a stack of Bi-Directional Long Short Term Memory (Bi-LSTM) layers (e.g., 206A-D). The stack of Bi-LSTM layers 206A-D can process the visual features of the text line and derive contextual features of the text line.") Examiner Comments: Gong teaches using a CNN for language identification in text (applicable to code segments as text with syntactic patterns), where the CNN is hierarchical with stacked layers that repetitively reduce dimensions via strides and pooling while extracting features at each layer, directly mapping to a hierarchical stacked convolutional network for repetitive reduction and feature extraction to classify language.
and transforming the code segment via the transformer neural network to the common code base. (As taught by Clement in the base rejection for claim 1; see mapping in claim 1 for transformer-based transformation post-identification.) Examiner Comments: Once the language is identified via Gong’s CNN, the code segment is transformed to a common base using Clement's transformer neural network, completing the process for handling unknown languages in a unified pipeline.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement, Siu, Chen and Hufnagl’s teaching into Gong’s in order to accurately identify unknown programming languages in source code using a CNN-based system, as Gong’s vision-based language identification extracts features from text structures similar to code syntax patterns, enabling standardization for subsequent transformation and reducing errors in multi-language code environments, stacked CNN layers repetitively reduce and extract features for accurate language identification in text inputs, allowing Bahrami, Clement, Siu, Chen, and Hufnagl's system to handle unknown code languages efficiently, improving overall code processing in network environments.
Regarding Claim 9, is a product claim corresponding to the system claim above (Claim 2) and, therefore, is rejected for the same reasons set forth in the rejection of claim 2.
Regarding Claim 16, is a method claim corresponding to the system claim above (Claim 2) and, therefore, is rejected for the same reasons set forth in the rejection of claim 2.
Claim(s) 3 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami (US 2023/0106226 A1) in view of Clement (US 2023/0162040 A1), Siu (US 20250285171 A1), Chen (US 20240346634) and Hufnagl (US 20240062621 A1) further in view of Boucher (US 8,578,389).
Regarding Claim 3, Bahrami, Clement, Siu, Chen and Hufnagl teach
The system of Claim 1.
Bahrami, Clement, Siu, Chen and Hufnagl did not specifically teach
wherein the directed acyclic graph represents interdependencies of a plurality of code segments.
However, Boucher (US 8,578,389) teaches
wherein the directed acyclic graph represents interdependencies of a plurality of code segments. (Claim 1, "generating a plurality of individual directed acyclic graphs, wherein each of the plurality of individual directed acyclic graphs comprise a plurality of nodes representing executable tasks and each of the plurality of individual directed acyclic graphs comprise dependencies between the plurality of nodes representing the executable tasks; merging the individual directed acyclic graphs at runtime to create a merged directed acyclic graph, wherein the merged directed acyclic graph includes at least one dependency between nodes from different individual directed acyclic graphs.") Examiner Comments: Boucher teaches using a DAG to represent dependencies and interdependencies between executable code tasks/segments, directly mapping to the claimed representation of interdependencies in a DAG structure.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement, Siu, Chen and Hufnagl’s teaching into Boucher’s in order to model code interdependencies efficiently with a DAG, as Boucher enables merging graphs at runtime for scalable representation of related code elements (Boucher, col. 1, lines 45-50: "The present invention generally relates to the merging of directed acyclic graphs in a data flow programming environment at runtime.", This passage from Boucher motivates the combination by explaining the need for runtime merging of DAGs to handle dependencies in code execution, allowing Bahrami, Clement, Siu, Chen, and Hufnagl's tokenized code system to represent interdependencies, enhancing network-based dependency mapping).
Regarding Claim 10, is a product claim corresponding to the system claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of claim 3.
Claim(s) 4, 11 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami (US 2023/0106226 A1) in view of Clement (US 2023/0162040 A1), Siu (US 20250285171 A1), Chen (US 20240346634), Hufnagl (US 20240062621 A1) and Boucher (US 8,578,389) further in view of Khandelwal (US 2022/0229883 A1).
Regarding Claim 4, Bahrami, Clement, Siu, Chen, Hufnagl and Boucher teach
The system of Claim 3.
Bahrami, Clement, Siu, Chen, Hufnagl and Boucher did not specifically teach
wherein at least one of the plurality of code segments comprises a licensing attribute.
However, Khandelwal (US 2022/0229883 A1) teaches
wherein at least one of the plurality of code segments comprises a licensing attribute. (Para [0016], " monetizing the validated NFT includes at least one of monetizing via a tradeable NFT rewards program component; monetizing via an IP collaterization component; monetizing via a licensing component.") Examiner Comments: Khandelwal teaches embedding licensing attributes directly into the metadata of tokenized code segments, directly mapping to the claimed inclusion of a licensing attribute in at least one code segment for managing intellectual property rights in a blockchain-based system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement, Siu, Chen and Hufnagl’s teaching into Khandelwal’s in order to incorporate licensing attributes into code segments via NFTs, as Khandelwal enables secure management and monetization of creative works like source code through blockchain-embedded terms to prevent unauthorized use and ensure attribution by utilizing licensing as a monetization method for validated NFTs, allowing Bahrami, Clement, Siu, Chen, Hufnagl, and Boucher's system to include licensing attributes in code segments for IP protection and revenue sharing in network environments (Khandelwal [Summary]).
Regarding Claim 11, is a product claim corresponding to the system claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of claim 4.
Regarding Claim 17, Bahrami, Clement, Siu, Chen and Hufnagl teach
The method of Claim 15.
Bahrami, Clement, Siu, Chen and Hufnagl did not specifically teach
wherein the directed acyclic graph represents interdependencies of a plurality of code segments,
wherein at least one of the plurality of code segments comprises a licensing attribute.
However, Boucher (US 8,578,389) teaches
wherein the directed acyclic graph represents interdependencies of a plurality of code segments. (Claim 1, "generating a plurality of individual directed acyclic graphs, wherein each of the plurality of individual directed acyclic graphs comprise a plurality of nodes representing executable tasks and each of the plurality of individual directed acyclic graphs comprise dependencies between the plurality of nodes representing the executable tasks; merging the individual directed acyclic graphs at runtime to create a merged directed acyclic graph, wherein the merged directed acyclic graph includes at least one dependency between nodes from different individual directed acyclic graphs.") Examiner Comments: Boucher teaches using a DAG to represent dependencies and interdependencies between executable code tasks/segments, directly mapping to the claimed representation of interdependencies in a DAG structure.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement, Siu, Chen and Hufnagl’s teaching into Boucher’s in order to model code interdependencies efficiently with a DAG, as Boucher enables merging graphs at runtime for scalable representation of related code elements (Boucher, col. 1, lines 45-50: "The present invention generally relates to the merging of directed acyclic graphs in a data flow programming environment at runtime."; This passage from Boucher motivates the combination by explaining the need for runtime merging of DAGs to handle dependencies in code execution, allowing Bahrami, Clement, Siu, Chen, and Hufnagl's tokenized code system to represent interdependencies, enhancing network-based dependency mapping).
Bahrami, Clement, Siu, Chen, Hufnagl and Boucher did not specifically teach
wherein at least one of the plurality of code segments comprises a licensing attribute.
However, Khandelwal (US 2022/0229883 A1) teaches
wherein at least one of the plurality of code segments comprises a licensing attribute. (Para [0016], " monetizing the validated NFT includes at least one of monetizing via a tradeable NFT rewards program component; monetizing via an IP collaterization component; monetizing via a licensing component.") Examiner Comments: Khandelwal teaches embedding licensing attributes directly into the metadata of tokenized code segments, directly mapping to the claimed inclusion of a licensing attribute in at least one code segment for managing intellectual property rights in a blockchain-based system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement, Siu, Chen and Hufnagl’s teaching into Khandelwal’s in order to incorporate licensing attributes into code segments via NFTs, as Khandelwal enables secure management and monetization of creative works like source code through blockchain-embedded terms to prevent unauthorized use and ensure attribution by utilizing licensing as a monetization method for validated NFTs, allowing Bahrami, Clement, Siu, Chen, Hufnagl, and Boucher's system to include licensing attributes in code segments for IP protection and revenue sharing in network environments (Khandelwal [Summary]).
Claim(s) 5, 12 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami (US 2023/0106226 A1) in view of Clement (US 2023/0162040 A1), Siu (US 20250285171 A1), Chen (US 20240346634), and Hufnagl (US 20240062621 A1) further in view of Khandelwal (US 2022/0229883 A1).
Regarding Claim 5, Bahrami, Clement, Siu, Chen, and Hufnagl teach
The system of Claim 1.
Bahrami, Clement, Siu, Chen, and Hufnagl did not teach
wherein upon third-party retrieval of the non-fungible token, an originator of the code segment is notified.
However, Khandelwal teaches
wherein upon third-party retrieval of the non-fungible token, an originator of the code segment is notified (Para [0126], " Once a protector finds unauthorized use of creative content, the protector may submit this information to the system and the system then notifies the creator of the unauthorized use."). Examiner Comments: Khandelwal teaches triggering a notification to the code originator upon third-party retrieval of the NFT, directly mapping to the claimed notification process to facilitate tracking, royalties, or usage monitoring in a decentralized system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement, Siu, Chen and Hufnagl’s teaching into Khandelwal’s in order to incorporate notifications for originators in NFT systems, as Khandelwal enables system-based alerts for unauthorized use to protect creators (Khandelwal, para [0126]: "Once a protector finds unauthorized use of creative content, the protector may submit this information to the system and the system then notifies the creator of the unauthorized use.", reasoning: This passage from Khandelwal motivates the combination by showing how notifications to creators upon detection of use enhance IP protection, allowing Bahrami, Clement, Siu, Chen, Hufnagl, and Boucher's tokenized code system to include originator alerts for retrieval, improving accountability in network environments).
Regarding Claim 12, is a product claim corresponding to the system claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of claim 5.
Regarding Claim 18, is a method claim corresponding to the system claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of claim 5.
Claim(s) 7, 14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami (US 2023/0106226 A1) in view of Clement (US 2023/0162040 A1), Siu (US 20250285171 A1), Chen (US 20240346634), and Hufnagl (US 20240062621 A1) further in view of Yu (US 2018/0129869 A1).
Regarding Claim 7, Bahrami, Clement, Siu, Chen and Hufnagl teach
The system of Claim 1.
Bahrami, Clement, Siu, Chen and Hufnagl did not specifically teach
wherein the Euclidean distance is output from a twinning network.
However, Yu (US 2018/0129869 A1) teaches
wherein the Euclidean distance is output from a twinning network. (Para [0037], FIG. 4 shows a high-level block/flow diagram of a Siamese reconstruction network method 400, in accordance with an embodiment of the present invention; Para [0038], "The reconstruction loss is defined as , which is the Euclidean distance squared, which is used to measure errors in self-reconstruction and cross-reconstruction tasks between reconstructed and original rich embeddings.") Examiner Comments: Yu teaches outputting Euclidean distance from a Siamese (twinning) network for similarity measurement, directly mapping to the claimed output from a twinning network for code/feature comparison. A "twinning network" is another term often used for a Siamese Neural Network.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bahrami, Clement, Siu, Chen and Hufnagl’s teaching into Yu’s in order to compute similarity distances using paired networks, as Yu's Siamese architecture minimizes errors for accurate feature matching by indicating how Euclidean distance in a Siamese network measures reconstruction errors for feature similarity, allowing Bahrami, Clement, Siu, Chen, and Hufnagl's system to output precise similarity levels from twinning networks for code uniqueness checks (Yu [0038]).
Regarding Claim 14, is a product claim corresponding to the system claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of claim 7.
Regarding Claim 20, is a method claim corresponding to the system claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of claim 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191