DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation – Claim Scope Change
Independent claim 1 was amended on 01/21/2025 as follows:
PNG
media_image1.png
469
726
media_image1.png
Greyscale
Claim 1 was amended to recite an alternative embodiment, directed to an application requesting a key from a secure element and deciphering data. The previously examined claims were directed to a secure element performing the deciphering (i.e. “requesting a deciphering of the first data by the secure element. Upon a cursory review of the specification as filed and Applicant’s arguments, specifically with respect to paragraph [0128], which explicitly discloses “alternative embodiment(s)”:
PNG
media_image2.png
182
701
media_image2.png
Greyscale
Claim 1 was, therefore, amended to be directed to an alternative embodiment, while claims 14-20 were amended to recite a third embodiment, in which an application performs either deciphering function, in alternative form:
PNG
media_image3.png
182
713
media_image3.png
Greyscale
Therefore, claims 1-13 and 14-20 were amended to further diverge in scope. For purposes of Examination and in view of the Broadest Reasonable interpretation of the claims, Examiner considered these species as obvious variants of each other based on the current record. However, Examiner cautions Applicant regarding potential restriction requirements if further claim amendments are directed to patentably distinct species and/or inventions.
Information Disclosure Statement
The Information Disclosure Statement filed 07/02/2025 was considered. An initialed copy of the Form PTO-1449 is enclosed herewith.
Acknowledgements
This Office Action is in response to the amendment received on 01/21/2025 and arguments received on 07/02/2025.
Claims 1, 2, 5, 10, 13-16 and 18 were amended.
Claims 1-20 are pending.
Claims 1-20 were examined.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 14-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 14 and 18 were amended to recite “an NFC circuit configured to communicate the ciphered first data to the application, wherein the application requests a deciphering of the first data by the secure element or requests a decipher key from the secure element for deciphering the ciphered first data to generate deciphered first data, and wherein the application gains access to the deciphered first data in response to the application being authorized to communicate with the secure element”. The specification as filed recites, inter alia:
“[0128] At step 408, application 2014 being authorized to communicate with the secure element, it asks secure element 2012 to decipher the answer e(ans2). The latter implements this deciphering and sends answer ans2 to application 2014. According to an alternative embodiment, application 2014 may ask for the decipher key to the secure element and decipher the data by itself.”
Therefore, the specification as filed does not recite the manner in which the NFC circuit implements these alternative embodiments in a single implementation, as claimed. For instance, the specification as filed clearly recites in paragraph [0128] two distinct and alternative embodiments. Claims 14 and 18, however, were amended to recite a third embodiment in which the application is configured to perform both of these two alternative embodiments, namely a single application requesting a deciphering of the data by the secure element or requesting a key and performing the deciphering by itself. This configuration is not reasonably described in the disclosure. A fair reading of the disclosure would lead one of ordinary skill in the art to reasonably understand the disclosure as reciting two alternative embodiments, and the application would be configured according to one of these alternative embodiments. The claims, however, were amended to recite a third embodiment in which a single application performs either embodiment. This function is not reasonably described in the disclosure as filed. Therefore, the specification as filed does not provide sufficient written description for the claimed language (see MPEP 2161.01). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. Dependent claims 15-17 and 19-20 are also rejected since they depend on claims 14 and 18, respectively.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-4, 6, 10-16, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ballesteros et al. (US 2014/0244513 A1) in view of Brudnicki et al. (US 2012/0124394 A1).
With respect to claims 1, 14 and 18, Ballesteros et al. teach a mobile terminal; a system (see NFC transactions, paragraph [0015]; Fig. 2, paragraph [0018 describe a device with NFC antenna, controller, secure element, and SOC containing I2C controller, SCU, security engine, and CPU; Fig. 3, computing device 300, paragraph [0031] describe a computing device including a processor, memory, OS, program modules, and data storage); and a method (Data protection in near field communications (NFC) transactions) comprising:
an external electronic circuit configured to transmit first data (claim 18) (see target device, Fig. 3, paragraph [0036]: “Computing device 300 may also include one or more communication connections 324 that allow the computing device 300 to communicate wirelessly with one or more other wireless devices, over wireless connection 328 based on near field communication (NFC), Wi-Fi, Bluetooth, radio frequency (RF), infrared, or a combination thereof”; Fig. 4, blocks 402-404, paragraph [0048]: “At block 402, initiating a secure transaction application is performed. For example, a SOC (e.g., SOC 208) may include a CPU (e.g., CPU 216) that is configured to host an NFC stack and applications processing of data during an NFC transaction. In this example, the data may include sensitive data received from a target device, such as a credit card or a smartphone. In an implementation, the CPU 216 may initiate the secure transaction application. For example, the secure transaction application includes receiving of sensitive data from the target device, such as a credit card or smartphone”);
implementing a near field communication (NFC) transaction between a mobile terminal and an external electronic circuit, (see Fig. 4, block 402, paragraph [0048]: “At block 402, initiating a secure transaction application is performed. For example, a SOC (e.g., SOC 208) may include a CPU (e.g., CPU 216) that is configured to host an NFC stack and applications processing of data during an NFC transaction. In this example, the data may include sensitive data received from a target device, such as a credit card or a smartphone. In an implementation, the CPU 216 may initiate the secure transaction application. For example, the secure transaction application includes receiving of sensitive data from the target device, such as a credit card or smartphone”),
wherein the mobile terminal comprises a processor, an NFC circuit, and a secure element distinct from the processor, the processor hosting an application establishing the NFC transaction (Claim 1) / a processor configured to host an application used to establish a near field communication (NFC) transaction, the NFC transaction being a transaction between the mobile terminal and the external electronic circuit (claims 14 and 18) (see Fig. 2, CPU 216, NFC stack, secure element 206, a system controller unit (SCU) 212, a security engine 214, paragraph [0018]: “FIG. 2 illustrates an example system 200 of the portable device 102 that implements data protection during NFC transactions or communications. As shown, the system 200 includes an NFC antenna 202, an NFC controller 204, a secure element 206, and a SOC 208. Furthermore, the SOC 208 may include an inter-integrated circuit (I2C) controller 210 (it is to be understood that other controllers may be used, such as a serial peripheral interface (SPI) bus controller), a system controller unit (SCU) 212, a security engine 214, and a CPU 216.”; paragraph [0021]: “As an example of present implementation herein, the secure element 206 is a secure and isolated execution environment for the sensitive data to be processed. For example, the secure element 206 is a component or a computing device that is external to the SOC 208. In other words, the secure element 206 is configured to process sensitive data independent of the SOC 208; however, the request to process the sensitive data is generated by the SOC 208 and particularly, the SCU 212. Upon processing of the sensitive data, the secure element 206 may supply the processed sensitive data back to the SOC 208 through the NFC controller 204. In an implementation, the secure element 206 is software/hardware tamper resistant such that transferring of sensitive data to a secure server is implemented via a secure channel (not shown).”; paragraph [0029]: “As an example of present implementation herein, the CPU 216 may host an NFC stack and applications processing sensitive data for NFC transactions. For example, the CPU 216 is configured to handle encrypted sensitive data so that malware will not be able to interpret it. Actual processing of the sensitive data may be implemented in isolation at the secure element 206”),
receiving, by the NFC circuit, first data received from the external electronic circuit (see Fig. 1, sensitive data received from external device/credit card 104 or smartphone 102-6, paragraph [0015]: “As an example of the present implementation, portable devices 102-2 and/or 102-4 may enter into EMV transactions with the credit card 104. In this example, the portable devices 102-2 and/or 102-4 may establish near field coupling with the credit card 104 by positioning the credit card 104 at a certain distance to its respective NFC antenna. At this certain distance, a principle of mutual induction in NFC communications is applied to communicate sensitive data between the credit card 104 and the portable devices 102-2 and/or 102-4. Similarly, the same principle may be applied when a portable device 102-6 is utilized in communicating sensitive data to the portable devices 102-2 and/or 102-4.”; paragraph [0016]: “The data may include sensitive data such as personal, financial, or business information that needs additional protection against malware attacks. In this example, the portable devices 102 are configured to detect which data are sensitive data and which data are not. For the sensitive data, the portable devices 102 are configured to isolate processing of the sensitive data before they are exposed on the clear (i.e., unencrypted) at one or more processors or CPUs (not shown) or host software in the portable devices 102. In this manner, the sensitive data that are utilized during the NFC communications are protected from malicious programs that are capable of stealing the sensitive data from the portable devices 102.”; Fig. 4, block 402, paragraph [0048]: “At block 402, initiating a secure transaction application is performed. For example, a SOC (e.g., SOC 208) may include a CPU (e.g., CPU 216) that is configured to host an NFC stack and applications processing of data during an NFC transaction. In this example, the data may include sensitive data received from a target device, such as a credit card or a smartphone. In an implementation, the CPU 216 may initiate the secure transaction application. For example, the secure transaction application includes receiving of sensitive data from the target device, such as a credit card or smartphone.”);
ciphering... the first data to generate a ciphered first data (Claim 1) / a secure element configured to: receive first data from an external electronic circuit, and cipher the first data to generate a ciphered first data (Claims 14 and 18) (see Fig. 4, blocks 406, encryption of sensitive data, paragraph [0049]: “At block 404, determining if the SCU sends the sensitive data to CPU is performed. For example, the SCU 212 is configured to send the sensitive data to the CPU 216 or to a component external to the SOC 208 such as a secure element (e.g., secure element 206). If the SCU 212 sends the sensitive data to the CPU 216, then following "YES" branch at block 406, the SCU 212 controls encryption of the sensitive data. Alternatively, if the SCU 212 sends or routes directly the sensitive data to a component external to the SOC 208 such as the secure element 206, then following "NO" branch at block 408, the SCU 212 allows unencrypted sensitive data to be forwarded to the secure element 206 for further processing.”); and
communicating, by the NFC circuit to the [processor], the ciphered first data (Claim 1) / an NFC circuit configured to communicate the ciphered first data to the [processor] (Claims 14 and 18) (see Fig. 4, block 412, paragraph [0052]: “At block 412, sending of encrypted sensitive data is performed. For example, if the SCU 212 sends the sensitive data to the CPU 216, the SCU 212 is configured to all encryption of the sensitive data before it is forwarded by the SCU 212 to the CPU 216. The encryption may be performed by a security engine as described above. The encrypted sensitive data is now protected from any malicious software or malware accessing the CPU.”).
Ballesteros et al. do not explicitly disclose a method, mobile terminal and system comprising: the processor configured to host an application; [ciphering is performed] using a cipher key stored in the secure element (Claim 1); requesting a decipher key stored in the secure element for deciphering the first data by the application (claim 1) / wherein the application ... requests a decipher key from the secure element for deciphering the ciphered first data to generate deciphered first data (alternative language in claims 14 and 18); and deciphering, by the application, the ciphered first data using the decipher key to generate the deciphered first data, wherein the application requests a deciphering of the first data by the secure element (alternative language in Claims 14 and 18). wherein the application gains access to the deciphered first data in response to the application being authorized to communicate with the secure element (claims 14 and 18).
However, Brudnicki et al. disclose a method, mobile terminal and system (System and method for providing a virtual secure element on a portable communication device) comprising:
the processor configured to host an application (see paragraph [0008]: “The present invention involves a virtual secure element on a portable communication device having a secured element. The system comprising memory; a card management module operably associated with the secure element providing an application programming interface to the secure element and controlling writing to and reading from at least a portion of the memory; a virtual encryption key preferably stored within the secured element; and an encryption engine capable of encrypting data before its placed in the memory and decrypting that data using the virtual encryption key. The memory may be located within the portable communication device. There may also be a reserved memory area for swapping data between the secure element and the memory. This reserved memory area may transmit to the NFC Baseband module.”; Fig. 3, card management/API, paragraph [0030] );
[ciphering is performed] using a cipher key stored in the secure element (Claim 1) (see encryption engine, paragraph [0008]: “...an encryption engine capable of encrypting data before its placed in the memory and decrypting that data using the virtual encryption key...”; Fig. 3, key 300, paragraph [0031]: “In one embodiment depicted in FIG. 3, the virtual secure element 115 may also be secured using a key 300 or other encryption information that is stored in the secure element 120 of the payment subsystem. In this case, in order to access (i.e. read) data stored within the virtual secure element 115, the card management system 100 would need to access and obtain the key 300 or other encryption information from the secure element 120. This effectively extends the security typically available only within the secure element 120 to the virtual secure element 115. ...”; paragraph [0032]: "Because of its encryption using the key 300 stored in the secure element 120, the data is secure when read out of memory.");
requesting a decipher key stored in the secure element for deciphering the first data by the application (claim 1) / wherein the application ... requests a decipher key from the secure element for deciphering the ciphered first data to generate deciphered first data (alternative language in claims 14 and 18) (see Fig. 3, key 300, paragraph [0031]: “In one embodiment depicted in FIG. 3, the virtual secure element 115 may also be secured using a key 300 or other encryption information that is stored in the secure element 120 of the payment subsystem. In this case, in order to access (i.e. read) data stored within the virtual secure element 115, the card management system 100 would need to access and obtain the key 300 or other encryption information from the secure element 120. This effectively extends the security typically available only within the secure element 120 to the virtual secure element 115. ...”;); and
deciphering, by the application, the ciphered first data using the decipher key to generate the deciphered first data, wherein the application requests a deciphering of the first data by the secure element (alternative language in Claims 14 and 18) (see paragraph [0032]: “When an application needs data previously stored in the virtual secure element 115, it requests the data via card management. The encrypted data is located within virtual secure element 115. Because of its encryption using the key 300 stored in the secure element 120, the data is secure when read out of memory. The secure data is fed into the encryption engine along with the virtual SE key 300, so the data can be decrypted. Once decrypted, the data from virtual secure element is saved to a reserved space in the secure element 120. From the reserved space within secure element 120, the decrypted data can be sent to the NFC Baseband for secure presentation to a POS.”). wherein the application gains access to the deciphered first data in response to the application being authorized to communicate with the secure element (claims 14 and 18) (see paragraph [0030]: “ ...For instance, the card management may use the digital signature of a third party application, which uniquely identifies its author for purposes of tracking assets issued by the third party application. In this embodiment, the card management system would reject the attempted storage of data from any unsigned application. The card management system determines which applications are able to view, select and/or change each asset stored in virtual secure memory and prevents unauthorized applications from accessing data stored in virtual secure memory 115 for which they are not authorized. Similarly, the card management system grants temporary access to selected assets in order to securely present data via the contact-less point of sale. Thus, card, coupon, ticket, access control data, and other credentials may be provisioned by the card management system to the virtual secure memory 115 (i.e. outside of the secure element 120) while still utilizing the same mechanisms used to provision data to the "secure element" in the Payment Subsystem.").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the data enciphering and deciphering mechanisms using a key stored in the secure element as disclosed by Brudnicki et al. in the method, mobile terminal and system of Ballesteros et al., the motivation being to providing better security to most credentials by employing a key encrypted virtual secure element stored outside of the hardware secure element of Ballesteros et al., only requiring temporary use of the payment subsystem when the consumer chooses to use services requiring presentation of this data, and overcoming the limited storage size of secure elements, thereby allowing users to increase storage of desired payment data while using the same device and hardware secure element. (see Brudnicki et al., paragraphs [0029] and [0031]).
With respect to claims 2, 15 and 19, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method, mobile terminal and system as described above with respect to claims 1, 14 and 18. Furthermore, Brudnicki et al. disclose a method, mobile terminal and system wherein the application is authorized to implement the NFC transaction using an interface software hosted by the processor, wherein the processor executes instructions sent by the application; Claim 2: as the deciphered first data (see reserved space, paragraph [0032]: “When an application needs data previously stored in the virtual secure element 115, it requests the data via card management. The encrypted data is located within virtual secure element 115. Because of its encryption using the key 300 stored in the secure element 120, the data is secure when read out of memory. The secure data is fed into the encryption engine along with the virtual SE key 300, so the data can be decrypted. Once decrypted, the data from virtual secure element is saved to a reserved space in the secure element 120. From the reserved space within secure element 120, the decrypted data can be sent to the NFC Baseband for secure presentation to a POS.”). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claims 3 and 16, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method and mobile terminal as described above with respect to claims 2 and 15. Furthermore, Brudnicki et al. disclose a method and mobile terminal further comprising prohibiting, using the interface software, a request, from the application, for a key from the secure element during the deciphering in response to the interface software including a no authorization instruction with regards to the application (see paragraph [0030]: “...The card management system determines which applications are able to view, select and/or change each asset stored in virtual secure memory and prevents unauthorized applications from accessing data stored in virtual secure memory 115 for which they are not authorized. Similarly, the card management system grants temporary access to selected assets in order to securely present data via the contact-less point of sale. Thus, card, coupon, ticket, access control data, and other credentials may be provisioned by the card management system to the virtual secure memory 115 (i.e. outside of the secure element 120) while still utilizing the same mechanisms used to provision data to the "secure element" in the Payment Subsystem.”; paragraph [0031]: “... For example, secure elements may be configured to self-destruct if multiple improper access attempts are detected. Thus, in this embodiment, if a secure element 120 is disabled due to such improper access attempts, the key 300 or other encryption information would no longer be accessible, effectively rendering the virtual secure element 115 disabled as well.”). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 4, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Brudnicki et al. disclose a method wherein the application is a system application (see paragraph [0008]: “The present invention involves a virtual secure element on a portable communication device having a secured element. The system comprising memory; a card management module operably associated with the secure element providing an application programming interface to the secure element and controlling writing to and reading from at least a portion of the memory; a virtual encryption key preferably stored within the secured element; and an encryption engine capable of encrypting data before its placed in the memory and decrypting that data using the virtual encryption key. The memory may be located within the portable communication device. There may also be a reserved memory area for swapping data between the secure element and the memory. This reserved memory area may transmit to the NFC Baseband module.”; Fig. 3, card management/API, paragraph [0030] ). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 6, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Brudnicki et al. disclose a method further comprising receiving, by the application, a temporary authorization to implement the NFC transaction (see paragraph [0030]: "...Similarly, the card management system grants temporary access to selected assets in order to securely present data via the contact-less point of sale. Thus, card, coupon, ticket, access control data, and other credentials may be provisioned by the card management system to the virtual secure memory 115 (i.e. outside of the secure element 120) while still utilizing the same mechanisms used to provision data to the "secure element" in the Payment Subsystem.”). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 10, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Brudnicki et al. disclose a method further comprising refusing, by the secure element, to provide the decipher key for the deciphering of the first data in response to the application not being authorized to implement the NFC transaction (see paragraph [0030]: "...The card management system tracks the issuers of all card, coupon, access control and ticket data stored in the "virtual secure" memory 115 as well as secure element 120 in the payment subsystem 150. For instance, the card management may use the digital signature of a third party application, which uniquely identifies its author for purposes of tracking assets issued by the third party application. In this embodiment, the card management system would reject the attempted storage of data from any unsigned application. The card management system determines which applications are able to view, select and/or change each asset stored in virtual secure memory and prevents unauthorized applications from accessing data stored in virtual secure memory 115 for which they are not authorized...."). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 11, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Ballesteros et al. disclose a method wherein the NFC transaction is a transaction to exchange critical data between the mobile terminal and the external electronic circuit (see paragraph [0040]: “Specifically, the data decryption method may be applied to a restoration process after data backup. A process of restoring data of an NFC card written into a Huawei wallet application is used as an example. When a part of sensitive data (for example, the first data) of the card needs to be restored to the SE, a content provider (for example, the access card party) of the NFC card is introduced to generate and deliver a key factor (for example, the second key factor). In other words, the content provider is responsible for security management of the second key factor. In addition, in combination with another key factor (for example, the first key factor) provided by the mobile phone party (for example, the Huawei device), a real backup key (for example, the first backup key) is generated in the secure element SE of the mobile phone. In the security domain of the SE, the sensitive data (for example, the first data) of the card is decrypted by using the first backup key, to obtain the sensitive data of the card. The mobile phone party cannot learn the second key factor delivered by the access card party, and the access card party cannot learn the first key factor generated by the mobile phone party. Neither party can independently determine the first backup key. In other words, the mobile phone party (for example, the Huawei device) or the third party (for example, the access card party) cannot independently decrypt and restore the sensitive data of the user. This implements reliable and secure backup of the data.”; Examiner notes "critical data" is interpreted under BRI as "sensitive data" from the card/external device.). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 12, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Ballesteros et al. disclose a method wherein the NFC transaction is a bank transaction (see paragraph [0139]: “It should be understood that the card for backup in this application may be a card supporting near field communication (near field communication, NFC), for example, an access card, a bank card, a bus card, or a credit card. This is not limited in this application.”;). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 13, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Ballesteros et al. disclose a method further comprising ciphering of the first data by the secure element in response to detecting, by the NFC circuit, that the first data includes critical data (see paragraph [0143]: “It should be further understood that, when the secure data backup method provided in the embodiments of this application is used, it is required that a card type of a to-be-backed-up card may support backup, a card issuer allows backup, and the user allows the card to be backed up to a cloud. For example, an access card party allows data of the access card to be backed up. However, for an electronic identification card (electronic identification card, eID) of the user, backup of eID data is not allowed. Alternatively, for example, if some manufacturers do not want to back up the access card, the access card may be set when a blank card service is applied for. However, in a backup process, the user agrees to back up the access card to a cloud server.”;). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
Claims 5, 7-9, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ballesteros et al. (US 2014/0244513 A1), in view of Brudnicki et al. (US 2012/0124394 A1), in view of Alberti et al. (US 2017/0251369 A1)
With respect to claim 5, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Brudnicki et al. disclose a method further comprising:
receiving, by the application, a permanent authorization to implement the NFC transaction (see paragraph [0030]: "...The card management system tracks the issuers of all card, coupon, access control and ticket data stored in the "virtual secure" memory 115 as well as secure element 120 in the payment subsystem 150. For instance, the card management may use the digital signature of a third party application, which uniquely identifies its author for purposes of tracking assets issued by the third party application. In this embodiment, the card management system would reject the attempted storage of data from any unsigned application. The card management system determines which applications are able to view, select and/or change each asset stored in virtual secure memory and prevents unauthorized applications from accessing data stored in virtual secure memory 115 for which they are not authorized....");
The combination of Ballesteros et al. and Brudnicki et al. does not explicitly disclose a method, mobile terminal and system comprising: storing, by the secure element, a list of rules indicating the permanent authorization concerning the application, wherein the application is a reliable application previously authorized by a manufacturer of the mobile terminal; and referring, by the secure element, to the list of rules to determine that the application is authorized to implement the NFC transaction.
However, Alberti et al. discloses a method (Method and device for controlling access from the device to a card via a NFC interface) further comprising:
storing, by the secure element, a list of rules indicating the permanent authorization concerning the application, wherein the application is a reliable application previously authorized by a manufacturer of the mobile terminal (see paragraph [0035]: “The method 400 comprises the step of determining by the processor 150 based on the specific signature, the particular card identifier and the ACL 300, if the specific application is granted access to the particular card 200 via the NFC interface of the device 100, or alternatively if the specific application is denied access to the particular card 200 via the NFC interface of the device 100.”; paragraph [0036]: “The method 400 further comprises the step of configuring the device 100 to grant or alternatively deny access of the specific application to the particular card 200 via the NFC interface of the device 100, based on the determination made by the processor. The configuration is dependent on the particular hardware and software architecture of the device 100. It may consist in updating a routing table on at least one of the Secure Element 130 or the CLF 120. If the specific application is granted access, the routing table is updated accordingly to authorize the application to exchange data with the card 100. If the specific application is denied access, the routing table is not updated and by default the application is not authorized to exchange data with the card 100.”; paragraph [0040]: “The ACL 300 may be implemented as a white list. If a specific application signature is not present in the list of application signatures 310, the corresponding application cannot access any card 200. If a specific application signature is present in the list of application signatures 310, the list of card identifiers 320 comprise all the particular card identifiers corresponding to the specific application signature and identifying the particulars cards 300 which can be accessed by the specific application. In the example illustrated in FIG. 2, a first application (executed by the CPU 110) having the signature App_sign_1 can only access a card 200 having the identifier Card_AID_X. A second application (executed by the CPU 110) having the signature App_sign_2 can only access a card 200 having the identifiers Card_AID_X or Card_AID_Y. A first applet (executed by the Secure Element 130) having the signature Applet_sign_1 can only access a card 200 having the identifier Card_AID_X. A second applet (executed by the Secure Element 130) having the signature Applet_sign_2 can only access a card 200 having the identifier Card_AID_Z. The implementation of the ACL 300 as a white list is preferable for devices 100 where most applications are not granted access to cards 200, such as general purpose tablets or smartphones.”); and
referring, by the secure element, to the list of rules to determine that the application is authorized to implement the NFC transaction (see paragraph [0037]: “As illustrated previously, the specific application may be an application 112 executed by the CPU 110 or an applet 132 executed by the Secure Element 130. Thus, in various embodiments of the present method 400 and device 100, access control may be provided only for applications 112 executed by the CPU 110, only for applets 132 executed by the Secure Element 130, or for both applications 112 executed by the CPU 110 and applets 132 executed by the Secure Element 130.”; paragraph [0038]: “The access control functionality 160 comprises a control software 162 executed by the processor 150 and the ACL 300 stored in the memory 140. The localization of the processor 150 and memory 140 in the device 100 depends on the particular architecture of the device 100, as will be detailed later in the description. The control software 162 may be integrated in an OS executing on the processor 150 or may be executing as an application on top of the OS.”; paragraph [0048]: “In another particular aspect corresponding to the SE centric architecture represented in FIG. 4, the access control functionality 160 is provided by the Secure Element 130. Thus, the processor 150 and the memory 140 implementing the access control functionality 160 are embedded in the Secure Element 130.”; paragraph [0050]: “Although FIG. 3 illustrates the method 400 in the context of an application 112 executed by the CPU 110, it can be generalized to an applet 132 executed by the Secure Element 130.”; paragraph [0054]: “In the case of the SE centric architecture illustrated in FIG. 4, the instructions for implementing the method 400 are executed by the processor 150 embedded in the Secure Element 130.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the access control mechanisms as disclosed by Alberti et al. in the method, mobile terminal and system of Ballesteros et al. and Brudnicki et al., the motivation being to prevent unauthorized access to the critical information stored on the card from the device via its NFC interface (see Alberti et al., paragraph [0003]).
With respect to claim 7, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method as described above with respect to claim 6. The combination of Ballesteros et al. and Brudnicki et al. does not explicitly teach a method further comprising transmitting, by the secure element, the temporary authorization.
However, Alberti et al. discloses a method (Method and device for controlling access from the device to a card via a NFC interface) further comprising transmitting, by the secure element, the temporary authorization (see paragraph [0039]: “The control software 162 receives the request from the specific application (e.g. 112 or 132) for accessing the particular card 200 and determines if the specific application (e.g. 112 or 132) is granted or denied access to the particular card 200. The determination is made by looking up the ACL 300 to find the specific signature among the list of application signatures 310 and further looking up the ACL to find the particular card identifier among the list card identifiers 320.”; paragraph [0054]: “In the case of the SE centric architecture illustrated in FIG. 4, the instructions for implementing the method 400 are executed by the processor 150 embedded in the Secure Element 130.”; paragraph [0042]: “The access control functionality 160 may also comprise an update software 164 executed by the processor 150. The update software 164 receives via a communication interface of the device 100 (e.g. a cellular interface, a Wi-Fi interface, etc.) an update of the ACL 300, and updates the ACL 300 stored in the memory 140 with the received update. The update may be transferred (in a push or pull mode) from a centralized Trusted Service Manager (TSM) to the device 100 though a proper security infrastructure providing encryption of the transferred ACL update. The use of a TSM is particularly relevant in the case where the ACL 300 is stored on a memory 140 of the Secure Element 130, as will be detailed later in the description.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the access control mechanisms as disclosed by Alberti et al. in the method, mobile terminal and system of Ballesteros et al. and Brudnicki et al., the motivation being to prevent unauthorized access to the critical information stored on the card from the device via its NFC interface (see Alberti et al., paragraph [0003]).
With respect to claim 8, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method as described above with respect to claim 6. The combination of Ballesteros et al. and Brudnicki et al. does not explicitly teach a method further comprising receiving, by the secure element, the temporary authorization from an external server.
However, Alberti et al. discloses a method (Method and device for controlling access from the device to a card via a NFC interface) further comprising receiving, by the secure element, the temporary authorization from an external server (see paragraph [0039]: “The control software 162 receives the request from the specific application (e.g. 112 or 132) for accessing the particular card 200 and determines if the specific application (e.g. 112 or 132) is granted or denied access to the particular card 200. The determination is made by looking up the ACL 300 to find the specific signature among the list of application signatures 310 and further looking up the ACL to find the particular card identifier among the list card identifiers 320.”; paragraph [0054]: “In the case of the SE centric architecture illustrated in FIG. 4, the instructions for implementing the method 400 are executed by the processor 150 embedded in the Secure Element 130.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the access control mechanisms as disclosed by Alberti et al. in the method, mobile terminal and system of Ballesteros et al. and Brudnicki et al., the motivation being to prevent unauthorized access to the critical information stored on the card from the device via its NFC interface (see Alberti et al., paragraph [0003]).
With respect to claims 9, 17 and 20, the combination of Ballesteros et al. and Brudnicki et al. teaches all the subject matter of the method, mobile terminal and system as described above with respect to claims 1, 15 and 18. The combination of Ballesteros et al. and Brudnicki et al. does not explicitly teach a method, mobile terminal and system wherein the application is a first application, and wherein the secure element comprises a list of rules indicating a first authorization concerning the first application and a second authorization concerning a second application.
However, Alberti et al. discloses a method, mobile terminal and system (Method and device for controlling access from the device to a card via a NFC interface) wherein the application is a first application, and wherein the secure element comprises a list of rules indicating a first authorization concerning the first application and a second authorization concerning a second application (see paragraph [0143]: “It should be further understood that, when the secure data backup method provided in the embodiments of this application is used, it is required that a card type of a to-be-backed-up card may support backup, a card issuer allows backup, and the user allows the card to be backed up to a cloud. For example, an access card party allows data of the access card to be backed up. However, for an electronic identification card (electronic identification card, eID) of the user, backup of eID data is not allowed. Alternatively, for example, if some manufacturers do not want to back up the access card, the access card may be set when a blank card service is applied for. However, in a backup process, the user agrees to back up the access card to a cloud server.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the access control mechanisms as disclosed by Alberti et al. in the method, mobile terminal and system of Ballesteros et al. and Brudnicki et al., the motivation being to prevent unauthorized access to the critical information stored on the card from the device via its NFC interface (see , paragraph [0003]).
Response to Arguments/Amendments
Claim rejections - 35 USC § 112
Applicant’s Arguments with respect to the rejection of claims 14-20 (see remarks dated 12/10/2025 with respect to the 35 U.S.C. 112(a) have been fully considered. However, Examiner disagrees with Applicant’s position. Claims 14 and 18 were amended on 01/21/2025 as follows:
PNG
media_image4.png
516
812
media_image4.png
Greyscale
PNG
media_image5.png
594
826
media_image5.png
Greyscale
The specification as filed describe two embodiments, represented by Figs. 3 and 4, as follows:
PNG
media_image6.png
832
578
media_image6.png
Greyscale
PNG
media_image7.png
871
543
media_image7.png
Greyscale
As an initial matter, it appears Applicant’s arguments are directed to characteristics of the “application”. Examiner notes that the scope of claims 14 and 18 do not encompass an “application”. Claim 14 is directed to a mobile terminal comprising a secure element, a processor and an NFC circuit. Claim 18 is directed to a system comprising an external electronic circuit and a mobile terminal comprising a secure element, a processor and an NFC circuit. The language “a processor configured to host an application…” represents the intended use of the “processor”. Examiner notes, for instance, that the claims do not require a memory storing instructions executed by the processor, but rather merely recite the intended use of the processor. Therefore, Examiner is in the position that language directed to further describing the application (i.e. wherein clause) carries little patentable weight in view of the scope set by the claims, which do not require an application being an integral part of the claimed apparatuses.
Even if weight should be given to the language directed to further describing an “application”, it appears the original claims were directed to the embodiment of Fig. 4, reciting “wherein the application requests a deciphering of the first data by the secure element” (See step 407). The claims were then amended to recite, in the wherein clause, “or requests a decipher key from the secure element…”, an element recited in conjunction with the embodiment of Fig. 3 (see step 307). Therefore, the claims were amended to both require a “secure element configured to… cipher the first data” (see Fig. 4, step 405 SE Encrypt) and the newly introduced and alternative decryption mechanism represented by Fig. 4, 407 or Fig. 3, 307. This embodiment is not sufficiently described in the specification as filed. Therefore, it appears the claims were amended in an attempt to represent the following hypothetical embodiment:
PNG
media_image8.png
1016
1228
media_image8.png
Greyscale
(For illustration purposes, subject matter introduced by amendment in red)
Examiner is in the position that the specification does not recite such an embodiment, requiring a decision point while at the same time explicitly requiring by the claim that the Secure Element encryption of the data. Specifically, the specification recites two alternative embodiments, one represented by Fig. 3 and another represented by Fig. 4. The specification as filed does not appear to describe these embodiments have interchangeable parts. Particularly, the specification as filed recited two implementation modes distinct methods of implementing, or method of performing, an NFC transaction of the type of the NFC transaction described in relation to Figure 1 (see paragraphs [0107] and [0120]), and it does not appear mixing these embodiments is envisioned.
Further, Examiner is in the position that the specification as filed does not recite the mechanisms for decrypting, by the application, data encrypted by the Secure Element. Examiner notes Fig. 3 explicitly recite an “NFC encrypt” mechanism (step 305, paragraph [0112]), in which the NFC circuit (not the SE element) encrypts the data by requesting a key to the secure element. Then, for decryption, the data is decrypted by the APP with a key requested from the secure element (App decrypt 308, paragraph [0115]). The claims, however, require a secure element encryption and two decryption alternatives, one by the secure element (original claim), and another by the application (amended language). The manner in which the decryption, by an application, of data encrypted by a secure element is not reasonably found in the specification as filed, and therefore the rejection is maintained.
Examiner notes that a similar rationale could be applied to claim 1, if the broadest reasonable interpretation of the amended claim is interpreted to encompass both encryptions (steps 305 and 405), but the decryption being required to be performed by the application (step 308). Examiner notes the breadth of the claim was altered to not require the cyphering to be performed by the secure element, as originally claimed, and another Examiner could potentially raise this similar issue in view of the broader claim scope introduced by the removal of the term “by”.
Claim rejections - 35 USC § 103
Applicant’s amendments and arguments (see remarks, pages 4-9, filed 12/10/2025), with respect to the rejection of claims 1-20 under 35 USC § 103 have been fully considered. As an initial matter, Applicant asserts, in page 9, “Claims 14 and 18 recite features analogous to those discussed above concerning claim 1 and, as a whole, are patentable over the cited references for similar reasons”. As described in the “Claim interpretation” section of the Non-Final office Action dated 08/15/2025, the claims were amended to recite embodiments which are not commensurate in scope. Therefore, Examiner treats Applicant’s remarks as being directed to claims 1-13.
Applicant is in the position that the combination of references does not teach the step of “deciphering, by the application, the ciphered first data using the decipher key to generate the deciphered first data” by addressing structural characteristics of the combination. Examiner reminds Applicant that a method claim is defined by a series of specific, ordered steps (actions or steps) rather than physical structure. It appears Applicant interprets the recited step of “deciphering, by the application” in a narrow manner, unduly incorporating characteristics of structural elements in an attempt to differentiate the claimed method steps. For instance, Applicant asserts “Brudnicki teaches that an encryption engine (not an application) performs the decryption operation. See, e.g., Brudnicki, [0008], [0032]” and further attempts to differentiate differences between an “application” and an “engine”. Examiner disagrees these nomenclature differences are relevant, and the reference clearly discloses the decryption operation, as claimed. Examiner notes that under broadest reasonable interpretation, “an engine”, “an application” or the combination of an “engine” and an “application” read on the claimed “application”, since the specification as filed does not lexicographically recite the term. Therefore, since the combination of references render the step of “deciphering” obvious to one of ordinary skill in the art, a prima facie case was established.
Applicant further argues that “modification of Ballesteros in view of Brudnicki would change the principle of operation of Ballesteros and make it unsatisfactory for its intended purposes”. However, Examiner is in the position that Applicant continues to apply undue weight to structural elements when the claims are directed to a process. Examiner respectfully disagrees the combination of references is deficient. The references can be reasonably combined to provide better security, as described in the previous Non-Final Office Action. For instance, Applicant asserts “According to both references, moving decryption to the application level would decrease security, not increase it, by exposing sensitive data to potential malware at the application level“, however, it appears that Applicant grants the term “application” a much narrower definition than the Broadest Reasonable interpretation of the process claim, and attempts to differentiate the prior art references not by the BRI of the claims, but rather to this narrow interpretation, in which weight is unduly given to structural characteristics of devices, rather than differentiating the claimed method steps from the steps recited by the prior art references. For instance, Applicant asserts “the motivation does not address or explain why one would change where decryption occurs (i.e., moving decryption from the security engine to the application level)”. Examiner disagrees with such a standard, placed on a narrow interpretation of certain structural elements. Examiner is in the position that the combination of references render the broadest reasonable interpretation of the claims obvious to one of ordinary skill in the art, therefore the rejections are herein maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Patent Literature
Nicolau (US 2015/0033291 A1) discloses multi-issuer secure element partition architecture for NFC enabled devices, including providing secure element partitions for an NFC enabled device for a plurality of card issuers, the method comprising creating in a secure element of the NFC enabled device a plurality of secure element partitions; and allocating said secure element partitions of the secure element to the respective card issuers.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. 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.
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698