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 office action is in response to the application filed on 6/18/2024. Claims 1-
14 are pending in this application. Claims 1 and 13 are independent claims.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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.
Claim 1 is rejected because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because the claim recites “a secure element” in the preamble with no underlying hardware which is considered software per se.
Claim 14 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because the claim is directed to a computer program which can be classified as software per se as there is no corresponding structure recited in the claim. Examiner has evaluated the claims for the mental process in the interest of compact prosecution.
Claims 1-14 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Regarding claim 1, the limitations “ to engage a free bytecode in a bytecode range that is unused according to the programming language specification as a user-defined bytecode” as drafted, is a function that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. This limitation encompasses a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. For example , the “engaging” limitation can be interpreted to mean assigning, or labeling , and can be accomplished by looking at the programming language specification, and using a pen and paper to label bytecode addresses that are not reserved as user-defined bytecode. The bytecodes being defined in the programming specification means that the number of bytecodes is fixed, which further supports that the assigning can reasonably be carried out in the human mind or by a human using a pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, the judicial exception is not integrated into a practical application. The additional element , “ to provide an allocation table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode, according to the context of the use of the user-defined bytecode”, does nothing more than add insignificant extra solution activity to the judicial exception of mere data gathering and outputting. Accordingly, the additional element does not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05 (g).
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As stated above in prong 2, the additional element, “to provide an allocation table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode, according to the context of the use of the user-defined bytecode” is merely gathering data which the courts have identified as well-understood, routine conventional activity. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Regarding claim 2, the limitation “the user-defined bytecode being labelled as optimized bytecode due to the memory space saving” recites additional mental process under Prong 1. The additional elements ,”the unused bytecode range being a hexadecimal value range between 0xCA and 0xFF” ,“and/or the secure element being a Java Card; and/or the runtime environment being a Java runtime environment; and/or the programming language specification being a Java specification” , can be classified as field of use and technical environment as they simply link the abstract idea to aspects of Java which does not integrate the abstract idea into a practical application under Prong 2, nor amount to significantly more under step 2B. See MPEP 2106.05(h).
Claim 3 recites additional element, “wherein the context is defined by virtue of the bytecode being in an operating system of the secure element or in an applet loaded on the secure element”, can be classified as field of use and technical environment as it simply links the abstract idea to aspects of Java which does not integrate the abstract idea into a practical application under Prong 2, nor amount to significantly more under step 2B. See MPEP 2106.05(h).
Regarding claim 4, the limitation “wherein the context [] is determined by the type of a method that the bytecode is in, the method being an instance method, a constructor or a static method.” recites additional mental process under Prong 1. The additional element , ”wherein the context comprises a package that contains the bytecode, and/or comprises a class to which the bytecode belongs” , can be classified as field of use and technical environment as they simply link the abstract idea to general software concepts which does not integrate the abstract idea into a practical application under Prong 2, nor amount to significantly more under step 2B. See MPEP 2106.05(h).
Regarding claim 5, the limitation “configured to use the allocation table to identify different contexts, including i) the operating system of the secure element, and/or ii) the applet, and/or iii) the package, and/or iv) the class and/or the type of the method, which permits a specific interpretation and implementation of the bytecode” , recites additional mental process under Prong 1.
Claim 6 recites the limitation “configured to carry out combined storage of the allocation table on the secure element, regardless of whether the actual storage location is in the memory area of the context, in order to permit faster access to bytecodes” , can be classified as mere data gathering and outputting which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided in the rejection of claim 1.
Claim 7 recites the limitation ”configured to provide a separate allocation table for each applet, given multiple applets, to improve memory use and to prevent incompatible combinations of the operating system and applets” ,which can be classified as mere data gathering and outputting which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided in the rejection of claim 1.
Regarding claim 8, the limitations, “wherein the allocation table comprises difference tables in order to improve storage efficiency, changes in the bytecode assignments being detected relative to a master allocation table, and “and/or the master allocation table is a fundamental table that comprises a set of user-defined bytecode assignments that is valid for different contexts,” can be classified as field of use and technical environment as they simply link the abstract idea to a particular data structure which does not integrate the abstract idea into a practical application under Prong 2, nor amount to significantly more under step 2B. See MPEP 2106.05(h).The additional element,” a difference table is designed to replace the user-defined bytecode for a subordinate context of the master allocation table with a bytecode that affords a greater memory space saving in the respective context”, can be classified as mere data gathering and outputting which does not integrate the judicial exception into a practical application under Prong 2, or amounts to significantly more under Step 2B for the reasons provided in the rejection of claim 1.
Regarding claim 9, the limitation, “wherein the difference table is in the form of a dense array, the dense array defining a first bytecode value and a last bytecode value, which is overwritten with regard to the next highest context, bytecode values in between likewise being overwritten”, can be classified as field of use and technical environment as they simply link the abstract idea to a particular data structure to which does not integrate the abstract idea into a practical application under Prong 2, nor amount to significantly more under step 2B. See MPEP 2106.05(h).
Regarding claim 10, the limitation, “wherein the dense array comprises elements that each have 1-byte indices that refer to a field in which the data for the user-defined bytecodes are stored, which implements an efficient redirection mechanism”, can be classified as field of use and technical environment as they simply link the abstract idea to a particular data structure to which does not integrate the abstract idea into a practical application under Prong 2, nor amount to significantly more under step 2B. See MPEP 2106.05(h).
Regarding claim 11, the limitation, “configured to use a prioritized assignment process, wherein, for a given context, the respective difference table for the bytecode assignment is first checked and, if no specific assignment is found, the master assignment table is used, which ensures an improved memory space saving within a context” ,recites additional mental process under Prong 1.
Regarding claim 12, the limitations, “comprising a Java Card operating system or a native operating system, the secure element being configured as a secure element module or as a chip card or as a smartcard or as a secure element module implemented in a housing having a different design than a secure element”, and “wherein the programming language being MULTOS Executable Language (MEL) or .NET Common Intermediate Language (CIL)”, can be classified as field of use and technical environment as they simply link the abstract idea to a particular operating system, programming language and hardware, which does not integrate the abstract idea into a practical application under Prong 2, nor amount to significantly more under step 2B. See MPEP 2106.05(h).
Regarding claims 13 and 14, the limitations recited in the claim are similar to that of claim 1 and thus are rejected for similar reasons as stated in the rejection of claim 1.
Claim Rejections - 35 USC § 112
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.
Claim 1, recites the limitations ”the programming language specification" in the third line of the claim and “the context" in the second to last line of the claim. There is insufficient antecedent basis for these limitations in the claim.
Claims 3,4 and 6 recites the limitation "the context" in the claims. There is insufficient antecedent basis for this limitation in the claim. These claims depend on claim 1 and “the context” in the claims is in reference to “the context” in claim 1, thus the objection may be overcome by amending claim 1.
Claim 13, recites the limitation "the context" in the second to last line of the claim. There is insufficient antecedent basis for this limitation in the claim.
Claims 9,10 and 11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. These claims reference limitations such as “the difference table” in claims 9 and 11 , and a dense array in claims 9 and 10. However, these claims depend on claim 1 which does not have the aforementioned limitations. It is unclear if these claims should depend on claim 8 or another claim.
Claim 14, is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The claim states “the method as claimed in claim 1”, however claim 1 is not a method claim. It is unclear if the claim should depend on claim 13 .
In addition, claims 2-12 are further rejected for depending on rejected claim 1, as the claims fail to cure the deficiency of their parent claim.
Allowable Subject Matter
Claims 9 and 11 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, and the rejection(s) under 35 U.S.C. 101 , set forth in this office action and to include all of the limitations of the base claim and any intervening claims.
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.
Claims 1, 3-8, 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Clausen et. al (Java Bytecode Compression for Low-End Embedded Systems, Published May, 2000) hereafter Clausen, in view of Zilli et. al (On the Dictionary Compression for Java Card Environment, Published 2013) hereafter Zilli.
Regarding claim 1, Clausen teaches: A secure element, that is configured to execute bytecode in a runtime environment and/or an applet, wherein the secure element is configured:([2.1, Par 2] “Java programs are transferred to JavaCard systems in units of packages, each package implementing either a set of applets or a library. The process of transferring a Java package to a JavaCard system is illustrated in Figure 1. First, a set of Java class files that make out a package is converted into a single CAP (converted applet) file and an export file describing the package interface….The CAP file is transferred onto the JavaCard device, which is then free to convert it into whatever internal representation is used for execution.“ [2.1, Par 3] “According to the experiments with stripped CAP files reported in Section 6, the bytecode takes up most of the memory footprint. We thus concentrate on reducing the size of the bytecode.”) The JavaCard device corresponds to a secure element. The JavaCard device is loaded with CAP files which store applets as bytecode which are converted for execution, which corresponds to, a secure element, that is configured to execute bytecode in a runtime environment and/or an applet.
to engage a free bytecode in a bytecode range that is unused according to the programming language specification as a user-defined bytecode; and([2.3, Par 4] “Our alternative is to extend the virtual machine to read new instruction definitions from the CAP file. These macro instruction definitions consist of bytecode instructions, and replace common instruction sequences in the code. Any instruction not in the standard instruction set is assumed to be a programmable instruction, defined by a table specific to the program being interpreted. “[4.2, Par 2] “The number of unused instructions in the instruction set determines the possible number of new macro instructions. The number of unused instructions depends on the Java platform used; it ranges from 52 to 152 free instructions (the various JavaCard instruction sets will be discussed in Section 6.1).”)The respective instruction set for the Java platform used defines all available bytecodes based on the Java version, which corresponds to a programming language specification. Programmable instructions which are the unused bytecodes allow users to define custom behavior for the bytecodes and therefore corresponds to user-defined bytecode. Thus, defining bytecodes that are not used in a table as programmable instructions, based on the Java platform instruction set, corresponds to, to engage a free bytecode in a bytecode range that is unused according to the programming language specification as a user-defined bytecode
[]according to the context of the use of the user-defined bytecode.([2.3, Par 4] “Any instruction not in the standard instruction set is assumed to be a programmable instruction, defined by a table specific to the program being interpreted”) The table of macros is generated based on the sequences of bytecodes from applets/programs stored by the CAP file and is specific to the program being interpreted, which corresponds to, according to the context of the use of the user-defined bytecode. This is consistent with the applicant’s definition of the context, which may be defined by the bytecode being in an applet at [Specification, 56].
Clausen does not explicitly detail the decoding of the macro table teaching: to provide an allocation table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode.
However, Zilli teaches: to provide an allocation table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode.([1, Par 3-4] “Dictionary compression for smart cards is the most suitable compression technique, since it does not need large amount of resources in the decompression phase. This technique consists in substituting repeated sequences with new macros. The compression phase consists of the search of repeated patterns later stored in a dictionary and their substitution with macros. These macros are afterwards decoded in the decompression phase looking them up into the dictionary, from where the code can be directly executed without any need of additional translation phase. Clausen et al. [4] have used dictionary compression and showed that a space savings up to 15% is reachable. A repeated sequence of Java bytecodes is substituted with a new bytecode. In the decoding phase the Java virtual machine translates the new bytecode looking up into a dictionary stored in an additional CAP file custom component [2]. The extension of the virtual machine with new bytecodes does not conflict with the standard. Some bytecodes are not utilized in Java Card specification [9] and thus they can be used for the extension. This paper investigates two new techniques derived from the base dictionary one.”) The decompression dictionary stores macros which are sequences of bytecode from the original application (standard bytecode). During compression these sequences are replaced in the original application with the undefined bytecodes (macro instructions). During decoding the dictionary is used to replace the macros in the original code with the sequence stored in the dictionary, which corresponds to, to provide an allocation table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Clausen with, to provide an allocation table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode, as taught by Zilli in order to improve the method of Clausen with space saving dictionary compression techniques, as Zilli is built on the teachings of Clausen evidenced above and at [Zilli 5,Par 1-3]
Regarding claim 3, Clausen and Zilli teach the method of claim 1 above. Clausen further teaches :wherein the context is defined by virtue of the bytecode being in an operating system of the secure element or in an applet loaded on the secure element
([2.3, Par 4] “Any instruction not in the standard instruction set is assumed to be a programmable instruction, defined by a table specific to the program being interpreted”) Clausen generates a table of macros based on the sequences of bytecodes from applets/programs stored by the CAP file and is specific to the program being interpreted, which corresponds to, according to the context of the use of the user-defined bytecode. This is consistent with the applicant’s definition of the context, which may be defined by the bytecode being in an applet at [Specification, 56].
Regarding claim 4, Clausen and Zilli teach the method of claim 1 above. Clausen further teaches: wherein the context comprises a package that contains the bytecode, and/or comprises a class to which the bytecode belongs, and/or is determined by the type of a method that the bytecode is in, the method being an instance method, a constructor or a static method.([8, Par 2]” Inspired by the strong separation between packages in the JavaCard 2.1 specification, we are currently investigating the option of having package-local macro tables. This has several advantages, chiefly that dynamically loaded packages can be prefactorized using a private set of macros ranging over all free instructions.”)
Clausen provides motivation for package-local macro tables, which would generate the macro tables based on each package rather than each applet. The source of the bytecode for conversion into sequences stored by the macro table corresponds to the context. Thus, generating the tables as package-local rather than applet specific corresponds to, wherein the context comprises a package that contains the bytecode [].
Regarding claim 5, Clausen and Zilli teach the method of claim 1 above. Clausen further teaches: The secure element as claimed in claim 1, configured to use the allocation table to identify different contexts, including i) the operating system of the secure element, and/or ii) the applet, and/or iii) the package, and/or iv) the class and/or the type of the method, which permits a specific interpretation and implementation of the bytecode.( ([5.3] “We assume that the virtual machine uses the CAP file format as its in-memory format, and therefore does not resolve constants before execution, which implies that the factorization algorithm does not need to resolve constants either. For this mechanism to work correctly, the virtual machine must keep track of the current package. Given that the virtual machine implicitly keeps track of the current class, and that the package of a class can be trivially found from the class itself, this requirement does not impose any significant overhead.”) See Appendix , Cap file structure. The CAP file stores the references for applets , classes and packages referenced by the virtual machine as well as the CAP file custom component storing the macro table. The virtual machine is able to get the package from the class which is stored in the CAP file , which corresponds to, the secure element as claimed in claim 1, configured to use the allocation table to identify different contexts, including [], and/or ii) the applet, and/or iii) the package, and/or iv) the class ,which permits a specific interpretation and implementation of the bytecode.
Regarding claim 6, Clausen and Zilli teach the method of claim 1 above. Clausen further teaches : The secure element as claimed in claim 1, configured to carry out combined storage of the allocation table on the secure element, regardless of whether the actual storage location is in the memory area of the context, in order to permit faster access to bytecodes.([2.1, par 2] “Java programs are transferred to JavaCard systems in units of packages, each package implementing either a set of applets or a library. The process of transferring a Java package to a JavaCard system is illustrated in Figure 1. First, a set of Java class files that make out a package is converted into a single CAP (converted applet) file and an export file describing the package interface…. The CAP file is transferred onto the JavaCard device, which is then free to convert it into whatever internal representation is used for execution."[Appendix]” In addition, we use the CAP file custom component mechanism to store the macro table generated by the factorization algorithm in its own component. “) The JavaCard stores the mapping table as a CAP file custom component on the Java card itself , which is a shared storage of the CAP file, which corresponds to, configured to carry out combined storage of the allocation table on the secure element, regardless of whether the actual storage location is in the memory area of the context.
Regarding claim 7, Clausen and Zilli teach the method of claim 1 above. Clausen does not explicitly teach : configured to provide a separate allocation table for each applet, given multiple applets, to improve memory use and to prevent incompatible combinations of the operating system and applets.
However, Zilli teaches: configured to provide a separate allocation table for each applet, given multiple applets, to improve memory use and to prevent incompatible combinations of the operating system and applets.([1, Par 2] ”Applications are distributed in the Java Card converted applet (CAP) file format” [4, Par 2]” For analyzing the developed techniques we used a set of four industrial banking applications. … code is written fully using Java Card language potential. In the following sections we analyze first of all the behavior of the compaction methods with a dynamic dictionary that can be stored into an additional CAP file component, and then with a static dictionary.[4.3, Par 1]“All previous results are achieved by means of dynamic dictionaries meaning that each application is associated to a dedicated dictionary.”) In the testing phase, each banking application/applet has a dedicated dynamic dictionary which corresponds to, configured to provide a separate allocation table for each applet, given multiple applets, to improve memory use and to prevent incompatible combinations of the operating system and applets.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Clausen with, configured to provide a separate allocation table for each applet, given multiple applets, to improve memory use and to prevent incompatible combinations of the operating system and applets, as taught by Zilli in order to apply well known techniques for dictionary compression that build on Clausen’s method. Evidenced by Zilli, [1, Par 4-5]”Clausen et al. have used dictionary compression and showed that a space savings up to 15% is reachable. This paper investigates two new techniques derived from the base dictionary one…we will see that the base dictionary technique performs better with dynamic dictionary”
Regarding claim 8, Clausen and Zilli teaches the method of claim 1 above. Clausen does not explicitly teach: wherein the allocation table comprises difference tables in order to improve storage efficiency, changes in the bytecode assignments being detected relative to a master allocation table, and/or the master allocation table is a fundamental table that comprises a set of user-defined bytecode assignments that is valid for different contexts, and/or a difference table is designed to replace the user-defined bytecode for a subordinate context of the master allocation table with a bytecode that affords a greater memory space saving in the respective context.
However Zilli teaches: wherein the allocation table comprises difference tables in order to improve storage efficiency, changes in the bytecode assignments being detected relative to a master allocation table, and/or the master allocation table is a fundamental table that comprises a set of user-defined bytecode assignments that is valid for different contexts, and/or a difference table is designed to replace the user-defined bytecode for a subordinate context of the master allocation table with a bytecode that affords a greater memory space saving in the respective context. ([3.2, Par 1]“A solution to this problem is the substitution of the dynamic dictionary with a static one, internally stored into the virtual machine. Static dictionaries generally target a specific context. The building of the dictionary can not be based on a single application but on a set of applications. … This solution is less effective in terms of compression respect to a dynamic dictionary, since the dictionary has to be shared and therefore made more general.”)
The static dictionary holds macros based a set of applications. As stated in the rejection claim 1, the context corresponds to the data used in the generation of the macros table which are the application/applet bytecodes. Thus, the static dictionary built on a set of applications, corresponds to, [] and/or the master allocation table is a fundamental table that comprises a set of user-defined bytecode assignments that is valid for different contexts [].
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Clausen with, and/or the master allocation table is a fundamental table that comprises a set of user-defined bytecode assignments that is valid for different contexts, as taught by Zilli in order to eliminate the need for dynamically generating the macro table during execution, thereby saving resources
Regarding claim 13, it is a method claim having similar limitations cited in the rejection of claim 1. Thus claim 13 is also rejected under the same rationale as
cited in the rejection of claim 1 above.
Regarding claim 14, it is a computer program claim having similar limitations cited in the rejection of claim 1. Thus claim 14 is also rejected under the same rationale as
cited in the rejection of claim 1 above.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Clausen et. al (Java Bytecode Compression for Low-End Embedded Systems, Published May, 2000) hereafter Clausen, in view of Zilli et. al (On the Dictionary Compression for Java Card Environment, Published 2013) hereafter Zilli , and further in view of (EP 2662770 A1) hereafter Delfin.
Regarding claim 2, Clausen and Zilli teach the method of claim 1 above. Clausen Further teaches: wherein the programming language is Java, wherein : [] , wherein the user-defined bytecode being labelled as optimized bytecode due to the memory space saving; and/or the secure element being a Java Card; and/or the runtime environment being a Java runtime environment; and/or the programming language specification being a Java specification. ([2.1]” Throughout this paper, we will use the JavaCard 2.1 environment [Sun Microsystems, Inc. 1999b; 1999c; 1999d] as a reference, since it is the only documented, freely available low-end Java execution platform. ava programs are transferred to JavaCard systems in units of packages, each package implementing either a set of applets or a library.”) Java programs transferred to the JavaCard System which are JavaCards (smart-cards), corresponds to, wherein the programming language is Java [] the secure element being a Java Card; and/or the runtime environment being a Java runtime environment.
Clausen does not explicitly teach: the unused bytecode range being a hexadecimal value range between 0xCA and 0xFF
However, Delfin teaches: the unused bytecode range being a hexadecimal value range between 0xCA and 0xFF( [27] “For instance, the range [0xB9 - 0xFE] is not defined by Javacard standard. The optimizer means M3 may select a specific bytecode in the range [0xB9 - 0xFE] for replacing a pattern made of several bytecodes which are not in this range.”) The range of unused bytecodes for JavaCard are 0xB9 - 0xFE which encompasses 0xCA-0xFE. Furthermore, Clausen states that any unused bytecodes can be used as macros [2.3, par4], meaning that bits 0xB9-0xC9 may be omitted from the range based on user preference.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Clausen with, the unused bytecode range being a hexadecimal value range between 0xCA and 0xFF, as taught by Delfin in order to define the unused bytecode range for the JavaCard version used.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Clausen et. al (Java Bytecode Compression for Low-End Embedded Systems, Published May, 2000) hereafter Clausen, in view of Zilli et. al (On the Dictionary Compression for Java Card Environment, Published 2013) hereafter Zilli , and further in view of (US20060101229A1) hereafter Sazegari.
Regarding claim 10, Clausen and Zilli teach the method of claim 1 above. Clausen and Zilli do not teach: wherein the dense array comprises elements that each have 1-byte indices that refer to a field in which the data for the user-defined bytecodes are stored, which implements an efficient redirection mechanism.
However, Sazegari teaches : wherein the dense array comprises elements that each have 1-byte indices that refer to a field [] ([0038]“Referring to FIG. 3, each byte in the permute mask 26 designates one byte in either of the two registers 28 and 30 which is to be copied to a corresponding byte position in the result register 32. Thus, the lookup table is comprised of single-byte entries. In some cases, however, it is desirable to employ tables whose entries consist of multiple bytes. For instance, in the example described in connection with FIG. 1, an 8-bit index is used to retrieve a 32-bit entry from the color lookup table.”) The lookup table is comprised of single-byte entries, used to retrieve another entry such as the 32-bit entry of claim 1, which corresponds to, wherein the dense array comprises elements that each have 1-byte indices that refer to a field.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Clausen and Zilli with, wherein the dense array comprises elements that each have 1-byte indices that refer to a field [], in order to utilize the user defined bytecodes and corresponding sequences of bytecodes as taught by Clausen and Zilli, using an array structure that reduces the memory required to store the table.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Clausen et. al (Java Bytecode Compression for Low-End Embedded Systems, Published May, 2000) hereafter Clausen, in view of Zilli et. al (On the Dictionary Compression for Java Card Environment, Published 2013) hereafter Zilli , and further in view of Joffray et. al (US 20110239307 A1) hereafter Joffray.
Regarding claim 12, Clausen and Zilli teach the method of claim 1 above. Clausen further teaches: The secure element as claimed in claim 1, comprising a Java Card operating system or a native operating system,([2.1, Par 1]” Throughout this paper, we will use the JavaCard 2.1 environment [Sun Microsys-tems, Inc. 1999b; 1999c; 1999d] as a reference, since it is the only documented, freely available low-end Java execution platform.”) The JavaCard 2.1 environment corresponds to a Java Card operating system
the secure element being configured as a secure element module or as a chip card or as a smartcard or as a secure element module implemented in a housing having a different design than a secure element. As stated in the rejection of Claim 1, the secure element is implemented as a JavaCard which corresponds to, the secure element being configured as a [] smartcard [].
Clausen does not teach: wherein the programming language being MULTOS Executable Language (MEL) or .NET Common Intermediate Language (CIL).
However, Joffray teaches: wherein the programming language being MULTOS Executable Language (MEL) or .NET Common Intermediate Language (CIL).([0003-004] “The most widespread example of security token is probably the smart card…. Such security tokens are advantageous because they can be easily programmed by loading an applet into them (e.g. Java applet, .Net applet, etc.).”) Loading a .Net applet corresponds to, wherein the programming language being [] .NET Common Intermediate Language (CIL).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Clausen with, wherein the programming language being [] .NET Common Intermediate Language (CIL), in order to make the method of bytecode compression applicable to multiple types of application.
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
US20070169043A1 (Supporting Applets on A High End Platform): Discloses a method for converting bytecodes for execution in alternate platforms.
US9754104B2 (Method For Securing Java Bytecode): Discloses extending the instruction set using unused bytecodes for verification purposes.
US6779101B1 (Method And Apparatus For Processing Compressed VLIW Subinstruction Opcodes) : Discloses a method for shortening bytecodes.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE O'CONNOR EMANUEL whose telephone number is (571)272-8975. The examiner can normally be reached M-F 9:00 - 5:00 pm .
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.
/L.S.O./Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights