DETAILED ACTION
This action is in response to new application titled “DYNAMIC GROUP MEMBERSHIP FOR DEVICES” filed 4/07/2025. Claims 1-20 are pending.
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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 12,287,965. Although the claims at issue are not identical, they are not patentably distinct from each other because each and every element of the above independent claims 1, 8 and 15 of the present application is broader and therefore anticipated by the corresponding independent claims 1, 13 and 18 of U.S. Patent No. 12,287,965 and each dependent claim has a corresponding dependent claim.
19/172557 claim 1
12,287,965 claim 1
A method implemented by a first computing device, the method comprising:
A method implemented by a first computing device, the method comprising:
establishing at least one cryptographic key;
establishing at least one cryptographic key;
identifying, based on the at least one cryptographic key, a particular synchronization sub-group to which the at least one cryptographic key corresponds, wherein the particular synchronization sub-group is identified based on a file type associated with the at least one cryptographic key, a software application with which the at least one cryptographic key is associated, or some combination thereof;
tagging the at least one cryptographic key as being included in a synchronization sub- group; and
tagging the at least one cryptographic key as being included in the particular synchronization sub-group; and
in response to determining that the first computing device and a second computing device both participate in the synchronization sub-group: forming a secure channel with the second computing device, identifying a set of requirements assigned to the secure channel,
in response to determining that the first computing device and a second computing device both participate in the particular synchronization sub-group:
based on the set of requirements assigned to the secure channel: identifying at least one encryption key for encrypting data that is transmitted between computing devices that are members of the synchronization sub-group, and encrypting the at least one cryptographic key using the at least one encryption key to produce at least one encrypted cryptographic key, and
forming a secure channel with the second computing device, encrypting, based on requirements of the secure channel used for communicating with the second computing device, the at least one cryptographic key to produce at least one encrypted cryptographic key, and
sending, over the secure channel, the at least one encrypted cryptographic key to the second computing device.
sending, over the secure channel, the at least one encrypted cryptographic key to the second computing device.
19/172557 claim 8
12,287,965 claim 7
A non-transitory computer readable storage medium configured to store instructions that, when executed by at least one processor included in a first computing device, cause the first computing device to carry out steps that include:
At least one non-transitory computer readable storage medium configured to store instructions that, when executed by at least one processor included in a first computing device, cause the first computing device to carry out steps that include:
establishing at least one cryptographic key;
establishing at least one cryptographic key;
identifying, based on the at least one cryptographic key, a particular synchronization sub-group to which the at least one cryptographic key corresponds, wherein the particular synchronization sub-group is identified based on a file type associated with the at least one cryptographic key, a software application with which the at least one cryptographic key is associated, or some combination thereof;
tagging the at least one cryptographic key as being included in a synchronization sub- group; and
tagging the at least one cryptographic key as being included in the particular synchronization sub-group; and
in response to determining that the first computing device and a second computing device both participate in the synchronization sub-group: forming a secure channel with the second computing device, identifying a set of requirements assigned to the secure channel,
in response to determining that the first computing device and a second computing device both participate in the particular synchronization sub-group:
based on the set of requirements assigned to the secure channel: identifying at least one encryption key for encrypting data that is transmitted between computing devices that are members of the synchronization sub-group, and encrypting the at least one cryptographic key using the at least one encryption key to produce at least one encrypted cryptographic key, and
forming a secure channel with the second computing device, encrypting, based on requirements of the secure channel used for communicating with the second computing device, the at least one cryptographic key to produce at least one encrypted cryptographic key, and
sending, over the secure channel, the at least one encrypted cryptographic key to the second computing device.
sending, over the secure channel, the at least one encrypted cryptographic key to the second computing device.
19/172557 claim 15
12,287,965 claim 13
A first computing device comprising at least one processor configured to cause the first computing device to carry out steps that include:
A first computing device, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first computing device to carry out steps that include:
establishing at least one cryptographic key;
establishing at least one cryptographic key;
identifying, based on the at least one cryptographic key, a particular synchronization sub-group to which the at least one cryptographic key corresponds, wherein the particular synchronization sub-group is identified based on a file type associated with the at least one cryptographic key, a software application with which the at least one cryptographic key is associated, or some combination thereof;
tagging the at least one cryptographic key as being included in a synchronization sub- group; and
tagging the at least one cryptographic key as being included in the particular synchronization sub-group; and
in response to determining that the first computing device and a second computing device both participate in the synchronization sub-group: forming a secure channel with the second computing device, identifying a set of requirements assigned to the secure channel,
in response to determining that the first computing device and a second computing device both participate in the particular synchronization sub-group:
based on the set of requirements assigned to the secure channel: identifying at least one encryption key for encrypting data that is transmitted between computing devices that are members of the synchronization sub-group, and encrypting the at least one cryptographic key using the at least one encryption key to produce at least one encrypted cryptographic key, and
forming a secure channel with the second computing device, encrypting, based on requirements of the secure channel used for communicating with the second computing device, the at least one cryptographic key to produce at least one encrypted cryptographic key, and
sending, over the secure channel, the at least one encrypted cryptographic key to the second computing device.
sending, over the secure channel, the at least one encrypted cryptographic key to the second computing device.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Brouwer et al (US 2014/0281540) in view of Baghdasaryan (US 2014/0289528).
With respect to claim 1 Brouwer teaches a method implemented by a first computing device, the method comprising:
establishing at least one cryptographic key; tagging the at least one cryptographic key as being included in a synchronization sub-group (see figure 12 step 1230 and paragraph i.e. At 1230, the process 1200 generates a delta manifest based on the manifests of the local device and the peer device. As described above, a delta manifest in some embodiments includes is (1) a list of differences between the local device's keychain items and keychain items listed in the peer device's manifest and (2) the data for the corresponding keychain items in the list. In some embodiments, the process 1200 generates the delta manifest by (1) comparing to keychain items in the local device's keychain against the keychain items listed n the peer device's manifest and (2) identifying the differences and paragraph 0120-0121 i.e. As mentioned above, a keychain, in some embodiments, is a defined collection of data that may include passwords, private keys, certificates, secure notes, etc… A keychain item of some embodiments represents an individual piece of data (e.g., a password, a key, a certificate, etc.)); and
in response to determining that the first computing device and a second computing device both participate in the particular synchronization sub-group (see figure 12 step 1210 and paragraph 0142-0143 i.e. FIG. 12 conceptually illustrates a process 1200 of some embodiments for pushing updates to peer devices. In some embodiments, the keychain manager described in this application performs the process 1200 to send updates that were applied to the local keychain of the local device to the peer devices in the sync circle. For instance, the keychain manager performs the process 1200 when the keychain manager is in states 1120 and 1145 described above by reference to FIG. 11. The process 1200 starts by identifying (at 1210) a peer device in the sync circle. In some embodiments, the process 1200 identifies a peer device by accessing a local copy of the sync device list while, in other embodiments, the process 1200 identifies a peer device by accessing the sync device list stored in the cloud services 305 (e.g., in storage 310)):
forming a secure channel with the second computing device, identifying at least one encryption key for encrypting data that is transmitted between computing devices that are members of the synchronization sub-group (see figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items), and
sending, over the secure channel, the at least one encrypted cryptographic key to the second computing device (see figure 12 step 1250 and paragraph 0147 i.e. Next, the process 1200 sends (at 1250) the encrypted keychain items and the delta manifest to the peer device through the secure communication channel).
Brouwer does not teach identifying a set of requirements assigned to the secure channel.
Baghdasaryan teaches identifying a set of requirements assigned to the secure channel (see Baghdasaryan paragraph 0132-0133 i.e. An application which uses the described private synchronization protocols in combination with the embodiments of the invention for performing user controlled trust delegation to a new device to share new registrations among a user's devices where a user doesn't need to authenticate with an authenticator every time when a new registration is being delegated to other devices. A set of authenticators belonging to the same user and forming a circle, where these authenticators are using the private synchronization protocols described above to sync authentication key pairs in order to share registrations of a single authenticator with other authenticators belonging to the same circle).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Brouwer in view of Baghdasaryan to used Baghdasaryan private synchronization protocols for performing user controlled trust delegation to a new device to share new registrations among a user's devices where a user doesn't need to authenticate with an authenticator every time when a new registration is being delegated to other devices where the set of authenticators belong to the same user forming a circle. Where the authenticators are using the private synchronization protocols to sync authentication key pairs in order to share registrations of a single authenticator with other authenticators belonging to the same circle (see Baghdasaryan paragraph 0132-0133). Therefore one would have been motivated to have used Baghdasaryan private synchronization protocols for performing user controlled trust delegation to a new device to share new registrations among a user's devices.
With respect to claim 2 Brouwer in view of Baghdasaryan teaches the method of claim 1, wherein the secure channel is formed with the second computing device using an Off-the-Record (OTR) messaging protocol (see paragraph 0053 i.e. some embodiments provide a secure transport layer to protect the data that devices communicate with each other. For this example, devices A-C communicate with each other through secure communication channels established between each pair of devices A-C. The secure communication channels may be implemented using any number of different protocols, such as message-based communication protocols (e.g., OTR messaging), stream-based communication protocols (e.g., SSL), etc).
With respect to claim 3 Brouwer in view of Baghdasaryan teaches the method of claim 1, further comprising, prior to tagging the at least one cryptographic key: identifying that the at least one cryptographic key corresponds to the synchronization sub-group (see Brouwer figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items).
With respect to claim 4 Brouwer in view of Baghdasaryan teaches the method of claim 1, wherein establishing the at least one cryptographic key comprises: receiving information through an application executing on the first computing device, and generating the at least one cryptographic key based on the information (see paragraph 0074 i.e. Next, the process 500 generates (at 520) a user signing public/private key pair based on the password provided by the user).
With respect to claim 5 Brouwer in view of Baghdasaryan teaches the method of claim 4, wherein the information comprises: a username and a password, and/or a cryptographic credential (see paragraph 0074 i.e. Next, the process 500 generates (at 520) a user signing public/private key pair based on the password provided by the user).
With respect to claim 6 Brouwer in view of Baghdasaryan teaches the method of claim 1, wherein the at least one encryption key includes a share key for encrypting messages transmitted over the secure channel (see figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items).
With respect to claim 7 Brouwer in view of Baghdasaryan teaches the method of claim 1, further comprising, prior to sending the at least one encrypted cryptographic key to the second computing device: encrypting the at least one encrypted cryptographic key using an additional key that is required to be possessed by both the first and second computing devices in order to participate in the synchronization sub-group (see figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items).
With respect to claim 8 Brouwer teaches at least one non-transitory computer readable storage medium configured to store instructions that, when executed by at least one processor included in a first computing device, cause the first computing device to carry out steps that include:
establishing at least one cryptographic key; tagging the at least one cryptographic key as being included in a synchronization sub-group (see figure 12 step 1230 and paragraph i.e. At 1230, the process 1200 generates a delta manifest based on the manifests of the local device and the peer device. As described above, a delta manifest in some embodiments includes is (1) a list of differences between the local device's keychain items and keychain items listed in the peer device's manifest and (2) the data for the corresponding keychain items in the list. In some embodiments, the process 1200 generates the delta manifest by (1) comparing to keychain items in the local device's keychain against the keychain items listed n the peer device's manifest and (2) identifying the differences and paragraph 0120-0121 i.e. As mentioned above, a keychain, in some embodiments, is a defined collection of data that may include passwords, private keys, certificates, secure notes, etc… A keychain item of some embodiments represents an individual piece of data (e.g., a password, a key, a certificate, etc.)); and
in response to determining that the first computing device and a second computing device both participate in the particular synchronization sub-group (see figure 12 step 1210 and paragraph 0142-0143 i.e. FIG. 12 conceptually illustrates a process 1200 of some embodiments for pushing updates to peer devices. In some embodiments, the keychain manager described in this application performs the process 1200 to send updates that were applied to the local keychain of the local device to the peer devices in the sync circle. For instance, the keychain manager performs the process 1200 when the keychain manager is in states 1120 and 1145 described above by reference to FIG. 11. The process 1200 starts by identifying (at 1210) a peer device in the sync circle. In some embodiments, the process 1200 identifies a peer device by accessing a local copy of the sync device list while, in other embodiments, the process 1200 identifies a peer device by accessing the sync device list stored in the cloud services 305 (e.g., in storage 310)):
forming a secure channel with the second computing device, identifying at least one encryption key for encrypting data that is transmitted between computing devices that are members of the synchronization sub-group (see figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items), and
sending, over the secure channel, the at least one encrypted cryptographic key to the second computing device (see figure 12 step 1250 and paragraph 0147 i.e. Next, the process 1200 sends (at 1250) the encrypted keychain items and the delta manifest to the peer device through the secure communication channel).
Brouwer does not teach identifying a set of requirements assigned to the secure channel.
Baghdasaryan teaches identifying a set of requirements assigned to the secure channel (see Baghdasaryan paragraph 0132-0133 i.e. An application which uses the described private synchronization protocols in combination with the embodiments of the invention for performing user controlled trust delegation to a new device to share new registrations among a user's devices where a user doesn't need to authenticate with an authenticator every time when a new registration is being delegated to other devices. A set of authenticators belonging to the same user and forming a circle, where these authenticators are using the private synchronization protocols described above to sync authentication key pairs in order to share registrations of a single authenticator with other authenticators belonging to the same circle).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Brouwer in view of Baghdasaryan to used Baghdasaryan private synchronization protocols for performing user controlled trust delegation to a new device to share new registrations among a user's devices where a user doesn't need to authenticate with an authenticator every time when a new registration is being delegated to other devices where the set of authenticators belong to the same user forming a circle. Where the authenticators are using the private synchronization protocols to sync authentication key pairs in order to share registrations of a single authenticator with other authenticators belonging to the same circle (see Baghdasaryan paragraph 0132-0133). Therefore one would have been motivated to have used Baghdasaryan private synchronization protocols for performing user controlled trust delegation to a new device to share new registrations among a user's devices.
With respect to claim 9 Brouwer in view of Baghdasaryan teaches the at least one non-transitory computer readable storage medium of claim 8, wherein the secure channel is formed with the second computing device using an Off-the-Record (OTR) messaging protocol (see paragraph 0053 i.e. some embodiments provide a secure transport layer to protect the data that devices communicate with each other. For this example, devices A-C communicate with each other through secure communication channels established between each pair of devices A-C. The secure communication channels may be implemented using any number of different protocols, such as message-based communication protocols (e.g., OTR messaging), stream-based communication protocols (e.g., SSL), etc).
With respect to claim 10 Brouwer in view of Baghdasaryan teaches the non-transitory computer readable storage medium of claim 8, wherein the steps further include, prior to tagging the at least one cryptographic key: identifying that the at least one cryptographic key corresponds to the synchronization sub-group (see Brouwer figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items)..
With respect to claim 11 Brouwer in view of Baghdasaryan teaches the at least one non-transitory computer readable storage medium of claim 8, wherein establishing the at least one cryptographic key comprises: receiving information through an application executing on the first computing device, and generating the at least one cryptographic key based on the information (see paragraph 0074 i.e. Next, the process 500 generates (at 520) a user signing public/private key pair based on the password provided by the user).
With respect to claim 12 Brouwer in view of Baghdasaryan teaches the at least one non-transitory computer readable storage medium of claim 11, wherein the information comprises: a username and a password, and/or a cryptographic credential(see paragraph 0074 i.e. Next, the process 500 generates (at 520) a user signing public/private key pair based on the password provided by the user).
With respect to claim 13 Brouwer in view of Baghdasaryan teaches the at least one non-transitory computer readable storage medium of claim 8, wherein the at least one encryption key includes a shared key for encrypting messages transmitted over the secure channel (see figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items).
With respect to claim 14 Brouwer in view of Baghdasaryan teaches the at least one non-transitory computer readable storage medium of claim 8, wherein the steps further include, prior to sending the at least one encrypted cryptographic key to the second computing device: encrypting the at least one encrypted cryptographic key using an additional key that is required to be possessed by both the first and second computing devices in order to participate in the synchronization sub-group (see figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items).
With respect to claim 15 Brouwer teaches a first computing device comprising at least one processor; and at least one memory storing instructions that when executed by the at least one processor, cause the first computing device to carry out steps that include:
establishing at least one cryptographic key; tagging the at least one cryptographic key as being included in a synchronization sub-group (see figure 12 step 1230 and paragraph i.e. At 1230, the process 1200 generates a delta manifest based on the manifests of the local device and the peer device. As described above, a delta manifest in some embodiments includes is (1) a list of differences between the local device's keychain items and keychain items listed in the peer device's manifest and (2) the data for the corresponding keychain items in the list. In some embodiments, the process 1200 generates the delta manifest by (1) comparing to keychain items in the local device's keychain against the keychain items listed n the peer device's manifest and (2) identifying the differences and paragraph 0120-0121 i.e. As mentioned above, a keychain, in some embodiments, is a defined collection of data that may include passwords, private keys, certificates, secure notes, etc… A keychain item of some embodiments represents an individual piece of data (e.g., a password, a key, a certificate, etc.)); and
in response to determining that the first computing device and a second computing device both participate in the particular synchronization sub-group (see figure 12 step 1210 and paragraph 0142-0143 i.e. FIG. 12 conceptually illustrates a process 1200 of some embodiments for pushing updates to peer devices. In some embodiments, the keychain manager described in this application performs the process 1200 to send updates that were applied to the local keychain of the local device to the peer devices in the sync circle. For instance, the keychain manager performs the process 1200 when the keychain manager is in states 1120 and 1145 described above by reference to FIG. 11. The process 1200 starts by identifying (at 1210) a peer device in the sync circle. In some embodiments, the process 1200 identifies a peer device by accessing a local copy of the sync device list while, in other embodiments, the process 1200 identifies a peer device by accessing the sync device list stored in the cloud services 305 (e.g., in storage 310)):
forming a secure channel with the second computing device, identifying at least one encryption key for encrypting data that is transmitted between computing devices that are members of the synchronization sub-group (see figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items), and
sending, over the secure channel, the at least one encrypted cryptographic key to the second computing device (see figure 12 step 1250 and paragraph 0147 i.e. Next, the process 1200 sends (at 1250) the encrypted keychain items and the delta manifest to the peer device through the secure communication channel).
Brouwer does not teach identifying a set of requirements assigned to the secure channel.
Baghdasaryan teaches identifying a set of requirements assigned to the secure channel (see Baghdasaryan paragraph 0132-0133 i.e. An application which uses the described private synchronization protocols in combination with the embodiments of the invention for performing user controlled trust delegation to a new device to share new registrations among a user's devices where a user doesn't need to authenticate with an authenticator every time when a new registration is being delegated to other devices. A set of authenticators belonging to the same user and forming a circle, where these authenticators are using the private synchronization protocols described above to sync authentication key pairs in order to share registrations of a single authenticator with other authenticators belonging to the same circle).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Brouwer in view of Baghdasaryan to used Baghdasaryan private synchronization protocols for performing user controlled trust delegation to a new device to share new registrations among a user's devices where a user doesn't need to authenticate with an authenticator every time when a new registration is being delegated to other devices where the set of authenticators belong to the same user forming a circle. Where the authenticators are using the private synchronization protocols to sync authentication key pairs in order to share registrations of a single authenticator with other authenticators belonging to the same circle (see Baghdasaryan paragraph 0132-0133). Therefore one would have been motivated to have used Baghdasaryan private synchronization protocols for performing user controlled trust delegation to a new device to share new registrations among a user's devices.
With respect to claim 16 Brouwer in view of Baghdasaryan teaches the first computing device of claim 15, wherein the secure channel is formed with the second computing device using an Off-the-Record (OTR) messaging protocol (see paragraph 0053 i.e. some embodiments provide a secure transport layer to protect the data that devices communicate with each other. For this example, devices A-C communicate with each other through secure communication channels established between each pair of devices A-C. The secure communication channels may be implemented using any number of different protocols, such as message-based communication protocols (e.g., OTR messaging), stream-based communication protocols (e.g., SSL), etc).
With respect to claim 17 Brouwer in view of Baghdasaryan teaches the first computing device of claim 15, wherein the steps further include, prior to tagging the at least one cryptographic key: identifying that the at least one cryptographic key corresponds to the synchronization sub-group (see Brouwer figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items).
With respect to claim 18 Brouwer in view of Baghdasaryan teaches the first computing device of claim 15, wherein establishing the at least one cryptographic key comprises: receiving information through an application executing on the first computing device, and generating the at least one cryptographic key based on the information (see paragraph 0074 i.e. Next, the process 500 generates (at 520) a user signing public/private key pair based on the password provided by the user).
With respect to claim 19 Brouwer in view of Baghdasaryan teaches the first computing device of claim 18, wherein the information comprises: a username and a password, and/or a cryptographic credential (see paragraph 0074 i.e. Next, the process 500 generates (at 520) a user signing public/private key pair based on the password provided by the user).
With respect to claim 20 Brouwer in view of Baghdasaryan teaches the first computing device of claim 15, wherein the at least one encryption key includes a shared key for encrypting messages transmitted over the secure channel (see figure 12 step 1240 and paragraph 0146 i.e. The process 1200 then encrypts (at 1240) a copy of the local keychain items that are specified in the delta manifest using the encryption key or set of keys for the peer device. As explained above, a secure communication channel is used in some embodiments between every pair of devices in the sync circle. As such, the process 1210 identifies the key or set of keys established for the secure communication channel used to communicate with the peer device and uses the identified key or set of keys to encrypt the copies of the local keychain items).
Prior Art
Briceno et al (US 2014/0289833) titled “ADVANCED AUTHENTICATION TECHNIQUES AND APPLICATIONS”.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 571-272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/DEVIN E ALMEIDA/Examiner, Art Unit 2492
Prosecution Insights