KR20210022157A - Synchronization and verification groups among related devices - Google Patents

Abstract

Users who own multiple devices with overlapping functions are becoming more and more common. Smartphones, tablets, and computers all access the web, allow users to process photos and the like, and users tend to have multiple such devices. Accordingly, users who wish to share data between devices and have access to data on multiple devices are also becoming more and more common. Users can typically use all kinds of different techniques for transferring data between devices, such as flash memory sticks, email, and the like. More efficient techniques are desired for automatically sharing data between users' devices.

Description

Synchronization and verification groups between related devices {SYNCHRONIZATION AND VERIFICATION GROUPS AMONG RELATED DEVICES}

Users who own multiple devices with overlapping functions are becoming more and more common. Smartphones, tablets, and computers all access the web, allow users to process photos and the like, and users tend to have multiple such devices. Accordingly, users who wish to share data between devices and have access to data on multiple devices are also becoming more and more common. Users can typically use all kinds of different techniques for transferring data between devices, such as flash memory sticks, email, and the like. More efficient techniques are desired for automatically sharing data between users' devices.

Some embodiments provide a method for synchronizing data items between a set of related electronic devices. Specifically, some embodiments define verification subgroups to which devices can join when devices satisfy membership requirements for verification subgroups, and synchronization in which devices participate using verification subgroups. Define subgroups. In some embodiments, different synchronization subgroups define different types of data items that devices participating in the synchronization subgroups share with each other through synchronization processes.

In some embodiments, the set of associated electronic devices includes all devices that the user associates with a third party service (eg, with the user's specific cloud service account). Knowledge of the cloud service account password serves as a requirement for membership in at least one of the verification subgroups of some embodiments, but some embodiments provide an additional verification subgroup to which various devices can join. Define them. Different embodiments define different sets of requirements for joining such additional verification subgroups, including the requirement that the device has a specific operating system, a specific level of password strength, and has a secure processor or other device configuration attributes. . Some embodiments allow the device to prove possession of a specific cryptographic secret to join a specific verification subgroup (e.g., possession of a key provided with a company profile to join a verification subgroup defined by the company). , Or require the user to verify the membership of the new device on the device already established in the verification subgroup. Additionally, some verification subgroups may require a new device to verify its properties for an established device through an out-of-band process (eg, by using a third party for verification).

In order for a device to join the verification subgroup, some embodiments require the device to sign a request to join the subgroup and have a request approved by one of the devices already in the verification subgroup. For example, in some embodiments, when a device meets the requirements for a verification subgroup that requires possession of a cryptographic secret, the device (i) has its public key (already shared with other devices). key) and a private key generated from the cryptographic secret at the date/time of application to the subgroup, and (ii) packaging these signatures with their identity used to join the verification subgroup; and , (iii) Sign the identity with its own private key. This signature is then sent to other devices in the verification subgroup as a request to join the subgroup. When one of the other devices verifies that the requesting device meets all the requirements for joining the subgroup, the established device notifies other devices in the verifying subgroup, including the new device being added. In some embodiments, this notification includes a list of members in the verification subgroup, including the new device.

In some embodiments, devices may be members of multiple verification subgroups. In addition, devices can dynamically move into and out of such verification subgroups as the properties of the devices change so that the devices either newly meet the requirements or no longer meet the requirements of the various verification subgroups. When the device's properties are changed (e.g., a profile containing a specific encryption secret is installed on the device, the user changes the device passcode length, etc.) and the device becomes eligible for the verification subgroup, the device , As described above, generates and transmits a request for membership in the verification subgroup. On the other hand, when a device no longer meets the requirements for membership in a verification subgroup in which the device is currently a member due to a change in the device's properties, the device detects that it should no longer be a member of the subgroup. And send this notification to other devices that are members of the subgroup.

In some embodiments, verification subgroups are used to organize devices into synchronization subgroups to determine which data items stored on the device should be synchronized with other devices. In some embodiments, synchronization subgroups are defined by (i) a set of requirements for a device to participate in a synchronization subgroup and (ii) a type of data item that is synchronized between devices participating in the synchronization subgroup. In some embodiments, the set of requirements for synchronization subgroups is membership within one or more verification subgroups. For example, the requirements for participation in the first synchronization subgroup may be membership within the first verification subgroup, while the requirements for participation in the second synchronization subgroup are the second and third verification subgroups. It can be a membership within both sides.

Synchronization subgroups are used to enable a set of related devices to synchronize data items with each other. In various embodiments, these synchronized data items include usernames and passwords, encryption for online accounts (eg, financial services websites, online forum sites, media content providers, online retail sites, etc.). Include some or all of the keys and/or secrets (i.e. data from which keys can be generated), network (e.g., Wi-Fi network) passwords, notes, photos, documents and other files, etc. . When one of the devices receives a new data item to add to the set of synchronization data items (e.g., from user input of a new password, import or download of a new photo, etc.), the device of some embodiments It is dynamically tagged as belonging to one or more synchronization subgroups. For example, the application for which the data was created (e.g., Wi-Fi networks/passwords versus online account usernames/passwords), username/type of website to which the account gains access (e.g., financial website versus Non-financial websites), data can be tagged based on whether the data is related to the company or not.

Data items belonging to a specific synchronization subgroup are synchronized among devices participating in a specific synchronization subgroup. In some embodiments, each pair of devices may have a secure channel between themselves (e.g., using an Off-the-Record (OTR) messaging protocol) for use in transferring data items Create In different embodiments, this secure channel may pass through a centralized service that allows temporary storage even when the receiving device is unlocked (eg, storage for a cloud service account to which devices on both sides are logged in). However, in some embodiments, the use of a secure channel protects these communications against man-in-the-middle attacks. Other embodiments use direct peer-to-peer connections (eg, via a Bluetooth connection).

When the first device determines that it should synchronize its data items with the second device, the first device identifies the synchronization subgroups to which both the first and second devices participate. For each such subgroup, the first device then identifies all synchronization data items that it stores and (i) has not yet transmitted to the second device and (ii) belongs to the synchronization subgroups to which the second device participates. Unless the synchronization subgroups impose any additional requirements for the secure channel, the first device transmits the identified synchronization data items to the second device over the secure channel. When the synchronization subgroup imposes additional requirements on the secure channel (e.g., encrypting data items with an encryption key required for membership within the verification subgroup), the first device uses a number of different secure channels. The set can be synchronized with the second device. The second device also performs a similar set of operations to synchronize its data items with the first device.

As devices dynamically join and leave verification subgroups, this can cause devices to join and leave synchronization subgroups. For example, if a particular synchronization subgroup requires that the device be a member of the first and second verification subgroups, then if the device loses its membership in the first verification subgroup, the device will second verify Even if membership within a subgroup is maintained, it will no longer be possible to participate in a specific synchronization subgroup. In some embodiments, when a device is no longer eligible to participate in a particular synchronization subgroup, the device is configured with that particular synchronization subgroup, except for data items that also belong to other synchronization subgroups to which the device still participates. Remove all data items belonging to the group (or the device prompts the user to determine whether these data items should be removed).

The preceding summary is intended to serve as a brief introduction to some embodiments of the invention. It is not intended to be an introduction or overview of all inventive subject matter disclosed in this document. The following detailed description and the drawings referred to in the detailed description further describe the embodiments described in the overview, and further describe other embodiments. Accordingly, an overview, detailed description, and a complete review of the drawings are required in order to understand all of the embodiments described by this document. Moreover, since the claimed subject matter may be embodied in other specific forms without departing from the spirit of the subject matter, the claimed subject matter is not limited by the overview, detailed description, and illustrative details in the drawings, Rather, it should be limited by the appended claims.

Novel features of the invention are set forth in the appended claims. However, for purposes of explanation, several embodiments of the invention are presented in the following figures.
1 shows an example of six electronic devices that a single user may own.
2 shows a first ring with only a single criterion that the device knows the user's cloud service account passwords.
3 shows a second ring for membership that requires (i) the device is running an iOS operating system and (ii) the user needs to approve the device within the ring.
4 shows for membership (i) the device will have a passcode/password with at least 12 characters (acting as a proxy for the passcode/password strength) and (ii) the user approves the device in the ring Shows the third ring that needs to do
Fig. 5 shows a fourth ring that requires the device to (i) have an enterprise profile configuration installed and (ii) know the cloud service password for membership.
Figure 6 shows a fifth ring for membership that requires (i) the device to have a password and (ii) the device to be verified as a genuine Apple device using an out-of-band process.
7-9 show examples of different views for the set of devices of FIG. 1, where each view is defined based on membership within one or more of the rings of FIGS. 2-6.
10 conceptually illustrates the software architecture of the device 1000 of some embodiments to enable grouping of devices into verification subgroups (rings) and synchronization subgroups (views).
11 conceptually illustrates a process 1100 of some embodiments for requesting membership within a ring.
12 conceptually shows a process 1200 of some embodiments for determining whether to allow a device within a ring.
13 conceptually shows that the first device requests to join the ring and is approved by the second device.
Fig. 14 conceptually shows a device joining a ring that requires not only possession of a secret encryption key, but also verification of device properties through a central authority.
15 conceptually illustrates a process 1500 of some embodiments for synchronizing keychain data from a first device with a second device.
16 shows the reception of a new data item for synchronization by the first device.
17 shows synchronization of a new data item from FIG. 16 from a first device with a second device.
18 and 19 illustrate a data protection structure in which an application specific private key is used to access data stored in the tree of keys and data fields, which ultimately allows access to the application data itself.
20 conceptually illustrates a process of some embodiments for dynamically modifying a device's ring membership and, subsequently, its view participation.
21A and 21B show the devices from FIGS. 16 and 17 when its password is changed such that one of the devices is removed from the ring.
22 shows an example of an architecture of a mobile computing device in which some embodiments are implemented.
23 conceptually illustrates another example of an electronic system in which some embodiments of the present invention are implemented.

In the following detailed description of the invention, a number of details, examples, and embodiments of the invention are presented and described. However, it will be apparent and will be apparent to those skilled in the art that the present invention is not limited to the presented embodiments and that the present invention may be practiced without some of the specific details and examples discussed.

Some embodiments provide a method for synchronizing data items between a set of related electronic devices. Specifically, some embodiments define verification subgroups to which devices can join when devices satisfy membership requirements for verification subgroups, and use verification subgroups to define synchronization subgroups to which devices participate. do. In some embodiments, different synchronization subgroups define different types of data items that devices participating in the synchronization subgroups share with each other through synchronization processes.

In some embodiments, the set of associated electronic devices includes all devices that the user associates with a third party service (eg, with the user's specific cloud service account). Knowledge of the cloud service account password serves as a requirement for membership within at least one of the verification subgroups (also referred to herein as rings) of some embodiments, but some embodiments may Defines additional rings that devices can join. In some cases, a user may own or use multiple smartphones, smartwatches, tablets, laptop computers, desktop computers, media players, etc., all of which are logged into the user's cloud service account. It has different properties.

Different embodiments require that the device has a certain operating system, a certain level of password strength, and has certain hardware (e.g., a secure processing unit such as the Apple Secure Enclave Processor) or other device configuration attributes. Define different sets of requirements for joining such additional rings, including those. Some embodiments allow the device to prove possession of a specific cryptographic secret to join a specific ring (e.g., possession of a key provided with a company profile to join a ring defined by the company), or a user already in the ring. It is necessary to verify the membership of the new device on the established device. In addition, some rings may require the new device to verify its properties for an established device through an out-of-band process (e.g., by using a third party for verification), where the device It serves as a persistent certificate of the attribute at the specific time of joining the ring.

In order for a device to join the ring, some embodiments require the device to sign a request to join the ring and have a request approved by one of the devices already in the ring. For example, in some embodiments, when the device meets the requirements for a ring that requires possession of a cryptographic secret, the device (i) has its public key (already shared with other devices) and into the ring. Sign with a private key generated from the cryptographic secret at the date/time of the application, (ii) package this signature with his identity used to join the ring, and (iii) sign the identity with his own private key. This signature is then sent to other devices in the ring as a request to join the ring. When one of the other devices verifies that the requesting device meets all the requirements for joining the ring, the established device notifies other devices in the ring, including the new device being added. In some embodiments, this notification includes a list of members of the ring, currently containing the new device.

In some embodiments, the devices may be members of multiple rings. In addition, devices can move dynamically in and out of those rings when the properties of the devices change so that the devices either newly meet the requirements or no longer meet the requirements of the various rings. When the properties of the device are changed (e.g., a profile containing a specific encryption secret is installed on the device, the user changes the device passcode length, etc.), the device becomes eligible for the ring, As described above, it creates and transmits a request for membership in the ring. On the other hand, when the device's properties change so that the device no longer meets the requirements for membership in the ring in which the device is currently a member, the device detects that it should no longer be a member of the ring, and this Send notifications to other devices that are members of the ring.

In some embodiments, rings are used to organize devices into synchronization subgroups (also referred to herein as views) to determine which data items stored on the device should be synchronized with other devices. In some embodiments, views are defined by (i) a set of requirements for a device to participate in the view and (ii) the type of data item that is synchronized between devices participating in the view. In some embodiments, the set of requirements for views is membership within one or more rings. For example, the requirements for participation in the first view may be membership within the first ring, while the requirements for participation in the second view may be membership within both the second and third rings. have.

Views are used to enable a set of related devices to synchronize data items with each other. In various embodiments, these synchronized data items include usernames and passwords, encryption for online accounts (eg, financial services websites, online forum sites, media content providers, online retail sites, etc.). Include some or all of the keys and/or secrets (i.e. data from which keys can be generated), network (e.g., Wi-Fi network) passwords, notes, photos, documents and other files, etc. . When one of the devices receives a new data item to be added to the set of synchronization data items (e.g., from user input of a new password, import or download of a new photo, etc.), the device of some embodiments displays the data in one or more views. It is dynamically tagged as belonging to. For example, the application for which data was created internally (e.g., Wi-Fi networks/passwords vs. online account usernames/passwords), username/type of website to which the account gains access (e.g., financial web Site vs. non-financial websites), data can be tagged based on whether the data is relevant to the company or not.

Data items belonging to a specific view are synchronized among devices participating in the specific view. In some embodiments, each pair of devices creates a secure channel between themselves (eg, using an off-the-record (OTR) messaging protocol) for use in transferring data items. In different embodiments, this secure channel may pass through a centralized service that allows temporary storage even when the receiving device is unlocked (eg, storage for a cloud service account to which devices on both sides are logged in). However, in some embodiments, the use of a secure channel protects these communications against man-in-the-middle attacks. Other embodiments use direct peer-to-peer connections (eg, via a Bluetooth connection). Synchronization of data items to a keychain is described in more detail in US Patent Publication No. 2014/0281540.

When the first device determines that its data items should be synchronized with the second device (e.g., based on user input, elapsed time, etc.), the first device Identify them. For each such view, the first device then identifies all synchronization data items that it stores and which (i) have not yet been sent to the second device and (ii) belong to the views to which the second device participates. Unless the views impose any additional requirements for the secure channel, the first device transmits the identified synchronization data items to the second device over the secure channel. When a view imposes additional requirements on a secure channel (e.g., encrypting data items with an encryption key required for membership within a verification subgroup), the first device uses a number of different secure channels to create a set of data items. It can be synchronized with the second device. The second device also performs a similar set of operations to synchronize its data items with the first device.

As devices dynamically join the rings and leave them, this can cause devices to join views and leave them. For example, if a particular view requires the device to be a member of the first and second rings, then if the device loses its membership within the first ring, the device retains membership within the second ring. Even if it does, it will no longer be possible to participate in a specific view. In some embodiments, when the device is no longer eligible to participate in a particular view, the device removes all data items belonging to that particular view, except for data items that also belong to other views to which the device still participates. Remove (or the device prompts the user to determine whether these data items should be removed).

The above describes examples of the data synchronization system of some embodiments. Several more detailed examples are described below. Section I describes a group of devices, and examples of rings and views that may be defined for the devices. Next, Section II describes the device architecture of some embodiments for enabling rings and views. Subsequently, Section III describes the ring join process of some embodiments, while Section IV describes the synchronization of data for different views. Section V then describes the results for dynamically evaluating the ring state and view participation in some embodiments. Finally, Section VI describes an electronic system in which some embodiments of the invention are implemented.

I. Ring and view examples

As described above, some embodiments define rings for a group of devices to which devices can join based on static or dynamic properties of the devices. These rings may, in various embodiments, be defined by manufacturers of devices, third party developers, or users themselves. For example, a manufacturer selling several different types of user devices, of which any number of user devices may be owned by a single user, may incorporate ring definitions into device operating systems. On the other hand, third-party developers or users can suggest additional rings that they find useful and design rings for some or all devices. In some embodiments, the manufacturer provides devices with a framework that allows users to arbitrarily define rings for their personal devices, where the framework has the ability to convert arbitrarily defined rings into functional ring definitions. Have.

Device manufacturers, third-party developers, or users can also organize devices into views based on ring memberships, as described above. That is, participation of the device in a specific view may be defined according to whether the device is a member of one or more rings. In some embodiments, views may also be defined with reference to device properties other than ring membership, while other embodiments limit the views to definitions based on ring memberships. In some embodiments, in addition to defining the ring membership criteria, the user can not only see what data is shared for a particular view, but also to participate in that particular view (i.e., to synchronize the specified data with other devices). It has the ability to define both sides of which rings the device should belong to.

1 shows an example of six electronic devices 105-130 that a single user can own. As shown, these six electronic devices include a first smartphone 105, a second smartphone 110, a tablet 115, a laptop computer 120, a streaming video set-top box 125, and a desktop computer ( 130). In this case, the first phone 105 and laptop 120 are the user's work devices, while the other four devices 110, 115, 125, 130 are the user's personally owned devices. Each of these devices has different properties, some of which are shown in this figure.

Specifically, the first smartphone 105 (which may be, for example, an iPhone 6) knows the password of the user's cloud service account (i) (because the user has logged into the cloud service account on that device), (ii) has a built-in fingerprint scanner, (iii) runs the iOS operating system, and (iv) features a remote wipe feature that allows the user to remotely instruct the phone to wipe its memory in case the phone is lost. Enabled, (v) have a passcode to unlock the device, which is at least 12 characters long, and (vi) enterprise constructs installed. Thus, the fingerprint scanner, long unlock passcode, and remote wipe features all indicate that the device is a secure device. In addition, the installation of the corporate construct of some embodiments provides a specific cryptographic secret to the device to enable generation of public/private key pairs.

The second smartphone 110 (which may be, for example, the previous iPhone) (i) knows the user's cloud service account password, (ii) runs the iOS operating system, and (iii) the remote wipe feature is enabled. And (iv) a 4-character passcode to unlock the device This smartphone 110, which has a shorter passcode and does not have a fingerprint scanner, is still quite secure, but less secure than the first smartphone 105.

The tablet 115 (e.g., iPad) (i) knows the user's cloud service account password, (ii) runs the iOS operating system, and (iii) a 4-character passcode to unlock the device Has. Laptop 120 (e.g., MacBook) (i) knows the user's cloud service account password, (ii) runs the Mac OS X operating system, and (iii) a 12-character pass to unlock the device Has a code, and (iv) the corporate structure is installed. The streaming video set-top box 125 (eg, Apple TV) only knows the password for the user's cloud service account. Finally, the home desktop 130 (e.g., iMac) (i) knows the user's cloud service account password, (ii) runs the Mac OS X operating system, and (iii) 12 to unlock. It has a character passcode.

These attributes, listed for various devices 105-130, are some examples of ring membership criteria (e.g., whether the user is logged into a cloud service account, the device's operating system, passcode strength, other security features, corporate It expresses the existence of an encryption secret through the composition). Those of skill in the art will recognize that many other criteria may be used to determine membership eligibility for a ring. As shown, some of these criteria are not properties of the device. For example, some embodiments use properties of applications running on the device (eg, whether the application is installed, how the application is set on the device, etc.) as a ring membership criterion. In addition, some embodiments include a specific user to join the ring, such as the user approving the device on another device already established in the ring, the user entering a code provided by the established device on the requesting device, etc. It requires actions. In addition, some ring membership criteria require third-party verification. For example, some embodiments require a third party certificate that the device is a valid iOS device. On the other hand, some ring membership criteria must simply be asserted by the device requesting membership (eg, the device passcode is at least a certain length).

2-6 provide examples of various rings of some embodiments for devices 105-130. 2 shows a first ring 200 with only a single criterion that the device knows the user's cloud service account passwords. Some embodiments use such a ring to have all of the devices owned by the user join the ring together, as long as the user logs the device to the cloud service account. In some embodiments, new devices generate a private key based on the account password using a deterministic public/private key generation algorithm and use this private key (which can be verified by any device already in the ring). You can apply to the ring by signing the application for ring membership using. Accordingly, all devices 105 to 130 are members of the first ring 200.

FIG. 3 shows a second ring 300 that requires (i) the device is running the iOS operating system for membership and (ii) the user needs to approve the device within the ring. Thus, no iOS device (ie, a random user's smartphone) can join the ring; Instead, the user of the established device must authorize the device to join within the ring. While user authorization provides an example of a security mechanism to prevent non-user devices from joining, some embodiments require knowledge of the cloud service account password (or other encryption secret) for all rings, so that the user Prevents the user's device from accidentally allowing in the ring with the user's actual devices. In some embodiments, the device asserts that it is an iOS device as part of the ring join procedure; Subsequently, a prompt to acknowledge that the device belongs to the user as well as that the device is iOS as claimed in the ring membership application (eg, "An iPhone wishes to join your iOS Device Ring; Please verify that this is your iPhone" A prompt that reads as, or similar information) is presented to the user. In other embodiments, the device is required to use a third party (eg, the device manufacturer) to verify that the device is an iOS device as claimed. This verification can be performed out of band before the device is approved in the ring. The second ring 300 has three members, that is, two smartphones 105 and 110 and a tablet 115 because the other three devices are not iOS devices.

4 shows for membership (i) the device will have a passcode/password with at least 12 characters (acting as a proxy for the passcode/password strength) and (ii) the user approves the device in the ring It shows the third ring 400 that needs to be done. As with the previous ring 300, the user authorization requirement prevents any random user device from joining the ring as soon as it has a passcode of sufficient length. Also, as described for ring 300, in some embodiments, a prompt appears on the user's established device requesting that the user approve the device as having a secure passcode/password. This ring 400 has three members, namely, a first smartphone 105, a laptop 120, and a home desktop 130.

FIG. 5 shows a fourth ring 500 that requires the device to (i) have a corporate profile component installed and (ii) know a cloud service password for membership. In some embodiments, devices may prove possession of a corporate profile construct by signing a membership request to join the ring with a private key provided as part of the corporate profile, the process in more detail below with reference to FIG. Is described. When a new device requests membership in the ring by sending a signed membership request, one of the established devices verifies this request using the company profile public key. Cloud service passwords limit membership to devices owned by a particular user, rather than to any member of the enterprise. This serves as a verification mechanism to ensure that the user approves the device joining the ring (by entering the cloud service password). Since only two of the user devices have these corporate profiles installed, the ring 500 contains only the smartphone 105 and the laptop 120.

Finally, FIG. 6 shows a fifth ring 600 for membership that requires (i) the device to have a password and (ii) the device to be verified as a genuine Apple device using an out-of-band process. Some embodiments require various out-of-band credentials for different ring memberships, requiring a third-party established device to authenticate some aspect the requesting device asserts to allow the requesting device in the ring. . For example, such third-party verification may be used to prove the validity of the device, the presence of a secure processor on the device, and the like, any of which may be ring membership requirements. The out-of-band verification of the membership criteria only verifies that the membership criteria are true at a specific time, but the presence of the ring allows continuous verification of the asserted criteria without requiring regular third-party verification. In the case of this ring, since all devices 105 to 130 are Apple devices, all those with passwords (smartphones 105, 110, tablet 115, laptop 120, and desktop 130) It is possible to join the ring 600.

In the examples above, membership in any of the rings for the requesting device somehow depends on verification of the membership criteria by the device already established in the ring. Some embodiments enable three different tiers of rings: (1) self-assertion rings that any device can join by simply asserting membership, (2) ) Application rings that require the device not only to assert membership but also to prove knowledge of the cryptographic secret, and (3) self-assertion (and in some cases, knowledge of the cryptographic secret) as well as Concordance rings requiring approval.

In some embodiments, self-assertion rings generally do not provide much security and therefore are not generally used to deploy view requirements (i.e., a device that simply asserts facts about itself is not subject to any No access to additional synchronization data) Instead, the assertion of these facts without verification may be part of the device identity used within membership requests for application rings and concordance rings. An example of a self-assertion ring would be a ring where the only membership criterion is for the device to assert that the device exists or that the device has a passcode, where the device is automatically added to the ring as soon as it makes such an assertion.

In some embodiments, an example of an application ring is a ring that requires a corporate key but does not require additional verification. Thus, to join the ring, the device must prove that it has the corporate key (eg, by signing an application with a private key). However, no additional level of verification is required for such a ring. For example, the user does not need to approve such a device, so any device that owns the cryptographic secret (which can thus generate the required key) can join the ring.

Finally, a concordance ring is the type of ring most commonly used to define views (ie, groups of devices that synchronize specific types of data). As mentioned, the concordance ring requires that the device request membership in the ring and that the application is explicitly verified (e.g., by prompting the user for approval) on a device already established in the ring. do. Concordance rings may also require a certificate of a specific cryptographic secret (e.g., a key generated based on a user's cloud service password, corporate key, etc.), but once the signature generated from that key is verified by the established device. In addition, the established device prompts the user of the device to verify that the requesting device should join the ring.

Further, some embodiments may use various out-of-band user interaction techniques (eg, out-of-band certificate of cryptographic secret) to verify that the device should be in the ring. For example, some embodiments rely on the user to return this secret to the requesting device in order to cause the established device to generate an encryption secret and to allow the established device to trust the requesting device. As an example, an established device can generate a random number that can cause a public/private key pair to be generated. When the user enters this on the requesting device, the requesting device can generate a private key and sign the ring membership request with the generated private key. Similarly, an established device may generate audio or image data (e.g., a quick response (QR) code), and may require the requesting device to capture such data, and public/private data in a deterministic manner. You can generate a key pair. One of ordinary skill in the art, depending on the two types of devices involved (e.g., a smartwatch that takes a picture of a QR code generated on a phone, moves one device close to another device in a specific manner, etc.) It will be appreciated that such techniques in the world may be possible.

Rings allow devices to verify that other devices have certain attributes, and persist certificates of these attributes so that devices do not need to verify attributes regularly. Using rings, some embodiments allow devices to form one or more synchronization subgroups or views that allow devices to share certain data items with devices that have verified certain attributes. Thus, in some embodiments participation in each view is defined based on membership within one or more rings; That is, only devices that meet the view requirements (by being allowed as members in one or more specified rings) can share synchronized data associated with the view.

Views enable layering of different types of data that are synchronized between user devices. As an example, a user wants certain data (e.g., most photos, insensitive documents, financial information or passwords to disable access to credit card numbers, etc.) to be shared among all user's devices. You can want. On the other hand, the user has other data (e.g., sensitive photos, confidential documents, passwords to financial websites or e-commerce sites that store the user's credit card information) less secure devices (e.g. You may want to stay away from streaming video set-top boxes that are not protected by. Also, some data may not be of any use on certain types of devices (passwords for mobile applications may not be useful on laptop or desktop devices that do not support such applications).

7-9 show examples of different views of the set of devices of FIG. 1. In these figures, each view is defined based on membership within one or more of the rings 200-600. While some embodiments only allow view requirements to be based on ring membership, other embodiments also have other types of requirements for a device to participate in the view (e.g., device properties such as those described above as ring membership requirements). Allow. In this sense (which defines view requirements based on ring membership), rings act similarly to certification authorities in that they are used to authenticate certain properties of devices, and those specific properties are then used by devices for synchronization purposes. It can be used to trust other devices.

As shown in FIG. 7, participation in the first view 700 is defined by membership within the first ring 200. As such, all of the six devices 105 to 130 participate in the first view. This figure shows that six devices 105 to 130 are connected in a full mesh framework, where each of the devices is capable of synchronizing with all of the other devices. As described in U.S. Patent Publication No. 2014/0281540, incorporated by reference above, some embodiments use a full mesh connection for synchronization between user devices, while other embodiments use other network components (e.g. A star network with one of the devices as the central hub) is used.

This figure shows that the three data items 705-715 belong to the first view 700. In some embodiments, as shown in Fig. 7, each data item stored on the device is tagged with view information specifying which view(s) the data item belongs to (a type of device that devices synchronize). For each data item; data items that are not eligible for synchronization will not be tagged as such). When one of the devices receives a new data item to add to the set of sync data items (e.g., from user input of a new password, import of a new photo from the camera, creation of a new document, etc.) It is dynamically tagged as belonging to the above views. For example, depending on how the views for the set of devices are defined, the application from which the data was created (e.g., Wi-Fi networks/passwords vs. online account usernames/passwords), username/account access The data may be tagged based on the type of website from which to obtain (e.g., a financial website versus a non-financial website), whether the data is related to a company or not.

In some embodiments, three data items 705-715 are stored in each of the three devices. Once one of the devices receives one of these data items, that device shares the data item with other devices through separate encrypted channels (i.e., a separate channel between each pair of devices). do. Thus, when the user first enters the password item 715 on the desktop computer 130, the desktop shares this item with each of the other devices 105-125 through separate channels. In some embodiments, these channels are password-authenticated key exchange, such as off-the-record (OTR) messaging, as described in U.S. Patent Publication No. 2014/0281540 and in more detail below. , PAKE).

Also as described in US Patent Publication No. 2014/0281540, in some embodiments, point-to-point connections use a cloud service arbiter. That is, in order for one of the devices (e.g., smartphone 105) to share the data item 705 with a second device (e.g., tablet 115), the transmitting device is The data item (encrypted with the public key) is transferred to intermediate storage in cloud services. The second device then retrieves the data item from the intermediate storage and decrypts the data item. Using PAKE allows devices to share sync data items in this way without being affected by man-in-the-middle attacks from the owners of the cloud service.

While the first view 700 includes all devices, FIG. 8 shows a second view that requires membership in both the third ring 400 and the fourth ring 500 for participation. Such a view, in essence, requires that the device be verified as having a corporate device (i.e., with a corporate profile installed) and having a highly secure password (at least 12 characters of length used as a proxy for security). To Only two devices, namely smartphone 105 and laptop 120, participate in this view. As shown, the view includes three data items 805 to 815, each of which is tagged as belonging to this second view V2. For example, data items may be tagged as belonging to the second view 800 if they are related to specific enterprise applications, or files specified by the user as work related. In this case, the addition of membership to the third ring 400 ensures that the user does not change one of their passcodes to a shorter and less secure passcode, which in doing so makes the third ring 400 and to This is because it will be expelled from the view 800 accordingly. In addition, one of the data items 815 is tagged as belonging to both the second view V2 and the third view V3. In some embodiments, data items may belong to multiple views and are shared to devices belonging to any of these views.

Finally, Figure 9 requires membership in both the second ring 300 and the fifth ring 600 (that is, the device needs to be an iOS device with a verified passcode as a genuine Apple device). A third view 900 is shown. In the case of this third view 900, three devices 105 to 115 participate, and two data items 815 and 905 are shared between these two devices. The data item 815 is synchronized with the devices 110 and 115 even if these devices do not participate in the second view 800. In other embodiments that require the device to be a member of each view to which the data item belongs, the smartphone 105 will not be allowed to share the data item 815 with any of the other devices.

Some embodiments allow the customization of this layering of synchronization data items by third-party developers or users of the devices themselves. For example, some embodiments provide a toolkit for developers to design rings and/or views for data associated with specific applications. For example, a developer of an enterprise application can design requirements for devices that share data items associated with the enterprise application (ie, specify specific password strength or other device requirements). In some embodiments, devices include a user interface for allowing users to customize how their devices synchronize data. That is, users can design different views for their data items based on a set of possible requirements, and devices will implement user selections through grouping rings into views. However, in other embodiments, the design of the rings and views is made by the device manufacturer who designs the set of user devices.

II. Device architecture

10 conceptually illustrates the software architecture of the device 1000 of some embodiments to enable grouping of devices into verification subgroups (rings) and synchronization subgroups (views). In this case, the device 1000 is one of several (N) devices associated with a cloud service account. For discussion in these and subsequent sections, it will be assumed that the various devices that join rings and share data items through views are all associated with a single user (eg, through a cloud service account or other user verification mechanism). Thus, in addition to device 1000, FIG. 10 shows a set of additional devices D ₂ to D _N 1005. Device 1000 and other devices 1005 may be any different type of electronic device capable of storing data and communicating with a network. For example, these devices include smartphones, tablets, laptop and/or desktop computers, smartwatches, set-top boxes (separated from or integrated into television), virtual devices running on other devices (e.g. , Virtual machines), and the like.

As shown, the device 1000 includes a synchronization engine 1010, a ring assessor 1015, a view evaluator 1020, a data tagger 1025, and a set of applications 1030. Include. The device also includes repositories 1035 for keychain data items, device and ring signing keys 1040, and view and ring requirements and description 1045. All of these repositories may be separate physical repositories (e.g., keys can be stored in more secure storage than view and ring requirements/technology) or the same physical storage (e.g., hard disk, solid state memory, random access Memory, etc.). In addition, some of the data can be embedded in the code of the modules. For example, if the view description and requirements are fixed, this information may be part of the view evaluator and data tagger, rather than separate data fetched from the repository by these modules.

In some embodiments, the keychain data store 1035 stores keychain data items, which are data items that are synchronized between the device 1000 and other devices 1005. In some embodiments, these data items are stored on device 1000 and encrypted with a public key associated with the device (and stored on other devices and encrypted with the public keys of those other devices). In some embodiments, this public key is a device specific key generated in a secure manner by the device when the device is initially formatted. Further, in some embodiments, each data item stored on the device is tagged as belonging to one or more views.

In some embodiments, the device and ring signing key store 1040 stores various keys that the device uses for data storage, data synchronization, and ring membership join/verify. For example, the device key is used by some embodiments to encrypt data items for storage on the device 1000, and US patent application Ser. No. 14/871,498 entitled "Backup System with Multiple Recovery Keys" In addition, it is also used to recover data backed up by one of the devices 1000 or 1005, as described in more detail in US Provisional Patent Applications 62/168,894 and 62/172,128. As described in more detail below, the key store 1040 also includes ring signing keys (e.g., a key generated from a shared user credential, such as a cloud service account password, used to join several different rings. Enterprise or other keys) as well as keys for protecting synchronization data items during transmission between devices (ie, keys for PAKE protected channels between each of device 1000 and devices 1005 ). In some embodiments, these keys may be stored in several different locations on device 1000, rather than in a single storage. For example, some of the keys may be stored in the secure processor, separate from the standard operation of the device 1000.

The view and ring requirements and description repository 1045 conceptually stores requirements for different rings, as defined by third party developers, device manufacturers, or users. These requirements, as indicated in the previous section, include possession of various credentials and/or encryption keys (e.g., shared user password or other credentials, corporate key, etc.), various device and/or application attributes (e.g., pass Assertion of code length, operating system, application composition, etc.), out-of-band verification of various attributes (e.g., operating system, device validity, etc.), or various user actions Inputting to, moving one device within proximity of another device, taking a picture of one device with another device, etc.) may be included. In addition, storage 1045 is a view requirement that in some embodiments identifies which rings a particular device (i.e., one of device 1000 or other devices 1005) should be a member of which rings to participate in each different view. Save them. In addition, storage 1045 includes, for each view, a view description that identifies which types of data items belong to the view. This view technology allows the data item to be received from which application (e.g., passwords from the Wi-Fi application for the first view, passwords from the web browser application for the second view), and which world wide web domain Data items for the view can be identified based on various characteristics including whether they are associated with (eg, passwords from a comprehensive list of financial web domains assigned to a particular view). In some embodiments, the view description simply specifies data items that are tagged as belonging to a particular view, and the user selects from a list of views the first time the data item is entered.

Through the applications 1030, a user of the device 1000 may input keychain data in some embodiments. Applications 1030 include applications that are integrated with the device operating system and originate from the device manufacturer (eg, built-in browser or email application, Wi-Fi application, etc.), as well as third-party applications (eg, banking applications, games). Applications, streaming video applications, etc.). The user enters usernames and passwords, or other keychain data through these applications 1030. Additionally, applications may receive keychain data in different ways (eg, by generating an encryption key, capturing a photo, etc.). Keychain data 1050 captured by applications 1030 in some embodiments is transmitted to data tagger 1025.

Data tagger 1025 is responsible for tagging keychain data 1050 (and keychain data items from any other sources when the data items are not yet tagged with view information) received from applications 1030. Process. In some embodiments, as shown, data tagger 1025 fetches view description information 1055 from view description and requirements store 1045 and uses this information to identify each of the keychain data items 1050. Determine which views belong to. In other embodiments, as mentioned, the view description is part of the data tagger code and does not need to be retrieved from the repository.

The data tagger 1025 attaches this view information to the keychain data. In some embodiments, the data tagger sends the view tagged keychain data 1060 to the synchronization engine 1010 (as shown), which uses the encryption key and function to encrypt the data items and These are stored in the keychain data storage 1035. In other embodiments, the data tagger encrypts view tagged keychain data 1060 using an encryption function and stores this data directly in storage 1035 without involving the synchronization engine 1010. In either case, some embodiments encrypt the data item but leave the view tags unencrypted so that the views to which the data item belongs can be identified (e.g., by synchronization engine 1010) without decrypting the data. have.

Ring evaluator 1015 (i) generates requests for device 1000 to join rings and (ii) requests from other devices 1005 to join rings for which device 1000 is already a member. Evaluate. To generate requests, the ring evaluator 1015 of some embodiments includes a self evaluator module 1016. This module uses ring requirements 1065 to determine when device 1000 meets the membership criteria for the ring. Ring requirements 1065 may be retrieved from repository 1045 (e.g., if defined by a user of the device or by third party developers) or (e.g., if hard coded by the device manufacturer) ring evaluator code Can be part of In some embodiments, the self-evaluator 1016 may ensure that device 1000 meets the requirements for a ring that is not yet a member, or no longer meets the requirements for a ring that is already a member. Is checked periodically to determine whether or not has changed. In other embodiments, the self-evaluator 1016 operates in an event driven manner. That is, when a device attribute (or other criterion affecting ring membership) changes, the self-evaluator 1016 is notified to determine whether the device's ring state should change.

Self-evaluator 1016 (other than any request driven actions such as the user approving ring membership or returning a code from one of the devices 1005 to the device 1000 (or vice versa)) When identifying that the device meets the criteria for joining the new ring, the ring evaluator 1015 signs the request, any keys 1067 required for the ring request (e.g., a device public key used as part of the device identity). The device private key and/or any ring-specific keys used to generate and sign a ring join request 1070). Details of such a request are described below with reference to FIG. 13, which illustrates the creation and transmission of a ring join request. Although not shown in this figure, ring evaluator 1015 may also send notifications to other devices when self-evaluator 1016 determines that the device should no longer be a member of a particular ring.

Ring evaluator 1015 also includes a credential checker module 1017 for verifying ring join requests 1075 received from other devices 1005. As with device 1000, when one of the other devices determines that it meets the criteria for joining the ring, that device generates a ring join request and sends it to other devices in the ring (some embodiments. In the field, each device stores a list of devices in each ring, including those that are not members). When device 1000 receives such a request, credential checker 1017 verifies whether the requesting device should be allowed within the ring it is requesting to join. This verifies that the request is signed with the appropriate key(s), any out-of-band criteria have been met, or out-of-band checks (e.g., whether the requesting device is a valid device, the code generated on device 1000 is Performing appropriate input on the device, etc.), whether the device properly asserted its criteria for joining the ring, whether the user of the device 1000 has approved the requesting device, and the like. When the ring join request is verified, the ring evaluator 1015 sends a ring status message (not shown) to the other devices 1005 in the ring. In some embodiments, the ring status message is a list of devices in the ring, including the recently added device. This not only notifies the requesting device that it has successfully joined the ring, but also informs other devices that the device 1000 has approved the requesting device's membership (and therefore they do not need to process the membership request separately). It plays a role to do. In some embodiments, this notification message is signed with the private key of the ring specific key pair (eg, the key used to sign the membership request).

Ring evaluator 1015 also keeps view evaluator 1020 regularly aware of the current ring state 1080 of device 1000 as well as other devices 1005. In some embodiments, the view evaluator 1020 requests this information as needed from the ring evaluator 1015 (or from the repository where the ring evaluator stores this information). View evaluator 1020 is responsible for determining which of the devices (including device 1000 and other devices 1005) participate in each of the different views defined for the group of devices. Specifically, in some embodiments, the view evaluator is the mapping between views and devices (ie, for each device, at any given point in time, based on the current ring membership state of all devices). Participate in; or, for each view, which device participates). The view evaluator 1020 is, again, view requirements (which may be coded within the view evaluator by the device manufacturer in various different embodiments or may be variable information generated by third party developers and/or users). 1085).

In addition to defining which rings a device must be a member of in order to participate in a view, the view requirements of some embodiments also define any requirements for the channel used to synchronize data for the view between devices ( Or for all). As mentioned above, in some embodiments, devices form peer-to-peer encrypted channels, e.g., using PAKE (relying on a shared key on which data items are encrypted during synchronization). Also, some views require the device to be a member of a ring that requires possession of a public/private key pair on its own. Some such views require the channel between the two devices to use this key in addition to (or as an alternative to) the shared key for PAKE. For example, for a corporate view that requires membership within a corporate ring that requires ownership of a corporate private key, some embodiments encrypt data items synchronized for that view using the corporate private key. Accordingly, the view evaluator 1020 provides the synchronization engine 1010 with (i) a mapping 1090 between views and devices and (ii) requirements 1095 for synchronization channels for each view.

In some embodiments, synchronization engine 1010 is responsible for synchronizing view tagged keychain data items with other devices 1005. In some embodiments, the synchronization engine 1010 determines that it should synchronize the data items with the other device, and from the view evaluator 1020 a list of views 1090 in which a particular other device participates and any Receive the special channel requirements of In some embodiments, the synchronization engine 1010 synchronizes only one channel at a time, so it is only a list of views that use a particular channel between device 1000 and another device (in the absence of special channel requirements. , This will be all views in which both the other device and the device 1000 participate) from the view evaluator 1020. The synchronization engine 1010 retrieves view tagged keychain data items 1097 belonging to the correct views from the keychain data store 1035 and synchronizes these data items with other devices through a secure channel. In some embodiments, this involves removing encryption for keychain data items used during storage on the device and re-encrypting keychain data items with the shared key used for the secure channel.

One skilled in the art will recognize that the set of modules shown in this figure is a subset of the device's software architecture comprising a wide range of modules for any number of purposes. Further, many of the illustrated modules will themselves include several modules, and various modules that can be reused by several of the illustrated modules are not illustrated. For example, the synchronization engine when synchronizing data with other devices (as shown below with reference to FIGS. 16 and 17) and ring applications of other devices (as shown below in FIG. 13) Encryption and/or decryption functions may be used by the ring evaluator (to sign and/or verify ring applications).

III. Join to rings

In order for a device to join the ring, some embodiments require the device to sign a request to join the ring and have a request approved by one of the devices already in the ring. For example, in some embodiments, when the device meets the requirements for a ring that requires possession of a cryptographic secret, the device (i) has its public key (already shared with other devices) and into the ring. Sign with a private key generated from the cryptographic secret at the date/time of the application, (ii) package this signature with his identity used to join the ring, and (iii) sign the identity with his own private key. This signature is then sent to other devices in the ring as a request to join the ring. When one of the other devices verifies that the requesting device meets all the requirements for joining the ring, the established device notifies other devices in the ring, including the new device being added. In some embodiments, this notification includes a list of members of the ring, currently containing the new device.

11 conceptually illustrates a process 1100 of some embodiments for requesting membership within a ring. In some embodiments, the device (eg, the device's ring evaluator) performs process 1100 when it determines that the device meets all the requirements for joining the ring. Device properties are changed (e.g., the user adds a passcode to protect access to the device, a construct containing the encryption key is installed on the device, the user enters the cloud service account password on the device) And so on), when the device is currently able to join a ring that is not a member, the device performs process 1100 (or a similar process) in some embodiments.

As shown, process 1100 begins with (at 1105) retrieving a device signing key pair. In some embodiments, this is a public/private key pair that is randomly generated by the device (and stored on the device) when the device operating system is initially started and configured by the user of the device. That is, when a user first purchases a device and configures the device for use by the user (or when resetting and reconfiguring the device's operating system), the device is made public/private based on randomized seed data. Generate a key pair. In some embodiments, the seed data for the key pair is not related to any device hardware, so when a new key pair is created for the device (when the user reformats the device), the new key pair is It will not have any cryptographic relationship with the key pair. In some embodiments, the device uses the device public key shared with other devices belonging to the user (ie, devices that cause the device to join rings) as part of its identity. The device includes backup recovery (as described in U.S. Patent Application Nos. 14/871,498 entitled "Backup System with Multiple Recovery Keys" as well as U.S. Provisional Patent Applications 62/168,894 and 62/172,128). It uses his private key to encrypt data items it stores, as well as for the purpose. Also, in some embodiments, the device signs ring membership requests using its private key.

Next, process 1100 determines (at 1110) whether the ring for which the device is requesting membership uses the certificate of the secret key for verification. That is, some rings require the device requesting membership to indicate that it possesses a particular private key (eg, by signing the membership request), and the devices established for it have a public key.

When such a key is required, the process generates (at 1115) a ring signing key pair based on the ring requirement data (or retrieves a ring signing key pair if the key has already been generated). For example, some embodiments require the user to enter a specific passcode/password to join the ring. The device then generates a key pair from this password in a deterministic manner, which is used for ring membership requests. In some embodiments, the seed data from which the key pair is generated is provided to the device as part of configuring the device for a specific purpose. For example, if a device is owned by an enterprise and used by an employee of the enterprise, the enterprise can install their enterprise specific constructs on the device containing seed data used to generate a public/private key pair The device can be used to join enterprise specific rings. Similarly, it can be joined to an application specific ring using the encrypted data available in the application download.

In addition, the process performs (at 1120) any additional ring credential verification. This is necessary for ring membership, but may involve self-identification-specific properties of the device that do not require external verification. For example, some embodiments require the device to assert, but it is running a specific operating system, a specific type of device (the device type is a smartphone, a specific brand of smartphone (e.g., Apple, Nokia, HTC, etc.), specific versions of the device (e.g., iPhone 5, iPhone 6, etc.), etc.), at least having a passcode of a certain length, etc. Does not.

Additional ring credential verification may also involve out-of-band verification (in some embodiments, performed after the ring membership request is transmitted, rather than before). Out-of-band verification requires the device to prove rather than simply assert the attributes required for membership in the ring. For example, a device may need to prove, through a third party, whether it has a valid device from a specific manufacturer, whether it runs a specific operating system, whether its passcode is at least a specific length, or other attributes. I can.

Next, the process signs the ring membership application (at 1125) using the device private key as well as any private ring signing key (ie, any key generated in operation 1115). This means that the device, through its ring membership application, is (i) it is a device claiming to be itself because only that device has a private key paired with its shared public key, and (ii) it joins the ring It makes it possible to prove that you own the encryption secret required to do so. In some embodiments, the signed ring membership application also includes the application time as well as other device identification information including its public key. The signed ring request of some embodiments is described in more detail below with reference to FIG. 13.

Finally, the process sends (at 1130) the signed ring membership application to other devices already in the ring. In some embodiments, each device associated with the user (e.g., by logging in to a user account, by joining a ring that requires a user password, etc.) of devices that are members of each possible ring Store the list and use this list to send ring membership requests to other devices in the ring. As long as one of these devices approves the membership request (eg, using a process such as that shown in FIG. 12 described below), the device is added to the ring.

12 conceptually shows a process 1200 of some embodiments for determining whether to allow a device within a ring. In some embodiments, the first device performs process 1100 (or similar process) to generate a signed request for ring membership and sends the request to devices established as members of the ring. Then, one (or more) of these established devices perform process 1200 (or a similar process) to allow the device within the ring (assuming the membership request is appropriate), or Reject the request.

As shown, process 1200 begins (at 1205) by receiving a request from another device to join a ring to which the local device (which process 1200 is executing) already belongs. In some embodiments, this request is received via a point-to-point connection from another device wishing to join the ring. This point-to-point connection may be transmitted through a direct connection (eg, a Bluetooth connection between devices, etc.) or through a central repository. For example, in some embodiments, the requesting device sends messages stored in a central repository to multiple established devices, each of the established devices retrieving these requests when they are active. That is, a device that is locked or powered off may not be able to receive the request until it is unlocked, powered on, and lit.

Upon receipt of the request, the process determines (at 1210) whether the request has already been approved by another device. In some embodiments, because the requesting device sends a membership request to each of the established devices in the ring, in some cases, one of the established devices is one of the other established devices already placing the requesting device in the ring. We will start processing the request only to determine that it has been added. In some embodiments, the established device sends a notification to other established and new devices when the requesting device is added to the ring. In this case, the process 1200 ends.

Assuming that the requesting device has not yet been added to the ring, process 1200 determines (at 1215) whether the request properly identifies the ring. To join a ring, some embodiments require the requesting device to create a request that identifies members of the ring and/or other aspects of the ring. If the request does not properly identify the ring, the process ends.

Next, the process determines (at 1220) whether the requesting device meets all criteria for membership in the ring. As described, this is by using the key to sign the request, by asserting the properties of the requesting device (its operating system, type of device, etc.), or by verifying the requirements of ring membership out of band. It may include proving possession of a specific encryption key. Thus, determining whether the requesting device meets all criteria may involve initiating an out-of-band process or determining whether an out-of-band process has already been performed to verify the requesting device's specific criteria. . If the requesting device does not meet the criteria, the process ends (and the requesting device is not added to the ring).

Finally, if the requesting device is otherwise approved for ring membership, the process determines (at 1225) whether the ring requires user approval. This is a specific type of ring criterion, in that it requires a user action on the granting device to allow the requesting device to be allowed in the ring. When no user authorization is required, the process proceeds to 1240, described below, to add the requesting device to the ring.

When user approval of the requesting device is required for ring membership, the process (at 1230) displays an approval prompt on the local device (the device performing process 1200). Such a prompt may simply indicate that the device is requesting membership to join the ring, or it may provide additional context. For example, the prompt may indicate the name of the device (eg, John's iPhone), the type of device, the name of the ring, or other information that helps the user in evaluating whether the request is valid. The process then waits for the user to indicate whether or not to allow the requesting device in the ring (not shown).

Once the user responds to the prompt, process 1200 determines (at 1235) whether the user has approved the requesting device. When the user does not approve the requesting device, the process ends. However, when the user approves the requesting device, the process adds the requesting device to the ring (at 1240). In some embodiments, the established device (performing process 1200) sends the requesting device by sending a message to all members of the ring (including the requesting device) using a list of all members of the ring. Add it to the ring. Some embodiments sign such a message with the sending device's private key.

13 conceptually shows a first device 1300 requesting to join a ring through four stages 1305-1320 and being approved by a second device 1325. The first device 1300 may be any type of electronic device capable of joining a ring, such as a smartphone, smartwatch, tablet, laptop or desktop computer, and the like. For a first device 1300, this figure shows a first storage in which the first device 1300 stores information about the various rings in which a group of devices (including the first device D1) 1300 participates. Including 1330 is shown. As shown in the first stage 1305, these include a first ring with D2 and D3 as members, a second ring with all three devices as members, and a third ring with D2 as the only member. . The first device 1300 also includes a second storage 1335 that stores various keys associated with other devices and/or rings. These include the public keys for D2 and D3, as well as the public/private key pair of the device 1300 itself.

In this first stage 1305, the company profile 1340 is installed on the first device 1300. As shown in the second stage 1310, the company profile 1340 includes a company key pair (or seed data from which the company key pair is generated) stored in the key store 1335. The company profile 1340 may also include the installation of applications, various security measures, etc. on the device 1300.

In a third stage 1315, the ring evaluator 1345 of the device 1300 determines that the device currently owns the credentials (ie, the corporate private key) for joining the first ring. As such, the ring evaluator uses the request signer 1350 to generate the request. In some embodiments, the request signer is a cryptographic digital signature generation function that uses a private key to sign a message or other piece of data. Subsequently, the first device (D1) 1300 transmits the request 1355 to the second device (D2) 1325. Although not shown, in some embodiments, the first device 1300 also sends a request to D3.

In some embodiments, the request 1355 is generated by the first device 1300 using a process such as that shown in FIG. 11. Specifically, in some embodiments, device 1300 (i) signs with its public key (already shared with other devices) and a private key generated from the encryption secret at the date/time of application to the ring, and ) Package these signatures with his identity used to join the ring, and (iii) sign the identity with his own private key. As shown, the most central part of request 1355 includes the time the first device is applying to the ring as well as the device's public key. This set of data (public key + application time) is then signed with a ring specific private key (ie, a corporate key received by device 1300 as part of a corporate profile). The device identity (also referred to as peer information) includes this signature, as well as other data about the device (eg, its name, hardware specific identifier, and/or other data). This device identity is then signed with the private key of the device 1300, thereby authenticating that the request is actually originating from the first device.

In the fourth stage 1320, the second device 1325 receives the request 1355 and verifies the request. The second device 1325 uses the public key of the first device (previously shared) as well as the signature verifier 1360 using the corporate public key (this device is already in the corporate ring and stores the corporate key pair accordingly). ) Is used. When the signature verifier 1360 verifies that the request is properly signed by the first device, the ring evaluator 1365 on the second device 1325 adds the first device 1300 to the first ring. Although not shown in this figure, the second device 1325 transmits a message to both D1 and D3 indicating that all three devices are members of the first ring. In some embodiments, this message is signed by the second device 1325.

The ring joined by the first device of FIG. 13 only needs to sign a request to prove possession of the corporate link key. However, as mentioned, in some cases rings may also require additional requirements. FIG. 14 conceptually shows that the same device 1300 joins the third ring through five stages 1405 to 1425, which require not only possession of a secret encryption key, but also verification of device properties through a central authority. do. In the first stage 1405, the device 1300 receives the encryption secret 1430 for the third ring (eg, through user input, download, etc.). As a result, the second stage 1410 shows that the key store on the first device 1300 contains a public/private key pair generated from the encryption secret 1430.

In the third stage, the first device 1300 sends a signed request 1435 to join the first ring to the second device 1325. In this case, since the second device is the only device that is currently a member of the ring, the first device only sends the request to the second device. In some embodiments, request 1435 is signed in the same manner as request 1355 shown in the previous figure. That is, the request includes the time of application to the first ring along with the public key of the first device, and is signed with the private key generated from the encryption secret 1430. This information is then packaged with a device identity, which device identity is then signed with the private key of the device 1300.

In a fourth stage, prior to accommodating the first device in the first ring, the second device 1325 receives a verification 1440 of the attributes of the first device 1300. In this case, the devices use the central authority 1445 to verify the device properties through a process that can be initiated by either of the devices. The central authority 1445 may be a manufacturer of a device that verifies that the device is genuine or that the device has a specific operating system. As discussed above, the out-of-band process, in various embodiments, may involve user actions rather than a central authority, or may involve a direct exchange of information between the two devices. Finally, in the fifth stage 1425, the second device 1325 verifies the request and adds the first device 1300 to the first ring as in the previous figure.

IV. Synchronization process

Once devices are established in rings (subgroups for verification purposes), they can be arranged in views (subgroups for synchronization purposes). As mentioned, in some embodiments rings are used to organize devices into views, and the views are used to determine which data items stored on the device should be synchronized with other devices. In some embodiments, views are defined by (i) a set of requirements for a device to participate in the view and (ii) the type of data item that is synchronized between devices participating in the view. In some embodiments, the set of requirements for views is membership in one or more rings (as indicated above with reference to FIGS. 7-9).

Views are used to enable a set of related devices to synchronize data items with each other. In various embodiments, these synchronized data items include usernames and passwords, encryption for online accounts (e.g., financial services websites, online forum sites, media content providers, online retail sites, etc.) Keys and/or secrets (i.e. data from which keys can be generated), application specific service keys that allow access to application-related data stored on a central server, network (e.g., Wi-Fi network) passwords, notes Includes some or all of the files, photos, documents, and other files.

15 conceptually illustrates a process 1500 of some embodiments for synchronizing keychain data from a first device with a second device. In this case, the process performs a synchronization process for a specific secure channel between the first and second devices, and the specific secure channel is the only secure channel between devices or one of several secure channels between devices. Can be While this process performs synchronization for all views over a specific secure channel, other embodiments synchronize (at once) all devices for a specific view, or all views (regardless of channel) for a specific device. ) You can use the processes you perform.

As shown, process 1500 begins (at 1505) by receiving a command to synchronize data for a particular remote device over a particular channel. In some embodiments, the process is performed on a first device participating in at least one view with a second remote device. The first device may periodically synchronize the data items with the second device, may synchronize the data items based on user commands, or the first device receives a new data item and The data items may be synchronized whenever it is determined that the data item should be synchronized with the second device (based on the set).

In some embodiments, each pair of devices within the entire group of devices establish a secure channel between themselves (e.g., using an off-the-record (OTR) messaging protocol) for use in synchronizing data items. Generate. In some embodiments, unless the views impose any additional requirements on the secure channel, the first device sends the identified synchronization data items for all views to which both devices participate through the secure channel to the second device. Transfer to. When a view imposes additional requirements on a secure channel (e.g., encrypting data items with an encryption key required for membership within a verification subgroup), the first device uses a number of different secure channels to create a set of data items. It can be synchronized with the second device. In this case, in some embodiments process 1500 is performed separately for each channel.

Next, the process (at 1510) identifies the set of views to which devices of both sides (the local device performing the synchronization and the device to which the data will be synchronized) participate. In some embodiments, the view evaluator module in the device generates a set of views in which the remote device participates, based on rings in which the remote device is a member. As discussed above, each device tracks the rings in which each other device in the group is a member, so that data can be used to determine views. Similarly, the device knows which views it participates in, based on its own ring memberships.

Process 1500 identifies new synchronization data items that have been tagged for any view (views in which both devices participate) in the identified set (at 1515) and have not previously been synchronized with the remote device. The device is part of its keychain and only synchronizes data belonging to at least one view to which the remote device also participates (i.e. data belonging to the views it is a member of). When the first device receives a new data item to add to the set of synchronization data items (e.g., from a user input of a new password, import or download of a new photo, etc.), the device of some embodiments may transfer the data to one or more views. Dynamically tagged as belonging. For example, the application for which data was created internally (e.g., Wi-Fi networks/passwords vs. online account usernames/passwords), username/type of website to which the account gains access (e.g., financial web Site vs. non-financial websites), data can be tagged based on whether the data is relevant to the company or not. When synchronizing data items with a remote device, the first device identifies all synchronization data items it stores and has not yet transferred to the second device (and belongs to the views to which the second device participates).

With the identified data items, process 1500 (at 1520) decrypts these new data items as they are stored on the local device. In some embodiments, the decryption process uses the private key of the local device, ie, a key known only to that device. In some embodiments, data items are stored on the device in an encrypted form encrypted using the device public key. Some embodiments also encrypt data items with one or more additional keys for storage on the device, such as the public key of the key pair (eg, user password based key pair, corporate key pair, etc.) used to join the ring. For each public key used to encrypt the data item for storage on the device, the process decrypts the data item using the corresponding private key.

Next, the process encrypts the data items for transmission to the remote device according to the requirements of the secure channel to which the items will be transmitted (at 1525). As mentioned, some embodiments use a password authentication key exchange (PAKE) that relies on a shared key used to encrypt messages between devices. In some cases, the view requirements for a particular view include data items belonging to a particular view, such as using an additional key (e.g., a key that needs to be owned to join a ring, membership that is a requirement for a particular view). Additional restrictions can be imposed on the secure channel for synchronization. Thus, some embodiments encrypt data items at least with a shared key, and possibly additional keys.

Finally, the process sends (at 1530) encrypted items for the view to the remote device over a secure channel between devices. In different embodiments, this secure channel may pass through a centralized service that allows temporary storage even when the receiving device is unlocked (eg, storage for a cloud service account to which devices on both sides are logged in). However, in some embodiments, the use of a secure channel protects these communications against man-in-the-middle attacks. Other embodiments use direct peer-to-peer connections (eg, via a Bluetooth connection). Upon receipt of encrypted items, in some embodiments the remote device decrypts the items (as encrypted on the channel) and re-encrypts them for local storage using its own public key. In some embodiments, the remote device also performs a process similar to process 1500 to synchronize any of its new data items with the local device.

16 and 17 conceptually illustrate a pair of devices 1600 and 1650 that synchronize data with each other. Specifically, FIG. 16 shows the reception of a new data item for synchronization by the first device 1600 through two stages 1605 and 1610. The first stage 1605 shows items stored by each of the two devices 1600 and 1650. In this example, the first device 1600 participates in the views V1 and V2, while the second device 1650 participates in the views V1 and V3. As shown, the first device stores item 1 (1615), item 2 (1620), and item 3 (1625). The two first items 1615 and 1620 belong to the first view V1, while the third item 1625 belongs to the second view V3, and data items are tagged accordingly. The second device stores item 1 (1615), item 2 (1620), and item 4 (1630). The fourth item 1630 belongs to V3, which is why this item is stored only on the second device 1650. Finally, this stage shows a legend representing the representations used in these and subsequent figures to represent the encryption of data items by different keys. Items stored on the first device 1600 are encrypted with the key of the first device, while items stored on the second device 1650 are encrypted with the key of the second device.

In the second stage, the user of the first device 1600 (this user is also a user of the second device 1650, and the devices thus synchronize data with each other) are sent via the application 1640 to data item 5 1635. ) To the device. These include web browser applications that allow users to enter passwords, third-party applications that use passwords, applications that allow users to create new files (e.g., documents through word processing applications, images captured through camera applications, etc.), Or it could be another application that allows the device 1600 to receive data.

This fifth data item 1635 is transmitted to the data tagger 1645 on the first device 1600, the data tagger identifies the data item as belonging to the first view V1, and tags the item accordingly. . This may be due to the application 1640 that caused the item to be received, or other data that identifies the data item (its file type, the web domain it is associated with, etc.). The item is also sent to an encryption function 1655 (e.g., performing asymmetric encryption such as RSA, DSS, elliptic curve encryption, etc.). The encryption function 1655 encrypts the data item 1635 for storage using the public key of the first device (not shown). In some embodiments, as shown in this figure, the view information is not encrypted because this information is not sensitive and the device should not be required to decrypt the view data to access the view data.

FIG. 17 shows the synchronization of a new data item 1635 from the first device 1600 with the second device 1650 through three stages 1705-1715. As shown in the first stage 1705, the view evaluator module 1720 on the first device 1600 notifies the synchronization engine 1725 to synchronize the data with the second device. The mapping of devices to views indicates that V1 is the only view in which both devices participate, and thus only data items tagged as belonging to V1 should be synchronized between devices.

Thus, in the second stage 1710, the first device 1600 transmits the new data item 1635 to the second device 1650. As shown by several dashed and dashed lines for the representation of the new data item 1635 in this figure, the first device encrypts the stored data item using its own private key (and potentially any other key required). Release, and then encrypt the plaintext version of the data item using the shared key over the secure channel between the devices. The synchronization engine 1725 on the first device 1600 then transmits the encrypted data item 1635 over a secure channel, where it is received by the synchronization engine 1730 on the second device 1650. In some embodiments, as a requirement of a secure channel, the view tag on data item 1635 is also encrypted using a shared key. As mentioned, although shown as a direct connection between two devices 1600, 1650, in some embodiments, data item 1635 is a central repository (e.g., cloud storage) by first device 1600 And subsequently fetched from the repository by the second device 1650.

The third stage 1715 shows a second device 1650 that stores a data item 1635. After receiving the data item, the device 1650 decrypts the item using the secure channel's shared key (and any other keys required, depending on the channel requirements for V1), and then its own public key ( And, if possible, use additional encryption keys) to encrypt the key for storage.

As mentioned, in different embodiments synchronization data items may include several different types of items including password/username combinations, Wi-Fi networks and corresponding passwords, encryption keys, files, etc. have. In some embodiments, the data items include application specific keys that enable access to application related data stored in the cloud service through a hierarchy of nested keys. That is, for each application on the device (or each subset of applications on the device), the synchronization data includes an application specific private key (eg, photo application key).

An application specific private key is used to access the data stored in the tree of keys and data fields, which ultimately allows access to the application data itself. This protective structure is shown in FIGS. 18 and 19. FIG. 18 shows a container structure 1800 stored in a centralized repository (eg, cloud storage) and capable of being downloaded by a device in some embodiments. The container structure 1800 is encrypted with an application specific public key, including its own private key 1805 (or seed data used to generate the private key). Thus, access to these container private keys requires possession of an application specific private key that is synchronized as a keychain data item. The container structure 1800 representing a high-level overview of the application is a container public key 1805, as well as a set of unencrypted fields 1810 (Field_1 to Field_M) that do not require any keys to access. Each contains both sides of the set of fields 1815 (Field_M+1 through Field_N) that are encrypted (and therefore require possession of the container private key for access).

In addition, the container public key is used to encrypt the zone private key 1905 which is part of the zone structure 1900. Thus, access to the zone structure requires access to the container private key 1805, which in turn requires access to the application specific service key. Like the container structure 1800, the zone structure 1900 includes several unencrypted fields 1910 (Field_1 to Field_Q), and several fields 1915 encrypted with a zone key (Field_Q+1 to Field_R) Include. While the container represents a high level overview of the application, in some embodiments the zone represents a specific database or table within the container. For example, a zone may represent a set of photos associated with an application, where each photo is represented by a record (and records are represented by a zone).

In some embodiments, each of the records referenced by a zone may include a key for a specific piece of application data (eg, a specific photo). In some embodiments, each record has a key encrypted with its zone public key, thus requiring a zone private key to access. Records are structured like zones and containers with unencrypted fields and encrypted fields. For example, fields for a photo record may store a title, location, timestamp, etc. for the photo, as well as a key to actually unlock the photo. In some embodiments, the record key unlocked by the zone key is a symmetric key rather than the private key of the public/private key pair.

In addition to being shared through the synchronization process, as described in U.S. Provisional Patent Applications 62/168,894 and 62/172,128, as well as U.S. Patent Application Nos. 14/871,498 and U.S. Patent Publication No. 2014/0093084. In some embodiments, application-specific keychain data items may be recovered through a secure escrow system.

V. Dynamic changes to group membership

2-6, in some embodiments, devices may be members of multiple rings. In addition, devices can move dynamically in and out of these rings as the properties of the devices change so that the devices are newly meeting the requirements or no longer meet the requirements of the various rings. The properties of the device are changed (e.g., a profile containing a specific encryption secret is installed on the device, the user changes the device passcode length, or adds the passcode to the device, etc.) When eligible, the device generates and sends a request for membership in the ring, as described above. On the other hand, when the device's properties change so that the device no longer meets the requirements for membership in the ring in which the device is currently a member, the device detects that it should no longer be a member of the ring, and this Send notifications to other devices that are members of the ring.

A device joining or leaving the ring may also affect the device's participation in one or more views. For example, when a device joins the ring, the device may be currently able to participate in a new view, and therefore must receive (via a synchronization process) data pertaining to that new view. On the other hand, when the device leaves the ring, the device may no longer be allowed to participate in one or more views that require membership within a particular ring in which the device is no longer a member. This will be recognized by other devices associated with the particular device, and those other devices will no longer share data pertaining to these affected views with the particular device. Also, in some embodiments, a particular device will delete all data items for which it is no longer entitled. In another embodiment, if the user wants to keep the data on the device even if the device no longer receives new data for the view, the device queries the user before deleting any data.

20 conceptually illustrates a process 2000 of some embodiments for dynamically modifying a device's ring membership, and subsequently, its view participation. Process 2000 is performed by the device, in some embodiments, evaluating his own ring membership and then his view participation. As indicated above, the device may be a smartphone, smartwatch, tablet, laptop computer, desktop computer, or any other device that participates in a synchronization system between related devices.

As shown, process 2000 begins with (at 2005) identifying a change in the device configuration (of the device executing the process). Changes to the device configuration include changes to the device's passcode by the user (e.g., changing from a four-digit passcode to a long passcode or vice versa, eliminating the use of a passcode on the device, and transferring the passcode to the device). Adding, etc.), installing an application on the device, upgrading the operating system of the device, modifying the application or device settings, acquiring a new encryption secret, and the like. While some embodiments regularly check for changes related to the enumerated set of ring requirements, in some embodiments process 2000 is an event driven event that causes specific changes to the device to be performed. to be.

The process determines whether (in 2010) any additions to the ring membership occur due to the change. Referring to the rings 200, 300, 400, 500, 600 of Figs. 2 to 6 above, examples of such modifications are to allow the user to enter the passcode on the smartphone 110 or table 115 in 4 characters. Rather, it may be changed to have at least 12 characters, a case where an enterprise configuration is installed on the home desktop 130 or one of these devices, a case where a device passcode is added to the streaming video set-top box 125, and the like. As discussed above, many other types of changes may also make the device eligible for membership in the ring.

When a change to the device configuration results in eligibility for membership in at least one ring, the process generates a request to join the ring (in 2015) and sends this signed request to other devices in the ring. . In some embodiments, the device performs process 1100 of FIG. 11 to create and transmit a ring signed in 2015. Once the device has successfully joined the ring (assuming the membership request is valid), if the ring membership causes the device to participate in one or more additional views, then process 1500 or a similar process is performed by one of the other devices. Can be performed to synchronize data items belonging to these additional views with these devices.

The process also determines (at 2020) whether the change is causing removal from any rings to the device. Referring again to the rings of FIGS. 2-7, examples of such changes are the removal of the enterprise component from either the smartphone 105 or the laptop 120, any of the devices 105-120 or 130 May be removal of the passcode from, shortening of the password on the smartphone 105, laptop 120, or desktop 130, and the like. Many other types of changes (eg, revoking a password or encryption key from the device) can also cause the device to lose membership eligibility in the ring as well.

If none of the device configuration changes have resulted in the removal of the device from any rings, the process 2000 ends. However, otherwise, the process notifies other devices in the ring (at 2025) about the removal of the device from the ring. Some embodiments send a message signed with the device's private key to indicate this change. In addition to notifying other devices in the ring, some embodiments also notify any other related devices that are not in that particular ring (eg, other devices of the same user). For example, if the smartphone 105 is removed from the ring 500 (because the enterprise component has been removed from the device), it will notify all of the devices 110-130 in some embodiments.

In addition to determining whether a device change affects the device's ring state, if the device leaves the ring, process 2000 also handles potential view participation changes for the device. Thus, the process determines (at 2030) whether removal from any of the views occurs due to ring membership removal. Since participation in any particular view is determined based on membership within one or more rings, removal from one of the rings used to determine view participation will cause the device to no longer be eligible to participate in the view. will be. For example, using the example in the previous paragraph, the removal of the smartphone 105 from the ring 500 will subsequently result in the smartphone no longer eligible to participate in the second view 800. .

There is no need to notify other devices participating in the view when the device is removed from the view, since other devices will draw the same conclusion based on the removal of the device from one of the required rings. However, in some embodiments, process 2000 deletes (at 2035) any synchronization data items that no longer belong to any views to which the device participates. As mentioned above, some embodiments do not automatically delete such data, but instead prompt the user to ask if the data should be deleted (so that the user does not lose any data he does not want to lose). In some embodiments, whether to prompt the user is view dependent. For example, if an enterprise view requires a certain level of security, the enterprise may not want to provide users with the option of retaining data if the device no longer meets security constraints. However, such a view may provide the user with the option of reverting the change that caused the removal from the view (eg, reverting the change with a shorter password).

21A and 21B show devices 1600 and 1650 from FIGS. 16 and 17 when their password is changed such that one of the devices is removed from the ring through four stages 2105-2120. . As shown in the first stage 2105, the second device 1650 includes not only the data item 1630 belonging to the view V3, but also synchronization data items 1615, 1620, and 1635 belonging to the view V1. Save it. In this stage, the user of device 1650 modifies his passcode from a 12-digit passcode ("012345678910") to a four-digit passcode "1234".

As a result, in the second stage 2110, the ring evaluator 2125 of the second device 1650 states that the device should no longer be a member of the ring (ring 3) because the passcode of the device is no longer long enough. Identify that. Accordingly, the second device 1650 transmits a message 2130 to the first device 1600 informing the first device that the second device is no longer a member of the ring 3. In some embodiments, as shown, the message indicates the reason for the change in ring state, but other embodiments simply send the notification without additional data.

In a third stage, both the first device 1600 and the second device 1650 process the removal of the second device from ring 3. The ring evaluator 2135 on the first device indicates the removal of the second device from this ring, and also notifies the view evaluator 1720 of a change in the ring state, so that the view evaluator is able to use the second device for future synchronization operations. It can be determined whether the view state has changed even a little. On the second device, the ring evaluator 2125 notifies the view evaluator 2140 of this same change, and the view evaluator as a result (i.e., because ring 3 membership is a requirement for view V1) the second device ( 1650) should no longer participate in view V1.

Accordingly, the view evaluator 2140 removes data items 1615, 1620, 1635 from the second device because they belong to the view V1 to which the device no longer participates. The fourth stage 2140 shows this result, in which case the second device 1650 stores only the item 1630 (which belongs to the view V3).

VI. Electronic system

Many of the above-described features and applications are implemented as software processes specified as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium). When these instructions are executed by one or more computation or processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they Let's do it. Examples of computer readable media include CD-ROMs, flash drives, random access memory (RAM) chips, hard drives, erasable programmable read-only memory (EPROM), electrically Including, but not limited to, electrically erasable programmable read-only memory (EEPROM), and the like. Computer-readable media do not include carrier waves and electronic signals that carry wirelessly or over wired connections.

In this specification, the term "software" is meant to include firmware located in read-only memory, or applications stored in magnetic storage, which can be read into memory processed by a processor. Further, in some embodiments, multiple software inventions may remain separate software inventions, implemented as sub-parts of a larger program. In some embodiments, multiple software inventions may also be implemented as separate programs. Finally, any combination of separate programs that together implement the software invention described herein is within the scope of the invention. In some embodiments, software programs define one or more specific machine implementations that, when installed to operate on one or more electronic systems, execute and perform operations of the software programs.

A. Mobile device

User data sharing in some embodiments occurs on mobile devices such as smartphones (eg, iPhones®) and tablets (eg, iPads®). 22 is an example of an architecture 2200 of such a mobile computing device. As shown, mobile computing device 2200 includes one or more processing units 2205, memory interface 2210, and peripherals interface 2215.

Peripheral interface 2215 includes various sensors, and camera subsystem 2220, wired communication subsystem(s) 2223, wireless communication subsystem(s) 2225, audio subsystem 2230, I/O It is coupled to subsystems including subsystem 2235 and the like. Peripheral interface 2215 enables communication between processing units 2205 and various peripherals. For example, orientation sensor 2245 (eg, gyroscope) and acceleration sensor 2250 (eg, accelerometer) are coupled to peripherals interface 2215 to enable orientation and acceleration functions.

The camera subsystem 2220 is coupled to one or more optical sensors 2240 (eg, a charged coupled device (CCD) optical sensor, a complementary metal-oxide-semiconductor (CMOS) optical sensor, etc.). Camera subsystem 2220 coupled with optical sensors 2240 enables camera functions such as image and/or video data capture. Wired communication subsystem 2223 and wireless communication subsystem 2225 serve to enable communication functions.

In some embodiments, the wireless communication subsystem 2225 includes radio frequency receivers and transmitters, and optical receivers and transmitters (not shown in FIG. 22). These receivers and transmitters of some embodiments are implemented to operate over one or more communication networks such as a GSM network, a Wi-Fi network, a Bluetooth network, and the like. The audio subsystem 2230 is coupled to a speaker and outputs audio (eg, outputs voice navigation commands). Further, the audio subsystem 2230 is coupled to the microphone to enable voice-enabled functions in some embodiments.

I/O subsystem 2235 entails transfer via peripheral interface 2215 between input/output peripheral devices such as displays, touch screens, etc. and the data bus of processing units 2205. The I/O subsystem 2235 includes a touch screen controller 2255 and other input controllers 2260 to enable transfer between input/output peripheral devices and the data bus of the processing units 2205. do. As shown, the touch screen controller 2255 is coupled to the touch screen 2265. The touch screen controller 2255 detects contact and movement on the touch screen 2265 using any of a number of touch sensitive technologies. Other input controllers 2260 are coupled to other input/control devices such as one or more buttons. Some embodiments include a near-touch sensitive screen and a corresponding controller capable of detecting near-touch interactions instead of or in addition to touch interactions.

Memory interface 2210 is coupled to memory 2270. In some embodiments, the memory 2270 is a volatile memory (e.g., fast random access memory), a nonvolatile memory (e.g., flash memory), a combination of volatile and nonvolatile memory, and/or any other type of memory. Includes. 22, the memory 2270 stores an operating system (OS) 2271. The OS 2271 includes instructions for handling basic system services and performing hardware dependent tasks.

The memory 2270 also includes communication instructions that enable communication with one or more additional devices (e.g., for peer-to-peer data sharing, or to access a server over the Internet for cloud-based data sharing). (2274); Graphical user interface instructions 2276 to enable graphical user interface processing; Image processing instructions 2278 to enable image related processing and functions; Input processing instructions 2280 that enable input related (eg, touch input) processes and functions; Audio processing instructions 2282 to enable audio related processes and functions; And camera instructions 2284 that enable camera related processes and functions. The instructions described above are exemplary only, and memory 2270 includes additional and/or other instructions in some embodiments. For example, a memory for a smartphone may contain phone instructions that enable phone related processes and functions. The above-described instructions need not be implemented as separate software programs or modules. The various functions of the mobile computing device may be implemented in hardware and/or software, including one or more signal processing and/or application specific semiconductors.

Although the components shown in FIG. 22 are shown as separate components, one of ordinary skill in the art will recognize that two or more components may be incorporated into one or more integrated circuits. Further, two or more components may be coupled together by one or more communication buses or signal lines. Further, although many functions have been described as being performed by one component, those skilled in the art will recognize that the functions described in connection with FIG. 22 may be divided into two or more integrated circuits.

B. Computer system

23 conceptually shows another example of an electronic system 2300 implementing some embodiments of the present invention. The electronic system 2300 may be a computer (eg, a desktop computer, a personal computer, a tablet computer, etc.), a telephone, a PDA, or any other kind of electronic or computing device. Such electronic systems include interfaces for various types of computer readable media and various other types of computer readable media. Electronic system 2300 includes bus 2305, processing unit(s) 2310, graphics processing unit (GPU) 2315, system memory 2320, network 2325, read-only memory 2330, and permanent storage. Device 2335, input devices 2340, and output devices 2345.

Bus 2305 collectively represents all system, peripheral, and chipset busses that communicatively connect the multiple internal devices of electronic system 2300. For example, bus 2305 communicatively connects read-only memory 2330, GPU 2315, system memory 2320, and persistent storage device 2335 with processing unit(s) 2310. .

From these various memory units, processing unit(s) 2310 retrieves instructions to be executed and data to be processed to execute the processes of the present invention. The processing unit(s) may be a single processor or a multi-core processor in different embodiments. Some instructions are passed to the GPU 2315 and executed by the GPU. The GPU 2315 may eliminate various calculations or supplement the image processing provided by the processing unit(s) 2310. In some embodiments, such functionality may be provided using the kernel shading language of CoreImage.

Read-only memory (ROM) 2330 stores static data and instructions required by the processing unit(s) 2310 and other modules of the electronic system. On the other hand, the persistent storage device 2335 is a read and write memory device. Such a device is a nonvolatile memory unit that stores instructions and data even when the electronic system 2300 is turned off. Some embodiments of the present invention use a mass storage device (such as a magnetic or optical disk and its corresponding disk drive, integrated flash memory) as the persistent storage device 2335.

Other embodiments use a removable storage device (such as a floppy disk, flash memory device, etc. and its corresponding drive) as a permanent storage device. Like persistent storage device 2335, system memory 2320 is a read and write memory device. However, unlike storage device 2335, system memory 2320 is a volatile read and write memory, such as random access memory. The system memory 2320 stores some of the instructions and data required by the processor at runtime. In some embodiments, the inventive processes are stored in system memory 2320, persistent storage device 2335, and/or read only memory 2330. For example, various memory units include instructions for processing multimedia clips in accordance with some embodiments. From these various memory units, processing unit(s) 2310 retrieves instructions to execute and data to process to execute the processes of some embodiments.

Bus 2305 also connects to input and output devices 2340 and 2345. Input devices 2340 may allow a user to transmit information to the electronic system and select commands for the electronic system. Input devices 2340 include letter and numeric keyboards and pointing devices (also referred to as “cursor control devices”), cameras (eg, webcams), microphones or similar devices that receive voice commands. And the like. Output devices 2345 display images generated by the electronic system or otherwise output data. Output devices 2345 include printers and display devices, such as a cathode ray tube (CRT) or liquid crystal display (LCD), as well as speakers or similar audio output devices. Some embodiments include devices such as touch screens that function as both an input device and an output device.

Finally, as shown in FIG. 23, bus 2305 also couples electronic system 2300 to network 2325 via a network adapter (not shown). In this way, the computer may be part of a network of computers (eg, a local area network (“LAN”), a wide area network (“WAN”), or an intranet), or a network of networks, eg the Internet. Any or all components of electronic system 2300 may be used with the present invention.

Some embodiments rely on electronic components, such as microprocessors, machine-readable or computer-readable media (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). It includes a storage and memory storing computer program instructions. Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROMs), recordable compact discs (CD-Rs), rewritable compact discs (CD-RWs), read-only DVDs ( digital versatile discs) (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g. , SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and writeable Blu-Ray® discs, ultra-high density optical discs , Any other optical or magnetic media, and floppy disks. Computer-readable media may store a computer program executable by at least one processing unit and including sets of instructions for performing various operations. Examples of computer programs or computer code are made by files containing machine code and containing higher-level code executed by a computer, electronic component, or microprocessor using, for example, a compiler, and an interpreter.

Although the above discussion mainly refers to microprocessors or multi-core processors executing software, some embodiments are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). do. In some embodiments, such integrated circuits execute instructions stored on the circuit itself. Furthermore, some embodiments execute software stored in programmable logic devices (PLDs), ROM, or RAM devices.

As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technical devices. These terms exclude people or groups of people. For the purposes of this specification, the terms “display” or “displaying” mean displaying on an electronic device. As used in this specification and any claims of this application, the terms "computer-readable medium", "computer-readable medium", and "machine-readable medium" refer to information in computer-readable form. It is entirely limited to the tangible physical objects it stores. These terms exclude any wireless signals, wired download signals, and any other temporary signals.

While the invention has been described with reference to a number of specific details, those skilled in the art will recognize that the invention may be embodied in other specific forms without departing from the spirit of the invention. For example, a number of drawings (including FIGS. 11, 12, 15, and 20) conceptually illustrate processes. Certain operations of these processes may not be performed in the exact order shown and described. Certain operations may not be performed in one successive series of operations, and different specific operations may be performed in different embodiments. Moreover, a process can be implemented using several sub-processes, or as part of a larger macro process. Accordingly, one of ordinary skill in the art will understand that the invention is not limited by the above exemplary details, but rather is defined by the appended claims.

Claims (1)

Method or apparatus according to the specification and drawings.

Images