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 .
Claim Objections
Claim 1 is objected to because of the following informalities: line 16-17 recites “rejecting the update of the first executable load file the first application identifier is identical”. Examiner suggests amending to “rejecting the update of the first executable load file if the first application identifier is identical”. 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-2 and 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Executable Load File Upgrade – Card Specification v2.3 – Amendment H – Version 1.1 (hereinafter referred to as Global Platform) in view of US 20120254859 A1 (hereinafter referred to as DiCarlo) and US 20180285089 A1 (hereinafter referred to as Khakpour).
Regarding claim 1, Global Platform teaches:
A computer-implemented method for updating multiple executable load files in a secure element (pg.8; Global Platform teaches the upgrade of multiple ELFs within the same ELF upgrade session), the computer-implemented method comprising:
- receiving at least one command for performing an update session of multiple executable load files (pg.11; Global Platform teaches if multiple ELFs must be upgraded within the same ELF upgrade session, the session shall start with multiple 'MANAGE ELF UPGRADE [start] commands), each executable load file being associated with a respective application identifier (pg.9; Global Platform teaches an Executable Load File is a java card package and each of these will be identified by an Application Identifier);
-checking whether the first executable load file is associated with a first application identifier identical to an application identifier of another executable load file for which an update is already ongoing in this update session (pg. 11; Global Platform teaches “the MANAGE ELF UPGRADE [start] command shall be rejected with an error and the ELF upgrade process shall be aborted if any of the following conditions is satisfied: -An ELF Upgrade is already going -The new ELF version is already present on the card; Once the ELF Upgrade session has been started (and until it is completed or aborted) the following rules shall apply: -Any unrelated operation involving an Application instance or ELF that is subject of the ELF Upgrade process shall be rejected; If multiple ELFs must be upgraded within the same ELF Upgrade session, the session shall start with multiple MANAGE ELF UPGRADE [start] commands, each one specifying an ELF that shall be upgraded. And the above checks shall be performed for each of these ELFS” pg. 18; Global Platform teaches “The following requirements apply to the new ELF version(s) (i.e. replacing the old one(s)): -Each new ELF version shall define at least the same Application modules as the old ELF version, with the exact same AIDs.” Examiner notes that although Global Platform does not implicitly state using the Application Identifier to check if update is ongoing for another ELF, it would be obvious to a person of ordinary skill in the art to utilize an ID for this function. Examiner also notes the citation above shows performing checks during an update session for multiple ELFs as they perform checks for each ELF);
Global Platform does not disclose:
(1) wherein the computer-implemented method further comprises, before starting an update of a first executable load file during the update session: maintaining, in a memory of the secure element, a list of application identifiers associated with executable load files already accepted for update during the update session:
(2) proceeding with the update of the first executable load file if the first application identifier is new in view of the application identifier of each executable load file in the list for which an update is already ongoing in this update session;
(2) or - rejecting the update of the first executable load file the first application identifier is identical to an application identifier of another executable load file in the list for which an update is already ongoing in the update session, wherein rejecting the update prevents the secure element from entering an inconsistent state during a waiting state during a loading phase of the update session, while maintaining the update session for each other executable load file of the update session.
However, in the analogous art of downloading software updates, DiCarlo teaches:
(1) wherein the computer-implemented method further comprises, before starting an update of a first executable load file during the update session: maintaining, in a memory of the secure element, a list of application identifiers associated with executable load files already accepted for update during the update session (Para. [34], DiCarlo shows "Download Taxi.TM. stores the download details for a given download ID. on the user computer 34, thus preventing the loss of the download cart if the user's session is interrupted or otherwise lost. The Sony.RTM. Download Taxi.TM. records the state of the download in a file under the folder C:\Sony Support. The file includes the following details: session ID; a list of files and their associated update ID in the given download; the time when the download process started; the name of the file which is currently being downloaded; the number of bytes that have been downloaded for the current file; and a list of files that have already been downloaded during the session. Before a file is downloaded, the Sony.RTM. Download Taxi.TM. uses the Update ID to check the status of a particular update on the update service center 38. If it is inactive, the Sony.RTM. Download Taxi.TM. skips the file." Examiner notes the citation above shows an update session involving multiple files, wherein each downloaded file is given an update ID and name and stored within a list inside a new file. Examiner also notes the citation above shows storing the file in memory, where when combined with Global Platform it becomes obvious to store the list within a secure element memory):
Additionally, in the analogous art of fragmented updating, Khakpour teaches:
(2) checking whether the first executable load file is associated with a first application identifier identical to an application identifier of another executable load file for which an update is already ongoing in this update session (Para. [30], Khakpour shows "The system controller 210 partitions the complete update into two or more fragments, wherein each fragment becomes a separate file that is a non-overlapping or partially overlapping subset of the complete file" Para. [37], Khakpour shows "One or more target identifiers can be associated with a particular update fragment as metadata" Para. [44], Khakpour shows "the system devices are configured with logic to reject duplicative fragments for fragments that have already been received or updates that have already been applied" Examiner notes the above citations show an update being split into multiple files representing updating multiple files and having a device configured with the logic to check if the update file has been applied and rejecting if so during the update session. Para. [10] within the applications specification provides support for the use of update fragments as ELF files are considered containers for one or more application’s executable code making them analogous to the update fragments shown above. It can be seen that the citation above shows this happening during an ongoing update session as the update session does not end until all update fragments have been downloaded and installed completing the update);
(2) proceeding with the update of the first executable load file if the first application identifier is new in view of the application identifier of each executable load file in the list for which an update is already ongoing in this update session (Para. [37], Khakpour shows "One or more target identifiers can be associated with a particular update fragment as metadata" Para. [44], Khakpour shows "the system devices are configured with logic to reject duplicative fragments for fragments that have already been received or updates that have already been applied" Examiner notes that the citation above implies that updates carry on as usual for the fragment file if the file is not redundant and it would be obvious to one of ordinary skill in the art to use the identifiers given to the update files to check if they are new.);
(2) or - rejecting the update of the first executable load file the first application identifier is identical to an application identifier of another executable load file in the list for which an update is already ongoing in the update session, wherein rejecting the update prevents the secure element from entering an inconsistent state during a waiting state during a loading phase of the update session, while maintaining the update session for each other executable load file of the update session (Para. [44], Khakpour shows "the system devices are configured with logic to reject duplicative fragments for fragments that have already been received or updates that have already been applied" Examiner notes the citation above shows rejecting the update if it is redundant. Examiner also notes the additional element, wherein rejecting prevents the secure element from entering an inconsistent state, since this element is an outcome of rejecting the update, it is not a step which occurs in the method, and it can be shown by the act of rejecting an update which prevents this inconsistent state).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of DiCarlo into the teachings of Global Platform to implement “wherein the computer-implemented method further comprises, before starting an update of a first executable load file during the update session: maintaining, in a memory of the secure element, a list of application identifiers associated with executable load files already accepted for update during the update session”. The modification would have been obvious as one of ordinary skill in the art would be motivated if the download aborts abnormally the user can resume where the download left off (DiCarlo, Para. [34]).
In addition, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Khakpour into the teachings of G to implement “proceeding with the update of the first executable load file if the first application identifier is new in view of the application identifier of each executable load file in the list for which an update is already ongoing in this update session; or - rejecting the update of the first executable load file the first application identifier is identical to an application identifier of another executable load file in the list for which an update is already ongoing in the update session, wherein rejecting the update prevents the secure element from entering an inconsistent state during a waiting state during a loading phase of the update session, while maintaining the update session for each other executable load file of the update session”. The modification would have been obvious as one of ordinary skill in the art would be motivated to prevent redundant downloading and installing of updated files and expediate the speed of the update by downloading only new files (Khakpour, Para. [44]).
Regarding claim 2, Global Platform as modified in claim 1 teaches:
wherein checking is performed upon receipt of said at least one command for performing the update session of multiple executable load files. (pg.11; Global Platform teaches if multiple ELFs must be upgraded within the same ELF upgrade session, the session shall start with multiple 'MANAGE ELF UPGRADE [start] commands' each one specifying an ELF that shall be upgraded, and the above checks shall be performed)
With regards to claim 3, Global Platform teaches claim 1 as modified above and teaches:
said checking being performed by comparing the application identifier of the executable load file to each application identifier in the list (pg.11; Global Platform teaches the MANAGE ELF UPGRADE [start] command shall be rejected with an error and the ELF upgrade process shall be aborted if any of the following conditions is satisfied: -An ELF Upgrade is already going; Once the ELF Upgrade session has been started (and until it is completed or aborted) the following rules shall apply: -Any unrelated operation involving an Application instance or ELF that is subject of the ELF Upgrade process shall be rejected. Examiner notes although Global Platform does not implicitly state using the Application Identifier to check if update is ongoing for another ELF, it would be obvious to a person of ordinary skill in the art to utilize an ID for this function).
Global platform does not explicitly disclose:
storing in a list of the memory the application identifier of an executable load file of the update session if its application identifier is new in view of the application identifier of each executable load file for which an update is already ongoing in this update session,
However, in the analogous art of software updating, DiCarlo teaches:
storing in a list of the memory the application identifier of an executable load file of the update session if its application identifier is new in view of the application identifier of each executable load file for which an update is already ongoing in this update session (Para. [34], DiCarlo shows "The file includes the following details: session ID; a list of files and their associated update ID in the given download; the time when the download process started; the name of the file which is currently being downloaded; the number of bytes that have been downloaded for the current file; and a list of files that have already been downloaded during the session. Before a file is downloaded, the Sony.RTM. Download Taxi.TM. uses the Update ID to check the status of a particular update on the update service center 38. If it is inactive, the Sony.RTM. Download Taxi.TM. skips the file." Examiner notes the citation above shows an update session involving multiple files, wherein each file is given an update ID and name. Also shown is maintaining a list of files that have been already downloaded in the update session),
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of DiCarlo into the teachings of Global Platform to implement “storing in a list of the memory the application identifier of an executable load file of the update session if its application identifier is new in view of the application identifier of each executable load file for which an update is already ongoing in this update session”. The modification would have been obvious as one of ordinary skill in the art would be motivated if the download aborts abnormally the user can resume where the download left off (DiCarlo, Para. [34]).
With regards to claims 4, Global Platform as modified teaches:
wherein checking is performed upon receipt of said at least one command for performing the update session of multiple executable load files. (pg.11; Global Platform teaches if multiple ELFs must be upgraded within the same ELF upgrade session, the session shall start with multiple 'MANAGE ELF UPGRADE [start] commands' each one specifying an ELF that shall be upgraded, and the above checks shall be performed)
With regards to claim 5, it is a system claim having similar limitations as cited in claim 1 above. Thus, claim 5 is also rejected under the same rationale as cited in the rejection of claim 1 above.
With regards to claim 6, it is a system claim having similar limitations as cited in claim 2 above. Thus, claim 6 is also rejected under the same rationale as cited in the rejection of claim 2 above.
With regards to claim 7, it is a system claim having similar limitations as cited in claim 3 above. Thus, claim 7 is also rejected under the same rationale as cited in the rejection of claim 3 above.
With regards to claim 8, it is a system claim having similar limitations as cited in claim 4 above. Thus, claim 8 is also rejected under the same rationale as cited in the rejection of claim 4 above.
Response to Arguments
Applicants’ arguments regarding 35 USC 101 filed 5/05/2026 have been fully considered and they are persuasive.
Applicants’ arguments regarding 35 USC 102 rejection of claims 1 and 4-5 filed 5/05/2026 have
been fully considered but they are not persuasive.
Applicant argues on Pg. 12, about Global Platform not disclosing the “checking" limitation. However, Khakpour teaches in Para. [30] "The system controller 210 partitions the complete update into two or more fragments, wherein each fragment becomes a separate file that is a non-overlapping or partially overlapping subset of the complete file" Para. [37], Khakpour shows "One or more target identifiers can be associated with a particular update fragment as metadata" Para. [44], Khakpour shows "the system devices are configured with logic to reject duplicative fragments for fragments that have already been received or updates that have already been applied". When combined with Global Platform it becomes obvious to one of ordinary skill in the art to check a file using its identifier to confirm if a file has been previously downloaded already during the update session.
Applicant argues on Pg. 12, Global Platform does not disclose the "maintaining" limitation which recites "maintaining, in a memory of the secure element, a list of application identifiers associated with executable load files already accepted for update during the update session." There is no disclosure in Global Platform of this requirement of claim 1. However, DiCarlo teaches Para. [34] “The file includes the following details: session ID; a list of files and their associated update ID in the given download; the time when the download process started; the name of the file which is currently being downloaded; the number of bytes that have been downloaded for the current file; and a list of files that have already been downloaded during the session. Before a file is downloaded, the Sony.RTM. Download Taxi.TM. uses the Update ID to check the status of a particular update on the update service center 38. If it is inactive, the Sony.RTM. Download Taxi.TM. skips the file." With Global Platform it becomes obvious to one of ordinary skill in the art to combine both references to store a list of files that have been updated with identifiers during the update session.
Applicant argues on Pg. 12, Global Platform does not disclose the "rejecting" limitation, which includes the requirement that "wherein rejecting the update prevents the secure element from entering an inconsistent state during a waiting state during a loading phase of the update session, while maintaining the update session for each other executable load file of the update session." There is no disclosure in Global Platform of this requirement of claim 1. However, Khakpour teaches in Para. [44], "the system devices are configured with logic to reject duplicative fragments for fragments that have already been received or updates that have already been applied" As mentioned above regarding the limitation of "wherein rejecting the update prevents the secure element from entering an inconsistent state during a waiting state during a loading phase of the update session, while maintaining the update session for each other executable load file of the update session." As this is an outcome of an action taken and not a direct action taken by the method it is not given weight and the rejection of an update to a file is taught by Khakpour as cited above.
Applicant argues on Pg 12, Global Platform also does not disclose that the recited limitations occur "before starting an update of a first executable load file during the update session." The Office Action relies on Global Platform's disclosure that an upgrade session will be rejected if an upgrade is already ongoing. However, this does not disclose the recited claims. The claims specifically recite updates to multiple executable load files "during the update session" and not in a separate, subsequent update sessions. Global Platform's teaching of rejecting an entirely new upgrade session when another upgrade is already in progress is different. There is no disclosure in Global Platform of this requirement of claim 1. However, Khakpour teaches in Para. [44], "the system devices are configured with logic to reject duplicative fragments for fragments that have already been received or updates that have already been applied" This rejection of update fragments occur in the middle of an update session and before the files themselves begin their individual updates, wherein they are determined to have been updated or not before beginning their update.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 10956241 B1 – This prior art teaches avoiding redundant configurations of programs on secure elements
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 ZEERICK A MALIK whose telephone number is (571)272-8110. The examiner can normally be reached Mon-Thurs, 7-5.
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, Chat Do can be reached at (571) 272-3721. 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.
/Z.A.M./Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights