Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
Claims filed on 12/30/2025 for patent application 18/572,296 has been acknowledged. Claims 1-14, 16, and 18-22 are currently pending and have been considered below. Claims 1, 7, 13, 14, 16, and 18 are independent claims. Claims 1, 4-7, 11-14, 16, and 18-22 have been amended. No new claims have been added.
In view of amendments to claims 1, 4-7, 11-14, 16, and 18-22, the 35 U.S.C. 112(b) rejection of claims 1, 4-7, 11-14, 16, and 18-22 has been withdrawn.
Priority
This application is a U.S. national application submitted under 35 U.S.C. 371 of PCT application number PCT/FR2022/051377 filed on 07/08/2022. The application claims the foreign priority of FRENCH REPUBLIC, FR2107461, filed on 07/09/2021.
Response to Arguments
Applicant's arguments on pages 8-9, filed on 12/30/2025, with regards to claims 1 and 13, have been fully considered but they are not persuasive. The reasons set forth below.
On page 8-9 of the remarks, filed on 12/30/2025, applicant argues: “Nevertheless, the Action asserts that Jacobs cures the above noted deficiencies of Lai. Specifically, the Action relies on the teaching of symbolic execution in Jacobs as corresponding to the claimed observing, by the processor, execution of the applet function. However, this reference does not actually observe execution of the applet function. In fact, the reference specifically discusses not executing the method and only using symbolic execution. In contrast, the claimed invention is designed to observe the actual execution of the applet.”
Examiner respectfully disagrees.
The cited paragraph from the Jacobs reference from the non-final rejection, filed on 10/07/2025, is reproduced here: Jacobs, Page 3, “Each method is verified by, executing it symbolically. Symbolic execution is like ordinary, concrete, execution, except that symbolic values are used instead of concrete values.”
Jacobs explicitly teaches the similarity between symbolic execution and ordinary execution, while illustrating one embodiment which comprises observing symbolic execution. Furthermore, Jacobs does not teach away from observing ordinary execution. A person of ordinary skills in the art, after reading the teachings of prior art references Lai in view of Jacobs, would understand that the execution of an applet function could be observed whether utilizing symbolic values or concrete values.
On page 9 of the remarks, filed on 12/30/2025, applicant argues: “Furthermore, the Action asserts that Jacobs taches implementing a security process. However, reporting errors is not a security process. Thus, Jacobs cannot reasonably be asserted as curing the deficiencies of Lai in this regard.”
Examiner respectfully disagrees.
The cited paragraph from the Jacobs reference from the non-final rejection, filed on 10/07/2025, is reproduced here: Jacobs, page 1, “reports either “0 errors found” or indicates the location of a potential error.”
A person of ordinary skills in the arts understands that reporting of errors is a common step deployed in common security processes. The broadest reasonable interpretation of a “security process” includes, both reporting an error and indicating the location of an error, as Jacobs explicitly teaches.
Applicant’s arguments on pages 9-10, filed on 12/30/2025, with respect to claims 7 and 14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Thus, the 35 USC 103 rejection is maintained and updated below to reflect the amendments.
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, 4-6, 13, 16, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Lai et al. (US Patent Application Publication No. US 2017/0235586 A1, hereinafter, Lai) in view of Jacobs et al. (Non-Patent Literature, “The VeriFast Program Verifier A Tutorial for Java Card Developers”, hereinafter, Jacobs).
Regarding Claim 1, Lai discloses: A method for handling execution of an applet function by an electronic device comprising:
receiving a request to execute the applet function (Lai, ¶[0021], “(4) execute the modified lambda functions with a null value passed to each corresponding formal parameter of the lambda functions to retrieve the values of the corresponding arguments for the captured local variables”);
verifying a type associated with the applet function (Lai, ¶[0020], “Java programs may include one or more lambda functions that may be compiled into GPU programs that will invoke processing resources provided by a device (e.g., the device 120). The lambda functions may employ captured local variables that the JVM 130 stores and makes available at runtime.”);
if the type of the applet function is a given type, determining, by a processor, information relating to arguments processed or to data delivered by the applet function (Lai, ¶[0021], “(4) execute the modified lambda functions with a null value passed to each corresponding formal parameter of the lambda functions to retrieve the values of the corresponding arguments for the captured local variables” ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”); and
Lai does not explicitly teach the following limitation that Jacobs teaches:
observing, by the processor, execution of the applet function and, if the applet function processes data inconsistently with the information relating to the arguments processed or to the data delivered by the applet function (Jacobs, page 1, “complies with method preconditions, method postconditions, loop invariants, and other assertions specified by the programmer in the form of special comments (known as annotations) in the source code.” Page 3, “Each method is verified by, executing it symbolically. Symbolic execution is like ordinary, concrete, execution, except that symbolic values are used instead of concrete values.”),
implementing a security process (Jacobs, page 1, “reports either “0 errors found” or indicates the location of a potential error.”).
Lai in view of Jacobs is analogous art because the references are from the “same field of endeavor” and are from the same “problem solving area.” Namely, they pertain to the field of “Java development security methods.” It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Lai with Jacobs to
“observing, by the processor, the progress of the function and, if the function processes data inconsistently with the information relating to the arguments processed and/or to the data delivered by the function, implementing a security process,”
because, VeriFast is a program verification tool for verifying certain correctness properties of Java and Java Card programs (Jacobs, page 1).
Regarding Claim 4, Lai in view of Jacobs teaches: The method as claimed in claim 1, wherein the information relating to the arguments processed or to the data delivered by the function comprise the type or the number of the arguments processed by the function (Lai, ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”).
Regarding Claim 5, Lai in view of Jacobs teaches: The method as claimed in claim 1, wherein the information relating to the arguments processed by the function comprise the type or the number of the data delivered by the function (Lai, ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”).
Regarding Claim 6, Lai in view of Jacobs teaches: The method as claimed in claim 1, wherein the determining the information relating to the arguments processed or to the data delivered by the applet function (Lai, ¶[0021], “(4) execute the modified lambda functions with a null value passed to each corresponding formal parameter of the lambda functions to retrieve the values of the corresponding arguments for the captured local variables” ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”) and
the observing each time a request to execute the function is received are implemented (Lai, ¶[0021], “(4) execute the modified lambda functions with a null value passed to each corresponding formal parameter of the lambda functions to retrieve the values of the corresponding arguments for the captured local variables”).
Regarding Claim 13, Lai in view of Jacobs teaches: An electronic device capable of executing an applet function comprising: processing circuity configured to:
receive a request to execute the applet function (Lai, ¶[0021], “(4) execute the modified lambda functions with a null value passed to each corresponding formal parameter of the lambda functions to retrieve the values of the corresponding arguments for the captured local variables”);
verify a type associated with the applet function (Lai, ¶[0020], “Java programs may include one or more lambda functions that may be compiled into GPU programs that will invoke processing resources provided by a device (e.g., the device 120). The lambda functions may employ captured local variables that the JVM 130 stores and makes available at runtime.”);
determine, if the type of the applet function is a given type, information relating to arguments processed or to data delivered by the applet function (Lai, ¶[0021], “(4) execute the modified lambda functions with a null value passed to each corresponding formal parameter of the lambda functions to retrieve the values of the corresponding arguments for the captured local variables” ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”); and
observe execution of the applet function and, if the applet function processes data inconsistently with the information relating to the arguments processed or to the data delivered by the applet function (Jacobs, page 1, “complies with method preconditions, method postconditions, loop invariants, and other assertions specified by the programmer in the form of special comments (known as annotations) in the source code.” Page 3, “Each method is verified by, executing it symbolically. Symbolic execution is like ordinary, concrete, execution, except that symbolic values are used instead of concrete values.”),
the processing circuity is further configured to implement a security process (Jacobs, page 1, “reports either “0 errors found” or indicates the location of a potential error.”).
Regarding Claim 16, Lai in view of Jacobs teaches: A non-transitory computer-readable storage medium on which is stored a computer program comprising instructions for the execution of the method for handling execution of the applet function by the electronic device as claimed in claim 1 (Lai, ¶[0021], “(4) execute the modified lambda functions with a null value passed to each corresponding formal parameter of the lambda functions to retrieve the values of the corresponding arguments for the captured local variables” ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”) (Jacobs, page 1, “complies with method preconditions, method postconditions, loop invariants, and other assertions specified by the programmer in the form of special comments (known as annotations) in the source code.” Page 3, “Each method is verified by, executing it symbolically. Symbolic execution is like ordinary, concrete, execution, except that symbolic values are used instead of concrete values.”).
Regarding Claim 22, Lai in view of Jacobs teaches: The method as claimed in claim 4, wherein the information relating to the arguments processed by the function comprise the type or the number of the data delivered by the function (Lai, ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”).
Claims 2-3 and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Lai et al. (US Patent Application Publication No. US 2017/0235586 A1, hereinafter, Lai) in view of Jacobs et al. (Non-Patent Literature, “The VeriFast Program Verifier A Tutorial for Java Card Developers”, hereinafter, Jacobs) and further in view of Lancia et al. (Non-Patent Literature, “Fuzzing and Overflows in Java Card Smart Cards,” hereinafter, Lancia).
Regarding Claim 2, Lai in view of Jacobs teaches: The method as claimed in claim 1,
Lai in view of Jacobs does not explicitly teach the following limitation that Lancia teaches:
wherein the given type is a function which is executed directly on the processor of the electronic device outside of a virtual machine which executes the applet (Lancia, chapter 3.3, “Abusing the Native Execution Mechanism for Code Injection; When a native method call occurs, the switch from the Java runtime environment to the native execution environment requires an index in the native array to determine the native function pointer.”).
Lai in view of Jacobs and further in view of Lancia is analogous art because the references are from the “same field of endeavor” and are from the same “problem solving area.” Namely, they pertain to the field of “Java development security methods.” It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Lai in view of Jacobs with Lancia,
“wherein the given type is a function which is executed directly on the processor of the electronic device outside of a virtual machine which executes the applet,”
because, the Byte Code Verifier (BCV) is one of the most important security element in the Java Card environment. Indeed, embedded applets must be verified prior installation to prevent ill-formed applet loading (Lancia, Abstract).
Regarding Claim 3, Lai in view of Jacobs and further in view of Lancia teaches: The method as claimed in claim 2, wherein the given type is a native function and the virtual machine is a Java Card virtual machine (Lancia, chapter 3.3, “Abusing the Native Execution Mechanism for Code Injection; When a native method call occurs, the switch from the Java runtime environment to the native execution environment requires an index in the native array to determine the native function pointer.”).
Regarding Claim 19, Lai in view of Jacobs and further in view of Lancia teaches: The method as claimed in claim 2, wherein the information relating to the arguments processed or to the data delivered by the function comprise the type or the number of the arguments processed by the function (Lai, ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”).
Regarding Claim 20, Lai in view of Jacobs and further in view of Lancia teaches: The method as claimed in claim 2, wherein the information relating to the arguments processed by the function comprise the type or the number of the data delivered by the function (Lai, ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”).
Regarding Claim 21, Lai in view of Jacobs and further in view of Lancia teaches: The method as claimed in claim 3, wherein the information relating to the arguments processed by the function comprise the type or the number of the data delivered by the function (Lai, ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”).
Claims 7, 11-12, 14, 18 are are rejected under 35 U.S.C. 103 as being unpatentable over Lai et al. (US Patent Application Publication No. US 2017/0235586 A1, hereinafter, Lai) in view of Pirzadeh et al. (US Patent Application Publication No. US 2015/0193222 A1, hereinafter, Pirzadeh).
Regarding Claim 7, Lai discloses: A method for loading an applet in an electronic device, comprising:
detecting in the applet a function having a given type (Lai, ¶[0020], “The JVM 130 itself is configured to provide an environment within which software programs written in Java may execute. As those skilled in the pertinent art understand, Java programs may include one or more lambda functions that may be compiled into GPU programs that will invoke processing resources provided by a device (e.g., the device 120).”);
determining, by a processor, arguments processed or data delivered by the function (Lai, ¶[0021], “the captured local variable retriever 150 is configured to (1) retrieve the signature of the lambda functions from classfiles of the Java classes containing the lambda functions, (2) compare the retrieved signature with the declarations of the lambda functions to identify the arguments corresponding to the captured local variables”);
generating information relating to the arguments processed or to the data delivered by the function (Lai, ¶[0021], “the captured local variable retriever 150 is configured to (1) retrieve the signature of the lambda functions from classfiles of the Java classes containing the lambda functions, (2) compare the retrieved signature with the declarations of the lambda functions to identify the arguments corresponding to the captured local variables” ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”);
loading the modified applet in the electronic device (Lai, ¶[0021], “(4) execute the modified lambda functions, … (6) pass the bytecode of the lambda functions”).
Lai does not explicitly teach the following limitation that Pirzadeh teaches:
adding, to the applet, information relating to the arguments processed or to the data delivered by the function to obtain a modified applet (Pirzadeh, ¶[0078], "A Get Data Function 317 and a Put Data Function 318 may allow for data synchronization between updatable applet 252 and static applet 253. The Get Data Function 317 may retrieve any data from the static applet 253 that may be requested by the updatable applet 252. The Put Data Function 318 may set any data in the static applet 253 that may be requested by the updatable applet 252." ¶[0086], "An Update Data Function 351 may delete, replace, or update any data in the updatable applet 252. Updated code 352 may comprise a code patch that may fix or add functionality to code in the updatable applet 252."); and
Lai in view of Pirzadeh is analogous art because the references are from the “same field of endeavor” and are from the same “problem solving area.” Namely, they pertain to the field of “Java development security methods.” It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Lai with Pirzadeh to
“adding in applet information relating to the arguments processed and/or to the data delivered by the function to obtain a modified applet,”
because, embodiments of the invention relate to a device comprising an updatable applet and a static applet (Pirzadeh, Abstract).
Regarding Claim 11, Lai in view of Pirzadeh teaches: The method as claimed in claim 7, wherein the information relating to the arguments processed or to the data delivered by the function comprise the type or the number of the arguments processed by the function (Lai, ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”).
Regarding Claim 12, Lai in view of Pirzadeh teaches: The method as claimed in claim 7, wherein the information relating to the arguments processed by the function comprise the type or the number of the data delivered by the function (Lai, ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”).
Regarding Claim 14, Lai in view of Pirzadeh teaches: A device for loading an applet in an electronic device comprising: processing circuitry configured to:
detect in the applet a function having a given type (Lai, ¶[0020], “The JVM 130 itself is configured to provide an environment within which software programs written in Java may execute. As those skilled in the pertinent art understand, Java programs may include one or more lambda functions that may be compiled into GPU programs that will invoke processing resources provided by a device (e.g., the device 120).”);
determine arguments processed or data delivered by the function (Lai, ¶[0021], “the captured local variable retriever 150 is configured to (1) retrieve the signature of the lambda functions from classfiles of the Java classes containing the lambda functions, (2) compare the retrieved signature with the declarations of the lambda functions to identify the arguments corresponding to the captured local variables”);
generate information relating to the arguments processed or to the data delivered by the function (Lai, ¶[0021], “the captured local variable retriever 150 is configured to (1) retrieve the signature of the lambda functions from classfiles of the Java classes containing the lambda functions, (2) compare the retrieved signature with the declarations of the lambda functions to identify the arguments corresponding to the captured local variables” ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”);
add, to the applet, information relating to the arguments processed or to the data delivered by the function to obtain a modified applet (Pirzadeh, ¶[0078], "A Get Data Function 317 and a Put Data Function 318 may allow for data synchronization between updatable applet 252 and static applet 253. The Get Data Function 317 may retrieve any data from the static applet 253 that may be requested by the updatable applet 252. The Put Data Function 318 may set any data in the static applet 253 that may be requested by the updatable applet 252." ¶[0086], "An Update Data Function 351 may delete, replace, or update any data in the updatable applet 252. Updated code 352 may comprise a code patch that may fix or add functionality to code in the updatable applet 252."); and
load the modified applet in the electronic device (Lai, ¶[0021], “(4) execute the modified lambda functions, … (6) pass the bytecode of the lambda functions”).
Regarding Claim 18, Lai in view of Pirzadeh teaches: A non-transitory computer-readable storage medium on which is stored a computer program comprising instructions for the execution of the method for loading the applet in the electronic device as claimed in claim 7 (Lai, ¶[0021], “(4) execute the modified lambda functions with a null value passed to each corresponding formal parameter of the lambda functions to retrieve the values of the corresponding arguments for the captured local variables” ¶[0022], “Turning to FIG. 2, illustrated is a flow diagram of one embodiment of a method 200 of retrieving values of captured local variables for lambda functions in Java.”) (Jacobs, page 1, “complies with method preconditions, method postconditions, loop invariants, and other assertions specified by the programmer in the form of special comments (known as annotations) in the source code.” Page 3, “Each method is verified by, executing it symbolically. Symbolic execution is like ordinary, concrete, execution, except that symbolic values are used instead of concrete values.”) (Pirzadeh, ¶[0078], "A Get Data Function 317 and a Put Data Function 318 may allow for data synchronization between updatable applet 252 and static applet 253. The Get Data Function 317 may retrieve any data from the static applet 253 that may be requested by the updatable applet 252. The Put Data Function 318 may set any data in the static applet 253 that may be requested by the updatable applet 252." ¶[0086], "An Update Data Function 351 may delete, replace, or update any data in the updatable applet 252. Updated code 352 may comprise a code patch that may fix or add functionality to code in the updatable applet 252.").
Claims 8-10 are are rejected under 35 U.S.C. 103 as being unpatentable over Lai et al. (US Patent Application Publication No. US 2017/0235586 A1, hereinafter, Lai) in view of Pirzadeh et al. (US Patent Application Publication No. US 2015/0193222 A1, hereinafter, Pirzadeh) further in view of Lancia et al. (Non-Patent Literature, “Fuzzing and Overflows in Java Card Smart Cards,” hereinafter, Lancia).
Regarding Claim 8, Lai in view of Pirzadeh teaches: The method as claimed in claim 7,
Lai in view of Pirzadeh does not explicitly teach the following limitation that Lancia teaches:
wherein the given type is a function which is executed directly on the processor of the electronic device outside of a virtual machine (Lancia, chapter 3.3, “Abusing the Native Execution Mechanism for Code Injection; When a native method call occurs, the switch from the Java runtime environment to the native execution environment requires an index in the native array to determine the native function pointer.”).
Lai in view of Pirzadeh and further in view of Lancia is analogous art because the references are from the “same field of endeavor” and are from the same “problem solving area.” Namely, they pertain to the field of “Java development security methods.” It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Lai in view of Pirzadeh with Lancia,
“wherein the given type is a function which is executed directly on the processor of the electronic device outside of a virtual machine”
because, the Byte Code Verifier (BCV) is one of the most important security element in the Java Card environment. Indeed, embedded applets must be verified prior installation to prevent ill-formed applet loading (Lancia, Abstract).
Regarding Claim 9, Lai in view of Pirzadeh and further in view of Lancia teaches: The method as claimed in claim 8, wherein the given type is a native function and the virtual machine is a Java Card virtual machine (Lancia, chapter 3.3, “Abusing the Native Execution Mechanism for Code Injection; When a native method call occurs, the switch from the Java runtime environment to the native execution environment requires an index in the native array to determine the native function pointer.”).
Regarding Claim 10, Lai in view of Pirzadeh and further in view of Lancia teaches: The method as claimed in claim 7 any one of claims 7, wherein the modified applet is a Java Card converted applet (Lancia, chapter 1.1, “Because Java Card does not support dynamic class loading, bytecode verification is performed at loading time, i.e. before installing the Converted APplet (CAP) file onto the card.”).
CONCLUSION
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDGAR W XIE whose telephone number is (703)756-4777. The examiner can normally be reached Monday - Friday, 8:00am - 5:00pm.
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, JEFFREY PWU can be reached at (571)272-6798. 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.
/EDGAR W XIE/ Examiner, Art Unit 2433
/WASIKA NIPA/ Primary Examiner, Art Unit 2433
Prosecution Insights