Detailed Action
Claims 1-8, 12-14, and 17-20 are pending and are examined.
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 .
Status of Claims
Claims 1, 4-5, 14, and 19 are currently amended.
Response to Remarks
Claim Objections
Applicant’s amendments to the claims have overcome the previous objections to claim 19. Accordingly, the previous objections are withdrawn.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “The Office considers the features of previous claim 5 to be disclosed in Van de Ruit, citing paragraphs [0154], [0155] and [0161]. The Office appears to consider the binding number 327 to correspond to the shared secret of claim 1. However, these paragraphs do not disclose that the binding number (or indeed, any parameter) is stored within a UICC and within a telecommunications network component, nor that a telecommunications network component sends this binding number to an external server. In particular, Van de Ruit states that "the low security data area may comprise an optional binding number" (paragraph [0154], emphasis added). This is part of the device (see, e.g., Figure 3 of Van de Ruit). Paragraphs [0158] and [0161] recite, inter alia and respectively, [...] the signing interface may receive the key derivation information, and binding number 327 (if any) and For example, the cryptographic kernel application may be configured to obtain a fingerprint of the blockchain transaction device, and to refuse the signing interface if the obtained fingerprint does not agree to a previously stored fingerprint. The binding number 327 discussed above may be part of such a fingerprint (emphasis added). The signing interface and cryptographic kernel application are part of the same device as the low security data area (see again, Figure 3 of Van de Ruit and paragraphs [00133] and [0134], for example). Furthermore, the signing interface/cryptographic kernel has to receive the binding number from the low security data area - i.e., it does not store the binding number when the UICC is manufactured. The binding number is thus not stored in two separate devices in the manner required of the shared secret in claim 1. Indeed, as noted above, claim 1 further recites that a third device (the external server) receives the shared secret from the telecommunications network component, but Van de Ruit does not mention that any other entity receives the binding number. In any case, claim 1 as amended requires that the telecommunications network component storing the shared secret "is a component within a core network of a telecommunications network". Van de Ruit does not mention any component of a core network within a telecommunications network at all, let alone in the paragraphs cited by the Office. To the extent that the Office appears to consider this disclosed in these paragraphs based on the comments on claim 6 (which requires that the telecommunications network component is a home location register, HLR), the Applicant strongly disagrees, as discussed below. A component of a core network is not a random component that can be replaced by any other entity in a telecommunications network (e.g., a cryptographic kernel on the same device as having the low security area). Rather, the use of a server, the device and the telecommunications network component in the core network in the manner recited in claim 1 defines a particular relationship that can allow telecommunications network infrastructure to be leveraged to verify a device and create a secure channel between the device and a server external to the telecommunications network. Thus, whilst Van de Ruit mentions SIMs, there is absolutely no discussion or hint of providing a relationship between a distributed ledger, a device, a server and a core network to verify a device with the distributed ledger and secure a communication channel between the server and the device. The presence of a SIM does not in any way mean that a core network component operates in the manner defined in claim 1 (e.g., storing a shared secret and sending it to an external server). As acknowledged by the Office, Van de Ruit lacks at least "verifying the device using a different physical communication channel to the secure communication channel, wherein the different physical communication channel is short-message service (SMS)" (emphasis added). Claim 1 as amended further defines that this verification is performed prior to receiving the instruction to execute a transaction and in order to register the device with the distributed ledger. This is also not described in Van de Ruit. In particular, the passages cited by the Office describe that the cryptographic kernel application obtains a fingerprint of the blockchain transaction device and refuses to sign a received transaction if the fingerprint does not agree with a previously stored fingerprint (paragraph [0161] of Van de Ruit; see also paragraphs [0173] to [0175]). It is thus evident that the verification in Van de Ruit is after receiving an instruction to execute a transaction. Given that a previously stored fingerprint of the device is available, and the device can send the signed transaction to the bitcoin network (see paragraphs [0161] and [0176] to [0177] of Van de Ruit), it is also evident that the device in Van de Ruit is already registered with the blockchain.”. (Applicant Arguments, 2026-03-02).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Van de Ruit, Armstrong, and Komandur) still teach the currently amended independent claims, as shown at least in paragraphs 113, 127, 158, and 178 of Van de Ruit, and as further outlined in paragraphs 11-17 of this action. Indeed, Van de Ruit teaches a SIM/UICC-based secret and binding framework, including that the data may be ‘encrypted with a secret key under control of the cryptographic kernel’ that a binding number may be used on the signing/key generation interface, and that the SIM security domains are issued and controlled by the MNO. Armstrong teaches the separate verification channel the applicant emphasizes, including that ‘once you have a verified real phone number (via SMS or call) is still required for account validation purposes’. It would have been obvious to use Armstrong’s SMS/phone verification with Van de Ruits SIM-based secret-sharing and operator-controlled security architecture to verify the device and establish the secure relationship before allowing sensitive transaction activity.Accordingly, this contention is unpersuasive.
Status of Claims
Claims 1-2, 4, 14, and 20 are currently amended.
Claims 9-11 and 15-16 are cancelled.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-8, 12-14, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Van de Ruit et al. (US20190121988A1) (hereinafter “Van de Ruit”) in view of Armstrong et al. (US20150262137A1) (hereinafter “Armstrong”) in further view of Komandur et al. (US20200177373A1) (hereinafter “Komandur”)
As per Claim 1, 14, and 19, Van de Ruit teaches:
A method for executing secure transactions, the method comprising the steps of: initiating a secure communication channel between a device having a UICC and a server external to a telecommunications network, wherein the secure communication channel is secured using the UICC; (“The transaction application is generally more complicated software and more likely to be compromised than the cryptographic kernel. Moreover, because fewer requirements are placed on the cryptographic kernel, a higher level of security can be achieved, e.g., by using the security provisions of the device. For example, in an embodiment the high and low security data areas may be provided in different memories. Access to the high security data area may be more restricted, e.g. restricted to the cryptographic kernel application. Likewise, the transaction application and the cryptographic kernel application may be executed on different processor circuits. For example, the memory for the high security data area and the processor for the cryptographic kernel may be combined in a hardware element which may be releasably connected to the transaction device. In an advantageous embodiment, the hardware element is a SIM card, and the transaction application is implemented in a mobile phone in which the SIM card may be inserted. The private key stored in the high security data area may be in any representation, e.g., the private key may be encrypted or may be stored as a seed from which the private key may be computed. In particular, the high security data stores information enabling derivation of the private key. A seed is considered data determining a private key, as it is required for deriving the key notwithstanding that other data may be involved that may also determine the private key. Determining the private key from a seed and optional further data is deterministic.” (Para. 0015); “The hardware element may be a so-called ‘secure element’. Examples of a secure element in phones include the chip directly embedded into the phone's hardware, a SIM/UICC card provided by your network operator, and an SD card that can be inserted into the mobile phone.” (Para. 0017); “For example, the high security memory 210 and the high security processor circuit 220 may be combined in a hardware element 200, e.g., as shown in FIG. 1c . The hardware element may be integrated in device 100, or may be separable from device 100. For example, in an embodiment, the blockchain transaction device is comprised in a mobile phone. The hardware element may be comprised in a Subscriber Identity Module (SIM). For example, FIG. 1d , shows a phone 202 and a SIM card 201. SIM card 201 comprises an integrated circuit 203. The integrated circuit implements memory 210 and circuit 220. In an embodiment, access to the SIM card is restricted. Memory 110 and circuit 120 may be implemented in phone 202. When card 201 is inserted in phone 202, the full functionality of the blockchain transaction device is obtained.” (Para. 0113).
receiving at the server from the device over the secure communication channel, an instruction to execute a transaction; (“For example, the high security memory 210 and the high security processor circuit 220 may be combined in a hardware element 200, e.g., as shown in FIG. 1c . The hardware element may be integrated in device 100, or may be separable from device 100. For example, in an embodiment, the blockchain transaction device is comprised in a mobile phone. The hardware element may be comprised in a Subscriber Identity Module (SIM). For example, FIG. 1d , shows a phone 202 and a SIM card 201. SIM card 201 comprises an integrated circuit 203. The integrated circuit implements memory 210 and circuit 220. In an embodiment, access to the SIM card is restricted. Memory 110 and circuit 120 may be implemented in phone 202. When card 201 is inserted in phone 202, the full functionality of the blockchain transaction device is obtained.” (Para. 0113); “Blockchain transaction device 100 is configured to create transactions. After a transaction is created, e.g., a transfer of Bitcoin value, by blockchain transaction device 100, the device may broadcast the transaction to the network where eventually it will be collected into a block. A transaction may have one or more transaction inputs and one or more transaction outputs. The transaction may refer to a previous transaction output as a new transaction input. In an embodiment, a transaction output comprises a so-called address, e.g., a key identifier. Later transfers of that output require a signature by the corresponding key. For example, a transaction input may comprise a reference to a previous transaction, and an unlock script, e.g., a scriptSig. For example, a transaction output may comprise a locking script. The unlock script, e.g., scriptSig combined with the locking script, e.g. scriptPubKey, in the referenced previous output produce a verifiable script. If the verifiable script can be executed successfully, then the transaction is valid. The transaction may also comprise the asset to be transferred, e.g., an amount of cryptocurrency, a domain name, etc. An unlock script, e.g., scriptSig, may contain two components, a signature and a public key. The public key must match a hash given in the locking script of the redeemed output. The public key is used to verify the redeemer's signature, which is the second component. For example, the second component may be an ECDSA signature over a hash over data derived from the transaction.” (Para. 0108); “Returning to FIG. 1a , such a peer to peer network 130 is shown. The network may comprise multiple blockchain management devices; shown are blockchain management device 131 and blockchain management device 132. The blockchain management devices in the network are connected, e.g., in a peer-to-peer fashion but it may also be in a different way, e.g., as an organized or hierarchical network, etc. Blockchain transaction device 100 comprises a communication interface 101 arranged to transmit the transaction for inclusion in the blockchain. For example, blockchain transaction device 100 may send a transaction directly to a blockchain management device, e.g., blockchain management device 131 or 132. For example, blockchain transaction device 100 may send the transaction to other devices in the network who in turn forward the transaction so that it reaches one or more blockchain management devices.” (Para. 0105).
in response to the received instruction, transmitting from the server to a distributed ledger a request to execute the transaction; and (“Blockchain transaction device 100 is configured to create transactions. After a transaction is created, e.g., a transfer of Bitcoin value, by blockchain transaction device 100, the device may broadcast the transaction to the network where eventually it will be collected into a block. A transaction may have one or more transaction inputs and one or more transaction outputs. The transaction may refer to a previous transaction output as a new transaction input. In an embodiment, a transaction output comprises a so-called address, e.g., a key identifier. Later transfers of that output require a signature by the corresponding key. For example, a transaction input may comprise a reference to a previous transaction, and an unlock script, e.g., a scriptSig. For example, a transaction output may comprise a locking script. The unlock script, e.g., scriptSig combined with the locking script, e.g. scriptPubKey, in the referenced previous output produce a verifiable script. If the verifiable script can be executed successfully, then the transaction is valid. The transaction may also comprise the asset to be transferred, e.g., an amount of cryptocurrency, a domain name, etc. An unlock script, e.g., scriptSig, may contain two components, a signature and a public key. The public key must match a hash given in the locking script of the redeemed output. The public key is used to verify the redeemer's signature, which is the second component. For example, the second component may be an ECDSA signature over a hash over data derived from the transaction.” (Para. 0108); “Blockchain transaction device 300 comprises a processor circuit system configured to execute a cryptographic kernel application 430 and a transaction application 330. Transaction application 330 is configured to generate a transaction. For example, transaction application 330 may comprise a transferring unit 340 configured to generate a transaction and to transmit the transaction for inclusion in the blockchain. For example, transferring unit 340 may be configured to send the transaction to a blockchain management device, e.g., in network 130, e.g. via a node in network 130.” (Para. 0133); “Returning to FIG. 1a , such a peer to peer network 130 is shown. The network may comprise multiple blockchain management devices; shown are blockchain management device 131 and blockchain management device 132. The blockchain management devices in the network are connected, e.g., in a peer-to-peer fashion but it may also be in a different way, e.g., as an organized or hierarchical network, etc. Blockchain transaction device 100 comprises a communication interface 101 arranged to transmit the transaction for inclusion in the blockchain. For example, blockchain transaction device 100 may send a transaction directly to a blockchain management device, e.g., blockchain management device 131 or 132. For example, blockchain transaction device 100 may send the transaction to other devices in the network who in turn forward the transaction so that it reaches one or more blockchain management devices.” (Para. 0105).
in response to the request, signing the transaction at the distributed ledger . . . (“Cryptographic kernel 430 comprises a signing unit 440. The signing unit 440 is configured to access the high security data area and compute the signature from the private key. For example, signing unit 440 may execute a signing algorithm that corresponds to the signature algorithm, e.g., the ECDSA signing algorithm, etc. The correct signing key may be selected through a key index or key identifier which may also be supplied on interface 460. The signing unit 440 may directly receive a hash value to sign from interface 460 and transaction application 330. This keeps the cryptographic kernel small, as it does not need a hashing algorithm. In theory, this keeps the threat that a rogue or hacked transaction application may perform transactions that are not authorized by the user. Still, this set-up provides several advantages, an attacker cannot extract the private key from area 420, so that the attacker needs to have access to device 300 at the time he wants to attack a particular key.” (Para. 0136).
wherein the transaction is recorded on the distributed ledger with a wallet identifier associated with the device, (“a transaction output comprises a so-called address, e.g., a key identifier. Later transfers of that output require a signature by the corresponding key. For example, a transaction input may comprise a reference to a previous transaction, and an unlock script, e.g., a scriptSig. For example, a transaction output may comprise a locking script. . . The public key must match a hash given in the locking script of the redeemed output.” (Para. 0108) – a wallet identifier reads on the address/key identifier used in transaction outputs; “the transaction may comprise a target of the transfer, e.g., in the form of a locking script, such as a pay to public hash script.” (Para. 0135); “The public key is hashed by SHA 256 followed by RIPEMD 160 to obtain the hashed public key which when encoded in Base 58 gives the bitcoin address associated with the random private key selected in the first step. The bitcoin address is analogous to a bank account number to which the bitcoins are sent in a transaction” (Para. 0165) – transactions are recorded in blocks on the ledger, and each transaction output carries the address (e.g. key identifier) in its locking script, such that the ledger record of the transaction includes the wallet identifier; “keys may be associated with . . . a corresponding key identifier. The key identifier may comprise a hash over the public key corresponding to the private key. For example, the key identifier may be a bitcoin address. A Bitcoin address is a 160-bit hash of the public portion of a public/private ECDSA key pair.” (Para. 0129)
the method further comprising the step of: generating the wallet identifier associated with the device on the distributed ledger by, prior to the receiving the instruction to execute a transaction and in order to register the device with the distributed ledger, verifying the device . . . (“If security domains are not available, one may alternatively use hardware fingerprinting. For example, the cryptographic kernel application may be configured to obtain a fingerprint of the blockchain transaction device, and to refuse the signing interface if the obtained fingerprint does not agree to a previously stored fingerprint. The binding number 327 discussed above may be part of such a fingerprint.” (Para. 0161); “There are various ways in which the high security data area may be used to store private keys. For example in an embodiment, the private keys may be encrypted, e.g., they may require decryption and/or other additional processing before the private keys stored in the high security data area can be used. For example, the low security data area may comprise an optional binding number 327 which is needed to access the private keys in the high security data area. The binding number further hardens access to the private keys. For example, the binding number may help against attacks in which the SIM card is inserted into another device. For example, a private key may need to be decrypted using the binding number. The binding number may be 128 bits, or more. The binding number may be included on a signing interface, or on a key generation interface. The binding number may be hidden in the device or obfuscated.” (Para. 0154); “The security procedures could impede on the backup of SIM data. Instead, the transaction application may connect to a new cryptographic kernel on a new SIM card by the binding procedure. When a SIM is replaced, the binding needs to be done again. In a seed based application, a user may enter the seed, e.g., as a passphrase, in particular a mnemonic multiple word passphrase, to recover the keys into the SIM.” (Para. 0160)
wherein the different physical communication channel is . . . (“The final applet has access to a random private key. The private key will be securely stored in the SIM card and will not be exposed from the secure element of the SIM card. Together with the cryptographic kernel that handles the private key operations, a transaction application, e.g., an android application, can be developed where the blockchain (e.g. bitcoin) transactions are generated. These transactions may later be sent to the java card applet in the SIM card where the transactions are signed. The signed transactions are sent back to the transaction application from where the transactions are published to the blockchain network. Therefore, the secret private key associated with a blockchain address never leaves the secure element of the SIM card. This is pictographically represented in FIG. 5. FIG. 5 shows a mobile phone 500 with a SIM card on which is installed a transaction application 510 and a cryptographic kernel 520 respectively. The phone can connect to the blockchain network 530. FIG. 5 schematically shows 5 parts in performing a transaction.” (Para. 0172); “If security domains are not available, one may alternatively use hardware fingerprinting. For example, the cryptographic kernel application may be configured to obtain a fingerprint of the blockchain transaction device, and to refuse the signing interface if the obtained fingerprint does not agree to a previously stored fingerprint. The binding number 327 discussed above may be part of such a fingerprint.” (Para. 0161); “In an embodiment, cryptographic kernel 300 comprises a key generation unit 450 configured to generate a new public/private key pair. For example, key generation unit 450 may comprise a creation unit 451 configured to generate a public key and private key pair. For example, the creation unit 451 may execute a key generation algorithm according to ECDSA. In an embodiment, the high security processor circuit is able to calculate the private key from the seed, etc., e.g., by first computing the public key.” (Para. 0140)
wherein the secure communication channel between the UICC and the server is initiated using a shared secret, wherein the secret is shared between the UICC and the server by: (“Another possibility is that the transaction application is capable of reading the high security data area, yet that data is encrypted with a secret key under control of the cryptographic kernel. In any case, the transaction application may have indirect access to the high security data area, through the cryptographic kernel application, e.g., by signing, etc.” (Para. 0127); “For example, the signing interface may receive the key derivation information, and binding number 327 (if any). The signing unit 440 combines this information with seed 426 compute the private key and perform the requested signing.” (Para. 0158); “Security Domains (SD) are used for the management of Service Provider applications on a SIM card, e.g., issued by the Mobile Network Operator (MNO).” (Para. 0159))
storing the shared secret within the UICC and within a telecommunications network component when the UICC is manufactured; and (“Examples of a secure element in phones include the chip directly embedded into the phone's hardware, a SIM/UICC card provided by your network operator, and an SD card that can be inserted into the mobile phone.” (Para. 0017); “For example, in an embodiment, the blockchain transaction device is comprised in a mobile phone. The hardware element may be comprised in a Subscriber Identity Module (SIM).” (Para. 0113); “Security Domains (SD) are used for the management of Service Provider applications on a SIM card, e.g., issued by the Mobile Network Operator (MNO).” (Para. 0159))
the telecommunications network component sending the shared secret to the server, wherein the telecommunications network component is a component within a core network of the telecommunications network. (“This process is controlled by the MNO and provides an extra layer of security,.” (Para. 0178); “The communication between the android application and the Java card applet can be established as given below. One of the attractive features of security SIM domains enforces access control from phone apps.” (Para. 0178); “The app allowed to access the secure SIM locker has to be exactly the same as the whitelisted app.” (Para. 0178))
Van de Ruit does not disclose:
• “short-message service (SMS)” and “using a different physical communication channel to the secure communication channel” (claim 1).
However, as per Claim 1, Armstrong in the analogous art of cryptographic transactions, teaches: “SMS” and “using a different physical communication channel to the secure communication channel” (See “The user also includes a two-factor code which the user may obtain through a mobile application or via SMS communication with the first host computer system 14.” (Para. 0153); See also Fig. 26, and Fig. 57, element 262.
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Van de Ruit with the technique of Armstrong to include generating the wallet identifier on the distributed ledger only upon successful verification of the device over a different physical communication channel (e.g. SMS). Therefore, the incentives of strengthening account/device binding and preventing unauthorized wallet activation provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Van de Ruit does not disclose:
• “using a public and private key pair stored within the distributed ledger” (claim 1).
However, as per Claim 1, Komandur in the analogous art of multi-key cryptographic transactions, teaches: “using a public and private key pair stored within the distributed ledger” (See “The last step endorses the proposal (calls the endorsement system chaincode that enforces the endorsement policy and signs the proposed transaction).” (Para. 0389); “There is a single public key that is held by all peers and each of the n peers has a unique private key. When a digital signature is produced, any peer can verify the signature by using the single public key.” (Para. 0394); “Endorsers' certificates and keys can be stored in a keystore located in /bchainlbigap-certificates/crypto/peerOrganization. . . Node.js servers can also have their own keystore (/bchain/bigap-certificates/fabric-user-keys and /bchain/bigap-cerfificates/fabric-user-certificates) that will contain certificates and private keys for all users that will be accessing the blockchain via the BIGAP application running on the servers.” (Para. 0150-153))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Van de Ruit, having a UICC-secured wallet/transaction flow with on-chain use of a wallet/address identifier, with the technique of Komandur, having permission ledger peers/endorsers holding key pairs and signing the transaction at the distributed ledger using a public/private key pair stored in the ledgers nodes. Therefore, the incentives of stronger security and policy enforcement at the ledger nodes, reduced reliance on end-user device keys, and improved auditability provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 2, Van de Ruit teaches:
The method of claim 1, wherein the secure communication between the UICC and the server is initiated using a public and private key pair stored on the UICC. (“The transaction application is generally more complicated software and more likely to be compromised than the cryptographic kernel. Moreover, because fewer requirements are placed on the cryptographic kernel, a higher level of security can be achieved, e.g., by using the security provisions of the device. For example, in an embodiment the high and low security data areas may be provided in different memories. Access to the high security data area may be more restricted, e.g. restricted to the cryptographic kernel application. Likewise, the transaction application and the cryptographic kernel application may be executed on different processor circuits. For example, the memory for the high security data area and the processor for the cryptographic kernel may be combined in a hardware element which may be releasably connected to the transaction device. In an advantageous embodiment, the hardware element is a SIM card, and the transaction application is implemented in a mobile phone in which the SIM card may be inserted. The private key stored in the high security data area may be in any representation, e.g., the private key may be encrypted or may be stored as a seed from which the private key may be computed. In particular, the high security data stores information enabling derivation of the private key. A seed is considered data determining a private key, as it is required for deriving the key notwithstanding that other data may be involved that may also determine the private key. Determining the private key from a seed and optional further data is deterministic.” (Para. 0015); “Blockchain transaction device 300 comprises an electronic memory system comprising a high security data area 420 and a low security data area 320. Preferably, the protection of the high security data area 420 is at least as good as that of low security data area 320. For example, read access to the high security data area may only be provided to the hardware element, or to the cryptographic kernel application, or to an application running in a protected mode, e.g. kernel mode. For example, blockchain transaction device 300 may be arranged so that the transaction application has access to the low security data area, e.g., read and write access. For example, the low security data area may be used to store public keys, and/or other data related to the blockchain. For example, blockchain transaction device 300 may be arranged so that the transaction application does not have access to the high security data area; in particular no read access, but in embodiments, also no write access. For example, blockchain transaction device 300 may be arranged so that the cryptographic kernel has access to the high security data area, e.g., read and write access. The cryptographic kernel may have access to the low security data area, but this is not needed; in fact in many embodiments, the cryptographic kernel does not have such access. For example, the high security data area may be used to store private keys, and/or other data related to the blockchain.” (Para. 0126); “The final applet has access to a random private key. The private key will be securely stored in the SIM card and will not be exposed from the secure element of the SIM card. Together with the cryptographic kernel that handles the private key operations, a transaction application, e.g., an android application, can be developed where the blockchain (e.g. bitcoin) transactions are generated. These transactions may later be sent to the java card applet in the SIM card where the transactions are signed. The signed transactions are sent back to the transaction application from where the transactions are published to the blockchain network. Therefore, the secret private key associated with a blockchain address never leaves the secure element of the SIM card. This is pictographically represented in FIG. 5. FIG. 5 shows a mobile phone 500 with a SIM card on which is installed a transaction application 510 and a cryptographic kernel 520 respectively. The phone can connect to the blockchain network 530. FIG. 5 schematically shows 5 parts in performing a transaction.” (Para. 0172).
As per Claim 3, Van de Ruit teaches:
The method of claim 2 further comprising the step of generating the public and private key pair within the UICC. (“In an embodiment, cryptographic kernel 300 comprises a key generation unit 450 configured to generate a new public/private key pair. For example, key generation unit 450 may comprise a creation unit 451 configured to generate a public key and private key pair. For example, the creation unit 451 may execute a key generation algorithm according to ECDSA. In an embodiment, the high security processor circuit is able to calculate the private key from the seed, etc., e.g., by first computing the public key.” (Para. 0140); “An embodiment using seeds is shown in FIG. 4a . The private key is stored in the high security data area as a seed 426. For each private key, the high security data area comprises key derivation information; shown are key derivation information 428 and 429 for keys 321 and 324 respectively. The cryptographic kernel application is configured to compute the private key from the seed if the private key is needed. For example, to compute the private key corresponding to key 321, a key derivation function may be applied to binding number 327, seed 426, and key derivation information 428. The key derivation may also be hierarchical, e.g., using multiple application of a key derivation function. Seed 426 may be generated by the cryptographic kernel, but it may also be set by the user, e.g., through the transaction application. The latter has the advantage that the seed can be re-entered if the SIM is lost.” (Para. 0156).
As per Claim 4, Van de Ruit teaches:
The method according to claim 1, wherein the telecommunications network component within the core network comprises an Authentication Center (AuC). (“There are various ways in which the high security data area may be used to store private keys. For example in an embodiment, the private keys may be encrypted, e.g., they may require decryption and/or other additional processing before the private keys stored in the high security data area can be used. For example, the low security data area may comprise an optional binding number 327 which is needed to access the private keys in the high security data area. The binding number further hardens access to the private keys. For example, the binding number may help against attacks in which the SIM card is inserted into another device. For example, a private key may need to be decrypted using the binding number. The binding number may be 128 bits, or more. The binding number may be included on a signing interface, or on a key generation interface. The binding number may be hidden in the device or obfuscated” (Para. 0154); “The binding number may also be used as seed. For example, key derivation, and/or a further seed may be stored in the high security data area. The private key to be used may then be derived by applying a key derivation function (KDF) to the binding number 327, further seed, and key derivation information. The binding number 327 is optional.” (Para. 0155); “For example, the signing interface may receive the key derivation information, and binding number 327 (if any). The signing unit 440 combines this information with seed 426 compute the private key and perform the requested signing. For example, the key generation interface may receive the key derivation information, and binding number 327 (if any). The key generation unit 450 combines this information with seed 426 to compute the private key. Next the corresponding public key may be computed and/or the key identifier and exported to the transaction application.” (Para. 0158)
As per Claim 5, Van de Ruit teaches:
The method of claim 4, wherein the telecommunications network component within the core network comprises a home subscriber server (HSS). (“There are various ways in which the high security data area may be used to store private keys. For example in an embodiment, the private keys may be encrypted, e.g., they may require decryption and/or other additional processing before the private keys stored in the high security data area can be used. For example, the low security data area may comprise an optional binding number 327 which is needed to access the private keys in the high security data area. The binding number further hardens access to the private keys. For example, the binding number may help against attacks in which the SIM card is inserted into another device. For example, a private key may need to be decrypted using the binding number. The binding number may be 128 bits, or more. The binding number may be included on a signing interface, or on a key generation interface. The binding number may be hidden in the device or obfuscated” (Para. 0154); “The binding number may also be used as seed. For example, key derivation, and/or a further seed may be stored in the high security data area. The private key to be used may then be derived by applying a key derivation function (KDF) to the binding number 327, further seed, and key derivation information. The binding number 327 is optional.” (Para. 0155); “If security domains are not available, one may alternatively use hardware fingerprinting. For example, the cryptographic kernel application may be configured to obtain a fingerprint of the blockchain transaction device, and to refuse the signing interface if the obtained fingerprint does not agree to a previously stored fingerprint. The binding number 327 discussed above may be part of such a fingerprint.” (Para. 0161).
As per Claim 6, Van de Ruit teaches:
The method of claim 5, wherein the telecommunications network component is a home location register, HLR. (“The final applet has access to a random private key. The private key will be securely stored in the SIM card and will not be exposed from the secure element of the SIM card. Together with the cryptographic kernel that handles the private key operations, a transaction application, e.g., an android application, can be developed where the blockchain (e.g. bitcoin) transactions are generated. These transactions may later be sent to the java card applet in the SIM card where the transactions are signed. The signed transactions are sent back to the transaction application from where the transactions are published to the blockchain network. Therefore, the secret private key associated with a blockchain address never leaves the secure element of the SIM card. This is pictographically represented in FIG. 5. FIG. 5 shows a mobile phone 500 with a SIM card on which is installed a transaction application 510 and a cryptographic kernel 520 respectively. The phone can connect to the blockchain network 530. FIG. 5 schematically shows 5 parts in performing a transaction.” (Para. 0172); “If security domains are not available, one may alternatively use hardware fingerprinting. For example, the cryptographic kernel application may be configured to obtain a fingerprint of the blockchain transaction device, and to refuse the signing interface if the obtained fingerprint does not agree to a previously stored fingerprint. The binding number 327 discussed above may be part of such a fingerprint.” (Para. 0161); “The security procedures could impede on the backup of SIM data. Instead, the transaction application may connect to a new cryptographic kernel on a new SIM card by the binding procedure. When a SIM is replaced, the binding needs to be done again. In a seed based application, a user may enter the seed, e.g., as a passphrase, in particular a mnemonic multiple word passphrase, to recover the keys into the SIM.” (Para. 0160)
As per Claim 7, Van de Ruit teaches:
The method of claim 4, wherein the shared secret is generated using generic bootstrapping architecture, GBA. (“The binding number may also be used as seed. For example, key derivation, and/or a further seed may be stored in the high security data area. The private key to be used may then be derived by applying a key derivation function (KDF) to the binding number 327, further seed, and key derivation information. The binding number 327 is optional.” (Para. 0155); “An embodiment using seeds is shown in FIG. 4a . The private key is stored in the high security data area as a seed 426. For each private key, the high security data area comprises key derivation information; shown are key derivation information 428 and 429 for keys 321 and 324 respectively. The cryptographic kernel application is configured to compute the private key from the seed if the private key is needed. For example, to compute the private key corresponding to key 321, a key derivation function may be applied to binding number 327, seed 426, and key derivation information 428. The key derivation may also be hierarchical, e.g., using multiple application of a key derivation function. Seed 426 may be generated by the cryptographic kernel, but it may also be set by the user, e.g., through the transaction application. The latter has the advantage that the seed can be re-entered if the SIM is lost.” (Para. 0156); “If security domains are not available, one may alternatively use hardware fingerprinting. For example, the cryptographic kernel application may be configured to obtain a fingerprint of the blockchain transaction device, and to refuse the signing interface if the obtained fingerprint does not agree to a previously stored fingerprint. The binding number 327 discussed above may be part of such a fingerprint.” (Para. 0161)
As per Claim 8, Van de Ruit teaches:
The method of claim 7, wherein the secret is shared between the UICC and the server by: generating the shared secret within the UICC and a bootstrapping server function, BSF; and the BSF sending the shared secret to the server. (“The binding number may also be used as seed. For example, key derivation, and/or a further seed may be stored in the high security data area. The private key to be used may then be derived by applying a key derivation function (KDF) to the binding number 327, further seed, and key derivation information. The binding number 327 is optional.” (Para. 0155); “An embodiment using seeds is shown in FIG. 4a . The private key is stored in the high security data area as a seed 426. For each private key, the high security data area comprises key derivation information; shown are key derivation information 428 and 429 for keys 321 and 324 respectively. The cryptographic kernel application is configured to compute the private key from the seed if the private key is needed. For example, to compute the private key corresponding to key 321, a key derivation function may be applied to binding number 327, seed 426, and key derivation information 428. The key derivation may also be hierarchical, e.g., using multiple application of a key derivation function. Seed 426 may be generated by the cryptographic kernel, but it may also be set by the user, e.g., through the transaction application. The latter has the advantage that the seed can be re-entered if the SIM is lost.” (Para. 0156); “If the root seed is not generated by the cryptographic kernel then deriving of more child keys may be covered by the transaction application. The latter may use the cryptographic kernel only to store the associated seed and private keys. For example, the cryptographic kernel may be configured to sign transactions but not to generate the keys, which is done by the transaction application. If the root seed is generated by the cryptographic kernel then the derivation function may be implemented in the cryptographic kernel. The root seed can be generate and stored in the hardware element, e.g., by the cryptographic kernel.” (Para. 0151)
As per Claim 12, Van de Ruit teaches:
The method according to claim 1 wherein the transaction is a blockchain transaction. (“The final applet has access to a random private key. The private key will be securely stored in the SIM card and will not be exposed from the secure element of the SIM card. Together with the cryptographic kernel that handles the private key operations, a transaction application, e.g., an android application, can be developed where the blockchain (e.g. bitcoin) transactions are generated. These transactions may later be sent to the java card applet in the SIM card where the transactions are signed. The signed transactions are sent back to the transaction application from where the transactions are published to the blockchain network. Therefore, the secret private key associated with a blockchain address never leaves the secure element of the SIM card. This is pictographically represented in FIG. 5. FIG. 5 shows a mobile phone 500 with a SIM card on which is installed a transaction application 510 and a cryptographic kernel 520 respectively. The phone can connect to the blockchain network 530. FIG. 5 schematically shows 5 parts in performing a transaction.” (Para. 0172); “Signed transaction is broadcast to the bitcoin network.” (Para. 0177); “Accordingly, in an embodiment a transaction may be done in the application, e.g., formatted, and signing the transaction may be done in a hardware element, such as a Secure Element. In turn the hardware element may return a signed transaction that can be broadcasted to the associated blockchain/cryptocurrency network by the application which holds the wallet function.” (Para. 0139).
As per Claim 13, Van de Ruit teaches:
The method according to claims 1, wherein the transaction is a credit card or bank transaction. (“The final applet has access to a random private key. The private key will be securely stored in the SIM card and will not be exposed from the secure element of the SIM card. Together with the cryptographic kernel that handles the private key operations, a transaction application, e.g., an android application, can be developed where the blockchain (e.g. bitcoin) transactions are generated. These transactions may later be sent to the java card applet in the SIM card where the transactions are signed. The signed transactions are sent back to the transaction application from where the transactions are published to the blockchain network. Therefore, the secret private key associated with a blockchain address never leaves the secure element of the SIM card. This is pictographically represented in FIG. 5. FIG. 5 shows a mobile phone 500 with a SIM card on which is installed a transaction application 510 and a cryptographic kernel 520 respectively. The phone can connect to the blockchain network 530. FIG. 5 schematically shows 5 parts in performing a transaction.” (Para. 0172); “A block may comprise one or more transactions. Some embodiments, may allow blocks with zero transactions, e.g., to support timely delivery of new blocks. The transactions may be transactions on cryptocurrency but this is not needed. The transactions may be registrations of transfers, e.g., of domain names. They may register data, e.g., sensor values. Typically, each of the blocks comprises a consensus proof. The consensus proofs are computed over the one or more transactions. New blocks are created by blockchain management devices, which may be connected in a peer to peer network. Various equivalent Cryptographically Secured Distributed Ledger technologies may be used such as: Blockchain, Hashgraph, Directed Acyclic Graph, etc., as such technologies support the same concepts: consensus algorithms, cryptocurrencies, tokens, etc.” (Para. 0104); “blockchain may be used to record a large variety of other transactions; ranging from distributed notaries to domain names.” (Para. 0004).
As per Claim 17, Van de Ruit teaches:
The system according to claims 14, wherein the UICC of the device further comprises memory storing a secure applet comprising instructions to respond to verification requests. (“The final applet has access to a random private key. The private key will be securely stored in the SIM card and will not be exposed from the secure element of the SIM card. Together with the cryptographic kernel that handles the private key operations, a transaction application, e.g., an android application, can be developed where the blockchain (e.g. bitcoin) transactions are generated. These transactions may later be sent to the java card applet in the SIM card where the transactions are signed. The signed transactions are sent back to the transaction application from where the transactions are published to the blockchain network. Therefore, the secret private key associated with a blockchain address never leaves the secure element of the SIM card. This is pictographically represented in FIG. 5. FIG. 5 shows a mobile phone 500 with a SIM card on which is installed a transaction application 510 and a cryptographic kernel 520 respectively. The phone can connect to the blockchain network 530.” (Para. 0172); “In an embodiment, cryptographic kernel 300 comprises a key generation unit 450 configured to generate a new public/private key pair. For example, key generation unit 450 may comprise a creation unit 451 configured to generate a public key and private key pair. For example, the creation unit 451 may execute a key generation algorithm according to ECDSA. In an embodiment, the high security processor circuit is able to calculate the private key from the seed, etc., e.g., by first computing the public key.” (Para. 0140); “For example, the signing interface may receive the key derivation information, and binding number 327 (if any). The signing unit 440 combines this information with seed 426 compute the private key and perform the requested signing. For example, the key generation interface may receive the key derivation information, and binding number 327 (if any). The key generation unit 450 combines this information with seed 426 to compute the private key. Next the corresponding public key may be computed and/or the key identifier and exported to the transaction application.” (Para. 0158)
As per Claim 18, Van de Ruit teaches:
The system according to claim 14, wherein the transactions are associated with an identifier of the device. (“The export unit 452 may be configured to store the private key in the high security data area, and export the public key to the transaction application. For example, the public key may be associated with a key index or key identifier by export unit 452. For example, the key index may be a sequential or random number. For example, the key identifier may be hash over the public key. The export unit may also omit this information, e.g., transaction unit 330 may compute the key identifier itself.” (Para. 0142); “Note that it is not needed that the public key is stored in the low security data area 320, instead it may be stored in the high security data area. In that case, the export unit 452 may export a key identifier of the public key to the transaction application. The key identifier may be used by the transaction application to receive assets that are bound to the new key. If the public key is stored in the high security data area, then the public key may be exported to the transaction application when a transaction is generated, e.g., together with the needed signature.” (Para. 0143); “Instead of storing the derivation information in the high security area, the key derivation data, e.g., data 428 and 429, may be stored in the low security data area; this is illustrated in FIG. 4b . In an embodiment, the high security area only needs to store the seed. If a private key is needed, it is generated from information stored in the low security part and the seed, e.g., through a key derivation function, e.g., by applying a hash function. Storing the derivation information outside the high security data area has the advantage that it may be backed-up, e.g., in the cloud, e.g., by the transaction application. This approach is taken a step further in FIG. 4c . In this example, the low security data area stores both the key derivation data and the information on which keys are available, e.g., the key indices 422, 425. This means that the cryptographic kernel relies on the transaction device to learn which keys are available on the transaction device. On the other hand, the seed 426 is required, in the sense that without it the private keys cannot be recovered. Even if the low security data area stores the public key, the key derivation information, the key identifier, etc., then still the private key cannot be obtained, if there is no access to seed 426. For signing, the cryptographic kernel can be supplied with the information needed to derive the private key from seed 426. For key generation, the cryptographic kernel can return all the information that needs to be stored, except for seed 426.” (Para. 0157)
As per Claim 20, Van de Ruit teaches:
The computer storage media of claim 19, wherein the secure communication between the UICC and the server is initiated using a public and private key pair stored on the UICC. (“The transaction application is generally more complicated software and more likely to be compromised than the cryptographic kernel. Moreover, because fewer requirements are placed on the cryptographic kernel, a higher level of security can be achieved, e.g., by using the security provisions of the device. For example, in an embodiment the high and low security data areas may be provided in different memories. Access to the high security data area may be more restricted, e.g. restricted to the cryptographic kernel application. Likewise, the transaction application and the cryptographic kernel application may be executed on different processor circuits. For example, the memory for the high security data area and the processor for the cryptographic kernel may be combined in a hardware element which may be releasably connected to the transaction device. In an advantageous embodiment, the hardware element is a SIM card, and the transaction application is implemented in a mobile phone in which the SIM card may be inserted. The private key stored in the high security data area may be in any representation, e.g., the private key may be encrypted or may be stored as a seed from which the private key may be computed. In particular, the high security data stores information enabling derivation of the private key. A seed is considered data determining a private key, as it is required for deriving the key notwithstanding that other data may be involved that may also determine the private key. Determining the private key from a seed and optional further data is deterministic.” (Para. 0015); “Blockchain transaction device 300 comprises an electronic memory system comprising a high security data area 420 and a low security data area 320. Preferably, the protection of the high security data area 420 is at least as good as that of low security data area 320. For example, read access to the high security data area may only be provided to the hardware element, or to the cryptographic kernel application, or to an application running in a protected mode, e.g. kernel mode. For example, blockchain transaction device 300 may be arranged so that the transaction application has access to the low security data area, e.g., read and write access. For example, the low security data area may be used to store public keys, and/or other data related to the blockchain. For example, blockchain transaction device 300 may be arranged so that the transaction application does not have access to the high security data area; in particular no read access, but in embodiments, also no write access. For example, blockchain transaction device 300 may be arranged so that the cryptographic kernel has access to the high security data area, e.g., read and write access. The cryptographic kernel may have access to the low security data area, but this is not needed; in fact in many embodiments, the cryptographic kernel does not have such access. For example, the high security data area may be used to store private keys, and/or other data related to the blockchain.” (Para. 0126); “The final applet has access to a random private key. The private key will be securely stored in the SIM card and will not be exposed from the secure element of the SIM card. Together with the cryptographic kernel that handles the private key operations, a transaction application, e.g., an android application, can be developed where the blockchain (e.g. bitcoin) transactions are generated. These transactions may later be sent to the java card applet in the SIM card where the transactions are signed. The signed transactions are sent back to the transaction application from where the transactions are published to the blockchain network. Therefore, the secret private key associated with a blockchain address never leaves the secure element of the SIM card. This is pictographically represented in FIG. 5. FIG. 5 shows a mobile phone 500 with a SIM card on which is installed a transaction application 510 and a cryptographic kernel 520 respectively. The phone can connect to the blockchain network 530. FIG. 5 schematically shows 5 parts in performing a transaction.” (Para. 0172).
Conclusion
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.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20150222631 (Chastain), discussing how “[m]utual authentication is then performed directly between user device 301 and user device 302 using the bearer path authentication keyset 341 (step 424). This authentication process is performed by the authentication management functions within the UICC of user device 301 and user device 302.” (Para. 0037) and “The user of device 302 must authenticate with the device before a signaling session can take place between device 302 and the secure application server 330. This is done (step 416) using user interface keyset 314, which may be different from user interface keyset 313. The user authentication process is performed by the authentication management function within the UICC of user device 302. The secure application server 330 then instructs user device 302 to establish a secure signaling session with the SAS (step 418). The secure application server 330 and the UICC of user device 302 mutually authenticate each other using signaling authentication keyset 333 (which may be different from signaling authentication keyset 331). The secure application server 330 is authenticated by the authentication management function within the UICC of user device 302” (Para. 0034)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. 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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/ARI SHAHABI/Primary Examiner, Art Unit 3697
Prosecution Insights