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 .
Status of Claims
Claims 1-20 are pending. Claim 21 is cancelled.
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.
Claim 5 is 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. Claim 5 recites “an electronic communication network communicably coupling the first device of the first system and a device of the second system”. However, applicant’s specification and claims as originally filed in the parent application (App. No. 16/745,334), make no reference to an electronic communication network communicably coupling the first device of the first system and a device of the second system. The specification instead refers to an “out-of-band channel”, e.g. [0070], “During the verification flow, the out-of-band channel 602 is used. It can be at least one of the following: a direct conversation, phone call, email communication, SMS, communication by an Internet chat application, or any other communication channel that does not rely upon the API”. It is clear from the above that the out-of-band channel refers to any means of communicating information from one device to another, and makes no specific reference to an electronic communication network. While some examples (e.g. email communication, SMS, Internet chat application) could potentially be seen as utilizing electronic communication means, they are not broadly representative of the claimed genus of an ”electronic communication network”. See MPEP § 2163.05: “A "representative number of species" means that the species which are adequately described are representative of the entire genus. Thus, when there is substantial variation within the genus, one must describe a sufficient variety of species to reflect the variation within the genus.” Therefore, claim 1 is rejected for failing to comply with the written description requirement.
Claim 14 is 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. Claim 14 contains similar subject matter to claim 5 and is therefore rejected for similar reasons.
Claim 3 is 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. Claim 3 recites “generating an encrypted verification message by encrypting the verification message using the public encryption key of the receiver system; and generating the signed, encrypted, verification message by encrypting the encrypted verification message using the private encryption key of the sender system”, clearly indicating that the message is first encrypted with the receiver’s public key, and then signed with the sender’s private key. However, there is nothing in the specification and claims as originally filed in the parent application (App. No. 16/745,334) which indicates the order in which the message is encrypted/signed. The specification recites: [0068] “The disclosed method comprises: obtaining, at a Sender's device, a receiver's Public Key 214 provided by API; encrypting, at the Sender's device, a verification message with the Receiver's Public Key 214 and the Sender's Private Key 206; sending the encrypted verification message from the Sender's device to the Receiver's device through the out-of-band channel”. However, this does not explicitly recite the order in which the message is encrypted using the keys. Further, if one is to take the order in which the keys are presented as the order in which they are applied, this is contradicted by the next step: “decrypting, at the Receiver's device, the encrypted verification message using Receiver's Private Key 206 and Sender's Public Key 214”. If the keys are meant to be applied in the order presented, than decrypting using the Receiver’s Private Key and the Sender’s Public Key in order would not arrive at the correct result if the message were originally encrypted with the Receiver’s Public Key followed by the Sender’s Private Key. Therefore, it is clear that no order is implied. As such, the specification does not appear to contain any subject matter which discloses an order in which the keys are applied. Therefore, claim 3 is rejected for failing to comply with the written description requirement.
Claim 12 is 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. Claims 12 contains similar subject matter to claim 3 and is therefore rejected for similar reasons.
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- 5, 11-14, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Feinberg et al (US 11,128,609), and further in view of Hyun et al (PGPUB 2021/0019748) and Mathias et al (PGPUB 2020/0052905).
Regarding Claims 1 and 20:
Feinberg teaches a method and non-transitory computer-readable storage medium, comprising executable instructions that, are executed by a processor of a first device of a first system to perform:
establishing, by a first device of a first system, cryptographic trust with a second system, wherein establishing cryptographic trust includes (col 3 line 7-56, an asymmetric cryptographic communication scheme configured to provide a more reliable user authentication and/or key exchange protocol, referred to as “Secure Authentication and Identity Loop” (SAIL); herein, for conducting user authentication and key exchange using SAIL, both a first user (source) and a second user (destination) utilize asymmetric keys to encrypt, sign and recover content for use in securely identifying and authenticating each of the users prior to commencing a communication session; first electronic device associated with the first user, and second electronic device associated with the second user):
obtaining, from a service provider server, a public encryption key of the second system (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users; as shown, a first user (User A) 110.sub.1 is associated with a first public key (PUKA) 160 that is stored within the key depository 150; similarly, a second public key (PUKB) 162 associated with the second user (User B) 110.sub.2 is stored within the key depository 150; hence, the first electronic device 110.sub.1 is able to retrieve PUKB 162, and the second electronic device 110.sub.2 is able to retrieve PUKA 160, as shown in FIGS. 3B-4B);
generating a signed, encrypted, verification message by encrypting first verification message content using the public encryption key of the second system and a private encryption key of the first system (col 8 line 38-63, the first user (User A) selects content to be included as part of the first cryptographically protected transmission, where the content is temporarily stored within the first electronic device and encrypted by logic within the first electronic device using the public key of second user (blocks 305 and 310); additionally, the encrypted content (e.g., entire encrypted content, a representation of the encrypted content such as its hash value, or a portion of the encrypted content or hash value) is signed with a private key of the first user (PUKA) to generate a first digital signature (block 315); col 8 line 64-col 9 line 14, the encryption/decryption logic within the first electronic device 110.sub.1 is configured to encrypt content 360 intended to be provided to User B (referenced as “Content_1 360”) using PUKB 162 to produce encrypted content 365);
sending the signed, encrypted, verification message to the second system (col 8 line 38-63, the encrypted content and the first digital signature are included as part of a first authentication message output from the first electronic device, which is provided as part of the first cryptographically protected transmission to a second electronic device associated with the second user (blocks 320 and 325));
receiving, from the second system, second verification message content (col 9 line 31-64, upon receipt of the first authentication message 375 of FIG. 3B, the second user (User B) disassembles the first authentication message to recover the first digital signature and the encrypted content (blocks 400 & 405); using the public key of the first user (PUKA), the cryptographic logic within the second electronic device verifies the first digital signature by recovering the signed content from the first digital signature and comparing the recovered signed content to the encrypted content that accompanies the digital signature (block 410); the cryptographic logic of the second electronic device may be configured to further decrypt the received encrypted content using the private key (PRKB) to recover the unencrypted content (content_1); col 10 line 34-65, the second user (User B), in particular logic within the second electronic device, combines the recovered unencrypted content (content_1) with the selected content (content_2); according to one embodiment of the disclosure, the combination may be a concatenation of content_1 and content_2 to produce a combined content (block 510); thereafter, the combined content is encrypted by cryptographic logic within the second electronic device using the public key (PUKA) of the first user (block 515); additionally, the encrypted combined content (e.g., entire encrypted combined content, a representation of the encrypted combined content such as its hash value, or a portion of the encrypted combined content or its hash value) may be signed with a private key of the second user (PRKB) to generate a second digital signature (block 520); the encrypted combined content and the second digital signature are included within a second authentication message being part of the second cryptographically protected transmission 144 provided from the second electronic device to the first electronic device associated with the first user (blocks 525 and 530)); and
verifying that the first verification message content matches the second verification message content (col 12 line 36-52, upon authentication, the cryptographic logic within the first electronic device 110.sub.1 may be further configured to extract the first content 680 from the combined content 670, and thereafter, compare the extracted first content 680 to a stored first content 360; if a match is determined, the second user (User B) is authenticated as, given the first content 360 was encrypted with a public key of the second user (PUKB) 162, only the second user having a corresponding private key (PRKB) 470 could gain access to the first content (content_1) 360).
Feinberg does not explicitly teach sending, via a channel that excludes the service provider server.
However, Hyun teaches the concept of sending, via a channel that excludes a service provider server (paragraph 164-166, the first server 420 (e.g., the server 108 in FIG. 1) may transmit the public key to the electronic device 101 (e.g., the processor 120 in FIG. 1); the public key may be necessary to perform authentication of a receipt for payment; in response to the request, the electronic device 101 (e.g., the processor 120 of FIG. 1) may receive the public key through the second wireless communication circuit (e.g., cellular wireless communication circuit); in operation 816, the electronic device 101 (e.g., the processor 120 of FIG. 1) may encrypt the receipt information by using the public key; the electronic device 101 may extract at least one piece of receipt information necessary for a refund, and may encrypt the extracted receipt information by using the public key; when one refund data reception method supported by the external payment device 410 is provided, the electronic device 101 (e.g., the processor 120 of FIG. 1) may prepare for refund transmission by using the corresponding reception method; by way of another example, when a plurality of refund data reception methods supported by the external payment device 410 is provided, the electronic device 101 (e.g., the processor 120 of FIG. 1) may transmit the request for the refund to the external electronic device 410 on the basis of the refund method using one (e.g., the near-field communication (NFC) module 861) selected by the user among the various refund methods; the electronic device 101 may transmit the request for the refund to the external payment device 410 through the wireless communication circuit (e.g., near-distance wireless communication circuit) on the basis of the selected refund method).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the out-of-band electronic communication network teachings of Hyun with the trusted device-to-device channel teachings of Feinberg, in order to improve the security environment by performing secure encrypted data exchanges using out-of-band networking technology, such as near-field communication, thereby requiring the devices exchanging keys to be in close proximity, reducing the ability for attackers to intercept the encrypted data or perform man-in-the-middle attacks without the device owners’ knowledge.
Neither Feinberg nor Hyun explicitly teaches, in response to verifying, storing the public encryption key of the second system, signed with the private encryption key of the first system, at the service provider server.
However, Mathias teaches the concept of, in response to verifying, storing a public encryption key of a second system, signed with a private encryption key of a first system, at a service provider server (paragraph 225, when a key has been shared with a friend or family member, the system 110 should store a new public key of the friend, after having verified required signature (discussed in further detail below); in some embodiments, the standard transaction flow is used in this situation; in some embodiments, the following additional cryptographic elements are used, relative to a standard transaction flow for the owner: SE.sig, owner.SK, owner.Sig, friend.ePK/friend.eSK, friend.PK/friend.SK, friend.Cert, and KTS.sig.; in some embodiments, owner.SK is a long term private key in the owner's device used to sign the public key of a friend when sharing access to the owner's system; this key may be the same key as the one used in the standard transaction flow (named phone.SK); in some embodiments, owner.Sig is generated when the owner signs the friend's public key when the owner has verified that the identity, and the entitlements, are correct and that the key has been generated on an authentic secure element; paragraph 209, for key sharing, the key tracking server (KTS) 1250 records: a friend's public key, access rights for the friend, a generation counter for the friend, start and expiration dates, a key identifier, an SE signature, an owner signature, and a KTS signature).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the storing a signed key teachings of Mathias with the trusted device-to-device channel teachings of Feinberg in view of Hyun, in order to combine the benefits of remote key storage with digital signature based trust, thereby allowing users to access trusted keys from a variety of locations and devices, while also ensuring that the keys were not tampered with in the remote storage using a user-provided digital signature, thereby improving the security environment.
Regarding Claim 2:
Feinberg in view of Hyun and Mathias teaches the method of claim 1. In addition, Feinberg teaches wherein:
the public encryption key of the second system is a part of an asymmetric key pair that includes a private encryption key of the second system (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users (i.e. user keys, independent of device); as shown, a first user (User A) 110.sub.1 is associated with a first public key (PUKA) 160 that is stored within the key depository 150; similarly, a second public key (PUKB) 162 associated with the second user (User B) 110.sub.2 is stored within the key depository 150; hence, the first electronic device 110.sub.1 is able to retrieve PUKB 162, and the second electronic device 110.sub.2 is able to retrieve PUKA 160, as shown in FIGS. 3B-4B; col 3 line 7-28, for each asymmetric key pair, a public key and a corresponding private key are mathematical inverses, and thus, are commonly generated at the same time); and
the private encryption key of the first system is a part of an asymmetric key pair that includes a public encryption key of the first system (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users (i.e. user keys, independent of device); col 3 line 7-28, for each asymmetric key pair, a public key and a corresponding private key are mathematical inverses, and thus, are commonly generated at the same time).
Regarding Claim 3:
Feinberg in view of Hyun and Mathias teaches the method of claim 2. In addition, Feinberg teaches wherein generating the signed, encrypted, verification message includes:
generating an encrypted verification message by encrypting the first verification message content using the public encryption key of the second system (col 8 line 38-63, the first user (User A) selects content to be included as part of the first cryptographically protected transmission, where the content is temporarily stored within the first electronic device and encrypted by logic within the first electronic device using the public key of second user (blocks 305 and 310)); and
obtaining the signed, encrypted, verification message by encrypting the encrypted verification message using the private encryption key of the first system (col 8 line 38-63, additionally, the encrypted content (e.g., entire encrypted content, a representation of the encrypted content such as its hash value, or a portion of the encrypted content or hash value) is signed with a private key of the first user (PUKA) to generate a first digital signature (block 315); col 8 line 64-col 9 line 14, the encryption/decryption logic within the first electronic device 110.sub.1 is configured to encrypt content 360 intended to be provided to User B (referenced as “Content_1 360”) using PUKB 162 to produce encrypted content 365).
Regarding Claim 4:
Feinberg in view of Hyun and Mathias teaches the method of claim 2. In addition, Feinberg teaches the method further comprising:
securely communicating with the second system by a second device of the first system (col 6 line 22-45, communication system 100 utilizing an improved asymmetric cryptographic communication scheme), wherein securely communicating includes:
obtaining, from the service provider server, the public encryption key of the second system (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users; as shown, a first user (User A) 110.sub.1 is associated with a first public key (PUKA) 160 that is stored within the key depository 150; similarly, a second public key (PUKB) 162 associated with the second user (User B) 110.sub.2 is stored within the key depository 150; hence, the first electronic device 110.sub.1 is able to retrieve PUKB 162, and the second electronic device 110.sub.2 is able to retrieve PUKA 160, as shown in FIGS. 3B-4B); and
sending, to the second system, data encrypted with the public encryption key of the second system (col 8 line 38-63, the first user (User A) selects content to be included as part of the first cryptographically protected transmission, where the content is temporarily stored within the first electronic device and encrypted by logic within the first electronic device using the public key of second user); and
Mathias teaches the public encryption key signed with the private encryption key of the first system (paragraph 225, when a key has been shared with a friend or family member, the system 110 should store a new public key of the friend, after having verified required signature (discussed in further detail below); in some embodiments, the standard transaction flow is used in this situation; in some embodiments, the following additional cryptographic elements are used, relative to a standard transaction flow for the owner: SE.sig, owner.SK, owner.Sig, friend.ePK/friend.eSK, friend.PK/friend.SK, friend.Cert, and KTS.sig.; in some embodiments, owner.SK is a long term private key in the owner's device used to sign the public key of a friend when sharing access to the owner's system; this key may be the same key as the one used in the standard transaction flow (named phone.SK); in some embodiments, owner.Sig is generated when the owner signs the friend's public key when the owner has verified that the identity, and the entitlements, are correct and that the key has been generated on an authentic secure element; paragraph 209, for key sharing, the key tracking server (KTS) 1250 records: a friend's public key, access rights for the friend, a generation counter for the friend, start and expiration dates, a key identifier, an SE signature, an owner signature, and a KTS signature); and
verifying the public encryption key of the second system with the public encryption key of the first system (paragraph 219, 233, check validity of an owner signature (e.g., using owner.PK [owner public key] received from system 110 during pairing)).
The rationale to combine Feinberg and Mathias is the same as provided for claim 1 due to the overlapping subject matter between claims 1 and 4.
Regarding Claim 5:
Feinberg in view of Hyun and Mathias teaches the method of claim 2. In addition, Hyun teaches wherein the channel that excludes the service provider server is separate from an electronic communication network communicably coupling the first device of the first system and a device of the second system (paragraph 164-166, the first server 420 (e.g., the server 108 in FIG. 1) may transmit the public key to the electronic device 101 (e.g., the processor 120 in FIG. 1); in response to the request, the electronic device 101 (e.g., the processor 120 of FIG. 1) may receive the public key through the second wireless communication circuit (e.g., cellular wireless communication circuit); by way of another example, when a plurality of refund data reception methods supported by the external payment device 410 is provided, the electronic device 101 (e.g., the processor 120 of FIG. 1) may transmit the request for the refund to the external electronic device 410 on the basis of the refund method using one (e.g., the near-field communication (NFC) module 861) selected by the user among the various refund methods; the electronic device 101 may transmit the request for the refund to the external payment device 410 through the wireless communication circuit (e.g., near-distance wireless communication circuit) on the basis of the selected refund method).
The rationale to combine Feinberg and Hyun is the same as provided for claim 1 due to the overlapping subject matter between claims 1 and 5.
Regarding Claim 11:
Feinberg teaches a system comprising:
a first device including:
a memory storing instructions for establishing cryptographic trust (col 4 line 66-col 5 line 35, memory with logic in the form of executable code); and
a processor that executes the instructions to establish cryptographic trust between the system and an external system, wherein to establish cryptographic trust between the system and the external system, the processor executes the instructions to (col 4 line 66-col 5 line 35, circuitry having data processing functionality; col 3 line 7-28, an asymmetric cryptographic communication scheme configured to provide a more reliable user authentication and/or key exchange protocol, referred to as “Secure Authentication and Identity Loop” (SAIL); herein, for conducting user authentication and key exchange using SAIL, both a first user (source) and a second user (destination) utilize asymmetric keys to encrypt, sign and recover content for use in securely identifying and authenticating each of the users prior to commencing a communication session):
obtain, from a service provider system, a public encryption key of the external system (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users; as shown, a first user (User A) 110.sub.1 is associated with a first public key (PUKA) 160 that is stored within the key depository 150; similarly, a second public key (PUKB) 162 associated with the second user (User B) 110.sub.2 is stored within the key depository 150; hence, the first electronic device 110.sub.1 is able to retrieve PUKB 162, and the second electronic device 110.sub.2 is able to retrieve PUKA 160, as shown in FIGS. 3B-4B), wherein the public encryption key of the external system is a part of an asymmetric key pair that includes a private encryption key of the external system (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users (i.e. user keys, independent of device); as shown, a first user (User A) 110.sub.1 is associated with a first public key (PUKA) 160 that is stored within the key depository 150; similarly, a second public key (PUKB) 162 associated with the second user (User B) 110.sub.2 is stored within the key depository 150; hence, the first electronic device 110.sub.1 is able to retrieve PUKB 162, and the second electronic device 110.sub.2 is able to retrieve PUKA 160, as shown in FIGS. 3B-4B; col 3 line 7-28, for each asymmetric key pair, a public key and a corresponding private key are mathematical inverses, and thus, are commonly generated at the same time);
generate a signed, encrypted, verification message, wherein, to generate the signed, encrypted, verification message, the processor executes the instructions to use the public encryption key of the external system and a private encryption key of the system to encrypt first verification message content (col 8 line 38-63, the first user (User A) selects content to be included as part of the first cryptographically protected transmission, where the content is temporarily stored within the first electronic device and encrypted by logic within the first electronic device using the public key of second user (blocks 305 and 310); additionally, the encrypted content (e.g., entire encrypted content, a representation of the encrypted content such as its hash value, or a portion of the encrypted content or hash value) is signed with a private key of the first user (PUKA) to generate a first digital signature (block 315); col 8 line 64-col 9 line 14, the encryption/decryption logic within the first electronic device 110.sub.1 is configured to encrypt content 360 intended to be provided to User B (referenced as “Content_1 360”) using PUKB 162 to produce encrypted content 365), wherein the private encryption key of the system is a part of an asymmetric key pair that includes a public encryption key of the system (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users (i.e. user keys, independent of device); col 3 line 7-28, for each asymmetric key pair, a public key and a corresponding private key are mathematical inverses, and thus, are commonly generated at the same time);
send, to the external system, the signed, encrypted, verification message (col 8 line 38-63, the encrypted content and the first digital signature are included as part of a first authentication message output from the first electronic device, which is provided as part of the first cryptographically protected transmission to a second electronic device associated with the second user (blocks 320 and 325));
receive, from the external system, second verification message content (col 9 line 31-64, upon receipt of the first authentication message 375 of FIG. 3B, the second user (User B) disassembles the first authentication message to recover the first digital signature and the encrypted content (blocks 400 & 405); using the public key of the first user (PUKA), the cryptographic logic within the second electronic device verifies the first digital signature by recovering the signed content from the first digital signature and comparing the recovered signed content to the encrypted content that accompanies the digital signature (block 410); the cryptographic logic of the second electronic device may be configured to further decrypt the received encrypted content using the private key (PRKB) to recover the unencrypted content (content_1); col 10 line 34-65, the second user (User B), in particular logic within the second electronic device, combines the recovered unencrypted content (content_1) with the selected content (content_2); according to one embodiment of the disclosure, the combination may be a concatenation of content_1 and content_2 to produce a combined content (block 510); thereafter, the combined content is encrypted by cryptographic logic within the second electronic device using the public key (PUKA) of the first user (block 515); additionally, the encrypted combined content (e.g., entire encrypted combined content, a representation of the encrypted combined content such as its hash value, or a portion of the encrypted combined content or its hash value) may be signed with a private key of the second user (PRKB) to generate a second digital signature (block 520); the encrypted combined content and the second digital signature are included within a second authentication message being part of the second cryptographically protected transmission 144 provided from the second electronic device to the first electronic device associated with the first user (blocks 525 and 530)); and
in response to a determination that the first verification message content matches the second verification message content, [perform a function] (col 12 line 36-52, upon authentication, the cryptographic logic within the first electronic device 110.sub.1 may be further configured to extract the first content 680 from the combined content 670, and thereafter, compare the extracted first content 680 to a stored first content 360; if a match is determined, the second user (User B) is authenticated as, given the first content 360 was encrypted with a public key of the second user (PUKB) 162, only the second user having a corresponding private key (PRKB) 470 could gain access to the first content (content_1) 360).
Feinberg does not explicitly teach send[ing], to the external system, via a channel that excludes the service provider system.
However, Hyun teaches the concept of sending, to an external system, via a channel that excludes a service provider system (paragraph 164-166, the first server 420 (e.g., the server 108 in FIG. 1) may transmit the public key to the electronic device 101 (e.g., the processor 120 in FIG. 1); the public key may be necessary to perform authentication of a receipt for payment; in response to the request, the electronic device 101 (e.g., the processor 120 of FIG. 1) may receive the public key through the second wireless communication circuit (e.g., cellular wireless communication circuit); in operation 816, the electronic device 101 (e.g., the processor 120 of FIG. 1) may encrypt the receipt information by using the public key; the electronic device 101 may extract at least one piece of receipt information necessary for a refund, and may encrypt the extracted receipt information by using the public key; when one refund data reception method supported by the external payment device 410 is provided, the electronic device 101 (e.g., the processor 120 of FIG. 1) may prepare for refund transmission by using the corresponding reception method; by way of another example, when a plurality of refund data reception methods supported by the external payment device 410 is provided, the electronic device 101 (e.g., the processor 120 of FIG. 1) may transmit the request for the refund to the external electronic device 410 on the basis of the refund method using one (e.g., the near-field communication (NFC) module 861) selected by the user among the various refund methods; the electronic device 101 may transmit the request for the refund to the external payment device 410 through the wireless communication circuit (e.g., near-distance wireless communication circuit) on the basis of the selected refund method).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the out-of-band electronic communication network teachings of Hyun with the trusted device-to-device channel teachings of Feinberg, in order to improve the security environment by performing secure encrypted data exchanges using out-of-band networking technology, such as near-field communication, thereby requiring the devices exchanging keys to be in close proximity, reducing the ability for attackers to intercept the encrypted data or perform man-in-the-middle attacks without the device owners’ knowledge.
Neither Feinberg nor Hyun explicitly teaches wherein [performing a function] is storing the public encryption key of the second system, signed with the private encryption key of the first system, at the service provider server.
However, Mathias teaches the concept wherein performing a function is, in response to determining, storing a public encryption key of a second system, signed with a private encryption key of a first system, at a service provider server (paragraph 225, when a key has been shared with a friend or family member, the system 110 should store a new public key of the friend, after having verified required signature (discussed in further detail below); in some embodiments, the standard transaction flow is used in this situation; in some embodiments, the following additional cryptographic elements are used, relative to a standard transaction flow for the owner: SE.sig, owner.SK, owner.Sig, friend.ePK/friend.eSK, friend.PK/friend.SK, friend.Cert, and KTS.sig.; in some embodiments, owner.SK is a long term private key in the owner's device used to sign the public key of a friend when sharing access to the owner's system; this key may be the same key as the one used in the standard transaction flow (named phone.SK); in some embodiments, owner.Sig is generated when the owner signs the friend's public key when the owner has verified that the identity, and the entitlements, are correct and that the key has been generated on an authentic secure element; paragraph 209, for key sharing, the key tracking server (KTS) 1250 records: a friend's public key, access rights for the friend, a generation counter for the friend, start and expiration dates, a key identifier, an SE signature, an owner signature, and a KTS signature).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the storing a signed key teachings of Mathias with the trusted device-to-device channel teachings of Feinberg in view of Hyun, in order to combine the benefits of remote key storage with digital signature based trust, thereby allowing users to access trusted keys from a variety of locations and devices, while also ensuring that the keys were not tampered with in the remote storage using a user-provided digital signature, thereby improving the security environment.
Regarding Claim 12:
Feinberg in view of Hyun and Mathias teaches the system of claim 11. In addition, Feinberg teaches wherein to generate the signed, encrypted, verification message, the processor executes the instructions to:
generate an encrypted verification message, wherein, to generate the encrypted verification message, the processor executes the instructions to use the public encryption key of the external system to encrypt the first verification message content (col 8 line 38-63, the first user (User A) selects content to be included as part of the first cryptographically protected transmission, where the content is temporarily stored within the first electronic device and encrypted by logic within the first electronic device using the public key of second user (blocks 305 and 310)); and
obtain the signed, encrypted, verification message, wherein, to obtain the signed, encrypted, verification message, the processor executes the instructions to use by the private encryption key of the system to encrypt the encrypted verification message (col 8 line 38-63, additionally, the encrypted content (e.g., entire encrypted content, a representation of the encrypted content such as its hash value, or a portion of the encrypted content or hash value) is signed with a private key of the first user (PUKA) to generate a first digital signature (block 315); col 8 line 64-col 9 line 14, the encryption/decryption logic within the first electronic device 110.sub.1 is configured to encrypt content 360 intended to be provided to User B (referenced as “Content_1 360”) using PUKB 162 to produce encrypted content 365).
Regarding Claim 13:
Feinberg in view of Hyun and Mathias teaches the system of claim 11. In addition, Feinberg teaches wherein:
the system includes a second device including:
a second memory storing second instructions (col 4 line 66-col 5 line 35, memory with logic in the form of executable code); and
a second processor that executes the second instructions to securely communicate with the external system, wherein to securely communicate (col 4 line 66-col 5 line 35, circuitry having data processing functionality; col 3 line 7-28, an asymmetric cryptographic communication scheme), the second processor executes the second instructions to:
obtain, from the service provider system, the public encryption key of the external system (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users; as shown, a first user (User A) 110.sub.1 is associated with a first public key (PUKA) 160 that is stored within the key depository 150; similarly, a second public key (PUKB) 162 associated with the second user (User B) 110.sub.2 is stored within the key depository 150; hence, the first electronic device 110.sub.1 is able to retrieve PUKB 162, and the second electronic device 110.sub.2 is able to retrieve PUKA 160, as shown in FIGS. 3B-4B); and
send, to the external system, data encrypted with the public encryption key of the external system (col 8 line 38-63, the first user (User A) selects content to be included as part of the first cryptographically protected transmission, where the content is temporarily stored within the first electronic device and encrypted by logic within the first electronic device using the public key of second user); and
Mathias teaches the public encryption key signed with the private encryption key of the system (paragraph 225, when a key has been shared with a friend or family member, the system 110 should store a new public key of the friend, after having verified required signature (discussed in further detail below); in some embodiments, the standard transaction flow is used in this situation; in some embodiments, the following additional cryptographic elements are used, relative to a standard transaction flow for the owner: SE.sig, owner.SK, owner.Sig, friend.ePK/friend.eSK, friend.PK/friend.SK, friend.Cert, and KTS.sig.; in some embodiments, owner.SK is a long term private key in the owner's device used to sign the public key of a friend when sharing access to the owner's system; this key may be the same key as the one used in the standard transaction flow (named phone.SK); in some embodiments, owner.Sig is generated when the owner signs the friend's public key when the owner has verified that the identity, and the entitlements, are correct and that the key has been generated on an authentic secure element; paragraph 209, for key sharing, the key tracking server (KTS) 1250 records: a friend's public key, access rights for the friend, a generation counter for the friend, start and expiration dates, a key identifier, an SE signature, an owner signature, and a KTS signature); and
Verify[ing] the public encryption key of the external system (paragraph 219, 233, check validity of an owner signature (e.g., using owner.PK [owner public key] received from system 110 during pairing)), wherein, to sign the public encryption key of the external system, the processor executes the instruction to use with the private encryption key of first system (paragraph 225, when a key has been shared with a friend or family member, the system 110 should store a new public key of the friend, after having verified required signature (discussed in further detail below); in some embodiments, the standard transaction flow is used in this situation; in some embodiments, the following additional cryptographic elements are used, relative to a standard transaction flow for the owner: SE.sig, owner.SK, owner.Sig, friend.ePK/friend.eSK, friend.PK/friend.SK, friend.Cert, and KTS.sig.; in some embodiments, owner.SK is a long term private key in the owner's device used to sign the public key of a friend when sharing access to the owner's system; this key may be the same key as the one used in the standard transaction flow (named phone.SK); in some embodiments, owner.Sig is generated when the owner signs the friend's public key when the owner has verified that the identity, and the entitlements, are correct and that the key has been generated on an authentic secure element; paragraph 209, for key sharing, the key tracking server (KTS) 1250 records: a friend's public key, access rights for the friend, a generation counter for the friend, start and expiration dates, a key identifier, an SE signature, an owner signature, and a KTS signature).
The rationale to combine Feinberg and Mathias is the same as provided for claim 11 due to the overlapping subject matter between claims 11 and 13.
Regarding Claim 14:
Feinberg in view of Hyun and Mathias teaches the system of claim 11. In addition, Hyun teaches wherein the channel that excludes the service provider system is separate from an electronic communication network communicably coupling the first device of the system and a device of the external system (paragraph 164-166, the first server 420 (e.g., the server 108 in FIG. 1) may transmit the public key to the electronic device 101 (e.g., the processor 120 in FIG. 1); in response to the request, the electronic device 101 (e.g., the processor 120 of FIG. 1) may receive the public key through the second wireless communication circuit (e.g., cellular wireless communication circuit); by way of another example, when a plurality of refund data reception methods supported by the external payment device 410 is provided, the electronic device 101 (e.g., the processor 120 of FIG. 1) may transmit the request for the refund to the external electronic device 410 on the basis of the refund method using one (e.g., the near-field communication (NFC) module 861) selected by the user among the various refund methods; the electronic device 101 may transmit the request for the refund to the external payment device 410 through the wireless communication circuit (e.g., near-distance wireless communication circuit) on the basis of the selected refund method).
The rationale to combine Feinberg and Hyun is the same as provided for claim 11 due to the overlapping subject matter between claims 11 and 14.
Claim(s) 6-8, 15-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Feinberg in view of Hyun and Mathias, and further in view of Dashlane (“Dashlane Security White Paper”, October 2018).
Regarding Claim 6:
Feinberg in view of Hyun and Mathias teaches the method of claim 2. In addition, Feinberg teaches the method, further comprising:
subsequent to establishing cryptographic trust, sharing, by the first system, an encrypted digital item with the second system (col 8 line 38-63, the encrypted content and the first digital signature are included as part of a first authentication message output from the first electronic device, which is provided as part of the first cryptographically protected transmission to a second electronic device associated with the second user (blocks 320 and 325); col 12 line 36-52, upon authentication (i.e. “subsequent to establishing cryptographic trust”), the cryptographic logic within the first electronic device 110.sub.1 may be further configured to extract the first content 680 from the combined content 670 (i.e. encrypted digital item is shared)), wherein sharing the encrypted digital item includes:
obtaining an unencrypted digital item (col 3 line 29-56, the content may include any collection of information, including one or more images, videos, alphanumeric characters, audio, or any combination thereof; col 6 line 61-col 7 line 36, Fig. 2, architecture of first electronic device; memory includes content data store which stores content in non-encrypted format); and
obtaining the public encryption key of the first system from service provider server (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users; as shown, a first user (User A) 110.sub.1 is associated with a first public key (PUKA) 160 that is stored within the key depository 150; similarly, a second public key (PUKB) 162 associated with the second user (User B) 110.sub.2 is stored within the key depository 150; hence, the first electronic device 110.sub.1 is able to retrieve PUKB 162, and the second electronic device 110.sub.2 is able to retrieve PUKA 160, as shown in FIGS. 3B-4B).
Neither Feinberg nor Hyun nor Mathias explicitly teaches obtaining an item key for encrypting the digital item;
obtaining the encrypted digital item by encrypting the unencrypted digital item using the item key;
obtaining an encrypted item key by encrypting the item key with the public encryption key of the second system; and
outputting the encrypted digital item and the encrypted item key to the service provider server, such that the unencrypted digital item is accessible to the second system by:
obtaining the encrypted digital item and the encrypted item key from service provider server;
obtaining the item key by decrypting the encrypted item key using the private encryption key of the second system; and
obtaining the unencrypted digital item by decrypting the encrypted digital item using the item key.
However, Dashlane teaches the concept wherein sharing an encrypted digital item includes:
obtaining an item key for encrypting a digital item (page 9 section k, Alice generates ObjectKey);
obtaining the encrypted digital item by encrypting the unencrypted digital item using the item key (page 9 section k, Alice encrypts her credential with ObjectKey, creating EncryptedCredential);
obtaining an encrypted item key by encrypting the item key with a public encryption key of a receiver system (page 9 section k, Sharing Data Between Users; Alice asks Dashlane’s servers for Bob’s public key; Alice generates a 256-bit AES key which is unique for each shared item and is called an ObjectKey; Alice encrypts the ObjectKey using Bob’s public key, creating a BobEncryptedObjectKey); and
outputting the encrypted digital item (page 9 section k, Alice sends EncryptedCredential to Dashlane’s servers) and the encrypted item key to a service provider server, such that the unencrypted digital item is accessible to the receiver system by (page 9 section k, Alice sends the BobEncryptedObjectKey to Dashlane’s servers; Alice encrypts credential with ObjectKey creating EncryptedCredential and sends to Dashlane’s servers; EncryptedCredential serves as item identification):
obtaining the encrypted digital item (page 9 section k, Dashlane’s servers send Bob the EncryptedCredential) and the encrypted item key from service provider server (page 9 section k, Dashlane’s servers send Bob the BobEncryptedObjectKey);
obtaining the item key by decrypting the encrypted item key using a private encryption key of the receiver system (page 9 section k, Bob decrypts BobEncryptedObjectKey with his private key and gets the ObjectKey); and
obtaining the unencrypted digital item by decrypting the encrypted digital item using the item key (page 9 section k, Bob decrypts the EncryptedCredential with the ObjectKey and adds Alice’s plain text credential to his own personal data).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the unique item key teachings of Dashlane with the trusted device-to-device channel teachings of Feinberg in view of Hyun and Mathias, in order to limit damage caused by malicious interception or leakage of a key by generating a key for individual encrypted items, as the individual keys would only be usable for a single item, thereby providing a measure of forward secrecy (i.e. future keys cannot be used to decrypt past items).
Regarding Claim 7:
Feinberg in view of Hyun, Mathias, and Dashlane teaches the method of claim 6. In addition, Dashlane teaches wherein obtaining the item key includes:
generating a symmetric key for encrypting the digital item (page 9 section k, Alice generates 256-bit AES key called ObjectKey; ObjectKey used for both encryption of EncryptedCredential and decryption, and is therefore symmetric key); and
using the symmetric key as the item key (page 9 section k, Alice encrypts her credential with ObjectKey, creating EncryptedCredential).
The rationale to combine Riscombe-Burton and Dashlane is the same as provided for claim 6 due to the overlapping subject matter between claims 6 and 7.
Regarding Claim 8:
Feinberg in view of Hyun, Mathias, and Dashlane teaches the method of claim 6. In addition, Feinberg teaches wherein obtaining the public encryption key of the second system includes:
receiving, from service provider server, the public encryption key of the second system in response to sending, to service provider server, a request to identify the first system (col 8 line 64-col 9 line 14, the key depository 150 is accessible to obtain asymmetric public keys for use in securing communications between two users; as shown, the first electronic device 110.sub.1 associated with a first user (User A) initiates a key query message 350 to the key depository 150 to request a public key of a targeted user (User B) to which User A desires to establish a secure communication session; the public key for User B, namely “PUKB 162,” is included as part of a key response message 355 returned to the first electronic device 110.sub.1 from the key depository 150).
Regarding Claim 15:
Feinberg in view of Hyun and Mathias teaches the system of claim 11. In addition, Feinberg teaches wherein the processor executes the instructions to:
subsequent to establishing cryptographic trust, share an encrypted digital item with the external system (col 8 line 38-63, the encrypted content and the first digital signature are included as part of a first authentication message output from the first electronic device, which is provided as part of the first cryptographically protected transmission to a second electronic device associated with the second user (blocks 320 and 325); col 12 line 36-52, upon authentication (i.e. “subsequent to establishing cryptographic trust”), the cryptographic logic within the first electronic device 110.sub.1 may be further configured to extract the first content 680 from the combined content 670 (i.e. encrypted digital item is shared));
obtain an unencrypted digital item (col 3 line 29-56, the content may include any collection of information, including one or more images, videos, alphanumeric characters, audio, or any combination thereof; col 6 line 61-col 7 line 36, Fig. 2, architecture of first electronic device; memory includes content data store which stores content in non-encrypted format); and
obtaining the public encryption key of the system from service provider server (col 6 line 46-60, a key depository 150 is an electronic device that is communicatively coupled to the network 130 and permits any of the electronic devices 110.sub.1 and/or 110.sub.N to register with and publish its asymmetric public key; unlike a certificate authority that manages the authenticity of the stored certificates, the key depository 150 maintains the public keys for registered electronic devices and/or its users; as shown, a first user (User A) 110.sub.1 is associated with a first public key (PUKA) 160 that is stored within the key depository 150; similarly, a second public key (PUKB) 162 associated with the second user (User B) 110.sub.2 is stored within the key depository 150; hence, the first electronic device 110.sub.1 is able to retrieve PUKB 162, and the second electronic device 110.sub.2 is able to retrieve PUKA 160, as shown in FIGS. 3B-4B).
Neither Feinberg nor Hyun nor Mathias explicitly teaches wherein, to share the encrypted digital item, the processor executes the instructions to:
obtain an item key for encrypting the digital item;
obtain the encrypted digital item, wherein, to obtain the encrypted digital item, the processor executes the instructions to use the item key to encrypt the unencrypted digital item;
obtain an encrypted item key, wherein, to obtain the encrypted item key, the processor executes the instructions to use the public encryption key of the external system to encrypt the item key; and
output the encrypted digital item and the encrypted item key to the service provider server, such that the unencrypted digital item is accessible to the external system by:
obtaining the encrypted digital item and the encrypted item key from service provider system;
obtaining the item key by decrypting the encrypted item key using the private encryption key of the external system; and
obtaining the unencrypted digital item by decrypting the encrypted digital item using the item key.
However, Dashlane teaches the concept wherein, to share an encrypted digital item, a processor executes instructions to:
obtain an item key for encrypting a digital item (page 9 section k, Alice generates ObjectKey);
obtain the encrypted digital item, wherein, to obtain the encrypted digital item, the processor executes the instructions to use the item key to encrypt the unencrypted digital item (page 9 section k, Alice encrypts her credential with ObjectKey, creating EncryptedCredential);
obtain an encrypted item key, wherein, to obtain the encrypted item key, the processor executes the instructions to use a public encryption key of an external system to encrypt the item key (page 9 section k, Sharing Data Between Users; Alice asks Dashlane’s servers for Bob’s public key; Alice generates a 256-bit AES key which is unique for each shared item and is called an ObjectKey; Alice encrypts the ObjectKey using Bob’s public key, creating a BobEncryptedObjectKey); and
output the encrypted digital item (page 9 section k, Alice sends EncryptedCredential to Dashlane’s servers) and the encrypted item key to a service provider server, such that the unencrypted digital item is accessible to the external system by (page 9 section k, Alice sends the BobEncryptedObjectKey to Dashlane’s servers; Alice encrypts credential with ObjectKey creating EncryptedCredential and sends to Dashlane’s servers; EncryptedCredential serves as item identification):
obtaining the encrypted digital item (page 9 section k, Dashlane’s servers send Bob the EncryptedCredential) and the encrypted item key from service provider system (page 9 section k, Dashlane’s servers send Bob the BobEncryptedObjectKey);
obtaining the item key by decrypting the encrypted item key using the private encryption key of the external system (page 9 section k, Bob decrypts BobEncryptedObjectKey with his private key and gets the ObjectKey); and
obtaining the unencrypted digital item by decrypting the encrypted digital item using the item key (page 9 section k, Bob decrypts the EncryptedCredential with the ObjectKey and adds Alice’s plain text credential to his own personal data).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the unique item key teachings of Dashlane with the trusted device-to-device channel teachings of Feinberg in view of Hyun and Mathias, in order to limit damage caused by malicious interception or leakage of a key by generating a key for individual encrypted items, as the individual keys would only be usable for a single item, thereby providing a measure of forward secrecy (i.e. future keys cannot be used to decrypt past items).
Regarding Claim 16:
Feinberg in view of Hyun, Mathias, and Dashlane teaches the system of claim 15. In addition, Dashlane teaches wherein, to obtain the item key, the processor executes the instructions to:
generate a symmetric key for encrypting the digital item (page 9 section k, Alice generates 256-bit AES key called ObjectKey; ObjectKey used for both encryption of EncryptedCredential and decryption, and is therefore symmetric key); and
use the symmetric key as the item key (page 9 section k, Alice encrypts her credential with ObjectKey, creating EncryptedCredential).
The rationale to combine Feinberg and Dashlane is the same as provided for claim 15 due to the overlapping subject matter between claims 15 and 16.
Regarding Claim 17:
Feinberg in view of Hyun, Mathias, and Dashlane teaches the system of claim 15. In addition, Feinberg teaches wherein, to obtain the public encryption key of the external system, the processor executes the instruction to:
receive, from service provider server, the public encryption key of the external system in response to sending, to service provider server, a request to identify the external system (col 8 line 64-col 9 line 14, the key depository 150 is accessible to obtain asymmetric public keys for use in securing communications between two users; as shown, the first electronic device 110.sub.1 associated with a first user (User A) initiates a key query message 350 to the key depository 150 to request a public key of a targeted user (User B) to which User A desires to establish a secure communication session; the public key for User B, namely “PUKB 162,” is included as part of a key response message 355 returned to the first electronic device 110.sub.1 from the key depository 150).
Claim(s) 9-10, 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Feinberg in view of Hyun, Mathias, and Dashlane, and further in view of Lee et al (PGPUB 2021/0195563).
Regarding Claim 9:
Feinberg in view of Hyun, Mathias, and Dashlane teaches the method of claim 6.
Neither Feinberg nor Hyun nor Mathias nor Dashlane explicitly teaches wherein obtaining the item key includes:
obtaining a second encrypted item key, encrypted with the public encryption key of the first system; and
obtaining the item key by decrypting the second encrypted item key using the private encryption key of the first system.
However, Lee teaches the concept wherein obtaining an item key includes (paragraph 99, user equipment (UE) may be provisioned with root key):
obtaining a second encrypted item key, encrypted with a public encryption key of a first system (paragraph 99, UI downloads encrypted root key from server, where the root key is encrypted using device public key); and
obtaining the item key by decrypting the second encrypted item key using a private encryption key of the first system (paragraph 99, encrypted root key decrypted using device private key associated with device public key).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the encrypted key distribution teachings of Lee with the trusted device-to-device channel teachings of Feinberg in view of Hyun, Mathias, and Dashlane, in order to provide a means of secure key distribution to any device in a network which requires use of the key by protecting the key in transit using well-known and understood PKI techniques such as encrypting the key using the public key of the device which shall receive the key, thereby preventing anyone who does not possess the corresponding private key from decrypting it.
Regarding Claim 10:
Feinberg in view of Hyun, Mathias, Dashlane, and Lee teaches the method of claim 9. In addition, Dashlane teaches wherein sharing the encrypted digital item includes:
obtaining a symmetric master key using a master password and a salt value (page 2 section b, user’s personal data is ciphered on user’s device; 32-bit salt is generated and used with User Master Password to generate AES 256-bit key (i.e. “master symmetric key”) for deciphering; page 9 section k, private key is stored in user’s personal data);
encrypting the private encryption key of the first system using the symmetric master key, such that the private encryption key of the first system is unavailable in the absence of the symmetric master key (page 2 section b, User Master Password which is only known by the user is used to generate symmetric AES 256-bit key for ciphering and deciphering the user’s personal data on the user’s device, i.e. ciphering and deciphering the private key stored in user’s personal data).
The rationale to combine Feinberg and Dashlane is the same as provided for claim 6 due to the overlapping subject matter between claims 6 and 10.
Regarding Claim 18:
Feinberg in view of Hyun, Mathias, and Dashlane teaches the system of claim 15.
Neither Feinberg nor Hyun nor Mathias nor Dashlane explicitly teaches wherein, to obtain the item key, the processor executes the instructions to:
obtain a second encrypted item key, encrypted with the public encryption key of the system; and
obtain the item key, wherein, to obtain the item key, the processor executes the instructions to use the private encryption key of the system to decrypt the second encrypted item key.
However, Lee teaches the concept wherein, to obtain an item key, a processor executes instructions to (paragraph 99, user equipment (UE) may be provisioned with root key):
obtain a second encrypted item key, encrypted with a public encryption key of a system (paragraph 99, UI downloads encrypted root key from server, where the root key is encrypted using device public key); and
obtain the item key, wherein, to obtain the item key, the processor executes the instructions to use a private encryption key of the system to decrypt the second encrypted item key (paragraph 99, encrypted root key decrypted using device private key associated with device public key).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the encrypted key distribution teachings of Lee with the trusted device-to-device channel teachings of Feinberg in view of Hyun, Mathias, and Dashlane, in order to provide a means of secure key distribution to any device in a network which requires use of the key by protecting the key in transit using well-known and understood PKI techniques such as encrypting the key using the public key of the device which shall receive the key, thereby preventing anyone who does not possess the corresponding private key from decrypting it.
Regarding Claim 19:
Feinberg in view of Hyun, Mathias, Dashlane, and Lee teaches the system of claim 18. In addition, Dashlane teaches wherein, to share the encrypted digital item, the processor executes the instructions to:
use a master password and a salt value to obtain a symmetric master key (page 2 section b, user’s personal data is ciphered on user’s device; 32-bit salt is generated and used with User Master Password to generate AES 256-bit key (i.e. “master symmetric key”) for deciphering; page 9 section k, private key is stored in user’s personal data);
use the symmetric master key to encrypt the private encryption key of the system, such that the private encryption key of the system is unavailable in the absence of the symmetric master key (page 2 section b, User Master Password which is only known by the user is used to generate symmetric AES 256-bit key for ciphering and deciphering the user’s personal data on the user’s device, i.e. ciphering and deciphering the private key stored in user’s personal data).
The rationale to combine Feinberg and Dashlane is the same as provided for claim 15 due to the overlapping subject matter between claims 15 and 19.
Response to Arguments
Applicant's arguments filed 7/18/2025 have been fully considered but they are not persuasive.
Regarding the rejection of claims under 35 USC 112(a):
Examiner’s response to applicant’s arguments, page 12 paragraph 3-page 13 paragraph 1: Examiner has clearly established the reasons that a person having ordinary skill in the art would not reasonably conclude that inventor had possession of encrypting the verification message with the Receiver’s Public Key and the Sender’s Private Key in the order recited by dependent claims 3 and 12. Applicant has not specified the encryption operations in such a way as to clearly indicate the order of operations. Taking the specification, [0068], to imply an order would result in an obvious contradiction, as the implied order would not function in conventional asymmetric cryptography as it is known in the art. Further, a person having ordinary skill in the art would not ordinarily consider the order of operations claimed, i.e. encrypting with the receiver’s public key followed by the sender’s private key, as this introduces an obvious vulnerability in terms of the non-repudiation offered by the conventional method of signing with the private key followed by encrypting with the public key. Anyone could intercept the encrypted message, remove the signature, and sign with their own private key to assume ownership of the transaction. Therefore, a person having ordinary skill in the art would not reasonably interpret the phrase “encrypting… with the Receiver’s Public Key and the Sender’s Private Key” (as per [0068]) to imply the claimed order without clear evidence that this was what applicant had intended. No such evidence is present in the specification and claims as originally filed. Examiner notes that “encrypting… with the Receiver’s Private Key 206 and the Sender’s Public Key 214”, as argued by applicant, does not appear in the specification. The specification instead refers to “decrypting… with the Receiver’s Private Key 206 and the Sender’s Public Key 214”, as in [0068].
Examiner’s response to applicant’s arguments, page 13 paragraph 2-3: Applicant has amended the subject matter requiring the previous 35 USC 112(a) rejection of claims 4 and 13, which is therefore withdrawn.
Examiner’s response to applicant’s arguments, page 13 paragraph 4-9: Applicant asserts that claims 5 and 14 do not recite that the claimed channel is an electronic communication network. The claimed channel is not the reason for which the 35 USC 112(a) rejection of claims 5 and 14 was given. The claim additionally recites “the channel… is separate from an electronic communication network communicably coupling the first device of the first system and a device of the second system”. However, the specification and claims as originally filed make no reference to such a separate electronic communication network. Therefore, the rejection is maintained.
Regarding the rejection of claims under 35 USC 103:
Examiner’s response to applicant’s arguments, page 14 paragraph 3-4: Applicant argues that a person having ordinary skill in the art would not interpret Hyun as teaching the concept of a channel that excludes a service provider service. However, a person having ordinary skill in the art would not need to interpret; Hyun explicitly shows that there is no intervening device in the direct connection between the external payment device 410 and the electronic device 101 (e.g. Fig. 4). Hyun teaches this connection is a near-field communication (NFC) link (e.g. [0075]. It is well-known in the art that NFC is a direct device-to-device link with no intervening servers (as the extremely limited operating distance, i.e. “near-field”, would make inserting an additional physical server difficult or impossible). It is clear from Hyun that the connection between device 410 and 101 in Hyun excludes an additional service provider server.
Examiner’s response to applicant’s arguments, page 14 paragraph 5: Applicant is incorrect. As an initial matter, Feinberg teaches that the message is a verification message; it is not necessary for Hyun to teach this also. However, Hyun does additionally teach that the message transmitted on the channel which excludes the service provider server (i.e. the NFC channel) is a verification message; Hyun teaches that the message is a request for refund which requires authentication (e.g. [0164]-[0166], [0183]-[0185]). It can therefore be seen as a “verification message”.
Examiner’s response to applicant’s arguments, page 14 paragraph 6-7: Applicant argues that the conclusion that “Hyun teaches the concept of sending, via a channel that excludes a service provider server” is overly broad, inconsistent with the full teachings of Hyun, and an impermissible application of hindsight reasoning in view of the present application. Applicant appears to be arguing that the clear teachings of a single reference (e.g. an NFC channel clearly excluding a service provider server), is “overly broad”, “inconsistent” with itself, and “impermissible application of hindsight reasoning” apparently in and of itself, as it is not the combination which is being argued in this paragraph; it is not clear how any of these terms apply to the cited subject matter from the Hyun reference, as shown above.
Applicant further argues that Hyun does not describe anything as “out-of-band”. The concept of an “out-of-band channel” in the art is well-known; it is any channel used to communicate between devices that is separate from a further communication channel between the devices. That Hyun never refers to the two separate channels (i.e. first wireless communication circuit and second wireless communication circuit, e.g. [0074]) as “out-of-band” does not matter; the two separate channels are out-of-band by definition. As it is further well-known in the art that out-of-band channels are used for security purposes, to separate key data from the data secured with said keys, it is clear why this would benefit secure, trusted device-to-device communication systems such as in Feinberg (which does not explicitly show a separate out-of-band channel).
Examiner’s response to applicant’s arguments, page 15 paragraph 1: Applicant is incorrect. Hyun is not cited as teaching a “near-distance wireless communication circuit”. Hyun is cited as teaching a channel that excludes a service provider server, i.e. an out-of-band channel. The “near-distance wireless communication circuit” of Hyun is given as an example of such a channel. A person having ordinary skill in the art would certainly interpret Feinberg as teaching the availability of near-distance wireless communication; what is missing from Feinberg is that the near-distance wireless communication is an out-of-band channel. Therefore, the out-of-band NFC channel of Hyun represents an improvement to the system of Feinberg for the security reasons provided above.
Examiner’s response to applicant’s arguments, page 15 paragraph 2: Applicant has misinterpreted or misunderstood the rationale provided by the examiner; what examiner is saying here is that it is an improvement for the devices exchanging keys, i.e. public keys using a first channel, to communicate the secure encrypted data encrypted by said keys, e.g. verification messages, using an out-of-band channel such as an NFC channel, so that it is more difficult for an attacker to intercept the encrypted data (i.e. data encrypted by the exchanged keys), thereby improving security. Examiner was not implying that the keys were exchanged using a proximity-based communication channel.
Examiner’s response to applicant’s arguments, page 15 paragraph 3-4: Applicant argues that Mathias, Feinberg, and Hyun do not describe allowing users to access trusted keys from a variety of locations and devices, therefore, this is an application of impermissible hindsight reasoning. This is incorrect. Mathias at least teaches, e.g. [0217]-[0218], that the system supports changing the owner device and facilitating restoration of shared keys on a new device.
Examiner’s response to applicant’s arguments, page 16 paragraph 4-5: Applicant’s argument that Hyun does not indicate that the first wireless communication circuit described therein is used to send a verification message is addressed above with regard to claim 1; the refund message sent by the electronic device requires authentication and can therefore be seen as a verification message.
Examiner’s response to applicant’s arguments, page 17 paragraph 1-3: Applicant is incorrect. Feinberg teaches multiple authentications, any of which can be considered “establishing cryptographic trust” (e.g. col 12 line 36-52); subsequent to the first authentication, combined content is extracted. This content can now be seen as shared between the first and second devices. Further, the claims define the sharing as including “obtaining an unencrypted digital item” and “obtaining the public encryption key of the first system from service provider server”; these aspects of sharing are taught by Feinberg (e.g. col 3 line 29-56, col 6 line 46-col 7 line 36).
Examiner’s response to applicant’s arguments, page 17 paragraph 4-5: Applicant appears to be arguing that obtaining the public encryption key of the second system occurs subsequent to establishing cryptographic trust. This is not what is claimed. Claim 6, from which claim 8 depends, does not recite obtaining the public encryption key of the second system; this is a feature of claim 1 which clearly occurs during the process of establishing cryptographic trust. Therefore, Feinberg’s key query message applies.
Applicant makes no further arguments.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, William Korzuch can be reached at (571) 272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/AMIR MEHRMANESH/Supervisory Patent Examiner, Art Unit 2491
Prosecution Insights