System and method for providing access to data file storage in data storage system

Abstract

The invention relates to a system and method for providing access to data files stored in a data storage system. Systems and methods disclosed herein provide access to data files stored in a remote data storage system. A user device can send a file access request to an application server via a user interface provided through a remote storage server to access a data file stored at the remote storage server. The application server can then optionally identify related applications for accessing the data file and send metadata and content requests related to the data file to the remote server. The metadata and the content request include version information of a previously cached version of the data file cached at the application server. When the cache version is not the latest version, the application server receives the latest version of the data file from the remote storage server. The latest version of the data file is then presented to the user device via an associated application on the application server.

Description

[0001] Case Analysis

[0002] This application is a divisional application of Chinese Invention Patent Application No. 201711237577.4, filed on November 30, 2017. Technical Field

[0003] In general, this disclosure relates to data file management in a remote access environment, and more particularly to systems and methods for providing access to data files stored at a remote data storage system. Background Technology

[0004] Users sometimes need to access and edit various data files. For example, users may need to open or edit word processing files, spreadsheet files, database files, programming source code files, presentation slides, email message files, image files, video files, or other types of files. Each of these data files may require a corresponding specialized software application to open or edit. Therefore, users typically need to install the necessary specialized software on their local computer to open various types of data files. When the specific software is not present on the user's device, the user cannot access or manipulate a particular type of data file.

[0005] When a user attempts to open and edit data files stored on a remote server, existing document systems typically require the user to download the data file from the remote server to their local computer, enabling the user to open the file via a specific locally installed software application. The need to download remotely stored data files and install various local software applications to manipulate different types of data files can be resource inefficient. Moreover, this access to data files becomes impractical when the user is operating a mobile device, such as a smartphone, which lacks the capacity to install computer applications or the storage space to download data files. Summary of the Invention

[0006] The systems and methods disclosed herein provide a mechanism for providing access to data files stored on a remote data storage system. An application server hosting various applications allows user devices to open data files stored on the remote data storage system without the user device needing to download a copy of the data file or install the relevant application locally. The user device sends a file access request to the application server via a user interface provided by the remote storage server to access the data file stored on the remote storage server. The application server can then optionally identify the relevant application for accessing the data file and send metadata and content requests related to the data file to the remote server. The metadata and content requests include version information of a previously cached version of the data file cached on the application server. Upon receiving the metadata and content requests, the remote storage server verifies whether the cached version of the data file is the latest version based on the version information received from the metadata and content requests. When the cached version is not the latest version, the application server receives the latest version of the data file from the remote storage server to replace the previously cached version. The latest version of the data file is then presented to the user device via the relevant application on the application server. In this way, the user can open, annotate, or edit the latest version of the data file stored on the remote storage server without downloading the data file to the user device or installing the relevant application locally on the user device. Attached Figure Description

[0007] The above and other features of this disclosure, including its nature and various advantages, will become more apparent when considered in conjunction with the following detailed description, in which the accompanying drawings are shown: Figure 1 An example data flow diagram according to an illustrative embodiment is provided, which illustrates data message passing for providing access to data files stored at a remote data storage system between a user device, an application server, and a remote storage server; Figure 2 This is an example logic flowchart according to an illustrative embodiment, which illustrates aspects of the workflow at an application server for providing access to data files stored at a remote storage server. Figure 3 Example flowcharts are provided according to illustrative embodiments, which illustrate aspects of creating new data files from a user device in a remote storage server via an application programming interface (API); Figure 4 Example flowcharts are provided according to illustrative embodiments, illustrating aspects of opening data files in a remote storage server for viewing, annotating, or editing from a user device via an API; and Figure 5 According to illustrative embodiments, a computing device is used to perform any of the processes described herein, such as Figure 1 A block diagram of any component of the system implemented in [the document / system]. Detailed Implementation

[0008] To provide a full understanding of the systems and methods described herein, certain embodiments will now be described, including systems and methods for providing access to data files stored at a remote data storage system. However, those skilled in the art will understand that the systems and methods described herein can be adapted and modified to suit the application being processed, and that the systems and methods described herein can be used for other suitable applications without departing from their scope. Typically, the computerized systems described herein may include one or more engines comprising one or more processing devices, such as computers, microprocessors, logic devices, or other devices or processors configured with hardware, firmware, or software to perform one or more of the computerized methods described herein.

[0009] In one embodiment, this document describes a mechanism for providing access to data files stored at a remote data storage system. A protocol is provided for communication between a remote application server and a remote storage server, enabling the remote application server to launch an application to access and perform operations on the data files originally stored on the remote storage server. Specifically, the remote application server sends an initial request to the remote storage server via an Application Programming Interface (API) for the metadata and content associated with the data file the user is attempting to access. The remote storage server can then verify whether the remote application server has the latest version of the requested data file, and if the application server does not have the latest version, it sends the latest version of the requested data file to the application server. In this way, the remote application server can open the latest version of the data file without requiring the user to download the data file to a local device or install a specific application locally to access and edit the data file.

[0010] For example, a user can attempt to open a data file stored on a remote storage server via a remote storage user interface, such as a browser-based interface. The user then sends an access request to a remote application server via the browser-based interface to launch the relevant application and open the requested data file. The remote application server sends a request to the remote storage server for the metadata and content associated with the data file. This metadata and content request can be a single request that includes both updated metadata and updated content for the data file. The metadata and content request must include at least the current cached version of the data file's content stored on the remote application server. Upon receiving the metadata and content request, the remote storage server determines if the content version is the latest version of the data file and then sends the latest version of the data file to the remote application server. In this way, the remote application server can open the latest version of the requested data file for the user.

[0011] Figure 1 Example Figure 100 is provided according to an illustrative embodiment, illustrating a data flow between user equipment 101a-c (collectively referred to herein as 101), application server 120, and remote storage server 110 for providing access to data files stored at a remote data storage system. This includes, but is not limited to, one or more entities of user equipment 101, application server 120, and remote storage server 110 communicating via one or more communication networks.

[0012] User equipment 101 includes various personal devices, such as, but not limited to, smartphones, laptops, desktop computers, workstations, tablets, personal digital assistants (PDAs), etc. Users can operate user equipment 101 to communicate with remote storage server 110 and / or application server 120.

[0013] Remote storage server 110 can be hosted by a remote provider independent of application server 120 or user device 101. For example, remote storage server 110 can be physically separate from any user device 101 or application server 120, hosted in a different domain, owned by a different entity, etc. Alternatively, remote storage server 110 can share the same public or private cloud as application server 120. Remote storage server 110 can provide user device 101 with a file storage user interface 105, enabling the user to interact with data files stored on remote storage server 110 via user interface 105. User interface 105 can include mobile applications (e.g., on smartphones or tablets) or browser-based applications (e.g., on computers), etc. Browser-based applications are used throughout this document as an example of user interface 105.

[0014] Within the file storage user interface 105, the user can configure or pre-configure how to open data files. For example, before attempting to open any data file, the user can pre-configure one or more data files to be opened by an application from application server 120, or the user can right-click the data file icon and select "Open With" to configure an application from application server 120 as the application to open the file. When the user selects a data file to access via the file storage user interface 105, if the user has already pre-configured an application from application server 120 as the default application, or has already selected an application from application server 120 to dynamically open the file, the user device 101 sends a file access request 108 to application server 120. The file access request includes information such as, but not limited to, a data file identifier, a storage server identifier, a data file type, a user device identifier, etc. In some implementations, the document identifier, the storage server identifier, and an optional protocol buffer can be combined and encoded into a string, and the string is included as a key in the file access request used for transmission.

[0015] In some implementations, application server 120 is a single server hosting various applications. In other implementations, application server 120 comprises multiple distributed application servers. For example, each distributed application server hosts one type of application, such as a document processing application, a software development application, a database management application, etc.

[0016] In some implementations, such as combining Figure 3-4 Furthermore, the file access request 108 takes the form of a Hypertext Transfer Protocol (HTTP) POST request, which can be used when the file access request 108 is generated from a mobile application or browser interface of the storage server. Specifically, when the storage server uses a browser-based application on a user's device, the structural tags in the Hypertext Markup Language (HTML) source code of the browser page, such as... <iframe>Generate an HTTP POST request within tags, etc. The structure tag defines a region on the browser page within which the requested data file or document can be displayed.

[0017] Implement a file application programming interface (API) 130 to allow the application server 120 to obtain the metadata and content of a data file from the remote storage server 110. The application server 120 sends a file metadata and content request 112 for the latest version of the metadata and the latest version of the content associated with the requested data file to the remote storage server 110 via the API 130. Example metadata attributes associated with the data file include, but are not limited to: file type, file identifier, file name, Multipurpose Internet Mail Extensions (MIME) type, whether the file is starred or marked by the file system, parent file, or folder, application attributes, file version, creation time, modification time, user name, user identifier (ID), and email address of the owner, requester, and creator at the last modification, full file extension, file checksum (for comparison, the storage server can select an encoding method (e.g., MD5, SHA1, SHA2, etc.)), file size, access / editing privileges, status regarding whether the file has an edit lock, etc. The metadata and content request 112 can also include a proof key, which is a public key issued by the application server 120, so that the remote storage server 110, which has previously been provided with the public key information by the application server 120, can verify that the key information from the metadata and content request 112 is consistent. In this way, key verification confirms that the metadata and content request 112 is sent from the application server 120. Then the remote storage server 110 sends the requested metadata and content to the application server 120. When the application server 120 does not have the latest version of the data file in its local cache, the remote storage server 110 sends the latest version of the content of the data file 113 to the application server 120, as further discussed in 207 of Figure 2.

[0018] In some implementations, the user can make changes to the data file via an application in the application server 120, and such changes are transmitted to the remote storage server 110 via the API 130 to update the data file stored at the remote storage server 110. The component that instantiates the API 130 on the application server 120 to interface with the remote storage server 110 can be implemented in JavaScript using a Post message.For example, remote storage server 110 can send a "title changed" message to notify remote storage server 120 that the title of a data file has been changed (e.g., by a user device), enabling remote storage server 110 to update information related to the data file title accordingly, such as the title bar in the browser interface of remote storage server 110 displayed on the user device. As another example, application server 120 can send a "share open" message to notify remote storage server 110 that a user has clicked the "share" button, enabling remote storage server 110 to open a share frame to allow the data file to be shared by the user with one or more other users. As yet another example, access control messages related to the data file, such as an "access control list open" message, can be sent to remote storage server 110 to notify remote storage server 110 that a user has attempted to modify access rights to the data file; for example, another user who cannot access the data file has been granted access. Therefore, remote storage server 110 can display an access control frame, such as an "access control list configuration" frame displayed in the file storage user interface 105 of the user device.

[0019] In some implementations, users can directly modify data files in remote storage server 110. In this case, remote storage server 110 sends a message to application server 120 via API 130 to synchronize the changes. For example, remote storage server 110 can send a "metadata change" message via API 130 to notify application server 120 that the user has changed file metadata (e.g., the sharing status of data files), and therefore application server 120 should refresh the metadata. As another example, when a user closes an access control frame in remote storage server 110, access control messages, such as an "access control list configuration closed" message, are sent from remote storage server 110 to notify application server 120 that the user has closed access control functions related to data files, such as the "access control list configuration" dialog box, and whether the user has decided to continue the action.

[0020] In some implementations, application server 120 and remote storage server 110 each configure API 130 by sharing information. For example, remote storage server 110 provides configuration information to application server 120 via a Uniform Resource Locator (URL) so that application server 120 knows the possible types of data or messages (e.g., metadata of data files, etc.) that can be received from remote server 110.

[0021] Figure 2 is an example logic flow diagram that illustrates aspects of the workflow at an application server (e.g., 120 in Figure 1) that provides access to data files stored at a remote storage server (e.g., 110 in Figure 1) according to the embodiments described herein; at 201, the application server (e.g., 120 in Figure 1) receives a file access request from a user device (e.g., 101 in Figure 1) to access (e.g., open, annotate, or edit) a data file stored at a remote storage server (e.g., see 110 in Figure 1). As discussed in connection with 108 in Figure 1, the file access request includes a data file identifier, a storage server identifier, a data file type, a user device identifier, etc. The file access request can take the form of an HTTP POST request within the structure tags of the HTML source code of a browser page. At 202, the application server can optionally identify and launch a relevant application to open the corresponding data file, e.g., based on the file type of the data file included in the file access request.When the file access request further includes an application identifier for opening the data file, such as when the user has right-clicked on the data file icon to select the application to open the file and the application identifier of the selected application is included in the file access request, the application server can directly launch the application. At 203, the application server can identify the cached data file in a data store (e.g., a database) and query whether the cached version of the data file has been previously saved in the database. At 204, if there is a cached version of the data file, the application server retrieves the version value (e.g., a number) from the metadata of the cached version of the data file and includes the version value in the request for metadata and content to be sent to the remote storage server. The version value is described in more detail below in connection with Figure 4. If there is no cached version, the metadata and content request includes an indicator identifying that there is no cached version on the application server. In one implementation, the application server can optionally include a delivery parameter in the metadata and content request. The delivery parameter can be a Boolean value configured as true or false, which is used to indicate whether the remote storage server should provide the content of the latest version of the data file to the application server if the cached version of the data file at the application server is not the latest version. For example, an application can periodically refresh the metadata of the cached version of a data file by requesting the latest metadata of the data file from the remote server, but may not need to request the latest content of the data file every time the metadata is refreshed to avoid excessive data traffic between the servers. In this case, the application server can set the delivery parameter in the metadata and content request to indicate that the latest content of the data file from the remote storage server is not required.

[0022] At 204, in addition to obtaining the version value of the cached version of the data file, the application server optionally retrieves a hash from the metadata associated with the cached version of the data file or generates a hash based on the content of the cached version. The hash is then optionally included in the metadata and content request together with the version value of the cached version to be sent to the remote storage server via the API.

[0023] At 205, the application server receives a message from the storage server and verifies whether the cached version on the application server is the latest version of the data file. The storage server determines whether the version value included in the metadata and content request reflects the latest version of the data file at the storage server.For example, a storage server maintains a data store (e.g., a database) of data files with metadata including version information for each data file, and is able to form a search for a desired data file based on the metadata and a data file identifier included in a content request to identify the data file and then retrieve the metadata associated with the data file. Additionally, if a hash of the cached version has been optionally included in the metadata and the content request (at 204), the storage server is able to obtain both the version value and the hash of the cached version and compare both the received version value and the received hash with the version value and hash associated with the latest version of the data file in the storage server. When the comparison shows that the latest version of the data file has a different version value but the same hash as the cached version, the storage server may not need to send the content of the data file to the application server because the content of the data file has not changed from the cached version.

[0024] When the cached version is the latest version of the data file, at 206, the application server is able to optionally receive a confirmation message from the storage server that the version does not need to be updated. The confirmation message may also include the metadata of the data file so that the application server can keep the metadata up to date. At 210, the application server is able to provide the cached version of the data file to the user device via a user interface (e.g., the file storage UI 105 in Figure 1). Otherwise, if the cached version in the metadata and the content request is not the latest version of the data file, or there is no cached version of the data file at all on the application server, the application server receives the metadata and content of the latest version of the data file from the storage server at 207. Specifically, when the metadata and the content request include a hash generated based on the content of the cached version, the storage server is able to optionally verify whether the received hash is the same as the hash associated with the latest version. If the two hashes match, the storage server does not need to send the content of the latest version to the application server. The application server receives the metadata of the latest version and an optional message identifying the cached version as having the latest content. If the two hashes do not match, the application server receives the latest content and metadata, as described, for example, at 207. In one implementation, the storage server reads the passing parameters in the metadata and the content request to determine whether to send the content of the latest version of the data file to the application server if the cached version of the data file at the application server is not the latest version.

[0025] At 207, the metadata and content of the data file can be sent to the application server in a single message or a multi-part message.For example, the content of a data file can be sent as a copy of the data file from a storage server, and the metadata of the file can be sent via a URL embedded in a message. In another example, an application can receive a message that includes a predefined link to the latest version of a data file stored in a storage server.

[0026] At 209, the application server overwrites any previously cached version of the data file on the application server with the received version at 209. Then, the application server can provide the newly cached version to the user device via a user interface in a similar manner as described, for example, at 206.

[0027] Figure 3 provides an example flowchart 300 according to some embodiments described herein, which illustrates aspects of creating a new data file in a remote storage server from a user device via an API (e.g., 130 in Figure 1). An application server 303 (similar to 120 in Figure 1) can send an HTTP action request, such as opening an existing file, creating a new file, saving file changes, etc., to a remote storage server (similar to 110 in the figure) to invoke relevant operations to be performed on a file in a user interface at the user device. At 305, a user interface instantiated at the user device (e.g., 101 in Figure 1), such as a browser 301, can send a user request to create a file at the remote storage server 302. The create file request includes the file type, file name, application identifier (for creating the file), folder name and directory in the storage server indicating where the created file will be stored, etc. The create file request can include an HTTP POST request, which can take a form similar to "create (POST files / create)” to create a new file in the folder indicated by the create file request.

[0028] At 306, the remote storage server 302 can optionally create a file identifier and potentially set a lock state on the file when a new file is created. The lock state grants an entity (e.g., application server 303) exclusive permission to create, access, or save file contents to storage server 302 for a period of time, such as 5 minutes, 10 minutes, 15 minutes, etc. Storage server 302 prevents any attempt from any other authorized entity to create, open, or save changes to the same locked file. Other authorized entities include, but are not limited to, users authorized to edit data files, applications authorized to edit data files, any remote user interface of the storage server authorized to edit data files, etc.

[0029] At 306, storage server 302 also sends a remote access token (also known as a "third-party access token" (TPAT)) to browser 301. The TPAT is generated by the remote storage server and has an expiration timestamp, which allows an entity (e.g., a user, etc.) to access a specific file, such as a file to be created, before the expiration timestamp. The TPAT can also authorize a user to access specific file and folder metadata.

[0030] At 307, a file creation request in the form of an HTTP POST request is sent to application server 303. The file creation request is displayed in the HTML source code of the browser 302 in the structure tags (e.g., ...).<iframe> The TPAT is generated within the tag and includes the TPAT received by browser 301 at 306. If browser 301 receives a prior request from application server 303 that includes a token authorizing browser 301 to access the specific application that will be used to create the file, browser 301 can optionally exchange the TPAT token.

[0031] In some implementations, a user can log in to the application server 303 with user credentials, and the browser 301 can include such user credentials in an HTTP POST request at 307 to enable the application server 303 to authenticate the user. The user can also log in to the storage server 302 via the browser 301, allowing the storage server 302 to determine whether the user is authorized to create or open data files on the storage server 302.

[0032] At 308, the application server 303 sends a metadata and content request to the remote storage server 302 in the form of an HTTP GET call "get (GET files / filesId)" to obtain the metadata and content of a file or folder.At 309, metadata and content requests can include file identifiers, file names, indicators that the file's content or version does not yet exist on the application server (such as for newly created files), and so on. In response to a GET call at 310 with no content, the remote storage server at 302 can then return the metadata of the newly created file in the message.

[0033] At 311, application server 303 creates a new data file, such as a document. The newly created document can be displayed in the file storage UI. The created document can be displayed in the structure tab specified by the file access request in 307 (e.g.,<iframe> Within the area defined by the tag, the newly created document can be edited. In 312, application server 303 can periodically upload the latest version value of the cached version to remote storage server 302, for example, every two minutes. A copy of the file can be uploaded using an HTTP POST message in the form of "upload(POST files / fileId / blob)," where the "blob" parameter is the web API used by application server 303 to communicate with storage server 302. When a new file identifier is created (e.g., in 306), a copy of the file is uploaded to the storage server in 312 using the POST message "uploadCopy(POST files / fileId / copy)). The copy can optionally be shared with the value of the user and / or entity that can access the file via TPAT. The storage server's response to the POST call contains a Uniform Resource Locator (URL) for opening the new file, as further discussed in 313.

[0034] At 313, the remote storage server 302 may optionally return the latest uploaded version to the application server 303. A response message to the upload at 312 is sent from the remote storage server 302 to the application server 303. The response message contains the version value and checksum of the newly created file.

[0035] Application server 303 is configured to periodically, intermittently, or continuously update file information with storage server 302 so that application server 303 maintains the latest metadata and content of data files. At 314, application server 303 can periodically use HTTP GET calls to retrieve file metadata from remote storage server 302, for example, every five minutes. The HTTP GET call can take the form of "get(GET files / fileId)", which is configured to retrieve file metadata or content. Remote storage server 302 can optionally return metadata at 315, for example, via the HTTP PUT message "updateMetadata(PUT files / fileId)".At 316, when the data file is closed at the application server 303, if the data file is potentially locked when the file identifier is created at 306, the application server can notify the remote storage server 302 by sending an HTTP PUT message "(PUT files / fileId / close)", and the storage server can unlock the data file at 317.

[0036] Figure 4 provides an example flowchart 400 according to some embodiments described herein, showing aspects of opening a data file stored by a remote storage server for viewing, annotating, or editing by a user device via an API (e.g., 130 in Figure 1). At 401, a user interface instantiated at the user device (e.g., 101 in Figure 1), such as browser 301, sends a file access request to open a file at the remote storage server 302. The user request can include a data file identifier, a storage server identifier, the type of the data file, a user identifier, a user device identifier, etc. At 402, the remote storage server 302 can check access authorization based on the user identifier, e.g., by verifying whether the user identifier is on an access control list associated with the data file to which the user has access rights.

[0037] At 402, the storage server 302 then checks the metadata of the data file to verify whether another entity has a lock on the data file. For example, the lock status is specified in the file metadata in the "locked_for_edit" field. If the file has not been locked by another entity, the storage server locks the file for the application server 303. When the file is locked by another entity, the file can still be opened for viewing (in browser 301 or for preview or download). If the application server 303 does not have a lock on the file, the application server will display a read-only view to the user and explain that the file is being edited by another entity (e.g., another user or another application). Any request for the file sent from the application server 303 to the storage server 302 can reset the lock for a period of time (e.g., 5 minutes, 15 minutes, etc.).The application server 303 can periodically call the storage server 302, such as every 5 minutes, etc., to obtain updated metadata and maintain the lock. In one embodiment, if a request (e.g., the metadata and content request to be discussed in 404) to update the metadata fails after three attempts, the application server 303 can display an error message to the user via the browser 301. If the application server 303 fails to make any metadata or content requests to the storage server 302 for a period of time (e.g., 15 minutes, etc.), the lock may be lost. If the lock on a file is lost, but then a file access request for the same file is received, the storage server 302 can attempt to reissue the lock to the application server 303. If the lock cannot be reissued because another entity already holds the lock on the same file, the application server 303 switches to the read-only mode of the file.

[0038] At 402, the storage server 302 also sends the TPAT back to the browser 301 in a similar manner as described by 306 in Figure 3.

[0039] At 403, a file access request is generated. The file access request can be an HTTP POST request generated within the structure tags of the HTML source code of the display page of the browser 302, and the HTTP POST request includes the TPAT for the file received from the storage server at 402. The file access request can include a data file identifier, a storage server identifier, the type of the data file, a user identifier, a user device identifier, a token (TPAT), etc., as discussed by 201 in Figure 2.

[0040] At 404, the application server 303 can send a metadata and content request to the remote storage server 302 to obtain the metadata and content of a file or folder. The metadata and content request can be an HTTP GET call. The GET call includes the version information (e.g., version value) of the data file stored in the cache at the application server 303. In one implementation, the application server 303 maintains a data table that maps the internal version values that have a format compatible with the application server 303 and are used by the application server 303 to the external version values that are compatible with and used by the remote storage server 302 or other entities.The application server 303 can identify or retrieve the build value from metadata stored in association with the cached version of the data file and then can convert the build value into the corresponding external version value. The GET call can include the external version value of the data file as the current version parameter, enabling the remote storage server 302 to read the current version parameter and obtain the version value associated with the cached version of the data file cached at the application server 303. The GET call can also optionally include a hash generated from the content of the cached version, as discussed in 204 in conjunction with Figure 2. In one implementation, if there is no data file stored in the cache, an indicator of no cached version is included in the metadata and the content request, for example, similar to 309 in Figure 3. In one implementation, the metadata and the content request optionally include a passing parameter that specifies whether the storage server 302 should provide the content of the latest version of the data file to the application server if the cached version of the data file at the application server is not the latest version. In one implementation, the application server can optionally request a specific version of the data file in the metadata and the content request, which may not be the latest version, and can include the version value of the requested specific version in the metadata and the content request. For example, the metadata and the content request can optionally include a "requested version" parameter that can be configured with a version value to request a specific version of the data file. When the metadata and the content request do not include such a requested version parameter, by default, the latest version of the data file stored on the remote storage server 302 is set as the requested version of the application server.

[0041] At 405, the remote storage server 302 checks whether the application server 303 has the latest version of the data file, for example, as discussed in 205 in Figure 2. In one implementation, as discussed above, the application server 303 may not request the content of the latest version and can request a specific version of the data file by configuring the "requested version" parameter in the metadata and the content request.At 405, in one implementation, the remote storage server 302 also checks whether there is a "request version" parameter in the metadata and content request indicating that the request is for a specific version, and then verifies whether the version value of the cached version stored at the application server 303 is equivalent to the specific version value requested in the "request version" parameter. At 406, the remote storage server 302 returns the metadata of the file to the application server 303. If the application server does not have the latest version of the content of the data file, the remote storage server 302 also checks the transfer parameters in the metadata and content request to determine whether to send the latest version to the application server 303. If the transfer parameter for the remote storage server 302 to provide the latest version is set, the remote storage server 302 sends the content of the latest version of the data file to the application server 303. In one implementation, if the request is for a specific version, the remote storage server 302 sends the content of the specific version of the data file to the application server 303. The remote storage server 302 is capable of sending an HTTP PUT message to the application server 303 at 406. For example, as discussed at 207, the content of the data file can be sent as a copy of the data file from the storage server, and the metadata of the file can be sent via the URL embedded in the message. In another example, the application can receive a message including a predefined link to the latest version of the data file stored in the storage server.

[0042] At 408, for example, the data file (e.g., a document) is displayed for editing. The document can be displayed in an area defined by a structural tag.

[0043] 409 - 414 are similar to 312 - 317 in Figure 3. For example, at 402, the data file may have been locked by another entity (e.g., another user or another application), and the application server can only open a "read-only" version of the data file to the user device. In this case, another entity (e.g., another user or another application) can make changes to the data file. In another example, even if the data file is locked by the storage server for a certain application at 402, an authorized user can directly make changes to the data file via the storage server. In this case, the application server 303 is configured to update the file information such as metadata and / or with the storage server 302 periodically, intermittently, or continuously, so that the application server 303 maintains the latest metadata and content of the data file. At 409, the application server 303 can upload the latest version of the file to the remote storage server 302 periodically, such as every two minutes, etc.At 410, the remote storage server 302 can optionally return the most recently uploaded version to the application server 303. At 411, the application server 303 periodically makes an HTTP GET call to obtain metadata of a file from the remote storage server 302, for example, every five minutes or the like. At 412, the remote storage server 302 optionally returns the metadata. At 413, when the data file is closed at the application server 303, the application server can notify the remote storage server by sending an HTTP PUT message "(PUT files / fileId / close)", and it can unlock the data file at 414.

[0044] As discussed in connection with FIGS. 3-4 (see FIGS. 3 and 4), the HTTP actions for creating or opening a file that an API (e.g., 130 in FIG. 1) can take can also be applied to a folder. For example, a POST message for creating a new folder as a subfolder of a given folder can take a form similar to "create (POST folders / folderId / create)", and a GET message "getMetadata(GET folders / folderId)" can be invoked to obtain folder metadata, and so on.When the application server (120 in Figure 1 or 303 in Figures 3-4) operates on a folder in the storage server (110 in Figure 1 or 302 in Figures 3-4), certain metadata attributes associated with the folder, such as type (always folder), folder ID, folder name, whether the folder is starred, and the parent folder, can be locked from being changed.

[0045] In addition to the above HTTP messages for creating or opening files, updating file metadata, etc., the API (e.g., 130 in Figure 1) can also invoke a GET list adopted by the API as an add-on to search for files or folders on the storage server. Example parameters for search queries generated via the API can include corpus (default "user"), sort (default "name"), page size, page token, etc. In response to the GET list, instead of receiving the complete content or metadata in the HTTP message, the application server receives attributes from the storage server, such as a list of file identifiers, file table, token for the next page of files, items (e.g., the kind, ID, name, etc. of a file or folder), and so on.

[0046] Figure 5 is a block diagram of a computing device for performing any of the processes described herein, such as any component of the system implemented in Figure 1. Each component of these systems may be implemented on one or more computing devices 500. In some aspects, multiple components of these systems may be included within one computing device 500. In some implementations, the components and storage devices may be implemented across several computing devices 500.

[0047] The computing device 500 includes at least one communication interface unit, an input / output controller 510, system memory, and one or more data storage devices. The system memory includes at least one random access memory (RAM 502) and at least one read-only memory (ROM 504). All of these elements communicate with a central processing unit (CPU 506) to facilitate operation of the computing device 500. The computing device 500 may be configured in many different ways. For example, the computing device 500 may be a conventional stand-alone computer, or, alternatively, the functionality of the computing device 500 may be distributed across multiple computer systems and architectures. Alternatively, computer systems may be virtualized to provide the functionality of multiple computing devices 500. In Figure 5, the computing device 500 is linked to other servers or systems via a network or a local area network.

[0048] The computing device 500 may be configured in a distributed architecture where the database and the processor are housed in separate units or locations. Some units perform the main processing functions and minimally include a general controller or processor and system memory. In a distributed architecture implementation, each of these units may be connected via a communication interface unit 508 to a communication hub or port (not shown), which serves as the main communication link to other servers, clients, or user computers and other related devices. The communication hub or port itself may have minimal processing power and mainly serves as a communication router. Various communication protocols may be part of the system.

[0049] CPU 506 includes a processor, such as one or more conventional microprocessors, and one or more auxiliary coprocessors, such as a math coprocessor for offloading workloads from CPU 506. CPU 506 communicates with communication interface unit 508 and input / output controller 510, through which CPU 506 communicates with other devices, such as other servers, user terminals, or devices. Communication interface unit 508 and input / output controller 510 may include multiple communication channels for simultaneous communication with, for example, other processors, servers, or client terminals.

[0050] The CPU 506 also communicates with a data storage device. The data storage device may include a suitable combination of magnetic, optical, or semiconductor memory, and may include, for example, RAM 502, ROM 504, a flash drive, an optical disc such as a compressed optical disc, or a hard disk or drive. The CPU 506 and the data storage device may, for example, both reside within a single computer or other computing device; or they may be interconnected via a communication medium such as a USB port, serial port cable, coaxial cable, Ethernet cable, telephone line, RF transceiver, or other similar wireless or wired media, or combinations thereof. For example, the CPU 506 may be connected to the data storage device via a communication interface unit 508. The CPU 506 may be configured to perform one or more specific processing functions.

[0051] The data storage device may store, for example: (i) the operating system 512 of the computing device 500; (ii) one or more applications 514 (e.g., computer program code or computer program products) adapted to boot the CPU 506 according to the systems and methods described herein, and in particular according to the procedures described in detail with respect to the CPU 506; or (iii) a database 516 adapted to store information that can be used to store information required by the program.

[0052] The operating system 512 and application 514 may be stored, for example, in a compressed, uncompiled, and encrypted format, and may include computer program code. The program instructions may be read from a computer-readable medium other than a data storage device, such as from ROM 504 or RAM 502, into the processor's main memory. Although execution of a sequence of instructions in the program causes CPU 506 to perform the process steps described herein, hardwired circuitry may be used in place of or in combination with software instructions for implementing the processes of the present invention. Therefore, the described systems and methods are not limited to any particular combination of hardware and software.

[0053] Suitable computer program code may be provided to perform one or more functions associated with performing the processes described herein. The program may also include program elements such as an operating system 512, a database management system, and a "device driver" that allows the processor to be connected to computer peripherals (e.g., a video display, keyboard, computer mouse, etc.) via an input / output controller 510.

[0054] As used herein, the term "computer-readable medium" means any non-transitory medium that provides or participates in providing instructions for execution to a processor of computing device 500 (or any other processor of the device described herein). Such media can take many forms, including, but not limited to, non-volatile media and volatile media. Non-volatile media include, for example, optical discs, magnetic disks, or optical disc drives, or integrated circuit memories, such as flash memory. Volatile media include dynamic random access memory (DRAM), which typically constitutes main memory. Common forms of computer-readable media include, for example, floppy disks, floppy disks, hard disks, magnetic tape, any other magnetic media, CD-ROMs, DVDs, any other optical media, punched cards, paper magnetic tape, any other physical media with a perforated pattern, RAM, PROM, EPROM, or EEPROM (electronically erasable programmable read-only memory), FLASH-EEPROM, any other memory chip or memory cartridge, or any other non-transitory medium that a computer can read.

[0055] Various forms of computer-readable media may relate to transmitting one or more sequences of instructions to CPU 506 (or any other processor of the device described herein) for execution. For example, the instructions may initially be carried on a disk of a remote computer (not shown). The remote computer is able to load the instructions into its dynamic memory and transmit the instructions via an Ethernet connection, cable, or even a telephone line using a modem. Local communication devices of computing device 500 (e.g., a server) are able to receive data on a corresponding communication line and place the data on the processor's system bus. The system bus transmits the data to main memory, from which the processor retrieves and executes the instructions. Instructions received from main memory may optionally be stored in memory before or after being executed by the processor. Alternatively, instructions may be received as electrical, electromagnetic, or optical signals via communication ports, which are exemplary forms of wireless communication or data streams carrying various types of information.

[0056] In the implementation shown in the figures, it will be apparent that aspects of the systems and methods described herein can be implemented in many different forms of software, firmware and hardware.The actual software code or dedicated control hardware used to implement aspects consistent with the principles of the systems and methods described herein is not limiting. Therefore, the operation and behavior of the various aspects of the systems and methods are described without reference to specific software code – it should be understood that those skilled in the art will be able to design software and control hardware to implement the aspects based on the descriptions herein.

[0057] Various aspects of the subject matter described in this specification can be implemented in a computing system, which includes back-end components, such as a data server, or middleware components, such as an application server, or front-end components, such as a client computer with a graphical user interface or a web browser, through which a user can interact with the subject matter described in this specification, or any combination of one or more such back-end components, middleware components, or front-end components. The components of the system can be interconnected via digital data communication in any form or medium, such as a communication network. The communication network can include, for example, a Personal Area Network (PAN), a Local Area Network (LAN), a Campus Network (CAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Broadband Network (BBN), the Internet, etc. Furthermore, the communication network can include, but is not limited to, any or more of the following network topologies, including bus networks, star networks, ring networks, mesh networks, star-bus networks, tree or hierarchical networks, etc. The communication module can be, for example, a modem or an Ethernet card.

[0058] As described above, the computing system 500 can include a client and a server. The client and server are typically geographically separated and typically interact via a communication network. The client-server relationship arises from computer programs running on their respective computers and having a client-server relationship with each other. The computer system 500 can be, for example, but not limited to, an enterprise server or server group, one or more desktop computers, one or more laptop computers, etc. The computer system 500 can also be embedded in another device, for example, but not limited to, a mobile phone, a personal digital assistant (PDA), a mobile audio player, a global positioning system (GPS) receiver, a video game console, and / or a set-top box.

[0059] Although this specification contains many specific details, these should not be construed as limiting the scope that can be claimed, but rather as descriptions of specific implementations of the subject matter. Some features described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation can also be implemented separately or in any suitable sub-combination in multiple implementations.Furthermore, although the features may be described above as functioning in certain combinations and even originally claimed in this manner, one or more features from the claimed combination may be removed from that combination in some cases, and the claimed combination may involve sub-combinations or variations thereof.

[0060] Although operations are described in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in the specific order shown or sequentially, or to perform all the operations shown to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of the various system components in the foregoing aspects should not be construed as requiring such separation in all aspects, and it should be understood that the described program components and systems can generally be integrated together in a single service provision or packaged into multiple service provisions.< / iframe>

Claims

1. A method comprising: The application server, which hosts multiple applications, receives a first request from a user device to create a data file to be stored on a third-party storage server. In response to receiving the first request, the application server sends a second request to the third-party storage server, the second request indicating that the data file be created on the third-party storage server; Receive an indication from the third-party storage server that the data file has been created on the third-party storage server; In response to receiving the indication that the data file has been created on the third-party storage server, the application server generates an instance of the data file stored on the application server; as well as The application server provides the instance of the data file to the user device for editing by related applications within the plurality of applications hosted by the application server.

2. The method according to claim 1, further comprising: The application server uploads the latest version of the data file stored on the application server to the third-party storage server.

3. The method according to claim 2, wherein, The application server periodically uploads the latest version of the data file stored on the application server to the third-party storage server via an application programming interface (API) operating according to the Hypertext Transfer Protocol (HTTP).

4. The method according to any one of claims 1 to 3, wherein, The first request includes a Hypertext Transfer Protocol (HTTP) message generated on the user device within a display area of ​​a browser-based application, the display area being defined by structural tags associated with the browser-based application.

5. The method according to any one of claims 1 to 3, wherein, The first request includes an access token issued by the third-party storage server for the user device, the access token authorizing the user device to access the data file.

6. The method according to any one of claims 1 to 3, wherein, The second request includes a file identifier, a file name, and an indication that the data file does not exist on the application server.

7. The method according to any one of claims 1 to 3, wherein, Receiving the indication that the data file has been created on the third-party storage server includes receiving metadata associated with the data file created on the third-party storage server.

8. A system: Memory; and A processor communicatively coupled to the memory, wherein the processor executes instructions stored in the memory to cause the system to perform the method according to any one of claims 1 to 7.

9. A non-transitory computer-readable storage medium comprising instructions that, in response to execution by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images