Prosecution Insights
Last updated: August 17, 2026
Application No. 18/582,274

METHOD OF EXECUTING A JAVA CARD APPLICATION

Non-Final OA §103
Filed
Feb 20, 2024
Priority
Feb 28, 2023 — EU 23159037.3
Examiner
TRAM, TIEN THANH
Art Unit
4100
Tech Center
4100
Assignee
STMicroelectronics N.V.
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-60.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
2 currently pending
Career history
1
Total Applications
across all art units

Statute-Specific Performance

§103
100.0%
+60.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 0 resolved cases

Office Action

§103
DETAILED ACTION This communication is in response to the application filed on 02/20/2024 in which claims 1-23 are pending in the application. Claims 1, 7, 15, 18, and 21 are in independent form. 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 . Information Disclosure Statement The information disclosure statement (IDS) submitted on 02/21/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Priority Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 23159037.3, filed on 02/28/2023. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Specification The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. The disclosure is objected to because of the following informalities: In ¶ [0004], “Such integrated circuits includes” should read “Such integrated circuits include”. ¶ [0045] and ¶ [0049] use 200 to refer to as method and system. ¶ [0049] use 202 to refer to as cores and circuits. Appropriate correction is required. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 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. Claim(s) 1-5, 7-11, 15-19 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Schwabe (US 7444631 B2) and in further view of Dawson (US 8813051 B2). As per claim 1, Schwabe teaches a method of executing an application of a scripting language on an integrated circuit [Col. 4: 64-67], the applet is executed by a virtual machine 49 running on a microprocessor 48. The virtual machine 49, which can be referred to as the Java Card virtual machine], the application of the scripting language using first and second packages of an application programming interface (API) that extend to each other, the method comprising: [Col. 9:40-42, in method component 180 that is located in an external package (package 1), linking is required (step 142)], [Col. 6:27-29, As shown in FIG. 3, a package may depend on other packages at the same API level or from those packages in lower API levels]. from a class of the first package, calling and executing a native method of the API [Col. 5:53-60, A method declares executable code that can be invoked and that passes a fixed number of values as arguments. Classes also can implement Java interfaces. An interface is a reference type whose members are constants and abstract methods. The virtual machine 49 may include an interpreter or native implementation which provides access to a runtime system which includes the Java Card API and supporting functionalities]. to implement a function of a method of the class of the first package [Col. 5:13-18, Application programming interface (API) classes for the smart card platform can be written as Java source files which include package designations, where a package includes a number of compilation units and has a unique name. Package mechanisms are used to identify and control access to classes, fields and methods]; Schwabe teaches a method of a class of the second package; [Col. 9:14-17, Program elements in package P2 200 may include references to methods and other data in external package P1 which already exists as an image 174 on card 40 (of CAP File A 74)] and executing the method of the class of the second package using a virtual machine of the scripting language [Col. 9:64-65, Using the process of FIG. 6, a package may be downloaded onto a card and prepared for execution by a virtual machine]. Schwabe teaches calling the method as detailed above but does not explicitly teach calling, from the native method of the API. Dawson discloses calling, from the native method of the API, [Col. 6:3-6, Referring to FIG. 5, in certain embodiments in accordance with the invention, several classes may be provided through a new Quarantine API 500 to enable multiple copies of native code 304 to execute in a Java Virtual Machine 202.] Dawson and Schwabe are both concerned with executing native code efficiently within managed runtime environments like Java and are therefore combinable/modifiable. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Dawson with the teachings of Schwabe to implement the first package’s method as native code, then have it trigger a method in the second package to be executed by the scripting-language virtual machine. The motivation would be to improve cross-package execution efficiency by allowing native API methods to bridge between scripting language packages. As per claim 2, Schwabe teaches the method according to claim 1, wherein the application of the scripting language is a Java card application [Col. 4:3-5, Referring to FIG. 1, development of an applet for a resource-constrained device, such as a smart card 40, begins in a manner similar to development of a Java program]. As per claim 3, Schwabe teaches the method according to claim 1, wherein the calling the method of the class of the second package comprises: pushing a class token and a method token of the method of the class of the second package on a card stack [Col. 6:27-32, the method reference consists of a package token, class token, and method token which are used to locate that particular method in an external package], [Col. 5:19-21, The Java Card API allows applications written for one Java Card-enabled platform to run on any other Java Card-enabled platform], [Col. 8:15-24 , CAP file B 100 for the second package includes an import component 104 with a list of all packages referenced by the applet classes. Each such external package reference comprises a mapping 106 between an internal package token and an external unique Application Identifier (AID) for that package. Each package token is used in other components within CAP file 100 to identify a particular referenced external package in a concise manner, thereby reducing the footprint size of the representation of the applet]. As per claim 4, Schwabe teaches the method according to claim 3, wherein the card stack is a Java card stack and the virtual machine is a Java card virtual machine [Col. 4:65-67, The virtual machine 49, which can be referred to as the Java Card virtual machine], [Col. 5:19-21, The Java Card API allows applications written for one Java Card-enabled platform to run on any other Java Card-enabled platform], [Col. 6:25-26, At the highest level is an application level where various applets 56, 58 and 60 reside]. As per claim 5, Dawson teaches the method according to claim 1, wherein the native method is in a C programming language [Col. 5: 5-14, As shown, the Java Virtual Machine 202 may support the Java Native Interface 208 as a mechanism to enable Java bytecode 200 to call methods written in native code (e.g., C and C++) and vice versa. Unlike the Java bytecode 200, the native code may be written for the underlying hardware and operating system platform 204, 206. The Java Native Interface 208 may allow a developer to write native methods to handle situations where an application cannot be written entirely in the Java programming language]. As per claim 7, the combination of Schwabe and Dawson discloses the claimed invention as detailed above for claim 1. Schwabe further discloses the executing the application including: from a class of the first package [Col. 9:52-55, Once the image 174 for package P1 is found from package registry 120, export component 182 of image 174 is searched to locate the class with the specified class token (step 150)]. As per claim 15, the combination of Schwabe and Dawson discloses the claimed invention as detailed above for claim 1. Dawson further discloses wherein the first native code is in a programming language different from the scripting language [Col. 5: 5-14, As shown, the Java Virtual Machine 202 may support the Java Native Interface 208 as a mechanism to enable Java bytecode 200 to call methods written in native code (e.g., C and C++) and vice versa. Unlike the Java bytecode 200, the native code may be written for the underlying hardware and operating system platform 204, 206. The Java Native Interface 208 may allow a developer to write native methods to handle situations where an application cannot be written entirely in the Java programming language] and the executing the first native code of the API includes calling a method of a class of the second package [Col. 6:34-40, However, referring to FIG. 8, using the new Quarantine API 500 API illustrated in FIG. 5, a call to native1 from quarantineCls1 will invoke the native code in a first process in a first remote execution container 400a, whereas a call to native1 from quarantineCls2 will invoke a copy of the same native code in a second process in a second remote execution container 400b]; and executing the called method of the class of the second package using a virtual machine of the scripting language [Col. 2:11-14, calling the native method in the second instance causes a second copy of the native code to run in a second remote execution container (e.g., a second process) separate from the first remote execution container]. As per claim 8, the claim is rejected using the same rationale as noted above for claim 2. As per claim 9, the claim is rejected using the same rationale as noted above for claim 3. As per claim 10, the claim is rejected using the same rationale as noted above for claim 4. As per claim 11, the claim is rejected using the same rationale as noted above for claim 5. As per claim 16, the claim is rejected using the same rationale as noted above for claim 2. As per claim 17, the claim is rejected using the same rationale as noted above for claim 5. As per claim 18, the claim is rejected using the same rationale as noted above for claim(s) 1, 7, and 15. As per claim 19, the claim is rejected using the same rationale as noted above for claim(s) 2 and 5. As per claim 21, the claim is rejected using the same rationale as noted above for claim(s) 1, 7, 15, and 18. Claim(s) 6 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Schwabe (US 7444631 B2) and Dawson (US 8813051 B2) and further in view of Plummer (US 20050166185 A1). As per claim 6, the combination of Schwabe and Dawson discloses the claimed invention as detailed above for claim 1 above. The combination does not specifically teach the method according to claim 1, wherein the executing the application avoids a linker error associated with rules of the scripting language. Plummer teaches the method according to claim 1, wherein the executing the application [¶[0028], the API enables a JAVA programming language native method to determine which method gets executed next] avoids a linker error associated with rules of the scripting language [Col. 5 :31-32, computer code for using a native method to manipulate the JAVA programming language stack], [¶[0026], rewriting sections of native C code as a JAVA programming language method called Class.runStaticinitializers( ), using a transition frame to execute Class.runStaticinitializers( ), using an SNI method to manipulate a corresponding JAVA programming language stack so that the "<clinit>" method may be executed without the need to re-enter and interpreter, and using a new opcode]. Dawson, Schwabe, and Plummer are in the same endeavor and they are in executing subprogram. Therefore, both references are combinable/modifiable. Dawson, Schwabe, and Plummer are both concerned with Java Virtual Machine (JVM) runtime optimizations, execution efficiency, and memory architecture management and are therefore combinable/modifiable. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Dawson and Schwabe with the teachings of Plummer to provide the native method that invokes a method of the second package which is executed by the scripting-language virtual machine which bypasses the cross-import restriction. The motivation would be to prevents linker conflicts by ensuring smooth cross-package communication without breaking scripting rules. As per claim 12, the claim is rejected using the same rationale as noted above for claim 6. Claim(s) 13 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Schwabe (US 7444631 B2) and Dawson (US 8813051 B2) and further in view of Wilkinson (US 8726247 B2). As per claim 13, the combination of Dawson and Schwabe discloses the claimed invention as detailed above for claim 1 above. The combination does not specifically teach the device of claim 7, comprising an integrated circuit, wherein the memory and the processing circuitry are embedded in the integrated circuit. Wilkinson teaches the device of claim 7, comprising an integrated circuit, wherein the memory and the processing circuitry [Col. 6:10-12 ,the integrated circuit card includes a processor that is coupled to the memory] are embedded in the integrated circuit [Col. 2:47-56, due to the small number of external components required and their small size, microcontrollers frequently are used in integrated circuit cards, such as smart cards. Such smart cards come in a variety of forms, including contact-based cards, which must be inserted into a reader to be used, and contactless cards, which need not be inserted. In fact, microcontrollers with contactless communication are often embedded into specialized forms, such as watches and rings, effectively integrating the functionality of a smart card in an ergonomically attractive manner]. Dawson, Schwabe, and Wilkinson are all concerned with Java Virtual Machine (JVM) and software execution optimization and are therefore combinable/modifiable. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Dawson with the teachings of Schwabe to provide the integrated circuit that includes a processing circuitry. The motivation would be that placing both the memory and processing units on the same single chip makes the system more compact and significantly speeds up data processing by reducing access delays. As per claim 14, the claim is rejected using the same rationale as noted above for claim 13. Claim(s) 20, 22, and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Schwabe (US 7444631 B2) and Dawson (US 8813051 B2) and further in view of Yamada (US 9965620 B2). As per claim 20, the combination of Dawson and Schwabe discloses the claimed invention as detailed above for claim 18 above. The combination does not specifically teach the non-transitory computer-readable medium of claim 18, wherein the contents comprise instructions executable by the processing circuitry. Yamada teaches the non-transitory computer-readable medium of claim 18, wherein the contents comprise instructions executable by the processing circuitry [Col. 8:17-22, Processing circuitry 102′ may be configured to execute various instructions in device 100′. Instructions may include program code configured to cause processing circuitry 204 to perform activities related to reading data, writing data, processing data, formulating data, converting data, transforming data, etc. Information (e.g., instructions, data, etc.)] Dawson, Schwabe, and Yamada are all concerned with Java Virtual Machine (JVM) security and execution environments and are therefore combinable/modifiable. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Dawson and Schwabe with the teachings of Yamada to provide an integrated circuit with a processing circuitry to execute instructions. The motivation would be that it ensures stored instructions reliably control hardware, preventing execution errors and maintaining consistency across different devices As per claim 22, the combination of Dawson and Schwabe discloses the claimed invention as detailed above for claim 21 above. The combination does not specifically teach the system of claim 21, wherein the security circuitry executes the application of the scripting language in response to an authentication request associated with the data processing circuitry. Yamada teaches the system of claim 21, wherein the security circuitry executes the application of the scripting language in response to an authentication request associated with the data processing circuitry [Col. 5:39-49, Security circuitry 108 may include various resources that may be engaged to protect device 100 from being compromised by an attack from a hacker, malware etc. Example activities that may occur when security circuitry 108 is engaged include, but are not limited to, deactivating device 100, increasing security in device 100 (e.g., moving certain data to storage within memory circuitry 104, encrypting certain data, requiring password authentication, etc.), generating a visible, audible or tactile notification regarding the state of device 100, etc.]. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to modify the teachings of Dawson and Schwabe with the teachings of Yamada to have the system that is provided with secure chip authentication services. The motivation would be to enhances security by ensuring the scripting application only runs after the security hardware verifies a request from the data processor. As per claim 23, the combination of Dawson and Schwabe discloses the claimed invention as detailed above for claim 21 above. The combination does not explicitly teach the system of claim 21, comprising an embedded universal integrated circuit card including the security circuitry. Yamada teaches the system of claim 21, comprising an embedded universal integrated circuit card including the security circuitry [Device 100 may comprise, for example, processing circuitry 102, memory circuitry 104, BT circuitry 106 and security circuitry 108. An example implementation of circuitry 102 to 108, as well as other circuitry that may exist in device 100, is shown in FIG. 2]. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claim invention was made to modify the teachings of Dawson and Schwabe with the teachings of Yamada to have a circuit card that contain both processing circuitry and security circuitry that runs the security and authentication checks when executing an application. The motivation would be to improve secure-card integration by allowing the application to run in a protected hardware environment that tightly links security features with program control. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Cabillic (US 8381177 B2) teaches a way for “an instance of the object class 416 created in API 412 could be passed to the Java applications 410 or an instance of the filtered class 420 created in the Java applications 410 could be passed to the API 412” (Col. 6:30-33). Thunemann (US 20140317642 A1) teaches a way for program written in one scripting language to use functions, classes, modules, and other code written in another scripting language and treats those code elements like reuseable objects that can be passed around between language. Tatsubori (US 20110302557 A1) teaches a way for “a first programming language that is a dynamic scripting language, the program having property declarations of classes, on an execution system of a second programming language, the method including the steps of” (¶ 0013). Buzinov (US 20080163167 A1) teaches a way for “method may include executing a Java.RTM. object method invocation using an arbitrary scripting language” (¶ 0018). Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c). When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tien Tram whose telephone number is (571) 270-3050. The examiner can normally be reached Mon-Fri, 8:00a-4:00p. 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, Pierre M. Vital can be reached at (571)272-4215. 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. /TIEN THANH TRAM/Examiner, Art Unit 2198 /PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Read full office action

Prosecution Timeline

Feb 20, 2024
Application Filed
Jul 28, 2026
Non-Final Rejection mailed — §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month