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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references 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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 7, 8, 10, 14, 15, 17, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Aho et al. (Compilers Principles, Techniques, & Tools) in view of Yin et al. (CN-108959626-A)
Regarding Claim 1, Aho teaches a method for function compilation, comprising: acquiring an objective function to be compiled (Pg. 422, "Procedures and their implementation will be discussed at length in Chapter 7, along with the run-time management of storage for names. We use the term function in this section for a procedure that returns a value. We briefly discuss function declarations and three-address code for function calls. In three-address code, a function call is unraveled into the evaluation of parameters in preparation for a call, followed by the call itself. For simplicity, we assume that parameters are passed by value; parameter-passing methods are discussed in Section 1.6.6.")
determining, according to a bracket identifier in the objective function, a function body in the objective function (Pg. 422, "The productions in Fig. 6.52 allow function definitions and function calls. (The syntax generates unwanted commas after the last parameter, but is good enough for illustrating translation.) Nonterminals D and T generate declarations and types, respectively, as in Section 6.3. A function definition generated by D consists of keyword define, a return type, the function name, formal parameters in parentheses and a function body consisting of a statement. Nonterminal F generates zero or more formal parameters, where a formal parameter consists of a type followed by an identifier. Nonterminals S and E generate statements and expressions, respectively. The production for S adds a statement that returns the value of an expression. The production for E adds function calls, with actual parameters generated by A. An actual parameter is an expression." Fig. 6.5.2)
an argument called by the function body (Pg. 422, example 6.25
PNG
media_image1.png
200
550
media_image1.png
Greyscale
However, Aho is not relied upon for:
compiling, according to the function body and the argument, the objective function into an abstract syntax tree, wherein the abstract syntax tree is configured to describe a parameter calling relation between the function body and the argument
obtaining, based on the abstract syntax tree, a computation result corresponding to the objective function
Yin teaches compiling, according to the function body and the argument, the objective function into an abstract syntax tree, wherein the abstract syntax tree is configured to describe a parameter calling relation between the function body and the argument (Yin, [0033] "The generation of several abstract syntax trees specifically involves assembling the token sequence from a simple linear structure into a tree structure according to the grammatical rules of the language. The abstract syntax tree is defined as an interface called ASTree, and several node classes that implement the ASTree interface are provided." Also see Aho pg. 107)
obtaining, based on the abstract syntax tree, a computation result corresponding to the objective function (Yin, [0034] "The efficient automatic generation method for cross-platform heterogeneous data briefings described above is further explained as follows: the abstract syntax tree is interpreted and executed one by one by the interpreter, and the execution result is fed back. Specifically, the interpreter evaluates each abstract syntax tree. The evaluation method starts from the root node and recursively traverses the entire abstract syntax tree until the leaf node. Each visited node will have an evaluation return value, and the return value of other nodes, except for the leaf nodes, depends on the return value of their child nodes" Also see Aho pg. 104 and example 2.20)
Aho and Yin are analogous art because they are from the same field of endeavor in code parsing and compilation. Yin teaches a known method of compiling and computing a function’s result based on the AST representation. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Aho and Yin to utilize Yin’s known technique into the environment and processes of Aho which teaches principles and techniques of parsing and compiling based on both AST and three address codes, but primarily uses the three address codes representation in embodiments taught. Note MPEP 2143- (B) Simple Substitution of One Known Element for Another To Obtain Predictable Results.
Regarding Claim 3, Aho in view of Yin teaches The method according to claim 1, wherein the determining, according to a bracket identifier in the objective function, a function body in the objective function and an argument called by the function body comprises:
carrying out morpheme analysis on the objective function, and obtaining a morpheme sequence comprising a plurality of morphemes(Yin, [0081] "The language processor process involves three basic steps: lexical analysis, syntax analysis, and execution (or generation of machine language) Lexical analysis, also known as tokenization, involves dividing the source code into several words (Tokens). The next step is syntax analysis, which involves clarifying the hierarchical logical relationships between each word and generating several Abstract Syntax Trees (ASTs).")
determining, from the morpheme sequence, a bracket identifier configured to represent function calling (Yin, [0084-0085] "DocumentScript tokens can be divided into four categories: string tokens, numeric tokens, identifier tokens, and file terminator tokens. String words and numeric words are easy to understand; they are simply sequences of characters that represent strings and numbers, respectively. However, a character sequence like "123" with quotation marks (") at both ends, even if the part in the middle of the quotation marks can represent a number, is not a numerical word, but a string word. Identifier words are keywords used in a program, curly braces "{}", square brackets "[]", parentheses "()", semicolons ";", and variable names, etc. In addition to the three types of tokens with practical significance mentioned above, this article also defines a special end-of-file (EOF) word in DocumentScript to indicate the end of a code file. In this article, words are defined as an abstract class Token, and its fields and methods are designed as shown in the table below. EOF represents the end-of-file token, and EOL is the newline character defined in DocumentScript. The `isNumber`, `isIdentifier`, and `isString` methods are used to determine whether a token is a number, string, or identifier. These three methods can be used to determine the specific type of the token. The getText and getNumber methods are used to return the numerical value and string from the Token object. In the Token class, all methods except the getLineNumber method are abstract methods, which are implemented one by one in its subclasses.")
determining, according to the bracket identifier configured to represent the function calling, the function body in the objective function and the argument called by the function body (Yin, [0091-0092] "A complete piece of program code can be broken down into the four types of token sequences mentioned above, and this splitting work is done by the token segmenter (lexical analyzer) This article defines the word segmenter as a Lexer class, which implements word segmentation through regular expression matching. The Lexer class has five string fields. comPat, numPat, strPat, and idPat are regular expressions used to match comments, numeric tokens, string tokens, and identifier tokens, respectively, while the regexPat expression can match all valid strings in DocumentScript. During the syntax analysis process of the Lexer class, the tokenizer reads the source code line by line, checks each line from left to right to see if it matches regexPat, and extracts all matching strings. If the matched string (excluding leading whitespace) matches comPat, then the string is a comment. If the string is a numeric literal, string literal, or identifier, it will match numPat, strPat, or idPat. The token of the determined type will be stored in the token queue for return. Then, the same method is used to process the remaining part, and this process is repeated until the source code ends. Lexer can then split the source code into a token queue. In the Lexer class of this paper, the above process is mainly implemented through the readLine method and the addToken method.")
Regarding Claim 7, Aho in view of Yin teaches The method according to claim 1, further comprising: carrying out syntax detection on the objective function, and outputting error reporting information in a case that a syntax detection result represents that the objective function has an error (Aho, Pg. 194-195, "Common programming errors can occur at many different levels. • Lexical errors include misspellings of identifiers, keywords, or operators — e.g., the use of an identifier elipseSize instead of ellipseSize — and missing quotes around text intended as a string. • Syntactic errors include misplaced semicolons or extra or missing braces; that is, "{" or "}." As another example, in C or Java, the appearance of a case statement without an enclosing switch is a syntactic error (however, this situation is usually allowed by the parser and caught later in the processing, as the compiler attempts to generate code). • Semantic errors include type mismatches between operators and operands. An example is a return statement in a Java method with result type void. • Logical errors can be anything from incorrect reasoning on the part of the programmer to the use in a C program of the assignment operator = instead of the comparison operator ==. The program containing = may be well formed; however, it may not reflect the programmer's intent. The precision of parsing methods allows syntactic errors to be detected very efficiently. Several parsing methods, such as the LL and LR methods, detect an error as soon as possible; that is, when the stream of tokens from the lexical analyzer cannot be parsed further according to the grammar for the language. More precisely, they have the viable-prefix property, meaning that they detect that an error has occurred as soon as they see a prefix of the input that cannot be completed to form a string in the language. Another reason for emphasizing error recovery during parsing is that many errors appear syntactic, whatever their cause, and are exposed when parsing cannot continue. A few semantic errors, such as type mismatches, can also be detected efficiently; however, accurate detection of semantic and logical errors at compile time is in general a difficult task. The error handler in a parser has goals that are simple to state but chal lenging to realize: • Report the presence of errors clearly and accurately. • Recover from each error quickly enough to detect subsequent errors. • Add minimal overhead to the processing of correct programs. Fortunately, common errors are simple ones, and a relatively straightforward error-handling mechanism often suffices. How should an error handler report the presence of an error? At the very least, it must report the place in the source program where an error is detected, because there is a good chance that the actual error occurred within the previous few tokens. A common strategy is to print the offending line with a pointer to the position at which an error is detected.")
Wherein the syntax detection comprises at least one of:
detecting whether the same parameter name exists in the objective function, and determining, in a case that the same parameter name exists in the objective function, that the syntax detection result represents that the objective function has the error (Aho, pg. 97, Static checks are consistency checks that are done during compilation. Not only do they assure that a program can be compiled successfully, but they also have the potential for catching programming errors early, before a program is run. Static checking includes: • Syntactic Checking. There is more to syntax than grammars. For ex ample, constraints such as an identifier being declared at most once in a scope, or that a break statement must have an enclosing loop or switch statement, are syntactic, although they are not encoded in, or enforced by, a grammar used for parsing. " and Pg. 195 for error reporting)
detecting whether a number of the named parameter comprised in the objective function is consistent with a number of the argument, and determining, in a case that the number of the named parameter is inconsistent with the number of the argument, that the syntax detection result represents that the objective function has the error (Aho, Pg. 97, "Type Checking. The type rules of a language assure that an operator or function is applied to the right number and type of operands. If conversion between types is necessary, e.g., when an integer is added to a float, then the type-checker can insert an operator into the syntax tree to represent that conversion. We discuss type conversion, using the common term "coercion," below.")
detecting whether the objective function calls the argument, and determining, in a case that the objective function does not call the argument, that the syntax detection result represents that the objective function has the error (EN: only the first two error checks are mapped to Aho).
Regarding Claim 8, Aho teaches a non-transitory computer-readable medium, storing a computer program, that when executed by a processor of a computer, causes the computer to (Pg. 454, “Therefore, practically all modern computers arrange their storage as a memory hierarchy. A memory hierarchy, as shown in Fig. 7.16, consists of a series of storage elements, with the smaller faster ones "closer" to the processor, and the larger slower ones further away. Typically, a processor has a small number of registers, whose contents are under software control. Next, it has one or more levels of cache, usually made out of static RAM, that are kilobytes to several megabytes in size. The next level of the hierarchy is the physical (main) memory, made out of hundreds of megabytes or gigabytes of dynamic RAM. The physical memory is then backed up by virtual memory, which is implemented by gigabytes of disks. Upon a memory access, the machine first looks for the data in the closest (lowest-level) storage and, if the data is not there, looks in the next higher level, and so on.”)
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Claims 10, and 14 are medium claims reciting limitations similar to 3, and 7 respectively and are rejected under the same rationale.
Regarding Claim 15, Aho teaches An electronic device, comprising: a storage unit storing a computer program; and a processing unit configured to execute the computer program in the storage unit to cause the electronic device (Pg. 454)
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Claims 17 and 20 are apparatus claims reciting limitations similar to 3, and 7 respectively and are rejected under the same rationale.
Claims 2, 4, 5, 9, 11, 12, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Aho et al. (Compilers Principles, Techniques, & Tools) in view of Yin et al. (CN-108959626-A) and further in view of Mayer et al. (US-20210263729-A1)
Regarding Claim 2, Aho in view of Yin teaches The method according to claim 1, wherein the compiling, according to the function body and the argument, the objective function into an abstract syntax tree comprises: compiling the objective function into a higher-order function node in the abstract syntax tree (pg. 107 for compiling the objective function into AST)
Yin teaches compiling a named parameter in the function body into a named parameter node in the abstract syntax tree, wherein the named parameter node represents that an argument called by the named parameter is determined according to a name corresponding to the named parameter (Yin, [0036] "The efficient automatic generation method for cross-platform heterogeneous data briefings described above is further explained as follows: the node classes implementing the ASTree interface can be divided into leaf nodes and non-leaf nodes. Leaf nodes no longer contain child nodes, while non-leaf nodes can contain child nodes. Leaf nodes contain four classes: Name, NumberLiteral, StringLiteral, and NullStmnt, all of which inherit from the leaf node class. Non-leaf nodes all inherit from the non-leaf node class. Non-leaf nodes can be divided into three categories: the first category is used for program flow control, which includes sequential structure classes, branching structure classes used for expression processing, and loop structure classes used for function control." [0115] "The DocumentScript language used in this article is a scripting language that supports variable definition, so it involves the scope of variables. Therefore, the environment object is passed to the eval method during execution. In short, an environment object is a data structure used to record the correspondence between variable names and variable values. This article defines it as the Evironment interface. When a program adds a new variable, a key-value pair consisting of the variable's name and initial value is added to the current environment object. If the variable is used again later, the program will retrieve the variable's value from the environment object. If you want to assign a new value to the same object again, you must first find the scope of the variable and update the variable value on the environment object of the specified scope." and [0118] "Among the many subclasses of ASTree, the Name, NumberLiteral, StringLiteral, and NullStmnt classes belong to the leaf node classes, that is, subclasses of ASTLeaf Because Name represents a user-defined variable, its eval method retrieves the value from the environment object. If the variable is not defined in the environment object, an exception is thrown")
Mayer teaches wherein the higher-order function node represents that an operation is carried out on the function body and the argument by means of a higher-order function, and the computation result of the objective function is obtained (Mayer, [0050-0054] "
FIG. 1a depicts a fundamental syntax for a lambda-calculus that models the language supported by the present techniques is presented. FIG. 1a includes definitions for expressions e, spread across three lines and corresponding respectively to:
constants c, variables x, function application e1 e2, list construction e1::e2, record extension {e|f=ef}, record field projection e.f,
(simple and recursive) let-bindings let x e1 e2, conditionals if e1 e2 e3, and case expressions case e (p1 e1) . . . ; and
evaluation update.
The fundamental syntax of FIG. 1a includes constants c including numbers n, booleans b, strings s, the empty list [ ], the empty record { }, and built-in primitive operators, including operators for arithmetic, logic, and custom lenses. In particular, the primitive operators updateApp, diff, and merge facilitate the definition of custom lenses, which are discussed below. The values v include constants, closures (E, λp.e) where the environment E binds free variables in the body of the function λp.e, and lists and records with zero or more components." [0218] "In some embodiments, forward evaluation may include a compilation step. The evaluation may cause output to be displayed, corresponding, in some embodiments, to the evaluation of program source code written in syntax provided herein, to generate an HTML output as described with respect to FIG. 5a et seq. The output may then be displayed in the programming environment.")
obtaining the abstract syntax tree corresponding to the objective function according to the higher-order function node, the named parameter node, and the parameter calling relation between the function body and the argument (Mayer, [0305-0306] "In some embodiments, to convert an evaluator to edit-action-producing evaluator, so that the evaluator can use outputToInputEditAction to back-propagate edit actions on the output to edit actions on the program, the following steps may be used, wherein the steps are illustrated in an environment-based call-by-value lambda calculus. The evaluate1 function below takes a ProgState and returns a Val:
PNG
media_image2.png
686
783
media_image2.png
Greyscale
"The present techniques may make the evaluator tail-recursive, by eliminating the need for recursion by storing continuations as callbacks. To do so, for an evaluator that takes programs ProgState and produces values Val, the evaluator is refactored to take a ComputationState to return a ComputationState and repeatedly call itself until it reaches a final value.")
Aho, Yin and Mayer are analogous art because they are from the same field of endeavor in code parsing and compilation. Mayer teaches a known method of utilizing higher order lambda functions (functions used as arguments or being returned as results). Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Aho, Yin, and Mayer to utilize Mayer’s known technique into the environment and processes of Aho which teaches principles and techniques of parsing and compiling of functions to include higher order functions in the compiling and evaluation. Note MPEP 2143- (D) Applying a Known Technique to a Known Device (Method, or Product) Ready for Improvement To Yield Predictable Results.
Regarding Claim 4, Aho in view of Yin teaches The method according to claim 1, wherein the obtaining, based on the abstract syntax tree, a computation result corresponding to the objective function comprises:
Yin teaches building a parameter mapping dictionary based on the argument and the named parameter in the function body, wherein the parameter mapping dictionary is configured to represent a mapping relation between a parameter name of the named parameter and an argument corresponding to the parameter name (Yin, [0116] "The implementation of the Evironment interface is done by the BasicEnv class. In the BasicEnv class, the values object is a HashMap used to store key-value pairs; the outer object is the parent environment of the current environment. The child environment and its parent environment have an inheritance relationship, meaning that the child environment can access variables defined in the parent environment, but the parent environment cannot access variables defined in the child environment. The design concept for variable assignment and retrieval is very simple; it is implemented using the put and get methods. It is important to note that the put method and the putNew method are different. The `putNew` method adds or modifies variables directly in the current environment object. The `put` method first determines the domain of the variable to be operated on. If the variable is defined in its parent environment, it modifies the value of the variable in its parent environment. If the variable is defined in the current environment or has not been defined in any environment, it calls the `putNew` method in the current environment to add or modify the variable. The function of finding the domain of a variable is handled by the `where` method. Its execution process is as follows: first, it checks whether the variable is defined in the current environment. If it is not defined in the current environment, it continues to recursively call the `where` method in the parent environment to check whether the variable is defined in its parent environment. If the variable is not defined in the current environment and the current environment has no parent environment, it returns null.")
writing the parameter mapping dictionary in a scope stack (Yin, [0116] teaches a scope stack where the parent/child each have different scopes)
finding a target argument corresponding to the parameter name in the scope stack based on the parameter name of the named parameter in the function body comprised in the abstract syntax tree (Yin, [0116] teaches the get methods for finding the target argument)
Mayer teaches converting the named parameter in the abstract syntax tree into the target argument, and obtaining a converted abstract syntax tree; (Mayer, [0313-0314] "In some embodiments, the present techniques may transform the ComputationState to a first-order data structure. Initially, continuations may be stored as closures, which may make them difficult to reason about, as the above-described Edit Actions cannot be applied directly to them. Thus, in some embodiments, continuations may be replaced by the data they require, including an identifier specifying which code may be called. For example, at the beginning of the equivalent of evaluate1_1 function, instead of calling the first continuation on the ComputationState, the present techniques may use a case disjunction to execute code that the original closure would have executed. In the above example, this would yield the function evaluate1_2 that replaces the function evaluate1_1:
PNG
media_image3.png
357
650
media_image3.png
Greyscale
)
obtaining the computation result corresponding to the objective function based on the converted abstract syntax tree (Mayer, [0306-0313] "The present techniques may make the evaluator tail-recursive, by eliminating the need for recursion by storing continuations as callbacks. To do so, for an evaluator that takes programs ProgState and produces values Val, the evaluator is refactored to take a ComputationState to return a ComputationState and repeatedly call itself until it reaches a final value. " See the cs.computation.value and it's calculation in [0313])
For motivation to combine see claim 2.
Regarding Claim 5, Aho in view of Yin and further in view of Mayer teaches The method according to claim 4, wherein, the finding a target argument corresponding to the parameter name in the scope stack based on the parameter name of the named parameter in the function body comprised in the abstract syntax tree comprises:
Mayer teaches carrying out a search from a stack top of the scope stack along a stack bottom of the scope stack based on the parameter name
(Mayer, [0306] The loop goes from top to bottom.
PNG
media_image4.png
175
600
media_image4.png
Greyscale
)
determining the target argument according to a first found argument corresponding to a parameter name consistent with the parameter name (Mayer, [0313-0314])
Claims 9, 11, and 12 are medium claims reciting limitations similar to 2, 4, and 5 respectively and are rejected under the same rationale.
Claims 16 and 18 are apparatus claims reciting limitations similar to 2 and 4 respectively and are rejected under the same rationale.
Claims 6, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Aho et al. (Compilers Principles, Techniques, & Tools) in view of Yin et al. (CN-108959626-A) and further in view of Peng et al. (WO-2019165706-A1)
Regarding Claim 6, 13, and 19, Aho in view of Yin teaches The method according to claim 1. Peng teaches further comprising: serializing the abstract syntax tree based on an inverse Polish expression in combination with a target serialization algorithm (Peng, [0072] "S350, pop the expression objects from the second stack in reverse order to generate the Reverse Polish notation." [0040] "Please refer to Figure 3 for details, which is a schematic diagram of a sub-process of an expression processing method provided in an embodiment of this application. Furthermore, the step S300 of performing Reverse Polish Notation on the expression based on the type of the expression object includes steps S310-S350." [0041-0071] disclose the serialization algorithm for parsing the syntax into a first stack, [0071-0074] discloses poping the objects from the first stack to a second stack in reverse order to create the serialized, linear, reverse polish notation. Also see Aho pg. 39-42 for inverse polish expression (postfix) implementation methods.)
obtaining a serialized object, and transmitting the objective function based on the serialized object.(Peng, [0076-0078] "Step 1: Initialize the preset third stack, and sequentially obtain the expression objects from the Reverse Polish notation. Specifically, the preset third stack is used to store the execution results of the Reverse Polish Notation. Specifically, the expression objects are obtained sequentially from the Reverse Polish Notation by feeding them into the Reverse Polish Notation sequentially from left to right." Please see [0079-0087]"Step four: If all expression objects of the Reverse Polish Notation have been obtained, then the execution result of the last one pushed onto the third stack is determined as the execution result of the Reverse Polish Notation" EN: once the serialization is complete the serialized object is popped from the second stack and transmitted onto the third stack for execution.)
Aho, Yin and Peng are analogous art because they are from the same field of endeavor in code parsing and compilation. Peng teaches a known method of utilizing polish inverse order (postfix notation) in the representation and evaluation of expressions. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Aho, Yin, and Peng to utilize Peng’s known technique into the environment and processes of Aho which teaches principles and techniques of parsing and compiling of functions to implement Aho’s postfix notation in a programmatic algorithm. Note MPEP 2143- (D) Applying a Known Technique to a Known Device (Method, or Product) Ready for Improvement To Yield Predictable Results.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Poon et al. (US-20200034125-A1): discloses error correction using parsed AST.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Lewis Bullock can be reached on 571-272-3759. 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.
/A.E.D./Examiner, Art Unit 2199
/DUY KHUONG T NGUYEN/Primary Examiner, Art Unit 2199
Prosecution Insights