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
Office Action is in response to the instant Application 19/251,226 filed on 6/26/2025. Claims 1-20 are pending. This Office Action is Non-Final.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 6/26/2025 and 3/4/2026, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 11, 12 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over D’Auria et al. (US 2013/0332318) in view of Mantri (US 2023/0236815).
As per claim 1, D’Auria teaches an electronic device comprising: at least one host processor comprising processing circuitry; and a secure element (SE) electrically connected to the at least one host processor, wherein the SE comprises: at least one processor, comprising processing circuitry; and memory storing instructions (D’Auria, Paragraph 0051 recites “Referring to FIG. 15, a computing device suitable for use with the browser includes a processor 52 operatively connected to one or more forms of computer-readable storage media 54, e.g. RAM, ROM, flash memory, optical and/or magnetic disk drives, etc. The storage media can be integral with the computing device, attachable to the computing device, e.g. a flash drive, or accessible via a wired or wireless network.”),
wherein at least one processor, individually and/or collectively, is configured to execute the instructions and to cause the electronic device to: generate authentication data for the target applet in the applet and transmit the authentication data to the target applet and determine whether to provide a function of the target applet to the applet by verifying the authentication data in the target applet (D’Auria, Paragraph 0040-0041 recites “If the user may possibly be interested in the applet, tapping or clicking on an action button 26 switches its functionality, and its displayed label, to change. As illustrated in FIG. 6, the button 26 now provides the user the opportunity to obtain the applet. If the user taps the button in this state, to retrieve the applet, the user may be required to authenticate himself or herself to the online store, or other resource via which the applet is provided. FIG. 7 illustrates an example of a password entry screen with a keyboard, via which the user can input his or her password, an identifier, and/or any other information that may be required to access the resource. Once the user has been authenticated, the applet is installed on the user's device 10. Referring to FIG. 8, the label of the button 26 changes during this time, to indicate that installation is taking place.”).
But fails to teach transmit, to an operating system (OS) of the SE, a request for a target applet to be used by an applet; provide an instance to the applet in response to the request for the target applet.
However, in an analogous art Mantri teaches transmit, to an operating system (OS) of the SE, a request for a target applet to be used by an applet; provide an instance to the applet in response to the request for the target applet (Mantri, Paragraph 0010 recites “According to a first aspect of the present invention, there is provided a method for installing applet instances in a card device, the card device comprising an operating system, OS. The method comprises in a step receiving from an off-card entity a request for installing an instance of a first applet, the request for installing comprising a first applet identifier, AID. In a subsequent step, an applet instance with the first applet identifier is installed in a registry of the OS. In a further step, a request, sent from the off-card entity, for hiding the instance of the first applet identified by the first applet identifier is received at the card device. Subsequently, the applet instance identified by the first applet identifier is hidden on the card device.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Mantri’s hiding and unhiding java card applet instances with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of provide a solution for a time-efficient personalization of a Java Card and reducing execution time.
Regarding claims 11, 12 and 20, claims 11, 12 and 20 are directed to a device, a method and a non-transitory computer-readable medium associated with the system of claim 1. Claims 11, 12 and 20 are of similar scope to claim 1, and are therefore rejected under similar rationale.
Claim(s) 2-4, 6, 13, 14 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over D’Auria et al. (US 2013/0332318) and Mantri (US 2023/0236815) and in further view of Fort et al. (US 2011/0314290).
As per claim 2, D’Auria in combination with Mantri teaches the electronic device of claim 1, but fails to teach wherein at least one processor, individually or collectively, is configured to cause the electronic device to: generate the authentication data based on a first authentication value using a first authentication key in the applet and update the first authentication value with the authentication data.
However, in an analogous art Fort teaches wherein at least one processor, individually or collectively, is configured to cause the electronic device to: generate the authentication data based on a first authentication value using a first authentication key in the applet and update the first authentication value with the authentication data (Fort, Paragraph 0027 recites “ In some cases (such as in the first use of the applet), when the applet is used by a specific user, the user is asked to choose and enter a migration secret. The migration secret or a hash of the migration secret is securely transferred to the server. If, thereafter, the user attempts to access the server using a personal computer which does not store the authentication key in a cookie, the following events will unfold. On detecting this condition the authentication applet requests the user to enter the migration secret as well as a password. This will be referred to as a local password and it can be the same or different as the password used on the original PC. Using the migration secret the applet can then securely download an authentication key (either the same authentication key which is stored in the cookie on the user's normally used PC, or a different authentication key) from the server and then locally store the downloaded authentication key in a cookie on the PC, currently employed by the user [FCO: shouldn't we somehow mention that the authentication in the cookie on the new PC is protected by the password that the user entered along with the migration secret?]. ”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Fort’s digipass for web-functional description with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of providing greater security than of the userid-password but yet retains the major advantages of the userid-password.
As per claim 3, D’Auria in combination with Mantri teaches the electronic device of claim 1, but fails to teach wherein at least one processor, individually or collectively, is configured to: cause the electronic device to generate a message authentication code (MAC) value for the first authentication value with the first authentication key and determine the MAC value as the authentication data.
However, in an analogous art Fort teaches wherein at least one processor, individually or collectively, is configured to: cause the electronic device to generate a message authentication code (MAC) value for the first authentication value with the first authentication key and determine the MAC value as the authentication data (Fort, Paragraph 0039 recites “Alternatively, signing transaction data with a shared secret by generating a Message Authentication Code (MAC) is common practice. One example is described in the standard ANSI X9.9. An alternative includes the transaction data in the variable input for the authentication algorithm which was described above.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Fort’s digipass for web-functional description with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of providing greater security than of the userid-password but yet retains the major advantages of the userid-password.
As per claim 4, D’Auria in combination with Mantri teaches the electronic device of claim 1, but fails to teach wherein the applet comprises a first authentication key configured to be used to generate the authentication data, a first recovery key configured to be used to generate recovery data based on verification failing, and the first authentication value updated with the authentication data generated by the first authentication key.
However, in an analogous art Fort teaches wherein the applet comprises a first authentication key configured to be used to generate the authentication data, a first recovery key configured to be used to generate recovery data based on verification failing, and the first authentication value updated with the authentication data generated by the first authentication key (Fort, Paragraph 0027 recites “ In some cases (such as in the first use of the applet), when the applet is used by a specific user, the user is asked to choose and enter a migration secret. The migration secret or a hash of the migration secret is securely transferred to the server. If, thereafter, the user attempts to access the server using a personal computer which does not store the authentication key in a cookie, the following events will unfold. On detecting this condition the authentication applet requests the user to enter the migration secret as well as a password. This will be referred to as a local password and it can be the same or different as the password used on the original PC. Using the migration secret the applet can then securely download an authentication key (either the same authentication key which is stored in the cookie on the user's normally used PC, or a different authentication key) from the server and then locally store the downloaded authentication key in a cookie on the PC, currently employed by the user [FCO: shouldn't we somehow mention that the authentication in the cookie on the new PC is protected by the password that the user entered along with the migration secret?]. ”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Fort’s digipass for web-functional description with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of providing greater security than of the userid-password but yet retains the major advantages of the userid-password.
As per claim 6, D’Auria in combination with Mantri teaches the electronic device of claim 1, but fails to teach wherein at least one processor, individually or collectively, is configured to cause the electronic device to: verify the authentication data based on a second authentication key configured to verify the authentication data in the target applet and a second authentication value included in the target applet.
However, in an analogous art Fort teaches wherein at least one processor, individually or collectively, is configured to cause the electronic device to: verify the authentication data based on a second authentication key configured to verify the authentication data in the target applet and a second authentication value included in the target applet (Fort, Paragraph 0027 recites “ In some cases (such as in the first use of the applet), when the applet is used by a specific user, the user is asked to choose and enter a migration secret. The migration secret or a hash of the migration secret is securely transferred to the server. If, thereafter, the user attempts to access the server using a personal computer which does not store the authentication key in a cookie, the following events will unfold. On detecting this condition the authentication applet requests the user to enter the migration secret as well as a password. This will be referred to as a local password and it can be the same or different as the password used on the original PC. Using the migration secret the applet can then securely download an authentication key (either the same authentication key which is stored in the cookie on the user's normally used PC, or a different authentication key) from the server and then locally store the downloaded authentication key in a cookie on the PC, currently employed by the user [FCO: shouldn't we somehow mention that the authentication in the cookie on the new PC is protected by the password that the user entered along with the migration secret?]. ”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Fort’s digipass for web-functional description with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of providing greater security than of the userid-password but yet retains the major advantages of the userid-password.
Regarding claim 13, claim 13 is directed to a similar method associated with the system of claim 2 respectively. Claim 13 is similar in scope to claim 2, respectively, and are therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a similar method associated with the system of claim 4 respectively. Claim 14 is similar in scope to claim 4, respectively, and are therefore rejected under similar rationale.
Regarding claim 16, claim 16 is directed to a similar method associated with the system of claim 6 respectively. Claim 16 is similar in scope to claim 6, respectively, and are therefore rejected under similar rationale.
Claim(s) 5, 8-10, 15, 18 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over D’Auria et al. (US 2013/0332318) and Mantri (US 2023/0236815) and in further view of McCormack et al. (US 10,797,871).
As per claim 5, D’Auria in combination with Mantri teaches the electronic device of claim 1, but fails to teach wherein the target applet comprises a second authentication key configured to verify the authentication data, a second recovery key configured to verify the recovery data generated from the applet based on verification failing, and a second authentication value configured to be updated with the authentication data based on verification of the authentication data being successful.
However, in an analogous art McCormack teaches wherein the target applet comprises a second authentication key configured to verify the authentication data, a second recovery key configured to verify the recovery data generated from the applet based on verification failing, and a second authentication value configured to be updated with the authentication data based on verification of the authentication data being successful (McCormack, Col. 5 Lines 5-24 recites “As mentioned above, in some embodiments the user interface module 103 and the key generation module 104 can be packaged into an application that is installed on the computing device 102—also called a native application or “app”. The native application can be a software application is installed locally on the mobile device 102 and written with programmatic code designed to interact with an operating system that is native to the mobile device 102. Such software is available from, e.g., the Apple® App Store or the Google® Play Store. In some embodiments, the native application includes a software development kit (SDK) module that is executed by a processor of the mobile device 102 to perform functions associated with generating a cryptographic authentication key as described herein. The native application can be executed when the computing device 102 is online—that is, communicatively coupled to a network, such as the Internet—or offline. As is described later in the specification, the offline mode feature can provide a benefit to the security of the cryptographic authentication key generation and recovery process.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use McCormack’s Generation Of Cryptographic Authentication Keys Using A Defined Sequence Of Security Questions with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of providing better key security and recovery instances.
As per claim 8, D’Auria in combination with Mantri teaches the electronic device of claim 1, but fails to teach wherein at least one processor, individually or collectively, is configured to cause the electronic device to: based on verification failing, generate a specified value in the target applet and transmit the specified value to the applet, generate recovery data based on the specified value using a first recovery key in the applet, regenerate, in the applet, the authentication data from the specified value or the recovery data based on a first authentication key included in the applet, and transmit the regenerated authentication data and the recovery data to the target applet.
However, in an analogous art McCormack teaches wherein at least one processor, individually or collectively, is configured to cause the electronic device to: based on verification failing, generate a specified value in the target applet and transmit the specified value to the applet, generate recovery data based on the specified value using a first recovery key in the applet, regenerate, in the applet, the authentication data from the specified value or the recovery data based on a first authentication key included in the applet, and transmit the regenerated authentication data and the recovery data to the target applet (McCormack, Col. 5 Lines 5-24 recites “As mentioned above, in some embodiments the user interface module 103 and the key generation module 104 can be packaged into an application that is installed on the computing device 102—also called a native application or “app”. The native application can be a software application is installed locally on the mobile device 102 and written with programmatic code designed to interact with an operating system that is native to the mobile device 102. Such software is available from, e.g., the Apple® App Store or the Google® Play Store. In some embodiments, the native application includes a software development kit (SDK) module that is executed by a processor of the mobile device 102 to perform functions associated with generating a cryptographic authentication key as described herein. The native application can be executed when the computing device 102 is online—that is, communicatively coupled to a network, such as the Internet—or offline. As is described later in the specification, the offline mode feature can provide a benefit to the security of the cryptographic authentication key generation and recovery process.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use McCormack’s Generation Of Cryptographic Authentication Keys Using A Defined Sequence Of Security Questions with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of providing better key security and recovery instances.
As per claim 9, D’Auria in combination with Mantri teaches the electronic device of claim 1, but fails to teach wherein at least one processor, individually or collectively, is configured to cause the electronic device to: receive, from the target applet, the regenerated authentication data and the recovery data and determine whether to provide the function of the target applet to the applet through verification based on the recovery data in the target applet.
However, in an analogous art McCormack teaches wherein at least one processor, individually or collectively, is configured to cause the electronic device to: receive, from the target applet, the regenerated authentication data and the recovery data and determine whether to provide the function of the target applet to the applet through verification based on the recovery data in the target applet (McCormack, Col. 5 Lines 5-24 recites “As mentioned above, in some embodiments the user interface module 103 and the key generation module 104 can be packaged into an application that is installed on the computing device 102—also called a native application or “app”. The native application can be a software application is installed locally on the mobile device 102 and written with programmatic code designed to interact with an operating system that is native to the mobile device 102. Such software is available from, e.g., the Apple® App Store or the Google® Play Store. In some embodiments, the native application includes a software development kit (SDK) module that is executed by a processor of the mobile device 102 to perform functions associated with generating a cryptographic authentication key as described herein. The native application can be executed when the computing device 102 is online—that is, communicatively coupled to a network, such as the Internet—or offline. As is described later in the specification, the offline mode feature can provide a benefit to the security of the cryptographic authentication key generation and recovery process.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use McCormack’s Generation Of Cryptographic Authentication Keys Using A Defined Sequence Of Security Questions with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of providing better key security and recovery instances.
As per claim 10, D’Auria in combination with Mantri and McCormack teaches the electronic device of claim 1, McCormack further teaches wherein at least one processor, individually or collectively, is configured to cause the electronic device to: verify, in the target applet, the recovery data based on the specified value and the second recovery key configured to verify the recovery data, update, in the target applet, a second authentication value included in the target applet with the specified value or the recovery data based on verification of the recovery data being successful, and determine whether to provide the function of the target applet to the applet by verifying the regenerated authentication data with the second authentication key and the updated second authentication value.
However, in an analogous art McCormack teaches (McCormack, Col. 5 Lines 5-24 recites “As mentioned above, in some embodiments the user interface module 103 and the key generation module 104 can be packaged into an application that is installed on the computing device 102—also called a native application or “app”. The native application can be a software application is installed locally on the mobile device 102 and written with programmatic code designed to interact with an operating system that is native to the mobile device 102. Such software is available from, e.g., the Apple® App Store or the Google® Play Store. In some embodiments, the native application includes a software development kit (SDK) module that is executed by a processor of the mobile device 102 to perform functions associated with generating a cryptographic authentication key as described herein. The native application can be executed when the computing device 102 is online—that is, communicatively coupled to a network, such as the Internet—or offline. As is described later in the specification, the offline mode feature can provide a benefit to the security of the cryptographic authentication key generation and recovery process.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use McCormack’s Generation Of Cryptographic Authentication Keys Using A Defined Sequence Of Security Questions with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of providing better key security and recovery instances.
Regarding claim 15, claim 15 is directed to a similar method associated with the system of claim 5 respectively. Claim 15 is similar in scope to claim 5, respectively, and are therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to a similar method associated with the system of claim 8 respectively. Claim 18 is similar in scope to claim 8, respectively, and are therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to a similar method associated with the system of claim 9 respectively. Claim 19 is similar in scope to claim 9, respectively, and are therefore rejected under similar rationale.
Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over D’Auria et al. (US 2013/0332318) and Mantri (US 2023/0236815) and in further view of Watson (US 2015/0096045).
As per claim 7, D’Auria in combination with Mantri teaches the electronic device of claim 1, but fails to teach wherein at least one processor, individually or collectively, is configured to cause the electronic device to allow the target applet and the applet to share a sharable interface object (SIO) based on verification being successful.
However, in an analogous art Watson teaches wherein at least one processor, individually or collectively, is configured to cause the electronic device to allow the target applet and the applet to share a sharable interface object (SIO) based on verification being successful (Watson, Paragraph 0042 recites “IG. 2 is a sequence diagram 200 for establishing an SIO between applets and providing authentication of the SIO-requesting applet. In particular, in FIG. 2, an SIO is established between a WCAp 201 (e.g., FIG. 1, WCAp 107) and an ISAp 202 (e.g., FIG. 1, ISAp 108), and the requesting applet WCAp 201 is authenticated. Although not illustrated in FIG. 2, the WCAp 201 and ISAp 202 may communicate via the runtime environment (e.g., FIG. 1, JCRE 106) on which the applets are deployed. It should be understood that this process may be used to establish an SIO between and authenticate any two applets.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Watson’s systems, methods, and computer program products for securely managing data on a secure element with D’Auria’s User Interface For In-Browser Product Viewing And Purchasing because it offers the advantage of curely storing critical data during time periods when managing applets are not fully active.
Regarding claim 17, claim 17 is directed to a similar method associated with the system of claim 7 respectively. Claim 17 is similar in scope to claim 7, respectively, and are therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODERICK TOLENTINO whose telephone number is (571)272-2661. The examiner can normally be reached Mon- Fri 8am-4pm.
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, Luu Pham can be reached at 571-270-5002. 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.
RODERICK . TOLENTINO
Examiner
Art Unit 2439
/RODERICK TOLENTINO/Primary Examiner, Art Unit 2439
