DETAILED ACTION
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 .
Receipt is acknowledged of amendments/arguments filed on 02/19/2026.
Claims 16 and 19-32 {including new claims 31-32} are presented for examination.
This application is a 371 of PCT/EP2023/025218 filed on 05/09/2023.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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) 16, 18-22, 24, 27-29 and 31-32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ali (US 2006/0041938) in view of Chapman et al. (US 2013/0086569).
Re Claim 16: Ali teaches method of supporting SSL/TLS protocols in a resource-constrained device, which includes a virtual machine {herein the ROM 1905 would also contain some type of operating system, e.g., a Java Virtual Machine} (¶ 214+); a non-volatile heap memory {herein the Heap Manager 201 is responsible for allocation, de-allocation, and compaction of memory blocks in the contiguous area of RAM heap 302, as well as NVM heap 311} which is arranged in a non-volatile memory and is configured for the persistent storage of objects (¶ 43+); and a volatile working memory {herein RAM 302} which is configured for non-persistent storage of data (¶ 83+); wherein a volatile heap memory 302 which is arranged in the volatile working memory and contains at least one volatile heap memory segment which is configured to keep objects stored at most only for a time-limited duration of a session of the volatile heap memory segment (¶ 83-89+), wherein the session is time-limited by a beginning {herein a starting point} and an end of the session so that an object on the volatile heap memory segment has a lifetime that is time-limited according to the time-limited duration of the session (¶ 89+, 112-115+).
Ali fails to specifically teach wherein the one or more objects each comprise an object header and one or more object data fields, the object header comprising information about data in the one or more object data fields, and wherein the volatile heap memory is configured to store both the object header and the object data fields of each of the one or more objects.
Chapman et al. teaches packed data objects, wherein the one or more objects each comprise an object header and one or more object data fields, the object header comprising information about data in the one or more object data fields (¶ 39+, 54+).
In view of Chapman et al.’s teachings, it would have been obvious to an artisan of ordinary skill in the before the effective filing date of the claimed invention to employ into the teachings of Ali that the one or more objects each comprise an object header and one or more object data fields, the object header comprising information about data in the one or more object data fields so as to determine a type of packed data object in a memory heap. Such modification would beneficial by enhancing compiler and provide support for multiple entries that identify all of the data for the object.
Re Claim 18: Ali as modified by Chapman et al. teaches a method, wherein the volatile heap memory is totally or partially configured as: clear-on-reset heap, wherein the end of the session is effected by resetting the secure element; and/or clear-on-deselect heap, wherein the end of the session is effected by deselecting an application of which one or more objects are stored in the volatile heap memory; and/or clear-on-session-deactivation heap, wherein the end of the session is effected by a command directed at the secure element to end a currently running session (¶ 181-186+).
Re Claim 19: Ali as modified by Chapman et al. teaches a method, wherein the beginning of the session is effected by one of the following actions: starting the secure element {herein initiate a secure HTTPS connection}; and/or selecting an application of which one or more objects are stored on the volatile heap memory; activating the or a volatile heap memory segment, activating the or a volatile heap memory segment by means of an application, by means of the operating system or by means of a different instance in or under the control of the secure element (¶ 38-39+, 184-189+).
Re Claims 20 and 28: Ali as modified by Chapman et al. teaches a method, wherein the volatile heap memory is segmented into at least two {herein segment A 1302 & segment B 1303}, or more, volatile heap memory segments, wherein at least some of the volatile heap memory segments have different time-limited durations of a session of the volatile heap memory segment and corresponding different lifetimes of objects on the respective volatile heap memory segment (¶ 151-152+).
Re Claim 21: Ali as modified by Chapman et al. teaches a method, wherein at least some of the volatile heap memory segments, or each volatile heap memory segment, is designed so that references to an object stored in the respective volatile heap memory segment can be stored only in the volatile heap memory segment in which the object itself is stored (151-152+).
Re Claim 22: Ali teaches a method, designed as a Java-card-based microprocessor device {herein Ali teaches the resource-constrained device 1801, e.g., a smart card has a central processing unit 1903} (¶ 214+).
Re Claim 24: Ali as modified by Chapman et al. teaches a method, wherein each volatile heap memory segment has a segment size, and wherein, for at least some or all of the volatile heap memory segments, the segment size can be modified {herein The header 1307 contains information about the size of the encrypted record payload 1305} during the lifetime of the heap memory segment (¶ 151-152+).
Re Claim 29: Ali as modified by Chapman et al. teaches a method, wherein the object is created on a volatile heap memory segment in one of the following ways: (a) direct creation on the volatile heap memory segment; (b) creation of the object on a memory other than the volatile heap memory segment, on the non-volatile heap memory, and subsequent copying of the object into the volatile heap memory segment (¶ 45-65+).
Re Claim 31: Ali as modified by Chapman et al. teaches a method, wherein the one or more objects are Java Card objects (¶ 214+).
Re Claim 32: Ali as modified by Chapman et al. teaches a method, wherein the information of a respective object header of a respective object is configured to be interpreted by the virtual machine such that the data in the one or more respective data fields of the respective object is processable by the virtual machine (¶ 214+).
Claim(s) 23, 25-26 and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ali (US 2006/0041938) as modified by Chapman et al. (US 2013/0086569) as applied to claim 16 above, and further in view of Bacca (EP 2535832 A1).
The teachings of Ali have been modified above. Ali further teaches a smart card has two types of memory areas that can be written to: a faster but very scarce RAM area 300, and a more abundant but much slower NVM (non-volatile memory) area 310 (see ¶ 83+, 155+).
Ali fails to specifically teach designed as a payment transaction card or virtual payment transaction card, or as a subscriber identity module or as an identity document module or as a health card.
Bacca teaches a method for operating a virtual machine over a file system, designed as a payment transaction card or virtual payment transaction card, or as a subscriber identity module or as an identity document module {herein interpreted as a user-ID, wherein upon each transaction, said transaction is given a transaction identifier} or as a health card (see pages 3-5, 10+ of Bacca).
In view of Bacca’s teachings, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to employ into the teachings of Ali a payment transaction card or virtual payment transaction card, or as a subscriber identity module or as an identity document module or as a health card so as to provide a memory to store membership requests, health data and other information. Such modification would be beneficial wherein crypto-processors comprise smartcards used for example in financial transactions, restricted access, and/or secure communication equipment.
Re Claims 25-26 and 30: The teachings of Ali have been discussed above. Ali also teaches a header 1307 (¶ 152+).
Ali fails to specifically teach an object which is stored on the volatile heap memory and comprises an object header and object data fields which are stored in the volatile heap memory, and a transient object which comprises an object header which is stored in the non-volatile heap memory.
Bacca teaches a method for operating a virtual machine over a file system, wherein an object which is stored on the volatile heap memory and comprises an object header and object data fields which are stored in the volatile heap memory, and a transient object which comprises an object header which is stored in the non-volatile heap memory (see pages 13-14 of Bacca).
In view of Bacca’s teachings, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made to employ into the teachings of Ali an object which is stored on the volatile heap memory and comprises an object header and object data fields which are stored in the volatile heap memory, and a transient object which comprises an object header which is stored in the non-volatile heap memory so as to maintain states that shall be preserved across applet selections.
Response to Arguments
Applicant’s arguments with respect to claim(s) 16 and 19-32 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Barrs et al. (US 2007/0016628) teaches classification system for versionable objects.
Rankl (EP 1675008 B1) teaches management of data objects on non-volatile rewritable memory.
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 EDWYN LABAZE whose telephone number is (571)272-2395. The examiner can normally be reached 8:30AM-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, Mr. STEVE PAIK can be reached at 571-272-2404. 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.
/EDWYN LABAZE/Primary Examiner, Art Unit 2876