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
This is a reply to the application filed on 12/20/2024, in which, claims 16-30 are pending. Claims 16, 23, 26, 29, and 30 are independent.
When making claim amendments, the applicant is encouraged to consider the references in their entireties, including those portions that have not been cited by the examiner and their equivalents as they may most broadly and appropriately apply to any particular anticipated claim amendments.
Information Disclosure Statement
The information disclosure statement (IDS) submitted is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings filed on 12/20/2024 are accepted.
Specification
The disclosure filed on 12/20/2024 is accepted.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
2. Claims 29, 30 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
3. Based upon consideration of all the relevant factors with respect to the claim as a whole, claims 29, 30 are held to claim software per se, and is therefore rejected as non-statutory subject matter under 35 U.S.C. 101. The rationale for this finding is explained below:
Claim 29 is rejected under 35 U.S.C. 101 as directed to non-statutory subject matter of software, per se. The claims lack the necessary physical articles or objects to constitute a machine or manufacture within the meaning of 35 U.S.C. 101. In this case, applicant has claimed a "shared interface" in the preamble to the claim without reciting any hardware element in the body of the claim; this implies that Applicants are claiming a system of software, per se, lacking the hardware necessary to realize any of the underlying functionality. Therefore, claim 29 is directed to non-statutory subject matter as computer programs, per se.
Claim 30 is rejected under 35 U.S.C. 101 as directed to non-statutory subject matter of software, per se. The claims lack the necessary physical articles or objects to constitute a machine or manufacture within the meaning of 35 U.S.C. 101. In this case, applicant has claimed a "computer program product comprising a set of instructions" in the preamble to the claim without reciting any hardware element in the body of the claim; this implies that Applicants are claiming a system of software, per se, lacking the hardware necessary to realize any of the underlying functionality. Therefore, claim 30 is directed to non-statutory subject matter as computer programs, per se.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 30 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim references claim 16 without further limiting any of the elements of the referenced claim. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 16-30 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Yakkundi, Ashwin Arvind. "Security Implications of Memory Use on Java Card Platform." (2017) (hereinafter ‘Arvind’).
As regards claim 16, Arvind discloses: A method for implementing a context shared between a plurality of applets in a Java Card data carrier, the Java Card data carrier comprising a Java Card runtime environment (JCRE), and a storage device, wherein at least a first or server applet of the plurality of applets is installed in a first context in the storage device, wherein the method in regard to the server applet comprises: (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 25-26)
implementing a shared interface in order to permit a second or client applet to join the context of the server applet; (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the shareable interface to join a context)
receiving a request to join the context of the server applet from the client applet via the shared interface; and (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the server applet’s shareable interface for one or more client applets to request to join a context)
instructing the JCRE to integrate the client applet into the first context of the server applet. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., JCRE mechanism integrating the client applet into server applet context)
As regards claim 17, Arvind discloses the method according to claim 16, wherein the shared interface is implemented as a public interface that defines a set of methods that are shared between contexts, and in particular defines a join context method that allows other applets of the plurality of applets to request to join the context of the server applet, wherein the request to join the context of the server applet is received by way of the call to the join context method, which is parameterized with an applet object of the client applet. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the parameter passed as TRUE/FALSE)
As regards claim 18, Arvind discloses the method according to claim 16, further comprising, in regard to the server applet, implementing a security check to verify whether the request to join the context is admissible. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the parameter passed as TRUE/FALSE is checked to allow an applet for connection)
As regards claim 19, Arvind discloses the method according to claim 18, wherein the security check comprises a check to ascertain whether a client applet identifier corresponding to the applet object received by way of the call to the join context method is held in a list of admissible applet identifiers, AIDs. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the AID is checked)
As regards claim 20, Arvind discloses the method according to claim 16, wherein the server applet sends a share context notification to the JCRE in order to provide instructions to integrate the client applet into the server applet context. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31)
As regards claim 21, Arvind discloses the method according to claim 20, wherein the share context notification is implemented as a system API method that obtains the client applet as input and returns "TRUE" or a value of comparable significance if the request to join the context is admissible, and otherwise returns "FALSE" or a value of comparable significance. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the parameter passed as TRUE/FALSE is checked to allow an applet for connection)
As regards claim 22, Arvind discloses the method according to claim 16, further comprising erasing an instance of the shared interface after integration of the client applet into the context of the server applet. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the parameter causing the applet to be deselected)
As regards claim 23, Arvind discloses: A method for implementing a context shared between a plurality of applets in a Java Card data carrier, the Java Card data carrier comprising a Java Card runtime environment (JCRE), and a storage device, wherein at least a first or server applet of the plurality of applets is installed in a first context in the storage device, wherein the method in regard to a second or client applet of the plurality of applets comprises: (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 25-26) setting up a communication with the server applet via a shared interface that is provided by the server applet; and (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the shareable interface to join a context)
sending a request to join the first context of the server applet to the server applet. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the server applet’s shareable interface for one or more client applets to request to join a context)
As regards claim 24, Arvind discloses the method according to claim 23, wherein setup of the communication with the server applet is implemented by sending a join context notification to the JCRE, indicating the server applet whose context the client applet is joining, the join context notification being implemented as a call to a Java Card system method JCSystem.getAppletShareableInterfaceObject (AID serverAID). (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31)
As regards claim 25, Arvind discloses the method according to claim 23, wherein the client applet sends the request to join the context of the server applet by calling a method that the server applet provides via the shared interface. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31)
As regards claim 26, Arvind discloses: A method for implementing a context shared between a plurality of applets in a Java Card data carrier, the Java Card data carrier comprising a Java Card runtime environment (JCRE), and a storage device, wherein at least a first or server applet of the plurality of applets is installed in a first context in the storage device, wherein the method in regard to the JCRE comprises: (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 25-26)
receiving a join context notification from a second or client applet, which notification indicates an applet identifier, AID, of the server applet; (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the server applet’s shareable interface for one or more client applets to request to join a context)
receiving a share context notification from the server applet, wherein the share context notification indicates an AID of the client applet; and (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the AID is checked)
installing the client applet within the first context if the share context notification is "TRUE" or a value of comparable significance. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the parameter passed as TRUE/FALSE is checked to allow an applet for connection)
As regards claim 27, Arvind discloses the method according to claim 26, further comprising, if the received share context notification is "FALSE" or a value of comparable significance, installing the client applet in a context of its own. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the parameter passed as TRUE/FALSE is checked to allow an applet for connection)
As regards claim 28, Arvind discloses the method according to claim 26, wherein the join context notification of the second applet is received during installation of the second applet or later at the time of execution. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31)
As regards claim 29, Arvind discloses: A shared interface comprising a set of shared interface methods that a server applet renders accessible to a client applet of a plurality of applets that are loaded in a Java Card data carrier in order to implement a communication between applets, wherein the shared interface defines a method to be called by the client applet, the method being parameterized with an applet object of the client applet. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 25-31)
As regards claim 29, Arvind discloses: A computer program product comprising a set of instructions for performing the following steps: loading a first package, comprising a first applet, onto a Java Card data carrier, the Java Card data carrier comprising a Java Card runtime environment, JCRE, and a storage device; (Arvind: Figs. 2.1, 3.1, Listings, 3.1, 3.2., 3.3, pages 21-26)
loading the first applet in a first context in the storage device of the Java Card data carrier; (Arvind: Fig. 4.1, page 36)
loading a second package, comprising a second applet, on the Java Card data carrier; (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31; and Fig. 4.1, page 36)
performing the steps according to claim 16 in regard to the first applet; (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31)
performing the steps according to a method for the second applet including setting up a communication with the server applet via a shared interface that is provided by the server applet; and (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31)
sending a request to join the first context of the server applet to the server applet; and (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the server applet’s shareable interface for one or more client applets to request to join a context)
performing the steps according to a method for the JCRE including receiving a join context notification from a second or client applet, which notification indicates an applet identifier, AID, of the server applet; (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the AID is checked)
receiving a share context notification from the server applet, wherein the share context notification indicates an AID of the client applet; and (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the AID is checked)
installing the client applet within the first context if the share context notification is "TRUE" or a value of comparable significance. (Arvind: Fig. 3.1, Listings, 3.1, 3.2., 3.3, pages 26-31, i.e., the AID is checked)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED A ZAIDI whose telephone number is (571)270-5995. The examiner can normally be reached Monday-Thursday: 5:30AM-5:30PM.
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 Nickerson can be reached at (469) 295-9235. 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.
/SYED A ZAIDI/Primary Examiner, Art Unit 2432
Prosecution Insights