A cross-device data operation method and system

Abstract

The application provides a cross-device data operation method and system, and relates to the technical field of computers. The method can include: a first device determining path information of to-be-uploaded data in response to acquired first instructions, the to-be-uploaded data being located in a second device; and the first device sending a first message to the second device, the first message including the path information, and the first message being used to instruct the second device to upload the to-be-uploaded data to a server. In this way, the first device can send a message indicating uploading data to the second device after acquiring the first instructions, so that the second device can upload data thereon to the server, so that the second device can directly communicate with the server under the control of the first device, thereby shortening the data uploading path, reducing the delay, and improving the user experience.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and system for cross-device data operation. Background Technology

[0002] With the rapid development of computer technology, the amount of data involved in people's lives and work has exploded, leading to a significant increase in storage demand and consequently, the rapid development of cloud storage services. Cloud storage services refer to services that provide users with cloud-based file storage, i.e., services that provide cloud storage services. Users can upload files from their devices to servers for storage using cloud storage clients (such as cloud drives or cloud storage clients), and can also manage files on the server by browsing, updating, and downloading them.

[0003] Currently, when users utilize cloud storage services, in addition to operating on files on their local machine (such as uploading files to the server or downloading files stored on the server to their local machine), they sometimes also manage files on other devices accessible to their local machine. For example, users can manage files on other devices shared within the local area network, and choose to upload files from other devices to the server for storage, or download files stored on the server to other devices accessible to their local machine for storage. However, currently, when operating cloud storage files across devices, issues often arise regarding the transfer of files between cloud storage devices, resulting in a poor user experience. Summary of the Invention

[0004] This application provides a cross-device data operation method, system, electronic device, computer storage medium, and computer program product that can avoid the problem of cloud storage file transfer when operating cloud storage files across devices and improve the user experience.

[0005] Firstly, this application provides a cross-device data operation method applied to a first device, which can remotely access shared data on a second device. The method includes: the first device, in response to a received first instruction, determining path information for data to be uploaded, wherein the data is located on the second device; and the first device sending a first message to the second device, the first message including the path information, which instructs the second device to upload the data to a server. Thus, after receiving the first instruction, the first device can send a message instructing the second device to upload data, allowing the second device to upload its data to the server. This enables the second device to communicate directly with the server under the control of the first device, thereby shortening the data upload path, reducing latency, and providing an operation experience consistent with local file uploads, thus improving the user experience.

[0006] In one possible implementation, the first message also includes identification information for the data to be uploaded. This allows the second device to determine the data to be uploaded from its data based on the identification information.

[0007] In one possible implementation, the first message also includes session credential information, which is an authentication credential between the first and second devices. This allows the second device to determine whether the two devices have been pre-authenticated, preventing data operations from being performed without authentication and thus improving the security of data operations.

[0008] In one possible implementation, before the first device sends the first message to the second device, the method further includes: the first device determining the association between a first account on the first device and a second account on the second device; the first device generating session credential information; or, the first device obtaining session credential information sent by the second device, wherein the session credential information is generated by the second device after determining the association between the first and second accounts. Thus, by determining the association between the accounts on the two devices before generating session credential information, authentication between the two devices is completed. For example, determining the association between the two accounts can be determining whether the two accounts are the same account. For example, the first account can be a device-level account, such as the account used to log in to the first device, or an application-level account, such as the account used to log in to one or more applications on the first device. For example, the second account can be a device-level account, such as the account used to log in to the second device, or an application-level account, such as the account used to log in to one or more applications on the second device.

[0009] In one possible implementation, before the first device generates session credential information, the method further includes: the first device determining the association between a first version corresponding to a first account and a second version corresponding to a second account. For example, when the first account is a device-level account, the first version corresponding to the first account can be the operating system version of the first device; when the second account is a device-level account, the second version corresponding to the second account can be the operating system version of the second device. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0010] In one possible implementation, before the first device sends the first message to the second device, the method further includes: the first device sending a first request to the server, the first request being used to request the upload of data to be uploaded; the first device obtaining upload authentication information sent by the server, the upload authentication information being generated by the server after obtaining the first request, and the upload authentication information being used by the server to verify the data to be uploaded after receiving the data to be uploaded sent by the second device. In this way, the first device and the second device can interact with each other without authentication. Afterwards, after receiving the data uploaded by the second device, the server can verify the data and determine whether to allow the second device to upload the data, thus improving the security and convenience of the operation.

[0011] In one possible implementation, the first message also includes uploaded authentication information. This allows the second device to send this uploaded authentication information to the server simultaneously when sending data, enabling the server to verify the data uploaded by the second device.

[0012] In one possible implementation, before the first device sends the first message to the second device, the method further includes: the first device determining the association between a first version corresponding to a first account on the first device and a second version corresponding to a second account on the second device. This allows the first and second devices to complete a pre-negotiation session, facilitating subsequent data operations. For example, when the first account is a device-level account, the first version corresponding to the first account can be the operating system version of the first device; when the second account is a device-level account, the second version corresponding to the second account can be the operating system version of the second device. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0013] In one possible implementation, the data to be uploaded includes one or more files.

[0014] In one possible implementation, a first client is configured on the first device, logged into a first account, and a second client is configured on the second device, logged into a second account. Signaling interactions between the first and second devices are performed by both clients. Thus, by deploying a client on the remote device for proxying file uploads, the client on the local machine (the first client) can remotely instruct the client on the remote device (the second client) to perform upload operations. This allows the client on the remote device to communicate directly with the server, shortening the file upload path on the remote device, reducing latency, and providing a user experience consistent with local file uploads. Since the remote device performs the upload operations itself, it fully utilizes its bandwidth and online availability. Furthermore, the remote device's upload operations do not consume local mobile network bandwidth or central processing unit (CPU) resources, reducing local resource consumption.

[0015] Secondly, this application provides a cross-device data operation method applied to a second device. The second device has shared data, which can be remotely accessed by a first device. The method includes: the second device receiving a first message sent by the first device, the first message including path information of data to be uploaded, the data to be uploaded being located on the second device, the first message instructing the second device to upload the data to a server; the second device determining the data to be uploaded based on the path information; and the second device sending the data to be uploaded to the server. In this way, after receiving the first instruction, the first device can send a message instructing the second device to upload data, thereby enabling the second device to upload its data to the server. This allows the second device to communicate directly with the server under the control of the first device, thus shortening the data upload path, reducing latency, and providing an operation experience consistent with local file uploads, thereby improving the user experience.

[0016] In one possible implementation, the first message also includes identification information of the data to be uploaded; the second device determines the data to be uploaded based on the path information, specifically including: the second device determines the data to be uploaded based on the identification information and the path information. Thus, the second device can determine the data to be uploaded from the data on it based on the identification information and the path information.

[0017] In one possible implementation, the first message also includes session credential information, which is an authentication credential between the first and second devices. This allows the second device to determine whether the two devices have been pre-authenticated, preventing data operations from being performed without authentication and thus improving the security of data operations.

[0018] In one possible implementation, before the second device receives the first message sent by the first device, the method further includes: the second device determining the association between a first account on the first device and a second account on the second device; the second device generating session credential information and sending the session credential information to the first device. Thus, by determining the association between the accounts on the two devices before generating the session credential information, authentication between the two devices is completed. For example, determining the association between the two accounts can mean determining whether the two accounts are the same account. For example, the first account can be a device-level account, such as the account used to log in to the first device, or an application-level account, such as the account used to log in to one or more applications on the first device. For example, the second account can be a device-level account, such as the account used to log in to the second device, or an application-level account, such as the account used to log in to one or more applications on the second device.

[0019] In one possible implementation, before the second device generates session credential information, the method further includes: the second device determining the association between a first version corresponding to the first account and a second version corresponding to the second account. For example, when the first account is a device-level account, the first version corresponding to the first account can be the operating system version of the first device; when the second account is a device-level account, the second version corresponding to the second account can be the operating system version of the second device. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0020] In one possible implementation, the first message further includes upload authentication information, which is generated by the server after receiving a first request from the first device. The first request is used to request the upload of data to be uploaded. The method also includes: the second device sending the upload authentication information to the server, which is used by the server to verify the data to be uploaded. This allows the second device to send the upload authentication information to the server simultaneously when sending data, enabling the server to verify the data uploaded by the second device.

[0021] In one possible implementation, before the second device receives the first message sent by the first device, the method further includes: the second device determining the association between a first version corresponding to a first account on the first device and a second version corresponding to a second account on the second device. This allows the first and second devices to complete a pre-negotiation session, facilitating subsequent data operations. For example, when the first account is a device-level account, the first version corresponding to the first account can be the operating system version of the first device; when the second account is a device-level account, the second version corresponding to the second account can be the operating system version of the second device. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0022] In one possible implementation, the data to be uploaded includes one or more files.

[0023] In one possible implementation, a first client is configured on the first device, logged into a first account, and a second client is configured on the second device, logged into a second account. Signaling interactions between the first and second devices are performed by both clients. Thus, by deploying a client on the remote device for proxying file uploads, the client on the local machine (the first client) can remotely instruct the client on the remote device (the second client) to perform upload operations. This allows the client on the remote device to communicate directly with the server, shortening the file upload path on the remote device, reducing latency, and providing a user experience consistent with local file uploads. Since the remote device performs the upload operations itself, it fully utilizes its bandwidth and online availability. Furthermore, the remote device's upload operations do not consume local mobile network bandwidth or central processing unit (CPU) resources, reducing local resource consumption.

[0024] Thirdly, this application provides a cross-device data operation method applied to a first device, which can remotely access shared data on a second device. The method includes: the first device, in response to a received second instruction, determining target information of the data to be downloaded, the target information including identification information and / or download path information, wherein the storage path represented by the download path information is located in the second device; the first device sending a second message to the second device, the second message including the target information, the second message being used to instruct the second device to download the data to be downloaded from the server. Thus, after receiving the second instruction, the first device can send a message instructing the second device to download data, thereby enabling the second device to request data from the server, receive the data sent by the server, and store the data. This allows the second device to communicate directly with the server under the control of the first device, thereby shortening the data download path, reducing latency, and providing an operation experience consistent with local file downloads, thus improving the user experience.

[0025] In one possible implementation, the second message also includes session credential information, which is an authentication credential between the first and second devices. This allows the second device to determine whether the two devices have been pre-authenticated, preventing data operations from being performed without authentication and thus improving the security of data operations.

[0026] In one possible implementation, before the first device sends the second message to the second device, the method further includes: the first device determining the association between a first account on the first device and a second account on the second device; the first device generating session credential information; or, the first device obtaining session credential information sent by the second device, wherein the session credential information is generated by the second device after determining the association between the first and second accounts. Thus, by determining the association between the accounts on the two devices before generating session credential information, authentication between the two devices is completed. For example, determining the association between the two accounts can be determining whether the two accounts are the same account. For example, the first account can be a device-level account, such as the account used to log in to the first device, or an application-level account, such as the account used to log in to one or more applications on the first device. For example, the second account can be a device-level account, such as the account used to log in to the second device, or an application-level account, such as the account used to log in to one or more applications on the second device.

[0027] In one possible implementation, before the first device generates session credential information, the method further includes: the first device determining the association between a first version corresponding to a first account and a second version corresponding to a second account. For example, when the first account is a device-level account, the first version corresponding to the first account can be the operating system version of the first device; when the second account is a device-level account, the second version corresponding to the second account can be the operating system version of the second device. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0028] In one possible implementation, before the first device sends a second message to the second device, the method further includes: the first device sending a second request to the server, the second request being for requesting the download of data to be downloaded; the first device obtaining download authentication information sent by the server, the download authentication information being generated by the server after obtaining the second request, the download authentication information being used by the server to verify a third request sent by the second device, the third request being for requesting the download of data to be downloaded, the third request including the download authentication information. In this way, the first and second devices can interact with data without authentication. Afterwards, upon receiving the data download request from the second device, the server can verify the request and determine whether to allow the second device to download data, thus improving the security and convenience of the operation.

[0029] In one possible implementation, the second message also includes download authentication information. This allows the second device to send the download authentication information to the server simultaneously when sending a data download request, enabling the server to verify the data download request sent by the second device.

[0030] In one possible implementation, before the first device sends the second message to the second device, the method further includes: the first device determining the association between a first version corresponding to a first account on the first device and a second version corresponding to a second account on the second device. This allows the first and second devices to complete a pre-negotiation session, facilitating subsequent data operations. For example, when the first account is a device-level account, the first version corresponding to the first account can be the operating system version of the first device; when the second account is a device-level account, the second version corresponding to the second account can be the operating system version of the second device. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0031] In one possible implementation, the data to be downloaded includes one or more files.

[0032] In one possible implementation, a first client is configured on the first device, logged into a first account, and a second client is configured on the second device, logged into a second account. Signaling interactions between the first and second devices are performed by both clients. Thus, by deploying a client on the remote device sharing files to proxy file downloads, the client on the local machine (i.e., the first client) can remotely instruct the client on the remote device (i.e., the second client) to perform download operations. The client on the remote device can also communicate directly with the server, thereby shortening the file download path on the remote device, reducing latency, and providing an experience consistent with local file downloads. Since the remote device performs the download operations itself, it can fully utilize its bandwidth and online advantages. Furthermore, when the remote device performs download operations, it does not consume the local machine's mobile network bandwidth or central processing unit (CPU) system resources, reducing local resource consumption.

[0033] Fourthly, this application provides a cross-device data operation method applied to a second device. The second device has shared data, which can be remotely accessed by a first device. The method includes: the second device acquiring a second message sent by the first device, the second message including target information, including identification information and / or download path information, the storage path represented by the download path information being located in the second device, the second message instructing the second device to download data to be downloaded from a server; the second device, in response to the acquired second message, sending a third request to the server, the third request requesting the acquisition of the data to be downloaded; the second device acquiring the data to be downloaded sent by the server, and storing the data to be downloaded in the storage path represented by the download path information. Thus, after acquiring the second instruction, the first device can send a message instructing the second device to download data, thereby enabling the second device to request data from the server, receive the data sent by the server, and store the data. This allows the second device to communicate directly with the server under the control of the first device, thereby shortening the data download path, reducing latency, and providing an operation experience consistent with local file downloads, thus improving the user experience.

[0034] In one possible implementation, the second message also includes session credential information, which is an authentication credential between the first and second devices. This allows the second device to determine whether prior authentication has been performed, preventing data operations from being performed without authentication and thus improving the security of data operations.

[0035] In one possible implementation, before the second device receives the second message sent by the first device, the method further includes: the second device determining the association between a first account on the first device and a second account on the second device; the second device generating session credential information and sending the session credential information to the first device. Thus, by determining the association between the accounts on the two devices before generating the session credential information, authentication between the two devices is completed. For example, determining the association between the two accounts can mean determining whether the two accounts are the same account. For example, the first account can be a device-level account, such as the account used to log in to the first device, or an application-level account, such as the account used to log in to one or more applications on the first device. For example, the second account can be a device-level account, such as the account used to log in to the second device, or an application-level account, such as the account used to log in to one or more applications on the second device.

[0036] In one possible implementation, before the second device generates session credential information, the method further includes: the second device determining the association between a first version corresponding to the first account and a second version corresponding to the second account. For example, when the first account is a device-level account, the first version corresponding to the first account can be the operating system version of the first device; when the second account is a device-level account, the second version corresponding to the second account can be the operating system version of the second device. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0037] In one possible implementation, the second message also includes download authentication information. This download authentication information is generated by the server after receiving the second request. The server uses this information to verify a third request sent by the second device, where the third request includes the download authentication information. This allows the second device to send the download authentication information to the server simultaneously when sending a data download request, enabling the server to verify the data download request sent by the second device.

[0038] In one possible implementation, before the second device receives the second message sent by the first device, the method further includes: the second device determining the association between a first version corresponding to a first account on the first device and a second version corresponding to a second account on the second device. This allows the first and second devices to complete a pre-negotiation session, facilitating subsequent data operations. For example, when the first account is a device-level account, the first version corresponding to the first account can be the operating system version of the first device; when the second account is a device-level account, the second version corresponding to the second account can be the operating system version of the second device. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0039] In one possible implementation, the data to be uploaded includes one or more files.

[0040] In one possible implementation, a first client is configured on the first device, logged into a first account, and a second client is configured on the second device, logged into a second account. Signaling interactions between the first and second devices are performed by both clients. Thus, by deploying a client on the remote device sharing files to proxy file downloads, the client on the local machine (i.e., the first client) can remotely instruct the client on the remote device (i.e., the second client) to perform download operations. The client on the remote device can also communicate directly with the server, thereby shortening the file download path on the remote device, reducing latency, and providing an experience consistent with local file downloads. Since the remote device performs the download operations itself, it can fully utilize its bandwidth and online advantages. Furthermore, when the remote device performs download operations, it does not consume the local machine's mobile network bandwidth or central processing unit (CPU) system resources, reducing local resource consumption.

[0041] Fifthly, this application provides a cross-device data operating system, including: a first device, a second device, and a server, wherein the first device can remotely access shared data on the second device;

[0042] The first device is used to respond to the received first instruction to determine the path information of the data to be uploaded, wherein the data to be uploaded is located in the second device; and to send a first message to the second device, the first message including the path information, the first message being used to instruct the second device to upload the data to be uploaded to the server;

[0043] The second device is used to obtain the first message sent by the first device, and to determine the data to be uploaded based on the path information, and send the data to be uploaded to the server.

[0044] The server is used at least to store the data to be uploaded sent by the second device.

[0045] In one possible implementation, the first message also includes identification information for the data to be uploaded.

[0046] In one possible implementation, the first message also includes session credential information, which is an authenticated credential between the first device and the second device.

[0047] In one possible implementation, the first device is further configured to determine the association between a first account on the first device and a second account on the second device before sending the first message to the second device; and to generate session credential information.

[0048] Furthermore, before generating session credential information, the first device is also used to: determine the association between the first version corresponding to the first account and the second version corresponding to the second account.

[0049] In one possible implementation, the second device is also used to determine the association between the first account on the first device and the second account on the second device before obtaining the first message, and to generate session credential information and send the session credential information to the first device.

[0050] The first device is also used to obtain session credential information sent by the second device before sending the first message to the second device.

[0051] Furthermore, before generating session credential information, the second device is also used to: determine the association between the first version corresponding to the first account and the second version corresponding to the second account.

[0052] In one possible implementation, before sending the first message to the second device, the first device is further configured to: send a first request to the server, the first request being used to request the upload of data to be uploaded;

[0053] The server is also used to respond to the first request received, generate upload authentication information, and send the upload authentication information to the first device;

[0054] The first device is also used to obtain upload authentication information sent by the server. The upload authentication information is used by the server to verify the data to be uploaded after obtaining the data to be uploaded sent by the second device.

[0055] Furthermore, the first message also includes uploading authentication information.

[0056] In one possible implementation, before sending the first message to the second device, the first device is further configured to: determine the association between the first version corresponding to the first account on the first device and the second version corresponding to the second account on the second device.

[0057] In one possible implementation, the data to be uploaded includes one or more files.

[0058] In one possible implementation, a first client is configured on the first device, and a first account is logged in on the first client. A second client is configured on the second device, and a second account is logged in on the second client. The signaling interaction between the first device and the second device is performed by the first client and the second client, and the signaling interaction between the second device and the server is performed by the second client and the server.

[0059] The fifth aspect and any implementation thereof correspond to the first aspect and any implementation thereof, and the second aspect and any implementation thereof, respectively. The technical effects corresponding to the fifth aspect and any implementation thereof can be found in the technical effects corresponding to the first aspect and any implementation thereof, and the second aspect and any implementation thereof, and will not be repeated here.

[0060] Sixthly, this application provides a cross-device data operating system, including: a first device, a second device, and a server, wherein the first device can remotely access shared data on the second device;

[0061] The first device is configured to, in response to the acquired second instruction, determine the target information of the data to be downloaded, the target information including identification information and / or download path information, the storage path represented by the download path information being located in the second device; and send a second message to the second device, the second message including the target information, the second message being used to instruct the second device to download the data to be downloaded from the server;

[0062] The second device is used to obtain the second message sent by the first device, and in response to the obtained second message, to send a third request to the server. The third request is used to request the data to be downloaded.

[0063] The server is used to obtain the third request sent by the second device, and in response to the third request, determine the data to be downloaded and send the data to be downloaded to the second device;

[0064] The second device is also used to acquire the data to be downloaded sent by the server, and to store the data to be downloaded in the storage path represented by the download path information.

[0065] In one possible implementation, the second message also includes session credential information, which is a credential that has been authenticated between the first device and the second device.

[0066] In one possible implementation, the first device is further configured to determine the association between a first account on the first device and a second account on the second device before sending a second message to the second device; and to generate session credential information.

[0067] Furthermore, before generating session credential information, the first device is also used to: determine the association between the first version corresponding to the first account and the second version corresponding to the second account.

[0068] In one possible implementation, the second device is also used to determine the association between the first account on the first device and the second account on the second device before obtaining the second message, and to generate session credential information and send the session credential information to the first device.

[0069] The first device is also used to obtain session credential information sent by the second device before sending the second message to the second device.

[0070] Furthermore, before generating session credential information, the second device is also used to: determine the association between the first version corresponding to the first account and the second version corresponding to the second account.

[0071] In one possible implementation, before sending the second message to the second device, the first device is further configured to: send a second request to the server, the second request being used to request the download of data to be downloaded;

[0072] The server is also used to respond to the obtained second request, generate download authentication information, and send the download authentication information to the first device;

[0073] The first device is also used to obtain download authentication information sent by the server. The download authentication information is used by the server to verify the third request sent by the second device. The third request is used to request the data to be downloaded, and the third request includes the download authentication information.

[0074] Furthermore, the second message also includes download authentication information.

[0075] Furthermore, before sending the data to be downloaded to the second device, the server also verifies the download authentication information and confirms that the verification has passed.

[0076] In one possible implementation, before sending the second message to the second device, the first device is further configured to: determine the association between the first version corresponding to the first account on the first device and the second version corresponding to the second account on the second device.

[0077] In one possible implementation, the data to be downloaded includes one or more files.

[0078] In one possible implementation, a first client is configured on the first device, and a first account is logged in on the first client. A second client is configured on the second device, and a second account is logged in on the second client. The signaling interaction between the first device and the second device is performed by the first client and the second client, and the signaling interaction between the second device and the server is performed by the second client and the server.

[0079] The sixth aspect and any implementation thereof correspond to the third aspect and any implementation thereof, and the fourth aspect and any implementation thereof, respectively. The technical effects corresponding to the sixth aspect and any implementation thereof can be found in the technical effects corresponding to the third aspect and any implementation thereof, and the fourth aspect and any implementation thereof, and will not be repeated here.

[0080] In a seventh aspect, this application provides an electronic device, comprising: at least one memory for storing a program; and at least one processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to execute the methods provided in the first, second, third, or fourth aspects.

[0081] The seventh aspect and any implementation thereof correspond to the first aspect and any implementation thereof, the second aspect and any implementation thereof, the third aspect and any implementation thereof, and the fourth aspect and any implementation thereof, respectively. The technical effects corresponding to the seventh aspect and any implementation thereof can be found in the technical effects corresponding to the first aspect and any implementation thereof, the second aspect and any implementation thereof, the third aspect and any implementation thereof, and the fourth aspect and any implementation thereof, and will not be repeated here.

[0082] Eighthly, this application provides a computer-readable storage medium storing a computer program that, when run on an electronic device, causes the electronic device to perform the methods provided in the first, second, third, or fourth aspects.

[0083] The eighth aspect and any implementation thereof correspond to the first aspect and any implementation thereof, the second aspect and any implementation thereof, the third aspect and any implementation thereof, and the fourth aspect and any implementation thereof, respectively. The technical effects corresponding to the eighth aspect and any implementation thereof can be found in the technical effects corresponding to the first aspect and any implementation thereof, the second aspect and any implementation thereof, the third aspect and any implementation thereof, and the fourth aspect and any implementation thereof, and will not be repeated here.

[0084] Ninthly, this application provides a computer program product, characterized in that, when the computer program product is run on an electronic device, it causes the electronic device to perform the methods provided in the first, second, third, or fourth aspects.

[0085] The ninth aspect and any implementation thereof correspond to the first aspect and any implementation thereof, the second aspect and any implementation thereof, the third aspect and any implementation thereof, and the fourth aspect and any implementation thereof, respectively. The technical effects corresponding to the ninth aspect and any implementation thereof can be found in the technical effects corresponding to the first aspect and any implementation thereof, the second aspect and any implementation thereof, the third aspect and any implementation thereof, and the fourth aspect and any implementation thereof, and will not be repeated here. Attached Figure Description

[0086] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application;

[0087] Figure 2a This is a schematic diagram of an application scenario provided by an embodiment of this application;

[0088] Figure 2b This is a schematic diagram of an application scenario provided by an embodiment of this application;

[0089] Figure 3 This is a schematic diagram of a system architecture for a cloud storage file cross-device collaborative operating system provided in an embodiment of this application;

[0090] Figure 4 This is a schematic diagram of the structure of a user equipment provided in an embodiment of this application;

[0091] Figure 5 This is a schematic diagram of the structure of a shared device provided in an embodiment of this application;

[0092] Figure 6 This is a schematic diagram of the structure of a cloud storage server provided in an embodiment of this application;

[0093] Figure 7 This is a flowchart illustrating a cloud storage file upload method provided in an embodiment of this application;

[0094] Figure 8 This is a flowchart illustrating a cloud storage file download method provided in an embodiment of this application;

[0095] Figure 9 This is a communication diagram illustrating collaborative device discovery and authentication provided in an embodiment of this application;

[0096] Figure 10 This is a communication diagram illustrating a collaborative file upload process for cloud storage provided in an embodiment of this application;

[0097] Figure 11a This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0098] Figure 11b This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0099] Figure 11c This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0100] Figure 11d This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0101] Figure 11e This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0102] Figure 12 This is a communication diagram illustrating a collaborative file download process using cloud storage, provided in an embodiment of this application.

[0103] Figure 13a This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0104] Figure 13b This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0105] Figure 13c This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0106] Figure 13d This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0107] Figure 13e This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0108] Figure 13f This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0109] Figure 14 This is a communication diagram illustrating other operations during collaborative file upload in cloud storage, provided in an embodiment of this application.

[0110] Figure 15a This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0111] Figure 15b This is a schematic diagram of a display interface of a user device provided in an embodiment of this application;

[0112] Figure 16 This is a communication diagram illustrating another cloud storage file collaborative upload process provided in an embodiment of this application;

[0113] Figure 17 This is a communication diagram illustrating another cloud storage file collaborative download process provided in an embodiment of this application;

[0114] Figure 18 This is a flowchart illustrating a cross-device data operation method provided in an embodiment of this application;

[0115] Figure 19 This is a flowchart illustrating another cross-device data operation method provided in an embodiment of this application. Detailed Implementation

[0116] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings.

[0117] The terminology used in the following embodiments is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to also include expressions such as “one or more,” unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, “at least one” and “one or more” refer to one or more (including two). The term “and / or” is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can indicate: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character “ / ” generally indicates that the preceding and following related objects are in an “or” relationship.

[0118] References to "one embodiment" or "some embodiments" as used in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes both direct and indirect connections, unless otherwise stated.

[0119] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0120] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0121] Generally, such as Figure 1As shown, when a user manages files on other devices 12 accessible from their local machine (i.e., user device 11), the user typically needs to operate the cloud storage client 111 on their local machine (i.e., user device 11). Within the cloud storage client 111, the user accesses the shared file system 121 on other devices via the file system 112, and then selects shared files on other devices 12 to upload to the cloud storage server 13, or downloads files stored on the cloud storage server 13 to a specified shared directory on other devices 12. During this process, when the user uploads files from other devices 12 to the cloud storage server 13 via the cloud storage client 111 on their local machine (i.e., user device 11), the cloud storage client 111 on the local machine (i.e., user device 11) often needs to first read the files from other devices 12 onto the local machine via the shared network before uploading them to the cloud storage server 13. Similarly, when a user downloads a file stored on cloud storage server 13 to another device 12 using cloud storage client 111, cloud storage client 111 needs to first download the file stored on cloud storage server 13 to its local machine, and then write it to the other device 12 via the shared network. It is evident that in this process, both the uploaded and downloaded file streams need to pass through the user's local machine and require two cross-network connections. This results in longer upload and download paths, significant consumption of local bandwidth, increased local latency, and a poor performance experience.

[0122] To avoid file transfer issues when operating cloud storage files across devices, users can access cloud storage clients on other devices via a browser or remote desktop on their local machine. They can then use these clients to select files on other devices and upload them to the cloud storage server, or download files to a specified file system directory on those other devices. For example,... Figure 2a As shown, a user can log in to the web version of the cloud storage client 221 on another device 22 via a browser on user device 21 (i.e., the local machine). Then, through the cloud storage client 221 on the other device 22, the user can select files from the file system 222 on the other device 22 and upload them to the cloud storage server 23, or download cloud storage files from the cloud storage client 221 on the other device 22 to a specified file system directory on the other device 22. For example, as... Figure 2bAs shown, a user can log in to a cloud storage client 221 on another device 22 via remote desktop from user device 21 (i.e., the local machine). Then, through the cloud storage client 221 on the other device 22, the user can select files from the file system 222 on the other device 22 and upload them to the cloud storage server 23, or download cloud storage files from the cloud storage client 221 on the other device 22 to a specified file system directory on the other device 22. While this method solves the problem of cloud storage file transfer during cross-device operations, the significant latency of web-based cloud storage clients and remote desktop operations across networks results in a poor user experience. Furthermore, the user's operations on files on the local machine and on remote files are disconnected, requiring switching between different clients, leading to a poor user experience.

[0123] Furthermore, to avoid file transfer issues when operating cloud storage files across devices and to improve the user experience, this application also provides a solution. This solution establishes a cross-device trust channel between the cloud storage client on the local machine and cloud storage clients on other devices. Through this trust channel, the cloud storage client on the local machine can negotiate with cloud storage clients on other devices regarding files that need to be uploaded or downloaded, and then the cloud storage clients on other devices will perform the file upload or download. This shortens the path for uploading or downloading files across devices, reduces latency, and ensures that the user experience of uploading or downloading files on other devices via the cloud storage client on the local machine is consistent with the user experience of uploading or downloading files on the local machine.

[0124] For example, Figure 3 A schematic diagram of a system architecture for a cloud storage file cross-device collaborative operating system is shown. For example... Figure 3As shown, the system includes: user equipment 31, sharing device 32, and server 33. User equipment 31 and sharing device 32 may or may not be on the same local area network (LAN). In this solution, user equipment 31 and server 33 can establish a connection via a wired or wireless network for data exchange. Similarly, sharing device 32 and server 33 can also establish a connection via a wired or wireless network for data exchange. Furthermore, user equipment 31 and sharing device 32 can also interact via short-range wireless communication technologies, such as Bluetooth. For example, the network involved in this solution can be a local area network (LAN) or a wide area network (WAN) (e.g., the Internet), and is not limited thereto.

[0125] User device 31 can be understood as a device near the user, i.e., a device that the user can operate at close range. Shared device 32 can be understood as a device that user device 31 can access remotely. For example, both user device 31 and shared device 32 can be, but are not limited to, mobile phones, tablets, wearable devices, smart TVs, Huawei smart screens, smart speakers, in-vehicle systems, etc. Furthermore, shared device 32 can also be a storage device, such as a network attached storage (NAS) device. Exemplary embodiments of user device 31 and shared device 32 include, but are not limited to, electronic devices running iOS, Android, Windows, Harmony OS, or other operating systems. This application does not specifically limit the type of electronic device.

[0126] Server 33 can be a server or a super terminal that can establish communication connections with electronic devices such as user device 31 and shared device 32, and provide data processing, computing, and / or storage functions for these devices. Server 33 can be a hardware server or embedded in a virtualization environment; for example, server 33 can be a virtual machine running on a hardware server that includes one or more other virtual machines. For instance, server 33 can be a cloud server.

[0127] In some embodiments, the user equipment 31 may be configured with a cloud storage client 311 and a file system 312, and the sharing device 32 may be configured with a cloud storage client 321 and a shared file system 322.

[0128] Both cloud storage client 311 and cloud storage client 321 can be clients used to manage cloud storage files.

[0129] The file system 312 refers to the system that organizes and allocates the space of the file storage device on the user device 31, and is responsible for file storage, protection, and retrieval of stored files. Specifically, it is responsible for creating files for users, storing, reading, modifying, and dumping files, controlling file access, and deleting files when the user no longer needs them.

[0130] The shared file system 322 refers to the system that organizes and allocates space on the file storage device on the shared device 32, and is responsible for file storage, protection, and retrieval of stored files. Specifically, it is responsible for creating files for users, storing, reading, modifying, and dumping files, controlling file access, and deleting files when users no longer need them. User device 31 can access the shared file system 322 on the shared device 32 through its file system 312.

[0131] In some embodiments, continue reading Figure 3 The cloud storage client 311 can be configured with a management module 3111, a collaborative session module 3112, and an upload / download module 3113. The cloud storage client 321 can also be configured with a collaborative session module 3211 and an upload / download module 3212. In one example, the cloud storage client 311 can use the socket in the user device 31 to establish network connections with the socket in the shared device 32 and the socket in the cloud storage server 33, respectively. The cloud storage client 321 can use the socket in the shared device 32 to establish network connections with the socket in the user device 31 and the socket in the cloud storage server 33, respectively.

[0132] The management module 3111 in the cloud storage client 311 is responsible for the user interface (UI) and related logic processing of user operations on the cloud storage client 311. Furthermore, the management module 3111 can also have cross-device collaborative operation functions. For example, the management module 3111 can confirm whether the upload file source and download destination are shared device 32, thereby determining whether to initiate system session negotiation; or, after confirming that the upload file source and download destination are shared device 32, initiate system session negotiation; or, receive and display the transmission progress from the collaborative session module 3112; or, operate collaborative upload and download tasks to pause, cancel, etc.

[0133] The collaborative session module 3112 in the cloud storage client 311 is responsible for device discovery, device connection, device authentication, collaborative session negotiation, collaborative session requests, and control in cross-device collaboration. Specifically, this collaborative session module 3112 is mainly used for collaborative requests and control. For example, it can send collaborative requests and control commands to the collaborative session module 3211 in the cloud storage client 321.

[0134] The upload / download module 3113 in the cloud storage client 311 can handle the relevant logic processing for uploading and downloading files in cloud storage, so that the cloud storage client 311 can have the function of uploading and downloading files in cloud storage.

[0135] The collaborative session module 3211 in the cloud storage client 321 is responsible for device discovery, device connection, device authentication, collaborative session negotiation, and control in cross-device collaboration. Specifically, this collaborative session module 3211 is mainly used for collaborative response and instruction reception, and for operating the upload / download module 3212 to achieve collaborative upload and download of cloud storage files. For example, it responds to collaborative requests sent by the collaborative session module 3112 in the cloud storage client 311, receives control instructions sent by the collaborative session module 3112, and operates the upload / download module 3212 based on these control instructions.

[0136] The upload / download module 3212 in the cloud storage client 321 is responsible for the logic processing related to uploading and downloading files in cloud storage. Specifically, this upload / download module 3212 is mainly used to receive instructions from the collaborative session module 3211 to achieve collaborative file upload and download.

[0137] It is understood that the various modules in cloud storage client 311 or cloud storage client 321 can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, it can be implemented in whole or in part as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on user equipment 31, all or part of the process or function corresponding to cloud storage client 311 as described in the embodiments of this application is generated. When the computer program instructions are loaded and executed on shared device 32, all or part of the process or function corresponding to cloud storage client 321 as described in the embodiments of this application is generated. It should be noted that, in the embodiments of this application, the processes executed by each module in cloud storage client 311 can be understood as being executed by cloud storage client 311, or by user equipment 31 where cloud storage client 311 is located. The processes executed by each module in cloud storage client 321 can be understood as being executed by cloud storage client 321, or by shared device 32 where cloud storage client 321 is located. For example, both cloud storage client 311 and cloud storage client 321 can be applications, application plugins, mini-programs, etc.

[0138] For example, Figure 4 A schematic diagram of a user equipment structure is shown; wherein, the user equipment can be Figure 3 User equipment 31 is shown in the image. (Example) Figure 4 As shown, the user equipment may include a processor 401, a network interface 402, a memory 403, and a display screen 404. The processor 401, network interface 402, and memory 403 can be connected via a bus or other means. In this solution, the processor 401 (or central processing unit, CPU) is the computing and control core of the user equipment. In one example, the processor 401 can assist the cloud storage client 311 in uploading and downloading stored files, etc. The network interface 402 may optionally include a standard wired interface or a wireless interface (such as Wi-Fi, mobile communication interface, etc.), controlled by the processor 401 for sending and receiving data. In one example, the network interface 402 can assist the cloud storage client 311 in sending control commands to the sharing device 32, or assist the cloud storage client 311 in receiving feedback information from the sharing device 32, etc. The memory 403 is the user equipment's storage device, used to store programs and data, such as cloud storage files downloaded by the user equipment from the server 33. Display screen 404 can present the user interface of cloud storage client 311 on the user device to the user. In one example, display screen 404 can be a touch panel.

[0139] For example, Figure 5 A schematic diagram of a shared device is shown; wherein, the shared device can be Figure 3 Shared device 32 is shown in the image. (Example) Figure 5 As shown, the shared device may include a processor 501, a network interface 502, and a memory 503. The processor 501, network interface 502, and memory 503 can be connected via a bus or other means. In this solution, the processor 501 (or central processing unit, CPU) is the computing and control core of the shared device. In one example, the processor 501 can assist the cloud storage client 321 in uploading and downloading stored files, etc. The network interface 502 may optionally include a standard wired interface or a wireless interface (such as Wi-Fi, mobile communication interface, etc.), controlled by the processor 501 for sending and receiving data. In one example, the network interface 502 can assist the cloud storage client 321 in receiving control commands sent by the user device 31, or assist the cloud storage client 321 in sending feedback information to the user device 31, etc. The memory 503 is the shared device's storage device, used to store programs and data, such as cloud storage files downloaded by the shared device from the server 33.

[0140] For example, Figure 6 A schematic diagram of a server structure is shown; wherein, the server can be Figure 3 Server 33 is shown in the image. (For example...) Figure 6 As shown, the server includes a processor 601, a network interface 602, and a memory 603. The processor 601, network interface 602, and memory 603 can be connected via a bus or other means. In this solution, the processor 601 (or central processing unit, CPU) is the computing and control core of the server. For example, the processor 601 can delete or update files stored on the server based on instructions sent by the user device 31. The network interface 602 may optionally include a standard wired interface or a wireless interface (such as Wi-Fi, mobile communication interface, etc.), controlled by the processor 601 for sending and receiving data, such as receiving files uploaded by the user device 31 or the sharing device 32, or sending files requested by the user device 31 or the sharing device 32. The memory 603 is the server's storage device, used to store programs and data, such as files uploaded by the user device 31 or the sharing device 32.

[0141] The above is an introduction to the cloud storage file cross-device collaborative operating system involved in this solution. The following section, based on the cloud storage file cross-device collaborative operating system described above, combines... Figure 7 and 8 The cloud storage file operation method provided in the embodiments of this application is described.

[0142] For example, Figure 7 A flowchart illustrating a file upload method for cloud storage operations is shown. Figure 7 As shown, the method for uploading files to cloud storage may include the following steps:

[0143] Step 1: Cloud storage client 311 sends a file upload command to cloud storage client 321.

[0144] Users can select files to upload from the sharing system 322 of the sharing device 32 through the file system 312 of the user device 31 using the cloud storage client 311. After the user selects the files to be uploaded, the cloud storage client 311 sends a file upload command to the cloud storage client 321. This file upload command may include the path information of the file to be uploaded selected by the user and the metadata of the file to be uploaded (such as the file name, file type, or characteristic values ​​representing the content of the file, etc.).

[0145] Step 2: The cloud storage client 321 determines the file to be uploaded based on the file upload command.

[0146] After receiving the file upload instruction, the cloud storage client 321 can find the file to be uploaded from the shared file system 322 of the shared device 32 by using the path information and metadata of the file to be uploaded contained in the file upload instruction.

[0147] Step 3: Cloud storage client 321 sends the file to be uploaded to server 33.

[0148] After the cloud storage client 321 identifies the file to be uploaded, it can send the file to the server 33.

[0149] Step 4: Server 33 stores the files to be uploaded.

[0150] After receiving the file to be uploaded, server 33 can store the file.

[0151] This completes the cross-device file upload operation.

[0152] For example, Figure 8 A flowchart illustrating a method for downloading files from cloud storage is shown. Figure 8 As shown, the method for downloading files from this cloud storage may include the following steps:

[0153] Step 1: Cloud storage client 311 sends a file download command to cloud storage client 321.

[0154] Users can select files to download from server 33 using cloud storage client 311. After the user selects the file to download, cloud storage client 311 sends a file download instruction to cloud storage client 321. This file download instruction may include identification information and download path information of the selected file.

[0155] Step 2: Cloud storage client 321 sends a file download request to server 33.

[0156] After receiving a file download instruction, the cloud storage client 321 can send a file download request to the server 33. This file download request may include identification information of the file to be downloaded.

[0157] Step 3: Server 33 sends the file to be downloaded to cloud storage client 321.

[0158] After receiving a file download request, server 33 can locate the file to be downloaded using the identification information of the file to be downloaded contained in the download request. Then, server 33 can send the file to be downloaded to cloud storage client 321.

[0159] Step 4: Store the files to be downloaded in the cloud storage client 321.

[0160] After receiving the file to be downloaded, the cloud storage client 321 can store the file to be downloaded in the download path determined by the download path information in the file download instruction.

[0161] This completes the cross-device file download operation.

[0162] Understandably, during the file upload or download process, cloud storage client 311 can also send a pause or cancel command to cloud storage client 321; subsequently, cloud storage client 321 can pause the file upload or download, or cancel the file upload or download.

[0163] In some embodiments, a collaborative session can be pre-established between cloud storage client 311 and cloud storage client 321 before uploading or downloading files, so that the two can communicate subsequently. In some embodiments, authentication can also be performed between cloud storage client 311 and cloud storage client 321 before or during file upload or download to improve the security of file upload or download. In some embodiments, when uploading or downloading files, cloud storage client 311 can first obtain upload authentication information from server 33, and then carry the upload authentication information in the corresponding instruction, so that cloud storage client 321 can carry the upload authentication information in the file upload / download request it sends to server 33, thereby allowing server 33 to verify the file upload / download request sent by cloud storage client 321 based on the upload authentication information, thereby improving the security of file upload or download.

[0164] To facilitate understanding of the technical solution provided in this application, the following is combined with... Figure 3 This application provides a detailed description of a cloud storage file cross-device collaborative operation scheme, using examples. It is understood that this cloud storage file cross-device collaborative operation scheme is merely illustrative and does not constitute a specific limitation on the embodiments of this application.

[0165] (1) System Preset Conditions

[0166] a) The cloud storage client 311 in user equipment 31 has been successfully logged in and is in a user-operable state, so that the user can issue operation commands to the cloud storage client 321 in shared device 32 through the cloud storage client 311 in user equipment 31.

[0167] b) The cloud storage client 321 in the shared device 32 is online and logged in, so that the cloud storage client 321 in the shared device 32 can receive and execute operation instructions sent by the cloud storage client 311 in the user device 31.

[0168] c) Shared directories and files exist on shared device 32. The shared directory is readable and writable, so that user device 31 can remotely access the files in shared device 32.

[0169] It is understandable that the system's preset conditions can be the conditions that user device 31 and shared device 32 need to meet in the cloud storage file cross-device collaborative operation scheme provided in this solution. When these preset conditions are met, user device 31 and shared device 32 can perform collaborative operations.

[0170] (2) Collaborative device discovery and authentication

[0171] In this solution, after user equipment 31 discovers shared device 32, a collaborative session connection can be established between user equipment 31 and shared device 32 to perform an authentication handshake, confirming that shared device 32 can participate in the assistance, thus preparing for subsequent collaborative upload and download. The collaborative device discovery and authentication process is described in detail below. Figure 9 As shown, the collaborative device discovery and authentication process may include:

[0172] Step 1: The collaborative session module 3211 in the cloud storage client 321 of the shared device 32 listens for collaborative session requests from other devices in the network.

[0173] In this solution, the collaborative session module 3211 in the cloud storage client 321 can establish a listening socket on a specific port (such as a listening port) of the shared device 32, and listen for collaborative session requests from other devices in the network in real time or periodically through the listening socket. In one example, the cloud storage client 321 can start simultaneously with the shared device 32 and remain resident, listening for collaborative session requests from the network, so as to promptly learn about the requests from devices that need to establish collaborative sessions.

[0174] Step 2: The collaborative session module 3112 in the cloud storage client 311 on the user device 31 initiates a collaborative session.

[0175] In this solution, when a user starts the cloud storage client 311 on the user device 31, the collaborative session module 3112 in the cloud storage client 311 can be triggered to initiate a collaborative session. Furthermore, if the collaborative session module 3112 is not triggered when the user starts the cloud storage client 311, it can periodically initiate collaborative sessions while the cloud storage client 311 is running. In one example, the collaborative session module 3112 initiating a collaborative session can be understood as the collaborative session module 3112 starting a collaborative session.

[0176] Step 3: The collaborative session module 3112 obtains information about shared devices that provide file sharing within the network from the file system 312 on the user device 31.

[0177] In this scheme, after initiating a collaborative session, the collaborative session module 3112 can obtain information about the devices accessible to the user device 31 from the shared device information stored in the file system 312. The shared device information stored in the file system 312 may include the identity identifier of the shared device. In one example, the identity identifier of the shared device may include the hostname or Internet Protocol address (IP address) of the shared device. For example, as shown in Table 1, the shared device information stored in the file system 312 may include three devices: device 1, device 2, and device 3.

[0178] Table 1

[0179] Serial Number hostname IP address Equipment 1 xxx xxxx Equipment 2 xxx xxxx Equipment 3 xxx xxxx

[0180] Step 4: The collaborative session module 3112 determines the set of collaborative devices to be detected based on the shared device information.

[0181] In this solution, after the collaborative session module 3112 obtains the shared device information, it can determine the identity of the devices included in the shared device information. The set of devices included in the shared device information constitutes the set of collaborative devices to be detected. For example, referring to "Table 1" above, the devices included in the set of collaborative devices to be detected are device 1, device 2, and device 3.

[0182] It is understandable that this solution is mainly based on file sharing for collaboration, so only devices that actually share files can become collaboration devices. Therefore, using devices that share files as collaboration devices to be screened can narrow the detection range and improve collaboration efficiency.

[0183] Step 5: The collaborative session module 3112 determines the collaborative devices to be detected from the set of collaborative devices to be detected.

[0184] In this scheme, after the collaborative session module 3112 determines the set of collaborative devices to be detected, it can use the devices in the set of collaborative devices to be detected as collaborative devices to be detected.

[0185] In one example, when there is only one collaborative device to be detected, that collaborative device can be the shared device 32. When there are multiple collaborative devices to be detected, the shared device 32 can be included among the multiple collaborative devices to be detected.

[0186] Step 6: The collaborative session module 3112 sends a socket connection request to the shared device 32.

[0187] In this solution, the collaborative session module 3112 can initiate a socket connection request to the IP address and listening port of the shared device 32.

[0188] In one example, when the collaborative session module 3112 identifies multiple collaborative devices to be detected, the collaborative session module 3112 can send socket connection requests to each of the multiple collaborative devices to be detected, so that the shared device 32 among the multiple collaborative devices to be detected can receive the socket connection request.

[0189] Step 7: The collaborative session module 3211 in the shared device 32 responds to the socket connection request and establishes a socket connection.

[0190] In this scheme, after receiving a socket connection request, the collaborative session module 3211 in the shared device 32 can establish a socket connection based on the transmission control protocol (TCP) / internet protocol (IP).

[0191] Step 8: The collaborative session module 3211 in the shared device 32 sends a socket connection message to the collaborative session module 3112 in the user device 31.

[0192] In this scheme, after establishing a socket connection, the collaborative session module 3211 in the shared device 32 can send a socket connection message to the collaborative session module 3112 in the user device 31 over the established socket connection, so that the collaborative session module 3112 in the user device 31 can determine whether a socket connection has been successfully established with the collaborative session module 3211. This socket connection message is mainly used to indicate whether the collaborative session module 3211 in the shared device 32 has established a socket connection with the collaborative session module 3112 in the user device 31.

[0193] Step 9: The collaborative session module 3112 sends a collaborative session request to the collaborative session module 3211 over the established socket connection.

[0194] In this scheme, after receiving the socket connection message from the collaborative session module 3211 in the shared device 32, the collaborative session module 3112 can determine whether the collaborative session module 3211 in the shared device 32 has established a socket connection with the collaborative session module 3112 in the user device 31. Once it is determined that the collaborative session module 3211 in the shared device 32 has established a socket connection with the collaborative session module 3112 in the user device 31, the collaborative session module 3112 can send a collaborative session request to the collaborative session module 3211 over the established socket connection. This collaborative session request can carry the login account information and version information of the cloud storage client 311 in the user device 31; primarily, this collaborative session request is used to request the establishment of a collaborative session with the shared device 32.

[0195] Step 10: The collaborative session module 3211 receives the collaborative session request sent by the collaborative session module 3112 and determines whether to establish a collaborative session.

[0196] In this scheme, after receiving a collaborative session request, the collaborative session module 3211 compares the login account information and version information of the cloud storage client 321 in the shared device 32 with the login account information and version information of the cloud storage client 311 in the user device 31. If the login account information is the same and the version information is the same or similar, or if the login account information is the same and the version number in the version information of the cloud storage client 311 on the user device 31 is lower than the version number in the version information of the cloud storage client 321 in the shared device 32, the collaborative session module 3211 may agree to establish a collaborative session with the collaborative session module 3112 if it determines that there is a capability overlap between the two versions. Alternatively, if the login account information is the same and the version number in the version information of the cloud storage client 311 on the user device 31 is higher than the version number in the version information of the cloud storage client 321 in the shared device 32, the collaborative session module 3211 may agree to establish a collaborative session with the collaborative session module 3112; otherwise, it will not agree to establish a collaborative session with the collaborative session module 3112.

[0197] In one example, similar version information can be understood as the difference between the version numbers of the cloud storage clients represented by two version information entries being a preset version interval. For instance, if one version information entry represents a cloud storage client version number of 1.0 and the other version information entry represents a cloud storage client version number of 1.5, and the preset version interval is 6 versions, then these two version information entries can be determined to be similar; if the preset version interval is 3 versions, then these two version information entries can be determined to be different and not similar.

[0198] In one example, comparing whether the version information of two modules is the same or similar can be understood as determining the negotiation capability set between the two collaborative session modules. In this scheme, the negotiation capability set can be understood as the set of capabilities that the two modules have the same, that is, there is an overlap in capabilities. For example, when the versions of the clients on both modules are the same, their capabilities are the same; when the versions of the clients on both modules are different, their capabilities are at least partially the same. The set of capabilities that the two modules have the same can be called the negotiation capability set.

[0199] In one example, when the collaborative session module 3211 agrees to establish a collaborative session with the collaborative session module 3112, if the version number contained in the version information of the cloud storage client 311 on the user device 31 is higher than the version number contained in the version information of the cloud storage client 321 on the shared device 32, then the collaborative session module 3112 on the user device 31 can initiate upload and download tasks in the future, provided that the capabilities of the cloud storage client represented by the version information of the cloud storage client 311 on the user device 31 are compatible with the capabilities of the cloud storage client represented by the version information of the cloud storage client 321 on the shared device 32.

[0200] Understandably, when the login accounts of both devices are the same, it can be determined that the operation was performed by the same user, which is relatively safe, so it is acceptable to agree to establish a collaborative session. When the login accounts of both devices are different, it can be determined that the operation was performed by different users, which poses a risk of data leakage, so it is acceptable to disagree to establish a collaborative session. When the version information of both devices is the same or similar, it can be determined that the two collaborative session modules have the same capabilities. In this case, the collaborative session module 3211 in the shared device 32 has the collaborative capabilities expected by the collaborative session module 3112, so it is acceptable to agree to establish a collaborative session. When the version information of both devices is different and not similar, it can be determined that the two collaborative session modules do not have the same capabilities. In this case, the collaborative session module 3211 in the shared device 32 does not have the collaborative capabilities expected by the collaborative session module 3112, so it is acceptable to disagree to establish a collaborative session.

[0201] It's understandable that comparing the version information of the two can be seen as a negotiation between them to determine if there's any overlap in the capabilities of their cloud storage clients. Similarly, comparing the login account information can be seen as an authentication process to determine if the login accounts for their cloud storage clients are identical.

[0202] Step 11: The collaborative session module 3211 sends a collaborative session establishment message to the collaborative session module 3112.

[0203] In this scheme, after the collaborative session module 3211 agrees to establish a collaborative session, it can send a collaborative session establishment message to the collaborative session module 3112. This collaborative session establishment message primarily indicates that the collaborative session module 3211 has agreed to establish the collaborative session, and it may carry session credential information. This session credential information primarily indicates that a collaborative session has been successfully established between the two. This session credential information can be used by the collaborative session module 3112 when subsequently sending request commands. Specifically, when the collaborative session module 3112 sends a request command, it can include this session credential information in the request command. After receiving the request command, the collaborative session module 3211 can use this session credential information to determine that a collaborative session has been established, thus avoiding the need to re-establish the collaborative session and improving processing efficiency.

[0204] In addition, after the collaborative session module 3211 determines that the collaborative authentication has failed, it can send a message to the collaborative session module 3112 that the collaborative session establishment has failed.

[0205] Step 12: The collaborative session module 3112 receives the collaborative session establishment message and records the device information and session credential information of the shared device 32.

[0206] In this solution, after determining that the collaborative session module 3211 in the shared device 32 agrees to establish a collaborative session, the collaborative session module 3112 can record the device information and session credential information of the shared device 32 for direct use during subsequent cross-device collaboration. For example, the device information of the shared device 32 may include the hostname and / or IP address of the shared device 32. For example, the session credential information may indicate that authentication has been performed between the two parties, and it may have a time limit, such as being valid for a period of time.

[0207] It is understandable that the process of discovering and authenticating collaborative devices can be completed in advance or when collaboration is needed. However, in order to improve the timeliness of device collaboration, it is possible to complete it in advance, and no restrictions are imposed here.

[0208] It is understood that all or part of the steps in the collaborative device discovery and authentication process can be executed, and this is not limited here. For example, step 2 can be executed directly, and after step 5, the collaborative session module 3112 can directly send a collaborative session request to the collaborative session module 3211 and execute subsequent steps.

[0209] (3) Collaborative file upload and download in cloud storage

[0210] After the cloud storage client 311 on user equipment 31 has completed negotiation and authentication (i.e., established a collaborative session) with the cloud storage client 321 in the shared device 32 that supports collaboration within the network through the collaborative device discovery function, the user can enable the collaborative upload and download function of cloud storage files when uploading shared files from the shared device 32 on user equipment 31. The collaborative upload and download process of cloud storage files is described in detail below.

[0211] a) Collaborative file upload process in cloud storage

[0212] Figure 10 This is a communication diagram illustrating a collaborative file upload process for cloud storage provided in an embodiment of this application. For example... Figure 10 As shown, in this solution, the collaborative file upload process for cloud storage may include:

[0213] Step 1: The user uploads files on the management module 3111 of the cloud storage client 311 on the user device 31.

[0214] In this solution, users can upload files on the cloud storage client 311 on user device 31. The management module 3111 in the cloud storage client 311 can be configured with an entry point for uploading files. For example, such as... Figure 11a As shown, after logging into their cloud drive (i.e., cloud storage client) on user device 31, the user can select the button at area a1, which can be used as the entry point for uploading files.

[0215] Step 2: The user selects the file in the remote shared folder of the shared device 32 to upload to the server 33 through the file system 322 on the user device 31.

[0216] In this solution, the user can select the file to be uploaded from the shared device 32 via the user device 31. The file to be uploaded refers to the file on the shared device 32 that needs to be uploaded to the cloud storage client 311.

[0217] For example, such as Figure 11a As shown, after logging into their cloud drive (i.e., cloud storage client) on user device 31, the user can select the button at area a1, and then the user device 31 will display the following... Figure 11b The interface shown allows you to choose whether to upload files from your local machine or from a network device. Next, please refer to... Figure 11b Users on user device 31 can select "Network Device" in area a2 to upload files from the network device. Figure 11b After selecting "Network Devices" in area a2, user equipment 31 will display as follows. Figure 11cThe interface shown allows users to select which network device to upload files from. Specifically, users can select "Shared Device 32" in area a3. Users can then... Figure 11c After selecting "Shared Device 32" in area a3, user device 31 will then display as shown below. Figure 11d The interface shown allows the user to view the shared files on shared device 32. The user can then select the file they wish to upload, such as "xx1.doc" in area a4. The user... Figure 11d After selecting “xx1.doc” in area a4, “xx1.doc” in area a4 is the file to be uploaded.

[0218] Step 3: The management module 3111 in the cloud storage client 311 determines whether the shared device 32 supports collaboration based on the results of the collaborative device discovery and authentication process.

[0219] In this scheme, user equipment 31 can determine whether sharing device 32 supports collaboration based on the device information of devices that have agreed to establish a collaboration session, which it recorded during the collaboration device discovery and authentication phase. For example, after sharing device 32 agrees to establish a collaboration session, user equipment 31 can record the device information of sharing device 32. Subsequently, when the remote device of the file to be uploaded is sharing device 32, user equipment 31 can determine that the remote device of the file to be uploaded supports collaboration.

[0220] Step 4: When the shared device 32 supports collaboration, the management module 3111 in the cloud storage client 311 sends a collaborative upload command to the collaborative session module 3112 in the cloud storage client 311.

[0221] In this scheme, the collaborative upload instruction may include one or more of the following information: an instruction command word indicating the upload; remote path information of the file to be uploaded; metadata of the file to be uploaded, such as filename, file type, or feature value; or, session credential information recorded by the collaborative session module 3112 when the collaborative session module in the remote device agrees to establish a collaborative session. The file's feature value can characterize the file's content; for example, the feature value can be a hash value.

[0222] Step 5: The collaborative session module 3112 in the cloud storage client 311 sends the collaborative upload command to the collaborative session module 3211 in the shared device 32.

[0223] Step 6: The collaborative session module 3211 in the shared device 32 receives the collaborative upload command and verifies the collaborative upload command.

[0224] In this solution, after receiving a collaborative upload instruction, the collaborative session module 3211 in the shared device 32 can determine whether the collaborative upload instruction contains one or more of the following information: the instruction command word indicating the upload, the remote path information of the file to be uploaded, the metadata of the file to be uploaded, or session credential information, etc. If the collaborative upload instruction contains one or more of the above information, the verification is successful; otherwise, the verification fails.

[0225] Step 7: After successful verification, the collaborative session module 3211 in the shared device 32 sends the collaborative upload command to the upload / download module 3212 in the shared device 32.

[0226] Step 8: The upload / download module 3212 in the shared device 32 receives the collaborative upload instruction and reads the file to be uploaded from the shared file system 322 of the shared device 32 according to the collaborative upload instruction.

[0227] In this solution, the upload / download module 3212 in the shared device 32 can read the content of the file to be uploaded from the shared file system 322 of the shared device 32 based on the remote path information and metadata of the file to be uploaded carried in the collaborative upload instruction. For example, if the remote path information of the file to be uploaded is D:\works, and the file name of the file to be uploaded is abc, the upload / download module 3212 can read the file named abc from the D drive works folder of the shared file system 322, which is the file to be uploaded.

[0228] Step 9: The upload / download module 3212 in the shared device 32 sends the file to be uploaded to the server 33.

[0229] Step 10: Server 33 receives the file to be uploaded and stores the file to be uploaded.

[0230] Step 11: The upload / download module 3212 in the shared device 32 sends the upload progress information and upload result information during the upload process to the collaborative session module 3211 in the shared device 32.

[0231] In this solution, the upload / download module 3212 in the shared device 32 can send upload progress information periodically or according to a preset progress ratio. For example, the upload / download module 3212 can send upload progress information every 2 seconds or every 2% of the upload progress.

[0232] Step 12: The collaborative session module 3211 in the shared device 32 sends upload progress information and upload result information to the collaborative session module 3112 in the user device 31.

[0233] Step 13: The collaborative session module 3112 in user equipment 31 sends upload progress information and upload result information to the management module 3111 in user equipment 31.

[0234] Step 14: The management module 3111 in user equipment 31 presents upload progress information and upload result information to the user.

[0235] In this solution, after the management module 3111 receives the upload progress information and upload result information, it can present this information to the user on the user device 31 through the cloud storage client 311. For example, as shown... Figure 11e As shown, after logging into their cloud drive (i.e., cloud storage client) on user device 31, users can view the upload progress in the transmission management interface. For example, in area a5, you can see that "xx1.doc" has been uploaded 30%.

[0236] Understandably, in this solution, after the upload / download module 3212 in shared device 32 successfully uploads the file, server 33 can update the cloud storage file it stores. Then, the newly uploaded file can be viewed through the cloud storage client 311 on user device 31.

[0237] It is understandable that all steps in the collaborative file upload process of cloud storage can be executed, or only some steps can be executed; this is not limited here. For example, after executing steps 1 and 2, the management module 3111 in the cloud storage client 311 can directly send a collaborative upload command to the collaborative session module 3112 in the cloud storage client 311 (i.e., execute step 4), and then execute subsequent steps. For example, steps 11 to 14 can be executed, or not, depending on the actual situation; this is not limited here.

[0238] b) Collaborative file download process from cloud storage

[0239] Figure 12 This is a communication diagram illustrating a collaborative file download process using cloud storage, provided in an embodiment of this application. For example... Figure 12 As shown, in this solution, the collaborative file download process from cloud storage can include:

[0240] Step 1: The user downloads cloud storage files on the management module 3111 of the cloud storage client 311 on the user device 31.

[0241] In this solution, users can download cloud storage files using the cloud storage client 311 on user device 31.

[0242] For example, such as Figure 13aAs shown, after logging into their cloud drive (i.e., cloud storage client) on user device 31, the user can select "xxa.doc" in region b1. The user can then... Figure 13a After selecting “xxa.doc” in area b1, “xxa.doc” in area b1 is the file to be downloaded. In other words, “xxa.doc” is the cloud storage file that the user wants to download.

[0243] Step 2: The user selects the remote shared folder of the shared device 32 as the target address for downloading files from the cloud storage via the file system 322 on the user device 31.

[0244] In this solution, users can select a folder on shared device 32 as the download target address for their chosen cloud storage files.

[0245] For example, the user in Figure 13a Selecting "xxa.doc" in region b1 will display the following on user device 31: Figure 13b The interface shown. (As shown) Figure 13b As shown, the user can select the "More" button in area b2, and the user device 31 will then display the following... Figure 13c The interface shown. In Figure 13c In the interface shown, users can choose to cache "xxa.doc" locally or save it to another location. For example... Figure 13c As shown, the user can select the "Save As" button in area b3, and then the user device 31 will display the following... Figure 13d The interface shown. In, as... Figure 13d In the process, the user can select "Shared Device 32" in area b4, at which point the user will choose to save "xxa.doc" to shared device 32. Then, the user's device 31 will display the following... Figure 13e As shown in the interface, the user can select the "xx1. folder" in area b5 as the download target address for the selected "xxa.doc". At this time, "xxa.doc" will be downloaded to the "xx1. folder".

[0246] Step 3: The management module 3111 in the cloud storage client 311 determines whether the shared device 32 supports collaboration based on the results of the collaborative device discovery and authentication process.

[0247] In this scheme, user equipment 31 can determine whether sharing device 32 supports collaboration based on the device information of devices that have agreed to establish a collaboration session, which it recorded during the collaboration device discovery and authentication phase. For example, after sharing device 32 agrees to establish a collaboration session, user equipment 31 can record the device information of sharing device 32. Then, when the remote device of the file to be downloaded is sharing device 32, user equipment 31 can determine that the remote device of the file to be downloaded supports collaboration.

[0248] Step 4: When the shared device 32 supports collaboration, the management module 3111 in the cloud storage client 311 sends a collaborative download instruction to the collaborative session module 3112 in the cloud storage client 311.

[0249] In this scheme, the collaborative download instruction may include one or more of the following information: the instruction command word indicating the download; the identification information of the file to be downloaded; the download path information of the file to be downloaded; or, the session credential information recorded by the collaborative session module 3112 when the collaborative session module in the remote device agrees to establish a collaborative session.

[0250] Step 5: The collaborative session module 3112 in the cloud storage client 311 sends a collaborative download command to the collaborative session module 3211 in the shared device 32.

[0251] Step 6: The collaborative session module 3211 in the shared device 32 receives the collaborative download instruction and verifies the collaborative download instruction.

[0252] In this solution, after receiving a collaborative download instruction, the collaborative session module 3211 in the shared device 32 can determine whether the instruction contains one or more of the following information: a download instruction command word, the identifier information of the file to be downloaded, the download path information of the file to be downloaded, or session credential information, etc. If the collaborative download instruction contains one or more of the above information, the verification is successful; otherwise, the verification fails.

[0253] Step 7: After successful verification, the collaborative session module 3211 in the shared device 32 sends a collaborative download command to the upload / download module 3212 in the shared device 32.

[0254] Step 8: The upload / download module 3212 in the shared device 32 receives the collaborative download instruction and sends a file download request to the server 33.

[0255] In this scheme, the file download request can carry the identification information of the file to be downloaded, so that the server 33 can know the file to be downloaded by the upload and download module 3212.

[0256] Step 9: Server 33 sends the downloaded file to upload / download module 3212 in shared device 32.

[0257] Step 10: The upload / download module 3212 in the shared device 32 receives the downloaded file and writes it to the target folder in the collaborative download instruction. The target folder can be determined by the download path information of the file to be downloaded. For example, if the download path information of the file to be downloaded is D:\works, then the target folder is works.

[0258] Step 11: The upload / download module 3212 in the shared device 32 sends the download progress information and download result information during the download process to the collaborative session module 3211 in the shared device 32.

[0259] In this solution, the upload / download module 3212 in the shared device 32 can send download progress information periodically or according to a preset progress ratio. For example, the upload / download module 3212 can send download progress information every 2 seconds or every 2% of the upload progress.

[0260] Step 12: The collaborative session module 3211 in the shared device 32 sends download progress information and download result information to the collaborative session module 3112 in the user device 31.

[0261] Step 13: The collaborative session module 3112 in user equipment 31 sends download progress information and download result information to the management module 3111 in user equipment 31.

[0262] Step 14: The management module 3111 in the user equipment 31 presents the download progress information and download result information to the user.

[0263] In this solution, after the management module 3111 receives the download progress information and download result information, it can present this information to the user on the user device 31 through the cloud storage client 311. For example, as shown in the figure... Figure 13f As shown, after logging into their cloud drive (i.e., cloud storage client) on user device 31, users can view the download progress in the transfer management interface. For example, in area b6, you can see that "xxa.doc" has been downloaded 30%.

[0264] It is understandable that all steps in the collaborative file download process of cloud storage can be executed, or only some steps can be executed; this is not limited here. For example, after executing steps 1 and 2, the management module 3111 in the cloud storage client 311 can directly send a collaborative upload command to the collaborative session module 3112 in the cloud storage client 311 (i.e., execute step 4), and then execute subsequent steps. For example, steps 11 to 14 can be executed, or not, depending on the actual situation; this is not limited here.

[0265] Therefore, in this solution, by deploying a cloud storage client on the remote device for file sharing to proxy file uploads and downloads, and by having the cloud storage client on the local machine and the cloud storage client on the remote device negotiate authentication with each other, it is possible to remotely instruct the cloud storage client on the remote device to perform upload and download operations through the cloud storage client on the local machine. This also allows the cloud storage client on the remote device to communicate directly with the cloud storage server, thereby shortening the file upload and download path on the remote device, reducing latency, and maintaining a user experience consistent with local file upload and download. Since the remote device performs upload and download operations itself, it can fully utilize the bandwidth and online advantages of the remote device; furthermore, when the remote device performs upload and download operations, it does not consume the local machine's mobile network bandwidth or central processing unit (CPU) system resources, reducing the consumption of local resources.

[0266] In addition, since the upload and download process is completed by the shared device in this solution, even if the user's device loses network access or goes offline during the upload and download process, it will not affect the upload and download tasks of files already started on the shared device.

[0267] It should be noted that during the collaborative upload and download of files in cloud storage, users can also initiate pause, cancellation, and other operations through the management module 3111 on the cloud storage client 311 on user device 31. Specifically, for example... Figure 14 As shown, user actions such as pausing and canceling during collaborative file upload and download in cloud storage can include the following steps:

[0268] Step 1: The user pauses or cancels the operation on the management module 3111 of the cloud storage client 311 on the user device 31.

[0269] For example, such as Figure 11e As shown, the user can access the cloud drive (i.e., cloud storage client) transfer management interface on user device 31 and select the transfer progress button in area a6, at which point the user will pause the transfer operation. Figure 13fAs shown, users can access the cloud disk (i.e., cloud storage client) transfer management interface on user device 31, select the transfer progress button in area b7, and then pause the transfer operation.

[0270] Step 2: The management module 3111 in the cloud storage client 311 sends a collaborative operation command to the collaborative session module 3112 in the cloud storage client 311.

[0271] In this scheme, the collaborative operation instruction is mainly used to indicate whether to pause or cancel an operation. This collaborative operation instruction may include one or more of the following information: an instruction word indicating pause or cancellation; task information to be performed; or, session credential information recorded by the collaborative session module 3112 when the collaborative session module in the remote device agrees to establish a collaborative session.

[0272] Step 3: The collaborative session module 3112 in the cloud storage client 311 sends a collaborative operation command to the collaborative session module 3211 in the cloud storage client 321 on the shared device 32.

[0273] Step 4: The collaborative session module 3211 in the cloud storage client 321 on the shared device 32 receives the collaborative operation instruction and verifies the collaborative operation instruction.

[0274] In this solution, after receiving a collaborative operation instruction, the collaborative session module 3211 in the shared device 32 can determine whether the instruction contains one or more of the following information: a command word indicating pause or cancellation; task information to be operated; or session credential information, etc. If the collaborative operation instruction contains one or more of the above information, the verification is successful; otherwise, the verification fails.

[0275] Step 5: After successful verification, the collaborative session module 3211 in the shared device 32 sends a collaborative operation command to the upload / download module 3212 in the shared device 32.

[0276] Step 6: The upload / download module 3212 in the shared device 32 executes a collaborative operation command to pause or cancel the upload / download process.

[0277] Step 7: The upload / download module 3212 in the shared device 32 sends the execution result information to the collaborative session module 3211 in the shared device 32.

[0278] Step 8: The collaborative session module 3211 in the shared device 32 sends the execution result information to the collaborative session module 3112 in the user device 31.

[0279] Step 9: The collaborative session module 3112 in user equipment 31 sends the execution result information to the management module 3111 in user equipment 31.

[0280] Step 10: The management module 3111 in user equipment 31 presents the execution result information to the user.

[0281] For example, such as Figure 15a As shown, area a6 on user device 31 will display the message that upload has been paused. Figure 15b As shown, area b7 on user device 31 can display that the download has been paused.

[0282] The above is an introduction to one cloud storage file cross-device collaborative operation scheme involved in this solution. Next, another cloud storage file cross-device collaborative operation scheme involved in this solution will be introduced. In this scheme, the login account of the cloud storage client on the user device and the login account of the cloud storage client on the shared device can be the same or different. Furthermore, the cloud storage client on the shared device may not require a login account; that is, there are no restrictions on the login account of the cloud storage client on the shared device in this scheme. In other words, this scheme can reduce the account authentication process. It should be understood that this cloud storage file cross-device collaborative operation scheme is merely illustrative and does not constitute a specific limitation on the embodiments of this application.

[0283] It is understandable that the system prerequisites for this cloud storage file cross-device collaborative operation solution are the same as those described above, and will not be repeated here.

[0284] (1) Collaborative device discovery

[0285] Understandably, the collaborative device discovery process in this cloud storage file cross-device collaborative operation solution is similar to the "collaborative device discovery and authentication process" described above. The difference lies in the fact that this collaborative device discovery process does not require an "authentication process." Specifically, the main differences between this collaborative device discovery process and the "collaborative device discovery and authentication process" described above are: the information carried in the collaborative session request is different, the process for determining whether to establish a collaborative session is different, and the information recorded subsequently is different.

[0286] In the process of discovering collaborative devices in the cross-device collaborative operation scheme of cloud storage files, the collaborative session request can carry the version information of the cloud storage client 311 in the user device 31; the collaborative session request is mainly used to request the establishment of a collaborative session with the shared device 32.

[0287] When determining whether to establish a collaborative session, the version information of the cloud storage client 321 in the shared device 32 can be compared with the version information of the cloud storage client 311 in the user device 31. If the version information is the same or similar, an agreement can be reached to establish a collaborative session with the collaborative session module 3112; otherwise, an agreement cannot be reached. It can be understood that comparing the version information is a negotiation between the two parties to determine if there is any overlap in the capabilities of their cloud storage clients.

[0288] After establishing a collaborative session, device information for shared device 32 can be recorded. However, since the collaborative device discovery process in this cloud storage file cross-device collaborative operation scheme does not involve an "authentication process," session credential information does not need to be recorded.

[0289] (2) Collaborative file upload and download in cloud storage

[0290] After the cloud storage client 311 on user equipment 31 has completed negotiation (i.e., established a collaborative session) with the cloud storage client 321 in the shared device 32 that supports collaboration within the network through the collaborative device discovery function, the user can enable the collaborative upload and download function of cloud storage files when uploading shared files from the shared device 32 on user equipment 31. The collaborative upload and download process of cloud storage files is described in detail below.

[0291] (a) Collaborative file upload process in cloud storage

[0292] For example, Figure 16 A communication diagram illustrating a collaborative file upload process in cloud storage is shown. Figure 16 As shown, in this solution, the collaborative file upload process for cloud storage may include:

[0293] Step 1: The user uploads files to the server 33 on the management module 3111 of the cloud storage client 311 on the user device 31.

[0294] Step 2: The user selects the file in the remote shared folder of the shared device 32 to upload to the server 33 through the file system 322 on the user device 31.

[0295] Step 3: The management module 3111 in the cloud storage client 311 determines whether the shared device 32 supports collaboration based on the results of the collaborative device discovery and authentication process.

[0296] Step 4: When the shared device 32 supports collaboration, the management module 3111 in the cloud storage client 311 sends an upload request message to the server 33.

[0297] In this scheme, the upload request message can be used to request the upload of a file to server 33. In one example, the upload request message can carry metadata of the file to be uploaded, such as the file name, file type, or characteristic value, where the characteristic value can be a hash value.

[0298] Step 5: Server 33 responds to the upload request message and sends upload authentication information to the management module 3111 in the cloud storage client 311.

[0299] In this scheme, after receiving an upload request message, server 33 can generate upload credentials, which can be a random number and valid for a preset time period. Furthermore, when the upload request message carries metadata and / or feature values ​​of the file to be uploaded, server 33 can also sign the metadata and / or feature values ​​of the file to be uploaded to generate upload signature information. The upload credentials can be used by server 33 to subsequently verify whether it has agreed to the upload; the upload signature information can be used by server 33 to subsequently verify whether the uploaded file it receives is the file requested by cloud storage client 311, to prevent the file requested by cloud storage client 311 from being tampered with. The filename can be used to prevent the filename from being tampered with subsequently, and the file's feature values ​​can be used to prevent the file content from being tampered with subsequently.

[0300] After the server 33 generates upload credential information and / or upload signature information, the server 33 can send upload authentication information to the management module 3111 in the cloud storage client 311. The upload authentication information may include upload credential information and / or upload signature information.

[0301] Step 6: The management module 3111 in the cloud storage client 311 sends a collaborative upload command to the collaborative session module 3112 in the cloud storage client 311.

[0302] In this scheme, the collaborative upload instruction may include one or more of the following information: the instruction command word indicating the upload; the remote path information of the file to be uploaded; the metadata of the file to be uploaded, such as the file name (which the user may modify), collection attributes, and other necessary file attribute information; or, upload authentication information.

[0303] Step 7: The collaborative session module 3112 in the cloud storage client 311 sends the collaborative upload command to the collaborative session module 3211 in the shared device 32.

[0304] Step 8: The collaborative session module 3211 in the shared device 32 receives the collaborative upload instruction and verifies the collaborative upload instruction.

[0305] In this solution, after receiving a collaborative upload command, the collaborative session module 3211 in the shared device 32 can determine whether the collaborative upload command contains one or more of the following information: the command word indicating the upload, the remote path information of the file to be uploaded, the metadata of the file to be uploaded, or upload authentication information, etc. If the collaborative upload command contains one or more of the above information, the verification is successful; otherwise, the verification fails.

[0306] Step 9: After successful verification, the collaborative session module 3211 in the shared device 32 sends the collaborative upload command to the upload / download module 3212 in the shared device 32.

[0307] Step 10: The upload / download module 3212 in the shared device 32 receives the collaborative upload instruction and reads the file to be uploaded from the shared file system 322 of the shared device 32 according to the collaborative upload instruction.

[0308] Step 11: The upload / download module 3212 in the shared device 32 sends a file upload request message and the file to be uploaded to the server 33.

[0309] In this scheme, a file upload request message can be used to request the upload of a file. This file upload request message can carry upload authentication information.

[0310] Step 12: Server 33 receives the file upload request message and verifies the upload authentication information.

[0311] In this scheme, after receiving a file upload request message, server 33 can verify the upload authentication information in the file upload request message. In one example, when the upload authentication information includes upload credential information, server 33 can verify whether the upload credential information was issued by it. If the verification confirms that it was issued by it, the verification passes; otherwise, the verification fails. When the upload authentication information includes upload signature information, server 33 can authenticate the upload signature information to determine whether the file it received was requested to be uploaded by user device 31. If it is determined that the file was requested to be uploaded by user device 31, the verification passes; otherwise, the verification fails.

[0312] Step 13: When the verification is successful, server 33 receives the file to be uploaded and stores the file to be uploaded.

[0313] It should be noted that, Figure 16Steps 1-3 shown above can be referred to the relevant descriptions in Figure 11 above, and will not be repeated here. In addition, after step 13, the cloud storage client 321 in the shared device 32 can also send the upload progress information and upload result information during the upload process to the cloud storage client 311 in the user device 31, so that the cloud storage client 311 can present the upload progress information and upload result information to the user. See the relevant descriptions in Figure 11 above for details, and will not be repeated here.

[0314] It is understandable that all or some of the steps in the collaborative file upload process of cloud storage can be executed, and this is not limited here. For example, after executing steps 1 and 2, the management module 3111 in the cloud storage client 311 can directly send an upload request message to the server 33 (i.e., execute step 4) and execute subsequent steps.

[0315] Understandably, in this solution, because the account authentication step is reduced and the request initiator (i.e., the cloud storage client on the user's device) carries and uploads authentication information, and the cloud storage server verifies the uploaded authentication information during the upload process, the shared device's cloud storage client can still collaborate with the user's cloud storage client even when the login account of the shared device's cloud storage client is different from that of the user's cloud storage client. This allows the shared device's cloud storage client to provide services to multiple different users, thus expanding its applicability.

[0316] (b) Collaborative download process of files from cloud storage

[0317] For example, Figure 17 This is a communication diagram illustrating a collaborative file download process using cloud storage, provided in an embodiment of this application. For example... Figure 17 As shown, in this solution, the collaborative file download process from cloud storage can include:

[0318] Step 1: The user downloads cloud storage files on the management module 3111 of the cloud storage client 311 on the user device 31.

[0319] Step 2: The user selects the remote shared folder of the shared device 32 as the target address for downloading files from the cloud storage via the file system 322 on the user device 31.

[0320] Step 3: The management module 3111 in the cloud storage client 311 determines whether the shared device 32 supports collaboration based on the results of the collaborative device discovery and authentication process.

[0321] Step 4: When the shared device 32 supports collaboration, the management module 3111 in the cloud storage client 311 sends a download request message to the server 33.

[0322] In this scheme, the download request message can be used to request the download of a file from server 33. In one example, the upload request message can carry identification information of the file to be downloaded.

[0323] Step 5: Server 33 responds to the download request message and sends download authentication information to the management module 3111 in the cloud storage client 311.

[0324] In this scheme, after receiving a download request message, server 33 can generate download credential information, which can be a random number and is valid for a preset time period. Furthermore, when the download request message carries identification information of the file to be downloaded, server 33 can also sign the identification information of the file to be downloaded to generate download signature information. The download credential information can be used by server 33 to subsequently verify whether it has agreed to the download; the download signature information can be used by server 33 to subsequently verify whether the downloaded file it received is the file requested by cloud storage client 311.

[0325] After the server 33 generates download credential information and / or download signature information, the server 33 can send download authentication information to the management module 3111 in the cloud storage client 311. The download authentication information may include download credential information and / or download signature information.

[0326] Step 6: The management module 3111 in the cloud storage client 311 sends a collaborative download command to the collaborative session module 3112 in the cloud storage client 311.

[0327] In this scheme, the collaborative download instruction may include one or more of the following information: the instruction command word indicating the download; the identification information of the file to be downloaded; the download path information of the file to be downloaded; or, download authentication information.

[0328] Step 7: The collaborative session module 3112 in the cloud storage client 311 sends a collaborative download command to the collaborative session module 3211 in the shared device 32.

[0329] Step 8: The collaborative session module 3211 in the shared device 32 receives the collaborative download instruction and verifies the collaborative download instruction.

[0330] In this solution, after receiving a collaborative download instruction, the collaborative session module 3211 in the shared device 32 can determine whether the collaborative download instruction contains one or more of the following information: the instruction command word indicating download, the identification information of the file to be downloaded, the download path information of the file to be downloaded, or download authentication information, etc. If the collaborative download instruction contains one or more of the above information, the verification is successful; otherwise, the verification fails.

[0331] Step 9: After successful verification, the collaborative session module 3211 in the shared device 32 sends a collaborative download command to the upload / download module 3212 in the shared device 32.

[0332] Step 10: The upload / download module 3212 in the shared device 32 receives the collaborative download instruction and sends a file download request to the server 33.

[0333] In this scheme, the file download request can carry the identification information of the file to be downloaded, as well as the download authentication information, so that the server 33 can know the file to be downloaded required by the upload and download module 3212, and verify the download authentication information.

[0334] Step 11: Server 33 receives the file download request and verifies the download authentication information.

[0335] In this scheme, after receiving a file download request, server 33 can verify the download authentication information carried in the file download request. In one example, when the download authentication information includes download credential information, server 33 can verify whether the download credential information was issued by it. If the verification confirms that it was issued by it, the verification passes; otherwise, the verification fails. When the download authentication information includes download signature information, server 33 can authenticate the download signature information to determine whether the file currently requested for download is requested by user device 31. If it is determined that user device 31 requested the download, the verification passes; otherwise, the verification fails.

[0336] Step 12: When the verification is successful, the server 33 sends the download file to the upload / download module 3212 in the shared device 32.

[0337] Step 13: The upload / download module 3212 in the shared device 32 receives the downloaded file and writes the downloaded file to the target folder in the collaborative download instruction.

[0338] It should be noted that, Figure 17 Steps 1-3 shown above can be referenced. Figure 12 The relevant descriptions in the text will not be repeated here. Furthermore, after step 13, the cloud storage client 321 in the shared device 32 can also send download progress information and download result information during the download process to the cloud storage client 311 in the user device 31, so that the cloud storage client 311 can present the download progress information and download result information to the user, as detailed above. Figure 12 The relevant descriptions in the text will not be repeated here.

[0339] It is understandable that all or some of the steps in the collaborative download process of cloud storage files can be executed, and this is not limited here. For example, after executing steps 1 and 2, the management module 3111 in the cloud storage client 311 can directly send a download request message to the server 33 (i.e., execute step 4) and execute subsequent steps.

[0340] Understandably, in this solution, because the account authentication step is reduced and instead the request initiator (i.e., the cloud storage client on the user's device) carries the download authentication information, and the cloud storage server verifies the download authentication information during the download process, the shared device's cloud storage client can still collaborate with the user's cloud storage client even when the login account of the shared device's cloud storage client is different from that of the user's cloud storage client. This allows the shared device's cloud storage client to provide services to multiple different users, thus expanding its applicability.

[0341] It should be noted that during the collaborative upload and download of files in cloud storage, users can also initiate pause, cancellation, and other operations through the management module 3111 on the cloud storage client 311 on user device 31. Understandably, the pause, cancellation, and other operations in this cross-device collaborative operation solution for cloud storage files are similar to the "pause, cancellation, and other operations" described above. The differences lie in the information contained in the collaborative operation instructions and the verification of the collaborative operation instructions.

[0342] In the process of pausing or canceling operations in this cloud storage file cross-device collaborative operation solution, the collaborative operation instruction may include one or more of the following information: a command word indicating pause or cancellation; task information to be performed; or authentication information. During collaborative upload, the authentication information is the upload authentication information. During collaborative download, the authentication information is the download authentication information.

[0343] When verifying a collaborative operation instruction, it can be determined whether the instruction contains one or more of the following information: a command word indicating pause or cancellation; information about the task to be performed; or authentication information. If the collaborative operation instruction contains one or more of the above information, the verification is successful; otherwise, the verification fails.

[0344] It should be noted that, in the collaborative device discovery phase, the solution provided in this application, besides sending probes based on the shared file device described above, can also discover collaborative devices through the Bonjour service discovery protocol. The communication negotiation channel between the user device and the shared device can utilize other mature communication channels or buses, in addition to self-built communication channels. Furthermore, remote device file access is not limited to shared file systems; distributed file systems or storage services using other protocols can also be used.

[0345] The above is an introduction to the relevant technical solutions provided in the embodiments of this application. Next, based on the content described above, a cross-device data operation method provided in the embodiments of this application will be introduced. It is understood that this method is proposed based on the content described above, and some or all of the content of this method can be found in the relevant description above. This cross-device data operation method can be applied to a system including a first device, a second device, and a server, and the first device can remotely access shared data on the second device. For example, the first device can be... Figure 3 The user equipment 31 shown can be a second device. Figure 3 The shared device 32 shown can be a server. Figure 3 The cloud storage server 33 shown.

[0346] For example, Figure 18 A method for cross-device data manipulation is illustrated. For example... Figure 18 As shown, the method may include the following steps:

[0347] S1801, the first device responds to the received first instruction and determines the path information of the data to be uploaded, wherein the data to be uploaded is located in the second device.

[0348] Specifically, the user can perform operations on the first device to issue a first command to the first device. For example, the operation performed by the user on the first device could be... Figure 10 or Figure 16 The file upload operation described herein. The first instruction can be understood as an instruction generated after the user performs an operation on the first device. When the user performs an operation on the first device, the first device can remotely access the data shared by the second device, thereby determining the path information of the data to be uploaded. For example, the process of determining the path information of the data to be uploaded can be found in [link to documentation]. Figure 10 or Figure 16 The descriptions of steps 1 and 2 are omitted here. For example, the data to be uploaded can... Figure 10 or Figure 16 The file to be uploaded as described in [the document / document].

[0349] In one example, the data to be uploaded may include one or more files.

[0350] S1802, the first device sends a first message to the second device. The first message includes path information and is used to instruct the second device to upload the data to be uploaded to the server.

[0351] Specifically, after determining the path information of the data to be uploaded, the first device can send a first message containing the path information to the second device. This first message can instruct the second device to upload the data to the server. For example, the first message could be... Figure 7 The file upload command described in [the document] can also be used for... Figure 10 or Figure 16 The collaborative upload command described in [the document].

[0352] In one example, the first message also includes identification information for the data to be uploaded.

[0353] In one example, the first message also includes session credential information, which is an authentication credential between the first and second devices. For instance, the session credential information could be... Figure 9 The session credential information described in [the document / document].

[0354] Furthermore, before sending the first message to the second device, the first device can also determine the association between a first account on the first device and a second account on the second device; and generate session credential information. For example, determining the association between the first account on the first device and the second account on the second device can be understood as... Figure 9 The description above determines whether two accounts are the same account. Furthermore, before generating session credential information, the first device can also determine the association between a first version corresponding to the first account and a second version corresponding to the second account. For example, determining the association between the first version corresponding to the first account and the second version corresponding to the second account can be understood as... Figure 9 Does the two versions described herein have overlapping capabilities? For example, the first account can be a device-level account, such as the account used to log in to a first device, or an application-level account, such as the account used to log in to one or more applications on the first device. Similarly, the second account can be a device-level account, such as the account used to log in to a second device, or an application-level account, such as the account used to log in to one or more applications on a second device.

[0355] Furthermore, the session credential information can also be generated by the second device. In this case, the second device can determine the association between the first account on the first device and the second account on the second device before receiving the first message, and generate the session credential information, which it then sends to the first device. Afterward, the first device can obtain the session credential information sent by the second device. Additionally, before generating the session credential information, the second device can determine the association between the first version corresponding to the first account and the second version corresponding to the second account. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0356] In one example, before sending the first message to the second device, the first device can also send a first request to the server. This first request requests the upload of data to be uploaded. The server can respond to the received first request by generating upload authentication information and sending it to the first device. Subsequently, the first device can obtain the upload authentication information sent by the server, which is used by the server to verify the data to be uploaded after receiving it from the second device. For example, the first request could be... Figure 16 The upload request message described herein allows for the uploading of authentication information, which can be... Figure 16 The uploaded authentication information described herein. Furthermore, the first device may include this uploaded authentication information in the first message so that the second device can obtain it.

[0357] Furthermore, before sending the first message to the second device, the first device can determine the association between the first version corresponding to the first account on the first device and the second version corresponding to the second account on the second device. For example, determining the association between the first version corresponding to the first account and the second version corresponding to the second account can be understood as... Figure 9 Does the two versions described in the text have overlapping capabilities?

[0358] S1803. The second device determines the data to be uploaded based on the path information contained in the first message.

[0359] Specifically, after receiving the first message, the second device can determine the data to be uploaded from the path information contained in the first message. For example, the process of determining the data to be uploaded can be found in [link to documentation]. Figure 10 Step 8 or Figure 16 The relevant descriptions in step 10 will not be repeated here.

[0360] In one example, when the first message includes identification information of the data to be uploaded, the second device can determine the data to be uploaded based on the identification information and the path information.

[0361] S1804. The second device sends the data to be uploaded to the server.

[0362] Specifically, once the second device identifies the data to be uploaded, it can send that data to the server.

[0363] S1805, The server stores data to be uploaded.

[0364] Specifically, after receiving the data to be uploaded, the server can store the data.

[0365] In one example, a first device can be configured with a first client, on which a first account can be logged in; a second device can be configured with a second client, on which a second account can be logged in. Signaling interactions between the first and second devices can be performed by the first and second clients, respectively, while signaling interactions between the second device and the server can be performed by the second client and the server, respectively. For example, the first device can be... Figure 3 The user equipment 31 shown can be a second device. Figure 3 The shared device 32 shown can be a server. Figure 3 The cloud storage server 33 shown can be used as the first client. Figure 3 The cloud storage client 311 shown can be a second client. Figure 3 The cloud storage client 321 shown is illustrated.

[0366] Therefore, after receiving the first instruction, the first device can send a message to the second device instructing it to upload data. This allows the second device to upload its data to the server, enabling it to communicate directly with the server under the control of the first device. This shortens the data upload path, reduces latency, and provides an experience consistent with local file uploads, thus improving the user experience.

[0367] For example, Figure 19 Another method for cross-device data manipulation is shown. For example... Figure 19 As shown, the method may include the following steps:

[0368] S1901, the first device responds to the acquired second instruction by determining the target information of the data to be downloaded. The target information includes identification information and / or download path information, and the storage path represented by the download path information is located in the second device.

[0369] Specifically, a user can perform operations on the first device to issue a second command to the first device. For example, the operations performed by the user on the first device could be... Figure 12 or Figure 17 The file download operation described herein. The second instruction can be understood as an instruction generated after the user performs an operation on the first device. When the user performs an operation on the first device, the first device can determine the target information of the data to be downloaded based on the user's operation. This target information may include identification information and / or download path information, where the storage path represented by the download path information is located on the second device. For example, the process of determining the target information of the data to be downloaded can be found in [link to documentation]. Figure 12 or Figure 17 The descriptions of steps 1 and 2 are not repeated here.

[0370] In one example, the data to be downloaded may include one or more files.

[0371] S1902, the first device sends a second message to the second device, the second message including target information, the second message being used to instruct the second device to download the data to be downloaded from the server.

[0372] Specifically, after determining the target information of the data to be downloaded, the first device can send a second message containing the target information to the second device. This second message instructs the second device to download the data from the server. For example, the first message could be... Figure 8 The file download instructions described herein can also be used for Figure 12 or Figure 17 The collaborative download instructions described in [the document].

[0373] In one example, the second message also includes session credential information, which is an authentication credential between the first and second devices. For instance, the session credential information could be... Figure 9 The session credential information described in [the document / document].

[0374] Furthermore, before sending the second message to the second device, the first device can also determine the association between a first account on the first device and a second account on the second device; and generate session credential information. For example, determining the association between the first account on the first device and the second account on the second device can be understood as... Figure 9 The description above determines whether two accounts are the same account. Furthermore, before generating session credential information, the first device can also determine the association between a first version corresponding to the first account and a second version corresponding to the second account. For example, determining the association between the first version corresponding to the first account and the second version corresponding to the second account can be understood as... Figure 9Does the two versions described herein have overlapping capabilities? For example, the first account can be a device-level account, such as the account used to log in to a first device, or an application-level account, such as the account used to log in to one or more applications on the first device. Similarly, the second account can be a device-level account, such as the account used to log in to a second device, or an application-level account, such as the account used to log in to one or more applications on a second device.

[0375] Furthermore, the session credential information can also be generated by the second device. In this case, the second device can determine the association between the first account on the first device and the second account on the second device before receiving the second message, and generate the session credential information, which it then sends to the first device. Afterward, the first device can obtain the session credential information sent by the second device. Additionally, before generating the session credential information, the second device can determine the association between the first version corresponding to the first account and the second version corresponding to the second account. For example, when the first account is an application-level account, the first version corresponding to the first account can be the version of the application logged in by the first account; when the second account is an application-level account, the second version corresponding to the second account can be the version of the application logged in by the second account.

[0376] In one example, before sending the second message to the second device, the first device can also send a second request to the server. This second request requests the download of data to be downloaded. The server can respond to the received second request by generating download authentication information and sending it to the first device. Subsequently, the first device can obtain the download authentication information sent by the server. This information is used by the server to verify a third request from the second device for downloading data. The third request may include the download authentication information. For example, the second request could be... Figure 17 The download request message described in [the document] can contain download authentication information such as [the required information]. Figure 17 The download authentication information described herein. Furthermore, the first device may include this download authentication information in a second message so that the second device can obtain it.

[0377] Furthermore, before sending the second message to the second device, the first device can determine the association between the first version corresponding to the first account on the first device and the second version corresponding to the second account on the second device. For example, determining the association between the first version corresponding to the first account and the second version corresponding to the second account can be understood as... Figure 9 Does the two versions described in the text have overlapping capabilities?

[0378] S1903, the second device obtains the second message sent by the first device, and in response to the obtained second message, sends a third request to the server, the third request being used to request the data to be downloaded.

[0379] Specifically, after receiving the second message, the second device can send a third request to the server to request the download of the data. For example, the third request could be... Figure 12 or Figure 17 The file download request described in the document can contain data that can be downloaded. Figure 12 or Figure 17 The target file described in the document is to be downloaded.

[0380] S1904. The server responds to the received third request and determines the data to be downloaded.

[0381] Specifically, after receiving a third request from the second device, the server can find the data to be downloaded from its stored files.

[0382] In one example, when a third-party request includes download authentication information, the server can verify the request and determine if the verification passes. For example, the verification process can be found in [link to example]. Figure 17 The description in step 11 will not be repeated here.

[0383] S1905, The server sends the data to be downloaded to the second device.

[0384] Specifically, after the server determines the data to be downloaded, it can send the data to the second device.

[0385] S1906, The second device stores the data to be downloaded in the storage path represented by the download path information.

[0386] Specifically, after the second device obtains the data to be downloaded, it can store the data to be downloaded in the storage path represented by the download path information.

[0387] In one example, a first device can be configured with a first client, on which a first account can be logged in; a second device can be configured with a second client, on which a second account can be logged in. Signaling interactions between the first and second devices can be performed by the first and second clients, respectively, while signaling interactions between the second device and the server can be performed by the second client and the server, respectively. For example, the first device can be... Figure 3 The user equipment 31 shown can be a second device. Figure 3 The shared device 32 shown can be a server. Figure 3 The cloud storage server 33 shown can be used as the first client. Figure 3The cloud storage client 311 shown can be a second client. Figure 3 The cloud storage client 321 shown is illustrated.

[0388] Therefore, after receiving the second instruction, the first device can send a message to the second device instructing it to download data. The second device can then request data from the server, receive the data sent by the server, and store the data. This allows the second device to communicate directly with the server under the control of the first device, thereby shortening the data download path, reducing latency, and providing an operation experience consistent with local file downloads, thus improving the user experience.

[0389] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0390] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0391] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0392] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

Claims

1. A method for cross-device data operation, characterized in that, Applied to a first device, the first device can remotely access shared data on a second device, the shared data including data to be uploaded, the method includes: In response to the first instruction received, the first device determines the path information of the data to be uploaded in the shared data, wherein the data to be uploaded is located in the second device, and the first instruction is obtained based on the user's operation on the first device; The first device sends a first message to the second device. The first message includes the path information and session credential information. The session credential information is an authenticated credential between the first device and the second device, used to indicate that a collaborative session has been established between the first device and the second device. The first message is used to instruct the second device to upload the data to be uploaded to the server when a collaborative session has been established between the first device and the second device.

2. The method according to claim 1, characterized in that, The first message also includes identification information of the data to be uploaded.

3. The method according to claim 1, characterized in that, Before the first device sends the first message to the second device, the method further includes: The first device determines the association between a first account on the first device and a second account on the second device; The first device generates the session credential information; Alternatively, the first device may obtain the session credential information sent by the second device, wherein the session credential information is generated by the second device after determining the association between the first account and the second account.

4. The method according to claim 3, characterized in that, Before the first device generates the session credential information, the method further includes: The first device determines the association between the first version corresponding to the first account and the second version corresponding to the second account.

5. The method according to claim 2, characterized in that, Before the first device sends the first message to the second device, the method further includes: The first device sends a first request to the server, the first request being used to request the upload of the data to be uploaded; The first device obtains the upload authentication information sent by the server. The upload authentication information is generated by the server after obtaining the first request. The upload authentication information is used by the server to verify the data to be uploaded after obtaining the data to be uploaded sent by the second device.

6. The method according to claim 5, characterized in that, The first message also includes the uploaded authentication information.

7. The method according to claim 6, characterized in that, Before the first device sends the first message to the second device, the method further includes: The first device determines the association between the first version corresponding to the first account on the first device and the second version corresponding to the second account on the second device.

8. The method according to any one of claims 1-7, characterized in that, The data to be uploaded includes one or more files.

9. The method according to claim 8, characterized in that, The first device is equipped with a first client, on which a first account is logged in. The second device is equipped with a second client, on which a second account is logged in. The signaling interaction between the first device and the second device is performed by the first client and the second client.

10. A method for cross-device data operation, characterized in that, Applied to a second device, the second device having shared data, the shared data being remotely accessible to a first device, the shared data including data to be uploaded, the method includes: The second device receives a first message sent by the first device. The first message includes path information and session credential information of the data to be uploaded in the shared data. The session credential information is an authenticated credential between the first device and the second device, used to indicate that a collaborative session has been established between the first device and the second device. The data to be uploaded is located in the second device. The first message is used to instruct the second device to upload the data to be uploaded to the server when a collaborative session has been established between the first device and the second device. The first message is sent based on a first instruction obtained by the first device. The first instruction is based on the user's operation on the first device. The second device determines the data to be uploaded based on the path information; The second device sends the data to be uploaded to the server.

11. The method according to claim 10, characterized in that, The first message also includes identification information of the data to be uploaded; The second device determines the data to be uploaded based on the path information, specifically including: The second device determines the data to be uploaded based on the identification information and the path information.

12. The method according to claim 11, characterized in that, Before the second device receives the first message sent by the first device, the method further includes: The second device determines the association between the first account on the first device and the second account on the second device; The second device generates the session credential information and sends the session credential information to the first device.

13. The method according to claim 12, characterized in that, Before the second device generates the session credential information, the method further includes: The second device determines the association between the first version corresponding to the first account and the second version corresponding to the second account.

14. The method according to claim 10, characterized in that, The first message also includes upload authentication information, which is generated by the server after receiving the first request sent by the first device. The first request is used to request the upload of the data to be uploaded. The method further includes: The second device sends the upload authentication information to the server, and the upload authentication information is used by the server to verify the data to be uploaded.

15. The method according to claim 14, characterized in that, Before the second device receives the first message sent by the first device, the method further includes: The second device determines the association between the first version corresponding to the first account on the first device and the second version corresponding to the second account on the second device.

16. The method according to any one of claims 10-15, characterized in that, The data to be uploaded includes one or more files.

17. The method according to claim 16, characterized in that, The first device is equipped with a first client, on which a first account is logged in. The second device is equipped with a second client, on which a second account is logged in. The signaling interaction between the first device and the second device is performed by the first client and the second client.

18. A method for cross-device data operation, characterized in that, Applied to a first device, the first device can remotely access shared data on a second device, the shared data including data to be downloaded, the method includes: In response to the acquired second instruction, the first device determines the target information of the data to be downloaded in the shared data. The target information includes identification information and / or download path information. The storage path represented by the download path information is located in the second device. The second instruction is obtained based on the user's operation on the first device. The first device sends a second message to the second device. The second message includes the target information and session credential information. The session credential information is an authenticated credential between the first device and the second device, used to indicate that a collaborative session has been established between the first device and the second device. The second message is used to instruct the second device to download the data to be downloaded from the server when a collaborative session has been established between the first device and the second device.

19. The method according to claim 18, characterized in that, The second message also includes session credential information, which is an authenticated credential between the first device and the second device.

20. The method according to claim 19, characterized in that, Before the first device sends the second message to the second device, the method further includes: The first device determines the association between a first account on the first device and a second account on the second device; The first device generates the session credential information; Alternatively, the first device may obtain the session credential information sent by the second device, wherein the session credential information is generated by the second device after determining the association between the first account and the second account.

21. The method according to claim 20, characterized in that, Before the first device generates the session credential information, the method further includes: The first device determines the association between the first version corresponding to the first account and the second version corresponding to the second account.

22. The method according to claim 18, characterized in that, Before the first device sends the second message to the second device, the method further includes: The first device sends a second request to the server, the second request being used to request the download of the data to be downloaded; The first device obtains download authentication information sent by the server. The download authentication information is generated by the server after obtaining the second request. The download authentication information is used by the server to verify the third request sent by the second device. The third request is used to request the data to be downloaded, and the third request includes the download authentication information.

23. The method according to claim 22, characterized in that, The second message also includes the download authentication information.

24. The method according to claim 22 or 23, characterized in that, Before the first device sends the second message to the second device, the method further includes: The first device determines the association between the first version corresponding to the first account on the first device and the second version corresponding to the second account on the second device.

25. The method according to any one of claims 18-24, characterized in that, The data to be downloaded includes one or more files.

26. The method according to claim 25, characterized in that, The first device is equipped with a first client, on which a first account is logged in. The second device is equipped with a second client, on which a second account is logged in. The signaling interaction between the first device and the second device is performed by the first client and the second client.

27. A method for cross-device data operation, characterized in that, Applied to a second device, the second device having shared data, the shared data being remotely accessible to a first device, the shared data including data to be downloaded, the method includes: The second device receives a second message sent by the first device. The second message includes target information and session credential information. The session credential information is an authenticated credential between the first device and the second device, used to indicate that a collaborative session has been established between the first device and the second device. The target information includes identification information and / or download path information. The storage path represented by the download path information is located in the second device. The second message is used to instruct the second device to download the data to be downloaded from the server when a collaborative session has been established between the first device and the second device. The second message is sent based on a second instruction obtained by the first device. The second instruction is based on the user's operation on the first device. In response to the received second message, the second device sends a third request to the server, the third request being used to request the data to be downloaded; The second device acquires the data to be downloaded sent by the server and stores the data to be downloaded in the storage path represented by the download path information.

28. The method according to claim 27, characterized in that, Before the second device receives the second message sent by the first device, the method further includes: The second device determines the association between the first account on the first device and the second account on the second device; The second device generates the session credential information and sends the session credential information to the first device.

29. The method according to claim 28, characterized in that, Before the second device generates the session credential information, the method further includes: The second device determines the association between the first version corresponding to the first account and the second version corresponding to the second account.

30. The method according to claim 27, characterized in that, The second message also includes download authentication information, which is generated by the server after receiving the second request. The download authentication information is used by the server to verify the third request sent by the second device, wherein the third request includes the download authentication information.

31. The method according to claim 30, characterized in that, Before the second device receives the second message sent by the first device, the method further includes: The second device determines the association between the first version corresponding to the first account on the first device and the second version corresponding to the second account on the second device.

32. The method according to any one of claims 27-31, characterized in that, The data to be uploaded includes one or more files.

33. The method according to claim 32, characterized in that, The first device is equipped with a first client, on which a first account is logged in. The second device is equipped with a second client, on which a second account is logged in. The signaling interaction between the first device and the second device is performed by the first client and the second client.

34. A cross-device data operating system, characterized in that, include: A first device, a second device, and a server; the first device can remotely access shared data on the second device. Wherein, the first device is used to perform the method as described in any one of claims 1-9, the second device is used to perform the method as described in any one of claims 10-17, and the server is at least used to store the data to be uploaded sent by the second device; Alternatively, the first device is configured to perform the method as described in any one of claims 18-26, the second device is configured to perform the method as described in any one of claims 27-33, and the server is configured to at least send data to be downloaded to the second device after receiving a third request sent by the second device, the third request being used to request the acquisition of the data to be downloaded.

35. An electronic device, characterized in that, include: At least one memory for storing programs; At least one processor is configured to execute a program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to perform the method as described in any one of claims 1-33.

36. A computer-readable storage medium storing a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1-33.

37. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-33.

Images