System and method for remote ownership and content control of media files on untrusted systems

Abstract

An example method includes receiving, by a client computing device, a request to open, at the client computing device, a super file stored in a memory device, the super file including encrypted content, the request including user credential information; in response to receiving the request to open the super file, passing, by the client computing device, the request to a remote server to access the super file, the request including credentials associated with a user account; receiving, from the remote server, cryptography information; using the cryptography information to decrypt the encrypted content; accessing and presenting the decrypted content; and maintaining communication with the remote server while the decrypted content is accessed.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 056,288, filed July 24, 2020, entitled "New computer file type that istrackable, has analytics, has the ability to change access at any time, isable for the owner of the file to update it, and then it updates everyone file who has the file," the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application generally relates to remote control of access to media content, and more specifically to systems and methods for remote ownership and content control of media files on untrusted systems. Background Technology

[0004] Computing systems can store data in different ways. One common way to store data is in files on non-volatile memory devices, such as hard drives. Data in these files can be accessed by different applications running on the computing system, and the files can be copied to other storage devices. Summary of the Invention

[0005] Various examples of systems and methods for remote ownership and content control of media files on untrusted systems are described. One example method includes: receiving, via a client computing device, a request to open a superfile stored on a storage device, the superfile comprising encrypted content, the request including user credential information; in response to receiving the request to open the superfile, passing the request via the client computing device to a remote server to access the superfile, the request including credentials associated with a user account; receiving cryptographic information from the remote server; using the cryptographic information to decrypt the encrypted content; accessing and presenting the decrypted content; and maintaining communication with the remote server while accessing the decrypted content.

[0006] Another example method includes: receiving a request from a remote client device to access encrypted content within a super file, the request including user credential information, the super file stored on the remote client device's storage device, and the encrypted content; determining an authorization level for accessing the encrypted content; in response to determining the authorization level: providing cryptographic information to the remote client device; and when the super file is opened at the remote client device, receiving and storing usage information from the remote client device associated with the encrypted content.

[0007] Another example method includes: receiving an instruction from a remote client device to create a new super file; creating one or more records in the data store associated with the new super file; storing one or more cryptographic keys in one or more records, one of which is used to encrypt the contents of the super file; and receiving and storing a copy of the super file.

[0008] These illustrative examples are not intended to limit or define the scope of this disclosure, but rather to provide examples to aid in understanding it. Illustrative examples are discussed in the detailed description, which provides further description. By studying this specification, the advantages offered by the various examples can be further understood. Attached Figure Description

[0009] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more specific examples and, together with the description of the examples, serve to explain the principles and implementation methods of those specific examples.

[0010] Figure 1 An example system for remote ownership and content control of media files on untrusted systems is shown; Figure 2 An example structure of a superfile is shown; Figure 3 An example system for remote ownership and content control of media files on untrusted systems is shown; Figure 4 An example sequence diagram of the process involving remote ownership and content control of media files on an untrusted system is shown; Figures 5 to 8 An example method for remote ownership and content control of media files on untrusted systems is shown; and Figure 9 An example computing device is shown that is suitable for use with example systems and methods for remote ownership and content control of media files on untrusted systems. Detailed Implementation

[0011] Examples of systems and methods for remote ownership and content control of media files on untrusted systems are described herein. Those skilled in the art will recognize that the following description is merely illustrative and not intended to be limiting in any way. Implementations of the examples shown in the accompanying drawings will now be described in detail. The same reference numerals will be used throughout the figures and the following description to refer to the same or similar items.

[0012] For clarity, not all routine features of the examples described herein are shown and described. It will be appreciated that in the development of any such practical implementation, many implementation-specific decisions must be made to achieve the developer’s specific goals, such as adhering to application and business-related constraints, and these specific goals will vary between different implementations and between different developers.

[0013] Computers are ubiquitous in modern society and are commonly used to create, exchange, view, and edit photos, videos, documents, and other types of files. However, most computer files lack the functionality to allow the owner of the content contained within them to exercise control over that content. While some applications allow users to password-protect or lock files to prevent editing, this functionality applies to the file itself, and once the file is distributed to others, the owner subsequently has no ability to change these restrictions unless they provide the necessary password or a backup copy of the file that has not been locked for editing.

[0014] Alternatively, computer files can be stored and shared via online platforms (such as cloud services) that allow different users to access files on the platform, such as viewing or editing them. However, control over these files is provided by the platform itself and is not native to the files stored on the platform. Therefore, file sharing is limited to sharing a reference to the location where the file is stored and interacting with the platform, which retains control over the file. While this configuration offers certain advantages, it requires all users to access the same copy of the file, where access is coordinated by the platform.

[0015] To enable content creators to widely distribute their content as discrete files that can be copied or shared like traditional files, users can save content into a file structure called a "hyperfile." A hyperfile includes content already created by the file's author (i.e., video, audio, text, spreadsheets, etc.) and information that enables computing devices or client devices to communicate with remote servers to obtain access to the hyperfile's content or to provide information about the use of the file's content and any restrictions imposed on users.

[0016] The example super file includes a header section and a content section, where the content is encrypted, but the header is not. The content section includes any content that the file's creator or editor has generated. Conversely, the header section includes information that enables the user's client device to request cryptographic information to decrypt and access the super file's content.

[0017] When a user attempts to open a super file, the operating system detects the file type as a super file, for example, by detecting the .super file extension (e.g., movie.super), and accesses the super file's header. From the header, the operating system extracts information identifying the server computer (or computer), which can be encoded as a Uniform Resource Identifier (“URI”), such as a Uniform Resource Locator (“URL”), and identifiers for the super file, such as a file ID and a cryptographic hash value. It then uses the URL to contact the server and provides the file ID and hash value, along with user credentials.

[0018] The server receives a file ID and a hash value, and verifies that both match the corresponding information about the file. In this example, when a new superfile is created or modified, the server adds a blockchain to the blockchain network, thereby gaining access to the blockchain corresponding to the file ID, and verifies whether the hash value received from the client computer matches the hash value stored in the blockchain. If they match, the server confirms that the blockchain corresponds to the identified superfile, and that the superfile is authentic.

[0019] After identifying the corresponding record in the HyperFile blockchain, the server determines whether to accept the provided user credentials. For example, a user might have a user account on the HyperFile server. Therefore, user credentials could be the user's username and password, or it could be other verifiable information used to establish the user's identity, such as a cryptographic signature. The server is then able to verify the user's identity and access any blockchain records to determine if the user has accessed a file or a separate data store containing such information.

[0020] After receiving the decryption key, the client device decrypts the file's contents in its storage and presents them to the user, while maintaining a connection with the SuperFile server and deleting the decryption key. When the client device opens a SuperFile, it can send information to the SuperFile server, such as which parts of the content it is viewing, how long the file has been open, how much idle time has been detected, and whether the user attempted to copy or edit the content. The SuperFile server stores the received information in a data storage record corresponding to the SuperFile's blockchain record. After the user closes the SuperFile, the user's computer deletes the decryption key and stops presenting the SuperFile's contents.

[0021] While this example provides a simple illustration of user access to a superfile, one advantage of superfiles is that the superfile owner can edit its contents or change the access level to the superfile, which can then be propagated in real time to any copies of the superfile and opened on the user's computer. For example, if the superfile owner edits text in a superfile document, these edits are sent to a superfile server, which then provides them to each copy of the file that is currently open on other client computers. These other client computers then receive the edited content and not only update the contents of the superfile itself but also dynamically change the decrypted content displayed for the user to view. Thus, the user sees the updates made by the file owner in near real-time. When one of the users viewing the superfile closes it, the changes received at that moment are stored in their copy of the superfile. For any user who did not view the superfile but later accesses it, they will be immediately provided with the updated content, as if they were granted access to the superfile upon approval. Therefore, superfiles provide a way for users to use superfiles like any traditional file, but with near real-time updates.

[0022] Similarly, the owner of a superfile can change access restrictions on the superfile's contents, which can then be propagated near real-time to any other copies of the file that are currently open. For example, if the owner revokes a user's access while the user is opening a superfile, the superfile server sends a message to the client's computer, which immediately stops providing the decrypted content to the user by rewriting the memory containing the decrypted content, thus preventing the user from accessing the content. It can also provide notification that the user's access permissions have been revoked by the owner.

[0023] Using HyperFiles, content creators can allow anyone to freely copy their work while still retaining control over access to it. Furthermore, usage information collected by HyperFiles servers allows users to monitor engagement with their content, enabling them to monetize it directly, for example, by selling access to the content, or indirectly, such as by selling accompanying advertising. Moreover, by employing blockchain as the mechanism for recording information about HyperFiles, the authenticity and ownership chain of HyperFiles can be verified by accessing the blockchain.

[0024] This illustrative example is given to introduce the reader to the general topics discussed herein, and this disclosure is not limited to this example. The following sections describe various additional, non-limiting examples, as well as examples of systems and methods for remote ownership and content control of media files on untrusted systems.

[0025] Now refer to Figure 1 , Figure 1 An example system for remote ownership and content control of media files on an untrusted system is illustrated. The example system includes a creator device 130 and multiple client devices 120a-n, which are capable of communicating with a super file server 110 via one or more communication networks 140. Each of these computing devices 110, 120a-n, 130 includes a corresponding data storage 112, 112a-n, 132, wherein the respective computing device is capable of permanently storing and accessing one or more data files.

[0026] Each user of client devices 120a-n or creator devices 130 is able to use the corresponding device to do many different things, such as creating or viewing creative content. This content is typically created using one or more software applications and then stored in one or more data files (or simply “files”) on the user’s client device 120a-n. The user (or “creator”) can then share this content with other users by providing copies of (multiple) related files, whether or not the creator is aware of it. Recipients then have access to (multiple) files and can view the content, and in some cases, edit it. However, once recipients receive a copy of the file, they possess a separate electronic package containing all the content, which they can then freely access and use.

[0027] In the example system 100 shown, each client device 120a-n is operated by one or more users and is generally referred to as an "untrusted" client relative to the creator device 130. In this sense, "untrusted" refers to a device operated independently and autonomously by the user, without the creator's control. Therefore, the creator cannot access the user's client devices 120a-n, such as preventing actions from being taken relative to content that other users might wish to take. Furthermore, without using this example system 100, the creator would lack the ability to determine whether they are the creator of the content or to track other users' use of their own data files.

[0028] To allow creators to maintain control over their content, they can save their content as part of a superfile. A superfile is a file that includes the functionality to request permissions from a superfile server to access its content. However, in addition to initially opening the file to access its content, a superfile needs to continuously communicate with the superfile server to ensure that permissions to access the file content are not altered or revoked, and to track user usage of the file's content.

[0029] When a user receives a super file, they receive the entire super file, which appears as a regular file. Therefore, the receiving user (or "receiver") owns the entire file and its contents, not just a portion of a file residing on a remote computer. In some examples, super files can also be identified by a filename extension (e.g., .super), although in other examples, super files may not have a filename extension or a specific filename extension.

[0030] To access a file, a user can attempt to open it using their client device (e.g., client device 120a), just as they would any other file, for example, by selecting and double-clicking the superfile's file icon using the mouse. The operating system (“OS”) executed by the receiving client device can detect the command to open the file based on user input and determine if the file is a superfile, for example, based on the file extension or by accessing header information within the superfile (discussed in more detail below). After determining that the file is a superfile, the OS can first attempt to open the file natively, or it can launch an application installed on the receiving client device to open the file. For example, the content header can indicate the type of content stored in the superfile, and the client device can open an application corresponding to that type of content.

[0031] To open a file, the OS or an application (both referred to as "application") attempts to contact the superfile server, such as superfile server 110. To do this, the application may issue a DNS request to obtain the network address of a pre-configured server name, such as files.superfile.org. The DNS response provides a network address, such as an Internet Protocol ("IP") address, which the application then uses to contact superfile server 110. Before or during communication with server 110, the application may also attempt to authenticate the identified server, for example, through authorization via a trusted certificate.

[0032] After establishing communication with the superfile server 110, the application requests access to the content. The superfile server 110 can determine whether the application or the corresponding user has permission to access the content, and if so, can transmit the information needed to decrypt or decompress the superfile's content. Upon receiving the information, the application uses it to decrypt or decompress the content, and then the application can either render the content itself or execute a separate application to render the content. In this example system, when decrypting the content, it is only decrypted to volatile system memory so that it can be presented to the user. A decrypted copy of the superfile is not created. This may help ensure that the security of the superfile content is not altered or revoked during event access.

[0033] When content is presented to the user, typically while the super file remains "open," the application maintains communication with the super file server and sends usage information to the server, such as how long the user has had the file open, which parts of the content are being viewed or presented, and so on. The super file server 110 can store this information in its data storage 112 and associate it with the record corresponding to the super file.

[0034] If an application loses contact with the superfile server 110 while the superfile is open, the application can immediately terminate access to the superfile by actions such as deleting information required to decrypt or decompress the content (if it hasn't already been deleted), deleting or rewriting any information from the superfile content that has been copied to storage to enable the content to be displayed, closing any separate applications used to view the content, and so on. In some examples, instead, the application can wait for a predetermined period of time, such as five or ten minutes, before terminating access to mitigate issues associated with intermittent network outages. Access can be restored if communication with the superfile server resumes, or the predetermined period can be reset if access has been terminated.

[0035] When a user attempts to access a superfile, access can be granted based on permissions established by the creator of the content within the superfile. For example, the creator can have "owner" access, which allows them to freely edit or delete content, change permissions for different users, or transfer ownership of the content to another user. Other users can have "viewer" access, which allows them to view the content but not edit it. Some users can have "editor" access, which allows them to edit the content but does not perform ownership functionalities such as enabling other users to view the content. Other types of permissions can be established.

[0036] The different permission levels for each file can be maintained by one or more superfile servers (e.g., superfile server 110). Therefore, when a user attempts to access a superfile, superfile server 110 can determine whether the user has permission to access the contents of the superfile, and if so, to what extent—e.g., owner, editor, viewer, etc. Permission levels can affect a user's ability to modify or save changes to the contents of a superfile. For example, a user can open a document saved as a superfile with only "viewer" permissions for the content. To prevent users from editing files, applications, such as operating systems or editing applications (e.g., word processing applications), can open the file as "read-only" to prevent users from editing the contents of the superfile.

[0037] Because superfiles can be freely distributed, any number of copies of a particular superfile can be opened in a loop and simultaneously. Therefore, a user on one client device (e.g., client device 120a) can open a copy of the superfile, while a user on another client device 120b can also open a copy of the superfile. The two client devices 120a and 120b will communicate with the superfile server 110, typically as discussed above.

[0038] Because client devices 120a and 120b maintain communication with the superfile server 110, any updates to the superfile's content, such as those made by the owner or "editor," are immediately propagated to any client device 120a or 120b that has a copy of the superfile opened by the superfile server. Conversely, any client device that does not have a copy of the superfile open will receive the updated content the next time it opens the superfile. Similarly, if user permissions change, the updated permissions are immediately propagated to any affected user who has opened the superfile. For example, if a user has "editor" permissions, and those permissions change to "viewer" permissions when they open the file, their client device will receive the changed permissions from the superfile server 110, preventing any changes from being saved to the superfile. In some cases, changes made by an editor will be rolled back if the superfile was opened before the permissions changed, although in other cases, the prohibition on editing will only be forward-looking. Furthermore, if a user's own permissions to access the file are revoked, the superfile content immediately becomes inaccessible, for example, by closing the superfile and discarding any cryptographic information used to access the content. In some examples, the super file can remain open, but its content will no longer be displayed; instead, an indication that the permissions have been changed will be shown.

[0039] It should be recognized that because client devices 120a-n are not under the control of super file server 110, super file server 110 itself cannot ensure that a user has not tampered with one or more applications executed by the client device to enable functionality that is otherwise prohibited. However, even if a user secretly modifies the contents of the super file, the modification can be detected by the super file server or another client device 120a-n that has not yet been tampered with. As mentioned above, a user with "editor" permissions is able to modify the contents of the super file, which is then propagated to super file server 110 and then to other users who have copies of the super file. However, if a user tampers with the super file to modify its contents, super file server 110 will refuse the modification based on the permissions maintained by super file server 110. Therefore, a user can modify a copy of the super file, but it will not be extended to others via super file server 110. Alternatively, a user may tamper with the contents of the super file and attempt to distribute the file to another user (the "recipient" in this example), for example, via email.

[0040] When a recipient attempts to access a superfile that has been tampered with, their client device will contact the superfile server 110 as described above, and may be presented with a message indicating that the file's content differs from the superfile's currently known state. In some examples, the superfile server 110 may instead detect the file content difference between the user's copy of the superfile and the superfile's currently known state, and then send the correct file content to the user to replace the content in the user's copy. Other example actions may be taken, such as presenting the user with an error indicating that the file content has been tampered with.

[0041] The functionalities enabled by the example system 100 are based on the structure of the super file (described below), the use of the super file server 110, and in some examples, on a blockchain network.

[0042] Reference Figure 2 , Figure 2 An example file structure for a superfile 200 is shown. In this example, superfile 200 includes a header 210 and a content payload 220. The content payload 220 includes any kind of content created by the creator. Examples of suitable content include written works (e.g., articles, books, scripts, etc.), audio or visual works (e.g., music, videos, images, etc.), technical information (e.g., 3D printer plans, computer-aided design or manufacturing documents, etc.), and so on. In some cases, the content payload 220 may include another superfile.

[0043] To protect the contents of a superfile from unauthorized access, in some examples, the content payload 220 may be encrypted or compressed, or both. Any suitable encryption technology can be used depending on the specific example, such as symmetric-key encryption, like the Advanced Encryption Standard (AES) family of encryption techniques, such as AES-256, or asymmetric-key encryption. In addition to (or alternative to) encryption, compression techniques, such as LZ compression, can be used to reduce the size of the content payload 220. For content payloads 220 that do not contain credential information, such as user manuals, resumes, etc., compression may be sufficient, while for other types of information, encryption may be necessary. However, the creator of the superfile can choose whether to use encryption or compression, and if so, the type to use. Furthermore, the creator (or another user with sufficient privileges) can change or remove (or reapply) the encryption or compression of the superfile at any time.

[0044] The superfile header 210 includes information identifying the file as a superfile, a unified identifier for the superfile, information indicating the type of encryption or compression applied to the content payload 220, and a checksum or hash value for the content payload 220. It may also include certain cataloging information, such as the creator of the superfile, the creation date of the superfile, the checksum or hash value of the cataloging information, and the checksum or hash value of the entire superfile 200. Typically, the superfile header 210 may include any information about superfiles that might be needed for maintenance using the superfile content, as well as certain information that might be needed to enable client devices to contact the superfile server and access the content payload 220.

[0045] Example superfile 200 is described as including a header section 210 and a content payload 220; however, it may also include other sections, such as trailers. In some examples, superfile 200 may include multiple content payloads 220, each accessible individually depending on the user's permission level. For example, superfile 200 may have two content payloads 220, one of which can be viewed by anyone with a copy of the file, such as a movie trailer or a book preface, while the other can only be accessed after purchasing access, such as the entire movie or book. Therefore, superfiles can have any suitable structure for storing, regulating, and monitoring access to content.

[0046] Now refer to Figure 3 , Figure 3 Another example system 300 is shown for providing remote ownership and content control of media files on untrusted systems. Figure 3The example system 300 shown includes multiple super file servers 310a-m and multiple client devices 320a-n, which collectively implement a blockchain network 330 including a blockchain 332a-k. The blockchain 332a-k provides a permanent, immutable record of the super file, enabling the super file servers 310a-m and client devices 320a-n to track and verify the super file over time on different computing systems based on these records.

[0047] In this example, the super file server 310a-m has the ability to read and write to blockchain 332a-k, while the client device 320a-n can read records in blockchain 332a-k. However, in some examples, only the super file server 310a-m can access the blockchain network. When a new super file is created, the creator's client device contacts the super file server, for example, super file server 310a, and registers the super file. Super file server 310a receives a copy of the super file and establishes a blockchain for the super file. When other users receive a copy of the super file (or when the creator accesses the super file again), they can verify the integrity of the super file by accessing the corresponding blockchain and traversing it as needed. The blockchain also provides ownership information about the super file, which can include records of information about the creator of the super file and ownership transfers from user to user. When changes are made to the super file, super file server 310a-m adds blocks to the blockchain, providing an audit trail of changes made to the super file over time.

[0048] In this example system, the hyperfile server 310a-m is hosted by a trusted third-party hyperfile service provider; however, in some examples, users (e.g., creators) or organizations can operate their own (multiple) hyperfile servers to manage their own network of hyperfiles and blockchains. For example, a film company could manage its own (multiple) hyperfile servers and blockchain network 310, enabling it to create hyperfiles to manage access to its released films, or to release updates over time or embed different features within the films. For instance, a film company could update a film's hyperfile to change trailers or marketing campaigns associated with various films. Similarly, other creative organizations, such as advertising agencies, recording studios, research labs, etc., could manage their own (multiple) hyperfile servers and blockchains, allowing users to access their content while monitoring and maintaining control over its use.

[0049] Therefore, the example systems according to this disclosure may include the use of a blockchain network to ensure the authenticity and validity of the superfile, while (multiple) superfile servers coordinate access to the superfile content. However, the use of blockchain is an optional feature in some example systems and may be omitted in others.

[0050] Now refer to Figure 4 , Figure 4 An example sequence diagram is shown, depicting interactions within a system for remote ownership and content control of media files on an untrusted system, according to this disclosure. The system includes several client devices 410a-c, a super file server, and a blockchain network 430.

[0051] This sequence begins with client device 410 creating content and saving it as a super file 440. This causes client device 410a to transmit a message to super file server 420, indicating that a new super file has been created. In this example, client device 410a also transmits a copy of the super file to server 420. The super file includes a header section and a content payload, similar to the one described above. Figure 2 The example superfile discussed. The header section includes the superfile's Uniform Identifier, which the client device 410a previously requested from the superfile server. However, in some examples, the client may create and save the superfile, and in response, receive the superfile identifier from the superfile server 420. The client device 410a then inserts the superfile identifier into the superfile header section.

[0052] In this example, the super file server 420 takes several different actions in response to receiving a new file 440 message from the client device 410a. The super file server 420 generates a uniform super file identifier, which is provided to the client device 410a (not shown) and inserted by the client device 410a into the header of the new super file. In some examples, the client device 410a may generate the uniform identifier or request a super file identifier from the super file server 420.

[0053] The super file server 420 also creates a new blockchain 442 in the blockchain network 430 corresponding to the new super file. It includes information about the super file, such as the super file identifier, checksum or hash value (e.g., a cryptographic hash), timestamp, creator name or identifier, owner name or identifier, etc. In some examples, blockchain 442 may include a copy of the super file itself.

[0054] In this example, as mentioned above... Figure 3The blockchain network under discussion can be distributed across multiple super file servers and client devices. Therefore, adding a new blockchain to a blockchain network can involve distributing one or more blocks among different computing devices, such as super file servers 420 or one or more client devices 410a-c.

[0055] After creating a super file, the creator of the super file 444 provides a copy of the super file 444 to another user at a different client device 410b. For example, the creator can send the super file to the recipient via email or can save it to a portable storage device (e.g., a thumb drive, portable hard drive, etc.), which can then be physically connected to other client devices 410b. Because super files are independent units, like traditional files, and are stored as traditional files by computing devices, they can be easily transferred to other computing devices or storage devices.

[0056] The receiver then uses its client device 410b to open the super file 446. To open the super file, the user can double-click the icon corresponding to the super file, such as in a graphical user interface (“GUI”) provided by the client device’s OS. In response to the user input to open the super file, the receiver’s client device 410b determines that the selected file is a super file and determines the super file server to contact to open the file. For example, the application can extract information from the super file itself to contact the super file server, such as using the URI or IP address stored in the super file’s header. The application can then transmit one or more messages to the super file server 420 via one or more networks to access the super file content payload.

[0057] The messages sent by client device 410b may include user credential information, such as user identity information or information that can be used to establish the user's identity. The messages may also include information about the super file, such as a super file identifier, checksum, or hash value, which can be used to identify the super file that client device 410b is attempting to open. If user credential information is not provided, the super file server 420 may request it.

[0058] In response to a request to open file 446 received from client device 410b, super file server 420 determines whether the recipient has permission to access the super file, and if so, assigns them a certain access level. Super file server 420 can also perform checks on the super file itself, such as determining whether the received checksum or hash value matches the checksum / hash value stored in the corresponding blockchain record of the super file. Additionally, super file server 420 can determine whether the super file content payload has been updated since the recipient received the file from the creator at item 444. For example, super file server 420 can search the blockchain corresponding to the super file to identify a record with a checksum / hash value that matches the checksum / hash value received from client device 410b.

[0059] If the received checksum / hash value matches the latest version of the superfile in the blockchain, the superfile server 420 determines that the client device 410b has the latest version of the superfile. However, if it matches an earlier version of the superfile's blockchain record, it can update the superfile at the client device 410b, which will be described in more detail below with respect to items 470 and 472. If the checksum or hash value does not match any block in the blockchain, the superfile server 420 can either send an error message or update the superfile.

[0060] If the superfile server 420 determines that the recipient has permission to access the superfile's content payload, it can send the information required to access the content payload (458). This information could be one or more cryptographic keys, an identifier of the compression algorithm used to compress the content payload, etc. However, in some examples, the content payload cannot be encrypted or compressed; in this case, the superfile server 420 can respond by indicating that decryption or decompression is not required. Further, in some examples, the superfile itself can indicate whether the content payload is encrypted or compressed. If the superfile indicates that it is neither encrypted nor compressed, it may not receive the information at item 448. Instead, the client device 410b can establish communication with the superfile server 420 and maintain communication while the superfile is open. Once the client device 410b receives the access information, it can access the content payload. However, in this example, when the client device 410b decrypts the superfile content, it only decrypts the content to volatile system memory so that it can be presented to the user; it does not decrypt the content to non-volatile storage. Therefore, no separate file is created for the decrypted client. This may help prevent access to content without first contacting the super file server 420.

[0061] When client device 410b is accessing a content payload, it can report information about its usage 450 of the super file to super file server 420. Usage information can be reported periodically, for example, once per minute, or in response to events occurring when the super file is opened, such as scrolling to a new page, playing / pausing / rewinding a movie or video, zooming in on a photo, etc. Usage information can include identifiers of actions taken relative to the content payload (e.g., those mentioned above), how long the content payload has been open, how long client device 410b has been active or idle, the time the content payload is in the foreground or background of the GUI presented to the user, the time the content is minimized, etc. It can also detect potential unauthorized actions, such as attempting to capture a screenshot of the presented content, attempting to modify the content payload, attempting to export the content payload to a separate file, etc. This usage information can be reported to super file server 420, which can maintain statistics associated with the super file. This information can be used to determine content engagement levels, identify different user interests, determine advertising or other monetization information related to the content, etc. This information can be accessed by the creator or owner of the superfile, and can be obtained by making a request to the superfile server 420 or by accessing an account maintained by the superfile server 420.

[0062] At some point, the receiver may further distribute the super file to other users, such as the user of client device 3 (410c) (the "second" receiver). Regarding item 444, the receiver may use any suitable mechanism to distribute the super file to any other user. Then, if the second receiver is authorized to access the content payload, the second receiver may attempt to open the super file, which initiates a similar process of sending one or more messages 462 to the super file server 420 and receiving access information 464. Then, when the super file is opened, the second receiver's client device 410c also maintains communication with the super file server 420 and may report usage information 466 to the super file server 420 as discussed above with respect to item 450.

[0063] At times, the creator, owner, or other editor of a superfile (referred to as the creator in this example) may modify the superfile's content payload. When this occurs, client device 410a reports the modification to superfile server 420. Modifications can be reported in real time as the creator modifies the superfile, although in some examples, modifications may only be reported when the user saves the changes to the superfile or closes the superfile. Modifications can be any changes to the superfile, including changes to the content payload, header section, or any other aspect of the superfile. These modifications can include changes to owner or permission levels, changes to the content payload, and so on.

[0064] When modification report 467 is sent to super file server 420, super file server 420 adds a new block to the blockchain associated with the super file and stores it in blockchain network 430. Therefore, the blockchain maintains a permanent, immutable record of the super file because it is revised over time.

[0065] In addition to updating the blockchain, the super file server 420 also identifies any other client devices that have the super file open while modifications are being made. In this example, the super file server 420 identifies two other client devices 410b-c that have an open copy of the super file based on the connection maintained with client device 410b-c. After identifying client devices 410b-c, the super file server 420 provides super file updates to each client device 410b-c, where the updates are applied to the super file and stored. Furthermore, the rendered content of the super file (if modified) is updated in real time for users to view. Therefore, when the creator revises the file, they can see the changes to the file content in real time or near real time.

[0066] Later, the creator changed the file access permissions 480 for the superfile's content payload. These changes were reported to the superfile server 420, similar to the modifications to file 467 discussed above.

[0067] In response to receiving a changed file access permission, the super file server 420 determines that the client device 410b-c now lacks permission to access the contents of the super file, and therefore the super file server 420 transmits one or more messages 482, 484 to the client device 410b-c, causing them to immediately cease rendering the contents of the super file, and discarding any access information previously received by the respective client device 410b-c, such as cryptographic keys, if not already discarded. To further protect the content from unauthorized access, the client device 410b-c may also rewrite the memory containing the decrypted content to ensure it has been completely removed from the client device. Therefore, the creator can revoke (or grant) access to anyone who has a copy of the super file in real time.

[0068] It should be recognized that this example sequence uses only a relatively small system with a single super file server 420 and three client devices 410a-c to illustrate certain functionalities. However, imagine systems with a large number of components, such as dozens, hundreds, thousands or more super file servers interacting with tens of thousands or even more client devices, and these systems are capable of providing similar functionality as described above, but on a significantly larger scale.

[0069] Now refer to Figure 5 , Figure 5 An example method 500 is shown, which creates a new superfile as part of a system for remote ownership and content control of media files on an untrusted system. In this example, method 500 involves two different computing systems performing different aspects of the method. And while these aspects may be related, each computing system performs its own unique method, which may involve receiving input from another computing device or sending information to another computing device.

[0070] At box 512, the user of client device 510 can create file content of any suitable type, such as documents, audio, video, source code, etc. The user can use any suitable authoring or capture tool to create the file content, such as word processing programs, source code editors, cameras, etc. The user can store this content in any suitable file according to any suitable file format.

[0071] At box 514, the user selects to store content as a super file. This can be done after the content has already been stored in an existing file according to a file format, or the user can initially save the content as the content of a super file. To do this, the user can interact with the application and select options to save or export the content (e.g., content stored in volatile memory or content stored in a file on non-volatile memory) to a new super file. The application can then generate a super file according to a suitable super file structure and store the content in the super file's content payload. During this process, the application can prompt the user for certain information, such as access control information, selection of one or more encryption options, selection of one or more compression options, selection of a super file server provider, etc. Based on the provided information, the application can generate or supplement the header section of a new super file. The application can then store the content of the super file to non-volatile memory, such as a hard drive or cloud storage.

[0072] When a super file is created, client device 510 contacts super file server 520, such as a super file server selected by the user or automatically selected by the application, and provides an indication that a new super file has been created. Additionally, client device 510 provides information about the super file, including part or all of the header information or part or all of the content payload. In some implementations, super file server 520 may generate a Uniform Identifier for the super file, which is provided to client device 510; however, in some examples, client device 510 may generate its own Uniform Identifier for the super file.

[0073] In addition to obtaining a unified identifier, if the superfile contains encrypted content, the client device 510 can generate one or more cryptographic keys to encrypt the content, or it can request such keys (or multiple keys) from the superfile server 520. The client device 510 then uses the cryptographic keys to encrypt the contents of the superfile.

[0074] At box 522, the super file server 520 registers the super file by creating a record in the data storage corresponding to the super file. The record may include information about the super file, such as the super file identifier, the super file owner, the super file's checksum or hash value, etc. It may also include part or all of the super file's content payload and cryptographic information, such as symmetric cryptographic keys, asymmetric cryptographic key pairs, or compression information. In addition to creating a record in the data storage, the super file server 520 may also generate an acknowledgment and provide it to the client device 510, indicating that the super file has been successfully created.

[0075] At box 524, the super file server 520 adds a blockchain to the blockchain network. The new blockchain is associated with a new super file, and blocks are created within the blockchain based on the new super file. A block can include information similar to that discussed above relative to box 522. It can also include part or all of the super file's content, such as the header portion or the content payload. By including the content payload, the super file server 520 is able to provide the content payload to other computing devices that open the super file, such as updating a copy of the super file with the current content or fixing a corrupted copy of the super file. Furthermore, any suitable information can be stored in blocks within the blockchain, depending on the implementation method.

[0076] Once a superfile has been created and registered with the superfile server 520, the creator can freely distribute the superfile to any other user, who can then access the superfile content as discussed in more detail below.

[0077] It should be recognized that not all hyperfile systems can use blockchain technology. Therefore, in some examples, box 524 can be omitted.

[0078] Now refer to Figure 6 , Figure 6 An example method 600 for accessing, modifying, and updating a superfile is shown. In this example, method 600 involves three different computing systems performing different aspects of the method. And while these aspects may be related, each computing system performs its own unique method, which may involve receiving input from another computing device or sending information to another computing device.

[0079] At box 612, client device 610 obtains a copy of the super file. For example, it can receive the super file via email or by downloading it from a website. In some examples, the user can use a portable storage device and connect it to client device 610 to obtain the super file.

[0080] At box 614, client device 610 opens a super file. Opening a super file may involve accessing the contents of the super file, although it may not involve being able to access encrypted or compressed data stored within the super file's content payload. A user can use client device 610 to open a super file, typically as described above, such as, relative to... Figure 4 Items 446 and 462. Furthermore, opening a super file may involve transmitting information to a super file server 630 to obtain access to the contents stored within the super file, as discussed above with respect to items 446 and 462.

[0081] At box 632, the super file server 630 receives user credential information from client device 610, which may indicate the identity of the user on client device 610. The user credential information may include user account information (e.g., username and password), an authentication token associated with the user identity established with a trusted entity, and so on. In some examples, if no user credential information is received, the super file server 630 may respond to client device 610 to request the user credential information. In some examples, if the super file server 630 does not receive user credential information, it may treat the user as an anonymous user.

[0082] At box 634, the super file server 630 determines access permissions for the super file for the user of the client device 610. Access permissions can be established for individual users, predefined user groups, etc. Therefore, based on user credential information, the super file server 630 can determine whether a user has specific access permissions, such as access to view, edit, transfer ownership, etc., of the super file. Such access permissions can be applied to data storage accessible by the super file server 630 (such as the data accessed above relative to the super file). Figure 5 It is stored in the data storage discussed in box 522, or within the blockchain of the super file.

[0083] Access permissions for different users can be applied by defining permission groups. Each permission group has specific types of allowed and prohibited actions, and users can be assigned to one of these groups, or customized allowed and prohibited actions can be created based on each user. Groups can be created for owners, editors, viewers, time-limited viewers, etc. Allowed or prohibited actions can include transferring ownership, adding content, modifying existing content, deleting existing content, changing permission levels or revoking access to one or more users or groups, changing encryption or compression settings, viewing all content, viewing specific parts of content, viewing ownership information, viewing creator information, and so on.

[0084] After granting access permissions to the requesting user, the super file server 630 responds to the client device 610. Based on the response, the client device 610 can access the entire content payload (or multiple payloads), a portion of the content payload, less than the entire content payload, etc., of the super file. In this example, the super file includes an encrypted content payload, and the super file server 630 determines that the requesting user has permission to access the content of the super file. In response to making this determination, the super file server 630 obtains cryptographic information from a record corresponding to the super file, stored in data accessible to the super file server 630, and provides the client device 610 with the cryptographic information required to decrypt the content payload. In the example of a compressed content payload, the super file server 630 may also provide information indicating the type of compression applied to the content payload.

[0085] At box 616, client device 610 receives cryptographic information and decrypts the contents of the superfile. In this example, the superfile contains only one content payload; however, if the superfile contains multiple content payloads, client device 610 may receive some or all of the cryptographic information required to decrypt the content payloads, and upon receiving such cryptographic information, decrypt the content payload whose cryptographic information was received. Similarly, if the content payload is compressed, client device 610 also decompresses any content payloads that can be decrypted. It should be understood that compression can be applied before or after encryption; therefore, the order of compression and decryption operations can be received from the superfile server or obtained from the header portion of the superfile. In this example, once the content is decrypted, the client device also immediately deletes the decryption key; however, in other examples, a copy of the decryption key may be retained when the file is opened.

[0086] At box 618, the client device 610 will present the decrypted contents of the super file to the user. The presentation method may vary depending on the type of content within the super file, such as playing audio, displaying video, presenting a document, etc.

[0087] At box 620, client device 610 maintains a communication connection with super file server 630 and transmits usage information to super file server 630 based on user activity with the content. For example, client device 610 may report which parts of the content are presented to the user, such as pages of a document reviewed by the user, tracks from a music album played by the user, portions of a movie or television program played by the user, whether the user rewinds, pauses, or fast-forwards content, how long the user has the super file open, and so on. Other information may also be provided, such as attempted prohibited actions, including attempts to edit documents, change permissions, view ownership information, etc.

[0088] It should be recognized that in some examples, usage information can be sent over time when the superfile is opened, although it can be aggregated at client device 610 and only sent when client device 610 closes the file. Other mechanisms can be employed to report usage information. Furthermore, while in this example the usage information is transmitted to the same superfile server 630 that initially contacted to open the superfile, it can be transmitted to any suitable computing device. For example, the superfile owner could include information indicating where the usage information should be sent when the superfile was created.

[0089] If communication between client device 610 and superfile server 630 is interrupted while the superfile is open, access to the superfile content can be suspended immediately or after a period of time. For example, a viewer of the superfile content may lose their internet connection, at which point their client device will no longer continue to render the superfile content. When communication with superfile server 630 is interrupted, it can further discard any cryptographic keys to prevent access to the superfile content. Once the connection is re-established, client device 610 can render the content again, which may include re-requesting cryptographic information from superfile server 630. The revocation of access can depend on the access level of a particular user. For example, the owner of the superfile may never lose access to the superfile content, while the creator or editor may have a longer timeout period, such as one hour, to allow them to continue revising the content without potentially losing their work. Other users may have shorter timeout periods. For example, non-anonymous viewers of the content may have short timeout periods, such as 5 to 10 minutes, to potentially smooth out the spread of the internet server. Anonymous viewers of the content may lose access immediately after the interruption. However, any suitable scheme can be used depending on the different examples.

[0090] At box 636, the super file server 630 receives usage information, stores it in the data store, and associates the usage information with the super file.

[0091] At box 662, the second client device modifies the content stored in a copy of the same superfile accessed by client device 610. For example, the owner of the superfile content can use client device 660 to modify the superfile content, while client device 610 opens a copy of the superfile. The changes made by client device 660 can be of any type and can be to the content payload, header section, adding a new content payload, removing an existing content payload, etc.

[0092] After making the changes, client device 660 provides the changes to super file server 630. The changes can be sent as an update to only a specific portion of the super file's content, or by sending the entire updated super file to super file server 630. Furthermore, the changes can be sent at any appropriate time, including in real-time when the changes are made, when the user of client device 660 selects the "Save file" option, or when the user of client device 660 closes the super file.

[0093] At box 638, super file server 630 receives changes from client device 660. In this example, super file server 630 is the same super file server 630 that is communicating with client device 610; however, in some examples, client device 660 may communicate with a different super file server 630 than client device 610.

[0094] Upon receiving the changed content, the super file server 630 updates one or more records associated with the super file in the data storage, as needed, based on the changes made by the client device 660. It then adds the new block to the blockchain corresponding to the super file, as discussed below with respect to box 638. Additionally, the super file server 630 notifies the client device 610 that the super file has been changed. In this example, the super file server 630 pushes the changed content to the client device 610 (and any other client devices with an open copy of the super file). However, in some examples, the super file server 630 notifies the client device 610 of the changed content, and the client device 610 can transmit a request for the changed content to the super file server 630. For example, the client device 610 can ask the user if they want to receive the changed content.

[0095] In an example where multiple superfile servers are associated with a specific superfile, each can access the same blockchain network to manage the creation of blockchains or blocks and the addition of blockchains or blocks to the network. Furthermore, each has access to the same data storage to obtain or update information about the superfile. Moreover, when one superfile server in the group receives an update to the superfile, it can broadcast a notification indicating that a change has been received, and other superfile servers can determine which client devices currently have copies of the superfile open and distribute the changed content as discussed above.

[0096] At box 640, the superfile server 630 adds a new block to the blockchain corresponding to the superfile. The new block includes information indicating changes to previous blocks in the blockchain, and in some examples, a copy of the changed superfile may be stored in the new block.

[0097] At box 622, client device 610 receives changed content from superfile server 630 when it opens a superfile. As discussed above, the changed content can be pushed by superfile server 630, or it can be requested by client device 610, for example, in response to a user indicating that they wish to receive changed content.

[0098] At box 624, the client device 610 presents the changed content to the user, typically as described above relative to box 618, and continues to send usage information by returning to box 620.

[0099] Therefore, this example method illustrates how a user obtains a copy of the superfile and how the system updates the user's copy of the superfile in real time when the user opens the file. Thus, the user is always able to view the latest version of the superfile, and the owner of the content within the superfile can ensure that the copy of the superfile always presents the current version of the content. It should be recognized that if the user closes the superfile before receiving the changed content, the superfile server 630 detects that the user has an older version of the content the next time the superfile is opened and serves the changed content at that time. Therefore, even if the user does not open the superfile when making changes, it will generally be updated the next time the file is opened, as described above with respect to boxes 662, 636, 638, 622, and 624.

[0100] Now refer to Figure 7 , Figure 7 The illustration shows an example method 700 for remote ownership and content control of media files on an untrusted system. Figure 7 The example shown will be relative to Figure 1 The example system 100 shown is discussed; however, any suitable system according to this disclosure may be used.

[0101] At box 712, the client device, such as client device 120a, receives a request to open a super file, such as when the user double-clicks the icon corresponding to the super file or selects the super file to open within the application.

[0102] At boxes 714 and 716, client device 120a transmits a request to access information about the super file to super file server 110, and in response, receives access information, typically as described above. Figure 4 Items 446, 362 and Figure 6The discussion is in box 614.

[0103] At box 718, client device 120a uses the received access information to decrypt the contents of the super file. It should be understood that, depending on the encryption or compression applied to the content (if any), box 718 may omit or involve decompressing the content, or both decompressing and decrypting the content.

[0104] At box 720, client device 120a presents the contents of the super file to the user, typically as shown above. Figure 6 The box 618 in the figure describes this.

[0105] At box 722, client device 120 receives modified super file content from a super file server (e.g., super file server 110), typically as described above relative to... Figure 4 Items 470, 472 or Figure 6 As described in box 622, the existing superfile content is replaced with the modified superfile content.

[0106] At box 724, client device 120a displays the modified super file content, typically as shown above relative to... Figure 4 or Figure 6 The box 624 describes this.

[0107] At box 726, client device 120a receives an access revocation instruction from the super file server, typically as described above relative to... Figure 4 The items 482 and 484 describe this.

[0108] At box 728, client device 120a revokes access to the contents of the super file. For example, client device 120a may discard any cryptographic keys, such as any cryptographic keys obtained at box 716. Client device 120a may also erase any decrypted copies of the contents stored in memory, such as when presenting the contents to the user. In some examples, client device 120a may also delete a copy of the super file from a long-term storage device (e.g., a hard drive).

[0109] It should be recognized that the boxes in this example method are executed in a specific order; however, it should also be recognized that the boxes can be executed in a different order, and some boxes may not be executed at all. For example, boxes 722 and 724 can be omitted if no modified superfile content is received. Similarly, boxes 726 and 728 can be omitted if no access revocation message is received. Additionally, boxes 722 and 724 can be repeated if the superfile is modified multiple times.

[0110] Now refer to Figure 8 , Figure 8An example method 800 for remote ownership and content control of media files on untrusted systems is shown. Figure 7 The example shown will be relative to Figure 1 The example system 100 shown is discussed; however, any suitable system according to this disclosure may be used.

[0111] At box 812, the super file server 110 receives the identifier of the new super file from the client device (e.g., client device 120a), typically as described above relative to... Figure 4 Item 440 and Figure 5 The discussion is in boxes 514 and 522.

[0112] At box 814, the super file server 110 adds a new blockchain to the blockchain network, for example, blockchain network 330, typically as described above relative to... Figure 4 Item 442 or Figure 5 The box 524 describes this.

[0113] At box 816, the super file server 110 receives a request from the client device to access the contents of the super file, typically as described above relative to... Figure 4 Items 446, 462 or Figure 6 The box 614 describes this.

[0114] At boxes 818 and 820, the super file server 110 determines the access level of the super file and provides access information, typically as described above relative to... Figure 4 Items 448, 464 or Figure 6 The boxes 632 and 634 describe this.

[0115] At box 822, the super file server 110 receives usage information from the client device, typically as described above. Figure 4 Item 450 or Figure 6 The box 636 describes this.

[0116] At box 824, the super file server 110 receives modifications to the contents of the super file from the client device, typically as described above relative to... Figure 4 Item 467 or Figure 6 The box 638 describes this.

[0117] At box 826, the super file server 110 adds a new block to the blockchain associated with the super file, typically as described above relative to... Figure 4 Item 468 or Figure 6 The box 640 is described.

[0118] At box 828, the super file server 110 distributes changes to the super file to client devices that have opened copies of the super file, typically as described above. Figure 4 Items 470, 472 or Figure 6 The boxes 622 and 638 describe this.

[0119] At box 830, the super file server 110 receives modifications to the access levels of the super file. For example, the owner of the super file can modify the access levels for different groups of users or individual users. The super file server 110 can receive these changes and update the corresponding records in the data storage 112, or it can add new blocks to the blockchain corresponding to the super file to reflect the updated permissions.

[0120] At box 832, the super file server 110 transmits instructions to clients that have an open copy of the super file. For example, if a modification to the access level revokes access to one or more users, the super file server 110 transmits instructions to any client device with the open super file so that one of the identified users can revoke access to the super file, as described above relative to... Figure 8 Items 482, 484 or Figure 7 As described in boxes 726 and 728. If a modification to the access level lowers the access level, for example, from editor to viewer, the super file server 110 can transmit a corresponding instruction, which can prevent the corresponding client from the user making or saving further modifications to the super file content. Additionally, the client device can present a notification of the access level change to the user. Similarly, if a modification to the access level increases the user's access level, for example, from viewer to editor, the client device can present a notification of the access level change to the user and enable the option in the corresponding application to allow editing and saving changes to the super file content.

[0121] It should be recognized that the boxes in this example method are executed in a specific order; however, it should also be recognized that the boxes can be executed in a different order, and some boxes may not be executed at all. For example, boxes 824 to 828 can be omitted if no modified superfile content is received. Similarly, boxes 830 and 832 can be omitted if no access changes to any access level are received. Furthermore, one or more boxes in boxes 822 to 832 can be repeated based on actions taken by various client devices.

[0122] Now refer to Figure 9 , Figure 9An example computing device 900 according to this disclosure is illustrated, suitable for use in an example system or method for remote ownership and content control of media files on an untrusted system. The example computing device 900 includes a processor 910 that communicates with a memory 920 and other components of the computing device 900 using one or more communication buses 902. The processor 910 is configured to execute processor-executable instructions stored in the memory 920 to perform one or more methods, according to various examples, for coordinating participant interaction during a video webinars, such as those described above. Figures 5 to 8 The example methods 500 to 800 described may be some or all of them. In this example, the computing device 900 also includes one or more user input devices 950, such as a keyboard, mouse, touchscreen, microphone, etc., for accepting user input. The computing device 900 also includes a display 940 for providing visual output to the user.

[0123] The computing device 900 also includes a communication interface 940. In some examples, the communication interface 930 can enable communication using one or more networks, including a local area network (“LAN”), a wide area network (“WAN”) (such as the Internet), a metropolitan area network (“MAN”), a point-to-point or peer-to-peer connection, etc. Communication with other devices can be accomplished using any suitable networking protocol. For example, a suitable networking protocol may include the Internet Protocol (“IP”), Transmission Control Protocol (“TCP”), User Datagram Protocol (“UDP”), or combinations thereof, such as TCP / IP or UDP / IP.

[0124] While some examples of the methods and systems described herein are based on software executed on various machines, the methods and systems can also be implemented as specifically configured hardware, such as a field-programmable gate array (FPGA), specifically for performing various methods according to this disclosure. For example, examples can be implemented in digital electronic circuit systems or in computer hardware, firmware, software, or a combination thereof. In one example, the device may include one or more processors. The processor includes computer-readable media, such as random access memory (RAM) coupled to the processor. The processor executes computer-executable program instructions stored in the memory, such as executing one or more computer programs. Such processors may include microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and state machines. Such processors may further include programmable electronic devices, such as a PLC, a programmable interrupt controller (PIC), a programmable logic device (PLD), a programmable read-only memory (PROM), an electronically programmable read-only memory (EPROM or EEPROM), or other similar devices.

[0125] Such processors may include media capable of storing processor-executable instructions, such as one or more non-transitory computer-readable media, which, when executed by the processor, enable the processor to perform methods performed or assisted by the processor according to this disclosure. Examples of non-transitory computer-readable media may include, but are not limited to, electronic, optical, magnetic, or other storage devices capable of providing processor-executable instructions to a processor (such as a processor in a web server). Other examples of non-transitory computer-readable media include, but are not limited to, floppy disks, CD-ROMs, magnetic disks, memory chips, ROMs, RAMs, ASICs, configured processors, all optical media, all magnetic tapes or other magnetic media, or any other media readable by a computer processor. The described processors and processes may be in one or more structures and may be distributed through one or more structures. The processor may include code for performing methods (or portions thereof) according to this disclosure.

[0126] The foregoing description of some examples is presented for illustrative and descriptive purposes only and is not intended to be exhaustive or to limit this disclosure to its precise form. Many modifications and adjustments thereto will become apparent to those skilled in the art without departing from the spirit and scope of this disclosure.

[0127] References to examples or embodiments herein mean that a particular feature, structure, operation, or other characteristic described in connection with an example may be included in at least one embodiment of this disclosure. This disclosure is not limited to the particular examples or embodiments described herein. The phrases “in one example,” “in an example,” “in one embodiment,” or “in an embodiment,” or variations thereof, appearing in various places throughout the specification, do not necessarily refer to the same example or embodiment. Any particular feature, structure, operation, or other characteristic described in this specification with respect to one example or embodiment may be combined with other features, structures, operations, or other characteristics described with respect to any other example or embodiment.

[0128] The word “or” is used in this document to cover both including and excluding OR conditions. In other words, A or B or C includes any or all of the following alternative combinations applicable to a particular use: including A alone; including B alone; including C alone; including only A and B; including only A and C; including only B and C; and including A, B, and C.

Claims

1. A method executed by a client computing device, comprising: The client computing device receives a request to open a super file stored in a memory device, the super file including an unencrypted header portion and encrypted content, and the request includes user credential information. In response to receiving the request to open the super file, the client computing device identifies a remote server based on the unencrypted header portion and passes the request to the identified remote server to access the super file, the request including credentials associated with the user account; Receive the key from the remote server; Use the key to decrypt the encrypted content; Access and present decrypted content; When accessing the decrypted content, communication is maintained with the remote server; When the decrypted content is accessed through the client computing device: Modified encrypted content is received from the server via maintained communication. The modified encrypted content is created at a second client computing device and sent to the server via the second client computing device, which has a second copy of the super file. Replace the encrypted content with the modified encrypted content; as well as The modified encrypted content is presented instead of the original encrypted content.

2. The method according to claim 1, further comprising: When the super file is opened, usage information associated with the super file is provided, as well as communication maintained with the remote server.

3. The method according to claim 2, wherein, The usage information indicates a portion of the decrypted content being presented or user input associated with the decrypted content.

4. The method according to claim 1, further comprising, when accessing the decrypted content: Receive an instruction indicating the loss of access to the encrypted content; The presentation of the decrypted content will cease; as well as Delete the decrypted content.

5. The method according to claim 1, further comprising, when accessing the decrypted content: The client computing device receives the modification of the decrypted content; Update the encrypted content based on the modifications; Replace the encrypted content with the updated encrypted content in the memory device of the client computing device; as well as The updated encrypted content is provided to the remote server.

6. The method of claim 1, further comprising, when accessing the decrypted content: Detect the loss of connectivity to the remote server; The presentation of the decrypted content will cease; as well as Delete the decrypted content.

7. The method of claim 1, further comprising: When the decrypted content is accessed, usage statistics related to the encrypted content are provided to the remote server.

8. A method executed by a server, comprising: The server receives a request from a remote client device to access encrypted content within a super file. The request includes user credential information, the super file is stored in the remote client device's storage device, and includes encrypted content and a second copy of the super file stored in the server's storage device. Determine the authorization level for accessing the encrypted content; In response to determining the authorization level: Provide the key to the remote client device; as well as When the super file is opened on the remote client device, usage information from the remote client device associated with the encrypted content is received and stored; The modified encrypted content is received from a second client device, which has a third copy of the super file stored in the storage device of the second client device, and the modified encrypted content is created at the second client device. The second copy of the super file is updated based on the modified encrypted content; as well as The modified encrypted content is sent to the second client device to update the super file.

9. The method according to claim 8, wherein, The usage information indicates a portion of the content being presented in the superfile or user input associated with the content being presented in the superfile.

10. The method according to claim 8, wherein, The authorization level includes at least one of the owner of the encrypted content or the authorized viewer of the encrypted content.

11. The method of claim 8, further comprising: Based on the modified encrypted content, block records are generated for the blockchain corresponding to the super file; as well as Add the block record to the blockchain.

12. The method of claim 8, further comprising: A request is received from a third remote client device for accessing encrypted content within a fourth copy of the super file. The request includes second user credential information. The second copy of the super file is stored in a second storage device of the third remote client device and includes the encrypted content. Determine the authorization level for accessing the encrypted content; In response to determining the authorization level: The updated super file information is provided to the third remote client device, and the updated super file information includes the modified content; Provide the key to the third remote client device; as well as When the super file is opened at the third remote client device, usage information from the third remote client device associated with the modified encrypted content is received and stored.

13. The method of claim 8, further comprising: Receive modifications to one or more access levels of the superfile; Based on the modification of the one or more access levels of the super file, instructions are transmitted to one or more clients that have an open copy of the super file.

Images