DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This action is in response to the following communication: Non-provisional Application No. 18/578208 filed on 01/10/2024.
3. Claims 1-15 are cancelled.
Claims 16-30 are pending.
Claims 1, 27, 28 and 30 are independent claims.
Claim Objections
4. It is noted that Claim 20 recites alternative/optional use language:
Claim 20: Line 2 references “and/or…”
Appropriate corrections are required.
Claim Interpretation
5. It is noted that claim 30 recites intended use language.
Claim 30: “comprising instructions which, when the program is executed…”
Appropriate corrections are required.
Specification
6. The disclosure is objected to because of the following informalities: The disclosure consists of abbreviations which are not written out the first time they are used (e.g. UICC, SE, SD, AID, c.f.). Abbreviations must be written out the first time they are used in the disclosure, again in the abstract, and again in the claims, as the intent of their meaning is likely to be changed over time.
Appropriate correction is required. The specification should be revised carefully in order to comply with 35 U.S.C. 112(a). 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. Any amendment to the disclosure must be supported by the disclosure as originally filed.
Claim Rejections - 35 USC § 101
7. 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.
8. Claims 27 and 30 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory and/or abstract subject matter.
9. Claim 27 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter because claim 27 recites an “Application Protocol Data Unit, APDU, command …” that has been reasonably interpreted as a computer program, software, listing per se (see paragraph [032], of the specification). Claim 27 recite the “Application Protocol Data Unit, APDU, command …” which does not fall within at least one of the four categories of patent eligible subject matter recited in 35 U.S.C 101 (process, machine, manufacture, or composition of matter), e.g., since the claim is directed to software. Therefore, claim 27 is rejected as non-statutory – see MPEP 7.05.01.
10. Claim 30 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter because claim 30 recites a “computer program product …” that has been reasonably interpreted as a computer program, software, listing per se (see paragraph [0035], of the specification). Claim 30 recite the “computer program product …” which does not fall within at least one of the four categories of patent eligible subject matter recited in 35 U.S.C 101 (process, machine, manufacture, or composition of matter), e.g., since the claim is directed to software. Therefore, claim 30 is rejected as non-statutory – see MPEP 7.05.01.
Claim Interpretation
11. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
12. Claim 24 is rejected under 35 U.S.C. 112 (b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
Claim 24 recites the limitation " first component… second component " in line 2 of the claim. There is insufficient antecedent basis for this limitation in the claim
13. The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
14. The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Such claim limitation(s) is/are: “A device for upgrading an Executable Load File… a receiving unit” in claim 28 and dependent claim 29, “Application Protocol Data Unit”.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 102
15. 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.
16. Claims 16, 23, 25, 26, 28 and 30 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Globalplatform: "Executable Load File Upgrade Card Specification v2.3 -Amendment H", published March 2018 (hereinafter Globalplatform).
In regards to claim 16, Globalplatform teaches:
A method for upgrading an Executable Load File, ELF, on a Secure Element, SE, the method comprising: (p. 6, 1st para., see “this document defines an extension of the Global Platform Card Specification ([GPCS]) to facilitate the upgrade of Executable Load Files (ELFs) present in a Secure Element”) and (p. 11, 3.2.1, see “Upgrade Session Start”). Facilitate the upgrade is very much the same as upgrading.
receiving a request for upgrading an ELF (p. 11, 3.2.1, see “Upgrade Session Start, The ELF Upgrade Session starts upon receipt of a MANAGE ELF UPGRADE [start] command”). Such command is very much the same as a request by user to perform the upgrading.
the request comprising a first identifier, identifying a first ELF version loaded on the SE, a second identifier, identifying a second ELF version loaded on the SE, and an upgrade option (p. 8, 1.6, see “Revision History, Added new P1 option for MANAGE ELF UPGRADE command to forcefully start the Recovery Procedure when still in the Loading Phase”), (p. 11, 3.2.1, see “the command specifies a minimum version number and the version number of the old ELF version being upgraded… The new ELF version is already present on the card (i.e. with an AID other than the old ELF version… 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”), (p. 10, 3 “Executable Load File Upgrade, this chapter describes the Executable Load File Upgrade Process. The ELF being upgraded will be commonly referred to as the "old ELF version" and the ELF upgrading the old ELF version will be commonly referred to as the "new ELF version", saving phase… Each existing Application instance created from the old ELF version can save its instance data using the Upgrade API... Loading Phase... During this phase, the new ELF version is loaded… Loading the new ELF version before starting the ELF Upgrade Session..,. Optional capability of upgrading more than one ELF within the same ELF Upgrade Session”). Such “minimum version number and the version number of the old ELF version” is very much the same as such first identifier and second identifier.
determining dependencies of the first ELF version from other ELFs loaded on the SE (p. 11, 3.2.1, see, “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… Static dependencies exist that would prevent the old ELF version from being deleted (according to Java Card rules)”). Checks static dependencies of the old ELF version/first ELF version.
if dependencies have been determined, checking whether the upgrade request is allowed (p. 11, 3.2.1, see, “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… Static dependencies exist that would prevent the old ELF version from being deleted (according to Java Card rules)”). Checks static dependencies of the old ELF version/first ELF version.
if the update request is allowed: starting an upgrade session; replacing the first ELF version with the second ELF version (p. 10, 3 “Executable Load File Upgrade, Loading Phase... During this phase, the new ELF version is loaded. Before loading the new ELF version, library ELFs... previously imported by and left unused after the deletion of the old ELF version may be deleted/replaced... and new library ELFs may be loaded (e.g. a new library ELF imported by the new ELF version). After the new ELF version has been loaded, the Restore Phase can start. Restore Phase... New Application instances are automatically created from the new ELF version, in the same number and with the same AIDs as previously existing Application instances”). Note, if the same AIDs are previous instance are used then this is very much the same as replace first and second version.
linking the dependencies of the first ELF version to the second ELF version (p. 10, see “Restore Phase… each new Application instance is permitted to restore the instance data from the previous Application instance that had the same AID. The Registry data of the previous Application instance is also automatically restored and associated with the new Application instance”). Such instance data is very much the same as dependencies.
In regards to claim 23, Globalplatform teaches:
linking the dependencies of the first ELF version to the second ELF version comprises: for each other ELF on the SE, which has the first ELF version as a dependency, executing a re-linking process, to make the each other ELF de-pendent on the second ELF version (p. 18, 3.2.4.1, see “requirements for the New ELF Version(s)… Each new ELF version shall define at least the same Application modules as the old ELF version, with the exact same AIDs. New Executable Modules may also be present. The purpose of this requirement is to establish a link between old and new Application instances. Before proceeding, the OPEN shall check that all required module AIDs are defined in the new ELF version”) (emphasis added).
In regards to claim 25, Globalplatform teaches:
after linking the dependencies of the first ELF version to the second ELF version replacing the second identifier with the first identifier (p. 10, see “Restore Phase… each new Application instance is permitted to restore the instance data from the previous Application instance that had the same AID. The Registry data of the previous Application instance is also automatically restored and associated with the new Application instance… New Application instances are automatically created from the new ELF version, in the same number and with the same AIDs as previously existing Application instances”). Note, if the same AIDs are previous instance are used then this is very much the same as replace first and second version”). Such instance data is very much the same as dependencies.
In regards to claim 26, Globalplatform teaches:
deleting the first ELF version after replacing the first ELF version with the second ELF version (p. 10, 3 “Executable Load File Upgrade, Loading Phase... During this phase, the new ELF version is loaded. Before loading the new ELF version, library ELFs... previously imported by and left unused after the deletion of the old ELF version may be deleted/replaced... and new library ELFs may be loaded (e.g. a new library ELF imported by the new ELF version). After the new ELF version has been loaded, the Restore Phase can start. Restore Phase... New Application instances are automatically created from the new ELF version, in the same number and with the same AIDs as previously existing Application instances”). Note, if the same AIDs are previous instance are used then this is very much the same as replace first and second version.
In regards to claim 28, Globalplatform teaches:
A device for upgrading an Executable Load File, ELF, on a Secure Element, SE, the device comprising: (p. 6, 1st para., see “this document defines an extension of the Global Platform Card Specification ([GPCS]) to facilitate the upgrade of Executable Load Files (ELFs) present in a Secure Element”) and (p. 11, 3.2.1, see “Upgrade Session Start”). Facilitate the upgrade is very much the same as upgrading.
a receiving unit, configured to receive a request for upgrading an ELF (p. 11, 3.2.1, see “Upgrade Session Start, The ELF Upgrade Session starts upon receipt of a MANAGE ELF UPGRADE [start] command”). Such command is very much the same as a request by user to perform the upgrading.
the request comprising a first identifier, identifying a first ELF version loaded on the SE, a second identifier, identifying a second ELF version loaded on the SE, and an upgrade option; a processing unit, configured to (p. 8, 1.6, see “Revision History, Added new P1 option for MANAGE ELF UPGRADE command to forcefully start the Recovery Procedure when still in the Loading Phase”), (p. 11, 3.2.1, see “the command specifies a minimum version number and the version number of the old ELF version being upgraded… The new ELF version is already present on the card (i.e. with an AID other than the old ELF version… 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”), (p. 10, 3 “Executable Load File Upgrade, this chapter describes the Executable Load File Upgrade Process. The ELF being upgraded will be commonly referred to as the "old ELF version" and the ELF upgrading the old ELF version will be commonly referred to as the "new ELF version", saving phase… Each existing Application instance created from the old ELF version can save its instance data using the Upgrade API... Loading Phase... During this phase, the new ELF version is loaded… Loading the new ELF version before starting the ELF Upgrade Session..,. Optional capability of upgrading more than one ELF within the same ELF Upgrade Session”). Such “minimum version number and the version number of the old ELF version” is very much the same as such first identifier and second identifier.
access a memory of the SE and to determine dependencies of the first ELF version from other ELFs loaded in the memory (p. 11, 3.2.1, see, “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… Static dependencies exist that would prevent the old ELF version from being deleted (according to Java Card rules)”). Checks static dependencies of the old ELF version/first ELF version.
if dependencies have been determined, check whether the upgrade re-quest is allowed (p. 11, 3.2.1, see, “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… Static dependencies exist that would prevent the old ELF version from being deleted (according to Java Card rules)”). Checks static dependencies of the old ELF version/first ELF version.
if the update request is allowed, start an upgrade session, replace the first ELF version with the second ELF version (p. 10, 3 “Executable Load File Upgrade, Loading Phase... During this phase, the new ELF version is loaded. Before loading the new ELF version, library ELFs... previously imported by and left unused after the deletion of the old ELF version may be deleted/replaced... and new library ELFs may be loaded (e.g. a new library ELF imported by the new ELF version). After the new ELF version has been loaded, the Restore Phase can start. Restore Phase... New Application instances are automatically created from the new ELF version, in the same number and with the same AIDs as previously existing Application instances”). Note, if the same AIDs are previous instance are used then this is very much the same as replace first and second version.
link the dependencies of the first ELF version to the second ELF version (p. 10, see “restore Phase… each new Application instance is permitted to restore the instance data from the previous Application instance that had the same AID. The Registry data of the previous Application instance is also automatically restored and associated with the new Application instance”). Such instance data is very much the same as dependencies.
In regards to claim 30, Globalplatform teaches:
A computer program product, comprising instructions which, when the program is executed by a computer, cause the computer to perform: (p. 6, 1st para., see “this document defines an extension of the Global Platform Card Specification ([GPCS]) to facilitate the upgrade of Executable Load Files (ELFs) present in a Secure Element”) and (p. 11, 3.2.1, see “Upgrade Session Start”). Facilitate the upgrade is very much the same as upgrading.
receiving a request for upgrading an ELF(p. 11, 3.2.1, see “Upgrade Session Start, The ELF Upgrade Session starts upon receipt of a MANAGE ELF UPGRADE [start] command”). Such command is very much the same as a request by user to perform the upgrading.
the request comprising a first identifier, identifying a first ELF version loaded on a SE, a second identifier, identifying a second ELF version loaded on the SE, and an upgrade option (p. 8, 1.6, see “Revision History, Added new P1 option for MANAGE ELF UPGRADE command to forcefully start the Recovery Procedure when still in the Loading Phase”), (p. 11, 3.2.1, see “the command specifies a minimum version number and the version number of the old ELF version being upgraded… The new ELF version is already present on the card (i.e. with an AID other than the old ELF version… 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”), (p. 10, 3 “Executable Load File Upgrade, this chapter describes the Executable Load File Upgrade Process. The ELF being upgraded will be commonly referred to as the "old ELF version" and the ELF upgrading the old ELF version will be commonly referred to as the "new ELF version", saving phase… Each existing Application instance created from the old ELF version can save its instance data using the Upgrade API... Loading Phase... During this phase, the new ELF version is loaded… Loading the new ELF version before starting the ELF Upgrade Session..,. Optional capability of upgrading more than one ELF within the same ELF Upgrade Session”). Such “minimum version number and the version number of the old ELF version” is very much the same as such first identifier and second identifier.
determining dependencies of the first ELF version from other ELFs stored on the SE (p. 11, 3.2.1, see, “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… Static dependencies exist that would prevent the old ELF version from being deleted (according to Java Card rules)”). Checks static dependencies of the old ELF version/first ELF version.
if dependencies have been determined, checking whether the upgrade request is allowed; and if the update request is allowed, starting an upgrade session, replacing the first ELF version with the second ELF version (p. 10, 3 “Executable Load File Upgrade, Loading Phase... During this phase, the new ELF version is loaded. Before loading the new ELF version, library ELFs... previously imported by and left unused after the deletion of the old ELF version may be deleted/replaced... and new library ELFs may be loaded (e.g. a new library ELF imported by the new ELF version). After the new ELF version has been loaded, the Restore Phase can start. Restore Phase... New Application instances are automatically created from the new ELF version, in the same number and with the same AIDs as previously existing Application instances”). Note, if the same AIDs are previous instance are used then this is very much the same as replace first and second version.
linking the dependencies of the first ELF version to the second ELF version (p. 10, see “Restore Phase… each new Application instance is permitted to restore the instance data from the previous Application instance that had the same AID. The Registry data of the previous Application instance is also automatically restored and associated with the new Application instance”). Such instance data is very much the same as dependencies.
Claim Rejections - 35 USC § 103
17. 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 of this title, 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.
18. Claims 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Globalplatform in view of Johnson et al., U.S. Patent No. 6,330,709 (hereinafter Johnson).
In regards to claim 16, the rejections above are incorporated respectively.
In regards to claim 21, Globalplatform teaches:
a second component listing for the one ELF instances that are stored or addressed by other ELFs (p. 18, 3.2.4.1, see “requirements for the New ELF Version(s)… Each new ELF version shall define at least the same Application modules as the old ELF version, with the exact same AIDs. New Executable Modules may also be present. The purpose of this requirement is to establish a link between old and new Application instances. Before proceeding, the OPEN shall check that all required module AIDs are defined in the new ELF version”) (emphasis added).
Globalplatform doesn’t explicitly teach:
each one ELF loaded on the SE comprises a first component listing a set of other ELFs imported by classes in the one ELF.
However, Johnson teaches such use: (Abstracts, see “a Class Encapsulator object would preferably be created in a Persistent Container for each class of Java objects loaded into that Persistent Container”) and (column 13, lines 46-52, see “when an application calls a method on the Factory class requesting creation of a Java object, the Factory class calls a method on Persistent ClassLoader object 244 to determine whether the Java class corresponding to the requested object has already been loaded into a Class Encapsulator object in the Persistent Container object”).
the first component and the second component are persistently stored in a memory of the SE.
However, Johnson teaches such use: (Abstracts, see “a Class Encapsulator object would preferably be created in a Persistent Container for each class of Java objects loaded into that Persistent Container”) and (column 13, lines 46-52, see “when an application calls a method on the Factory class requesting creation of a Java object, the Factory class calls a method on Persistent ClassLoader object 244 to determine whether the Java class corresponding to the requested object has already been loaded into a Class Encapsulator object in the Persistent Container object”).
Globalplatform and Johnson are analogous art because they are from the same field of endeavor, software upgrade..
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Globalplatform and Johnson before him or her, to modify the system of Globalplatform to include the teachings of Johnson, as a system for shared persistent objects, and accordingly it would enhance the system of Globalplatform, which is focused on an executable load file upgrade, because that would provide Globalplatform with the ability to create shared persistent objects efficiently, as suggested by Johnson (Abstracts, column 26, lines 8-18).
In regards to claim 22, Globalplatform teaches:
determining dependencies of the first ELF version from other ELFs loaded on the SE is based on the information contained in the first component and the second component of the first ELF version (p. 10, see “Restore Phase… each new Application instance is permitted to restore the instance data from the previous Application instance that had the same AID. The Registry data of the previous Application instance is also automatically restored and associated with the new Application instance”). Such instance data is very much the same as dependencies.
18. Claims 17-20 and 27 is rejected under 35 U.S.C. 103 as being unpatentable over Globalplatform in view of Odivak et al., U.S. Patent No. 9,348,730 (hereinafter Odivak).
In regards to claim 16, the rejections above are incorporated respectively.
In regards to claim 17, Globalplatform doesn’t explicitly teach:
the upgrade option is a tag-length-value, TLV, field comprising a plurality of bits, one bit being reserved for indicating to the SE to perform a hot replacement, that is, to allow the upgrade session, if dependencies have been determined.
However, Odivak teaches such use: (Abstract, see “a system in which firmware residing in ROM may be upgraded without re-spinning silicon. A one-bit flag may be assigned for each patchable function representing a firmware upgrade. The first statement of each function may check its associated flag and determine if patch-code should be executed in place of the current function residing in ROM. If the flag is not set, the code may continue executing normally. If the flag is set, a function identifier may be placed into a global memory location, and an assembly language “jump” instruction may be executed, redirecting program control to a specified location in a volatile Scratch Read Only Memory (SROM) where the corresponding patched code may be stored”). Such one-bit flag is very much the same as a bit being reserved for indicating a hot replacement.
Globalplatform and Odivak are analogous art because they are from the same field of endeavor, software upgrade..
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Globalplatform and Odivak before him or her, to modify the system of Globalplatform to include the teachings of Odivak, as a system for firmware patches, and accordingly it would enhance the system of Globalplatform, which is focused on an executable load file upgrade, because that would provide Globalplatform with the ability to make patching any subroutine fairly straightforward, as suggested by Odivak (Abstract, column 10, lines 43-57).
In regards to claim 18, Globalplatform doesn’t explicitly teach:
checking whether the upgrade request is allowed comprises checking the value of the one bit being reserved for indicating a hot replacement to be equal to 1.
However, Odivak teaches such use: (Abstract, see “a system in which firmware residing in ROM may be upgraded without re-spinning silicon. A one-bit flag may be assigned for each patchable function representing a firmware upgrade. The first statement of each function may check its associated flag and determine if patch-code should be executed in place of the current function residing in ROM. If the flag is not set, the code may continue executing normally. If the flag is set, a function identifier may be placed into a global memory location, and an assembly language “jump” instruction may be executed, redirecting program control to a specified location in a volatile Scratch Read Only Memory (SROM) where the corresponding patched code may be stored”).
Globalplatform and Odivak are analogous art because they are from the same field of endeavor, software upgrade..
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Globalplatform and Odivak before him or her, to modify the system of Globalplatform to include the teachings of Odivak, as a system for firmware patches, and accordingly it would enhance the system of Globalplatform, which is focused on an executable load file upgrade, because that would provide Globalplatform with the ability to make patching any subroutine fairly straightforward, as suggested by Odivak (Abstract, column 10, lines 43-57).
In regards to claim 19, Globalplatform teaches:
checking whether the upgrade request is allowed comprises checking whether the second ELF version satisfies the dependencies of the first ELF version (p. 11, 3.2.1, see, “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… Static dependencies exist that would prevent the old ELF version from being deleted (according to Java Card rules)”). Checks static dependencies of the old ELF version/first ELF version.
In regards to claim 20, Globalplatform doesn’t explicitly teach:
if the value of the one bit being reserved for indicating a hot replacement is 1 and/or the second ELF version satisfies the dependencies of the first ELF version, then allowing the upgrade request, otherwise, rejecting the upgrade request.
However, Odivak teaches such use: (Abstract, see “a system in which firmware residing in ROM may be upgraded without re-spinning silicon. A one-bit flag may be assigned for each patchable function representing a firmware upgrade. The first statement of each function may check its associated flag and determine if patch-code should be executed in place of the current function residing in ROM. If the flag is not set, the code may continue executing normally. If the flag is set, a function identifier may be placed into a global memory location, and an assembly language “jump” instruction may be executed, redirecting program control to a specified location in a volatile Scratch Read Only Memory (SROM) where the corresponding patched code may be stored”).
Globalplatform and Odivak are analogous art because they are from the same field of endeavor, software upgrade..
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Globalplatform and Odivak before him or her, to modify the system of Globalplatform to include the teachings of Odivak, as a system for firmware patches, and accordingly it would enhance the system of Globalplatform, which is focused on an executable load file upgrade, because that would provide Globalplatform with the ability to make patching any subroutine fairly straightforward, as suggested by Odivak (Abstract, column 10, lines 43-57).
In regards to claim 27, Globalplatform teaches:
An Application Protocol Data Unit, APDU, command for upgrading an Executable Load File, ELF, on a Secure Element, SE, the command comprising an upgrade option (p. 22, see “APDU Commands, see this chapter describes the APDU commands that shall be supported by Security Domains to enable the ELF Upgrade Process”) and (p. 8, 1.6, see “Revision History, Added new P1 option for MANAGE ELF UPGRADE command to forcefully start the Recovery Procedure when still in the Loading Phase”) (emphasis added). Such APDU which enables an ELF upgrade process is very much the same as upgrading an Executable Load file.
Globalplatform doesn’t explicitly teach:
the upgrade option is a tag-length-value, TLV, field comprising a plurality of bits, one bit being reserved for indicating to the SE to perform a hot replacement.
However, Odivak teaches such use: (Abstract, see “a system in which firmware residing in ROM may be upgraded without re-spinning silicon. A one-bit flag may be assigned for each patchable function representing a firmware upgrade. The first statement of each function may check its associated flag and determine if patch-code should be executed in place of the current function residing in ROM. If the flag is not set, the code may continue executing normally. If the flag is set, a function identifier may be placed into a global memory location, and an assembly language “jump” instruction may be executed, redirecting program control to a specified location in a volatile Scratch Read Only Memory (SROM) where the corresponding patched code may be stored”). Such one-bit flag is very much the same as a bit being reserved for indicating a hot replacement.
Globalplatform and Odivak are analogous art because they are from the same field of endeavor, software upgrade..
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Globalplatform and Odivak before him or her, to modify the system of Globalplatform to include the teachings of Odivak, as a system for firmware patches, and accordingly it would enhance the system of Globalplatform, which is focused on an executable load file upgrade, because that would provide Globalplatform with the ability to make patching any subroutine fairly straightforward, as suggested by Odivak (Abstract, column 10, lines 43-57).
Allowable Subject Matter
20. Claims 24 and 29 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all the limitation of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: As per claim 24, prior art of record does not each and/or fairly suggest that “the re-linking process is executed using information contained in the first component and the second component of the first ELF version”. The art of record does not expressly disclose such features.
The following is a statement of reasons for the indication of allowable subject matter: As per claim 29, prior art of record does not each and/or fairly suggest that “the request is received through the APDU command according to an Application Protocol Data Unit, APDU, command for upgrading an Executable Load File, ELF, on a Secure Element, SE, the command comprising an upgrade option, wherein the upgrade option is a tag-length-value, TLV, field comprising a plurality of bits, one bit being reserved for indicating to the SE to perform a hot replacement, and wherein the device is further configured to perform a method of a method for upgrading an Executable Load File, ELF, on a Secure Element, SE, the method comprising: receiving a request for upgrading an ELF, the request comprising a first identifier, identifying a first ELF version loaded on the SE, a second identifier, identifying a second ELF version loaded on the SE, and an upgrade option; determining dependencies of the first ELF version from other ELFs loaded on the SE; if dependencies have been determined, checking whether the upgrade request is allowed; and if the update request is allowed: starting an upgrade session; replacing the first ELF version with the second ELF version; and linking the dependencies of the first ELF version to the second ELF version”. The art of record does not expressly disclose such features.
Conclusion
21. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent Application Publications
Sepe 20240289116 teaches a method for updating multiple executable load files in a secure element comprising: receiving at least one command for performing an update session of multiple executable load files, each executable load file associated with an application identifier.
Perez 20180293164 teaches automatic persistent memory management, an example system includes a non-volatile memory to allocate space as persistent data space and a processor executing a program to generate program data to be stored as persistent data in the persistent data space.
22. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Evral Bodden whose telephone number is 571-272-3455. The examiner can normally be reached on Monday to Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Cha Do, can be reached at telephone number 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 an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automatedinterview-request-air-form.
/EVRAL E BODDEN/Primary Examiner, Art Unit 2193