Cloud storage
24 claims: 20 independent, 4 dependent
- 1ユーザアカウントに関連付けられた第1のコンピューティングデバイスにおいて、前記第1のコンピューティングデバイス上で動作しているアプリケーションから実行中のクエリを受信するステップと、 前記実行中のクエリを満たすデータ項目がリモートストレージロケーションで利用可能であることの通知を受信するステップであって、前記実行中のクエリを満たす前記データ項目は、前記ユーザアカウントに関連付けられた第2のコンピューティングデバイスによって提供されたものである、ステップと、 前記通知に基づき、1つ以上のアプリケーション別アクセスポリシーにより前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第1データ項目へのアクセスの許可を有することを判定するステップと、 前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第2データ項目へのアクセスの許可を有さないことを判定するステップと、 前記アプリケーションに対して前記実行中のクエリを満たす前記第1データ項目を提示するステップと、 前記アプリケーションに対する前記第2データ項目の提示を控えるステップと、を含 み、 前記実行中のクエリは、前記アプリケーションが終了又は削除されるまでアクティブのままである ことを特徴とする方法。
- 2前記リモートストレージロケーションに、前記第1データ項目を受信する要求を送信するステップと、 前記リモートストレージロケーションから前記第1データ項目を受信するステップと、を含むことを特徴とする請求項1に記載の方法。
- 3ユーザアカウントに関連付けられた第1のコンピューティングデバイスにおいて、前記第1のコンピューティングデバイス上で動作しているアプリケーションから実行中のクエリを受信するステップと、 前記実行中のクエリを満たすデータ項目がリモートストレージロケーションで利用可能であることの通知を受信するステップであって、前記実行中のクエリを満たす前記データ項目は、前記ユーザアカウントに関連付けられた第2のコンピューティングデバイスによって提供されたものである、ステップと、 前記通知に基づき、1つ以上のアプリケーション別アクセスポリシーにより前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第1データ項目へのアクセスの許可を有することを判定するステップと、 前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第2データ項目へのアクセスの許可を有さないことを判定するステップと、 前記アプリケーションに対して前記実行中のクエリを満たす前記第1データ項目を提示するステップと、 前記アプリケーションに対する前記第2データ項目の提示を控えるステップと、 を含み、 前記アプリケーションが前記第1データ項目へのアクセスの許可を有することを判定するステップは、前記第1データ項目に関連付けられた識別子が前記アプリケーションに関連付けられた識別子と適合するかを判定するステップを含 み、 前記アプリケーションに関連付けられた前記識別子は、当該識別子に関連付けられたデータ項目への共有アクセスを有するアプリケーションのファミリーを識別する ことを特徴とす る方 法。
- 4前記実行中のクエリを満たす前記データ項目がリモートストレージロケーションで利用可能であることの前記通知は、 前記アプリケーションに関連付けられた前記識別子が適合する 前記第1データ項目に関連付けられた前記識別子 を 示すデータを含むことを特徴とする請求項 3 に記載の方法。
- 5前記受信した通知のデータに基づき、前記データ項目が前記実行中のクエリを満たすことを判定するステップを含むことを特徴とする請求項1に記載の方法。
- 6前記通知を前記ユーザアカウントに関連付けられた別のコンピューティングデバイスから受信することを特徴とする請求項1に記載の方法。
- 7ユーザアカウントに関連付けられた第1のコンピューティングデバイスと、サーバシステムと、を備えているシステムであって、 前記第1のコンピューティングデバイスは、 前記第1のコンピューティングデバイス上で動作しているアプリケーションから実行中のクエリを受信し、 前記実行中のクエリを満たすデータ項目であって、前記ユーザアカウントに関連付けられた第2のコンピューティングデバイスによって提供されたものである前記データ項目が、リモートストレージロケーションで利用可能であることの通知を受信し、 前記通知に基づき、1つ以上のアプリケーション別アクセスポリシーにより前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第1データ項目へのアクセスの許可を有することを判定し、 前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第2データ項目へのアクセスの許可を有さないことを判定し、 前記アプリケーションに対して前記実行中のクエリを満たす前記第1データ項目を提示し、 前記アプリケーションに対する前記第2データ項目の提示を控える様に構成され、 前記サーバシステムは、 前記第1のコンピューティングデバイスから、前記第1のコンピューティングデバイス上で動作している前記アプリケーションに関連付けられたデータ項目を受信し、 前記データ項目を格納し、 前記ユーザアカウントに関連付けられた1つ以上の別のデバイスに前記データ項目の通知を送信する様に構成され、 前記通知は、前記データ項目に関連付けられた前記アプリケーションの識別子を含 み、 前記実行中のクエリは、前記アプリケーションが終了又は削除されるまでアクティブのままである ことを特徴とするシステム。
- 8前記第1のコンピューティングデバイスは、 前記リモートストレージロケーションに、前記第1データ項目を受信する要求を送信し、 前記リモートストレージロケーションから前記第1データ項目を受信する様にさらに構成されていることを特徴とする請求項 7 に記載のシステム。
- 9ユーザアカウントに関連付けられた第1のコンピューティングデバイスと、サーバシステムと、を備えているシステムであって、 前記第1のコンピューティングデバイスは、 前記第1のコンピューティングデバイス上で動作しているアプリケーションから実行中のクエリを受信し、 前記実行中のクエリを満たすデータ項目であって、前記ユーザアカウントに関連付けられた第2のコンピューティングデバイスによって提供されたものである前記データ項目が、リモートストレージロケーションで利用可能であることの通知を受信し、 前記通知に基づき、1つ以上のアプリケーション別アクセスポリシーにより前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第1データ項目へのアクセスの許可を有することを判定し、 前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第2データ項目へのアクセスの許可を有さないことを判定し、 前記アプリケーションに対して前記実行中のクエリを満たす前記第1データ項目を提示し、 前記アプリケーションに対する前記第2データ項目の提示を控える様に構成され、 前記サーバシステムは、 前記第1のコンピューティングデバイスから、前記第1のコンピューティングデバイス上で動作している前記アプリケーションに関連付けられたデータ項目を受信し、 前記データ項目を格納し、 前記ユーザアカウントに関連付けられた1つ以上の別のデバイスに前記データ項目の通知を送信する様に構成され、 前記通知は、前記データ項目に関連付けられた前記アプリケーションの識別子を含み、 前記アプリケーションが前記第1データ項目へのアクセスの許可を有することを判定することは、前記第1データ項目に関連付けられた識別子が前記アプリケーションに関連付けられた識別子と適合するかを判定することを含 み、 前記アプリケーションに関連付けられた前記識別子は、当該識別子に関連付けられたデータ項目への共有アクセスを有するアプリケーションのファミリーを識別する ことを特徴とす るシ ステム。
- 10前記実行中のクエリを満たす前記データ項目がリモートストレージロケーションで利用可能であることの前記通知は、 前記アプリケーションに関連付けられた前記識別子に適合する 前記第1データ項目に関連付けられた前記識別 子を 示すデータを含むことを特徴とする請求項 9 に記載のシステム。
- 11前記受信した通知のデータに基づき、前記データ項目が前記実行中のクエリを満たすことを判定することを含むことを特徴とする請求項 7 に記載のシステム。
- 12前記通知を前記ユーザアカウントに関連付けられた別のコンピューティングデバイスから受信することを特徴とする請求項 7 に記載のシステム。
- 13前記第1のコンピューティングデバイスからデータベースのトランザクションログファイルを受信し、複数の関連するコンピューティングデバイスのそれぞれに前記トランザクションログファイルを通知する様に構成されたサーバシステムを含み、 前記データベースのトランザクションログファイルは、データベースになされた個別の変更を識別し、前記データベースの代わりに受信され、 前記関連するコンピューティングデバイスは、第1のコンピューティングデバイスに関連付けられた前記ユーザアカウントに関連付けられていることを特徴とする請求項 7 に記載のシステム。
- 14前記サーバシステムは、前記複数の関連するコンピューティングデバイスの1つのデバイスからの要求に応答して、前記トランザクションログファイルの1つ以上を提供する様に構成されていることを特徴とする請求項 13 に記載のシステム。
- 15前記第1のコンピューティングデバイスから、データベースになされた個別の変更を識別する第1のトランザクションログを受信し、 第2のコンピューティングデバイスから、前記データベースになされた個別の変更を識別する第2のトランザクションログを受信し、 前記第1のトランザクションログと前記第2のトランザクションログとの間の競合が存在するかを判定し、 前記トランザクションログの2つ以上のトランザクションをマージできるかを判定し、 前記2つ以上のトランザクションをマージできる場合、前記データベースにマージしたトランザクションを適用する様に構成されたサーバシステムを備えていることを特徴とする請求項 7 に記載のシステム。
- 16前記2つ以上のトランザクションをマージできない場合、前記サーバシステムは、競合において優先するトランザクションを判定し、前記判定したトランザクションを前記データベースに適用する様に構成されていることを特徴とする請求項 15 に記載のシステム。
- 17前記2つ以上のトランザクションのマージは、共通する祖先データベースを判定し、前記共通する祖先データベースと、前記第1のトランザクションログと、前記第2のトランザクションログとの間の3ウェイマージを実行することを含むことを特徴とする請求項 15 に記載のシステム。
- 18前記競合は、ユーザの介入なしに解決されることを特徴とする請求項 15 に記載のシステム。
- 19コンピュータ可読記憶媒体に保存され、第1のコンピューティングデバイスで実行されると、前記第1のコンピューティングデバイスに、 前記第1のコンピューティングデバイス上で動作しているアプリケーションから実行中のクエリを受信し、 前記実行中のクエリを満たすデータ項目であって 、ユ ーザアカウントに関連付けられた第2のコンピューティングデバイスによって提供されたものである前記データ項目が、リモートストレージロケーションで利用可能であることの通知を受信し、 前記通知に基づき、1つ以上のアプリケーション別アクセスポリシーにより前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第1データ項目へのアクセスの許可を有することを判定し、 前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第2データ項目へのアクセスの許可を有さないことを判定し、 前記アプリケーションに対して前記実行中のクエリを満たす前記第1データ項目を提示し、 前記アプリケーションに対する前記第2データ項目の提示を控える、ことを含む動作を実行させる命令を含 み、 前記実行中のクエリは、前記アプリケーションが終了又は削除されるまでアクティブのままである ことを特徴とするコンピュータプログラム。
- 20前記動作は、 前記リモートストレージロケーションに、前記第1データ項目を受信する要求を送信することと、 前記リモートストレージロケーションから前記第1データ項目を受信することを含むことを特徴とする請求項 19 に記載のコンピュータプログラム。
- 21コンピュータ可読記憶媒体に保存され、第1のコンピューティングデバイスで実行されると、前記第1のコンピューティングデバイスに、 前記第1のコンピューティングデバイス上で動作しているアプリケーションから実行中のクエリを受信し、 前記実行中のクエリを満たすデータ項目であって、ユーザアカウントに関連付けられた第2のコンピューティングデバイスによって提供されたものである前記データ項目が、リモートストレージロケーションで利用可能であることの通知を受信し、 前記通知に基づき、1つ以上のアプリケーション別アクセスポリシーにより前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第1データ項目へのアクセスの許可を有することを判定し、 前記アプリケーションが前記実行中のクエリを満たす前記データ項目の第2データ項目へのアクセスの許可を有さないことを判定し、 前記アプリケーションに対して前記実行中のクエリを満たす前記第1データ項目を提示し、 前記アプリケーションに対する前記第2データ項目の提示を控える、 ことを含む動作を実行させる命令を含み、 前記アプリケーションが前記第1データ項目へのアクセスの許可を有することを判定することは、前記第1データ項目に関連付けられた識別子が前記アプリケーションに関連付けられた識別子と適合するかを判定することを含み、 前記アプリケーションに関連付けられた前記識別子は、当該識別子に関連付けられたデータ項目への共有アクセスを有するアプリケーションのファミリーを識別する ことを特徴とす るコ ンピュータプログラム。
- 22前記実行中のクエリを満たす前記データ項目がリモートストレージロケーションで利用可能であることの前記通知は、 前記アプリケーションに関連付けられた前記識別子に適合する 前記第1データ項目に関連付けられた前記識別 子を 示すデータを含むことを特徴とする請求項 21 に記載のコンピュータプログラム。
- 23前記受信した通知のデータに基づき、前記データ項目が前記実行中のクエリを満たすことを判定することを含むことを特徴とする請求項 19 に記載のコンピュータプログラム。
- 24前記データ項目を決定することは、前記ユーザアカウントに関連付けられた別のコンピューティングデバイスからのデータ項目の通知を受信したことの応答であることを特徴とする請求項19に記載のコンピュータプログラム。
Independent claims24
89 paragraphs, as filed
The present invention relates to data storage.
The user can store data in a remote location, for example, a network storage location. Users can also transfer data between devices. Users generally share data with other users by transferring or sharing files. For example, a user can identify a particular file to send to another user, such as by using an email or file transfer protocol. File sharing allows, for example, other users on the network to access the file, but generally the file remains in its original location. Alternatively, other users can see the file from its original storage location, but in general, only the user who sees the file can modify the file.
<p num="0003"> The present invention describes techniques related to data storage and synchronization.</p>
<p num="0004"> In general, one aspect of the subject matter described in the present invention is one of a plurality of data items that identify an running query from an application and allow the application to view according to one or more application-specific access policies. It can be performed in a method that includes an action of determining one or more data items and an action of presenting one or more data items to an application but not presenting another data item among a plurality of data items. ..</p><p num="0005"> Other embodiments of this embodiment include a corresponding system, each of which is configured to perform the operation of the method, a device, and a computer program recorded on a computer storage device.</p><p num="0006"> Each of these and other embodiments may optionally include one or more of the following features: Determining one or more data items involves determining whether the identifier associated with each of the plurality of data items matches the identifier associated with the application. The identifier associated with the application uniquely identifies the application. The identifier associated with the application identifies a family of applications that have shared access to the associated data item. Determining a data item is in response to receiving a data item notification from another device.</p><p num="0007"> In general, one aspect of the subject matter described in the present invention is a synchronization manager configured to upload data items to remote storage and receive data items uploaded to data storage by other devices with multiple applications. And one or more configured to provide an access manager configured to determine permission to view available data items for each of multiple applications according to one or more application-specific access policies. It can be carried out in a device equipped with a computing device.</p><p num="0008"> In general, one aspect of the subject described in the present invention is the action of receiving a data item from a device, the action of determining a container for storing a user account and application-specific data item associated with the data item, and data. It can be performed in a manner that includes storing the item in a container and sending a notification of the data item to one or more other devices associated with the user account. Other embodiments of this embodiment include a corresponding system, each of which is configured to perform the operation of the method, a device, and a computer program recorded on a computer storage device.</p><p num="0009"> In general, one aspect of the subject matter described in the present invention is one or more database transaction log files, each identifying individual changes made to the database and received on behalf of the database. It can be performed in a manner that includes an action of receiving from a device and an action of notifying each of a plurality of related devices of a transaction log file. Other embodiments of this embodiment include a corresponding system, each of which is configured to perform the operation of the method, a device, and a computer program recorded on a computer storage device.</p><p num="0010"> Each of these and other embodiments may optionally include one or more of the following features: The method further comprises storing a transaction log file. The method further comprises providing one or more transaction log files in response to a request from one of a plurality of devices.</p><p num="0011"> In general, one aspect of the subject matter described in the present invention is the operation of receiving multiple transaction logs, each identifying an individual change made to a database, and two or more of the transaction logs. The behavior of determining if there is a conflict between the transaction logs, the behavior of determining whether two or more of the conflicting transaction logs can be merged, and the behavior of merging two or more transactions if they can be merged. It can be performed in a way that includes applying the transaction to the database and determining the winning transaction when two or more transactions cannot be merged and applying the transaction to the database. Other embodiments of this embodiment include a corresponding system, each of which is configured to perform the operation of the method, a device, and a computer program recorded on a computer storage device.</p><p num="0012"> Each of these and other embodiments may optionally include one or more of the following features: Merging transactions involves determining a database of common ancestors and performing a three-way merge. Conflicts are resolved without user interaction.</p><p num="0013"> Specific embodiments of the subject matter described in the present invention are feasible to achieve one or more of the following advantages: Data can be stored securely according to application-based policies. The application can only view and read data items from authorized cloud storage. Access control can be performed on each client device using application-based policies.</p><p num="0014"> The database can be synchronized between devices using the transaction log without atomically synchronizing the database as a whole. Conflicts between individual database transactions can be resolved on each client device using competing transactions and a database of common ancestors. Policies published by the system or application can automatically resolve conflicts between records in a file without user interaction. Client devices can reconfigure the database from scratch using synchronized data to bring new peer devices online or to solve problems with local files.</p><p num="0015"> In the accompanying drawings and description below, details of one or more embodiments of the subject matter described in the present invention will be described. Other features, aspects and advantages of the subject matter will become apparent from the description, drawings and claims.</p>
<figref num="1">The figure which shows an example of the system which stores a data item safely.</figref><figref num="2">The figure which shows an example of the system which synchronizes data items.</figref><figref num="3">A flowchart showing an example of a method for safely storing and synchronizing data items.</figref><figref num="4">A flowchart showing an example of how to upload and read application data items.</figref><figref num="5">The figure which shows an example of the system which stores a database transaction.</figref><figref num="6">A flowchart showing an example of how to synchronize a database.</figref><figref num="7">A flowchart showing an example of how to synchronize a database.</figref><figref num="8">A flowchart showing an example of how to manage conflicts.</figref><figref num="9">The figure which shows an example of a system architecture.</figref>
The same reference numerals and names in the various drawings indicate similar elements.
Describe application-centric secure storage technology. Data items such as files associated with a particular application can be stored in one or more remote locations such as cloud storage and synchronized with other devices. Each application can only view data items stored in remote locations with permission. The access manager on each client device enforces application-specific access policies. Remote storage can be secured for each user or application associated with a user account, for example using an isolated container.
When an application saves a data item, the data item can be synchronized to a remote storage location. The remote storage location notifies the other device associated with the user of the data item. The access manager on individual devices determines whether a particular application is notified of data items based on the access policy for the application and any particular query received from those applications. When the application is notified and the application requests to read the data item, the data item is read from the remote storage.
Database synchronization techniques are also described. The database can be synchronized between client devices without automatically moving the entire database to a remote storage location or between peer devices. The transaction log file identifies changes to the database for a particular baseline state. The transaction log file is synchronized so that the database is synchronized when the transaction identified in the transaction log file is applied to the local database. When conflicts are detected between transaction log files, a decision is made as to whether the transactions can be merged and applied to the database. If the transactions cannot be merged, the winner of the conflict is determined according to a particular conflict resolution policy.
FIG. 1 is a diagram showing an example of a system 100 for safely storing data items. System 100 includes a first device 102, a second device 104, a third device 106, and a remote storage location 108.
The first device 102, the second device 104, the third device 106, and the remote storage location 108 are communicably coupled together using one or more networks 110. The one or more networks 110 can include both wired and wireless networks. For example, network 110 may be part of a local area network, wide area network or the Internet.
The first device 102, the second device 104, and the third device 106 include a desktop computing device or laptop computing device, a mobile device, a tablet device, a personal data assistant, or another computing device. Can be done. In particular, as shown in FIG. 1, each of the devices 102 and 104 is associated with a first user or user account 112. Similarly, the third device 106 and one or more other devices (not shown) are associated with the second user or user account 114. The remote storage location 108 may be further coupled to one or more different users or many other devices (not shown) associated with different user accounts.
The remote storage location 108 may be a single storage location or a plurality of storage locations. For example, as part of a cloud storage system that indicates a server, a network addressed storage location, a collection of computing devices, or virtualized network storage.
Remote storage location 108 includes a separate logical container that stores data from different user / user account and application combinations. In some examples, a logical container can be a directory or data structure in a file system, or another type of data organizational unit. For example, the first user / user account 112 can have a container 116 on the remote storage location 108, with one container for each user or individual application associated with the user account. Similarly, the second user / user account 114 can have a container 118 for each application. Application data items received from individual devices (eg, first device 102) are stored in their respective containers for that application. Remote storage location 108 can include a storage manager that creates and manages containers and generates notifications for devices associated with users.
The first device 102 includes one or more applications 120, a synchronization manager 122, and an access manager 124. The one or more applications 120 can include various applications such as production applications, system applications, games and the like. Each application can be associated with a unique key or other identifier that can be used to identify the application and the particular permissions of that application. In some implementations, one or more applications 120 are sandboxed so that they are isolated from each other application.
As described in more detail below, synchronization manager 122 manages sending data items to remote storage location 108 and receiving information (eg, data items or notifications) from remote storage location 108. To do. Access Manager 124 presents data items available for a particular application in application 120 in response to queries from each application. Access Manager 124 applies one or more access policies to determine which data items are visible to a particular application in application 120.
Similarly, the second device 104 includes one or more applications 126, a synchronization manager 128, and an access manager 130. Application 120 and application 126 can include one or more of the same applications. Similarly, the third device 106 includes one or more applications 132, a synchronization manager 134, and an access manager 136. However, the third device 106 is associated with the second user or user account 114.
FIG. 2 is a diagram showing an example of a system 200 that synchronizes data items between devices. System 200 includes a first device 202, a second device 204, and cloud storage 206.
The first device 202 includes application 208, synchronization manager 210, and access manager 212. Similarly, the second device 204 includes application 214, synchronization manager 216, and access manager 218. Each synchronization manager, access manager and application may be similar to those described above for FIG.
When a data item is stored by an application in application 208 (eg, by creating a new file or updating an existing file), the synchronization manager 210 detects the data item (eg, in the event notification provided by the device kernel). (Although there is), send the data item to the cloud storage 206. The cloud storage 206 stores data items in the corresponding application container in the cloud storage 206. The cloud storage 206 further notifies the second device 204 of the data item. The synchronization manager 216 on the second device receives the notification. The synchronization manager 216 notifies the access manager 218, which controls which application can see the data item, of the received notification.
Access Manager 218 determines which applications have permission to read data items according to one or more access policies. The notification of the data item can include an identifier indicating one or more applications associated with the data item (eg, the notification can include the corresponding application key of the application that generated the data item).
Access Manager 218 further determines if there is a query from the application requesting that the new data item be recognized. For example, the corresponding application can initiate a running query on a new data item associated with the application (for example, after it is installed on a second device 204). If there is a query for a data item, Access Manager 218 notifies the corresponding application 214 of the data item. A particular application 214 can browse one or more available data items and request data items as needed. In particular, the data item does not need to be read from the cloud storage 206 to be presented to the application. When the application requests read access, the data item can be retrieved or read remotely. The location of the data item does not have to be visible to the application (for example, the data item may appear to be located locally when placed in cloud storage).
FIG. 3 is a flowchart showing an example of a method 300 for safely storing and synchronizing data items. Method 300 is feasible with one or more computing devices, such as the device of FIG. 1 and a remote storage location.
The application data item is received for storage and / or synchronization (step 302). Application data items may be received in response to the data items being stored locally on a particular device. For example, a given application can store a file in a storage device on the device. Data items can be stored in response to user actions (eg, user modifications to application data). Data items can be saved as new files or modified versions of previously stored data items. For example, a user of a word processing application can create a new file or modify an existing file. In some implementations, the synchronization manager (eg, synchronization manager 122) identifies new or modified data items that are stored. For example, a synchronization manager can monitor file system events to identify data items. In some other implementations, individual applications notify the synchronization manager. The synchronization manager can send data items to a remote storage location (eg, remote storage location 108).
Receiving a data item can include receiving data and additional information about the data item or metadata about the data item. Additional information can include information that identifies the application associated with the data item (eg, the application that generated the data item). In some other implementations, the additional information identifies the application that has permission to access the data item. Identification can include a unique key that identifies a particular application or group of related applications. For example, a particular application developer can generate a number of related applications (a set of applications by a developer or company) that can share data items.
The data item is stored in a secure application container (step 304). For example, a remote storage location such as cloud storage can include a container independent for each application associated with a given user or user account. Therefore, data items for each application and user can be stored separately on the remote storage location. Also, in some implementations, each container is secure and / or encrypted.
The peer device is notified (step 306). Notify the associated device of the new data item in order to synchronize the data item between the user or peer devices such as a number of devices associated with the user account. Devices are associated, for example, through a registration process by a user who links the device to a peer. Notifications are sent so that the actual data item does not have to be sent to individual peer devices until requested. However, in some other implementations, the data item itself can be sent to the peer device instead of the notification.
Once notified, a particular peer device can process the notification. Processing can include determining whether the data item was previously identified (eg, as part of a preceding notification of a previous data item stored at a remote location). Processing can also determine one or more applications associated with a data item using, for example, information or metadata about the data item contained in the notification (eg, including a key that identifies the application). Can include. Each peer device can notify the associated application of a data item.
The data item is provided to the device in response to the request (step 308). For example, a particular application on the device can immediately request read access. Alternatively, the application can store the availability of the data item while leaving it on the remote storage location. The data item can be read as needed, for example in response to a request to open the data item. For example, a user can request to open a particular data item within an application. The application then requests the data item from the access manager requesting the data item from the remote storage location.
FIG. 4 is a flowchart showing an example of a method 400 for uploading and reading application data items. Method 400 can be performed by one or more computing devices, such as the first device 102 in FIG.
The query is received from the application (step 402). For example, you can receive a query when the application is first installed or configured. Alternatively, you can receive queries when you configure your application for synchronization with other devices. The query can be a running query that remains in a wait state and may respond during the life of the application on the device (eg, until the application is disabled or deleted).
Access to the data item associated with the application is checked (step 404). A unique identifier (eg, a particular application key) can be used to determine which data item or type of data item the application has access to. For example, an application can provide a key that can be matched to a particular application access policy.
Notifications for new data items, including data items associated with the application, are received (step 406). The particular peer device notifies the application of the data item (step 310). In particular, the access manager (eg, access manager 124) can determine one or more applications that have permission to access the data item. Permission to access a data item can be determined according to one or more access policies. Access policies can identify permissions for a particular application based on the application's key or other unique identifier. The identifier can be checked before installing the application. The information associated with the data item can be compared to the permissions specified by the access policy to determine which application has permission to access the data item. In some implementations, only a single application has permission to access the application's data items. In some other implementations, some data items can be shared between specific specified applications.
In some implementations, even if the application has permission to access the data item, no notification will be sent unless there is an application query. For example, an application query can request some new data item. In some implementations, the query is a running query that was initiated when the application was first installed on the device or first synchronized with another device.
The application is only notified of the data items associated with the application (step 408). By notifying the application, the user can only view the data items to which the application has access. Thus, for example, if other data items associated with another application have been received, the application will not be able to view these data items without the necessary permission.
A read request is received and the corresponding data is presented (step 410). The application can request read access immediately. Alternatively, the application can store the availability of the data item while leaving the data item on the remote storage location. The data item can be read as needed, for example in response to a request to open the data item. For example, a user can request to open a particular data item within an application. The application then requests the data item from the access manager requesting the data item from the remote storage location.
FIG. 5 is a diagram showing an example of a system 500 that stores database transactions.
System 500 includes a first device 502 and a second device 504. The first device 502 and the second device 504 are associated with the first user 506. The first device 502 and the second device 504 are connected to the remote storage location 508 via network 510.
The first device 502 and the second device 504 can include desktop or laptop computing devices, mobile devices, tablet devices, personal data assistants, or other computing devices.
For example, network 510 may be part of a local area network, wide area network or the Internet.
The first device 502 includes a database 512, an event monitor 514, and a transaction cache 516. Similarly, the second device 504 includes a database 518, an event monitor 520, and a transaction cache 522.
If the user makes changes to database 512, the changes can be detected by event monitor 514. For example, a user can modify a database cell that corresponds to a particular row and column. Changes can be written to transaction cache 516 as individual transaction logs. The transaction log may be sent to remote storage location 508 periodically or on each receipt as part of a bundle of one or more transaction files sent periodically according to a particular criterion. Similarly, changes to database 518 can be detected by event monitor 520 and written to the transaction log stored in transaction cache 522. The transaction log may be sent to remote storage location 508.
The remote storage location 508 includes independent storage for per-user database information for a large number of users, including the first user 506. In particular, FIG. 5 shows the transaction log 524 for the first user and the transaction log 526 for the second user. The remote storage location 508 can securely store transaction logs for each user.
Also, in some implementations, while database 512 and database 518 are stored locally on first device 102 and second device 104, respectively, the corresponding database is not stored at remote storage location 508. Alternatively, the transaction logs provided to remote storage location 508 can be synchronized on each of the first device 502 and the second device 504. Thus, for example, changes to cells in a large database can be efficiently synchronized between the device and the remote storage location without sending out the entire large database.
Within a particular device, transaction logs can be applied to locally stored databases to synchronize the databases between users. For example, the transaction log from the first device 502 can be synchronized with the second device 504. The transaction log received on the second device 504 can be applied to database 518 to synchronize database 518 with database 512 without transferring each database as a whole.
FIG. 6 is a flowchart showing an example of the method 600 for synchronizing the databases. Method 600 can be performed by one or more computing devices, such as the first device 502 in FIG.
Each database transaction is stored in a transaction log file (step 602). The transaction log file encapsulates the state of the database for a particular transaction so that the transaction can be canceled or repeated. Transaction log files provide a single separate container for a particular database transaction. Transactions can include editing, adding, or deleting rows or columns as a whole, in addition to individual database cells. Transactions can be isolated and affect a single cell, or can be tied to other cells related to the contents of the edited cell.
The transaction log file further provides a chronological history of transactions that occur to the database. In some implementations, each transaction log can include a time stamp indicating when a transaction occurred. In some other implementations, the transaction log file contains a change vector. Due to the change vector, the device reading the transaction log file is first applied at the time the log was generated, which other transaction the device that generated the transaction log has seen before (eg, on the device or by a previous synchronization). Can be determined. By using the timeline and the transaction log data itself, a transaction can be recreated on another database that has a common state in the database in which the transaction occurred.
One or more transaction log files are pushed to a remote storage location (step 604). Transaction log files can be sent individually when stored by the database according to specific criteria or when sent periodically in batches. For example, individual transaction log files can be stored in a transaction cache (eg, transaction cache 516). Criteria can include the number or time of individual transaction log files. For example, the criteria can set a threshold for the number of transaction log files in the cache to trigger uploads to remote storage locations. Similarly, criteria can specify the time period or time range for uploading transaction log files (eg, hourly or nightly). If the criteria are met, the transaction log file in the cache can be sent to a remote storage location. Criteria can be combined, for example, a time limit can trigger the sending of transaction log files even if the specified number of transaction log files are not yet cached.
Notification of the transaction log file provided to the remote storage location by another device is received (step 606). In particular, the device (eg, first device 502) is notified of transaction log files that have been uploaded to a remote storage location by another device (eg, second device 504). For example, the device can receive a list of transaction log files. This list can identify all transaction log files received, or all transaction log files from a particular point in time, such as from the last notification or the state of a common database. The list can include transaction log files uploaded by the device. In some implementations, notifications for a particular transaction log file are not received in chronological order. Therefore, the device can wait until all transaction log files have been identified.
The change vector can be used to determine if there are any lost transactions. The change vector can include an identifier for each transaction known to the device. In particular, each transaction can have an identifier that identifies the transaction and the device that created the particular transaction. The change vector encapsulates the transaction that the authoring peer device is looking at from other devices. Logs from other devices have been imported by authoring peer devices. For example, in the case of peer devices A, B and C, each peer device can maintain its own counter (eg transaction # 1, transaction # 2, etc.). Since it is difficult to establish a global order, the order is instead determined by the transaction that some peer was looking at at the time it created the new log. For example, peer device C may use the change vector of (transaction # 42 of peer device C, transaction # 12 of peer device A, transaction # 101 of peer device B). Timestamps may be included, for example, if further processing is required to break the bond or ensure that the change vector entries are consistent.
The transaction identified by the transaction log file is applied to the database (step 608). The transaction log file provides all the state information needed to recreate a transaction given a state that follows the previous transaction. The current state of the database can be determined. The current state indicates which transaction log file starts applying the database. For example, by applying the received transaction log file, the last time the database was modified can establish the state of the database to which the new transaction log file can be applied. In some implementations, the baseline database state is periodically established across all relevant devices so that transactions are applied from a common baseline state.
After identifying the transaction that applies to the database, you can request the corresponding transaction log file from a remote storage location. Transaction log files, once retrieved, can be used to re-execute each transaction in turn on the database.
FIG. 7 is a flowchart showing an example of the method 700 for synchronizing the databases. Method 700 can be performed by one or more computing devices, such as the remote storage location 508 of FIG.
One or more database transaction logs are received from one or more devices (step 702). Transaction log files can be uploaded periodically from various devices. A group of devices can be associated with a particular user or user account. In some implementations, database transaction logs are received from each separate user or group of many devices associated with a user account.
The transaction log is stored (step 704). The remote storage location can include a storage location that is independent for each device associated with a particular user or user account. The uploaded transaction log file can be stored in the corresponding location on the remote storage location. In some implementations, this is a subdirectory or container. The combination of all transaction log files uploaded from all relevant devices constitutes a remotely stored version of the database, as the database can be recreated by applying all transactions.
Transaction log notifications are sent to each one or more devices (step 706). In some implementations, for a given user / user account, periodic notifications are broadcast to each device associated with one or more received transaction logs. Notifications can be sent when individual transaction log files are received from peer devices or according to a particular schedule. In some implementations, the notification provides a running list of all transaction log files received for the database. In some other implementations, the notification provides a list of transaction log files received after a particular point in time. The point in time may be based on the last notification sent to the device or the last established baseline database.
One or more transaction log files are provided to the device in response to the request (step 708). Individual devices can request one or more of the transaction log files in response to received notifications.
The baseline database is optionally stored periodically (step 710). In particular, in some implementations, the state of the baseline database is periodically established. This database can be stored, for example, on a remote storage location. The transaction log file can then be maintained and notifications will be sent to this baseline database. Alternatively, in some other implementations, only the running set of received transaction log files is maintained.
FIG. 8 is a flowchart showing an example of the method 800 for managing conflicts. Method 800 can be performed by one or more computing devices, such as the first device 502 or the second device 504 in FIG.
The transaction log is received (step 802). In particular, transaction log files can be received from two or more different devices. A determination is made as to whether there is a conflict (step 804). Conflict determination can be based on transaction log file comparisons. Comparisons can be used to determine the characteristics of the changes applied to the database by each transaction. For example, a conflict can occur if there is a column name change in the first transaction on the first device and another change from a different device to the same column name in the second transaction. In some implementations, two transactions that modify the same row in the database are considered conflicts.
In some other implementations, metadata about the contents of transaction log files can be cached. This makes it possible to speed up the detection of conflicts. For example, metadata can identify rows modified by a transaction so that conflicting transaction logs can be quickly identified.
If there are no conflicts, the transaction is applied to the database (step 806). When a transaction is applied, the database can have a state corresponding to the sum of transactions as applied to the baseline database.
If there is a conflict, a decision is made as to whether the conflicting transactions can be merged (step 808). For example, two or more transactions can make changes to the same row in the database. However, each transaction can be applied separately if the individual cells are independent of each other and the changes to the rows occur in different columns. In contrast, two transactions for the same cell in the database do not have to be merged together because the changes are inconsistent with each other.
In some implementations, a transaction with a conflict in which the same cell has changed twice is resolved by selecting the most recent change (eg, using change vectors and timestamps), and at the same time more recently. Minimize the amount of data that is clearly wrong due to changes in. In this way, advanced merging can be performed without user intervention or application developer effort.
Conflict minimization can be done column by column or on join table entries (contents of to-many relationships). As an example, the database can contain identifiers for membership within a group. Many peer devices can edit membership within a group, for example by adding and removing members. Conflicts do not occur when different devices add or remove different members. Conflicts only occur when the same member is added or removed in different ways between different devices. Which membership change is an addition or deletion is determined for the common ancestor of the device. This is a "three-way merge" (eg, device # 1, device # 2, and common ancestors, which are the last database states that the device has previously agreed to, as described in more detail below).
In some implementations, competing transactions are compared to the state of the database of a common ancestor to determine if a merge is possible. Comparisons are used to determine if both transactions can be applied in a non-mergable database without causing other conflicts.
One or more factors can be used to identify a database of common ancestors. Factors include the identification of the first peer device connected to the remote storage location, the slowest peer device (for example, to identify the state of the common database reached by all peer devices), and the inactivity. This can include declaring the peer as dead. The state of a common ancestor at which competing peer devices reach a pre-agreed database state is determined using log change vectors and timestamps to go far enough in a transaction. The baseline database may be the most backward to all peers, but only one of the two peer devices may be turned off by a small number of transaction logs. They inspect the logs in reverse order to get the state before the first conflict that has not been resolved between them. Also, in some implementations, conflict resolution is not limited to two peers. You can notice that three or more peers are competing.
If you can merge conflicting transactions, you can apply the merged transactions to the database (step 810). When a transaction is applied, the database can have a state corresponding to the sum of transactions as applied to the baseline database.
If the competing transactions cannot be merged, the winner of the conflict is determined between the competing transactions (step 812). In some implementations, the winner of the competition is determined based on the time stamp associated with each transaction. For example, each transaction log file can contain a time stamp that indicates how long the transaction occurred on its device. The winner of the conflict may be selected as the last change in the competing transaction. Other heuristics can be used to determine the winner of the competition. Rules allow you to establish priorities for certain types of transactions. Deletion, for example, can win different types of changes. You can apply the competitor's winner's transaction to the database, while discarding the competitor's loser's transaction.
In some implementations, the merge policy for a particular database structure may be specified by the database developer or user. The user interface may be presented to enter or modify the merge policy.
In some implementations, the peer database can be restored from a damaged state using a transaction log file stored on a remote storage location. Similarly, transaction log files stored on the remote storage location can be used to keep the database up to date from new user devices added to the remote storage location.
In some implementations, conflicts identified by the "ABA" problem occur. Even if the column values don't seem to change from a common ancestor (eg A), the ABA problem actually changes twice (A to B, then back to A). is there. By detecting this, the conflict can be resolved to prefer the last change. Thus, in this case, A appears to be identical to the common ancestor, but can still be more recent than the new value from another device.
FIG. 9 shows an example of the system architecture 900 for a computer system. System architecture 900 is capable of performing the operations described herein. Architecture 900 includes one or more processors 902 (eg, IBM PowerPC, Intel Pentium 4, etc.), one or more display devices 904 (eg, CRT, LCD), and graphics processor 906 (eg, NVIDIA GeForce, etc.). A network interface 908 (eg, Ethernet, FireWire, USB, etc.), an input device 910 (eg, keyboard, mouse, etc.), and one or more computer-readable storage media 912. These components communicate and exchange data using one or more buses 914 (eg, EISA, PCI, PCI Express, etc.).
The term "computer-readable storage medium" refers to any tangible medium involved in providing instructions to processor 902 to execute. The computer-readable medium 912 includes an operating system 916 (eg, Mac OS (r), Windows (r), Linux, etc.), a network communication module 918, an access control manager 920, a synchronization manager 922, and other applications 924. Further prepare.
The operating system 916 may be multi-user, multi-processing, multi-tasking, multi-threading, real-time and the like. The operating system 916 identifies the input from the input device 910, sends the output to the display device 904, and tracks files and directories on a computer-readable storage medium 912 (eg, memory or storage device). And perform basic tasks including, but not limited to, controlling peripherals (eg, disk drives, printers, etc.) and managing traffic on one or more buses 914. The network communication module 918 includes various components that establish and maintain network connections (eg, software that implements communication protocols such as TCP / IP, HTTP, Ethernet, etc.).
The access control manager 920 and synchronization manager 922 perform various functions that perform application-specific access control and synchronization of data items including database transactions between devices as described in connection with FIGS. 1-8. Provides software components.
The embodiments of the subject and the operations described in the present invention are digital electronic networks, or computer software, firmware or hardware, including the structures and structural equivalence disclosed in the present invention, or one or more of them. It is feasible in the combination of. Embodiments of the subject described in the present invention are one or more computer programs, i.e. computer programs encoded on a computer storage medium to be executed by or to control the operation of the data processing apparatus. It can be realized as one or more modules of instructions. Alternatively or additional , the program instructions, the electrical signals generated by a machine generated information for transmission to the appropriate receiver apparatus to encode for execution by the data processing unit, an optical signal or an electromagnetic signal It can be encoded on an artificially generated propagation signal such as. The computer-readable medium may be a computer-readable storage device, a computer-readable storage board, a random access memory array or a random access memory element, a serial access memory array or a serial access memory element, or a combination thereof. , Or may be included in them. Further, the computer storage medium is not a propagation signal, but can be a source or destination of computer program instructions encoded in an artificially generated propagation signal. Further, the computer storage medium may be or may be one or more independent physical components or media (eg, a large number of CDs, disks or other storage devices).
The operations described in the present invention can be realized as operations performed by a data processor on data stored on one or more computer-readable storage devices or data received from other sources.
The term "data processor" refers to a programmable processor, a computer, a system on one or more chips, or a device that includes all types of devices, devices, and machines that process data, including, for example, the combinations described above. It can include dedicated logic networks such as FPGAs (Field Programmable Gate Arrays) or ASICs (Application Specific Integrated Circuits). In addition to hardware, the device is code that creates an execution environment for the computer program, such as processor firmware, protocol stacks, database management systems, operating systems, cross-platform run-time environments, virtual machines, or one or more of them. The code that makes up the combination can also be included. Equipment and execution environments can implement a variety of different computing model infrastructures such as web services, distributed computing infrastructures and grid computing infrastructures.
Computer programs (also known as programs, software, software applications, scripts or code) may be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and stand alone. It may be deployed in any form, including programs, or forms that are modules, components, subroutines, objects, or other units suitable for use in a computing environment. The computer program may, but may not, correspond to the files in the file system. Stored in a single file or multiple linkage files dedicated to the program (eg, a file that contains one or more modules, subprograms, or parts of code) and other programs or data (eg, in a markup language document). A program can be stored in a part of a file that holds (one or more scripts). Computer programs can be run on one or more computers located at one site, or deployed to be distributed across multiple sites and interconnected by communication networks.
The processing and logical flows described in the present invention can be performed by one or more programmable processors that execute one or more computer programs to operate on the input data and to perform the operation by producing an output. is there. The processing and logic flow can be further executed by a dedicated logic network such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the device can also be realized as a dedicated logic network.
Suitable processors for executing computer programs include, by way of example, both general purpose and dedicated microprocessors and any one or more processors of any kind of digital computer. Processors generally receive instructions and data from read-only memory, random access memory, or both. Essential elements of a computer are a processor that performs operations according to instructions, and one or more memory elements that store instructions and data. In general, the computer further comprises one or more mass storage devices for storing data such as magnetic disks, magneto-optical disks or optical disks, or receives data from the one or more mass storage devices, or a combination thereof. Data is transferred to one or more mass storage devices or is operably combined to perform both reception and transfer. However, the computer does not necessarily have to have such a device. In addition, computers are mobile phones, personal digital assistants (PDAs), mobile audio players or mobile video players, game consoles, Global Positioning System (GPS) receivers, or portable storage devices (eg, mobile storage devices), to name just one example. , USB (universal serial bus) flash drive), etc. can be embedded in another device. Devices suitable for storing computer program instructions and data include semiconductor memory elements such as EPROM, EEPROM and flash memory elements, internal hard disks or magnetic disks such as removable disks, magneto-optical disks, and CD-ROM disks and DVDs. -Includes all forms of non-volatile memory, media and memory elements, including ROM disks as an example. The processor and memory can be supplemented by a dedicated logic network or can be incorporated into a dedicated logic network.
In order to interact with the user, embodiments of the subject described in the present invention provide a display device such as a CRT (Brown tube) monitor or LCD (LCD) monitor that displays information to the user, as well as the user providing input to a computer. It can be realized on a computer having a keyboard and a pointing device such as a mouse or trackball that can be used. Other types of devices can be used to interact with the user, for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback or tactile feedback, from the user. The input may be received in any form, including acoustic input, audio input or tactile input. In addition, the computer sends a document to and from a device used by the user and receives the document from that device, eg, a web page on the user's client device in response to a request received from the web browser. This allows you to interact with the user.
Embodiments of the subject described in the present invention are, for example, a back-end component such as a data server or a middleware component such as an application server, or a graphical user interface or web browser that allows a user to interact with an embodiment of the subject described in the present invention. It is feasible in computing systems that include front-end components such as client computers, or any combination of one or more such back-end components, middleware components, or front-end components. The components of the system may be interconnected by digital data communication in any form or medium, such as a communication network. Examples of communication networks include local area networks (LAN) and wide area networks (WAN), internetworks (eg, the Internet), and peer-to-peer networks (eg, ad hoc peer-to-peer networks).
Computing systems can include clients and servers. Clients and servers are generally separated from each other and typically interact over a communication network. The client-server relationship arises from computer programs that run on their respective computers and have a client-server relationship with each other. In some embodiments, the server sends data (eg, an HTML page) to a client device (eg, to display data to and receive user input from a user interacting with the client device. ). Data generated on the client device (eg, as a result of user interaction) can be received from the client device on the server.
Although the present invention contains details of many specific embodiments, they should not be construed as limiting the scope of any invention or what may be claimed, and are specific to a particular invention. It should be construed as explaining the characteristics specific to the embodiment. Certain features described in the present invention in the light of independent embodiments can also be realized in combination in a single embodiment. Conversely, the various features described in the light of a single embodiment can be realized separately in multiple embodiments or as part of any suitable combination. Also, features are described above as operating in a particular combination and may be so claimed first, but one or more features from the claimed combination may be removed from that combination in some cases. The claimed combination may be associated with a portion of the combination or a modification of a portion of the combination.
Similarly, the actions are illustrated in a particular order, which means that such actions are performed in a particular order or in a contiguous order to obtain the desired result, or all shown. Should not be understood as requiring that the action be performed. In certain situations, multitasking and parallel processing may be advantageous. Also, the separation of the various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and the program components and systems described are generally single. It should be understood that they can be embedded together in one of the software products or packaged in multiple software products.
Therefore, specific embodiments of the subject have been described. Other embodiments are within the scope of the following claims. In some cases, the actions listed in the claims can be performed in different orders with the desired result. Also, the processes shown in the accompanying drawings do not necessarily require the specific order or sequential order shown to obtain the desired result. In certain implementations, multitasking and parallelism may be advantageous.
9 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9
Every citation, both waysCites: the store holds 2 of 3
| Document | Relation | Office |
|---|---|---|
| JP2011513863A | Cites | Japan |
| JP2010527087A | Cites | Japan |
| 千種 菊里,手のひらの中のUNIX iPhoneのアーキテクチャ,UNIX magazine,日本,2009年 4月 1日,Vol.24 No.2,PP,113-131 | Non-patent | – |
14 members in 7 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 201161493390 | United States of America | P | |
| 201161493390 | United States of America | P | |
| 61493390 | United States of America | – | |
| 61493390 | – | – | – |
| US201161493390P | – | – | – |
Members14
| Document | Office | Kind | |
|---|---|---|---|
| US2012310880A1 | United States of America | A1 | |
| WO2012167108A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2012261986A1 | Australia | A1 | |
| KR20140014268A | Republic of Korea | A | |
| CN103620599A | China | A | |
| EP2715571A1 | European Patent Office (EPO) | A1 | |
| JP2014525066A | Japan | A | |
| JP5740529B2 | Japan | B2 | |
| JP2015172946A | Japan | A | |
| US9208201B2 | United States of America | B2 | |
| AU2012261986B2 | Australia | B2 | |
| KR101596559B1 | Republic of Korea | B1 | |
| JP6000401B2This record | Japan | B2 | |
| CN103620599B | China | B |
14 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 |
Numbers
- Publication
- 6000401
- Publication, DOCDB
- 6000401
- Publication, EPODOC
- JP6000401B
- Application
- 90784
- Application, DOCDB
- 2015090784
- Application, EPODOC
- JP20150090784
Titles2
- Japanese
- クラウドストレージ
- English
- Cloud storage
Classification
- CPC, 3
- G06F16/24575
- G06F16/2471
- G06F3/0622
- IPC, 1
- G06F12 00
